Bundesamt Für Sicherheit in Der Informationstechnik

Bundesamt fr Sicherheit in der Informationstechnik 2004
Der Prsident
_________________________________________________________________________________________
Vorwort
Das vorliegende IT-Grundschutzhandbuch enthlt Standardsicherheitsmanahmen, Umsetzungshin-

weise und Hilfsmittel fr zahlreiche IT-Konfigurationen, die typischerweise im heutigen IT-Einsatz
anzutreffen sind. Dieses Informationsangebot soll zur zgigen Lsung hufiger Sicherheitsprobleme
dienen, die Anhebung des Sicherheitsniveaus von IT-Systemen untersttzen und die Erstellung von
IT-Sicherheitskonzepten vereinfachen. Die im IT-Grundschutzhandbuch zusammengestellten Stan-
dardsicherheitsmanahmen orientieren sich dabei an einem Schutzbedarf, der fr die meisten IT-
Systeme zutrifft.
Damit kann fr die berwiegende Zahl der IT-Systeme der bislang arbeitsintensive Prozess der
Erstellung eines IT-Sicherheitskonzepts erheblich vereinfacht werden, da aufwendige und oft kom-
plexe Analysen von Bedrohungen und Eintrittswahrscheinlichkeiten entfallen. Mit Verwendung des
Handbuchs bedarf es lediglich eines Abgleichs des Manahmen-Solls mit dem Manahmen-Ist, um
Sicherheitsdefizite zu ermitteln und passende Sicherheitsmanahmen zu identifizieren.
Das IT-Grundschutzhandbuch ist als "weiterentwicklungsfhiges Werk" angelegt. Durch eine halb-
jhrliche Fortschreibung sollen Verbesserungsvorschlge, Erweiterungen sowie die Weiterent-
wicklung der IT bercksichtigt werden. Fr die von den Anwendern des IT-Grundschutzhandbuchs
bersandten Beitrge, die bei der Fortschreibung der vorliegenden Version bercksichtigt wurden,
mchte ich mich bedanken.
Dr. Udo Helmbrecht
_________________________________________________________________________________________
IT-Grundschutzhandbuch: 5. EL Stand Oktober 2003 1
Bundesamt fr Sicherheit in der Informationstechnik 2004
Der Prsident
_________________________________________________________________________________________
Hinweis:
Wird im Text die mnnliche Form verwendet, geschieht dies ausschlielich aus Grnden der
leichteren Lesbarkeit.
_________________________________________________________________________________________
Dankesworte 2004
_________________________________________________________________________________________
Dankesworte
Fr die Mitarbeit bei der Weiterentwicklung des IT-Grundschutzes und die engagierte Untersttzung
bei der Fortschreibung der 5. Ergnzungslieferung des IT-Grundschutzhandbuchs wird an dieser Stelle
folgenden Beteiligten gedankt:
- Gesamtkoordination Frau Isabel Mnch, BSI

- Redaktionelle Bearbeitung und Hotline Frau Elke Csar, BSI
Frau Gabriele Scheer-Gumm, BSI
Frau Petra Simons-Felwor, BSI
- Baustein Router und Switches Herr Herbert Blaauw, Atos Origin CCI
Herr Matthias Mnter, Atos Origin CCI
Herr Thomas Hberlen, BSI
- Baustein S/390- und zSeries-Mainframe Herr Stephan Httinger, TSI (T-Systems
International GmbH)
Herr Torsten Kullich, TSI
Herr Klaus Mller, TSI
Herr Stefan Morkovsky, TSI
Herr Dr. Harald Niggemann, BSI
- Baustein PDA Frau Isabel Mnch, BSI
Herr Thomas Hberlen, BSI
- berarbeitung Baustein Sicherheitsgateway Herr Bjrn Dehms, BSI
(Firewall) Herr Thomas Hberlen, BSI
- Qualittssicherung Frau Isabel Mnch, BSI
Herr Dr. Harald Niggemann, BSI
Herr Michael Mehrhoff, BSI
Herr Frank Weber, BSI
Darber hinaus sei allen gedankt, die sich durch konstruktive Kritik und praktische Verbesserungs-
vorschlge an der Verbesserung des IT-Grundschutzhandbuchs beteiligt haben.
Bei der Fortschreibung und Weiterentwicklung vorhergehender Versionen des IT-Grundschutz-

handbuchs haben die nachfolgend aufgezhlten Personen und Institutionen mitgewirkt. Auch ihnen sei
hiermit Dank ausgesprochen:
_________________________________________________________________________________________
IT-Grundschutzhandbuch: 6. EL Stand 2004 3
Dankesworte 2004
_________________________________________________________________________________________
- ConSecur GmbH - Innenministerium des Landes

Herr Nedon, Hr. Eckardt Schleswig-Holstein
Herr Kuhr
- Daimler-Benz AG
Herr Heinle, Hr. Schlette - Landesbeauftragter fr den Datenschutz
Saarland
- Europische Kommission
Herr Simon
GD Informationsgesellschaft
Herr Achim Klabunde - Fa. Novell
- Fa. EUROSEC GmbH - Fa. Oracle
Herr Fnfrocken
- Rhm GmbH Chemische Fabrik
Herr Dr. Zieschang
Datenschutzbeauftragter
- Evangelische Kirche von Westfalen, Herr Gldemeister
Das Landeskirchenamt
- Atos Origin CCI
Herr Huget
Herr Gtz, Herr Jaster, Herr Pohl
- Flughafen Dsseldorf GmbH
- Universitt GH Essen, FB Wirtschaft-
Herr Andreas Peters
informatik
- GUIDE SHARE EUROPE Herr Prof. Dr. Vobein
Arbeitskreis "DATENSCHUTZ und
- Universittsklinikum der TU Dresden
DATENSICHERHEIT"
Klinik fr Orthopdie
- Henkel KGaA Herr Frank Heyne
Herr Rhefus
- Verband der Chemischen Industrie e. V.
- HiSolutions Software GmbH
- VZM GmbH
Herr Alexander Geschonneck
Herr Bruno Hecht, Herr Werner Metterhausen,
- INFODAS Herr Rainer von zur Mhlen
Herr Dr. Weck
- Zentrale Datenverarbeitungsstelle fr das
- Ingenieurbro Mink Saarland
Herr Mller
_________________________________________________________________________________________
Dankesworte 2004
_________________________________________________________________________________________
Folgende Autoren haben durch die Erstellung von Bausteinen ihr Fachwissen in das IT-
Grundschutzhandbuch einflieen lassen. Ihnen gebhrt besonderer Dank, da ihr Engagement die
Entstehung und Weiterentwicklung des IT-Grundschutzhandbuchs erst ermglicht hat.
Bundesministerium des Innern: Herr Jrg-Udo Aden, Herr Andr Reisen, Herr Manfred Kramer
Bundesministerium fr Bildung und Wissenschaft: Herr Frank Stefan Stumm
Bundesamt fr Sicherheit in der Informationstechnik: Herr Rainer Belz, Herr Thomas Biere, Herr Uwe
Dornseifer, Herr Gnther Ennen, Herr Olaf Erber, Herr Frank W. Felzmann, Herr Michael Frtsch,
Herr Dr. Kai Fuhrberg, Herr Dr. Dirk Hger, Herr Dr. Hartmut Isselhorst, Herr Harald Kelter, Herr
Kurt Klinner, Herr Dr. Christian Mrugalla, Frau Isabel Mnch, Herr Robert Rasten, Frau Martina
Rohde, Herr Fabian Schelo, Herr Heiner Schorn, Herr Dr. Ernst Schulte-Geers, Herr Carsten Schulz,
Herr Bernd Schweda, Frau Katja Vogel, Herr Frank Weber, Herr Helmut Weisskopf, Herr Dr. Stefan
Wolf
_________________________________________________________________________________________
Inhaltsverzeichnis 2004
_________________________________________________________________________________________
Inhaltsverzeichnis
Vorwort
Inhaltsverzeichnis
Einleitung
1 Wegweiser durch das 4 Infrastruktur

IT-Grundschutzhandbuchs
1.1 IT-Grundschutz: Ziel, Idee und 4.1 Gebude
Konzeption 4.2 Verkabelung
1.2 Aufbau und Lesart des Handbuchs 4.3 Rume
1.3 Anwendungsweisen des 4.3.1 Broraum
IT-Grundschutzhandbuchs 4.3.2 Serverraum
1.4 Kurzdarstellung vorhandener Bausteine 4.3.3 Datentrgerarchiv
1.5 Hilfsmittel 4.3.4 Raum fr technische Infrastruktur
1.6 Informationsfluss und Kontakte 4.4 Schutzschrnke
4.5 Huslicher Arbeitsplatz
4.6 Rechenzentrum
2 Anwendung des IT- 5 Nicht vernetzte Systeme
Grundschutzhandbuchs
2.1 IT-Strukturanalyse 5.1 DOS-PC (ein Benutzer)
2.2 Schutzbedarfsfeststellung 5.2 Unix-System
2.3 Modellierung nach IT-Grundschutz 5.3 Tragbarer PC
2.4 Basis-Sicherheitscheck 5.4 PCs mit wechselnden Benutzern
2.5 Ergnzende Sicherheitsanalyse 5.5 PC unter Windows NT
2.6 Realisierung von 5.6 PC mit Windows 95
IT-Sicherheitsmanahmen 5.7 Windows 2000 Client
2.7 IT-Grundschutz-Zertifikat 5.8 Internet-PC
5.99 Allgemeines nicht vernetztes IT-System
3 bergeordnete Komponenten 6 Vernetzte Systeme
3.0 IT-Sicherheitsmanagement 6.1 Servergesttztes Netz
3.1 Organisation 6.2 Unix-Server
3.2 Personal 6.3 Peer-to-Peer-Dienste
3.3 Notfallvorsorge-Konzept 6.4 Windows NT Netz
3.4 Datensicherungskonzept 6.5 Novell Netware 3.x
3.5 Datenschutz 6.6 Novell Netware 4.x
3.6 Computer-Virenschutzkonzept 6.7 Heterogene Netze
3.7 Kryptokonzept 6.8 Netz- und Systemmanagement
3.8 Behandlung von Sicherheitsvorfllen 6.9 Windows 2000 Server
3.9 Hard- und Software-Management 6.10 S/390- und z-Series-Mainframe
3.10 Outsourcing
_________________________________________________________________________________________
Inhaltsverzeichnis 2004
_________________________________________________________________________________________
7 Datenbertragungseinrichtungen 8 Telekommunikation
7.1 Datentrgeraustausch 8.1 TK-Anlage
7.2 Modem 8.2 Faxgert
7.3 Sicherheitsgateway (Firewall) 8.3 Anrufbeantworter
7.4 E-Mail 8.4 LAN-Anbindung eines IT-Systems ber
7.5 Web Server ISDN
7.6 Remote Access 8.5 Faxserver
7.7 Lotus Notes 8.6 Mobiltelefon
7.8 Internet Information Server 8.7 PDA
7.9 Apache Webserver
7.10 Exchange/Outlook2000
7.11 Router und Switches
9 Sonstige IT-Komponenten
9.1 Standardsoftware
9.2 Datenbanken
9.3 Telearbeit
9.4 Novell eDirectory 8.6
9.5 Archivierung
Kataloge zu Manahmen und

Gefhrdungen
Manahmenkataloge Gefhrdungskataloge
M1 Infrastruktur G1 Hhere Gewalt
M2 Organisation G2 Organisatorische Mngel
M3 Personal G3 Menschliche Fehlhandlungen
M4 Hardware/Software G4 Technisches Versagen
M5 Kommunikation G5 Vorstzliche Handlungen
M6 Notfallvorsorge
Anhang
- Hilfsmittel
- KBSt- Empfehlungen 2/95
- Bezugsdokumente
- Index
_________________________________________________________________________________________
Neues 2004
_________________________________________________________________________________________
Neues in Version 2004 des IT-Grundschutzhandbuchs

Bedarfsorientierte Weiterentwicklung
Aufgrund der jhrlichen Bedarfsabfrage bei registrierten Anwendern wurde das Handbuch bedarfs-
orientiert weiterentwickelt.
Insgesamt wurden fr die Version 2004 folgende Bausteine neu entwickelt:
6.10 S/390- und z-Series-Mainframe
8.7 PDA
Aktualisierung und berarbeitung
Der Baustein 7.3 wurde berarbeitet und enthlt jetzt alle Grundschutzmanahmen zum Thema
Sicherheitsgateway (Firewall).
Darber hinaus wurden zahlreiche einzelne Gefhrdungen und Manahmen an neue technische
Entwicklungen, neue Bedrohungsszenarien und neue Entwicklungen in der IT-Sicherheit angepasst.
Weitere strukturelle Vernderungen wurden in der aktualisierten Ausgabe nicht durchgefhrt. Die
Nummerierung bestehender Gefhrdungen und Manahmen blieb erhalten, sodass ein im Vorjahr auf
Basis des IT-Grundschutzhandbuchs erstelltes Sicherheitskonzept fortgeschrieben werden kann. Es
empfiehlt sich dennoch, die ausgewhlten Manahmen bei der Bearbeitung komplett zu lesen, um
Ergnzungen bercksichtigen zu knnen und um ggf. das Wissen zur IT-Sicherheit aufzufrischen.
Eine detaillierte Darstellung der durchgefhrten nderungen kann dem Winword-Versionsvergleich
entnommen werden, der sich auf der CD-ROM im Verzeichnis .../VGL befindet.
Rechtschreibung
In das Handbuch neu aufgenommene Seiten wurden nach den Regeln der Rechtschreibreform
abgefasst. Erfolgte fr ein auszutauschendes Blatt eine inhaltliche nderung auf nur einer Seite, so
wurde auch fr die andere Seite des Blattes die neue Rechtschreibung angewandt. Auf diese Weise
soll verhindert werden, dass mit dem Ablauf der bergangszeit zum 31. August 2005 eine
vollstndige berarbeitung des Werkes erfolgen muss. Um die Blattzahl der Ergnzungslieferung
durch die Anwendung der neuen Rechtschreibung nicht unntig zu erhhen, wurde darauf verzichtet,
nderungen bis ins letzte Detail durchzufhren. Dies hat jedoch zur Folge, dass z. B. die Schreibweise
einer Manahmenberschrift im Inhaltsverzeichnis von der Schreibweise im Manahmenkatalog
abweichen kann.
Fuzeilen
Seiten, die neu in das Handbuch aufgenommen oder inhaltlich aktualisiert wurden, sind durch die
Fuzeile "Stand 2004" gekennzeichnet. Wurde auf einer Seite lediglich die Rechtschreibung an die
neuen Regeln angepasst oder Marginalien hinzugefgt, so wurde die Angabe zum Versionsstand
_________________________________________________________________________________________
Neues 2004
_________________________________________________________________________________________
nicht verndert. Auf diese Weise ist anhand der Fuzeilen direkt erkennbar, welche Seiten sich
inhaltlich gendert haben.
WWW-Seiten zum IT-Grundschutz
Das Bundesamt fr Sicherheit in der Informationstechnik ist auch ber das Internet erreichbar. Den
aktuellen Sachstand zum IT-Grundschutz knnen Sie ber die Seite http://www.bsi.bund.de/gshb
abrufen. Auf diesen Seiten ist ein Forum eingerichtet, um aktuelle Informationen zum IT-Grund-
schutzhandbuch zeitnah zu prsentieren.
IT-Grundschutz-Zertifikat
Da das IT-Grundschutzhandbuch mit seinen Empfehlungen von Standardsicherheitsmanahmen
inzwischen einen Quasi-Standard fr IT-Sicherheit darstellt, bietet es sich an, dies als allgemein aner-
kanntes Kriterienwerk fr IT-Sicherheit zu verwenden. Hufige Anfragen nach einem "bescheinigten
Sicherheitsgrad" haben im BSI zu dem Entschluss gefhrt, ein Grundschutz-Zertifikat zu entwickeln.
Der weitere Sachstand wird in Kapitel 2.7 IT-Grundschutz-Zertifikat beschrieben. Aktuelle
Informationen finden sich im Internet unter http://www.bsi.bund.de/gshb/zert.
_________________________________________________________________________________________
Einleitung 2004
_________________________________________________________________________________________
Einleitung
IT-Grundschutz - Basis fr IT-Sicherheit
Zunehmend werden Funktionen in der ffentlichen
Verwaltung und der Wirtschaft, aber auch im tglichen
Leben in der modernen Informations- und Kommuni-
kationsgesellschaft durch den Einsatz von Informations-
technik (IT) untersttzt. Viele Arbeitsprozesse werden
elektronisch gesteuert und groe Mengen von Infor-
mationen werden digital gespeichert, elektronisch
verarbeitet und in lokalen und ffentlichen Netzen
bermittelt. Die Wahrnehmung mancher ffentlicher oder
privatwirtschaftlicher Aufgaben ist ohne IT berhaupt
nicht, die Erfllung anderer Aufgaben nur noch teilweise mglich. Damit sind viele Institutionen in
Verwaltung und Wirtschaft von dem einwandfreien Funktionieren der eingesetzten IT abhngig. Ein
Erreichen der Behrden- und Unternehmensziele ist nur bei ordnungsgemem und sicheren IT-
Einsatz mglich.
Dabei sind die auftretenden Abhngigkeiten von einer funktionierenden IT vielfltig. Fr Unter-
nehmen hngt der wirtschaftliche Erfolg und die Konkurrenzfhigkeit von der IT ab, letztlich sind es
damit sogar Arbeitspltze, die direkt vom Funktionieren der IT abhngen. Ganze Branchen wie zum
Beispiel Banken und Versicherungen, Automobilindustrie und Logistik knnen heute nicht mehr ohne
IT betrieben werden. Letztlich hngt damit das Wohl jedes Brgers von der IT ab: sei es der Arbeits-
platz des Brgers, sei es die Erfllung des tglichen Konsumbedarfs oder seine digitale Identitt im
Zahlungsverkehr, in der Kommunikation oder zunehmend im E-Commerce. Mit der Abhngigkeit von
der IT erhht sich auch der potentielle soziale Schaden durch den Ausfall von IT. Da IT an sich nicht
frei von Schwachstellen ist, besteht ein durchaus berechtigtes Interesse, die von der IT verarbeiteten
Daten und Informationen zu schtzen und die Sicherheit der IT zu planen, zu realisieren und zu
kontrollieren.
Die Schden durch IT-Fehlfunktionen knnen verschiedenen Kategorien zugeordnet werden. Am
aufflligsten ist der Verlust der Verfgbarkeit: luft ein IT-System nicht, knnen keine Geldtrans-
aktionen durchgefhrt werden, Online-Bestellungen sind unmglich, Produktionsprozesse stehen still.
Hufig diskutiert ist auch der Verlust der Vertraulichkeit von Daten: jeder Brger wei um die
Notwendigkeit, seine personenbezogenen Daten vertraulich zu halten, jedes Unternehmen wei, dass
firmeninterne Daten ber Umsatz, Marketing, Forschung und Entwicklung die Konkurrenz interessie-
ren. Aber auch der Verlust der Integritt (Korrektheit von Daten) kann schwerwiegende Folgen haben:
geflschte oder verflschte Daten fhren zu Fehlbuchungen, Produktionsprozesse stoppen wegen
fehlerhafter Lieferungen, falsche Entwicklungs- und Planungsdaten fhren zu fehlerhaften Produkten.
Seit einigen Jahren gewinnt auch der Verlust der Authentizitt als ein Teilbereich der Integritt an
Bedeutung: Daten werden einer falschen Person zugeordnet. Beispielsweise knnen Zahlungsan-
weisungen oder Bestellungen zu Lasten einer dritten Person verarbeitet werden, ungesicherte digitale
Willenserklrungen knnen falschen Personen zugerechnet werden, die "digitale Identitt" wird
geflscht.
Dabei wird diese Abhngigkeit von der IT in Zukunft noch weiter zunehmen. Besonders erwhnens-
wert sind dabei folgende Entwicklungen:
_________________________________________________________________________________________
IT-Grundschutzhandbuch: 3. EL Stand Juli 2001 10
Einleitung 2004
_________________________________________________________________________________________
- Steigender Vernetzungsgrad: IT-Systeme arbeiten heutzutage nicht mehr isoliert voneinander,

sondern werden immer strker vernetzt. Die Vernetzung ermglicht es, auf gemeinsame Daten-
bestnde zuzugreifen und intensive Formen der Kooperation ber geographische Grenzen hinweg
zu nutzen. Damit entsteht nicht nur eine Abhngigkeit von den einzelnen IT-Systemen, sondern in
starkem Mae auch von den Datennetzen. Sicherheitsmngel eines IT-Systems knnen aber
dadurch schnell globale Auswirkungen haben.
- IT-Verbreitung: Immer mehr Bereiche werden durch Informationstechnik untersttzt. So findet
beispielsweise eine Verlagerung des Konsums in den Bereich E-Commerce statt, Auto- und
Verkehrsleittechnik werden IT-gesttzt perfektioniert, Haushaltsgerte lassen sich programmieren
und werden vernetzt.
- Steigende Leistungsfhigkeit: die fortschreitende Miniaturisierung ermglicht eine Leistungs-
steigerung der Hardwaretechnik, so dass immer mehr rechenintensive Aufgaben in dezentrale
Rechner oder sogar Mikroprozessoren verlagert werden knnen. Besonders deutlich zeigt sich dies
im Bereich Chipkartentechnologie. Moderne multifunktionale Chipkarten knnen Zahlungsverkehr
abwickeln, dienen zur Zeiterfassung, knnen Zutrittskontrollen ermglichen und hochkomplexe
mathematische Verschlsselungsoperationen durchfhren. Die Leistungssteigerung der Hardware
erlaubt auch die Implementation aufwendiger Softwarealgorithmen in Kleinstrechnern, fr die vor
einem Jahrzehnt noch Grorechner notwendig waren. Selbst Vorstellungen ber Software als
mobiler Code, der im Internet beispielsweise kostengnstige Anbieter bestimmter Waren autonom
sucht, konkretisieren sich derzeit.
Dabei steigt das Gefhrdungspotential berproportional an, da mehrere Ursachen zusammentreffen:
- Die Abhngigkeit von der IT und damit die Verletzlichkeit nimmt wie oben beschrieben zu.
- Die Verantwortung fr die Umsetzung der IT-Sicherheitsmanahmen ist hufig auf viele Einzel-
personen verteilt. Dabei sind einzelne Verantwortliche schnell durch die vielschichtigen Problem
im Bereich IT-Sicherheit berfordert.
- Das Wissen um Gefhrdungen und Manahmen zur IT-Sicherheit ist unzureichend. Kurze Innova-
tionszyklen der IT erschweren es, den berblick ber neue oder neu entdeckte Gefhrdungen und
notwendige Gegenmanahmen zu behalten. In vielen Fllen besteht auch Unsicherheit darber,
welche Sicherheitsmanahmen angemessen sind, um den jeweiligen Gefhrdungen zu begegnen.
- Die steigende Funktionalitt birgt letztlich auch eine grere Angriffsflche. Immer wieder werden
in Protokollen und Netzdiensten, aber auch in lokaler Anwendungssoftware Sicherheitslcher
gefunden, die fr Angriffe ausgenutzt werden knnen.
- Es findet eine immer weitergehende ffnung der IT-Systeme nach auen statt, z. B. durch Vernet-
zung, Internet-Zugang und Internetauftritt. Dadurch knnen aber auch immer mehr potentielle
Angreifer auf die IT-Systeme zugreifen.
Bezglich des Gefhrdungspotentials ist zwischen vorstzlich herbeigefhrten und durch "zufllige
Ereignisse" verursachten Schden zu unterscheiden. Letztere umfassen Strungen durch hhere
Gewalt, technisches Versagen, Nachlssigkeit und Fahrlssigkeit. Statistisch verursachen diese
"zuflligen Ereignisse" die meisten Schden. Demgegenber sind Schden, die auf vorstzliche
Handlungen zurckgefhrt werden knnen, seltener, aber bei Eintritt hufig kritischer. Als Ttermoti-
vationen sind hier Spieltrieb, Rachegefhle, Neid und persnliche Bereicherung zu nennen. Sowohl
bei den vorstzlichen als auch bei den nicht-vorstzlichen Strungen kann zustzlich noch dahin-
gehend unterschieden werden, ob die Ursache des Schadens innerhalb oder auerhalb der Institution
zu suchen ist. Bemerkenswert ist in diesem Zusammenhang, dass im Bereich vorstzlich herbeige-
fhrter IT-Schden der berwiegende Teil auf "Innentter" zurckgefhrt werden kann.
_________________________________________________________________________________________
Einleitung 2004
_________________________________________________________________________________________
Angesichts der vorgestellten Gefhrdungspotentiale und der steigenden Abhngigkeit stellen sich
damit fr jede Institution, sei es ein Unternehmen oder eine Behrde, bezglich IT-Sicherheit mehrere
zentrale Fragen:
- Wie sicher ist die IT einer Institution?
- Welche IT-Sicherheitsmanahmen mssen ergriffen werden?
- Wie mssen diese Manahmen konkret umgesetzt werden?
- Wie hlt bzw. verbessert eine Institution das erreichte Sicherheitsniveau?
- Wie sicher ist die IT anderer Institutionen, mit denen eine Kooperation stattfindet?
Bei der Suche nach Antworten auf diese Fragen ist zu beachten, dass IT-Sicherheit nicht alleine eine
technische Fragestellung ist. Um ein ausreichend sicheres IT-System betreiben zu knnen, sind neben
den technischen auch organisatorische, personelle und baulich-infrastrukturelle Manahmen zu reali-
sieren und insbesondere ist ein IT-Sicherheitsmanagement einzufhren, das die Aufgaben zur IT-
Sicherheit konzipiert, koordiniert und berwacht.
Vergleicht man jetzt die IT-Systeme aller Institutionen im Hinblick auf obige Fragen, so kristallisiert
sich eine besondere Gruppe von IT-Systemen heraus. Die IT-Systeme in dieser Gruppe lassen sich wie
folgt charakterisieren:
- Es sind typische IT-Systeme, d. h. diese Systeme sind keine Individuallsungen, sondern sie sind
weit verbreitet im Einsatz.
- Der Schutzbedarf der IT-Systeme bezglich Vertraulichkeit, Integritt und Verfgbarkeit liegt im
Rahmen des Normalmaes.
- Zum sicheren Betrieb der IT-Systeme sind Standard-Sicherheitsmanahmen aus den Bereichen
Infrastruktur, Organisation, Personal, Technik und Notfallvorsorge erforderlich.
Gelingt es, fr diese Gruppe der "typischen" IT-Systeme den gemeinsamen Nenner aller Sicherheits-
manahmen, die Standard-Sicherheitsmanahmen, zu beschreiben, so wrde dies die Beantwortung
obiger Fragen fr diese "typischen" IT-Systeme erheblich erleichtern. IT-Systeme, die auerhalb
dieser Gruppe liegen, seien es seltenere Individualsysteme oder IT-Systeme mit sehr hohem Schutz-
bedarf, knnen sich dann zwar an den Standard-Sicherheitsmanahmen orientieren, bedrfen letztlich
aber einer individuellen Betrachtung.
Das IT-Grundschutzhandbuch beschreibt detailliert diese Standard-Sicherheitsmanahmen, die
praktisch fr jedes IT-System zu beachten sind. Es umfasst:
- Standardsicherheitsmanahmen fr typische IT-Systeme mit "normalem" Schutzbedarf,
- eine Darstellung der pauschal angenommenen Gefhrdungslage,
- ausfhrliche Manahmenbeschreibungen als Umsetzungshilfe,
- eine Beschreibung des Prozesses zum Erreichen und Aufrechterhalten eines angemessenen IT-
Sicherheitsniveaus und
- eine einfache Verfahrensweise zur Ermittlung des erreichten IT-Sicherheitsniveaus in Form eines
Soll-Ist-Vergleichs.
Da die Informationstechnik sehr innovativ ist und sich stndig weiterentwickelt, ist das vorliegende
Handbuch auf Aktualisierbarkeit und Erweiterbarkeit angelegt. Das Bundesamt fr Sicherheit in der
Informationstechnik aktualisiert auf der Grundlage von Anwenderbefragungen das Handbuch stndig
und erweitert es um neue Themen.
_________________________________________________________________________________________
Einleitung 2004
_________________________________________________________________________________________
Dabei ist die Resonanz sehr positiv. Im Anhang des Handbuchs findet sich ein Auszug aus der Liste
derjenigen Institutionen, die das IT-Grundschutzhandbuch einsetzen. Sie stellt im berblick dar, in
welchen Branchen und in welchen Firmen bzw. Behrden IT-Grundschutz angewendet wird.
Da das Handbuch auch international groen Anklang findet, wird es zustzlich in einer englisch-
sprachigen Version digital zur Verfgung gestellt.
_________________________________________________________________________________________
Wegweiser durch das IT-Grundschutzhandbuch 1
_________________________________________________________________________________________
1 Wegweiser durch das IT-Grundschutzhandbuch
1.1 IT-Grundschutz: Ziel, Idee und Konzeption

1.2 Aufbau und Lesart des Handbuchs
1.3 Anwendungsweisen des IT-Grundschutzhandbuchs
1.4 Kurzdarstellung vorhandener Bausteine
1.5 Hilfsmittel
1.6 Informationsfluss und Kontakte
_________________________________________________________________________________________
IT-Grundschutz: Ziel, Idee und Konzeption 1.1
_________________________________________________________________________________________
1. Wegweiser durch das IT-

Grundschutzhandbuch
1.1 IT-Grundschutz: Ziel, Idee und Konzeption

Im IT-Grundschutzhandbuch werden Standardsicherheitsmanahmen fr typische IT-Systeme
empfohlen. Das Ziel dieser IT-Grundschutz-Empfehlungen ist es, durch geeignete Anwendung von
organisatorischen, personellen, infrastrukturellen und technischen Standard-Sicherheitsmanahmen
ein Sicherheitsniveau fr IT-Systeme zu erreichen, das fr den normalen Schutzbedarf angemessen
und ausreichend ist und als Basis fr hochschutzbedrftige IT-Systeme und -Anwendungen dienen
kann.
Um den sehr heterogenen Bereich der IT einschlielich der Einsatzumgebung besser strukturieren und
aufbereiten zu knnen, verfolgt das IT-Grundschutzhandbuch das Baukastenprinzip. Die einzelnen
Bausteine spiegeln typische Bereiche des IT-Einsatzes wider, wie beispielsweise Client-Server-Netze,
bauliche Einrichtungen, Kommunikations- und Applikationskomponenten. In jedem Baustein wird
zunchst die zu erwartende Gefhrdungslage beschrieben, wobei sowohl die typischen Gefhrdungen
als auch die pauschalisierten Eintrittswahrscheinlichkeiten bercksichtigt werden. Diese Gefhr-
dungslage bildet die Grundlage, um ein spezifisches Manahmenbndel aus den Bereichen Infrastruk-
tur, Personal, Organisation, Hard- und Software, Kommunikation und Notfallvorsorge zu generieren.
Die Gefhrdungslage wird zur Sensibilisierung angefhrt, fr die Erstellung eines Sicherheitskon-
zeptes nach IT-Grundschutz wird sie nicht weiter bentigt. Um das fr einen durchschnittlichen
Schutzbedarf notwendige Sicherheitsniveau zu erreichen, brauchen die Anwender die vorgenannten
aufwendigen Analysen nicht durchzufhren. Es ist vielmehr ausreichend, die fr das relevante IT-
System oder den betrachteten IT-Verbund entsprechenden Bausteine zu identifizieren und die darin
empfohlenen Manahmen konsequent und vollstndig umzusetzen.
Mit Hilfe des IT-Grundschutzhandbuchs lassen sich IT-Sicherheitskonzepte einfach und arbeits-
konomisch realisieren. Bei der traditionellen Risikoanalyse werden zunchst die Gefhrdungen
ermittelt und mit Eintrittswahrscheinlichkeiten bewertet, um dann die geeigneten IT-Sicherheits-
manahmen auszuwhlen und anschlieend noch das verbleibende Restrisiko bewerten zu knnen. Bei
Anwendung des IT-Grundschutzhandbuchs wird hingegen nur ein Soll-Ist-Vergleich zwischen
empfohlenen und bereits realisierten Manahmen durchgefhrt. Dabei festgestellte fehlende und noch
nicht umgesetzte Manahmen zeigen die Sicherheitsdefizite auf, die es durch die empfohlenen
Manahmen zu beheben gilt. Erst bei einem signifikant hheren Schutzbedarf muss zustzlich eine
ergnzende Sicherheitsanalyse unter Beachtung von Kosten- und Wirksamkeitsaspekten durchgefhrt
werden. Hierbei reicht es dann aber in der Regel aus, die Manahmenempfehlungen des IT-Grund-
schutzhandbuchs durch entsprechende individuelle, qualitativ hherwertige Manahmen, zu ergnzen.
_________________________________________________________________________________________
IT-Grundschutz: Ziel, Idee und Konzeption 1.1
_________________________________________________________________________________________
Bei den im IT-Grundschutzhandbuch aufgefhrten Manahmen handelt es sich um Standardsicher-

heitsmanahmen, also um diejenigen Manahmen, die fr die jeweiligen Bausteine nach dem Stand
der Technik umzusetzen sind, um eine angemessene Sicherheit zu erreichen. Teilweise wird mit diesen
Manahmen auch bereits ein hherer Schutzbedarf abgedeckt, trotzdem sind sie in den jeweiligen
Bereichen das Minimum dessen, was vernnftigerweise an Sicherheitsvorkehrungen umzusetzen ist.
Sicherheitskonzepte, die mittels des IT-Grundschutzhandbuchs erstellt werden, sind kompakt, da
innerhalb des Konzepts jeweils nur auf die entsprechenden Manahmen im Handbuch referenziert
werden muss. Dies frdert die Verstndlichkeit und die bersichtlichkeit. Um die Umsetzung der
Manahmenempfehlungen zu erleichtern, werden die Manahmenbeschreibungen im Handbuch so
detailliert gestaltet, das sie als konkrete Umsetzungshinweise dienen knnen. Bei der verwendeten
Fachterminologie wird darauf geachtet, dass die Manahmenbeschreibungen fr diejenigen verstnd-
lich sind, die die Manahmen realisieren mssen. Demzufolge unterscheiden sich Manahmen, die ein
versierter Administrator umsetzen soll, in Ausdrucksweise und Terminologie von denen, die ein
Anwender umsetzen soll.
Um die Realisierung der Manahmen zu vereinfachen, werden die Texte des Handbuchs konsequent
auch in elektronischer Form zur Verfgung gestellt. Darber hinaus wird die Realisierung der
Manahmen auch durch Hilfsmittel und Musterlsungen untersttzt, die teilweise durch das BSI und
teilweise auch von Anwendern des Handbuchs bereitgestellt werden.
Angesichts der Innovationsschbe und Versionswechsel im IT-Bereich ist das IT-Grundschutzhand-
buch auf leichte Erweiterbarkeit und Aktualisierbarkeit ausgerichtet. Daher ist es durch Bausteine und
Kataloge modular aufgebaut und als Lose-Blatt-Sammlung erweiterungsfhig. Das BSI berarbeitet
und aktualisiert regelmig die bestehenden Bausteine, um die Empfehlungen auf dem Stand der
Technik zu halten. Darber hinaus wird das bestehende Werk regelmig um weitere Bausteine
erweitert. Mageblich fr diese Fortschreibung des IT-Grundschutzhandbuchs sind die Wnsche der
Anwender, die regelmig mittels einer Befragung ermittelt werden. Nur so ist eine bedarfsgerechte
Weiterentwicklung dieses Werkes auf Dauer gewhrleistet. Das BSI bietet daher allen Anwendern die
Mglichkeit der freiwilligen, selbstverstndlich kostenfreien Registrierung an. Registrierte Anwender
erhalten regelmig Informationen ber aktuelle Themen. Die Registrierung ist auerdem die Grund-
lage fr die Anwenderbefragung. Nur durch den stndigen Erfahrungsaustausch mit den Benutzern des
Handbuchs ist eine bedarfsgerechte Weiterentwicklung mglich. Diese Bemhungen zielen letztlich
darauf, aktuelle Empfehlungen zu aktuellen typischen IT-Sicherheitsproblemen aufzeigen zu knnen.
Manahmenempfehlungen, die nicht stndig aktualisiert und erweitert werden, veralten sehr schnell
oder mssen so generisch gehalten werden, dass sie ihren eigentlichen Nutzen, Sicherheitslcken zu
identifizieren und die konkrete Umsetzung zu vereinfachen, nicht verfehlen.
_________________________________________________________________________________________
Aufbau und Lesart des Handbuchs 1.2
_________________________________________________________________________________________
1.2 Aufbau und Lesart des Handbuchs

Das IT-Grundschutzhandbuch lsst sich in fnf Bereiche untergliedern, die zum Verstndnis des
Handbuchs hier kurz erlutert werden sollen:
Einstieg und Vorgehensweise
Dieser erste Teil umfasst die Kapitel 1 und 2. In ihnen wird die Konzeption IT-Grundschutz
dargestellt, ein Wegweiser zur Nutzung des Handbuchs erlutert, der Quereinstieg ins Handbuch zu
ausgewhlten Themen ermglicht und die Vorgehensweise zur Erstellung eines Sicherheitskonzepts
nach IT-Grundschutz vorgestellt. Wesentlich fr das Verstndnis dieses Handbuchs ist das
Durcharbeiten von Kapitel 2. Hier wird detailliert beschrieben, welche Schritte notwendig sind, um ein
IT-Sicherheitsniveau im Sinne des IT-Grundschutzes zu erreichen. Insbesondere wird dargestellt, wie
eine vorhandene IT-Landschaft mit den in diesem Handbuch enthaltenen Bausteinen abgebildet und
wie der Soll-Ist-Vergleich nach IT-Grundschutz durchgefhrt und dokumentiert werden kann.
Bausteine
Der zweite Teil umfasst die Kapitel 3 bis 9. Sie enthalten die Gefhrdungslage und die Manahmen-
empfehlungen fr verschiedene Komponenten, Vorgehensweisen und IT-Systeme, die jeweils in
einem Baustein zusammengefasst werden. Diese sind logisch gruppiert in die folgenden Kapitel:
Kapitel 3: IT-Grundschutz bergeordneter Komponenten
Kapitel 4: Infrastruktur
Kapitel 5: Nicht vernetzte Systeme
Kapitel 6: Vernetzte Systeme
Kapitel 7: Datenbertragungseinrichtungen
Kapitel 8: Telekommunikation
Kapitel 9: Sonstige IT-Komponenten
Gefhrdungskataloge
Dieser Bereich enthlt die ausfhrlichen Beschreibungen der Gefhrdungen, die in den einzelnen
Bausteinen als Gefhrdungslage genannt wurden. Die Gefhrdungen sind in fnf Kataloge gruppiert:
G1: Hhere Gewalt
G2: Organisatorische Mngel
G3: Menschliche Fehlhandlungen
G4: Technisches Versagen
G5: Vorstzliche Handlungen
Manahmenkataloge
Dieser Teil beschreibt die in den Bausteinen des Handbuchs zitierten IT-Sicherheitsmanahmen
ausfhrlich. Die Manahmen sind in sechs Manahmenkataloge gruppiert:
M 1: Manahmenkatalog Infrastruktur
M 2: Manahmenkatalog Organisation
M 3: Manahmenkatalog Personal
M 4: Manahmenkatalog Hardware/Software
M 5: Manahmenkatalog Kommunikation
M 6: Manahmenkatalog Notfallvorsorge
Anhang
Im letzten Teil des Handbuchs befinden sich ergnzende Hilfsmittel, Vordrucke, Kurzdarstellungen zu
Tools rund um den IT-Grundschutz und eine Liste registrierter Anwender des Handbuchs.
_________________________________________________________________________________________
_________________________________________________________________________________________
Lesart des Handbuchs

Die zentrale Rolle des IT-Grundschutzhandbuchs bilden die Bausteine, deren Aufbau im Prinzip
gleich ist. Zunchst enthlt jeder Baustein eine kurze Beschreibung der betrachteten Komponente, der
Vorgehensweise bzw. des IT-Systems.
Im Anschluss erfolgt eine Darstellung der Gefhrdungslage. Die Gefhrdungen sind dabei nach den
genannten Bereichen Hhere Gewalt, Organisatorische Mngel, Menschliche Fehlhandlungen, Tech-
nisches Versagen und Vorstzliche Handlungen unterteilt.
Um die Bausteine bersichtlich zu gestalten und um Redundanzen zu vermeiden, erfolgt lediglich eine
Referenzierung auf die Gefhrdungstexte. Hier ein Beispiel fr das Zitat einer Gefhrdung innerhalb
eines Bausteins:
- G 4.1 Ausfall der Stromversorgung
Im Krzel G x.y steht der Buchstabe "G" fr Gefhrdung. Die Zahl x vor dem Punkt bezeichnet den
Gefhrdungskatalog (hier G 4 = Technisches Versagen) und die Zahl y nach dem Punkt bezeichnet die
laufende Nummer der Gefhrdung innerhalb des jeweiligen Katalogs. Es folgt der Titel der
Gefhrdung. Ein Einlesen in die Gefhrdungen ist aus Grnden der Sensibilisierung und des
Verstndnisses der Manahmen empfehlenswert, aber fr die Erstellung eines IT-Sicherheitskonzepts
nach dem IT-Grundschutzhandbuch nicht unbedingt zwingend erforderlich.
Den wesentlichen Teil eines jeden Bausteins bilden die Manahmenempfehlungen, die sich an die
Gefhrdungslage anschlieen. Zunchst erfolgen kurze Hinweise zum jeweiligen Manahmenbndel.
So enthalten diese Ausfhrungen in einigen Bausteinen z. B. Hinweise zur folgerichtigen Reihenfolge
bei der Realisierung der notwendigen Manahmen.
Analog zu den Gefhrdungen sind die Manahmen in die Manahmenkataloge Infrastruktur, Organi-
sation, Personal, Hardware / Software, Kommunikation und Notfallvorsorge gruppiert. Wie bei den
Gefhrdungen wird hier ebenfalls nur auf die entsprechende Manahme referenziert. Hier ein Beispiel
fr das Zitat einer empfohlenen Manahme innerhalb eines Bausteins:
- M 1.15 (1) Geschlossene Fenster und Tren
Im Krzel M x.y bezeichnet "M" eine Manahme, die Zahl x vor dem Punkt den Manahmenkatalog
(hier M 1 = Infrastruktur). Die Zahl y nach dem Punkt ist die laufende Nummer der Manahme inner-
halb des jeweiligen Katalogs.
Mit der Zahl in Klammern - hier (1) - wird jeder Manahme eine Prioritt zugewiesen. Diese ist bei
der Erstellung eines Realisierungsplans fr bisher nicht oder nicht vollstndig umgesetzte Manahmen
von groer Bedeutung. In der Praxis treten gerade in dieser Phase hufig finanzielle, zeitliche oder
auch personelle Engpsse auf. Wird hierdurch die anzustrebende vollstndige Umsetzung aller
notwendigen Manahmen verzgert, so gibt die in den Bausteinen ausgewiesene Prioritt einer
Manahme einen Anhaltspunkt fr die anzustrebende Reihenfolge bei der Umsetzung fehlender
Manahmen. Folgende Priorittsstufen wurden vergeben:
"1": Diese Manahmen sind die Grundlage fr die Sicherheit innerhalb des
betrachteten Bausteins. Sie sind vorrangig umzusetzen.
"2": Diese Manahmen sind wichtig. Eine zgige Realisierung ist anzustreben.
"3": Diese Manahmen sind wichtig fr die Abrundung der IT-Sicherheit. Bei
Engpssen knnen sie zeitlich nachrangig umgesetzt werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
Einige Manahmen werden mit dem Hinweis optional gekennzeichnet. Beispiel:

- M 2.18 (3) Kontrollgnge (optional)
Manahmen knnen aus verschiedenen Grnden als optional gekennzeichnet worden sein, etwa weil
sie kostentrchtig sind, weil sie auf einen hheren Schutzbedarf ausgerichtet sind oder weil sie andere
Manahmen ersetzen. Da solche Manahmen nicht pauschal als angemessen fr den IT-Grundschutz
angesehen werden knnen, ist bei diesen immer zu entscheiden und zu begrnden, ob diese ange-
messen und wirtschaftlich sind. Bei einem hheren Schutzbedarf ist die Umsetzung zumeist angeraten.
Um ein IT-Sicherheitskonzept nach dem IT-Grundschutzhandbuch erstellen und den dabei notwen-
digen Soll-Ist-Vergleich durchfhren zu knnen, ist es erforderlich, die Texte zu den jeweils in den
identifizierten Bausteinen enthaltenen Manahmen im jeweiligen Manahmenkatalog sorgfltig zu
lesen. Als Beispiel sei hier ein Auszug aus einer Manahme zitiert:
M 2.11 Regelung des Passwortgebrauchs

Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, IT-Benutzer
[Manahmentext ...]
Ergnzende Kontrollfragen:
- Sind die Benutzer ber den korrekten Umgang mit Passwrtern unterrichtet worden?
[...]
Neben der eigentlichen Empfehlung, wie die einzelnen Manahmen umzusetzen sind, werden Ver-
antwortliche beispielhaft genannt. Verantwortlich fr die Initiierung bezeichnet die Personen oder
Rollen, die die Umsetzung einer Manahme typischerweise veranlassen sollten. Verantwortlich fr die
Umsetzung bezeichnet die Personen oder Rollen, die die Realisierung der Manahme durchfhren
sollten.
Weiterhin werden ergnzende Kontrollfragen angefhrt, die das behandelte Thema abrunden und
nochmals einen kritischen Blick auf die Umsetzung der Manahmen bewirken sollen. Diese ergn-
zenden Kontrollfragen erheben dabei jedoch keinen Anspruch auf Vollstndigkeit.
Der Zusammenhang zwischen den fr den IT-Grundschutz angenommenen Gefhrdungen und den
empfohlenen Manahmen kann den Manahmen-Gefhrdungstabellen entnommen werden. Diese
werden nicht abgedruckt, sondern befinden sich auf der CD-ROM zum IT-Grundschutzhandbuch
(siehe Anhang: Hilfsmittel). Fr jeden Baustein gibt es eine Manahmen-Gefhrdungstabelle.
_________________________________________________________________________________________
_________________________________________________________________________________________
Als Beispiel sei ein Auszug aus der Manahmen-Gefhrdungstabelle fr den Baustein Datentrger-
austausch angefhrt:
G G G G G G G G
1. 1. 1. 2. 2. 2. 2. 2.
Prioritt 7 8 9 3 1 1 1 1
0 7 8 9
M 1.36 2* X X
M 2.42 2 X
M 2.43 1 X X X
M 2.44 1 X X X
Alle Tabellen haben einen einheitlichen Aufbau. In der Kopfzeile sind die im dazugehrigen Baustein
aufgelisteten Gefhrdungen mit ihren Nummern eingetragen. In der ersten Spalte finden sich entspre-
chend die Nummern der Manahmen wieder. In der zweiten Spalte ist eingetragen, welche Prioritt
die einzelne Manahme fr den betrachteten Baustein besitzt. Folgt dieser Zahl ein "*", ist diese
Manahme im Baustein als "optional" gekennzeichnet.
Die brigen Spalten beschreiben den Zusammenhang zwischen Manahmen und Gefhrdungen. Ist in
einem Feld ein "X" eingetragen, so bedeutet dies, dass die korrespondierende Manahme gegen die
entsprechende Gefhrdung wirksam ist. Diese Wirkung kann schadensvorbeugender oder schadens-
mindernder Natur sein.
Fr den Fall, dass eine empfohlene Manahme nicht umgesetzt werden kann, ist es anhand dieser
Tabellen mglich zu ermitteln, welche Gefhrdungen ggf. nicht mehr ausreichend abgewehrt werden.
Es ist dann abzuwgen, ob eine Ersatzmanahme realisiert werden sollte. Keinesfalls jedoch sollten
diese Tabellen so interpretiert werden, dass eine Manahme, die besonders viele "X"-Eintrge besitzt,
auch eine besonders hohe Bedeutung besitzt. Es gibt Flle, in denen eine Manahme genau gegen eine
Gefhrdung wirkt, aber dennoch unverzichtbar ist.
Abschlieend sei erwhnt, dass smtliche Bausteine, Gefhrdungen, Manahmen, Tabellen und
Hilfsmittel auf der CD-ROM zum IT-Grundschutzhandbuch enthalten sind. Diese Texte knnen bei
der Erstellung eines Sicherheitskonzeptes und bei der Realisierung von Manahmen weiterverwendet
werden.
_________________________________________________________________________________________
Anwendungsweisen des IT-Grundschutzhandbuchs 1.3
_________________________________________________________________________________________
1.3 Anwendungsweisen des IT-Grundschutzhandbuchs

Fr die erfolgreiche Etablierung eines kontinuierlichen und effektiven IT-Sicherheitsprozesses mssen
eine ganze Reihe von Aktionen durchgefhrt werden. Hierfr bietet das IT-Grundschutzhandbuch
Hinweise zur Methodik und praktische Umsetzungshilfen. Enthalten sind ferner Lsungsanstze fr
verschiedene, die IT-Sicherheit betreffende Aufgabenstellungen, beispielsweise IT-Sicherheits-
konzeption, Revision und Qualifizierung. Je nach vorliegender Aufgabenstellung sind dabei unter-
schiedliche Anwendungsweisen des IT-Grundschutzhandbuchs zweckmig. Dieser Abschnitt dient
dazu, durch Querverweise auf die entsprechenden Kapitel des IT-Grundschutzhandbuchs den direkten
Einstieg in die einzelnen Anwendungsweisen zu erleichtern.
IT-Sicherheitsprozess und IT-Sicherheitsmanagement
Die Abhngigkeit vom ordnungsgemen Funktionieren der Informationstechnik hat in den letzten
Jahren sowohl in der ffentlichen Verwaltung als auch in der Privatwirtschaft stark zugenommen.
Immer mehr Geschftsprozesse werden auf die Informationstechnik verlagert oder mit ihr verzahnt.
Ein Ende dieser Entwicklung ist nicht abzusehen. IT-Sicherheit ist daher als integraler Bestandteil der
originren Aufgabe anzusehen. Der folgende Aktionsplan beinhaltet alle wesentlichen Schritte, die fr
einen kontinuierlichen IT-Sicherheitsprozess notwendig sind, und ist somit als eine planmig anzu-
wendende, begrndete Vorgehensweise zu verstehen, wie ein angemessenes IT-Sicherheitsniveau
erreicht und aufrechterhalten werden kann:
- Entwicklung einer IT-Sicherheitspolitik
- Auswahl und Etablierung einer geeigneten Organisationsstruktur fr das IT-Sicherheitsmanage-
ment
- Erstellung eines IT-Sicherheitskonzepts
- Realisierung der IT-Sicherheitsmanahmen
- Schulung und Sensibilisierung
- Aufrechterhaltung der IT-Sicherheit im laufenden Betrieb
In Kapitel 3.0 wird der IT-Sicherheitsprozess im berblick dargestellt und es wird eine detaillierte
Erluterung der einzelnen Aktionen in Form empfohlener Standard-Manahmen gegeben.
IT-Strukturanalyse
Unter einem IT-Verbund ist die Gesamtheit von infrastrukturellen, organisatorischen, personellen und
technischen Komponenten zu verstehen, die der Aufgabenerfllung in einem bestimmten Anwen-
dungsbereich der Informationsverarbeitung dienen. Ein IT-Verbund kann dabei als Ausprgung die
gesamte IT einer Institution oder auch einzelne Bereiche, die durch organisatorische Strukturen (z. B.
Abteilungsnetz) oder gemeinsame IT-Anwendungen (z. B. Personalinformationssystem) gegliedert
sind, umfassen. Fr die Erstellung eines IT-Sicherheitskonzepts und insbesondere fr die Anwendung
des IT-Grundschutzhandbuchs ist es erforderlich, die Struktur der vorliegenden Informationstechnik
zu analysieren und zu dokumentieren. Aufgrund der heute blichen starken Vernetzung von IT-
Systemen bietet sich ein Netztopologieplan als Ausgangsbasis fr die Analyse an. Die folgenden
Aspekte mssen bercksichtigt werden:
- die vorhandene Infrastruktur,
- die organisatorischen und personellen Rahmenbedingungen fr den IT-Verbund,
- im IT-Verbund eingesetzte vernetzte und nicht-vernetzte IT-Systeme,
- die Kommunikationsverbindungen zwischen den IT-Systemen und nach auen,
- im IT-Verbund betriebene IT-Anwendungen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Die einzelnen Schritte der IT-Strukturanalyse werden im Detail in Kapitel 2.1 dieses Handbuchs in
Form einer Handlungsanweisung beschrieben.
Schutzbedarfsfeststellung
Zweck der Schutzbedarfsfeststellung ist es zu ermitteln, welcher Schutz fr die Informationen und die
eingesetzte Informationstechnik ausreichend und angemessen ist. Hierzu werden fr jede Anwendung
und die verarbeiteten Informationen die zu erwartenden Schden betrachtet, die bei einer Beeintrch-
tigung von Vertraulichkeit, Integritt oder Verfgbarkeit entstehen knnen. Wichtig ist dabei auch
eine realistische Einschtzung der mglichen Folgeschden. Bewhrt hat sich eine Einteilung in die
drei Schutzbedarfskategorien "niedrig bis mittel", "hoch" und "sehr hoch". Erluterungen und
praktische Hinweise zur Schutzbedarfsfeststellung sind Gegenstand von Kapitel 2.2.
Sicherheitskonzeption
Die Informationstechnik in Behrden und Unternehmen ist heute blicherweise durch stark vernetzte
IT-Systeme geprgt. In der Regel ist es daher zweckmig, im Rahmen einer IT-Sicherheitsanalyse
bzw. IT-Sicherheitskonzeption die gesamte IT und nicht einzelne IT-Systeme zu betrachten. Um diese
Aufgabe bewltigen zu knnen, ist es sinnvoll, die gesamte IT in logisch getrennte Teile zu zerlegen
und jeweils einen Teil, eben einen IT-Verbund, getrennt zu betrachten. Voraussetzung fr die Anwen-
dung des IT-Grundschutzhandbuchs auf einen IT-Verbund sind detaillierte Unterlagen ber seine
Struktur. Diese knnen beispielsweise ber die oben beschriebene IT-Strukturanalyse gewonnen
werden. Anschlieend mssen die Bausteine des IT-Grundschutzhandbuchs in einem Modellierungs-
schritt auf die Komponenten des vorliegenden IT-Verbunds abgebildet werden.
In Kapitel 2.3 dieses Handbuchs wird beschrieben, wie die Modellierung eines IT-Verbunds durch
Bausteine des Handbuchs vorgenommen werden sollte. Wie die anschlieende IT-Grundschutzer-
hebung anhand eines Basis-Sicherheitschecks durchgefhrt werden sollte, wird in Kapitel 2.4
beschrieben.
Basis-Sicherheitscheck
Der Basis-Sicherheitscheck ist ein Organisationsinstrument, welches einen schnellen berblick ber
das vorhandene IT-Sicherheitsniveau bietet. Mit Hilfe von Interviews wird der Status Quo eines
bestehenden (nach IT-Grundschutz modellierten) IT-Verbunds in Bezug auf den Umsetzungsgrad von
Sicherheitsmanahmen des IT-Grundschutzhandbuchs ermittelt. Als Ergebnis liegt ein Katalog vor, in
dem fr jede relevante Manahme der Umsetzungsstatus "entbehrlich", "ja", "teilweise" oder "nein"
erfasst ist. Durch die Identifizierung von noch nicht oder nur teilweise umgesetzten Manahmen
werden Verbesserungsmglichkeiten fr die Sicherheit der betrachteten Informationstechnik auf-
gezeigt. Kapitel 2.4 beschreibt einen Aktionsplan fr die Durchfhrung eines Basis-Sicherheitschecks.
Dabei wird sowohl den organisatorischen Aspekten als auch den fachlichen Anforderungen bei der
Projektdurchfhrung Rechnung getragen.
IT-Sicherheitsrevision
Die im IT-Grundschutzhandbuch enthaltenen Sicherheitsmanahmen knnen auch fr die IT-Sicher-
heitsrevision genutzt werden. Hierzu sind exemplarisch auf der Grundlage der Bausteine
3.1 Organisation 5.5 PC unter Windows NT
3.2 Personal 5.6 PC mit Windows 95
Checklisten entwickelt worden, die das IT-Sicherheitsmanagement bei der berprfung der in einer
Behrde oder einem Unternehmen umgesetzten IT-Sicherheit untersttzen sollen. Die Checklisten
sind auf der CD-ROM zum IT-Grundschutzhandbuch enthalten (siehe Anhang: Hilfsmittel). Der
derzeitige Stand der Checklisten ist keineswegs endgltig, er bildet lediglich die Grundlage fr
Diskussionen und
_________________________________________________________________________________________
_________________________________________________________________________________________
Erfahrungsaustausch mit den Anwendern des IT-Grundschutzhandbuchs. Kommentare und

Verbesserungsvorschlge knnen per E-Mail an gshb@bsi.de weitergegeben werden.
Ergnzende Sicherheitsanalyse
Die Standardsicherheitsmanahmen nach IT-Grundschutz bieten im Normalfall einen angemessenen
und ausreichenden Schutz. Bei hohem oder sehr hohem Schutzbedarf kann es jedoch sinnvoll sein zu
prfen, ob zustzlich oder ersatzweise hherwertige IT-Sicherheitsmanahmen erforderlich sind. Die
Auswahl geeigneter IT-Sicherheitsmanahmen erfolgt mittels einer ergnzenden Sicherheitsanalyse,
wobei unterschiedliche Methoden angewandt werden knnen, beispielsweise
- Risikoanalyse,
- Penetrationstest und
- Differenz-Sicherheitsanalyse.
In Kapitel 2.5 werden diese Methoden berblicksartig dargestellt. Die erfolgreiche Durchfhrung einer
ergnzenden Sicherheitsanalyse hngt entscheidend von den Fachkenntnissen des Projektteams ab.
Daher kann es sinnvoll sein, fachkundiges externes Personal hinzuzuziehen.
Umsetzung von IT-Sicherheitskonzepten
Ein ausreichendes IT-Sicherheitsniveau lsst sich nur erreichen, wenn in einer Sicherheitsanalyse
bestehende Schwachstellen ermittelt werden, in einem Sicherheitskonzept der Status Quo festgehalten
wird, erforderliche Manahmen identifiziert und wenn insbesondere diese Manahmen auch konse-
quent umgesetzt werden. In Kapitel 2.6 wird beschrieben, was bei der Umsetzungsplanung von IT-
Sicherheitsmanahmen beachtet werden muss.
Qualifizierung nach IT-Grundschutz
Das IT-Grundschutzhandbuch wird heute nicht nur fr die IT-Sicherheitskonzeption, sondern auch
zunehmend als Referenz im Sinne eines Sicherheitsstandards verwendet. Durch eine IT-Grundschutz-
Qualifizierung kann eine Institution nach auen hin dokumentieren, dass sie IT-Grundschutz in der
erforderlichen Tiefe umgesetzt hat. In Kapitel 2.7 wird die Qualifizierung nach IT-Grundschutz
vorgestellt und das diesbezgliche Qualifizierungsschema definiert. Das Niveau der Qualifizierung
wird dabei durch drei verschiedene Klassen unterteilt, die sich sowohl im Hinblick auf die Gte (d. h.
den erforderlichen Umsetzungsgrad der Sicherheitsmanahmen) als auch in Bezug auf die Vertrau-
enswrdigkeit unterscheiden. Das Eingangsniveau kann durch einen Mitarbeiter der Institution selbst
nachgewiesen werden, das hchste Niveau erfordert eine Prfung durch unabhngige Dritte.
_________________________________________________________________________________________
Kurzdarstellung vorhandener Bausteine 1.4
_________________________________________________________________________________________
1.4 Kurzdarstellung vorhandener Bausteine

In der nachfolgenden bersicht werden die im IT-Grundschutzhandbuch vorhandenen Bausteine kurz
skizziert. Sie bietet einen kompakten berblick ber den Umfang der erarbeiteten
Manahmenempfehlungen des IT-Grundschutzhandbuchs.
3.0 IT-Sicherheitsmanagement
Das Kapitel zeigt einen systematischen Weg auf, wie ein funktionierendes IT-Sicherheitsmanagement
eingerichtet und im laufenden Betrieb weiterentwickelt werden kann.
3.1 Organisation
In diesem Baustein werden die fr die IT-Sicherheit grundlegend notwendigen organisatorischen
Regelungen angefhrt. Beispiele sind Festlegung der Verantwortlichkeiten, Datentrgerverwaltung
und Regelungen zum Passwortgebrauch. Sie sind fr jedes IT-System umzusetzen.
3.2 Personal
Der Baustein "Personal" beschreibt die Manahmen im Personalbereich, die zum Erreichen von IT-
Sicherheit zu beachten sind. Beispiele sind Vertretungsregelungen, Schulungsmanahmen und gere-
gelte Verfahrensweise beim Ausscheiden von Mitarbeitern. Sie sind unabhngig von der Art der
eingesetzten IT-Systems zu beachten.
3.3 Notfallvorsorge-Konzept
Hier wird eine Vorgehensweise dargestellt, wie ein Notfallvorsorge-Konzept erstellt werden kann.
Dieser Baustein sollte insbesondere fr grere IT-Systeme bercksichtigt werden.
3.4 Datensicherungskonzept
Dieser Baustein stellt dar, wie ein fundiertes Datensicherungskonzept systematisch erarbeitet werden
kann. Dieser Baustein ist insbesondere fr grere IT-Systeme oder IT-Systeme mit groem Daten-
bestand gedacht.
3.5 Datenschutz
Die Rahmenbedingungen fr einen praxisgerechten Datenschutz und die Verbindung zur IT-Sicherheit
ber den IT-Grundschutz werden in diesem Baustein dargestellt. Das Kapitel Datenschutz wurde
federfhrend vom Bundesbeauftragten fr den Datenschutz (BfD) gemeinsam mit dem Arbeitskreis
Technik der Datenschutzbeauftragten des Bundes und der Lnder erstellt und kann beim BfD abge-
rufen werden.
3.6 Computer-Virenschutzkonzept
Ziel eines Computer-Virenschutzkonzeptes ist es, ein geeignetes Manahmenbndel zusammen-
zustellen, bei dessen Einsatz das Auftreten von Computer-Viren auf den in einer Organisation einge-
setzten IT-Systemen verhindert bzw. mglichst frh erkannt wird, um Gegenmanahmen vornehmen
zu knnen und mgliche Schden zu minimieren.
3.7 Kryptokonzept
Dieser Baustein beschreibt eine Vorgehensweise, wie in einer heterogenen Umgebung sowohl die
lokal gespeicherten Daten als auch die zu bertragenen Daten wirkungsvoll durch kryptographische
Verfahren und Techniken geschtzt werden knnen.
_________________________________________________________________________________________
_________________________________________________________________________________________
3.8 Behandlung von Sicherheitsvorfllen

Um die IT-Sicherheit im laufenden Betrieb aufrecht zu erhalten, ist es notwendig, die Behandlung von
Sicherheitsvorfllen (Incident Handling) konzipiert und eingebt zu haben. Als Sicherheitsvorfall wird
dabei ein Ereignis bezeichnet, das Auswirkungen nach sich ziehen kann, die einen groen Schaden
anrichten knnen. Um Schden zu verhten bzw. zu begrenzen, sollte die Behandlung der
Sicherheitsvorflle zgig und effizient ablaufen.
3.9 Hard- und Software-Management
Ziel des Bausteins "Hard- und Software-Management" ist es, einen ordnungsgemen IT-Betrieb im
Hinblick auf Management bzw. Organisation sicherzustellen. Hierzu enthlt der Baustein schwer-
punktmig Empfehlungen zu Regelungen und Ablufen, die sich spezifisch auf informations-
technische Hardware- oder Software-Komponenten beziehen.
3.10 Outsourcing
Der Baustein Outsourcing beschreibt IT-Sicherheitsmanahmen, die zu beachten sind, wenn Arbeits-
oder Geschftsprozesse einer Organisation ganz oder teilweise zu externen Dienstleistern ausgelagert
werden. Outsourcing kann sowohl Nutzung und Betrieb von Hardware und Software, aber auch
Dienstleistungen betreffen.
4.1 Gebude
Hier werden die Manahmen genannt, die in jedem Gebude, in dem Datenverarbeitung stattfindet, zu
beachten sind. Es sind Manahmen zur Stromversorgung, zum Brand- und Gebudeschutz sowie
organisatorische Manahmen wie die Schlsselverwaltung.
4.2 Verkabelung
Im Baustein "Verkabelung" werden Manahmen empfohlen, die fr die Verkabelung eines Gebudes
mit Versorgungs- und Kommunikationsleitungen relevant sind. Beispiele sind Brandabschottung von
Trassen, Auswahl geeigneter Kabeltypen und Dokumentation der Verkabelung.
4.3.1 Broraum
Im Kapitel "Broraum" sind alle Manahmen zusammengefasst, die im Zusammenhang mit dem IT-
Einsatz in einem Bro zu beachten sind. Beispiele sind: Geschlossene Fenster und Tren und die
Beaufsichtigung von Fremdpersonen.
4.3.2 Serverraum
Hier werden die Manahmen genannt, die bei Nutzung eines Raumes, in dem ein Server (fr IT-
Systeme oder TK-Anlagen) aufgestellt ist, beachtet werden mssen. Beispiele sind: Vermeidung von
Wasserleitungen, Klimatisierung, lokale unterbrechungsfreie Stromversorgung und Rauchverbot.
4.3.3 Datentrgerarchiv
Wird ein Raum als Datentrgerarchiv genutzt, so sind bestimmte Randbedingungen fr die IT-Sicher-
heit einzuhalten. Diese werden als Manahmen fr den IT-Grundschutz formuliert. Beispiele sind:
Handfeuerlscher, Verwendung von Sicherheitstren und Rauchverbot.
4.3.4 Raum fr technische Infrastruktur
Auch fr Rume, in denen technische Infrastruktur installiert wird, wie im Eingangsraum fr externe
Kommunikationsleitungen, Verteilerraum, Niederspannungsverteilerraum, mssen im Sinne der IT-
Sicherheit bestimmte Manahmen ergriffen werden, die in diesem Kapitel genannt werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
4.4 Schutzschrnke
Fr die sichere Aufbewahrung von Datentrgern oder Hardware knnen Schutzschrnke die Schutz-
wirkung von Rumen (Serverraum, Datentrgerarchiv) zustzlich erhhen. Ggf. kann ein spezieller
Serverschrank auch als Alternative zu einem Serverraum eingesetzt werden. Die fr die Beschaffung,
die Aufstellung und die Nutzung eines Schutzschrankes erforderlichen Manahmen werden in diesem
Baustein beschrieben.
In diesem Baustein werden die Manahmen beschrieben, die erforderlich sind, um einen huslichen
Arbeitsplatz mit einem adquaten Sicherheitsstandard einzurichten, so dass dieser fr dienstliche
Aufgaben genutzt werden kann.
4.6 Rechenzentrum
Als Rechenzentrum werden die fr den Betrieb einer greren, zentral fr mehrere Stellen
eingesetzten Datenverarbeitungsanlage erforderlichen Einrichtungen und Rumlichkeiten bezeichnet.
Der Baustein enthlt Manahmenempfehlungen fr ein Rechenzentrum mittlere Art und Gte, d. h. die
Sicherheitsanforderungen liegen zwischen denen eines Serverraums und denen von Hoch-
sicherheitsrechenzentren.
5.1 DOS-PC (ein Benutzer)
In diesem Baustein werden die Manahmen genannt, die beim Einsatz eines handelsblichen PCs
beachtet werden mssen, der standardmig nur von einem Benutzer betrieben wird. Beispiele sind:
Passwortschutz, Einsatz eines Viren-Suchprogramms, regelmige Datensicherung.
5.2 Unix-System
Betrachtet wird ein IT-System unter dem Betriebssystem Unix oder Linux, das entweder ohne
Verbindung zu anderen Rechnern oder als Client in einem Netz betrieben wird. Terminals oder PCs,
die als Terminal betrieben werden, knnen angeschlossen sein. Hierzu werden sowohl
organisatorische wie auch Unix-spezifische Manahmen genannt.
5.3 Tragbarer PC
Ein tragbarer PC (Laptop) erfordert gegenber dem normalen PC zustzliche IT-Sicherheitsmanah-
men, da er aufgrund der mobilen Nutzung anderen Gefhrdungen ausgesetzt ist. Beispiele fr zustz-
liche Manahmen sind: geeignete Aufbewahrung im mobilen Einsatz und der Einsatz eines
Verschlsselungsproduktes.
5.4 PCs mit wechselnden Benutzern
In diesem Baustein werden die Manahmen genannt, die beim Einsatz eines handelsblichen PCs
beachtet werden mssen, der standardmig von mehreren Benutzern betrieben wird. Beispiele sind:
PC-Sicherheitsprodukt, Passwortschutz, Einsatz eines Viren-Suchprogramms, regelmige Daten-
sicherung.
5.5 PC unter Windows NT
In diesem Baustein werden Manahmen genannt, die fr nicht vernetzte PCs mit dem Betriebssystem
Windows NT (Version 3.51 oder 4.0) erforderlich sind. Auf sicherheitsspezifische Aspekte einzelner
Windows NT-Anwendungen wird nur am Rande eingegangen.
_________________________________________________________________________________________
_________________________________________________________________________________________
5.6 PC mit Windows 95

Nicht vernetzte PCs mit dem Betriebssystem Windows 95 knnen als Stand-alone-Systeme bzw. als
Clients in einem Netz fr einen oder fr mehrere Benutzer eingerichtet werden. Fr beide Betriebs-
varianten werden die erforderlichen Manahmen in diesem Baustein genannt.
5.7 Windows 2000 Client
Betrachtet werden Stand-alone-PCs oder als Client in einem Netz betriebene PCs, die unter dem
Betriebssystem Windows 2000 Professional ablaufen. Der Baustein verweist auf die hierfr relevanten
Gefhrdungen und die erforderlichen Standard-Sicherheitsmanahmen.
5.8 Internet-PC
Ein Internet-PC ist ein Computer, der ber eine Internet-Anbindung verfgt, jedoch nicht mit dem
internen Netz der Institution verbunden ist. Hierdurch sollen zustzliche Bedrohungen fr das lokale
Netz vermieden werden. Dieser Baustein verweist auf die fr einen Internet-PC auf der Basis eines
Windows-Betriebssystems oder Linux erforderlichen Standard-Sicherheitsmanahmen.
Fr die noch nicht im IT-Grundschutzhandbuch betrachteten IT-Systeme wie z. B. OS/2 kann der
generische Baustein 5.99 angewendet werden.
6.1 Servergesttztes Netz
In diesem Baustein werden die notwendigen Manahmen erlutert, die beim Betrieb eines server-
gesttzten Netzes beachtet werden mssen. Diese Betrachtungen sind unabhngig von den Server- und
Client-Betriebssystemen. Die bezglich der Betriebssysteme zu ergreifenden Manahmen befinden
sich in den spezifischen Bausteinen der Kapitel 5 und 6.
6.2 Unix-Server
Es werden IT-Systeme betrachtet, die als Server in einem Netz Dienste anbieten und unter dem
Betriebssystem Unix oder Linux betrieben werden. Fr diese IT-Umgebung werden Manahmen
genannt, die IT-Sicherheit ermglichen. Diese Manahmen sind Unix-spezifisch und mssen durch
Kapitel 6.1 ergnzt werden.
6.3 Peer-to-Peer-Dienste
Beschrieben wird, wie ein Peer-to-Peer-Dienst fr den IT-Grundschutz ausreichend sicher betrieben
werden kann. Themen sind die Konzeption eines solchen Netzes unter Sicherheitsgesichtspunkten,
Administrationsmglichkeiten und funktionelle Einschrnkungen. Grundlagen bilden die Betriebs-
systeme Windows fr Workgroups 3.11, Windows 95 und Windows NT.
6.4 Windows NT Netz
In diesem Baustein wird die Konzeption und der Betrieb eines sicheren Windows NT Netzes
beschrieben. Hierbei handelt es sich berwiegend um Windows NT-spezifische Manahmen, die um
die allgemeinen Manahmen aus Kapitel 6.1 ergnzt werden mssen.
6.5 Novell Netware 3.x
Gegenstand dieses Kapitels ist ein Novell 3.x Netz in einer Client-Server-Funktionalitt. Damit ist
dieses Kapitel die betriebssystemspezifische Ergnzung des Kapitels 6.1 "Servergesttztes Netz".
Behandelt werden die Installation, die Einrichtung, der Betrieb und die Revision von Novell Netware
Servern.
_________________________________________________________________________________________
_________________________________________________________________________________________
6.6 Novell Netware Version 4.x

Gegenstand dieses Kapitels ist ein Novell 4.x Netz in einer Client-Server-Funktionalitt. Damit ist
dieses Kapitel die betriebssystemspezifische Ergnzung des Kapitels 6.1 "Servergesttztes Netz". Die
erforderlichen Manahmen fr die Bereiche Installation, Einrichtung und Betrieb eines Novell 4.x
Netzes werden beschrieben. Hierbei wird insbesondere auch auf den Verzeichnisdienst NDS (Novell
Directory Services) eingegangen.
6.7 Heterogene Netze
Mit Hilfe des Bausteins wird die Analyse und Weiterentwicklung eines bestehenden bzw. die Planung
eines neuen heterogenen Netzes ermglicht. Fr einen sicheren Betrieb des heterogenen Netzes wird
u. a. aufgezeigt, wie eine geeignete Segmentierung des Netzes vorgenommen wird, wie ein Netz-
management-System geplant und umgesetzt wird und wie ein Audit und die Revision des Netzes
erfolgen kann. Daneben werden Aspekte wie die redundante Auslegung von Netzkomponenten und
Sicherung von Konfigurationsdaten im Rahmen der Notfallplanung behandelt.
6.8 Netz- und Systemmanagement
Mittels eines Managementsystems kann eine zentrale Verwaltung aller in einem lokalen Netz ange-
siedelten Hard- und Softwarekomponenten durchgefhrt werden. Fr den erfolgreichen Aufbau eines
Netz- und Systemmanagementsystems werden in diesem Baustein die erforderlichen Schritte
beschrieben, beginnend mit der Konzeption ber die Beschaffung bis hin zum Betrieb.
6.9 Windows 2000 Server
Windows 2000 ist das Nachfolgeprodukt zum Betriebssystem Windows NT. Der vorliegende Baustein
beschreibt die aus Sicherheitssicht relevanten Gefhrdungen und Manahmen, die fr einen Server mit
Windows 2000 zutreffen. Dabei wird insbesondere die Sicherheit des Active Directory und des
Kerberos-Verfahrens behandelt.
6.10 S/390- und zSeries-Mainframe
Der Baustein beschreibt Standard-Sicherheitsmanahmen fr den Einsatz von Grorechnern des Typs
IBM S/390 und zSeries. Diese Manahmen ergnzen die generischen Empfehlungen des Bausteins 6.1
um plattformspezifische Aspekte. Es wird davon ausgegangen, dass Grorechner in einem
Rechenzentrum betrieben werden.
7.1 Datentrgeraustausch
Beschrieben werden die Manahmen, die bei einem Datentrgeraustausch beachtet werden sollten.
Technische Manahmen wie Verschlsselung werden ebenso betrachtet wie die richtige Auswahl der
Versandart. Die Manahmen zielen insbesondere auf den Fall, dass der Datentrgeraustausch regel-
mig stattfindet.
7.2 Modem
Dargestellt werden in diesem Baustein Manahmen, die im Zusammenhang mit dem Einsatz eines
Modems zu beachten sind. Dies sind insbesondere Callback-Mechanismen und Verschlsselung. Auch
Hinweise zur Absicherung der Fernwartung ber Modem werden gegeben.
7.3 Sicherheitsgateway (Firewall)
Die Vernetzung vorhandener Teilnetze mit globalen Netzen wie dem Internet erfordert einen effekti-
ven Schutz des eigenen Netzes. Hierfr werden Sicherheitsgateways (oft auch Firewalls genannt)
eingesetzt. Um einen wirksamen Schutz zu gewhrleisten, bedarf es der Formulierung von
Sicherheitszielen, die schlielich durch eine korrekte Installation und Administration der soft- und
hardwaretechnischen Komponenten eines Sicherheitsgateways umgesetzt werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
7.4 E-Mail
Fr eine sichere E-Mail-Kommunikation werden hier die erforderlichen Manahmen sowohl auf
Seiten des Mailservers als auch auf Seiten des Mailclients aufgefhrt. Auerdem werden die von den
Benutzern einzuhaltenden Sicherheitsbestimmungen vorgestellt.
7.5 Webserver
Ein WWW-Server ist ein IT-System, das ber eine Informationsdatenbank WWW-Clients Dateien zur
Verfgung stellt. Ein WWW-Client, auch Browser genannt, zeigt die Informationen eines WWW-
Servers auf dem Benutzerrechner an. Die Sicherheit der WWW-Nutzung beruht auf der Sicherheit des
WWW-Servers, des WWW-Clients und der Kommunikationsverbindung zwischen beiden. Die fr
eine sichere WWW-Nutzung erforderlichen Manahmen werden im Baustein WWW-Server
beschrieben.
7.6 Remote Access
Um einem Benutzer entfernte Zugriffe (Remote Access) mit seinem lokalen Rechner auf ein entferntes
Rechnernetz zu ermglichen, mssen hierfr entsprechende Dienste (RAS, Remote Access Service)
eingerichtet werden. Wie die einzelnen RAS-Systemkomponenten abgesichert werden knnen und wie
hierzu ein entsprechendes RAS-Sicherheitskonzept erstellt werden kann, wird in diesem Baustein
vorgestellt.
7.7 Lotus Notes
Lotus Notes ist ein Produkt im Bereich der Workgroup-Untersttzung. Hierzu stellt es Funktionen zur
Kommunikation, Datenbertragung und Datenhaltung zur Verfgung. Der Baustein enthlt
Manahmen zur sicheren Planung, Installation, Konfiguration und zum sicheren Betrieb der Client-
und Server-seitigen Komponenten von Lotus Notes.
7.8 Internet Information Server
Der Microsoft Internet Information Server (IIS) wird standardmig mit den Serverversionen von
Windows NT 4.0 (IIS 4), Windows 2000 (IIS 5), mit Windows XP Professional (IIS 5.1) und
Windows Server 2003 (IIS 6) ausgeliefert. Er stellt die Informationsdienste WWW, FTP, NNTP und
SMTP auf der Windows-Plattform zur Verfgung. Der Baustein beschreibt Sicherheitsmanahmen fr
die IIS-Versionen 4 und 5 und ergnzt somit den Baustein 7.5 um produktspezifische Aspekte.
7.9 Apache-Webserver
Der Apache Webserver ist die am hufigsten im Internet eingesetzte Webserver-Software. Sie kann
sowohl auf Unix- als auch auf Windows-Systemen betrieben werden. Der Baustein beschreibt
Sicherheitsmanahmen fr den Apache Webserver und ergnzt somit den Baustein 7.5 um
produktspezifische Aspekte. Der Schwerpunkt liegt auf der Versionsreihe 2.0.x, die meisten
Empfehlungen knnen jedoch problemlos auf die Versionen 1.3.x bertragen werden.
7.10 Exchange 2000 / Outlook 2000
Microsoft Exchange 2000 ist ein Managementsystem unter anderem fr E-Mails, Newsgroups,
Kalender und Aufgabenlisten. In Unternehmen und Behrden wird es hufig gemeinsam mit dem
Client-Produkt Outlook 2000 eingesetzt, das Teil des Microsoft Office 2000 Pakets ist. Der Baustein
beschreibt Standard-Sicherheitsmanahmen fr Exchange 2000 und Outlook 2000 und ergnzt somit
Baustein 7.4 um produktspezifische Aspekte.
_________________________________________________________________________________________
_________________________________________________________________________________________

Router und Switches bilden die Basis und das Rckgrat aller vernetzten IT-Infrastrukturen. Daher
mssen Router und Switches vor unerlaubten Zugriffen und Manipulationen geschtzt werden. In
diesem Baustein sind die fr einen sicheren Einsatz von Routern und Switches zu bercksichtigenden
Manahmen aufgezeigt.
8.1 TK-Anlage
In diesem Baustein wird eine auf ISDN basierende Telekommunikationsanlage betrachtet. Eine TK-
Anlage in der heutigen Ausprgung ist ein komplexes IT-System, bei dessen Administration eine
Reihe von Manahmen beachtet werden mssen, um den sicheren Betrieb der TK-Anlage zu gewhr-
leisten.
8.2 Faxgert
Die Informationsbermittlung per stand-alone Faxgert erffnet ein neues Feld von Gefhrdungen.
Dargestellt werden daher die notwendigen Manahmen, mit denen fr die Faxnutzung ein IT-Grund-
schutz realisiert werden kann. Dies sind zum Beispiel die Entsorgung von Fax-Verbrauchsgtern, die
geeignete Aufstellung des Faxgertes und die ggf. notwendigen Absprachen von Absender und
Empfnger.
8.3 Anrufbeantworter
Moderne Anrufbeantworter mit Fernabfragemglichkeiten knnen als IT-Systeme aufgefasst werden,
in denen Sprachinformationen gespeichert werden. Sie sind der Gefhrdung ausgesetzt, dass die
Fernabfrage missbraucht wird. Dargestellt werden IT-Grundschutz-Manahmen fr Anrufbeantworter,
auch speziell zu dieser Gefhrdung.
8.4 LAN-Anbindung eines IT-Systems ber ISDN
Die Anbindung eines IT-Systems ber eine ISDN-Adapterkarte mit S0-Schnittstelle an ein entfernt
stehendes lokales Netz (LAN) wird in diesem Baustein betrachtet. Vorausgesetzt wird, dass innerhalb
dieses LAN ein Router vorhanden ist, der ber eine S2M-Schnittstelle mit dem ffentlichen Netz
verbunden ist.
8.5 Faxserver
In diesem Baustein werden fr die Informationsbertragung per Fax als technische Basis ausschlie-
lich Faxserver betrachtet. Ein Faxserver in diesem Sinne ist eine Applikation, die auf einem IT-System
installiert ist und in einem Netz fr andere IT-Systeme die Dienste Faxversand und/oder Faxempfang
zur Verfgung stellt.
8.6 Mobiltelefon
Um fr digitale Mobilfunksysteme nach dem GSM-Standard (D- und E-Netze) einen sicheren Einsatz
zu gewhrleisten, werden in diesem Kapitel fr die Komponenten Mobiltelefon, Basisstation und
Festnetz und deren Zusammenspiel untereinander geeignete Sicherheitsmanahmen vorgeschlagen.
8.7 PDA
Dieser Baustein beschftigt sich mit PDAs (Personal Digital Assistants), also handtellergroen,
mobilen Endgerten zur Datenerfassung, -bearbeitung und -kommunikation. Es wird beschrieben,
welche Regelungen und Sicherheitsmanahmen fr deren sicheren Einsatz innerhalb von
Organisationen ergriffen werden sollten.
_________________________________________________________________________________________
_________________________________________________________________________________________
Es wird eine Vorgehensweise beschrieben, wie der Lebenszyklus von Standardsoftware, d. h. Anfor-
derungskatalog, Auswahl, Testen, Freigabe, Installation und Deinstallation, gestaltet werden kann.
Insbesondere werden Aspekte wie Tests der Funktionalitt und Sicherheitseigenschaften, Installati-
onsanweisungen und Freigabeerklrung erlutert.
9.2 Datenbanken
Die fr die Auswahl einer Datenbank, deren Installation und Konfiguration sowie fr den laufenden
Betrieb erforderlichen Manahmen wie z. B. Erstellung eines Datenbankkonzeptes, Regelung zur
Einrichtung von Datenbankbenutzern/-benutzergruppen oder Richtlinien fr Datenbank-Anfragen
werden in diesem Kapitel beschrieben.
9.3 Telearbeit
Die aus organisatorischer und personeller Sicht erforderlichen Regelungen fr die Einrichtung von
Telearbeitspltzen werden in diesem Baustein beschrieben. Weiterhin werden die sicherheitstech-
nischen Anforderungen an die Telearbeit formuliert, die durch den Einsatz geeigneter IT-Kompo-
nenten realisiert werden mssen.
9.4 Novell eDirectory
Novell eDirectory ist ein komplexes und vielseitiges Produkt, das einerseits innerhalb eines Netzes das
Management der eingebundenen Ressourcen und deren Benutzer bernehmen kann und andererseits
auch als Internet-Informationsbasis einsetzbar ist. Der Baustein verweist auf die beim Einsatz von
Novell eDirectory erforderlichen Standard-Sicherheitsmanahmen.
9.5 Archivierung
Die dauerhafte und unvernderbare Speicherung von elektronischen Dokumenten und anderen Daten
wird als Archivierung bezeichnet. Der Baustein beschreibt Sicherheitsempfehlungen unter anderem
zur systematischen Planung, Einfhrung, Betrieb und Migration von Archivsystemen.
_________________________________________________________________________________________
Hilfsmittel 1.5
_________________________________________________________________________________________
1.5 Hilfsmittel
Mit den Empfehlungen der Standard-Sicherheitsmanahmen bietet das IT-Grundschutzhandbuch
unmittelbare Hilfe zur Umsetzung der IT-Sicherheit. Darber hinaus stehen weitere Hilfsmittel fr die
tgliche Arbeit mit IT-Sicherheit zur Verfgung. Diese Hilfsmittel lassen sich in zwei Bereiche
unterteilen: einerseits Software und Programme und andererseits weiterfhrende Dokumente.
Software-Hilfsmittel
Fr den IT-Grundschutz stehen zur Zeit folgende Software-Hilfsmittel zur Verfgung (weitere
Informationen dazu finden sich auf der BSI Webseite):
- BSI-Tool zum IT-Grundschutz: Mit diesem im Auftrag des BSI entwickelten Tool wird die
gesamte Vorgehensweise bei der Erstellung eines Sicherheitskonzepts nach IT-Grundschutz, der
Soll-Ist-Vergleich, die Umsetzung der Manahmen und die anschlieende Sicherheitsrevision
untersttzt. Darber hinaus kann aus dem Tool elektronisch auf die Texte des Handbuchs zugegrif-
fen werden. Ein individuell anpassbares Berichtswesen untersttzt den IT-Sicherheitsbeauftragten
dabei, IT-Grundschutz umzusetzen.
- Webkurs IT-Grundschutz: Dieser Selbstlern-Kurs erleichtert den Einstieg in das umfassende
Thema IT-Grundschutz. In etwa vier Stunden werden Einsteiger in leicht nachvollziehbarer Form
an das Thema IT-Grundschutz herangefhrt. Der Webkurs zeigt auf, wie fr einen IT-
Sicherheitsprozess die notwendigen Analysen durchzufhren und Dokumente auszuarbeiten sind.
Anhand eines Beispiels wird die Anwendung des IT-Grundschutzhandbuchs fr einen
vollstndigen IT-Verbund demonstriert. Durch zahlreiche Anleitungen, Beispiele, bungen und
Hilfsmittel werden die Lernenden so trainiert, dass sie eigene Sicherheitskonzepte gem IT-
Grundschutzhandbuch erstellen knnen.
- Chiasmus fr Windows: Speziell fr die Belange der deutschen Verwaltung wurde ein
Verschlsselungsprogramm, das unter der Windows-Oberflche eingesetzt werden kann, vom BSI
entwickelt. Darber hinaus knnen mit diesem Tool auch Dateien physikalisch gelscht werden.
Weiterfhrende Dokumente
Zur Ergnzung des IT-Grundschutzhandbuchs stehen eine Reihe von weiteren Dokumenten zur
Verfgung. Diese sind teilweise vom BSI erstellt worden und teilweise auch von Anwendern des
Handbuchs dem BSI zur weiteren Verbreitung kostenlos zur Verfgung gestellt worden. Eine ber-
sicht ber die verfgbaren Hilfsmittel befindet sich im Anhang.
An dieser Stelle seien einige dieser Hilfsmittel genannt:
- Muster einer IT-Sicherheitsleitlinie,
- Musterdienstanweisung fr IT-Sicherheitsbeauftragte,
- Muster einer Benutzerordnung fr elektronische Kommunikationsdienste,
- Mustervertrag zur Entsorgung von Datentrgern,
- Musterbetriebsvereinbarung fr E-Mail und Internet,
- Foliensatz zur Vorstellung von IT-Grundschutz fr Manager, IT-Verantwortliche und Mitarbeiter
und
- Formbltter fr die IT-Grundschutzerhebung.
Alle Hilfsmittel, die von Anwendern des IT-Grundschutzhandbuchs erarbeitet und anderen Anwen-
dern hier zur Verfgung gestellt werden, erspart der "Interessengemeinschaft IT-Sicherheit" erhebliche
Arbeit, indem das Rad nicht immer wieder neu erfunden werden muss. Hilfsmittel knnen dem BSI
ber die IT-Grundschutz-Hotline (01888/9582-369 oder gshb@bsi.bund.de) bermittelt werden.
_________________________________________________________________________________________
Informationsfluss und Kontakte 1.6
_________________________________________________________________________________________
1.6 Informationsfluss und Kontakte

Neben der regelmigen Aktualisierung und Weiterentwicklung des IT-Grundschutzhandbuchs gibt
das BSI weitere aktuelle Informationen rund um das Thema IT-Grundschutz auf verschiedenen
Kommunikationswegen heraus.
BSI-CD-ROM und IT-Grundschutz
Die dem gedruckten Handbuch beiliegende CD-ROM enthlt smtliche Texte und Hilfsmittel des
deutschen IT-Grundschutzhandbuchs im Word- und im PDF-Format.
Das BSI verteilt kostenlos BSI-CD-ROMs, die neben vielen anderen BSI-Informationen das
vollstndige IT-Grundschutzhandbuch enthalten. Hier finden sich neben der aktuellen deutschen
Version des IT-Grundschutzhandbuchs auch die englische bersetzung und die HTML-Version des
Handbuchs.
Diese BSI-CD-ROMs knnen gegen Einsendung eines an sich selbst adressierten Rckumschlags
(Format C5, frankiert mit 1,44 Euro) beim BSI CD-Versand, Postfach 20 10 10, 53140 Bonn bezogen
werden.
IT-Grundschutz im Intranet
Die elektronischen Versionen des IT-Grundschutzhandbuchs knnen auch in Intranets bereitgestellt
werden. Hierzu eignet sich besonders die HTML-Version. Dies bedarf keiner besonderen Genehmi-
gung durch das BSI.
IT-Grundschutz im Internet
Das gesamte Handbuch in Deutsch und in Englisch ist auch im Internet unter
http://www.bsi.bund.de/gshb abrufbar. Darber hinaus finden sich dort auch aktuelle Informationen
ber neue Entwicklungen zum Handbuch und neu verfgbare Hilfsmittel.
IT-Grundschutz-Hotline
Fr aktuelle Fragen rund um das Thema IT-Grundschutz stellt das BSI in den blichen Brozeiten
(werktags 8.00 - 16.00 Uhr) eine Hotline zur Verfgung. Diese Hotline ist erreichbar unter:
Telefon: 01888 9582 - 369
Fax: 01888 9582 - 405
E-Mail: gshb@bsi.bund.de
Verbesserungsvorschlge, Fehlermeldungen und Erweiterungswnsche knnen ebenfalls an die IT-
Grundschutz-Hotline gerichtet werden.
Freiwillige Registrierung
Das BSI bentigt den Erfahrungsaustausch mit den Anwendern des Handbuchs, um es aktuell und
bedarfsgerecht weiterentwickeln zu knnen. Gleichzeitig werden Wege gesucht, die Anwender direkt
ber aktuelle Themen des IT-Grundschutzes (Vorabinformationen zu neuen Bausteinen und
Entwicklungen, Einladungen zum IT-Grundschutz-Forum, Fragebogenaktionen) informieren zu
knnen. Anwender des Handbuchs knnen sich zu diesem Zweck unter
www.bsi.bund.de/gshb/deutsch/etc/registrierung.htm beim BSI freiwillig registrieren lassen. Die
bermittelten Daten werden gespeichert und nur zu dem Zweck des Informationsaustauschs rund um
die Themen IT-Sicherheit und IT-Grundschutz verwendet. Durch die Registrierung entstehen keine
Kosten. Aufgrund der hohen Zahl freiwillig registrierter Anwender kann das BSI
_________________________________________________________________________________________
Informationsfluss und Kontakte 1.6
_________________________________________________________________________________________
den Informationsaustausch nur per E-Mail und per Fax abwickeln, der Postweg wird nur in seltenen
Ausnahmen genutzt.
Um Transparenz zu erzeugen, welche Branchen IT-Grundschutz einsetzen, verffentlicht das BSI im
Internet diejenigen registrierten Institutionen, die dieser Verffentlichung zustimmen. Dazu finden
regelmig Abfragen durch das BSI statt.
_________________________________________________________________________________________
Anwendung des IT-Grundschutzhandbuchs 2
_________________________________________________________________________________________
2 Anwendung des IT-Grundschutzhandbuchs
2.1 IT-Strukturanalyse
2.2 Schutzbedarfsfeststellung
2.3 Modellierung nach IT-Grundschutz
2.4 Basis-Sicherheitscheck
2.5 Ergnzende Sicherheitsanalyse
2.6 Realisierung von IT-Sicherheitsmanahmen
2.7 IT-Grundschutz-Zertifikat
_________________________________________________________________________________________
_________________________________________________________________________________________
2 Anwendung des IT-

Grundschutzhandbuchs
Die Durchsetzung und Aufrechterhaltung eines
angemessenen IT-Sicherheitsniveaus kann nur durch ein
geplantes und organisiertes Vorgehen aller Beteiligten
gewhrleistet werden. Voraussetzung fr die sinnvolle
Umsetzung und Erfolgskontrolle von IT-
Sicherheitsmanahmen ist ein durchdachter und
gesteuerter IT-Sicherheitsprozess.
Der IT-Sicherheitsprozess beginnt mit der Definition der
IT-Sicherheitsziele und der Einrichtung eines IT-
Sicherheitsmanagements. Dessen Aufgabe ist es, ein IT-Sicherheitskonzept zu erstellen und zu
realisieren. Mit der Aufrechterhaltung der IT-Sicherheit im laufenden Betrieb kehrt der IT-
Sicherheitsprozess regelmig zur Erstellung des Sicherheitskonzepts zurck, um damit einen
kontinuierlichen Prozess zu ermglichen. Diese Vorgehensweise wird in der nachfolgenden bersicht
schematisch dargestellt.
Abbildung: IT-Sicherheitsprozess
Weiterfhrende Informationen zum Bereich IT-Sicherheitsmanagement sind in Kapitel 3.0 dieses
Handbuchs zu finden.
_________________________________________________________________________________________
_________________________________________________________________________________________
Die Kernaufgabe des IT-Sicherheitsmanagements bildet die Erstellung des IT-Sicherheitskonzepts, da

dieses eine notwendige Voraussetzung zur Realisierung der erforderlichen IT-Sicherheitsmanahmen
bildet. In den nachfolgenden Abschnitten dieses Kapitels wird daher beschrieben, wie ein IT-Sicher-
heitskonzept unter Verwendung des IT-Grundschutzhandbuchs erstellt werden kann.
In der nachfolgenden Abbildung wird die prinzipielle Vorgehensweise schematisch dargestellt:
Abbildung: Erstellung eines IT-Sicherheitskonzepts
Nach der Erfassung der vorhandenen Informationstechnik wird eine Schutzbedarfsfeststellung durch-
gefhrt. In der anschlieenden IT-Grundschutzanalyse wird zunchst die betrachtete IT-Landschaft
durch Bausteine des Handbuchs nachgebildet. Anschlieend findet ein Soll-Ist-Vergleich zwischen
empfohlenen Standard-Sicherheitsmanahmen und den bereits realisierten Manahmen statt. Sollten
bei der Schutzbedarfsfeststellung Komponenten mit einem hohen oder sehr hohen Schutzbedarf
identifiziert worden sein, so bietet es sich an, nach der IT-Grundschutzanalyse eine ergnzende IT-
Sicherheitsanalyse durchzufhren. Dies kann ebenso fr den Fall erforderlich sein, dass im IT-Grund-
schutzhandbuch keine passenden Bausteine vorhanden sind. Den Abschluss der Erstellung eines IT-
Sicherheitskonzepts unter Verwendung des IT-Grundschutzhandbuchs bildet die Erstellung eines
Realisierungsplans fr die identifizierten und konsolidierten IT-Sicherheitsmanahmen.
_________________________________________________________________________________________
IT-Strukturanalyse 2.1
_________________________________________________________________________________________
2.1 IT-Strukturanalyse
Die IT-Strukturanalyse dient der Vorerhebung von
Informationen, die fr die weitere Vorgehensweise in der
Erstellung eines IT-Sicherheitskonzepts nach IT-Grund-
schutz bentigt werden. Sie gliedert sich in folgende
Teilaufgaben:
- Netzplanerhebung
- Komplexittsreduktion durch Gruppenbildung
- Erhebung der IT-Systeme
- Erfassung der IT-Anwendungen und der zugehrigen
Informationen
Diese Teilaufgaben werden nachfolgend beschrieben und durch ein begleitendes Beispiel erlutert.
Eine ausfhrliche Version des Beispiels ist den Hilfsmitteln auf der CD-ROM zum IT-Grundschutz-
handbuch beigefgt.
Auswertung eines Netzplans
Einen geeigneten Ausgangspunkt fr die IT-Strukturanalyse stellt ein Netzplan (beispielsweise in
Form eines Netztopologieplans) dar. Ein Netzplan ist eine graphische bersicht ber die im betrach-
teten Bereich der Informations- und Kommunikationstechnik eingesetzten Komponenten und deren
Vernetzung. Im Einzelnen sollte der Plan folgende Objekte darstellen:
- IT-Systeme, d. h. Client- und Server-Computer, aktive Netzkomponenten (wie Hubs, Switches,
Router), Netzdrucker, etc.
- Netzverbindungen zwischen diesen Systemen, d. h. LAN-Verbindungen (wie Ethernet, Token-
Ring), Backbone-Technologien (wie FDDI, ATM), etc.
- Verbindungen des betrachteten Bereichs nach auen, d. h. Einwahl-Zugnge ber ISDN oder
Modem, Internet-Anbindungen ber analoge Techniken oder Router, Funkstrecken oder Miet-
leitungen zu entfernten Gebuden oder Liegenschaften, etc.
Zu jedem der dargestellten Objekte gehrt weiterhin ein Minimalsatz von Informationen, die einem
zugeordneten Katalog zu entnehmen sind. Fr jedes IT-System sollte zumindest
- eine eindeutige Bezeichnung (beispielsweise der vollstndige Hostname oder eine Identifikations-
nummer),
- Typ und Funktion (beispielsweise Datenbankserver fr Anwendung X),
- die zugrunde liegende Plattform (d. h. Hardware-Plattform und Betriebssystem),
- der Standort (beispielsweise Gebude- und Raumnummer),
- der zustndige Administrator sowie
- die Art der Netzanbindung und die Netzadresse
vermerkt sein. Nicht nur fr die IT-Systeme selbst, sondern auch fr die Netzverbindungen zwischen
den Systemen und fr die Verbindungen nach auen sind bestimmte Informationen erforderlich,
nmlich
- die Art der Verkabelung (z. B. Lichtwellenleiter),
_________________________________________________________________________________________
_________________________________________________________________________________________
- die maximale Datenbertragungsrate (z. B. 10 Mbps),

- die auf den unteren Schichten verwendeten Netzprotokolle (z. B. Ethernet, TCP/IP),
- bei Auenanbindungen: Details zum externen Netz (z. B. Internet, Name des Providers).
Hat die Informationstechnik im Unternehmen bzw. in der Behrde einen gewissen Umfang ber-
schritten, bietet es sich an, bei der Erfassung und Pflege des Netzplans auf geeignete Hilfsprogramme
zurckzugreifen, da die Unterlagen eine erhebliche Komplexitt aufweisen knnen und stndigem
Wandel unterzogen sind.
Aktualisierung des Netzplans
Da die IT-Struktur in der Regel stndig an die Anforderungen der Behrde bzw. des Unternehmens
angepasst wird und die Pflege des Netzplans entsprechende Ressourcen bindet, ist der Netzplan der
Organisation nicht immer auf dem aktuellen Stand. Vielmehr werden in der Praxis oftmals nur grere
nderungen an der IT-Struktur einzelner Bereiche zum Anlass genommen, den Plan zu aktualisieren.
Im Hinblick auf die Verwendung des Netzplans fr die IT-Strukturanalyse besteht demnach der
nchste Schritt darin, den vorliegenden Netzplan (bzw. die Teilplne, wenn der Gesamtplan aus
Grnden der bersichtlichkeit aufgeteilt wurde) mit der tatschlich vorhandenen IT-Struktur abzu-
gleichen und ggf. auf den neuesten Stand zu bringen. Hierzu sind die IT-Verantwortlichen und
Administratoren der einzelnen Anwendungen und Netze zu konsultieren. Falls Programme fr ein
zentralisiertes Netz- und Systemmanagement zum Einsatz kommen, sollte auf jeden Fall geprft
werden, ob diese Programme bei der Erstellung eines Netzplans Untersttzung anbieten. Zu beachten
ist jedoch, dass Funktionen zur automatischen oder halbautomatischen Erkennung von Komponenten
temporr zustzlichen Netzverkehr erzeugen. Es muss sichergestellt sein, dass dieser Netzverkehr
nicht zu Beeintrchtigungen des IT-Betriebs fhrt.
Komplexittsreduktion durch Gruppenbildung
Der nchste Schritt besteht darin, den Netzplan um die Informationen zu bereinigen, die fr die nach-
folgenden Aufgaben nicht erforderlich sind, um dadurch bersichtlichkeit zu gewinnen. Hierzu sollten
jeweils gleichartige Komponenten zu einer Gruppe zusammengefasst werden, die im Netzplan durch
ein einzelnes Objekt dargestellt wird. Komponenten knnen dann ein und derselben Gruppe zuge-
ordnet werden, wenn die Komponenten alle
- vom gleichen Typ sind,
- gleich oder nahezu gleich konfiguriert sind,
- gleich oder nahezu gleich in das Netz eingebunden sind (z. B. am gleichen Switch),
- den gleichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen und
- die gleichen Anwendungen bedienen.
Aufgrund der genannten Voraussetzungen fr die Gruppenbildung kann bezglich IT-Sicherheit davon
ausgegangen werden, dass eine Stichprobe aus einer Gruppe den IT-Sicherheitszustand der Gruppe
reprsentiert.
Wichtigstes Beispiel fr die Gruppierung von Komponenten im Netzplan ist sicherlich die Zusam-
menfassung von Client-Computern. In der Regel gibt es in einem Unternehmen bzw. in einer Behrde
eine groe Anzahl von Clients, die sich jedoch gem obigem Schema in eine berschaubare Anzahl
von Gruppen aufteilen lassen. In groen IT-Verbnden, wo aus Grnden der Redundanz oder des
Durchsatzes viele Server die gleiche Aufgabe wahrnehmen, knnen durchaus auch Server zu Gruppen
zusammengefasst werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
Nach erfolgreicher Gruppierung werden die zusammengefassten Komponenten im Netzplan durch ein
Objekt dargestellt. Dabei sind Typ und Anzahl der Komponenten zu vermerken, die durch die Gruppe
reprsentiert werden.
Beispiel: Bundesamt fr Organisation und Verwaltung (BOV) - Teil 1
Im Folgenden wird anhand einer fiktiven Behrde, dem BOV, beispielhaft dargestellt, wie ein berei-
nigter Netzplan aussehen kann. Zu beachten ist, dass die IT-Struktur des BOV im Hinblick auf IT-
Sicherheit keineswegs optimal ist. Sie dient lediglich dazu, die Vorgehensweise bei der Anwendung
des IT-Grundschutzhandbuchs zu illustrieren. (Das komplette Beispiel ist den Hilfsmitteln auf der CD-
ROM beigefgt.)
Das BOV sei eine fiktive Behrde mit 150 Mitarbeitern, von denen 130 an Bildschirmarbeitspltzen
arbeiten. Rumlich besteht eine Aufteilung des Bundesamts in die Hauptstelle Bonn und eine Auen-
stelle in Berlin, wo unter anderem die Teilaufgaben Grundsatz, Normung und Koordinierung wahrge-
nommen werden. Von den insgesamt 130 Mitarbeitern mit IT-gesttzten Arbeitspltzen sind 90 in
Bonn und 40 in Berlin ttig.
Um die Dienstaufgaben leisten zu knnen, sind alle Arbeitspltze vernetzt worden. Die Auenstelle
Berlin ist ber eine angemietete Standleitung angebunden. Alle zu Grunde liegenden Normen und
Vorschriften sowie Formulare und Textbausteine sind stndig fr jeden Mitarbeiter abrufbar. Alle
relevanten Arbeitsergebnisse werden in eine zentrale Datenbank eingestellt. Entwrfe werden aus-
schlielich elektronisch erstellt, weitergeleitet und unterschrieben. Zur Realisierung und Betreuung
aller bentigten Funktionalitten ist in Bonn ein IT-Referat installiert worden.
Abbildung: Beispiel eines bereinigten Netzplans

In dem dargestellten Netzplan sind die IT-Systeme durch eine Nummer (Server, Clients und aktive
Netzkomponenten in der Form Sn, Cn bzw. Nn), die Funktion und ggf. das Betriebssystem (in Klam-
mern) gekennzeichnet.
_________________________________________________________________________________________
_________________________________________________________________________________________
Sowohl in Berlin als auch in Bonn wurden die Clients in geeignete Gruppen zusammengefasst. Zwar
sind alle 130 Clients nahezu gleich konfiguriert, sie unterscheiden sich jedoch im Hinblick auf die
Anwendungen, die Einbindung in das Netz und die infrastrukturellen Rahmenbedingungen. Die
Gruppe C1 reprsentiert die 5 Clients in der Personalabteilung. Diese haben Zugriff auf den Server S1
der Personalabteilung in Bonn. C2 und C3 fassen die 10 Clients der Verwaltungsabteilung bzw. die 75
Clients der Fachabteilungen in Bonn zusammen. Sie unterscheiden sich lediglich im Hinblick auf die
genutzten Anwendungsprogramme. Schlielich werden durch die Gruppe C4 die Clients der Fachab-
teilungen in der Liegenschaft Berlin dargestellt. Von den Gruppen C1 bis C3 unterscheiden sie sich
durch die umgebende Infrastruktur und die abweichende Einbindung in das Gesamtnetz.
Erhebung der IT-Systeme
Im Hinblick auf die spter durchzufhrende Schutzbedarfsfeststellung und Modellierung des IT-
Verbunds wird als nchster Schritt eine Liste der vorhandenen und geplanten IT-Systeme in tabella-
rischer Form aufgestellt. Der Begriff IT-System umfasst dabei nicht nur Computer im engeren Sinn,
sondern auch aktive Netzkomponenten, Netzdrucker, TK-Anlagen, etc. Die technische Realisierung
eines IT-Systems steht im Vordergrund, beispielsweise stand-alone PC, Windows NT-Server, PC-
Client unter Windows 95, Unix-Server, TK-Anlage. An dieser Stelle soll nur das System als solches
erfasst werden (z. B. Unix-Server), nicht die einzelnen Bestandteile, aus denen das IT-System zusam-
mengesetzt ist (also nicht: Rechner, Tastatur, Bildschirm, etc.).
Zu erfassen sind sowohl die vernetzten als auch die nicht vernetzten IT-Systeme, insbesondere also
auch solche, die nicht im zuvor betrachteten Netzplan aufgefhrt sind. IT-Systeme, die bei der Berei-
nigung des Netzplans zu einer Gruppe zusammengefasst worden sind, knnen weiterhin als ein Objekt
behandelt werden. Auch bei den IT-Systemen, die nicht im Netzplan aufgefhrt sind, ist zu prfen, ob
sie sinnvoll zusammengefasst werden knnen. Mglich ist dies beispielsweise bei einer greren
Anzahl von stand-alone PCs, die die im Abschnitt "Komplexittsreduktion durch Gruppenbildung"
genannten Bedingungen fr eine Gruppierung erfllen.
Bei dieser Erfassung sollten folgende Informationen vermerkt werden, die fr die nachfolgende Arbeit
ntzlich sind:
- eine eindeutige Bezeichnung des IT-Systems,
- Beschreibung (Typ und Funktion),
- Plattform (z. B. Hardware-Architektur/Betriebssystem),
- bei Gruppen: Anzahl der zusammengefassten IT-Systeme,
- Aufstellungsort des IT-Systems,
- Status des IT-Systems (in Betrieb, im Test, in Planung) und
- Anwender/Administrator des IT-Systems.
Als Beispiel ist in der folgenden Tabelle ein Auszug aus der Liste der IT-Systeme im BOV aufgefhrt.
Die vollstndige Liste ist den Hilfsmitteln auf der CD-ROM beigefgt.
_________________________________________________________________________________________
_________________________________________________________________________________________
Nr. Beschreibung Plattform Anzahl Aufstel- Status Anwender/Admin.

lungsort
S1 Server fr Personalverwaltung Windows NT-Server 1 Bonn, R 1.01 in Betrieb Personalreferat

S2 Primrer Domnen-Controller Windows NT-Server 1 Bonn, R 3.10 in Betrieb alle IT-Anwender
C1 Gruppe von Clients der Perso- Windows NT-Work- 5 Bonn, R 1.02 - in Betrieb Personalreferat
naldatenverarbeitung station R 1.06
C2 Gruppe von Clients in der Windows NT-Work- 10 Bonn, R 1.07 - in Betrieb Verwaltungsabteilung
Verwaltungsabteilung station R 1.16
C6 Gruppe der Laptops fr den Laptop unter Windows 2 Berlin, R 2.01 in Betrieb alle IT-Anwender in
Standort Berlin 95 der Auenstelle Berlin
N1 Router zum Internet-Zugang Router 1 Bonn, R 3.09 in Betrieb alle IT-Anwender
N2 Firewall Application Gateway auf 1 Bonn, R 3.09 in Betrieb alle IT-Anwender
Unix
N3 Switch Switch 1 Bonn, R 3.09 in Betrieb alle IT-Anwender
T1 TK-Anlage fr Bonn ISDN-TK-Anlage 1 Bonn, B.02 in Betrieb alle Mitarbeiter in der
Hauptstelle Bonn
Die IT-Systeme bzw. Gruppen S1, S2, C1, C2, N1, N2 und N3 sind direkt dem Netzplan entnommen.
Demgegenber hinzugekommen sind die nicht vernetzten IT-Systeme C6 (Laptop) und T1 (TK-
Anlage).
Erfassung der IT-Anwendungen und der zugehrigen Informationen
Zur Reduzierung des Aufwands werden die jeweils wichtigsten auf den betrachteten IT-Systemen
laufenden oder geplanten IT-Anwendungen erfasst. Zur effizienten Durchfhrung dieser Aufgabe kann
auf eine vollstndige Erfassung aller Anwendungen verzichtet werden, wenn sichergestellt ist, dass
zumindest diejenigen IT-Anwendungen des jeweiligen IT-Systems benannt werden,
- deren Daten bzw. Informationen und Programme den hchsten Bedarf an Geheimhaltung
(Vertraulichkeit) besitzen,
- deren Daten bzw. Informationen und Programme den hchsten Bedarf an Korrektheit und Unver-
flschtheit (Integritt) besitzen,
- die die krzeste tolerierbare Ausfallzeit (hchster Bedarf an Verfgbarkeit) haben.
Um dies sicherzustellen, sollten bei der Erfassung der IT-Anwendungen die Benutzer bzw. die fr die
IT-Anwendung Verantwortlichen nach ihrer Einschtzung befragt werden.
Es erleichtert die Definition und Erfassung der IT-Anwendungen, wenn die IT-Anwendungen orien-
tiert an den IT-Systemen zusammengetragen werden. Aufgrund ihrer Breitenwirkung sollte dabei mit
den Servern begonnen werden. Um ein mglichst ausgewogenes Bild zu bekommen, kann anschlie-
end diese Erhebung auf Seiten der Clients und Stand-alone-Systeme vervollstndigt werden.
Abschlieend sollte noch festgestellt werden, welche Netzkoppelelemente welche IT-Anwendungen
untersttzen.
Zweckmigerweise sollten die Anwendungen zu Referenzzwecken durchnummeriert werden. Da
viele IT-Sicherheitsbeauftragte gleichzeitig auch als Datenschutzbeauftragte fr den Schutz personen-
bezogener Daten zustndig sind, bietet es sich an, an dieser Stelle schon zu vermerken, ob die
beschriebene IT-Anwendung personenbezogene Daten speichert und/oder verarbeitet.
_________________________________________________________________________________________
_________________________________________________________________________________________
Anschlieend werden die Anwendungen jeweils denjenigen IT-Systeme zugeordnet, die fr deren
Ausfhrung bentigt werden. Dies knnen die IT-Systeme sein, auf denen die IT-Anwendungen
verarbeitet werden, oder auch diejenigen, die Daten dieser Anwendung transferieren.
Das Ergebnis ist eine bersicht, welche wichtigen IT-Anwendungen auf welchen IT-Systemen
bearbeitet oder von welchen IT-Systemen genutzt oder bertragen werden. Zur Dokumentation der
Ergebnisse bietet sich die Darstellung in tabellarischer Form an.
Nachfolgend wird ein Auszug aus der Erfassung der IT-Anwendungen und der Zuordnung zu den
betroffenen IT-Systemen fr das fiktive Beispiel BOV aufgezeigt:
Beschreibung der IT-Anwendungen IT-Systeme
Anw.-Nr. IT-Anwendung/Informationen Pers.-bez. S1 S2 S3 S4 S5 S6 S7
Daten
A1 Personaldatenverarbeitung X X
A2 Beihilfeabwicklung X X
A3 Reisekostenabrechnung X X
A4 Benutzer-Authentisierung X X X
A5 Systemmanagement X
A6 E Xchange (E-Mail, Terminkalender) X X
A7 zentrale Dokumentenverwaltung X
Legende: Ai X Sj = Die Ausfhrung der IT-Anwendung Ai hngt vom IT-System Sj ab.
_________________________________________________________________________________________
Schutzbedarfsfeststellung 2.2
_________________________________________________________________________________________
2.2 Schutzbedarfsfeststellung
Die Schutzbedarfsfeststellung der erfassten IT-Struktur
gliedert sich in vier Schritte. Nach der Definition der
Schutzbedarfskategorien wird anhand von typischen
Schadensszenarien zunchst der Schutzbedarf der IT-
Anwendungen bestimmt. Anschlieend wird daraus der
Schutzbedarf der einzelnen IT-Systeme abgeleitet. Aus
diesen Ergebnissen wiederum wird abschlieend der
Schutzbedarf der bertragungsstrecken und der Rume,
die fr die IT zur Verfgung stehen, abgeleitet.
Schutzbedarfsfeststellung fr IT-Anwendungen
Ziel der Schutzbedarfsfeststellung ist es, fr jede erfasste IT-Anwendung einschlielich ihrer Daten zu
entscheiden, welchen Schutzbedarf sie bezglich Vertraulichkeit, Integritt und Verfgbarkeit besitzt.
Dieser Schutzbedarf orientiert sich an den mglichen Schden, die mit einer Beeintrchtigung der
betroffenen IT-Anwendung verbunden sind.
Da der Schutzbedarf meist nicht quantifizierbar ist, beschrnkt sich das IT-Grundschutzhandbuch im
Weiteren auf eine qualitative Aussage, indem der Schutzbedarf in drei Kategorien unterteilt wird:
Schutzbedarfskategorien
"niedrig bis mittel" Die Schadensauswirkungen sind begrenzt und berschaubar.
"hoch" Die Schadensauswirkungen knnen betrchtlich sein.
"sehr hoch" Die Schadensauswirkungen knnen ein existentiell bedrohliches,
katastrophales Ausma erreichen.
Die nachfolgenden Schritte erlutern, wie fr IT-Anwendungen die adquate Schutzbedarfskategorie

ermittelt werden kann.
Schritt 1: Definition der Schutzbedarfskategorien
Die Schden, die bei dem Verlust der Vertraulichkeit, Integritt oder Verfgbarkeit fr eine IT-
Anwendung einschlielich ihrer Daten entstehen knnen, lassen sich typischerweise folgenden
Schadensszenarien zuordnen:
- Versto gegen Gesetze/Vorschriften/Vertrge,
- Beeintrchtigung des informationellen Selbstbestimmungsrechts,
- Beeintrchtigung der persnlichen Unversehrtheit,
- Beeintrchtigung der Aufgabenerfllung,
- negative Auenwirkung und
- finanzielle Auswirkungen.
Hufig treffen dabei fr einen Schaden mehrere Schadenskategorien zu. So kann beispielsweise der
Ausfall einer IT-Anwendung die Aufgabenerfllung beeintrchtigen, was direkte finanzielle Einbuen
nach sich zieht und gleichzeitig auch zu einem Imageverlust fhrt.
_________________________________________________________________________________________
_________________________________________________________________________________________
Um die Schutzbedarfskategorien "niedrig bis mittel", "hoch" und "sehr hoch" voneinander abgrenzen
zu knnen, bietet es sich an, die Grenzen fr die einzelnen Schadensszenarien zu bestimmen. Zur
Orientierung, welchen Schutzbedarf ein potentieller Schaden und seine Folgen erzeugen, sollten dabei
folgende Tabellen benutzt werden.
Schutzbedarfskategorie "niedrig bis mittel"

1. Versto gegen - Verste gegen Vorschriften und Gesetze mit geringfgigen
Gesetze/Vorschriften/Vertrge Konsequenzen
- Geringfgige Vertragsverletzungen mit maximal geringen
Konventionalstrafen
2. Beeintrchtigung des informa- - Eine Beeintrchtigung des informationellen
tionellen Selbstbestimmungsrechts Selbstbestimmungsrechts wrde durch den Einzelnen als
tolerabel eingeschtzt werden.
- Ein mglicher Missbrauch personenbezogener Daten hat nur
geringfgige Auswirkungen auf die gesellschaftliche Stellung
oder die wirtschaftlichen Verhltnisse des Betroffenen.
3. Beeintrchtigung der - Eine Beeintrchtigung erscheint nicht mglich.
persnlichen Unversehrtheit
4. Beeintrchtigung der - Die Beeintrchtigung wrde von den Betroffenen als tolerabel
Aufgabenerfllung eingeschtzt werden.
- Die maximal tolerierbare Ausfallzeit ist grer als
24 Stunden.
5. Negative Auenwirkung - Eine geringe bzw. nur interne Ansehens- oder
Vertrauensbeeintrchtigung ist zu erwarten.
6. Finanzielle Auswirkungen - Der finanzielle Schaden bleibt fr die Institution tolerabel.
Schutzbedarfskategorie "hoch"
1. Versto gegen - Verste gegen Vorschriften und Gesetze mit erheblichen
Gesetze/Vorschriften/Vertrge Konsequenzen
- Vertragsverletzungen mit hohen Konventionalstrafen
2. Beeintrchtigung des informa- - Eine erhebliche Beeintrchtigung des informationellen Selbst-
tionellen Selbstbestimmungsrechts bestimmungsrechts des Einzelnen erscheint mglich.
- Ein mglicher Missbrauch personenbezogener Daten hat
erhebliche Auswirkungen auf die gesellschaftliche Stellung
oder die wirtschaftlichen Verhltnisse des Betroffenen.
3. Beeintrchtigung der - Eine Beeintrchtigung der persnlichen Unversehrtheit kann
persnlichen Unversehrtheit nicht absolut ausgeschlossen werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
4. Beeintrchtigung der - Die Beeintrchtigung wrde von einzelnen Betroffenen als

Aufgabenerfllung nicht tolerabel eingeschtzt.
- Die maximal tolerierbare Ausfallzeit liegt zwischen einer und
24 Stunden.
5. Negative Auenwirkung - Eine breite Ansehens- oder Vertrauensbeeintrchtigung ist zu
erwarten.
6. Finanzielle Auswirkungen - Der Schaden bewirkt beachtliche finanzielle Verluste, ist
jedoch nicht existenzbedrohend.
Schutzbedarfskategorie "sehr hoch"

1. Versto gegen - Fundamentaler Versto gegen Vorschriften und Gesetze
Gesetze/Vorschriften/Vertrge
- Vertragsverletzungen, deren Haftungsschden ruins sind
2. Beeintrchtigung des informa- - Eine besonders bedeutende Beeintrchtigung des
tionellen Selbstbestimmungsrechts informationellen Selbstbestimmungsrechts des Einzelnen
erscheint mglich.
- Ein mglicher Missbrauch personenbezogener Daten wrde
fr den Betroffenen den gesellschaftlichen oder
wirtschaftlichen Ruin bedeuten.
3. Beeintrchtigung der - Gravierende Beeintrchtigungen der persnlichen
persnlichen Unversehrtheit Unversehrtheit sind mglich.
- Gefahr fr Leib und Leben
4. Beeintrchtigung der - Die Beeintrchtigung wrde von allen Betroffenen als nicht
Aufgabenerfllung tolerabel eingeschtzt werden.
- Die maximal tolerierbare Ausfallzeit ist kleiner als eine
Stunde.
5. Negative Auenwirkung - Eine landesweite Ansehens- oder Vertrauensbeeintrchtigung,
evtl. sogar existenzgefhrdender Art, ist denkbar.
6. Finanzielle Auswirkungen - Der finanzielle Schaden ist fr die Institution
existenzbedrohend.
Individualisierung der Zuordnungstabelle

Da nicht ausgeschlossen werden kann, dass bei individuellen Betrachtungen ber diese sechs
Schadensszenarien hinaus weitere in Frage kommen, sollten diese entsprechend ergnzt werden. Fr
alle Schden, die sich nicht in diese Szenarien abbilden lassen, muss ebenfalls eine Aussage getroffen
werden, wo die Grenze zwischen "niedrig bis mittel", "hoch" oder "sehr hoch" zu ziehen ist.
Darber hinaus sollten die individuellen Gegebenheiten der Institution bercksichtigt werden: Bedeu-
tet in einem Grounternehmen ein Schaden in Hhe von 200.000.- Euro gemessen am Umsatz und am
IT-Budget noch einen geringen Schaden, so kann fr ein Kleinunternehmen schon ein Schaden in
_________________________________________________________________________________________
_________________________________________________________________________________________
Hhe von 10.000.- Euro existentiell bedrohlich sein. Daher kann es sinnvoll sein, eine prozentuale
Gre als Grenzwert zu definieren, der sich am Gesamtumsatz, am Gesamtgewinn oder am IT-Budget
orientiert.
hnliche berlegungen knnen bezglich der Verfgbarkeitsanforderungen angestellt werden. So
kann beispielsweise ein Ausfall von 24 Stunden Dauer als noch tolerabel eingeschtzt werden. Tritt
jedoch eine Hufung dieser Ausflle ein, z. B. mehr als einmal wchentlich, so kann dies in der
Summe nicht tolerierbar sein.
Bei der Festlegung der Grenze zwischen "mittel" und "hoch" sollte bercksichtigt werden, dass fr den
mittleren Schutzbedarf die Standard-Sicherheitsmanahmen dieses Handbuchs ausreichen sollten. Die
getroffenen Festlegungen sind in geeigneter Weise im Sicherheitskonzept zu dokumentieren.
Schritt 2: Betrachtung von Schadensszenarien

Ausgehend von der Mglichkeit, dass Vertraulichkeit, Integritt oder Verfgbarkeit einer IT-Anwen-
dung oder der zugehrigen Informationen verloren gehen, werden die maximalen Schden und Folge-
schden betrachtet, die aus einer solchen Situation entstehen knnen. Unter der Fragestellung
"Was wre, wenn ... ?"
werden aus Sicht der Anwender realistische Schadensszenarien entwickelt und die zu erwartenden
materiellen oder ideellen Schden beschrieben. Die Hhe dieser mglichen Schden bestimmt
letztendlich dann den Schutzbedarf der IT-Anwendung. Dabei ist es unbedingt erforderlich, die
Verantwortlichen und die Benutzer der betrachteten IT-Anwendung nach ihrer persnlichen Ein-
schtzung zu befragen. Sie haben im Allgemeinen eine gute Vorstellung darber, welche Schden
entstehen knnen, und knnen fr die Erfassung wertvolle Hinweise geben.
Um die Ermittlung der mglichen Schden zu vereinfachen, werden nachfolgend zu den genannten
Schadensszenarien Fragestellungen vorgestellt, die die mglichen Auswirkungen hinterfragen. Diese
Anregungen erheben nicht den Anspruch auf Vollstndigkeit, sie dienen lediglich zur Orientierung. In
jedem Fall mssen die individuelle Aufgabenstellung und die Situation der Institution bercksichtigt,
und diese Fragen entsprechend ergnzt werden.
In der weiteren Vorgehensweise bietet es sich an, fr die erfassten IT-Anwendungen die folgenden
Schadensszenarien einschlielich der Fragestellungen durchzuarbeiten. Anschlieend sollte anhand
der oben definierten Tabellen die Festlegung des Schutzbedarfs bezglich Vertraulichkeit, Integritt
und Verfgbarkeit durch die Zuordnung zu einer Schutzbedarfskategorie vorgenommen werden.
Schadensszenario "Versto gegen Gesetze/Vorschriften/Vertrge"
Sowohl aus dem Verlust der Vertraulichkeit als auch der Integritt und ebenso der Verfgbarkeit
knnen derlei Verste resultieren. Die Schwere des Schadens ist dabei oftmals abhngig davon,
welche rechtlichen Konsequenzen daraus fr die Institution entstehen knnen.
Beispiele fr relevante Gesetze sind:
Grundgesetz, Brgerliches Gesetzbuch, Strafgesetzbuch, Bundesdatenschutzgesetz und Daten-
schutzgesetze der Lnder, Sozialgesetzbuch, Handelsgesetzbuch, Personalvertretungsgesetz,
Betriebsverfassungsgesetz, Urheberrechtsgesetz, Patentgesetz, Informations- und Kommuni-
kationsdienstegesetz (IuKDG), Gesetz zur Kontrolle und Transparenz im Unternehmen(KonTraG).
Beispiele fr relevante Vorschriften sind:
Verwaltungsvorschriften, Verordnungen und Dienstvorschriften.
_________________________________________________________________________________________
_________________________________________________________________________________________
Beispiele fr Vertrge:
Dienstleistungsvertrge im Bereich Datenverarbeitung, Vertrge zur Wahrung von Betriebs-
geheimnissen.
Fragen:
Verlust der Vertraulichkeit
Erfordern gesetzliche Auflagen die Vertraulichkeit der Daten?
Ist im Falle einer Verffentlichung von Informationen mit Strafverfolgung oder Regressforderungen
zu rechnen?
Sind Vertrge einzuhalten, die die Wahrung der Vertraulichkeit bestimmter Informationen beinhalten?
Verlust der Integritt
Erfordern gesetzliche Auflagen die Integritt der Daten?
In welchem Mae wird durch einen Verlust der Integritt gegen Gesetze bzw.Vorschriften verstoen?
Verlust der Verfgbarkeit
Sind bei Ausfall der IT-Anwendung Verste gegen Vorschriften oder sogar Gesetze die Folge? Wenn
ja, in welchem Mae?
Schreiben Gesetze die dauernde Verfgbarkeit bestimmter Informationen vor?
Gibt es Termine, die bei Einsatz der IT-Anwendung zwingend einzuhalten sind?
Gibt es vertragliche Bindungen fr bestimmte einzuhaltende Termine?
Schadensszenario "Beeintrchtigung des informationellen Selbstbestimmungsrechts"
Bei der Implementation und dem Betrieb von IT-Systemen und IT-Anwendungen besteht die Gefahr
einer Verletzung des informationellen Selbstbestimmungsrechts bis hin zu einem Missbrauch perso-
nenbezogener Daten.
Beispiele fr die Beeintrchtigung des informationellen Selbstbestimmungsrechts sind:
- Unzulssige Erhebung personenbezogener Daten ohne Rechtsgrundlage oder Einwilligung,
- unbefugte Kenntnisnahme bei der Datenverarbeitung bzw. der bermittlung von personen-
bezogenen Daten,
- unbefugte Weitergabe personenbezogener Daten,
- Nutzung von personenbezogenen Daten zu einem anderen, als dem bei der Erhebung zulssigen
Zweck und
- Verflschung von personenbezogenen Daten in IT-Systemen oder bei der bertragung.
Die folgenden Fragen knnen zur Abschtzung mglicher Folgen und Schden herangezogen werden:
Fragen:
Welche Schden knnen fr den Betroffenen entstehen, wenn seine personenbezogenen Daten nicht
vertraulich behandelt werden?
Werden personenbezogene Daten fr unzulssige Zwecke verarbeitet?
Ist es im Zuge einer zulssigen Verarbeitung personenbezogener Daten mglich, aus diesen Daten
z. B. auf den Gesundheitszustand oder die wirtschaftliche Situation einer Person zu schlieen?
_________________________________________________________________________________________
_________________________________________________________________________________________
Welche Schden knnen durch den Missbrauch der gespeicherten personenbezogenen Daten
entstehen?
Welche Schden wrden fr den Betroffenen entstehen, wenn seine personenbezogenen Daten
unabsichtlich verflscht oder absichtlich manipuliert wrden?
Wann wrde der Verlust der Integritt personenbezogener Daten frhestens auffallen?
Knnen bei Ausfall der IT-Anwendung oder bei einer Strung einer Datenbertragung personen-
bezogene Daten verloren gehen oder verflscht werden, so dass der Betroffene in seiner gesellschaft-
lichen Stellung beeintrchtigt wird oder gar persnliche oder wirtschaftliche Nachteile zu befrchten
hat?
Schadensszenario "Beeintrchtigung der persnlichen Unversehrtheit"

Die Fehlfunktion eines IT-Systems oder einer IT-Anwendung kann unmittelbar die Verletzung, die
Invaliditt oder den Tod von Personen nach sich ziehen. Die Hhe des Schadens ist am direkten
persnlichen Schaden zu messen.
Beispiele fr solche IT-Anwendungen und -Systeme sind:
- medizinische berwachungsrechner,
- medizinische Diagnosesysteme,
- Flugkontrollrechner und
- Verkehrsleitsysteme.
Fragen:
Kann durch das Bekanntwerden personenbezogener Daten eine Person physisch oder psychisch
geschdigt werden?
Knnen durch manipulierte Programmablufe oder Daten Menschen gesundheitlich gefhrdet werden?
Bedroht der Ausfall der IT-Anwendung oder des IT-Systems unmittelbar die persnliche Unversehrt-
heit von Personen?
Schadensszenario "Beeintrchtigung der Aufgabenerfllung"

Gerade der Verlust der Verfgbarkeit einer IT-Anwendung oder der Integritt der Daten kann die Auf-
gabenerfllung in einem Unternehmen oder in einer Behrde erheblich beeintrchtigen. Die Schwere
des Schadens richtet sich hierbei nach der zeitlichen Dauer der Beeintrchtigung und nach dem
Umfang der Einschrnkungen der angebotenen Dienstleistungen.
Beispiele sind:
- Fristversumnisse durch verzgerte Bearbeitung von Verwaltungsvorgngen,
- versptete Lieferung aufgrund verzgerter Bearbeitung von Bestellungen,
_________________________________________________________________________________________
_________________________________________________________________________________________
- fehlerhafte Produktion aufgrund falscher Steuerungsdaten und

- unzureichende Qualittssicherung durch Ausfall eines Testsystems.
Fragen:
Gibt es Daten, deren Vertraulichkeit die Grundlage fr die Aufgabenerfllung ist (z. B. Strafver-
folgungsinformationen, Ermittlungsergebnisse)?
Knnen Datenvernderungen die Aufgabenerfllung dergestalt einschrnken, dass die Institution
handlungsunfhig wird?
Entstehen erhebliche Schden, wenn die Aufgaben trotz verflschter Daten wahrgenommen werden?
Wann werden unerlaubte Datenvernderungen frhestens erkannt?
Knnen verflschte Daten in der betrachteten IT-Anwendung zu Fehlern in anderen IT-Anwendungen
fhren?
Welche Folgen entstehen, wenn Daten flschlicherweise einer Person zugeordnet werden, die in
Wirklichkeit diese Daten nicht erzeugt hat?
Kann durch den Ausfall der IT-Anwendung die Aufgabenerfllung der Institution so stark beeintrch-
tigt werden, dass die Wartezeiten fr die Betroffenen nicht mehr tolerabel sind?
Sind von dem Ausfall dieser IT-Anwendung andere IT-Anwendungen betroffen?
Ist es fr die Institution bedeutsam, dass der Zugriff auf IT-Anwendungen nebst Programmen und
Daten stndig gewhrleistet ist?
Schadensszenario "Negative Auenwirkung"
Durch den Verlust einer der Grundwerte Vertraulichkeit, Integritt oder Verfgbarkeit in einer IT-
Anwendung knnen verschiedenartige negative Auenwirkungen entstehen, zum Beispiel:
- Ansehensverlust einer Behrde bzw. eines Unternehmens,
- Vertrauensverlust gegenber einer Behrde bzw. einem Unternehmen,
- Beeintrchtigung der wirtschaftlichen Beziehungen zusammenarbeitender Unternehmen,
- verlorenes Vertrauen in die Arbeitsqualitt einer Behrde bzw. eines Unternehmens und
- Einbue der Konkurrenzfhigkeit.
Die Hhe des Schadens orientiert sich an der Schwere des Vertrauensverlustes oder des Verbrei-
tungsgrades der Auenwirkung.
Ursachen fr diese Schden knnen vielfltiger Natur sein:
- Handlungsunfhigkeit einer Institution durch IT-Ausfall,
- fehlerhafte Verffentlichungen durch manipulierte Daten,
- Fehlbestellungen durch mangelhafte Lagerhaltungsprogramme,
- Nichteinhaltung von Verschwiegenheitserklrungen,
- Weitergabe von Fahndungsdaten an interessierte Dritte und
- Zuspielen vertraulicher Informationen an die Presse.
Fragen
_________________________________________________________________________________________
_________________________________________________________________________________________
Welche Konsequenzen ergeben sich fr die Institution durch die unerlaubte Verffentlichung der fr
die IT-Anwendung gespeicherten schutzbedrftigen Daten?
Kann der Vertraulichkeitsverlust der gespeicherten Daten zu einer Schwchung der Wettbewerbs-
position fhren?
Entstehen bei Verffentlichung von vertraulichen gespeicherten Daten Zweifel an der amtlichen
Verschwiegenheit?
Knnen Verffentlichungen von Daten zur politischen oder gesellschaftlichen Verunsicherung fhren?
Welche Schden knnen sich durch die Verarbeitung, Verbreitung oder bermittlung falscher oder
unvollstndiger Daten ergeben?
Wird die Verflschung von Daten ffentlich bekannt?
Entstehen bei einer Verffentlichung von verflschten Daten Ansehensverluste?
Knnen Verffentlichungen von verflschten Daten zur politischen oder gesellschaftlichen Verun-
sicherung fhren?
Knnen verflschte Daten zu einer verminderten Produktqualitt und damit zu einem Ansehensverlust
fhren?
Schrnkt der Ausfall der IT-Anwendung die Informationsdienstleistungen fr Externe ein?
Wird der (vorbergehende) Ausfall der IT-Anwendung extern bemerkt?
Schadensszenario "Finanzielle Auswirkungen"
Unmittelbare oder mittelbare finanzielle Schden knnen durch den Verlust der Vertraulichkeit
schutzbedrftiger Daten, die Vernderung von Daten oder den Ausfall einer IT-Anwendung entstehen.
Beispiele dafr sind:
- unerlaubte Weitergabe von Forschungs- und Entwicklungsergebnissen,
- Manipulation von finanzwirksamen Daten in einem Abrechnungssystem,
- Ausfall eines IT-gesteuerten Produktionssystems und dadurch bedingte Umsatzverluste,
- Einsichtnahme in Marketingstrategiepapiere oder Umsatzzahlen,
- Ausfall eines Buchungssystems einer Reisegesellschaft,
- Ausfall eines E-Commerce-Servers,
- Zusammenbruch des Zahlungsverkehrs einer Bank,
- Diebstahl oder Zerstrung von Hardware.
Die Hhe des Gesamtschadens setzt sich zusammen aus den direkt und indirekt entstehenden Kosten,
etwa durch Sachschden, Schadenersatzleistungen und Kosten fr zustzlichen Aufwand (z. B.
Wiederherstellung).
Fragen
Kann die Verffentlichung vertraulicher Informationen Regressforderungen nach sich ziehen?
Gibt es in der IT-Anwendung Daten, aus deren Kenntnis ein Dritter (z. B. Konkurrenzunternehmen)
finanzielle Vorteile ziehen kann?
_________________________________________________________________________________________
_________________________________________________________________________________________
Werden mit der IT-Anwendung Forschungsdaten gespeichert, die einen erheblichen Wert darstellen?
Was passiert, wenn sie unerlaubt kopiert und weitergegeben werden?
Knnen durch vorzeitige Verffentlichung von schutzbedrftigen Daten finanzielle Schden
entstehen?
Knnen durch Datenmanipulationen finanzwirksame Daten so verndert werden, dass finanzielle
Schden entstehen?
Kann die Verffentlichung falscher Informationen Regressforderungen nach sich ziehen?
Knnen durch verflschte Bestelldaten finanzielle Schden entstehen (z. B. bei Just-in-Time Produk-
tion)?
Knnen verflschte Daten zu falschen Geschftsentscheidungen fhren?
Wird durch den Ausfall der IT-Anwendung die Produktion, die Lagerhaltung oder der Vertrieb
beeintrchtigt?
Ergeben sich durch den Ausfall der IT-Anwendung finanzielle Verluste aufgrund von verzgerten
Zahlungen bzw. Zinsverlusten?
Wie hoch sind die Reparatur- oder Wiederherstellungskosten bei Ausfall, Defekt, Zerstrung oder
Diebstahl des IT-Systems?
Kann es durch Ausfall der IT-Anwendung zu mangelnder Zahlungsfhigkeit oder zu Konventional-
strafen kommen?
Wieviele wichtige Kunden wren durch den Ausfall der IT-Anwendung betroffen?
Schritt 3: Dokumentation der Ergebnisse
Es bietet sich an, den oben ermittelten Schutzbedarf der einzelnen IT-Anwendungen in einer Tabelle
zu dokumentieren. Diese zentrale Dokumentation bietet den Vorteil, dass bei der nachfolgenden
Schutzbedarfsfeststellung fr IT-Systeme darauf referenziert werden kann.
Dabei ist darauf zu achten, dass nicht nur die Festlegung des Schutzbedarfs dokumentiert wird,
sondern auch die entsprechenden Begrndungen. Diese Begrndungen erlauben es spter, die Fest-
legungen nachzuvollziehen und weiterzuverwenden.
In der nachfolgenden Tabelle werden die wesentlichen IT-Anwendungen, deren Schutzbedarf und die
entsprechenden Begrndungen erfasst.
_________________________________________________________________________________________
_________________________________________________________________________________________
IT-Anwendung Schutzbedarfsfeststellung
Nr. Bezeichnung pers. Grund- Schutz- Begrndung
Daten wert bedarf
A1 Personaldatenverarbei X Vertrau- hoch Personaldaten sind besonders
tung lichkeit schutzbedrftige personenbezogene
Daten, deren Bekanntwerden die
Betroffenen erheblich beeintrchtigen
knnen.
Integritt mittel Der Schutzbedarf ist nur mittel, da
Fehler rasch erkannt und die Daten
nachtrglich korrigiert werden knnen.
Verfg- mittel Ausflle bis zu einer Woche knnen
barkeit mittels manueller Verfahren
berbrckt werden.
A2 Beihilfeabwicklung X Vertrau- hoch Beihilfedaten sind besonders
lichkeit schutzbedrftige personenbezogene
Daten, die z. T. auch Hinweise auf
Erkrankungen und rztliche Befunde
enthalten. Ein Bekanntwerden kann die
Betroffenen erheblich beeintrchtigen.
Integritt mittel Der Schutzbedarf ist nur mittel, da
Fehler rasch erkannt und die Daten
nachtrglich korrigiert werden knnen.
Verfg- mittel Ausflle bis zu einer Woche knnen
barkeit mittels manueller Verfahren
berbrckt werden.
An dieser Stelle kann es sinnvoll sein, ber diese Informationen hinaus den Schutzbedarf auch aus
einer gesamtheitlichen Sicht der Geschftsprozesse oder Fachaufgaben zu betrachten. Dazu bietet es
sich an, den Zweck einer IT-Anwendung in einem Geschftsprozess oder in einer Fachaufgabe zu
beschreiben und daraus wiederum deren Bedeutung abzuleiten. Diese Bedeutung kann wie folgt klas-
sifiziert werden:
Die Bedeutung der IT-Anwendung ist fr den Geschftsprozess bzw. die Fachaufgabe:
- niedrig bis mittel: Der Geschftsprozess bzw. die Fachaufgabe kann mit tolerierbarem Mehrauf-
wand mit anderen Mitteln (z. B. manuell) durchgefhrt werden.
- hoch: Der Geschftsprozess bzw. die Fachaufgabe kann nur mit deutlichem Mehraufwand mit
anderen Mitteln durchgefhrt werden.
- sehr hoch: Der Geschftsprozess bzw. die Fachaufgabe kann ohne die IT-Anwendung berhaupt
nicht durchgefhrt werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
Der Vorteil, eine solche ganzheitliche Zuordnung vorzunehmen, liegt insbesondere darin, dass bei der
Schutzbedarfsfeststellung die Leitungsebene als Regulativ fr den Schutzbedarf der einzelnen IT-
Anwendungen agieren kann. So kann es sein, dass ein Verantwortlicher fr eine IT-Anwendung deren
Schutzbedarf aus seiner Sicht als "niedrig" einschtzt, die Leitungsebene aus Sicht des Geschfts-
prozesses bzw. der Fachaufgabe diese Einschtzung jedoch nach oben korrigiert.
Diese optionalen Angaben sollten ebenfalls tabellarisch dokumentiert werden.
Schutzbedarfsfeststellung fr IT-Systeme
Um den Schutzbedarf eines IT-Systems festzustellen, mssen zunchst die IT-Anwendungen betrach-
tet werden, die in direktem Zusammenhang mit dem IT-System stehen. Eine bersicht, welche IT-
Anwendungen relevant sind, wurde im Schritt "Erfassung der IT-Anwendungen und der zugehrigen
Informationen" ermittelt.
Zur Ermittlung des Schutzbedarfs des IT-Systems mssen nun die mglichen Schden der relevanten
IT-Anwendungen in ihrer Gesamtheit betrachtet werden. Im Wesentlichen bestimmt der Schaden bzw.
die Summe der Schden mit den schwerwiegendsten Auswirkungen den Schutzbedarf eines IT-
Systems (Maximum-Prinzip).
Bei der Betrachtung der mglichen Schden und ihrer Folgen muss auch beachtet werden, dass IT-
Anwendungen eventuell Arbeitsergebnisse anderer IT-Anwendungen als Input nutzen. Eine - fr sich
betrachtet - weniger bedeutende IT-Anwendung A kann wesentlich an Wert gewinnen, wenn eine
andere, wichtige IT-Anwendung B auf ihre Ergebnisse angewiesen ist. In diesem Fall muss der
ermittelte Schutzbedarf der IT-Anwendung B auch auf die IT-Anwendung A bertragen werden.
Handelt es sich dabei um IT-Anwendungen verschiedener IT-Systeme, dann mssen Schutzbedarfs-
anforderungen des einen IT-Systems auch auf das andere bertragen werden (Beachtung von
Abhngigkeiten).
Werden mehrere IT-Anwendungen bzw. Informationen auf einem IT-System verarbeitet, so ist zu
berlegen, ob durch Kumulation mehrerer (z. B. kleinerer) Schden auf einem IT-System ein insge-
samt hherer Gesamtschaden entstehen kann. Dann erhht sich der Schutzbedarf des IT-Systems
entsprechend (Kumulationseffekt).
Beispiel: Auf einem Netz-Server befinden sich smtliche fr den Schreibdienst bentigten IT-Anwen-
dungen einer Institution. Der Schaden bei Ausfall einer dieser IT-Anwendungen wurde als gering ein-
geschtzt, da gengend Ausweichmglichkeiten vorhanden sind. Fllt jedoch der Server (und damit
alle IT-Anwendungen) aus, so ist der dadurch entstehende Schaden deutlich hher zu bewerten. Die
Aufgabenerfllung innerhalb der notwendigen Zeitspanne kann u. U. nicht mehr gewhrleistet werden.
Daher ist auch der Schutzbedarf dieser "zentralen" Komponenten entsprechend hher zu bewerten.
Auch der umgekehrte Effekt kann eintreten. So ist es mglich, dass eine IT-Anwendung einen hohen
Schutzbedarf besitzt, ihn aber deshalb nicht auf ein betrachtetes IT-System bertrgt, weil auf diesem
IT-System nur unwesentliche Teilbereiche der IT-Anwendung laufen. Hier ist der Schutzbedarf zu
relativieren (Verteilungseffekt).
Beispiele: Der Verteilungseffekt tritt hauptschlich bezglich des Grundwertes Verfgbarkeit auf. So
kann bei redundanter Auslegung von IT-Systemen der Schutzbedarf der Einzelkomponenten niedriger
sein als der Schutzbedarf der Gesamtanwendung. Auch im Bereich der Vertraulichkeit sind Vertei-
lungseffekte vorstellbar: Falls sichergestellt ist, dass ein Client nur unkritische Daten einer hochver-
traulichen Datenbankanwendung abrufen kann, so besitzt der Client im Gegensatz zum Datenbank-
server nur einen geringen Schutzbedarf.
_________________________________________________________________________________________
_________________________________________________________________________________________
Darstellung der Ergebnisse

Die Ergebnisse der Schutzbedarfsfeststellung der IT-Systeme sollten wiederum in einer Tabelle fest-
gehalten werden. Darin sollte verzeichnet sein, welchen Schutzbedarf jedes IT-System bezglich
Vertraulichkeit, Integritt und Verfgbarkeit hat. Besonderer Wert ist auf die Begrndung der
Einschtzungen zu legen, damit diese auch fr Auenstehende nachvollziehbar sind. Hier kann auf
die Schutzbedarfsfeststellung der IT-Anwendung zurckverwiesen werden.
Eine solche Tabelle knnte beispielsweise wie folgt aussehen:
IT-System Schutzbedarfsfeststellung
Nr. Beschreibung Grundwert Schutz- Begrndung
bedarf
S1 Server fr Vertraulichk hoch Maximumprinzip.
Personalverwaltung eit
Integritt mittel Maximumprinzip.
Verfgbarkei mittel Maximumprinzip.
t
S2 Primrer Domnen- Vertraulichk mittel Maximumprinzip.
Controller eit
Integritt hoch Maximumprinzip.
Verfgbarkei mittel Gem der Schutzbedarfsfeststellung fr
t Anwendung A4 ist von einem hohen
Schutzbedarf fr diesen Grundwert auszugehen.
Zu bercksichtigen ist aber, dass diese
Anwendung auf zwei Rechnersysteme verteilt
ist. Eine Authentisierung ber den Backup
Domnen-Controller in Berlin ist fr die
Mitarbeiter des Bonner Standortes ebenfalls
mglich. Ein Ausfall des Primren Domnen-
Controllers kann bis zu 72 Stunden
hingenommen werden. Der Schutzbedarf ist
aufgrund dieses Verteilungseffekts daher
"mittel".
Hinweise: Besitzen die meisten IT-Anwendungen auf einem IT-System nur einen mittleren Schutz-
bedarf und sind nur eine oder wenige hochschutzbedrftig, so kann unter Kostengesichtspunkten in
Erwgung gezogen werden, diese wenigen auf ein isoliertes IT-System auszulagern. Eine solche
Alternative kann dem Management zur Entscheidung vorgelegt werden.
Hilfsmittel:
Fr die Durchfhrung der Schutzbedarfsfeststellung wurden als Hilfsmittel Formbltter entwickelt, die
sich auf der CD-ROM zum Handbuch befinden (siehe Anhang: Hilfsmittel).
_________________________________________________________________________________________
_________________________________________________________________________________________
Schutzbedarfsfeststellung fr Kommunikationsverbindungen
Nachdem im vorhergehenden Abschnitt die Schutzbedarfsfeststellung fr die betrachteten IT-Systeme
abgeschlossen wurde, soll nun der Schutzbedarf bezglich der Vernetzungsstruktur erarbeitet werden.
Grundlage fr die weiteren berlegungen ist wiederum der in Kapitel 2.1 erarbeitete Netzplan des zu
untersuchenden IT-Verbunds.
Um die Entscheidungen vorzubereiten, auf welchen Kommunikationsstrecken kryptographische
Sicherheitsmanahmen eingesetzt werden sollten, welche Strecken redundant ausgelegt sein sollten
und ber welche Verbindungen Angriffe durch Innen- und Auentter zu erwarten sind, mssen nach
den IT-Systemen die Kommunikationsverbindungen betrachtet werden. Hierbei werden folgende
Kommunikationsverbindungen als kritisch gewertet:
- Kommunikationsverbindungen, die Auenverbindungen darstellen, d. h. die in oder ber
unkontrollierte Bereiche fhren (z. B. ins Internet oder ber ffentliches Gelnde). Hier besteht die
Gefahr, dass von auen Penetrationsversuche auf das zu schtzende System vorgenommen oder
dass Computer-Viren bzw. trojanische Pferde eingespielt werden. Darber hinaus kann auch ein
Innentter ber eine solche Verbindung vertrauliche Informationen nach auen bertragen.
- Kommunikationsverbindungen, ber die hochschutzbedrftige Informationen bertragen werden,
wobei dies sowohl Informationen mit einem hohen Anspruch an Vertraulichkeit wie auch Integritt
oder Verfgbarkeit sein knnen. Diese Verbindungen knnen das Angriffsziel vorstzlichen
Abhrens oder vorstzlicher Manipulation sein. Darber hinaus kann der Ausfall einer solchen
Verbindung die Funktionsfhigkeit wesentlicher Teile des IT-Verbundes beeintrchtigen.
- Kommunikationsverbindungen, ber die bestimmte hochschutzbedrftige Informationen nicht
bertragen werden drfen. Hierbei kommen insbesondere vertrauliche Informationen in Betracht.
Falls Netzkoppelelemente ungeeignet oder falsch konfiguriert sind, kann der Fall eintreten, dass
ber eine solche Verbindung die Informationen, die gerade nicht bertragen werden sollen, trotz-
dem bertragen und damit angreifbar werden.
Bei der Erfassung der kritischen Kommunikationsverbindungen kann wie folgt vorgegangen werden.
Zunchst werden smtliche "Auenverbindungen" als kritische Verbindungen identifiziert und erfasst.
Anschlieend untersucht man smtliche Verbindungen, die von einem IT-System mit hohem oder sehr
hohem Schutzbedarf ausgehen. Dabei werden diejenigen Verbindungen identifiziert, ber die hoch-
schutzbedrftige Informationen bertragen werden. Danach untersucht man die Verbindungen, ber
die diese hochschutzbedrftigen Daten weiterbertragen werden. Abschlieend sind die Kommuni-
kationsverbindungen zu identifizieren, ber die derlei Informationen nicht bertragen werden drfen.
Zu erfassen sind dabei:
- die Verbindungsstrecke,
- ob es sich um eine Auenverbindung handelt,
- ob hochschutzbedrftige Informationen bertragen werden und ob der Schutzbedarf aus der
Vertraulichkeit, Integritt oder Verfgbarkeit resultiert und
- ob hochschutzbedrftige Informationen nicht bertragen werden drfen.
Sinnvollerweise knnen die dabei erfassten Daten tabellarisch dokumentiert oder graphisch im Netz-
plan hervorgehoben werden.
_________________________________________________________________________________________
_________________________________________________________________________________________

Fr das fiktive Beispiel BOV ergeben sich folgende kritischen Verbindungen:
In der graphischen Darstellung sind die kritischen Verbindungen durch "fette" Linien markiert. Die
Zahlen neben den Linien kennzeichnen den Grund (bzw. die Grnde), warum die jeweilige Verbin-
dung kritisch ist, und sind in den Spaltenkpfen der nachfolgenden Tabelle erlutert.
Kritisch aufgrund
1 2 3 4 5
Verbindung Auen- hohe Ver- hohe hohe Ver- keine
verbindung traulichkeit Integritt fgbarkeit bertragung
N1 - Internet X
N5 - N6 X
S1 - N4 X
S3 - N3 X
S4 - N3 X
S5 - N3 X
C1 - N4 X
N1 - N2 X X
N2 - N3 X
N4 - N3 X
_________________________________________________________________________________________
_________________________________________________________________________________________
Besonderer Wert sollte bei dieser Erhebung darauf gelegt werden, dass die erstellte bersicht voll-
stndig ist. Nur eine bersehene kritische Verbindung kann die Gesamtsicherheit unterlaufen. So
sollten zum Beispiel alle eingesetzten Modems erfasst sein, da von ihnen potentiell kritische Verbin-
dungen nach auen ausgehen knnen. Oftmals jedoch werden diese Modem-Auenverbindungen als
Prestige-Objekte betrachtet, deren Existenz geleugnet wird, um sich einen persnlichen Vorteil zu ver-
schaffen. Oder Modems werden als Verbrauchsmaterial beschafft und eingestuft, ohne dass IT-
Verantwortliche ber deren Einsatzzweck informiert sind. Im Sinne einer vollstndigen IT-Sicherheit
drfen derlei kritische Gerte und Verbindungen jedoch nicht bergangen werden.
Schutzbedarfsfeststellung fr IT-Rume
Fr die weitere Vorgehensweise der Modellierung nach IT-Grundschutz und fr die Planung des Soll-
Ist-Vergleichs ist es hilfreich, eine bersicht ber die Rume zu erstellen, in denen IT-Systeme
aufgestellt oder die fr den IT-Betrieb genutzt werden. Dazu gehren Rume, die ausschlielich dem
IT-Betrieb dienen (wie Serverrume, Datentrgerarchive), oder solche, in denen unter anderem IT-
Systeme betrieben werden (wie Brorume). Wenn IT-System statt in einem speziellen Technikraum
in einem Schutzschrank untergebracht sind, ist der Schutzschrank wie ein Raum zu erfassen.
Hinweis: Bei der Erfassung der IT-Systeme sind schon die Aufstellungsorte miterfasst worden.
Anschlieend sollte aus den Ergebnissen der Schutzbedarfsfeststellung der IT-Systeme abgeleitet
werden, welcher Schutzbedarf fr die jeweiligen Rume resultiert. Dieser Schutzbedarf leitet sich aus
dem Schutzbedarf der im Raum installierten IT-Systeme oder beherbergten Datentrger nach dem
Maximum-Prinzip ab. Dabei sollte zustzlich ein mglicher Kumulationseffekt bercksichtigt werden,
wenn sich in einem Raum eine grere Anzahl von IT-Systemen befindet, wie typischerweise bei
Serverrumen. Zustzlich sollte eine Begrndung der Schutzbedarfseinschtzung dokumentiert
werden.
Hilfreich ist auch hier eine tabellarische Erfassung der notwendigen Informationen.
Ein Auszug aus dem Ergebnis fr das BOV ist folgende Tabelle:
Raum IT Schutzbedarf
Bezeich- Art Lokation IT-Systeme / Datentrger Vertrau- Integrit Verfg-
nung lichkeit t barkeit
R U.02 Datentrger-archiv Gebude Bonn Backup-Datentrger hoch hoch mittel
(Wochen-sicherung der
Server S1 bis S5)
R B.02 Technikraum Gebude Bonn TK-Anlage mittel mittel hoch
R 1.01 Serverraum Gebude Bonn S1, N4 hoch hoch mittel
R 1.02 - R Brorume Gebude Bonn C1 hoch mittel mittel
1.06
R 3.11 Schutzschrank im Gebude Bonn Backup-Datentrger hoch hoch mittel
Raum R 3.11 (Tagessicherung der
Server S1 bis S5)
R E.03 Serverraum Gebude Berlin S6, N6, N7 mittel hoch hoch
R 2.01 - R Brorume Gebude Berlin C4, einige mit Faxgerten mittel mittel mittel
2.40
_________________________________________________________________________________________
_________________________________________________________________________________________
Interpretation der Ergebnisse der Schutzbedarfsfeststellung

Die bei der Schutzbedarfsfeststellung erzielten Ergebnisse bieten einen Anhaltspunkt fr die weitere
Vorgehensweise der IT-Sicherheitskonzeption. Fr den Schutz, der von den in diesem Handbuch
empfohlenen Standard-Sicherheitsmanahmen ausgeht, wird bezglich der Schutzbedarfskategorien
folgendes angenommen:
Schutzwirkung von Standard-Sicherheitsmanahmen nach IT-Grundschutz

Schutzbedarfskategorie "niedrig bis mittel" Standard-Sicherheitsmanahmen nach IT-Grundschutz
sind im Allgemeinen ausreichend und angemessen.
Schutzbedarfskategorie "hoch" Standard-Sicherheitsmanahmen nach IT-Grundschutz
bilden einen Basisschutz, sind aber unter Umstnden
alleine nicht ausreichend. Weitergehende Manahmen
knnen auf Basis einer ergnzenden Sicherheitsanalyse
ermittelt werden.
Schutzbedarfskategorie "sehr hoch" Standard-Sicherheitsmanahmen nach IT-Grundschutz
bilden einen Basisschutz, reichen aber alleine i. A.
nicht aus. Die erforderlichen zustzlichen Sicherheits-
manahmen mssen individuell auf der Grundlage
einer ergnzenden Sicherheitsanalyse ermittelt werden.
Wird der Schutzbedarf fr ein IT-System als "mittel" definiert, so reicht es aus, die Standard-
manahmen nach IT-Grundschutz pauschal umzusetzen. Fr IT-Systeme, Netzverbindungen und
Rume mit IT-Nutzung mit "hohem" und besonders mit "sehr hohem" Schutzbedarf sollte eine
ergnzende Sicherheitsanalyse eingeplant werden. Ebenso sollte bei diesen Komponenten im Soll-Ist-
Vergleich der hohe Schutzbedarf bei der Bearbeitung von als "optional" gekennzeichneten Manah-
men bercksichtigt werden. So kann beispielsweise die Manahme M 1.10 Verwendung von Sicher-
heitstren in einem Serverraum mit mittlerem Schutzbedarf nicht notwendig, bei hohem Schutzbedarf
an Vertraulichkeit aber dringend erforderlich sein.
_________________________________________________________________________________________
Modellierung nach IT-Grundschutz 2.3
_________________________________________________________________________________________
2.3 Modellierung nach IT-

Grundschutz
Nachdem die notwendigen Informationen aus der IT-
Strukturanalyse und der Schutzbedarfsfeststellung
vorliegen, besteht die nchste zentrale Aufgabe darin, den
betrachteten IT-Verbund mit Hilfe der vorhandenen
Bausteine des IT-Grundschutzhandbuchs nachzubilden.
Als Ergebnis wird ein IT-Grundschutzmodell des IT-
Verbunds erstellt, das aus verschiedenen, ggf. auch
mehrfach verwendeten Bausteinen des Handbuchs
besteht und eine Abbildung zwischen den Bausteinen und
den sicherheitsrelevanten Aspekten des IT-Verbunds
beinhaltet.
Das erstellte IT-Grundschutzmodell ist unabhngig davon, ob der IT-Verbund aus bereits im Einsatz
befindlichen IT-Systemen besteht oder ob es sich um einen IT-Verbund handelt, der sich erst im Pla-
nungsstadium befindet. Jedoch kann das Modell unterschiedlich verwendet werden:
- Das IT-Grundschutzmodell eines bereits realisierten IT-Verbunds identifiziert ber die verwen-
deten Bausteine die relevanten Standard-Sicherheitsmanahmen. Es kann in Form eines Prfplans
benutzt werden, um einen Soll-Ist-Vergleich durchzufhren.
- Das IT-Grundschutzmodell eines geplanten IT-Verbunds stellt hingegen ein Entwicklungskonzept
dar. Es beschreibt ber die ausgewhlten Bausteine, welche Standard-Sicherheitsmanahmen bei
der Realisierung des IT-Verbunds umgesetzt werden mssen.
Die Einordnung der Modellierung und die mglichen Ergebnisse verdeutlicht das folgende Bild:
Bild: Ergebnis der Modellierung nach IT-Grundschutz

Typischerweise wird ein im Einsatz befindlicher IT-Verbund sowohl realisierte als auch in Planung
befindliche Anteile besitzen. Das resultierende IT-Grundschutzmodell beinhaltet dann sowohl einen
Prfplan wie auch Anteile eines Entwicklungskonzepts. Die IT-Sicherheitsmanahmen, die bei Durch-
fhrung des Soll-Ist-Vergleichs als unzureichend oder fehlend identifiziert werden, und diejenigen, die
sich fr die in Planung befindlichen Anteile des IT-Verbunds ergeben, bilden dann gemeinsam die
Basis fr die Erstellung des IT-Sicherheitskonzepts.
_________________________________________________________________________________________
_________________________________________________________________________________________
Fr die Abbildung eines im Allgemeinen komplexen IT-Verbunds auf die Bausteine des Handbuchs
bietet es sich an, die IT-Sicherheitsaspekte gruppiert nach bestimmten Themen zu betrachten.
Bild: Schichten des IT-Grundschutzmodells

Die IT-Sicherheitsaspekte eines IT-Verbunds werden wie folgt den einzelnen Schichten zugeordnet:
- Schicht 1 umfasst smtliche bergreifenden IT-Sicherheitsaspekte, die fr smtliche oder groe
Teile des IT-Verbunds gleichermaen gelten. Dies betrifft insbesondere bergreifende Konzepte
und die daraus abgeleiteten Regelungen. Typische Bausteine der Schicht 1 sind unter anderem IT-
Sicherheitsmanagement, Organisation, Datensicherungskonzept und Computer-Virenschutzkon-
zept.
- Schicht 2 befasst sich mit den baulich-technischen Gegebenheiten, in der Aspekte der infrastruktu-
rellen Sicherheit zusammengefhrt werden. Dies betrifft insbesondere die Bausteine Gebude,
Rume, Schutzschrnke und huslicher Arbeitsplatz.
- Schicht 3 betrifft die einzelnen IT-Systeme des IT-Verbunds, die ggf. in Gruppen zusammengefasst
wurden. Hier werden die IT-Sicherheitsaspekte sowohl von Clients als auch von Servern, aber auch
von Stand-alone-Systemen behandelt. In die Schicht 3 fallen damit beispielsweise die Bausteine
Unix-System, Tragbarer PC, Windows NT Netz und TK-Anlage.
- Schicht 4 betrachtet die Vernetzungsaspekte der IT-Systeme, die sich nicht auf bestimmte IT-Sys-
teme, sondern auf die Netzverbindungen und die Kommunikation beziehen. Dazu gehren zum
Beispiel die Bausteine Heterogene Netze, Netz- und Systemmanagement und Firewall.
- Schicht 5 schlielich beschftigt sich mit den eigentlichen IT-Anwendungen, die im IT-Verbund
genutzt werden. In dieser Schicht knnen unter anderem die Bausteine E-Mail, WWW-Server,
Faxserver und Datenbanken zur Modellierung verwendet werden.
Die Einteilung in diese Schichten hat folgende Vorteile:
- Die Komplexitt der IT-Sicherheit wird reduziert, indem eine sinnvolle Aufteilung der Einzelas-
pekte vorgenommen wird.
- Da bergeordnete Aspekte und gemeinsame infrastrukturelle Fragestellungen getrennt von den IT-
Systemen betrachtet werden, werden Redundanzen vermieden, weil diese Aspekte nur einmal be-
arbeitet werden mssen und nicht wiederholt fr jedes IT-System.
- Die einzelnen Schichten sind so gewhlt, dass auch die Zustndigkeiten fr die betrachteten As-
pekte gebndelt sind. Schicht 1 betrifft Grundsatzfragen des IT-Einsatzes, Schicht 2 den Bereich
Haustechnik, Schicht 3 die Ebene der Administratoren und IT-Nutzer, Schicht 4 die Netz- und
Systemadministratoren und Schicht 5 schlielich die IT-Anwendungsverantwortlichen und
-betreiber.
_________________________________________________________________________________________
_________________________________________________________________________________________
- Aufgrund der Aufteilung der Sicherheitsaspekte in Schichten knnen Einzelaspekte in resultieren-

den IT-Sicherheitskonzepten leichter aktualisiert und erweitert werden, ohne dass andere Schichten
umfangreich tangiert werden.
Die Modellierung nach IT-Grundschutz besteht nun daraus, fr die Bausteine einer jeden Schicht zu
entscheiden, ob und wie sie zur Abbildung des IT-Verbunds herangezogen werden knnen. Je nach
betrachtetem Baustein knnen die Zielobjekte dieser Abbildung von unterschiedlicher Art sein: ein-
zelne Komponenten, Gruppen von Komponenten, Gebude, Liegenschaften, Organisationseinheiten,
usw.
Das IT-Grundschutzmodell, also die Zuordnung von Bausteinen zu Zielobjekten sollte in Form einer
Tabelle mit folgenden Spalten dokumentiert werden:
- Nummer und Titel des Bausteins
- Zielobjekt oder Zielgruppe: Dies kann z. B. die Identifikationsnummer einer Komponente oder
einer Gruppe bzw. der Name eines Gebudes oder einer Organisationseinheit sein.
- Ansprechpartner: Diese Spalte dient zunchst nur als Platzhalter. Der Ansprechpartner wird nicht
im Rahmen der Modellierung, sondern erst bei der Planung des eigentlichen Soll-Ist-Vergleichs im
Basis-Sicherheitscheck ermittelt.
- Hinweise: In dieser Spalte knnen Randinformationen und Begrndungen fr die Modellierung
dokumentiert werden.
Nachfolgend wird in Kapitel 2.3.1 die Vorgehensweise der Modellierung fr einen IT-Verbund detail-
liert beschrieben. Dabei wird besonderer Wert auf die Randbedingungen gelegt, wann ein einzelner
Baustein sinnvollerweise eingesetzt werden soll und auf welche Zielobjekte er anzuwenden ist.
In Kapitel 2.3.2 werden einige Hinweise fr den Fall beschrieben, dass IT-Komponenten vorhanden
sind, zu denen es keine Bausteine oder Manahmen im IT-Grundschutzhandbuch gibt. Dies knnen
z. B. neue Betriebssysteme, Proxy-Server, PKI oder drahtlose Netze sein.
2.3.1 Modellierung eines IT-Verbunds

Bei der Modellierung eines IT-Verbunds ist es zweckmig, die Zuordnung der Bausteine anhand des
Schichtenmodells vorzunehmen. Daran anschlieend folgt schlielich die Vollstndigkeitsprfung.
zu Schicht 1: bergeordnete Aspekte der IT-Sicherheit
In dieser Schicht werden alle Aspekte des IT-Verbunds modelliert, die den technischen Komponenten
bergeordnet sind. Im Vordergrund stehen dabei Konzepte und die von diesen Konzepten abgeleiteten
Regelungen. Diese Aspekte sollten fr den gesamten IT-Verbund einheitlich geregelt sein, so dass die
entsprechenden Bausteine in den meisten Fllen nur einmal fr den gesamten IT-Verbund anzuwenden
sind. Dem IT-Sicherheitsmanagement, der Organisation des IT-Betriebs sowie der Schulung und Sen-
sibilisierung des Personals kommt dabei eine besondere Bedeutung zu. Die Umsetzung der diesbezg-
lichen Manahmen ist von grundlegender Bedeutung fr die sichere Nutzung von Informations- und
Kommunikationstechnik. Unabhngig von den eingesetzten technischen Komponenten sind die ent-
sprechenden Bausteine daher immer anzuwenden.
- Der Baustein 3.0 IT-Sicherheitsmanagement ist fr den gesamten IT-Verbund einmal anzuwen-
den. Ein funktionierendes IT-Sicherheitsmanagement ist die wesentliche Grundlage fr die Errei-
chung eines angemessenen Sicherheitsniveaus. Im Fall von Outsourcing muss der Baustein auch
auf den Outsourcing-Dienstleister angewendet werden, wenn sich wesentliche Teile des IT-Ver-
_________________________________________________________________________________________
_________________________________________________________________________________________
bunds unter seiner Kontrolle befinden oder der Schutzbedarf der ausgelagerten Komponenten hoch
ist.
- Der Baustein 3.1 Organisation muss fr jeden IT-Verbund mindestens einmal herangezogen wer-
den. Wenn Teile des vorliegenden IT-Verbunds einer anderen Organisationseinheit zugeordnet sind
und daher anderen Rahmenbedingungen unterliegen, sollte er auf jede Organisationseinheit ge-
trennt angewandt werden. Ein wichtiger Spezialfall dessen liegt vor, wenn Teile des IT-Verbunds
im Outsourcing betrieben werden.
- Der Baustein 3.2 Personal muss fr jeden IT-Verbund mindestens einmal herangezogen werden.
Wenn Teile des vorliegenden IT-Verbunds einer anderen Organisation(-seinheit) zugeordnet sind
und daher anderen Rahmenbedingungen unterliegen, sollten er auf jede Organisation(-seinheit) ge-
trennt angewandt werden. Ein wichtiger Spezialfall ist hier, dass Teile des IT-Verbunds im Out-
sourcing betrieben werden.
- Der Baustein 3.3 Notfallvorsorge-Konzept ist zumindest dann anzuwenden, wenn in der Schutz-
bedarfsfeststellung Komponenten identifiziert wurden, die einen hohen oder sehr hohen Schutzbe-
darf in Bezug auf Verfgbarkeit haben oder wenn grere IT-Systeme bzw. umfangreiche Netze
betrieben werden. Bei der Bearbeitung des Bausteins ist besonderes Augenmerk auf diese Kompo-
nenten zu richten.
- Der Baustein 3.4 Datensicherungskonzept ist fr den gesamten IT-Verbund einmal anzuwenden.
- Der Baustein 3.6 Computer-Virenschutzkonzept ist fr den gesamten IT-Verbund einmal anzu-
wenden, soweit im betrachteten IT-Verbund Systeme enthalten sind, die von Computer-Viren be-
fallen werden knnen.
- Der Baustein 3.7 Kryptokonzept ist zumindest dann anzuwenden, wenn in der Schutzbedarfsfest-
stellung Komponenten identifiziert wurden, die einen hohen oder sehr hohen Schutzbedarf in Be-
zug auf Vertraulichkeit oder Integritt haben, oder wenn bereits kryptographische Verfahren im
Einsatz sind.
- Der Baustein 3.8 Behandlung von Sicherheitsvorfllen ist zumindest dann anzuwenden, wenn in
der Schutzbedarfsfeststellung Komponenten identifiziert wurden, die einen hohen oder sehr hohen
Schutzbedarf in Bezug auf einen der drei Grundwerte haben, oder wenn der Ausfall des gesamten
IT-Verbunds einen Schaden in den Kategorien hoch oder sehr hoch zur Folge hat.
- Der Baustein 3.9 Hard- und Software-Management muss fr jeden IT-Verbund mindestens ein-
mal herangezogen werden. Wenn Teile des vorliegenden IT-Verbunds einer anderen Organisati-
onseinheit zugeordnet sind und daher anderen Rahmenbedingungen unterliegen, sollte er auf jede
Organisationseinheit getrennt angewandt werden. Ein wichtiger Spezialfall dessen liegt vor, wenn
Teile des IT-Verbunds im Outsourcing betrieben werden.
- Der Baustein 3.10 Outsourcing ist immer dann anzuwenden, wenn IT-Systeme, Anwendungen
oder Geschftsprozesse zu einem externen Dienstleister ausgelagert werden. Gibt es in einem IT-
Verbund verschiedene ausgelagerte Komponenten bei unterschiedlichen Dienstleistern, ist der Bau-
stein fr jeden externen Dienstleister einmal anzuwenden.
- Der Baustein 9.1 Standardsoftware sollte zumindest einmal fr den gesamten IT-Verbund ange-
wandt werden. Gibt es innerhalb des IT-Verbunds Teilbereiche mit unterschiedlichen Anforderun-
gen oder Regelungen fr die Nutzung von Standardsoftware, sollte Baustein 9.1 auf diese Teilbe-
reiche jeweils getrennt angewandt werden.
- Der Baustein 9.5 Archivierung ist auf den IT-Verbund anzuwenden, wenn aufgrund interner oder
externer Vorgaben eine Langzeitarchivierung elektronischer Dokumente erforderlich ist oder be-
reits ein System zur Langzeitarchivierung elektronischer Dokumente betrieben wird.
_________________________________________________________________________________________
_________________________________________________________________________________________
zu Schicht 2: Sicherheit der Infrastruktur

Die fr den vorliegenden IT-Verbund relevanten baulichen Gegebenheiten werden mit Hilfe der Bau-
steine aus Kapitel 4 Infrastruktur modelliert. Jedem Gebude, Raum oder Schutzschrank (bzw. Grup-
pen dieser Komponenten) wird dabei der entsprechende Baustein aus dem IT-Grundschutzhandbuch
zugeordnet.
- Der Baustein 4.1 Gebude ist fr jedes Gebude bzw. jede Gebudegruppe einmal anzuwenden.
- Der Baustein 4.2 Verkabelung ist in der Regel einmal pro Gebude bzw. Gebudegruppe
anzuwenden (zustzlich zum Baustein 4.1). Falls bestimmte Teilbereiche - beispielsweise Server-
raum oder Leitstand - in Bezug auf die Verkabelung Besonderheiten aufweisen, kann es jedoch
zweckmig sein, den Baustein 4.2 an diesen Stellen gesondert anzuwenden.
- Der Baustein 4.3.1 Broraum ist auf jeden Raum bzw. jede Gruppe von Rumen anzuwenden, in
denen Informationstechnik genutzt wird, fr die jedoch keiner der Bausteine 4.3.2, 4.3.3 oder 4.3.4
herangezogen wird.
- Der Baustein 4.3.2 Serverraum ist auf jeden Raum bzw. jede Gruppe von Rumen anzuwenden, in
denen Server oder TK-Anlagen betrieben werden. Server sind IT-Systeme, die Dienste im Netz zur
Verfgung stellen.
- Der Baustein 4.3.3 Datentrgerarchiv ist auf jeden Raum bzw. jede Gruppe von Rumen
anzuwenden, in denen Datentrger gelagert oder archiviert werden.
- Der Baustein 4.3.4 Raum fr technische Infrastruktur ist auf jeden Raum bzw. jede Gruppe von
Rumen anzuwenden, in denen technische Gerte betrieben werden, die keine oder nur wenig Be-
dienung erfordern (z. B. Verteilerschrank, Netzersatzanlage).
- Der Baustein 4.4 ist auf jeden Schutzschrank bzw. jede Gruppe von Schutzschrnken einmal
anzuwenden. Schutzschrnke knnen ggf. als Ersatz fr einen dedizierten Serverraum dienen.
- Der Baustein 4.5 ist auf jeden huslichen Arbeitsplatz bzw. jede Gruppe (falls entsprechende
Gruppen definiert wurden) einmal anzuwenden.
- Der Baustein 4.6 ist auf jedes Rechenzentrum einmal anzuwenden. Als Rechenzentrum werden
die fr den Betrieb einer greren, zentral fr mehrere Stellen eingesetzten Datenverarbeitungsan-
lage erforderlichen Einrichtungen und Rumlichkeiten bezeichnet.
zu Schicht 3: Sicherheit der IT-Systeme
Sicherheitsaspekte, die sich auf IT-Systeme, d. h. auf Server- und Client-Computer, Hosts, Terminals,
etc. beziehen, werden in dieser Schicht abgedeckt. Hierzu werden Bausteine aus den Kapiteln 5 bis 9
des IT-Grundschutzhandbuchs herangezogen.
Analog zum Bereich "Sicherheit der Infrastruktur" knnen die Bausteine des Bereichs "Sicherheit der
IT-Systeme" sowohl auf einzelne IT-Systeme als auch auf Gruppen solcher IT-Systeme angewandt
werden. Dies wird im Folgenden nicht mehr gesondert hervorgehoben.
- Der Baustein 5.1 DOS-PC (ein Benutzer) ist auf jeden Stand-alone-Rechner oder Client anzuwen-
den, auf dem das Betriebssystem DOS installiert ist.
- Der Baustein 5.2 Unix-System ist auf jeden Stand-alone-Rechner oder Client anzuwenden, der mit
diesem Betriebssystem arbeitet.
- Der Baustein 5.3 Tragbarer PC ist auf jeden mobilen Computer (Laptop) anzuwenden.
- Der Baustein 5.4 PCs mit wechselnden Benutzern ist auf jeden Stand-alone-Rechner oder Client
anzuwenden, an dem mehrere Benutzer abwechselnd arbeiten.
_________________________________________________________________________________________
_________________________________________________________________________________________
Hinweis: Die Anwendung von Baustein 5.4 kann bei IT-Systemen, die mit Hilfe von Baustein 5.5,
5.6, 5.7, 5.8 oder 5.99 modelliert werden, entfallen. In diesen Bausteinen werden Sicherheitsas-
pekte bei wechselnden Benutzern explizit behandelt.
- Der Baustein 5.5 PC unter Windows NT ist auf jeden Stand-alone-Rechner oder Client anzuwen-
den, der mit diesem Betriebssystem arbeitet.
- Der Baustein 5.6 PC mit Windows 95 ist auf jeden Stand-alone-Rechner oder Client anzuwenden,
der mit diesem Betriebssystem arbeitet.
- Der Baustein 5.7 Windows 2000 Client ist auf jeden Stand-alone-Rechner oder Client anzuwen-
den, der mit diesem Betriebssystem arbeitet.
- Der Baustein 5.8 Internet-PC ist auf jeden Computer anzuwenden, der ausschlielich fr die Nut-
zung von Internet-Diensten vorgesehen ist und nicht mit dem internen Netz der Institution verbun-
den ist. In diesem speziellen Szenario brauchen keine weiteren Bausteine des IT-Grundschutzhand-
buchs auf diesen Computer (bzw. diese Gruppe) angewandt werden.
- Der Baustein 5.99 Allgemeines nicht vernetztes IT-System ist auf jedes IT-System anzuwenden,
fr das kein Betriebssystem-spezifischer Baustein im IT-Grundschutzhandbuch enthalten ist.
- Der Baustein 6.1 Servergesttztes Netz ist auf jedes IT-System anzuwenden, das Dienste (z. B.
Datei- oder Druckdienste) als Server im Netz anbietet.
- Der Baustein 6.2 Unix-Server ist auf jeden Server anzuwenden, der mit diesem Betriebssystem
arbeitet.
- Der Baustein 6.3 Peer-to-Peer-Netz ist auf jeden Client anzuwenden, der Peer-to-Peer-Dienste
(beispielsweise freigegebene Verzeichnisse) im Netz anbietet.
- Der Baustein 6.4 Windows NT Netz ist auf jeden Server anzuwenden, der mit diesem Betriebs-
system arbeitet.
- Der Baustein 6.5 Novell Netware 3.x ist auf jeden Server anzuwenden, der mit diesem Betriebs-
system arbeitet.
- Der Baustein 6.6 Novell Netware 4.x ist auf jeden Server anzuwenden, der mit diesem Betriebs-
system arbeitet.
- Der Baustein 6.9 Windows 2000 Server ist auf jeden Server anzuwenden, der mit diesem Betriebs-
system arbeitet.
- Der Baustein 6.10 s/390- und zSeries-Mainframe ist auf jedem Server anzuwenden, der mit
diesem Betriebssystem arbeitet
Hinweis: Fr jeden Server muss neben dem Betriebssystem-spezifischen Baustein immer auch
Baustein 6.1 angewandt werden, da in diesem Baustein die plattformunabhngigen Sicherheitsas-
pekte fr Server zusammengefasst sind.
- Der Baustein 8.1 ist auf jede TK-Anlage bzw. auf jede entsprechende Gruppe anzuwenden.
- Der Baustein 8.2 ist auf jedes Faxgert bzw. auf jede entsprechende Gruppe anzuwenden.
- Der Baustein 8.3 ist auf jeden Anrufbeantworter bzw. auf jede entsprechende Gruppe anzuwen-
den.
- Der Baustein 8.6 Mobiltelefon sollte mindestens einmal angewandt werden, wenn die Benutzung
von Mobiltelefonen in der betrachteten Organisation(-seinheit) nicht grundstzlich untersagt ist.
_________________________________________________________________________________________
_________________________________________________________________________________________
Bestehen mehrere unterschiedliche Einsatzbereiche von Mobiltelefonen (beispielsweise mehrere

Mobiltelefon-Pools), so ist der Baustein 7.6 jeweils getrennt darauf anzuwenden.
- Der Baustein 8.7 PDA sollte mindestens einmal angewandt werden, wenn die Benutzung von
PDAs in der betrachteten Organisation(-seinheit) nicht grundstzlich untersagt ist.
- Der Baustein 9.3 Telearbeit ist zustzlich auf jedes IT-System anzuwenden, das fr Telearbeit
verwendet wird.
zu Schicht 4: Sicherheit im Netz
In dieser Schicht werden Sicherheitsaspekte im Netz behandelt, die nicht an bestimmten IT-Systemen
(z. B. Servern) festgemacht werden knnen. Vielmehr geht es um Sicherheitsaspekte, die sich auf die
Netzverbindungen und die Kommunikation zwischen den IT-Systemen beziehen.
Um die Komplexitt zu verringern, ist es sinnvoll, bei der Untersuchung statt des Gesamtnetzes Teil-
bereiche jeweils einzeln zu betrachten. Die hierzu erforderliche Aufteilung des Gesamtnetzes in Teil-
netze sollte anhand der beiden folgenden Kriterien vorgenommen werden:
- Im Rahmen der Schutzbedarfsfeststellung sind Verbindungen identifiziert worden, ber die be-
stimmte Daten auf keinen Fall transportiert werden drfen. Diese Verbindungen bieten sich als
"Schnittstellen" zwischen Teilnetzen an, d. h. die Endpunkte einer solchen Verbindung sollten in
verschiedenen Teilnetzen liegen. Umgekehrt sollten Verbindungen, die Daten mit hohem oder sehr
hohem Schutzbedarf transportieren, mglichst keine Teilnetzgrenzen berschreiten. Dies fhrt zu
einer Definition von Teilnetzen mit mglichst einheitlichem Schutzbedarf.
- Komponenten, die nur ber eine Weitverkehrsverbindung miteinander verbunden sind, sollten nicht
demselben Teilnetz zugeordnet werden, d. h. Teilnetze sollten sich nicht ber mehrere Standorte
oder Liegenschaften erstrecken. Dies ist sowohl aus Grnden der bersichtlichkeit als auch im
Hinblick auf eine effiziente Projektdurchfhrung wnschenswert.
Falls diese beiden Kriterien nicht zu einer geeigneten Aufteilung des Gesamtnetzes fhren (beispiels-
weise weil einige resultierende Teilnetze zu gro oder zu klein sind), kann die Aufteilung in Teilnetze
alternativ auch auf organisatorischer Ebene erfolgen. Dabei werden die Zustndigkeitsbereiche der
einzelnen Administratoren(-Teams) als Teilnetze betrachtet.
Es ist nicht mglich, eine grundstzliche Empfehlung darber zu geben, welche Aufteilung in Teil-
netze zu bevorzugen ist, falls die oben angegebenen Anforderungen mit dem vorliegenden IT-Verbund
grundstzlich nicht vereinbar sind. Stattdessen sollte im Einzelfall entschieden werden, welche Auftei-
lung des Gesamtnetzes im Hinblick auf die anzuwendenden Bausteine des IT-Grundschutzhandbuchs
am praktikabelsten ist.
- Der Baustein 6.7 Heterogene Netze ist in der Regel auf jedes Teilnetz einmal anzuwenden. Falls
die Teilnetze klein sind und mehrere Teilnetze in der Zustndigkeit des gleichen Administratoren-
Teams liegen, kann es jedoch ausreichend sein, den Baustein 6.7 auf diese Teilnetze insgesamt
einmal anzuwenden.
- Der Baustein 6.8 Netz- und Systemmanagement ist auf jedes Netz- bzw. Systemmanagement-
System, das im vorliegenden IT-Verbund eingesetzt wird, anzuwenden.
- Der Baustein 7.2 Modem ist auf jedes mit einem Modem ausgestattete IT-System bzw. jede
Gruppe solcher IT-Systeme anzuwenden.
- Der Baustein 7.3 Sicherheitsgateway (Firewall) ist fr jede Auenverbindung zu IT-Systemen
oder Netzen Dritter anzuwenden, wenn ber diese Auenverbindung hochschutzbedrftige IT-
Systeme im internen Netz erreicht werden knnen. Dies gilt auch, wenn dort noch kein
_________________________________________________________________________________________
_________________________________________________________________________________________
Sicherheitsgateway-System eingesetzt wird. Beispiele sind Internet-Anbindungen, Remote Access-

Zugnge und Verbindungen zu Netzen von Geschftspartnern.
- Der Baustein 7.6 Remote Access ist pro entfernter Zugriffsmglichkeit auf das interne Netz, die
nicht ber eine dedizierte Standleitung erfolgt, einmal anzuwenden (z. B. Telearbeit, Anbindung
von Auendienstmitarbeitern ber analoge Whlleitungen, ISDN oder Mobiltelefon).
- Der Baustein 7.11 Router und Switches ist in jedem aktiven Netz, das im vorliegenden IT-
Verbund eingesetzt wird, anzuwenden.
- Der Baustein 8.4 LAN-Anbindung eines IT-Systems ber ISDN ist auf alle Auenverbindungen
anzuwenden, die ber ISDN realisiert sind.
zu Schicht 5: Sicherheit in Anwendungen
In der untersten Schicht des zu modellierenden IT-Verbunds erfolgt die Nachbildung der Anwendun-
gen. Moderne Anwendungen beschrnken sich nur selten auf ein einzelnes IT-System. Insbesondere
behrden- bzw. unternehmensweite Kernanwendungen sind in der Regel als Client-Server-Applikatio-
nen realisiert. In vielen Fllen greifen Server selbst wieder auf andere, nachgeschaltete Server, z. B.
Datenbank-Systeme, zu. Die Sicherheit der Anwendungen muss daher unabhngig von den IT-Syste-
men und Netzen betrachtet werden.
- Der Baustein 7.1 Datentrgeraustausch sollte fr jede Anwendung einmal herangezogen werden,
die als Datenquelle fr einen Datentrgeraustausch dient oder auf diesem Wege eingegangene Da-
ten weiterverarbeitet.
- Der Baustein 7.4 E-Mail ist auf jedes E-Mail-System (intern oder extern) des betrachteten IT-Ver-
bunds anzuwenden.
- Der Baustein 7.5 WWW-Server ist auf jeden WWW-Dienst (z. B. Intranet oder Internet) des be-
trachteten IT-Verbunds anzuwenden.
- Der Baustein 7.7 ist auf jedes Workgroup-System, das auf dem Produkt Lotus Notes basiert, bzw.
auf jede entsprechende Gruppe im IT-Verbund einmal anzuwenden.
- Der Baustein 8.5 ist auf jeden Faxserver bzw. auf jede entsprechende Gruppe anzuwenden.
- Der Baustein 9.2 Datenbanken sollte pro Datenbanksystem bzw. pro Gruppe von Datenbanksyste-
men einmal angewandt werden.
- Der Baustein 9.4 Novell eDirectory sollte auf jeden Verzeichnisdienst, der mit Hilfe von Novell
eDirectory realisiert ist, einmal angewandt werden.
- Der Baustein 7.8 Internet Information Server ist - zustzlich zu Baustein 7.5 - auf jeden WWW-
Dienst anzuwenden, der mit diesem Produkt betrieben wird.
- Der Baustein 7.9 Apache Webserver ist - zustzlich zu Baustein 7.5 - auf jeden WWW-Dienst
anzuwenden, der mit diesem Produkt betrieben wird.
- Der Baustein 7.10 ist - zustzlich zu Baustein 7.4 - auf jedes Workgroup- oder E-Mail-System
anzuwenden, das auf Microsoft Exchange bzw. Outlook basiert.
Prfung auf Vollstndigkeit
Abschlieend sollte berprft werden, ob die Modellierung des Gesamtsystems vollstndig ist und
keine Lcken aufweist. Es wird empfohlen, hierzu erneut den Netzplan oder eine vergleichbare ber-
sicht ber den IT-Verbund heranzuziehen und die einzelnen Komponenten systematisch durchzuge-
hen. Jede Komponente sollte entweder einer Gruppe zugeordnet oder einzeln modelliert worden sein.
_________________________________________________________________________________________
_________________________________________________________________________________________
Falls das Gesamtnetz in der Schicht 4 in Teilnetze aufgeteilt wurde, sollte geprft werden, ob
- jedes Teilnetz vollstndig nachgebildet wurde und
- durch die Summe aller Teilnetze das Gesamtnetz vollstndig dargestellt wird.
Wichtig ist, dass nicht nur alle Hard- und Software-Komponenten in technischer Hinsicht nachgebildet
sind, sondern dass auch die zugehrigen organisatorischen, personellen und infrastrukturellen Aspekte
vollstndig abgedeckt sind. Dies kann anhand der Tabellen in Abschnitt 2.3.2 geprft werden, in de-
nen fr einige typische Komponenten die Bausteine des IT-Grundschutzhandbuchs genannt sind, die
in der Modellierung auf jeden Fall enthalten sein sollten.
Falls sich bei der berprfung Lcken in der Modellierung zeigen, sind die entsprechenden fehlenden
Bausteine hinzuzufgen. Andernfalls besteht die Gefahr, dass wichtige Bestandteile des Gesamtsys-
tems oder wichtige Sicherheitsaspekte bei der Anwendung des IT-Grundschutzhandbuchs nicht be-
rcksichtigt werden.
Fr den Fall, dass die Modellierung nicht vollstndig durchfhrbar ist, weil entsprechende Bausteine
im IT-Grundschutzhandbuch fehlen, wird darum gebeten, den Bedarf an die IT-Grundschutz-Hotline
des BSI weiterzuleiten.
Die folgende Tabelle ist ein Auszug aus der Modellierung fr das fiktive Bundesamt BOV:
Nr. Titel des Bausteins Zielobjekt/ Ansprech- Hinweise
Zielgruppe partner
3.1 Organisation Standort Bonn Der Baustein Organisation muss fr die Standorte Bonn und
Berlin separat bearbeitet werde, da in Berlin eigene organi-
satorische Regelungen gelten.
3.1 Organisation Standort Berlin
3.2 Personal gesamtes BOV Die Personalverwaltung des BOV erfolgt zentral in Bonn.
4.3.3 Datentrgerarchiv R U.02 (Bonn) In diesem Raum werden die Backup-Datentrger aufbewahrt
5.3 Tragbarer PC C5 Die Laptops in Bonn bzw. Berlin werden jeweils in eine
Gruppe zusammengefasst.
5.3 Tragbarer PC C6
7.5 WWW-Server S5 S5 dient als Server fr das Intranet.

9.2 Datenbanken S5 Auf dem Server S5 kommt eine Datenbank zum Einsatz
2.3.2 Modellierung neuer IT-Komponenten

Bei der Modellierung eines IT-Verbunds nach IT-Grundschutz kann das Problem auftreten, dass IT-
Komponenten vorhanden sind, zu denen es keine Bausteine oder Manahmen im IT-Grundschutz-
handbuch gibt. Dies knnen z. B. neue Betriebssysteme, Proxy-Server, PKI oder drahtlose Netze sein.
Falls die Modellierung nicht vollstndig durchfhrbar ist, weil zu bestimmten IT-Systemen, Aspekten
oder Vorgehensweisen im IT-Verbund Bausteine fehlen, dann sollten ersatzweise folgende Schritte
durchgefhrt werden.
- Es sollte zunchst geklrt werden, zu welcher der Schichten 1 bis 5 diese Komponente gehrt.
- Es empfiehlt sich dann, sich an hnlichen Bausteinen orientieren. Solche finden sich fast immer,
z. B. ein hnliches Betriebssystem oder eine vergleichbare Vorgehensweise. Es sollten ein oder
zwei Baustein ausgewhlt werden, die der betrachteten Komponente nahe kommen. Diese sollten
dann sinngem angewendet werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
- Es sollte die Skizze eines neuen Bausteins erstellt werden, in der aufgezeigt wird, in welchen
Schritten weiter vorgegangen wurde. Der Umfang dieses Ersatz-Bausteins sollte in der Beschrei-
bung kurz abgegrenzt werden.
- Es ist zu erarbeiten, welche Gefhrdungen und Manahmen neu hinzukommen oder zu ndern
sind.
- Die wesentlichen Stichworte zu diesen Gefhrdungen und Manahmen sollten kurz im Zusammen-
hang dargestellt werden.
Fr eine IT-Sicherheitsberprfung auf der Basis des IT-Grundschutzhandbuchs (Basis-Sicherheits-
check) gibt es fr jeden Baustein des IT-Grundschutzhandbuchs ein entsprechendes Formblatt. Fr
die fehlende Komponente sollte ein eigenes Erhebungsformular erstellt bzw. in ein IT-
Grundschutz-Tool eingepflegt werden. Hierbei geht es nur um die bertragung der identifizierten
Manahmen in ein Formular bzw. Tool, um einen schnellen Soll-Ist-Vergleich durchfhren zu
knnen.
- Damit sind die wichtigsten Bereiche fr einen fehlenden Baustein erzeugt worden. Dieser muss
dann noch in die Modellierung des betrachteten IT-Verbunds eingebracht werden. Dabei ist es
zweckmig, die Zuordnung des Bausteins anhand des Schichtenmodells vorzunehmen.
- Auerdem ist der ergnzte Baustein bei der Konzeption bzw. Revision eines IT-Sicherheitskon-
zepts entsprechend zu bercksichtigen.
Wenn die in dem neu erstellten Baustein betrachtete Komponente oder Vorgehensweise nicht zu spe-
ziell ist, bietet es sich an, die erarbeiteten Dokumente dem IT-Grundschutz-Team des BSI zur weiteren
Verwendung zur Verfgung zu stellen. Das BSI wird prfen, ob auch andere Anwender von den In-
halten profitieren knnen und den neuen Baustein ggf. ber die blichen Vertriebswege des IT-Grund-
schutzhandbuchs allen Anwendern zur Verfgung stellen.
Beispiele:
1. Grorechner
Ein Grorechner ist sicherlich eine Obermenge eines Servers und ist Schicht 3 des IT-Grundschutz-
Schichtenmodells zuzuordnen. Daher sollte Baustein 6.1 Servergesttztes Netz betrachtet werden.
Darber hinaus mssen eventuell zustzliche Manahmen umgesetzt sein, die nicht im IT-Grund-
schutzhandbuch beschrieben sind. Es gibt sehr viele Quellen zu spezifischen Sicherheitsmanahmen,
die hierzu herangezogen werden knnen und sollten. Es ist sinnvoll, sich zunchst beim Hersteller
bzw. Vertreiber des Betriebssystems zu informieren, welche Dokumente dort zur Sicherheit des IT-
Systems vorhanden sind bzw. welche Literatur diese empfehlen knnen.
2. PDA
hnliche Themenbereiche wie der Einsatz von PDAs oder Organizern in Behrden oder Unternehmen
finden sich in den Bausteinen 5.3 Tragbarer PC und 8.6 Mobiltelefon. Diese sollten daher als Grund-
lage fr die Erarbeitung eines Bausteins zum Thema PDA verwendet und ergnzt werden. Der neue
Baustein ist Schicht 3 des IT-Grundschutz-Schichtenmodells zuzuordnen.
_________________________________________________________________________________________
_________________________________________________________________________________________
3. Raumstation (als Infrastruktur)

Als Grundlage fr die Erarbeitung eines neuen Bausteins zur Infrastruktur "Raumstation" eignet sich
der existierende Baustein 4.1 Gebude. Die Raumstation befindet sich im All und verfgt somit ber
eine sehr gute Zutrittskontrolle. Sie umgibt die aufgestellte Informationstechnik und gewhrleistet
somit einen ueren Schutz. Weiterhin ermglichen die Infrastruktureinrichtungen der Raumstation
erst den IT-Betrieb. Daher ist einerseits die strukturelle Integritt zu betrachten und andererseits die
Versorgungseinrichtungen. Letztere sind bei bemannten Raumstationen besonders wichtig. Die
Sprach- und Datenkommunikation wird gesondert betrachtet.
_________________________________________________________________________________________
Basis-Sicherheitscheck 2.4
_________________________________________________________________________________________
2.4 Basis-Sicherheitscheck
Fr die nachfolgenden Betrachtungen wird vorausgesetzt,
dass fr einen ausgewhlten IT-Verbund folgende Teile
des IT-Sicherheitskonzepts nach IT-Grundschutz erstellt
wurden: Anhand der IT-Strukturanalyse des IT-
Verbundes wurde eine bersicht ber die vorhandene IT,
deren Einsatzorte und die untersttzten IT-Anwendungen
erstellt. Darauf aufbauend wurde anschlieend die
Schutzbedarfsfeststellung durchgefhrt, deren Ergebnis
eine bersicht ber den Schutzbedarf der IT-Anwen-
dungen, der IT-Systeme, der IT-genutzten Rume und der
Kommunikationsverbindungen ist. Mit Hilfe dieser
Informationen wurde die Modellierung des IT-Verbundes nach IT-Grundschutz durchgefhrt. Das
Ergebnis war eine Abbildung des betrachteten IT-Verbundes auf Bausteine des Handbuchs.
Diese Modellierung nach IT-Grundschutz wird nun als Prfplan benutzt, um anhand eines Soll-Ist-
Vergleichs herauszufinden, welche Standardsicherheitsmanahmen ausreichend oder nur unzu-
reichend umgesetzt sind.
Dieses Kapitel beschreibt, wie bei der zentralen Aufgabe zur Erstellung eines IT-Sicherheitskonzepts
nach IT-Grundschutz, der Durchfhrung des Basis-Sicherheitschecks, vorgegangen werden sollte.
Dieser Basis-Sicherheitscheck besteht aus drei unterschiedlichen Schritten. Im ersten Schritt werden
die organisatorischen Vorbereitungen getroffen, insbesondere die relevanten Ansprechpartner fr den
Soll-Ist-Vergleich ausgewhlt. Im zweiten Schritt wird der eigentliche Soll-Ist-Vergleich mittels
Interviews und stichprobenartiger Kontrolle durchgefhrt. Im letzten Schritt werden die erzielten
Ergebnisse des Soll-Ist-Vergleichs einschlielich der erhobenen Begrndungen dokumentiert.
Nachfolgend werden diese Schritte des Basis-Sicherheitschecks detailliert beschrieben.
2.4.1 Organisatorische Vorarbeiten
Fr die reibungslose Durchfhrung des Soll-Ist-Vergleichs sind einige Vorarbeiten erforderlich.
Zunchst sollten alle hausinternen Papiere, z. B. Organisationsverfgungen, Arbeitshinweise, Sicher-
heitsanweisungen, Manuals und "informelle" Vorgehensweisen, die die IT-sicherheitsrelevanten
Ablufe regeln, gesichtet werden. Diese Dokumente knnen bei der Ermittlung des Umsetzungsgrades
hilfreich sein, insbesondere bei Fragen nach bestehenden organisatorischen Regelungen. Weiterhin ist
zu klren, wer gegenwrtig fr deren Inhalt zustndig ist, um ggf. spter die richtigen Ansprechpartner
bestimmen zu knnen.
Als Nchstes sollte festgestellt werden, ob und in welchem Umfang externe Stellen bei der Ermittlung
des Umsetzungsstatus beteiligt werden mssen. Dies kann beispielsweise bei externen Rechenzentren,
vorgesetzten Behrden, Firmen, die Teile des IT-Betriebes in Outsourcing bernehmen, oder Bau-
behrden, die fr infrastrukturelle Manahmen zustndig sind, erforderlich sein.
Ein wichtiger Schritt vor der Durchfhrung des eigentlichen Soll-Ist-Vergleichs ist die Ermittlung
geeigneter Interviewpartner. Hierzu sollte zunchst fr jeden einzelnen Baustein, der fr die Modellie-
rung des vorliegenden IT-Verbunds herangezogen wurde, ein Hauptansprechpartner festgelegt werden.
- Bei den Bausteinen der Schicht 1 "bergeordnete Aspekte" ergibt sich ein geeigneter Ansprech-
partner in der Regel direkt aus der im Baustein behandelten Thematik. Beispielsweise sollte fr den
Baustein 3.2 Personal ein Mitarbeiter der zustndigen Personalabteilung als Ansprechpartner aus-
gewhlt werden. Bei den konzeptionellen Bausteinen, z. B. Baustein 3.4 Datensicherungskonzept,
_________________________________________________________________________________________
_________________________________________________________________________________________
steht im Idealfall der Mitarbeiter zur Verfgung, der fr die Fortschreibung des entsprechenden
Dokuments zustndig ist. Anderenfalls sollte derjenige Mitarbeiter befragt werden, zu dessen Auf-
gabengebiet die Fortschreibung von Regelungen in dem betrachteten Bereich gehren.
- Im Bereich der Schicht 2 "Infrastruktur" sollte die Auswahl geeigneter Ansprechpartner in
Abstimmung mit der Abteilung Innerer Dienst/Haustechnik vorgenommen werden. Je nach Gre
der betrachteten Institution knnen beispielsweise unterschiedliche Ansprechpartner fr die Infra-
strukturbereiche Verkabelung und Schutzschrnke zustndig sein. In kleinen Institutionen kann in
vielen Fllen der Hausmeister Auskunft geben. Zu beachten ist im Bereich Infrastruktur, dass hier
u. U. externe Stellen zu beteiligen sind. Dies betrifft insbesondere grere Unternehmen und
Behrden.
- In Bausteinen der Schicht 3 "IT-Systeme" und Schicht 4 "Netze" werden in den zu prfenden
Sicherheitsmanahmen verstrkt technische Aspekte behandelt. In der Regel kommt daher der
Administrator derjenigen Komponente bzw. Gruppe von Komponenten, der der jeweilige Baustein
bei der Modellierung zugeordnet wurde, als Hauptansprechpartner in Frage.
- Fr die Bausteine der Schicht 5 "IT-Anwendungen" sollten die Betreuer bzw. die Verantwortlichen
der einzelnen IT-Anwendungen als Hauptansprechpartner ausgewhlt werden.
In vielen Fllen kann der Hauptansprechpartner nicht zu allen Fragen des jeweiligen Bausteins umfas-
send Auskunft geben. Dann ist es vorteilhaft, eine oder auch mehrere zustzliche Personen in das
Interview einzubeziehen. Hinweise dazu, welche Mitarbeiter u. U. hinzugezogen werden sollten,
lassen sich den Eintrgen "Verantwortlich fr Initiierung" und "Verantwortlich fr Umsetzung", die
sich am Anfang jeder Manahmenbeschreibung befinden, entnehmen.
Fr die anstehenden Interviews mit den Systemverantwortlichen, Administratoren und sonstigen
Ansprechpartnern sollte ein Terminplan - ggf. mit Ausweichterminen - erstellt werden. Besonderes
Augenmerk gilt hier der Terminkoordination mit Personen aus anderen Organisationseinheiten oder
anderen Institutionen.
Je nach Gre der Projektgruppe sollten fr die Durchfhrung der Interviews Teams mit verteilten
Aufgaben gebildet werden. Es hat sich bewhrt, in Gruppen mit je zwei Personen zu arbeiten. Dabei
notiert eine Person die Ergebnisse und Anmerkungen zu den Antworten, die andere stellt die notwen-
digen Fragen.
2.4.2 Durchfhrung des Soll-Ist-Vergleichs

Sind alle erforderlichen Vorarbeiten erledigt, kann die eigentliche Erhebung an den zuvor festge-
setzten Terminen beginnen. Hierzu werden die Manahmen des jeweiligen Bausteins, fr den die
Interviewpartner zustndig sind, der Reihe nach durchgearbeitet.
Als Antworten bezglich des Umsetzungsstatus der einzelnen Manahmen kommen folgende Aus-
sagen in Betracht:
_________________________________________________________________________________________
_________________________________________________________________________________________
"entbehrlich" - Die Umsetzung der Manahmenempfehlungen ist in der vorgeschlagenen Art

nicht notwendig, da den entsprechenden Gefhrdungen mit anderen adquaten
Manahmen entgegengewirkt wird (z. B. durch Manahmen, die nicht im
IT-Grundschutzhandbuch aufgefhrt sind, aber dieselbe Wirkung erzielen),
oder die Manahmenempfehlungen nicht relevant sind (z. B. weil Dienste
nicht aktiviert wurden).
"ja" - Alle Empfehlungen in der Manahme sind vollstndig und wirksam umge-
setzt.
"teilweise" - Einige der Empfehlungen sind umgesetzt, andere noch nicht oder nur teil-
weise.
"nein" - Die Empfehlungen der Manahme sind grtenteils noch nicht umgesetzt.
Es ist nicht zu empfehlen, bei den Interviews den Text der Manahmenempfehlung vorzulesen, da er
nicht fr ein Zwiegesprch konzipiert wurde. Deshalb ist die inhaltliche Kenntnis des Bausteins fr
den Interviewer notwendig, ergnzend sollten vorher griffige Checklisten mit Stichworten erstellt
werden. Um im Zweifelsfall Unstimmigkeiten klren zu knnen, ist es jedoch sinnvoll, den Volltext
der Manahmen griffbereit zu haben. Es wird ebenfalls nicht empfohlen, whrend des Interviews die
Antworten direkt in einen PC einzugeben, da es alle Beteiligten ablenkt und fr ungewollte Unter-
brechungen der Kommunikation sorgt.
Es schafft eine entspannte, aufgelockerte und produktive Arbeitsatmosphre, das Interview mit einlei-
tenden Worten zu beginnen und den Zweck des Basis-Sicherheitschecks kurz vorzustellen. Es bietet
sich an, mit der Manahmenberschrift fortzufahren und die Manahme kurz zu erlutern. Besser als
einen Monolog zu fhren ist es, dem Gegenber die Mglichkeit zu geben, auf die bereits umgesetzten
Manahmenteile einzugehen, und danach noch offene Punkte zu besprechen.
Die Befragungstiefe richtet sich zunchst auf das Niveau von Standard-Sicherheitsmanahmen,
darber hinausgehende Aspekte hochschutzbedrftiger Anwendungen sollten erst nach Abschluss des
Basis-Sicherheitschecks betrachtet werden. Falls der Bedarf besteht, die in den Interviews gemachten
Aussagen zu verifizieren, bietet es sich an, stichprobenartig die entsprechenden Regelungen und
Konzepte zu sichten, im Bereich Infrastruktur gemeinsam mit dem Ansprechpartner die zu unter-
suchenden Objekte vor Ort zu besichtigen sowie Client- bzw. Servereinstellungen an ausgewhlten IT-
Systemen zu berprfen.
Zum Abschluss jeder Manahme sollte den Befragten mitgeteilt werden, wie das Ergebnis ausgefallen
ist (Umsetzungsstatus der Manahme: entbehrlich/ja/teilweise/nein), und diese Entscheidung erlutert
werden.
2.4.3 Dokumentation der Ergebnisse

Fr die Dokumentation der Ergebnisse des Basis-Sicherheitschecks stehen auf der CD-ROM zum IT-
Grundschutzhandbuch Formulare zur Verfgung (siehe Anhang: Hilfsmittel). Das Verzeichnis enthlt
fr jeden Baustein des IT-Grundschutzhandbuchs eine Datei im Word-Format, in der tabellarisch fr
jede Manahme des Bausteins die Ergebnisse des Soll-Ist-Vergleichs erfasst werden knnen.
Zunchst sollten in die dafr vorgesehenen Felder am Anfang des Formulars
- die Nummer und die Bezeichnung der Komponente oder Gruppe von Komponenten, der der Bau-
stein bei der Modellierung zugeordnet wurde,
_________________________________________________________________________________________
_________________________________________________________________________________________
- der Standort der zugeordneten Komponente bzw. Gruppe von Komponenten,

- das Erfassungsdatum und der Name des Erfassers und
- die befragten Ansprechpartner
eingetragen werden. Die eigentlichen Ergebnisse des Soll-Ist-Vergleichs werden in der auf dem
Formular vorbereiteten Tabelle erfasst. Dabei sollten zu jeder Manahme des jeweiligen Bausteins die
Felder wie folgt ausgefllt werden:
- Umsetzungsgrad (entbehrlich/ja/teilweise/nein)
Hier wird der im Interview ermittelte Umsetzungsstatus der jeweiligen Manahme erfasst.
- Umsetzung bis
Dieses Feld wird whrend des Basis-Sicherheitschecks im Allgemeinen nicht ausgefllt. Es dient
als Platzhalter, um in der Realisierungsplanung an dieser Stelle zu dokumentieren, bis zu welchem
Termin die Manahme vollstndig umgesetzt sein soll.
- verantwortlich
Falls es bei der Durchfhrung des Soll-Ist-Vergleichs eindeutig ist, welcher Mitarbeiter fr die
vollstndige Umsetzung einer defizitren Manahme verantwortlich sein wird, so kann dies in
diesem Feld dokumentiert werden. Falls die Verantwortlichkeit nicht eindeutig ist, sollte das Feld
freigelassen werden. Es wird spter in der Realisierungsplanung mit dem Namen des dann als
verantwortlich Bestimmten gefllt.
- Bemerkungen / Begrndung fr Nicht-Umsetzung
Bei Manahmen, deren Umsetzung entbehrlich erscheint, ist hier die Begrndung bzw. die Ersatz-
manahme zu nennen. Bei Manahmen, die noch nicht oder nur teilweise umgesetzt sind, sollte in
diesem Feld dokumentiert werden, welche Empfehlungen der Manahme noch umgesetzt werden
mssen. In dieses Feld sollten auch alle anderen Bemerkungen eingetragen werden, die bei der
Beseitigung von Defiziten hilfreich sind oder im Zusammenhang mit der Manahme zu berck-
sichtigen sind.
- Kostenschtzung
Bei Manahmen, die noch nicht oder nur teilweise umgesetzt sind, kann in dieses Feld eine
Schtzung eingetragen werden, welchen finanziellen und personellen Aufwand die Beseitigung der
Defizite erfordert.
Ein Beispiel fr ein ausgeflltes Erhebungsformular befindet sich am Ende dieses Abschnitts.
Die Dokumentation der Ergebnisse kann auch mit Hilfe eines Tools erfolgen, beispielsweise mit dem
im Auftrag des BSI entwickelten IT-Grundschutz-Tool. Hierdurch ergeben sich komfortable Mglich-
keiten zur Auswertung und Revision der Ergebnisse, z. B. die Suche nach bestimmten Eintrgen,
Generierung benutzerdefinierter Reports, Statistikfunktionen usw.
_________________________________________________________________________________________
_________________________________________________________________________________________
_________________________________________________________________________________________
Ergnzende Sicherheitsanalyse 2.5
_________________________________________________________________________________________
2.5 Ergnzende Sicherheitsanalyse

Wie im Kapitel 2.2 Schutzbedarfsfeststellung dargestellt,
bieten die Standardsicherheitsmanahmen nach IT-
Grundschutz im Normalfall einen angemessenen und
ausreichenden Schutz. Hat sich bei der Schutzbedarfs-
feststellung jedoch herausgestellt, dass eine IT-Anwen-
dung einschlielich ihrer Daten einen hohen oder sehr
hohen Schutzbedarf besitzt, kann es sinnvoll sein zu
prfen, ob die Standardsicherheitsmanahmen durch
hherwertige - meist jedoch auch kostspieligere - IT-
Sicherheitsmanahmen ergnzt oder ersetzt werden
mssen. Welche zustzlichen Manahmen geeignet sind,
kann nach der Durchfhrung des Basis-Sicherheitschecks nach IT-Grundschutz mittels einer
ergnzenden Sicherheitsanalyse festgestellt werden.
Um den Aufwand einer ergnzenden Sicherheitsanalyse auf das Notwendige zu beschrnken, ist es
sinnvoll, nicht den gesamten IT-Verbund zu analysieren, sondern sich auf die sicherheitskritischen
Bereiche zu konzentrieren. Zu diesem Zweck sollten aus den Ergebnissen der Schutzbedarfsfeststel-
lung diejenigen Bereiche extrahiert werden, die einen hohen oder sehr hohen Schutzbedarf besitzen
oder als sicherheitskritisch eingestuft wurden. Dies knnen sein:
- IT-Systeme mit hherem Schutzbedarf,
- Kommunikationsverbindungen nach auen,
- Kommunikationsverbindungen mit hochschutzbedrftigen Daten,
- Kommunikationsverbindungen, die bestimmte Daten nicht transportieren drfen, und
- IT-Rume mit hohem Schutzbedarf.
Diese auf den sicherheitskritischen Bereich eingeschrnkten Teile des IT-Verbunds werden
anschlieend einer ergnzenden Sicherheitsanalyse unterzogen. Hierzu knnen unterschiedliche
Methoden angewandt werden wie beispielsweise
- Risikoanalyse,
- Penetrationstest und
- Differenz-Sicherheitsanalyse.
Es sei vorab erwhnt, dass die erfolgreiche Durchfhrung einer ergnzenden Sicherheitsanalyse
entscheidend von den Fachkenntnissen des Projektteams abhngt. Unverzichtbar ist eine fundierte
Fachkunde in den Bereichen Informationstechnik und IT-Sicherheit, die idealerweise durch einen
breiten Erfahrungshintergrund ergnzt wird. Anderenfalls besteht die Gefahr, dass wesentliche
Schwachstellen oder Manahmen bersehen werden und dass das Ergebnis oft nur eine trgerische
Scheinsicherheit erzeugt. Daher kann es fr ergnzende Sicherheitsanalysen sinnvoll sein, fachkun-
diges externes Personal hinzuzuziehen.
Risikoanalyse
In einer Risikoanalyse wird versucht, die relevanten Bedrohungen herauszuarbeiten, die sich aufgrund
vorhandener Schwachstellen auf ein IT-System auswirken knnen. Anschlieend wird die Eintritts-
wahrscheinlichkeit der Bedrohungen geschtzt und mit dem Schutzbedarf kombiniert, um die beste-
henden Risiken zu ermitteln. Fr untragbare Risiken werden anschlieend adquate IT-Sicherheits-
_________________________________________________________________________________________
_________________________________________________________________________________________
manahmen ausgewhlt, um die Eintrittswahrscheinlichkeit zu senken bzw. die Schadenshhe zu

reduzieren.
Schwierig und zugleich fehlerempfindlich ist dabei insbesondere die Schtzung der Eintrittswahr-
scheinlichkeiten. Meist liegen dazu keine statistischen Informationen vor. Insbesondere ist diese
Schtzung schwierig bei Bedrohungen, die auf vorstzlich handelnde Tter zurckzufhren sind. Liegt
die Schtzung nur geringfgig zu niedrig, kann daraus ein scheinbar tragbares Risiko resultieren, so
dass keine zustzlichen Manahmen ergriffen werden, obwohl diese eigentlich notwendig wren.
Eine Beschreibung, wie eine Risikoanalyse durchgefhrt werden kann, findet sich beispielsweise im
IT-Sicherheitshandbuch (siehe Literaturverzeichnis).
Penetrationstest
Penetrationstests dienen dazu, die Erfolgsaussichten eines vorstzlichen Angriffs auf einen IT-
Verbund vorab einzuschtzen und daraus notwendige ergnzende Manahmen abzuleiten. Dazu wird
versucht, das Angriffsverhalten eines vorstzlichen Innen- oder Auentters zu simulieren und zu
ermitteln, welche vorhandenen Schwachstellen ausgenutzt bzw. welche potentiellen Schden verur-
sacht werden knnen. Oftmals werden folgende Anstze verfolgt:
- Angriffe durch Erraten von Passwrtern oder Wrterbuchattacken,
- Angriffe durch Aufzeichnen und Manipulieren des Netzverkehrs,
- Angriffe durch Einspielen geflschter Datenpakete oder
- Angriffe durch Ausnutzen bekannter Software-Schwachstellen (Makro-Sprachen, Betriebssystem-
fehler, Remote-Dienste, etc.).
Dabei ist zwischen zwei Arten von Penetrationstests zu unterscheiden:
- Blackbox-Ansatz: Der Angreifer besitzt keinerlei Informationen ber den IT-Verbund. Damit wird
ein Auentter simuliert.
- Whitebox-Ansatz: Der Angreifer besitzt Kenntnisse ber den internen Aufbau, Applikationen und
Dienste im IT-Verbund, ber die typischerweise ein Innentter verfgt.
Weiterhin wre zu unterscheiden, ob die Durchfhrung eines Penetrationstests nur mit dem Manage-
ment abgestimmt oder ob sie den betroffenen Mitarbeitern vorher angekndigt wird. Die
Durchfhrung von Penetrationstests setzt in besonderem Mae fundierte Kenntnisse und Erfahrungen
voraus, da sonst nicht ausgeschlossen werden kann, dass durch die aktiven Angriffe unbeabsichtigt
Schden entstehen.
Differenz-Sicherheitsanalyse
Ein erster Ansatz, notwendige hherwertige IT-Sicherheitsmanahmen fr hochschutzbedrftige
Bereiche eines IT-Verbundes zu identifizieren, besteht in der Durchfhrung einer Differenz-Sicher-
heitsanalyse. Dazu wird in einem ersten Schritt untersucht, welche IT-Sicherheitsmanahmen ber die
IT-Grundschutzmanahmen hinausgehen oder welche als optional gekennzeichneten IT-Grundschutz-
manahmen realisiert sind. Anschlieend wird ein Vergleich durchgefhrt, ob die ergriffenen hher-
wertigen Manahmen den Musterlsungen entsprechen, die sich in der Praxis fr hochschutzbedrf-
tige IT-Bereiche etabliert haben. Hierbei ist zu beachten, dass die relevanten Grundwerte
(Vertraulichkeit, Integritt und Verfgbarkeit) fr die Eignung der hherwertigen Manahmen
entscheidend sind. So helfen kryptographische Manahmen zwar zur Erhhung der Sicherheit der
Grundwerte Vertraulichkeit und Integritt, jedoch ist ihr Wirkungsgrad in Bezug auf Verfgbarkeit in
den meisten Fllen gering oder sie stellen sogar eine potentielle Gefhrdung fr dieses Schutzziel dar.
Ebenso wichtig ist darauf zu achten, dass erforderliche Produkte geeignet und die hherwertigen
Manahmen korrekt implementiert sind, damit sie ihre Schutzwirkung erbringen knnen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Typische hherwertige Manahmen im Bereich der IT-Systeme sind der Einsatz von zertifizierten
Betriebssystemen oder von speziellen Sicherheitsversionen der Betriebssysteme, der Einsatz von
Authentisierungstoken oder sogar die Isolation der IT-Systeme. Im Bereich der Kommunikationsver-
bindungen kommen beispielsweise folgende hherwertige Manahmen zum Einsatz: Kappung von
Auenverbindungen, Leitungs- oder Ende-zu-Ende-Verschlsselung, gepanzerte Kabeltrassen oder
druckberwachte Kabel, redundante Kommunikationsstrecken oder redundante Kabelfhrung sowie
Einsatz von mehrstufigen Firewalls kombiniert mit Intrusion Detection Tools. Im Bereich der
infrastrukturellen Sicherheit knnen beispielsweise Vereinzelungsschleusen, Brandlschtechnik,
Videoberwachung, Zutrittskontrollsysteme und Einbruchmeldeanlagen bis hin zu Backup-Rechen-
zentren eingesetzt werden.
Das BSI verffentlicht so genannte Schutzklassenmodelle, in dem fr thematisch eingegrenzte
Bereiche (z. B. TK-Anlagen) adquate hherwertige Manahmen fr den hohen und sehr hohen
Schutzbedarf zusammengestellt werden.
_________________________________________________________________________________________
Realisierung von IT-Sicherheitsmanahmen 2.6
_________________________________________________________________________________________
2.6 Realisierung von IT-Sicherheits-

manahmen
In diesem Kapitel werden verschiedene Aspekte vorge-
stellt, die bei der Realisierung von IT-Sicherheits-
manahmen beachtet werden mssen. Dabei wird
beschrieben, wie die Umsetzung als fehlend erkannter IT-
Sicherheitsmanahmen geplant, durchgefhrt, begleitet
und berwacht werden kann.
Bevor mit der Realisierung von IT-Sicherheitsmanah-
men begonnen werden kann, muss fr das untersuchte IT-
System oder den untersuchten IT-Verbund die IT-
Strukturanalyse, die Schutzbedarfsfeststellung und die Modellierung nach den Kapiteln 2.1-2.3 erfolgt
sein. Ebenso mssen die Ergebnisse des Basis-Sicherheitschecks, also des daran anschlieenden Soll-
Ist-Vergleichs, vorliegen. Sollte fr ausgewhlte Bereiche aufgrund eines hheren Schutzbedarfs eine
ergnzende Sicherheitsanalyse durchgefhrt worden sein, so sollten die dabei erarbeiteten
Manahmenvorschlge ebenfalls vorliegen und nachfolgend bercksichtigt werden.
Ist eine Vielzahl von Manahmen zu realisieren und stehen ggf. fr die Realisierung nur beschrnkte
Ressourcen an Geld und Personal zur Verfgung, so kann die Realisierung der IT-Sicherheitsma-
nahmen wie in den nachfolgenden Schritten beschrieben vollzogen werden. Ein Beispiel zur Erlu-
terung der Vorgehensweise findet sich am Ende dieses Kapitels.
Sind nur wenige fehlende Manahmen identifiziert worden, deren Umsetzung wenig finanzielle oder
personelle Ressourcen bindet, kann oft ad hoc entschieden werden, wer diese Manahmen bis wann
umzusetzen hat. Dies kann einfach und unkompliziert in den Erfassungstabellen des Soll-Ist-Ver-
gleichs dokumentiert werden. In diesem Fall knnen die nachfolgenden Schritte 1, 3 und 4 entfallen.
Schritt 1: Sichtung der Untersuchungsergebnisse
In einer Gesamtsicht sollten zuerst die fehlenden oder nur teilweise umgesetzten IT-Grundschutz-
manahmen ausgewertet werden. Dazu bietet es sich an, aus den Ergebnissen des Basis-Sicherheits-
checks alle nicht umgesetzten bzw. nur teilweise umgesetzten Manahmen einschlielich ihrer Priori-
tten zu extrahieren und in einer Tabelle zusammenzufassen.
Durch ergnzende Sicherheitsanalysen knnen eventuell weitere zu realisierende Manahmen identi-
fiziert worden sein. Diese sollten ebenfalls tabellarisch erfasst werden. Diese zustzlichen Manahmen
sollten den vorher betrachteten Zielobjekten der Modellierung und den entsprechenden IT-Grund-
schutz-Bausteinen thematisch zugeordnet werden.
Schritt 2: Konsolidierung der Manahmen
In diesem Schritt werden zunchst die noch umzusetzenden IT-Sicherheitsmanahmen konsolidiert.
Falls zustzliche Sicherheitsanalysen durchgefhrt wurden, knnen hierdurch IT-Sicherheitsma-
nahmen hinzugekommen sein, die Manahmen aus dem IT-Grundschutzhandbuch ergnzen oder auch
ersetzen. Hierbei wird geprft, fr welche IT-Grundschutzmanahmen die Realisierung entfallen kann,
da zu realisierende hherwertige IT-Sicherheitsmanahmen sie ersetzen.
Da im IT-Grundschutzhandbuch fr eine Vielzahl von verschiedenen Organisationsformen und tech-
nischen Ausgestaltungen Empfehlungen gegeben werden, mssen die ausgewhlten Manahmen
eventuell noch konkretisiert bzw. an die organisatorischen und technischen Gegebenheiten der Insti-
tution angepasst werden. Auerdem sollten alle IT-Sicherheitsmanahmen noch einmal daraufhin
berprft werden, ob sie auch geeignet sind: Sie mssen vor den mglichen Gefhrdungen wirksam
_________________________________________________________________________________________
_________________________________________________________________________________________
schtzen, aber auch in der Praxis tatschlich umsetzbar sein, drfen also z. B. nicht die Organisations-
ablufe behindern oder andere Sicherheitsmanahmen aushebeln. In solchen Fllen kann es notwendig
werden, bestimmte IT-Grundschutzmanahmen durch adquate andere IT-Sicherheitsmanahmen zu
ersetzen.
Um auch spter noch nachvollziehen zu knnen, wie die konkrete Manahmenliste erstellt und verfei-
nert wurde, sollte dies geeignet dokumentiert werden.
Beispiele:
- In einer ergnzenden Sicherheitsanalyse wurde festgestellt, dass zustzlich zu den IT-Grund-
schutzmanahmen auch eine chipkartengesttzte Authentisierung und lokale Verschlsselung der
Festplatten an NT-Clients der Personaldatenverarbeitung notwendig sind. Diese zustzliche
Manahme wrde die Manahme M 4.48 Passwortschutz unter Windows NT ersetzen.
- Im Basis-Sicherheitscheck wurde festgestellt, dass die Manahme M 1.24 Vermeidung von wasser-
fhrenden Leitungen nicht realisiert und aufgrund der baulichen Gegebenheiten nicht wirtschaftlich
umsetzbar ist. Stattdessen sollten als Ersatzmanahme unter den wasserfhrenden Leitungen
Wasser ableitende Bleche installiert werden, die gleichzeitig von einem Wassermelder berwacht
werden. Die Meldung wird beim Pfrtner aufgeschaltet, so dass im Schadensfall der entstehende
Wasserschaden zgig entdeckt und eingegrenzt werden kann.
Schritt 3: Kosten- und Aufwandsschtzung
Da das Budget zur Umsetzung von IT-Sicherheitsmanahmen praktisch immer begrenzt ist, sollte fr
jede zu realisierende Manahme festgehalten werden, welche Investitionskosten und welcher Perso-
nalaufwand dafr bentigt werden. Hierbei sollte zwischen einmaligen und wiederkehrenden Investi-
tionskosten bzw. Personalaufwnden unterschieden werden. An dieser Stelle zeigt sich hufig, dass
Einsparungen bei der Technik einen hohen fortlaufenden Personaleinsatz verursachen.
In diesem Zusammenhang ist zu ermitteln, ob alle identifizierten Manahmen wirtschaftlich umsetzbar
sind. Falls es Manahmen gibt, die nicht finanzierbar sind, sollten berlegungen angestellt werden,
durch welche Ersatzmanahmen sie ersetzt werden knnen oder ob das Restrisiko, dass durch die
fehlende Manahme entsteht, tragbar ist. Diese Entscheidung ist ebenfalls zu dokumentieren.
Stehen die geschtzten Ressourcen fr Kosten und Personaleinsatz zur Verfgung, so kann zum
nchsten Schritt bergegangen werden. In vielen Fllen muss jedoch noch eine Entscheidung herbei-
gefhrt werden, wieviel Ressourcen fr die Umsetzung der IT-Sicherheitsmanahmen eingesetzt
werden sollen. Hierfr bietet es sich an, fr die Entscheidungsebene (Management, IT-Leiter, IT-
Sicherheitsbeauftragter,...) eine Prsentation vorzubereiten, in der die Ergebnisse der Sicherheits-
untersuchung dargestellt werden. Geordnet nach Schutzbedarf sollten die festgestellten Schwach-
stellen (fehlende oder unzureichend umgesetzte IT-Sicherheitsmanahmen) zur Sensibilisierung
vorgestellt werden. Darber hinaus bietet es sich an, die fr die Realisierung der fehlenden Manah-
men der Prioritt 1, 2 und 3 entstehenden Kosten und Aufwnde aufzubereiten. Im Anschluss an diese
Prsentation sollte eine Entscheidung ber das Budget erfolgen.
Kann kein ausreichendes Budget fr die Realisierung aller fehlenden Manahmen bereitgestellt
werden, so sollte aufgezeigt werden, welches Restrisiko dadurch entsteht, dass einige Manahmen
nicht oder verzgert umgesetzt werden. Zu diesem Zweck knnen die Manahmen-Gefhrdungs-
Tabellen (s. CD-ROM: word20\tabellen) hinzugezogen werden, um zu ermitteln, welche Gefhrdun-
gen nicht mehr ausreichend abgedeckt werden. Das entstehende Restrisiko sollte fr zufllig eintre-
tende oder absichtlich herbeigefhrte Gefhrdungen transparent beschrieben und der Leitungsebene
zur Entscheidung vorgelegt werden. Die weiteren Schritte knnen erst nach der Entscheidung der
Leitungsebene, dass das Restrisiko tragbar ist, erfolgen, da die Leitungsebene die Verantwortung fr
die Konsequenzen tragen muss.
_________________________________________________________________________________________
_________________________________________________________________________________________
Schritt 4: Festlegung der Umsetzungsreihenfolge der Manahmen

Wenn das vorhandene Budget oder die personellen Ressourcen nicht ausreichen, um smtliche
fehlenden Manahmen sofort umsetzen zu knnen, muss eine Umsetzungsreihenfolge festgelegt
werden. Bei der Festlegung der Reihenfolge sollten folgende Aspekte bercksichtigt werden:
- Die Prioritt einer Manahme spiegelt wider, in welcher zeitlichen Reihenfolge die Manahme
umzusetzen ist. Vorrangig ist mit Manahmen der Prioritt 1 zu beginnen.
- Bei einigen Manahmen ergibt sich durch logische Zusammenhnge eine zwingende zeitliche
Reihenfolge. So sind zwar die Manahmen M 2.25 Dokumentation der Systemkonfiguration und
M 2.26 Ernennung eines Administrators und eines Vertreters beide sehr wichtig, aber ohne
Administrator kann M 2.25 kaum umgesetzt werden.
- Manche Manahmen erzielen eine groe Breitenwirkung, manche jedoch nur eine eingeschrnkte
lokale Wirkung. Oft ist es sinnvoll, zuerst auf die Breitenwirkung zu achten.
- Es gibt Bausteine, die auf das angestrebte Sicherheitsniveau eine greren Einfluss haben als
andere. Manahmen eines solchen Bausteins sollten bevorzugt behandelt werden, insbesondere
wenn hierdurch Schwachstellen in hochschutzbedrftigen Bereichen beseitigt werden. So sollten
immer zunchst die Server abgesichert werden (z. B. durch Umsetzung des Bausteins 6.2 Unix-
Server) und dann erst die angeschlossenen Clients.
- Bausteine mit auffallend vielen fehlenden Manahmen reprsentieren Bereiche mit vielen
Schwachstellen. Sie sollten ebenfalls bevorzugt behandelt werden.
Schritt 5: Festlegung der Verantwortlichkeit
Nach der Bestimmung der Reihenfolge fr die Umsetzung der Manahmen muss anschlieend fest-
gelegt werden, wer bis wann welche Manahmen realisieren muss. Ohne eine solche Festlegung
verzgert sich die Realisierung erfahrungsgem erheblich bzw. unterbleibt ganz. Dabei ist darauf zu
achten, dass der als verantwortlich Benannte ausreichende Fhigkeiten und Kompetenzen zur
Umsetzung der Manahmen besitzt und dass ihm die erforderlichen Ressourcen zur Verfgung gestellt
werden.
Ebenso ist festzulegen, wer fr die berwachung der Realisierung verantwortlich ist bzw. an wen der
Abschluss der Realisierung der einzelnen Manahmen zu melden ist. Typischerweise wird die
Meldung an den IT-Sicherheitsbeauftragten erfolgen. Der Fortschritt der Realisierung sollte regel-
mig nachgeprft werden, damit die Realisierungsauftrge nicht verschleppt werden.
Der nun fertig gestellte Realisierungsplan sollte mindestens folgende Informationen umfassen:
- Beschreibung des Zielobjektes als Einsatzumfeld,
- Nummer des betrachteten Bausteins,
- Manahmentitel bzw. Manahmenbeschreibung,
- Terminplanung fr die Umsetzung,
- Budgetrahmen,
- Verantwortliche fr die Umsetzung und
- Verantwortliche fr die berwachung der Realisierung.
Schritt 6: Realisierungsbegleitende Manahmen
beraus wichtig ist es, notwendige realisierungsbegleitende Manahmen rechtzeitig zu konzipieren
und fr die Realisierung mit einzuplanen. Zu diesen Manahmen gehren insbesondere Sensibilisie-
rungsmanahmen, die darauf zielen, die von neuen IT-Sicherheitsmanahmen betroffenen Mitarbeiter
ber die Notwendigkeit und die Konsequenzen der Manahmen zu unterrichten und sie fr die
Belange der IT-Sicherheit zu sensibilisieren.
_________________________________________________________________________________________
_________________________________________________________________________________________
Darber hinaus mssen die betroffenen Mitarbeiter geschult werden, die neuen IT-Sicherheits-
manahmen korrekt um- und einzusetzen. Wird diese Schulung unterlassen, knnen die Manahmen
nicht umgesetzt werden und verlieren ihre Wirkung. Darber hinaus wrden sich die Mitarbeiter
unzureichend informiert fhlen, was oft zu einer ablehnenden Haltung gegenber IT-Sicherheit fhrt.
Nach der Realisierung und Einfhrung der neuen IT-Sicherheitsmanahmen sollte durch den IT-
Sicherheitsbeauftragten geprft werden, ob die notwendige Akzeptanz der Mitarbeiter vorhanden ist.
Stellt sich heraus, dass die neuen Manahmen nicht akzeptiert werden, ist ein Misserfolg vorpro-
grammiert. Die Ursachen sind herauszuarbeiten und ggf. ist eine zustzliche Aufklrung der Betroffe-
nen einzuleiten.
Beispiel:
Um die obigen Schritte nher zu beschreiben, wird nachfolgend ein fiktives Beispiel auszugsweise
beschrieben. Zunchst soll die Tabelle der konsolidierten, zu realisierenden Manahmen einschlielich
der Kostenschtzungen, die als Ergebnis der Schritte 1 - 3 entsteht, dargestellt werden:
Zielobjekt Bau- Manahme Prio- Kosten Bemerkung
stein ritt
1 2 3
Gesamte Organisation 3.1 M 2.11 Regelung des Passwort- T a) 0,- Euro

gebrauchs b) 2 AT
c) 0.-Euro/Jahr
d) 0 AT/Jahr
Serverraum R 3.10 4.3.2 M 1.24 Vermeidung von wasser- F a) 20000.- Euro Diese Manahme ist nicht
fhrenden Leitungen b) 12 AT wirtschaftlich umsetzbar.
c) 0.- Euro/Jahr Ersatzweise wird Manahme Z
d) 0 AT/Jahr 1 umgesetzt.
Serverraum R 3.10 4.3.2 Z 1 Installation von Wasser a) 4000.- Euro Ersetzt Manahme M 1.24
ableitenden Blechen mit ber- b) 3 AT
wachung mittels eines Wasser- c) 0.- Euro/Jahr
melders und Aufschaltung auf d) 0 AT/Jahr
den Pfrtner
Server S4 6.5 M 1.28 Lokale unterbrechungs- F a) 1000.- Euro
freie Stromversorgung b) 1 AT
c) 0.-Euro/Jahr
d) 0 AT/Jahr
Gruppe Clients C1 5.5 Z 2 chipkartengesttzte Authen- a) 1400.- Euro Diese zustzliche Manahme
tisierung und lokale Verschls- b) 2 AT ersetzt die Manahme M 4.1
selung der Festplatten c) 0.- Euro/Jahr
d) 2 AT/Jahr
...
Legende:
- Manahme
Z 1 = Zusatzmanahme 1 (zustzlich zu IT-Grundschutzmanahmen)
- Prioritten
T = teilweise erfllt, F = fehlt, ist nicht realisiert
- Kosten:
a) = einmalige Investitionskosten
b) = einmaliger Personalaufwand (AT = Arbeitstage)
c) = wiederkehrende Investitionskosten
d) = wiederkehrender Personalaufwand (AT = Arbeitstage)
_________________________________________________________________________________________
_________________________________________________________________________________________
Als nchstes wird der tabellarische Realisierungsplan dargestellt, der sich nach der Management-
entscheidung aus obiger Tabelle ergeben wrde.
Realisierungsplan (Stand 01.09.2000)

Zielobjekt Bau- Manahme Umset- Verant- Budgetrahmen Bemer-
stein zung bis wortlich kung
Gesamte 3.1 M 2.11 Regelung des 31.12.20 a) Herr a) 0,- Euro
Organisation Passwortgebrauchs 00 Mller b) 2 AT
b) Frau c) 0.-Euro/Jahr
Meier d) 0 AT/Jahr
Serverraum 4.3.2 Z 1 Installation von 30.04.20 a) Herr a) 1000.- Euro Installation
R 3.10 Wasser ableitenden 01 Schmitz b) 1 AT der Bleche
Blechen mit b) Herr c) 0.- Euro/Jahr ledig-lich
berwachung mittels Hofmann d) 0 AT/Jahr unter
eines Wassermelders frisch- und
und Aufschaltung auf abwasser-
den Pfrtner fhrenden
Leitungen
Server S4 6.5 M 1.28 Lokale unter- 31.10.20 a) Herr a) 500.- Euro
brechungs-freie 00 Schulz b) 1 AT
Stromversorgung b) Frau c) 0.-Euro/Jahr
Meier d) 0 AT/Jahr
Gruppe 5.5 Z 2 chipkartengesttzte 31.12.20 a) Herr a) 1400.- Euro
Clients C1 Authentisierung und 00 Schulz
b) 2 AT
lokale Verschlsselung b) Frau
der Festplatten Meier c) 0.- Euro/Jahr
d) 2 AT/Jahr
...
Legende:
- Verantwortlich:
a) = Verantwortlich fr die Umsetzung der Manahme
b) = Verantwortlich fr die Kontrolle der Umsetzung
- Budgetrahmen: Fr die Realisierung der Manahme stehen zur Verfgung
a) = einmalige Investitionskosten
b) = einmaliger Personalaufwand (AT = Arbeitstage)
c) = wiederkehrende Investitionskosten
d) = wiederkehrender Personalaufwand (AT = Arbeitstage)
_________________________________________________________________________________________
IT-Grundschutz-Zertifikat 2.7
_________________________________________________________________________________________
2.7 IT-Grundschutz-Zertifikat
Aufgrund hufiger Anfragen, ob fr einen IT-Verbund, in
dem die Standardsicherheitsmanahmen nach IT-
Grundschutz umgesetzt sind, ein Zertifikat erlangt
werden kann, wird dieses Thema im BSI aufgegriffen.
Dabei sind die Interessen an einem IT-Grundschutz-
Zertifikat vielfltig:
- IT-Dienstleister mchten mit Hilfe dieses Zertifikats
einen vertrauenswrdigen Nachweis fhren, dass sie
die Manahmen nach dem IT-Grundschutzhandbuch
realisiert haben.
- Kooperierende Unternehmen mchten sich darber
informieren, welchen Grad von IT-Sicherheit ihre Geschftspartner zusichern knnen.
- Von Institutionen, die an ein Netz neu angeschlossen werden, wird der Nachweis darber verlangt,
dass sie eine ausreichende IT-Sicherheit besitzen, damit durch den Anschluss ans Netz keine
untragbaren Risiken entstehen.
- Unternehmen und Behrden mchten dem Kunden bzw. Brger gegenber ihre Bemhungen um
eine ausreichende IT-Sicherheit deutlich machen.
Da das IT-Grundschutzhandbuch mit seinen Empfehlungen von Standardsicherheitsmanahmen
inzwischen einen Quasi-Standard fr IT-Sicherheit darstellt, bietet es sich an, dies als allgemein aner-
kanntes Kriterienwerk fr IT-Sicherheit zu verwenden.
Das IT-Grundschutz-Zertifikat wird eine Institution fr einen ausgewhlten IT-Verbund erlangen
knnen, wenn eine unabhngige akkreditierte Stelle mittels eines Basis-Sicherheitschecks nachweisen
kann, dass die erforderlichen Standardsicherheitsmanahmen nach IT-Grundschutz realisiert sind. Die
Vorgehensweise entspricht dabei der in den Kapitel 2.1 bis 2.4 dargestellten Weise. Da bei der Durch-
fhrung des Basis-Sicherheitschecks zustzlich ein Sicherheitskonzept nach IT-Grundschutz als
Zwischenergebnis erstellt wird, ist die Weiterverwendbarkeit der im Zertifizierungsprozess generierten
Unterlagen sichergestellt.
Natrlich kann nicht ausgeschlossen werden, dass das Ergebnis des Basis-Sicherheitschecks die
Erteilung eines Zertifikats nicht zulsst. Fr diesen Fall wird berlegt, der Institution die Mglichkeit
einzurumen, ihre Bemhungen im IT-Sicherheitsprozess nach IT-Grundschutz zur Erlangung eines
IT-Grundschutz-Zertifikats ffentlich kund zu tun. Es ist vorgesehen, dass eine Institution im Rahmen
einer Selbsterklrung verffentlichen kann, dass sie eine noch zu definierende Einstiegsstufe
(Mindestniveau) oder darauf aufsetzende Aufbaustufe (unterhalb des IT-Grundschutzniveaus) erreicht
hat und das IT-Grundschutz-Zertifikat nach Umsetzung der fehlenden Manahmen anstrebt.
Nhere Informationen zum Diskussionsstand "IT-Grundschutz-Zertifikat" befinden sich auf dem BSI-
Server unter http://www.bsi.bund.de/gshb.
_________________________________________________________________________________________
IT-Grundschutz bergeordneter Komponenten 3
_________________________________________________________________________________________
3 IT-Grundschutz bergeordneter Komponenten

In diesem Kapitel werden bergeordnete oder grundlegende IT-Grundschutzmanahmen zu folgenden
Themen vorgestellt.
3.1 Organisation
3.2 Personal
3.5 Datenschutz
3.7 Kryptokonzept
3.8 Behandlung von Sicherheitsvorfllen
3.10 Outsourcing
_________________________________________________________________________________________
IT-Sicherheitsmanagement 3.0
_________________________________________________________________________________________
Beschreibung
Im Gleichklang mit den wachsenden Anforderungen an
die Informationstechnik ist auch deren Komplexitt
stndig gewachsen. Ein angemessenes IT-Sicherheits-
niveau kann daher in zunehmendem Mae nur durch
geplantes und organisiertes Vorgehen aller Beteiligten
durchgesetzt und aufrechterhalten werden. Voraussetzung
fr die sinnvolle Umsetzung und Erfolgskontrolle von IT-
Sicherheitsmanahmen ist somit ein durchdachter und
gesteuerter IT-Sicherheitsprozess. Diese Planungs- und
Lenkungsaufgabe wird als IT-Sicherheitsmanagement
bezeichnet. Die Etablierung eines funktionierenden IT-Sicherheitsmanagements steht notwendiger-
weise am Anfang des IT-Sicherheitsprozesses.
Ein funktionierendes IT-Sicherheitsmanagement muss in die existierenden Managementstrukturen
einer jeden Organisation eingebettet werden. Daher ist es praktisch nicht mglich, eine fr jede
Organisation unmittelbar anwendbare IT-Sicherheitsmanagement-Struktur anzugeben, vielmehr
werden hufig Anpassungen an organisationspezifische Gegebenheiten erforderlich sein.
In diesem Kapitel soll ein systematischer Weg aufgezeigt werden, wie ein funktionierendes IT-Sicher-
heitsmanagement eingerichtet und im laufenden Betrieb weiterentwickelt werden kann. Die darge-
stellte Vorgehensweise soll dabei insofern Mustercharakter haben, als sich spezifische Ausprgungen
an ihr orientieren knnen.
Anmerkung: In einigen anderen Kapiteln dieses Handbuchs wird der Begriff IT-Sicherheitsmanage-
ment auch als Bezeichnung fr das IT-Sicherheitsmanagement-Team verwendet, also fr diejenige
Personengruppe, die fr den IT-Sicherheitsprozess innerhalb einer Organisation verantwortlich ist.
Gefhrdungslage
Gefhrdungen im Umfeld des IT-Sicherheitsmanagements knnen vielfltiger Natur sein. Stellver-
tretend fr diese Vielzahl der Gefhrdungen wird in diesem Kapitel die folgende typische Gefhrdung
betrachtet:
Organisatorischer Mngel:
- G 2.66 Unzureichendes IT-Sicherheitsmanagement
Manahmenempfehlungen
Zuerst ist in jedem Fall Manahme M 2.191 Etablierung des IT-Sicherheitsprozesses bearbeiten. Diese
Manahme beschreibt eine Vorgehensweise, wie ein vollstndiger IT-Sicherheitsprozess initiiert und
realisiert wird. Es werden dazu notwendige Schritte und Aktivitten beschrieben, die wiederum in den
nachfolgenden Manahmen ausfhrlich behandelt werden.
Nachfolgend wird das Manahmenbndel fr den Bereich "IT-Sicherheitsmanagement" vorgestellt.
Organisation:
- M 2.191 (1) Etablierung des IT-Sicherheitsprozesses
- M 2.192 (1) Erstellung einer IT-Sicherheitsleitlinie
- M 2.193 (1) Aufbau einer geeigneten Organisationsstruktur fr IT-Sicherheit
- M 2.194 (1) Erstellung einer bersicht ber vorhandene IT-Systeme
- M 2.195 (1) Erstellung eines IT-Sicherheitskonzepts
_________________________________________________________________________________________
IT-Sicherheitsmanagement 3.0
_________________________________________________________________________________________
- M 2.196 (1) Umsetzung des IT-Sicherheitskonzepts nach einem Realisierungsplan

- M 2.197 (2) Erstellung eines Schulungskonzepts fr IT-Sicherheit
- M 2.198 (2) Sensibilisierung der Mitarbeiter fr IT-Sicherheit
- M 2.199 (1) Aufrechterhaltung der IT-Sicherheit
- M 2.200 (1) Erstellung von Managementreports zur IT-Sicherheit
- M 2.201 (2) Dokumentation des IT-Sicherheitsprozesses
- M 2.202 (2) Erstellung eines Handbuchs zur IT-Sicherheit (optional)
- M 2.203 (3) Aufbau einer Informationsbrse zur IT-Sicherheit (optional)
_________________________________________________________________________________________
Organisation 3.1
_________________________________________________________________________________________
3.1 Organisation
Beschreibung
In diesem Kapitel werden allgemeine und bergreifende
Manahmen im Organisationsbereich aufgefhrt, die als
organisatorische Standardmanahmen zur Erreichung
eines Mindestschutzniveaus erforderlich sind. Spezielle
Manahmen organisatorischer Art, die in unmittelbarem
Zusammenhang mit anderen Manahmen stehen (z. B.
LAN-Administration), werden in den entsprechenden
Kapiteln aufgefhrt. Auf das ordnungsgeme
Management informationstechnischer Komponenten
(Hardware oder Software) ausgerichtete Standard-
Sicherheits-Manahmen befinden sich im Kapitel 3.9.
Gefhrdungslage
In diesem Kapitel werden fr den IT-Grundschutz die folgenden typischen Gefhrdungen betrachtet:
- G 2.1 Fehlende oder unzureichende Regelungen
- G 2.2 Unzureichende Kenntnis ber Regelungen
- G 2.3 Fehlende, ungeeignete, inkompatible Betriebsmittel
- G 2.5 Fehlende oder unzureichende Wartung
- G 2.6 Unbefugter Zutritt zu schutzbedrftigen Rumen
- G 2.7 Unerlaubte Ausbung von Rechten
- G 2.8 Unkontrollierter Einsatz von Betriebsmitteln
Zur Realisierung des IT-Grundschutzes wird empfohlen, die notwendigen Manahmenbndel
("Bausteine") wie in Kapitel 2.3 und 2.4 beschrieben auszuwhlen.
Nachfolgend wird das Manahmenbndel fr den Bereich "Organisation" vorgestellt:
Organisation:
- M 2.1 (2) Festlegung von Verantwortlichkeiten und Regelungen fr den IT-Einsatz
- M 2.2 (2) Betriebsmittelverwaltung
- M 2.4 (2) Regelungen fr Wartungs- und Reparaturarbeiten
- M 2.5 (1) Aufgabenverteilung und Funktionstrennung
- M 2.6 (1) Vergabe von Zutrittsberechtigungen
- M 2.7 (1) Vergabe von Zugangsberechtigungen
- M 2.8 (1) Vergabe von Zugriffsrechten
- M 2.13 (2) Ordnungsgeme Entsorgung von schtzenswerten Betriebsmitteln
- M 2.14 (2) Schlsselverwaltung
- M 2.37 (2) "Der aufgerumte Arbeitsplatz"
- M 2.39 (2) Reaktion auf Verletzungen der Sicherheitspolitik
- M 2.40 (2) Rechtzeitige Beteiligung des Personal-/Betriebsrates
- M 2.177 (2) Sicherheit bei Umzgen
- M 2.225 (2) Zuweisung der Verantwortung fr Informationen, Anwendungen und IT-
Komponenten
_________________________________________________________________________________________
Personal 3.2
_________________________________________________________________________________________
3.2 Personal
Beschreibung
In diesem Kapitel werden die bergeordneten IT-Grund-
schutzmanahmen erlutert, die im Bereich Personal-
wesen standardmig durchgefhrt werden sollten.
Beginnend mit der Einstellung von Mitarbeitern bis hin
zu deren Ausscheiden ist eine Vielzahl von Manahmen
erforderlich. Personelle Manahmen, die an eine
bestimmte Funktion gebunden sind wie z. B. die
Ernennung des Systemadministrators eines LAN, werden
in den IT-spezifischen Kapiteln angefhrt.
Gefhrdungslage
Hhere Gewalt:
- G 1.1 Personalausfall
Organisatorische Mngel
Menschliche Fehlhandlungen:
- G 3.1 Vertraulichkeits-/Integrittsverlust von Daten durch Fehlverhalten der IT-Benutzer
- G 3.2 Fahrlssige Zerstrung von Gert oder Daten
- G 3.3 Nichtbeachtung von IT-Sicherheitsmanahmen
- G 3.8 Fehlerhafte Nutzung des IT-Systems
Vorstzliche Handlungen:
- G 5.1 Manipulation/Zerstrung von IT-Gerten oder Zubehr
- G 5.2 Manipulation an Daten oder Software
- G 5.42 Social Engineering
- G 5.104 Aussphen von Informationen
Nachfolgend wird das Manahmenbndel fr den Bereich "Personal" vorgestellt:
Personal:
- M 3.1 (1) Geregelte Einarbeitung/Einweisung neuer Mitarbeiter

- M 3.2 (2) Verpflichtung der Mitarbeiter auf Einhaltung einschlgiger Gesetze, Vorschriften
und Regelungen
- M 3.3 (1) Vertretungsregelungen
- M 3.4 (1) Schulung vor Programmnutzung
- M 3.5 (1) Schulung zu IT-Sicherheitsmanahmen
- M 3.6 (2) Geregelte Verfahrensweise beim Ausscheiden von Mitarbeitern
- M 3.7 (3) Anlaufstelle bei persnlichen Problemen (optional)
- M 3.8 (3) Vermeidung von Strungen des Betriebsklimas (optional)
_________________________________________________________________________________________
IT-Grundschutzhandbuch: 4. EL Stand Mai 2002 89
Notfallvorsorge-Konzept 3.3
_________________________________________________________________________________________
Beschreibung
Die Notfallvorsorge umfasst Manahmen, die auf die
Wiederherstellung der Betriebsfhigkeit nach (technisch
bedingtem bzw. durch fahrlssige oder vorstzliche
Handlungen herbeigefhrten) Ausfall eines IT-Systems
ausgerichtet sind. Abhngig vom Zeitpunkt der
Realisierung dieser Manahmen lassen sich vier Phasen
der Notfallvorsorge unterscheiden:
Phase 1: Planung der Notfallvorsorge

In dieser Phase werden die individuell fr ein IT-System geeigneten und wirtschaftlich
angemessenen Manahmen identifiziert. Es wird festgelegt, welche Manahmen whrend des
Betriebes eines IT-Systems (z. B. Rauchverbot, unterbrechungsfreie Stromversorgung, Wartung,
Datensicherung) durchzufhren sind, damit ein Notfall verhindert bzw. der Schaden aufgrund eines
Notfalls vermindert wird. Darber hinaus wird in Notfallplnen, die Bestandteile eines
Notfallhandbuchs sind, festgeschrieben, welche Manahmen bei Eintreten eines Notfalls
durchgefhrt werden mssen.
Phase 2: Umsetzung der den IT-Betrieb begleitenden Notfallvorsorgemanahmen
In Phase 2 werden die Notfallvorsorgemanahmen realisiert und aufrechterhalten, die schon vor
Eintritt eines Notfalls durchgefhrt sein mssen, um die Eintrittswahrscheinlichkeit eines Notfalls
zu verringern oder um eine zgige und wirtschaftliche Wiederherstellung der Betriebsfhigkeit zu
ermglichen.
Phase 3: Durchfhrung von Notfallbungen
Von besonderer Bedeutung ist die Durchfhrung von Notfallbungen zeitgleich zu Phase 2, um die
Umsetzung der im Notfall-Handbuch aufgefhrten Manahmen einzuben und deren Effizienz zu
steigern.
Phase 4: Umsetzung geplanter Manahmen nach Eintreten eines Notfalls
Ist autorisiert entschieden worden, dass ein Notfall vorliegt, so sind die fr diesen Fall geplanten
und im Notfall-Handbuch niedergelegten Manahmen unverzglich umzusetzen.
Um eine unter Wirtschaftlichkeitsgesichtspunkten angemessene Notfallvorsorge betreiben zu knnen,
mssen die entstehenden Kosten dem potentiellen Schaden (Kosten aufgrund mangelnder
Verfgbarkeit im Notfall) gegenbergestellt und bewertet werden. Als Kosten sind zu betrachten:
- Kosten fr die Erstellung eines Notfallvorsorgekonzeptes,
- Kosten fr die Realisierung und Aufrechterhaltung der den IT-Betrieb begleitenden
Notfallvorsorgemanahmen,
- Kosten fr Notfallbungen und
- Kosten fr die Wiederherstellung der Betriebsfhigkeit.
_________________________________________________________________________________________
Notfallvorsorge-Konzept 3.3
_________________________________________________________________________________________
In diesem Kapitel soll ein systematischer Weg aufgezeigt werden, wie ein Notfall-Handbuch erstellt
und dessen Anwendung gebt werden kann. Damit sind Teile der Phase 1 und die Phasen 3 und 4
betroffen. Die in Phase 2 umzusetzenden Manahmen setzen eine individuelle Betrachtung des IT-
Systems und der Einsatzumgebung voraus. Diese Manahmen werden in den jeweiligen umfeld- und
systemspezifischen Bausteinen dieses Handbuchs behandelt.
Der Aufwand zur Erstellung eines Notfallhandbuchs einschlielich der notwendigen begleitenden
Manahmen ist betrchtlich. Daher kann dieses Kapitel insbesondere fr
- IT-Systeme mit hohen Verfgbarkeitsanforderungen,
- grere IT-Systeme (Grorechner, groe Unix-Systeme, umfangreiche Netze) oder
- eine grere Anzahl rumlich konzentrierter IT-Systeme
sinnvoll eingesetzt werden.
Gefhrdungslage
In diesem Kapitel wird fr den IT-Grundschutz die Gefhrdung
- G 1.2 Ausfall des IT-Systems
stellvertretend fr alle Gefhrdungen betrachtet, durch die ein Ausfall herbeigefhrt werden kann.
Die Bearbeitung der Manahmen sollte in der angegebenen Reihenfolge geschehen, um systematisch
ein Notfall-Handbuch zu erarbeiten.
Notfallvorsorge:
- M 6.1 (2) Erstellung einer bersicht ber Verfgbarkeitsanforderungen
- M 6.2 (2) Notfall-Definition, Notfall-Verantwortlicher
- M 6.3 (2) Erstellung eines Notfall-Handbuches
- M 6.4 (2) Dokumentation der Kapazittsanforderungen der IT-Anwendungen
- M 6.5 (2) Definition des eingeschrnkten IT-Betriebs
- M 6.6 (2) Untersuchung interner und externer Ausweichmglichkeiten
- M 6.7 (2) Regelung der Verantwortung im Notfall
- M 6.8 (1) Alarmierungsplan
- M 6.9 (1) Notfall-Plne fr ausgewhlte Schadensereignisse
- M 6.10 (2) Notfall-Plan fr DF-Ausfall
- M 6.11 (2) Erstellung eines Wiederanlaufplans
- M 6.12 (1) Durchfhrung von Notfallbungen
- M 6.13 (2) Erstellung eines Datensicherungsplans
- M 6.14 (3) Ersatzbeschaffungsplan
- M 6.15 (3) Lieferantenvereinbarungen (optional)
- M 6.16 (2) Abschlieen von Versicherungen (optional)
- M 6.75 (2) Redundante Kommunikationsverbindungen (optional)
_________________________________________________________________________________________
Datensicherungskonzept 3.4
_________________________________________________________________________________________
Beschreibung
Durch technisches Versagen, versehentliches Lschen
oder durch Manipulation knnen gespeicherte Daten
unbrauchbar werden bzw. verloren gehen. Eine
Datensicherung soll gewhrleisten, dass durch einen
redundanten Datenbestand der IT-Betrieb kurzfristig
wiederaufgenommen werden kann, wenn Teile des
operativen Datenbestandes verloren gehen.
Die Konzeption einer angemessenen und
funktionstchtigen Datensicherung bedarf allerdings
aufgrund der Komplexitt einer geordneten Vorgehensweise. In diesem Kapitel wird ein Weg
beschrieben, wie fr ein IT-System ein Datensicherungskonzept erstellt werden kann.
Gefhrdungslage
Fr die mittels eines Datensicherungskonzepts zu schtzenden Daten wird fr den IT-Grundschutz
folgende typische Gefhrdung angenommen:
Technisches Versagen:
- G 4.13 Verlust gespeicherter Daten
Nachfolgend wird das Manahmenbndel fr den Bereich "Datensicherungskonzept" vorgestellt, das
vor allem fr grere IT-Systeme oder IT-Systeme mit groem Datenvolumen sinnvoll ist. Die
Bearbeitung der Manahmen sollte in der angegebenen Reihenfolge geschehen, um systematisch ein
Datensicherungskonzept zu erarbeiten.
Notfallvorsorge:
- M 6.33 (2) Entwicklung eines Datensicherungskonzepts (optional)
- M 6.34 (2) Erhebung der Einflussfaktoren der Datensicherung (optional)
- M 6.35 (2) Festlegung der Verfahrensweise fr die Datensicherung (optional)
- M 6.36 (1) Festlegung des Minimaldatensicherungskonzeptes
- M 6.37 (2) Dokumentation der Datensicherung
- M 6.41 (1) bungen zur Datenrekonstruktion
Organisation:
- M 2.41 (2) Verpflichtung der Mitarbeiter zur Datensicherung
- M 2.137 (2) Beschaffung eines geeigneten Datensicherungssystems
_________________________________________________________________________________________
IT-Grundschutzhandbuch: Stand Juli 1999 93
Datenschutz 3.5
_________________________________________________________________________________________
3.5 Datenschutz
Beschreibung
Aufgabe des Datenschutzes ist es, den einzelnen davor zu
schtzen, dass er durch den Umgang mit seinen
personenbezogenen Daten in seinem Recht beeintrchtigt
wird, selbst ber die Preisgabe und Verwendung seiner
Daten zu bestimmen ("informationelles Selbstbestim-
mungsrecht").
Aufgrund der engen Verflechtung von Datenschutz und
IT-Sicherheit sollte es Ziel eines IT-Grundschutzkapitels
zum Thema "Datenschutz" sein, einerseits die Rahmen-
bedingungen fr den Datenschutz praxisgerecht aufzubereiten und andererseits die Verbindung zur IT-
Sicherheit ber den IT-Grundschutz aufzubauen.
Ein Vorschlag fr ein solches IT-Grundschutzkapitel "Datenschutz" wurde federfhrend vom
Bundesbeauftragten fr den Datenschutz gemeinsam mit dem Arbeitskreis Technik der
Datenschutzbeauftragten des Bundes und der Lnder erstellt. Es richtet sich an die ffentlichen Stellen
des Bundes und der Lnder, die privaten Anbieter von Telekokmmunikationsdiensten und
Postdienstleistungen.
Dieser Vorschlag kann beim Bundesbeauftragten fr den Datenschutz per E-Mail angefordert werden
unter der Adresse:
poststelle@bfd.bund.de
Darber hinaus kann dieser Vorschlag auch auf dem Internet-Server des Bundesbeauftragten fr den
Datenschutz unter der Adresse www.bfd.bund.de nachgelesen werden. In Vorbereitung befindet sich
darber hinaus eine Download-Mglichkeit dieses Vorschlagkapitels, das fr die Lose-Blattsammlung
des IT-Grundschutzhandbuchs vorformatiert ist.
_________________________________________________________________________________________
Computer-Virenschutzkonzept 3.6
_________________________________________________________________________________________
Beschreibung
Ziel eines Computer-Virenschutzkonzeptes ist es, ein
geeignetes Manahmenbndel zusammenzustellen, bei
dessen Einsatz das Auftreten von Computer-Viren auf
den in einer Organisation eingesetzten IT-Systemen ver-
hindert bzw. mglichst frh erkannt wird, um Gegen-
manahmen vornehmen zu knnen und evtl. mgliche
Schden zu minimieren. Wesentlicher Aspekt des
Schutzes vor Computer-Viren ist die konsequente
Aufrechterhaltung der Manahmen und die stndige
Aktualisierung technischer Gegenmanahmen. Diese
Forderung begrndet sich durch die permanent neu auftauchenden Computer-Viren oder deren
Varianten. Auch durch die Weiterentwicklung von Betriebssystemen, Programmiersprachen und
Anwendungssoftware mssen die sich hieraus ergebenden mglichen Angriffspotentiale fr
Computer-Viren beachtet werden und rechtzeitig geeignete Gegenmanahmen eingeleitet werden.
Da in Behrden oder Unternehmen Rechner in zunehmendem Mae in lokale Netze integriert werden
oder ein Anschluss an ffentliche Kommunikationsnetze erfolgt, werden ber die Weitergabe ber
Disketten hinaus zustzliche Schnittstellen geschaffen, ber die eine Infektion mit Computer-Viren
erfolgen kann. Dies erfordert es oftmals, dass eine permanente Kontrolle der eingesetzten Rechner auf
Computer-Viren vorgenommen wird.
Um fr eine Gesamtorganisation einen effektiven Computer-Virenschutz zu erreichen, wird in diesem
Kapitel die Vorgehensweise zur Erstellung und Realisierung eines Viren-Schutzkonzeptes in einzelnen
Schritten erlutert. Manahmenempfehlungen zum Computer-Virenschutz fr einzelne IT-Systeme
finden sich in den entsprechenden Kapiteln 5 und 6.
Gefhrdungslage
Fr den IT-Grundschutz werden bezglich Computer-Viren die folgenden typischen Gefhrdungen
betrachtet:
Organisatorische Mngel:
- G 2.4 Unzureichende Kontrolle der IT-Sicherheitsmanahmen
- G 2.9 Mangelhafte Anpassung an Vernderungen beim IT-Einsatz
- G 2.26 Fehlendes oder unzureichendes Test- und Freigabeverfahren
- G 5.21 Trojanische Pferde
- G 5.23 Computer-Viren
- G 5.43 Makro-Viren
- G 5.80 Hoax
_________________________________________________________________________________________
Computer-Virenschutzkonzept 3.6
_________________________________________________________________________________________
Bei der Erstellung eines Computer-Viren-Schutzkonzepts (vgl.M 2.154 Erstellung eines Computer-
Virenschutzkonzept,) muss zunchst ermittelt werden, welche der vorhandenen oder geplanten IT-
Systeme in das Computer-Viren-Schutzkonzept einzubeziehen sind (siehe M 2.155 Identifikation
potentiell von Computer-Viren betroffener IT-Systeme). Fr diese IT-Systeme mssen die fr die
Umsetzung von Sicherheitsmanahmen relevanten Einflussfaktoren betrachtet werden. Darauf aufbau-
end knnen dann die technischen und organisatorischen Manahmen ausgewhlt werden. Hierzu ist
insbesondere die Auswahl geeigneter technischer Gegenmanahmen wie Computer-Viren-Suchpro-
gramme zu beachten (siehe M 2.156 Auswahl einer geeigneten Computer-Virenschutz-Strategie und
,M 2.157 Auswahl eines geeigneten Computer-Viren-Suchprogramms). Neben der Einrichtung eines
Meldewesens (vgl. M 2.158 Meldung von Computer-Virusinfektionen) und der Koordinierung der
Aktualisierung eingesetzter Schutzprodukte (vgl. M 2.159 Aktualisierung der eingesetzten Computer-
Viren-Suchprogramme) sind fr die Umsetzung des Konzeptes eine Reihe von Regelungen zu verein-
baren (vgl. M 2.11 Regelung des Passwortgebrauchs), in denen zustzlich notwendige Manahmen
zum Virenschutz festgelegt werden.
Eine der wichtigsten Vorbeugemanahmen gegen Schden durch Computer-Viren ist die regelmige
Datensicherung (siehe M 6.32 Regelmige Datensicherung).
Zur Realisierung des IT-Grundschutzes wird empfohlen, die notwendigen Manahmebndel ("Bau-
steine") wie in Kapitel 2.3 und 2.4 beschrieben auszuwhlen. Als zustzliche Literatur ist Band 2 der
Schriftenreihe zur IT-Sicherheit des Bundesamtes fr Sicherheit in der Informationstechnik "
Informationen zu Computer-Viren" zu empfehlen.
Organisation:
- M 2.9 (3) Nutzungsverbot nicht freigegebener Hard- und Software
- M 2.10 (3) berprfung des Hard- und Software-Bestandes
- M 2.34 (2) Dokumentation der Vernderungen an einem bestehenden System
- M 2.35 (2) Informationsbeschaffung ber Sicherheitslcken des Systems
- M 2.154 (1) Erstellung eines Computer-Virenschutzkonzepts
- M 2.155 (2) Identifikation potentiell von Computer-Viren betroffener IT-Systeme
- M 2.156 (2) Auswahl einer geeigneten Computer-Virenschutz-Strategie
- M 2.157 (2) Auswahl eines geeigneten Computer-Viren-Suchprogramms
- M 2.158 (2) Meldung von Computer-Virusinfektionen
- M 2.159 (2) Aktualisierung der eingesetzten Computer-Viren-Suchprogramme
- M 2.160 (2) Regelungen zum Computer-Virenschutz
Personal:
Hardware/Software:
- M 4.3 (2) Regelmiger Einsatz eines Viren-Suchprogramms
- M 4.33 (2) Einsatz eines Viren-Suchprogramms bei Datentrgeraustausch und
Datenbertragung
- M 4.44 (2) Prfung eingehender Dateien auf Makro-Viren
- M 4.84 (2) Nutzung der BIOS-Sicherheitsmechanismen
Notfallvorsorge:
- M 6.23 (2) Verhaltensregeln bei Auftreten eines Computer-Virus
- M 6.24 (2) Erstellen einer PC-Notfalldiskette
- M 6.32 (1) Regelmige Datensicherung
_________________________________________________________________________________________
Kryptokonzept 3.7
_________________________________________________________________________________________
3.7 Kryptokonzept
Beschreibung
Dieser Baustein beschreibt eine Vorgehensweise, wie in
einer heterogenen Umgebung sowohl die lokal gespei-
cherten Daten als auch die zu bertragenen Daten
wirkungsvoll durch kryptographische Verfahren und
Techniken geschtzt werden knnen. Dazu wird
beschrieben, wie und wo in einer heterogenen Umgebung
kryptographische Verfahren und die entsprechenden
Komponenten eingesetzt werden knnen. Da beim Ein-
satz kryptographischer Verfahren sehr viele komplexe
Einflussfaktoren zu betrachten sind, sollte hierfr ein
Kryptokonzept erstellt werden.
In diesem Baustein wird daher beschrieben, wie ein Kryptokonzept erstellt werden kann. Beginnend
mit der Bedarfsermittlung und der Erhebung der Einflussfaktoren geht es ber die Auswahl geeigneter
kryptographischer Lsungen und Produkte bis hin zur Sensibilisierung und Schulung der Anwender
und zur Krypto-Notfallvorsorge.
Dieser Baustein kann auch herangezogen werden, wenn nur ein kryptographisches Produkt fr eines
der mglichen Einsatzfelder ausgewhlt werden soll. Dann knnen einige der im folgenden beschrie-
benen Schritte ausgelassen werden und nur die fr das jeweilige Einsatzfeld relevanten Teile bearbei-
tet werden.
Fr die Umsetzung dieses Bausteins sollte ein elementares Verstndnis der grundlegenden krypto-
graphischen Mechanismen vorhanden sein. Ein berblick ber kryptographische Grundbegriffe findet
sich in M 3.23 Einfhrung in kryptographische Grundbegriffe.
Gefhrdungslage
Kryptographische Verfahren werden eingesetzt zur Gewhrleistung von
- Vertraulichkeit,
- Integritt,
- Authentizitt und
- Nichtabstreitbarkeit.
Daher werden fr den IT-Grundschutz primr die folgenden Gefhrdungen fr kryptographische
Verfahren betrachtet:
- G 4.33 Schlechte oder fehlende Authentikation
- G 5.85 Integrittsverlust schtzenswerter Informationen
- G 5.27 Nichtanerkennung einer Nachricht
- G 5.71 Vertraulichkeitsverlust schtzenswerter Informationen
Werden kryptographische Verfahren eingesetzt, sollten fr den IT-Grundschutz zustzlich folgende
Gefhrdungen betrachtet werden:
- G 2.19 Unzureichendes Schlsselmanagement bei Verschlsselung
_________________________________________________________________________________________
Kryptokonzept 3.7
_________________________________________________________________________________________
- G 3.32 Versto gegen rechtliche Rahmenbedingungen beim Einsatz von
kryptographischen Verfahren
- G 3.33 Fehlbedienung von Kryptomodulen
- G 4.22 Software-Schwachstellen oder -Fehler
- G 4.34 Ausfall eines Kryptomoduls
- G 4.35 Unsichere kryptographische Algorithmen
- G 4.36 Fehler in verschlsselten Daten
- G 5.81 Unautorisierte Benutzung eines Kryptomoduls
- G 5.82 Manipulation eines Kryptomoduls
- G 5.83 Kompromittierung kryptographischer Schlssel
- G 5.84 Geflschte Zertifikate
Darber hinaus sind im Bereich kryptographische Verfahren im wesentlichen die folgenden Schritte
durchzufhren:
1. Entwicklung eines Kryptokonzepts (siehe M 2.161 Entwicklung eines Kryptokonzepts)
Der Einsatz kryptographischer Verfahren wird von einer groen Zahl von Einflussfaktoren
bestimmt. Das IT-System, das Datenvolumen, das angestrebte Sicherheitsniveau und die Verfg-
barkeitsanforderungen sind einige dieser Faktoren. Daher sollte zunchst ein Konzept entwickelt
werden, in dem alle Einflussgren und Entscheidungskriterien fr die Wahl eines konkreten
kryptographischen Verfahrens und der entsprechenden Produkte bercksichtigt werden und das
gleichzeitig unter Kostengesichtspunkten wirtschaftlich vertretbar ist.
2. Ermittlung der Anforderungen an die kryptographischen Verfahren
Es muss ein Anforderungskatalog erstellt werden, in dem die Einflussgren und die Entschei-
dungskriterien beschrieben werden, die einem Einsatz von kryptographischen Verfahren zugrunde
liegen (siehe M 2.162 Bedarfserhebung fr den Einsatz kryptographischer Verfahren und Produkte
und M 2.163 Erhebung der Einflussfaktoren fr kryptographische Verfahren und Produkte).
Kryptographische Verfahren knnen auf den verschiedenen Schichten des ISO/OSI-Schichten-
modells eingesetzt werden. Je nach den festgestellten Anforderungen oder Gefhrdungen ist der
Einsatz auf bestimmten Schichten zu empfehlen (siehe auch M 4.90 Einsatz von kryptographischen
Verfahren auf den verschiedenen Schichten des ISO/OSI-Referenzmodells).
3. Auswahl geeigneter kryptographischer Verfahren (siehe M 2.164 Auswahl eines geeigneten
kryptographischen Verfahrens)
Bei der Auswahl von kryptographischen Verfahren steht zunchst die Frage, ob symmetrische,
asymmetrische oder hybride Algorithmen geeignet sind, im Vordergrund und dann die Mechanis-
menstrke. Anschlieend sind geeignete Produkte zu bestimmen.
_________________________________________________________________________________________
Kryptokonzept 3.7
_________________________________________________________________________________________
4. Auswahl eines geeigneten kryptographischen Produktes (siehe M 2.165 Auswahl eines geeigneten
kryptographischen Produktes )
Nachdem alle Rahmenbedingungen bestimmt worden sind, muss ein Produkt ausgewhlt werden,
das die im Kryptokonzept dargelegte Sicherheitsfunktionalitt bietet. Ein solches Produkt, im fol-
genden kurz Kryptomodul genannt, kann dabei aus Hardware, Software, Firmware oder aus einer
diesbezglichen Kombination sowie der zur Durchfhrung der Kryptoprozesse notwendigen Bau-
teilen wie Speicher, Prozessoren, Busse, Stromversorgung etc. bestehen. Ein Kryptomodul kann
zum Schutz von sensiblen Daten bzw. Informationen in unterschiedlichsten Rechner- oder Tele-
kommunikationssystemen Verwendung finden.
5. Geeigneter Einsatz der Kryptomodule (siehe M 2.166 Regelung des Einsatzes von Kryptomodulen)
Auch im laufenden Betrieb mssen eine Reihe von Sicherheitsanforderungen an ein Kryptomodul
gestellt werden. Neben der Sicherheit der durch das Kryptomodul zu schtzenden Daten geht es
schwerpunktmig auch darum, das Kryptomodul selbst gegen unmittelbare Angriffe und Fremd-
einwirkung zu schtzen.
6. Die sicherheitstechnischen Anforderungen an die IT-Systeme, auf denen die kryptographischen
Verfahren eingesetzt werden, sind den jeweiligen systemspezifischen Bausteinen zu entnehmen. So
finden sich die Bausteine fr Clients (inkl. Laptops) in Kapitel 5, die fr Server in Kapitel 6.
7. Notfallvorsorge, hierzu gehren
- die Datensicherung bei Einsatz kryptographischer Verfahren (siehe M 6.56 Datensicherung
bei Einsatz kryptographischer Verfahren), also die Sicherung der Schlssel, der
Konfigurationsdaten der eingesetzten Produkte, der verschlsselten Daten,
- die Informationsbeschaffung ber sowie die Reaktion auf Sicherheitslcken.
Nachfolgend wird das Manahmenbndel fr den Bereich "Kryptokonzept" vorgestellt. Auf eine
Wiederholung von Manahmen anderer Kapitel wird hier verzichtet.
Organisation:
- M 2.39 (2) Reaktion auf Verletzungen der Sicherheitspolitik
- M 2.46 (2) Geeignetes Schlsselmanagement
- M 2.161 (1) Entwicklung eines Kryptokonzepts
- M 2.162 (1) Bedarfserhebung fr den Einsatz kryptographischer Verfahren und Produkte
- M 2.163 (1) Erhebung der Einflussfaktoren fr kryptographische Verfahren und Produkte
- M 2.164 (1) Auswahl eines geeigneten kryptographischen Verfahrens
- M 2.165 (1) Auswahl eines geeigneten kryptographischen Produktes
- M 2.166 (1) Regelung des Einsatzes von Kryptomodulen
Personal:
- M 3.23 (1) Einfhrung in kryptographische Grundbegriffe
Hardware/Software:
- M 4.85 (3) Geeignetes Schnittstellendesign bei Kryptomodulen (optional)
- M 4.86 (2) Sichere Rollenteilung und Konfiguration der Kryptomodule
- M 4.87 (2) Physikalische Sicherheit von Kryptomodulen (optional)
- M 4.88 (2) Anforderungen an die Betriebssystem-Sicherheit beim Einsatz von Kryptomodulen
_________________________________________________________________________________________
Kryptokonzept 3.7
_________________________________________________________________________________________
- M 4.89 (3) Abstrahlsicherheit (optional)

- M 4.90 (3) Einsatz von kryptographischen Verfahren auf den verschiedenen Schichten des
Notfallvorsorge:
- M 6.56 (2) Datensicherung bei Einsatz kryptographischer Verfahren
Viele andere Bausteine enthalten Manahmen, die das Thema kryptographische Verfahren berhren
und die als Realisierungsbeispiele betrachtet werden knnen. Dazu gehren z. B.:
- M 4.29 Einsatz eines Verschlsselungsproduktes fr tragbare PCs
- M 4.30 Nutzung der in Anwendungsprogrammen angebotenen Sicherheitsfunktionen
- M 4.34 Einsatz von Verschlsselung, Checksummen oder Digitalen Signaturen
- M 4.41 Einsatz eines angemessenen PC-Sicherheitsproduktes
- M 4.72 Datenbank-Verschlsselung
- M 5.33 Absicherung der per Modem durchgefhrten Fernwartung
- M 5.34 Einsatz von Einmalpasswrtern
- M 5.36 Verschlsselung unter Unix und Windows NT
- M 5.50 Authentisierung mittels PAP/CHAP
- M 5.52 Sicherheitstechnische Anforderungen an den Kommunikationsrechner
- M 5.63 Einsatz von GnuPG oder PGP
- M 5.64 Secure Shell
- M 5.65 Einsatz von S-HTTP
- M 5.66 Verwendung von SSL
_________________________________________________________________________________________
Behandlung von Sicherheitsvorfllen 3.8
_________________________________________________________________________________________
3.8 Behandlung von

Sicherheitsvorfllen
Beschreibung
Um die IT-Sicherheit im laufenden Betrieb aufrecht zu
erhalten, ist es notwendig, die Behandlung von
Sicherheitsvorfllen (Incident Handling) konzipiert und
eingebt zu haben. Als Sicherheitsvorfall wird dabei ein
Ereignis bezeichnet, das Auswirkungen nach sich ziehen
kann, die einen groen Schaden anrichten knnen. Um
Schden zu verhten bzw. zu begrenzen, sollte die
Behandlung der Sicherheitsvorflle zgig und effizient
ablaufen. Wenn hierbei auf ein vorgegebenes Verfahren aufgesetzt werden kann, knnen
Reaktionszeiten minimiert werden. Die mglichen Schden bei einem Sicherheitsvorfall knnen dabei
sowohl die Vertraulichkeit oder Integritt von Daten als auch die Verfgbarkeit betreffen.
Ein besonderer Bereich der Behandlung von Sicherheitsvorfllen ist dabei das Notfallvorsorgekonzept
(vgl. Kapitel 3.3). In einem Notfallvorsorgekonzept wird konkret fr bestimmte IT-Systeme der
Ausfall kritischer Komponenten vorab analysiert und eine Vorgehensweise zur Aufrechterhaltung oder
Wiederherstellung der Verfgbarkeit festgelegt.
Sicherheitsvorflle knnen zum Beispiel ausgelst werden durch
- Benutzerfehlverhalten, das zu Datenverlust oder sicherheitskritischer nderung von
Systemparametern fhrt,
- Auftreten von Sicherheitslcken in Hard- oder Softwarekomponenten,
- massenhaftes Auftreten von Computer-Viren,
- Hacking von Internet-Servern,
- Offenlegung vertraulicher Daten,
- Personalausfall oder
- kriminelle Handlungen (etwa Einbruch, Diebstahl oder Erpressung mit IT-Bezug).
Alle Arten von Sicherheitsvorfllen mssen angemessen angegangen werden. Dies gilt sowohl fr
solche Sicherheitsvorflle, gegen die man sich konkret rsten kann, wie z. B. Computer-Viren, als
auch solche, die die Organisation unerwartet treffen.
In diesem Kapitel soll ein systematischer Weg aufgezeigt werden, wie ein Konzept zur Behandlung
von Sicherheitsvorfllen erstellt und wie dessen Umsetzung und Einbettung innerhalb eines
Unternehmens bzw. einer Behrde sichergestellt werden kann. Der Aufwand zur Erstellung und
Umsetzung eines solchen Konzepts ist nicht gering. Daher sollte dieses Kapitel vor allem bei greren
IT-Systemen und/oder solchen mit hoher Relevanz fr die Behrde bzw. das Unternehmen beachtet
werden.
Gefhrdungslage
Sicherheitsvorflle knnen durch eine Vielzahl von Gefhrdungen ausgelst werden. Eine groe
Sammlung von Gefhrdungen, die kleinere oder grere Sicherheitsvorflle verursachen knnen,
findet sich in den Gefhrdungskatalogen.
_________________________________________________________________________________________
IT-Grundschutzhandbuch: 1. EL Stand Januar 2000 101
Behandlung von Sicherheitsvorfllen 3.8
_________________________________________________________________________________________
Ein groer Schaden kann durch diese Gefhrdungen dann ausgelst werden, wenn dafr keine
angemessene Herangehensweise vorgesehen ist. In diesem Kapitel wird daher stellvertretend fr alle
Gefhrdungen, die sich im Umfeld von Sicherheitsvorfllen ereignen knnen, folgende Gefhrdung
betrachtet:
- G 2.62 Ungeeigneter Umgang mit Sicherheitsvorfllen
Um ein effektives System zur Behandlung von Sicherheitsvorfllen einzurichten, sind eine Reihe von
Schritten zu durchlaufen. Diese sind in der Manahme M 6.58 Etablierung eines Managementsystems
zur Behandlung von Sicherheitsvorfllen beschrieben und werden durch die daran anschlieenden
Manahmen erlutert. Daher sollte mit der Umsetzung der Manahme M 6.58 Etablierung eines
Managementsystems zur Behandlung von Sicherheitsvorfllen begonnen werden.
Nachfolgend wird das Manahmenbndel fr den Bereich "Behandlung von Sicherheitsvorfllen"
vorgestellt.
Notfallvorsorge:
- M 6.58 (1) Etablierung eines Managementsystems zur Behandlung von Sicherheitsvorfllen
- M 6.59 (1) Festlegung von Verantwortlichkeiten bei Sicherheitsvorfllen
- M 6.60 (1) Verhaltensregeln und Meldewege bei Sicherheitsvorfllen
- M 6.61 (1) Eskalationsstrategie fr Sicherheitsvorflle
- M 6.62 (1) Festlegung von Prioritten fr die Behandlung von Sicherheitsvorfllen
- M 6.63 (1) Untersuchung und Bewertung eines Sicherheitsvorfalls
- M 6.64 (1) Behebung von Sicherheitsvorfllen
- M 6.65 (1) Benachrichtigung betroffener Stellen
- M 6.66 (2) Nachbereitung von Sicherheitsvorfllen
- M 6.67 (2) Einsatz von Detektionsmanahmen fr Sicherheitsvorflle (optional)
- M 6.68 (2) Effizienzprfung des Managementsystems zur Behandlung von
Sicherheitsvorfllen
_________________________________________________________________________________________
Hard- und Software-Management 3.9
_________________________________________________________________________________________

Beschreibung
Um den notwendigen und erwnschten Sicherheitsgrad
fr die gesamte IT-Organisation zu erreichen, gengt es
nicht, nur die einzelnen IT-Komponenten zu sichern. Es
ist vielmehr erforderlich, auch alle Ablufe und Vor-
gnge, die diese IT-Systeme berhren, so zu gestalten,
dass das angestrebte IT-Sicherheitsniveau erreicht und
beibehalten wird. Es sind daher fr alle diese Vorgnge
Regelungen einzufhren und zu pflegen, die die Wirk-
samkeit der Sicherheitsmanahmen gewhrleisten.
Den Schwerpunkt dieses Bausteins bilden dabei
Regelungen, die sich spezifisch auf informationstechnische Hardware- oder Software-Komponenten
beziehen, mit dem Ziel, einen ordnungsgemen IT-Betrieb in Bezug auf Management bzw.
Organisation sicherzustellen. Sicherheit sollte integrierter Bestandteil des gesamten Lebenszyklus
eines IT-Systems bzw. eines Produktes sein.
Gefhrdungslage
- G 2.10 Nicht fristgerecht verfgbare Datentrger
- G 2.22 Fehlende Auswertung von Protokolldaten
- G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten
- G 3.44 Sorglosigkeit im Umgang mit Informationen
- G 4.43 Undokumentierte Funktionen
- G 5.4 Diebstahl
_________________________________________________________________________________________
_________________________________________________________________________________________
Ein IT-Verbund besteht aus einer Vielzahl von IT-Komponenten, die zunchst als Einzelkomponenten
gem der Manahmenvorschlge aus den entsprechenden Bausteinen abgesichert werden sollten.
Damit fr alle eingesetzten IT-Komponenten das gleiche Sicherheitsniveau erreicht wird, sollten durch
das Hard- und Software-Management einheitliche Regelungen vorgegeben werden.
Im Rahmen des Hard- und Software-Managements sind unabhngig von der Art der eingesetzten IT-
Komponenten eine Reihe von Manahmen umzusetzen, beginnend mit der Konzeption ber die
Beschaffung bis zum Betrieb. Die Schritte, die dabei zu durchlaufen sind, sowie die Manahmen, die
in den jeweiligen Schritten beachtet werden sollten, sind im Folgenden aufgefhrt.
1. Es sollte immer mit ein Konzept erstellt werden, das auf den Sicherheitsanforderungen fr die
bereits vorhandenen IT-Systeme sowie den Anforderungen aus den geplanten Einsatzszenarien
beruht (siehe M 2.214 Konzeption des IT-Betriebs).
2. Fr die Beschaffung von IT-Systemen mssen die aus dem Konzept resultierenden Anforderungen
an die jeweiligen Produkte formuliert und basierend darauf die Auswahl der geeigneten Produkte
getroffen werden.
3. Die fr den sicheren Betrieb aller IT-Komponenten notwendigen Manahmen mssen in einer
Sicherheitsrichtlinie festgelegt werden. Diese sollte u. a. folgende Bereiche umfassen:
- Berechtigungskonzepte fr die IT-Nutzung
- Administration und Rollenverteilung (insbesondere bei vernetzten IT-Systemen muss die
Aufteilung der Administration klar geregelt sein)
- Identifikation und Authentikation der Benutzer
- Datenhaltung und allgemeiner Umgang mit der IT
- Festlegung von Hausstandards fr IT-Komponenten
- Gesicherte Anbindung an Fremdnetze
- Sensibilisierung und Schulung der Administratoren und Benutzer
4. Aufbauend auf der Sicherheitsrichtlinie mssen Sicherheitsmanahmen fr die Installation und
erste Konfiguration sowie fr den laufenden Betrieb der IT-Systeme festgelegt werden.
Nachfolgend wird das Manahmenbndel fr den Bereich "Hard- und Software-Management"
vorgestellt:
Infrastruktur:
- M 1.46 (3) Einsatz von Diebstahl-Sicherungen (optional)
Organisation:
- M 2.3 (2) Datentrgerverwaltung
- M 2.11 (1) Regelung des Passwortgebrauchs
- M 2.12 (3) Betreuung und Beratung von IT-Benutzern (optional)
- M 2.30 (1) Regelung fr die Einrichtung von Benutzern / Benutzergruppen
- M 2.62 (2) Software-Abnahme- und Freigabe-Verfahren
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 2.64 (2) Kontrolle der Protokolldateien

- M 2.69 (2) Einrichtung von Standardarbeitspltzen
- M 2.110 (2) Datenschutzaspekte bei der Protokollierung
- M 2.111 (2) Bereithalten von Handbchern
- M 2.138 (2) Strukturierte Datenhaltung
- M 2.167 (2) Sicheres Lschen von Datentrgern
- M 2.182 (2) Regelmige Kontrollen der IT-Sicherheitsmanahmen
- M 2.204 (1) Verhinderung ungesicherter Netzzugnge
- M 2.214 (1) Konzeption des IT-Betriebs
- M 2.215 (2) Fehlerbehandlung
- M 2.216 (2) Genehmigungsverfahren fr IT-Komponenten
- M 2.217 (1) Sorgfltige Einstufung und Umgang mit Informationen, Anwendungen und
Systemen
- M 2.218 (3) Regelung der Mitnahme von Datentrgern und IT-Komponenten
- M 2.219 (1) Kontinuierliche Dokumentation der Informationsverarbeitung
- M 2.220 (1) Richtlinien fr die Zugriffs- bzw. Zugangskontrolle
- M 2.221 (2) nderungsmanagement
- M 2.222 (2) Regelmige Kontrollen der technischen IT-Sicherheitsmanahmen
- M 2.223 (2) Sicherheitsvorgaben fr die Nutzung von Standardsoftware
- M 2.224 (2) Vorbeugung gegen Trojanische Pferde
- M 2.226 (1) Regelungen fr den Einsatz von Fremdpersonal
Personal:
- M 3.26 (1) Einweisung des Personals in den sicheren Umgang mit IT
Hardware/Software:
- M 4.42 (2) Implementierung von Sicherheitsfunktionalitten in der IT-Anwendung (optional)
- M 4.65 (2) Test neuer Hard- und Software
- M 4.78 (2) Sorgfltige Durchfhrung von Konfigurationsnderungen
- M 4.109 (2) Software-Reinstallation bei Arbeitsplatzrechnern
- M 4.133 (2) Geeignete Auswahl von Authentikations-Mechanismen (optional)
- M 4.134 (3) Wahl geeigneter Datenformate
- M 4.135 (1) Restriktive Vergabe von Zugriffsrechten auf Systemdateien
Kommunikation:
- M 5.68 (2) Einsatz von Verschlsselungsverfahren zur Netzkommunikation (optional)
- M 5.77 (1) Bildung von Teilnetzen (optional)
- M 5.87 (2) Vereinbarung ber die Anbindung an Netze Dritter
- M 5.88 (2) Vereinbarung ber Datenaustausch mit Dritten
Notfallvorsorge:
- M 6.75 (3) Redundante Kommunikationsverbindungen (optional)
_________________________________________________________________________________________
Outsourcing 3.10
_________________________________________________________________________________________
3.10 Outsourcing
Beschreibung
Beim Outsourcing werden Arbeits- oder Geschftspro-
zesse einer Organisation ganz oder teilweise zu externen
Dienstleistern ausgelagert. Outsourcing kann sowohl
Nutzung und Betrieb von Hardware und Software, aber
auch Dienstleistungen betreffen. Dabei ist es unerheblich,
ob die Leistung in den Rumlichkeiten des Auftraggebers
oder in einer externen Betriebssttte des Outsourcing-
Dienstleisters erbracht wird. Typische Beispiele sind der
Betrieb eines Rechenzentrums, einer Applikation, einer
Webseite oder des Wachdienstes. Outsourcing ist ein
Oberbegriff, der oftmals durch weitere Begriffe ergnzt wird: Tasksourcing bezeichnet das Auslagern
von Teilbereichen. Werden Dienstleistungen mit Bezug zur IT-Sicherheit ausgelagert, wird von
Security Outsourcing oder Managed Security Services gesprochen. Beispiele sind die Auslagerung des
Firewall-Betriebs, die berwachung des Netzes, Virenschutz oder der Betrieb eines Virtual Private
Networks (VPN). Unter Application Service Provider (ASP) versteht man einen Dienstleister, der auf
seinen eigenen Systemen einzelne Anwendungen oder Software fr seine Kunden betreibt (E-Mail,
SAP-Anwendungen, Archivierung, Web-Shops, Beschaffung). Auftraggeber und Dienstleister sind
dabei ber das Internet oder ein VPN miteinander verbunden. Beim Application Hosting ist ebenfalls
der Betrieb von Anwendungen an einen Dienstleister ausgelagert, jedoch gehren im Gegensatz zum
ASP-Modell die Anwendungen noch dem jeweiligen Kunden. Da die Grenzen zwischen klassischem
Outsourcing und reinem ASP in der Praxis zunehmend verschwimmen, wird im Folgenden nur noch
der Oberbegriff Outsourcing verwendet.
Das Auslagern von Geschfts- und Produktionsprozessen ist ein etablierter Bestandteil heutiger Orga-
nisationsstrategien. Speziell in den letzten beiden Jahrzehnten hat sich der Trend zum Outsourcing
enorm verstrkt, und dieser scheint auch fr die nchste Zukunft ungebrochen. Es gibt aber inzwischen
auch publizierte Beispiele fr gescheiterte Outsourcing-Projekte, wo der Auftraggeber den Outsour-
cing-Vertrag gekndigt hat und die ausgelagerten Geschftsprozesse wieder in Eigenregie betreibt
(Insourcing).
Die Grnde fr Outsourcing sind vielfltig: die Konzentration einer Organisation auf ihre Kernkom-
petenzen, die Mglichkeit einer Kostenersparnis (z. B. keine Anschaffungs- oder Betriebskosten fr
IT-Systeme), der Zugriff auf spezialisierte Kenntnisse und Ressourcen, die Freisetzung interner Res-
sourcen fr andere Aufgaben, die Straffung der internen Verwaltung, die verbesserte Skalierbarkeit
der Geschfts- und Produktionsprozesse, die Erhhung der Flexibilitt sowie der Wettbewerbsfhig-
keit einer Organisation sind nur einige Beispiele.
Beim Auslagern von IT-gesttzten Organisationsprozessen werden die IT-Systeme und Netze der
auslagernden Organisation und ihres Outsourcing-Dienstleisters in der Regel eng miteinander verbun-
den, so dass Teile von internen Geschftsprozessen unter Leitung und Kontrolle eines externen
Dienstleisters ablaufen. Ebenso findet auf personeller Ebene ein intensiver Kontakt statt.
Durch die enge Verbindung zum Dienstleister und die entstehende Abhngigkeit von der Dienstleis-
tungsqualitt ergeben sich Risiken fr den Auftraggeber, durch die im schlimmsten Fall sogar die Ge-
schftsgrundlage des Unternehmens oder der Behrde vital gefhrdet werden knnen. (Beispielsweise
knnten sensitive Organisationsinformationen gewollt oder ungewollt nach auen preisgegeben wer-
den.) Der Betrachtung von Sicherheitsaspekten und der Gestaltung vertraglicher Regelungen zwischen
Auftraggeber und Outsourcing-Dienstleister kommt im Rahmen eines Outsourcing-Vorhabens somit
eine zentrale Rolle zu.
_________________________________________________________________________________________
Outsourcing 3.10
_________________________________________________________________________________________
Den Schwerpunkt dieses Bausteins bilden daher Manahmen, die sich mit IT-Sicherheitsaspekten des
Outsourcing beschftigen. Dazu zhlen ebenfalls geeignete Manahmen zur Kontrolle der vertraglich
vereinbarten Ziele und Leistungen sowie der IT-Sicherheitsmanahmen.
Gefhrdungslage
Die Gefhrdungslage eines Outsourcing-Vorhabens ist ausgesprochen vielschichtig. Die Entscheidung
ber das Auslagern einer speziellen Aktivitt beeinflusst nachhaltig die strategische Ausrichtung der
Organisation, die Definition ihrer Kernkompetenzen, die Ausgestaltung der Wertschpfungskette und
betrifft viele weitere wesentliche Belange eines Organisationsmanagements. Es sollten daher alle An-
strengungen unternommen werden, um Fehlentwicklungen des Unternehmens oder der Behrde frh-
zeitig zu erkennen und zu verhindern.
Die Gefhrdungen knnen parallel auf physikalischer, technischer und auch menschlicher Ebene exis-
tieren und sind nachfolgend in den einzelnen Gefhrdungskatalogen aufgefhrt. Um die jeweils exis-
tierenden Risiken quantitativ bewerten zu knnen, mssen zuvor die organisationseigenen Werte und
Informationen entsprechend ihrer strategischen Bedeutung fr die Organisation beurteilt und klassifi-
ziert werden.
Hhere Gewalt:
- G 1.10 Ausfall eines Weitverkehrsnetzes
- G 2.47 Ungesicherter Akten- und Datentrgertransport
- G 2.66 Unzureichendes IT-Sicherheitsmanagement
- G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten
- G 2.83 Fehlerhafte Outsourcing-Strategie
- G 2.84 Unzulngliche vertragliche Regelungen mit einem externen Dienstleister
- G 2.85 Unzureichende Regelungen fr das Ende des Outsourcing-Vorhabens
- G 2.86 Abhngigkeit von einem Outsourcing-Dienstleister
- G 2.88 Strung des Betriebsklimas durch ein Outsourcing-Vorhaben
- G 2.89 Mangelhafte IT-Sicherheit in der Outsourcing-Einfhrungsphase
- G 2.90 Schwachstellen bei der Anbindung an einen Outsourcing-Dienstleister
- G 2.93 Unzureichendes Notfallvorsorgekonzept beim Outsourcing
- G 4.48 Ausfall der Systeme eines Outsourcing-Dienstleisters
- G 5.10 Missbrauch von Fernwartungszugngen
- G 5.20 Missbrauch von Administratorrechten
- G 5.42 Social Engineering
- G 5.107 Weitergabe von Daten an Dritte durch den Outsourcing-Dienstleister
_________________________________________________________________________________________
Outsourcing 3.10
_________________________________________________________________________________________
Zur Realisierung des IT-Grundschutzes wird empfohlen, die notwendigen Manahmenbndel ("Bau-
steine") wie in Kapitel 2.3 und 2.4 beschrieben auszuwhlen. Ein ausgelagerter IT-Verbund kann so-
wohl aus Komponenten bestehen, die sich ausschlielich im Einflussbereich des Outsourcing-
Dienstleisters befinden, als auch aus Komponenten beim Auftraggeber. In der Regel gibt es in diesem
Fall Schnittstellen zur Verbindung der Systeme. Fr jedes Teilsystem und fr die Schnittstellenfunkti-
onen muss IT-Grundschutz gewhrleistet sein.
Ein Outsourcing-Vorhaben besteht aus mehreren Phasen, die im Folgenden kurz dargestellt sind.
Phase 1: Strategische Planung des Outsourcing-Vorhabens
Schon im Rahmen der strategischen Entscheidung, ob und in welcher Form ein Outsourcing-Vorhaben
umgesetzt wird, mssen die sicherheitsrelevanten Gesichtspunkte herausgearbeitet werden. In der
Manahme M 2.250 Festlegung einer Outsourcing-Strategie werden die wesentlichen Punkte vorge-
stellt, die zu beachten sind.
Phase 2: Definition der wesentlichen Sicherheitsanforderungen
Wenn die Entscheidung zum Outsourcing gefallen ist, mssen die wesentlichen bergeordneten Si-
cherheitsanforderungen fr das Outsourcing-Vorhaben festgelegt werden. Diese Sicherheitsanforde-
rungen sind die Basis fr das Ausschreibungsverfahren (siehe M 2.251 Festlegung der
Sicherheitsanforderungen fr Outsourcing-Vorhaben).
Phase 3: Auswahl des Outsourcing-Dienstleisters
Der Wahl des Outsourcing-Dienstleisters kommt eine besondere Bedeutung zu (siehe M 2.252 Wahl
eines geeigneten Outsourcing-Dienstleisters).
Phase 4: Vertragsgestaltung
Auf Basis des Pflichtenheftes muss nun ein Vertrag mit dem Partner ausgehandelt werden, der die
gewnschten Leistungen inklusive Qualittsstandards und Fristen im Einklang mit der vorhandenen
Gesetzgebung festschreibt. Diese Vertrge werden hufig als Service Level Agreements (SLA) be-
zeichnet. In diesem Vertrag mssen auch die genauen Modalitten der Zusammenarbeit geklrt sein:
Ansprechpartner, Reaktionszeiten, IT-Anbindung, Kontrolle der Leistungen, Ausgestaltung der IT-
Sicherheitsvorkehrungen, Umgang mit vertraulichen Informationen, Verwertungsrechte, Weitergabe
von Information an Dritte etc. (siehe hierzu M 2.253 Vertragsgestaltung mit dem Outsourcing-
Dienstleister).
Phase 5: Erstellung eines IT-Sicherheitskonzepts fr den ausgelagerten IT-Verbund
In enger Zusammenarbeit mssen Auftraggeber und Outsourcing-Dienstleister ein detailliertes Sicher-
heitskonzept (M 2.254 Erstellung eines IT-Sicherheitskonzepts fr das Outsourcing-Vorhaben), das
ein Notfallvorsorgekonzept (M 6.83 Notfallvorsorge beim Outsourcing) enthlt, erstellen.
Phase 5 wird in der Regel erst nach Beendigung der Migrationsphase abgeschlossen werden knnen,
weil sich whrend der Migration der IT-Systeme und Anwendungen immer wieder neue Erkenntnisse
ergeben, die in das IT-Sicherheitskonzept eingearbeitet werden mssen.
Phase 6: Migrationsphase
Besonders sicherheitskritisch ist die Migrations- oder bergangsphase, die deshalb einer sorgfltigen
Planung bedarf (siehe M 2.255 Sichere Migration bei Outsourcing-Vorhaben).
_________________________________________________________________________________________
Outsourcing 3.10
_________________________________________________________________________________________
Phase 7: Planung und Sicherstellen des laufenden Betriebs

Wenn der Outsourcing-Dienstleister die Systeme bzw. Geschftsprozesse bernommen hat, sind ver-
schiedene Manahmen, wie regelmige Kontrollen und Durchfhrung von Systemwartungen, zur
Aufrechterhaltung der IT-Sicherheit im laufenden Betrieb notwendig (siehe M 2.256 Planung und
Aufrechterhaltung der IT-Sicherheit im laufenden Outsourcing-Betrieb). Diese mssen im Vorfeld
entsprechend geplant werden. Notfall- und Eskalationsszenarien mssen unbedingt in der Planung mit
bercksichtigt werden.
Nachfolgend wird das Manahmenbndel fr den Bereich "Outsourcing" vorgestellt.
Organisation
- M 2.42 (2) Festlegung der mglichen Kommunikationspartner
- M 2.221 (1) nderungsmanagement
- M 2.226 (1) Regelungen fr den Einsatz von Fremdpersonal
- M 2.250 (1) Festlegung einer Outsourcing-Strategie
- M 2.251 (1) Festlegung der Sicherheitsanforderungen fr Outsourcing-Vorhaben
- M 2.252 (1) Wahl eines geeigneten Outsourcing-Dienstleisters
- M 2.253 (1) Vertragsgestaltung mit dem Outsourcing-Dienstleister
- M 2.254 (1) Erstellung eines IT-Sicherheitskonzepts fr das Outsourcing-Vorhaben
- M 2.255 (1) Sichere Migration bei Outsourcing-Vorhaben
- M 2.256 (1) Planung und Aufrechterhaltung der IT-Sicherheit im laufenden Outsourcing-
Betrieb
Personal
- M 3.8 (2) Vermeidung von Strungen des Betriebsklimas
- M 3.33 (2) Sicherheitsberprfung von Mitarbeitern
Kommunikation
- M 5.87 (1) Vereinbarung ber die Anbindung an Netze Dritter
- M 5.88 (1) Vereinbarung ber Datenaustausch mit Dritten
Notfallvorsorge
- M 6.70 (1) Erstellen eines Notfallplans fr den Ausfall des RAS-Systems
- M 6.83 (1) Notfallvorsorge beim Outsourcing
_________________________________________________________________________________________
Infrastruktur 4
_________________________________________________________________________________________
4 IT-Grundschutz im Bereich Infrastruktur

In diesem Kapitel werden IT-Grundschutzmanahmen in den nachfolgend aufgezhlten Bausteinen
vorgestellt.
4.1 Gebude
4.2 Verkabelung
4.3 Rume
4.3.1 Broraum
4.3.2 Serverraum
4.4 Schutzschrnke
4.6 Rechenzentrum
_________________________________________________________________________________________
Gebude 4.1
_________________________________________________________________________________________
4.1 Gebude
Beschreibung
Das Gebude umgibt die aufgestellte Informationstechnik
und gewhrleistet somit einen ueren Schutz. Weiterhin
ermglichen die Infrastruktureinrichtungen des Gebudes
erst den IT-Betrieb. Daher ist einerseits das Bauwerk,
also Wnde, Decken, Bden, Dach, Fenster und Tren zu
betrachten und andererseits alle gebudeweiten
Versorgungseinrichtungen wie Strom, Wasser, Gas,
Heizung, Rohrpost etc. Die Verkabelung in einem
Gebude wird in Kapitel 4.2 gesondert betrachtet, die
TK-Anlage in Kapitel 8.1.
Gefhrdungslage
Fr den IT-Grundschutz eines Gebudes werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.3 Blitz
- G 1.4 Feuer
- G 1.5 Wasser
- G 4.2 Ausfall interner Versorgungsnetze
- G 4.3 Ausfall vorhandener Sicherungseinrichtungen
- G 5.3 Unbefugtes Eindringen in ein Gebude
- G 5.4 Diebstahl
- G 5.5 Vandalismus
- G 5.6 Anschlag
_________________________________________________________________________________________
Gebude 4.1
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "Gebude" vorgestellt:
Infrastruktur:
Stromversorgung
- M 1.1 (2) Einhaltung einschlgiger DIN-Normen/VDE-Vorschriften
- M 1.2 (2) Regelungen fr Zutritt zu Verteilern
- M 1.3 (1) Angepasste Aufteilung der Stromkreise
- M 1.4 (3) Blitzschutzeinrichtungen (optional)
- M 1.5 (3) Galvanische Trennung von Auenleitungen (optional)
Brandschutz
- M 1.6 (2) Einhaltung von Brandschutzvorschriften
- M 1.7 (2) Handfeuerlscher
- M 1.8 (2) Raumbelegung unter Bercksichtigung von Brandlasten
- M 1.9 (1) Brandabschottung von Trassen
- M 1.10 (2) Verwendung von Sicherheitstren und -fenstern (optional)
Gebudeschutz
- M 1.11 (2) Lageplne der Versorgungsleitungen
- M 1.12 (2) Vermeidung von Lagehinweisen auf schtzenswerte Gebudeteile
- M 1.13 (3) Anordnung schtzenswerter Gebudeteile (optional)
- M 1.14 (2) Selbstttige Entwsserung (optional)
- M 1.16 (3) Geeignete Standortauswahl (optional)
- M 1.17 (3) Pfrtnerdienst (optional)
- M 1.18 (2) Gefahrenmeldeanlage (optional)
- M 1.19 (2) Einbruchsschutz (optional)
Organisation:
- M 2.15 (2) Brandschutzbegehungen
- M 2.16 (2) Beaufsichtigung oder Begleitung von Fremdpersonen (optional)
- M 2.17 (2) Zutrittsregelung und -kontrolle
Notfallvorsorge:
- M 6.17 (1) Alarmierungsplan und Brandschutzbungen
_________________________________________________________________________________________
Verkabelung 4.2
_________________________________________________________________________________________
4.2 Verkabelung
Beschreibung
Die Verkabelung von IT-Systemen umfasst alle Kabel
und passiven Komponenten (Rangier-/Spleiverteiler) der
Netze vom evtl. vorhandenen bergabepunkt aus einem
Fremdnetz (Telefon, ISDN) bis zu den Anschlusspunkten
der Netzteilnehmer. Aktive Netzkomponenten (Repeater,
Sternkoppler, Bridges etc.) sind nicht Bestandteil dieses
Kapitels.
Gefhrdungslage
Fr den IT-Grundschutz der Verkabelung werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.6 Kabelbrand
- G 2.11 Unzureichende Trassendimensionierung
- G 2.12 Unzureichende Dokumentation der Verkabelung
- G 2.13 Unzureichend geschtzte Verteiler
- G 2.32 Unzureichende Leitungskapazitten
- G 3.4 Unzulssige Kabelverbindungen
- G 3.5 Unbeabsichtigte Leitungsbeschdigung
- G 4.4 Leitungsbeeintrchtigung durch Umfeldfaktoren
- G 4.5 bersprechen
- G 4.21 Ausgleichsstrme auf Schirmungen
- G 5.7 Abhren von Leitungen
- G 5.8 Manipulation an Leitungen
Nachfolgend wird das Manahmenbndel fr den Bereich "Verkabelung" vorgestellt:
Infrastruktur:
- M 1.20 (3) Auswahl geeigneter Kabeltypen unter physikalisch-mechanischer Sicht
- M 1.21 (2) Ausreichende Trassendimensionierung
- M 1.22 (3) Materielle Sicherung von Leitungen und Verteilern (optional)
- M 1.39 (3) Verhinderung von Ausgleichsstrmen auf Schirmungen
_________________________________________________________________________________________
Verkabelung 4.2
_________________________________________________________________________________________
Organisation:
- M 2.19 (2) Neutrale Dokumentation in den Verteilern
- M 2.20 (3) Kontrolle bestehender Verbindungen (optional)
Kommunikation:
- M 5.1 (3) Entfernen oder Kurzschlieen und Erden nicht bentigter Leitungen
- M 5.2 (2) Auswahl einer geeigneten Netz-Topographie
- M 5.3 (2) Auswahl geeigneter Kabeltypen unter kommunikationstechnischer Sicht
- M 5.4 (2) Dokumentation und Kennzeichnung der Verkabelung
- M 5.5 (2) Schadensmindernde Kabelfhrung
Notfallvorsorge:
- M 6.18 (3) Redundante Leitungsfhrung (optional)
_________________________________________________________________________________________
Broraum 4.3.1
_________________________________________________________________________________________
4.3 Rume
4.3.1 Broraum
Beschreibung
Der Broraum ist ein Raum, in dem sich ein oder
mehrere Mitarbeiter aufhalten, um dort der Erledigung
ihrer Aufgaben evtl. auch IT-untersttzt nachzugehen.
Diese Aufgaben knnen aus den verschiedensten Ttig-
keiten bestehen: Erstellung von Schriftstcken, Bearbei-
tung von Karteien und Listen, Durchfhrung von
Besprechungen und Telefonaten, Lesen von Akten und
sonstigen Unterlagen.
Wird jedoch ein Broraum berwiegend zur Archivierung von Datentrgern genutzt, ist zustzlich
Kapitel 4.3.3 Datentrgerarchiv zu beachten. Ist in einem Broraum ein Server (LAN, TK-Anlage,
o. .) aufgestellt, sind zustzlich die Manahmen aus Kapitel 4.3.2 (Serverraum) zu beachten.
Gefhrdungslage
Fr den IT-Grundschutz eines Broraums werden folgende typische Gefhrdungen angenommen:
- G 2.14 Beeintrchtigung der IT-Nutzung durch ungnstige Arbeitsbedingungen
- G 3.6 Gefhrdung durch Reinigungs- oder Fremdpersonal
- G 5.4 Diebstahl
- G 5.5 Vandalismus
Nachfolgend wird das Manahmenbndel fr den Bereich "Broraum" vorgestellt:
Infrastruktur:
- M 1.23 (1) Abgeschlossene Tren
- M 1.46 (3) Einsatz von Diebstahl-Sicherungen (optional)
Organisation:
- M 2.16 (2) Beaufsichtigung oder Begleitung von Fremdpersonen
Personal:
- M 3.9 (3) Ergonomischer Arbeitsplatz (optional)
_________________________________________________________________________________________
Serverraum 4.3.2
_________________________________________________________________________________________
4.3.2 Serverraum
Beschreibung
Der Serverraum dient in erster Linie zur Unterbringung
eines Servers, z. B. eines LAN-Servers, eines Unix-
Zentralrechners oder eines Servers fr eine TK-Anlage.
Darber hinaus knnen dort serverspezifische Unter-
lagen, Datentrger in kleinem Umfang, weitere Hardware
(Sternkoppler, Protokolldrucker, Klimatechnik) vor-
handen sein.
Im Serverraum ist kein stndig besetzter Arbeitsplatz
eingerichtet; er wird nur sporadisch und zu kurzfristigen
Arbeiten betreten. Zu beachten ist jedoch, dass im Serverraum aufgrund der Konzentration von IT-
Gerten und Daten ein deutlich hherer Schaden eintreten kann als zum Beispiel in einem Broraum.
Gefhrdungslage
Fr den IT-Grundschutz eines Serverraumes werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 1.7 Unzulssige Temperatur und Luftfeuchte
- G 4.6 Spannungsschwankungen/berspannung/ Unterspannung
- G 5.4 Diebstahl
- G 5.5 Vandalismus
Bei der Auswahl und Gestaltung eines Serverraums sind eine Reihe infrastruktureller und
organisatorischer Manahmen umzusetzen, die in M 1.58 Technische und organisatorische Vorgaben
fr Serverrume beschrieben sind.
Nachfolgend wird das Manahmenbndel fr den Bereich "Serverraum" vorgestellt:
_________________________________________________________________________________________
Serverraum 4.3.2
_________________________________________________________________________________________
Infrastruktur:
- M 1.24 (3) Vermeidung von wasserfhrenden Leitungen (optional)
- M 1.25 (2) berspannungsschutz (optional)
- M 1.26 (2) Not-Aus-Schalter (optional)
- M 1.27 (2) Klimatisierung (optional)
- M 1.28 (1) Lokale unterbrechungsfreie Stromversorgung (optional)
- M 1.31 (3) Fernanzeige von Strungen (optional)
- M 1.52 (3) Redundanzen in der technischen Infrastruktur (optional)
- M 1.58 (1) Technische und organisatorische Vorgaben fr Serverrume
Organisation:
- M 2.21 (2) Rauchverbot
_________________________________________________________________________________________
Datentrgerarchiv 4.3.3
_________________________________________________________________________________________
Beschreibung
Das Datentrgerarchiv dient der Lagerung von Daten-
trgern jeder Art. Im Rahmen des IT-Grundschutzes
werden an den Archivraum hinsichtlich des Brand-
schutzes keine erhhten Anforderungen gestellt. Der
Brandschutz kann entsprechend den Bedrfnissen des IT-
Betreibers durch die Behltnisse, in denen die Daten-
trger aufbewahrt werden, realisiert werden.
Bei zentralen Datentrgerarchiven und Datensicherungs-
archiven ist die Nutzung von Datensicherungsschrnken
(vgl. Kapitel 4.4) empfehlenswert, um den Brandschutz, den Schutz gegen unbefugten Zugriff und die
Durchsetzung von Zugangsberechtigungen zu untersttzen.
Gefhrdungslage
Fr den IT-Grundschutz eines Datentrgerarchivs werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 1.8 Staub, Verschmutzung
- G 5.4 Diebstahl
- G 5.5 Vandalismus
Nachfolgend wird das Manahmenbndel fr den Bereich "Datentrgerarchiv" vorgestellt:
Infrastruktur:
_________________________________________________________________________________________
Datentrgerarchiv 4.3.3
_________________________________________________________________________________________
Organisation:
_________________________________________________________________________________________
Raum fr technische Infrastruktur 4.3.4
_________________________________________________________________________________________
Beschreibung
In Rumen fr technische Infrastruktur sind in der Regel
solche Gerte und Einrichtungen untergebracht, die keine
oder nur eine seltene Bedienung durch einen Menschen
bentigen. In der Regel wird es sich um Verteiler interner
Versorgungsnetze handeln (z. B. Postkabeleingangsraum,
Hochspannungsbergaberaum,
Mittelspannungsbergaberaum, Niederspannungshaupt-
verteiler). Eventuell werden in diesen Rumen auch die
Sicherungen der Elektroversorgung untergebracht. Auch die Aufstellung sonstiger Gerte (USV,
Sternkoppler, etc.) ist vorstellbar. Selbst ein Netzserver kann, wenn er keinen eigenen Raum hat
(Kapitel 4.3.2 Serverraum), hier untergebracht sein.
Gefhrdungslage
Fr den IT-Grundschutz eines Raums fr technische Infrastruktur werden folgende typische
Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 5.4 Diebstahl
- G 5.5 Vandalismus
Nachfolgend wird das Manahmenbndel fr den Bereich "Raum fr technische Infrastruktur"
vorgestellt:
Infrastruktur:
_________________________________________________________________________________________
Raum fr technische Infrastruktur 4.3.4
_________________________________________________________________________________________

- M 1.26 (2) Not-Aus-Schalter (optional)
Organisation:
_________________________________________________________________________________________
Schutzschrnke 4.4.1
_________________________________________________________________________________________
4.4.1 Schutzschrnke
Beschreibung
Schutzschrnke dienen zur Aufbewahrung von
Datentrgern jeder Art oder zur Unterbringung von
informationstechnischen Gerten ("Serverschrank").
Diese Schutzschrnke sollen den Inhalt gegen unbefugten
Zugriff und/oder gegen die Einwirkung von Feuer oder
schdigenden Stoffen (z. B. Staub) schtzen. Sie knnen
als Ersatz fr einen Serverraum oder ein Datentrger-
archiv (vgl. Kapitel 4.3.2 und 4.3.3) eingesetzt werden,
wenn die vorhandenen rumlichen oder organisatorischen
Gegebenheiten eigene Rume nicht zulassen.
Darber hinaus knnen Schutzschrnke auch in Serverrumen oder Datentrgerarchiven eingesetzt
werden, um die Schutzwirkung der Rume zu erhhen. Sie sind auch zu empfehlen, wenn in einem
Serverraum Server aus unterschiedlichen Organisationsbereichen aufgestellt sind, die dem jeweils
anderen Administrator nicht zugnglich sein sollen.
Da die Kosten fr Schutzschrnke nicht unerheblich sind, ist ein Kostenvergleich dringend
empfehlenswert. Zu vergleichen sind die Kosten, die die Beschaffung und der Unterhalt eines
Schutzschrankes verursachen, mit den Kosten, die fr die Errichtung eines Serverraums bzw.
Datentrgerarchivs und den Unterhalt der Rume anfallen wrden.
Um mit einem Schutzschrank einen mit den dedizierten Rumen vergleichbaren Schutz zu erreichen,
sind eine Reihe von Manahmen, beginnend mit der geeigneten Auswahl bis zur Aufstellung und
Nutzungsregelung, notwendig. Diese werden im vorliegenden Kapitel vorgestellt.
Gefhrdungslage
Fr den IT-Grundschutz eines Schutzschrankes werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 3.21 Fehlbedienung von Codeschlssern

- G 4.4 Leitungsbeeintrchtigung durch Umfeldfaktoren
_________________________________________________________________________________________
Schutzschrnke 4.4.1
_________________________________________________________________________________________
- G 5.4 Diebstahl
- G 5.5 Vandalismus
- G 5.16 Gefhrdung bei Wartungs-/Administrierungsarbeiten durch internes Personal
- G 5.17 Gefhrdung bei Wartungsarbeiten durch externes Personal
- G 5.53 Bewusste Fehlbedienung von Schutzschrnken aus Bequemlichkeit
Nachfolgend wird das Manahmenbndel fr den Bereich "Schutzschrnke" vorgestellt. Es ist
gruppiert nach den Manahmen, die im Aufstellungsraum des Schutzschrankes, fr den Schutzschrank
allgemein und fr Serverschrnke speziell realisiert werden mssen.
Fr den Raum, in dem der Schutzschrank aufgestellt werden soll, sind folgende Manahmen zu
beachten:
Infrastruktur:
Organisation:
- M 2.21 (2) Rauchverbot (optional)
Fr die Beschaffung und den Einsatz eines Schutzschrankes sind folgende Manahmen umzusetzen:
Infrastruktur:
- M 1.18 (2) Gefahrenmeldeanlage (fr den Schutzschrank) (optional)
- M 1.40 (1) Geeignete Aufstellung von Schutzschrnken
Organisation:
- M 2.95 (1) Beschaffung geeigneter Schutzschrnke
- M 2.96 (1) Verschluss von Schutzschrnken
- M 2.97 (1) Korrekter Umgang mit Codeschlsser (falls vorhanden)
Personal:
- M 3.3 (1) Vertretungsregelungen
- M 3.20 (1) Einweisung in die Bedienung von Schutzschrnken
_________________________________________________________________________________________
Schutzschrnke 4.4.1
_________________________________________________________________________________________
Soll der Schutzschrank als Serverschrank eingesetzt werden, sind zustzlich zu den oben genannten
noch folgende Manahmen im bzw. fr den Serverschrank zu realisieren:
Infrastruktur:
- M 1.26 (2) Not-Aus-Schalter
- M 1.41 (2) Schutz gegen elektromagnetische Einstrahlung (optional)
Organisation:
_________________________________________________________________________________________
Huslicher Arbeitsplatz 4.5
_________________________________________________________________________________________

Beschreibung
Werden dienstliche Aufgaben in der huslichen
Umgebung und nicht in Rumen des Unternehmens bzw.
der Behrde wahrgenommen, sind
Sicherheitsmanahmen zu ergreifen, die eine mit einem
Broraum vergleichbare Sicherheitssituation erreichen
lassen. Bei einem huslichen Arbeitsplatz kann nicht die
infrastrukturelle Sicherheit, wie sie in einer gewerblichen
oder behrdlichen Broumgebung anzutreffen ist,
vorausgesetzt werden. Besucher oder Familienangehrige
haben oftmals Zutritt zu diesem Arbeitsplatz. In diesem
Kapitel werden die typischen Gefhrdungen und Manahmen fr einen huslichen Arbeitsplatz
beschrieben. Dieser husliche Arbeitsplatz kann zum Beispiel im Rahmen der Telearbeit, bei freien
Mitarbeitern und fr Selbstndige eingesetzt werden.
Gefhrdungslage
Fr den IT-Grundschutz des huslichen Arbeitsplatzes werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.14 Beeintrchtigung der IT-Nutzung durch ungnstige Arbeitsbedingungen
- G 2.47 Ungesicherter Akten- und Datentrgertransport
- G 2.48 Ungeeignete Entsorgung der Datentrger und Dokumente am huslichen
Arbeitsplatz
- G 5.69 Erhhte Diebstahlgefahr am huslichen Arbeitsplatz
- G 5.70 Manipulation durch Familienangehrige und Besucher
_________________________________________________________________________________________
Huslicher Arbeitsplatz 4.5
_________________________________________________________________________________________
Manahmenempfehlungen:
Nachfolgend wird das Manahmenbndel fr den Bereich "Huslicher Arbeitsplatz" vorgestellt.
Infrastruktur:
- M 1.7 (3) Handfeuerlscher (optional)
- M 1.19 (2) Einbruchsschutz (optional)
- M 1.44 (2) Geeignete Einrichtung eines huslichen Arbeitsplatzes
- M 1.45 (1) Geeignete Aufbewahrung dienstlicher Unterlagen und Datentrger
Organisation:
- M 2.112 (2) Regelung des Akten- und Datentrgertransports zwischen huslichem Arbeitsplatz
und Institution
- M 2.136 (2) Einhaltung von Regelungen bzgl. Arbeitsplatz und Arbeitsumgebung
Personal:
- M 3.9 (3) Ergonomischer Arbeitsplatz (optional)
_________________________________________________________________________________________
Rechenzentrum 4.6
_________________________________________________________________________________________
4.6 Rechenzentrum
Beschreibung
Bedingt durch erhhte Verfgbarkeitsanforderungen, aber
auch durch Forderungen nach einheitlichen
Administrationskonzepten, meist unter dem Druck
zustzlicher Personaleinsparungen, ist eine Tendenz zur
Zentralisierung der geschftskritischen Produktiv-
Hardware einer Behrde bzw. eines Unternehmens zu
verzeichnen. Die Anforderungen an die Leistungs-
fhigkeit dieser Systeme und der Netzumgebung sind
insbesondere dort gestiegen, wo zeitkritische Zugriffe auf
zentrale Datenbanken realisiert werden mssen. Um
diesem gestiegenen Leistungsbedarf gerecht zu werden und zustzlich mittelfristig entsprechende
Reserven vorzuhalten, haben auch Unternehmen mittlerer Gre, die bislang ausschlielich auf ein
verteiltes Client-Server-Konzept vertrauten, ihre IT-Landschaft durch Rechenzentren ergnzt oder
teilweise ersetzt.
Als Rechenzentrum werden die fr den Betrieb einer greren, zentral fr mehrere Stellen
eingesetzten Datenverarbeitungsanlage erforderlichen Einrichtungen (Rechner-, Speicher-, Druck-,
Robotersysteme usw.) und Rumlichkeiten (Rechnersaal, Archiv, Lager, Aufenthaltsraum usw.)
bezeichnet. Ein Rechenzentrum ist entweder stndig personell besetzt (Schichtdienst) oder es existiert
in bedienerlosen Zeiten eine Rufbereitschaft (mit oder ohne Fernadministrationsmglichkeit). In der
Regel sttzt sich die Datenverarbeitung eines Unternehmens nicht ausschliesslich auf die zentralen IT-
Gerte in einem Rechenzentrum, sondern auf eine Vielzahl damit verbundener dezentraler IT-
Systeme. In einem Rechenzentrum kann aufgrund der Konzentration von IT-Gerten und Daten jedoch
ein deutlich hherer Schaden eintreten als bei dezentraler Datenverarbeitung. In jedem Fall ist beim
Einsatz einer Grorechenanlage der Baustein Rechenzentrum anzuwenden.
Gegenstand dieses Bausteins ist ein Rechenzentrum mittlerer Art und Gte. Die
Sicherheitsanforderungen liegen zwischen denen eines Serverraums oder "Serverparks" und denen von
Hochsicherheitsrechenzentren, wie sie beispielsweise im Bankenbereich eingesetzt werden. Neben den
hier aufgefhrten Standard-Sicherheitsmanahmen, die sich in der Praxis bewhrt haben, sind in den
meisten Fllen jedoch weitere, individuelle IT-Sicherheitsmanahmen erforderlich, die die konkreten
Anforderungen und das jeweilige Umfeld bercksichtigen. Gefhrdungen aus den Bereichen
Terrorismus oder hhere Gewalt wird durch die hier beschriebenen Standard-Sicherheitsmanahmen
nur begrenzt Rechnung getragen.
Der Baustein richtet sich einerseits an Leser, die ein Rechenzentrum betreiben und im Rahmen einer
Revision prfen mchten, ob sie geeignete Standard-Sicherheitsmanahmen umgesetzt haben. Auf der
anderen Seite kann der Baustein Rechenzentrum auch dazu verwendet werden, berblicksartig die IT-
Sicherheitsmanahmen abzuschtzen, die bei einer Zentralisierung der IT in einem mittleren
Rechenzentrum fr einen sicheren Betrieb umgesetzt werden mssen. Um den Baustein berschaubar
zu halten, wurde bewusst auf technische Details und planerische Gren verzichtet. Der Neubau eines
Rechenzentrums sollte auch von groen IT-Abteilungen nicht ohne Hilfe eines erfahrenen
Planungsstabes bzw. einer versierten Planungs- und Beratungsfirma in Betracht gezogen werden.
Beim Outsourcing von Rechenzentrumsleistungen kann dieser Baustein dazu benutzt werden, die
angebotenen Leistungen im Hinblick auf deren Sicherheitsniveau zu prfen.
Im Gegensatz zum Schutzbedarf eines Serverraums (siehe dort) werden viele IT-Sicherheits-
manahmen fr ein Rechenzentrum nicht als optional, sondern obligatorisch empfohlen. Dazu gehren
beispielsweise eine angemessene Gefahrenmeldeanlage und eine alternative
_________________________________________________________________________________________
Rechenzentrum 4.6
_________________________________________________________________________________________
Stromversorgung. Fr einen sicheren IT-Betrieb ist eine Brandfrhesterkennung durch

Objektberwachung der eingesetzten Hardware und des Doppelbodens effektiv und kostengnstig.
Eine Raumlschung richtet sich in erster Linie auf den Erhalt des Gebudes.
Gefhrdungslage
Fr den IT-Grundschutz eines Rechenzentrums werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.3 Blitz
- G 1.4 Feuer
- G 1.5 Wasser
- G 1.6 Kabelbrand
- G 1.11 Technische Katastrophen im Umfeld
- G 1.12 Beeintrchtigung durch Groveranstaltungen
- G 1.13 Sturm
- G 2.11 Unzureichende Trassendimensionierung
- G 2.12 Unzureichende Dokumentation der Verkabelung
- G 2.20 Unzureichende oder falsche Versorgung mit Verbrauchsgtern
- G 5.4 Diebstahl
- G 5.5 Vandalismus
- G 5.6 Anschlag
- G 5.68 Unberechtigter Zugang zu den aktiven Netzkomponenten
- G 5.102 Sabotage
_________________________________________________________________________________________
Rechenzentrum 4.6
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "Rechenzentrum" vorgestellt:
Infrastruktur:
Planung
- M 1.16 (3) Geeignete Standortauswahl (optional)
- M 1.49 (2) Technische und organisatorische Vorgaben fr das Rechenzentrum
Stromversorgung
- M 1.4 (1) Blitzschutzeinrichtungen
- M 1.5 (1) Galvanische Trennung von Auenleitungen
- M 1.25 (1) berspannungsschutz
- M 1.56 (2) Sekundr-Energieversorgung
Brandschutz
- M 1.10 (2) Verwendung von Sicherheitstren und -fenstern
- M 1.26 (1) Not-Aus-Schalter
- M 1.47 (1) Eigener Brandabschnitt
- M 1.48 (1) Brandmeldeanlage
- M 1.50 (1) Rauchschutz
- M 1.51 (2) Brandlastreduzierung
- M 1.54 (2) Brandfrhesterkennung / Lschtechnik (optional)
Gebudeschutz
- M 1.11 (2) Lageplne der Versorgungsleitungen
- M 1.13 (3) Anordnung schtzenswerter Gebudeteile
- M 1.14 (2) Selbstttige Entwsserung (optional)
- M 1.17 (3) Pfrtnerdienst (optional)
- M 1.18 (1) Gefahrenmeldeanlage
- M 1.19 (1) Einbruchsschutz
- M 1.24 (2) Vermeidung von wasserfhrenden Leitungen
- M 1.27 (1) Klimatisierung
- M 1.52 (2) Redundanzen in der technischen Infrastruktur
- M 1.53 (2) Videoberwachung (optional)
- M 1.55 (2) Perimeterschutz (optional)
- M 1.57 (2) Aktuelle Infrastruktur- und Bauplne
_________________________________________________________________________________________
Rechenzentrum 4.6
_________________________________________________________________________________________
Organisation:
- M 2.15 (2) Brandschutzbegehungen
- M 2.52 (3) Versorgung und Kontrolle der Verbrauchsgter
- M 2.212 (2) Organisatorische Vorgaben fr die Gebudereinigung
- M 2.213 (2) Wartung der technischen Infrastruktur
Notfallvorsorge:
- M 6.16 (3) Abschlieen von Versicherungen (optional)
- M 6.17 (1) Alarmierungsplan und Brandschutzbungen
- M 6.74 (2) Notfallarchiv (optional)
_________________________________________________________________________________________
Nicht vernetzte Systeme 5
_________________________________________________________________________________________
5 Nicht vernetzte Systeme und Clients

In diesem Kapitel wird der IT-Grundschutz fr nicht vernetzte Systeme oder Systeme, die als Client in
einem Netz eingesetzt werden knnen, definiert. Fr die noch nicht im IT-Grundschutzhandbuch
betrachteten IT-Systeme wie z. B. OS/2 kann der generische Baustein 5.99 angewendet werden.

5.2 Unix-System
5.3 Tragbarer PC
5.8 Internet-PC
_________________________________________________________________________________________
DOS-PC (ein Benutzer) 5.1
_________________________________________________________________________________________

Beschreibung
Betrachtet wird ein handelsblicher IBM-kompatibler
PC, der mit dem Betriebssystem DOS oder einem
vergleichbaren betrieben wird. Dieser PC soll nicht an ein
lokales Netz angeschlossen sein. Der PC verfgt ber ein
Diskettenlaufwerk, eine Festplatte und evtl. eine Maus.
Ein eventuell vorhandener Drucker wird direkt am PC
angeschlossen. Weiterhin kann eine graphische
Benutzeroberflche eingesetzt sein. Fr die weiteren
Betrachtungen wird vorausgesetzt, dass dieser PC nur
von einem Benutzer betrieben wird.
Gefhrdungslage
Fr den IT-Grundschutz eines DOS-PC (ein Benutzer) werden folgende Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 4.7 Defekte Datentrger
- G 5.4 Diebstahl
- G 5.9 Unberechtigte IT-Nutzung
_________________________________________________________________________________________
DOS-PC (ein Benutzer) 5.1
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "DOS-PC (ein Benutzer)" vorgestellt:
Infrastruktur:
- M 1.29 (3) Geeignete Aufstellung eines IT-Systems (optional)
Organisation:
- M 2.22 (2) Hinterlegen des Passwortes
- M 2.23 (3) Herausgabe einer PC-Richtlinie (optional)
- M 2.24 (3) Einfhrung eines PC-Checkheftes (optional)
Personal:
Hardware/Software:
- M 4.1 (1) Passwortschutz fr IT-Systeme
- M 4.2 (1) Bildschirmsperre
- M 4.4 (3) Geeigneter Umgang mit Laufwerken fr Wechselmedien und externen
Datenspeichern (optional)
- M 4.30 (2) Nutzung der in Anwendungsprogrammen angebotenen Sicherheitsfunktionen
(optional)
Notfallvorsorge:
- M 6.20 (2) Geeignete Aufbewahrung der Backup-Datentrger
- M 6.21 (3) Sicherungskopie der eingesetzten Software
- M 6.22 (2) Sporadische berprfung auf Wiederherstellbarkeit von Datensicherungen
- M 6.27 (3) Sicheres Update des BIOS
_________________________________________________________________________________________
Unix-System 5.2
_________________________________________________________________________________________
5.2 Unix-System
Beschreibung
Betrachtet wird ein Unix-System, das entweder im Stand-
alone-Betrieb oder als Client in einem Netz genutzt wird.
Es knnen Terminals, Laufwerke, Drucker und andere
Gerte angeschlossen sein. Weiterhin kann eine
graphische Benutzeroberflche wie X-Windows einge-
setzt sein. Entsprechend knnen dann auch X-Terminals
und graphische Eingabegerte angeschlossen sein. Bei
den weiteren Betrachtungen wird davon ausgegangen,
dass ein Unix-System blicherweise von mehreren
Personen benutzt wird.
Gefhrdungslage
Fr den IT-Grundschutz eines Unix-Systems werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.15 Vertraulichkeitsverlust schutzbedrftiger Daten im Unix-System
- G 3.9 Fehlerhafte Administration des IT-Systems
- G 4.8 Bekanntwerden von Softwareschwachstellen
- G 4.11 Fehlende Authentisierungsmglichkeit zwischen NIS-Server und NIS-Client
- G 4.12 Fehlende Authentisierungsmglichkeit zwischen X-Server und X-Client
- G 5.4 Diebstahl
_________________________________________________________________________________________
Unix-System 5.2
_________________________________________________________________________________________

- G 5.18 Systematisches Ausprobieren von Passwrtern
- G 5.19 Missbrauch von Benutzerrechten
- G 5.40 Abhren von Rumen mittels Rechner mit Mikrofon
- G 5.41 Mibruchliche Nutzung eines Unix-Systems mit Hilfe von uucp
- G 5.89 Hijacking von Netz-Verbindungen
Nachfolgend wird das Manahmenbndel fr den Bereich "Unix-System" vorgestellt.
Fr eventuell angeschlossene Rechner (DOS-PC, PC unter Windows NT oder Windows 95) sind die
in Kapitel 5 beschriebenen Manahmen zu realisieren.
Darber hinaus sind folgende weitere Manahmen umzusetzen:
Infrastruktur:
Organisation:
- M 2.25 (1) Dokumentation der Systemkonfiguration
- M 2.26 (1) Ernennung eines Administrators und eines Vertreters
- M 2.31 (1) Dokumentation der zugelassenen Benutzer und Rechteprofile
- M 2.32 (2) Einrichtung einer eingeschrnkten Benutzerumgebung
- M 2.33 (2) Aufteilung der Administrationsttigkeiten unter Unix
Personal:
- M 3.10 (1) Auswahl eines vertrauenswrdigen Administrators und Vertreters
- M 3.11 (1) Schulung des Wartungs- und Administrationspersonals
Hardware/Software:
Zugang zum Unix-System
- M 4.7 (1) nderung voreingestellter Passwrter
- M 4.13 (1) Sorgfltige Vergabe von IDs
- M 4.14 (1) Obligatorischer Passwortschutz unter Unix
_________________________________________________________________________________________
Unix-System 5.2
_________________________________________________________________________________________
- M 4.15 (2) Gesichertes Login

- M 4.16 (3) Zugangsbeschrnkungen fr Accounts und / oder Terminals
- M 4.17 (2) Sperren und Lschen nicht bentigter Accounts und Terminals
- M 4.18 (1) Administrative und technische Absicherung des Zugangs zum Monitor- und
Single-User-Modus
- M 4.105 (1) Erste Manahmen nach einer Unix-Standardinstallation
Attributvergabe/Arbeiten mit dem Unix-System
- M 4.9 (1) Einsatz der Sicherheitsmechanismen von X-Windows
- M 4.19 (1) Restriktive Attributvergabe bei Unix-Systemdateien und -verzeichnissen
- M 4.20 (2) Restriktive Attributvergabe bei Unix-Benutzerdateien und -verzeichnissen
- M 4.21 (1) Verhinderung des unautorisierten Erlangens von Administratorrechten
- M 4.22 (3) Verhinderung des Vertraulichkeitsverlusts schutzbedrftiger Daten im Unix-
System
- M 4.23 (3) Sicherer Aufruf ausfhrbarer Dateien
Protokollierung/Sicherheitscheck
- M 4.25 (1) Einsatz der Protokollierung im Unix-System
- M 4.26 (2) Regelmiger Sicherheitscheck des Unix-Systems
- M 4.40 (2) Verhinderung der unautorisierten Nutzung des Rechnermikrofons
- M 4.93 (1) Regelmige Integrittsprfung
- M 4.106 (2) Aktivieren der Systemprotokollierung
Kommunikation:
- M 5.17 (1) Einsatz der Sicherheitsmechanismen von NFS
- M 5.18 (1) Einsatz der Sicherheitsmechanismen von NIS
- M 5.19 (1) Einsatz der Sicherheitsmechanismen von sendmail
- M 5.20 (1) Einsatz der Sicherheitsmechanismen von rlogin, rsh und rcp
- M 5.21 (1) Sicherer Einsatz von telnet, ftp, tftp und rexec
- M 5.34 (2) Einsatz von Einmalpasswrtern (optional)
- M 5.35 (1) Einsatz der Sicherheitsmechanismen von UUCP
- M 5.36 (2) Verschlsselung unter Unix und Windows NT (optional)
- M 5.64 (2) Secure Shell
- M 5.72 (1) Deaktivieren nicht bentigter Netzdienste
Notfallvorsorge:
- M 6.31 (2) Verhaltensregeln nach Verlust der Systemintegritt
_________________________________________________________________________________________
Tragbarer PC 5.3
_________________________________________________________________________________________
5.3 Tragbarer PC
Beschreibung
Unter einem tragbaren PC (Laptop, Notebook) wird ein
handelsblicher IBM-kompatibler PC verstanden, der mit
dem Betriebssystem DOS oder einem vergleichbaren
betrieben wird. Er verfgt ber ein Diskettenlaufwerk
und eine Festplatte. Einrichtungen zur
Datenfernbertragung (Modem) werden hier nicht
behandelt (vgl. Kap. 7.2). Von besonderer Bedeutung ist,
dass dieser PC aufgrund seiner Bauart, insbesondere mit
interner Stromversorgung, mobil genutzt werden kann.
Fr den tragbaren PC wird vorausgesetzt, dass er
innerhalb eines bestimmten Zeitraums nur von einem Benutzer gebraucht wird. Ein anschlieender
Benutzerwechsel wird bercksichtigt.
Gefhrdungslage
Fr den IT-Grundschutz eines tragbaren PC werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.16 Ungeordneter Benutzerwechsel bei tragbaren PCs
- G 4.9 Ausfall der internen Stromversorgung
- G 5.4 Diebstahl
- G 5.22 Diebstahl bei mobiler Nutzung des IT-Systems
_________________________________________________________________________________________
Tragbarer PC 5.3
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "Tragbarer PC" vorgestellt:
Infrastruktur:
- M 1.33 (1) Geeignete Aufbewahrung tragbarer IT-Systeme bei mobilem Einsatz
- M 1.34 (2) Geeignete Aufbewahrung tragbarer PCs im stationren Einsatz
- M 1.35 (3) Sammelaufbewahrung mehrerer tragbarer PCs (optional)
Organisation:
- M 2.36 (2) Geregelte bergabe und Rcknahme eines tragbaren PC
Personal:
Hardware/Software:
- M 4.27 (1) Passwortschutz am tragbaren PC
- M 4.28 (3) Software-Reinstallation bei Benutzerwechsel eines tragbaren PC (optional)
- M 4.29 (1) Einsatz eines Verschlsselungsproduktes fr tragbare PCs (optional)
(optional)
- M 4.31 (2) Sicherstellung der Energieversorgung im mobilen Einsatz
Notfallvorsorge:
- M 6.71 (2) Datensicherung bei mobiler Nutzung des IT-Systems
_________________________________________________________________________________________
PCs mit wechselnden Benutzern 5.4
_________________________________________________________________________________________

Beschreibung
Dieser Baustein sollte beim Einsatz von PCs mit
wechselnden Benutzern beachtet werden. Betrachtet wird
ein handelsblicher IBM-kompatibler PC, der mit dem
Betriebssystem DOS oder einem vergleichbaren
betrieben wird. Fr PCs, die mit anderen
Betriebssystemen betrieben werden, sind die Manahmen
analog anzupassen.
Wenn der PC an ein lokales Netz angeschlossen ist, sind
die entsprechenden Bausteine aus Kapitel 6 umzusetzen.
Der PC kann ber Disketten- und CD-Laufwerke, eine Festplatte, eine Maus und andere
Peripheriegerte verfgen. Ein eventuell vorhandener Drucker wird direkt am PC angeschlossen.
Weiterhin kann eine graphische Benutzeroberflche eingesetzt sein. Fr die weiteren Betrachtungen
wird vorausgesetzt, dass mehrere Personen, die unterschiedliche Zugriffsrechte auf die gespeicherten
Daten besitzen, diesen PC nutzen.
PCs mit wechselnden Benutzern knnen z. B. in PC-Pools, fr Schulungszwecke oder aufgrund
organisationsinterner Gegebenheiten eingesetzt werden.
Gefhrdungslage
Fr den IT-Grundschutz eines PCs mit wechselnden Benutzern werden folgende typischen
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.21 Mangelhafte Organisation des Wechsels zwischen den Benutzern
- G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten
- G 3.17 Kein ordnungsgemer PC-Benutzerwechsel
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 5.4 Diebstahl
Fr die Durchfhrung von Datensicherungen seiner persnlichen Daten ist jeder Benutzer selbst
verantwortlich. Der Virenproblematik ist bei Rechnern mit wechselnden Benutzern ganz besondere
Aufmerksamkeit zu schenken. Es sollte daher ein residentes Viren-Suchprogramm eingesetzt werden.
Ansonsten ist sicherzustellen, dass eine berprfung auf Computer-Viren vor und nach jedem
Benutzerwechsel vorgenommen wird.
Nachfolgend wird das Manahmenbndel fr den Bereich "PCs mit wechselnden Benutzern"
vorgestellt:
Infrastruktur:
Organisation:
- M 2.63 (1) Einrichten der Zugriffsrechte
- M 2.65 (1) Kontrolle der Wirksamkeit der Benutzer-Trennung am IT-System
- M 2.66 (2) Beachtung des Beitrags der Zertifizierung fr die Beschaffung
Personal:
- M 3.18 (1) Verpflichtung der Benutzer zum Abmelden nach Aufgabenerfllung
_________________________________________________________________________________________
_________________________________________________________________________________________
Hardware/Software:
(optional)
- M 4.41 (1) Einsatz eines angemessenen PC-Sicherheitsproduktes
- M 4.109 (2) Software-Reinstallation bei Arbeitsplatzrechnern
Notfallvorsorge:
_________________________________________________________________________________________
PC unter Windows NT 5.5
_________________________________________________________________________________________

Beschreibung
Betrachtet werden einzelne, nicht vernetzte PCs mit Fest-
platte (wie in Kapitel 5.1 beschrieben), die unter dem
Betriebssystem Windows NT (Version 3.51 oder 4.0)
betrieben werden. Die PCs knnen mit einem Disketten-
laufwerk ausgestattet sein. Auf sicherheitsspezifische
Aspekte von einzelnen Windows NT-Anwendungen wird
nur am Rande eingegangen.
Gefhrdungslage
Fr den IT-Grundschutz einzelner PCs unter dem
Betriebssystem Windows NT werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.31 Unzureichender Schutz des Windows NT Systems
- G 4.23 Automatische CD-ROM-Erkennung
- G 5.4 Diebstahl
- G 5.52 Missbrauch von Administratorrechten im Windows NT/2000 System
- G 5.79 Unberechtigtes Erlangen von Administratorrechten unter Windows NT/2000
Systemen
_________________________________________________________________________________________
_________________________________________________________________________________________
Die in den folgenden Listen mit dem Zusatz "optional" gekennzeichneten Manahmen gehen
zumindest teilweise ber den Grundschutz hinaus, oder sie beziehen sich auf spezielle Einsatz-
umgebungen. Sie sind dann zu realisieren, wenn die betreffenden Einsatzbedingungen gegeben sind,
insbesondere dann, wenn mehrere Benutzer mit demselben System arbeiten und gegeneinander
geschtzt werden sollen bzw. wenn die Kontrolle sicherheitskritischer Funktionen nicht beim Benutzer
selbst liegt, sondern zentral verwaltet werden soll.
Nachfolgend wird das Manahmenbndel fr den Bereich "Nicht vernetzter Windows NT Rechner"
vorgestellt.
Infrastruktur:
Organisation:
- M 2.26 (1) Ernennung eines Administrators und eines Vertreters (optional)
- M 2.30 (2) Regelung fr die Einrichtung von Benutzern / Benutzergruppen (optional)
- M 2.31 (2) Dokumentation der zugelassenen Benutzer und Rechteprofile (optional)
- M 2.32 (2) Einrichtung einer eingeschrnkten Benutzerumgebung (optional)
- M 2.34 (2) Dokumentation der Vernderungen an einem bestehenden System (optional)
Personal:
- M 3.10 (1) Auswahl eines vertrauenswrdigen Administrators und Vertreters (optional)
- M 3.11 (1) Schulung des Wartungs- und Administrationspersonals (optional)
Hardware/Software:
(optional)
- M 4.48 (1) Passwortschutz unter Windows NT/2000
- M 4.49 (1) Absicherung des Boot-Vorgangs fr ein Windows NT/2000 System
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 4.50 (2) Strukturierte Systemverwaltung unter Windows NT (optional)

- M 4.51 (3) Benutzerprofile zur Einschrnkung der Nutzungsmglichkeiten von Windows NT
(optional)
- M 4.52 (2) Gerteschutz unter Windows NT/2000
- M 4.53 (2) Restriktive Vergabe von Zugriffsrechten auf Dateien und Verzeichnisse unter
Windows NT
- M 4.54 (2) Protokollierung unter Windows NT (optional)
- M 4.55 (2) Sichere Installation von Windows NT
- M 4.56 (3) Sicheres Lschen unter Windows-Betriebssystemen
- M 4.57 (2) Deaktivieren der automatischen CD-ROM-Erkennung
- M 4.75 (1) Schutz der Registrierung unter Windows NT/2000
- M 4.76 (3) Sichere Systemversion von Windows NT
- M 4.77 (1) Schutz der Administratorkonten unter Windows NT
Notfallvorsorge:
- M 6.42 (1) Erstellung von Rettungsdisketten fr Windows NT
- M 6.44 (1) Datensicherung unter Windows NT
_________________________________________________________________________________________
PC mit Windows 95 5.6.1
_________________________________________________________________________________________

Beschreibung
Betrachtet wird ein handelsblicher PC, der mit dem
Betriebssystem Windows 95 betrieben wird. Der PC
verfgt ber ein Diskettenlaufwerk, eine Fest- oder
Wechselplatte, ein CD-ROM Laufwerk und eine Maus.
Ein eventuell vorhandener Drucker wird direkt am PC
angeschlossen. Fr die weiteren Betrachtungen wird
zugrunde gelegt, dass dieser PC auch von mehreren
Benutzern betrieben werden kann.
Dabei gelten jedoch folgende grundlegende
berlegungen:
Wesentliche Sicherheitseigenschaften von Windows 95 lassen sich erst in einem servergesttztem
Netz realisieren. Wird ein Windows 95-Rechner als Einzelplatzrechner betrieben, so sollte von einem
Mehr-Benutzer-Betrieb abgesehen werden, solange nicht unter Zuhilfenahme eines PC-Sicherheits-
produktes wichtige Funktionen wie z. B. Rechtekontrolle und Protokollierung realisiert werden
knnen. Selbst bei Nutzung des Rechners durch nur einen Benutzer gelten dieselben berlegungen,
wenn die Benutzerumgebung durch einen Administrator mittels Systemrichtlinien eingeschrnkt
werden soll, da faktisch damit wieder ein Mehr-Benutzer-Betrieb entsteht.
Fazit: Ein nicht vernetzter Windows 95-Rechner sollte nur von einem Benutzer und uneingeschrnkt
genutzt werden knnen. Eine Einschrnkung des Benutzers ist nur dann sinnvoll, wenn damit das
Navigieren im System erleichtert wird oder wenn Fehlbedienungen damit ausgeschlossen werden
sollen. Wird dennoch ein Mehr-Benutzer-Betrieb realisiert, so ist dieser unter Sicherheitsgesichts-
punkten nur in Kombination mit einem PC-Sicherheitsprodukt sinnvoll.
Gefhrdungslage
Fr den IT-Grundschutz eines PC mit Windows 95 werden folgende Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 2.36 Ungeeignete Einschrnkung der Benutzerumgebung
_________________________________________________________________________________________
_________________________________________________________________________________________

- G 3.22 Fehlerhafte nderung der Registrierung
- G 4.24 Dateinamenkonvertierung bei Datensicherungen unter Windows 95
- G 5.4 Diebstahl
- G 5.60 Umgehen der Systemrichtlinien
Nachfolgend wird das Manahmenbndel fr den Bereich "PC mit Windows 95" vorgestellt. Die
grundlegenden berlegungen zu Anfang des Kapitels (s. o.) sollten dabei bercksichtigt werden. Die
Manahmen unterteilen sich in die folgenden Kategorien:
- Basis-Manahmen (diese sind im wesentlichen analog zu Kapitel 5.1 DOS-PC (ein Benutzer)),
- Manahmen fr den Mehrbenutzerbetrieb und
- Einschrnkungen und
- Einsatz im Netz.
Als Basis-Manahmen sind folgende Manahmen umzusetzen:
Infrastruktur:
Organisation:
Personal:
_________________________________________________________________________________________
_________________________________________________________________________________________
Hardware/Software:
(optional)
Notfallvorsorge:
- M 6.45 (1) Datensicherung unter Windows 95
- M 6.46 (1) Erstellung von Rettungsdisketten fr Windows 95
Sollen an dem Windows 95-Rechner mehrere Benutzer arbeiten, so ist eine Administration des
Rechners und eine Benutzertrennung unumgnglich. In diesem Fall sind die folgenden Manahmen
fr den Mehrbenutzerbetrieb zustzlich umzusetzen:
Organisation:
- M 2.103 (1) Einrichten von Benutzerprofilen unter Windows 95
Personal:
Soll die Benutzerumgebung benutzerspezifisch mit bestimmten Einschrnkungen versehen werden, so
sind weiterhin die folgenden Manahmen zu ergreifen (die Manahmen M 2.64 Kontrolle der
Protokolldateien und M 2.65 Kontrolle der Wirksamkeit der Benutzer-Trennung am IT-System wirken
nur in Verbindung mit M 4.41 Einsatz eines angemessenen PC-Sicherheitsproduktes oder M 4.42
Implementierung von Sicherheitsfunktionalitten in der IT-Anwendung):
Organisation:
- M 2.104 (1) Systemrichtlinien zur Einschrnkung der Nutzungsmglichkeiten von Windows 95
Hardware/Software:
_________________________________________________________________________________________
_________________________________________________________________________________________
Ist der PC mit Windows 95 in einem Netz eingebunden, so ist zustzlich folgende Manahme
umzusetzen:
Hardware/Software:
- M 4.74 (1) Vernetzte Windows 95 Rechner
_________________________________________________________________________________________
Windows 2000 Client 5.7
_________________________________________________________________________________________

Beschreibung
Betrachtet werden einzelne, als Client betriebene PCs mit
Festplatte, die unter dem Betriebssystem Windows 2000
Professional ablaufen. Die PCs knnen miteinander,
innerhalb eines LANs oder gar nicht vernetzt sein. Auf
sicherheitsspezifische Aspekte von einzelnen
Windows 2000-Anwendungen wird nur am Rande einge-
gangen. Die Server-spezifischen Sicherheitsmanahmen
sind dem Kapitel 6 (siehe Baustein 6.9 Windows 2000
Server) zu entnehmen.
Gefhrdungslage
Fr den IT-Grundschutz einzelner PCs unter dem Betriebssystem Windows 2000 werden folgende
typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 5.4 Diebstahl
_________________________________________________________________________________________
_________________________________________________________________________________________
Systemen
Die in den folgenden Listen mit dem Zusatz "optional" gekennzeichneten Manahmen gehen
zumindest teilweise ber den IT-Grundschutz hinaus, oder sie beziehen sich auf spezielle Einsatz-
umgebungen. Sie sind dann zu realisieren, wenn die betreffenden Einsatzbedingungen gegeben sind,
insbesondere dann, wenn mehrere Benutzer mit demselben System arbeiten und gegeneinander
geschtzt werden sollen bzw. wenn die Kontrolle sicherheitskritischer Funktionen nicht beim Benutzer
selbst liegt, sondern zentral verwaltet werden soll.
Nach der Entscheidung, Windows 2000 als Client-Betriebssystem einzusetzen, sollte zunchst der
Einsatz von Windows 2000 geplant werden (siehe Manahme M 2.227 Planung des Windows 2000
Einsatzes). Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe Manahme M 2.228
Festlegen einer Windows 2000 Sicherheitsrichtlinie ).
Nachfolgend wird das Manahmenbndel fr den Baustein "Windows 2000 Client" vorgestellt.
Infrastruktur:
Organisation:
- M 2.26 (1) Ernennung eines Administrators und eines Vertreters (optional)
- M 2.30 (2) Regelung fr die Einrichtung von Benutzern / Benutzergruppen (optional)
- M 2.31 (2) Dokumentation der zugelassenen Benutzer und Rechteprofile (optional)
- M 2.34 (2) Dokumentation der Vernderungen an einem bestehenden System (optional)
- M 2.227 (1) Planung des Windows 2000 Einsatzes
- M 2.228 (1) Festlegen einer Windows 2000 Sicherheitsrichtlinie
- M 2.231 (1) Planung der Gruppenrichtlinien unter Windows 2000
Personal:
- M 3.10 (1) Auswahl eines vertrauenswrdigen Administrators und Vertreters (optional)
- M 3.11 (1) Schulung des Wartungs- und Administrationspersonals (optional)
- M 3.28 (1) Schulung zu Windows 2000 Sicherheitsmechanismen fr Benutzer
_________________________________________________________________________________________
_________________________________________________________________________________________
Hardware/Software:
Datenspeichern
(optional)
- M 4.136 (1) Sichere Installation von Windows 2000
- M 4.148 (1) berwachung eines Windows 2000 Systems
- M 4.149 (1) Datei- und Freigabeberechtigungen unter Windows 2000
- M 4.150 (1) Konfiguration von Windows 2000 als Workstation
- M 4.200 (2) Umgang mit USB-Speichermedien (optional)
Notfallvorsorge:
_________________________________________________________________________________________
Internet-PC 5.8
_________________________________________________________________________________________
5.8 Internet-PC
Beschreibung
Die Nutzung des Internets zur Informationsbeschaffung
und Kommunikation ist in weiten Bereichen der ffent-
lichen Verwaltung und Privatwirtschaft zur Selbstver-
stndlichkeit geworden. Auch E-Commerce- und
E-Government-Anwendungen gewinnen immer mehr an
Bedeutung. Grtmglichen Komfort bietet es dabei, den
Mitarbeitern einer Institution einen Internet-Zugang
direkt ber den Arbeitsplatz-PC zur Verfgung zu stellen.
Dieser ist jedoch meist in ein lokales Netz (LAN) einge-
bunden, so dass dadurch unter Umstnden zustzliche Bedrohungen fr die Institution entstehen.
Um diese Probleme zu umgehen oder aus anderen anwendungsspezifischen Grnden stellen viele
Behrden und Unternehmen eigenstndige "Internet-PCs" zur Verfgung. Ein Internet-PC ist ein
Computer, der ber eine Internet-Anbindung verfgt, jedoch nicht mit dem internen Netz der Insti-
tution verbunden ist. Falls es sich um mehrere Internet-PCs handelt, knnen diese Computer auch
untereinander vernetzt sein, beispielsweise um eine gemeinsame Internet-Anbindung zu nutzen. Inter-
net-PCs dienen meist dazu, Mitarbeitern die Nutzung von Internet-Diensten zu ermglichen und dabei
zustzliche Bedrohungen fr das lokale Netz zu vermeiden.
Betrachtet wird ein Internet-PC auf der Basis eines Windows-Betriebssystems oder Linux. Fr die
Nutzung der Internet-Dienste kommen gngige Browser, wie z. B. Internet Explorer, Netscape
Navigator oder Opera, sowie E-Mail-Clients, wie z. B. Microsoft Outlook, Outlook Express, Netscape
Messenger oder KMail, zum Einsatz. Je nach Einsatzszenario knnen weitere Programme fr die
Nutzung anderer Internet-Dienste, beispielsweise News, Instant Messaging oder Internet-Banking,
installiert sein.
Gefhrdungslage
Fr den IT-Grundschutz eines Internet-PCs werden die folgenden typischen Gefhrdungen ange-
nommen:
Hhere Gewalt:
- G 3.37 Unproduktive Suchzeiten
- G 3.38 Konfigurations- und Bedienungsfehler
_________________________________________________________________________________________
Internet-PC 5.8
_________________________________________________________________________________________
- G 5.48 IP-Spoofing
- G 5.78 DNS-Spoofing
- G 5.87 Web-Spoofing
- G 5.88 Missbrauch aktiver Inhalte
- G 5.91 Abschalten von Sicherheitsmechanismen fr den RAS-Zugang
- G 5.103 Missbrauch von Webmail
Ist geplant, in einem Unternehmen bzw. in einer Behrde einen oder mehrere Internet-PCs zur Verf-
gung zu stellen, sollten im Hinblick auf die IT-Sicherheit folgende Schritte durchlaufen werden:
1. Konzeption von Internet-PCs (siehe M 2.234 Konzeption von Internet-PCs)
Zu Anfang mssen grundstzliche Fragen des Einsatzes festgelegt werden, beispielsweise welche
Internet-Dienste genutzt werden sollen und wer fr die Administration des Internet-PCs zustndig
ist.
2. Richtlinien fr die Nutzung von Internet-PCs (siehe M 2.235 Richtlinien fr die Nutzung von
Internet-PCs)
Fr die sichere Nutzung eines Internet-PCs mssen verbindliche Richtlinien festgelegt werden.
Dies umfasst beispielsweise, wer den Internet-PC wann und wofr nutzen darf und ggf. wie Daten
zwischen dem Internet-PC und dem Hausnetz transportiert werden.
3. Sichere Installation von Internet-PCs (siehe M 4.151 Sichere Installation von Internet-PCs)
Durch die Verbindung zum Internet ergeben sich fr die auf dem Internet-PC installierten
Anwendungen und fr die gespeicherten Daten zustzliche Gefhrdungen. Eine sorgfltige
Auswahl der Betriebssystem- und Software-Komponenten sowie deren sichere Installation ist daher
besonders wichtig.
4. Sichere Konfiguration der installierten Komponenten
Je nach Sicherheitsanforderungen mssen die beteiligten Software-Komponenten unterschiedlich
konfiguriert werden. Dies betrifft insbesondere den verwendeten Browser (siehe M 5.93 Sicherheit
von WWW-Browsern bei der Nutzung von Internet-PCs) den E-Mail-Client (siehe M 5.94
Sicherheit von E-Mail-Clients bei der Nutzung von Internet-PCs ) und ggf. spezielle E-Business-
Software.
5. Sicherer Betrieb von Internet-PCs (siehe M 4.152 Sicherer Betrieb von Internet-PCs)
Eine der wichtigsten IT-Sicherheitsmanahmen beim Betrieb eines Internet-PCs ist das
systematische und schnellstmgliche Einspielen sicherheitsrelevanter Patches und Updates. Um
Angriffsversuche und missbruchliche Nutzung erkennen zu knnen, sollte das System auerdem
berwacht werden.
6. Datensicherung beim Einsatz von Internet-PCs (siehe M 6.79 Datensicherung beim Einsatz von
Internet-PCs)
Die Vorgehensweise und der erforderliche Umfang der Datensicherung richtet sich nach dem
Einsatzszenario des Internet-PCs.
_________________________________________________________________________________________
Internet-PC 5.8
_________________________________________________________________________________________
Der vorliegende Baustein gibt Empfehlungen zur Konzeption, Konfiguration und Betrieb eines
solchen Internet-PCs. Wichtig ist dabei, dass die hier aufgefhrten Manahmen nicht ausreichend sind
fr einen Standard-Arbeitsplatz-PC, auf dem in der Regel mehrere unterschiedliche Anwendungen
betrieben und mit dem schtzenswerte Daten verarbeitet werden. Dieses Manahmenbndel richtet
sich ausschlielich an das spezielle Einsatzszenario "Internet-PC". Geeignete IT-Sicherheitsempfeh-
lungen fr Standard-Arbeitsplatz-PCs sind in anderen Bausteinen des Kapitels 5 beschrieben.
Nachfolgend wird das Manahmenbndel fr den Baustein "Internet-PC" vorgestellt.
Infrastruktur:
Organisation:
- M 2.234 (1) Konzeption von Internet-PCs
- M 2.235 (2) Richtlinien fr die Nutzung von Internet-PCs
Personal:
Hardware/Software:
- M 4.41 (1) Einsatz eines angemessenen PC-Sicherheitsproduktes (optional)
- M 4.151 (1) Sichere Installation von Internet-PCs
- M 4.152 (2) Sicherer Betrieb von Internet-PCs
Kommunikation:
- M 5.59 (1) Schutz vor DNS-Spoofing
- M 5.66 (2) Verwendung von SSL
- M 5.91 (3) Einsatz von Personal Firewalls fr Internet-PCs (optional)
- M 5.92 (1) Sichere Internet-Anbindung von Internet-PCs
- M 5.93 (1) Sicherheit von WWW-Browsern bei der Nutzung von Internet-PCs
- M 5.94 (2) Sicherheit von E-Mail-Clients bei der Nutzung von Internet-PCs
- M 5.95 (2) Sicherer E-Commerce bei der Nutzung von Internet-PCs
- M 5.96 (1) Sichere Nutzung von Webmail
- M 5.98 (2) Schutz vor Missbrauch kostenpflichtiger Einwahlnummern
Notfallvorsorge:
- M 6.79 (1) Datensicherung beim Einsatz von Internet-PCs
_________________________________________________________________________________________
Allgemeines nicht vernetztes IT-System 5.99.1
_________________________________________________________________________________________
5.99 Allgemeines nicht vernetztes IT-

System
Beschreibung
Betrachtet wird ein IT-System, das mit keinem anderen
IT-System vernetzt ist. Es kann mit einem beliebigen
Betriebssystem ausgestattet sein. Das IT-System kann auf
einer beliebigen Plattform betrieben werden, es kann sich
dabei um einen PC mit oder ohne Festplatte, aber auch
um eine Unix-Workstation oder einen Apple Macintosh
handeln. Das IT-System kann ber Disketten- und CD-
Laufwerke, eine Festplatte, eine Maus und andere
Peripheriegerte verfgen. Ein eventuell vorhandener Drucker wird direkt am IT-System
angeschlossen. Weiterhin kann eine graphische Benutzeroberflche eingesetzt sein.
Dieses Kapitel bietet einen berblick ber Gefhrdungen und IT-Sicherheitsmanahmen, die fr nicht
vernetzte IT-Systeme typisch sind. Dieser berblick ist unabhngig vom eingesetzten Betriebssystem.
Dafr sind die weiterfhrenden Kapitel des IT-Grundschutzhandbuchs (zum Beispiel Kapitel 5.2 Nicht
vernetztes Unix-System) zu beachten.
Gefhrdungslage
Fr den IT-Grundschutz eines allgemeinen nicht vernetzten IT-Systems werden folgende
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 5.4 Diebstahl
Nachfolgend wird das Manahmenbndel fr den Bereich "Allgemeines nicht vernetztes IT-System"
vorgestellt. Die Manahmen unterteilen sich in
- Basis-Manahmen und
- Manahmen fr den Mehrbenutzerbetrieb.
Abhngig vom eingesetzten Betriebssystem sind bei der Anwendung dieses Bausteins ggf. weitere
Manahmen erforderlich.
Als Basis-Manahmen sind folgende Manahmen umzusetzen:
Infrastruktur:
Organisation:
Personal:
Hardware/Software:
(optional)
Notfallvorsorge:
_________________________________________________________________________________________
_________________________________________________________________________________________

Sollen an dem IT-System mehrere Benutzer arbeiten, so ist eine Administration des Rechners und eine
Benutzertrennung unumgnglich. In diesem Fall sind die folgenden Manahmen und Gefhrdungen
fr den Mehrbenutzerbetrieb zustzlich zu betrachten:
Gefhrdungslage
Organisation:
Personal:
- M 3.18 (1) Verpflichtung der PC-Benutzer zum Abmelden nach Aufgabenerfllung
Hardware/Software:
Wird durch das auf dem IT-System eingesetzte Betriebssystem keine Benutzertrennung ermglicht, ist
zustzlich die folgende Manahme zu beachten:
_________________________________________________________________________________________
Vernetzte Systeme 6
_________________________________________________________________________________________
6 Vernetzte Systeme
In diesem Kapitel wird der IT-Grundschutz fr vernetzte Systeme definiert. Als Grundlage dient
Kapitel 6.1, das betriebssystemunabhngig notwendige Manahmen aufzeigt. Es wird ergnzt um die
betriebssystem-spezifischen Manahmen der Kapitel 6.2, 6.4, 6.5, 6.6 und 6.9. Wird zustzlich eine
Peer-to-Peer-Funktionalitt benutzt, ist zustzlich Kapitel 6.3 zu beachten.
Werden heterogene Netze miteinander gekoppelt, ist das Kapitel 6.7 zustzlich zu beachten.
Die Manahmen zu den angeschlossenen Clients sind Kapitel 5 zu entnehmen.
Folgende Kapitel sind vorhanden:
6.2 Unix-Server
6.4 Windows NT Netz
_________________________________________________________________________________________
Servergesttztes Netz 6.1
_________________________________________________________________________________________

Beschreibung
Betrachtet wird ein lokales Netz mit mindestens einem
Server. Die Clients knnen PCs mit oder ohne Festplatte
(wie in Kapitel 5.1 beschrieben) sein, aber auch Unix-
Workstations oder Terminals. Dieses Kapitel bietet einen
berblick ber Gefhrdungen und IT-
Sicherheitsmanahmen, die fr lokale Netze typisch sind.
Dieser berblick ist jedoch unabhngig vom
Netzbetriebssystem bzw. den Betriebssystemen der
Clients. Dafr sind die weiterfhrenden Kapitel des IT-
Grundschutzhandbuchs (zum Beispiel Kapitel 6.2 Unix-
Server) zu beachten.
Gefhrdungslage
Fr den IT-Grundschutz eines servergesttzten Netzes werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 1.5 Wasser
- G 3.31 Unstrukturierte Datenhaltung
- G 4.10 Komplexitt der Zugangsmglichkeiten zu vernetzten IT-Systemen
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 5.4 Diebstahl
- G 5.24 Wiedereinspielen von Nachrichten
- G 5.25 Maskerade
- G 5.26 Analyse des Nachrichtenflusses
- G 5.28 Verhinderung von Diensten
Nachfolgend wird das Manahmenbndel fr den Bereich "Servergesttztes Netz" vorgestellt.
Es wird vorausgesetzt, dass der Server in einem Serverraum (vgl. Kapitel 4.3.2) bzw. in einem
Serverschrank (vgl. Kapitel 4.4) untergebracht ist. Die fr die Netzbetriebssysteme umzusetzenden
Manahmen sind den ergnzenden Kapitel des Handbuchs zu entnehmen. Dies gilt analog auch fr die
angeschlossenen Clients.
Infrastruktur:
- M 1.28 (2) Lokale unterbrechungsfreie Stromversorgung
- M 1.32 (1) Geeignete Aufstellung von Konsole, Gerten mit austauschbaren Datentrgern und
Druckern
Organisation:
- M 2.38 (2) Aufteilung der Administrationsttigkeiten
- M 2.138 (2) Strukturierte Datenhaltung
_________________________________________________________________________________________
_________________________________________________________________________________________
Personal:
Hardware/Software:
- M 4.16 (2) Zugangsbeschrnkungen fr Accounts und / oder Terminals
- M 4.24 (2) Sicherstellung einer konsistenten Systemverwaltung
Kommunikation:
- M 5.6 (1) Obligatorischer Einsatz eines Netzpasswortes
- M 5.7 (1) Netzverwaltung
- M 5.8 (1) Monatlicher Sicherheitscheck des Netzes
- M 5.9 (2) Protokollierung am Server
- M 5.10 (1) Restriktive Rechtevergabe
- M 5.13 (1) Geeigneter Einsatz von Elementen zur Netzkopplung
Notfallvorsorge:
- M 6.25 (1) Regelmige Datensicherung der Server-Festplatte
_________________________________________________________________________________________
Unix-Server 6.2
_________________________________________________________________________________________
6.2 Unix-Server
Beschreibung
Unix-Server sind Rechner mit dem Betriebssystem Unix,
die in einem Netz Dienste anbieten, die von anderen IT-
Systemen in Anspruch genommen werden knnen.
In diesem Kapitel werden ausschlielich die fr einen
Unix-Server spezifischen Gefhrdungen und Manahmen
beschrieben, daher sind zustzlich noch diejenigen fr
servergesttzte Netze aus Kapitel 6.1 zu betrachten.
Gefhrdungslage
Fr den IT-Grundschutz eines Unix-Servers werden
folgende typische Gefhrdungen angenommen:
- G 2.15 Vertraulichkeitsverlust schutzbedrftiger Daten im Unix-System
- G 2.23 Schwachstellen bei der Einbindung von DOS-PCs in ein servergesttztes Netz
- G 2.65 Komplexitt der SAMBA-Konfiguration
- G 3.10 Falsches Exportieren von Dateisystemen unter Unix
- G 3.11 Fehlerhafte Konfiguration von sendmail
- G 5.41 Mibruchliche Nutzung eines Unix-Systems mit Hilfe von uucp
- G 5.89 Hijacking von Netz-Verbindungen
Nachfolgend wird das Manahmenbndel fr den Bereich Unix-Server vorgestellt.
Einige Manahmen beziehen sich auf die Konfiguration der einzelnen Server, andere Manahmen
mssen auf Servern und Clients eingesetzt werden, um wirksam zu werden. Fr eventuell ange-
schlossene Clients sind die in Kapitel 5 beschriebenen Manahmen zu realisieren.
Es ist sinnvoll, den Server in einem separaten Serverraum aufzustellen. Zu realisierende Manahmen
sind in Kapitel 4.3.2 beschrieben. Steht kein Serverraum zur Verfgung, sollte ein Serverschrank
verwendet werden, vgl. Kapitel 4.4.
Infrastruktur:
_________________________________________________________________________________________
Unix-Server 6.2
_________________________________________________________________________________________
Organisation:
- M 2.33 (2) Aufteilung der Administrationsttigkeiten unter Unix
Hardware/Software:
Zugang zum Unix-System
- M 4.13 (1) Sorgfltige Vergabe von IDs
- M 4.14 (1) Obligatorischer Passwortschutz unter Unix
- M 4.18 (1) Administrative und technische Absicherung des Zugangs zum Monitor- und
Single-User-Modus
- M 4.105 (1) Erste Manahmen nach einer Unix-Standardinstallation
Attributvergabe/Arbeiten mit dem Unix-System

- M 4.9 (1) Einsatz der Sicherheitsmechanismen von X-Windows
- M 4.19 (1) Restriktive Attributvergabe bei Unix-Systemdateien und -verzeichnissen
- M 4.20 (2) Restriktive Attributvergabe bei Unix-Benutzerdateien und -verzeichnissen
- M 4.21 (1) Verhinderung des unautorisierten Erlangens von Administratorrechten
- M 4.22 (3) Verhinderung des Vertraulichkeitsverlusts schutzbedrftiger Daten im Unix-
System
- M 4.23 (3) Sicherer Aufruf ausfhrbarer Dateien
Protokollierung/Sicherheitscheck
- M 4.25 (1) Einsatz der Protokollierung im Unix-System
- M 4.26 (2) Regelmiger Sicherheitscheck des Unix-Systems
- M 4.106 (1) Aktivieren der Systemprotokollierung
- M 4.107 (2) Nutzung von Hersteller-Ressourcen
Kommunikation:
- M 5.16 (2) bersicht ber Netzdienste
- M 5.17 (1) Einsatz der Sicherheitsmechanismen von NFS
- M 5.18 (1) Einsatz der Sicherheitsmechanismen von NIS
- M 5.19 (1) Einsatz der Sicherheitsmechanismen von sendmail
- M 5.20 (1) Einsatz der Sicherheitsmechanismen von rlogin, rsh und rcp
- M 5.21 (1) Sicherer Einsatz von telnet, ftp, tftp und rexec
- M 5.34 (2) Einsatz von Einmalpasswrtern (optional)
- M 5.35 (1) Einsatz der Sicherheitsmechanismen von UUCP
- M 5.38 (2) Sichere Einbindung von DOS-PCs in ein Unix-Netz
- M 5.64 (2) Secure Shell
- M 5.72 (1) Deaktivieren nicht bentigter Netzdienste
- M 5.82 (1) Sicherer Einsatz von SAMBA
- M 5.83 (2) Sichere Anbindung eines externen Netzes mit Linux FreeS/WAN (optional)
Notfallvorsorge:
_________________________________________________________________________________________
Peer-to-Peer-Dienste 6.3
_________________________________________________________________________________________
Beschreibung
Peer-to-Peer-Dienste sind Funktionen auf Arbeitsplatz-
Computern, die anderen IT-Systemen im lokalen Netz
Ressourcen zur Verfgung stellen, beispielsweise
gemeinsamen Zugriff auf die Festplatte oder auf Drucker.
Solche Dienste werden von den gngigen Betriebssyste-
men untersttzt. In diesem Baustein werden die Betriebs-
systeme Windows fr Workgroups (WfW),
Windows 95/NT/2000 und Unix betrachtet, bercksich-
tigt wird hier aber nur die reine Peer-to-Peer-Funktiona-
litt dieser Betriebssysteme. Auf sicherheitsspezifische
Aspekte einzelner Anwendungen bei der Benutzung von Peer-to-Peer-Funktionalitten, zum Beispiel
bezglich Mail, Exchange, Schedule+, Direct-Data-Exchange (DDE) oder Remote Access Service
(RAS), wird nur am Rande eingegangen. Weiterhin werden in diesem Kapitel ausschlielich die fr
Peer-to-Peer-Dienste spezifischen Gefhrdungen und Manahmen beschrieben, daher sind zustzlich
noch die betriebssystemspezifischen Bausteine aus Kapitel 5 zu betrachten. Peer-to-Peer-Kommuni-
kation ber das Internet ist nicht Gegenstand dieses Bausteins.
Da Peer-to-Peer-Dienste wesentlich geringere Sicherheitsfunktionalitten bieten als durch dedizierte
Server bereitgestellte Dienste, sollten Peer-to-Peer-Dienste innerhalb servergesttzter Netze nicht
verwendet werden.
Gefhrdungslage
Fr den IT-Grundschutz von Peer-to-Peer-Diensten werden folgende typische Gefhrdungen
angenommen:
- G 2.25 Einschrnkung der bertragungs- oder Bearbeitungsgeschwindigkeit durch Peer-
to-Peer-Funktionalitten
- G 2.65 Komplexitt der SAMBA-Konfiguration
- G 3.18 Freigabe von Verzeichnissen, Druckern oder der Ablagemappe
- G 3.19 Speichern von Passwrtern unter WfW und Windows 95
- G 3.20 Ungewollte Freigabe des Leserechtes bei Schedule+
- G 5.45 Ausprobieren von Passwrtern unter WfW und Windows 95
- G 5.46 Maskerade unter WfW
- G 5.47 Lschen des Post-Office unter WfW
_________________________________________________________________________________________
Peer-to-Peer-Dienste 6.3
_________________________________________________________________________________________
Bei der Bearbeitung der originren Peer-to-Peer-Manahmen sollte zuerst anhand von Manahme
M 2.67 Festlegung einer Sicherheitsstrategie fr Peer-to-Peer-Dienste eine Sicherheitsstrategie
ausgearbeitet werden, da diese die Grundlage fr die weiteren Manahmen ist.
Nachfolgend wird das Manahmenbndel fr den Bereich "Peer-to-Peer-Dienste" vorgestellt:

Organisation:
- M 2.67 (1) Festlegung einer Sicherheitsstrategie fr Peer-to-Peer-Dienste
- M 2.68 (2) Sicherheitskontrollen durch die Benutzer beim Einsatz von Peer-to-Peer-Diensten
- M 2.94 (2) Freigabe von Verzeichnissen unter Windows NT
Personal:
- M 3.19 (1) Einweisung in den richtigen Einsatz der Sicherheitsfunktionen von Peer-to-Peer-
Diensten
Hardware/Software:
- M 4.45 (1) Einrichtung einer sicheren Peer-to-Peer-Umgebung unter WfW
- M 4.46 (1) Nutzung des Anmeldepasswortes unter WfW und Windows 95
- M 4.58 (2) Freigabe von Verzeichnissen unter Windows 95
Kommunikation:
- M 5.37 (2) Einschrnken der Peer-to-Peer-Funktionalitten in einem servergesttzten Netz
(optional)
- M 5.82 (2) Sicherer Einsatz von SAMBA
Notfallvorsorge:
_________________________________________________________________________________________
Windows NT Netz 6.4
_________________________________________________________________________________________
6.4 Windows NT Netz

Beschreibung
Betrachtet wird ein Windows NT Netz, das als Client-
Server-System unter dem Betriebssystem Windows NT
Version 3.51 oder 4.0 betrieben wird. Dieses Kapitel
behandelt die Sicherheitsaspekte eines Windows NT
Servers, die Client-spezifischen Manahmen sind
Kapitel 5 zu entnehmen.
Auf sicherheitsspezifische Aspekte von Windows NT-
Anwendungen, zum Beispiel bezglich Mail, Schedule+,
Direct-Data-Exchange (DDE) oder Remote Access
Service (RAS), wird nur am Rande eingegangen. Zustzlich zu den hier angegebenen Gefhrdungen
und Schutzmanahmen gelten noch die im Kapitel 6.1 fr ein allgemeines servergesttztes Netz
genannten Manahmen. Falls im Windows NT Netz die Peer-to-Peer Funktionalitt von Windows NT
genutzt wird, ist auerdem der Inhalt des Kapitels 6.3 zu bercksichtigen.
Gefhrdungslage
Fr den IT-Grundschutz eines servergesttzten Netzes unter dem Betriebssystem Windows NT
werden folgende typische Gefhrdungen angenommen:
- G 2.23 Schwachstellen bei der Einbindung von DOS-PCs in ein servergesttztes Netz
- G 2.25 Einschrnkung der bertragungs- oder Bearbeitungsgeschwindigkeit durch Peer-
to-Peer-Funktionalitten
- G 2.30 Unzureichende Domnenplanung
- G 2.31 Unzureichender Schutz des Windows NT Systems
Systemen
Bei der Bearbeitung der originren Windows NT Manahmen sollte zuerst anhand der Manahme
M 2.91 Festlegung einer Sicherheitsstrategie fr das Windows NT Client-Server-Net und zustzlich,
soweit Peer-to-Peer Funktionalitt genutzt wird, auch der Manahme M 2.67 Festlegung einer
Sicherheitsstrategie fr Peer-to-Peer-Dienste eine Sicherheitsstrategie ausgearbeitet werden, da diese
die Grundlage fr die weiteren Manahmen ist.
_________________________________________________________________________________________
Windows NT Netz 6.4
_________________________________________________________________________________________
Die eigentliche Planung des Windows NT Netzes sollte dann, wie in der Manahme M 2.93 Planung
des Windows NT Netzes , durchgefhrt werden. Entsprechend den dabei erarbeiteten Vorgaben sollte
zunchst ein Server installiert und mit einer kleinen Anzahl von Clients ausgetestet werden, um die
festgelegten Strukturen optimieren und anpassen zu knnen, ehe sie in der Breite eingesetzt werden.
Fr die unter Windows NT vernetzten Systeme sind, neben den hier genannten Manahmen, die in
Kapitel 6.1 beschriebenen Manahmen zu realisieren. Sinnvoll erscheint es, den Fileserver in einem
separaten Serverraum aufzustellen. Zu realisierende Manahmen sind in Kapitel 4.3.2 beschrieben.
Alternativ ist die Verwendung eines Serverschrankes, vgl. Kapitel 4.4.
Fr angeschlossene Clients sind die in Kapitel 5 beschriebenen Manahmen zu realisieren. Soweit
auch die Peer-to-Peer Funktionalitt von Windows NT genutzt wird, sind auerdem die in Kapitel 6.3
genannten Manahmen zu realisieren.
Die mit dem Zusatz "optional" gekennzeichneten Manahmen gehen zumindest teilweise ber den IT-
Grundschutz hinaus, oder sie beziehen sich auf spezielle Einsatzumgebungen. Sie sind dann zu
realisieren, wenn die betreffenden Einsatzbedingungen gegeben sind und/oder spezifische, durch diese
Manahmen abgewehrte Bedrohungen zu erwarten sind.
Nachfolgend wird das Manahmenbndel fr den Bereich "Windows NT Netz" vorgestellt:
Organisation:
- M 2.91 (1) Festlegung einer Sicherheitsstrategie fr das Windows NT Client-Server-Netz
- M 2.92 (2) Durchfhrung von Sicherheitskontrollen im Windows NT Client-Server-Netz
- M 2.93 (1) Planung des Windows NT Netzes
- M 2.94 (3) Freigabe von Verzeichnissen unter Windows NT
Hardware/Software:
- M 4.50 (2) Strukturierte Systemverwaltung unter Windows NT (optional)
- M 4.51 (3) Benutzerprofile zur Einschrnkung der Nutzungsmglichkeiten von Windows NT
(optional)
- M 4.53 (2) Restriktive Vergabe von Zugriffsrechten auf Dateien und Verzeichnisse unter
Windows NT
- M 4.54 (2) Protokollierung unter Windows NT
- M 4.55 (2) Sichere Installation von Windows NT
- M 4.76 (2) Sichere Systemversion von Windows NT
- M 4.77 (1) Schutz der Administratorkonten unter Windows NT
_________________________________________________________________________________________
Windows NT Netz 6.4
_________________________________________________________________________________________
Kommunikation:
- M 5.40 (1) Sichere Einbindung von DOS-PCs in ein Windows NT Netz
- M 5.41 (2) Sichere Konfiguration des Fernzugriffs unter Windows NT
- M 5.42 (2) Sichere Konfiguration der TCP/IP-Netzverwaltung unter Windows NT
- M 5.43 (2) Sichere Konfiguration der TCP/IP-Netzdienste unter Windows NT
Notfallvorsorge:
- M 6.42 (2) Erstellung von Rettungsdisketten fr Windows NT
- M 6.43 (3) Einsatz redundanter Windows NT/2000 Server (optional)
- M 6.44 (1) Datensicherung unter Windows NT
_________________________________________________________________________________________
Novell Netware 3.x 6.5
_________________________________________________________________________________________

Beschreibung
Betrachtet wird ein LAN mit PCs, die unter dem
Netzbetriebssystem Novell Netware 3.x vernetzt sind.
Die PCs knnen mit Festplatte, CD-ROM Laufwerk
sowie Diskettenlaufwerken ausgestattet sein. An das Netz
sind ggf. ein oder mehrere Netzdrucker als
Warteschleifendrucker angeschlossen. Gegenstand dieses
Kapitels ist das Novell 3.x Netz in einer Client-Server-
Funktionalitt. Damit ist dieses Kapitel die
betriebssystemspezifische Ergnzung des Kapitels 6.1
"Servergesttztes Netz".
Die Funktionalitten des sog. Accounting werden nicht betrachtet.
Bemerkung: Namen von Dateien und Programmen werden immer durch Grobuchstaben mit kursiver
Schreibweise (z. B. SYS:PUBLIC\SYSCON.EXE) dargestellt.
Gefhrdungen und die hieraus abgeleiteten Manahmen wurden anhand der Versionen Novell 3.11
und 3.12 erarbeitet. Aufgrund verschiedener Patchlevel im Netzbetriebssystem ist es mglich, dass
nicht alle Gefhrdungen auf jede Variante von Novell Netware 3.x zutreffen.
Gefhrdungslage
Fr den IT-Grundschutz werden die folgenden typischen Gefhrdungen betrachtet:
Hhere Gewalt:
- G 2.33 Nicht gesicherter Aufstellungsort von Novell Netware Servern
- G 2.34 Fehlende oder unzureichende Aktivierung von Novell Netware
Sicherheitsmechanismen
- G 5.54 Vorstzliches Herbeifhren eines Abnormal End
- G 5.55 Login Bypass
- G 5.56 Temporr frei zugngliche Accounts
- G 5.57 Netzanalyse-Tools
- G 5.58 "Hacking Novell Netware"
- G 5.59 Missbrauch von Administratorrechten unter Novell Netware 3.x
_________________________________________________________________________________________
Novell Netware 3.x 6.5
_________________________________________________________________________________________
Fr die vernetzten PCs sind die in Kapitel 5 beschriebenen Manahmen zu realisieren. Zu beachten ist,
dass das hier vorgestellte Manahmenbndel, das nur die Besonderheiten des Netzbetriebssystems
Novell Netware 3.x bercksichtigt, um die allgemeinen Netzsicherheitsmanahmen des Kapitels 6.1
"Servergesttztes Netz" ergnzt werden muss.
Nachfolgend wird das Manahmenbndel fr den Bereich "Novell Netware 3.x" vorgestellt.
Infrastruktur:
- M 1.42 (1) Gesicherte Aufstellung von Novell Netware Servern
Organisation:
- M 2.98 (2) Sichere Installation von Novell Netware Servern
- M 2.99 (1) Sichere Einrichtung von Novell Netware Servern
- M 2.100 (1) Sicherer Betrieb von Novell Netware Servern
- M 2.101 (2) Revision von Novell Netware Servern
- M 2.102 (3) Verzicht auf die Aktivierung der Remote Console (optional)
_________________________________________________________________________________________
Novell Netware Version 4.x 6.6
_________________________________________________________________________________________

Beschreibung
Betrachtet wird das Netzbetriebssystem Novell
Netware 4.x (mit dem Schwerpunkt auf Netware 4.11).
Novell Netware wird auf PC-Servern betrieben und stellt
im wesentlichen die Infrastrukturdienste Authentisierung,
Verzeichnisdienst, Dateidienst, Druckdienst und
Protokolldienst in einem Netz zur Verfgung.
Gegenstand dieses Kapitels ist das Novell 4.x Netz in
einer Client-Server-Funktionalitt. Damit ist dieses
Kapitel eine betriebssystemspezifische Ergnzung des
Kapitels 6.1 "Servergesttztes Netz".
Zentraler Aspekt des Novell Netware 4.x-Betriebssystems ist die Verteilung der zentralen Datenbank
des Verzeichnisdienstes NDS (Novell Directory Services) unabhngig von spezifischen Server-
systemen ber das LAN und der objektorientierte Ansatz zur Verwaltung aller Elemente im Betriebs-
systemumfeld in einer einheitlichen Umgebung.
Die Funktionalitten der Zusatzprodukte von Novell Netware wie z. B. DHCP, WEB Server und
WAN Connectivity sind ebenfalls Bestandteil dieser Betrachtung.
Bemerkungen:
- Namen von Dateien und Programmen werden immer durch Grobuchstaben mit kursiver Schreib-
weise (z. B. SYS:PUBLIC\NWADMIN.EXE) dargestellt.
- Gefhrdungen und die hieraus abgeleiteten Manahmen wurden anhand der Version Novell 4.11
erarbeitet. Aufgrund verschiedener Patchlevel bzw. Entwicklungsunterschiede zwischen
Netware 4.10 und Netware 4.11 im Netzbetriebssystem ist es mglich, dass nicht alle Gefhr-
dungen auf jede Variante von Novell Netware 4.x zutreffen. Bei Bedarf wird darauf explizit hin-
gewiesen bzw. im Text entsprechend unterschieden.
Gefhrdungslage
Fr den IT-Grundschutz von Novell Netware Version 4.x werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 2.33 Nicht gesicherter Aufstellungsort von Novell Netware Servern
- G 2.34 Fehlende oder unzureichende Aktivierung von Novell Netware
Sicherheitsmechanismen
- G 2.42 Komplexitt der NDS
- G 2.43 Migration von Novell Netware 3.x nach Novell Netware Version 4
- G 3.25 Fahrlssiges Lschen von Objekten
- G 3.26 Ungewollte Freigabe des Dateisystems
- G 3.27 Fehlerhafte Zeitsynchronisation
_________________________________________________________________________________________
Novell Netware Version 4.x 6.6
_________________________________________________________________________________________
- G 5.55 Login Bypass
- G 5.56 Temporr frei zugngliche Accounts
- G 5.58 "Hacking Novell Netware"
- G 5.59 Missbrauch von Administratorrechten unter Novell Netware 3.x
Fr die vernetzten PCs sind die im Kapitel 5 beschriebenen Manahmen zu realisieren. Zu beachten
ist, dass das hier vorgestellte Manahmenbndel, das nur die Besonderheiten des Netzbetriebssystems
Novell Netware 4.x bercksichtigt, um die allgemeinen Netzsicherheitsmanahmen des Kapitels 6.1
ergnzt werden muss.
Darber hinaus werden folgende weitere Manahmen vorgeschlagen:
Infrastruktur:
- M 1.42 (1) Gesicherte Aufstellung von Novell Netware Servern
Organisation:
- M 2.102 (2) Verzicht auf die Aktivierung der Remote Console (optional)
- M 2.147 (1) Sichere Migration von Novell Netware 3.x Servern in Novell Netware 4.x Netze
- M 2.148 (1) Sichere Einrichtung von Novell Netware 4.x Netzen
- M 2.149 (2) Sicherer Betrieb von Novell Netware 4.x Netzen
- M 2.150 (1) Revision von Novell Netware 4.x Netzen
- M 2.151 (1) Entwurf eines NDS-Konzeptes
- M 2.152 (2) Entwurf eines Zeitsynchronisations-Konzeptes
- M 2.153 (1) Dokumentation von Novell Netware 4.x Netzen
Hardware/Software:
- M 4.102 (2) C2-Sicherheit unter Novell 4.11 (optional)
- M 4.103 (1) DHCP-Server unter Novell Netware 4.x (optional)
- M 4.104 (2) LDAP Services for NDS (optional)
- M 4.108 (2) Vereinfachtes und sicheres Netzmanagement mit DNS Services unter Novell
NetWare 4.11 (optional)
Notfallvorsorge:
- M 6.55 (2) Reduzierung der Wiederanlaufzeit fr Novell Netware Server
_________________________________________________________________________________________
Heterogene Netze 6.7
_________________________________________________________________________________________

Beschreibung
Ein lokales Netz setzt sich aus der Verkabelung (d. h. den
passiven Netzkomponenten Kabel und den Verbindungs-
elementen) sowie den aktiven Netzkomponenten zur
Netzkopplung zusammen. Generell knnen dabei unter-
schiedliche Verkabelungstypen wie auch unterschiedliche
aktive Netzkomponenten in ein LAN integriert werden.
Als aktive Netzkomponenten werden alle Netz-
komponenten bezeichnet, die eine eigene
(Netz-)Stromversorgung bentigen. Dazu gehren u. a.
Repeater, Brcken, Switches, Router, Gateways. Als
passive Netzkomponenten werden alle Netzkomponenten betrachtet, die keine eigene Netzstrom-
Versorgung bentigen. Dazu gehren z. B. Kabel, Verteilerschrnke, Patchfelder, Steckverbinder.
Die Verkabelung wird bereits detailliert in Kapitel 4.2, die anwendungsbezogene Peripherie in den
Kapiteln 5 und 6 behandelt, so dass im vorliegenden Baustein primr die aktiven Netzkomponenten,
die ihnen zugrunde liegende Topologie, ihre Konfiguration, Kriterien zur Auswahl geeigneter
Komponenten, die Auswahl von bertragungsprotokollen sowie das zugehrige Netzmanagement
betrachtet werden.
Es werden nur LAN-Technologien betrachtet, z. B. die Netzprotokolle Ethernet, Token Ring oder
FDDI bzw. die zugehrigen Netzkomponenten wie Bridges, Switches oder Router. Diese
Technologien knnen u. U. auch in einem MAN zum Einsatz kommen. Fragestellungen im
Zusammenhang mit einer WAN-Anbindung werden dagegen nicht behandelt. Hier sei u. a. auf das
Kapitel 7.3 Firewall verwiesen.
Soll ein LAN hinreichend im Sinne des IT-Grundschutzes geschtzt werden, so gengt es nicht, nur
das vorliegende Kapitel alleine zu bearbeiten. Neben den aktiven Netzkomponenten und der
eingesetzten Software zum Netzmanagement mssen auch die physikalische Verkabelung und die im
Netz zur Verfgung stehenden Serversysteme beachtet werden. Deshalb ist es unumgnglich, auch die
oben genannten Kapitel durchzuarbeiten.
Dieses Kapitel beschreibt einen Leitfaden, wie ein heterogenes Netz analysiert und darauf aufbauend
unter Sicherheitsaspekten konzipiert und betrieben werden kann. Damit richtet sich dieses Kapitel an
die Stelle einer Organisation, die fr den Netzbetrieb verantwortlich ist und das entsprechende
fachliche Wissen besitzt.
Gefhrdungslage
Fr den IT-Grundschutz eines heterogenen Netzes werden pauschal die folgenden Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.3 Blitz
- G 1.4 Feuer
- G 1.5 Wasser
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 2.27 Fehlende oder unzureichende Dokumentation
- G 2.44 Inkompatible aktive und passive Netzkomponenten
- G 2.45 Konzeptionelle Schwchen des Netzes
- G 2.46 berschreiten der zulssigen Kabel- bzw. Buslnge oder der Ringgre
- G 3.28 Ungeeignete Konfiguration der aktiven Netzkomponenten
- G 3.29 Fehlende oder ungeeignete Segmentierung
- G 4.31 Ausfall oder Strung von Netzkomponenten
- G 5.4 Diebstahl
- G 5.5 Vandalismus
- G 5.6 Anschlag
- G 5.66 Unberechtigter Anschluss von IT-Systemen an ein Netz
- G 5.67 Unberechtigte Ausfhrung von Netzmanagement-Funktionen
- G 5.68 Unberechtigter Zugang zu den aktiven Netzkomponenten
An dieser Stelle sei nochmals darauf hingewiesen, dass ein ausreichender Schutz fr ein LAN im
Sinne des IT-Grundschutzhandbuchs nur dann gewhrleistet werden kann, wenn zustzlich die
Manahmenbndel aus Kapitel 4.2 Verkabelung, Kapitel 6.1 Servergesttztes Netz und ggf. die
betriebssystem-spezifischen Ergnzungen und Kapitel 6.8 Netz- und Systemmanagement umgesetzt
werden.
_________________________________________________________________________________________
_________________________________________________________________________________________
Weiterhin sollten die aktiven Netzkomponenten in Rumen fr technische Infrastruktur (z. B.

Verteilerrume) untergebracht werden, so dass auch die Manahmen aus Kapitel 4.3.4 Raum fr
technische Infrastruktur realisiert werden mssen.
Der Arbeitsplatz des Netzadministrators sollte ebenfalls besonders geschtzt werden. Neben den
Manahmen aus Kapitel 4.3.1 Broraum sind hier die Regelungen fr das eingesetzte Betriebssystem
zu nennen (siehe Kapitel 6).
Fr den sicheren Einsatz eines heterogenen Netzes sind eine Reihe von Manahmen umzusetzen,
beginnend mit der Analyse der aktuellen Netzsituation ber die Entwicklung eines Netzmanagement-
Konzeptes bis zum Betrieb eines heterogenen Netzes. Die Schritte, die dabei durchlaufen werden
sollten, sowie die Manahmen, die in den jeweiligen Schritten beachtet werden sollten, sind im
folgenden aufgefhrt.
1. Analyse der aktuellen Netzsituation (siehe M 2.139 Ist-Aufnahme der aktuellen Netzsituation und
M 2.140 Analyse der aktuellen Netzsituation)
- Erhebung von Lastfaktoren und Verkehrsflussanalyse
- Feststellung von Netzengpssen
- Identifikation kritischer Bereiche
2. Konzeption
- Konzeption eines Netzes (siehe M 2.141 Entwicklung eines Netzkonzeptes und M 2.142
Entwicklung eines Netz-Realisierungsplans und M 5.60 Auswahl einer geeigneten
Backbone-Technologie )
- Konzeption Netzmanagement (siehe M 2.143 Entwicklung eines Netzmanagementkonzeptes
und M 2.144 Geeignete Auswahl eines Netzmanagement-Protokolls)
3. Sicherer Betrieb des Netzes
- Segmentierung des Netzes (siehe M 5.61 Geeignete physikalische Segmentierung und
M 5.62 Geeignete logische Segmentierung)
- Einsatz einer Netzmanagement-Software (siehe M 2.145 Anforderungen an ein
Netzmanagement-Tool und M 2.146 Sicherer Betrieb eines Netzmanagementsystems)
- Audit und Revision des Netzes (siehe M 4.81 Audit und Protokollierung der Aktivitten im
Netz und M 2.64 Kontrolle der Protokolldateien)
4. Notfallvorsorge
- Redundante Auslegung der Netzkomponenten (siehe M 6.53 Redundante Auslegung der
Netzkomponenten)
- Sicherung der Konfigurationsdaten (siehe M 6.52 Regelmige Sicherung der
Konfigurationsdaten aktiver Netzkomponenten und M 6.22 Sporadische berprfung auf
Wiederherstellbarkeit von Datensicherungen)
Nachfolgend wird das komplette Manahmenbndel fr den Bereich Heterogene Netze vorgestellt, in
dem auch Manahmen von eher grundstzlicher Art enthalten sind, die zustzlich zu den oben
aufgefhrten Schritten beachtet werden mssen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Infrastruktur:
- M 1.25 (1) berspannungsschutz
- M 1.27 (2) Klimatisierung
- M 1.32 (1) Geeignete Aufstellung von Konsole, Gerten mit austauschbaren Datentrgern und
Druckern
Organisation:
- M 2.38 (2) Aufteilung der Administrationsttigkeiten
- M 2.139 (1) Ist-Aufnahme der aktuellen Netzsituation
- M 2.140 (1) Analyse der aktuellen Netzsituation (optional)
- M 2.141 (1) Entwicklung eines Netzkonzeptes
- M 2.142 (1) Entwicklung eines Netz-Realisierungsplans
- M 2.143 (1) Entwicklung eines Netzmanagementkonzeptes
- M 2.144 (1) Geeignete Auswahl eines Netzmanagement-Protokolls
- M 2.145 (2) Anforderungen an ein Netzmanagement-Tool
- M 2.146 (1) Sicherer Betrieb eines Netzmanagementsystems
Personal:
Hardware/Software:
- M 4.24 (1) Sicherstellung einer konsistenten Systemverwaltung
- M 4.79 (1) Sichere Zugriffsmechanismen bei lokaler Administration
- M 4.80 (1) Sichere Zugriffsmechanismen bei Fernadministration
- M 4.81 (2) Audit und Protokollierung der Aktivitten im Netz
- M 4.82 (1) Sichere Konfiguration der aktiven Netzkomponenten
- M 4.83 (3) Update/Upgrade von Soft- und Hardware im Netzbereich
Kommunikation:
- M 5.2 (1) Auswahl einer geeigneten Netz-Topographie
- M 5.7 (1) Netzverwaltung
- M 5.12 (2) Einrichtung eines zustzlichen Netzadministrators
- M 5.13 (1) Geeigneter Einsatz von Elementen zur Netzkopplung
- M 5.60 (1) Auswahl einer geeigneten Backbone-Technologie
- M 5.61 (1) Geeignete physikalische Segmentierung
- M 5.62 (1) Geeignete logische Segmentierung (optional)
- M 5.77 (1) Bildung von Teilnetzen (optional)
_________________________________________________________________________________________
_________________________________________________________________________________________
Notfallvorsorge:
- M 6.52 (1) Regelmige Sicherung der Konfigurationsdaten aktiver Netzkomponenten
- M 6.53 (1) Redundante Auslegung der Netzkomponenten
- M 6.54 (3) Verhaltensregeln nach Verlust der Netzintegritt
_________________________________________________________________________________________
Netz- und Systemmanagement 6.8
_________________________________________________________________________________________

Beschreibung
Ein Managementsystem fr ein i. allg. lokales Rechner-
netz (LAN, VLAN) dient dazu, mglichst alle im lokale
Netz angesiedelten Hard- und Software-Komponenten
i. d. R. zentral zu verwalten. Ein solches System soll den
Systemverwalter maximal in seiner tglichen Arbeit
untersttzen. Grundstzlich kann zwischen Netz-
management und Systemmanagement unterschieden
werden. Die Unterschiede ergeben sich durch die jeweils
verwalteten Komponenten.
Netzmanagement umfasst die Gesamtheit der
Vorkehrungen und Aktivitten zur Sicherstellung des effektiven Einsatzes eines Netzes. Hierzu gehrt
beispielsweise die berwachung der Netzkomponenten auf ihre korrekte Funktion, das Monitoring der
Netzperformance und die zentrale Konfiguration der Netzkomponenten. Netzmanagement ist in erster
Linie eine organisatorische Problemstellung, deren Lsung lediglich mit technischen Mitteln, einem
Netzmanagementsystem, untersttzt werden kann.
Systemmanagement befasst sich in erster Linie mit dem Management verteilter IT-Systeme. Hierzu
gehren beispielsweise eine zentrale Verwaltung der Benutzer, Softwareverteilung, Management der
Anwendungen usw. In einigen Bereichen, wie z. B. dem Konfigurationsmanagement (dem ber-
wachen und Konsolidieren von Konfigurationen eines Systems oder einer Netzkomponente), sind
Netz- und Systemmanagement nicht klar zu trennen.
Im folgenden wird das (Software-) System, das zum Verwalten eines Netzes und dessen Komponenten
dient, immer als "Managementsystem" bezeichnet, die damit verwalteten Komponenten werden als
"verwaltetes System" bezeichnet. Im Englischen werden hier die Begriffe "management system" und
"managed system" verwendet, dies gilt insbesondere fr den Bereich Netzmanagement.
In der ISO/IEC-Norm 7498-4 bzw. als X.700 der ITU-T ist ein Netz- und Systemmanagement-
Framework definiert. Zu den Aufgaben eines Managementsystems gehren demnach:
1. Konfigurationsmanagement,
2. Performancemanagement,
3. Fehlermanagement,
4. Abrechnungsmanagement,
5. Sicherheitsmanagement.
Dabei muss ein konkretes Systemmanagement-Produkt nicht fr jeden der Bereiche Untersttzung
anbieten. Die Hersteller bieten i.d.R Produktpaletten an, die so konzipiert sind, dass spezielle Funktio-
nalitten als Modul oder als kooperierendes Einzelprodukt erhltlich sind.
Netzmanagement ist die ltere und ausgereiftere Managementdisziplin. Systemmanagement ist im
Gegensatz dazu eine noch junge Disziplin, wird aber durch die stark gewachsene Vernetzung in
Unternehmen bzw. Behrden und die damit zunehmende Heterogenitt und Komplexitt immer mehr
gefordert. Ziel muss es hier sein, beide Disziplinen zu integrieren. Die zurzeit erhltlichen Manage-
mentprodukte sind so angelegt, dass sie primr entweder zum Netzmanagement oder zum System-
management konzipiert sind. Produkte, die beide Funktionalitten vereinen, sind in der Entwicklung.
In der Regel erlauben Produkte, die fr das Systemmanagement ausgelegt sind, auch den Zugriff auf
Informationen des Netzmanagements.
_________________________________________________________________________________________
_________________________________________________________________________________________
Aufgrund der Heterogenitt von Hard- und Software heutiger Netze ist Systemmanagement eine sehr
komplexe Aufgabe. Erschwert wird Systemmanagement zustzlich dadurch, dass die Management-
software und die Software, die verwaltet werden soll, sehr eng zusammenarbeiten mssen. In der
Regel ist heute erhltliche Software jedoch nicht darauf eingerichtet, mit einem Managementsystem
zusammenzuarbeiten. Dies liegt zum einen an fehlenden Standards, die z. B. ausreichende Sicherheit
garantieren, zum anderen daran, dass grere Softwarepakete mit eigenem, proprietrem Management
ausgestattet sind, da Interna ber die Software, die zum Verwalten dieser ntig sind, nicht offengelegt
werden sollen. Beispielsweise existiert fr den Microsoft Internet Explorer eine Managementsoftware,
das "Internet Explorer Administration Kit (IEAK)", welches z. B. die Vorgabe von Sicher-
heitseinstellungen durch den Administrator erlaubt, die vom Benutzer nachtrglich nicht mehr oder
nur im Rahmen vorgegebener Werte verndert werden knnen. Die Funktionsweise dieses Tools ist
proprietr und unterliegt keinem Standard.
Prinzipiell ist die Architektur von Managementsoftware zentralistisch aufgebaut: es gibt eine zentrale
Managementstation oder -konsole, von der aus der Systemadministrator das ihm anvertraute Netz mit
den darin befindlichen Hard- und Software-Komponenten verwalten kann. Insbesondere die Systeme
zum Netzmanagement bauen darauf auf. Durch die fehlenden Standards im Bereich Systemmanage-
ment findet man hier in den erhltlichen Produkten in vielen Fllen zwar die zentralistische Architek-
tur, die jedoch im Detail proprietr realisiert ist, so dass hier keine weitere generelle Architektur-
aussage gemacht werden kann.
Einem Netzmanagementsystem liegt i. d. R. ein Modell zugrunde, das zwischen "Manager", "Agent"
(auch "Managementagent") und "verwalteten Objekten" (auch "managed objects") unterscheidet. Die
weiteren Bestandteile sind das zur Kommunikation verwendete Protokoll zwischen Manager und den
Agenten, sowie eine Informationsdatenbank, die so genannte "MIB" (Management Information Base).
Die MIB muss sowohl dem Manager als auch jedem Managementagenten zur Verfgung stehen.
Konzeptionell werden Managementagenten und deren MIB als Teil des verwalteten Systems ange-
sehen.
Ein Agent ist fr ein oder mehrere zu verwaltende Objekte zustndig. Es ist mglich, die Agenten
hierarchisch zu organisieren: Ein Agent ist dann fr die ihm zugeordneten Unteragenten zustndig.
Am Ende einer jeden auf diese Art entstehenden Befehlskette steht immer ein zu verwaltendes Objekt.
Ein zu verwaltendes Objekt ist entweder ein physikalisch vorhandenes Objekt (Gert), wie ein
Rechner, ein Drucker oder ein Router, oder ein Softwareobjekt, wie z. B. ein Hintergrundproze zur
_________________________________________________________________________________________
_________________________________________________________________________________________
Verwaltung von Druckauftrgen. Bei Gerten, die ber ein Managementsystem verwaltet werden
knnen, ist der Managementagent i. d. R. schon vom Hersteller in das Gert "fest" eingebaut. Versteht
dieser das vom Manager verwendete Kommunikationsprotokoll nicht, ist z. B. ein Software-
Managementagent ntig, der die Protokollumsetzung beherrscht. In hnlicher Weise knnen Software-
Komponenten den Managementagenten schon enthalten, oder es wird ein spezieller Managementagent
bentigt, der fr die Verwaltung dieser Software-Komponente konzipiert ist.
Um die einzelnen Komponenten des zu verwaltenden Systems anzusprechen, tauschen der Manager
und die jeweiligen Agenten Informationen aus. Die Art des zur Kommunikation verwendeten Proto-
kolls bestimmt mageblich die Mchtigkeit und insbesondere die Sicherheit des Managementsystems.
Prinzipiell knnen Managementsysteme bezglich des verwendeten Kommunikationsprotokolls in drei
Kategorien unterteilt werden (siehe auch M 2.144 Geeignete Auswahl eines Netzmanagement-
Protokolls):
1. Es wird SNMP (Simple Network Management Protocol) benutzt, das weit verbreitete Standard-
protokoll des TCP/IP-basierten Systemmanagements.
2. Es wird CMIP (Common Management Information Protocol) benutzt, das seltener benutzte
Standardprotokoll des ISO/OSI-basierten Systemmanagements.
3. Es wird ein herstellerspezifisches Protokoll benutzt. Es existiert meist die Mglichkeit, so genannte
Adapter zum Einbinden der Standardprotokolle zu verwenden, wobei in der Regel lediglich eine
SNMP-Anbindung existiert.
Das am hufigsten benutzte Protokoll ist SNMP. SNMP ist ein sehr einfaches Protokoll, das nur fnf
Nachrichtentypen kennt und daher auch einfach zu implementieren ist. CMIP wird hauptschlich zum
Management von Telekommunikationsnetzen verwandt, und hat im Inter- und Intranet-basierten
Management keine Bedeutung, da es den OSI-Protokollstack verwendet und nicht den TCP/IP-Stack.
Systemmanagementsysteme sind zwar in der Regel auch zentralistisch ausgelegt, um das Verwalten
des Systems von einer Managementstation aus zu erlauben, die konkrete Architektur hngt jedoch
davon ab, wie gro die Systeme, die verwaltet werden knnen, sein drfen und welcher Funktions-
umfang angeboten wird. Hier reicht die Palette von einfachen Sammlungen von Management-Tools,
die ohne Integration nebeneinander in kleinen Netzen eingesetzt werden, bis hin zu Managementplatt-
formen, die ein weltumspannendes Firmennetz mit mehreren Tausend Rechnern verwalten knnen.
Bestimmte Managementplattformen benutzen proprietre Protokolle zur Kommunikation zwischen
den Komponenten. Diese Systeme weisen in der Regel ein wesentlich hheres Leistungsspektrum auf
und dienen nicht nur dem Netz- und Systemmanagement, sondern bieten unternehmens- bzw. behr-
denweites Ressourcenmanagement an. Durch die unzureichend spezifizierten Sicherheitsmechanismen
in den wenigen existierenden Standards, erlauben proprietre Lsungen zudem die (zwar nicht
standardisierte) Verfgbarkeit sicherheitsrelevanter Mechanismen, wie z. B. Verschlsselungs-
verfahren.
Gefhrdungslage
Fr den IT-Grundschutz eines Managementsystems werden die folgenden typischen Gefhrdungen
angenommen:
Hhere Gewalt
- G 2.59 Betreiben von nicht angemeldeten Komponenten
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 2.60 Fehlende oder unzureichende Strategie fr das Netz- und Systemmanagement

- G 2.61 Unberechtigte Sammlung personenbezogener Daten
- G 3.34 Ungeeignete Konfiguration des Managementsystems
- G 3.35 Server im laufenden Betrieb ausschalten
- G 3.36 Fehlinterpretation von Ereignissen
- G 4.38 Ausfall von Komponenten eines Netz- und Systemmanagementsystems
- G 5.86 Manipulation von Managementparametern
Das zu verwaltende System besteht aus einzelnen Rechnern, Netzkoppelelementen und dem physika-
lischen Netz. Jede dieser Komponenten ist ein potentielles Sicherheitsrisiko fr das Gesamtsystem.
Diese Risiken knnen im allgemeinen alleine durch die Einfhrung von Managementsoftware nicht
vollstndig beseitigt werden. Dies gilt schon deshalb, weil in der Regel nicht alle Systeme in gleichem
Mae durch ein Managementsystem erfasst werden. Grundvoraussetzung fr die Systemsicherheit ist
hier einerseits die Definition und andererseits die Realisierung einer unternehmensweiten
Sicherheitspolitik, die sich im betrachteten Fall insbesondere in der Konfiguration von Hard- und
Software niederschlagen muss. Aus diesem Grund sollten insbesondere die Manahmen der im
Kapitel 6 aufgefhrten Bausteine betrachtet werden. Als Ausgangsbaustein kann der Baustein 6.7
Heterogene Netze dienen.
Da Managementsysteme von einem zentralistischen Ansatz ausgehen, kommt der zentralen Manage-
mentstation eine besondere Bedeutung unter Sicherheitsgesichtspunkten zu und ist daher besonders zu
schtzen. Zentrale Komponenten eines Managementsystems sollten daher in Rumen aufgestellt
werden, die den Anforderungen an einen Serverraum (vgl. Kapitel 4.3.2) entsprechen. Wenn kein
Serverraum zur Verfgung steht, knnen sie alternativ in einem Serverschrank aufgestellt werden (vgl.
Kapitel 4.4 Schutzschrnke).
Fr den erfolgreichen Aufbau eines Netz- und Systemmanagementsystems sind eine Reihe von
Manahmen umzusetzen, beginnend mit der Konzeption ber die Beschaffung bis zum Betrieb. Die
Schritte, die dabei durchlaufen werden sollten, sowie die Manahmen, die in den jeweiligen Schritten
beachtet werden sollten, sind im folgenden aufgefhrt.
1. Erstellen eines Managementkonzeptes, das auf den Anforderungen beruht, die sich aus den
Gegebenheiten des in der Regel bereits vorhandenen IT-Systems ergeben
1.1 Anforderungsanalyse (siehe M 2.168 IT-System-Analyse vor Einfhrung eines
Systemmanagementsystems)
1.2 Definition des Konzeptes (siehe M 2.169 Entwickeln einer Systemmanagementstrategie)
2. Die Beschaffung des Managementsystems erfordert zunchst, die aus dem Managementkonzept
resultierenden
2.1 Anforderungen an das Managementprodukt zu formulieren (siehe M 2.170 Anforderungen
an ein Systemmanagementsystem) und basierend darauf
2.2 die Auswahl eines geeigneten Managementproduktes zu treffen (siehe M 2.170
Anforderungen an ein Systemmanagementsystem).
_________________________________________________________________________________________
_________________________________________________________________________________________
3. Die sicherheitsrelevanten Manahmen fr den Betrieb des Managementsystems untergliedern sich

in die Bereiche:
3.1 Installation, mit der Umsetzung des Managementkonzeptes (siehe M 4.91 Sichere
Installation eines Systemmanagementsystems) und
3.2 den laufenden Betrieb des Managementsystems (siehe M 4.92 Sicherer Betrieb eines
Systemmanagementsystems). Daneben sind natrlich die bisherigen Manahmen fr
3.3 den laufenden Betrieb des verwalteten Systems zu beachten (siehe Kapitel 4 bis 9)
Nachfolgend wird das Manahmenbndel fr den Baustein Netz- und Systemmanagement vorgestellt.
Infrastruktur:
- M 1.29 (1) Geeignete Aufstellung eines IT-Systems
Organisation:
- M 2.143 (1) Entwicklung eines Netzmanagementkonzeptes
- M 2.144 (1) Geeignete Auswahl eines Netzmanagement-Protokolls
- M 2.168 (1) IT-System-Analyse vor Einfhrung eines Systemmanagementsystems
- M 2.169 (1) Entwickeln einer Systemmanagementstrategie
- M 2.170 (1) Anforderungen an ein Systemmanagementsystem
- M 2.171 (1) Geeignete Auswahl eines Systemmanagement-Produktes
Personal:
Hardware / Software:
- M 4.91 (1) Sichere Installation eines Systemmanagementsystems
- M 4.92 (1) Sicherer Betrieb eines Systemmanagementsystems
Kommunikation:
- M 5.68 (2) Einsatz von Verschlsselungsverfahren zur Netzkommunikation
Notfallvorsorge:
- M 6.57 (2) Erstellen eines Notfallplans fr den Ausfall des Managementsystems
_________________________________________________________________________________________
Windows 2000 Server 6.9
_________________________________________________________________________________________

Beschreibung
Windows 2000 ist das Nachfolgeprodukt zum
Betriebssystem Windows NT, das hufig eingesetzt wird,
um kleine, mittlere und auch groe Rechnernetze
aufzubauen. Es ist zu erwarten, dass Windows 2000 in
Zukunft die Rolle von Windows NT bernimmt, so dass
mit einer entsprechend groen Verbreitung zu rechnen
ist. Die Sicherheit eines solchen Betriebssystems spielt
eine wichtige Rolle, da Schwachstellen auf der
Betriebssystemebene die Sicherheit aller Anwendungen
beeintrchtigen knnen. Der vorliegende Baustein
beschreibt die aus Sicherheitssicht relevanten Gefhrdungen und insbesondere auch Manahmen, die
fr einen Server mit Windows 2000 zutreffen.
Windows 2000 Produkte im berblick
Die Windows 2000 Produktfamilie umfasst die Arbeitsplatz-Variante "Microsoft Windows 2000
Professional", die vergleichbar mit der Workstation Version von Microsoft Windows NT ist (siehe
dazu Baustein 5.7 Windows 2000 Client) und drei verschiedene Server-Versionen:
- Microsoft Windows 2000 Server,
- Microsoft Windows 2000 Advanced Server und
- Microsoft Windows 2000 Datacenter Server.
Die einzelnen Versionen des Microsoft Windows 2000 Server Betriebssystems unterscheiden sich
dabei hauptschlich in der Skalierbarkeit. Die untersttzte Hardware-Ausstattung liegt z. B.
- mit Microsoft Windows 2000 Server bei maximal 4 Prozessoren und 4 Gigabyte Hauptspeicher,
- mit Microsoft Windows 2000 Advanced Server bei maximal 8 Prozessoren und 8 Gigabyte
Hauptspeicher sowie
- bei maximal 32 Prozessoren und 64 Gigabyte Hauptspeicher mit Microsoft Windows 2000
Datacenter Server.
Die zugrunde liegende Architektur der Software und die verfgbaren Dienste unterscheiden sich nur in
wenigen Punkten. So untersttzen z. B. der Advanced Server und der Datacenter Server im Gegensatz
zur Windows 2000 Server Software auch Clustering-Mechanismen, mit denen mehrere physikalische
Rechner zu einem virtuellen Rechner mit erhhter Ausfallsicherheit zusammengeschaltet werden
knnen.
Hauptunterschiede zu Windows NT
Windows 2000 bietet im Vergleich zu Windows NT einige neue Sicherheitsmechanismen.
Hauptschlich ist hier das Kerberos-Protokoll zu nennen, das von Windows 2000 standardmig als
Authentisierungsverfahren benutzt wird. Das NTLM-Verfahren von Windows NT kann ebenfalls zur
Authentisierung benutzt werden, so dass ein gemeinsamer Betrieb von Windows NT und Windows
2000 Rechnern innerhalb einer Windows 2000 Domne mglich ist.
Durch die Verwendung des Kerberos-Verfahrens wird es einfacher, die Authentisierung von
Benutzern zu delegieren. Dies ist eine der Voraussetzungen fr den Betrieb groer Windows 2000
Netze, in denen sich Benutzer auch ber Domnengrenzen hinweg authentisieren knnen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Eine der wichtigsten neuen Komponenten unter Windows 2000 ist das Active Directory. Dabei
handelt es sich um eine verteilte Datenbank, die die Benutzer- und Konfigurationsdaten einer Domne
auf mehrere Domnen-Controller verteilt. nderungen knnen an jedem Domnen-Controller
vorgenommen werden. Die Domnen-Controller replizieren diese nderungen untereinander. Durch
die Verwendung des Active Directory werden grere Domnen mglich als bei Windows NT. Zum
einen kann die Active Directory Datenbank wesentlich mehr Eintrge fassen, als die SAM-
Benutzerdatenbank eines Windows NT Domnen-Controllers. Zum anderen lsst sich aufgrund der
verteilten Struktur des Active Directories die Last besser auf mehrere Domnen-Controller verteilen,
als dies bei Windows NT der Fall ist.
Unter Sicherheitsaspekten spielt das Active Directory eine wichtige Rolle, da es
- viele sicherheitsrelevante Daten enthlt,
- ber eigene, dem Dateisystem sehr hnliche Zugriffskontrollmechanismen verfgt, sowie
- die Basis fr das wichtigste Konfigurationswerkzeug fr Zugriffsrechte und Privilegien in
Windows 2000 bildet: die Gruppenrichtlinien.
Weitere sicherheitsspezifische Neuerungen von Windows 2000 sind
- die Dateiverschlsselung durch EFS (Encrypting File System),
- die Untersttzung von Chipkarten zur Anmeldung an Windows 2000 Benutzerkonten,
- die in Windows 2000 integrierte PKI-Funktionalitt, die eine eigene Zertifikatsausgabestelle
beinhaltet, sowie
- die Untersttzung von IPSec zur Netzverschlsselung.
Ein weiterer Punkt, in dem sich Windows NT und Windows 2000 unterscheiden, ist die
Voreinstellung der Zugriffsrechte auf das Dateisystem: Unter Windows 2000 lassen sich diese
Zugriffsrechte restriktiver konfigurieren als unter Windows NT. Eine solche restriktive Konfiguration
ist nicht zwingend erforderlich, unter Sicherheitsgesichtspunkten jedoch wnschenswert. Ihre
Verwendung kann jedoch zu Problemen mit Windows NT Applikationen fhren, die fr eine solche
Rechtekonfiguration nicht ausgelegt sind.
Gefhrdungslage
Wie jedes IT-System ist auch ein Netz von Microsoft Windows 2000 Rechnern vielfltigen Gefahren
ausgesetzt. Dabei sind neben Angriffen von auen auch Angriffe von innen mglich. Oft nutzen
erfolgreiche Angriffe Fehlkonfigurationen einzelner oder mehrerer Systemkomponenten. Daher
kommt der korrekten Konfiguration des Systems und seiner Komponenten eine wichtige Rolle zu.
Generell gilt, dass die Gefhrdungslage einzelner Rechner immer auch vom Einsatzszenario abhngt
und diese Einzelgefhrdungen auch in die Gefhrdung des Gesamtsystems eingehen.
Fr den IT-Grundschutz eines servergesttzten Netzes unter dem Betriebssystem Microsoft Windows
2000 werden die folgenden typischen Gefhrdungen angenommen:
Hhere Gewalt
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 2.18 Ungeordnete Zustellung der Datentrger

- G 2.68 Fehlende oder unzureichende Planung des Active Directory
- G 3.48 Fehlkonfiguration von Windows 2000 Rechnern
- G 3.49 Fehlkonfiguration des Active Directory
("Bausteine" - wie in Kapitel 2.3 und 2.4 beschrieben) auszuwhlen.
Fr den erfolgreichen Aufbau eines Windows 2000 Systems sind eine Reihe von Manahmen
umzusetzen, beginnend mit der Konzeption ber die Installation bis zum Betrieb. Die Schritte, die
dabei zu durchlaufen sind, sowie die Manahmen, die in den jeweiligen Schritten beachtet werden
sollten, sind im Folgenden aufgefhrt.
1. Nach der Entscheidung, Windows 2000 als internes Betriebssystem einzusetzen, muss die
Beschaffung der Software und eventuell zustzlich bentigter Hardware erfolgen. Folgende
Manahmen sind durchzufhren:
- Zunchst muss der Aufbau bzw. die Migration eines Windows 2000 System geplant werden
(siehe Manahme M 2.227 Planung des Windows 2000 Einsatzes).
- Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe Manahme , M 2.228
Festlegen einer Windows 2000 Sicherheitsrichtlinie ), die einerseits die bereits bestehenden
Sicherheitsrichtlinien im Windows 2000-Kontext umsetzt und andererseits die fr Windows
2000 spezifischen Erweiterungen definiert.
- Die Benutzer bzw. die Administratoren haben einen wesentlichen Einfluss auf die Windows
2000 Sicherheit. Vor der tatschlichen Einfhrung von Windows 2000 mssen die Benutzer
und Administratoren daher fr den Umgang mit Windows 2000 und dessen Komponenten
geschult werden. Insbesondere fr Administratoren empfiehlt sich aufgrund der Komplexitt
in der Planung und in der Verwaltung eines Windows 2000-Systems eine intensive
Schulung. Die Administratoren sollen dabei detaillierte Systemkenntnisse erwerben (siehe
M 3.27 Schulung zur Active Directory-Verwaltung so dass eine konsistente und korrekte
Systemverwaltung gewhrleistet ist. Benutzern sollte insbesondere die Nutzung der
Windows 2000 Sicherheitsmechanismen vermittelt werden (siehe M 3.28 Schulung zu
Windows 2000 Sicherheitsmechanismen fr Benutzer). Hier spielt als neuer
Dateisystemmechanismus EFS - das verschlsselnde Dateisystem - eine Rolle, da die
_________________________________________________________________________________________
_________________________________________________________________________________________
Sicherheit von EFS von der korrekten Konfiguration und Nutzung abhngt. Hinweise dazu
finden sich unter M 4.147 Sichere Nutzung von EFS unter Windows 2000.
2. Nachdem die organisatorischen und planerischen Vorarbeiten durchgefhrt wurden, kann die
Installation des Windows 2000-Systems erfolgen. Dabei sind die folgenden Manahmen zu
beachten:
- Schon die Installation muss mit besonderer Sorgfalt durchgefhrt werden, da insbesondere
die Sicherheitskonfiguration whrend der Installation noch nicht erfolgt ist. In M 4.136
Sichere Installation von Windows 2000 sind die relevanten Empfehlungen zusammengefasst.
- Nach der reinen Installation muss ein Windows 2000 System konfiguriert werden. Die dabei
zu beachtenden Aspekte finden sich in M 4.137 Sichere Konfiguration von Windows 2000.
Dabei kommt u. a. auch zum tragen, fr welchen Einsatzzweck ein Windows 2000 Rechner
geplant ist, auf die jeweils relevanten Manahmen wird dort entsprechend verwiesen.
- Die sichere Konfiguration eines Windows 2000 Systems hngt nicht nur von der sicheren
Konfiguration des Betriebssystems ab, die Windows 2000 Sicherheit hngt auch wesentlich
von systemnahen Diensten ab. Die relevanten Dienste sowie Verweise auf dienstespezifische
Manahmen finden sich in M 4.140 Sichere Konfiguration wichtiger Windows 2000
Dienste.
3. Nach der Erstinstallation und einer Testbetriebsphase wird der Regelbetrieb aufgenommen. Unter
Sicherheitsgesichtspunkten sind dabei folgende Aspekte zu beachten:
- Ein Windows 2000 System ndert sich in der Regel tglich. Dabei muss bei jeder nderung
sichergestellt werden, dass die Sicherheit auch nach der nderung nicht beeintrchtigt wird.
Die dabei zu beachtenden Aspekte sind in M 4.146 Sicherer Betrieb von Windows 2000
zusammengefasst.
- Ein Mittel im Rahmen der Aufrechterhaltung der Sicherheit eines Windows 2000 Netzes ist
die berwachung des Systems bzw. seiner Einzelkomponenten. Die hier relevanten
Manahmen finden sich in M 4.148 berwachung eines Windows 2000 Systems. Dabei
spielen auch insbesondere Datenschutzaspekte eine Rolle.
- Neben der Absicherung im laufenden Betrieb spielt jedoch auch die Notfallvorsorge eine
wichtige Rolle, da nur so der Schaden im Notfall verringert werden kann. Hinweise zur
Notfallvorsorge finden sich in M 6.76 Erstellen eines Notfallplans fr den Ausfall eines
Windows 2000 Netzes.
Nachfolgend wird nun das Manahmenbndel fr den Baustein "Windows 2000" vorgestellt.
Organisation:
- M 2.227 (1) Planung des Windows 2000 Einsatzes
- M 2.228 (1) Festlegen einer Windows 2000 Sicherheitsrichtlinie
- M 2.229 (1) Planung des Active Directory
- M 2.230 (1) Planung der Active Directory-Administration
- M 2.231 (1) Planung der Gruppenrichtlinien unter Windows 2000
- M 2.232 (2) Planung der Windows 2000 CA-Struktur
- M 2.233 (1) Planung der Migration von Windows NT auf Windows 2000
_________________________________________________________________________________________
_________________________________________________________________________________________
Personal:
- M 3.27 (1) Schulung zur Active Directory-Verwaltung
- M 4.136 (1) Sichere Installation von Windows 2000
- M 4.137 (1) Sichere Konfiguration von Windows 2000
- M 4.138 (1) Konfiguration von Windows 2000 als Domnen-Controller
- M 4.139 (1) Konfiguration von Windows 2000 als Server
- M 4.140 (1) Sichere Konfiguration wichtiger Windows 2000 Dienste
- M 4.141 (1) Sichere Konfiguration des DDNS unter Windows 2000
- M 4.142 (2) Sichere Konfiguration des WINS unter Windows 2000
- M 4.143 (2) Sichere Konfiguration des DHCP unter Windows 2000
- M 4.144 (2) Nutzung der Windows 2000 CA
- M 4.145 (2) Sichere Konfiguration von RRAS unter Windows 2000
- M 4.146 (1) Sicherer Betrieb von Windows 2000
- M 4.147 (2) Sichere Nutzung von EFS unter Windows 2000
- M 4.148 (1) berwachung eines Windows 2000 Systems
Kommunikation:
- M 5.89 (1) Konfiguration des sicheren Kanals unter Windows 2000
- M 5.90 (2) Einsatz von IPSec unter Windows 2000
Notfallvorsorge:
- M 6.43 (1) Einsatz redundanter Windows NT/2000 Server
- M 6.76 (1) Erstellen eines Notfallplans fr den Ausfall eines Windows 2000 Netzes
_________________________________________________________________________________________
S/390- und zSeries-Mainframe 6.10
_________________________________________________________________________________________

Einfhrung
Die IBM S/390- und zSeries-Systeme gehren zu den
Server-Systemen, die allgemein als Mainframes
("Grorechner") bezeichnet werden. Mainframes haben
sich von klassischen Einzelsystemen mit
Stapelverarbeitung hin zu modernen Client-/Server-
Systemen entwickelt. Sie bilden heute das obere Ende der
Palette der angebotenen Server-Systeme.
In diesem Baustein werden nur Mainframes des Typs
IBM zSeries bzw. IBM S/390 betrachtet. zSeries-
Systeme, mit dem Betriebssystem z/OS, stellen eine logische Weiterentwicklung der OS/390-
Architektur dar. Mit zSeries kommt z. B. die zustzliche 64 Bit-Untersttzung hinzu. Beide
Systemtypen existieren nebeneinander, wobei OS/390 als ein "auslaufendes" Betriebssystem
betrachtet werden kann, da IBM den Service im Herbst 2004 eingestellt hat. Aus Grnden der
bersichtlichkeit wird in diesem Zusammenhang nur der Begriff "zSeries" fr die Hardware und
"z/OS" fr das Betriebssystem verwendet.
Historie
Die im Jahr 1964 eingefhrte S/360-Architektur stellt die Basis fr alle folgenden Weiter-
entwicklungen dar und findet sich noch heute in ihren wesentlichen Teilen auf den aktuellen zSeries-
Systemen wieder. Der Namenswechsel, von "S/360" ber "S/370" und "S/390" bis zur heutigen
"zSeries", reflektiert die fortwhrende Entwicklung der zugrundeliegenden Architektur. Aufgrund
ihrer Abwrtskompatibilitt untersttzt die Architektur neben neueren 64-Bit-Applikationen auch
Programme im lteren 24- oder 31-Bit-Modus.
Trotz steigender Leistungsfhigkeit haben sich die physischen Abmessungen von Mainframe-
Systemen stark verringert. Mainframe-Systeme haben heute hnliche Abmessungen wie andere
Systeme, die typischerweise in Rechenzentren betrieben werden.
berblick
Fr zSeries-Systeme stehen Mechanismen zur Verfgung, mit denen eine hohe Verfgbarkeit und
Skalierbarkeit erreicht werden kann. Die hohe Verfgbarkeit wird dabei durch redundante Auslegung
der Komponenten erzielt. Zur Steigerung der Leistung und Verfgbarkeit knnen derzeit in einem
zSeries-System bis zu 16 Prozessoren parallel betrieben und bis zu 32 zSeries-Systeme zu einem
Cluster zusammengestellt werden. Dies wird als Parallel-Sysplex-Cluster bezeichnet.
Fr die zSeries-Hardware sind verschiedene Betriebssysteme verfgbar (z. B. z/OS, VSE, z/VM oder
TPF). Die Auswahl erfolgt in der Regel anhand der Parameter Rechnergre und Einsatzzweck. Am
hufigsten kommt jedoch das z/OS-Betriebssystem zum Einsatz. Um den Rahmen dieses Bausteins
nicht zu sprengen, beschrnken sich die Empfehlungen in diesem Baustein im Wesentlichen auf das
Betriebssystem z/OS.
Durch die Erweiterung des frher auch als "MVS" bezeichneten z/OS-Betriebssystems um das
Subsystem Unix System Services ist es mglich, parallel zu den klassischen Mainframe-Anwendungen
auch Unix-basierte Anwendungen zu betreiben. Daneben ist fr die zSeries-Hardware auch ein Linux-
Betriebssystem verfgbar.
_________________________________________________________________________________________
_________________________________________________________________________________________
Einsatzbereiche fr heutige z/OS-Systeme sind:

- klassische Stapelverarbeitung fr groe "Batch-Ketten",
- Stapelverarbeitung einschlielich der transaktionsorientierten Verarbeitung (z. B. IMS oder CICS),
- Datenbank-Server (z. B. DB2, IMS DB oder Oracle) oder
- Webserver und deren Anwendungen
Die in diesem Baustein beschriebenen Software-Komponenten beziehen sich hauptschlich auf
Produkte des Herstellers IBM. Es gibt darber hinaus viele Produkte von Drittherstellern, die hufig in
Grorechner-Umgebungen zum Einsatz kommen. Auf diese Produkte kann leider nur in
Ausnahmefllen eingegangen werden, da sonst der Rahmen des Bausteins gesprengt wrde.
Das z/OS-Betriebssystem besteht aus dem eigentlichen Betriebssystem (Kernel) mit Schnittstellen zu
den Benutzerprozessen. Verschiedene Subsysteme steuern und untersttzen die Kommunikation. Die
wichtigsten Subsysteme sind
- das Job Entry Subsystem (JES) fr den Hintergrundbetrieb (Stapelverarbeitung oder Batch
genannt),
- die Time Sharing Option (TSO) fr den Vordergrundbetrieb (interaktiv) und
- die Unix System Services (Posix-kompatibles Unix-Subsystem).
Weitere Subsysteme sind z. B.
- der Transaktionsmanager IMS und die zugehrige Datenbank fr die transaktionsorientierte
Datenverarbeitung,
- der Transaktionsmanager CICS fr die transaktionsorientierte Datenverarbeitung,
- die Datenbank DB2 fr relationale Datenbanken und
- der Communications Server (SNA, TCP/IP) fr Netzanbindungen.
Die Sicherheitsschnittstelle System Authorization Facility (SAF) ermglicht es, das System und die
Dateien vor unbefugten Zugriffen zu schtzen. Die eigentlichen Sicherheitsfunktionen werden dabei
von der Sicherheitssoftware RACF bereitgestellt. Als alternative Produkte sind an dieser Stelle auch
Top Secret und ACF2 zu nennen.
Die folgende Abbildung stellt die Zusammenhnge des Betriebssystemaufbaus stark vereinfacht dar:
Abbildung: Prinzipieller Aufbau des z/OS-Betriebssystems
_________________________________________________________________________________________
_________________________________________________________________________________________
Eine bersicht ber die zSeries- und z/OS-Architektur und Erklrungen zu der Terminologie finden
sich in den folgenden Manahmen:
- M 3.39 Einfhrung in die zSeries-Plattform
- M 3.40 Einfhrung in das z/OS-Betriebssystem
- M 3.41 Einfhrung in Linux und z/VM fr zSeries-Systeme
Gefhrdungslage
Generell hngt die Gefhrdungslage vom Einsatzszenario ab. Ein z/OS-System mit SNA-Anschluss an
einem isolierten behrden- oder firmeninternen Netz ist z. B. in der Regel weniger gefhrdet als ein
z/OS-System, das an das Internet angeschlossen ist und dort Web-Services anbietet. Darber hinaus
spielt es eine Rolle, ob auf Daten nur lesend zugegriffen werden soll (z. B. bei einem
Auskunftssystem) oder ob die Daten bearbeitet werden knnen. Gerade durch den Einsatz von Web-
Servern oder Web-Applikationen mit Internet-Anbindung hat sich die Gefhrdungslage der frher als
"sehr sicher" geltenden Mainframe-Systeme stark erhht.
Aufgrund der ffentlichen Netzanbindung von Mainframe-Systemen ergeben sich wesentlich strkere
Gefhrdungen durch unsachgeme oder fehlerhafte Konfiguration der Systeme oder durch fehlende
oder unvollstndig etablierte Prozesse, als es frher der Fall war.
Dies gilt sowohl fr externe Anbindungen und darber mgliche Angriffe, als auch fr den internen
Bereich. Mainframe-Systeme sind heute hnlichen Gefhrdungen ausgesetzt wie Unix- oder
Windows-Systeme.
- G 2.54 Vertraulichkeitsverlust durch Restinformationen
- G 2.99 Unzureichende oder fehlerhafte Konfiguration der zSeries-Systemumgebung
- G 3.66 Fehlerhafte Zeichensatzkonvertierung beim Einsatz von z/OS
- G 3.67 Unzureichende oder fehlerhafte Konfiguration des z/OS-Betriebssystems
- G 3.68 Unzureichende oder fehlerhafte Konfiguration des z/OS-Webservers
- G 3.69 Fehlerhafte Konfiguration der Unix System Services unter z/OS
- G 3.70 Unzureichender Dateischutz des z/OS-Systems
- G 3.71 Fehlerhafte Systemzeit bei z/OS-Systemen
- G 3.72 Fehlerhafte Konfiguration des z/OS-Sicherheitssystems RACF
- G 3.73 Fehlbedienung der z/OS-Systemfunktionen
- G 3.74 Unzureichender Schutz der z/OS-Systemeinstellungen vor dynamischen
nderungen
- G 3.75 Mangelhafte Kontrolle der Batch-Jobs bei z/OS
- G 4.50 berlastung des z/OS-Betriebssystems
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 5.116 Manipulation der z/OS-Systemsteuerung
- G 5.117 Verschleiern von Manipulationen unter z/OS
- G 5.118 Unbefugtes Erlangen hherer Rechte im RACF
- G 5.119 Benutzung fremder Kennungen unter z/OS-Systemen
- G 5.120 Manipulation der Linux/zSeries Systemsteuerung
- G 5.121 Angriffe ber TCP/IP auf z/OS-Systeme
- G 5.122 Missbrauch von RACF-Attributen unter z/OS
("Bausteine") gem den Ergebnissen der im Kapitel 2.3 beschriebenen Modellierung auszuwhlen.
Fr den erfolgreichen Aufbau eines z/OS-Mainframe-Systems sind eine Reihe von Manahmen
umzusetzen, beginnend mit der strategischen Entscheidung, ber Konzeption und Installation bis zum
Betrieb. Nicht vergessen werden darf dabei die ordnungsgeme Aussonderung eines Systems, wenn
das Ende der Betriebsphase erreicht wird.
Parallel zur Betriebsphase muss die Notfallvorsorge sicherstellen, dass der Betrieb auch im Notfall
aufrecht erhalten werden kann. IT-Sicherheitsmanagement und Revision stellen sicher, dass das
Regelwerk auch eingehalten wird.
Die Schritte, die dabei zu durchlaufen sind, sowie die Manahmen, die in den jeweiligen Phasen
beachtet werden sollten, sind im Folgenden aufgefhrt:
Strategie
Vor Beginn einer jeden Planung findet eine Phase der strategischen Orientierung statt, die weitgehend
auf den Anforderungen der Anwendungseigner basiert. Hier ist zu prfen, ob die z/OS-Plattform fr
die Lsung der jeweiligen Aufgabenstellung geeignet ist.
Darber hinaus kommt es auf die generelle Ausrichtung der IT-Landschaft des Rechenzentrums an.
Gibt es noch keine z/OS-Plattform im Betrieb, muss der Aufbau des notwendigen Wissens des
Betriebspersonals entsprechend vorbereitet werden. Als Hilfestellung fr die strategische Planung
dienen die Manahmen
- M 3.39 Einfhrung in die zSeries-Plattform,
- M 3.40 Einfhrung in das z/OS-Betriebssystem und
- M 3.41 Einfhrung in Linux und z/VM fr zSeries-Systeme.
Sie geben einen berblick ber die einzelnen Funktionen von Hard- und Software und untersttzen
damit das Verstndnis fr die z/OS-Plattform.
_________________________________________________________________________________________
_________________________________________________________________________________________
Konzeption
Sollte die strategische Entscheidung fr den Einsatz eines z/OS-Mainframe-Systems gefallen sein,
muss sich eine detaillierte Planung fr den Einsatz dieses Systems anschlieen. Die folgenden
Manahmen sind dabei zu bercksichtigen:
- Vor der Anschaffung und Inbetriebnahme von zSeries-Systemen mssen verschiedene planerische
Ttigkeiten durchgefhrt werden (siehe M 2.286 Planung und Einsatz von zSeries-Systeme).
- Bei hheren Ansprchen an die Verfgbarkeit oder die Skalierbarkeit empfiehlt sich der Einsatz
eines Parallel-Sysplex-Clusters (siehe M 4.221 Parallel-Sysplex unter z/OS).
- Es mssen Sicherheitsrichtlinien fr das z/OS-System und besonders auch fr das
Sicherheitssystem RACF (Resource Access Control Facility) geplant und festgelegt werden (siehe
M 2.288 Erstellung von Sicherheitsrichtlinien fr z/OS-Systeme).
- Es mssen Standards fr die z/OS-Systemdefinitionen festgelegt werden (siehe M 2.285
Festlegung von Standards fr z/OS-Systemdefinitionen).
- Es sollte ein Rollenkonzept fr die Systemverwaltung von z/OS-Systemen eingefhrt werden
(siehe M 2.295 Systemverwaltung von z/OS-Systemen).
Umsetzung
Nachdem die organisatorischen und planerischen Vorarbeiten durchgefhrt worden sind, kann die
Installation der zSeries-Hardware und des z/OS-Betriebssystems erfolgen. Dabei sind die folgenden
Manahmen zu beachten:
- Es ist eine sichere Grundkonfiguration der Autorisierungsmechanismen des z/OS-Betriebssystems
erforderlich (siehe M 4.209 Sichere Grundkonfiguration von z/OS-Systemen).
- Wesentlich fr die Absicherung der z/OS-Umgebung ist die entsprechende Konfiguration des
Sicherheitssystems (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
- Fr die Umsetzung der z/OS-Steuerung einschlielich der Fernsteuerungskonsole RSF (Remote
Support Facility) sind die Empfehlungen in Manahme M 4.207 Einsatz und Sicherung
systemnaher z/OS-Terminals zu beachten.
Betrieb
Nach der Erstinstallation und einer Testbetriebsphase wird der Regelbetrieb aufgenommen. Unter
- Die Bereitstellung der Funktionalitten des z/OS-Betriebssystems setzt einen sicheren Betrieb des
z/OS-Betriebssystems voraus (siehe M 4.210 Sicherer Betrieb des z/OS-Betriebssystems).
- Es mssen die Dienstprogramme abgesichert werden, die zur Untersttzung von betrieblichen
Funktionen des z/OS-Betriebssystems dienen und eine hohe Autorisierung bentigen (siehe
M 4.215 Absicherung sicherheitskritischer z/OS-Dienstprogramme).
- Die erforderlichen Wartungsaktivitten eines z/OS-Systems sind in der Manahme M 2.293
Wartung von zSeries-Systemen beschrieben.
- z/OS-Systeme oder Parallel-Sysplex-Cluster mssen im laufenden Betrieb berwacht werden
(siehe M 2.292 berwachung von z/OS-Systemen).
Aussonderung
Empfehlungen zur Deinstallation von z/OS-Systemen, etwa nach Abschluss des Regelbetriebs, finden
sich in der Manahme M 2.297 Deinstallation von z/OS-Systemen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Notfallvorsorge
Empfehlungen zur Notfallvorsorge finden sich in der Manahme M 6.93 Notfallvorsorge fr z/OS-
Systeme.
IT-Sicherheitsmanagement und Revision
Das IT-Sicherheitsmanagement sollte den kompletten Lebenszyklus eines z/OS-Systems begleiten.
Die folgenden Punkte sollten besonders beachtet werden:
- Bei der Vergabe und der Revision von Autorisierungen ist zu prfen, ob die entsprechenden
Mitarbeiter diese fr ihre Ttigkeit bentigen. Dies gilt besonders fr hohe Autorisierungen (siehe
Manahme M 2.289 Einsatz restriktiver z/OS-Kennungen).
- Beim Betrieb eines z/OS-Systems ist regelmig zu kontrollieren, ob die Sicherheitsvorgaben
eingehalten werden (siehe Manahme M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS).
Nachfolgend wird das Manahmenbndel fr den Baustein "S/390- und zSeries-Mainframe"
vorgestellt.
Organisation:
- M 2.285 (1) Festlegung von Standards fr z/OS-Systemdefinitionen (optional)
- M 2.286 (1) Planung und Einsatz von zSeries-Systemen (optional)
- M 2.287 (3) Batch-Job-Planung fr z/OS-Systeme (optional)
- M 2.288 (1) Erstellung von Sicherheitsrichtlinien fr z/OS-Systeme
- M 2.289 (1) Einsatz restriktiver z/OS-Kennungen
- M 2.290 (2) Einsatz von RACF-Exits (optional)
- M 2.291 (2) Sicherheits-Berichtswesen und -Audits unter z/OS
- M 2.292 (1) berwachung von z/OS-Systemen
- M 2.293 (1) Wartung von zSeries-Systemen
- M 2.294 (1) Synchronisierung von z/OS-Passwrtern und RACF-Kommandos (optional)
- M 2.295 (1) Systemverwaltung von z/OS-Systemen
- M 2.296 (3) Grundstzliche berlegungen zu z/OS-Transaktionsmonitoren (optional)
- M 2.297 (2) Deinstallation von z/OS-Systemen
Personal:
- M 3.39 (1) Einfhrung in die zSeries-Plattform
- M 3.40 (1) Einfhrung in das z/OS-Betriebssystem
- M 3.41 (1) Einfhrung in Linux und z/VM fr zSeries-Systeme
- M 3.42 (1) Schulung des z/OS-Bedienungspersonals
Hardware/Software:
- M 4.207 (1) Einsatz und Sicherung systemnaher z/OS-Terminals
- M 4.208 (2) Absichern des Start-Vorgangs von z/OS-Systemen
- M 4.209 (1) Sichere Grundkonfiguration von z/OS-Systemen
- M 4.210 (2) Sicherer Betrieb des z/OS-Betriebssystems
- M 4.211 (1) Einsatz des z/OS-Sicherheitssystems RACF
- M 4.212 (3) Absicherung von Linux fr zSeries (optional)
- M 4.213 (1) Absichern des Login-Vorgangs unter z/OS
- M 4.214 (1) Datentrgerverwaltung unter z/OS-Systemen
- M 4.215 (1) Absicherung sicherheitskritischer z/OS-Dienstprogramme
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 4.216 (2) Festlegung der Systemgrenzen von z/OS

- M 4.217 (2) Workload Management fr z/OS-Systeme
- M 4.218 (3) Hinweise zur Zeichensatzkonvertierung bei z/OS-Systemen (optional)
- M 4.219 (1) Lizenzschlssel-Management fr z/OS-Software
- M 4.220 (2) Absicherung von Unix System Services bei z/OS-Systemen
- M 4.221 (2) Parallel-Sysplex unter z/OS
Kommunikation:
- M 5.113 (3) Einsatz des VTAM Session Management Exit unter z/OS (optional)
- M 5.114 (1) Absicherung der z/OS-Tracefunktionen
Notfallvorsorge:
- M 6.67 (2) Einsatz von Detektionsmanahmen fr Sicherheitsvorflle
- M 6.93 (1) Notfallvorsorge fr z/OS-Systeme
_________________________________________________________________________________________
Datenbertragungseinrichtungen 7
_________________________________________________________________________________________
7 Datenbertragungseinrichtungen
In diesem Kapitel wird der IT-Grundschutz fr Einrichtungen zur Datenbertragung dargestellt:
7.2 Modem
7.4 E-Mail
7.5 Webserver
7.6 Remote Access
7.7 Lotus Notes
7.9 Apache Webserver
_________________________________________________________________________________________
Datentrgeraustausch 7.1
_________________________________________________________________________________________
Beschreibung
Betrachtet wird der Austausch von Datentrgern zur
Datenbertragung zwischen nicht vernetzten IT-
Systemen. Bercksichtigte Datentrger sind Disketten,
Wechselplatten (magnetisch, magneto-optisch), CD-
ROMs, Magnetbnder und Kassetten. Daneben wird auch
die Speicherung der Daten auf dem Sender- und
Empfnger-System, soweit es in direktem Zusammen-
hang mit dem Datentrgeraustausch steht, sowie der
Umgang mit den Datentrgern vor bzw. nach dem
Versand bercksichtigt.
Gefhrdungslage
Fr den IT-Grundschutz im Rahmen des Austausches von Datentrgern werden folgende typische
Hhere Gewalt:
- G 1.9 Datenverlust durch starke Magnetfelder
- G 2.10 Nicht fristgerecht verfgbare Datentrger
- G 2.17 Mangelhafte Kennzeichnung der Datentrger
- G 3.12 Verlust der Datentrger beim Versand
- G 3.13 bertragung falscher oder nicht gewnschter Datenstze
- G 5.4 Diebstahl
- G 5.29 Unberechtigtes Kopieren der Datentrger
_________________________________________________________________________________________
Datentrgeraustausch 7.1
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "Datentrgeraustausch" vorgestellt.
Infrastruktur:
- M 1.36 (2) Sichere Aufbewahrung der Datentrger vor und nach Versand (optional)
Organisation:
- M 2.43 (1) Ausreichende Kennzeichnung der Datentrger beim Versand
- M 2.44 (1) Sichere Verpackung der Datentrger
- M 2.45 (1) Regelung des Datentrgeraustausches
- M 2.46 (2) Geeignetes Schlsselmanagement (optional)
Personal:
- M 3.14 (2) Einweisung des Personals in den geregelten Ablauf eines Datentrgeraustausches
(optional)
(optional)
Hardware/Software:
- M 4.32 (2) Physikalisches Lschen der Datentrger vor und nach Verwendung
Datenbertragung
- M 4.34 (1) Einsatz von Verschlsselung, Checksummen oder Digitalen Signaturen (optional)
- M 4.35 (3) Verifizieren der zu bertragenden Daten vor Versand (optional)
Kommunikation:
- M 5.22 (2) Kompatibilittsprfung des Sender- und Empfngersystems (optional)
- M 5.23 (2) Auswahl einer geeigneten Versandart fr den Datentrger
Notfallvorsorge:
- M 6.38 (2) Sicherungskopie der bermittelten Daten (optional)
_________________________________________________________________________________________
Modem 7.2
_________________________________________________________________________________________
7.2 Modem
Beschreibung
ber ein Modem wird eine Datenendeinrichtung, z. B.
ein PC, ber das ffentliche Telefonnetz mit anderen
Datenendeinrichtungen verbunden, um Informationen
austauschen zu knnen. Ein Modem wandelt die digitalen
Signale aus der Datenendeinrichtung in analoge
elektrische Signale um, die ber das Telefonnetz
bertragen werden knnen. Damit zwei IT-Systeme ber
Modem kommunizieren knnen, muss auf den IT-
Systemen die entsprechende Kommunikationssoftware
installiert sein.
Unterschieden werden externe, interne und PCMCIA-Modems. Ein externes Modem ist ein
eigenstndiges Gert mit eigener Stromversorgung, das blicherweise ber eine serielle Schnittstelle
mit dem IT-System verbunden wird. Als internes Modem werden Steckkarten mit Modem-
Funktionalitt, die ber keine eigene Stromversorgung verfgen, bezeichnet. Ein PCMCIA-Modem ist
eine scheckkartengroe Einsteckkarte, die ber eine PCMCIA-Schnittstelle blicherweise in Laptops
eingesetzt wird.
In diesem Kapitel wird Datenbertragung ber ISDN nicht betrachtet, dazu siehe Kapitel 8.1 TK-
Anlage.
Gefhrdungslage
In diesem Kapitel werden fr den IT-Grundschutz beim Einsatz eines Modems folgende
Hhere Gewalt:
- G 5.12 Abhren von Telefongesprchen und Datenbertragungen
- G 5.25 Maskerade
- G 5.39 Eindringen in Rechnersysteme ber Kommunikationskarten
_________________________________________________________________________________________
Modem 7.2
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich "Modem" vorgestellt.
Infrastruktur:
- M 1.38 (1) Geeignete Aufstellung eines Modems
Organisation:
- M 2.59 (1) Auswahl eines geeigneten Modems in der Beschaffung
- M 2.60 (1) Sichere Administration eines Modems
- M 2.61 (2) Regelung des Modem-Einsatzes
Personal:
- M 3.17 (1) Einweisung des Personals in die Modem-Benutzung
Hardware/Software:
Datenbertragung
Kommunikation:
- M 5.30 (1) Aktivierung einer vorhandenen Callback-Option
- M 5.31 (1) Geeignete Modem-Konfiguration
- M 5.32 (1) Sicherer Einsatz von Kommunikationssoftware
- M 5.33 (1) Absicherung der per Modem durchgefhrten Fernwartung
- M 5.44 (2) Einseitiger Verbindungsaufbau (optional)
_________________________________________________________________________________________
Sicherheitsgateway (Firewall) 7.3
_________________________________________________________________________________________

Beschreibung
Ein Sicherheitsgateway (oft auch Firewall genannt) ist
ein System aus soft- und hardwaretechnischen Kompo-
nenten um IP-Netze sicher zu koppeln. Dazu wird die
technisch mgliche auf die in einer IT-Sicherheitsleitlinie
ordnungsgem definierte Kommunikation einge-
schrnkt. Sicherheit bei der Netzkopplung bedeutet hier-
bei die ausschlieliche Zulassung erwnschter Zugriffe
oder Datenstrme zwischen verschiedenen Netzen.
Sicherheitsgateways werden am zentralen bergang
zwischen zwei unterschiedlich vertrauenswrdigen Netzen eingesetzt. Unterschiedlich
vertrauenswrdige Netze stellen dabei nicht unbedingt nur die Kombination Internet-Intranet dar.
Vielmehr knnen auch zwei organisationsinterne Netze unterschiedlich hohen Schutzbedarf besitzen,
z. B. bei der Trennung des Brokommunikationsnetzes vom Netz der Personalabteilung, in dem
besonders schutzwrdige, personenbezogene Daten bertragen werden.
Die Verwendung des Begriffs Sicherheitsgateway anstatt des blicherweise verwendeten Begriffs
"Firewall" soll verdeutlichen, dass zur Absicherung von Netzbergngen heute oft nicht mehr ein
einzelnes Gert verwendet wird, sondern eine ganze Reihe von IT-Systemen, die unterschiedliche
Aufgaben bernehmen, z. B. Paketfilterung, Schutz vor Viren oder die berwachung des Netzver-
kehrs ("Intrusion Detection").
In diesem Kapitel werden ausschlielich die fr ein Sicherheitsgateway spezifischen Gefhrdungen
und Manahmen beschrieben. Zustzlich sind noch die Gefhrdungen und Manahmen zu betrachten,
die fr das IT-System, mit dem das Sicherheitsgateway realisiert wird, spezifisch sind. Oftmals
werden Komponenten von Sicherheitsgateways auf einem Unix-System implementiert - in diesem Fall
sind zustzlich zu den im Folgenden beschriebenen Gefhrdungen und Manahmen die in Kapitel 6.2
Unix-Server beschriebenen zu beachten.
Gefhrdungslage
Fr den IT-Grundschutz eines Sicherheitsgateways werden die folgenden typischen Gefhrdungen
angenommen:
- G 2.24 Vertraulichkeitsverlust schutzbedrftiger Daten des zu schtzenden Netzes
- G 2.101 Unzureichende Notfallvorsorge bei einem Sicherheitsgateway
_________________________________________________________________________________________
_________________________________________________________________________________________

- G 4.20 Datenverlust bei erschpftem Speichermedium
- G 4.39 Software-Konzeptionsfehler
- G 5.25 Maskerade
- G 5.49 Missbrauch des Source-Routing
- G 5.50 Missbrauch des ICMP-Protokolls
- G 5.51 Missbrauch der Routing-Protokolle
Ein Sicherheitsgateway schtzt nicht vor Angriffen, die innerhalb des internen Netzes erfolgen. Um
das interne Netz gegen Angriffe von Innenttern zu schtzen, mssen auch beim Einsatz eines
Sicherheitsgateways alle erforderlichen Sicherheitsmanahmen umgesetzt sein. Wenn es sich bei dem
internen Netz beispielsweise um ein Unix- bzw. PC-Netz handelt, sind die in Kapitel 6.2 Unix-Server
bzw. Kapitel 6.1 Servergesttztes Netz beschriebenen Sicherheitsmanahmen umzusetzen.
Das Sicherheitsgateway sollte in einem separaten Serverraum aufgestellt werden. Hierbei zu
realisierende Manahmen sind in Kapitel 4.3.2 Serverraum beschrieben. Wenn kein Serverraum zur
Verfgung steht, kann das Sicherheitsgateway alternativ in einem Serverschrank aufgestellt werden
(siehe Kapitel 4.4 Schutzschrnke). Soll das Sicherheitsgateway nicht in Eigenregie, sondern von
einem Dienstleister betrieben werden, so ist der Baustein 3.10 Outsourcing anzuwenden. Insbesondere
sollten die Empfehlungen in M 5.116 Integration eines E-Mailservers in ein Sicherheitsgateway
beachtet werden.
Fr den erfolgreichen Aufbau eines Sicherheitsgateway sind eine Reihe von Manahmen umzusetzen,
beginnend mit der Konzeption ber die Beschaffung bis zum Betrieb der Komponenten. Die Schritte,
die dabei durchlaufen werden sollten, sowie die Manahmen, die in den jeweiligen Schritten beachtet
werden sollten, sind im folgenden aufgefhrt.
1. Konzept der Netzkopplung mit Hilfe eines Sicherheitsgateway (siehe M 2.70 Entwicklung eines
Konzepts fr Sicherheitsgateways):
- Festlegung der Sicherheitsziele
- Anpassung der Netzstruktur
- grundlegende Voraussetzungen
2. Policy des Sicherheitsgateways (siehe M 2.71 Festlegung einer Policy fr ein Sicherheitsgateway):
- Auswahl der Kommunikationsanforderungen
_________________________________________________________________________________________
_________________________________________________________________________________________
- Auswahl der Dienste (Vor der Diensteauswahl sollten die Erluterungen und
Randbedingungen aus M 5.39 Sicherer Einsatz der Protokolle und Dienste gelesen werden.)
- Organisatorische Regelungen
3. Beschaffung der Komponenten des Sicherheitsgateways:
- Auswahl des Grundaufbaus des Sicherheitsgateways (siehe M 2.73 Auswahl geeigneter
Grundstrukturen fr Sicherheitsgateways)
- Beschaffungskriterien (siehe M 2.74 Geeignete Auswahl eines Paketfilters und M 2.75
Geeignete Auswahl eines Application-Level-Gateways)
4. Sicherheitsrichtlinie fr das Sicherheitsgateway (siehe M 2.299 Erstellung einer Sicherheitsleitlinie
fr ein Sicherheitsgateway)
- Regelungen und Hinweise zum sicheren Betrieb und zur sicheren Administration des
Sicherheitsgateways bzw. seiner einzelnen Komponenten
5. Aufbau des Sicherheitsgateways:
- Filterregeln aufstellen und implementieren (siehe M 2.76 Auswahl und Einrichtung
geeigneter Filterregeln)
- Umsetzung der IT-Grundschutz-Manahmen fr die Komponenten des Sicherheitsgateways
(siehe Kapitel 6.2 Unix-Server)
- Umsetzung der IT-Grundschutz-Manahmen, die IT-Systeme des internen Netzes
berprfen (siehe z. B. siehe Kapitel 6.1 Servergesttztes Netz, 6.2 Unix-Server und 6.3
Peer-to-Peer-Dienste)
- Randbedingungen fr sicheren Einsatz der einzelnen Protokolle und Dienste beachten (siehe
M 5.39 Sicherer Einsatz der Protokolle und Dienste)
- Einbindung weiterer Komponenten (siehe M 2.77 Integration von Servern in das
Sicherheitsgateway)
6. Betrieb des Sicherheitsgateways: (siehe M 2.78 Sicherer Betrieb eines Sicherheitsgateways)
- Regelmige Kontrolle
- Anpassung an nderungen und Tests
- Protokollierung der Sicherheitsgateway-Aktivitten (siehe M 4.47 Protokollierung der
Sicherheitsgateway-Aktivitten)
- Notfallvorsorge fr das Sicherheitsgateway (ergnzend siehe Kapitel 3.3 Notfallvorsorge-
Konzept)
- Datensicherung (siehe Kapitel 3.4 Datensicherungskonzept)
7. Betrieb der an das Sicherheitsgateway angeschlossenen Clients
Auf Seite der Clients ist - neben den in Kapitel 5 beschriebenen Manahmen - zustzlich die
Manahme M 5.45 Sicherheit von WWW-Browsern zu beachten.
Es kann verschiedene Grnde geben, sich gegen den Einsatz eines Sicherheitsgateways zu
entscheiden. Dies knnen die Anschaffungskosten oder der Administrationsaufwand sein, aber auch
die Tatsache, dass die bestehenden Restrisiken nicht in Kauf genommen werden knnen. Falls
trotzdem ein Anschluss an das Internet gewnscht ist, kann alternativ ein Stand-alone-System
eingesetzt werden (siehe M 5.46 Einsatz von Stand-alone-Systemen zur Nutzung des Internets).
_________________________________________________________________________________________
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Bereich " Sicherheitsgateway" vorgestellt.

Organisation:
- M 2.70 (1) Entwicklung eines Konzepts fr Sicherheitsgateways
- M 2.71 (1) Festlegung einer Policy fr ein Sicherheitsgateway
- M 2.72 (1) Anforderungen an eine Firewall
- M 2.73 (1) Auswahl geeigneter Grundstrukturen fr Sicherheitsgateways
- M 2.74 (1) Geeignete Auswahl eines Paketfilters
- M 2.75 (1) Geeignete Auswahl eines Application-Level-Gateways
- M 2.76 (1) Auswahl und Einrichtung geeigneter Filterregeln
- M 2.77 (1) Integration von Servern in das Sicherheitsgateway
- M 2.78 (1) Sicherer Betrieb eines Sicherheitsgateways
- M 2.299 (1) Erstellung einer Sicherheitsrichtlinie fr ein Sicherheitsgateway
- M 2.300 (3) Sichere Auerbetriebnahme oder Ersatz von Komponenten eines
Sicherheitsgateways
- M 2.301 (3) Outsourcing des Sicherheitsgateway (optional)
- M 2.302 (3) Sicherheitsgateways und Hochverfgbarkeit (optional)
Personal
- M 3.43 (3) Schulung der Administratoren des Sicherheitsgateways
- M 4.47 (1) Protokollierung der Sicherheitsgateway-Aktivitten
- M 4.100 (1) Sicherheitsgateways und aktive Inhalte
- M 4.101 (1) Sicherheitsgateways und Verschlsselung
- M 4.222 (2) Festlegung geeigneter Einstellungen von Sicherheitsproxies
- M 4.223 (2) Integration von Proxy-Servern in das Sicherheitsgateway
- M 4.224 (1) Integration von Virtual Private Networks in ein Sicherheitsgateway (optional)
- M 4.225 (3) Einsatz eines Protokollierungsservers in einem Sicherheitsgateway (optional)
- M 4.226 (3) Integration von Virenscannern in ein Sicherheitsgateway (optional)
- M 4.227 (3) Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation
Kommunikation:
- M 5.39 (1) Sicherer Einsatz der Protokolle und Dienste
- M 5.45 (2) Sicherheit von WWW-Browsern
- M 5.46 (1) Einsatz von Stand-alone-Systemen zur Nutzung des Internets
- M 5.70 (1) Adreumsetzung - NAT (Network Address Translation)
- M 5.71 (1) Intrusion Detection und Intrusion Response Systeme
- M 5.115 (3) Integration eines Webservers in ein Sicherheitsgateway (optional)
- M 5.116 (3) Integration eines E-Mailservers in ein Sicherheitsgateway (optional)
- M 5.117 (3) Integration eines Datenbank-Servers in ein Sicherheitsgateway (optional)
- M 5.118 (3) Integration eines DNS-Servers in ein Sicherheitsgateway (optional)
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 5.119 (1) Integration einer Web-Anwendung mit Web-, Applikations- und Datenbank-Server
in ein Sicherheitsgateway (optional)
- M 5.120 (1) Behandlung von ICMP am Sicherheitsgateway
Notfallvorsorge:
- M 6.94 (3) Notfallvorsorge bei Sicherheitsgateways
_________________________________________________________________________________________
E-Mail 7.4
_________________________________________________________________________________________
7.4 E-Mail
Beschreibung
Der Dienst "Electronic Mail", kurz E-Mail, erlaubt es,
elektronische Nachrichten innerhalb krzester Zeit welt-
weit zu versenden und zu empfangen. Eine E-Mail hat im
Allgemeinen neben den Adressangaben (From/To) eine
Titel- oder Betreffzeile (Subject), einen Textkrper und
eventuell ein oder mehrere Anhnge (Attachments).
Mittels E-Mail knnen nicht nur kurze Informationen
schnell, bequem und informell weitergegeben werden,
sondern es knnen auch Geschftsvorflle zur Weiterbe-
arbeitung an andere Bearbeiter weitergeleitet werden. Ab-
hngig davon, fr welchen Einsatzzweck E-Mail eingesetzt wird, unterscheiden sich auch die Anspr-
che an Vertraulichkeit, Verfgbarkeit, Integritt und Verbindlichkeit der zu bertragenden Daten so-
wie des eingesetzten E-Mail-Programms.
Gefhrdungslage
Fr den IT-Grundschutz im Rahmen des elektronischen Dateiaustausches ber E-Mail werden
- G 2.54 Vertraulichkeitsverlust durch Restinformationen
- G 2.55 Ungeordnete E-Mail-Nutzung
- G 2.56 Mangelhafte Beschreibung von Dateien
- G 4.32 Nichtzustellung einer Nachricht
- G 4.37 Mangelnde Authentizitt und Vertraulichkeit von E-Mail
- G 5.25 Maskerade
_________________________________________________________________________________________
E-Mail 7.4
_________________________________________________________________________________________

- G 5.72 Mibruchliche E-Mail-Nutzung
- G 5.73 Vortuschen eines falschen Absenders
- G 5.74 Manipulation von Alias-Dateien oder Verteilerlisten
- G 5.75 berlastung durch eingehende E-Mails
- G 5.76 Mailbomben
- G 5.77 Mitlesen von E-Mails
- G 5.110 Web-Bugs
- G 5.111 Missbrauch aktiver Inhalte in E-Mails
Bei der Betrachtung von E-Mailsystemen sind im Wesentlichen die folgenden Komponenten zu
untersuchen:
- Die Benutzer setzen fr den Versand, den Empfang und die Bearbeitung von E-Mails
Mailprogramme ein.
- Die Benutzer-Mailprogramme bergeben und erhalten die E-Mail an bzw. von einem Mailserver.
Zu diesem Zweck fhrt der Mailserver fr jeden Benutzer eine Mailbox. Fr den weiteren
Nachrichtentransport kommuniziert der Mailserver mit Gateways, die die Nachrichten an andere
Mailsysteme senden.
Dies erfordert bei der Umsetzung von Sicherheitsmanahmen fr den Informationsaustausch per
E-Mail, dass zunchst eine bergreifende Sicherheitsrichtlinie erarbeitet wird (siehe M 2.118 Konzep-
tion der sicheren E-Mail-Nutzung).
Der Betrieb von E-Mailsystemen erfordert neben der Umsetzung von Sicherheitsmanahmen am
Mailserver auch Sicherheitsmanahmen an den eingesetzten Clients. Von besonderer Bedeutung sind
jedoch die von den Benutzern einzuhaltenden Sicherheitsvorkehrungen und Anweisungen.
Werden als E-Mail-Programme Lotus Notes oder Microsoft Exchange eingesetzt, so sind zustzlich zu
den hier beschriebenen Manahmen die in den Kapiteln 7.7 Lotus Notes und 7.10 Exchange 2000 /
Outlook 2000 vorgestellten systemspezifischen Manahmen umzusetzen. Fr andere E-Mail-
Programme sind analoge Sicherheitsmanahmen zu ergreifen.
Nachfolgend wird das Manahmenbndel fr den Bereich "E-Mail" vorgestellt.
Organisation:
- M 2.118 (1) Konzeption der sicheren E-Mail-Nutzung
- M 2.119 (1) Regelung fr den Einsatz von E-Mail
- M 2.120 (1) Einrichtung einer Poststelle
- M 2.121 (2) Regelmiges Lschen von E-Mails
- M 2.122 (2) Einheitliche E-Mail-Adressen
- M 2.123 (2) Auswahl eines Mailproviders
- M 2.274 (1) Vertretungsregelungen bei E-Mail-Nutzung
_________________________________________________________________________________________
E-Mail 7.4
_________________________________________________________________________________________
- M 2.275 (3) Einrichtung funktionsbezogener E-Mailadressen (optional)

Personal:
Hardware/Software:
Datenbertragung
- M 4.64 (1) Verifizieren der zu bertragenden Daten vor Weitergabe / Beseitigung von
Restinformationen
- M 4.199 (1) Vermeidung gefhrlicher Dateiformate
Kommunikation:
- M 5.22 (2) Kompatibilittsprfung des Sender- und Empfngersystems (optional)
- M 5.53 (2) Schutz vor Mailbomben
- M 5.54 (2) Schutz vor Mailberlastung und Spam
- M 5.55 (2) Kontrolle von Alias-Dateien und Verteilerlisten
- M 5.56 (1) Sicherer Betrieb eines Mailservers
- M 5.57 (1) Sichere Konfiguration der Mail-Clients
- M 5.63 (2) Einsatz von GnuPG oder PGP (optional)
- M 5.67 (3) Verwendung eines Zeitstempel-Dienstes (optional)
- M 5.108 (3) Kryptographische Absicherung von E-Mail (optional)
- M 5.109 (2) Einsatz eines E-Mail-Scanners auf dem Mailserver (optional)
- M 5.110 (3) Absicherung von E-Mail mit SPHINX (S/MIME) (optional)
Notfallvorsorge:
- M 6.38 (2) Sicherungskopie der bermittelten Daten (optional)
- M 6.90 (3) Datensicherung und Archivierung von E-Mails
_________________________________________________________________________________________
Webserver 7.5
_________________________________________________________________________________________
7.5 Webserver
Beschreibung
Das World Wide Web (WWW) ist eines der zentralen
Medien der heutigen Informationsgesellschaft. Die In-
formationsangebote im WWW werden von Servern be-
reitgestellt, die Daten, meist Dokumente in Form von
HTML-Seiten, an entsprechende Clientprogramme aus-
liefern. Dies erfolgt typischerweise ber die Protokolle
HTTP (Hypertext Transfer Protocol) oder HTTPS (HTTP
ber SSL bzw. TLS, d. h. HTTP geschtzt durch eine
verschlsselte Verbindung). Neben dem Einsatz im Inter-
net werden Webserver auch in zunehmendem Mae fr interne Informationen und Anwendungen in
Firmennetzen (Intranet) eingesetzt. Ein Grund dafr ist, dass sie eine einfache und standardisierte
Schnittstelle zwischen Server-Anwendungen und Benutzern bieten und entsprechende Client-Software
(Webbrowser) fr praktisch jede Betriebssystemumgebung kostenlos verfgbar ist.
Die Bezeichnung Webserver (oder auch WWW-Server) wird meist sowohl fr das Programm benutzt,
welches die HTTP-Anfragen beantwortet, als auch fr den Rechner, auf dem dieses Programm luft.
Bei Webservern sind verschiedene Sicherheitsaspekte zu beachten.
Da ein Webserver ein ffentlich zugngliches System darstellt, sind eine sorgfltige Planung vor dem
Aufbau eines Webservers und die sichere Installation und Konfiguration des Systems und seiner Netz-
umgebung von groer Bedeutung. Das Thema Sicherheit umfasst bei Webservern auch deswegen eine
relativ groe Anzahl von Gebieten, weil auf einem Webserver meist neben der reinen Webserver-An-
wendung noch weitere Serveranwendungen vorhanden sind, die zum Betrieb des Webservers erfor-
derlich sind und deren sicherer Betrieb ebenfalls gewhrleistet sein muss. Beispielsweise werden die
Daten meist ber das Netz (etwa per ftp oder scp) auf den Server bertragen oder es wird Zugriff auf
eine Datenbank bentigt.
Einige der relevanten Aspekte sollen an dieser Stelle kurz erlutert werden.
Planung des Webauftritts
Ein wichtiger Aspekt der Sicherheit eines Webservers ist bereits relevant, bevor dieser berhaupt
existiert: Planung und Organisation des Webangebots. Nur dann, wenn geklrt ist, welche Ziele mit
dem Webangebot erreicht werden sollen (handelt es sich um ein reines Informationsangebot, um ein
E-Commerce- oder ein E-Government-Angebot?) und welche Inhalte oder Anwendungen zu diesem
Zweck angeboten werden, kann durch entsprechende Manahmen dafr gesorgt werden, dass Sicher-
heitsprobleme so weit wie mglich vermieden werden.
Der Aspekt der Sicherheit muss bereits sehr frh in der Planungsphase bercksichtigt werden, um die
entstehende Architektur entsprechend sicher auslegen zu knnen.
Organisation
Bei der Betreuung eines Webangebots sind oft mehrere Organisationseinheiten beteiligt, hufig wer-
den die technische und die inhaltliche Betreuung von verschiedenen Stellen bernommen. Manchmal
wird der Server gar nicht mehr in der Organisation selbst betrieben, sondern bei einem externen
Dienstleister untergebracht. Fr das mglichst reibungslose Funktionieren des Webangebots mssen
daher entsprechende organisatorische Rahmenbedingungen geschaffen werden. Idealerweise sollte
eine Redaktion fr das Webangebot eingerichtet werden (siehe M 2.272 Einrichtung eines WWW-
Redaktionsteams).
_________________________________________________________________________________________
Webserver 7.5
_________________________________________________________________________________________
Auch bei der Festlegung der organisatorischen Rahmenbedingungen eines Webangebots sollte das
Thema Sicherheit eine Rolle spielen. Davon hngt insbesondere eine schnelle und effektive Reaktion
auf Probleme ab.
Sicherheit von Datenbertragung und Authentisierungsmechanismen
Generell wird ein Webserver von auen ber die HTTP-Schnittstelle angesprochen. Abhngig davon,
welches Ziel das Webangebot hat und welche Inhalte und Anwendungen angeboten werden, sind die
folgenden Fragen von Bedeutung:
- Muss die Integritt der Daten bei der bertragung vom Webserver zum Client geschtzt
werden?
- Muss die Vertraulichkeit der Daten bei der bertragung vom Webserver zum Client gewhr-
leistet werden?
- Ist eine Authentisierung des Webservers dem Client gegenber erforderlich?
- Ist eine Authentisierung der Clients gegenber dem Webserver erforderlich?
Bei einem reinen Informationsangebot, das ffentlich zugnglich sein soll, werden alle diese Fragen
normalerweise verneint werden knnen. Handelt es sich jedoch um ein E-Commerce- oder
E-Government-Angebot, so werden sicherlich mehrere Fragen bejaht.
Im Wesentlichen betreffen diese Fragen nur Eigenschaften der verwendeten bertragungsprotokolle
HTTP oder HTTPS. Spezifisch fr den einzelnen Webserver ist dabei nur, inwieweit der Webserver
diese Protokolle untersttzt. Diese Punkte knnen daher als Kriterien fr die Auswahl eines Webser-
ver-Produktes herangezogen werden.
Sicherheit der Inhalte und Anwendungen auf dem Webserver
Um die Inhalte und Anwendungen auf dem Server vor unbefugtem Zugriff oder Vernderung zu
schtzen, ist es wichtig, die Rechte der verschiedenen beteiligten Benutzer klar festzulegen. Die orga-
nisatorische und technische Realisierung der Trennung zwischen verschiedenen Benutzern, die even-
tuell Inhalte auf dem Server einstellen bzw. pflegen drfen, oder gar zwischen verschiedenen Weban-
geboten, die gemeinsam auf einem Server beheimatet sind, ist ein wichtiger Aspekt der Sicherheit
eines Webangebots.
Technische Sicherheit des Servers
Die Kompromittierung eines Webservers kann erhebliche finanzielle Verluste oder Imageschden
nach sich ziehen. Da es in der Regel keine oder nur wenige (vertrauenswrdige) Anwender auf einem
Web-Server gibt, werden die meisten Angriffe nicht lokal, sondern ber das Netz ausgefhrt. Daher
spielt der Schutz des Webservers gegen Angriffe ber das Netz (also z. B. ber das Internet, aber auch
aus dem Intranet heraus) eine sehr wichtige Rolle. Neben Angriffen auf die Webserver-Anwendung
sind auch Angriffe auf Schwachstellen des verwendeten Betriebssystems oder anderer Programme
mglich, beispielsweise auf eine nicht ausreichend gesicherte Datenbankanbindung, auf einen eventu-
ell vorhandenen ftp-Zugang oder auf per NFS oder SMB freigegebene Verzeichnisse. Oft wird zur
Realisierung eines Webangebots auch der Zugriff auf weitere IT-Systeme, etwa einen Datenbankser-
ver, bentigt. Da immer mehr Webangebote nicht mehr ausschlielich aus statischen HTML-Seiten
bestehen, sondern beispielsweise ber entsprechende Anwendungen Zugriff auf Datenbanken bieten,
spielt auerdem die Sicherheit dieser Programme eine zunehmende Rolle.
Gefhrdungslage
Fr den IT-Grundschutz werden pauschal die folgenden Gefhrdungen als typisch im Zusammenhang
mit einem Webserver und der Nutzung des WWW angenommen:
_________________________________________________________________________________________
Webserver 7.5
_________________________________________________________________________________________
- G 2.28 Verste gegen das Urheberrecht
- G 2.37 Unkontrollierter Aufbau von Kommunikationsverbindungen
- G 2.96 Veraltete oder falsche Informationen in einem Webangebot
- G 2.100 Fehler bei der Beantragung und Verwaltung von Internet-Domainnamen
- G 3.37 Unproduktive Suchzeiten
- G 5.87 Web-Spoofing
steine") wie in Kapitel 2.3 und 2.4 beschrieben auszuwhlen.
In diesem Kapitel werden die fr einen Webserver spezifischen Gefhrdungen und Manahmen be-
schrieben. Darber hinaus muss fr die Sicherheit des organisationseigenen Netzes Baustein 6.1
Servergesttztes Netz umgesetzt werden, sowie je nach dem eingesetzten Betriebssystem beispiels-
weise die Bausteine 6.2 Unix-Server oder 6.9 Windows 2000 Server. Falls das Webangebot Inhalte
enthlt, die von einer Webanwendung dynamisch aus einer Datenbank erzeugt werden, ist auch der
Baustein 9.2 Datenbanken zu bercksichtigen. Insbesondere dann, wenn der Webserver aus dem Inter-
net heraus angesprochen werden kann, sollte auch Baustein 3.8 Behandlung von Sicherheitsvorfllen
beachtet werden.
Fr die sichere Anbindung eines Webservers an ffentliche Netze (z. B. das Internet) ist Baustein 7.3
Firewall zu betrachten, ebenso wie fr den Zusammenschluss mehrerer Intranets zu einem bergrei-
fenden Intranet. Die kontrollierte Anbindung externer Anschlusspunkte (z. B. von Telearbeitspltzen
_________________________________________________________________________________________
Webserver 7.5
_________________________________________________________________________________________
via ISDN) wird im Baustein 9.3 Telearbeit behandelt. Ein Webserver sollte in einem separaten Server-
raum aufgestellt werden. Hierbei zu realisierende Manahmen sind in Baustein 4.3.2 Serverraum
beschrieben. Wenn kein Serverraum zur Verfgung steht, kann der Webserver alternativ in einem
Serverschrank aufgestellt werden (vgl. Baustein 4.4 Schutzschrnke). Wird der Webserver nicht bei
der Organisation selbst, sondern bei einem externen Dienstleister betrieben, so muss Baustein 3.10
Outsourcing betrachtet werden.
Fr den erfolgreichen und sicheren Aufbau eines Webservers sind eine Reihe von Manahmen umzu-
setzen. Die Schritte, die dabei durchlaufen werden sollten, sowie die Manahmen, die in den jeweili-
gen Schritten beachtet werden sollten, sind im folgenden aufgefhrt.
1. Planung des Einsatzes (siehe M 2.172 Entwicklung eines Konzeptes fr die WWW-Nutzung) und
Festlegung einer WWW-Sicherheitsstrategie (siehe M 2.173 Festlegung einer WWW-Sicherheits-
strategie):
- Festlegung des Einsatzzwecks des Webservers
- Festlegung der Sicherheitsziele
- Gegebenenfalls Auswahl geeigneter Authentisierungsmechanismen
- Anpassung der Netzstruktur
- Organisatorische Regelungen
2. Einrichtung des Webservers (siehe M 2.175 Aufbau eines WWW-Servers):
- Umsetzung der IT-Grundschutz-Manahmen fr den Serverrechner (siehe z. B. Baustein 6.2
fr Webserver auf Unix-Basis) oder Umsetzung der Manahmen des Bausteins 3.10
Outsourcing, falls der Betrieb des Webservers von einem externen Dienstleister
bernommen wird.
- Gegebenenfalls Nutzung sicherer Kommunikationsverbindungen (siehe M 5.66 Verwendung
von SSL beziehungsweise M 5.64 Secure Shell)
- Vermeidung von Java, ActiveX und anderen aktiven Inhalten im eigenen Webangebot (siehe
auch M 5.69 Schutz vor aktiven Inhalten)
3. Betrieb des Webservers (siehe M 2.174 Sicherer Betrieb eines WWW-Servers):
- regelmige Kontrolle
- Anpassung an nderungen und Tests
- Zugriffsschutz auf WWW-Dateien (M 4.94 Schutz der WWW-Dateien)
- Protokollierung am Webserver
- Notfallvorsorge fr den Webserver (siehe M 6.88 Erstellen eines Notfallplans fr den
Webserver und ergnzend auch Baustein 3.3 Notfallvorsorge-Konzept)
- Datensicherung (siehe Baustein 3.4 Datensicherungskonzept)
4. Sicherer Betrieb von WWW-Clients
Obwohl der sichere Betrieb von WWW-Clients (Arbeitsplatzrechner) nicht direkt zum Thema
Webserver gehrt, sollen an dieser Stelle einige Hinweise zur Sicherheit von Webbrowsern gege-
ben werden. Fr jeden (Client-) Rechner, der mit dem Internet verbunden wird, mssen die ent-
sprechenden Manahmen aus Kapitel 5 umgesetzt werden. Fr den sicheren Zugriff auf das WWW
sind auerdem folgende Manahmen zu beachten:
- Sichere Konfiguration und Nutzung der WWW-Client Software (Webbrowser) (siehe
M 5.45 Sicherheit von WWW-Browsern)
- Schutz vor Viren, Makro-Viren, aktiven Inhalten (siehe M 4.33 Einsatz eines Viren-Suchpro-
gramms bei Datentrgeraustausch und Datenbertragung, M 5.69 Schutz vor aktiven
Inhalten)
_________________________________________________________________________________________
Webserver 7.5
_________________________________________________________________________________________
- Soweit mglich, sollten sichere Kommunikationsverbindungen genutzt werden (siehe

M 5.66 Verwendung von SSL).
Nachfolgend wird das Manahmenbndel fr den Bereich "WWW-Server" vorgestellt. Auf eine Wie-
derholung von Manahmen anderer Kapitel wird hier aus Redundanzgrnden verzichtet.
Organisation:
- M 2.172 (1) Entwicklung eines Konzeptes fr die WWW-Nutzung
- M 2.173 (1) Festlegung einer WWW-Sicherheitsstrategie
- M 2.174 (1) Sicherer Betrieb eines WWW-Servers
- M 2.175 (2) Aufbau eines WWW-Servers
- M 2.176 (2) Geeignete Auswahl eines Internet Service Providers
- M 2.271 (1) Festlegung einer Sicherheitsstrategie fr den WWW-Zugang
- M 2.272 (3) Einrichtung eines WWW-Redaktionsteams (optional)
- M 2.273 (1) Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates
- M 2.298 (z) Verwaltung von Internet-Domainnamen,
Personal:
Hardware/Software:
Datenbertragung
- M 4.64 (1) Verifizieren der zu bertragenden Daten vor Weitergabe / Beseitigung von
Restinformationen
- M 4.94 (1) Schutz der WWW-Dateien
- M 4.95 (1) Minimales Betriebssystem
- M 4.96 (2) Abschaltung von DNS
- M 4.97 (2) Ein Dienst pro Server
- M 4.98 (1) Kommunikation durch Paketfilter auf Minimum beschrnken
- M 4.99 (2) Schutz gegen nachtrgliche Vernderungen von Informationen
- M 4.177 (2) Sicherstellung der Integritt und Authentizitt von Softwarepaketen
Kommunikation:
- M 5.45 (2) Sicherheit von WWW-Browsern
- M 5.64 (2) Secure Shell (optional)
- M 5.66 (2) Verwendung von SSL (optional)
- M 5.69 (1) Schutz vor aktiven Inhalten
Notfallvorsorge:
- M 6.88 (2) Erstellen eines Notfallplans fr den Webserver
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
7.6 Remote Access

Beschreibung
Durch entfernte Zugriffe (Remote Access) wird es einem
Benutzer ermglicht, sich mit einem lokalen Rechner an
ein entferntes Rechnernetz zu verbinden und dessen
Ressourcen zu nutzen, als ob eine direkte LAN-
Koppelung bestehen wrde. Die dafr benutzten Dienste
werden Remote Access Service (RAS) genannt. Durch
RAS wird entfernten Benutzern der Zugriff auf die
Ressourcen des Netzes gewhrt.
Generell lassen sich fr den Einsatz von RAS im Wesentlichen folgende Szenarien unterscheiden:
- das Anbinden einzelner stationrer Arbeitsplatzrechner (z. B. fr Telearbeit einzelner Mitarbeiter),
- das Anbinden mobiler Rechner (z. B. zur Untersttzung von Mitarbeitern im Auendienst oder auf
Dienstreise),
- das Anbinden von ganzen LANs (z. B. zur Anbindung von lokalen Netzen von Auenstellen oder
Filialen),
- der Managementzugriff auf entfernte Rechner (z. B. zur Fernwartung).
Fr diese Szenarien bietet RAS eine einfache Lsung: der entfernte Benutzer verbindet sich z. B. ber
das Telefonnetz mit Hilfe eines Modems mit dem Firmennetz. Diese Direktverbindung kann solange
wie ntig bestehen bleiben und als Standleitung angesehen werden, die nur bei Bedarf geschaltet wird.
Abbildung: Entfernter Zugriff auf Ressourcen

Damit eine RAS Verbindung aufgebaut werden kann, werden in der Regel drei Komponenten
bentigt:
1. ein Rechner mit RAS-Software im Firmennetz, der bereit ist, RAS-Verbindungen
entgegenzunehmen - der so genannte RAS-Server oder Zugangs-Server (engl. Access-Server),
2. ein entfernter Rechner mit RAS-Software, der die RAS-Verbindung initiiert - der so genannte
RAS-Client - und
3. das Kommunikationsmedium, ber das die RAS-Verbindung aufgebaut wird. In den meisten
Szenarien nutzt der RAS-Client ein Telekommunikationsnetz zur Verbindungsaufnahme. Es wird
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
daher mindestens ein Telefonanschluss und ein entsprechendes Modem bentigt. Je nach RAS-
Architektur kommen serverseitig unterschiedliche Anbindungstechniken zum Einsatz.
Der RAS-Dienst ist als Client-Server-Architektur realisiert: Der RAS-Client kann so konfiguriert
werden, dass er die RAS-Verbindung automatisch aufbaut, wenn Ressourcen des Firmennetzes
bentigt werden. Dies geschieht dadurch, dass er die Telefonnummer des Rechners anwhlt, auf dem
die RAS-Server-Software installiert ist. Alternativ kann die RAS-Verbindung auch "von Hand" vom
Benutzer initiiert werden. Einige Betriebssysteme erlauben auch das Aktivieren des RAS-Dienstes
schon bei der Systemanmeldung, beispielsweise Windows NT.
Fr die Verbindungsaufnahme zum entfernten LAN kommen im Wesentlichen zwei Verfahren zum
Einsatz (siehe Manahme M 2.185 Auswahl einer geeigneten RAS-Systemarchitektur):
1. das direkte Anwhlen des Zugangsservers, der in diesem Fall Teil des entfernten LANs ist,
2. das Anwhlen eines Zugangsservers eines Internetdienstanbieters (Internet Service Provider - ISP)
und Zugang zum entfernten LAN ber das Internet.
Unter dem Gesichtspunkt der Sicherheit sind fr RAS-Zugnge folgende Sicherheitsziele zu
unterscheiden:
1. Zugangssicherheit: Der entfernte Benutzer muss durch das RAS-System eindeutig zu identifizieren
sein. Die Identitt des Benutzers muss durch einen Authentisierungsmechanismus bei jedem
Verbindungsaufbau zum lokalen Netz sichergestellt werden. Im Rahmen des Systemzugangs
mssen weitere Kontrollmechanismen angewandt werden, um den Systemzugang fr entfernte
Benutzer reglementieren zu knnen (z. B. zeitliche Beschrnkungen oder Einschrnkung auf
erlaubte entfernte Verbindungspunkte).
2. Zugriffskontrolle: Ist der entfernte Benutzer authentisiert, so muss das System in der Lage sein, die
entfernten Zugriffe des Benutzers auch zu kontrollieren. Dazu mssen die Berechtigungen und
Einschrnkungen, die fr lokale Netzressourcen durch befugte Administratoren festgelegt wurden,
auch fr den entfernten Benutzer durchgesetzt werden.
3. Kommunikationssicherheit: Bei einem entfernten Zugriff auf lokale Ressourcen sollen im
Allgemeinen auch ber die aufgebaute RAS-Verbindung Nutzdaten bertragen werden. Generell
sollen auch fr Daten, die ber RAS-Verbindungen bertragen werden, die im lokalen Netz
geltenden Sicherheitsanforderungen bezglich Kommunikationsabsicherung (Vertraulichkeit,
Integritt, Authentizitt) durchsetzbar sein. Der Absicherung der RAS-Kommunikation kommt
jedoch eine besondere Bedeutung zu, da zur Abwicklung der Kommunikation verschiedene
Kommunikationsmedien in Frage kommen, die in der Regel nicht dem Hoheitsbereich des
Betreibers des lokalen Netzes zuzurechnen sind.
4. Verfgbarkeit: Wird der RAS-Zugang im produktiven Betrieb genutzt, so ist die Verfgbarkeit des
RAS-Zugangs von besonderer Bedeutung. Der reibungslose Ablauf von Geschftsprozessen kann
bei Totalausfall des RAS-Zugangs oder bei Verbindungen mit nicht ausreichender Bandbreite unter
Umstnden beeintrchtigt werden. Durch die Nutzung von alternativen oder redundanten RAS-
Zugngen kann diese Gefahr bis zu einem gewissen Grad verringert werden. Dies gilt insbesondere
fr RAS-Zugnge, die das Internet als Kommunikationsmedium nutzen, da hier in der Regel keine
Verbindungs- oder Bandbreitengarantien gegeben werden.
Gefhrdungslage
Durch die Client-Server-Architektur von RAS-Systemen ergeben sich fr RAS-Client und RAS-
Server jeweils spezifische Gefahren durch die Art des Einsatzumfeldes und die Nutzungsweise.
- RAS-Clients knnen stationr (heimischer PC), aber auch mobil (Laptop) verwendet werden. In der
Regel unterliegt der Client-Standort jedoch nicht der Kontrolle des LAN-Betreibers, so dass
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
insbesondere fr den mobilen Einsatz von einem unsicheren Umfeld mit spezifischen
Gefhrdungen ausgegangen werden muss. Hier mssen insbesondere auch physische Gefahren
(Diebstahl, Beschdigung, usw.) in Betracht gezogen werden. Hierzu knnen auch die Kapitel 4.5
Huslicher Arbeitsplatz, Kapitel 5.3 Tragbarer PC und Kapitel 9.3 Telearbeit betrachtet werden.
RAS-Server sind in der Regel Teil des LANs, mit dem sich entfernte Benutzer verbinden wollen.
Sie sind im Hoheits- und Kontrollbereich des LAN-Betreibers angesiedelt und knnen damit durch
die lokal geltenden Sicherheitsvorschriften erfasst werden. Da die Hauptaufgabe des RAS-Servers
darin besteht, nur berechtigten Benutzern den Zugriff auf das angeschlossene LAN zu gewhren,
sind die Gefahren fr RAS-Server eher im Bereich von Angriffen zu sehen, die den unberechtigten
Zugang zum LAN zum Ziel haben.
Von einer vollstndig getrennten Betrachtung der Client- und Server-seitigen Gefhrdungen soll an
dieser Stelle abgesehen werden, da sich z. B. durch die Gefahr der Kompromittierung eines RAS-
Clients automatisch eine Gefhrdung fr den RAS-Server ergibt. Ferner ist zu bedenken, dass sich
z. B. im Windows-Umfeld jeder RAS-Client auch als RAS-Server betreiben lsst, so dass sich hier die
Gefhrdungen kumulieren.
Fr den IT-Grundschutz eines RAS-Systems werden die folgenden typischen Gefhrdungen
angenommen:
Hhere Gewalt
- G 2.44 Inkompatible aktive und passive Netzkomponenten
- G 2.49 Fehlende oder unzureichende Schulung der Telearbeiter
- G 2.64 Fehlende Regelungen fr das RAS-System
- G 3.30 Unerlaubte private Nutzung des dienstlichen Telearbeitsrechners
- G 3.39 Fehlerhafte Administration des RAS-Systems
- G 3.40 Ungeeignete Nutzung von Authentisierungsdiensten bei Remote Access
- G 3.41 Fehlverhalten bei der Nutzung von RAS-Diensten
- G 3.42 Unsichere Konfiguration der RAS-Clients
- G 3.43 Ungeeigneter Umgang mit Passwrtern
- G 4.40 Ungeeignete Ausrstung der Betriebsumgebung des RAS-Clients
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
- G 5.91 Abschalten von Sicherheitsmechanismen fr den RAS-Zugang

- G 5.92 Nutzung des RAS-Clients als RAS-Server
- G 5.93 Erlauben von Fremdnutzung von RAS-Komponenten
Ein RAS-System besteht aus mehreren Komponenten, die zunchst als Einzelkomponenten
abgesichert werden sollten. Jenseits der RAS-Funktionalitt sind diese als normale IT-Systeme oder
Netzkoppelelemente anzusehen und sollten gem der Manahmenvorschlge aus den entsprechenden
Bausteinen abgesichert werden. RAS-Server sind Rechner, die sich blicherweise im Hoheitsgebiet
eines Unternehmens oder einer Behrde befinden, und nehmen die wichtige Aufgabe wahr, den
Zugriff auf das interne Netz zu kontrollieren. Die RAS-Funktionalitt ist in der Regel auf einem
Betriebssystem aufgesetzt, das in den meisten Fllen weitere Dienste anbietet. Daher hngt die
Sicherheit des RAS-Zuganges auch davon ab, dass auch auf Betriebssystem- und Dienstebene keine
Sicherheitslcken existieren.
Zustzlich zu der Absicherung der RAS-Systemkomponenten muss jedoch auch ein RAS-
Sicherheitskonzept erstellt werden, das sich in das bestehende Sicherheitskonzept eingliedert: das
RAS-System muss einerseits bestehende Sicherheitsforderungen umsetzen und erfordert andererseits
das Aufstellen neuer, RAS-spezifischer Sicherheitsregeln.
Ein RAS-System wird in der Regel im Umfeld anderer Systeme eingesetzt, die dazu dienen, den
Zugriff auf das interne Netz von auen zu kontrollieren. Hier sind z. B. Firewall-Systeme oder
Systeme zur Fernwartung zu nennen, mit denen ein RAS-System im Verbund zusammenarbeiten
muss. Aus diesem Grund sind bei der Durchfhrung der RAS-spezifischen Manahmen auch die
Manahmen aus den jeweiligen Bausteinen der betroffenen Systeme zu bercksichtigen. Zu nennen
sind u. a. die Bausteine:
- 4.5 Huslicher Arbeitsplatz
- 7.3 Firewall
- 8.1 TK-Anlage
- 9.3 Telearbeit
Fr den sicheren Aufbau eines RAS-Zuganges sind eine Reihe von Manahmen umzusetzen,
beginnend mit der Konzeption ber die Beschaffung bis zum Betrieb. Die Schritte, die dabei zu
durchlaufen sind, sowie die Manahmen, die in den jeweiligen Schritten beachtet werden sollten, sind
im Folgenden aufgefhrt.
1. Begonnen wird mit dem Erstellen eines RAS-Konzeptes, das auf den
Sicherheitsanforderungen fr die bereits vorhandenen IT-Systeme sowie den Anforderungen
aus den geplanten Einsatzszenarien fr Remote Access beruht.
1.1 Um das Konzept individuell zuschneiden zu knnen, mssen zunchst die Anforderungen
festgestellt werden. Dazu ist eine Anforderungsanalyse (siehe M 2.183 Durchfhrung einer
RAS-Anforderungsanalyse) durchzufhren.
1.2 Aufgrund der festgestellten Anforderungen kann dann die Definition eines RAS-Konzeptes
(siehe M 2.184 Entwicklung eines RAS-Konzeptes) erfolgen.
1.3 Zur Umsetzung des Konzeptes ist eine RAS-Systemarchitektur zu definieren (siehe M 2.185
Auswahl einer geeigneten RAS-Systemarchitektur), die auf die Anforderungen des RAS-
Einsatzes und das umzusetzende Konzept abgestimmt ist.
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
2. Die Beschaffung des RAS-Systems erfordert, die aus dem RAS-Konzept resultierenden
Anforderungen an das RAS-Produkt zu formulieren und basierend darauf die Auswahl eines
geeigneten RAS-Produktes zu treffen (s. M 2.186 Geeignete Auswahl eines RAS-Produktes).
3. Die sicherheitsrelevanten Manahmen fr die Umsetzung des RAS-Konzepts untergliedern
sich in die Bereiche:
3.1 Definition der Sicherheitsrichtlinie fr den RAS-Einsatz (siehe M 2.187 Festlegen einer
RAS-Sicherheitsrichtlinie),
3.2 Installation und erste Konfiguration (siehe M 4.110 Sichere Installation des RAS-Systems
und M 4.111 Sichere Konfiguration des RAS-Systems) und
3.3 den laufenden Betrieb des RAS-Systems (siehe M 4.112 Sicherer Betrieb des RAS-Systems,).
Typischerweise muss fr RAS-Systeme immer eine Betrachtung von RAS-Servern und
RAS-Clients erfolgen. Da die Benutzer eines RAS-Systems wesentlich zu dessen sicheren
Betrieb beitragen, mssen sie auf die Nutzung des RAS-Zugangs vorbereitet werden und den
Umgang mit der RAS-Software erlernen. Hier muss insbesondere auf die Gefahren aufmerk-
sam gemacht werden, die sich bei der Nutzung des RAS-Zugangs von zu Hause oder von
unterwegs ergeben (siehe M 3.4 Schulung vor Programmnutzung und M 3.5 Schulung zu IT-
Sicherheitsmanahmen).
Zur Absicherung von RAS-Verbindungen werden in vielen Fllen so genannte Tunnel-
Protokolle eingesetzt. Diese erlauben es, aufbauend auf einer bestehenden Verbindung einen
durch Zugriffskontrolle und Verschlsselung abgeschotteten Kommunikationskanal
zwischen IT-Systemen oder Netzen herzustellen. Aufgrund dieser Abschottung gegen die
Auenwelt wird hier auch hufig von Virtuellen Privaten Netzen (VPN) gesprochen (siehe
M 5.76 Einsatz geeigneter Tunnel-Protokolle fr die RAS-Kommunikation).
Nachfolgend wird das Manahmenbndel fr den Baustein "Remote Access" vorgestellt.
Infrastruktur:
Organisation:
- M 2.183 (1) Durchfhrung einer RAS-Anforderungsanalyse
- M 2.184 (1) Entwicklung eines RAS-Konzeptes
- M 2.185 (1) Auswahl einer geeigneten RAS-Systemarchitektur
- M 2.186 (1) Geeignete Auswahl eines RAS-Produktes
- M 2.187 (1) Festlegen einer RAS-Sicherheitsrichtlinie
- M 2.205 (1) bertragung und Abruf personenbezogener Daten
Personal:
- M 4.110 (1) Sichere Installation des RAS-Systems
- M 4.111 (1) Sichere Konfiguration des RAS-Systems
- M 4.112 (1) Sicherer Betrieb des RAS-Systems
- M 4.113 (2) Nutzung eines Authentisierungsservers beim RAS-Einsatz
_________________________________________________________________________________________
Remote Access 7.6
_________________________________________________________________________________________
Kommunikation:
- M 5.76 (2) Einsatz geeigneter Tunnel-Protokolle fr die RAS-Kommunikation
Notfallvorsorge:
- M 6.70 (2) Erstellen eines Notfallplans fr den Ausfall des RAS-Systems
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________
7.7 Lotus Notes

Beschreibung
Lotus Notes ist ein Produkt im Bereich der Workgroup-
Untersttzung. Es bietet die Mglichkeit, die in einem
Unternehmen anfallenden Broarbeitsablufe zu unter-
sttzen und zu organisieren. Die gesamte dazu ntige
Kommunikation, Datenbertragung und Datenhaltung
kann ber Lotus Notes abgewickelt werden. Dem Notes
Konzept liegt eine Client-Server-Architektur zugrunde:
Benutzer verwenden den Notes-Client oder einen
Browser, um sich mit dem Domino Server zu verbinden
und zu arbeiten.
In frheren Versionen von Lotus Domino/Notes wurden proprietre Kommunikationsprotokolle ver-
wendet. Demgegenber sind in die aktuelle Version (derzeit 5.0.5) standardisierte Internet-Protokolle
integriert. Durch die ffnung in Richtung Internet (erstmals mit Version 4.5) ist es mglich, auch von
einem beliebigen Browser ber das Internet Zugriff auf die Daten eines Lotus Domino Servers zu
haben. Dabei ist nicht nur der lesende Zugriff, sondern auch der schreibende und administrative
Zugriff auf den Server mglich. Aus Sicherheitssicht ist mit dem Release-Wechsel von Version 5.0.3
auf die Version 5.0.4 die wichtigste Vernderung verbunden: durch die Vernderung der US-Export-
Politik wurde die Version 5.0.4 als "Global-Version" zur Verfgung gestellt, die generell starke
Verschlsselungsmechanismen enthlt, so dass nun keine getrennten Versionen mehr fr den nord-
amerikanischen Markt und den internationalen Markt existieren.
Nachfolgend sind die derzeit (Stand 11/2000) aktuellen Produktbezeichnungen der Lotus
Domino/Notes-Komponenten kurz zusammengefasst, da Lotus die betreffenden Komponenten im
Verlauf der vergangenen Release-Wechsel teilweise umbenannt hat. In den nachfolgenden Gefhr-
dungs- und Manahmenbeschreibungen werden die Namen Lotus Domino Server und Lotus Notes
Server synonym verwendet.
Server-Produkte:
- Domino Application Server: Dies ist der eigentliche Nachfolger des ursprnglichen Lotus Notes
Servers. Der Application Server ist modular aufgebaut und bietet neben den Komponenten fr den
Datenbankzugriff auch weitere Module - u. a. ein SMTP-Server-Modul, ein HTTP-Server-Modul
und ein LDAP-Server-Modul - an.
- Domino Mail Server: Die E-Mail-Funktionalitt ist ein Bestandteil des Domino Application
Servers. Durch diese Konfigurationsvariante ist die Funktion eines E-Mail-Servers auch unab-
hngig von den restlichen Server-Modulen verfgbar.
- Domino Enterprise Server: Diese Erweiterung des Domino Application Servers hie zuvor
Domino Advanced Services. Bestandteil dieser Erweiterung sind Funktionen fr Hochverfgbar-
keit, Partitionierung (Partitioning), Serververbnde (Clustering) und Abrechnungsinformationen
(Billing).
- Lotus QuickPlace: QuickPlace ist eine spezielle Konfigurationsvariante, die auf das schnelle und
problemlose Einrichten eines Web-basierten Team-Arbeitsplatzes zugeschnitten ist. QuickPlace ist
Bestandteil des Domino Application Servers und des Domino Enterprise Servers.
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________
Client-Produkte:
- Notes Client: Dies ist der "klassische" Client fr den Zugriff auf den Domino/Notes Server sowie
zur Bearbeitung von E-Mail, Terminen, Kontakten und vielem mehr. Der Notes Client enthlt auch
eine Browser-Komponente, mit der Web-Inhalte angezeigt werden knnen, die auf Grund der
Client-Anfrage durch den "Web-Retriever" vom jeweiligen Web-Server geladen und an den Client
weitergereicht werden.
- Domino Administrator Client: Der Domino Administrator Client ist kein eigenstndiger Client,
sondern ist als optionaler Bestandteil in Domino Server R5 und in Domino Designer R5 enthalten.
Der Domino Administrator Client ist zentrales Werkzeug fr die Sicherheitsadministration des
Domino Servers.
- Domino Designer: Domino Designer ist ein Entwicklungswerkzeug zur Erstellung von Web-
Anwendungen. Domino-Applikationen knnen hierbei unter Verwendung von Java, JavaScript,
HTML4, C++, CORBA/IIOP, OLE und LotusScript erstellt werden.
Unter dem Gesichtspunkt der Sicherheit sind fr Lotus Notes Aspekte aus den folgenden Kategorien
zu unterscheiden:
1. Zugangssicherheit: Die auf einem Notes-Server gehaltenen Daten drfen nur berechtigten Benut-
zern zugnglich gemacht werden. Dazu wird vom Notes-Server eine Zugangskontrolle zum Server
selbst bereitgestellt. Dadurch kann gesteuert werden, welche Benutzer prinzipiell auf welchen
Notes-Server zugreifen drfen.
2. Zugriffskontrolle: Neben der Kontrolle des Serverzugriffs stellt die Zugriffskontrolle auf Daten-
bankebene einen wichtigen Sicherheitsmechanismus zur Verfgung. Durch die von Lotus Notes
bereitgestellten Methoden ist eine detaillierte Kontrolle mglich, welche Benutzer (oder welche
Benutzergruppen) welche Aktionen auf einer bestimmten Datenbank ausfhren drfen.
3. Kommunikationssicherheit: Wenn ein Client auf eine Datenbank auf einem Server zugreift, werden
die abgerufenen Daten ber eine Netzverbindung bertragen. Um die Vertraulichkeit und Integritt
der Daten zu sichern, stellt Lotus Notes Verschlsselungsverfahren zur Verfgung.
4. Verfgbarkeit: Wird ein Notes-System fr Unternehmensbereiche als Brokommunikations-
medium eingesetzt, so mssen auch Anforderungen an die Verfgbarkeit gestellt werden. Dies
betrifft zum einen die Schadensminderung bei Ausfall durch redundante Datenhaltung oder physi-
kalische Redundanz von Rechnern und zum anderen das Erstellen eines Notfallvorsorgeplanes, der
bei einem Ausfall Anleitungen und Hinweise fr eine schnelle Wiederherstellung des Systems gibt.
Gefhrdungslage
Fr den IT-Grundschutz eines Notes-Systems werden die folgenden typischen Gefhrdungen ange-
nommen:
Hhere Gewalt
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________

- G 2.40 Komplexitt des Datenbankzugangs/-zugriffs
- G 3.46 Fehlkonfiguration eines Lotus Notes Servers
- G 3.47 Fehlkonfiguration des Browser-Zugriffs auf Lotus Notes
- G 4.26 Ausfall einer Datenbank
- G 4.28 Verlust von Daten einer Datenbank
- G 5.100 Missbrauch aktiver Inhalte beim Zugriff auf Lotus Notes
- G 5.101 "Hacking Lotus Notes"
Zustzlich zu der Absicherung der Lotus Notes-Komponenten muss jedoch auch ein spezifisches
Sicherheitskonzept erstellt werden, das sich in das bestehende Sicherheitskonzept eingliedert: das
Notes-System muss einerseits bestehende Sicherheitsanforderungen umsetzen und erfordert anderer-
seits das Aufstellen neuer, Notes-spezifischer Sicherheitsregeln.
Ein Notes-System wird in der Regel im Umfeld anderer Systeme eingesetzt, die dazu dienen, den
Zugriff auf das interne Netz von auen zu kontrollieren. Hier sind z. B. Firewall-Systeme oder
Systeme zur Fernwartung zu nennen, mit denen ein Notes-System im Verbund zusammenarbeiten
muss. Aus diesem Grund sind bei der Durchfhrung der Notes-spezifischen Manahmen auch die
Manahmen aus den jeweiligen Bausteinen der betroffenen Systeme zu bercksichtigen. Neben den
entsprechenden Bausteinen aus den Kapiteln 5 und 6 sind u. a. auch die folgenden Bausteine zu
nennen:
- 7.3 Firewall, wenn Notes-Systeme in einer Firewall-Umgebung eingesetzt werden (siehe auch
M 2.211 Planung des Einsatzes von Lotus Notes in einer DMZ).
- 7.6 Remote Access, wenn der Zugriff auf das Notes-System ber Einwahl-Leitungen erfolgt.
Die im Baustein 9.2 Datenbanken aufgefhrten Manahmen sind im Kontext von Lotus Notes nur
bedingt anwendbar, da Notes ein proprietres Datenbanksystem darstellt.
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________
Fr den erfolgreichen Aufbau eines Notes-Systems sind eine Reihe von Manahmen umzusetzen,
beginnend mit der Konzeption ber die Installation bis zum Betrieb. Die Schritte, die dabei zu durch-
laufen sind, sowie die Manahmen, die in den jeweiligen Schritten beachtet werden sollten, sind im
folgenden aufgefhrt.
1. Nach der Entscheidung, Lotus Notes als internes Kommunikationssystem einzusetzen, muss die
Beschaffung der Software und eventuell zustzlich bentigter Hardware erfolgen. Da Lotus Notes
in verschiedenen Konfigurationsvarianten angeboten wird (siehe oben), hngt die zu beschaffende
Software auch von den geplanten Einsatzszenarien ab. Daher sind folgende Manahmen durchzu-
fhren:
- Zunchst muss der Einsatz fr das Notes System geplant werden (siehe Manahme M 2.206
Planung des Einsatzes von Lotus Notes).
- Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe Manahme M 2.207 Festlegen
einer Sicherheitsrichtlinie fr Lotus Notes), die einerseits die bereits bestehenden
Sicherheitsrichtlinien im Kontext von Lotus Notes umsetzt und andererseits Notes-
spezifische Erweiterungen definiert.
- Vor der tatschlichen Einfhrung des Notes-Systems mssen die Benutzer und
Administratoren auf den Umgang mit Lotus Notes durch eine Schulung vorbereitet werden.
Insbesondere fr Administratoren empfiehlt sich aufgrund der Komplexitt der Verwaltung
eines Notes-Systems eine intensive Schulung. Die Administratoren sollen dabei detaillierte
Systemkenntnisse erwerben (siehe M 3.24 Schulung zur Lotus Notes Systemarchitektur fr
Administratoren), so dass eine konsistente und korrekte Systemverwaltung gewhrleistet ist.
Benutzern sollte die Nutzung der Sicherheitsmechanismen von Lotus Notes vermittelt
werden (siehe M 3.25 Schulung zu Lotus Notes Sicherheitsmechanismen fr Benutzer).
Installation des Notes-Systems erfolgen. Dabei sind folgenden Manahmen zu beachten:
- Die Installation kann erst dann als abgeschlossen betrachtet werden, wenn die Lotus Notes
Systeme in einen sicheren Zustand gebracht wurden (siehe M 4.116 Sichere Installation von
Lotus Notes). Dadurch wird sichergestellt, dass in der folgenden Konfigurationsphase nur
berechtigte Administratoren auf das Notes System zugreifen knnen.
- Nach der "Rohinstallation" erfolgt eine erstmalige Konfiguration des Notes-Systems, das aus
den Servern (siehe M 4.117 Sichere Konfiguration eines Lotus Notes Servers) und den
Clients (siehe M 4.126 Sichere Konfiguration eines Lotus Notes Clients und M 4.127
Sichere Browser-Konfiguration fr den Zugriff auf Lotus Notes ) besteht.
- Ein Notes-System ist in der Regel stndigen Vernderungen unterworfen. Daher mssen
sicherheitsrelevante Konfigurationsparameter kontinuierlich angepasst werden. Daneben
hngt die Sicherheit in einem Client-Server-basierten System auch von der Sicherheit aller
Teilsysteme - hier auch insbesondere der Clients - ab. Die fr den sicheren Betrieb
relevanten Manahmen sind in M 4.128 Sicherer Betrieb von Lotus Notes und den
Manahmen zur Kommunikationsabsicherung (siehe M 5.84 Einsatz von
Verschlsselungsverfahren fr die Lotus Notes Kommunikation, M 5.85 Einsatz von
Verschlsselungsverfahren fr Lotus Notes E-Mail und M 5.86 Einsatz von
Verschlsselungsverfahren beim Browser-Zugriff auf Lotus Notes) zusammengefasst.
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________
Notfallvorsorge finden sich in M 6.73 Erstellen eines Notfallplans fr den Ausfall des Lotus
Notes-Systems.
Nachfolgend wird nun das Manahmenbndel fr den Baustein "Lotus Notes" vorgestellt.
Infrastruktur:
- M 1.29 (1) Geeignete Aufstellung eines IT-Systems (Server)
Organisation:
- M 2.206 (1) Planung des Einsatzes von Lotus Notes
- M 2.207 (1) Festlegen einer Sicherheitsrichtlinie fr Lotus Notes
- M 2.208 (1) Planung der Domnen und der Zertifikatshierarchie von Lotus Notes
- M 2.209 (1) Planung des Einsatzes von Lotus Notes im Intranet
- M 2.210 (2) Planung des Einsatzes von Lotus Notes im Intranet mit Browser-Zugriff
- M 2.211 (2) Planung des Einsatzes von Lotus Notes in einer DMZ
Personal:
- M 3.24 (1) Schulung zur Lotus Notes Systemarchitektur fr Administratoren
- M 3.25 (1) Schulung zu Lotus Notes Sicherheitsmechanismen fr Benutzer
- M 4.116 (1) Sichere Installation von Lotus Notes
- M 4.117 (1) Sichere Konfiguration eines Lotus Notes Servers
- M 4.118 (1) Konfiguration als Lotus Notes Server
- M 4.119 (1) Einrichten von Zugangsbeschrnkungen auf Lotus Notes Server
- M 4.120 (1) Konfiguration von Zugriffslisten auf Lotus Notes Datenbanken
- M 4.121 (1) Konfiguration der Zugriffsrechte auf das Namens- und Adressbuch von Lotus
Notes
- M 4.122 (2) Konfiguration fr den Browser-Zugriff auf Lotus Notes
- M 4.123 (2) Einrichten des SSL-geschtzten Browser-Zugriffs auf Lotus Notes
- M 4.124 (2) Konfiguration der Authentisierungsmechanismen beim Browser-Zugriff auf Lotus
Notes
- M 4.125 (2) Einrichten von Zugriffsbeschrnkungen beim Browser-Zugriff auf Lotus Notes
Datenbanken
- M 4.126 (1) Sichere Konfiguration eines Lotus Notes Clients
- M 4.127 (2) Sichere Browser-Konfiguration fr den Zugriff auf Lotus Notes
- M 4.128 (1) Sicherer Betrieb von Lotus Notes
- M 4.129 (1) Sicherer Umgang mit Notes-ID-Dateien
- M 4.130 (1) Sicherheitsmanahmen nach dem Anlegen neuer Lotus Notes Datenbanken
- M 4.131 (2) Verschlsselung von Lotus Notes Datenbanken (optional)
- M 4.132 (1) berwachen eines Lotus Notes-Systems
_________________________________________________________________________________________
Lotus Notes 7.7
_________________________________________________________________________________________
Kommunikation:
- M 5.68 (2) Einsatz von Verschlsselungsverfahren zur Netzkommunikation (optional)
- M 5.84 (2) Einsatz von Verschlsselungsverfahren fr die Lotus Notes Kommunikation
(optional)
- M 5.85 (2) Einsatz von Verschlsselungsverfahren fr Lotus Notes E-Mail (optional)
- M 5.86 (1) Einsatz von Verschlsselungsverfahren beim Browser-Zugriff auf Lotus Notes
Notfallvorsorge:
- M 6.49 (1) Datensicherung einer Datenbank
- M 6.73 (1) Erstellen eines Notfallplans fr den Ausfall des Lotus Notes-Systems
_________________________________________________________________________________________
Internet Information Server 7.8
_________________________________________________________________________________________

Beschreibung
Der Microsoft Internet Information Server (IIS) stellt die
Internet Informationsdienste (WWW-Server, FTP-Server,
NNTP-Dienst und SMTP-Dienst) fr die Microsoft
Betriebssysteme zur Verfgung.
Standardmig wird der IIS mit den Serverversionen von
Windows NT 4.0 (IIS 4), Windows 2000 (IIS 5), Win-
dows XP Professional (IIS 5.1) und Windows Server
2003 (IIS 6) ausgeliefert.
In diesem Kapitel werden spezifische Gefhrdungen und
Manahmen fr einen Webserver basierend auf dem IIS 4 oder IIS 5 beschrieben. Fr Webserver, die
auf einer neueren Version des IIS basieren, knnen die detaillierten technischen Manahmen dieses
Kapitels mglicherweise nicht direkt angewandt werden. Zumindest die allgemeineren Manahmen
sollten jedoch in jedem Fall umgesetzt werden.
Internet Information Server 4.0 (IIS 4 )
Viele Windows NT Versionen beinhalten noch eine ltere Version des IIS, meist die Version 2.0.
Aufgrund vorhandener Sicherheitsrisiken sollten solche lteren Versionen jedoch nicht mehr einge-
setzt werden. Das bedeutet, dass der IIS 4 neu zu installieren ist. Es sollte kein Update von einem
installierten IIS 2.0 auf den IIS 4 stattfinden.
Der IIS 4 ist Bestandteil des Windows NT 4.0 Server Option Packs, das eine Reihe von zustzlichen
Dienstprogrammen und Anwendungen enthlt, die mit dem IIS 4 zusammenarbeiten. Als typische
Microsoft-Anwendung ist der IIS 4 eng mit den Ressourcen des Betriebssystems verzahnt. Der IIS 4
verwendet die Verzeichnisdatenbank von Windows NT, d. h. die Benutzerkonten werden mit Hilfe des
Windows NT-Benutzermanagers verwaltet. Auerdem werden vorhandene Windows-NT-Dienst-
programme, wie der Systemmonitor, die Ereignisanzeige und die SNMP-Untersttzung, zur Verwal-
tung des Webservers genutzt.
Internet Information Server 5.0 (IIS 5.0)
Mit dem Betriebssystem Windows 2000 werden die Internet Informationsdienste durch den IIS 5.0
bereitgestellt. Der IIS 5.0 ist vollstndig in das Betriebssystem integriert und wird standardmig mit
installiert.
Im Vergleich zum IIS 4 enthlt die Version 5.0 eine Reihe von neuen Funktionen und Verbesserun-
gen. Beispielsweise wird die MMC-Technologie (Microsoft Management Console) durch die Integra-
tion in Windows 2000 vollstndig untersttzt und die Verwaltung des Servers durch neue Sicherheits-
assistenten, frei zu definierende Fehlermeldungen (fr HTTP) und losgelste Serverprozesse (Start der
Internet Informationsdienste ohne Neustart des Computers) vereinfacht. Daneben wurden die ASP-
Merkmale durch zustzliche Methoden ergnzt und die Protokollierungsfunktionen, insbesondere im
Bereich Performance und Auslastung, erweitert.
Nach einer Installation der Betriebssysteme Windows 2000 Datacenter Server, Windows 2000
Advanced Server und Windows 2000 Server ist der IIS 5 standardmig aktiviert. Nach einer Instal-
lation von Windows 2000 Professional ist der IIS 5 standardmig nicht aktiviert.
_________________________________________________________________________________________
_________________________________________________________________________________________
Internet Information Server 5.1 (IIS 5.1)

Der IIS 5.1 wird mit dem Betriebssystem Windows XP Professional ausgeliefert. Nach einer Installa-
tion von Windows XP Professional ist der IIS 5.1 standardmig nicht aktiviert.
Internet Information Server 6.0 (IIS 6)
Der IIS 6 wird mit dem Betriebssystem Windows Server 2003 ausgeliefert. Gegenber den Vor-
gngerversionen wurde diese Version grundlegend berarbeitet und weitgehend neu entwickelt.
Gefhrdungslage
Generell hngt die Gefhrdungslage Einsatzszenario ab. Webserver werden fr vielfltige Aufgaben
eingesetzt, beispielsweise als einfache Informationsserver im Internet oder Intranet, auf die nur lesend
zugegriffen werden darf, aber auch als Basis fr weiterfhrende Anwendungen, z. B. E-Commerce
oder E-Government-Anwendungen, die auf Datenbanken zugreifen oder als Entwicklungsserver fr
neue Applikationen.
Wird der IIS als Internet-Server eingesetzt, zeigt sich eine besondere Gefhrdungslage. In diesem Fall
ist der Zugriff Externer und Unbekannter auf den Server erwnscht, dabei mssen aber die Verfg-
barkeit des Servers, die Integritt der Daten und auch die Vertraulichkeit von Konfigurationsdateien
und vorhandenen Skripten gewhrleistet sein. Nur durch die Kombination von bergeordneten, orga-
nisatorischen Manahmen mit technischen Sicherheitsvorkehrungen, wie geeigneten Trenneinrich-
tungen und der sicheren Konfiguration des Betriebssystems sowie der eigentlichen Internetdienste,
kann diese Anforderung erfllt werden.
Allerdings darf nicht nur die Mglichkeit eines Angriffs von auen betrachtet werden, denn auch
innerhalb eines LANs ist ein Angriff auf einen IIS denkbar. Wie jedes vernetzte IT-System ist auch ein
Webserver mit IIS vielfltigen Gefahren ausgesetzt, so dass der sicheren Konfiguration des Systems
und seiner Komponenten auch im internen Netz eine wichtige Rolle zukommt.
Fr den IT-Grundschutz eines IIS-basierenden Webservers werden die folgenden typischen Gefhr-
dungen angenommen:
- G 2.87 Verwendung unsicherer Protokolle in ffentlichen Netzen
- G 2.94 Unzureichende Planung des IIS-Einsatzes
- G 3.56 Fehlerhafte Einbindung des IIS in die Systemumgebung
- G 3.57 Fehlerhafte Konfiguration des Betriebssystems fr den IIS
- G 3.58 Fehlkonfiguration eines IIS
- G 3.59 Unzureichende Kenntnisse ber aktuelle Sicherheitslcken und Prfwerkzeuge fr
den IIS
_________________________________________________________________________________________
_________________________________________________________________________________________

- G 5.108 Ausnutzen von systemspezifischen Schwachstellen des IIS
Zur Realisierung des IT-Grundschutzes eines Webservers basierend auf dem IIS 4 oder IIS 5 wird
empfohlen, die notwendigen Manahmenbndel ("Bausteine") wie in Kapitel 2.3 und 2.4 beschrieben
auszuwhlen.
Da in einer Einsatzumgebung von vernetzten Systemen der IIS nicht alleine betrachtet werden darf,
sind darber hinaus folgende Kapitel zu bercksichtigen:
Kapitel 6.1 Servergesttztes Netz,
Kapitel 7.3 Firewall (bei der Anbindung an Netze mit anderem Schutzbedarf),
Kapitel 7.5 Webserver,
Kapitel 6.4 Windows NT Netz (bei der Verwendung von IIS 4.0)
Kapitel 6.9 Windows 2000 Server (bei der Verwendung von IIS 5.0)
Je nachdem, wie die Administration und Pflege des IIS-Systems erfolgen, sollten gegebenenfalls auch
die Kapitel 7.6 Remote Access und 9.3 Telearbeit fr die Anbindung externer Anschlusspunkte
herangezogen werden.
Fr den erfolgreichen Aufbau und Betrieb eines Internet Information Servers sind in den einzelnen
Realisierungsphasen (Konzeption, Implementation und Betrieb) eine Reihe von Manahmen umzuset-
zen. Die Realisierungsschritte, die dabei durchlaufen werden, sowie die Manahmen, die in den je-
weiligen Schritten zu beachten sind, werden nachfolgend aufgefhrt. Teilweise stellen diese Ma-
nahmen "Spezialisierungen" von Manahmen aus einem der oben genannten Bausteine dar.
1. Nach der Entscheidung, einen IIS als Webserver einzusetzen, muss die Beschaffung der Software
und eventuell zustzlich bentigter Hardware erfolgen. Die zu beschaffende Soft- und Hardware ist
abhngig von den geplanten Einsatzszenarien. Daher sind folgende Manahmen durchzufhren:
- Zunchst muss der Einsatz des IIS-Systems geplant werden (siehe M 2.267 Planen des IIS-
Einsatzes).
- Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe M 2.268 Festlegung einer IIS-
Sicherheitsrichtlinie), in der die bestehenden Sicherheitsrichtlinien fr den IIS angewandt
und spezialisiert werden.
- Vor der tatschlichen Einfhrung des IIS-Systems mssen die Administratoren auf den
Umgang mit dem IIS durch eine Schulung vorbereitet werden. Insbesondere fr
Administratoren empfiehlt sich aufgrund der Komplexitt der Verwaltung eine intensive
Schulung. Die Administratoren sollen dabei detaillierte Systemkenntnisse erwerben (siehe
M 3.36 Schulung der Administratoren zur sicheren Installation und Konfiguration des IIS),
so dass eine konsistente und korrekte Systemverwaltung gewhrleistet ist.
Installation des Webservers erfolgen. Dabei sind folgenden Manahmen zu beachten:
- Die Installation kann erst dann als abgeschlossen betrachtet werden, wenn die IIS-Systeme in
einen sicheren Zustand gebracht wurden. Basis fr die sichere Installation des IIS ist ein
_________________________________________________________________________________________
_________________________________________________________________________________________
abgesichertes Betriebssystem (siehe M 4.174 Vorbereitung der Installation von Windows

NT/2000 fr den IIS und M 4.175 Sichere Konfiguration von Windows NT/2000 fr den IIS).
Es muss sichergestellt werden, dass in der folgenden Konfigurationsphase nur berechtigte
Administratoren auf das IIS-System zugreifen knnen.
- Nach der "Rohinstallation" erfolgt eine erstmalige Konfiguration des IIS-Systems. Bei der
Konfiguration sind die relevanten Manahmen aus den Bereichen Hardware / Software und
Kommunikation zu bercksichtigen.
- Ein IIS ist in der Regel stndigen Vernderungen unterworfen. Daher mssen sicher-
heitsrelevante Konfigurationsparameter kontinuierlich angepasst werden. Die fr den
sicheren Betrieb relevanten Sicherheitseinstellungen sind in den Manahmen zur Hardware /
Software und Kommunikation zusammengefasst.
Notfallvorsorge finden sich in M 6.85 Erstellung eines Notfallplans fr den Ausfall des IIS.
Nachfolgend wird nun das Manahmenbndel fr den Baustein IIS vorgestellt.
Organisation:
- M 2.267 (1) Planen des IIS-Einsatzes
- M 2.268 (1) Festlegung einer IIS-Sicherheitsrichtlinie
Personal:
- M 3.36 (1) Schulung der Administratoren zur sicheren Installation und Konfiguration des IIS
- M 4.174 (1) Vorbereitung der Installation von Windows NT/2000 fr den IIS
- M 4.175 (1) Sichere Konfiguration von Windows NT/2000 fr den IIS
- M 4.178 (1) Absicherung der Administrator- und Benutzerkonten beim IIS-Einsatz
- M 4.179 (1) Schutz von sicherheitskritischen Dateien beim IIS-Einsatz
- M 4.180 (2) Konfiguration der Authentisierungsmechanismen fr den Zugriff auf den IIS
- M 4.181 (1) Ausfhren des IIS in einem separaten Prozess
- M 4.182 (1) berwachen des IIS-Systems
- M 4.183 (2) Sicherstellen der Verfgbarkeit und Performance des IIS
- M 4.184 (2) Deaktivieren nicht bentigter Dienste beim IIS-Einsatz
- M 4.185 (2) Absichern von virtuellen Verzeichnissen und Web-Anwendungen beim IIS-Einsatz
- M 4.186 (1) Entfernen von Beispieldateien und Administrations-Scripts des IIS
- M 4.187 (1) Entfernen der FrontPage Server-Erweiterung des IIS
- M 4.188 (2) Prfen der Benutzereingaben beim IIS-Einsatz
- M 4.189 (2) Schutz vor unzulssigen Programmaufrufen beim IIS-Einsatz
- M 4.190 (2) Entfernen der RDS-Untersttzung des IIS
Kommunikation:
- M 5.66 (1) Verwendung von SSL (optional)
- M 5.101 (2) Entfernen nicht bentigter ODBC-Treiber beim IIS-Einsatz
- M 5.102 (3) Installation von URL-Filtern beim IIS-Einsatz
- M 5.103 (2) Entfernen smtlicher Netzwerkfreigaben beim IIS-Einsatz
- M 5.104 (3) Konfiguration des TCP/IP-Filters beim IIS-Einsatz
- M 5.105 (2) Vorbeugen vor SYN-Attacken auf den IIS
- M 5.106 (1) Entfernen nicht vertrauenswrdiger Root-Zertifikate beim IIS-Einsatz
_________________________________________________________________________________________
_________________________________________________________________________________________
Notfallvorsorge:
- M 6.85 (3) Erstellung eines Notfallplans fr den Ausfall des IIS
- M 6.86 (2) Schutz vor schdlichem Code auf dem IIS
- M 6.87 (1) Datensicherung auf dem IIS
_________________________________________________________________________________________
Apache Webserver 7.9
_________________________________________________________________________________________
7.9 Apache-Webserver
Beschreibung
Der Apache-Webserver ist seit 1997 der bei weitem am
hufigsten eingesetzte Webserver. Laut der Netcraft-
Webserverstatistik war im August 2002 auf ber 60 Pro-
zent aller betrachteten Webserver ein Apache-Webserver
im Einsatz.
Der Apache-Webserver entstand 1995 aus dem bis dahin
meist genutzten Webserver, dem NCSA httpd, der am
National Center for Supercomputing Applications der
University of Illinois entwickelt worden war. Da der bis-
herige Entwickler, Rob McCool, das NCSA verlassen hatte, war die Entwicklung ins Stocken geraten.
Eine Gruppe von Webmastern fand sich zusammen, um den NCSA httpd weiter zu entwickeln. Da die
Weiterentwicklung zunchst in der Form von Patches und Ergnzungen zum NCSA httpd erfolgte,
bekam das Produkt Namen Apache, von "A patchy server".
Ende 1995 wurde die Version 1.0 des Apache-Webservers verffentlicht. Nach einer lngeren Beta-
testphase fr die Version 2, die sich seit ungefhr 1998 in der Entwicklung befand, wurde im April
2002 mit der Version 2.0.35 die erste "Produktionsversion", beim Apache-Webserver General Avail-
ability Release genannt, freigegeben.
In der neuen Version des Apache-Webservers hat sich vor allem an der Architektur des Apache-Kerns
einiges gendert. Bei der Entwicklung der neuen Version hatten die Autoren das Ziel, die Portierung
auf neue Plattformen einfacher zu gestalten, und entwarfen eine modulare Architektur, in der die
Apache Portable Runtime (APR) eine Abstraktionsschicht zwischen dem unterliegenden Betriebs-
system und dem Apache 2.0 darstellt. Die APR stellt fr die eigentlichen Apache-Module gewisser-
maen ein virtuelles Betriebssystem dar, verwendet aber so weit wie mglich native Betriebssystem-
aufrufe, um eine bestmgliche Performance zu erzielen.
Gefhrdungslage
Fr den Grundschutz werden pauschal die folgenden Gefhrdungen als typisch fr einen Apache-
Webserver angenommen:
- G 2.87 Verwendung unsicherer Protokolle in ffentlichen Netzen
- G 3.62 Fehlerhafte Konfiguration des Betriebssystems fr einen Apache-Webserver
- G 3.63 Fehlerhafte Konfiguration eines Apache-Webservers
_________________________________________________________________________________________
_________________________________________________________________________________________

- G 5.109 Ausnutzen systemspezifischer Schwachstellen beim Apache-Webserver
Seit Version 2 wird neben diversen Unix-Varianten auch Windows als Betriebssystemplattform fr
den Apache-Webserver voll untersttzt. Zwar gab es auch eine Portierung der Version 1.3 auf
Windows, diese galt jedoch bis zuletzt als nicht so stabil wie die Unix-Versionen. Die Manahmen in
diesem Kapitel sind so weit wie mglich so formuliert, dass sie sich sowohl auf einen Apache-
Webserver unter Unix als auch unter Windows anwenden lassen. An einigen Stellen wird auf betriebs-
systemspezifische Aspekte besonders eingegangen.
Fr die sichere Planung, Implementierung und den sicheren Betrieb eines Apache-Webservers mssen
zunchst die allgemeinen Aspekte bercksichtigt werden, die im Kapitel7.5 Webserver erlutert
werden. In diesem Kapitel werden vor allem solche Aspekte der Sicherheit betrachtet, die ber die
allgemeinen Aspekte hinaus speziell fr einen Apache-Webserver relevant sind.
Im Rahmen der allgemeinen Planung fr den Aufbau eines Webangebots (siehe M 2.172 Entwicklung
eines Konzeptes fr die WWW-Nutzung) wird entschieden, zu welchem Zweck das Webangebot dienen
soll und an welche Zielgruppen es sich richtet. Ist im Anschlu daran die Entscheidung gefallen, dass
das Webangebot mit einem Apache-Webserver aufgebaut werden soll, muss sich eine detailliertere
Planung fr dessen Einsatz anschlieen (siehe M 2.269 Planung des Einsatzes eines Apache-Web-
servers). Soll der Apache-Webserver in Verbindung mit SSL eingesetzt werden, so muss dies frh-
zeitig in die Planung einbezogen werden (siehe M 2.270 Planung des SSL-Einsatzes beim Apache-
Webserver). Der Einsatz von SSL erfordert auch beim Betrieb des Servers einige zustzliche Ma-
nahmen (siehe M 5.107 Verwendung von SSL im Apache-Webserver).
Die Administratoren mssen fr die sichere Installation und den sicheren Betrieb eines Apache-Web-
servers geschult werden. Wichtige Aspekte, die in einer solchen Schulung abgedeckt werden sollten,
sind in M 3.37 Schulung der Administratoren eines Apache-Webservers beschrieben.
Bevor der Apache-Webserver auf dem Serverrechner installiert wird, muss zunchst das Betriebs-
system geeignet konfiguriert und abgesichert werden. (siehe M 4.192 Konfiguration des Betriebs-
systems fr einen Apache-Webserver). Die Integritt und Authentizitt der zur Installation verwende-
ten Pakete (Quelltext- oder Binrpakete) muss berprft werden (siehe M 4.191 berprfung der
Integritt und Authentizitt der Apache-Pakete). Bei der eigentlichen Installation und der anschlieen-
den Gundkonfiguration sind eine Reihe von Punkten zu beachten, die in M 4.193 Sichere Installation
eines Apache-Webservers und M 4.194 Sichere Grundkonfiguration eines Apache-Webservers be-
schrieben werden.
Sollen auf dem Webserver Bereiche nicht ffentlich, sondern nur einem begrenzten Kreis von Be-
suchern zugnglich sein, so ist M 4.195 Konfiguration der Zugriffssteuerung beim Apache-Webserver
zu beachten. Beim Betrieb eines Apache-Webservers sind auerdem die in M 4.196 Sicherer Betrieb
eines Apache-Webservers beschriebenen Aspekte zu beachten.
Falls auf dem Apache-Webserver dynamische Webseiten ber Server-Side-Includes, cgi-Programme
oder andere Servererweiterungen realisiert werden sollen, so ist M 4.197 Servererweiterungen fr
dynamische Webseiten beim Apache-Webserver zu bercksichtigen. Der Apache-Webserver kann zur
Erhhung der Systemsicherheit unter verschiedenen Unix-Varianten in einem sogenannten chroot-
Kfig installiert werden (siehe M 4.198 Installation eines Apache-Webservers in einem chroot-Kfig).
_________________________________________________________________________________________
_________________________________________________________________________________________
Einige Punkte, die bei der Notfallplanung zustzlich zu den allgemeinen Aspekten der Notfallplanung
speziell fr einen Apache-Webserver bercksichtigt werden mssen, sind in M 6.89 Notfallvorsorge
fr einen Apache-Webserver zusammen gefasst.
In Beispielen und bei konkreten Empfehlungen wird im Rahmen dieses Bausteins von Version 2.0
eines Apache-Webservers ausgegangen. Wo nicht explizit auf einen Unterschied hingewiesen wird,
sollten jedoch die meisten Aussagen auch fr die Version 1.3 gelten. Beispiele werden meist in der
Syntax angegeben, wie sie fr einen Apache-Webserver unter Unix korrekt ist, sie sind aber ohne
groe Mhe auf die Windows-Version bertragbar.
Nachfolgend sind die Manahmen zur Umsetzung von IT-Grundschutz fr den Apache-Webserver
zusammengefasst. Die Manahmen des allgemeinen Webserver-Bausteins und der anderen relevanten
Bausteine werden aus Grnden der bersichtlichkeit hier nicht noch einmal aufgefhrt.
Organisation
- M 2.269 (2) Planung des Einsatzes eines Apache-Webservers
- M 2.270 (1) Planung des SSL-Einsatzes beim Apache-Webserver (zustzlich)
Personal
- M 3.37 (1) Schulung der Administratoren eines Apache-Webservers
Hardware / Software
- M 4.191 (1) berprfung der Integritt und Authentizitt der Apache-Pakete
- M 4.192 (1) Konfiguration des Betriebssystems fr einen Apache-Webserver
- M 4.194 (1) Sichere Grundkonfiguration eines Apache-Webservers
- M 4.195 (1) Konfiguration der Zugriffssteuerung beim Apache-Webserver
- M 4.196 (1) Sicherer Betrieb eines Apache-Webservers
- M 4.197 (2) Servererweiterungen fr dynamische Webseiten beim Apache-Webserver
- M 4.198 (3) Installation eines Apache-Webservers in einem chroot-Kfig (optional)
Kommunikation
- M 5.107 (2) Verwendung von SSL im Apache-Webserver (optional)
Notfallvorsorge
- M 6.89 (1) Notfallvorsorge fr einen Apache-Webserver
_________________________________________________________________________________________
Exchange 2000 / Outlook 2000 7.10
_________________________________________________________________________________________

Beschreibung
Der Exchange 2000 Server ist ein Managementsystem fr
Nachrichten, das berdies Funktionen im Bereich der
Workflow-Untersttzung bietet. Es ist dazu gedacht, in
mittleren bis groen Behrden bzw. Unternehmen den
internen und externen E-Mail-Verkehr zu regeln. Ebenso
werden Newsgroups, Kalender und Aufgabenlisten von
Exchange verwaltet.
Outlook 2000 ist ein E-Mail-Client, der Bestandteil des
Office 2000 Paketes von Microsoft ist. Neben der reinen
E-Mail-Funktionalitt bietet er eine Reihe von Zusatzfunktionen, die den Arbeitsprozess in Unter-
nehmen und Behrden erleichtern sollen.
Es handelt sich hierbei um eine typische Client-Server-Anwendung, wobei Exchange 2000 die Server-
und Outlook 2000 die Client-Komponente darstellt.
Unterschiede zur Vorgngerversion Exchange 5.5
Die Vorgngerversion von Exchange 2000 Server ist der Exchange 5.5 Server. Zwischen diesen Ver-
sionen besteht konzeptionell ein gravierender Unterschied. Exchange 2000 Server integriert sich tief in
das Betriebssystem Windows 2000, speziell in das Active Directory. Dies betrifft die Organisation des
Exchange Systems, dessen Administration und besonders auch die Sicherheit des Gesamtsystems
durch die Verwendung der Systemrichtlinien von Windows 2000.
Das Standort-Konzept (Site) von Exchange 5.5 wurde fallen gelassen und stattdessen das Forest-Kon-
zept von Windows 2000 bernommen, denen sich sogenannte Routing Groups von Exchange 2000
Servern unterordnen. Darber hinaus haben sich interne Kommunikationsprotokolle gendert. Bei-
spielsweise basiert in der neuen Version die interne E-Mail-Kommunikation innerhalb einer Routing
Group ausschlielich auf dem "klassischen" Simple Mail Transfer Protocol (SMTP) anstelle der zuvor
verwendeten Remote Procedure Calls (RPCs).
Weitere Unterschiede ergeben sich aus einer erweiterten Funktionalitt und einer Vergrerung des
Leistungsspektrums: Die E-Mail- und Nachrichten-Datenbanken knnen in separat verwaltete Teile
partitioniert und auf verschiedene Server verteilt werden. Dies dient zum einen der Skalierbarkeit des
Systems und erhht zum anderen auch die Ausfallsicherheit. Weiterhin wird eine verteilte Konfigu-
ration untersttzt, eine vereinheitlichte Administration ber die Microsoft Management Console
(MMC) ermglicht, mehrfache ffentliche Verzeichnisse bereitgestellt, Video- und Datenkonferenzen
ermglicht und Instant Messaging untersttzt.
Exchange 2000 Server integriert auerdem in hohem Mae die Internet Information Services (IIS) von
Windows 2000. Dies fhrt zu zustzlichen Gefhrdungen und ist fr einen gesicherten Betrieb des
Systems unbedingt zu bercksichtigen. Betroffen ist davon unter anderem der sogenannte Web Store
(Installable File System - IFS), der den lokalen und den entfernten (remote) Zugriff auf das Datei-
system erlaubt. Das Laufwerk M (Standardeinstellung) eines jeden Rechners, auf dem Exchange 2000
installiert wird, bietet einen direkten Zugang ber das Dateisystem auf diesen Web Store. Dieses
Laufwerk erhlt automatisch eine Netzfreigabe, so dass weitere Applikationen darauf zugreifen
knnen. Ein weiterer Punkt sind die Web Forms, die vom Exchange 2000 Server direkt an Browser
bermittelt werden, um interaktive Arbeitsprozesse ber Browser zu ermglichen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Zwischen der Exchange Store Architektur und den Internet Access Protokollen liegt eine spezielle
Schicht, der Exchange Interprocess Communication Layer EXIPC, auch Epoxy-Layer genannt. Dieser
besteht aus einem asynchron geteilten Speicherbereich, in welchem sowohl der Prozess STORE.EXE
als auch die IIS-Protokolle Daten lesen und schreiben knnen. STORE.EXE ist ein wesentlicher Pro-
zess des Exchange Servers. Dadurch wird ein schneller Datenaustausch ermglicht, der aus Sicher-
heitssicht jedoch auch problematisch ist.
Die Zusammenarbeit von Client mit Server lsst sich auf vielfltige Art und Weise konfigurieren und
betreiben. Hier ergeben sich zum Teil erhebliche Unterschiede in Bezug auf die Sicherheit. Weiterhin
ist es mglich, den Exchange 2000 Server so zu konfigurieren, dass mittels des sogenannten Outlook
Web Access (OWA) direkt ber das Internet zugegriffen werden kann. Dies ist von erheblicher sicher-
heitstechnischer Relevanz, siehe M 4.164 Browser-Zugriff auf Exchange 2000.
Allgemeine Gesichtspunkte beim Betrieb eines E-Mail-Systems
Fr einen sicheren Betrieb des Exchange 2000 Systems gelten auch allgemeine IT-Sicherheitsaspekte
eines E-Mail-Systems, wie z. B. die Frage der Internet-Anbindung, eventuelle unterliegende Ver-
schlsselungsmanahmen, Behandlung aktiver Inhalte, Einsatz von Anti-Viren-Software und vieles
mehr. Diesbezglich wird auf den Baustein 7.4 E-Mail verwiesen. Die dort dargestellten Gefhr-
dungen und Manahmen besitzen im Kontext von Exchange/Outlook 2000 uneingeschrnkte Gltig-
keit.
Wie in der bisherigen bersicht dargestellt, spielt die Sicherheit von Windows 2000 eine zentrale
Rolle fr die Sicherheit von Exchange bzw. Outlook. Dies gilt sowohl fr die Server als auch die
Clients des betrachteten Netzes. In diesem Zusammenhang sei auf die Bausteine 6.9 Windows 2000
Server und 5.7 Windows 2000 Client sowie die dort aufgefhrten Gefhrdungen und Manahmen
verwiesen.
Eine Ende-zu-Ende-Sicherheit auf Anwendungsebene (hier: Outlook-Client) kann mittels Ver-
schlsselung und Signatur von elektronischen Nachrichten erzielt werden. Die Konfiguration und der
Betrieb eines solchen Systems setzen dabei entweder die Verwendung der Microsoft Public Key Infra-
struktur (PKI) oder eine Plug-In-Lsung eines Drittherstellers voraus. Theoretisch ist es natrlich
mglich, gnzlich auf eine PKI zu verzichten, jedoch sind dann die bekannten Skalierungsprobleme
im Schlsselmanagement oder die Probleme der Vertrauensbeziehungen zu lsen.
Betrachtete Versionen
Im folgenden sind die derzeit aktuellen (Stand Oktober 2001) Produktversionen aufgefhrt. In der
Folge bezeichnet Exchange 2000 Server jede dieser Produktausprgungen:
- Exchange 2000 Server:
Dies ist die Grundausstattung des Produktes und richtet sich an kleine bis mittlere Unternehmen
bzw. Behrden.
- Exchange 2000 Enterprise Server:
Diese Ausprgung beinhaltet die Grundfunktionalitt von Exchange 2000 sowie Mechanismen fr
eine bessere Skalierbarkeit des Systems, z. B. Verteilung der E-Mail-Datenbanken auf verschie-
dene Server, keine Beschrnkungen in der Gre von Transaktionsdaten, Vier-Wege-Clustering.
- Exchange 2000 Conferencing Server:
Diese Version bietet die umfassendste Funktionalitt, unter anderem Werkzeuge zur Durchfhrung
von Daten-, Audio- und Videokonferenzen, Load Balancing und Bandbreitenmanagement.
_________________________________________________________________________________________
_________________________________________________________________________________________
- Outlook 2000, Service Release 1

In diesem Baustein wird die englischsprachige Version des Produktes Exchange 2000 betrachtet. Dies
erfolgt vor dem Hintergrund der allgemeinen Empfehlung, stets diejenige Version im Betrieb einzu-
setzen, fr welche Software-Anpassungen und Fehlerbehebungen generell als erstes verfgbar sind.
Fr die Office-Anwendung Outlook 2000 wird die deutsche Version betrachtet, da diese in deutsch-
sprachigen Behrden und Unternehmen eine grere Verbreitung findet als die entsprechende eng-
lischsprachige Ausgabe.
Fr ein Exchange/Outlook 2000 System knnen folgende Sicherheitsziele unterschieden werden:
1. Zugangssicherheit: Die auf einem Exchange 2000 Server gespeicherten Daten drfen nur
berechtigten Benutzern zugnglich sein. Das heit, der Zugriff auf den Server muss entsprechend
geregelt sein. Dies wird in erster Linie durch geeignete Konfiguration des Windows 2000 Servers
erreicht, auf dem die Exchange Services installiert werden. Um Rollenkonflikte und erhebliche zu-
stzliche Risiken zu vermeiden, sollte dies grundstzlich ein Member Server des Netzes sein und
kein Domnen-Controller.
2. Zugriffskontrolle: Neben der Kontrolle des Serverzugriffs stellt der Zugriff auf Datenbankebene
(Mail Stores) einen wichtigen Sicherheitsaspekt dar. Hier lsst sich mit Hilfe der Sicherheitsein-
stellungen des Active Directory (Access Control Lists auf die relevanten Objekte) ein Schutz er-
reichen.
3. Kommunikationssicherheit: Wenn ein E-Mail-Client auf die Daten des Exchange 2000 Servers
zugreift, werden die abgerufenen Daten ber eine Netzverbindung (LAN, WAN oder Internet)
bertragen. Um Vertraulichkeit und Integritt der Daten zu gewhrleisten, lassen sich Schutzma-
nahmen auf verschiedenen Ebenen der bertragung durchfhren.
4. Verfgbarkeit: Um die Produktivitt innerhalb eines Unternehmens bzw. einer Behrde nicht zu
gefhrden, sind Anforderungen an die Verfgbarkeit des Systems zu stellen. Dies umso mehr, als
E-Mail oft einen entscheidenden Anteil an der Abwicklung von Geschftsprozessen hat. Manah-
men zum Schutz der Verfgbarkeit sind die Verteilung der E-Mail-Datenbanken auf mehrere
Server, allgemeine Spiegelungstechniken sowie die Erstellung eines Notfallplans.
Gefhrdungslage
Fr den IT-Grundschutz eines Exchange 2000 Systems inklusive zugeordneter Outlook 2000 Clients
werden die folgenden typischen Gefhrdungen angenommen:
Hhere Gewalt:
- G 2.55 Ungeordnete E-Mail-Nutzung
- G 2.91 Fehlerhafte Planung der Migration von Exchange 5.5 nach Exchange 2000
- G 2.92 Fehlerhafte Regelungen fr den Browser-Zugriff auf Exchange
- G 2.95 Fehlendes Konzept zur Anbindung anderer E-Mail-Systeme an Exchange/Outlook
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 3.60 Fehlkonfiguration von Exchange 2000 Servern
- G 3.61 Fehlerhafte Konfiguration von Outlook 2000 Clients
- G 4.32 Nichtzustellung einer Nachricht
Zustzlich zu der Absicherung der Komponenten von Exchange bzw. Outlook muss noch ein spezi-
fisches Sicherheitskonzept erstellt werden, das sich konsistent in das bestehende betriebsweite Sicher-
heitskonzept integrieren lsst. Das Exchange/Outlook-System muss so konfiguriert werden, dass be-
reits bestehende Sicherheitsanforderungen umgesetzt werden. Darber hinaus sind weitere, fr
Exchange bzw. Outlook spezifische Anforderungen zu erfllen.
Ein Exchange/Outlook-System wird in der Regel im Umfeld mit weiteren Systemen eingesetzt, die
den Zugriff auf das interne Netz von auen kontrollieren. Hierbei sind insbesondere Firewall-Systeme
und Systeme zur Fernwartung zu nennen, mit denen Exchange 2000 zusammenarbeiten muss. Aus
diesem Grund sind bei der Durchfhrung der fr Exchange bzw. Outlook spezifischen Manahmen
stets auch die entsprechenden Empfehlungen aus den jeweiligen Bausteinen zustzlich betroffener
Systeme zu bercksichtigen. Neben den Bausteinen aus den Kapiteln 5 und 6 sind unter anderem auch
die folgenden Bausteine zu nennen:
- 7.3 Firewall, sofern Exchange 2000 Systeme in einer Firewall-Umgebung eingesetzt werden.
- 7.6 Remote Access, wenn der Zugriff auf das Exchange-System ber Einwahlleitungen erfolgt.
Fr die erfolgreiche Implementierung eines Exchange/Outlook-Systems sind eine Reihe von Ma-
nahmen umzusetzen, beginnend mit der Planung ber die Installation bis hin zum Betrieb. Die
einzelnen Schritte sowie die jeweiligen Manahmen, die auf diesem Weg zu beachten sind, sind nach-
stehend zusammengefasst:
1. Nach der Entscheidung, Exchange 2000 als internes Kommunikationssystem einzusetzen, muss die
Beschaffung der Software und eventuell zustzlich bentigter Hardware erfolgen. Da Exchange
2000 in verschiedenen Ausprgungen erhltlich ist (siehe oben), hngt das zu beschaffende Soft-
wareprodukt von den geplanten Einsatzszenarien ab. Daher sind folgende Manahmen zu
ergreifen:
_________________________________________________________________________________________
_________________________________________________________________________________________
- Zunchst muss der Einsatz des Exchange/Outlook-Systems geplant werden (siehe M 2.247
Planung des Einsatzes von Exchange/Outlook 2000).
- Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe M 2.248 Festlegung einer
Sicherheitsrichtlinie fr Exchange/ Outlook 2000), die einerseits bereits bestehende Sicher-
heitsrichtlinien im Kontext von Exchange/Outlook umsetzt und gleichzeitig fr Exchange
bzw. Outlook spezifische Ergnzungen definiert.
- Vor der tatschlichen Verteilung des Exchange/Outlook-Systems mssen die Benutzer und
Administratoren im Umgang mit den Produkten geschult werden. Insbesondere fr Admi-
nistratoren empfiehlt sich eine intensive und praxisnahe Schulung, die auf fundierte Kennt-
nisse bezglich Windows 2000 und dessen Sicherheit aufsetzen sollte (siehe M 3.31
Schulung zur Systemarchitektur und Sicherheit von Exchange 2000 fr Administratoren).
Benutzern sollten die verfgbaren Sicherheitsmechanismen von Outlook 2000 detailliert er-
lutert werden (siehe M 3.32 Schulung zu Sicherheitsmechanismen von Outlook 2000 fr
Benutzer).
2. Nachdem die organisatorischen und planerischen Vorbereitungen durchgefhrt wurden, kann die
Installation des Exchange/Outlook-Systems erfolgen. Folgende Manahmen sind dabei zu er-
greifen:
- Die Systeme, auf denen Exchange/Outlook installiert werden soll, mssen geeignet abge-
sichert sein. Empfehlungen fr die Betriebssystemplattform des Servers finden sich unter
anderem in Baustein 6.9 Windows 2000 Server.
- Die Installation kann erst dann als abgeschlossen angesehen werden, wenn die
Exchange/Outlook-Systeme in einen sicheren Zustand berfhrt wurden (siehe M 4.161
Sichere Installation von Exchange/Outlook 2000). Dadurch wird sichergestellt, dass in der
anschlieenden Konfigurationsphase nur berechtigte Administratoren auf das Exchange
2000 System zugreifen knnen.
- Nach der Installation erfolgt eine erstmalige Konfiguration des Exchange/Outlook-Systems,
siehe M 4.162 Sichere Konfiguration von Exchange 2000 Server, M 4.165 Sichere Konfigu-
ration von Outlook 2000 sowie M 4.164 Browser-Zugriff auf Exchange 2000.
3. Nach der Erstinstallation und einer Testbetriebsphase wird der Regelbetrieb aufgenommen. Dabei
sind aus Sicht der IT-Sicherheit folgende Aspekte zu beachten:
- Ein Exchange/Outlook-System ist in der Regel kontinuierlichen Vernderungen unterworfen.
Entsprechend mssen die sicherheitsrelevanten Konfigurationsparameter stndig angepasst
werden. Weiterhin hngt die Sicherheit bei einer verteilten Software-Architektur von der
Sicherheit smtlicher Teilsysteme ab. Dies gilt insbesondere fr die Outlook-Clients. Die fr
den sicheren Betrieb relevanten Empfehlungen sind in M 4.166 Sicherer Betrieb von
Exchange/Outlook 2000 und den Manahmen zur Kommunikationssicherung (siehe M 5.100
Einsatz von Verschlsselungs- und Signaturverfahren fr die Exchange 2000 Kommunika-
tion) zusammengefasst.
- Neben der Absicherung des laufenden Betriebs sind auch die Manahmen zur Notfallvor-
sorge von zentraler Bedeutung. Hinweise zu diesem Thema finden sich in M 6.82 Erstellen
eines Notfallplans fr den Ausfall von Exchange-Systemen.
Nachfolgend wird das Manahmenbndel fr den Einsatz von Exchange 2000 und Outlook 2000 vor-
gestellt.
_________________________________________________________________________________________
_________________________________________________________________________________________
Organisation:
- M 2.247 (1) Planung des Einsatzes von Exchange/Outlook 2000
- M 2.248 (1) Festlegung einer Sicherheitsrichtlinie fr Exchange/ Outlook 2000
- M 2.249 (1) Planung der Migration von "Exchange 5.5-Servern" nach "Exchange 2000"
Personal:
- M 3.31 (1) Schulung zur Systemarchitektur und Sicherheit von Exchange 2000 fr
Administratoren
- M 3.32 (1) Schulung zu Sicherheitsmechanismen von Outlook 2000 fr Benutzer
- M 4.161 (1) Sichere Installation von Exchange/Outlook 2000
- M 4.162 (1) Sichere Konfiguration von Exchange 2000 Servern
- M 4.163 (1) Zugriffsrechte auf Exchange 2000 Objekte
- M 4.164 (1) Browser-Zugriff auf Exchange 2000
- M 4.165 (1) Sichere Konfiguration von Outlook 2000
- M 4.166 (1) Sicherer Betrieb von Exchange/Outlook 2000
- M 4.167 (2) berwachung und Protokollierung von Exchange 2000 Systemen
Kommunikation:
- M 5.99 (2) SSL/TLS-Absicherung fr Exchange 2000
- M 5.100 (2) Einsatz von Verschlsselungs- und Signaturverfahren fr die Exchange 2000
Kommunikation (optional) (optional)
Kommunikation (optional)
Notfallvorsorge:
- M 6.82 (1) Erstellen eines Notfallplans fr den Ausfall von Exchange-Systemen
_________________________________________________________________________________________
Router und Switches 7.11
_________________________________________________________________________________________

Netze spielen eine immer wichtigere Rolle als Teile der
IT-Infrastruktur, weil Anwendungen heutzutage vermehrt
ber lokale Netze oder Weitverkehrsnetze betrieben
werden. Die Verfgbarkeit, Integritt und Vertraulichkeit
der Netze muss sichergestellt sein und mindestens den
Anforderungen der Anwendungen an den Schutz dieser
drei Grundwerte der IT-Sicherheit entsprechen.
Ein Netz besteht aus aktiver und passiver Netztechnik.
Als passive Netztechnik wird in erster Linie die
strukturierte Verkabelung verstanden. Hierzu gehren
Patch-Felder (ber Steckfelder konfigurierbare Kabelverteiler), Schutzschrnke und Anschlussdosen
am Arbeitsplatz. Zur aktiven Netztechnik gehren beispielsweise Hubs, Bridges, Switches und Router.
In modernen Netzen ersetzen Switches heutzutage vielfach Hubs sowie Bridges. Ein Ausfall einer
oder mehrerer Komponenten der aktiven Netztechnik (Router und Switches) kann zum kompletten
Stillstand der gesamten IT-Infrastruktur fhren. Da diese Komponenten die Basis und das Rckgrat
der IT-Infrastruktur bilden, mssen Router und Switches vor unerlaubten Zugriffen und
Manipulationen geschtzt werden.
Die Funktionsweise von Routern ist in M 2.276 Funktionsweise eines Routers beschrieben. Die
Manahme M 2.277 Funktionsweise eines Switches beschreibt die Funktionsweise eines Switches. Die
wichtigsten funktionalen Unterschiede der in der folgenden Abbildung dargestellten aktiven
Netzkomponenten werden kurz erklrt.
Abbildung: Hub, Bridge, Switch und Router

Kollisionsdomne
Unter einer Kollisionsdomne wird ein einzelnes Segment beim Netzzugangsverfahren CSMA/CD
(Carrier Sense Multipe Access with Collision Detection) verstanden. Alle Gerte, die im selben
Segment angeschlossen sind, sind Bestandteil dieser Kollisionsdomne. Versuchen zwei Gerte, zum
gleichen Zeitpunkt ein Paket ins Netz zu senden, so spricht man von einer Kollision. Beide Gerte
warten dann einen bestimmten Zeitraum zufllig gewhlter Lnge und versuchen dann erneut, das
Paket zu senden. Durch diese Wartezeit verringert sich die effektive Bandbreite, die den Gerten zur
Verfgung steht.
_________________________________________________________________________________________
_________________________________________________________________________________________
Broadcast-Domne
Broadcast-Informationen sind nicht an ein bestimmtes Endgert gerichtet, sondern an alle
"benachbarten" Endgerte. Diejenigen Gerte in einem Netz, die die jeweiligen Broadcast-
Informationen der anderen Gerte empfangen, bilden zusammen eine Broadcast-Domne. Gerte, die
in einer Broadcast-Domne zusammen gefasst sind, mssen sich nicht in derselben Kollisionsdomne
befinden. Beim IP-Protokoll spricht man in diesem Fall auch von einem IP-Subnetz. Beispielsweise
bilden die Stationen mit den IP-Adressen von 192.168.1.1 bis 192.168.1.254 in einem IP-Subnetz mit
einer Subnetzmaske von 255.255.255.0 eine Broadcast-Domne.
Hub
Hubs arbeiten auf der OSI Schicht 1 (Bitbertragungsschicht). Alle angeschlossenen Gerte befinden
sich in derselben Kollisionsdomne und damit auch in derselben Broadcast-Domne. Hubs werden
heutzutage durch Access-Switches (siehe M 2.277 Funktionsweise eines Switches) abgelst.
Bridge
Bridges verbinden Netze auf der OSI Schicht 2 (Sicherungsschicht) und segmentieren
Kollisionsdomnen. Jedes Segment bzw. Port an einer Bridge bildet eine eigene Kollisionsdomne.
Alle angeschlossenen Stationen sind im Normalfall Bestandteil einer Broadcast-Domne. Bridges
knnen auch dazu dienen, Netze mit unterschiedlichen Topographien (Ethernet, Token Ring, FDDI,
etc.) auf der OSI Schicht 2 miteinander zu verbinden (transparent bridging, translational bridging).
Hauptschlich wurden Bridges zur Lastverteilung in Netzen eingesetzt. Die Entlastung wird dadurch
erzielt, dass eine Bridge als zentraler bergang zwischen zwei Netzsegmenten nicht mehr jedes
Datenpaket weiterleitet. Eine Bridge hlt eine interne MAC-Adresstabelle vor, aus der hervorgeht, in
welchem angeschlossenen Segment entsprechende MAC-Adressen vorhanden sind. Wenn die Bridge
beispielsweise aus dem Teilsegment A ein Datenpaket fr eine Station im Teilsegment B erhlt, wird
das Datenpaket weitergeleitet. Falls die Bridge hingegen ein Datenpaket aus dem Teilsegment A fr
eine Station aus dem Teilsegment A empfngt, wird dieses Datenpaket nicht in das Teilsegment B
bertragen. Dadurch wird eine Entlastung des Teilsegments B erreicht. Heutzutage werden Bridges
durch Switches ersetzt.
Layer-2-Switch
Herkmmliche Layer-2-Switches verbinden Netze auf der OSI Schicht 2. Jeder Switch-Port bildet eine
eigene Kollisionsdomne. Normalerweise sind alle angeschlossenen Stationen Bestandteil einer
Broadcast-Domne. Das bedeutet, dass ein Layer-2-Switch die Ziel-MAC-Adresse im MAC-Header
als Entscheidungskriterium dafr verwendet, auf welchen Port eingehende Datenpakete weitergeleitet
werden. Trotz der vergleichbaren Funktionsweise gibt es zwei wesentliche Unterschiede zu Bridges:
- Ein Switch verbindet in der Regel wesentlich mehr Teilsegmente miteinander als eine Bridge.
- Der Aufbau eines Switches basiert auf sogenannten Application Specific Interface Circuits
(ASICs). Dadurch ist ein Switch in der Lage, Datenpakete wesentlich schneller als eine Bridge von
einem Segment in ein anderes zu transportieren. Unterschiedliche Switching-Technologien sind in
M 2.277 Funktionsweise eines Switches beschrieben.
Gelegentlich werden Switches auch als Multiport Bridges bezeichnet.
Router
Router arbeiten auf der OSI Schicht 3 (Netzschicht) und vermitteln Datenpakete anhand der Ziel-IP-
Adresse im IP-Header. Jedes Interface an einem Router stellt eine eigene Broadcast-Domne und
damit auch eine Kollisionsdomne dar. Router sind in der Lage, Netze mit unterschiedlichen
Topographien zu verbinden. Router werden verwendet, um lokale Netze zu segmentieren oder um
_________________________________________________________________________________________
_________________________________________________________________________________________
lokale Netze ber Weitverkehrsnetze zu verbinden. Ein Router identifiziert eine geeignete Verbindung
zwischen dem Quellsystem beziehungsweise Quellnetz und dem Zielsystem beziehungsweise
Zielnetz. In den meisten Fllen geschieht dies durch die Weitergabe des Datenpaketes an den nchsten
Router, den sogenannten Next Hop. Weitergehende Aspekte sind in M 2.276 Funktionsweise eines
Routers beschrieben.
Router mssen jedes IP-Paket vor der Weiterleitung analysieren. Dies fhrt zu Verzgerungen und
damit im Vergleich zu "klassischen" Switches zu einem geringeren Datendurchsatz.
Layer-3-Switch und Layer-4-Switch
Layer-3- und Layer-4-Switches sind Switches, die zustzlich eine Routing-Funktionalitt bieten.
Layer-2-Switches verwenden die Ziel-MAC-Adresse im MAC-Header eines Paketes zur
Entscheidung, zu welchem Port Datenpakete weitergeleitet werden. Ein Layer-3-Switch behandelt
Datenpakete beim ersten Mal wie ein Router (Ziel-IP-Adresse im IP-Header). Alle nachfolgenden
Datenpakete des Senders an diesen Empfnger werden daraufhin jedoch auf der OSI Schicht 2 (Ziel-
MAC-Adresse im MAC-Header) weitergeleitet. Dadurch kann ein solcher Switch eine wesentlich
hhere Durchsatzrate erzielen als ein herkmmlicher Router.
Ein weiteres Unterscheidungsmerkmal zwischen einem Router und einem Layer-3-Switch ist die
Anzahl von Ports zum Anschluss von einzelnen Endgerten. Ein Layer-3-Switch verfgt in der Regel
ber eine wesentlich grere Portdichte.
Durch die Routing-Funktion knnen Layer-3 oder Layer-4-Switches in lokalen Netzen herkmmliche
LAN-to-LAN-Router ersetzen.
Abgrenzung
In diesem Kapitel werden Gefhrdungen und Manahmen beim Einsatz von Routern und Switches
beschrieben. Die Abgrenzung zwischen Routern und Switches wird durch die Einfhrung der
Bezeichnungen Layer-2-Switch, Layer-3-Switch oder Layer-4-Switch durch verschiedene Hersteller
erschwert. Durch die Verschmelzung der Funktionen von Routern und Switches kann der Groteil der
beschriebenen Manahmen sowohl auf Router als auch auf Switches angewendet werden.
Es ist eine groe Auswahl von unterschiedlichen Routern und Switches von verschiedenen Herstellern
am Markt verfgbar. Die Beschreibung der Manahmen und Gefhrdungen in diesem Kapitel ist so
gehalten, dass sie so weit wie mglich herstellerunabhngig ist.
Neben den bergreifenden Aspekten und den infrastrukturellen Manahmen ist bei dem Einsatz von
Routern und Switches das Kapitel 6.7 Heterogene Netze zu bercksichtigen. Speziell bei der
Einbindung der aktiven Netzkomponenten in ein umfassendes Netz- und Systemmanagement ist das
Kapitel 6.8 Netz- und Systemmanagement von Bedeutung. Bei der Verwendung eines Routers als
Paketfilter oder als Einwahlmglichkeit sind zustzlich die Bausteine 7.3 Sicherheitsgateway
(Firewall) und 7.6 Remote Access zu bercksichtigen.
Neben eigens dafr hergestellten Gerten bieten auch verschiedene Betriebssysteme (beispielsweise
diverse Unix-Derivate, Windows 2000, etc.) Routing-Funktionalitt. Das bedeutet, dass ein Router aus
einem entsprechenden Rechner mit zwei oder mehr Netzwerkkarten und einem
Standardbetriebssystem bestehen kann. In kleineren lokalen Netzen kann dies unter Umstnden eine
kostengnstige Alternative sein. Neben den in diesem Baustein beschriebenen Sicherheitsmanahmen
sind beim Betrieb eines solchen Routers die Sicherheitsmanahmen des eingesetzten Betriebssystems
(Unix, Windows 2000, etc.) zu bercksichtigen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Gefhrdungslage
Neben den Gefhrdungen, die generell fr den Groteil der IT-Systeme gelten, existieren fr aktive
Netzkomponenten eine Reihe spezieller Gefhrdungen.
Diese Gefhrdungen basieren oft auf bekannten Schwachstellen in den verwendeten Protokollen, wie
TCP, UDP, IP oder ICMP. Durch Schwachstellen in dynamischen Routing-Protokollen knnen
beispielsweise Routing-Tabellen auf Routern modifiziert werden. Die oft fehlende oder unzureichende
Mglichkeit zur Authentisierung auf aktiven Netzkomponenten ist als weitere Gefhrdung anzufgen.
Aktive Netzkomponenten werden oft mit einer unsicheren Default-Konfiguration ausgeliefert (siehe
G 4.49 Unsichere Default-Einstellungen auf Routern und Switches), die bei der Inbetriebnahme der
Gerte geprft werden sollte. Einige Hersteller von Switches schlagen fr die sichere Trennung von
Teilnetzen mit unterschiedlichem Schutzbedarf die Nutzung von virtuellen Netzen (VLANs) vor. Es
sind jedoch einige Angriffsmethoden bekannt, die es ermglichen, die Grenzen zwischen VLANs zu
berwinden und unberechtigt auf andere VLANs zuzugreifen (siehe G 5.115 berwindung der
Grenzen zwischen VLANs).
Nachfolgend ist die Gefhrdungslage beim Einsatz von Routern und Switches als bersicht
dargestellt:
- G 2.98 Fehlerhafte Planung und Konzeption des Einsatzes von Routern und Switches
Menschliche Fehlhandlungen
- G 3.64 Fehlerhafte Konfiguration von Routern und Switchen
- G 3.65 Fehlerhafte Administration von Routern und Switchen
Technisches Versagen
- G 4.49 Unsichere Default-Einstellungen auf Routern und Switchen
Vorstzliche Handlungen
- G 5.112 Manipulation von ARP-Tabellen
- G 5.113 MAC Spoofing
- G 5.114 Missbrauch von Spanning Tree
- G 5.115 berwindung der Grenzen zwischen VLANs
Die diesem Baustein zugeordneten Sicherheitsmanahmen orientieren sich an dem Lebenszyklus der
aktiven Netzkomponenten. Es werden Manahmen beschrieben, die in folgende Zyklen kategorisiert
sind:
- Planung und Konzeption des Einsatzes von Routern und Switches
Der Einsatz von Routern und Switches muss sorgfltig geplant werden. Die Funktionen von Routern
und Switches sind in M 2.276 Funktionsweise eines Routers und M 2.277 Funktionsweise eines
Switches beschrieben. Typische Einsatzszenarien von Routern und Switches, die bei der Planung und
Konzeption hilfreich sein knnen, sind in M 2.278 Typische Einsatzszenarien von Routern und
Switches zu finden.
- Festlegung einer Sicherheitsstrategie fr Router und Switches
Vor der Beschaffung aktiver Netzkomponenten (siehe M 2.280 Kriterien fr die Beschaffung und
geeignete Auswahl von Routern und Switches) ist eine Sicherheitsstrategie fr den sicheren Betrieb der
Gerte festzulegen und zu dokumentieren (siehe M 2.279 Erstellung einer Sicherheitsrichtlinie fr
_________________________________________________________________________________________
_________________________________________________________________________________________
Router und Switches). Anschlieend knnen geeignete Netzkoppelelemente ausgewhlt werden, die
anschlieend sicher in die bestehende Netzinfrastruktur zu integrieren sind. In dieser Phase ist es
zudem wichtig, die Administratoren fr die sichere Administration zu schulen (siehe M 3.38
Administratorenschulung fr Router und Switches).
- Konfiguration und Inbetriebnahme von Routern und Switches
Bei der Konfiguration und Inbetriebnahme von Routern und Switches ist eine Reihe von wichtigen
Sicherheitsmanahmen zu bercksichtigen. Unsichere Default-Konfigurationen von Netzkomponenten
stellen oft ein erhebliches Sicherheitsrisiko dar. Deswegen muss die Konfiguration bei der
Inbetriebnahme berprft und angepasst werden.
Bei der Inbetriebnahme von Routern und Switches spielt neben der Dokumentation der
Systemkonfiguration (siehe M 2.281 Dokumentation der Systemkonfiguration von Routern und
Switches) die sichere Einrichtung der Systeme eine groe Rolle (siehe M 4.201 Sichere lokale
Grundkonfiguration von Routern und Switches und M 4.202 Sichere Netz-Grundkonfiguration von
Routern und Switches). Beim Einsatz von Routern muss zudem darauf geachtet werden, dass die
Routing-Protokolle sicher eingesetzt werden. Abhngig vom Einsatzzweck sollten auf Routern Access
Control Lists (ACLs) konfiguriert werden (siehe M 5.111 Einrichtung von Access Control Lists auf
Routern).
Router werden auerdem oft zur sicheren Einwahl und zur Etablierung von virtuellen privaten Netzen
(VPNs) verwendet. Bei der Einrichtung von VLANs auf Switches sind einige Sicherheitsaspekte zu
bercksichtigen. Zusammenfassend ist in M 4.203 Konfigurations-Checkliste fr Router und Switches
eine Checkliste zur sicheren Konfiguration von Routern und Switches dokumentiert.
- Sicherer Betrieb von Routern und Switches
Hinweise zum sicheren Betrieb von Routern und Switches finden sich in M 2.282 Regelmige
Kontrolle von Routern und Switches , M 2.283 Software-Pflege auf Routern und Switches und M 6.91
Datensicherung und Recovery bei Routern und Switches gegeben. Aspekte der Protokollierung auf
Routern und Switches werden in M 4.205 Protokollierung bei Routern und Switches beschrieben.
Sicherheitsaspekte, die im Fall einer Strung wichtig sind, werden in M 6.92 Notfallvorsorge bei
Routern und Switches beschrieben.
- Sicherheitsaspekte bei der Auerbetriebnahme von Routern und Switches
Gespeicherte Konfigurationsdateien und Log-Dateien auf Routern und Switches verraten
Informationen ber die Netzstruktur. Bei der Auerbetriebnahme aktiver Netzkomponenten sind die
Hinweise aus M 2.284 Sichere Auerbetriebnahme von Routern und Switches zu bercksichtigen.
Nachfolgend sind die beim Einsatz von Routern und Switches zu bercksichtigenden Manahmen
aufgelistet:
Infrastruktur:
- M 1.43 (1) Gesicherte Aufstellung aktiver Netzkomponenten
Organisation:
- M 2.276 (opt) Funktionsweise eines Routers
- M 2.277 (opt) Funktionsweise eines Switches
- M 2.278 (opt) Typische Einsatzszenarien von Routern und Switches
- M 2.279 (1) Erstellung einer Sicherheitsrichtlinie fr Router und Switches
- M 2.280 (3) Kriterien fr die Beschaffung und geeignete Auswahl von Routern und Switches
- M 2.281 (2) Dokumentation der Systemkonfiguration von Routern und Switches
- M 2.282 (1) Regelmige Kontrolle von Routern und Switches
- M 2.283 (2) Software-Pflege auf Routern und Switches
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 2.284 (3) Sichere Auerbetriebnahme von Routern und Switches

Personal:
- M 3.38 (2) Administratorenschulung fr Router und Switches
Hardware/Software
- M 4.201 (1) Sichere lokale Grundkonfiguration von Routern und Switches
- M 4.202 (1) Sichere Netz-Grundkonfiguration von Routern und Switches
- M 4.203 (1) Konfigurations-Checkliste fr Router und Switches
- M 4.204 (1) Sichere Administration von Routern und Switches
- M 4.205 (2) Protokollierung bei Routern und Switches
- M 4.206 (3) Sicherung von Switch-Ports
- M 5.111 (3) Einrichtung von Access Control Lists auf Routern

- M 5.112 (3) Sicherheitsaspekte von Routing-Protokollen
- M 6.91 (2) Datensicherung und Recovery bei Routern und Switches

- M 6.92 (2) Notfallvorsorge bei Routern und Switches
_________________________________________________________________________________________
Telekommunikation 8
_________________________________________________________________________________________
8 Telekommunikation
IT-Grundschutz wird fr folgende Einsatzfelder der Telekommunikation definiert:
8.1 TK-Anlage
8.2 Faxgert
8.4 LAN-Anbindung eines IT-Systems ber ISDN
8.5 Faxserver
8.6 Mobiltelefon
8.7 PDA
_________________________________________________________________________________________
TK-Anlage 8.1
_________________________________________________________________________________________
8.1 TK-Anlage
Beschreibung
Die private, digitale ISDN-Telekommunikations-Anlage
(TK-Anlage) stellt sowohl eine Kommunikationsbasis fr
den eigenen Bereich als auch die Schnittstelle zum
ffentlichen Netz dar. Sie dient der bertragung von
Sprache und Bildern (Fax) und in zunehmendem Ma als
LAN bzw. LAN-Koppler sowie als bertragungsmedium
fr elektronische Mailsysteme. Bei der Nutzung als LAN
ist das Kapitel 6.1 Servergesttztes Netz zu beachten.
Es wird davon ausgegangen, dass ein Verantwortlicher
fr die TK-Anlage benannt ist, der die grundstzlichen Sicherheitsentscheidungen fllen und
Sicherheitsmanahmen initiieren kann.
Gefhrdungslage
Fr den IT-Grundschutz einer TK-Anlage werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
- G 1.4 Feuer
- G 3.7 Ausfall der TK-Anlage durch Fehlbedienung
- G 5.11 Vertraulichkeitsverlust in TK-Anlagen gespeicherter Daten
- G 5.12 Abhren von Telefongesprchen und Datenbertragungen
- G 5.13 Abhren von Rumen
- G 5.14 Gebhrenbetrug
- G 5.15 "Neugierige" Mitarbeiter
- G 5.44 Missbrauch von Remote-Zugngen fr Managementfunktionen von TK-Anlagen
Es werden hier solche Gefhrdungen betrachtet, die die Funktionsfhigkeit einer Institution beein-
trchtigen knnen. Datenschutzrechtliche Erwgungen stehen somit nicht im Vordergrund. Diesen
wird bereits zu groen Teilen durch bestehende Betriebs- bzw. Dienstvereinbarungen Rechnung getra-
gen. Gleichwohl trgt der IT-Grundschutz natrlich auch zum Schutz der personenbezogenen Daten
bei.
_________________________________________________________________________________________
TK-Anlage 8.1
_________________________________________________________________________________________
Die zentralen Einrichtungen einer TK-Anlage sollten in einem Raum aufgestellt werden, der den
Anforderungen an einen Serverraum (Kapitel 4.3.2) oder einen Raum fr technische Infrastruktur
(Kapitel 4.3.4) gengt. Fr die Verkabelung der TK-Anlage wird auf Kapitel 4.2 hingewiesen.
Nachfolgend wird das Manahmenbndel fr den Bereich "TK-Anlage" vorgestellt:
Infrastruktur:
- M 1.13 (3) Anordnung schtzenswerter Gebudeteile
- M 1.22 (2) Materielle Sicherung von Leitungen und Verteilern (optional)
- M 1.30 (2) Absicherung der Datentrger mit TK-Gebhrendaten
Organisation:
- M 2.27 (1) Verzicht auf Fernwartung der TK-Anlage (optional)
- M 2.28 (3) Bereitstellung externer TK-Beratungskapazitt (optional)
- M 2.29 (2) Bedienungsanleitung der TK-Anlage fr die Benutzer
- M 2.105 (1) Beschaffung von TK-Anlagen
Personal:
- M 3.12 (2) Information aller Mitarbeiter ber mgliche TK-Warnanzeigen, -symbole und -
tne
- M 3.13 (2) Sensibilisierung der Mitarbeiter fr mgliche TK-Gefhrdungen
Hardware/Software:
- M 4.5 (2) Protokollierung der TK-Administrationsarbeiten
- M 4.6 (2) Revision der TK-Anlagenkonfiguration
- M 4.8 (1) Schutz des TK-Bedienplatzes
- M 4.10 (2) Passwortschutz fr TK-Endgerte
- M 4.11 (2) Absicherung der TK-Anlagen-Schnittstellen
- M 4.12 (1) Sperren nicht bentigter TK-Leistungsmerkmale
- M 4.62 (2) Einsatz eines D-Kanal-Filters (optional)
Kommunikation:
- M 5.14 (1) Absicherung interner Remote-Zugnge
_________________________________________________________________________________________
TK-Anlage 8.1
_________________________________________________________________________________________
- M 5.15 (1) Absicherung externer Remote-Zugnge

Notfallvorsorge:
- M 6.10 (2) Notfall-Plan fr DF-Ausfall
- M 6.26 (2) Regelmige Datensicherung der TK-Anlagen-Konfigurationsdaten
- M 6.28 (3) Vereinbarung ber Lieferzeiten "lebensnotwendiger" TK-Baugruppen (optional)
- M 6.29 (2) TK-Basisanschluss fr Notrufe (optional)
- M 6.30 (3) Katastrophenschaltung (optional)
_________________________________________________________________________________________
Faxgert 8.2
_________________________________________________________________________________________
8.2 Faxgert
Beschreibung
Betrachtet wird die Informationsbermittlung in Form
eines Faksimile (Fax). Fr die Manahmenauswahl im
Bereich IT-Grundschutz wurde nicht nach dem
verwendeten bertragungsstandard (z. B. CCITT Gruppe
3) unterschieden. In diesem Baustein werden als
technische Basis des Faxversands ausschlielich
marktbliche Stand-Alone-Faxgerte betrachtet, nicht
jedoch Fax-Einschubkarten oder Faxserver (siehe Kapitel
8.5 Faxserver).
Gefhrdungslage
Fr den IT-Grundschutz werden bei der Informationsbermittlung per Fax folgende typische
- G 2.20 Unzureichende oder falsche Versorgung mit Verbrauchsgtern
- G 3.14 Fehleinschtzung der Rechtsverbindlichkeit eines Fax
- G 4.14 Verblassen spezieller Faxpapiere
- G 4.15 Fehlerhafte Faxbertragung
- G 5.30 Unbefugte Nutzung eines Faxgertes oder eines Faxservers
- G 5.31 Unbefugtes Lesen von Faxsendungen
- G 5.32 Auswertung von Restinformationen in Faxgerten und Faxservern
- G 5.33 Vortuschen eines falschen Absenders bei Faxsendungen
- G 5.34 Absichtliches Umprogrammieren der Zieltasten eines Faxgertes
- G 5.35 berlastung durch Faxsendungen
("Bausteine") wie in Kapitel 2.3 und 2.4 beschrieben auszuwhlen. Nachfolgend wird das
Manahmenbndel fr den Bereich "Faxgert" vorgestellt:
Infrastruktur:
- M 1.37 (1) Geeignete Aufstellung eines Faxgertes
Organisation:
- M 2.47 (2) Ernennung eines Fax-Verantwortlichen
- M 2.48 (2) Festlegung berechtigter Faxbediener (optional)
- M 2.48 (2) Festlegung berechtigter Faxbediener (optional)
- M 2.49 (2) Beschaffung geeigneter Faxgerte
- M 2.50 (2) Geeignete Entsorgung von Fax-Verbrauchsgtern und -Ersatzteilen
- M 2.51 (3) Fertigung von Kopien eingehender Faxsendungen (optional)
_________________________________________________________________________________________
Faxgert 8.2
_________________________________________________________________________________________
- M 2.52 (3) Versorgung und Kontrolle der Verbrauchsgter

- M 2.53 (3) Abschalten des Faxgertes auerhalb der Brozeiten (optional)
Personal:
- M 3.15 (1) Informationen fr alle Mitarbeiter ber die Faxnutzung
Hardware/Software:
- M 4.36 (2) Sperren bestimmter Faxempfnger-Rufnummern (optional)
- M 4.37 (3) Sperren bestimmter Absender-Faxnummern (optional)
- M 4.43 (2) Faxgert mit automatischer Eingangskuvertierung (optional)
Kommunikation:
- M 5.24 (1) Nutzung eines geeigneten Faxvorblattes
- M 5.25 (2) Nutzung von Sende- und Empfangsprotokollen
- M 5.26 (2) Telefonische Ankndigung einer Faxsendung (optional)
- M 5.27 (2) Telefonische Rckversicherung ber korrekten Faxempfang (optional)
- M 5.28 (2) Telefonische Rckversicherung ber korrekten Faxabsender (optional)
- M 5.29 (2) Gelegentliche Kontrolle programmierter Zieladressen und Protokolle
Notfallvorsorge:
- M 6.39 (3) Auflistung von Hndleradressen zur Fax-Wiederbeschaffung (optional)
_________________________________________________________________________________________
Anrufbeantworter 8.3
_________________________________________________________________________________________
Beschreibung
Betrachtet werden Anrufbeantworter, die zustzlich zum
Telefon an das lokale Haus-Telefonnetz angeschlossen
werden knnen. Sie dienen blicherweise der Aufzeich-
nung eingehender Gesprche oder Nachrichten in
gesprochener Form, wenn der Angerufene nicht erreich-
bar ist. Technisch unterscheiden sich diese Gerte durch
unterschiedliche Aufzeichnungsweisen: vollstndig
analog aufzeichnende Gerte, vollstndig digital
aufzeichnende Gerte und Kombinationsformen. Insbe-
sondere das heute verbreitete Leistungsmerkmal der
Fernabfrage legt es nahe, Anrufbeantworter als IT-System aufzufassen, wobei gerade die Fernabfrage
ein erhebliches Gefhrdungspotential darstellen kann.
Gefhrdungslage
Fr den IT-Grundschutz eines Anrufbeantworters werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 3.15 Fehlbedienung eines Anrufbeantworters
- G 4.18 Entladene oder beralterte Notstromversorgung im Anrufbeantworter
- G 4.19 Informationsverlust bei erschpftem Speichermedium
- G 5.36 Absichtliche berlastung des Anrufbeantworters
- G 5.37 Ermitteln des Sicherungscodes
- G 5.38 Missbrauch der Fernabfrage
Nachfolgend wird das Manahmenbndel fr den Bereich "Anrufbeantworter" vorgestellt.
_________________________________________________________________________________________
Anrufbeantworter 8.3
_________________________________________________________________________________________
Infrastruktur:
- M 1.23 (3) Abgeschlossene Tren (optional)
Organisation:
- M 2.4 (3) Regelungen fr Wartungs- und Reparaturarbeiten (optional)
- M 2.11 (2) Regelung des Passwortgebrauchs
- M 2.54 (1) Beschaffung geeigneter Anrufbeantworter
- M 2.55 (1) Einsatz eines Sicherungscodes (optional)
- M 2.56 (1) Vermeidung schutzbedrftiger Informationen auf dem Anrufbeantworter
- M 2.57 (2) Regelmiges Abhren und Lschen aufgezeichneter Gesprche
- M 2.58 (3) Begrenzung der Sprechdauer (optional)
Personal:
- M 3.16 (2) Einweisung in die Bedienung des Anrufbeantworters
Hardware/Software:
- M 4.38 (1) Abschalten nicht bentigter Leistungsmerkmale
- M 4.39 (3) Abschalten des Anrufbeantworters bei Anwesenheit (optional)
Notfallvorsorge:
- M 6.40 (3) Regelmige Batterieprfung/-wechsel (optional)
_________________________________________________________________________________________
LAN-Anbindung eines IT-Systems ber ISDN 8.4
_________________________________________________________________________________________
8.4 LAN-Anbindung eines IT-Systems

ber ISDN
Beschreibung
ISDN (Integrated Services Digital Network) ist ein digi-
tales Telekommunikationsnetz, ber das verschiedene
Dienste, wie Telefon und Telefax, genutzt sowie Daten
und Bilder bertragen werden knnen.
In diesem Kapitel wird die Anbindung eines abgesetzten
IT-Systems an ein lokales Netz ber ein ffentliches
ISDN-Netz betrachtet. Hierbei erfolgt die Anbindung auf
Seiten des abgesetzten IT-Systems mittels einer ISDN-
Adapterkarte mit S0-Schnittstelle. Die Anbindung des LAN wird ber einen Router hergestellt, der
ber eine S2M-Schnittstelle mit einem ffentlichen ISDN-Netz verbunden ist.
Diese Form der Anbindung eines entfernt stehenden IT-Systems kommt typischerweise fr die
Anbindung von Telearbeitspltzen in Betracht.
Gefhrdungslage
Fr den Grundschutz werden die folgenden Gefhrdungen als typisch fr die LAN-Anbindung eines
IT-Systems ber ISDN angenommen:
Hhere Gewalt:
- G 4.25 Nicht getrennte Verbindungen
_________________________________________________________________________________________
_________________________________________________________________________________________

- G 5.14 Gebhrenbetrug
- G 5.25 Maskerade
- G 5.61 Missbrauch von Remote-Zugngen fr Managementfunktionen von Routern
- G 5.62 Missbrauch von Ressourcen ber abgesetzte IT-Systeme
- G 5.63 Manipulationen ber den ISDN-D-Kanal
In diesem Kapitel steht die Gewhrleistung einer sicheren Kommunikation im Vordergrund. Die fr
die kommunizierenden IT-Systeme weiterhin erforderlichen Manahmen sind den jeweiligen Kapiteln
(fr das LAN siehe Kapitel 6, fr das entfernt stehende IT-System siehe Kapitel 5) zu entnehmen.
Nachfolgend wird das Manahmenbndel fr den Bereich LAN-Anbindung eines IT-Systems ber
ISDN vorgestellt.
Infrastruktur:
- M 1.43 (2) Gesicherte Aufstellung aktiver Netzkomponenten,
Organisation:
- M 2.46 (2) Geeignetes Schlsselmanagement
- M 2.106 (2) Auswahl geeigneter ISDN-Karten in der Beschaffung
- M 2.107 (2) Dokumentation der ISDN-Karten-Konfiguration
- M 2.108 (2) Verzicht auf Fernwartung der ISDN-Netzkoppelelemente (optional)
- M 2.109 (1) Rechtevergabe fr den Fernzugriff
Personal:
Hardware/Software:
- M 4.59 (1) Deaktivieren nicht bentigter ISDN-Karten-Funktionalitten
- M 4.60 (1) Deaktivieren nicht bentigter ISDN-Router-Funktionalitten
- M 4.61 (1) Nutzung vorhandener Sicherheitsmechanismen der ISDN-Komponenten
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 4.62 (2) Einsatz eines D-Kanal-Filters (optional)

Kommunikation:
- M 5.29 (2) Gelegentliche Kontrolle programmierter Zieladressen und Protokolle
- M 5.47 (1) Einrichten einer Closed User Group (optional)
- M 5.48 (1) Authentisierung mittels CLIP/COLP
- M 5.49 (1) Callback basierend auf CLIP/COLP
- M 5.50 (1) Authentisierung mittels PAP/CHAP
_________________________________________________________________________________________
Faxserver 8.5
_________________________________________________________________________________________
8.5 Faxserver
Beschreibung
Betrachtet wird die Informationsbermittlung in Form
eines Faksimile (Fax). Fr die Manahmenauswahl im
Bereich IT-Grundschutz wird nicht nach dem
verwendeten bertragungsstandard (z. B. CCITT
Gruppe 3) unterschieden. In diesem Baustein werden als
technische Basis des Fax-Verkehrs ausschlielich
Faxserver betrachtet. Ein Faxserver in diesem Sinne ist
eine Applikation, die auf einem IT-System installiert ist
und in einem Netz fr andere IT-Systeme die Dienste
Faxversand und/oder Faxempfang zur Verfgung stellt.
Faxserver werden in der Regel in bereits bestehende E-Mailsysteme integriert. So ist es u. a. mglich,
dass eingehende Fax-Dokumente durch den Faxserver per E-Mail an den Benutzer zugestellt werden.
Abzusendende Dokumente werden entweder ber eine Druckerwarteschlange oder per E-Mail an den
Faxserver bergeben. Durch die Integration des Faxservers in ein E-Mail-System ist es auch mglich,
"Serienbriefe" wahlweise per Fax und per E-Mail zu versenden. Sofern ein Adressat ber einen E-
Mail-Zugang verfgt, erhlt er die Nachricht kostengnstig per E-Mail, ansonsten per Fax. Das von
einem Faxserver gesendete oder empfangene Dokument ist eine Grafik-Datei, die nicht unmittelbar in
Textverarbeitungssystemen weiterverarbeitet werden kann. Mglich ist aber auf jeden Fall die
Archivierung. Dies kann durch die Faxserver-Software oder auch in Dokumentenmanagement-
systemen erfolgen.
Faxserver gibt es fr eine Reihe von Betriebssystemen wie z. B. fr verschiedene Unix-Derivate,
Microsoft Windows NT und Novell Netware. berlegungen zu Gefhrdungen und Manahmen, die
durch das jeweils verwendete Betriebssystem bedingt werden, sind nicht Gegenstand dieses Bausteins.
Vielmehr sind hierzu das Kapitel 6.1 und das jeweils betriebssystemspezifische Kapitel
durchzuarbeiten.
Faxserver verfgen hufig zustzlich ber den Binary-Transfer-Mode. Hiermit werden beliebige
Daten, die nicht im Fax-Format vorliegen, bertragen. Es handelt sich dabei nicht um
Faxbertragungen. Daher werden spezielle Gefhrdungen und Manahmen, die diesen Dienst
betreffen, nicht in diesem Kapitel betrachtet. Wird der Binary-Transfer-Mode zugelassen, so ist
zustzlich Kapitel 7.2 Modem zu bearbeiten.
Gefhrdungslage
Fr den IT-Grundschutz werden bei der Informationsbermittlung per Fax mittels eines Faxservers
- G 2.63 Ungeordnete Faxnutzung
- G 3.14 Fehleinschtzung der Rechtsverbindlichkeit eines Fax
_________________________________________________________________________________________
Faxserver 8.5
_________________________________________________________________________________________
- G 4.15 Fehlerhafte Faxbertragung
- G 5.25 Maskerade
- G 5.30 Unbefugte Nutzung eines Faxgertes oder eines Faxservers
- G 5.31 Unbefugtes Lesen von Faxsendungen
- G 5.32 Auswertung von Restinformationen in Faxgerten und Faxservern
- G 5.33 Vortuschen eines falschen Absenders bei Faxsendungen
- G 5.35 berlastung durch Faxsendungen
- G 5.90 Manipulation von Adressbchern und Verteillisten
Zunchst sollte eine bergreifende Sicherheitsleitlinie fr den Faxserver erarbeitet werden (siehe
M 2.178 Erstellung einer Sicherheitsleitlinie fr die Faxnutzung) und ein geeigneter Faxserver
beschafft werden (siehe M 2.181 Auswahl eines geeigneten Faxservers). Hieraus mssen Regelungen
abgeleitet werden. Schlielich sind Verantwortliche fr den Einsatz des Faxservers zu benennen (siehe
M 3.10 Auswahl eines vertrauenswrdigen Administrators und Vertreters und M 2.180 Einrichten
einer Fax-Poststelle). Sowohl die Sicherheitsleitlinie als auch die daraus folgenden Regelungen und
die Benennung von Verantwortlichen sollte schriftlich erfolgen. Die dort erarbeiteten Festlegungen
sollten sodann in konkrete Sicherheitsmanahmen umgesetzt werden. Neben dem sicheren Betrieb des
Faxservers ist von besonderer Bedeutung, dass von den Benutzern die entsprechenden
Sicherheitsvorkehrungen und Anweisungen eingehalten werden.
Nachfolgend wird das Manahmenbndel fr die Applikation "Faxserver" vorgestellt:
Organisation:
- M 2.178 (1) Erstellung einer Sicherheitsleitlinie fr die Faxnutzung
- M 2.179 (1) Regelungen fr den Faxserver-Einsatz
- M 2.180 (1) Einrichten einer Fax-Poststelle
- M 2.181 (1) Auswahl eines geeigneten Faxservers
Personal:
- M 3.15 (1) Informationen fr alle Mitarbeiter ber die Faxnutzung
_________________________________________________________________________________________
Faxserver 8.5
_________________________________________________________________________________________
Hardware/Software:
- M 4.36 (2) Sperren bestimmter Faxempfnger-Rufnummern (optional)
- M 4.37 (2) Sperren bestimmter Absender-Faxnummern (optional)
Kommunikation:
- M 5.24 (1) Nutzung eines geeigneten Faxvorblattes
- M 5.25 (2) Nutzung von Sende- und Empfangsprotokollen
- M 5.26 (2) Telefonische Ankndigung einer Faxsendung (optional)
- M 5.27 (2) Telefonische Rckversicherung ber korrekten Faxempfang (optional)
- M 5.28 (2) Telefonische Rckversicherung ber korrekten Faxabsender (optional)
- M 5.73 (1) Sicherer Betrieb eines Faxservers
- M 5.74 (1) Pflege der Faxserver-Adressbcher und der Verteillisten
- M 5.75 (1) Schutz vor berlastung des Faxservers
Notfallvorsorge:
- M 6.69 (1) Notfallvorsorge und Ausfallsicherheit bei Faxservern
_________________________________________________________________________________________
Mobiltelefon 8.6
_________________________________________________________________________________________
8.6 Mobiltelefon
Beschreibung
Mobiltelefone sind inzwischen nicht mehr wegzu-
denkende Bestandteile der Kommunikationsinfrastruktur
geworden. Damit stellt sich die Frage nach deren sicheren
Nutzung.
In diesem Kapitel werden digitale Mobilfunksysteme
nach dem GSM-Standard (D- und E-Netze) betrachtet.
Um deren sicheren Einsatz zu gewhrleisten, mssen
verschiedene Komponenten und deren Zusammenspiel
betrachtet werden (siehe Bild):
- Mobiltelefon
- Basisstation
- Festnetz
Mobiltelefon
Ein Mobiltelefon besteht aus zwei Komponenten: Dem Mobilfunkgert selbst und dem Identifi-
kationsmodul, der SIM-Karte (SIM - Subscriber Identity Module). Damit kann im GSM-Netz
zwischen Benutzer und Gert unterschieden werden.
Das Mobilfunkgert ist gekennzeichnet durch seine international eindeutige Seriennummer (IMEI
- International Mobile Equipment Identity). Der Benutzer wird durch seine auf der SIM-Karte gespei-
cherten Kundennummer (IMSI - International Mobile Subscriber Identity) identifiziert. Sie wird dem
Teilnehmer beim Vertragsabschluss vom Netzbetreiber zugeteilt. Sie ist zu unterscheiden von den ihm
zugewiesenen Telefonnummern (MSISDN). Durch diese Trennung ist es mglich, dass ein Teil-
nehmer mit seiner SIM-Karte verschiedene Mobilfunkgerte nutzen kann.
_________________________________________________________________________________________
Mobiltelefon 8.6
_________________________________________________________________________________________
Auf der SIM-Karte wird u. a. die teilnehmerbezogene Rufnummer (MSISDN) gespeichert. Ebenso
sind dort die kryptographischen Algorithmen fr die Authentisierung und Nutzdatenverschlsselung
implementiert. Darber hinaus knnen dort Kurznachrichten, Gebhreninformationen und ein
persnliches Telefonbuch gespeichert werden.
SIM-Toolkit
Seit 1999 sind Mobiltelefone und SIM-Karten auf dem Markt, bei denen die Menfunktionen der
Mobiltelefone erweitert wurden. Dieser neue Standard "SIM-Toolkit" definiert neue Funktionen
zwischen SIM-Karte und Mobilfunkgert. Damit knnen im laufenden Betrieb neue Daten und
Programme vom Netzbetreiber heruntergeladen werden. Mit SIM-Toolkit lassen sich so ganz neue
Serviceangebote realisieren. Beispielsweise bietet es dem Kartenanbieter die Mglichkeit, die Men-
struktur des Mobiltelefons den Bedrfnissen der Kunden anzupassen. Mchte der Kunde ber sein
Mobiltelefon eine Hotelreservierung vornehmen oder eine Reise buchen, wird die Menstruktur des
Mobiltelefons vom Serviceanbieter entsprechend angepasst. Dafr mssen allerdings sowohl Karte als
auch Gert den Standard "SIM-Toolkit" untersttzen.
Basisstation
Jeder Netzbetreiber unterhlt eine Vielzahl von Sendestationen (BTS - Base Station Transceiver
System). Jede dieser Stationen kann ein Gebiet mit einem Radius von ca. 250 m bis 35 km versorgen,
je nach Sendeleistung und Gelndebeschaffenheit. Das Versorgungsgebiet einer Sendestation wird als
Funkzelle bezeichnet. Mehrere Funkzellen werden von einer Kontrollstation (BSC - Base Station
Controller) gesteuert. Der Verbund von Sendestationen und Kontrollstation heit wiederum Base
Station Subsystem (BSS) oder kurz Basisstation.
Die Basisstation stellt also die Schnittstelle zwischen dem Netz und dem Mobiltelefon dar. Hier
werden die Kanle fr die Signalisierung und den Nutzverkehr bereitgestellt. Die Basisstation wird
ber den Vermittlungsknoten (MSC) gesteuert. Dieser Vermittlungsknoten bernimmt alle tech-
nischen Funktionen eines Festnetz-Vermittlungsknotens, wie z. B. Wegsuche, Signalwegschaltung
und Dienstmerkmalsbearbeitung. Falls Verbindungswnsche zu einem Teilnehmer im Festnetz beste-
hen, werden sie vom Vermittlungsknoten ber einen Koppelpfad (GMSC) ins Festnetz weitergeleitet.
Als Besonderheit im GSM-Netz gegenber dem Festnetz kann die Verschlsselung der Daten auf der
Luftschnittstelle, d. h. zwischen Mobiltelefon und Basisstation, angesehen werden. Dies soll den
Teilnehmer gegen unbefugtes Mithren schtzen.
Register
Damit der Netzbetreiber in die Lage versetzt wird, auch alle gewnschten Dienste zu erbringen, muss
er verschiedene Daten speichern. Er muss z. B. wissen, welche Teilnehmer sein Netz nutzen und
welche Dienste sie in Anspruch nehmen wollen. Diese Daten, wie Teilnehmer, Kundennummer und
beanspruchte Dienste, werden im Heimatregister (HLR - Home Location Register) abgelegt. Soll eine
Verbindung, z. B. von einem Festnetzanschluss zu einem Mobiltelefon, hergestellt werden, muss der
Netzbetreiber wissen, wo sich der Teilnehmer befindet und ob er sein Mobiltelefon eingeschaltet hat.
Diese Informationen werden im Besucher- (VLR) und im Heimatregister (HLR) abgelegt. Um zu
prfen, ob der Teilnehmer berhaupt berechtigt ist, das Mobilfunknetz zu nutzen (also einen Karten-
vertrag besitzt), fhrt der Netzbetreiber das Identifikationsregister (AUC). Hier werden der Sicher-
heitscode der SIM-Karte sowie die vom Teilnehmer festgelegten PINs abgelegt.
Auerdem kann der Netzbetreiber noch ein Gerteregister, das EIR, fhren. Hier sind alle im Netz
zugelassenen Mobilfunkgerte registriert, aufgeteilt in drei Gruppen, den so genannten weien, grauen
und schwarzen Listen. In der weien Liste sind alle unbedenklichen Gerte registriert, die graue Liste
enthlt alle Gerte, die mglicherweise fehlerhaft sind und in der schwarzen Liste stehen
_________________________________________________________________________________________
Mobiltelefon 8.6
_________________________________________________________________________________________
all jene, die defekt oder als gestohlen gemeldet sind. Allerdings fhren nicht alle Netzbetreiber ein
Gerteregister.
Damit der Netzbetreiber eine detaillierte Abrechnung der durch den Kunden in Anspruch
genommenen Dienste erstellen kann, mssen die Verbindungsdaten gespeichert werden. Hierzu
gehren z. B. Angaben ber Kommunikationspartner (z. B. Rufnummern des Angerufenen), Zeitpunkt
und Dauer der Verbindung und die Standortkennungen der mobilen Endgerte.
Verbindungsaufbau
Sobald der Besitzer sein Mobiltelefon einschaltet, meldet es sich ber die nchstgelegene Basisstation
beim Netzbetreiber an. Mit seiner SIM-Karte und den darauf befindlichen kryptographischen Algo-
rithmen identifiziert sich der Teilnehmer gegenber dem Netzbetreiber. Die Authentikation erfolgt mit
Hilfe eines Schlssels, der nur dem Netzbetreiber und dem Teilnehmer bekannt ist. Beim Netz-
betreiber werden Daten zur Identitt des Nutzers, die Seriennummer des Mobiltelefons und die
Kennung der Basisstation, ber die seine Anmeldung erfolgt ist, protokolliert und gespeichert. Dies
erfolgt auch dann, wenn kein Gesprch gefhrt wird. Weiterhin wird jeder Verbindungsversuch
gespeichert, unabhngig vom Zustandekommen der Verbindung. Damit ist dem Netz bekannt, welcher
Teilnehmer sich im Netz befindet, und es knnen nun Verbindungen von und zum Teilnehmer
aufgebaut werden.
Festnetz
Als Festnetz wird das herkmmliche ffentliche Telefonnetz mit seinen Verbindungswegen bezeich-
net.
Da bei jeder Mobilfunkverbindung auch Festnetze benutzt werden, treten eine Reihe von Festnetz-
Gefhrdungen auch bei der Nutzung von Mobilfunknetzen auf. Der leitungsgebundene Teil eines
GSM-Netzes ist ein Spezialfall eines ISDN-Netzes. Daher sind auch die Gefhrdungen und Manah-
men, die fr ISDN gelten, grtenteils fr GSM relevant. Fr den Bereich des Datenaustausches ber
GSM ist daher Kapitel 8.4 LAN-Anbindung eines IT-Systems ber ISDN zu betrachten.
In diesem Kapitel werden diejenigen IT-Sicherheitseigenschaften von Mobiltelefonen betrachtet, die
fr die Anwender bei deren Nutzung relevant sind. Es soll ein systematischer Weg aufgezeigt werden,
wie ein Konzept zum Einsatz von Mobiltelefonen innerhalb einer Organisation erstellt und wie dessen
Umsetzung und Einbettung sichergestellt werden kann.
Gefhrdungslage
Fr den IT-Grundschutz werden im Rahmen der Nutzung von Mobiltelefonen folgende typische
- G 3.45 Unzureichende Identifikationsprfung von Kommunikationspartnern
- G 4.41 Nicht-Verfgbarkeit des Mobilfunknetzes
- G 4.42 Ausfall des Mobiltelefons oder des PDAs
_________________________________________________________________________________________
Mobiltelefon 8.6
_________________________________________________________________________________________
- G 5.4 Diebstahl
- G 5.80 Hoax
- G 5.94 Kartenmissbrauch
- G 5.95 Abhren von Raumgesprchen ber Mobiltelefone
- G 5.96 Manipulation von Mobiltelefonen
- G 5.97 Unberechtigte Datenweitergabe ber Mobiltelefone
- G 5.98 Abhren von Mobiltelefonaten
- G 5.99 Auswertung von Verbindungsdaten bei der Nutzung von Mobiltelefonen
Um Mobiltelefone sicher und effektiv einsetzen zu knnen, sollte zunchst die Mobiltelefon-Nutzung
in der Behrde bzw. im Unternehmen geregelt und Sicherheitsrichtlinien dafr erarbeitet werden
(siehe M 2.188 Sicherheitsrichtlinien und Regelungen fr die Mobiltelefon-Nutzung).
Nachfolgend wird das Manahmenbndel fr den Einsatz von Mobiltelefonen vorgestellt.
Organisation:
- M 2.188 (1) Sicherheitsrichtlinien und Regelungen fr die Mobiltelefon-Nutzung
- M 2.189 (1) Sperrung des Mobiltelefons bei Verlust
- M 2.190 (2) Einrichtung eines Mobiltelefon-Pools (optional)
Hardware/Software:
- M 4.114 (1) Nutzung der Sicherheitsmechanismen von Mobiltelefonen
- M 4.115 (2) Sicherstellung der Energieversorgung von Mobiltelefonen
Kommunikation:
- M 5.78 (3) Schutz vor Erstellen von Bewegungsprofilen bei der Mobiltelefon-Nutzung
(optional)
- M 5.79 (3) Schutz vor Rufnummernermittlung bei der Mobiltelefon-Nutzung (optional)
- M 5.80 (3) Schutz vor Abhren der Raumgesprche ber Mobiltelefone (optional)
- M 5.81 (2) Sichere Datenbertragung ber Mobiltelefone
Notfallvorsorge:
- M 6.72 (2) Ausfallvorsorge bei Mobiltelefonen
_________________________________________________________________________________________
PDA 8.7
_________________________________________________________________________________________
8.7 PDA
Beschreibung
Dieser Baustein beschftigt sich mit handtellergroen,
mobilen Endgerten zur Datenerfassung, -bearbeitung
und -kommunikation, die im folgenden der einfacheren
Lesbarkeit halber alle als PDAs (Personal Digital
Assistant) bezeichnet werden. Diese gibt es in verschie-
denen Gerteklassen, die sich nach Abmessungen und
Leistungsmerkmalen unterscheiden, dazu gehren unter
anderem:
- Organizer, um Adressen und Termine zu verwalten.
- PDAs ohne eigene Tastatur, bei denen die Dateneingabe ber das Display erfolgt (mittels Stift).
Der primre Einsatzzweck ist das Erfassen und Verwalten von Terminen, Adressen und kleinen
Notizen.
- PDAs, bei denen die Dateneingabe ber eine eingebaute Tastatur und/oder einen Touchscreen
erfolgt. Diese sollen neben dem Erfassen und Verwalten von Terminen, Adressen und kleinen
Notizen auch die Bearbeitung von E-Mail ermglichen.
- PDAs mit integriertem Mobiltelefon, sogenannte Smartphones, die damit eine eingebaute Schnitt-
stelle zur Datenbertragung besitzen. Beim Einsatz von Smartphones ist zustzlich Kapitel 8.6
Mobiltelefon umzusetzen.
- Den bergang zu "echten" Notebooks stellen sogenannte Sub-Notebooks dar, die wesentlich klei-
ner als normale Notebooks sind und daher beispielsweise weniger Peripheriegerte und
Anschlussmglichkeiten bieten, die aber unter anderem fr die Vorfhrung von Prsentationen
geeignet sind. Beim Einsatz von Sub-Notebooks ist der Baustein 5.3 Tragbarer PC umzusetzen.
Die bergnge zwischen den verschiedenen Gertetypen sind flieend und auerdem dem stndigen
Wandel der Technik unterworfen. PDA- und Mobiltelefon-Funktionalitten werden in zunehmendem
Ma kombiniert.
Eine typische Anforderungen an PDAs ist die Nutzung von Standard-Office-Anwendungen, auch
unterwegs. Zum Teil werden hierfr angepasste Varianten von Textverarbeitungs-, Tabellenkalku-
lations-, E-Mail- bzw. Kalenderprogrammen angeboten. PDAs werden aber auch zunehmend fr
sicherheitskritische Applikationen eingesetzt, wie beispielsweise die Nutzung als Authentisierungs-
token fr Zugriffe auf Unternehmensnetze (z. B. Generierung von Einmalpasswrtern), Speicherung
von Patientendaten oder die Fhrung von Kundenkarteien.
In diesem Kapitel werden diejenigen IT-Sicherheitseigenschaften von PDAs betrachtet, die fr die
Anwender bei deren Nutzung relevant sind. Es soll ein systematischer Weg aufgezeigt werden, wie ein
Konzept zum Einsatz von PDAs innerhalb einer Organisation erstellt und wie dessen Umsetzung und
Einbettung sichergestellt werden kann.
Gefhrdungslage
Fr den IT-Grundschutz werden im Rahmen der Nutzung von PDAs folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 1.15 Beeintrchtigung durch wechselnde Einsatzumgebung
_________________________________________________________________________________________
PDA 8.7
_________________________________________________________________________________________
- G 3.45 Unzureichende Identifikationsprfung von Kommunikationspartnern
- G 3.76 Fehler bei der Synchronisation mobiler Endgerte
- G 4.42 Ausfall des Mobiltelefons oder des PDAs
- G 4.51 Unzureichende Sicherheitsmechanismen bei PDAs
- G 4.52 Datenverlust bei mobilem Einsatz
- G 5.123 Abhren von Raumgesprchen ber mobile Endgerte
- G 5.124 Missbrauch der Informationen von mobilen Endgerten
- G 5.125 Unberechtigte Datenweitergabe ber mobile Endgerte
- G 5.126 Unberechtigte Foto- und Filmaufnahmen mit mobilen Endgerten
Im Rahmen des PDA-Einsatzes sind eine Reihe von Manahmen umzusetzen, beginnend mit der Kon-
zeption ber die Beschaffung bis zum Betrieb. Die Schritte, die dabei zu durchlaufen sind, sowie die
Manahmen, die in den jeweiligen Schritten beachtet werden sollten, sind im Folgenden aufgefhrt.
1. Um PDAs sicher und effektiv in Behrden oder Unternehmen einsetzen zu knnen, sollte ein Kon-
zept erstellt werden, das auf den Sicherheitsanforderungen fr die bereits vorhandenen IT-Systeme
sowie den Anforderungen aus den geplanten Einsatzszenarien beruht. Darauf aufbauend ist die
PDA-Nutzung zu regeln und Sicherheitsrichtlinien dafr zu erarbeiten (siehe M 2.304 Sicherheits-
richtlinien und Regelungen fr die PDA-Nutzung).
2. Fr die Beschaffung von PDAs mssen die aus dem Konzept resultierenden Anforderungen an die
jeweiligen Produkte formuliert und basierend darauf die Auswahl der geeigneten Produkte getrof-
fen werden (siehe M 2.305 Geeignete Auswahl von PDAs).
3. Je nach Sicherheitsanforderungen mssen die beteiligten Software-Komponenten (PDA, Synchro-
nisationssoftware, Software zum zentralen PDA-Management) unterschiedlich konfiguriert
werden. Dies betrifft vor allem die PDAs selber (siehe M 4.228 Nutzung der Sicherheits-
mechanismen von PDAs), die Synchronisationsumgebung (siehe M 4.229 Sicherer Betrieb von
PDAs) und gegebenenfalls spezielle Software zum zentralen PDA-Management.
_________________________________________________________________________________________
PDA 8.7
_________________________________________________________________________________________
Damit PDAs sicher eingesetzt werden knnen, mssen auch damit gekoppelte Arbeitsplatz-Rechner
und hier vor allem die Synchronisationsschnittstelle sicher konfiguriert sein. Geeignete IT-Sicher-
heitsempfehlungen fr Standard-Arbeitsplatz-PCs sind in den Bausteinen des Kapitels 5 beschrieben.
Nachfolgend wird das Manahmenbndel fr den Einsatz von PDAs vorgestellt.
Infrastruktur:
- M 1.33 (1) Geeignete Aufbewahrung tragbarer IT-Systeme bei mobilem Einsatz
Organisation:
- M 2.218 (2) Regelung der Mitnahme von Datentrgern und IT-Komponenten
- M 2.303 (1) Festlegung einer Strategie fr den Einsatz von PDAs
- M 2.304 (1) Sicherheitsrichtlinien und Regelungen fr die PDA-Nutzung
- M 2.305 (3) Geeignete Auswahl von PDAs
- M 2.306 (3) Verlustmeldung
Hardware/Software:
- M 4.31 (2) Sicherstellung der Energieversorgung im mobilen Einsatz
- M 4.228 (1) Nutzung der Sicherheitsmechanismen von PDAs
- M 4.229 (3) Sicherer Betrieb von PDAs
- M 4.230 (3) Zentrale Administration von PDAs
- M 4.231 (3) Einsatz zustzlicher Sicherheitswerkzeuge fr PDAs
- M 4.232 (3) Sichere Nutzung von Zusatzspeicherkarten
Kommunikation:
- M 5.121 (2) Sichere Kommunikation von unterwegs
Notfallvorsorge:
- M 6.95 (2) Ausfallvorsorge und Datensicherung bei PDAs
_________________________________________________________________________________________
Sonstige IT-Komponenten 9
_________________________________________________________________________________________
9 Sonstige IT-Komponenten
In diesem Kapitel werden IT-Grundschutzmanahmen in den nachfolgend aufgezhlten Bausteinen
vorgestellt.
9.2 Datenbanken
9.3 Telearbeit
9.5 Archivierung
_________________________________________________________________________________________
Standardsoftware 9.1
_________________________________________________________________________________________
Beschreibung
Unter Standardsoftware wird Software verstanden, die
auf dem Markt angeboten wird und im Allgemeinen ber
den Fachhandel, z. B. ber Kataloge, erworben werden
kann. Sie zeichnet sich dadurch aus, dass sie vom
Anwender selbst installiert werden soll und dass nur
geringer Aufwand fr die anwenderspezifische
Anpassung notwendig ist.
In diesem Kapitel wird eine Vorgehensweise fr den
Umgang mit Standardsoftware unter Sicherheits-
gesichtspunkten dargestellt. Dabei wird der gesamte Lebenszyklus von Standardsoftware betrachtet:
Erstellung eines Anforderungskataloges, Vorauswahl eines geeigneten Produktes, Test, Freigabe,
Installation, Lizenzverwaltung und Deinstallation.
Das Qualittsmanagementsystem des Entwicklers der Standardsoftware fllt nicht in den
Anwendungsbereich dieses Kapitels. Es wird vorausgesetzt, dass die Entwicklung der Software unter
Beachtung gngiger Qualittsstandards erfolgte.
Die beschriebene Vorgehensweise dient der Orientierung, um einen Sicherheitsprozess bezglich
Standardsoftware zu etablieren. Gegebenenfalls kann die hier aufgezeigte Vorgehensweise auch zum
Vergleich mit einem bereits eingefhrten Verfahren herangezogen werden.
Gefhrdungslage
Fr den IT-Grundschutz von "Standardsoftware" werden die folgenden typischen Gefhrdungen
betrachtet:
- G 2.28 Verste gegen das Urheberrecht
- G 2.29 Softwaretest mit Produktionsdaten
_________________________________________________________________________________________
Standardsoftware 9.1
_________________________________________________________________________________________
Nachfolgend wird das Manahmenbndel fr den Baustein "Standardsoftware" vorgestellt. Je nach
Art und Umfang der jeweiligen Standardsoftware muss erwogen werden, ob einzelne Manahmen nur
reduziert umgesetzt werden. Die Manahmen M 2.79 bis M 2.89 stellen in der angegebenen
Reihenfolge eine umfassende Beschreibung dar, wie der Lebenszyklus von Standardsoftware gestaltet
werden kann. Sie werden durch die anderen genannten Manahmen ergnzt.
Organisation:
- M 2.79 (1) Festlegung der Verantwortlichkeiten im Bereich Standardsoftware
- M 2.80 (1) Erstellung eines Anforderungskatalogs fr Standardsoftware
- M 2.81 (1) Vorauswahl eines geeigneten Standardsoftwareproduktes
- M 2.82 (1) Entwicklung eines Testplans fr Standardsoftware
- M 2.83 (1) Testen von Standardsoftware
- M 2.84 (1) Entscheidung und Entwicklung der Installationsanweisung fr Standardsoftware
- M 2.85 (1) Freigabe von Standardsoftware
- M 2.86 (2) Sicherstellen der Integritt von Standardsoftware
- M 2.87 (2) Installation und Konfiguration von Standardsoftware
- M 2.88 (2) Lizenzverwaltung und Versionskontrolle von Standardsoftware
- M 2.89 (3) Deinstallation von Standardsoftware
- M 2.90 (2) berprfung der Lieferung
Personal:
Hardware/Software:
Notfallvorsorge:
- M 6.21 (3) Sicherungskopie der eingesetzten Software (optional)
_________________________________________________________________________________________
Datenbanken 9.2
_________________________________________________________________________________________
9.2 Datenbanken
Beschreibung
Datenbanksysteme (DBS) sind ein weithin akzeptiertes
Hilfsmittel zur rechnergesttzten Organisation, Erzeu-
gung, Manipulation und Verwaltung groer Datensamm-
lungen. Ein DBS besteht aus dem so genannten Daten-
bankmanagement-System (DBMS) und einer gewissen
Anzahl von Datenbanken. Eine Datenbank ist eine
Sammlung von Daten, welche Fakten ber eine spezielle
Anwendung der realen Welt reprsentiert. Das DBMS
fungiert dabei als Schnittstelle zwischen den Benutzern
und einer Datenbank. Es stellt sicher, dass die Benutzer
auf ihre Daten effizient und unter zentralisierter Kontrolle zugreifen knnen, und dass die Daten
dauerhaft vorhanden sind.
Der Einsatz von Datenbankmanagement-Systemen in der IT ist inzwischen nicht mehr wegzudenken.
Die Flut von Daten, die erfasst, verarbeitet und ausgewertet werden mssen, kann ohne ein DBMS
nicht mehr bewltigt werden. Die Konzeption einer Datenbank und eines DBMS basiert auf einem so
genannten Datenbankmodell. Nachfolgend werden die wichtigsten Datenbankmodelle kurz
beschrieben:
Hierarchisches Datenbankmodell
Es ist die lteste existierende Variante und wird auch als Datenbankmodell der ersten Generation
bezeichnet. Die Organisation der Datenbank erfolgt in Form einer Baumstruktur. Die Knoten bzw.
Bltter einer solchen Struktur sind Dateien. Ein Knoten/Blatt hat genau einen Vorgnger. Der Zugriff
auf die Daten erfolgt immer sequentiell. Die Zugriffspfade sind durch die Baumstruktur (bzw. Datei-
struktur) festgelegt.
Relationales Datenbankmodell
Das relationale Datenbankmodell basiert auf einer strikten Trennung von Daten und Zugriffsmglich-
keiten. Die Daten werden in Form von Tabellen abgelegt, wobei eine Zeile einem Datensatz entspricht
(dieser wird Tupel genannt) und eine Spalte einem Attribut des Datensatzes. Tupel knnen nun mit
anderen Tupeln aus anderen Tabellen in einer Beziehung stehen, was durch entsprechende Relationen
gekennzeichnet wird. Im Gegensatz zum hierarchischen sind dem relationalen Datenbankmodell keine
Grenzen hinsichtlich der Zugriffsmglichkeiten auf Daten gesetzt.
Die in allen relationalen Datenbanksystemen zur Verfgung stehende Datenbanksprache ist SQL
(Standard Query Language), die durch die ISO standardisiert ist.
Objektorientiertes Datenbankmodell
Objektorientierte Datenbankmodelle stellen eine Erweiterung klassischer Datenbankmodelle dar und
verwenden einen objektorientierten (OO) Ansatz. Dieser zeichnet sich dadurch aus, dass Objekte mit
hnlichen Eigenschaften zu Klassen zusammengefasst und diese wiederum zu Klassenhierarchien
gruppiert werden knnen. Nur definierte Methoden knnen die Objekte verndern, und der Mecha-
nismus der Vererbung von Methoden und Attributen ist dabei ein zentraler Punkt des OO-Ansatzes.
Weiterhin sind neben den Standarddatentypen wie z. B. "Integer" oder "Character" auch Typkonstruk-
tore mglich, so dass komplexe Werte definiert werden knnen.
Dieses Kapitel bercksichtigt ausschlielich Datenbanken, die auf dem relationalen Datenbankmodell
basieren, da dies das derzeit am meisten verbreitete Datenbankmodell ist.
_________________________________________________________________________________________
Datenbanken 9.2
_________________________________________________________________________________________
Ein Datenbanksystem steht im allgemeinen nicht nur einem Benutzer exklusiv zur Verfgung, sondern
es muss die parallele Verarbeitung verschiedener Benutzerauftrge (so genannte Transaktionen)
ermglichen und dabei einen gewissen Grad an Fehlertoleranz gewhrleisten. Wesentlich dafr ist die
Einhaltung der folgenden vier Eigenschaften, die unter dem ACID-Prinzip bekannt sind:
- Atomaritt (Atomicity)
Eine Transaktion wird aus der Sicht des Benutzers nur vollstndig oder gar nicht ausgefhrt. Sollte
es bei der Ausfhrung zu einem Fehler bzw. Abbruch kommen, werden alle bereits gettigten
nderungen an der Datenbank wieder zurckgenommen. Dies wird durch geeignete Recovery-
Mechanismen des Datenbanksystems sichergestellt.
- Konsistenz (Consistency)
Alle Integrittsbedingungen der Datenbank werden eingehalten, d. h. eine Transaktion berfhrt
eine Datenbank immer von einem konsistenten Zustand in einen anderen konsistenten Zustand.
Dies kann u. a. durch eine geeignete Synchronisationskontrolle des Datenbanksystems gewhr-
leistet werden.
- Isolation (Isolation)
Jede Transaktion luft isoliert von anderen Transaktionen ab und ist in jeder Hinsicht unabhngig
von anderen. Dazu gehrt auch, dass jeder Transaktion nur diejenigen Daten aus der Datenbank zur
Verfgung gestellt werden, die Teil eines konsistenten Zustands sind.
- Persistenz (Durability)
Falls eine Transaktion erfolgreich beendet und dies dem Benutzer auch gemeldet wurde, berleben
die in der Datenbank erzeugten Effekte (falls es solche gibt) jeden danach auftretenden Hard- oder
Softwarefehler (es sei denn, die Festplatte mit der Datenbank wird zerstrt).
Diese Eigenschaften muss das Transaktionssystem des DBMS gewhrleisten, was mittlerweile bis auf
wenige Ausnahmen von allen kommerziellen DBMSen erfllt wird.
Datenbanksysteme stellen Standardsoftware dar, d. h. sie werden von den unterschiedlichsten Herstel-
lern auf dem Markt angeboten. Soll eine Datenbank zur Verarbeitung von Daten eingesetzt werden, so
ist im ersten Schritt eine geeignete Standardsoftware auszuwhlen. Die zugehrigen Gefhrdungen
und Manahmen aus dem Kapitel 9.1 Standardsoftware sind deshalb zustzlich zu beachten.
Datenbanken knnen nicht losgelst von der Umgebung betrachtet werden, in der sie eingesetzt
werden. Ein Stand-alone PC ist ebenso denkbar, wie ein Grorechnerumfeld oder vernetzte Unix-
Systeme. Dementsprechend sind in Abhngigkeit des Einsatzumfeldes die Gefhrdungen und
Manahmen der Kapitel 5 Nicht Vernetzte Systeme, Kapitel 6 Vernetzte Systeme und Kapitel 7
Datenbertragungseinrichtungen zu bercksichtigen. Auf eine Wiederholung von Gefhrdungen und
Manahmen dieser Kapitel wird hier aus Redundanzgrnden verzichtet, es sei denn, sie sind von
besonderer Wichtigkeit.
_________________________________________________________________________________________
Datenbanken 9.2
_________________________________________________________________________________________
Gefhrdungslage
Fr den IT- Grundschutz von Datenbanken werden die folgenden Gefhrdungen angenommen:
Hhere Gewalt:
- G 2.38 Fehlende oder unzureichende Aktivierung von Datenbank-Sicherheitsmechanismen
- G 2.39 Komplexitt eines DBMS
- G 2.41 Mangelhafte Organisation des Wechsels von Datenbank-Benutzern
- G 2.57 Nicht ausreichende Speichermedien fr den Notfall
- G 3.23 Fehlerhafte Administration eines DBMS
- G 3.24 Unbeabsichtigte Datenmanipulation
- G 4.27 Unterlaufen von Zugriffskontrollen ber ODBC
- G 4.28 Verlust von Daten einer Datenbank
- G 4.29 Datenverlust einer Datenbank bei erschpftem Speichermedium
- G 4.30 Verlust der Datenbankintegritt/-konsistenz
- G 5.64 Manipulation an Daten oder Software bei Datenbanksystemen
- G 5.65 Verhinderung der Dienste eines Datenbanksystems
("Bausteine") wie in Kapitel 2.3 und 2.4 beschrieben umzusetzen.
Es ist sinnvoll, den Datenbank-Server in einem separaten Serverraum aufzustellen. Zu realisierende
Manahmen sind in Kapitel 4.3.2 beschrieben. Sollte ein als Bro genutzter Raum gleichzeitig als
Serverraum dienen mssen, so sind zustzlich die in Kapitel 4.3.1 beschriebenen Manahmen zu
realisieren.
Wird der Datenbank-Server in einem Schutzschrank aufgestellt, ist auch das Kapitel 4.4 Schutz-
schrnke zu beachten.
_________________________________________________________________________________________
Datenbanken 9.2
_________________________________________________________________________________________
Darber hinaus sind im Bereich Datenbanken im wesentlichen die folgenden Schritte durchzufhren:
1. Anforderungen an die Datenbank-Software ermitteln
Zu Beginn muss ein Anforderungskatalog fr Standardsoftware erstellt werden, so dass eine geeig-
nete Datenbank-Software ausgewhlt werden kann (M 2.80 und M 2.124).
2. Schulung der Administratoren
Bevor die Datenbank-Software produktiv eingesetzt werden kann, sollten die zustndigen
Administratoren zum Betrieb des Datenbanksystems geschult werden (M 3.11). Dies sollte nach
Mglichkeit bereits vor deren Beschaffung geschehen.
3. Erstellung eines Datenbankkonzeptes
Vor dem Einsatz der Datenbank-Software sollte ein Datenbankkonzept erstellt werden, welches
sowohl die Installation und Konfiguration der Datenbank-Software selbst, ein ausreichendes
Benutzerkonzept, als auch die anwendungsspezifische Datenbank beinhalten sollte. Je nach Volu-
men und Einsatzbereich der Datenbank, sowie der gewhlten Datenbank-Standardsoftware kann
ein solches Konzept sehr umfangreich sein (M 2.125, M 2.129, M 2.128 und M 2.126).
4. Betrieb der Datenbank
Die Inbetriebnahme und der eigentliche Betrieb des Datenbanksystems bedeuten neben der
Umsetzung des Konzeptes eine permanente Kontrolle des DBMS, um die Verfgbarkeit, die
Datenintegritt sowie den Schutz vertraulicher Daten sicherstellen zu knnen. Die hierfr
wichtigsten Manahmen betreffen die Punkte Dokumentation (M 2.25, M 2.31, M 2.34),
Administration (M 2.130, M 2.133 und die aufgefhrten Manahmen fr Hard- und Software)
sowie Nutzung der Datenbank (M 2.65, M 3.18).
5. Notfallvorsorge
Neben den allgemein zu diesem Komplex gehrenden Manahmen gilt es insbesondere, die daten-
bankspezifischen Gegebenheiten zu bercksichtigen, um bei einem System- respektive Daten-
bankcrash den Anforderungen hinsichtlich des verkraftbaren Datenverlusts sowie der Wiederan-
laufzeit der Datenbank zu gengen (M 6.32, M 6.49, M 6.50).
Nachfolgend wird das Manahmenbndel fr den Bereich Datenbanken vorgestellt.
Organisation:
- M 2.80 (1) Erstellung eines Anforderungskatalogs fr Standardsoftware
- M 2.111 (2) Bereithalten von Handbchern
- M 2.124 (1) Geeignete Auswahl einer Datenbank-Software
- M 2.125 (1) Installation und Konfiguration einer Datenbank
- M 2.126 (1) Erstellung eines Datenbanksicherheitskonzeptes
- M 2.127 (2) Inferenzprvention
- M 2.128 (1) Zugangskontrolle einer Datenbank
- M 2.129 (1) Zugriffskontrolle einer Datenbank
- M 2.130 (1) Gewhrleistung der Datenbankintegritt
- M 2.131 (1) Aufteilung von Administrationsttigkeiten bei Datenbanksystemen
- M 2.132 (1) Regelung fr die Einrichtung von Datenbankbenutzern/-benutzergruppen
_________________________________________________________________________________________
Datenbanken 9.2
_________________________________________________________________________________________
- M 2.133 (2) Kontrolle der Protokolldateien eines Datenbanksystems

- M 2.134 (2) Richtlinien fr Datenbank-Anfragen
- M 2.135 (3) Gesicherte Datenbernahme in eine Datenbank
Personal:
Hardware/Software:
- M 4.67 (3) Sperren und Lschen nicht bentigter Datenbank-Accounts
- M 4.68 (1) Sicherstellung einer konsistenten Datenbankverwaltung
- M 4.69 (2) Regelmiger Sicherheitscheck der Datenbank
- M 4.70 (3) Durchfhrung einer Datenbankberwachung
- M 4.71 (2) Restriktive Handhabung von Datenbank-Links
- M 4.72 (2) Datenbank-Verschlsselung (optional)
- M 4.73 (2) Festlegung von Obergrenzen fr selektierbare Datenstze
Kommunikation:
- M 5.58 (1) Installation von ODBC-Treibern
Notfallvorsorge:
- M 6.48 (2) Verhaltensregeln nach Verlust der Datenbankintegritt
- M 6.49 (1) Datensicherung einer Datenbank
- M 6.50 (1) Archivierung von Datenbestnden
- M 6.51 (3) Wiederherstellung einer Datenbank
_________________________________________________________________________________________
Telearbeit 9.3
_________________________________________________________________________________________
9.3 Telearbeit
Beschreibung
Unter Telearbeit versteht man im allgemeinen
Ttigkeiten, die rumlich entfernt vom Standort des
Arbeit- bzw. Auftraggebers durchgefhrt werden, deren
Erledigung durch eine kommunikationstechnische
Anbindung an die IT des Arbeit- bzw. Auftraggebers
untersttzt wird.
Es gibt unterschiedliche Formen von Telearbeit wie z. B.
Telearbeit in Satellitenbros, Nachbarschaftsbros,
mobile Telearbeit sowie Telearbeit in der Wohnung des
Arbeitnehmers. Bei der letzteren unterscheidet man zwischen ausschlielicher Teleheimarbeit und
alternierender Telearbeit, d. h. der Arbeitnehmer arbeitet teilweise im Bro und teilweise zu Hause.
Dieses Kapitel konzentriert sich auf die Formen der Telearbeit, die teilweise oder ganz im huslichen
Umfeld durchgefhrt werden. Es wird davon ausgegangen, dass zwischen dem Arbeitsplatz zu Hause
und der Institution eine Telekommunikationsverbindung besteht, die den Austausch von Daten oder
ggf. auch den Zugriff auf Daten in der Institution ermglicht.
Die Manahmenempfehlungen dieses Kapitels umfassen vier verschiedene Bereiche:
- die Organisation der Telearbeit,
- den Telearbeitsrechner des Telearbeiters,
- die Kommunikationsverbindung zwischen Telearbeitsrechner und Institution und
- der Kommunikationsrechner der Institution zur Anbindung des Telearbeitsrechners.
Die in diesem Kapitel aufgefhrten Manahmenempfehlungen konzentrieren sich auf zustzliche
Sicherheitsanforderungen fr ein IT-System, das fr die Telearbeit eingesetzt wird. Insbesondere fr
die technischen Anteile der Telearbeit (Telearbeitsrechner, Kommunikationsverbindung und
Kommunikationsrechner) werden sicherheitstechnische Anforderungen formuliert, die bei der
konkreten Ausgestaltung durch geeignete IT-Systeme realisiert werden mssen. Fr das eingesetzte
IT-System muss weiterhin der entsprechende Baustein aus Kapitel 5 betrachtet werden sowie die in
Kapitel 4.5 fr den huslichen Arbeitsplatzes erforderlichen Manahmen.
Gefhrdungslage
Fr den IT-Grundschutz der Telearbeit werden folgende typische Gefhrdungen angenommen:
Hhere Gewalt:
_________________________________________________________________________________________
Telearbeit 9.3
_________________________________________________________________________________________

- G 2.50 Verzgerungen durch temporr eingeschrnkte Erreichbarkeit der Telearbeiter
- G 2.51 Mangelhafte Einbindung des Telearbeiters in den Informationsfluss
- G 2.52 Erhhte Reaktionszeiten bei IT-Systemausfall
- G 2.53 Unzureichende Vertretungsregelungen fr Telearbeit
- G 3.30 Unerlaubte private Nutzung des dienstlichen Telearbeitsrechners
- G 5.25 Maskerade
Eine ausreichend sichere Form der Telearbeit wird nur erreicht, wenn IT-Sicherheitsmanahmen aus
mehreren Bereichen ineinandergreifen und sich ergnzen. Wird einer dieser Bereiche vernachlssigt,
ist eine sichere Telearbeit nicht mehr mglich. Die einzelnen Bereiche und wesentlichen Manahmen
sind:
- Infrastrukturelle Sicherheit des Telearbeitsplatzes: Manahmen, die am Telearbeitsplatz zu
beachten sind, werden im Kapitel 4.5 Huslicher Arbeitsplatz beschrieben.
- Organisation der Telearbeit: sichere Telearbeit setzt organisatorische Regelungen und personelle
Manahmen voraus. Diese werden nachfolgend unter den Oberbegriffen "Organisation" und
_________________________________________________________________________________________
Telearbeit 9.3
_________________________________________________________________________________________
"Personal" beschrieben. Besonders zu beachten sind die Verpflichtungen des Telearbeiters, seine
Einweisung und die Nutzungsregelungen der Kommunikation. Sie sind in den folgenden
Manahmen beschrieben
- M 2.113 (2) Regelungen fr Telearbeit
- M 2.116 (1) Geregelte Nutzung der Kommunikationsmglichkeiten
- M 2.117 (1) Regelung der Zugriffsmglichkeiten des Telearbeiters
- M 3.21 (1) Sicherheitstechnische Einweisung und Fortbildung des Telearbeiters
- Sicherheit des Telearbeitsrechners: der Telearbeitsrechner muss so gestaltet sein, dass im
unsicheren Einsatzumfeld eine sichere Nutzung mglich ist. Insbesondere darf nur eine autorisierte
Person den Telearbeitsrechner offline und online nutzen knnen. Die notwendigen Manahmen
sind unter dem Oberbegriff "Hardware/Software" und "Notfallvorsorge" zusammengefasst. Dabei
sind insbesondere die Sicherheitsanforderungen aus M 4.63 Sicherheitstechnische Anforderungen
an den Telearbeitsrechner zu beachten.
- Sichere Kommunikation zwischen Telearbeitsrechner und Institution: da die Kommunikation ber
ffentliche Netze ausgefhrt wird, sind besondere Sicherheitsanforderungen fr die
Kommunikation zwischen Telearbeitsrechner und Institution zu erfllen. Sie sind in M 5.51
Sicherheitstechnische Anforderungen an die Kommunikationsverbindung Telearbeitsrechner -
Institution beschrieben. Fr die Anbindung des Telearbeitsrechners ber das ffentliche Netz ist
Kapitel 8.4 LAN-Anbindung eines IT-Systems ber ISDN zu beachten. Fr die Anbindung des
Telearbeitsrechners ber einen Remote-Access-Service (RAS) ist Kapitel 7.6 Remote Access zu
beachten.
- Sicherheit des Kommunikationsrechners der Institution: dieser Rechner stellt eine quasi ffentlich
zugngliche Schnittstelle dar, ber die der Telearbeiter die IT und die Daten der Institution nutzen
kann. Da hier ein Missbrauch durch Dritte verhindert werden muss, sind besondere
Sicherheitsanforderungen zu erfllen, die in M 5.52 Sicherheitstechnische Anforderungen an den
Kommunikationsrechner beschrieben sind.
Nachfolgend wird das Manahmenbndel fr den Bereich "Telearbeit" vorgestellt.
Organisation:
- M 2.113 (2) Regelungen fr Telearbeit
- M 2.114 (2) Informationsfluss zwischen Telearbeiter und Institution
- M 2.115 (2) Betreuungs- und Wartungskonzept fr Telearbeitspltze
- M 2.116 (1) Geregelte Nutzung der Kommunikationsmglichkeiten
- M 2.117 (1) Regelung der Zugriffsmglichkeiten des Telearbeiters
- M 2.205 (1) bertragung und Abruf personenbezogener Daten
- M 2.241 (1) Durchfhrung einer Anforderungsanalyse fr den Telearbeitsplatz
Personal:
- M 3.21 (1) Sicherheitstechnische Einweisung und Fortbildung des Telearbeiters
- M 3.22 (2) Vertretungsregelung fr Telearbeit
_________________________________________________________________________________________
Telearbeit 9.3
_________________________________________________________________________________________
Hardware/Software:
Datenbertragung
- M 4.63 (1) Sicherheitstechnische Anforderungen an den Telearbeitsrechner
Kommunikation:
- M 5.51 (1) Sicherheitstechnische Anforderungen an die Kommunikationsverbindung
Telearbeitsrechner - Institution
- M 5.52 (1) Sicherheitstechnische Anforderungen an den Kommunikationsrechner
Notfallvorsorge:
- M 6.13 (2) Erstellung eines Datensicherungsplans
- M 6.38 (2) Sicherungskopie der bermittelten Daten
- M 6.47 (2) Aufbewahrung der Backup-Datentrger fr Telearbeit
_________________________________________________________________________________________
Novell eDirectory 9.4
_________________________________________________________________________________________

Beschreibung
Novell eDirectory ist ein komplexes und vielseitiges
Produkt, welches
- einerseits innerhalb eines Behrden- oder Unter-
nehmensnetzes das Management der eingebundenen
Ressourcen und deren Benutzer plattformbergreifend
bernehmen kann und
- andererseits auch als Internet-Informationsbasis mit
gesicherten und standardisierten Zugriffsmg-
lichkeiten via geeigneter Clients einsetzbar ist.
Diese beiden Szenarien ergeben vllig unterschiedliche Gefhrdungen fr den Einsatz und den Betrieb
eines solchen Systems. Vor allem eine Kombination dieser Einsatzszenarien stellt vom Standpunkt der
IT-Sicherheit eine Herausforderung dar.
Entsprechend muss fr die Sicherheit der in einem eDirectory-Verzeichnis gespeicherten Daten stets
auch die Sicherheit des zugrunde liegenden Betriebssystems mit bercksichtigt werden. Letzteres ist
jedoch nicht Bestandteil dieses Bausteins und es wird deshalb auf die entsprechenden Beschreibungen
zum sicheren Betrieb des genutzten Betriebssystems in Kapitel 6 des IT-Grundschutzhandbuchs ver-
wiesen.
eDirectory ist aus dem Verzeichnisdienst Novell Directory Services (NDS) hervorgegangen, das
Bestandteil des Betriebssystems Netware 4 war. Dies war seinerzeit die herausragende Neuerung
gegenber dem Betriebssystem Netware 3. Inzwischen positioniert Novell diese Verzeichnisdienste
als eigenstndiges Produkt eDirectory vollstndig unabhngig vom Netware-Betriebssystem.
eDirectory lsst sich dabei auf einer Vielzahl von Betriebssystemen installieren und betreiben. In der
Literatur und in den Quellen wird jedoch hufig weiterhin von "den Novell Directory Services"
gesprochen und NDS mit eDirectory synonym gesetzt.
In diesem Baustein wird speziell die eDirectory-Version 8.6 betrachtet, und zwar die englische
Version. Die Software untersttzt die Plattformen Netware, Windows NT/2000, Linux sowie Sun
Solaris.
eDirectory kann mit spezieller Clientsoftware verwendet werden, wie dem Novell Client fr die
Windows-Betriebssysteme. Diese Clients sind in den Bootvorgang des jeweiligen Rechners integriert
und bernehmen die Authentisierung der Benutzer gegen den Verzeichnisdienst eDirectory. Auch fr
Unix-Betriebssysteme (Linux, Solaris) gibt es eine hnliche Mglichkeit, die den Mechanismus der
Pluggable Authentication Modules (PAM) nutzt. Dabei kommen die Novell Account Management
Modules zum Einsatz. Auch hier werden Benutzer beim Login gegen den eDirectory-Verzeichnis-
dienst authentisiert.
Eine andere Mglichkeit bietet der Zugriff ber die LDAP-Schnittstelle. Durch die Verwendung dieser
standardisierten Schnittstelle ist die Nutzung des eDirectorys auch mit anderen Applikationen und
Systemen mglich. Fr den Einsatz im Internet ist generell das LDAP-Protokoll die Zugriffsmethode.
_________________________________________________________________________________________
_________________________________________________________________________________________
Abbildung: Architekturskizze
Weiterhin bietet die eDirectory-Software eine Vielzahl von Tools, unter anderem den iMonitor, der
berwachungs- und Diagnosemglichkeiten ber die Server eines Verzeichnisdienstes von einem
Web-Browser aus zur Verfgung stellt.
Gefhrdungslage
Aufgrund der Vielzahl an Funktionen und der Komplexitt der Software ist ein eDirectory-Verzeich-
nisdienst einer Reihe von Gefhrdungen ausgesetzt. Hinzu kommen die Gefhrdungen, die das einge-
setzte Betriebssystem betreffen, insbesondere den allgemeinen Serverzugriff und das Dateisystem.
Fr den IT-Grundschutz eines Novell eDirectory-Systems werden folgende typische Gefhrdungen
angenommen:
Hhere Gewalt:
- G 2.38 Fehlende oder unzureichende Aktivierung von Datenbank-Sicherheitsmechanismen
- G 2.69 Fehlende oder unzureichende Planung des Einsatzes von Novell eDirectory
- G 2.70 Fehlerhafte oder unzureichende Planung der Partitionierung und Replizierung im
Novell eDirectory
- G 2.71 Fehlerhafte oder unzureichende Planung des LDAP-Zugriffs auf Novell
_________________________________________________________________________________________
_________________________________________________________________________________________
- G 3.33 Fehlbedienung von Kryptomodulen
- G 3.34 Ungeeignete Konfiguration des Managementsystems
- G 3.36 Fehlinterpretation von Ereignissen
- G 3.50 Fehlkonfiguration von Novell eDirectory
- G 3.51 Falsche Vergabe von Zugriffsrechten im Novell eDirectory
- G 3.52 Fehlkonfiguration des Intranet-Clientzugriffs auf Novell eDirectory
- G 3.53 Fehlkonfiguration des LDAP-Zugriffs auf Novell eDirectory
- G 4.44 Ausfall von Novell eDirectory
- G 5.64 Manipulation an Daten oder Software bei Datenbanksystemen
- G 5.65 Verhinderung der Dienste eines Datenbanksystems
- G 5.81 Unautorisierte Benutzung eines Kryptomoduls
Zur Umsetzung des IT-Grundschutzes wird empfohlen, die dazu notwendigen Manahmenbndel
gem den Kapiteln 2.3 und 2.4 durchzufhren.
Fr den Einsatz der eDirectory-Komponenten sollte bereits bei der Planung ein spezifisches IT-Sicher-
heitskonzept erstellt werden, welches sich konsistent in das bestehende organisationsweite IT-Sicher-
heitskonzept integrieren lsst. Das eDirectory-System muss so konfiguriert werden, dass bereits beste-
hende Sicherheitsanforderungen umgesetzt werden, und hat darber hinaus weitere, eDirectory-spezi-
fische Anforderungen durchzusetzen.
_________________________________________________________________________________________
_________________________________________________________________________________________
Ein eDirectory-System wird in der Regel im Umfeld mit weiteren Systemen eingesetzt, welche den
Zugriff auf das interne Netz von auen kontrollieren. Hierbei sind insbesondere Firewall-Systeme und
Systeme zur Fernwartung zu nennen, mit denen eDirectory zusammenarbeiten muss. Aus diesem
Grund sind bei der Durchfhrung der eDirectory-spezifischen Manahmen stets auch die entsprechen-
den Manahmen aus den jeweiligen Bausteinen zustzlich betroffener Systeme mit zu bercksichti-
gen. Neben den Bausteinen aus den Kapiteln 5 und 6 sind u. a. auch die folgenden Bausteine zu
nennen:
- 7.3 Firewall, sofern eDirectory-Systeme in einer Firewall-Umgebung eingesetzt werden
- 7.6 Remote Access , wenn der Zugriff auf das eDirectory-System ber Einwahlleitungen erfolgt
- 9.2 Datenbanken allgemein
Fr die sichere Implementierung eines eDirectory-Systems sind eine Reihe von Manahmen umzu-
setzen, beginnend mit der Planung ber die Installation bis hin zum Betrieb. Die einzelnen Schritte
sowie die jeweiligen Manahmen, die auf diesem Weg zu beachten sind, sind nachstehend zusammen-
gefasst:
1. Nach der Entscheidung, eDirectory als Verzeichnissystem einzusetzen, muss Software und eventu-
ell zustzlich bentigte Hardware beschafft werden. Da eDirectory verschiedene Einsatzmglich-
keiten zulsst (siehe oben), hngt die gegebenenfalls zu beschaffende Hardware von den geplanten
Einsatzszenarien ab. Daher sind folgende Manahmen zu ergreifen:
- Zunchst muss der Einsatz des eDirectory-Systems geplant werden (siehe Manahmen
M 2.236 Planung des Einsatzes von Novell eDirectory und M 2.237 Planung der
Partitionierung und Replikation im Novell eDirectory).
- Parallel dazu ist eine Sicherheitsrichtlinie zu erarbeiten (siehe Manahme M 2.238
Festlegung einer Sicherheitsrichtlinie fr Novell eDirectory), die einerseits bereits
bestehende IT-Sicherheitsrichtlinien im Kontext von eDirectory umsetzt und gleichzeitig
eDirectory-spezifische Ergnzungen konsistent definiert.
- Vor der tatschlichen Verwendung des eDirectory-Systems im Regelbetrieb mssen die
Benutzer und Administratoren auf den Umgang mit dem Produkt geschult werden.
Insbesondere fr Administratoren empfiehlt sich eine intensive Beschftigung mit der
Materie, die auf einen umfassenden Kenntnisstand bezglich der Sicherheit der eingesetzten
Betriebssysteme aufsetzen sollte (siehe M 3.29 Schulung zur Administration von Novell
eDirectory ). Benutzern sollten die verfgbaren Sicherheitsmechanismen der eingesetzten
Clients detailliert vermittelt werden (siehe M 3.30 Schulung zum Einsatz von Novell
eDirectory Clientsoftware).
2. Nachdem die organisatorischen und planerischen Vorbereitungen durchgefhrt wurden, kann die
Installation des eDirectory-Systems erfolgen. Folgende Manahmen sind dabei zu ergreifen:
- Die Installation kann erst dann als abgeschlossen angesehen werden, wenn die eDirectory-
Systeme in einen sicheren Zustand berfhrt wurden ( M 4.153 Sichere Installation von
Novell eDirectory und siehe M 4.154 Sichere Installation der Novell eDirectory
Clientsoftware). Dadurch wird sichergestellt, dass in der anschlieenden
Konfigurationsphase nur berechtigte Administratoren auf das eDirectory-System zugreifen
knnen.
- Nach der "Rohinstallation" erfolgt eine erstmalige Konfiguration des eDirectory-Systems,
siehe M 4.155 Sichere Konfiguration von Novell eDirectory , M 4.156 Sichere Konfiguration
der Novell eDirectory Clientsoftware, M 4.157 Einrichten von Zugriffsberechtigungen auf
Novell eDirectory sowie M 4.158 Einrichten des LDAP-Zugriffs auf Novell eDirectory.
_________________________________________________________________________________________
_________________________________________________________________________________________
3. Nach der Konfiguration und einer Testbetriebsphase wird der Regelbetrieb aufgenommen. Dabei
sind unter Sicherheitsgesichtspunkten folgende Aspekte zu beachten:
- Ein eDirectory-System ist in der Regel kontinuierlichen Vernderungen unterworfen.
Entsprechend mssen die sicherheitsrelevanten Konfigurationsparameter stndig angepasst
werden. Weiterhin hngt die Sicherheit bei einer verteilten Softwarearchitektur von der
Sicherheit smtlicher Teilsysteme ab. Dies gilt insbesondere fr die eDirectory-
Clientsoftware. Die fr den sicheren Betrieb relevanten Manahmen sind in M 4.159
Sicherer Betrieb von Novell eDirectory und M 4.160 berwachen von Novell eDirectory
sowie der Manahme zur Kommunikationssicherung (siehe M 5.97 Absicherung der
Kommunikation mit Novell eDirectory) zusammengefasst.
- Neben den Manahmen zur Absicherung des laufenden Betriebs sind auch die Manahmen
zur Notfallvorsorge von zentraler Bedeutung. Hinweise zu diesem Thema finden sich in
M 6.80 Erstellen eines Notfallplans fr den Ausfall eines Novell eDirectory
Verzeichnisdienstes sowie M 6.81 Erstellen von Datensicherungen fr Novell eDirectory.
Nachfolgend wird das Manahmenbndel fr den Baustein "Novell eDirectory" vorgestellt:

Infrastruktur:
Organisation:
- M 2.236 (1) Planung des Einsatzes von Novell eDirectory
- M 2.237 (1) Planung der Partitionierung und Replikation im Novell eDirectory
- M 2.238 (1) Festlegung einer Sicherheitsrichtlinie fr Novell eDirectory
- M 2.239 (1) Planung des Einsatzes von Novell eDirectory im Intranet
- M 2.240 (1) Planung des Einsatzes von Novell eDirectory im Extranet
Personal:
- M 3.29 (1) Schulung zur Administration von Novell eDirectory
- M 3.30 (1) Schulung zum Einsatz von Novell eDirectory Clientsoftware
- M 4.34 (2) Einsatz von Verschlsselung, Checksummen oder Digitalen Signaturen
- M 4.153 (1) Sichere Installation von Novell eDirectory
- M 4.154 (1) Sichere Installation der Novell eDirectory Clientsoftware
- M 4.155 (1) Sichere Konfiguration von Novell eDirectory
- M 4.156 (1) Sichere Konfiguration der Novell eDirectory Clientsoftware
- M 4.157 (1) Einrichten von Zugriffsberechtigungen auf Novell eDirectory
_________________________________________________________________________________________
_________________________________________________________________________________________
- M 4.158 (2) Einrichten des LDAP-Zugriffs auf Novell eDirectory

- M 4.159 (1) Sicherer Betrieb von Novell eDirectory
- M 4.160 (1) berwachen von Novell eDirectory
Kommunikation:
- M 5.97 (2) Absicherung der Kommunikation mit Novell eDirectory
Notfallvorsorge:
- M 6.80 (1) Erstellen eines Notfallplans fr den Ausfall eines Novell eDirectory
Verzeichnisdienstes
- M 6.81 (1) Erstellen von Datensicherungen fr Novell eDirectory
_________________________________________________________________________________________
Archivierung 9.5
_________________________________________________________________________________________
9.5 Archivierung
Beschreibung
Die Abbildung von Geschftsprozessen und -unterlagen
in elektronische Dokumente erfordert eine geeignete Ab-
lage der entstehenden Daten fr die sptere Verwendung,
deren Wiederfinden und Aufbereitung. Dies betrifft so-
wohl Datenstze als auch elektronische Reprsentationen
papierner Geschftsdokumente und Belege. Die dauer-
hafte und unvernderbare Speicherung von elektro-
nischen Dokumenten und anderen Daten wird als Archi-
vierung bezeichnet.
Die Archivierung ist als Teil eines
Dokumentenmanagement-Prozesses zu sehen. Neben der Erzeugung, Bearbeitung und Verwaltung
elektronischer Dokumente spielt die dauerhafte Speicherung (Archivierung) eine besondere Rolle,
denn es wird blicherweise erwartet, dass einerseits die Dokumente bis zum Ablauf einer
vorgegebenen Aufbewahrungsfrist verfgbar sind und andererseits deren Vertraulichkeit- und
Integritt gewahrt bleibt. Unter Umstnden sollen elektronische Dokumente zeitlich unbegrenzt
verfgbar sein.
Die technische Ausgestaltung dieses Prozesses erfolgt ber Dokumentenmanagement- und Archiv-
systeme (siehe Abbildung). In diesem Baustein werden ausschlielich elektronische Archivsysteme
betrachtet.
Die Spannweite der Realisierungsmglichkeiten eines solchen Archivsystems umfasst:

- kleine Archivsysteme, z. B. bestehend aus einen Archivserver mit angeschlossenem Massenspei-
cher (wie Festplatte oder Jukebox), bis hin zu
- komplexen, gegebenenfalls weltweit verteilten Archivsystemen zur organisationsweiten Archivie-
rung von relevanten Geschftsdaten, bestehend aus:
- zentralen Archivserver-Komponenten mit RAID-Systemen, Jukeboxen oder der Anbindung
an Storage Area Networks (SAN) fr das zentrale Speichern von Dateien,
- WORM-Medien fr die revisionssichere, unvernderbare Speicherung von Daten,
- Komponenten zur Indizierung von Dateien, Recherche und zur Umwandlung von Speicher-
formaten (Rendition),
_________________________________________________________________________________________
Archivierung 9.5
_________________________________________________________________________________________
- dezentralen Cache-Servern fr den schnellen Zugriff auf hufig bentigte Daten,

- Client-Software, die einen direkten Zugriff auf Daten des Archivs erlaubt (z. B. auch aus
Office-Anwendungen heraus).
Es ist zweckmig, elektronische Archive gegenber Systemen zur Datensicherung abzugrenzen. Bei
einer Datensicherung werden Kopien der System- und Nutzdaten angelegt. Die gesicherten Daten
werden hierbei physikalisch vom IT-System getrennt und gefahrengeschtzt gelagert. Elektronische
Archive dagegen sind regelmig in den laufenden Systembetrieb eingebunden. Dabei werden bli-
cherweise groe Mengen von Nutzdaten (elektronischen Dokumenten) abgelegt, die aus dem elektro-
nischen Archivsystem heraus jederzeit abgerufen werden knnen. Bei besonderem Aufbau (z. B. die
redundante Auslegung der Speicherkomponenten und eine entsprechende rumliche Anordnung) kn-
nen grere Archivsysteme teilweise die Funktionalitt der Datensicherung (der Nutzdaten) berneh-
men.
In diesem Kapitel soll ein systematischer Weg aufgezeigt werden, wie ein Konzept zur elektronischen
Archivierung erstellt und wie der Aufbau eines Archivsystems und dessen Einbettung innerhalb eines
Unternehmens bzw. einer Behrde sichergestellt werden kann. Der Aufwand zur Erstellung und Um-
setzung eines solchen Konzepts ist nicht gering. Dieses Kapitel sollte immer dann angewandt werden,
wenn die zu archivierenden Daten langfristig fr die Behrde bzw. das Unternehmen relevant sind.
Gefhrdungslage
Fr die bei der elektronischen Archivierung zu betrachtenden Archivsysteme sowie die zugehrigen
Organisationsprozesse werden im Rahmen des IT-Grundschutzes die folgenden typischen Gefhrdun-
gen angenommen:
Hhere Gewalt:
- G 1.9 Datenverlust durch starke Magnetfelder
- G 1.14 Datenverlust durch starkes Licht
- G 2.72 Unzureichende Migration von Archivsystemen
- G 2.73 Fehlende Revisionsmglichkeit von Archivsystemen
- G 2.74 Unzureichende Ordnungskriterien fr Archive
- G 2.75 Mangelnde Kapazitt von Archivdatentrgern
- G 2.76 Unzureichende Dokumentation von Archivzugriffen
- G 2.77 Unzulngliche bertragung von Papierdaten in elektronische Archive
- G 2.78 Unzulngliche Auffrischung von Datenbestnden bei der Archivierung
- G 2.79 Unzureichende Erneuerung von digitalen Signaturen bei der Archivierung
- G 2.80 Unzureichende Durchfhrung von Revisionen bei der Archivierung
- G 2.81 Unzureichende Vernichtung von Datentrgern bei der Archivierung
- G 2.82 Fehlerhafte Planung des Aufstellungsortes von Archivsystemen
- G 3.54 Verwendung ungeeigneter Datentrger bei der Archivierung
- G 3.55 Versto gegen rechtliche Rahmenbedingungen beim Einsatz von Archivsystemen
_________________________________________________________________________________________
Archivierung 9.5
_________________________________________________________________________________________
- G 4.30 Verlust der Datenbankintegritt/-konsistenz
- G 4.31 Ausfall oder Strung von Netzkomponenten
- G 4.45 Verzgerte Archivauskunft
- G 4.46 Fehlerhafte Synchronisierung von Indexdaten bei der Archivierung
- G 4.47 Veralten von Kryptoverfahren
- G 5.6 Anschlag
- G 5.29 Unberechtigtes Kopieren der Datentrger
- G 5.102 Sabotage
- G 5.105 Verhinderung der Dienste von Archivsystemen
- G 5.106 Unberechtigtes berschreiben oder Lschen von Archivmedien
Darber hinaus wird die im Folgenden beschriebene Vorgehensweise fr die Einfhrung und den Be-
trieb von elektronischen Archivsystemen empfohlen. Bereits bei der Planung ist zu bercksichtigen,
dass die eingesetzten Archivsysteme und -medien im Lauf der Zeit technologisch und physikalisch
veralten werden. Daher schliet sich an eine Planungs- und Einfhrungs-/Betriebsphase eine Migrati-
onsphase an, in der das bestehende Archivsystem oder Teile davon durch neue Technologien und
Komponenten ersetzt werden. Die Migrationsphase umfasst auch die bertragung der archivierten
Daten und Dokumente in zuknftig verwendete Datenformate.
Die einzelnen Phasen und die darin umzusetzenden Manahmen sind nachfolgend kurz erlutert.
1. Planungsphase
In der Planungsphase muss die Zielsetzung , die mit dem Einsatz des Archivsystems verbunden ist,
formuliert werden (siehe M 2.242 Zielsetzung der elektronischen Archivierung). Hierbei mssen die
relevanten organisatorischen, rechtlichen und technischen Anforderungen ermittelt werden, wobei
auch abgeschtzt werden muss, wie sich die Anforderungen whrend der erwarteten Laufzeit des ein-
_________________________________________________________________________________________
Archivierung 9.5
_________________________________________________________________________________________
zufhrenden Archivsystems entwickeln werden (siehe M 2.244, M 2.245 und M 2.246). Die Ergeb-
nisse mssen in einem Archivierungskonzept niedergelegt werden (siehe M 2.243).
2. Einfhrung und Betrieb
Bei der Einfhrung eines Archivsystems ist zunchst ein System auszuwhlen, das den ermittelten
Anforderungen gengt. Darber hinaus sind der Aufstellungsort des Systems sowie der Lagerungsort
der Archivmedien festzulegen (siehe M 4.168, M 4.169, M 4.170, M 1.59, M 1.60).
Neben dem Archivsystem als solches muss ein geeignetes bergeordnetes Dokumentenmanagement-
System zur Verwaltung der Inhalte des Archivs eingefhrt werden (siehe M 2.258, M 2.259).
Es mssen die Regelungen fr die Nutzung des Archivsystems sowie den Einsatz digitaler Signaturen
festgelegt und die Administratoren und Benutzer geschult werden (siehe M 2.262, M 2.265, M 3.34,
M 3.35).
Um die Ordnungsmigkeit langfristig sicherstellen zu knnen, ist der Archivierungsprozess kontinu-
ierlich zu berwachen und auf Korrektheit zu prfen. Darber hinaus ist sicherzustellen, dass zu jedem
Zeitpunkt gengend Medien zur Archivierung verfgbar sind (siehe M 2.257, M 2.260 M 2.263,
M 4.171, M 4.172, M 4.173, M 6.84).
In Abhngigkeit der konkret eingesetzten Archivsoftware mssen auch die in Baustein 9.2 Datenban-
ken beschriebenen Manahmen umgesetzt werden.
3. Migrationsphase
Die Migrationsphase wird hufig durch Ereignisse wie die folgenden ausgelst:
- Bei Systemkomponenten oder Datenformaten hat ein Technologiewechsel stattgefunden, daher
sollten die Entwicklungen in diesem Bereich beobachtet werden (siehe M 2.261 Regelmige
Marktbeobachtung von Archivsystemen).
- Systemkomponenten, insbesondere Datentrger, sind beraltert und mssen durch neue ersetzt
werden (siehe M 2.266 Regelmige Erneuerung technischer Archivsystem-Komponenten).
- Die Nutzungskriterien fr das Archivsystem haben sich gendert.
- Kryptographische Verfahren, Produkte bzw. Schlssel mssen durch neue abgelst werden (siehe
M 2.264 Regelmige Aufbereitung von verschlsselten Daten bei der Archivierung).
Nachfolgend wird das Manahmenbndel fr den Einsatz elektronischer Archivsysteme vorgestellt:
Infrastruktur:
- M 1.59 (1) Geeignete Aufstellung von Archivsystemen
- M 1.60 (1) Geeignete Lagerung von Archivmedien
Organisation:
- M 2.242 (1) Zielsetzung der elektronischen Archivierung
- M 2.243 (1) Entwicklung des Archivierungskonzepts
- M 2.244 (1) Ermittlung der technischen Einflussfaktoren fr die elekronische Archivierung
- M 2.245 (1) Ermittlung der rechtlichen Einflussfaktoren fr die elektronische Archivierung
- M 2.246 (1) Ermittlung der organisatorischen Einflussfaktoren fr die elektronische Archi-
vierung
- M 2.257 (1) berwachung der Speicherressourcen von Archivmedien
- M 2.258 (1) Konsistente Indizierung von Dokumenten bei der Archivierung
- M 2.259 (1) Einfhrung eines bergeordneten Dokumentenmanagements
_________________________________________________________________________________________
Archivierung 9.5
_________________________________________________________________________________________
- M 2.260 (1) Regelmige Revision des Archivierungsprozesses

- M 2.261 (1) Regelmige Marktbeobachtung von Archivsystemen
- M 2.262 (1) Regelung der Nutzung von Archivsystemen
- M 2.263 (1) Regelmige Aufbereitung von archivierten Datenbestnden
- M 2.264 (1) Regelmige Aufbereitung von verschlsselten Daten bei der Archivierung
- M 2.265 (1) Geeigneter Einsatz digitaler Signaturen bei der Archivierung
- M 2.266 (1) Regelmige Erneuerung technischer Archivsystem-Komponenten
Personal:
- M 3.2 (1) Verpflichtung der Mitarbeiter auf Einhaltung einschlgiger Gesetze, Vorschriften
und Regelungen
- M 3.34 (1) Einweisung in die Administration des Archivsystems
- M 3.35 (1) Einweisung der Benutzer in die Bedienung des Archivsystems
Hardware und Software:
- M 4.168 (1) Auswahl eines geeigneten Archivsystems
- M 4.169 (1) Verwendung geeigneter Archivmedien
- M 4.170 (1) Auswahl geeigneter Datenformate fr die Archivierung von Dokumenten
- M 4.171 (1) Schutz der Integritt der Index-Datenbank von Archivsystemen
- M 4.172 (1) Protokollierung der Archivzugriffe
- M 4.173 (1) Regelmige Funktions- und Recoverytests bei der Archivierung
Notfallvorsorge:
- M 6.84 (1) Regelmige Datensicherung der System- und Archivdaten
_________________________________________________________________________________________
Gefhrdungskatalog Hhere Gewalt G1 Bemerkungen
___________________________________________________________________ ..........................................
G1 Gefhrdungskatalog Hhere Gewalt

G 1.1 Personalausfall ........................................................................... 1
G 1.2 Ausfall des IT-Systems.............................................................. 2
G 1.3 Blitz............................................................................................ 3
G 1.4 Feuer .......................................................................................... 4
G 1.5 Wasser........................................................................................ 5
G 1.6 Kabelbrand................................................................................. 6
G 1.7 Unzulssige Temperatur und Luftfeuchte.................................. 7
G 1.8 Staub, Verschmutzung ............................................................... 8
G 1.9 Datenverlust durch starke Magnetfelder.................................... 9
G 1.10 Ausfall eines Weitverkehrsnetzes............................................ 10
G 1.11 Technische Katastrophen im Umfeld....................................... 11
G 1.12 Beeintrchtigung durch Groveranstaltungen ......................... 12
G 1.13 Sturm........................................................................................ 13
G 1.14 Datenverlust durch starkes Licht ............................................. 14
G 1.15 Beeintrchtigung durch wechselnde Einsatzumgebung........... 15
___________________________________________________________________ ..........................................
Gefhrdungskatalog Hhere Gewalt G 1.1 Bemerkungen
___________________________________________________________________ ..........................................
G 1.1 Personalausfall
Durch Krankheit, Unfall, Tod oder Streik kann ein nicht vorhersehbarer
Personalausfall entstehen. Desweiteren ist auch der Personalausfall bei einer
regulren Beendigung des Arbeitsverhltnisses zu bercksichtigen,
insbesondere wenn die Restarbeitszeit z. B. durch einen Urlaubsanspruch
verkrzt wird.
In allen Fllen kann die Konsequenz sein, dass entscheidende Aufgaben auf- Schlsselstellung im
IT-Bereich
grund des Personalausfalls im IT-Einsatz nicht mehr wahrgenommen werden.
Dies ist besonders dann kritisch, wenn die betroffene Person im IT-Bereich
eine Schlsselstellung einnimmt und aufgrund fehlenden Fachwissens anderer
nicht ersetzt werden kann. Strungen des IT-Betriebs knnen die Folge sein.
Ein Personalausfall kann zustzlich einen empfindlichen Verlust von Wissen Verlust von Wissen und
Geheimnissen
und Geheimnissen nach sich ziehen, der die nachtrgliche bertragung der
Ttigkeiten auf andere Personen unmglich macht.
Beispiele:
- Aufgrund lngerer Krankheit blieb der Netzadministrator vom Dienst fern.
In der betroffenen Firma lief das Netz zunchst fehlerfrei weiter. Nach
zwei Wochen jedoch war nach einem Systemabsturz niemand in der Lage,
den Fehler zu beheben. Dies fhrte zu einem Ausfall des Netzes ber
mehrere Tage.
- Whrend des Urlaubs des Administrators muss fr Datensicherungszwecke
auf die Backupbnder im Datensicherungstresor zurckgegriffen werden.
Der Zugangscode zum Tresor wurde erst krzlich gendert und ist nur dem
Administrator bekannt. Erst nach mehreren Tagen konnte die
Datenrestaurierung durchgefhrt werden, da der Aufenthaltsort des
Administrators zuerst ermittelt werden musste.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.2 Ausfall des IT-Systems

Der Ausfall einer Komponente eines IT-Systems kann zu einem Ausfall des Ausfall zentraler
gesamten IT-Betriebs fhren. Insbesondere zentrale Komponenten eines IT- Komponenten
Systems sind geeignet, solche Ausflle herbeizufhren, z. B. LAN-Server,
Datenfernbertragungseinrichtung. Auch der Ausfall von Komponenten der
technischen Infrastruktur, beispielsweise Klima- oder Stromversorgungs-
einrichtungen, kann zu einem Ausfall des IT-Systems beitragen.
Technisches Versagen (z. B. G 4.1 Ausfall der Stromversorgung) muss nicht Technisches Versagen/
menschliche Fehlhand-
zwingend als Ursache fr den Ausfall eines IT-Systems angenommen werden. lungen
Ausflle lassen sich auch oft auf menschliches Fehlverhalten (z. B. G 3.2
Fahrlssige Zerstrung von Gert oder Daten) oder vorstzliche Handlungen
(z. B. G 5.4 Diebstahl, G 5.102 Sabotage) zurckfhren. Auch durch hhere
Gewalt (z. B. Feuer, Blitzschlag, Chemieunfall) knnen Schden eintreten,
allerdings sind diese Schden meist um ein Vielfaches hher.
Werden auf einem IT-System zeitkritische IT-Anwendungen betrieben, sind
die Folgeschden nach Systemausfall entsprechend hoch, wenn es keine
Ausweichmglichkeiten gibt.
Beispiele:
- Durch Spannungsspitzen in der Stromversorgung wird das Netzteil eines
wichtigen IT-Systems zerstrt. Da es sich um ein lteres Modell handelt,
steht nicht unmittelbar Ersatz bereit. Die Reparatur nimmt einen Tag in
Anspruch, in dieser Zeit ist der gesamte IT-Betrieb nicht verfgbar.
- Es wird eine Firmware in ein IT-System eingespielt, die nicht fr diesen
Systemtyp vorgesehen ist. Das IT-System startet daraufhin nicht mehr
fehlerfrei und muss vom Hersteller wieder betriebsbereit gemacht werden.
- Bei einem Internet Service Provider fhrte ein Stromversorgungsfehler in
einem Speichersystem dazu, dass dieses abgeschaltet wurde. Obwohl der
eigentliche Fehler schnell behoben werden konnte, lieen sich die
betroffenen IT-Systeme anschlieend nicht wieder hochfahren, da
Inkonsistenzen im Dateisystem auftraten. Bis alle Folgeprobleme behoben
waren, waren mehrere der vom ISP betriebenen WWW-Server tagelang
nicht erreichbar.
- In elektronischen Archiven kann der Zeitpunkt der erstmaligen Ausfall einer
Archivkomponente
Archivierung als Entstehungszeitpunkt von Dokumenten missinterpretiert
werden, wenn keine anderweitigen Beweisverfahren, z. B.
Zeitstempeldienste, zur Beglaubigung eingesetzt werden. Dies gilt vor
allem fr Geschftsprozesse, in die die elektronische Archivierung von
massenhaft anfallenden Belegdaten transparent eingebunden ist. Im
vorliegenden Fall konnte aufgrund des Ausfalls einer Archivkomponente
ein Teil von Belegdaten erst um einen Tag verzgert archiviert werden.
Durch die Verwendung von WORM-Medien wurde die Reihenfolge der
physikalischen Archivierung der Geschftsbelege trotzdem nachweisbar
dokumentiert, es wurde jedoch kein Nachweis fr die ansonsten nicht
auftretende Verzgerung durch die ausgefallene Archivkomponente
gefhrt. Dadurch entstand bei einer spteren Prfung der Eindruck einer
nachtrglichen Manipulation.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.3 Blitz
Der Blitz ist die wesentliche whrend eines Gewitters bestehende Gefhrdung Freisetzung elektrischer
fr ein Gebude und die darin befindliche Informationstechnik. Blitze errei- Energie
chen bei Spannungen von mehreren 100.000 Volt Strme bis zu 200.000
Ampere. Diese enorme elektrische Energie wird innerhalb von 50-100 Mikro-
sekunden freigesetzt und abgebaut. Ein Blitz mit diesen Werten, der in einem
Abstand von ca. 2 km einschlgt, verursacht auf elektrischen Leitungen im
Gebude immer noch Spannungsspitzen, die zur Zerstrung empfindlicher
elektronischer Gerte fhren knnen. Diese indirekten Schden nehmen mit
abnehmender Entfernung zu.
Schlgt der Blitz direkt in ein Gebude ein, werden durch die dynamische Gebudeschden
Energie des Blitzes Schden hervorgerufen. Dies knnen Beschdigungen des
Baukrpers (Dach und Fassade), Schden durch auftretende Brnde oder
berspannungsschden an elektrischen Gerten sein.
ber das regional unterschiedliche Blitzschlagrisiko erteilt der Deutsche
Wetterdienst entsprechende Ausknfte.
Beispiele:
- Auf einem deutschen Groflughafen schlug ein Blitz in unmittelbarer Nhe
neben dem Tower ein. Trotz der installierten ueren Blitzschutzanlage
(Blitzableiter) wurde die automatische Lschanlage im IT-Bereich ausge-
lst und dadurch der gesamte Flughafenbetrieb fr 2 Stunden lahmgelegt.
- Neben direkten Schden haben Blitzschlge auch oft weitreichendere
Folgen. Hufig finden sich Meldungen wie diese: Im April 1999 fhrte ein
Blitzeinschlag in eine Hochspannungsleitung im Raum Darmstadt zu
einem kurzzeitigen Stromausfall, von dem ca. 80.000 Personen betroffen
waren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.4 Feuer
Neben direkten durch das Feuer verursachten Schden an einem Gebude oder
dessen Einrichtung lassen sich Folgeschden aufzeigen, die insbesondere fr
die Informationstechnik in ihrer Schadenswirkung ein katastrophales Ausma
erreichen knnen. Lschwasserschden treten beispielsweise nicht nur an der
Brandstelle auf. Sie knnen auch in tiefer liegenden Gebudeteilen entstehen.
Bei der Verbrennung von PVC entstehen Chlorgase, die zusammen mit der
Luftfeuchtigkeit und dem Lschwasser Salzsure bilden. Werden die Salzsu-
redmpfe ber die Klimaanlage verteilt, knnen auf diese Weise Schden an
empfindlichen elektronischen Gerten entstehen, die in einem vom Brandort
weit entfernten Teil des Gebudes stehen. Aber auch "normaler" Brandrauch
kann auf diesem Weg beschdigend auf die IT-Einrichtung einwirken.
Ein Brand entsteht nicht nur durch den fahrlssigen Umgang mit Feuer (z. B.
Adventskranz, Schwei- und Ltarbeiten), sondern auch durch unsachgeme
Benutzung elektrischer Einrichtungen (z. B. unbeaufsichtigte Kaffeemaschine,
berlastung von Mehrfachsteckdosen). Technische Defekte an elektrischen
Gerten knnen ebenfalls zu einem Brand fhren.
Die Ausbreitung eines Brandes kann unter anderem begnstigt werden durch:
- Aufhalten von Brandabschnittstren durch Keile,
- Unsachgeme Lagerung brennbarer Materialien,
- Nichtbeachtung der einschlgigen Normen und Vorschriften,
- Fehlen von Brandmeldeeinrichtungen,
- Fehlen von Handfeuerlschern bzw. automatische Lscheinrichtungen
- mangelhaft vorbeugenden Brandschutz (z. B. Fehlen von Brandabschot-
tungen auf Kabeltrassen).
Beispiele:
- Anfang der 90er Jahre erlitt im Frankfurter Raum ein Grorechenzentrum
einen katastrophalen Brandschaden, der zu einem kompletten Ausfall
fhrte.
- Immer wieder kommt es vor, dass elektrische Kleingerte wie z. B.
Kaffeemaschinen oder Halogenlampen unsachgem installiert sind oder
betrieben werden und dadurch Brnde verursachen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.5 Wasser
Der unkontrollierte Eintritt von Wasser in Gebuden oder Rumen kann
beispielsweise bedingt sein durch:
- Regen, Hochwasser, berschwemmung,
- Strungen in der Wasser-Versorgung oder Abwasser-Entsorgung,
- Defekte der Heizungsanlage,
- Defekte an Klimaanlagen mit Wasseranschluss,
- Defekte in Sprinkleranlagen,
- Lschwasser bei der Brandbekmpfung und
- Wassersabotage z. B. durch ffnen der Wasserhhne und Verstopfen der
Abflsse.
Unabhngig davon, auf welche Weise Wasser in Gebude oder Rume
gelangt, besteht die Gefahr, dass Versorgungseinrichtungen oder IT-Kompo-
nenten beschdigt oder auer Betrieb gesetzt werden (Kurzschluss, mecha-
nische Beschdigung, Rost etc.). Wenn zentrale Einrichtungen der Gebude-
versorgung (Hauptverteiler fr Strom, Telefon, Daten) in Kellerrumen ohne
selbstttige Entwsserung untergebracht sind, kann eindringendes Wasser sehr
hohe Schden verursachen.
Beispiele:
- Viele Gewerbebetriebe, auch groe Unternehmen, tragen der Hochwasser-
gefhrdung nicht hinreichend Rechnung. So wurde ein Unternehmen
bereits mehrere Male durch Hochwasserschden am Rechenzentrum
"berrascht". Das Rechenzentrum schwamm im wahrsten Sinne des Wortes
innerhalb von 14 Monaten zum zweiten Mal davon. Der entstandene
Schaden belief sich auf mehrere hunderttausend Euro und ist nicht von
einer Versicherung gedeckt.
- In einem Serverraum verlief eine Wasserleitung unterhalb der Decke, die
mit Gipskarton verkleidet war. Als eine Verbindung undicht wurde, wurde
dies nicht rechtzeitig erkannt. Das austretende Wasser sammelte sich
zunchst an der tiefsten Stelle der Verkleidung, bevor es dort austrat und
im darunter angebrachten Stromverteiler einen Kurzschluss verursachte.
Dies fhrte dazu, dass bis zur endgltigen Reparatur sowohl die Wasser-
als auch die Stromversorgung des betroffenen Gebudeteils abgeschaltet
werden musste.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.6 Kabelbrand
Wenn ein Kabel in Brand gert, sei es durch Selbstentzndung oder durch
Beflammung, hat dies verschiedene Folgen:
- Die Verbindung kann unterbrochen werden.
- Es knnen sich aggressive Gase entwickeln. Diese knnen zum einen "aggressive" Gase
korrosiv sein, also die Informations- und Kommunikationstechnik in Mit-
leidenschaft ziehen. Sie knnen aber auch toxisch sein, also zu Personen-
schden (z. B. Vergiftung) fhren.
- An Kabeln, deren Isolationsmaterial nicht flammwidrig bzw. selbstver- Ausbreitung durch
Kabelschchte
lschend ist, kann sich ein Feuer ausbreiten. Selbst Brandabschottungen
verhindern dies nicht vollstndig, sie verzgern die Ausbreitung.
- Bei dicht gepackten Trassen kann es zu Schwelbrnden kommen, die ber
lngere Zeit unentdeckt bleiben und so zur Ausbreitung des Feuers fhren,
lange bevor es offen ausbricht.
Beispiel:
In einem ostdeutschen Verwaltungsgebude wurden die vorhandenen Elektro-
leitungen aus Kostengrnden nicht ersetzt, sondern wider besseres Wissen
berlastet. Die notwendigen Anpassungsarbeiten wurden nicht durchgefhrt,
da in Krze ein neu erstelltes Verwaltungsgebude bezogen werden sollte.
Die berlasteten Leitungen erhitzten sich und durch die sehr dichte Verlegung
kam es zu einem Hitzestau, der dann zu einem Schwelbrand fhrte. Dieser
wurde erst dann entdeckt, als die Leitungen durch die groe Hitze versagten.
Bis die vom Brand betroffenen Arbeitspltze wieder ordnungsgem benutzt
werden konnten, vergingen zwei Tage.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.7 Unzulssige Temperatur und Luftfeuchte

Jedes Gert hat einen Temperaturbereich, innerhalb dessen seine
ordnungsgeme Funktion gewhrleistet ist. berschreitet die
Raumtemperatur die Grenzen dieses Bereiches nach oben oder unten, kann es
zu Betriebsstrungen und zu Gerteausfllen kommen.
So wird z. B. in einem Serverraum durch die darin befindlichen Gerte elek- IT-Systeme als Heizung
trische Energie in Wrme umgesetzt und daher der Raum aufgeheizt. Bei
unzureichender Lftung kann die zulssige Betriebstemperatur der Gerte
berschritten werden. Bei Sonneneinstrahlung in den Raum sind Temperatu-
ren ber 50C nicht unwahrscheinlich.
Zu Lftungszwecken werden oft die Fenster des Serverraumes geffnet. In der
bergangszeit (Frhjahr, Herbst) kann das bei groen Temperatur-
schwankungen dazu fhren, dass durch starke Abkhlung die zulssige Luft-
feuchte berschritten wird.
Bei der Lagerung von Langzeitspeichermedien knnen zu groe Fehler auf
Langzeitspeichermedien
Temperaturschwankungen oder zu groe Luftfeuchtigkeit zu Datenfehlern und
reduzierter Speicherdauer fhren. Einige Hersteller geben die optimalen
Lagerbedingungen fr Langzeitspeichermedien mit Temperaturen von 20 bis
22C und einer Luftfeuchtigkeit von 40% an.
Beispiel:
In einer Bonner Behrde wurde die gesamte Steuerungs- und Auswerte-
elektronik einer Sicherungseinrichtung in einem Raum untergebracht, der
gerade genug Platz lie, um die Tren der Gerteschrnke zu ffnen. Aus
Sicherheitsgrnden waren sowohl die Schrnke als auch der Raum mit festen
Tren verschlossen.
Nach der Fertigstellung der Anlage im Herbst lief die Anlage strungsfrei. Im
folgenden Sommer zeigten sich zuerst unerklrliche Funktionsfehler und bald
Totalabstrze des Systems, alles ohne erkennbare Systematik. Tagelanges
Suchen mit hohem technischen und personellem Aufwand bei geffneten
Tren erbrachte keine Ergebnisse. Nur durch Zufall wurde schlielich die
berhitzung der Anlage bei Auentemperaturen ber 30C als Ursache der
Strungen erkannt und durch ein Khlgert erfolgreich abgestellt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.8 Staub, Verschmutzung

Trotz zunehmender Elektronik in der IT kommt sie noch nicht ohne mecha- Staub strt Elektronik
nisch arbeitende Komponenten aus. Zu nennen sind Disketten, Fest- und
Wechselplatten, Diskettenlaufwerke, Drucker, Scanner etc, aber auch Lfter
von Prozessoren und Netzteile. Mit steigenden Anforderungen an die Qualitt
und die Schnelligkeit mssen diese Gerte immer prziser arbeiten. Bereits
geringfgige Verunreinigungen knnen zu einer Strung eines Gertes fhren.
Staub und Verschmutzungen knnen beispielsweise durch
- Arbeiten an Wnden, Doppelbden oder anderen Gebudeteilen,
- Umrstungsarbeiten an der Hardware bzw.
- Entpackungsaktionen von Gerten (z. B. aufwirbelndes Styropor)
in grerem Mae entstehen, die entsprechende Ausflle der Hardware verur-
sachen knnen.
Vorhandene Sicherheitsschaltungen in den Gerten fhren meist zu einem
rechtzeitigen Abschalten. Das hlt zwar den Schaden, die Instandsetzungs-
kosten und die Ausfallzeiten klein, fhrt aber dazu, dass das betroffene Gert
nicht verfgbar ist.
Beispiele:
- Bei der Aufstellung eines Servers in einem Medienraum, zusammen mit
einem Kopierer und einem Normalpapier-Faxgert, traten nacheinander die
Lhmung des Prozessor-Lfters und des Netzteil-Lfters aufgrund der
hohen Staubbelastung des Raumes auf. Der Ausfall des Prozessor-Lfters
fhrte zu sporadischen Server-Abstrzen. Der Ausfall des Netzteil-Lfters
fhrte schlielich zu einer berhitzung des Netzteils mit der Folge eines
Kurzschlusses, was schlielich einen Totalausfall des Servers nach sich
zog.
- Um eine Wandtafel in einem Bro aufzuhngen, wurden von der Haus-
technik Lcher in die Wand gebohrt. Der Mitarbeiter hatte hierzu sein Bro
fr kurze Zeit verlassen. Nach Rckkehr an seinen Arbeitsplatz stellte er
fest, dass sein PC nicht mehr funktionierte. Ursache hierfr war Bohrstaub,
der durch die Lftungsschlitze in das PC-Netzteil eingedrungen war.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.9 Datenverlust durch starke Magnetfelder

Typische Datentrger mit magnetisierbaren Speichermedien sind Disketten,
Wechselplatten, Kassetten und Bnder. Informationen werden ber Schreib-
/Lesekpfe aufgebracht. Die derart magnetisierten Datentrger sind empfind-
lich gegenber magnetischer Strstrahlung, so dass die Nhe zu solchen
Strahlungsquellen vermieden werden sollte.
Je nach Strke der Strahlung fhrt diese zu mehr oder weniger groen Daten-
verlusten. Besonders kritisch ist dies bei Dateien, die aufgrund ihrer internen
Formatierung bereits durch geringfgige Vernderungen gnzlich unbrauchbar
werden (z. B. Postscript-Dateien, Datenbanken).
Beispiele fr Quellen magnetischer Strstrahlung sind:
- Elektromotoren,
- Transformatoren,
- Ausweiselesegerte auf Magnetfeldbasis.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.10 Ausfall eines Weitverkehrsnetzes

Werden auf IT-Systemen, die ber Weitverkehrsnetze verbunden sind, zeit-
kritische IT-Anwendungen betrieben, sind die durch einen Netzausfall mg-
lichen Schden und Folgeschden entsprechend hoch, wenn keine Ausweich-
mglichkeiten (z. B. Anbindung an ein zweites Kommunikationsnetz) vorge-
sehen sind.
Im Rahmen der Liberalisierung des Telekommunikationsmarktes bietet nicht
nur die Deutsche Telekom AG ihre Dienste fr die Bereitstellung von
Kommunikationsverbindungen zum Daten- und Sprachtransfer an. Viele,
teilweise sehr kleine Netzbetreiber, konkurrieren mit gnstigen Kommuni-
kationsentgelten untereinander und mit der Deutschen Telekom AG. Daher
sollte ein Kunde sich informieren, mit welcher Gte dieser Dienst tatschlich
erbracht werden kann, indem er den Netzbetreiber um detaillierte Ausknfte
ber Backup-Strategien oder Notfallplanungen bittet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.11 Technische Katastrophen im Umfeld

Probleme im Umfeld einer Behrde bzw. eines Unternehmens knnen zu
Schwierigkeiten im Betrieb bis hin zu Arbeitsausfllen fhren. Dies knnen
technische Unglcksflle, Havarien, aber auch gesellschaftliche oder poli-
tische Unruhen wie Demonstrationen oder Krawalle sein (siehe auch G 1.12
Beeintrchtigung durch Groveranstaltungen).
Die Liegenschaften einer Organisation knnen verschiedenen Gefhrdungen
aus dem Umfeld durch Verkehr (Straen, Schiene, Luft, Wasser), Nachbar-
betrieben oder Wohngebieten ausgesetzt sein. Diese knnen beispielsweise
durch Brnde, Explosionen, Stube, Gase, Sperrungen, Strahlung, Emissionen
(chemische Industrie) verursacht sein.
Vorbeugungs- oder Rettungsmanahmen knnen die Liegenschaften dabei
direkt betreffen. Durch die Komplexitt der Haustechnik und der IT-Einrich-
tungen kann es aber auch zu indirekten Problemen kommen.
Beispiel:
Bei einem Brand in einem chemischen Betrieb in unmittelbarer Nhe eines
Rechenzentrums (ca. 1000 m Luftlinie) entstand eine mchtige Rauchwolke.
Das Rechenzentrum besa eine Klima- und Lftungsanlage, die ber keine
Auenluftberwachung verfgte. Nur durch die Aufmerksamkeit eines Mitar-
beiters (der Unfall geschah whrend der Arbeitszeit), der die Entstehung und
Ausbreitung verfolgte, konnte die Auenluftzufuhr rechtzeitig manuell abge-
schaltet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.12 Beeintrchtigung durch Groveranstaltungen

Groveranstaltungen aller Art knnen zu Behinderungen des ordnungs-
gemen Betriebs einer Behrde bzw. eines Unternehmens fhren. Hierzu
gehren u. a. Straenfeste, Konzerte, Sportveranstaltungen, Arbeitskmpfe
oder Demonstrationen. Ausschreitungen im Umfeld solcher Veranstaltungen
knnen zustzlich Auswirkungen wie die Einschchterung bis hin zur
Gewaltanwendung gegen das Personal oder das Gebude nach sich ziehen.
Beispiele:
- Whrend der heien Sommermonate fand eine Demonstration in der Nhe
eines Rechenzentrums statt. Die Situation eskalierte und es kam zu Gewalt-
ttigkeiten. In einer Nebenstrae stand noch ein Fenster des Rechenzen-
trumsbereiches auf, durch das ein Demonstrant eindrang und die Gelegen-
heit nutzte, IT-Hardware mit wichtigen Daten zu entwenden.
- Beim Aufbau einer Grokirmes wurde aus Versehen eine Stromleitung
gekappt. Dies fhrte in einem hierdurch versorgten Rechenzentrum zu
einem Ausfall, der jedoch durch die vorhandene Netzersatzanlage abge-
fangen werden konnte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.13 Sturm
Die Auswirkungen eines Sturms oder Orkans auf Aueneinrichtungen, die
zum Betrieb eines Rechenzentrums mittelbar bentigt werden, werden hufig
unterschtzt. Aueneinrichtungen knnen hierdurch beschdigt oder
abgerissen werden. Abgerissene und vom Sturm fortgeschleuderte
Gegenstnde knnen weitere Folgeschden verursachen. Weiterhin knnen
dadurch technische Komponenten in ihrer Funktion beeintrchtigt werden.
Beispiele:
- Khlleitungen der Klimaanlage eines Rechenzentrums waren auf dem lose verlegte
Khlleitungen
Dach als flexible Hart-PVC-Schluche verlegt, aber ber weite Strecken
auf der Dachhaut weder beschwert noch befestigt. Sie wurden vom Orkan
gepackt und vom Dach des Gebudes gefegt. Dabei rissen sie aus den
Verbindungen. Die Khlflssigkeit lief aus und das System musste fr
mehrere Stunden stillgelegt werden. Fr die Dauer des Sturmes konnten
wegen der Gefahr, vom Dach geweht zu werden, keinerlei Reparaturen
vorgenommen werden. Der Serverpark fiel fr fast 12 Stunden aus. Er
versorgt ca. 12.000 Nutzer.
- In einem anderen Fall strzte eine Lamellenwand, welche die durch Sturm
abgerissene Verkleidung
Rckkhlwerke auf dem Dach des Prozessrechenzentrums eines
Industriebetriebs optisch verkleidete, ein. Die scharfen Kanten der Bleche
durchschnitten die Elektroleitungen der Rckkhlwerke. Es gab einen
Kurzschluss mit Lichtbogen, der die vom Sturm mit hoch gerissene
Dachhaut in Brand steckte. Gleichzeitig wirkte die umgestrzte
Verkleidung geringfgig als Windschutz - lie aber genug Wind durch, um
das Feuer zu entfachen. Der Brand setzte sich in der Isolierung zwischen
Trapezblech und Dichtungsbahnen fort. Nur durch einen glcklichen Zufall
konnte ein Totalschaden verhindert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.14 Datenverlust durch starkes Licht

Typische Datentrger mit optischen Speichermedien sind CD-ROM, CD-RW,
DVD-RAM, DVD-RW und MO. Informationen werden ber Schreib-
/Lesekpfe sowie Laser aufgebracht. Die derart beschriebenen Datentrger
sind empfindlich gegenber starkem Licht, insbesondere im UV-Bereich, so
dass die Nhe zu solchen Lichtquellen vermieden werden sollte.
Je nach Strke und Dauer der Strahlung fhrt diese zu mehr oder weniger
groen Datenverlusten. Besonders kritisch ist dies bei Dateien, die aufgrund
ihrer internen Formatierung bereits durch geringfgige Vernderungen
gnzlich unbrauchbar werden (z. B. Postscript-Dateien, Datenbanken oder
verschlsselte Dateien).
Beispiele fr starke Lichtquellen sind:
- Sonnenlicht (vor allem an wolkenfreien Sommertagen oder in
Hhenlagen),
- Halogenlampen,
- spezielle Neonrhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 1.15 Beeintrchtigung durch wechselnde Einsatzum-

gebung
Mobile Gerte werden in sehr unterschiedlichen Umgebungen eingesetzt und
sind dadurch einer Vielzahl von Gefhrdungen ausgesetzt. Dazu gehren bei-
spielsweise schdigende Umwelteinflsse wie zu hohe oder zu niedrige Tem-
peraturen, ebenso wie Staub oder Feuchtigkeit. Zu anderen Problemen, die
durch die Beweglichkeit der Gerte entstehen, gehren beispielsweise Trans-
portschden.
Ein wichtiger Aspekt bei mobilen Gerten ist aber auch, dass sie sich in Berei- Unbekannte Umgebung -
unbekannte Risiken
chen mit unterschiedlichem Sicherheitsniveau bewegen. Bei einigen Umge-
bungen ist das Sicherheitsniveau den Benutzern durchaus bekannt, bei anderen
nicht. Neben der Beweglichkeit ist auch die Kommunikationsfhigkeit mit
anderen IT-Systemen ein Grund fr den Einsatz von PDAs, Laptops und
anderen mobilen Gerten. Daher mssen auch die Probleme betrachtet
werden, die durch die Interaktion mit anderen IT-Systemen ausgelst werden
knnen. Innerhalb der eigenen Organisation kann die Vertrauenswrdigkeit
von IT-Systemen bis zu einem gewissen Grad eingeschtzt werden. Dies ist
allerdings in fremden Umgebungen schwierig. Die Kommunikation mit unbe-
kannten IT-Systemen und Netzen kann immer Gefhrdungspotential fr das
eigene mobile System und dessen Anwendungen und Daten enthalten. Bei der
Kontaktaufnahme mit anderen IT-Systemen knnten beispielsweise auch
Computerviren oder Trojanische Pferde mit bertragen werden.
Daher muss auch nach der Rckkehr von mobilen Systemen immer kritisch
hinterfragt werden, wo dieser PDA schon berall gewesen ist, und die ent-
sprechenden Vorsichtsregeln sind zu beachten.
Ein weiteres Problem bei der Nutzung von fremden Infrastrukturen, wie z. B.
beim Herunterladen von Informationsangeboten auf Messen, ist die hufig
unzureichende Transparenz der angebotenen Dienste. Viele Dienstanbieter
sammeln Kundendaten, um Profile erstellen zu knnen, um einerseits ihren
Kunden besser auf sie zugeschnittene Dienste anbieten zu knnen, aber auch
um diese andererseits an andere Anbieter weiterverkaufen zu knnen. Es
knnten beispielsweise Profile erstellt werden, alleine indem die Informa-
tionen ber Aufenthaltsorte und das Kommunikationsverhalten des Benutzers
ausgewertet werden (welche Dienste, wann, wie oft, mit wem). Auch bei
Anwendungen, die vollstndig auf dem eigenen mobilen Endgert ablaufen,
kann es vorkommen, dass diese Daten sammeln (z. B. ber Nutzungshufig-
keit und -art) und weitergeben, sobald das Gert online geht.
Immer wieder werden mobile Endgerte verloren oder gestohlen. Je kleiner
und begehrter solche Gerte sind, wie beispielsweise PDAs, desto hher ist
dieses Risiko. Neben dem unmittelbaren Verlust kann dabei durch den Verlust
bzw. die Offenlegung wichtiger Daten weiterer Schaden entstehen.
___________________________________________________________________ ..........................................
IT-Grundschutzhandbuch: Neu 307
Gefhrdungskatalog Organisatorische Mngel G2 Bemerkungen
___________________________________________________________________ ..........................................
G2 Gefhrdungskatalog Organisatorische Mngel

G 2.1 Fehlende oder unzureichende Regelungen ................................ 1
G 2.2 Unzureichende Kenntnis ber Regelungen................................ 2
G 2.3 Fehlende, ungeeignete, inkompatible Betriebsmittel................. 3
G 2.4 Unzureichende Kontrolle der IT-Sicherheitsmanahmen.......... 4
G 2.5 Fehlende oder unzureichende Wartung ..................................... 5
G 2.6 Unbefugter Zutritt zu schutzbedrftigen Rumen ..................... 6
G 2.7 Unerlaubte Ausbung von Rechten ........................................... 7
G 2.8 Unkontrollierter Einsatz von Betriebsmitteln ............................ 8
G 2.9 Mangelhafte Anpassung an Vernderungen beim IT-
Einsatz........................................................................................ 9
G 2.10 Nicht fristgerecht verfgbare Datentrger ............................... 10
G 2.11 Unzureichende Trassendimensionierung ................................. 11
G 2.12 Unzureichende Dokumentation der Verkabelung.................... 12
G 2.13 Unzureichend geschtzte Verteiler .......................................... 13
G 2.14 Beeintrchtigung der IT-Nutzung durch ungnstige
Arbeitsbedingungen ................................................................. 14
G 2.15 Vertraulichkeitsverlust schutzbedrftiger Daten im
Unix-System ............................................................................ 15
G 2.16 Ungeordneter Benutzerwechsel bei tragbaren PCs.................. 16
G 2.17 Mangelhafte Kennzeichnung der Datentrger ......................... 17
G 2.18 Ungeordnete Zustellung der Datentrger................................. 18
G 2.19 Unzureichendes Schlsselmanagement bei
Verschlsselung....................................................................... 19
G 2.20 Unzureichende oder falsche Versorgung mit
Verbrauchsgtern..................................................................... 20
G 2.21 Mangelhafte Organisation des Wechsels zwischen den
Benutzern................................................................................. 21
G 2.22 Fehlende Auswertung von Protokolldaten............................... 22
G 2.23 Schwachstellen bei der Einbindung von DOS-PCs in
ein servergesttztes Netz ......................................................... 23
G 2.24 Vertraulichkeitsverlust schutzbedrftiger Daten des zu
schtzenden Netzes.................................................................. 24
G 2.25 Einschrnkung der bertragungs- oder
Bearbeitungsgeschwindigkeit durch Peer-to-Peer-
Funktionalitten ....................................................................... 25
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.26 Fehlendes oder unzureichendes Test- und

Freigabeverfahren .................................................................... 26
G 2.27 Fehlende oder unzureichende Dokumentation......................... 27
G 2.28 Verste gegen das Urheberrecht ............................................ 28
G 2.29 Softwaretest mit Produktionsdaten .......................................... 29
G 2.30 Unzureichende Domnenplanung............................................ 30
G 2.31 Unzureichender Schutz des Windows NT Systems................. 31
G 2.32 Unzureichende Leitungskapazitten ........................................ 32
G 2.33 Nicht gesicherter Aufstellungsort von Novell Netware
Servern..................................................................................... 33
G 2.34 Fehlende oder unzureichende Aktivierung von Novell
Netware Sicherheitsmechanismen ........................................... 34
G 2.35 Fehlende Protokollierung unter Windows 95
(gestrichen!) ............................................................................. 35
G 2.36 Ungeeignete Einschrnkung der Benutzerumgebung .............. 36
G 2.37 Unkontrollierter Aufbau von
Kommunikationsverbindungen................................................ 37
G 2.38 Fehlende oder unzureichende Aktivierung von
Datenbank-Sicherheitsmechanismen ....................................... 38
G 2.39 Komplexitt eines DBMS........................................................ 39
G 2.40 Komplexitt des Datenbankzugangs/-zugriffs......................... 41
G 2.41 Mangelhafte Organisation des Wechsels von
Datenbank-Benutzern .............................................................. 43
G 2.42 Komplexitt der NDS .............................................................. 44
G 2.43 Migration von Novell Netware 3.x nach Novell
Netware Version 4 ................................................................... 45
G 2.44 Inkompatible aktive und passive Netzkomponenten ............... 46
G 2.45 Konzeptionelle Schwchen des Netzes.................................... 47
G 2.46 berschreiten der zulssigen Kabel- bzw. Buslnge
oder der Ringgre .................................................................. 49
G 2.47 Ungesicherter Akten- und Datentrgertransport...................... 51
G 2.48 Ungeeignete Entsorgung der Datentrger und
Dokumente am huslichen Arbeitsplatz .................................. 52
G 2.49 Fehlende oder unzureichende Schulung der Telearbeiter ........ 53
G 2.50 Verzgerungen durch temporr eingeschrnkte
Erreichbarkeit der Telearbeiter ................................................ 54
G 2.51 Mangelhafte Einbindung des Telearbeiters in den
Informationsfluss ..................................................................... 55
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.52 Erhhte Reaktionszeiten bei IT-Systemausfall........................ 56

G 2.53 Unzureichende Vertretungsregelungen fr Telearbeit............. 57
G 2.54 Vertraulichkeitsverlust durch Restinformationen .................... 58
G 2.55 Ungeordnete E-Mail-Nutzung ................................................. 59
G 2.56 Mangelhafte Beschreibung von Dateien.................................. 60
G 2.57 Nicht ausreichende Speichermedien fr den Notfall ............... 61
G 2.58 Novell Netware und die Datumsumstellung im Jahr
2000 ......................................................................................... 62
G 2.59 Betreiben von nicht angemeldeten Komponenten ................... 63
G 2.60 Fehlende oder unzureichende Strategie fr das Netz-
und Systemmanagement .......................................................... 64
G 2.61 Unberechtigte Sammlung personenbezogener Daten .............. 66
G 2.62 Ungeeigneter Umgang mit Sicherheitsvorfllen...................... 67
G 2.63 Ungeordnete Faxnutzung......................................................... 68
G 2.64 Fehlende Regelungen fr das RAS-System............................. 69
G 2.65 Komplexitt der SAMBA-Konfiguration ................................ 71
G 2.66 Unzureichendes IT-Sicherheitsmanagement ........................... 73
G 2.67 Ungeeignete Verwaltung von Zugangs- und
Zugriffsrechten......................................................................... 75
G 2.68 Fehlende oder unzureichende Planung des Active
Directory .................................................................................. 76
G 2.69 Fehlende oder unzureichende Planung des Einsatzes
von Novelle eDirectory............................................................ 77
G 2.70 Fehlerhafte oder unzureichende Planung der
Partitionierung und Replizierung im Novell eDirectory.......... 79
G 2.71 Fehlerhafte oder unzureichende Planung des
LDAP-Zugriffs auf das Novell eDirectory .............................. 81
G 2.72 Unzureichende Migration von Archivsystemen ...................... 83
G 2.73 Fehlende Revisionsmglichkeit von Archivsystemen ............. 85
G 2.74 Unzureichende Ordnungskriterien fr Archive ....................... 86
G 2.75 Mangelnde Kapazitt von Archivdatentrgern ........................ 87
G 2.76 Unzureichende Dokumentation von Archivzugriffen.............. 88
G 2.77 Unzulngliche bertragung von Papierdaten in
elektonische Archive................................................................ 89
G 2.78 Unzulngliche Auffrischung von Datenbestnden bei
der Archivierung...................................................................... 91
G 2.79 Unzulngliche Erneuerung von digitalen Signaturen bei
der Archivierung...................................................................... 92
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.80 Unzureichende Durchfhrung von Revisionen bei der

Archivierung ............................................................................ 93
G 2.81 Unzureichende Vernichtung von Datentrgern bei der
Archivierung ............................................................................ 94
G 2.82 Fehlerhafte Planung des Aufstellungsortes von
Archivsystemen ....................................................................... 95
G 2.83 Fehlerhafte Outsourcing-Strategie........................................... 96
G 2.84 Unzulngliche vertragliche Regelungen mit einem
externen Dienstleister .............................................................. 97
G 2.85 Unzureichende Regelungen fr das Ende des
Outsourcing-Vorhabens ........................................................... 99
G 2.86 Abhngigkeit von einem Outsourcing-Dienstleister.............. 100
G 2.87 Verwendung unsicherer Protokolle in ffentlichen
Netzen .................................................................................... 101
G 2.88 Strungen des Betriebsklimas durch ein Outsourcing-
Vorhaben................................................................................ 103
G 2.89 Mangelhafte IT-Sicherheit in der Outsourcing-
Einfhrungsphase................................................................... 104
G 2.90 Schwachstellen bei der Anbindung an einen
Outsourcing-Dienstleister ...................................................... 106
G 2.91 Fehlerhafte Planung der Migration von Exchange 5.5
nach Exchange 2000 .............................................................. 107
G 2.92 Fehlerhafte Regelungen fr den Browser-Zugriff auf
Exchange................................................................................ 108
G 2.93 Unzureichendes Notfallvorsorgekonzept beim
Outsourcing............................................................................ 109
G 2.94 Unzureichende Planung des IIS-Einsatzes............................. 110
G 2.95 Fehlendes Konzept zur Anbindung anderer E-Mail-
Systeme an Exchange/Outlook .............................................. 111
G 2.96 Veraltete oder falsche Informationen in einem
Webangebot ........................................................................... 112
G 2.97 Unzureichende Notfallplanung bei einem Apache
Webserver .............................................................................. 113
G 2.98 Fehlerhafte Planung und Konzeption des Einsatzes von
Routern und Switchen............................................................ 114
G 2.99 Unzureichende oder fehlerhafte Konfiguration der
zSeries-Systemumgebung...................................................... 116
G 2.100 Fehler bei der Beantragung und Verwaltung von
Internet-Domainnamen .......................................................... 117
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.101 Unzureichende Notfallvorsorge bei einem

Sicherheitsgateway ................................................................ 119
___________________________________________________________________ ..........................................
Gefhrdungskatalog Organisatorische Mngel G 2.1 Bemerkungen
___________________________________________________________________ ..........................................
G 2.1 Fehlende oder unzureichende Regelungen

Die Bedeutung bergreifender organisatorischer Regelungen und Vorgaben
fr das Ziel IT-Sicherheit nimmt mit dem Umfang der Informationsverar-
beitung, aber auch mit dem Schutzbedarf der zu verarbeitenden Informationen
zu.
Von der Frage der Zustndigkeiten angefangen bis hin zur Verteilung von
Kontrollaufgaben kann das Spektrum der Regelungen sehr umfangreich sein.
Auswirkungen von fehlenden oder unzureichenden Regelungen werden
beispielhaft in den Gefhrdungen G 2.2 ff. beschrieben.
Vielfach werden nach Vernderungen technischer, organisatorischer oder
personeller Art, die wesentlichen Einfluss auf die IT-Sicherheit haben,
bestehende Regelungen nicht angepasst. Veraltete Regelungen knnen dem
strungsfreien IT-Betrieb entgegen stehen. Probleme knnen auch dadurch
entstehen, dass Regelungen unverstndlich oder zusammenhanglos formuliert
sind und dadurch missverstanden werden.
Dass Regelungsdefizite schadensfrdernde Auswirkungen haben knnen,
machen folgende Beispiele deutlich:
- Durch eine mangelhafte Betriebsmittelverwaltung kann der termingerechte
Arbeitsablauf in einem Rechenzentrum schon durch eine unterbliebene
Druckerpapierbestellung stark beeintrchtigt werden.
- Neben einer Beschaffung von Handfeuerlschern muss auch deren War-
tung geregelt sein, um sicherzustellen, dass diese im Brandfall auch funk-
tionstchtig sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.2 Unzureichende Kenntnis ber Regelungen

Die Festlegung von Regelungen allein sichert den strungsfreien IT-Einsatz
noch nicht. Die fr einen Funktionstrger geltenden Regelungen mssen
diesem auch bekannt sein. Der Schaden, der sich aus einer unzureichenden
Kenntnis ber bestehende Regelungen ergeben kann, darf sich nicht mit den
Aussagen entschuldigen lassen: "Ich habe nicht gewusst, dass ich dafr
zustndig bin." oder "Ich habe nicht gewusst, wie ich zu verfahren hatte."
Beispiele:
- Werden Mitarbeiter nicht ber die Verfahrensweise des Umgangs mit
bersandten Datentrger und E-Mails unterrichtet, besteht die Gefahr, dass
ein Computer-Virus im Unternehmen bzw. in der Behrde verbreitet wird.
- In einer Bundesbehrde wurden farblich unterschiedliche Papierkrbe auf-
gestellt, von denen eine Farbe fr die Entsorgung zu vernichtender Unter-
lagen bestimmt war. Die meisten Mitarbeiter waren von dieser Regelung
nicht unterrichtet.
- In einer Bundesbehrde gab es eine Vielzahl von Regelungen zur Durch-
fhrung von Datensicherungen, die mndlich zwischen dem IT-Sicher-
heitsbeauftragten und dem IT-Referat sukzessiv vereinbart wurden. Eine
Nachfrage ergab, dass die betroffenen IT-Benutzer keine Kenntnis und
keinen Ansprechpartner ber die getroffenen "Vereinbarungen" hatten. Die
Regelungen zur Datensicherung waren auch nicht dokumentiert. Viele
Benutzer haben deshalb unntig lokale Datensicherungen angefertigt.
- In einem Rechenzentrum wurde als neue Regelung festgelegt, dass bei
Problemen mit der Einbruch- oder Brandmeldeanlage eine Besetzung der
Pfrtnerloge auch nachts erfolgt. Der sich selbst organisierende Pfrtner-
dienst war ber diese eingefhrte Regelung vom Sicherheitsverantwort-
lichen nicht informiert worden. Als Folge war das Rechenzentrum fr
mehrere Wochen ungeschtzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.3 Fehlende, ungeeignete, inkompatible

Betriebsmittel
Eine nicht ausreichende Bereitstellung von Betriebsmitteln kann einen IT-
Betrieb erheblich beeintrchtigen. Strungen knnen sich aus einer nicht aus-
reichenden Menge bentigter Betriebsmittel oder deren nicht termingerechter
Bereitstellung ergeben.
Ebenso kann es vorkommen, dass ungeeignete oder sogar inkompatible
Betriebsmittel beschafft werden, die infolgedessen nicht eingesetzt werden
knnen.
Beispiele:
- Durch das Jahr-2000-Problem knnen durch den bevorstehenden Jahres-
wechsel Kompatibilittsproblemen bei der eingesetzten Hard- und Soft-
ware auftreten.
- Fr den neu angemieteten Datex-P-Anschluss wird vergessen, das Entgelt
fr die Einrichtung an den Betreiber zu berweisen mit der Folge, dass der
Anschluss nicht freigeschaltet wird. Das IT-Verfahren, das diesen
Anschluss nutzen soll, kann daher nur mit Versptung in Betrieb
genommen werden.
- Ein ungeeignetes Betriebsmittel ist zum Beispiel eine graphische
Benutzeroberflche, die auf einem nicht ausreichend leistungsfhigen
Rechner installiert werden soll.
- Ein Beispiel fr inkompatible Betriebsmittel sind Verbindungskabel unter-
schiedlicher Pin-Belegung zum Anschluss von Druckern.
- Fr den Betrieb einer Datenbank unter der neu beschafften Datenbanken-
Standardsoftware ist im zugehrigen Rechner nicht gengend Haupt-
speicher vorhanden oder der Plattenplatz reicht nicht aus.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.4 Unzureichende Kontrolle der IT-

Sicherheitsmanahmen
Nach der Einfhrung von Manahmen, die der Sicherheit der IT dienen (z. B.
Datensicherung, Zutrittskontrolle, Vorgaben fr Verhalten bei Notfllen),
mssen diese auch konsequent umgesetzt werden. Finden keine oder nur
unzureichende Kontrollen der Sicherheitsmanahmen statt, wird weder deren
Missachtung noch ihre effektive Wirksamkeit festgestellt. Eine rechtzeitige
und der jeweiligen Situation angemessene Reaktion wird dadurch verhindert.
Darber hinaus gibt es Sicherheitsmanahmen, die nur mit der Durchfhrung
entsprechender Kontrollen ihre Wirkung entfalten. Hierzu zhlen bei-
spielsweise Protokollierungsfunktionen, deren Sicherheitseigenschaften erst
mit der Auswertung der Protokolldaten zum Tragen kommen.
Beispiele:
- Der Administrationsplatz einer Datenverarbeitungsanlage ist mit einem
Konsoldrucker ausgestattet. Dieser Drucker soll smtliche Eingaben
protokollieren, die ber die Bedienungskonsole erfolgen. Ob durch die
Administration missbruchlich Handlungen vorgenommen werden, lsst
sich erst durch eine Auswertung der Ausdrucke feststellen. Fehlt diese
Auswertung durch eine unabhngige Person, so ist die Protokollierung
wirkungslos.
- Zur Vorbereitung von Straftaten kommt es vor, dass Schliezylinder in
Auentren und Toren ausgetauscht werden. Gerade wenn es sich um
Zugnge handelt, die selten genutzt werden oder lediglich als Notausgnge
vorgesehen sind, werden diese bei Streifengngen nur in Panikrichtung
geprft. Der Schliezylinder wird nicht ausprobiert.
- In einer Behrde werden einige Unix-Server zur externen Datenkommu-
nikation eingesetzt. Aufgrund der zentralen Bedeutung dieser IT-Systeme
sieht das IT-Sicherheitskonzept vor, dass die Unix-Server wchentlich
einer Integrittsprfung unterworfen werden. Da diese berprfungen
nicht regelmig nachgehalten werden, fllt erst bei der Klrung eines
Sicherheitsvorfalls auf, dass die IT-Abteilung auf solche Integrittspr-
fungen verzichtet hat. Als Grund wurde die mangelhafte personelle Aus-
stattung der Abteilung genannt.
- In einem Unternehmen wurde die Rolle des z/OS-Security-Auditors nicht
besetzt. Dies hatte zur Folge, dass die Einstellungen im RACF im Laufe
der Zeit nicht mehr den Sicherheitsvorgaben des Unternehmens
entsprachen. Erst nach einem Produktionsausfall wurde bemerkt, dass
einige Anwender mehr Rechte hatten, als sie fr ihre Ttigkeit bentigten.
Eine fr die Produktion wichtige Anwendung war von ihnen gestoppt
worden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.5 Fehlende oder unzureichende Wartung

Die Funktionsfhigkeit der eingesetzten Technik muss gewhrleistet bleiben.
Durch regelmige Wartung kann die Funktionsfhigkeit der eingesetzten
Technik gefrdert werden. Werden Wartungsarbeiten nicht oder nur unzurei-
chend durchgefhrt, knnen daraus unabsehbar hohe Schden oder Folgesch-
den entstehen.
Beispiele:
- Die Batterien einer unterbrechungsfreien Stromversorgung (USV) verfgen
infolge fehlender Wartung ber eine unzureichende Kapazitt (zu geringer
Suregehalt). Die USV kann einen Stromausfall nicht mehr ausreichend
lange berbrcken.
- Die Feuerlscher verfgen aufgrund fehlender Wartung nicht mehr ber
einen ausreichenden Druck, so dass ihre brandbekmpfende Wirkung nicht
mehr vorhanden ist.
- Der Laserdrucker fllt aufgrund berhitzung aus, weil ein Lftungsgitter
nicht vorschriftsmig gereinigt wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.6 Unbefugter Zutritt zu schutzbedrftigen

Rumen
Gelangen Unbefugte in schutzbedrftige Rume, knnen sich Gefhrdungen
nicht nur durch vorstzliche Handlungen, sondern auch durch
unbeabsichtigtes Fehlverhalten ergeben. Eine Strung des Betriebsablaufs tritt
allein schon dadurch ein, dass aufgrund des unbefugten Zutritts eine Fest-
stellung mglicher Schden erforderlich wird. Dabei ist zu beachten, dass
auch dienstlich genutzte Rume im huslichen Umfeld zu diesen schutz-
bedrftigen Rumen zu zhlen sind.
Beispiel:
Beim Reinigungspersonal wird eine Urlaubsvertretung eingesetzt. Die
Urlaubsvertretung bernimmt eigenmchtig - obwohl sie nicht eingewiesen
wurde - die Reinigung des Rechenzentrums. Dort ffnet sie den
alarmberwachten Notausgang und lst hierdurch einen Fehlalarm aus.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.7 Unerlaubte Ausbung von Rechten

Rechte wie Zutritts-, Zugangs- und Zugriffsberechtigungen werden als orga-
nisatorische Manahmen eingesetzt, um eine sichere und ordnungsgeme IT-
Nutzung zu gewhrleisten. Werden solche Rechte an die falsche Person
vergeben oder wird ein Recht unautorisiert ausgebt, knnen sich eine Viel-
zahl von Gefhrdungen ergeben, die die Vertraulichkeit und Integritt von
Daten oder die Verfgbarkeit von Rechnerleistung beeintrchtigen.
Beispiel:
Der Arbeitsvorbereiter, der keine Zutrittsberechtigung zum Datentrgerarchiv
besitzt, entnimmt in Abwesenheit des Archivverwalters Magnetbnder, um
Sicherungskopien einspielen zu knnen. Durch die unkontrollierte Entnahme
wird das Bestandsverzeichnis des Datentrgerarchivs nicht aktualisiert, die
Bnder sind fr diesen Zeitraum nicht auffindbar.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.8 Unkontrollierter Einsatz von Betriebsmitteln

Betriebsmittel - gleich welcher Art - drfen nur entsprechend dem Verwen-
dungszweck eingesetzt werden. Die fr die Beschaffung und den Einsatz der
Betriebsmittel verantwortlichen Personen mssen sowohl den unkontrollierten
Einsatz verhindern als auch den korrekten Einsatz berwachen. Wird jedoch
der Einsatz von Betriebsmitteln nicht ausreichend kontrolliert, knnen als
Folge vielfltige Gefhrdungen auftreten.
Beispiele:
- Der Einsatz privater Datentrger durch Mitarbeiter kann zu einer Infektion
des dienstlichen PC durch Computer-Viren fhren.
- Falsche Reinigungsmittel knnen zu einer Beschdigung von Monitoren
fhren.
- Ungeeignete Tinte fr Tintenstrahldrucker kann zu einer Verunreinigung
oder Fehlfunktion des Druckers fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.9 Mangelhafte Anpassung an Vernderungen

beim IT-Einsatz
Die speziell fr den Einsatz von Informationstechnik geschaffenen organisato-
rischen Regelungen, aber auch das gesamte Umfeld einer Behrde bzw. eines
Unternehmens unterliegen stndigen Vernderungen. Sei es nur, dass
Mitarbeiter ausscheiden oder hinzukommen, Mitarbeiter das Bro wechseln,
neue Hardware oder Software beschafft wird, der Zulieferbetrieb fr die
Betriebsmittel Konkurs anmeldet. Da sich bei einer ungengenden Berck-
sichtigung der vorzunehmenden organisatorischen Anpassungen Gefhr-
dungen ergeben, zeigen folgende Beispiele:
- Vor Urlaubsantritt vergisst ein Mitarbeiter, der Urlaubsvertretung Zugriffs-
rechte auf alle von dieser bentigten Dateien und Verzeichnisse zu ber-
tragen. Hierdurch knnen sich Verzgerungen im IT-Betrieb ergeben.
- Durch bauliche nderungen im Gebude werden bestehende Fluchtwege
verndert. Durch mangelhafte Unterrichtung der Mitarbeiter ist die Ru-
mung des Gebudes nicht in der erforderlichen Zeit mglich.
- Durch eine Umstellung eines IT-Verfahrens werden grere Mengen an
Druckerpapier bentigt. Durch fehlende Unterrichtung der Beschaffungs-
stelle kommt es zu Engpssen im IT-Betrieb.
- Beim Empfang elektronischer Dokumente werden diese nicht automatisch
auf Makro-Viren berprft, da dieses Problem noch nicht bekannt ist oder
kein Virenprfprogramm vorhanden ist.
- Bei der bermittlung elektronischer Dokumente wird nicht darauf geach-
tet, diese in einem fr die Empfngerseite lesbaren Format abzuspeichern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.10 Nicht fristgerecht verfgbare Datentrger

Die korrekte Verwendung von Datentrgern ist fr ein IT-Verfahren von
besonderer Bedeutung. Bereits geringfgige Fehler - z. B. mangelhafte Kenn-
zeichnung, falscher Aufbewahrungsort, fehlende Ein- oder Ausgabebestti-
gungen im Datentrgerarchiv - knnen dazu fhren, dass ein Datentrger nicht
in der erforderlichen Zeit aufgefunden werden kann. Die resultierenden
Verzgerungen knnen zu erheblichen Schden fhren.
Beispiele:
- Datensicherungsbnder werden versehentlich in ein externes Datensiche-
rungsarchiv ausgelagert. Eine erforderliche Datenrekonstruktion wird
erheblich verzgert, weil die Wiederbeschaffung der Bnder nicht unver-
zglich mglich ist.
- Datensicherungsbnder unterschiedlichen Inhalts werden versehentlich
gleich gekennzeichnet. Der Archivverwalter gibt unabsichtlich das aktu-
ellere Magnetband zum Lschen frei. Folglich steht nur noch eine ber-
alterte Datensicherung zur Verfgung.
- Bandverwaltungssysteme im z/OS-Betriebssystem verwenden Batch-Jobs,
um Datensicherungsbnder mit erreichtem Expiration Date zu erkennen
und zum berschreiben frei zu geben. Bricht dieser Batch-Job ab oder luft
erst gar nicht an, so stehen unter Umstnden nicht genug Leerbnder
(Scratch Tapes) fr die Folgesicherungen zur Verfgung und es kann zu
Engpssen in der Bandverarbeitung kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.11 Unzureichende Trassendimensionierung

Bei der Planung von Netzen, Serverrumen oder Rechenzentren wird oft der
Fehler begangen, die funktionale, kapazitive oder sicherheitstechnische Aus-
legung ausschlielich am aktuellen Stand auszurichten. Dabei wird bersehen,
dass
- die Kapazitten des Netzes und der Rechner aufgrund steigender Daten-
volumina oder Einsatz neuer Dienste und Dienstleistungen erweitert
werden mssen,
- nderungen technischer Standards bauliche oder sicherheitstechnische
Anpassungen nach sich ziehen knnen,
- Erweiterungen des Netzes nicht auszuschlieen sind
- neue Forderungen an das Netz die Verlegung anderer Kabel erforderlich
machen.
Beispiele:
- Eine Erweiterung von Netzen ist nur in dem Umfang mglich, wie es die kein Austausch einzelner
Kabel mglich
vorhandenen, verlegten Kabel zulassen oder der zur Verfgung stehende
Platz fr zustzliche Kabel erlaubt. Gerade in geschlossenen Trassen
(Rohre, estrichberdeckte Fubodenkanle etc.) ist es trotz noch
vorhandenen Platzes oft nicht mglich, zustzliche Kabel einzuziehen,
ohne neue und alte Kabel zu beschdigen. Als Ausweg bleibt dann nur, die
vorhandenen Kabel aus der Trasse herauszuziehen und alle Kabel, die alten
und die neuen, gleichzeitig neu einzuziehen. Die dadurch entstehenden
Betriebsbeeintrchtigungen und Kosten sind betrchtlich.
- Die Planung eines Rechenzentrum erfolgte zunchst allein unter Trassen nicht eingeplant
sthetischen Gesichtspunkten. Infrastrukturelle und sicherheitstechnische
Anforderungen standen im Hintergrund und wurden erst nach der
Rohbauerstellung konkreter definiert. Die Fertigstellung des Baus
verzgerte sich extrem, weil erforderliche Trassen nicht zur Verfgung
standen und Rume nicht bedarfsgerecht dimensioniert und positioniert
waren. nderungen whrend des spteren Betriebs waren nur unter groen
Umstnden zu bewltigen.
- In einem Unternehmen wurde nach zehn Jahren Betriebszeit eine schlechte Koordination
vollstndig neue Netzstruktur und IT-Verkabelung geplant. Auf Nachfrage
stellte sich heraus, dass im folgenden Jahr eine Erneuerung der TK-Anlage
und der TK-Verkabelung geplant war, die bislang zusammen mit der IT-
Verkabelung in derselben Trasse gefhrt wurde. Ohne Koordinierung
dieser beiden Manahmen wren doppelte Arbeiten an den Trassen
erforderlich geworden und es wren mglicherweise zu kleine Trassen
geplant worden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.12 Unzureichende Dokumentation der Verkabelung

Ist aufgrund unzureichender Dokumention die genaue Lage von Leitungen
nicht bekannt, so kann es bei Bauarbeiten auerhalb oder innerhalb eines
Gebudes zu Beschdigungen von Leitungen kommen. Dabei kann es zu
lngeren Ausfallzeiten oder unter Umstnden sogar zu lebensbedrohenden
Gefahren, z. B. durch Stromschlag, kommen.
Eine unzureichende Dokumentation erschwert zudem Prfung, Wartung und
Reparatur von Leitungen sowie Rangierungen, wie sie z. B. bei nderungen
im Endgerte-Bereich (Umzug, Neuzugang) erforderlich werden.
Beispiel:
In einer greren Behrde wurde die Verkabelung der IT durch eine externe
Firma vorgenommen. Die Anfertigung einer Dokumentation war im
Leistungsumfang nicht enthalten. Da nach Fertigstellung der Verkabelung mit
der Firma kein Wartungsvertrag abgeschlossen wurde, verfgte die Behrde
nicht ber die notwendige Dokumentation. Erweiterungen des Netzes konnten
nur mit erheblichen Verzgerungen vorgenommen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.13 Unzureichend geschtzte Verteiler

Verteiler des Stromversorgungsnetzes sind vielfach frei zugnglich und unver-
schlossen in Fluren oder Treppenhusern untergebracht. Somit ist es
jedermann mglich, diese Verteiler zu ffnen, Manipulationen vorzunehmen
und ggf. einen Stromausfall herbeizufhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.14 Beeintrchtigung der IT-Nutzung durch

ungnstige Arbeitsbedingungen
Ein nicht nach ergonomischen Gesichtspunkten eingerichteter Arbeitsplatz
oder das Arbeitsumfeld (z. B. Strungen durch Lrm oder Staub) knnen dazu
fhren, dass die zur Verfgung stehende IT nicht oder nicht optimal genutzt
werden kann.
Die meisten der denkbaren Strungen wirken sich nicht direkt auf die IT aus.
Vielmehr wird der Mitarbeiter in der Form beeinflusst, dass er seiner Aufgabe
nicht mit entsprechender Konzentration nachgehen kann. Die Strungen
reichen von Lrm oder starkem, unorganisiertem Kundenverkehr bis zu
ungnstiger Beleuchtung, schlechter Belftung u... Erste Anzeichen solcher
Strungen sind die Verlangsamung der Aufgabenerledigung und die Zunahme
kleiner Fehler (Zeichendreher, Schreibfehler). Dadurch wird nicht nur das
direkte Arbeitsergebnis beeintrchtigt. Auch die gespeicherten Daten enthalten
evtl. Fehler, die Integritt der Daten wird vermindert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.15 Vertraulichkeitsverlust schutzbedrftiger Daten

im Unix-System
Durch verschiedene Unix-Programme ist es mglich, Daten abzufragen, die
das IT-System ber die Benutzer speichert. Hiervon sind auch solche Daten
betroffen, die Auskunft ber das Leistungsprofil eines Benutzers geben
knnen. Datenschutzrechtliche Gesichtspunkte mssen deshalb genauso
beachtet werden wie die Gefahr, dass solche Informationen
Missbrauchsmglichkeiten erleichtern.
Beispiel:
Mit einem einfachen Programm, das in einem bestimmten Zeitintervall die
Informationen, die der Befehl who liefert, auswertet, kann jeder Benutzer ein
genaues Nutzungsprofil fr einen Account erstellen. Z. B. lassen sich auf diese
Weise die Abwesenheitszeiten des oder der Systemadministratoren feststellen,
um diese Zeiten fr unberechtigte Handlungen zu nutzen. Desweiteren lsst
sich feststellen, welche Terminals fr einen privilegierten Zugang zugelassen
sind.
Weitere Programme mit hnlichen Missbrauchsmglichkeiten sind finger oder
ruser.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.16 Ungeordneter Benutzerwechsel bei tragbaren

PCs
Der Benutzerwechsel bei tragbaren PCs wie Laptops oder Notebooks wird
oftmals durch die einfache bergabe des Gertes vorgenommen. Dies hat zur
Folge, dass meist nicht sichergestellt wird, dass auf dem Gert keine schutzbe-
drftigen Daten mehr gespeichert sind und dass das Gert nicht mit einem
Computer-Virus verseucht ist. Zudem ist nach einiger Zeit nicht mehr nach-
vollziehbar, wer den tragbaren PC wann genutzt hat oder wer ihn zurzeit
benutzt. Der ungeordnete Benutzerwechsel ohne Speicherkontrollen und ohne
entsprechende Dokumentation kann damit zur Einschrnkung der
Verfgbarkeit des Gerts und zum Vertraulichkeitsverlust von Restdaten der
Festplatte fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.17 Mangelhafte Kennzeichnung der Datentrger

Unterbleibt eine ordnungsgeme Kennzeichnung der ausgetauschten Daten-
trger, so ist fr den Empfnger oft nicht nachvollziehbar, wer den
Datentrger bersandt hat, welche Informationen darauf gespeichert sind oder
welchem Zweck sie dienen. Wenn mehrere Datentrger ein- und desselben
Absenders eingehen, kann bei fehlender Kennzeichnung die Reihenfolge
verwechselt werden.
Beispiel:
Absender A verschickt an den Empfnger E eine Diskette mit Informationen,
bei denen groes Gewicht auf deren Integritt gelegt wird. Am nchsten Tag
stellt A fest, dass die Daten fehlerhaft waren, verschickt eine korrigierte
Version und kndigt diese beim Empfnger telefonisch an. Auf dem Postweg
berholt nun die zweite Diskette die erste, so dass der Empfnger aufgrund
mangelhafter Kennzeichnung glaubt, die zuerst erhaltene Diskette enthielte die
falschen Daten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.18 Ungeordnete Zustellung der Datentrger

Bei ungeordneter Zustellung von Datentrgern besteht die Gefahr, dass
vertrauliche, auf dem Datentrger gespeicherte Daten in unbefugte Hnde
gelangen oder das gewnschte Ziel nicht rechtzeitig erreichen.
Beispiele:
- eine fehlerhafte Adressierung kann dazu fhren, dass der Datentrger
einem unautorisierten Empfnger bergeben wird,
- eine unzureichende Verpackung kann zu einer Beschdigung des Datentr-
gers fhren, aber auch einen unbefugten Zugriff ermglichen, der nicht
festgestellt werden kann,
- eine fehlende Festlegung der Verantwortung beim Empfnger kann zur
Folge haben, dass ein eingegangener Datentrger erst versptet bearbeitet
wird,
- eine nicht festgelegte Versandart kann bewirken, dass der Datentrger zu
spt zugestellt wird, da die falsche Versandart ausgewhlt wurde,
- eine fehlende Festlegung der Verantwortung beim Absender kann zur
Folge haben, dass eine terminlich zugesicherte Zustellung der Datentrger
nicht eingehalten werden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.19 Unzureichendes Schlsselmanagement bei

Verschlsselung
Werden zum Schutz der Vertraulichkeit zu bermittelnder Daten Verschlsse-
lungssysteme eingesetzt, so kann aufgrund eines unzureichenden Schlssel-
managements der gewnschte Schutz unterlaufen werden, wenn
- die Schlssel in einer ungesicherten Umgebung erzeugt oder aufbewahrt
werden,
- ungeeignete oder leicht erratbare Schlssel eingesetzt werden,
- die zur Verschlsselung bzw. Entschlsselung eingesetzten Schlssel nicht
auf einem sicheren Weg den Kommunikationspartner erreichen.
Beispiele:
- Einfachstes Negativbeispiel ist der Versand der verschlsselten Infor-
mationen und des benutzten Schlssels auf ein- und derselben Diskette. In
diesem Fall kann jeder, der in den Besitz der Diskette gelangt, die Infor-
mationen entschlsseln, vorausgesetzt, dass das bei der Verschlsselung
eingesetzte Verfahren bekannt ist.
- Kryptographische Schlssel werden im Allgemeinen durch Zufallsprozesse schlechte Zufallsquelle
erzeugt und evtl. nachbearbeitet. Wenn die verwendete Zufallsquelle unge-
eignet ist, knnen Schlssel erzeugt werden, die unsicher sind.
- Bei der Erzeugung von kryptographischen Schlsseln, insbesondere von schlechte Wahl der
Schlssel
Masterkeys, ist es fr die Sicherheit entscheidend, dass keine schwachen
kryptographischen Schlssel erzeugt werden. Dies knnen Schlssel sein,
die leicht zu erraten sind, oder Schlssel, die fr die Verschlsselung unge-
eignet sind (Beispiel: schwache und semischwache DES-Schlssel). Wenn
bei der Ableitung von Schlsseln aus Masterkeys nicht berprft wird, ob
dabei ein schwacher Schlssel erzeugt wurde, kann dadurch ein schwacher
Schlssel im Wirkbetrieb zum Einsatz kommen.
- Werden beim Triple-DES identische Teilschlssel verwendet, bewirkt die
Triple-DES-Verschlsselung nur eine einfache DES-Verschlsselung. Der
Sicherheitsgewinn geht verloren.
Aber nicht nur die Offenlegung, sondern auch der Verlust von kryptogra-
phischen Schlsseln kann zu groen Problemen fhren. Kryptographische
Schlssel knnen
- verloren oder vergessen werden,
- nicht mehr zugreifbar sein, z. B. wenn der Schlsselinhaber die Firma
verlassen hat, oder
- zerstrt werden, indem sie versehentlich gelscht werden oder indem sie
verndert werden, z. B. durch Datentrgerversagen oder Bitfehler.
Wenn die Schlssel nicht mehr verfgbar sind, knnen damit geschtzte
Daten nicht mehr entschlsselt oder auf ihre Authentizitt berprft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.20 Unzureichende oder falsche Versorgung mit

Verbrauchsgtern
Viele im Broalltag eingesetzte Gerte wie Faxgerte, Drucker, Datensiche-
rungslaufwerke usw. bentigen fr einen reibungslosen und unterbrechungs-
freien Betrieb Verbrauchsgter in ausreichender Menge. Fehlen Verbrauchs-
gter, kann der Betriebsablauf empfindlich gestrt werden. In Notfllen kann
die Handlungsfhigkeit stark beeintrchtigt sein und hohe Folgekosten
verursachen, weil Verbrauchsgter nicht in ausreichender Menge zur
Verfgung stehen.
Beispiele:
- Eingehende Faksimiles knnen nicht ausgedruckt werden, obwohl sie
ordnungsgem empfangen wurden, wenn der Papier- oder der Tonervorrat
aufgebraucht sind. Der Puffer-Speicher kann aufgrund seiner begrenzten
Speicherkapazitt die Abweisung oder den Verlust von Fax-Sendungen nur
herauszgern, aber nicht langfristig verhindern.
- Es wird ein neues Bandlaufwerk beschafft, das mit den alten Bndern nicht
kompatibel ist. Neue passende Bnder sind nicht beschafft worden, daher
knnen tagelang keine Datensicherungen angefertigt werden.
- Ein wichtiger Druckjob steht an. Die beschaffte Tonerkartusche zur
Reserve passt jedoch nicht fr den Drucker.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.21 Mangelhafte Organisation des Wechsels

zwischen den Benutzern
Arbeiten mehrere Benutzer zeitlich versetzt an einem Einzelplatz-IT-System,
so findet zwangslufig ein Wechsel zwischen den Benutzern statt. Ist dieser
nicht ausreichend organisiert und geregelt, wird er unter Umstnden nicht
sicherheitsgerecht durchgefhrt. Hierdurch knnen Missbrauchsmglichkeiten
entstehen, wenn z. B.
- laufende Anwendungen nicht korrekt abgeschlossen werden,
- aktuelle Daten nicht gespeichert werden,
- Restdaten im Hauptspeicher oder in temporren Dateien verbleiben,
- der vorhergehende Benutzer sich nicht am IT-System abmeldet und
- der neue Benutzer sich nicht ordnungsgem am IT-System anmeldet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.22 Fehlende Auswertung von Protokolldaten

Protokolldaten dienen dem Zweck, nachtrglich feststellen zu knnen, ob
Sicherheitsverletzungen im IT-System stattgefunden haben oder ob ein solcher
Versuch unternommen wurde. Daher knnen Protokolldaten fr die
Tterermittlung im Schadensfall genutzt werden. Eine weitere wichtige
Funktion der Protokolldaten ist die Abschreckung. Werden Protokolldaten
regelmig ausgewertet, knnen vorstzliche Angriffe auf ein IT-System
frhzeitig erkannt werden. Findet die Auswertung der Protokolldaten jedoch
nicht oder nur unzureichend statt und wird dies bekannt, verliert sich die
Abschreckungswirkung vollstndig.
Bei vielen IT-Systemen oder Anwendungen fehlen ausreichende Protokollie-
rungsmglichkeiten. Teilweise ist berhaupt keine Protokollierung vorge-
sehen, hufig ist es nicht mglich, die Protokollierung nach Ereignissen zu
differenzieren.
Beispiel:
Auf einem nicht vernetzten Windows 95-Rechner gibt es keine Mglichkeit,
die Aktivitten eines oder mehrerer Benutzer benutzerspezifisch zu protokol-
lieren. Es ist daher nicht festzustellen, ob Sicherheitsverletzungen im IT-
System stattgefunden haben oder ob ein solcher Versuch unternommen wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.23 Schwachstellen bei der Einbindung von DOS-

PCs in ein servergesttztes Netz
Durch die Einbindung von DOS-PCs in ein servergesttztes Netz knnen in
einem ansonsten sicheren Netz Schwachstellen hinzukommen.
Werden beispielsweise DOS-PCs in ein Unix-Netz eingebunden, ist den
Benutzern der Einsatz von Unix-Diensten wie telnet, ftp, NFS, RPCs, X-
Windows mglich. Die hierdurch entstehenden Sicherheitsprobleme sind
grundstzlich nicht verschieden von denen in einem reinen Unix-Netz.
Jedoch werden durch die Einbindung von DOS-PCs in ein servergesttztes Abhren des Netzes
Netz zustzliche unkontrollierte Netzzugnge geschaffen. Jeder Netzanschluss
kann zum Abhren des Netzes missbraucht werden. Dies ist mit geeigneter
Software (Sniffer) auch durch einen am Netz angeschlossenen PC mglich.
Damit ist es ein Leichtes, alle Informationen, d. h. alle Passwrter und auch
Dateiinhalte, die ber das Netz verschickt werden mitzulesen und zu
missbrauchen.
Ein PC-Benutzer kann zudem i. allg. den PC selbstndig administrieren. Vorspiegelung einer
falschen Identitt
Indem er den PC so konfiguriert, dass hiermit eine falsche Identitt vorge-
spiegelt wird, kann er zugelassene Dienste wie z. B. NFS oder RPCs nutzen,
um Zugriff auf Verzeichnisse und Dateien anderer Benutzer auf dem Server zu
erlangen. Er kann diese Informationen dann unbemerkt lesen, kopieren,
verflschen oder lschen.
DOS-PCs, die in ein Windows NT Netz eingebunden sind, stellen ebenfalls unkontrollierter Import
und Export von Informa-
eine potentielle Bedrohung der Sicherheit dieses Netzes dar. So knnen durch tionen
Kopieren von Dateien von einem Server auf die Festplatte eines PCs sicher-
heitsrelevante Informationen auf einem physisch nur unzureichend geschtz-
ten Medium abgelegt werden, oder durch Kopieren auf ein lokales Disketten-
laufwerk knnen solche Informationen an externe Stellen abgegeben werden,
ohne dass dies von den Protokollierungsfunktionen des Servers erfasst wird.
Umgekehrt besteht die Gefahr des Imports von Computer-Viren ber unge-
ngend abgesicherte Diskettenlaufwerke.
Unix-Rechner, die mittels des Programmes SAMBA ihre Dateisysteme fr SAMBA
Windows-Rechner verfgbar machen, knnen bei mangelhafter Konfiguration
ein hohes Sicherheitsrisiko darstellen. So ist es z. B. mglich, dass ein
Benutzer, der sich auf einem Windows-Rechner mit der Kennung "root"
anmeldet, bei einem weiteren Anmeldevorgang unter Unix-Rechner sich auch
hier Zugriff auf die "root"-Kennung verschaffen kann und somit Administra-
tor-Rechte erhlt.
Die Verwendung eines Primary Domnen Controller (PDC) als Passwort-
server fr SAMBA projiziert eventuell bestehende Sicherheitslcken von
Windows NT auf das Unix-System, da ein kompromittierter NT-Server somit
einer unberechtigten Person Zugriff auf das Unix-Filesystem ermglichen
kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.24 Vertraulichkeitsverlust schutzbedrftiger Daten

des zu schtzenden Netzes
Bei einem nicht durch eine Firewall geschtzten Netz, das mit einem externen
Netz wie dem Internet gekoppelt ist, knnen aus dem externen Netz verschie-
dene Daten des internen Netzes wie z. B. Mailadressen, IP-Nummern, Rech-
nernamen und Benutzernamen abgerufen werden. Dadurch lassen sich Rck-
schlsse auf die interne Netzstruktur und dessen Anwender ziehen. Je mehr
Informationen ein Angreifer ber potentielle Angriffsziele hat, desto mehr
Angriffsmglichkeiten hat er. Wenn ein Angreifer z. B. Benutzernamen eines
IT-Systems kennt, kann er versuchen, die zugehrigen Passwrter zu erraten
oder ber Wrterbuchattacken herauszufinden (siehe auch G 5.18 Systema-
tisches Ausprobieren von Passwrtern).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.25 Einschrnkung der bertragungs- oder

Bearbeitungsgeschwindigkeit durch Peer-to-
Peer-Funktionalitten
In einem servergesttzten Netz knnen auf Clients aktivierte Peer-to-Peer-
Funktionalitten die verfgbare bertragungsbandbreite einschrnken, da
dasselbe physikalische Medium beansprucht wird. Beispielsweise erfolgen
Zugriffe auf Dateien des Servers unter Umstnden mit erheblichen Verzge-
rungen, wenn gleichzeitig ber die Peer-to-Peer-Funktionen groe Dateien
von Client zu Client kopiert werden.
Ein Arbeitsplatz-Computer kann in einem Peer-to-Peer-Netz als "Server", d. h.
als Applikations- oder Dateianbieter fr andere Rechner, eingesetzt werden.
Dabei wird er durch die zu verwaltenden Peer-to-Peer-Funktionalitten unter
Umstnden erheblich belastet, wodurch die lokale Bearbeitungsgeschwindig-
keit deutlich abnimmt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.26 Fehlendes oder unzureichendes Test- und

Freigabeverfahren
Wird neue Hard- oder Software nicht oder nur unzureichend getestet und ohne
Installationsvorschriften freigegeben, kann es passieren, dass Fehler in der
Hard- oder Software nicht erkannt werden oder dass die notwendigerweise
einzuhaltenden Installationsparameter nicht erkannt bzw. nicht beachtet wer-
den. Diese Hardware-, Software- oder Installationsfehler, die aus einem feh-
lenden oder unzureichenden Software-Test- und Freigabeverfahren resultieren,
stellen eine erhebliche Gefhrdung fr den IT-Betrieb dar.
Im Vertrauen auf eine problemlose Installation neuer Hard- bzw. Software
wird oftmals bersehen, dass mgliche Schden in keinem Verhltnis zu dem
Aufwand stehen, den ein geordnetes Test- und Freigabeverfahren erfordert.
Programme oder IT-Systeme werden unzureichend getestet und mit Fehlern in
eine Produktionsumgebung eingebracht. Die Fehler wirken sich in der Folge
strend auf den bis zu diesem Zeitpunkt problemlosen Betrieb aus.
Beispiele fr solche Schden werden nachfolgend aufgezeigt:
- Programme oder Programm-Updates lassen sich nicht sinnvoll nutzen, da Ressourcen
fr ein annehmbares Verarbeitungstempo mehr Ressourcen (z. B. Haupt-
speicher, Prozessorkapazitt) als erwartet bentigt werden. Wird dies nicht
im Test erkannt, kann dies zu erheblichen Fehl- oder Folgeinvestitionen
fhren. Nicht selten fhrten Entscheidungen gegen weitere Investitionen
dazu, dass ein Softwareprodukt zwar gekauft und bezahlt, jedoch nie be-
nutzt wurde.
- Eingebte Arbeitsablufe werden nach Installation neuer Software Arbeitsbehinderungen
mageblich behindert. Der mit der Installation des Programms beab-
sichtigte Nutzen stellt sich erst bedeutend spter ein, da die Mitarbeiter im
Vorfeld nicht geschult bzw. nicht ber die neuen Funktionen des Pro-
gramms informiert wurden.
- Durch das Einspielen eines neuen Updates einer DBMS-Standardsoftware,
das mit Fehlern behaftet ist, steht die Datenbank nicht mehr zur Verfgung
und es kann zu einem Datenverlust kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.27 Fehlende oder unzureichende Dokumentation

Verschiedene Formen der Dokumentation knnen betrachtet werden: die Pro-
duktbeschreibung, die Administrator- und Benutzerdokumentation zur
Anwendung des Produktes und die Systemdokumentation.
Eine fehlende oder unzureichende Dokumentation der eingesetzten IT-
Komponenten kann sowohl im Auswahl- und Entscheidungsprozess fr ein
Produkt, als auch bei einem Schadensfall im Wirkbetrieb erhebliche Auswir-
kungen haben.
Bei einer unzureichenden Dokumentation kann sich im Schadensfall, bei- Schadensbehebung
ohne Dokumentation
spielsweise durch den Ausfall von Hardware bzw. Fehlfunktionen von Pro- schwierig
grammen, die Fehlerdiagnose und -behebung erheblich verzgern oder vllig
undurchfhrbar sein.
Dies gilt auch fr die Dokumentation von Leitungswegen und Verkabelungen
innerhalb der Gebude-Infrastruktur. Ist aufgrund unzureichender Dokumen-
tation die genaue Lage von Leitungen nicht bekannt, so kann es bei Bau-
arbeiten auerhalb oder innerhalb eines Gebudes zu Beschdigungen von
Leitungen kommen. Dabei kann es zu lngeren Ausfallzeiten (Eintritt eines
Notfalls) oder unter Umstnden sogar zu lebensbedrohenden Gefahren, z. B.
durch Stromschlag, kommen.
Beispiele:
- Wenn von einem Programm Arbeitsergebnisse in temporren Dateien vertrauliche Infor-
mationen versehentlich
zwischengespeichert werden, ohne dass dies ausreichend dokumentiert ist, offen gelegt
kann dies dazu fhren, dass die temporren Dateien nicht angemessen
geschtzt und vertrauliche Informationen offengelegt werden. Durch
fehlenden Zugriffsschutz auf diese Dateien oder eine nicht korrekte physi-
kalische Lschung der nur temporr genutzten Bereiche knnen Informa-
tionen Unbefugten zugnglich werden.
- Bei Installation eines neuen Softwareproduktes werden bestehende Konfi-
gurationen abgendert. Andere, bislang fehlerfrei laufende Programme sind
danach falsch parametrisiert und strzen ggf. ab. Durch eine detaillierte
Dokumentation der Vernderung bei der Installation von Software liee
sich der Fehler schnell lokalisieren und beheben.
- In einer greren Behrde wurde die Verkabelung der IT durch eine Dokumentationspflicht
vergessen
externe Firma vorgenommen. Die Anfertigung einer Dokumentation war
im Leistungsumfang nicht enthalten. Da nach Fertigstellung der Ver-
kabelung mit der Firma kein Wartungsvertrag abgeschlossen wurde,
verfgte die Behrde nicht ber die notwendige Dokumentation. Erwei-
terungen des Netzes konnten nur mit erheblichen Verzgerungen
vorgenommen werden.
- In einer z/OS-Installation wurden jeden Abend automatisch Batch-Jobs
zur Verarbeitung von Anwendungsdaten gestartet. Fr die Verarbeitung
war es wichtig, dass die Batch-Jobs in der richtigen Reihenfolge abliefen.
Als eines Abends die Automation versagte, mussten die Jobs manuell
gestartet werden. Aufgrund fehlender Dokumentation wurden die Batch-
Jobs in der falschen Reihenfolge gestartet. Dies fhrte zu Abbrchen in der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verarbeitung der Anwendungsdaten und zu Verzgerungen in der Produktion

um mehrere Stunden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.28 Verste gegen das Urheberrecht

Der Einsatz nicht-lizensierter Software kann einen Versto gegen das
Urheberrecht darstellen und sowohl zu zivil- als auch strafrechtlichen
Konsequenzen fhren.
Behrden und Unternehmen, in denen Raubkopien zum Einsatz kommen,
knnen im Rahmen des Organisationsverschuldens, unabhngig von der
Schuldform (Vorsatz oder Fahrlssigkeit) vom Urheberrechtseigentmer
schadensersatzpflichtig gemacht werden.
Beispiel:
In einem Unternehmen wurde eine groe Anzahl Benutzeroberflchen einge-
setzt, ohne dass die hierfr erforderlichen Lizenzen erworben wurden. Die
Kosten fr die erforderliche Nachlizenzierung sowie den Schadensersatz an
den Urheberrechtseigentmer beliefen sich auf ein Vielfaches der
Lizenzgebhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.29 Softwaretest mit Produktionsdaten

Vielfach ist zu beobachten, dass Softwaretests mit Produktionsdaten vollzogen
werden. Als wesentliche Grnde werden hierfr angefhrt, dass nur im
direkten Vergleich mit vorhandenen Arbeitsergebnissen eine abschlieende
Beurteilung ber die Funktion und Performance des Produktes mglich ist.
Darber hinaus sind mangelndes Sicherheitsbewusstsein, berzogenes
Vertrauen in die zu testende Software und Unkenntnis ber mgliche
schdliche Auswirkungen urschlich fr diese Vorgehensweise.
Beim Test mit Produktionsdaten kann es zu folgenden Problemen kommen:
- Software wird mit Kopien von Produktionsdaten in isolierter Test-
umgebung getestet:
Wenn neue Software mit nicht anonymisierten Daten getestet wird,
erhalten evtl. nicht befugte Mitarbeiter, bzw. Dritte, die mit dem
Softwaretest beauftragt worden sind, hierbei Einblick in Dateien mit evtl.
vertraulichen Informationen.
- Software wird mit Produktionsdaten im Wirkbetrieb getestet:
Fehlfunktionen von Software whrend des Testens knnen ber den oben
geschilderten Fall hinaus beispielsweise dazu fhren, dass neben der Ver-
traulichkeit der Produktionsdaten auch deren Integritt und Verfgbarkeit
beeintrchtigt werden.
Aufgrund der Inkompatibilitt unterschiedlicher Programme knnen
Seiteneffekte auftreten, die bei anderen Systemkomponenten zu nach-
haltigen Beeintrchtigungen fhren knnen. Bei vernetzten Systemen kann
das von Performanceverlusten bis hin zum Systemabsturz des Netzes
reichen.
Durch fehlerhaftes Verhalten der zu testenden Software oder Bedienfehler
knnen Produktionsdaten ungewollt verndert werden. Mglicherweise
wird diese Vernderung nicht festgestellt. Da Datenbestnde, um unntige
Redundanz zu vermeiden, zunehmend durch unterschiedliche Programme
gemeinsam genutzt werden, knnen sich diese Fehler auch auf andere IT-
Anwendungen auswirken. Im Schadensfall ist nicht nur der Aufwand fr
die Rekonstruktion der Daten notwendig, darber hinaus mssen bereits
erstellte Arbeitsergebnisse auf ihre Integritt berprft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.30 Unzureichende Domnenplanung

Eine unzureichende Planung der Domnen und ihrer Vertrauensbeziehungen
in einem Windows NT Netz kann dazu fhren, dass Vertrauensbeziehungen zu
Domnen bestehen, die nicht als vertrauenswrdig zu betrachten sind. Damit
ist es Benutzern der betreffenden Domnen unter Umstnden mglich, auf
Ressourcen der vertrauenden Domne zuzugreifen, ohne dass dies dort
beabsichtigt ist oder auch nur erkannt wird. Dies kann insbesondere dann
geschehen, wenn die Zugriffsrechte der vertrauenden Domne in der
Annahme, dass keine andere Domne auf die lokalen Ressourcen zugreift,
relativ weitgehend festgesetzt wurden.
Umgekehrt knnen fehlende Vertrauensbeziehungen zwischen Domnen dazu
fhren, dass sich Benutzer unntigerweise explizit bei fremden Domnen
authentisieren mssen, was bei mangelnder Koordination der Passwrter zwi-
schen diesen Domnen zu Verwirrung fhrt. Der Benutzer muss sich dann
eine Vielzahl von Passwrtern merken, was zu einer Beeintrchtigung der
Sicherheit fhren kann, wenn er sich die Passwrter aufschreibt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.31 Unzureichender Schutz des Windows NT

Systems
Windows NT wird mit sehr weitgehenden Zugriffsrechten auf das Datei-
system und auf die Registrierung ausgeliefert. Wenn diese Zugriffsrechte nicht
nach der Installation entsprechend den lokalen Sicherheitsanforderungen
strikter eingestellt werden, besitzt effektiv jeder Benutzer Zugriff auf alle
Dateien und auf die gesamte Registrierung, d.h. der Zugriffsschutz ist de facto
ausgeschaltet.
Weiterhin ist Windows NT nicht in der Lage, den Zugriff auf Disketten- und
CD-ROM-Laufwerke sowie auf Bnder zu kontrollieren, so dass hier eine
Mglichkeit zu unzulssigem Datenimport und -export besteht, wenn nicht
durch zustzliche Manahmen der Zugriff auf diese Datentrger eingeschrnkt
oder zumindest auf organisatorischer Ebene kontrolliert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.32 Unzureichende Leitungskapazitten

Bei der Planung von Netzen wird oft der Fehler begangen, die Kapazitts-
auslegung ausschlielich am aktuellen Bedarf vorzunehmen. Dabei wird
bersehen, dass die Kapazittsanforderungen an das Netz stetig steigen, z. B.
wenn neue IT-Systeme in das Netz integriert werden oder das bertragene
Datenvolumen zunimmt.
Wenn die Kapazitt des Netzes nicht mehr ausreicht, wird die bertragungs-
geschwindigkeit und ggf. auch die Erreichbarkeit im Netz fr alle Benutzer
stark eingeschrnkt. Beispielsweise werden Dateizugriffe auf entfernten IT-
Systemen erheblich verzgert, wenn gleichzeitig das Netz von anderen
Benutzern stark in Anspruch genommen wird, wie durch das Verschieben von
groen Dateien von einem IT-System zum anderen.
Beispiel:
Eine verteilte Organisation baut fr die Datenkommunikation ein Netz ber
ISDN-So-Verbindungen auf. Nach Einfhrung eines graphisch orientierten,
firmeneigenen Intranet kommt die Datenkommunikation fast zum Stillstand.
Erst das Umstellen auf S2M-bertragungswege schafft die ntige bertra-
gungskapazitt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.33 Nicht gesicherter Aufstellungsort von Novell

Netware Servern
Die Aufstellung von Novell Netware Servern in einer nicht gesicherten Umge-
bung (z. B. Flure, nicht verschlossene Serverrume) stellt eine erhebliche
Gefhrdung fr die IT-Sicherheit dar.
Direkte Eingaben an der Server-Konsole bzw. das Laden von NLMs (Netware
Loadable Modules) am Server knnen dazu fhren, dass die installierten
Sicherheitsmechanismen auer Kraft gesetzt werden, ohne dass dieser
Umstand dem Administrationspersonal bzw. dem IT-Sicherheitsmanagement
bekannt wird.
Beispiel:
Durch das Laden spezieller NLMs ist es mglich, einen Supervisor-quivalen-
ten Benutzer zu generieren bzw. einen existierenden Benutzer mit Supervisor-
quivalenten Rechten zu versehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Novell Netware Sicherheitsmechanismen
Das Netzbetriebssystem Novell Netware verfgt ber eine Sammlung an
Sicherheitsmechanismen, die den unerlaubten Zugriff auf Dateien des Servers
abwehren.
Diese Sicherheitsmechanismen werden jedoch nicht automatisch aktiviert,
sondern mssen durch die Systemadministration nach dem erstmaligen Start
des Servers eingerichtet werden.
Werden die Sicherheitsmechanismen eines Novell Netware Servers nicht oder
nur unzureichend installiert, so kann der unerlaubte Zugriff auf schtzens-
werte Dateien entscheidend erleichtert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.35 Fehlende Protokollierung unter Windows 95

Auf einem nicht vernetzten Windows 95-Rechner gibt es keine Mglichkeit,
die Aktivitten eines oder mehrerer Benutzer benutzerspezifisch zu
protokollieren. Es ist daher nicht festzustellen, ob Sicherheitsverletzungen im
IT-System stattgefunden haben oder ob ein solcher Versuch unternommen
wurde.
Hinweis:
Der Inhalt dieser Gefhrdung wurde in G 2.22 Fehlende Auswertung von
Protokolldaten integriert und wird in der Version 1999 des IT-Grundschutz-
handbuchs in keinem Baustein mehr benutzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.36 Ungeeignete Einschrnkung der

Benutzerumgebung
Verschiedene Betriebssysteme (z. B. Windows 95, Windows NT) und PC-
Sicherheitsprodukte bieten die Mglichkeit, die Benutzerumgebung indi-
viduell fr jeden Benutzer einzuschrnken. Dabei bestehen prinzipiell zwei
Mglichkeiten:
1. Bestimmte Funktionalitten werden erlaubt, alle anderen sind verboten.
2. Bestimmte Funktionalitten werden verboten, alle anderen sind erlaubt.
In beiden Fllen besteht die Mglichkeit, den Benutzer derart einzuschrnken,
dass dieser wesentliche Funktionen nicht mehr ausfhren kann oder dass sogar
ein sinnvolles und effizientes Arbeiten mit dem PC nicht mehr mglich ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.37 Unkontrollierter Aufbau von

Kommunikationsverbindungen
Beim Einsatz von Kommunikationskarten innerhalb eines IT-Systems (Fax-,
Modem- oder ISDN-Karten) ist fr den Benutzer nicht immer offensichtlich,
was auer seinen Nutz- und Protokollinformationen zustzlich bertragen
wird. Nach Aktivierung einer Kommunikationskarte ist es grundstzlich
mglich, dass diese, ohne Initiierung durch den Benutzer, Verbindungen zu
einer nicht gewnschten Gegenstelle aufbaut oder durch Dritte ber dem
Benutzer nicht bekannte Remote-Funktionalitten angesprochen wird.
Beispiele:
- Bei der erstmaligen Konfiguration einer Faxkarte wurde der Benutzer vom
Installationsprogramm nach der Landesvorwahl von Schweden gefragt. Zu
vermuten ist, dass der Kartenhersteller ber den Einsatz seines Produkts,
evtl. aus Grnden des Produkt-Marketings, informiert werden wollte.
- Eine groe Anzahl von Modem-Karten untersttzt den ferngesteuerten
Zugriff auf IT-Systeme. Zwar lassen sich diese Zugriffe ber teilweise
sogar auf den Karten integrierte Mechanismen (Callback-Option und
Rufnummernauthentisierung) absichern, voreingestellt ist dies jedoch
nicht. Ein so konfiguriertes IT-System lsst sich von auen ber die
Modemkarte vollstndig manipulieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Datenbank-Sicherheitsmechanismen
Jede Datenbank-Standardsoftware stellt in der Regel eine Reihe von Sicher-
heitsmechanismen bereit, mittels derer die Daten vor unberechtigtem Zugriff
o. . geschtzt werden knnen. Sie sind jedoch nicht unbedingt automatisch
aktiv, sondern mssen vom Datenbank-Administrator meistens manuell einge-
schaltet werden. Wird davon kein Gebrauch gemacht, so kann weder die Ver-
traulichkeit noch die Integritt der Daten gewhrleistet werden. In diesem Fall
ist es dann meistens nicht mglich, solche Schutzverletzungen zu erkennen
und zu protokollieren. Der Verlust bzw. die Manipulation von Daten bis hin
zur Zerstrung der Datenbank selbst kann die Folge sein.
Beispiel:
Bei der Datenbank MS Access ist die Aktivierung des Passwortschutzes optio-
nal. Hierdurch kann es auf einfache Weise zu einem unberechtigten Zugang
zum Datenbanksystem und damit auch zu einem unberechtigten Zugriff auf
die dort gespeicherten Daten kommen. Eine Kontrolle der Datenbanknutzung
ist in diesem Fall nicht mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.39 Komplexitt eines DBMS

Die Auswahl und der Einsatz einer Datenbank-Standardsoftware erfordert
sorgfltige Planung, Installation und Konfiguration des Datenbank-Manage-
mentsystems (DBMS), um einen strungsfreien Einsatz zu gewhrleisten. Die
Vielzahl mglicher Gefhrdungen sollen durch die nachfolgenden Beispiele
verdeutlicht werden.
Auswahl einer ungeeigneten Datenbank-Standardsoftware
- Es wird ein DBMS ausgewhlt, welches in der geplanten Einsatzumgebung
nicht lauffhig ist. Dies kann daraus resultieren, dass das DBMS an ein
bestimmtes Betriebssystem gebunden ist oder die Mindestanforderungen
an die Hardware nicht erfllt werden.
- Das ausgewhlte DBMS stellt ein Sicherheitsrisiko dar, weil die vom Her-
steller zur Verfgung gestellten Sicherheitsmechanismen nicht ausreichen,
um die geforderte Verfgbarkeit, Integritt und Vertraulichkeit der Daten
zu gewhrleisten.
Fehlerhafte Installation bzw. Konfiguration der Datenbank-Standardsoft-
ware
- Es knnen sich weitere Gefhrdungen ergeben, wenn die vom Hersteller
empfohlenen Sicherheitsmanahmen falsch oder gar nicht durchgefhrt
werden.
Beispiel: Die Kontrolldateien eines Datenbanksystems werden nicht
gespiegelt bzw. die gespiegelte Kontrolldatei wird nicht auf einer anderen
Festplatte abgelegt. Ein Plattencrash fhrt dabei unweigerlich zur
Zerstrung der Datenbank.
- Die physischeVerteilung der Daten ist unzureichend (falls das DBMS eine
physikalische Verteilung vorsieht).
Beispiel: In einer Oracle-Datenbank gibt es eine maximal zulssige Anzahl
Dateien pro Tablespace. Werden nun alle Daten im System-Tablespace
verwaltet, so knnen keine Dateien mehr hinzugefgt werden, wenn diese
maximale Anzahl erreicht ist. Da im System-Tablespace auch das Data
Dictionary abgelegt ist, kann dieses Problem nur ber eine komplette Neu-
Installation der Datenbank behoben werden.
- Durch falsche Parametereinstellungen kann der Zugriff auf bestimmte
Daten verhindert werden.
Beispiel: Durch eine falsche Lndereinstellung in einer Datenbank-
Software kann die Darstellung von Umlauten unmglich gemacht werden.
Fehlerhafte Konzeption der Datenbank
- Fehlende Relationen zwischen einzelnen Tabellen knnen zu einem
Verlust der Datenkonsistenz bzw. der Datenbankintegritt fhren.
- Werden anwendungsspezifische Daten nicht physikalisch voneinander
getrennt gespeichert, kann ein Ausfall einer einzigen Festplatte zu einem
Komplettausfall aller Anwendungen fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden keine Datenbanktrigger oder Stored Procedures eingesetzt, kann

es zu Inkonsistenzen der Daten kommen, wenn die Anwendung dies nicht
selbst bercksichtigt.
- Durch eine mangelhafte Konzeption des Einsatzes von Datenbanktriggern
und Stored Procedures kann es zu einem Verlust der Datenintegritt oder
unkontrollierten Datenmanipulationen kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.40 Komplexitt des Datenbankzugangs/-zugriffs

Die Benutzer greifen ber ein Datenbankmanagementsystem (DBMS) auf eine
oder mehrere Datenbanken zu. Dabei knnen sie dies direkt tun oder aber von
einer Anwendung aus. Um die Integritt einer Datenbank zu gewhrleisten,
mssen alle Datenbankzugriffe von einer zentralen Stelle aus kontrolliert wer-
den. Aufgrund der Komplexitt solcher Zugriffe knnen die folgenden
Probleme entstehen.
Fehlerhafte Konzeption der Benutzerumgebung
- Ist der Berechtigungsumfang fr die Benutzer zu restriktiv definiert, kann
dies dazu fhren, dass sie bestimmte Arbeiten nicht durchfhren knnen.
- Ist der Berechtigungsumfang fr die Benutzer dagegen zu umfangreich,
kann dies dazu fhren, dass Daten unberechtigt manipuliert bzw. einge-
sehen werden knnen. Dadurch werden die Integritt und Vertraulichkeit
der Datenbank verletzt.
- Wird es den Benutzern erlaubt, direkt auf die Datenbank zuzugreifen (im
Gegensatz zum Zugriff aus einer Anwendung heraus), so besteht das
Risiko des Integrittsverlustes der Datenbank durch Datenmanipulationen,
deren Auswirkungen die Benutzer nicht abschtzen knnen.
- Werden Datenbankobjekte von den darauf zugreifenden Anwendungen
nicht explizit durch ein entsprechendes Berechtigungs- und Zugriffs-
konzept geschtzt, so besteht das Risiko, dass die Datenbankobjekte selbst
manipuliert werden (Manipulation von Feldern einer Tabelle, Manipulation
von Tabellen-Indizes etc.). Dies kann zur Zerstrung der Datenbank
fhren.
Remote-Zugriff auf Datenbanken
- Wird die Datenbank in einem Netz zur Verfgung gestellt, so knnen
durch mangelnde Sicherheitsvorkehrungen im Bereich des Remote-
Zugriffs auf die Datenbank sowohl Daten manipuliert als auch unberechtigt
eingesehen werden. Auch dies verletzt die Integritt und Vertraulichkeit
der Datenbank.
Datenbankabfragen
- Die Menge aller mglichen Datenbankabfragen muss fr jeden Benutzer
eingeschrnkt sein bzw. bestimmte Abfragen mssen explizit verboten
werden. Ist dies nicht der Fall, kann dies (insbesondere bei statistischen
Datenbanken) zum Verlust der Vertraulichkeit schutzbedrftiger Daten
fhren.
- Werden Datenbankabfragen innerhalb einer Anwendung nicht gem des
SQL-Standards formuliert, so kann dies dazu fhren, dass sie vom DBMS
nicht bearbeitet werden knnen und zurckgewiesen werden (insbesondere
beim Einsatz von DBMSen verschiedener Hersteller).
- Bei der Verwendung von nicht exakt formulierten Datenbankabfragen kann
dies dazu fhren, dass durch eine nderung der Datenbankobjekte die
Datenbankabfrage pltzlich falsche oder unerwartete Ergebnisse liefert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel:
Die Abfrage "SELECT * FROM Tabelle" liefert alle Attribute bzw. Felder
eines Tupels bzw. Datensatzes. Wird nun ein Feld in der Tabelle
hinzugefgt oder gelscht, so hat dies u. U. fatale Auswirkungen auf eine
Anwendung, in der eine solche Datenbankabfrage benutzt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.41 Mangelhafte Organisation des Wechsels von

Datenbank-Benutzern
Teilen sich mehrere Benutzer einer Datenbank den gleichen Arbeitsplatz, so
besteht die Gefahr von ungewollten oder gezielten Datenmanipulationen,
wenn der Wechsel zwischen den Benutzern nicht organisiert ist bzw. der
Wechsel nicht ordnungsgem durchgefhrt wird. Auch ist dann die
Vertraulichkeit der Daten nicht mehr gewhrleistet.
Beispiel:
Wird eine Anwendung, die auf eine Datenbank zugreift, vor einem
Benutzerwechsel nicht ordnungsgem verlassen, so fhren die
unterschiedlichen Berechtigungsprofile der betroffenen Benutzer zu den o. g.
Gefhrdungen. Auch wird dabei der Protokollmechanismus der Datenbank
unterlaufen, da dieser die Datenmodifikationen und Aktivitten der aktiven
Benutzer-Kennung festhlt. Diese Kennung stimmt aber in einem solchen Fall
nicht mit dem tatschlichen Benutzer berein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.42 Komplexitt der NDS

Die Netware Verzeichnisdienste NDS (Netware Directory Services) ermgli-
chen das Einrichten einer gemeinsamen, dezentralen Verzeichnisdatenbank
aller logischen und physischen Ressourcen in einem Netz. Jede Netzressource
wird durch einen eindeutigen Eintrag in dieser Datenbank reprsentiert, wobei
es keine Rolle spielt, wo sich die Ressourcen tatschlich befinden. Der
Zugang zum Netz bzw. der Zugriff auf eine Netzressource erfolgt dabei,
anders als bei Novell Netware 3.x, nicht ber einen bestimmten Netware 4.x
Server, sondern ber den Verzeichnisdienst des Novell Netzes (siehe M 2.151
Entwurf eines NDS-Konzeptes).
Die NDS ist die zentrale Komponente der Ressourcenverwaltung von Novell
Netware 4.x und die Anforderungen an deren korrekte Funktionsweise sind
entsprechend hoch. Aufgrund der komplexen Administrationsmglichkeiten
kann es zum Verlust der Verfgbarkeit, Vertraulichkeit sowie Integritt und
dabei beispielsweise zu folgenden konkreten Gefhrdungen kommen:
- Der Zugang eines Benutzers zum Netz erfolgt ber die Authentisierung
gegenber der NDS. Diese Anmeldung findet am nchstgelegenen Net-
ware 4-Server statt, der die Master-Partition des Verzeichnisbaums oder
eine Kopie davon gespeichert hat. Existieren zu wenige Kopien im Netz,
mssen sich alle Benutzer an den gleichen Servern beglaubigen. Jeder
Anmeldevorgang bedeutet zustzliche Serverbelastung und zustzliche
Netzlast. Dies kann zu lngeren Wartezeiten bei der Anmeldung fhren
sowie die Verfgbarkeit beeintrchtigen.
Werden keine Kopien der Master-Partition auf weiteren Netware 4-Servern
angelegt, ist eine Anmeldung am Netz bei einem Fehler in der NDS-Daten-
bank nicht mehr mglich.
- Werden beim Entwurf des Verzeichnisbaumes zu viele Organisationen und
Unterorganisationen ineinander verschachtelt, erhht sich der
Administrationsaufwand erheblich. Auerdem wird dann das Auffinden
von Netzressourcen fr die Administratoren und die Benutzer
unbersichtlich.
- Wenn in einem WAN-Verbund nicht an jedem Standort eine Reproduktion
der zugehrigen Partitions des Standortes gespeichert wird, ist eine Anmel-
dung am Netz bei einem Ausfall des WANs fr die betroffenen Standorte
nicht mehr mglich.
- Werden zuviele Reproduktionen einer Partition in einem WAN-Verbund
eingerichtet, entsteht sehr hoher Netzverkehr im WAN, da bei jeder
Anmeldung das Anmeldedatum des Benutzers in allen Reproduktionen
gendert werden muss.
- In den verschiedenen Versionen und Patchleveln von Novell Net-
ware Version 4 kann auch das Modul DS.NLM verschiedene Versionen
aufweisen. Diese Information wird jedoch von den Netware 4-Servern
genutzt, um nderungswnsche an der NDS-Datenbank zu filtern. Dies
kann u. U. dazu fhren, dass sich die Netware 4-Server untereinander nicht
ber die nderungen an der NDS informieren knnen, so dass es dort zu
Inkonsistenzen kommt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.43 Migration von Novell Netware 3.x nach Novell

Netware Version 4
Sind in einem Netz sowohl Netware 3.x als auch Netware 4.x Server vorhan-
den, so knnen prinzipiell zwei Szenarien unterschieden werden:
- die Netware 3.x Server wurden migriert und damit in die NDS integriert
- Netware 3.x und Netware 4.x Server arbeiten im Parallelbetrieb
In diesem Zusammenhang sind die folgenden konkreten Gefhrdungen zu
beachten:
- Bei einer Migration eines Netware 3.x Servers wird ein Groteil seiner
NLMs ersetzt, so dass er vom Netware-Administrator ber einen Net-
ware 4.x Server kontrolliert werden kann. Ein solcher migrierter Net-
ware 3.x Server kann ohne aufwendige Manahmen nicht mehr von seinem
zustndigen Netware 4.x Server getrennt werden, um wieder als eigenstn-
diger Netware 3.x Server im Netz fungieren zu knnen.
- Wird nach der Migration eines Netware 3.x Servers keine Bindery Emula-
tion auf dem Netware 4.x Server aktiviert, knnen sich Benutzer mit der
alten Client-Software nicht mehr am Netware 4 Netz anmelden.
- Werden die Netware 3.x Server getrennt als eigenstndiges Netz betrieben,
entsteht ein sehr hoher administrativer Aufwand, da dann die Benutzer
weiterhin an allen Netware 3.x Servern einzeln und zustzlich in der NDS
verwaltet werden mssen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.44 Inkompatible aktive und passive

Netzkomponenten
Durch inkompatible aktive Netzkomponenten knnen Probleme verursacht
werden, die im Umfeld nicht oder noch nicht vollstndig standardisierter
Kommunikationsverfahren auftreten, wie z. B. ATM oder Tag-Switching. Um
das betreffende Kommunikationsverfahren nutzen zu knnen, sind die
Hersteller aufgrund der fehlenden oder nur teilweise vorhandenen Standards
gezwungen, proprietre Implementierungen einzusetzen.
Inkompatibilittsprobleme dieser Art knnen entstehen, wenn bestehende
Netze um aktive Netzkomponenten anderer Hersteller ergnzt werden oder
wenn Netze mit Netzkomponenten unterschiedlicher Hersteller aufgebaut
werden.
Werden aktive Netzkomponenten mit unterschiedlichen Implementierungen
des gleichen Kommunikationsverfahrens gemeinsam in einem Netz betrieben,
kann es zu einem Verlust der Verfgbarkeit des gesamten Netzes, von einzel-
nen Teilbereichen oder bestimmter Dienste kommen. Zwei Flle knnen je
nach Art der Inkompatibilitt unterschieden werden:
- Durch nicht interoperable Implementierungen eines Kommunikations-
verfahrens kann ber die zugehrigen Komponenten hinweg keine
Kommunikation erfolgen.
Beispiel: ATM-Komponenten knnen unterschiedliche Signalisierungspro-
tokolle verwenden, z. B. gem UNI (User Network Interface) Version 3.0
und UNI Version 3.1, die nicht interoperabel zueinander sind.
- Auch auf aktiven Netzkomponenten, die prinzipiell interoperabel sind,
knnen spezifische Dienste unterschiedlich implementiert sein. Dies hat
zur Folge, dass die betreffenden Dienste nicht oder nicht netzweit zur Ver-
fgung stehen, obwohl eine Kommunikation ber diese Komponenten
hinweg mglich ist.
Beispiel: Es existieren proprietre Implementierungen redundanter LAN
Emulation Server fr ATM-Netze. Besteht ein ATM-Netz z. B. aus zwei
ATM-Switches, von denen ein Switch ber eine solche proprietre Imple-
mentierung verfgt und der andere nicht, kann zwar eine Kommunikation
via LANE (LAN Emulation) erfolgen, der proprietr implementierte Dienst
jedoch nicht genutzt werden.
Aber auch die Kombination von inkompatiblen passiven Netzkomponenten
kann die Verfgbarkeit eines Netzes gefhrden. So existieren fr Twisted-
Pair-Kabel Ausfhrungen in 100 und 150 Ohm, die nicht ohne einen ent-
sprechenden Umsetzer zusammen verwendet werden drfen. Eine ungeeignete
Kombination von aktiven und passiven Netzkomponenten kann die
Verfgbarkeit ebenfalls beeintrchtigen, wenn beispielsweise ein Netz-
zugangsprotokoll auf einem nicht hierfr definierten Medium betrieben wird.
Beispielsweise lsst sich ATM nicht ber ein 50 Ohm Koaxialkabel betreiben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.45 Konzeptionelle Schwchen des Netzes

Die Planung des Auf- und Ausbaus eines Netzes ist ein kritischer
Erfolgsfaktor fr den Netzbetrieb. Insbesondere bei den immer krzer
werdenden Innovationszyklen in der IT knnen sich Netze, die auf Grund
ihrer Konzeption nicht neuen Erfordernissen angepasst werden knnen,
schnell zu einem Engpass entwickeln:
- Abhngig von einer Anforderungsermittlung von Netzteilnehmern (z. B.
Arbeitsgruppen) an die Vertraulichkeit der Daten und die Integritt des
Netzes muss das Netz entsprechend konzipiert worden sein. Ansonsten
knnen vertrauliche Daten einer Arbeitsgruppe von anderen, hierzu
unbefugten Netzteilnehmern mitgelesen werden. Unter diesem Aspekt
kann die Vertraulichkeit auch durch den Umzug von
Arbeitsgruppenteilnehmern oder der ganzen Arbeitsgruppe verloren gehen,
wenn es nicht mglich ist, im Netz neue vertrauliche Bereiche einzurichten
bzw. zu ndern. Diese Gefhrdung betrifft analog die Integritt des Netzes
bzw. die Integritt von Netzsegmenten.
Beispiel: Fr eine Arbeitsgruppe mit besonderen Anforderungen an Ver-
traulichkeit und Integritt ihrer Daten wurde ein eigenes Teilnetz
eingerichtet, welches durch einen Router abgetrennt ist. Dieses Segment ist
durch die Kabelfhrung auf ein Gebude beschrnkt. Nach einem Umzug
mehrerer Mitglieder dieser Arbeitsgruppe in andere Gebude mssen diese
ber das normale Produktivnetz miteinander kommunizieren. Die
Vertraulichkeit und auch die Integritt der Daten kann nicht mehr
gewhrleistet werden.
- Werden neue Anwendungen mit einem hheren als zum Planungszeitpunkt
bercksichtigten Bandbreitenbedarf auf dem Netz betrieben, kann dies
schnell zu einem Verlust der Verfgbarkeit des gesamten Netzes fhren,
wenn die Netzinfrastruktur in Folge konzeptioneller Schwchen nicht mehr
ausreichend skaliert werden kann (Verlust der Verfgbarkeit durch ber-
lastung). Abhngig von der gewhlten Segmentierung des Netzes kann der
Verlust der Verfgbarkeit auch nur einzelne Segment des Netzes betreffen.
Beispiel: In den heute noch hufig vorzufindenden, bedarfsorientiert
gewachsenen Netzen, sind aus historischen Grnden vielfach Backbone-
Segmente mit niedriger maximaler Bandbreite, wie z. B. Token-Ring- oder
Ethernet-Segmente, vorhanden. Durch diese Beschrnkung der Geschwin-
digkeit im Backbone-Bereich ist bei hoher zustzlicher Last die Verfgbar-
keit des gesamten Netzes betroffen.
- Netze, die ausschlielich zum Anschluss proprietrer Systeme geeignet
sind, knnen ebenfalls einen Verlust der Verfgbarkeit bedingen, wenn
hierfr ungeeignete Systeme an das Netz angeschaltet werden (Verlust der
Verfgbarkeit durch nicht interoperable Netzkomponenten).
Beispiel: Nicht systemneutrale Netze sind vorrangig im
Grorechnerumfeld zur Vernetzung der Grorechner mit den zugehrigen
Terminals anzutreffen. Hufig sind dies Netze, die fr den Terminal- oder
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Druckerbetrieb installiert wurden und nicht fr den Betrieb von anderen

Architekturen (z. B. Ethernet) geeignet sind. Dies betrifft sowohl die
eingesetzte Verkabelung als auch die aktiven Netzkomponenten. Wird
dennoch versucht, wird das proprietre Netz im allgemeinen nicht mehr
verfgbar sein. Eine Mglichkeit zur Integration zweier Architekturen
kann u. U. die Kopplung ber ein Gateway darstellen.
- Beim Einsatz von aktiven Netzkomponenten, die nicht fr den Einsatz
bestimmter Protokolle vorgesehen sind, knnen ggf. zustzlich
erforderliche Dienste oder Protokolle nicht verwendet werden.
Beispiel: In einem Netz, welches ausschlielich mit aktiven
Netzkomponenten aufgebaut ist, die nur IP-Routing oder IP-Switching
untersttzen, kann kein Novell Netware-Netzbetriebssystem auf der Basis
von SPX/IPX betrieben werden.
- Beim Einsatz von passiven Netzkomponenten, die eine Einschrnkung der
auf ihnen zu betreibenden Netzzugangsprotokollen mit sich bringen, kann
das Netz in Zukunft u. U. nicht mehr skaliert werden.
Beispiel: In einem Netz, welches ausschlielich mit 50 Ohm Koaxialkabel
aufgebaut ist, kann kein ATM benutzt werden. An Netzen, die mit 150
Ohm Twisted-Pair-Kabeln aufgebaut sind, knnen keine 100 Ohm
Ethernet-Komponenten betrieben werden. Die Folge der o. a., zum Teil
historisch bedingten konzeptionellen Schwchen, sind kostenintensive
Vernderungen der Netzinfrastruktur.
Netze knnen zwar anwendungs-, system- und dienstneutral ausgefhrt sein,
aber durch eine sehr heterogene Komponentenlandschaft einen
Betreuungsaufwand erfordern, der durch das Betriebspersonal nicht mehr
geleistet werden kann. Dies kann zu einem Verlust der Verfgbarkeit des
Netzes fhren, wenn Strungen oder Ausflle passiver oder aktiver
Netzkomponenten aufgrund mangelnder personeller Ressourcen nicht mehr
schnell genug beseitigt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.46 berschreiten der zulssigen Kabel- bzw.

Buslnge oder der Ringgre
Je nach Kabeltyp, Topologie und bertragungsverfahren sehen die
betreffenden Standards maximale Kabel- bzw. Buslngen sowie maximale
Ringgren vor, um die Funktionsfhigkeit des Netzes im Sinne dieses
Standards zu garantieren. berhhte Kabellngen wie auch berhhte Bus-
oder Ringlngen verlngern die Signallaufzeiten ber das fr das betreffende
bertragungsverfahren vorgesehene Ma hinaus, so dass die Verfgbarkeit
des jeweiligen Netzsegments oder die Kommunikationsbandbreite
herabgesetzt wird.
Die auftretenden Phnomene sind vom Zugriffsverfahren abhngig:
- Bei Netzsegmenten, auf denen das Zugriffsverfahren CSMA/CD (Carrier
Sense Multiple Access/Collision Detection) verwendet wird, greifen alle
Endgerte gleichberechtigt zu, obwohl das Medium jeweils nur exklusiv
durch ein Endgert genutzt werden kann. Hierzu prft jedes Endgert zu-
nchst, ob das Medium fr die Benutzung zur Verfgung steht (Carrier
Sense). Ist dies der Fall, beginnt das betreffende Endgert mit der bertra-
gung. Geschieht dies durch mehrere Endgerte gleichzeitig (Multiple
Access), kommt es zu einer Kollision, die von den sendenden Endgerten
erkannt wird (Collision Detection) und zu einer erneuten Prfung des Me-
diums mit anschlieender Wiederholung der bertragung fhrt.
Wird die maximal definierte Signallaufzeit auf dem Medium berschritten,
knnen Kollisionen ggf. im vorgesehenen Zeitintervall (Collision
Detection) nicht erkannt werden. Dies bedeutet, dass ein Endgert bereits
begonnen hat, Daten zu bertragen, whrend ein anderes Endgert das
bertragungsmedium noch als frei betrachtet. In diesem Fall kommt es zu
so genannten spten Kollisionen, die das betreffende Datenpaket
unbrauchbar machen und in Abhngigkeit der Lnge des Datenpakets das
Medium ber Gebhr blockieren. Die nutzbare bertragungsbandbreite auf
dem Medium kann dadurch stark eingeschrnkt werden. Einen Verlust von
Informationen tritt in der Regel, trotz des Verlustes von einzelnen
Datenpaketen, durch die Sicherung des Netzzugangsprotokolls nicht auf.
Beispielsweise verwenden Ethernet oder Fast Ethernet das CSMA/CD
bertragungsverfahren.
- bertragungsverfahren, die auf dem Token-Passing-Verfahren basieren,
verwenden ein spezielles Datenpaket (das so genannte Token), um
festzulegen, welches Endgert das Medium belegen darf. Erhlt ein
Endgert das Token, belegt es das Medium und gibt das Token in
Abhngigkeit des implementierten Token-Passing-Verfahrens an das
nchste Endgert weiter. Hiermit ist gewhrleistet, dass das Medium
immer nur durch ein einziges Endgert belegt wird.
Wesentlich fr Netzsegmente, auf denen ein Token-Passing-Verfahren
betrieben wird, ist eine synchrone Datenbertragung mit konstanter Bitrate.
Ist das Medium belegt, werden die betreffenden Zeitintervalle fr die
unterschiedlichen Bits fr die bertragung der Datenpakete genutzt, ist das
Medium frei, werden die Zeitintervalle fr die Weitergabe des Tokens
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
genutzt. Bei einer berschreitung der maximal vorgesehenen

Signallaufzeit kann die fr das betreffende bertragungsverfahren
vorgesehene konstante Bitrate nicht mehr eingehalten werden, so dass die
Kommunikation zum Erliegen kommt. Beispielsweise basieren Token Ring
oder FDDI auf dem Token-Passing-Verfahren.
Neben einer Verlngerung der Signallaufzeit erhhen lngere Kabel die
Dmpfung. Bei berschreitung der Kabellngen im Hinblick auf den
betreffenden Standard kann die Dmpfung des Kabels so gro werden, dass
die verschiedenen Signalpegel nicht mehr wie im Standard festgelegt
voneinander unterschieden werden knnen. Die Kommunikation ber die
betreffenden Adern oder Glasfasern kann in diesem Fall nicht ber die
gesamte Lnge sichergestellt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.47 Ungesicherter Akten- und Datentrgertransport

Werden Dokumente, Datentrger oder Akten zwischen der Institution und
anderen Stellen, zum Beispiel dem huslichen Arbeitsplatz, transportiert,
besteht die Gefahr, dass sie
- auf dem Transportweg verloren gehen,
- auf dem Transportweg entwendet werden,
- auf dem Transportweg gelesen oder manipuliert werden und
- an einen falschen Empfnger bergeben werden.
Insbesondere wenn es sich um Unikate handelt, knnen Zerstrung, Vertrau-
lichkeitsverlust oder Manipulation grere Schden verursachen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.48 Ungeeignete Entsorgung der Datentrger und

Dokumente am huslichen Arbeitsplatz
Sind am huslichen Arbeitsplatz keine geeigneten Mglichkeiten vorhanden,
um Datentrger und Dokumente geeignet zu entsorgen, knnen bei
unsachgemer Entsorgung Informationen oder Restinformationen auf den
Datentrgern von Dritten ausgelesen oder aus den Dokumenten extrahiert
werden. Der entstehende Schaden richtet sich nach dem Wert der
Informationen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.49 Fehlende oder unzureichende Schulung der

Telearbeiter
Telearbeiter sind am huslichen Arbeitsplatz weitestgehend auf sich allein
gestellt. Das bedeutet, dass sie sich besser mit der eingesetzten IT auskennen
mssen als ihre Kollegen in der Institution, die meist kurzfristig auf IT-
Systemspezialisten vor Ort zurckgreifen knnen. Ist der Telearbeiter nicht
ausreichend im Umgang mit der IT geschult, kann dies bei Problemen zu
erhhten Ausfallzeiten fhren, da ggf. ein IT-Betreuer aus der Institution zum
huslichen Arbeitsplatz des Telearbeiters fahren muss, um dort die Probleme
zu beseitigen.
Beispiel:
Der Telearbeiter sollte in der Lage sein, selbststndig Sicherungskopien seiner
Daten herzustellen. Wird dem Telearbeiter ein zustzliches Speichermedium
(z. B. Bandlaufwerk) zur Verfgung gestellt, so muss er in den Gebrauch
eines solchen eingewiesen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.50 Verzgerungen durch temporr eingeschrnkte

Erreichbarkeit der Telearbeiter
blicherweise hat ein Telearbeiter keine festen Arbeitszeiten am huslichen
Arbeitsplatz. Lediglich feste Zeiten der Erreichbarkeit werden vereinbart. Bei
alternierender Telearbeit sind seine Arbeitszeiten zwischen huslichem
Arbeitsplatz und dem innerbetrieblichen Arbeitsplatz verteilt. Ergibt sich
kurzfristig das Problem, dass Informationen vom Telearbeiter eingeholt oder
Informationen an den Telearbeiter bergeben werden mssen, kann es auf-
grund der schwierigen Erreichbarkeit zu Verzgerungen kommen. Selbst eine
bermittlung der Informationen ber E-Mail verkrzt nicht notwendigerweise
die Reaktionszeit, da nicht sichergestellt werden kann, dass der Telearbeiter
die E-Mail zeitnah liest.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.51 Mangelhafte Einbindung des Telearbeiters in

den Informationsfluss
Da Telearbeiter nicht tglich in der Institution sind, sondern berwiegend zu
Hause arbeiten, haben sie weniger Gelegenheit, am direkten Informationsaus-
tausch mit Vorgesetzten und Arbeitskollegen teilzuhaben. Es besteht die
Gefahr, dass sie vom betrieblichen Geschehen abgeschnitten werden und sich
dadurch auch die Identifizierung mit der Institution verringert.
Darber hinaus ist nicht auszuschlieen, dass durch einen mangelhaften
Informationsfluss fr IT-Sicherheit notwendige Informationen nicht
ausreichend oder nicht rechtzeitig den Telearbeiter erreichen. Beispielsweise
kann die kurzfristige Weitergabe von Computer-Viren-Meldungen erschwert
sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.52 Erhhte Reaktionszeiten bei IT-Systemausfall

Findet beim Telearbeiter zu Hause ein IT-Systemausfall statt, den er nicht
selbstndig beheben kann oder darf, so muss entweder ein IT-Systemverant-
wortlicher zu ihm nach Hause kommen oder das IT-System muss zu seiner
Institution gebracht werden, damit es dort repariert werden kann. Dies nimmt
einige Zeit in Anspruch, so dass der Telearbeiter mit erhhten Ausfallzeiten
rechnen muss. Gleiche Probleme entstehen bei Wartungsarbeiten oder bei der
Neuinstallation von Komponenten oder Software.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.53 Unzureichende Vertretungsregelungen fr

Telearbeit
Die Aufgaben des Telearbeiters sind in der Regel so konzipiert, dass er
weitestgehend selbstndig arbeiten kann. Dies birgt die Gefahr in sich, dass es
im Krankheitsfall schwierig ist, eine entsprechende Vertretung fr den
Telearbeiter bereitzustellen. Insbesondere kann es zu Problemen fhren, die
erforderlichen Unterlagen oder die Daten aus dem Telearbeitsrechner fr den
Vertreter bereitzustellen, wenn keine Zutrittsmglichkeiten zum huslichen
Arbeitsplatz des Telearbeiters bestehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.54 Vertraulichkeitsverlust durch Restinformationen

Bei elektronischer Datenbermittlung oder Datentrgerweitergabe passiert es
immer wieder, dass dabei auch Informationen weitergegeben werden, die die
Institution nicht verlassen sollten. Als mgliche Ursachen fr die unbeabsich-
tigte Weitergabe von Informationen lassen sich folgende Beispiele anfhren:
- Eine Datei enthlt Textpassagen, die als "versteckt" oder "verborgen" for-
matiert sind. Solche Textpassagen knnen Bemerkungen enthalten, die
nicht fr den Empfnger bestimmt sind.
- Dateien, die mit Standardsoftware wie Textverarbeitungsprogrammen oder
Tabellenkalkulationen erstellt worden sind, knnen Zusatzinformationen
ber Verzeichnisstrukturen, Versionsstnde, Bearbeiter, Kommentare,
Bearbeitungszeit, letztes Druckdatum, Dokumentnamen und -beschrei-
bungen enthalten. Besonders hervorzuheben ist in diesem Zusammenhang
Funktionen, die mehreren Bearbeitern das gemeinsame Bearbeiten eines
Dokuments erlauben. Solche Funktionen lschen Textpassagen, die ein
Bearbeiter lscht oder berschreibt, nicht wirklich aus dem Dokument,
sondern markieren diese nur als gelscht und erlauben es spteren
Bearbeitern, nderungen ganz oder teilweise rckgngig zu machen.
Praktisch alle aktuellen Office-Suites (Microsoft Office, StarOffice,
OpenOffice) bieten diese Mglichkeit. Werden die Daten solcher
nderungen nicht vor der Weitergabe entfernt, so erhlt der Empfnger
neben dem tatschlichen Dokument unter Umstnden eine groe Menge
weiterer Informationen.
- Praktisch alle aktuellen Office-Suites besitzen die Mglichkeit der Schnell-
speicherung von erstellten Dokumenten. Dies fhrt dazu, dass nur die
nderungen an einem Dokument gespeichert werden. Dieser Vorgang
nimmt vergleichsweise weniger Zeit in Anspruch als ein vollstndiger
Speichervorgang, bei dem Winword das vollstndige berarbeitete
Dokument speichert. Ein vollstndiger Speichervorgang erfordert jedoch
weniger Festplattenspeicher als eine Schnellspeicherung. Der
entscheidende Nachteil ist jedoch, dass bei einer Schnellspeicherung
dieDatei unter Umstnden Textfragmente enthalten kann, die der Verfasser
nicht weitergeben mchte.
- Eine weitere Mglichkeit, wie Informationen weitergegeben werden
knnen, die nicht fr Externe bestimmt sind, stellen Funktionen dar, die es
beispielsweise erlauben, in ein Textdokument oder eine Prsentation eine
Tabelle aus einem Tabellenkalkulationsdokument so einzubetten, dass die
Tabelle direkt im Textdokument bearbeitet werden kann. Wird ein solches
Textdokument weitergegeben, so knnen unter Umstnden sehr viel mehr
Informationen aus dem Tabellenkalkulationsdokument bertragen werden,
als im Textdokument sichtbar ist.
- Wird eine Datei auf eine Diskette kopiert, so wird der erforderliche
physikalische Speicherbereich (Block) vollstndig aufgefllt. Bentigt das
Original einen Block nicht vollstndig, so wird dieser (nach dem End-Of-
File Kennzeichen) mit beliebigen "Restinformationen" des IT-Systems
aufgefllt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Auf z/OS-Systemen werden gelschte Member nicht sofort in der z/OS-Systeme

Bibliothek (PDS - Partitioned Dataset) berschrieben. Lediglich der
Eintrag des Members im Verzeichnis (Directory) des PDS wird
gelscht. Erst wenn im PDS freier Speicherplatz bentigt wird,
werden die Informationen des alten Members berschrieben. Noch
nicht berschriebene Daten lassen sich mit Hilfsprogrammen
auslesen.
- Werden in z/OS-Systemen Dateien auf einer Festplatte gelscht, so
wird die Datei im Volume Table of Content (VTOC) als gelscht
gekennzeichnet, die Datei selbst auf der Festplatte jedoch nicht
gelscht. Die Datei wird erst berschrieben, wenn neue Daten auf
der Festplatte gespeichert werden sollen und kein freier Platz
verfgbar ist. Gelingt es, die Speicherstelle der Datei aus dem
VTOC auszulesen, so ist es mglich, die Datei mit speziellen
Programmen zu editieren und wieder herzustellen. Dies gilt ebenso
fr Bnder, die zwar als Leer-Bnder gekennzeichnet, aber noch
nicht berschrieben sind.
Restinformationen auf Datentrgern
Bei den meisten Dateisystemen werden Dateien, die vom Benutzer ber einen
Lschbefehl gelscht werden, nicht wirklich in dem Sinn gelscht, dass die
Information anschlieend nicht mehr vorhanden ist. Normalerweise werden
lediglich die Verweise auf die Datei aus den Verwaltungsinformationen des
Dateisystems (etwa aus der Dateizuordnungstabelle (File Allocation Table)
beim FAT-Dateisystem) gelscht und die zu der Datei gehrenden Blcke als
"frei" markiert. Der tatschliche Inhalt der Blcke auf dem Datentrger bleibt
jedoch erhalten und kann mit entsprechenden Werkzeugen rekonstruiert
werden.
Wenn Datentrger an Dritte weitergegeben werden, beispielsweise
- wenn ein Rechner ausinventarisiert wurde und verkauft wird,
- wenn ein defektes Gert zur Reparatur gegeben oder im Rahmen der
Garantie ausgetauscht wird oder
- wenn ein Datentrger im Rahmen des Datentrgeraustauschs an einen
Geschftspartner weitergegeben wird
knnen auf diese Weise sensitive Informationen nach drauen gelangen.
Beispiele:
- Die Forscher Simson Garfinkel und Abhi Shelat vom MIT kauften
zwischen 2000 und 2002 bei verschiedenen Hndlern ber das Online-
Auktionshaus eBay eine grere Anzahl gebrauchter Festplatten und
untersuchten diese auf enthaltene Restinformationen. Sie fanden eine
erschreckende Menge an Daten, beispielsweise
- interne Vermerke von Unternehmen, bei denen es um
Personalsachen ging,
- eine groe Anzahl von Kreditkartennummern
- medizinische Informationen
- E-Mails
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
und vieles mehr. Ihre Ergebnisse verffentlichten sie in einem Journal der
IEEE.
- Ein Benutzer entdeckte durch Benutzung eines anderen Editors per Zufall,
dass die kurz vor der Versendung stehende Datei diverse URLs enthielt,
inklusive Benutzername und Passwort fr einen WWW-Server. Mit URL
(Uniform Resource Locator) wird die Adresse eines WWW-Dokuments
bezeichnet. Der Zugriff auf die WWW-Seite kann passwortgeschtzt sein.
- Eine Behrde hatte mit dem Programm Microsoft Powerpoint erstellte
Prsentationen in Dateiform an Externe weitergegeben. Spter stellte sich
heraus, dass neben den Prsentationen auch Informationen ber die Rech-
nerumgebung des Benutzers mitgeliefert worden waren, wie etwa darber,
welche Newsgruppen ein Benutzer abonniert hat und welche News er
schon gelesen hat. Die Powerpoint-Datei enthielt u. a. folgende Eintrge:
de.alt.drogen! s21718 0
de.alt.dummschwatz! s125 0
- Zwei Verkufer konkurrierender Firmen tauschten ihre Prsentationen aus,
die sie bei einer Veranstaltung gehalten hatten. Eines der Powerpoint-Do-
kumente enthielt eine kleine Tabelle mit Endkunden-Preisen fr die Pro-
dukte der einen Firma. Beim ffnen der Prsentation entdeckte der Emp-
fnger, dass diese kleine Tabelle Teil eines sehr umfangreichen Tabellen-
kalkulationsdokuments war, das in die Prsentation eingebettet worden
war, und das die gesamte Preiskalkulation des Konkurrenzunternehmens
enthielt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.55 Ungeordnete E-Mail-Nutzung

Bei ungeordneter Nutzung von E-Mails besteht die Gefahr, dass sensitive
Daten Unbefugten zur Kenntnis gelangen oder das gewnschte Ziel nicht
rechtzeitig erreichen.
Beispiele:
- Eine fehlerhafte Adressierung kann dazu fhren, dass die E-Mail an einen
unautorisierten Empfnger bersandt wird.
Werden Verteilerlisten nicht gepflegt, knnen E-Mails Empfngern zuge-
stellt werden, die von der Versendung htten ausgeschlossen sein mssen.
- Eine falsche Versandmethode kann zu bertragungs- oder Empfangspro-
blemen fhren. Wenn beispielsweise die Datei nicht mit uuencode in eine
7-Bit ASCII-Darstellung umgewandelt wurde, kann sie nach dem Empfang
fehlerhaft konvertiert und damit nicht lesbar sein. Wenn die Datenmenge
zu gro ist, kann eines der an der bertragung beteiligten IT-Systeme die
Weitergabe verweigern.
- Fehlende oder mangelhafte organisatorische Regelungen beim Empfnger
knnen zur Folge haben, dass eine empfangene E-Mail erst versptet
bearbeitet wird.
- Fehlende oder mangelhafte organisatorische Regelungen beim Absender
knnen zur Folge haben, dass ein terminlich zugesichertes Absenden der
Daten nicht eingehalten werden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.56 Mangelhafte Beschreibung von Dateien

Werden beim elektronischen Dateiaustausch die bertragenen Dateien nicht
gut genug beschrieben, so ist fr den Empfnger oft nicht nachvollziehbar,
wer diese bersandt hat, welche Informationen sie enthalten oder welchem
Zweck sie dienen.
Wenn mehrere E-Mails ein- und desselben Absenders eingehen, kann bei
fehlender oder schlechter Kennzeichnung die Reihenfolge verwechselt
werden.
Beispiel:
Absender A verschickt an die Empfngerin E eine E-Mail mit mehreren Datei-
en. Am nchsten Tag stellt A fest, dass eine Datei noch Fehler enthielt und
verschickt eine korrigierte Version mit der Bitte, die vorhergehende E-Mail zu
lschen. Nachdem E die alte E-Mail gelscht hat, stellt sie fest, dass die
aktuelle E-Mail nur die korrigierte Datei enthlt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.57 Nicht ausreichende Speichermedien fr den

Notfall
Wenn Daten nach ihrer Zerstrung wiederhergestellt werden mssen, ist es
vielen Fllen notwendig, die gesicherten Daten zunchst auf getrennten Spei-
chermedien wiedereinzuspielen. Dies ist insbesondere bei komplexeren Daten-
strukturen wie z. B. bei Datenbanken notwendig, da die Wiederherstellung
nicht immer reibungslos und fehlerfrei funktioniert. Wird die hierfr bentigte
Speicherkapazitt nicht fr den Notfall vorgehalten, kann es durch bereiltes
Handeln whrend des Notfalls zu weiteren Datenverlusten kommen.
Beispiel:
In einem Unternehmen mit einer groer Datenbank-Applikation wurde die
Datenbank als inkonsistent vom Datenbankmanagementsystem (DBMS)
gemeldet. Daraufhin nahm das Systemmanagement die Datenbank auer
Betrieb und restaurierte den letzten gesicherten Datenbestand im
Produktionssystem. Von der scheinbar korrupten Datenbank wurden nur Log-
und Konfigurationsdateien vorher gesichert. Durch diese Aktion gingen alle
Datennderungen seit der letzten Sicherung verloren, da aufgrund eines bis
dahin unbekannten Fehlers im DBMS das Nachfahren der nderungen nicht
mglich war. Die Analyse der Log- und Konfigurationsdateien ergab dann,
dass die Datenbank in Wirklichkeit gar nicht inkonsistent gewesen war. Htte
ausreichend Plattenplatz zur Verfgung gestanden, um die Rekonstruktion
parallel durchzufhren, wre das alte produktive System ohne Datenverlust
nach Erkennung und Behebung der nur scheinbaren Inkonsistenz wieder
einsatzbereit gewesen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.58 Novell Netware und die Datumsumstellung im

Jahr 2000
Datumsangaben werden unter Novell Netware derzeit zweistellig gespeichert
und zur optischen Darstellung der Zahl 19.. angehngt.
Dies bedeutet, dass mit dem Datumswechsel 1999/2000 die
Zahlenkombination von 00 dazu fhrt, dass ein laufender Netware-Server das
neue Datum als das Jahr 1900 interpretiert. Im Falle eines Neustarts des
Servers wird sich dessen Datum, nach Angaben von Novell, dann auf das Jahr
1980 umschalten.
Diese Umstellung wird dadurch hervorgerufen, dass bei einem Neustart der
Wert (19)00 als ungltiges Datum interpretiert wird und daher stattdessen der
Standardwert (19)80 ("Geburtsstunde des IBM-PCs") als gltiges Datum
gewhlt wird.
Zwar werden durch dieses Verhalten die gespeicherten Daten nicht zerstrt,
jedoch werden Fehler in allen zeitgesteuerten Programmen, bei Benutzer-
Accounts mit zeitlichem Ablaufdatum, sowie den zeitgesteuerten Prozessen,
wie z. B. Datensicherungen auftreten, die dann u. U. zu Datenverlusten fhren
knnen. Vor allem wrden erhebliche Probleme in der NDS auftreten, wenn
das Datum pltzlich zurckgestellt werden wrde. Wichtig ist aber auch, dass
auch das BIOS fr den Rechner Jahr-2000-fhig ist und ein automatischer
bergang vom 31.12.1999 auf den 1.1.2000 erfolgen kann.
Von diesen Fehlern sind derzeit (Berichtsstand: Juni 1999) die Versionen
NW 2.x, NW 3.x vor Version 3.2, NW 4.x von Novell Netware betroffen.
Weitere Information zum Verhalten von Novell Produkten bei der
Datumsumstellung zum Jahr 2000 sind im Internet u. a. unter den URLs
http://www.novell.de/jahr2000/ und http://www.novell.com/year2000/
erhltlich. Hier sind auch Programme zu finden, um die im Einsatz befindliche
Netware Software auf Jahr-2000-Fhigkeit zu prfen. Ebenso wird eine
bersicht gegeben, welche Programme von Novell auf ihre Jahr-2000-
Fhigkeit getestet sind und mit welchem Ergebnis diese bestanden haben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.59 Betreiben von nicht angemeldeten

Komponenten
In der Regel sollten alle Komponenten eines Netzes der Systemadministration
bekannt sein. Es muss auf organisatorischer Ebene gewhrleistet sein, dass
neue Komponenten bei der Systemadministration angemeldet und frei-
gegebenen werden, z. B. durch eine automatische Meldung der Beschaffungs-
stelle oder einen entsprechenden Antrag der die Komponenten betreibenden
Organisationseinheit.
Nicht angemeldete Komponenten stellen ein Sicherheitsrisiko dar, da sie nicht
in organisatorische innerbetriebliche Ablufe und Kontrollen eingebunden
sind. Dies kann einerseits zu Gefahren fr die Benutzer der nicht
angemeldeten Komponenten fhren (z. B. Datenverlust, da das System nicht
in die Datensicherung eingebunden ist), aber auch zur Gefhrdung anderer
Netzkomponenten, z. B. knnen durch nicht erfasste Zugangspunkte zum Netz
Schwachstellen entstehen, wenn diese schlecht oder gar nicht gegen
unbefugten Zugriff abgesichert sind. Da eine solche Komponente nicht der
Kontrolle des Netzmanagements und/oder des Systemmanagements unterliegt,
knnen insbesondere Fehlkonfigurationen des lokalen Systems zu einem
Sicherheitsloch fhren.
Beispiel:
Der Administrator wartet ber das Systemmanagementsystem die Passwrter
(Community Names) fr das verwendete Netzmanagementsystem, welches
auf SNMP basiert. Eine Arbeitsgruppe beschliet den Kauf eines neuen Netz-
PCs, vergisst diesen jedoch der zentralen Administration zu melden. Die
Installationseinstellung fr das Passwort (Community Name) des lokalen
SNMP-Dmons lautet "public". Dieses Passwort ist wohl bekannt. Angreifer
knnen nun einen SNMP-basierten Angriff starten, da sie vollen Zugriff auf
die SNMP-Daten besitzen. Der so kompromittierte PC kann als
Ausgangspunkt fr weitere Angriffe auf das interne Netz dienen. So knnten
dort z. B. Passwort-Sniffer installiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.60 Fehlende oder unzureichende Strategie fr das

Netz- und Systemmanagement
Werden fr die Bereiche Netzmanagement und/oder Systemmanagement
keine organisationsbergreifenden Managementstrategien festgelegt, kann es
insbesondere in mittleren und groen Netzen mit mehreren Management-
domnen durch Fehlkoordination der einzelnen Subdomnen zu schwerwie-
genden Problemen durch Fehlkonfiguration kommen, die bis hin zu vlligem
Systemzusammenbruch auf Netzebene fhren knnen.
Aus diesem Grund ist die Festlegung und Durchsetzung einer Management-
strategie zwingend erforderlich. Im folgenden werden einige Beispiele fr
Probleme durch eine fehlende oder unzureichende Strategie fr das Netz- und
Systemmanagement gegeben.
Fehlende Bedarfsanalyse vor Festlegung der Managementstrategie
Um eine Netz- und/oder Systemmanagementstrategie festlegen zu knnen, ist
eine vorangehende Bedarfsanalyse durchzufhren. Ohne die Feststellung des
Managementbedarfs (etwa: Welche verwaltbaren Netzkoppelelemente
existieren? Wie dynamisch ist der zu verwaltende Softwarebestand?) knnen
Anforderungen an die Managementstrategie nicht formuliert werden. Da die
Managementstrategie zudem Einfluss auf das zu beschaffende Software-
produkt hat, kann dies zu Fehlentscheidungen fhren.
Wird dann z. B. ein Managementprodukt eingefhrt, das einen zu geringen
Funktionsumfang besitzt, so kann diese Funktionslcke zustzlich zu einem
Sicherheitsproblem werden, da die ntige Funktion "von Hand" bereitgestellt
werden muss. In greren Systemen kann dies dann leicht zu Fehlkonfigu-
rationen fhren.
Beschaffung von nicht managebaren Komponenten
Wird ein Rechnerverbund mit Hilfe eines Netz- und/oder eines
Systemmanagementsystems verwaltet, so ist bei der Beschaffung neuer
Komponenten darauf zu achten, dass sie in das jeweilige Managementsystem
integrierbar sind, damit sie in das Management einbezogen werden knnen. Ist
dies nicht der Fall, so fllt mindestens zustzlicher Verwaltungsaufwand an,
da auch auf den nicht mit dem Managementsystem verwalteten Komponenten
die festgelegte Managementstrategie durchgesetzt werden muss. Da jedoch
diese Komponenten insbesondere nicht in die automatisierten Verwal-
tungsablufe des Managementsystems integriert sind, kann es hier zu Fehlkon-
figurationen kommen. Dies birgt durch nicht abgestimmte Konfigurationen
ein Sicherheitsrisiko.
Nicht koordiniertes Managen von benachbarten Bereichen
(Communities, Domnen)
Existieren in einem durch ein Managementsystem verwalteten Rechnernetz
mehrere Verwaltungsbereiche, die jeweils von einem eigenen Systemmanager
betreut werden, so sind deren Kompetenzen durch die Managementstrategie
eindeutig festzulegen. Ist dies nicht der Fall, kann es durch unkoordiniertes
Management einzelner Komponenten zu Sicherheitsproblemen kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Werden z. B. einerseits einzelne Komponenten wie Netzkoppelelemente

flschlicherweise von zwei Verwaltungsbereichen verwaltet (dies kann etwa
geschehen, wenn keine unterschiedlichen SNMP-"Passwrter" (Community
Strings) verwendet werden), so fhrt das unkoordinierte Einstellen von Konfi-
gurationsparametern unter Umstnden zu Sicherheitslcken.
Werden andererseits Komponenten (etwa Drucker) gemeinsam von zwei Ver-
waltungsbereichen genutzt und wurde z. B. die Vertrauensstellung des jeweils
anderen Verwaltungsbereiches (z. B. Windows NT Netzwerkfreigaben) nicht
korrekt eingerichtet, so kann dies unbeabsichtigt zu Sicherheitsproblemen
fhren, wenn nun auch unberechtigten Dritten der Zugriff gestattet wird.
Nicht integrierte Verwaltungssoftware
Beim Verwalten von mittleren und groen Systemen kann es vorkommen,
dass nach Einfhrung des Managementsystems neue Komponenten in das
System integriert werden sollen, deren Verwaltung Funktionen erfordern, die
das eingesetzte Managementsystem nicht untersttzt. Dies gilt insbesondere
fr den Bereich Applikationsmanagement. Wird zur Verwaltung der neuen
Komponente nun eine Verwaltungssoftware eingesetzt, die nicht in das einge-
setzte Managementsystem integriert werden kann (z. B. ber eine Program-
mierschnittstelle, oder durch den Einsatz von so genannten Gateways), so ist
ein koordiniertes Einbinden in das Managementsystem nicht mglich.
Dadurch unterliegt die neue Komponente jedoch nicht dem "automatisierten"
Management, was ein Verwalten "von Hand" ntig macht. Die festgelegte
Managementstrategie muss nun fr zwei Systeme umgesetzt werden, dies
kann jedoch zu Fehlkonfigurationen fhren, die Sicherheitslcken bedingen
knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.61 Unberechtigte Sammlung personenbezogener

Daten
Beim Einsatz von Managementsystemen fallen im Rahmen des normalen
Ablaufes auch viele Protokolldaten an, die in der Regel automatisch erzeugt
und ausgewertet werden. Dies trifft im besonderen Mae auf die Bereiche der
Netz- und Systemberwachung zu. Ohne ausfhrliche Protokollierung der
Systemaktivitten ist es z. B. auch nicht mglich, Sicherheitsverletzungen
aufzudecken. Eine Anforderung im Rahmen der berwachung ist jedoch auch
die eindeutige Zuordnung bestimmter Zugriffe zu Benutzern. Damit mssen
die berwachten Benutzeraktivitten aber personenbezogen protokolliert
werden. In der Regel wird durch die Managementstrategie organisationsber-
greifend und im Einvernehmen mit dem Datenschutzbeauftragten festgelegt,
welche Benutzeraktivitten aus Sicherheitsgrnden berwacht werden sollen.
Hierber sind die betroffenen Benutzer entsprechend zu informieren. Die
Einhaltung der durch die Managementstrategie festgelegten Vorgaben ist
jedoch im Rahmen der Systemrevision zu berprfen. Es ist zudem mglich,
dass das Managementsystem im Rahmen einer regulren Funktion temporre
Protokolldateien erstellt, die z. B. im wenig geschtzten Bereich fr temporre
Dateien abgelegt werden. Die Protokolldateien sind dann potentiell zumindest
fr die Zeit ihrer Existenz zugreifbar und knnen zudem Benutzerinfor-
mationen enthalten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.62 Ungeeigneter Umgang mit Sicherheitsvorfllen

Sicherheitsvorflle mit dem Potential groer Schden werden in der Praxis nie
ausgeschlossen werden knnen. Die gilt auch dann, wenn eine Reihe von
Sicherheitsmanahmen umgesetzt sind. Wird auf akute Sicherheitsvorflle
nicht angemessen reagiert, so knnen sich daraus unter Umstnden groe
Schden bis hin zu Katastrophen entwickeln.
Beispiele dafr sind:
- Es treten zunchst sporadisch, dann massenhaft neue Computer-Viren mit Arbeitsausflle
Schadfunktionen auf. Erfolgt keine rechtzeitige Reaktion, knnen unter
Umstnden ganze Organisationseinheiten arbeitsunfhig werden. Konkret
ist dies bei Auftreten des Computer-Virus "Melissa" beobachtet worden.
- Auf einem Webserver finden sich unerklrlich vernderte Inhalte. Wird Imageverlust
dies nicht als Hinweis auf mgliche Hacker-Attacken weiterverfolgt,
knnen weitere Angriffe auf den Server u. U. auch zu groem Imageverlust
fhren.
- In der Protokollierung einer Firewall finden sich Ungereimtheiten. Wird
dies nicht als Hacking-Versuch untersucht, knnen ggf. tatschlich externe
Angreifer die Firewall berwinden.
- Es werden Sicherheitslcken in den verwendeten IT-Systemen bekannt.
Werden diese Informationen nicht rechtzeitig beschafft und notwendige
Gegenmanahmen nicht zgig umgesetzt, so besteht die Gefahr, dass die
Sicherheitslcken von Innen- oder Auenttern missbraucht werden.
- Es ergeben sich Hinweise auf manipulierte Unternehmensdaten. Wird dies Folgeschden
nicht zum Anlass genommen, den Manipulationen nachzugehen, so knnen
auch unerkannte Manipulationen schwere Folgeschden nach sich ziehen,
wie zum Beispiel fehlerhafte Lagerbestnde, falsche Buchhaltung oder
unkontrolliert abgeflossene Finanzmittel.
- Wird Hinweisen auf Kompromittierung von vertraulichen Unternehmens-
daten nicht nachgegangen, knnen weitere vertrauliche Daten abflieen.
Diese Beispiele verdeutlichen, dass bei Sicherheitsvorfllen eine schnelle
Benachrichtigung zustndiger Stellen, eine zgige Reaktion und eine Unter-
richtung der potentiell Betroffenen zur Schadensminimierung oder -prvention
notwendig ist.
Wenn fr die Behandlung von Sicherheitsvorfllen keine geeignete Vor- Fehlentscheidungen
gehensweise definiert ist, knnen auerdem falsche Entscheidungen getroffen
werden, die z. B. dazu fhren
- dass Pressevertreter falsche Ausknfte erhalten,
- dass die betroffenen Systeme bzw. Komponenten trotz schwerer Sicher-
heitslcken nicht abgeschaltet werden,
- dass Systeme bzw. einzelne Komponenten bei relativ unbedeutenden
Sicherheitslcken vllig abgeschaltet werden,
- dass keinerlei Ausweichmanahmen vorgesehen sind, wie z. B. der Aus-
tausch kompromittierter Komponenten, kryptographischer Verfahren oder
Schlssel.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.63 Ungeordnete Faxnutzung

Bei ungeordneter Nutzung von Faxgerten oder Faxservern besteht die
Gefahr, dass sensitive Daten Unbefugten zur Kenntnis gelangen oder das
gewnschte Ziel nicht rechtzeitig erreichen.
Beispiele:
- Eine fehlerhafte Adressierung kann dazu fhren, dass ein Fax an einen falsche Adressierung
unautorisierten Empfnger bersandt wird.
Werden Adressbcher und Verteillisten nicht gepflegt, knnen Faxe
Empfngern zugestellt werden, die von der Versendung htten ausge-
schlossen sein mssen.
- Eine fehlerhafte Administration eines Faxservers kann dazu fhren, dass
eingehende Faxe an Mitarbeiter zugestellt werden, die von dem Inhalt
keine Kenntnis erlangen sollen.
- Fehlende oder mangelhafte organisatorische Regelungen beim Empfnger unzuverlssige
Bearbeitung
knnen zur Folge haben, dass ein empfangenes Fax erst versptet bearbei-
tet wird.
- Fehlende oder mangelhafte organisatorische Regelungen beim Absender
knnen zur Folge haben, dass ein terminlich zugesichertes Absenden einer
Nachricht per Fax nicht eingehalten werden kann.
- Fehlende Sensibilisierung der Benutzer bei der Verwendung von
Faxservern kann dazu fhren, dass versehentlich ein Entwurf versandt
wird, der so die Organisation nicht verlassen sollte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.64 Fehlende Regelungen fr das RAS-System

Fehlende Regelungen fr das RAS-System stellen eine erhebliche Gefhrdung
des Gesamtsystems dar. Da sich ein RAS-System aus verschiedenen
Komponenten zusammensetzt, ergeben sich zunchst die jeweiligen Gefhr-
dungen aus dem Bereich "organisatorische Mngel" der Einzelkomponenten,
wie sie den jeweiligen Bausteinbeschreibungen zu entnehmen sind.
Im RAS-Umfeld sind folgende Gefhrdungen besonders hervorzuheben:
- Ein RAS-System sollte nicht "organisch wachsen". Vielmehr sollte vor der Fehlende oder
mangelhafte Planung
Nutzung eines RAS-Zuganges - gleichgltig, wie komplex der Zugang des RAS-Systems
gestaltet ist - eine Planung erfolgen. Die Erfahrung zeigt, dass insbesondere
beim stetigen Ausbau von RAS-Zugngen komplexe Hard- und Software-
Szenarien entstehen knnen, die dann nicht mehr beherrscht werden
knnen. Dies kann dazu fhren, dass Sicherheitseinstellungen falsch
gewhlt werden, inkompatibel zueinander sind oder sich gegenseitig
aufheben.
- Ohne durchgngiges und verbindliches Sicherheitskonzept bleibt es in der Fehlendes RAS-
Sicherheitskonzept
Regel einzelnen Administratoren und RAS-Benutzern berlassen, die
Sicherheitseinstellungen nach "Gutdnken" vorzunehmen. Dies kann zu
inkompatiblen Sicherheitseinstellungen fhren, die entweder die Verbin-
dungsaufnahme verhindern oder den Aufbau ungesicherter Verbindungen
ermglichen. Da mittels RAS angebundene IT-Systeme jedoch in vielen
Fllen die gleichen Zugriffsmglichkeiten wie direkt im LAN befindliche
IT-Systeme haben, wird dadurch u. U. die Sicherheit des LANs beein-
trchtigt.
- Die Sicherheit eines RAS-Systems basiert auf dem Zusammenspiel der Von den Vorgaben
abweichende Installation
physikalischen Komponenten (Rechner, Netzkoppelelemente), deren
Verbindungsstruktur (Netzaufteilung, Verbindungstopologie) und den
Konfigurationen der jeweiligen Software-Komponenten. Die im Rahmen
des RAS-Sicherheitskonzeptes festgelegten Regelungen und deren
Umsetzung durch entsprechende Konfigurationseinstellungen knnen die
gewnschte Sicherheit jedoch nur dann erbringen, wenn das tatschlich
installierte System mit dem geplanten System bereinstimmt. Oft ergeben
sich jedoch, z. B. aufgrund von fehlenden Detailinformationen whrend der
Planungsphase, in der Installationsphase nderungen im physikalischen
Aufbau. Werden die nderungen nicht erfasst, dokumentiert und auf
Auswirkungen auf die IT-Sicherheit analysiert, so kann die Sicherheit des
LANs durch Inkompatibilitten von Systemaufbau und Konfiguration des
RAS-Systems gefhrdet sein.
- Fehlende Regelungen fr die RAS-Nutzung stellen eine besondere Fehlende Regelungen fr
die RAS-Nutzung
Gefhrdung dar. Der RAS-Benutzer ist whrend der Nutzung in der Regel
auf sich alleine gestellt. Existieren fr den RAS-Einsatz keine dedizierten
Regeln oder sind diese den Benutzern nicht bekannt, so knnen durch den
Benutzer unbewusst Sicherheitslcken geschaffen werden. Regelungen,
deren Einhaltung alleine der Verantwortung des einzelnen Benutzers
unterliegen, werden von diesen nicht immer vollstndig eingehalten,
beispielsweise aufgrund fehlendem technischen Verstndnis.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Durch fehlende Beachtung datenschutzrechtlicher Belange bei der Fehlende Beachtung

bertragung personenbezogener Daten zwischen den Komponenten des datenschutzrechtlicher
RAS-Systems kann es zu Gesetzesversten kommen. So ist z. B. bei der Belange
Einrichtung automatisierter Abrufverfahren durch die beteiligten Stellen zu
gewhrleisten, dass die Zuverlssigkeit des Abrufverfahrens kontrolliert
werden kann (vgl. 10 Abs. 2 Bundesdatenschutzgesetz).
Beispiele:
- Inkompatible Sicherheitseinstellungen: Der Administrator des RAS-
Systems lsst nur mit Tripel-DES-Verfahren verschlsselte Verbindungen
zu, ein Benutzer hat jedoch fr den RAS-Client keine Verschlsselung
konfiguriert. Eine Verbindung wird daher nicht aufgebaut.
- Von der Planung abweichende Installation: Aufgrund inkompatibler
Anschlsse zwischen RAS-Server und bergabepunkt des Telekommuni-
kationsanbieters (z. B. ISDN-Endgerteanschluss gegenber ISDN-
Anlagenanschluss) sowie ungnstiger Leitungsfhrung wird bei der Instal-
lation des RAS-Systems entschieden, dass eine zustzliche kleine ISDN-
Anlage installiert wird, welche kompatible Anschlsse zu beiden Seiten hin
anbietet. Da dieses zustzliche Gert in der Planung nicht erfasst wurde,
wird versumt, es im RAS-Sicherheitskonzept zu bercksichtigen. Bei
aufgebauter RAS-Verbindung ist es nun mglich, z. B. ber den mit einem
Standardpasswort gesicherten Fernwartungszugang, auf das Gert
zugreifen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.65 Komplexitt der SAMBA-Konfiguration

SAMBA ist ein freies Programmpaket fr Unix-Betriebssysteme, das unter
anderem Datei-, Druck- und Authentisierungsdienste ber das SMB (Server
Message Block) bzw. CIFS (Common Internet File System) Protokoll zur
Verfgung stellt. Wichtigste Beispiele fr SMB/CIFS-Clients sind sicherlich
die Betriebssysteme der Microsoft Windows-Familie. Hierdurch ist es
beispielsweise mglich, dass Windows 9x- oder Windows NT-Rechner direkt
auf freigegebene Dateien auf einem Unix-Server zugreifen knnen. Ein
Umweg ber die Protokolle FTP oder NFS und die Installation zustzlicher
Software auf Client-Seite entfallen. In der aktuellen Version bildet SAMBA
eine ganze Reihe der Funktionen eines Windows NT Servers nach, sodass ein
Unix-System mit SAMBA in vielen Fllen einen solchen Server ersetzen
kann.
Die Konfiguration von SAMBA geschieht hauptschlich auf der Server-Seite unbemerkte Seiten-
effekte
in der Datei smb.conf, insbesondere werden hier die freigegebenen Verzeich-
nisse und Drucker sowie diverse Einstellungen zur Authentisierung einge-
tragen. Hierzu existiert eine ganze Reihe von Parametern, die in den einzelnen
Abschnitten der Datei smb.conf gesetzt werden knnen. Eine bestimmte
Funktion des SAMBA-Servers wird in der Regel durch mehrere verschiedene
Parameter gesteuert. Je nach Anwendungsfall kann das Zusammenspiel dieser
Parameter untereinander sehr komplex sein, so dass die Gefahr besteht, dass
der Administrator die Wirkung einer bestimmten Parameter-Kombination
falsch interpretiert. Insbesondere besteht die Gefahr, dass bei Modifikation
eines bestimmten Parameters unbemerkte Seiteneffekte entstehen, die die
Sicherheit des Servers u. U. beeintrchtigen.
Die zuvor beschriebene Problematik wird bei der Konfiguration der Zugriffs- Zugriffsrechte auf
Verzeichnisse/Dateien
rechte auf Verzeichnisse und Dateien noch verstrkt. Hier sind nicht nur die
Einstellungen in der Datei smb.conf, sondern auch die Zugriffsrechte auf dem
(Unix-)Dateisystem zu bercksichtigen, auf dem die Verzeichnisse bzw.
Dateien vorgehalten werden. Die tatschlichen Rechte, die fr den Benutzer
beim Zugriff ber SAMBA gltig sind, lassen sich ber die Datei smb.conf auf
zwei verschiedenen Wegen beeinflussen: Einerseits knnen direkt
Zugriffsbeschrnkungen fr die einzelnen Freigaben eines SAMBA-Servers
vergeben werden (z. B. ber den Parameter valid users). Andererseits existie-
ren in der Datei smb.conf Parameter (z. B. force user), mit denen konfiguriert
werden kann, wie sich verzeichnis- und dateibasierte Zugriffsbeschrnkungen
auf die tatschlich gltigen Rechte des Benutzers auswirken. Hier kann leicht
eine Fehlkonfiguration entstehen, die dazu fhrt, dass Benutzer zu weit-
reichende Zugriffsrechte auf Verzeichnisse bzw. Dateien erhalten.
Beispiel:
Der Administrator eines SAMBA-Servers vergibt verzeichnis- bzw. datei-
basierte Zugriffsrechte auf dem lokalen Dateisystem des Servers. Hierzu setzt
er auf allen freigegebenen Bereichen geeignete Permissions und Ownerships.
In der Datei smb.conf ist jedoch die Zeile
force user = root
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
enthalten. Dies bedeutet, dass Zugriffe auf das Dateisystem unter dem Benut-
zer-Account "root" durchgefhrt werden, unabhngig davon, welcher
Benutzer sich am Server angemeldet hat. In der Regel fhrt dies dazu, dass
verzeichnis- und dateibasierte Zugriffsbeschrnkungen ignoriert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.66 Unzureichendes IT-Sicherheitsmanagement

Die Komplexitt der heute vielerorts eingesetzten IT-Systeme und ihre Unkoordinierte
zunehmende Vernetzung macht ein organisiertes Vorgehen bei der Planung, Vorgehensweise
Durchfhrung und Kontrolle des IT-Sicherheitsprozesses zwingend erforder-
lich. Die Erfahrung zeigt, dass es nicht gengt, lediglich die Umsetzung von
Manahmen anzuordnen, da die einzelnen Betroffenen, insbesondere die IT-
Benutzer dadurch hufig aufgrund fehlender Fachkenntnisse und unzureichen-
der zeitlicher Ressourcen berfordert sind. In der Konsequenz wird es hufig
unterlassen, berhaupt Sicherheitsmanahmen umzusetzen, so dass kein
befriedigender IT-Sicherheitszustand erreicht wird. Selbst wenn ein solcher
einmal erreicht wurde, bedarf er der stndigen Pflege, um ihn dauerhaft im
laufenden Betrieb aufrechtzuerhalten.
Ein unzureichendes IT-Sicherheitsmanagement ist hufig Symptom einer Mangelhafte
Gesamtorganisation
mangelhaften Gesamtorganisation des IT-Sicherheitsprozesses und damit des
gesamten IT-Betriebs. Beispiele fr konkrete Gefhrdungen, die aus einem
unzureichenden IT-Sicherheitsmanagement resultieren, sind:
- Fehlende persnliche Verantwortung: Wird in einer Organisation kein IT-
Sicherheitsmanagement-Team eingerichtet bzw. kein IT-Sicherheitsbeauf-
tragter ernannt und die persnliche Verantwortung fr die Umsetzung von
Einzelmanahmen nicht eindeutig festgelegt, so ist es wahrscheinlich, dass
viele IT-Benutzer ihre Verantwortung fr die IT-Sicherheit durch Verweis
auf bergeordnete Hierarchieebenen ablehnen. Folglich unterbleibt die
Umsetzung von Manahmen, die ja zunchst fast immer einen Mehrauf-
wand im gewohnten Arbeitsablauf darstellt.
- Mangelnde Untersttzung durch die Leitungsebene: In der Regel gehren
IT-Sicherheitsbeauftragte nicht der Behrden- bzw. Unternehmensleitung
an. Unterbleibt seitens dieser eine unmissverstndliche Untersttzung der
IT-Sicherheitsverantwortlichen bei ihrer Arbeit, so werden sie es mitunter
schwer haben, notwendige Manahmen auch von IT-Benutzern, die in der
Linienstruktur ber ihnen stehen, wirksam einzufordern. Eine vollstndige
Umsetzung des IT-Sicherheitsprozesses ist unter diesen Umstnden nicht
gewhrleistet.
- Unzureichende strategische und konzeptionelle Vorgaben: In vielen
Organisationen wird die Erstellung eines IT-Sicherheitskonzept in Auftrag
gegeben, dessen Inhalt nur wenigen Insidern bekannt ist und dessen
Vorgaben an Stellen, an denen organisatorischer Aufwand zu betreiben
wre, bewusst oder unbewusst nicht eingehalten werden. Sofern das IT-
Sicherheitskonzept strategische Zielsetzungen enthlt, werden diese viel-
fach als bloe Sammlung von Absichtserklrungen betrachtet, und es
werden fr deren Umsetzung keine gengenden Ressourcen zur Verfgung
gestellt. Vielfach wird flschlicherweise davon ausgegangen, dass in einer
automatisierten Umgebung Sicherheit automatisch produziert werde.
Schadensflle in der eigenen oder in hnlich strukturierten Organisationen,
sind bisweilen Auslser fr mehr oder minder heftigen Aktionismus, bei
dem hufig bestenfalls Teilaspekte verbessert werden.
- Unzureichende oder fehlgeleitete Investitionen: Wird die Leitungsebene
einer Organisation nicht durch regelmige und mit klaren Priorisierungen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
versehene IT-Sicherheitsreports ber den Sicherheitszustand der IT-

Systeme und Anwendungen und ber vorhandene Mngel unterrichtet, ist
es wahrscheinlich, dass nicht gengend Ressourcen fr den IT-Sicherheits-
prozess bereitgestellt oder diese nicht sachgerecht eingesetzt werden. In
letzterem Fall kann es dazu kommen, dass einem bertrieben hohen
Sicherheitsniveau in einem Teilbereich schwerwiegende Mngel in einem
anderen gegenberstehen. Hufig ist auch zu beobachten, dass teure
technische Sicherungssysteme falsch eingesetzt werden und somit unwirk-
sam sind oder gar selbst zur Gefahrenquelle werden.
- Unzureichende Durchsetzbarkeit von Manahmenkonzepten: Zur Errei-
chung eines durchgehenden IT-Sicherheitsniveaus ist es erforderlich, dass
unterschiedliche Zustndigkeitsbereiche innerhalb einer Organisation
miteinander kooperieren. Fehlende strategische Leitaussagen und unklare
Zielsetzungen fhren mitunter zu unterschiedlicher Interpretation der
Bedeutung der IT-Sicherheit. Dies kann zur Konsequenz haben, dass die
notwendige Kooperation wegen vermeintlich fehlender Notwendigkeit
oder ungengender Priorisierung der Aufgabe "IT-Sicherheit" letztlich
unterbleibt und somit die Durchsetzbarkeit der IT-Sicherheitsmanahmen
nicht gegeben ist.
- Fehlende Aktualisierung im IT-Sicherheitsprozess: Neue IT-Systeme oder
neue Bedrohungen beeinflussen den IT-Sicherheitszustand innerhalb einer
Organisation. Ohne effektives Revisionskonzept verringert sich das IT-
Sicherheitsniveau. Aus realer Sicherheit wird somit schleichend eine
gefhrliche Scheinsicherheit, da das Bewusstsein fr die neuen Bedro-
hungen hufig fehlt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.67 Ungeeignete Verwaltung von Zugangs- und

Zugriffsrechten
Wenn die Vergabe von Zugangs- und Zugriffsrechten schlecht geregelt ist,
fhrt das schnell zu gravierenden Sicherheitslcken, z. B. durch Wildwuchs in
der Rechtevergabe.
In vielen Organisationen ist die Verwaltung von Zugangs- und Zugriffsrechten hoher Arbeitsaufwand
eine extrem arbeitsintensive Aufgabe, weil sie schlecht geregelt ist oder die
falschen Tools dafr eingesetzt werden. Dadurch kann z. B. viel "Handarbeit"
erforderlich sein, die gleichzeitig wiederum sehr fehleranfllig ist. Auerdem
sind in diesem Prozess dann auch hufig viele unterschiedliche Rollen und
Personengruppen eingebunden, so dass hier auch leicht der berblick ber
durchgefhrte Aufgaben verloren geht.
Weiterhin gibt es auch Organisationen, in denen kein berblick ber alle auf berblick geht verloren
den verschiedenen IT-Systemen eingerichteten Benutzer und deren Rechte-
profil vorhanden ist. Typischerweise fhrt das dazu, dass sich Accounts finden
von Benutzern, die die Behrde bzw. das Unternehmen lngst verlassen haben
oder die durch wechselnde Ttigkeiten zu viele Rechte aufgehuft haben.
Wenn die Tools zur Verwaltung von Zugangs- und Zugriffsrechten schlecht
ausgewhlt wurden, sind diese oft nicht flexibel genug, um auf nderungen in
der Organisationsstruktur oder auf Wechsel der IT-Systeme angepasst zu
werden.
Die Rollentrennung von Benutzern kann falsch vorgenommen worden sein, so Falsche Rolleneinteilung
dass Sicherheitslcken entstehen, beispielsweise durch falsche Zuordnung von
Benutzern in Gruppen oder zu grozgige Rechtevergabe. Benutzer knnen
Rollen zugeordnet werden, die nicht ihren Aufgaben entsprechen (zu viel oder
zu wenig Rechte) oder die sie aufgrund ihrer Aufgaben nicht haben drfen
(Rollenkonflikte).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.68 Fehlende oder unzureichende Planung des

Active Directory
Die globale Struktur des Active Directory, also die Gliederung in Domnen,
hat weitreichende Auswirkungen auf die Sicherheit einer Windows 2000
Installation. Problematische Aspekte ergeben sich hier besonders dann, wenn
fr die verschiedenen Domnen unterschiedliche Sicherheitsanforderungen
bestehen oder Domnen zu verschiedenen Organisationsbereichen gehren.
Bei fehlender oder unzureichender Planung ergeben sich beispielsweise
folgende domnenbergreifende Gefhrdungen:
- Alle Domnen in einem Active Directory mssen das gleiche Schema inkompatible
Schemanderungen
verwenden. Soll auch nur in einer Domne eine Software installiert
werden, die eine Schemanderung bentigt, mssen alle anderen Domnen
diese nderung mit tragen. Inkompatible Schemanderungen durch
verschiedene Softwareprodukte knnen dann dazu fhren, dass Software
nicht installiert werden kann oder fehlerhaft abluft.
- Bestimmte Benutzerdaten aus dem Active Directory (Global Catalog) Datenschutz
stehen in jeder Domne zur Verfgung. Dies kann unter Aspekten des
Datenschutzes problematisch sein.
- Administratoren der Forest Root Domain haben weitreichende Befugnisse verzgerte
Kontosperrung
auch in anderen Domnen.
- Ist eine Domne auf mehrere Standorte verteilt, die nur unzureichend
miteinander vernetzt sind, kann es zu lange dauern, bis eine Kontosperrung
in allen Standorten wirksam wird. Daher kann sich ein Benutzer, dessen
Konto gesperrt worden ist, u. U. noch an anderen Standorten am System
unberechtigt anmelden.
Auch innerhalb einer Domne muss der Aufbau des Active Directory sorg-
fltig geplant werden, da sich sonst beispielsweise folgende Gefhrdungen
ergeben:
- Werden Rechner und Benutzerkonten in den voreingestellten Containern
Computer und Benutzer unterhalb der Domne angeordnet, ist keine
Gruppenrichtlinien-Konfiguration entsprechend verschiedener Typen von
Benutzerkonten oder verschiedener Computertypen mglich.
- Werden Organisations-Einheiten (OUs) tief geschachtelt, so kann die
Struktur der Domne unberschaubar werden, so dass das Active Directory
anflliger fr Fehlkonfigurationen wird. Zudem sinkt die Performance des
Active Directory Dienstes mit der Schachtelungstiefe, wenn OUs zu tief,
d. h. ber mehr als 4 Ebenen, geschachtelt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.69 Fehlende oder unzureichende Planung des

Einsatzes von Novell eDirectory
Als Werkzeug fr das Ressourcenmanagement in Netzen ist eDirectory fr
den Einsatz in einer heterogenen IT-Umgebung unter einer Vielzahl unter-
sttzter Betriebssysteme ausgelegt. Die Sicherheit des Gesamtsystems ist
naturgem abhngig von der Sicherheit jedes Teilsystems. Die Betriebs-
systemsicherheit und speziell die Sicherheit des Dateisystems sind die Basis,
auf die sich die Sicherheit von eDirectory sttzt.
Da sich eDirectory sowie die einsetzbare Clientsoftware auf einer Vielzahl
von Betriebssystemen installieren und betreiben lassen, kann sich daraus eine
hohe Vielfalt der bei den eingesetzten Betriebssystemen jeweils vorzu-
nehmenden Sicherheitseinstellungen ergeben. Dies erhht die Anforderungen
an die Planung und setzt entsprechende Kenntnisse smtlicher involvierter
Betriebssysteme voraus. Es besteht deshalb die Gefahr, dass der Einsatz von
eDirectory nicht detailliert und tief genug geplant wird, wenn die Gesamt-
lsung sehr heterogen ist.
Fr den Einsatz im Intranet ist speziell die Planung der Baumstruktur und die Unzulnglicher Betrieb
des Verzeichnisdienstes
Abbildung der Unternehmensinfrastruktur darin von groer Bedeutung. Bei
fehlerhafter Planung besteht die Gefahr von Inkonsistenzen und bermiger
Komplexitt im Aufbau des Verzeichnisdienstes. Daraus knnen in der Folge
Fehlkonfigurationen und falscher oder unzulnglicher Betrieb des Systems
resultieren.
Die globale Baumstruktur des eDirectory-Verzeichnisdienstes hat weit- Inkonsistenz der Sicher-
heitsrichtlinien zwischen
reichende Auswirkungen auf die Sicherheit einer eDirectory-Installation. einzelnen Baum-
Problematische Aspekte ergeben sich hier besonders dann, wenn die verschie- Hierarchien
denen Teilbume unterschiedliche Sicherheitsanforderungen haben oder zu
verschiedenen Organisationsbereichen gehren. Durch die impliziten
Vererbungsmechanismen und die Komplexitt der Regeln fr die Berechnung
der tatschlich wirksamen, effektiven Rechte einzelner Objekte stellt dies
hohe Anforderungen an die Planung des Systems.
Die implizit eingesetzte CA (Zertifizierungsstelle) ist wesentlicher Bestandteil
der Sicherheit von eDirectory. Auch hier kann eine fehlerhafte Planung die
Sicherheit des Verzeichnisdienstes beeintrchtigen.
Die Planung der Zugriffsmglichkeiten auf den Verzeichnisdienst ist ein Unklarheit ber die tat-
schlich angewendeten
Kernthema fr die Systemsicherheit. Dies gilt sowohl fr den Einsatz im effektiven Rechte
Intranet als auch besonders fr den Einsatz von eDirectory als LDAP-Server
im Internet.
Weiterhin ist die Planung der Administration des Verzeichnisdienstes ein Ungewollte Zugriffs-
mglichkeiten auf den
wichtiges Thema. eDirectory erlaubt die Umsetzung eines Rollen-basierten Verzeichnisdienst
Administrationskonzeptes sowie die Delegation von Administrationsaufgaben.
Dies ist speziell unter dem Aspekt der Sicherheitsadministration wichtig. Die
Planung der Administration erfordert uerste Sorgfalt und Umsicht, anderen-
falls besteht die Gefahr, dass unautorisierte Systemnutzer ungewollte
Zugriffsmglichkeiten erhalten.
Darber hinaus bietet die eDirectory-Software das iMonitor-Tool, welches
einen Web-basierten Monitorzugriff auf die eDirectory-Server und das
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verzeichnissystem gestattet. Eine fehlerhafte Planung des Einsatzes dieser

Funktionalitt erlaubt unter Umstnden unautorisierten Benutzern den Zugang
zu Interna der eDirectory-Installation.
Ein wichtiger Punkt im Betrieb von eDirectory ist auch die Partitionierung des
Verzeichnisdienstes und dessen Replikation. Hier kann eine unzulngliche
Planung mangelhafte Performance, Inkonsistenzen in der Datenhaltung bis hin
zu Datenverlusten zur Folge haben.
Der eDirectory-Verzeichnisdienst erlaubt eine rollenbasierte Administration Inkonsistenz der Sicher-
heitsrichtlinien zwischen
der Verzeichnisdatenbank sowie die Delegation einzelner Administrations- eDirectory und der
aufgaben. Die Planung der Administrationsrollen und der Delegations- jeweiligen Betriebs-
mglichkeiten hat dabei in bereinstimmung mit der festzulegenden Sicher- systemumgebung
heitsrichtlinie (siehe M 2.238 Festlegung einer Sicherheitsrichtlinie fr Novell
eDirectory) zu erfolgen. Bei fehlender oder fehlerhafter Planung der
Administrationsaufgaben besteht die Gefahr, dass das System unsicher oder
unzulnglich administriert wird.
eDirectory erlaubt die Synchronisation von Verzeichnisdaten mit weiteren Unzulngliche
Administration des
Verzeichnisdiensten via DirXML. DirXML besteht aus einem Kern (engine) Verzeichnissystems
und spezialisierten Treibern (z. B. fr Windows 2000 Active Directory, Lotus
Notes, SAP R/3, Netscape, etc.) fr den Austausch von Verzeichnisinforma-
tionen im XML-Format. Dabei knnen die fremden Verzeichnisdienste ber
einen so genannten Publisher Channel dem eDirectory nderungen mitteilen.
Bei entsprechenden Rechten, die vom jeweils betrachteten Zielsystem abhn-
gen, werden diese nderungen dann auch im eDirectory aktiv. Die externen
Verzeichnisse knnen sich umgekehrt beim eDirectory einschreiben, um
nderungen des eDirectory-Informationsstandes ber diesen Kanal (subscri-
ber channel) zu erfahren und ihr Verzeichnis daraufhin abzugleichen. Diese
Synchronisation bedarf einer detaillierten Planung, da anderenfalls sensitive
Daten unter Umstnden ungewollt automatisiert nach auen vervielfltigt
werden. Umgekehrt knnen unter Umstnden ungewollt bestehende Daten auf
diesem Weg berschrieben werden. Um die Daten beim Transport zu
schtzen, kann SSL eingesetzt werden. Hierbei knnen Fehler in der Planung
den Verlust von Integritt und Vertraulichkeit von Verzeichnisdaten nach sich
ziehen.
Nicht zuletzt ist die Verwendung von Login-Skripts fr Benutzer und
Benutzergruppen zu planen. Bei fehlender oder unzulnglicher Planung
knnen hierbei Inkonsistenzen zur festgelegten Sicherheitsrichtlinie auftreten.
Darber hinaus knnen sich bei fehlender oder unzureichender Planung auch
folgende Probleme ergeben:
- Der Administrationszugriff auf das System kann unzureichend gesichert
sein,
- der Betrieb der Public-Key-Infrastruktur kann unzulnglich sein,
- die Systemperformance zu gering sein und
- es kann zu Datenverlusten kommen, sofern Replikation und Backup nicht
ausreichend bercksichtigt wurden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.70 Fehlerhafte oder unzureichende Planung der

Partitionierung und Replizierung im Novell
eDirectory
Die Partitionierung und die Replizierung des eDirectory-Verzeichnisdienstes
ist ein wesentlicher Aspekt bei der Planung des Einsatzes.
Bei der Partitionierung handelt es sich um eine Aufteilung der Verzeichnis-
daten des eDirectory in einzelne Teilbereiche (Partitionen). Diese Aufteilung
kann nicht beliebig erfolgen, sondern muss gewissen Regeln entsprechen, die
sich aus der Logik der hierarchischen Baumstruktur ergeben. Zweck der
Partitionierung ist zum einen eine Lastverteilung des Verzeichnissystems auf
mehrere Teile, zum anderen kann damit eine physikalische Trennung der
Aufbewahrungsorte von Verzeichnisdaten - z. B. den Standorten einer Organi-
sation entsprechend - erreicht werden. Weiterhin knnen Partitionen auch
Verwaltungseinheiten des Verzeichnissystems darstellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Replizierung von Partitionen des eDirectory dient in erster Linie der
Erhhung der Verfgbarkeit und der Lastverteilung des Verzeichnissystems.
Weiter wird durch die Redundanz in der Datenhaltung die Ausfallsicherheit
verbessert.
Die Planung ist auch deshalb von entscheidender Bedeutung, da nachtrgliche
nderungen an den Partitions- und Replikationseinstellungen zwar mglich
sind, jedoch unter Umstnden Inkonsistenzen nach sich ziehen knnen.
Bei nderungen am eDirectory dauert es naturgem eine gewisse Zeit, bis Zeitfenster mit
Inkonsistenzen
sich die neuen Einstellungen berall hin ausgebreitet haben. Somit kann sich
ein Zeitfenster ergeben, innerhalb dessen das eDirectory inkonsistent ist.
Solche Inkonsistenzen knnen vor allem in der Definition der Authentisie-
rungsdaten oder auch der Zugriffsrechte auf eDirectory-Objekte ein Problem
darstellen.
Eine Partitionierung des eDirectory-Verzeichnisses hat direkte Konsequenzen
fr die Vererbung von Zugriffsrechten (Access Control Lists, ACL). Um die
Vererbungsregeln bei einem bestehenden eDirectory-Baum zu erhalten, wird
bei einer Partitionierung dem Wurzelobjekt der neuen Partition die bergeord-
nete ACL als inherited ACL vom System zur Kenntnis gebracht.
Die Festlegung der Partitionierung des eDirectory-Verzeichnisdienstes hat erhhter
Administrationsaufwand
direkte Auswirkung auf die Replizierungsaktivitten des Gesamtsystems. Um
effizient ber den Gesamtbaum nach Objekten suchen zu knnen (Tree
walking), legt das eDirectory automatisch so genannte Subordinate Reference
Replicas an, welche im Wesentlichen Sprungadressen enthalten. Ist die
Planung unzulnglich (z. B. bei zu flacher Baumstruktur), so werden hier sehr
umfassende Replizierungsringe erzeugt. Wird ein Replizierungsring sehr gro,
so besteht eine gewisse Wahrscheinlichkeit, dass zumindest ein eDirectory-
Server des Ringes momentan nicht erreichbar ist. In einem solchen Fall
werden Fehler- und Statusmeldungen auf jedem weiteren eDirectory-Server
des Replizierungsrings erzeugt. Dies kann zu erhhtem Administrations-
aufwand fhren, der sich ber groe Teile des Verzeichnisbaums erstrecken
kann.
Weitere Problemfelder sind in G 2.42 Komplexitt der NDS beschrieben.
Auerdem kann eine fehlerhafte oder unzureichende Planung der Partitionie-
rung und der Replizierung des Verzeichnisdienstes auch zu Datenverlusten
sowie Inkonsistenzen in der Datenhaltung, einer mangelhaften Verfgbarkeit
des Verzeichnisdienstes und einer insgesamt schlechten Systemperformance
bis hin zu Systemausfllen fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.71 Fehlerhafte oder unzureichende Planung des

LDAP-Zugriffs auf Novell
Die LDAP-Zugriffsmglichkeit auf den Verzeichnisdienst von eDirectory ist
ein wesentliches Leistungsmerkmal des Softwareprodukts. Der Zugriff durch
die Benutzer erfolgt ber das LDAP v3-Protokoll, welches einen weit-
verbreiteten Internet-Standard darstellt. Betreiber, die eDirectory als
eBusiness-Plattform verwenden, stellen ihren Benutzern dabei in der Regel
spezielle Clients zur Verfgung. Einfache Web-Browser oder E-Mail-Clients
knnen jedoch ebenfalls als LDAP-Clients agieren.
Die LDAP-Schnittstelle ist auerdem auch dazu geeignet, dass Netzappli-
kationen und deren Services darber auf den Verzeichnisdienst zugreifen.
Dieser Zugriff bedarf eingehender Planung, insbesondere auch in Bezug auf
die fr den sinnvollen Einsatz der Anwendungen bentigten eDirectory-
Rechte.
Die Planung des LDAP-Zugriffs hngt also wesentlich vom Einsatzszenario verschiedene
Verbindungsarten
des eDirectory ab. Prinzipiell gibt es aus Sicht des eDirectory drei verschie-
dene Verbindungsarten fr einen LDAP-Client:
- als [Public] Objekt (Anonymous Bind): Hierbei werden keine Authenti-
sierungsinformationen abgefragt und das [Public] Objekt besitzt standard-
mig stets das uneingeschrnkte Browse-Recht auf den Verzeichnisbaum.
- als Proxy User (Proxy User Anonymous Bind): Diese Konfigurationsmg-
lichkeit kann anstelle des anonymen Login gewhlt werden. Der Proxy
User ist dabei eDirectory-seitig entsprechend zu konfigurieren.
- als NDS User (NDS User Bind): Hierbei meldet sich der Benutzer mit
seinen eDirectory-Rechten am Verzeichnisdienst an. Das entsprechende
Benutzerobjekt muss beim eDirectory angelegt sein.
Es muss in der Planung bercksichtigt werden, ob und welche Daten im Klar- Was darf im Klartext
bertragen werden?
text gem den organisationsinternen Sicherheitsrichtlinien bertragen werden
drfen. Dies gilt fr den Einsatz im Intranet sowie besonders fr die Anbin-
dung an das Internet.
Dabei geht es z. B. darum, ob Benutzerpasswrter im Klartext bermittelt
werden drfen und wie konsequent der Einsatz der SSL-Verschlsselung
umgesetzt wird. Damit untersttzt eDirectory entsprechend dem Standard
LDAP v3 zwei Verbindungsarten:
- anonymous bind: ohne Benutzername und Passwort,
- clear-text password bind: Benutzername und Klartextpasswort zur
Authentisierung.
Zustzlich wird LDAP ber SSL untersttzt. Seitens eDirectory muss konfi-
guriert werden, ob die ersten beiden Verbindungsarten untersttzt werden.
Auerdem wird SSL in zwei Modi untersttzt: ein- und zweiseitige Authenti-
sierung. Bei beidseitiger Authentisierung mssen die erforderlichen Creden-
tials, unter anderem das Wurzelzertifikat der Zertifizierungsstelle, allgemein
zugnglich sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Durch die oben beschriebene Vielfalt der Konfigurationsoptionen fr den Fehlkonfigurationen

LDAP-Zugriff auf den eDirectory-Verzeichnisdienst knnen sich schnell
Fehlkonfigurationen ergeben. Konsequenzen solcher Fehlkonfigurationen
knnten sein:
- Falsche Vergabe von Zugriffsrechten,
- unautorisierte Zugriffsmglichkeiten auf den eDirectory-Verzeichnisdienst,
- bermittlung von Benutzerpasswrtern im Klartext,
- Aussphen von unverschlsselten Informationen,
- Fehler beim LDAP-Zugriff, insbesondere fr netzbasierte Anwendungen,
sowie
- unzureichende Produktivitt des Gesamtsystems.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.72 Unzureichende Migration von Archivsystemen

Archivierte Daten sollen typischerweise ber einen sehr langen Zeitraum ge-
speichert bleiben. Whrend dieses Zeitraums knnen die zugrundeliegenden
technischen Systemkomponenten, Speichermedien und Datenformate physi-
kalisch bzw. technologisch altern und dadurch unbrauchbar werden. Auer-
dem knnen sich im Laufe der Zeit Probleme mit der Kompatibilitt der ver-
wendeten Datenformate ergeben.
Wenn auf die Alterung des bestehenden Systems nicht reagiert wird, ist lang- Alterung von
Komponenten
fristig damit zu rechnen, dass
- archivierte Rohdaten physikalisch nicht mehr von den Archivmedien lesbar
sind,
- archivierte Daten durch physikalische Fehler an Archivsystem und -medien
verndert werden,
- Ersatzteile fr Hardware-Komponenten nicht mehr lieferbar sind,
- Ergnzungen fr Software-Komponenten nicht mehr lieferbar sind,
- verwendete Datenformate nicht mehr den Integrittsanforderungen entspre-
chen,
- elektronische Signaturen unbrauchbar werden,
- verschlsselte Daten fr Unberechtigte lesbar werden.
Auch wenn rechtzeitig Systemkomponenten ausgetauscht oder die Daten Alterung
kryptographischer Ver-
kopiert werden, so knnen trotzdem noch Probleme durch die Verwendung fahren
kryptographischer Verfahren auftreten. Beispielsweise knnten Schwachstel-
len in integrittssichernden Verfahren entstehen, da Verschlsselungs- und
Signaturalgorithmen im Laufe der Zeit und mit steigender Rechenleistung an
Schutzwirkung verlieren knnen (siehe auch G 2.79 Unzulngliche Er-
neuerung von digitalen Signaturen bei der Archivierung).
Beispiele:
- Durch physikalische Langzeiteinflsse (Materialverschlei, Verformung,
Verkratzen von Medienoberflchen, Weichmacher) knnen Datentrger
beschdigt werden. Je nach Verwendungszweck des betroffenen Daten-
trgers als System- oder Archivmedium kann der Betrieb des Archiv-
systems gestrt oder die auf den Archivmedien gespeicherten Daten verlo-
ren gehen.
- Der Hersteller eines Archivsystems hatte in den Kontextdaten fr Doku-
mente ein Debug-Feld vorgesehen. In der Pilotphase des Archivsystems
wurden Dokumente aus dem normalen Geschftsbetrieb zu Testzwecken
archiviert, wobei der Teststatus in der Debug-Information festgehalten
wurde. Beim bergang in die Betriebsphase wurden die Testdokumente
dann nicht gelscht, da sie auf WORM-Datentrgern archiviert waren,
sondern es wurden die mit der betreffenden Debug-Information markierten
Dokumente nicht mehr angezeigt. Das Nachfolgesystem wurde von einem
anderen Hersteller geliefert, der Debug-Informationen auf eine andere
Weise darstellte. Bei der anschlieenden Migration der Archivdaten auf
das neue Archivsystem wurde jedoch versehentlich das alte Debug-Feld
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nicht ausgewertet. Die alten Testdokumente befanden sich nach der Migra-
tion der Daten weiterhin im Archiv, tauchten bei einer spteren Recherche
jedoch pltzlich als vermeintlich authentische Dokumente auf.
- Elektronische Signaturverfahren knnten durch Ausprobieren der Signatur-
schlssel oder durch mathematische Verfahren kompromittiert werden.
Sofern dies innerhalb des Archivierungszeitraums eintritt, ist es mglich,
elektronische Signaturen auch rckwirkend zu flschen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.73 Fehlende Revisionsmglichkeit von

Archivsystemen
Die Revision eines Archivierungsvorgangs muss sowohl organisatorische als
auch technische Kriterien bercksichtigen. Die Prfung von Archivsystemen
muss daher neben der Begutachtung der Systemkonfiguration auch die Pr-
fung der Vergabe und Nutzung von Zugriffsrechten umfassen.
Wenn das ausgewhlte Archivsystem hierbei nicht die notwendige technische
Untersttzung liefert, z. B. in Form von speziellen Benutzerkonten fr die
Revision, Monitoring-Werkzeugen, integrittsgeschtzten Protokolldateien
(siehe G 2.76 Unzureichende Dokumentation der Archivzugriffe), kann der
Prfungsvorgang sehr aufwendig werden. Dadurch besteht auerdem die Ge-
fahr, dass dieser nur unvollstndig stattfindet und wesentliche Punkte berse-
hen werden. Der Revisionsvorgang des Archivierungsprozesses kann hier-
durch insgesamt gefhrdet werden.
Mittelbar knnen sich hieraus rechtliche und wirtschaftliche Nachteile erge-
ben, z. B. durch den Wegfall der Nachweiskraft archivierter Dokumente.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.74 Unzureichende Ordnungskriterien fr Archive

Elektronische Archive knnen sehr groe Datenmengen beinhalten. Zur
Ablage und zum Wiederauffinden einzelner Datenstze dienen Ordnungskrite-
rien, die in Indexdaten des Dokumentenmanagementsystems (DMS) und
Indexdaten des Archivsystems zu unterscheiden sind.
Ordnungskriterien des DMS dienen dazu, den Kontext und Inhaltsangaben Dokumentenmanage-
mentsystem
zusammen mit dem jeweiligen Dokument zu verwalten. Eine ungeeignete
Auswahl von Kontextkriterien htte hier zur Folge, dass archivierte Doku-
mente nicht oder nur mit groem Aufwand wieder zu recherchieren wren
oder die Semantik archivierter Dokumente nicht eindeutig bestimmbar wre.
Eine groe Zahl von Kontextkriterien andererseits steigert den Verwaltungs-
aufwand und reduziert mit wachsender Zahl archivierter Dokumente die Per-
formance des Dokumentenmanagementsystems.
Ordnungskriterien des Archivsystems hingegen sind eher technischer Natur. Archivsystem
Sie dienen der Identifikation einzelner Rohdaten und der Organisation der
Ablage der Rohdaten auf Speichermedien. Ihre Auswahl wird in der Regel
nicht durch das DMS, sondern durch den Aufbau des Archivservers und der
zugrundeliegenden Speicherarchitektur bestimmt. Eine wesentliche Anforde-
rung ist die Eindeutigkeit der Dokumentkennung. Sollte diese Anforderung
verletzt werden, d. h. wenn zwei Dokumente dieselbe Dokumentkennung
erhalten, so kann je nach Suchverfahren beim Abrufen ein falsches Dokument
an das DMS zurckgegeben und dort mit einem neuen Dokumentkontext ver-
sehen werden. Das nicht gefundene Dokument wre zwar physikalisch vor-
handen, wrde aber nicht mehr eindeutig einem Vorgang im DMS zuzuordnen
sein.
Die Revisionssicherheit des Archivierungsprozesses bezieht sich wesentlich eindeutige Kennzeich-
nung
auf die eindeutige Kennzeichnung aller verwalteten Dokumente sowie die
Nachweisbarkeit der Verknpfung von Dokument und Kontextinformationen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.75 Mangelnde Kapazitt von Archivdatentrgern

Eine falsche Einschtzung des Datenaufkommens bei der Archivierung kann
dazu fhren, dass zu kleine Archivmedien verwendet werden und daher die
Archivierung unvollstndig oder verzgert erfolgt.
Bei der Abschtzung des bentigten Datenvolumens wird hufig nur die er- nderungshufigkeit
von Dokumenten
wartete maximale Gre der zu speichernden Dokumente als einzige Ein-
flussgre zugrundegelegt. Tatschlich jedoch kann der Speicherbedarf bei
Archivsystemen ein Vielfaches davon betragen, da hierbei auch die Art der
Datenablage sowie die nderungshufigkeit von Dokumenten einen wesent-
lichen Einfluss haben.
Bei einer Archivierung auf WORM-Medien (Write Once Read Multiple) wer-
den beispielsweise die Dokumente zwangslufig in mehreren Versionen ab-
gelegt, d. h. nach jeder nderung wird ein neues Dokument gespeichert.
Dadurch kann sich auch bei kleinen Dokumenten mit hoher nderungs-
frequenz ein hohes Datenvolumen ergeben. Alte Versionen der Dokumente
knnen nachtrglich nicht mehr vom Archivmedium gelscht werden. Neben
Kapazittsengpssen kann dies auch zu Datenschutz- oder Vertraulichkeits-
problemen fhren, da Daten nur als "zu lschen" markiert, aber nicht tatsch-
lich gelscht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.76 Unzureichende Dokumentation von

Archivzugriffen
Ebenso wie bei anderen IT-Systemen bestehen auch bei Archivsystemen
Manipulationsmglichkeiten, wenn diese schlecht geschtzt sind. Benutzer
knnten versuchen, geflschte Dokumente in das Archiv einzubringen und
durch Angabe entsprechender Kontextinformationen diese Dokumente beste-
henden Verwaltungsvorgngen zuzuweisen oder komplett neue Vorgnge zu
flschen. Systemadministratoren knnten Manipulationen am Archivsystem
vorbei durchfhren und die Manipulation durch Vernderung von Protokoll-
dateien verbergen.
blicherweise wird Protokolldateien ein geringerer Wert beigemessen als den Protokolldateien werden
oft vernachlssigt
zu archivierenden Dokumenten selbst. Dies uert sich hufig in geringeren
Aufbewahrungsfristen fr Protokolldateien und im weniger sorgsamen
Umgang mit Protokolldateien.
Wenn archivierte Dokumente in sptere Verwaltungsvorgnge einflieen sol-
len, ist es unerlsslich, die Authentizitt nachweisen zu knnen, also korrekte
von manipulierten Dokumenten unterscheiden und im Falle von strittigen
Dokumenten die Dokumenthistorie belegen zu knnen. Dies wird gefhrdet
durch
- eine nicht ausreichende Protokollierung der Archivzugriffe, insbesondere
der Speichervorgnge,
- einen nicht ausreichenden Schutz der Protokolldaten vor Manipulation
durch Benutzer sowie Systemadministratoren,
- den Verlust von Protokolldaten,
- zu kurze Aufbewahrungsfristen der Protokolldaten.
Sofern die zu archivierenden Dokumente nach Vertraulichkeitsstufen klassifi-
ziert sind, muss auch immer nachvollziehbar sein, wer zu welchem Zeitpunkt
Einsicht in Dokumente genommen hat. Dies ist nicht mehr gewhrleistet,
wenn Lesezugriffe und Suchanfragen nicht dokumentiert werden.
Beispiele:
- Im Rahmen einer Archiv-Recherche wird ein Dokument aufgefunden, das
in einem laufenden Verwaltungsvorgang eine Person in bestimmter Weise
belastet. Anhand der mitgespeicherten Kontextinformationen wird das
Dokument als authentisch bewertet. Das Dokument wurde aber seinerzeit
von einem Unberechtigten erzeugt, der bewusst falsche Kontextinformati-
onen (u. a. Ersteller des Dokuments und Erstelldatum) angegeben hatte, um
spter die fragliche Person belasten zu knnen. Da die Protokolldateien der
Archivzugriffe zwischenzeitlich gelscht wurden, kann dies aber nun nicht
mehr erkannt werden. Der betroffene Mitarbeiter wird dadurch flschlich
belastet.
- Ein Benutzer mit administrativen Privilegien manipuliert Dateien im
Cache-Bereich des Archivsystems, bevor diese auf dauerhaften Medien
abgelegt werden. Die Manipulation ist nicht nachvollziehbar, da der Be-
nutzer am Archivsystem vorbei sowohl die Daten selbst als auch die Proto-
kolldateien manipuliert hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.77 Unzulngliche bertragung von Papierdaten in

elektronische Archive
In vielen elektronischen Archiven werden regelmig Dokumente gespeichert,
die ursprnglich nur in Papierform vorlagen und daher in eine elektronische
Form bertragen werden mssen. Dies erfolgt unter Wahrung ausgewhlter
Merkmale des Originaldokuments. Je nach Verwendungszweck des Doku-
ments ergeben sich hier unterschiedliche Anforderungen. Dies kann die ber-
einstimmung des ueren Erscheinungsbilds der Kopie mit dem Original sein,
wenn beispielsweise eine Bilddatei verwendet wird. Es kann auch die ber-
einstimmung von Textausschnitten, z. B. unter Verwendung einer Textdatei,
oder die Abbildung weiterer Merkmale, z. B. Biometriedaten oder Kontext-
daten, gefordert sein.
Die Ablage als Text- oder Bilddatei allein reicht fr den Nachweis der Ori-
ginaltreue des Dokuments nicht immer aus, da sowohl Manipulationen als
auch Fehler auftreten knnen:
- Mit Text- und Bildverarbeitungsprogrammen knnen bestehende Doku- Manipulation
mente manipuliert werden.
- Durch Fehler beim Einscannen kann die Semantik der aufgenommenen Fehler beim Einscannen
Daten verflscht werden, wodurch Fehlinterpretationen und -berechnungen
ausgelst werden knnen. Beispielsweise knnten wichtige Teile des Do-
kuments beim Scanvorgang vergessen werden.
In einigen Archivierungsszenarien ist vorgesehen, die in Papierform vorlie-
genden Dokumente nach dem Einscannen aus Platzgrnden zu vernichten.
Hierbei muss davon ausgegangen werden, dass nach Vernichtung des Origi-
naldokumentes der sptere Nachweis der Originaltreue von Kopie und Doku-
ment nicht mehr direkt erbracht werden kann.
Dies bedeutet, dass alle fr sptere Nachweiszwecke notwendigen Merkmale
des Originaldokuments bereits in der Phase der bertragung in elektronischer
Form erfasst und nachvollziehbar mitgespeichert werden mssen. Werden
hierbei Merkmale nicht bercksichtigt oder vergessen (z. B. die Anzahl der
Seiten eines Originaldokumentes), kann das die Nachweiskraft der Doku-
mente erheblich einschrnken, da Nacherhebungen von Merkmalen des Origi-
naldokuments oftmals nicht mehr mglich sind.
Eine unzulngliche Vorgehensweise bei der bertragung der Dokumente ge-
fhrdet die Wirksamkeit und Nachvollziehbarkeit des nachfolgenden Ver-
arbeitungsprozesses fr Dokumente und letztlich die Korrektheit der archi-
vierten Dokumente.
Beispiele:
- Der eingehende Schriftverkehr einer Behrde wird zur spteren elektroni- Originale werden ver-
nichtet
schen Weiterverarbeitung eingescannt und im Archiv abgelegt. Gelegent-
lich wird jedoch vergessen, die Rckseite eines Briefes einzuscannen. Da
der eingehende Schriftverkehr nach dem Einscannen vernichtet wird, kann
der Originalzustand des Briefes nicht mehr nachgewiesen werden.
- Beim Einscannen und automatischen Erfassen von Text werden Passagen Text wird falsch erkannt
ausgelassen oder verflscht, die vom OCR-Programm (Optical Character
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Recognition - Verfahren zur Erkennung von Text aus Bilddateien) nicht

korrekt erkannt worden sind. Das kann z. B. in schwacher Farbe oder un-
deutlicher Schrift gedruckten Text betreffen, aber auch handschriftliche
Ergnzungen in Dokumenten oder ein verwischtes Druckbild von Tinten-
strahldruckern. Falsch erkannte Rechnungsbetrge (nicht erkannte Kom-
mata, etc.) sind ebenfalls eine mgliche Fehlerquelle fr sptere Missver-
stndnisse.
- Manuelle Unterschriften unter Dokumenten werden als Bild eingescannt. hndische Unterschrift
ist nicht berprfbar
Bei einem spteren Rechtsstreit ber die Echtheit von Dokument und
Unterschrift kann ein graphologisches Gutachten keine eindeutige Aussage
mehr liefern, da die vorgelegte Bilddatei mit einem Bildbearbeitungspro-
gramm manipuliert bzw. ein anderes Dokument kopiert worden sein
knnte. Merkmale des Originaldokuments, wie z. B. Beschaffenheit und
Zusammensetzung des verwendeten Papiers oder die Andruckstrke bei der
hndischen Unterschrift, sind nicht mehr nachvollziehbar.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.78 Unzulngliche Auffrischung von

Datenbestnden bei der Archivierung
Datentrger knnen physikalisch wie technologisch veralten. Datenformate
werden ebenfalls gelegentlich um neue syntaktische bzw. strukturelle Merk-
male erweitert. Beides kann dazu fhren, dass archivierte Daten nicht mehr
lesbar sind (siehe auch G 2.72 Unzureichende Migration von Archivsystemen).
Daher sollten elektronisch archivierte Dokumente in greren Zeitabstnden
auf neue Datentrger kopiert bzw. in neue, aktuellere Datenformate bertragen
werden. Hierbei besteht die Gefahr, dass Daten bei der bertragung auf neue
Datentrger aus ihrem Dokumentkontext gelst werden oder beim Um-
kopieren in andere Datenformate unbeabsichtigt semantische nderungen
vorgenommen werden.
Daneben bestehen Manipulationsmglichkeiten whrend der bertragung der
Daten auf ein neues Speichermedium. Hierbei knnen selbst auf WORM-Me-
dien abgelegte Daten "gendert" werden.
Nach der Migration der Datenbestnde kann die Notwendigkeit bestehen, alte
Datentrger zu vernichten. Hierzu wird auf die Gefhrdung G 2.81 Unzurei-
chende Vernichtung von Datentrgern bei der Archivierung verwiesen.
Beispiele:
- Im Rahmen der Migration der Datenbestnde werden Vorversionen von
versioniert gespeicherten Dokumenten aus Platzgrnden gelscht, obwohl
diese aus Nachweisgrnden noch bentigt werden.
- Es werden Dateien, die ursprnglich auf WORM-Medien nderungssicher
("revisionssicher") gespeichert waren, auf neue Datentrger bertragen.
Dabei werden Dateien whrend des Kopiervorgangs ausgetauscht, d. h.
einzelne Dateien werden nicht auf das neue Medium bernommen, statt-
dessen werden geflschte Dateien eingefgt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.79 Unzureichende Erneuerung von digitalen

Signaturen bei der Archivierung
Die Algorithmen und Schlssellngen, die bei digitalen Signaturen verwendet
werden, mssen in regelmigen Abstnden an den aktuellen Stand der Tech-
nik angepasst werden, damit ihre Schutzwirkung gewhrleistet ist (siehe
G 4.47 Veralten von Kryptoverfahren). Das bedeutet, dass die verwendeten
kryptographischen Schlssel und die zugehrigen Zertifikate nur eine be-
grenzte Zeit zuverlssige Gltigkeit besitzen. Gemessen an der angestrebten
Archivierungsdauer sind dies verhltnismig kurze Zeitrume. Um die Be-
weiskraft digitaler Signaturen zu erhalten, muss daher rechtzeitig die elektro-
nische Signatur jedes einzelnen Dokuments erneuert werden.
Bei der regelmigen Neusignatur der archivierten Dokumente knnen u. a.
folgende Sicherheitsprobleme auftreten:
- Wenn Dokumente mit einer vormals ungltigen oder fehlenden elektro- "versehentliche"
Neusignatur
nischen Signatur flschlicherweise eine gltige neue Signatur erhalten, so
knnen diese Dokumente fortan flschlicherweise als authentisch ange-
sehen werden.
- Es knnte passieren, dass Dokumente bei einer Neusignatur vergessen Dokumente werden
vergessen
werden, d. h. keine neue gltige Signatur erhalten, obwohl sie vormals
gltig signiert waren. Dadurch kann die Authentizitt bzw. Integritt des
betreffenden Dokuments fortan mglicherweise nicht mehr nachgewiesen
werden, wenn kein alternativer Nachweis anhand anderer Merkmale mg-
lich ist.
- Zum Zeitpunkt der Neusignatur knnte das zu Grunde liegende krypto- kompromittierte krypto-
graphische Verfahren
graphische Verfahren bereits kompromittiert oder der ursprngliche Sig-
naturschlssel bekannt geworden sein (z. B. durch massiven Rechenauf-
wand ermittelt). Dadurch knnten Unbefugte Dokumente erzeugen und mit
einer technisch gltigen Signatur, gegebenenfalls auch mit beliebigen Zeit-
signaturen (Zeitstempel), versehen. Gelingt es, diese Dokumente in den
Prozess der Neusignatur einzubringen, so knnen diese Dokumente flsch-
licherweise als authentisch angesehen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.80 Unzureichende Durchfhrung von Revisionen

bei der Archivierung
Die elektronische Archivierung stellt sehr hohe Anforderungen an den Prozess
der Umwandlung von Papierdokumenten in elektronische Dokumente. Die bei
der Archivierung auszufhrenden Ttigkeiten sollten in einer Verfahrensdo-
kumentation genau beschrieben sein und durch eine Protokollierung, die auf-
zeichnet, welcher Benutzer wann welche Aktivitten im Archiv ausgefhrt
hat, nachvollziehbar gemacht werden.
Zu seltene und zu ungenaue berprfung der Arbeitsvorgnge bei der Archi-
vierung oder der aufgezeichneten Protokolldaten kann mittelbar dazu fhren,
dass die Ordnungsmigkeit des Archivierungsprozesses und damit die Rich-
tigkeit der archivierten Dokumente selbst angezweifelt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.81 Unzureichende Vernichtung von Datentrgern

Archivsysteme mit ihren Speichermedien bieten alleine fr sich in der Regel
keinen Zugriffsschutz auf die gespeicherten Daten. Diese Funktion wird statt-
dessen vom bergeordneten Dokumenten-Management-System (DMS) erfllt.
Sind Archivdatentrger auerhalb der Archivumgebung (Archivsystem und
DMS) zugnglich, ist davon auszugehen, dass jeder, der das Medium lesen
kann, auf die dort gespeicherten Informationen zugreifen kann.
Besonders wenn archivierte Daten auf neue Datentrger umkopiert werden, Missbrauch alter
Archivmedien
besteht ein erhebliches Risiko, dass alte, nicht mehr gebrauchte Archivmedien,
die nicht ordnungsgem und vollstndig zerstrt werden, zur Informations-
gewinnung missbraucht werden.
Auch bei verschlsselt archivierten Daten kann eine nicht ordnungsgeme einmalige Verschls-
selung schtzt nicht
Vernichtung von Datentrgern ein Problem darstellen, da die Sicherheit von dauerhaft
Kryptoalgorithmen immer nur zeitlich begrenzt garantiert werden kann (siehe
auch G 4.47 Veralten von Kryptoverfahren). Eine einmalige Verschlsselung
schtzt deshalb nicht dauerhaft vor Datenmissbrauch.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.82 Fehlerhafte Planung des Aufstellungsortes von

Archivsystemen
Aufgrund der Sensitivitt der gespeicherten Daten sowie der sehr langen Auf-
bewahrungszeit sind bei Archivsystemen erhebliche Anforderungen an die
Qualitt der Datenspeicherung zu stellen. Die Wahl des Aufstellungsortes fr
das Archivsystem hat hierauf hohen Einfluss.
In diesem Zusammenhang sind folgende potentielle Sicherheitsprobleme zu
beachten:
- Unzulngliche klimatische Bedingungen
Eine zu hohe oder zu niedrige Temperatur kann ebenso wie eine zu hohe
Luftfeuchtigkeit zu Fehlfunktionen in technischen Komponenten und zur
Beschdigung von Archivmedien fhren. Hufige Schwankungen der kli-
matischen Bedingungen verstrken diesen Effekt. Auch durch Sekundr-
schden knnen derartige Klimabelastungen hervorgerufen werden. Ein
Beispiel dafr ist die Ausdnstung von Wnden, die nach einem Brand im
Nachbarraum auftreten kann.
- Unzureichender physikalischer Schutz des Archivsystems
Durch unzureichenden Schutz des Archivsystems gegen unbefugten Zutritt
und Zugriff knnen vorstzliche Handlungen (z. B. Diebstahl, Manipula-
tion oder Sabotage) begnstigt werden.
- Unzureichender Schutz gegen sonstige Umgebungseinflsse
Auch durch sonstige Umgebungseinflsse (z. B. Erschtterungen oder eine
hohe Staubbelastung) knnen Schden an technischen Komponenten des
Archivsystems oder an Speichermedien hervorgerufen werden. Besonders
rgerlich ist das, wenn die schdigenden Einflsse sogar vorhersehbar
waren, wie z. B. bei Bauarbeiten.
Beispiel:
Durch Ansiedlung des zentralen IT-Bereichs nahe an Produktionsanlagen
kommt es dort gelegentlich zu Erschtterungen. Als Folge treten immer wie-
der Strungen in den technischen Komponenten des Archivsystems auf, das
ebenfalls im IT-Bereich betrieben wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.83 Fehlerhafte Outsourcing-Strategie

Die Entscheidung, ein Outsourcing-Vorhaben durchzufhren, ist eine weitrei-
chende Entscheidung. Durch diese begibt sich ein Unternehmen oder eine
Behrde in ein enges Abhngigkeitsverhltnis zu dem Outsourcing-
Dienstleister. Daher haben diesbezgliche Fehlentscheidungen langfristige
und schwerwiegende Folgen. Diese knnen organisatorische, technische und
auch gravierende finanzielle Auswirkungen sein.
Sicherheitsprobleme (z. B. bei mangelhafter Verfgbarkeit) beim Outsour-
cing-Dienstleister knnen nicht nur teuer, sondern auch existenzbedrohend
sein. Jedoch knnen auch Fehleinschtzungen der auslagernden Organisation
gravierende Folgen haben. Wird beispielsweise der Aufwand (z. B. Erstellung
von Dokumentationen, Tests, Absicherung von Systemen) unterschtzt, so
sind zeitliche Verzgerungen zu erwarten. Um verlorene Zeit einzuholen und
Geld zu sparen, wird erfahrungsgem hufig der Testaufwand reduziert, was
zu Abstrichen bei der Sicherheit fhren kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.84 Unzulngliche vertragliche Regelungen mit

einem externen Dienstleister
Wenn Situationen eintreten, die nicht eindeutig vertraglich geregelt sind, kn-
nen (z. B. im Rahmen eines Outsourcing-Vorhabens) Nachteile fr den Auf-
traggeber entstehen.
So kann beispielsweise ein Outsourcing-Auftraggeber fr Sicherheitsmngel
zur Verantwortung gezogen werden, die im Einflussbereich des Outsourcing-
Dienstleisters liegen, aber vertraglich nicht eindeutig geregelt sind.
Ein Hauptgrund fr Probleme zwischen den Vertragspartnern sind zu optimis-
tische Kostenschtzungen. Wenn sich herausstellt, dass der Outsourcing-
Dienstleister zu den kalkulierten und angebotenen Kosten die Dienstleistung
nicht erbringen kann oder Uneinigkeit darber besteht, was "selbstverstnd-
lich" ist, kann das direkt zu Sicherheitsproblemen fhren. Erfahrungsgem
wird an der IT-Sicherheit gespart, wenn in anderen Bereichen ein Kostendruck
entsteht, dem so begegnet werden kann, ohne dass Folgen unmittelbar sichtbar
werden. Der Ausgestaltung der vertraglichen Regelungen zwischen Auftrag-
geber und Auftragnehmer kommt daher eine entscheidende Bedeutung zu. Nur
was von Anfang an vertraglich fixiert ist, wird auch spter sicher in die Tat
umgesetzt!
Weitere Beispiele fr Folgen aus unzulnglichen vertraglichen Regelungen
mit externen Dienstleistern sind:
- Der Auftraggeber kann seiner Auskunftspflicht gegenber Aufsichtsbehr- Auskunftspflicht
den oder Wirtschaftsprfern nicht nachkommen, wenn der Dienstleister
keinen Zutritt zu seinen Rumlichkeiten oder keinen Zugang zu den not-
wendigen Unterlagen gewhrt.
- Der Auftraggeber muss sich fr Verste gegen geltende Gesetze verant- Gesetze
worten, wenn der Dienstleister nicht auf die Einhaltung dieser Gesetze ver-
pflichtet wurde.
- Aufgaben, Leistungsparameter und Aufwnde wurden ungengend oder Missverstndnisse
missverstndlich beschrieben, so dass aus Unkenntnis oder wegen fehlen-
der Ressourcen Sicherheitsmanahmen nicht umgesetzt werden.
- Der Auftraggeber kann neuen Anforderungen (z. B. fachlich, gesetzliche Anpassungen
Vorschriften, Verfgbarkeit, technische Entwicklung) nicht nachkommen,
wenn nderungsmanagement und Systemanpassungen nicht ausreichend
vertraglich geregelt wurden.
- Bei Outsourcing-Vorhaben ist die Behrden- bzw. Unternehmensleitung Verantwortung
des Auftraggebers unter Umstnden voll verantwortlich fr die ausgela-
gerten Geschftsbereiche, kann dieser Verantwortung aber wegen fehlen-
der Kontrollmglichkeiten nicht gerecht werden.
- Ausgelagerte Daten oder Systeme werden ungengend geschtzt, wenn ihr Schutzbedarf
Schutzbedarf dem Outsourcing-Dienstleister unbekannt ist.
- Die Dienstleistungsqualitt ist schlecht, und es gibt keine Sanktionen
Eingriffsmglichkeiten, weil keine Sanktionen vertraglich festgelegt wur-
den.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Dienstleister zieht qualifiziertes Personal ab oder Vertreter des Stamm- Personal
personals sind nicht ausreichend vorbereitet, was zu Sicherheitsproblemen
fhren kann.
Besondere Probleme treten hufig dann auf, wenn Dienstleistungsvertrge
beendet werden (siehe auch G 2.85 Unzureichende Regelungen fr das Ende
des Outsourcing-Vorhabens) und diese Situation nur unzureichend vertraglich
geregelt wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.85 Unzureichende Regelungen fr das Ende des

Outsourcing-Vorhabens
Wird ein Outsourcing-Vorhaben durchgefhrt, so kommt es in der Regel zu
Know-how-Verlust beim Auftraggeber und zu einer Abhngigkeit des Auf-
traggebers vom Outsourcing-Dienstleister. Daher knnen unzureichende Re-
gelungen fr eine mgliche Kndigung des Vertragsverhltnisses gravierende
Folgen fr den Auftraggeber haben. Dies ist erfahrungsgem immer dann
besonders problematisch, wenn ein aus Sicht des Auftraggebers kritischer Fall
unerwartet eintritt, wie beispielsweise Insolvenz oder Verkauf des Outsour-
cing-Dienstleisters.
Beispiele:
- Ein Konkurrent des Auftraggebers kauft den Outsourcing-Dienstleister.
- Eine nationale Sicherheitsbehrde hat Prozesse zu einem Rechenzentrum
ausgelagert, das spter von einem auslndischen Unternehmen gekauft
wird.
- Es gibt juristische Auseinandersetzungen zwischen Auftraggeber und Out-
sourcing-Dienstleister wegen schlechter Dienstleistungsqualitt oder gra-
vierender Sicherheitsmngel, in deren Folge ein Vertragspartner den Ver-
trag kndigen mchte.
Ohne ausreichende interne Vorsorge sowie genaue Vertragsregelungen besteht
immer die Gefahr, dass sich der Auftraggeber nur schwer aus dem abgeschlos-
senen Vertrag mit dem Outsourcing-Dienstleister lsen kann. In diesem Fall
ist es schwer bis unmglich, den ausgelagerten Bereich beispielsweise auf
einen anderen Dienstleister zu bertragen oder ihn wieder in das eigene Un-
ternehmen einzugliedern, falls dies geboten erscheint.
Im Folgenden sind beispielhaft weitere Probleme aufgelistet, die in dieser
Situation auftreten knnen:
- Durch unflexible Kndigungsrechtregelungen kann der Vertrag nicht im
Sinne des Auftraggebers bedarfsgerecht beendet werden.
- Zu kurze Kndigungszeiten fhren bei Kndigung durch den Dienstleister
dazu, dass keine Zeit fr einen geordneten bergang bleibt.
- Unzureichende Regelungen ber das Eigentumsrecht an eingesetzter Hard-
und Software (Schnittstellenprogramme, Tools, Batchablufe, Makros, Li-
zenzen, Backups) knnen einen geregelten bergang, beispielsweise auf
einen neuen Outsourcing-Dienstleister, verhindern.
- Unzureichende Regelungen ber das berlassen von Dokumentationen
knnen dazu fhren, dass die IT-Systeme nicht geregelt weiterbetrieben
werden.
- Unzureichende Regelungen fr das Lschen von Daten beim Outsourcing-
Dienstleister knnen dazu fhren, dass vertrauliche Daten Dritten bekannt
werden.
- Der Auftraggeber kann seine Aufgaben unter Umstnden nicht mehr erfl-
len, da die Verfgbarkeit nicht mehr gewhrleistet ist.
- In der Endphase des Auflsungsprozesses sind eventuell Daten und Sys-
teme nicht mehr ausreichend geschtzt, da diese als "Alt-Systeme" angese-
hen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.86 Abhngigkeit von einem Outsourcing-

Dienstleister
Durch ein Outsourcing-Vorhaben gert der Auftraggeber immer in die Ab-
hngigkeit vom Outsourcing-Dienstleister. Daraus ergeben sich folgende
typische Gefahren:
- Durch das Auslagern von Geschftsprozessen geht intern das ent- Know-how-Verlust
sprechende Know-how verloren.
- Mitarbeiter des Auftraggebers verlassen das Unternehmen oder werden
versetzt und nehmen ihr Know-how mit.
- IT-Systeme und Ressourcen werden dem Outsourcing-Dienstleister ber- Kontrollverlust
lassen, so dass ber diese keine vollstndige Kontrolle mehr besteht.
- Auftraggeber und Auftragnehmer schtzen den Schutzbedarf der ausge-
lagerten Informationen unterschiedlich ein, beispielsweise aufgrund von
Missverstndnissen in der Kommunikation oder einer anderen Sicherheits-
kultur. Damit knnen dann die ergriffenen Sicherheitsmanahmen unzu-
reichend oder falsch gelagert sein.
Aus einer zu groen Abhngigkeit knnen sich auerdem folgende Konse-
quenzen ergeben, die es zu bedenken gilt:
- Insourcing ist im Allgemeinen teuer und im Extremfall sogar unmglich. Probleme bei Wechsel
des Dienstleister
- Ein Wechsel des Dienstleisters ist im Allgemeinen schwierig und kann zu
existenzbedrohenden Situationen (Verfgbarkeit, Kosten) fhren.
- Auf Vernderung der Rahmenbedingungen (z. B. Eigentmerwechsel beim
Outsourcing-Dienstleister, nderung der Gesetzeslage, Zweifel an der Zu-
verlssigkeit des Outsourcing-Dienstleisters) kann unter Umstnden nicht
angemessen reagiert werden.
Erkennt der Outsourcing-Dienstleister eine groe Abhngigkeit des Auftrag-
gebers, so knnen sich zudem auch folgende Probleme ergeben:
- Der Dienstleister fhrt drastische Preiserhhungen durch.
- Es kommt zu schlechter Dienstleistungsqualitt.
- Die Drohung, die Dienstleistung sofort einzustellen, wird als Druckmittel
(z. B. bei Kndigung des Vertrages oder bei Streitigkeiten) benutzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.87 Verwendung unsicherer Protokolle in

ffentlichen Netzen
Bei der Kommunikation ber ffentliche Netze, insbesondere das Internet,
exisitiert eine Reihe von Gefahren, die aus der Verwendung unsicherer
Protokolle entstehen.
Eine wichtige Gefahr ist, dass vertrauliche Informationen in fremde Hnde Vertraulichkeitsverlust
bertragener Daten bei
gelangen knnen. Als unsichere Protokolle mssen insbesondere solche Klartextprotokollen
Protokolle gelten, bei denen Informationen im Klartext bertragen werden. Da
der Weg der Datenpakete im Internet nicht vorhersagbar ist, knnen in diesem
Fall die bertragenen Informationen an verschiedensten Stellen mitgelesen
werden. Besonders kritisch ist dies, wenn es sich um
- Authentisierungsdaten wie Benutzernamen und Passwrter,
- Autorisierungsdaten, beispielsweise Transaktionsnummern beim Electronic
Banking oder Electronic Brokerage,
- andere vertrauliche Informationen, beispielsweise in Dokumenten, die per Telnet, http, ftp, SMTP
usw.
E-Mail verschickt werden,handelt. Protokolle, bei denen smtliche
Informationen im Klartext bertragen werden, sind beispielsweise
- das Hypertext Transfer Protocol http, das bei der Kommunikation zwischen
Webbrowsern und Webservern verwendet wird,
- das telnet Protokoll, das noch an einigen Stellen fr Remote Logins
verwendet wird,
- das File Transfer Protocol ftp, das noch hufig fr den Zugriff auf Server
benutzt wird, die Dateien zum Download bereitstellen,
- das Simple Mail Transfer Protocol smtp, das zur bertragung von E-Mail
verwendet wird,
- die Protokolle rsh (Remote Shell), rlogin (Remote Login) und andere
verwandte Protokolle.
Bei solchen Protokollen knnen smtliche bertragenen Informationen auf
jedem Rechner, ber den eine entsprechende Verbindung luft, mitgelesen und
gegebenenfalls auch verndert werden. Kritisch ist beispielsweise die
bertragung von Kreditkartennummern oder Passwrtern ber http-
Verbindungen im WWW.
Mittels Password-Sniffings knnen in einem ersten Schritt Passwrter bei der
bertragung zu einem System abgefangen werden. Dies erlaubt dem
Angreifer anschlieend auf dieses IT-System zu gelangen, um dann weitere
Angriffe lokal auf dem Rechner durchzufhren.
Bei den erwhnten Protokollen (besonders bei http oder telnet) drohen auch Man-in-the-middle
Angriffe und Session
sogenannte Man-in-the-middle-Angriffe oder Session Hijacking (siehe G 5.89 Hijacking
Hijacking von Netz-Verbindungen). Bei dieser Art von Angriffen ist ein
Angreifer nicht nur dazu in der Lage, Informationen mitzulesen, sondern kann
darber hinaus aktiv Schaden anrichten, indem laufende Transaktionen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
verndert werden. Beispielsweise knnen Preise oder Bestellmengen bei

Geschften ber das Internet so verndert werden, dass der Besteller nur die
Artikel oder Lieferadresse sieht und besttigt bekommt, die er eingibt,
whrend der Angreifer eine wesentlich hhere Menge und eine andere
Lieferadresse an den Verkufer schickt.
Neben den erwhnten Protokollen, bei denen smtliche Informationen im
Klartext bertragen werden, existieren auch solche, bei denen zumindest die
bertragung der Authentisierungsdaten verschlsselt erfolgt. Dabei droht
jedoch immer noch das Mitlesen der bertragenen Nutzinformation.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.88 Strung des Betriebsklimas durch ein

Outsourcing-Vorhaben
Outsourcing-Vorhaben haben je nach Art und Umfang nicht nur Auswirkun-
gen auf die Geschftsprozesse, sondern auch auf das Personal innerhalb eines
Unternehmens oder einer Behrde. Dabei sind neben den vom Auftraggeber
erwarteten Positiveffekten aus Sicht der Arbeitnehmer jedoch auch negative
Effekte mglich. Beispiele dafr sind:
- Im Outsourcing-Bereich kann es zu einem Stellenabbau und damit verbun-
den zu Versetzungen oder Kndigungen von Mitarbeitern kommen.
- Durch die Auslagerung von Geschftsvorfllen werden gewohnte
Arbeitsprozesse gendert.
- Vor, whrend oder nach der Einfhrung eines Outsourcing-Vorhabens
kann es zu hohen Arbeitsbelastungen kommen.
- Durch die Zusammenarbeit mit Mitarbeitern eines Outsourcing-
Dienstleisters oder externen Beratern kann es erforderlich sein, dass ein-
zelne Mitarbeiter Kompetenzen und Zustndigkeiten abgeben mssen. Ge-
nauso kann sich aber auch ergeben, dass Mitarbeiter neue Zustndigkeiten
bernehmen mssen und sich dadurch berfordert fhlen.
- Durch Umstrukturierungen im Zusammenhang mit einem Outsourcing-
Vorhaben kann es auch dazu kommen, dass Mitarbeiter den Arbeitgeber
wechseln mssen (z. B. bergang zu einer Tochterfirma oder bernahme
durch den Outsourcing-Dienstleister). Dabei kann der Mitarbeiter auch
dazu gezwungen sein, schlechtere Bedingungen zu akzeptieren oder dies
zumindest so empfinden.
Durch diese oder hnlich Vernderungen kann das Betriebsklima nachhaltig
gestrt werden. Mgliche Gefhrdungspotenziale sind unter anderem:
- Mitarbeiter oder ehemalige Mitarbeiter knnen Racheakte verben. vorstzliche Handlungen
- Die Mitarbeiter sind schlecht motiviert und vernachlssigen unabsichtlich Pflichtverletzung

oder mutwillig Pflichten, insbesondere Sicherheitsmanahmen.
- Know-how-Trger (wie beispielsweise IT-Leiter und Administratoren) Know-how-Verlust
knnen whrend der Einfhrungsphase kndigen. In Folge knnte dadurch
das Outsourcing-Vorhaben nicht bedarfsgerecht oder gar nicht umgesetzt
werden, was wiederum existenzbedrohend sein kann. Oftmals ist der Out-
sourcing-Dienstleister sogar darauf angewiesen, dass die entscheidenden
Know-how-Trger geordnet zu ihm wechseln.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.89 Mangelhafte IT-Sicherheit in der Outsourcing-

Einfhrungsphase
Ein Outsourcing-Vorhaben wird in der Regel in mehreren Schritten umgesetzt.
Die Einfhrungsphase geht meist mit drastischen internen Vernderungen auf
Seiten des Auftraggebers einher. Zustzlich wird ein Outsourcing-Vorhaben
von stringenten terminlichen und finanziellen Randbedingungen begleitet. Oft
bleibt keine Zeit fr regelmige Sicherheitskontrollen und Audits. Um
Termine und Budgets whrend der Einfhrungsphase einzuhalten, leidet oft-
mals die Arbeitsqualitt und Sicherheitskonzepte werden vernachlssigt. Dies
hat jedoch gravierenden Einfluss auf die IT-Sicherheit. Mgliche weitere Ge-
fhrdungen der IT-Sicherheit sind unter anderem:
- Der Betrieb von bergangslsungen erfolgt unter geringen Sicherheits- Nichts hlt lnger als
Zwischenlsungen!
standards. Dabei wird hufig argumentiert: "Hauptsache, es luft!" Oft
werden solche bergangslsungen dann jedoch aus verschiedenen
Grnden auf Jahre hin weiterbetrieben.
- Aus Zeit- und Ressourcengrnden werden "Altsysteme" vernachlssigt,
whrend an den neuen Systemen gearbeitet wird.
Ausgelst durch die hohe Arbeitsbelastung und den Zeitdruck werden die
Probleme durch bewusste oder unbewusste Nachlssigkeiten oder Fehler ver-
strkt. Grnde knnen sein:
- Whrend der Einfhrungsphase muss ein Parallelbetrieb der von der Aus-
lagerung betroffenen Systeme erfolgen.
- Durch die Anbindung an den Outsourcing-Dienstleister entstehen viele
neue organisatorische und technische Schnittstellen.
- Mitarbeiter mssen in neue Aufgaben eingearbeitet werden, so dass zustz-
lich Ressourcen gebunden sind.
- Ein Outsourcing-Vorhaben geht einher mit dem Einsatz neuer Soft- und
Hardware. Gefahren resultieren dabei aus fehlerhaften oder gnzlich
fehlenden Tests, aus Unerfahrenheit mit neuen Sicherheitsmechanismen,
aus Installations- und Administrationsfehlern oder aber aus Software-
fehlern.
IT-Sicherheitsmngel knnen sich jedoch auch aus organisatorischen
Schwchen whrend der Einfhrungsphase ergeben. Die Grnde knnen bei-
spielsweise folgende sein:
- Die Zusammenarbeit zwischen den Mitarbeitern des Auftraggebers und Anlaufschwierigkeiten
bei der Kommunikation
denen des Outsourcing-Dienstleister oder externer Berater funktioniert
nicht richtig. Ursachen knnen etwa Kommunikationsprobleme technischer
oder persnlicher Art sein. Da am Anfang auch die Ansprechpartner der
Gegenseite noch unbekannt sind, knnen in dieser Phase auerdem An-
griffe ber "Social Engineering" besonders leicht erfolgreich sein.
- Entscheidungshierarchien funktionieren noch nicht oder Ansprechpartner
und Zustndigkeiten sind noch nicht geklrt oder wechseln hufig. Als
Folge werden Entscheidungen gar nicht oder nur sehr zgerlich getroffen.
Das fhrt dann unter Umstnden dazu, dass Sicherheitsvorschriften nicht
eingehalten, umgangen oder nicht kontrolliert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese Gesamtproblematik fhrte beispielsweise auch fr ein namhaftes

Finanzinstitut zu Problemen: Whrend an der Einrichtung eines neuen Web-
servers gearbeitet wurde, wurde das "Altsystem" nicht mehr ausreichend ge-
wartet und war Ziel eines Angriffes, bei dem Kundendaten kompromittiert
wurden. Das Ereignis wurde durch die Medien einem Millionenpublikum be-
kannt gemacht.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.90 Schwachstellen bei der Anbindung an einen

Outsourcing-Dienstleister
Die Durchfhrung eines Outsourcing-Vorhabens verlangt in aller Regel den
Zugriff des Dienstleisters auf interne Ressourcen des Auftraggebers. Dies wird
hufig durch eine gegenseitige Anbindung von Teilen der jeweiligen IT-Infra-
struktur realisiert. Zum beschleunigten Informationsaustausch zwischen Auf-
traggeber und Auftragnehmer werden mglicherweise spezielle Informations-
kanle (z. B. dedizierte Standleitungen, VPN-Verbindungen, Zugnge fr die
Remote-Wartung) eingerichtet.
Ist diese Anbindung nicht gesichert oder treten bei der Absicherung Schwach-
stellen auf, so ergeben sich zwangslufig eine Reihe von Gefhrdungen:
- Die Vertraulichkeit der Kommunikation kann gefhrdet sein.
- Die Integritt von bermittelten Datenstzen ist nicht mehr garantiert.
- Der Empfang von bermittelten Informationen und Nachrichten knnte
abgestritten werden.
- Es wird Externen ein fr die tatschlichen Bedrfnisse des Dienstleisters zu
umfassender Einblick in Interna des Auftraggebers gegeben.
- Es entstehen zustzliche Zugangsmglichkeiten fr Auenstehende zum
Intranet der Organisation und damit Gefahrenquellen.
- Bei offenen oder schlecht gesicherten IT-Zugngen ergeben sich
Manipulationsmglichkeiten.
- Es knnten vertrauliche Informationen und geistiges Eigentum an
Auenstehende weitergegeben werden.
- Externe Systemzugriffe werden unter Umstnden nicht ausreichend
kontrolliert.
Die IT-Anbindung zwischen auslagernder Organisation und Outsourcing-
Dienstleister kann auch komplett ausfallen. Dabei knnen Daten, deren ber-
tragung vor dem Ausfall noch nicht vollstndig abgeschlossen war, zerstrt
oder inkonsistent werden. In Abhngigkeit von der Dauer und Art des Aus-
falles knnen die Konsequenzen auch existenzbedrohend sein. Diese Gefahr
wird verstrkt, wenn kein Notfallvorsorgekonzept (siehe auch G 2.93 Unzu-
reichendes Notfallvorsorgekonzept beim Outsourcing) existiert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.91 Fehlerhafte Planung der Migration von

Exchange 5.5 nach Exchange 2000
Hufiger als eine Neuinstallation eines Exchange 2000 E-Mail-Systems ist in
der Praxis die Migration einer bestehenden Exchange 5.5 Installation nach
Exchange 2000. In vielen Fllen ist diese Umstellung verbunden mit einem
Betriebssystemwechsel von Windows NT nach Windows 2000. Fr den
Betrieb eines Exchange 2000 Servers ist dieser Betriebssystemwechsel sogar
Voraussetzung.
Mit dem Betriebssystemwechsel ist auch eine Umstellung des NT-Domnen-
konzeptes auf den Verzeichnisdienst Active Directory von Windows 2000
erforderlich. Dies ist eine planerische und organisatorische Herausforderung,
die speziell aus Sicherheitssicht eine sorgfltige Einarbeitung und eine grund-
legende Neuplanung verlangt (siehe M 2.249 Planung der Migration von
"Exchange 5.5-Servern" nach "Exchange 2000").
Folgende Sicherheitsprobleme knnen bei einer fehlerhaften Planung der
Migration auftreten:
- Die Konfigurationen einer NT-Domne knnte falsch oder inkonsistent in Domnen
das Active Directory von Windows 2000 abgebildet werden, da dies eine
vollstndige Neukonzeption der bisherigen Infrastruktur umfasst. Weiter-
hin knnte eine fehlerhafte Anbindung an das Active Directory zur Folge
haben, dass die Systemrichtlinien von Windows 2000 und die Access
Control Lists (ACL) nicht wirksam sind.
- Eine oder mehrere Exchange 5.5 Site(s) knnten unzulnglich auf eine Sites
Exchange 2000 Routing Group abgebildet werden, da dies unter Um-
stnden eine Umstrukturierung der Exchange-Server bedeutet. Die Gefahr
besteht hier in erster Linie in einem Funktionsausfall durch fehlerhafte
Protokolleinstellungen oder sonstige Fehlkonfigurationen.
- Unter Umstnden wird die Administration des Systems unsachgem ge- Rollen und Gruppen
plant und die Administrationsgrenzen unklar definiert, da sich die Admi-
nistrationsgrenzen durch Einfhrung der Administrationsgruppen in
Exchange 2000 im Vergleich zu Exchange 5.5 ndern knnen. Die Admi-
nistratorrolle unter Exchange 5.5 existiert in Exchange 2000 nicht mehr
und es mssen entsprechende Domnenbenutzer konfiguriert werden. Wird
fr diese Benutzergruppe die Rechtevergabe falsch geplant, so kann dies zu
Sicherheitslcken oder auch zur Behinderung der Administration des
Systems fhren.
- Die geforderten organisationsweiten Sicherheitsrichtlinien knnten durch Richtlinien
eine falsche Planung der Migration der Sicherheitseinstellungen unge-
ngend umgesetzt werden. Dies betrifft sowohl die Zugriffsmglichkeiten
auf den Server an sich als auch auf die dort gespeicherten Daten.
- Daten und Informationen knnten bei der Migration verloren gehen, beson- Datenverlust
ders wenn das System whrend der Migrationsphase abstrzt.
- Durch notwendige Nachbesserungen der Konfiguration an den Produktiv- Ausfall
systemen knnte sich ein Produktivittsausfall ergeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.92 Fehlerhafte Regelungen fr den Browser-Zugriff

auf Exchange
Exchange 2000 bietet - wie auch schon Exchange 5.5 - die Mglichkeit, ber WebDAV
einen Browser auf das eigene E-Mail-Konto zuzugreifen. Neu in
Exchange 2000 ist dabei die Untersttzung des WebDAV-Protokolls, das auf
dem Protokoll HTTP aufsetzt. Dadurch kann auf das Installable File System
(IFS) zugegriffen werden und damit wird die Funktionalitt des Web Store
und der Web Forms untersttzt. Hierzu werden die Internet Information
Services (IIS) verwendet, die fester Bestandteil der Installation von Exchange
2000 Server sind.
Grundstzlich besteht die Gefahr, dass es bei unsachgemer Planung und
fehlerhaften Regelungen fr diese Funktionalitt mglich wird, unkontrolliert
von auen auf das interne Netz zuzugreifen.
Fehlkonfigurationen betreffen in erster Linie die Authentisierung des Web- schwache
Authentisierung und
clients gegenber dem Exchange 2000 Server sowie die geschtzte ber- Verschlsselung
tragung der Informationen ber das IP-Netz. Sind die geforderten Authentisie-
rungsmethoden zu schwach, so knnen unter Umstnden Unbefugte auf E-
Mail-Daten und Systemressourcen zugreifen. Sind die eingesetzten Verschls-
selungsmechanismen nicht hinreichend stark, so besteht die Gefahr, dass
Daten abgehrt werden. Bei nicht ausreichenden Authentisierungs- und Ver-
schlsselungsmechanismen knnen bestehende Verbindungen unter Um-
stnden durch unbefugte Dritte bernommen werden. Weiterhin besteht die
Gefahr, dass ber den OWA-Kanal Viren oder anderer schdlicher Code auf
den E-Mail-Server gelangen.
Das Gefahrenpotential ist darber hinaus vielfltig. Beispiele fr weitere
mgliche Folgen sind:
- E-Mail-Adressen knnten ausgespht werden.
- Unbefugte knnten Zugriff auf E-Mail-Funktionen erlangen.
- Spam-Attacken knnten ermglicht werden.
- Unbefugte knnten interne Informationen ber das Unternehmen bzw. die
Behrde erlangen.
- Es knnten sich direkte Angriffsmglichkeiten auf das interne Netz
ergeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.93 Unzureichendes Notfallvorsorgekonzept beim

Outsourcing
Versumnisse im Bereich der Notfallvorsorge haben beim Outsourcing schnell
gravierende Folgen. Zustzliche Schwierigkeiten ergeben sich dadurch, dass
Probleme generell auf drei kritische Bereiche verteilt sein knnen. Es sind
dies:
1. IT-Systeme beim Auftraggeber unterschiedliche Zu-
stndigkeiten
2. IT-Systeme beim Outsourcing-Dienstleister
3. Schnittstellen (z. B. Netzverbindung, Router, Telekommunikations-Provi-
der) zwischen Auftraggeber und Dienstleister
Im Falle eines Fehlers muss dieser zunchst korrekt lokalisiert werden, was je
nach Fehlerart schwierig ist, da unterschiedliche Fehler zu gleichen Sympto-
men fhren knnen, z. B. Ausfall der Kommunikationsverbindung und Ausfall
eines Systems beim Dienstleister. Erst nachdem der Fehler identifiziert wor-
den ist, knnen sinnvolle Notfallmanahmen eingeleitet werden.
Versumnisse bei den Notfallvorsorgekonzepten fr die IT-Systeme von Auf-
traggeber bzw. Dienstleister sowie der Schnittstellen fhren im Falle eines
Teil- oder Totalausfalls immer zu unntig langen Ausfallzeiten mit entspre-
chenden Folgen fr die Produktivitt bzw. Dienstleistung des Auftraggebers.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.94 Unzureichende Planung des IIS-Einsatzes

Der IIS bietet vielfltige Einsatzmglichkeiten, z. B. als einfacher Informa-
tionsserver im Intranet. Auch als Basis fr komplexe Webanwendungen im
Internet ist der IIS geeignet. Aus diesen Einsatzumgebungen resultieren unter-
schiedliche Anforderungen an die Sicherheit des IIS. Die Absicherung eines
aus dem Internet erreichbaren Servers ist in der Regel mit einem viel hheren
Aufwand verbunden als die Absicherung eines Servers im LAN, auf den nur
vertrauenswrdige Benutzer zugreifen.
Erfolgt vor der Installation keine ausreichende Planung, z. B. in welche Sys-
temumgebung der Server einzubinden ist, welche Protokolle verwendet wer-
den und wie der Zugriff (Authentisierung) geregelt wird, besteht die Gefahr,
dass bestehende Risiken nicht bercksichtigt werden.
Die Verfgbarkeit und Performance sind fr den Erfolg eines Internet-Ange-
bots von entscheidender Bedeutung. Lange Wartezeiten werden von keinem
Anwender auf Dauer akzeptiert, deshalb muss ein Internet-Server stndig
verfgbar und seine Reaktionszeit mglichst kurz sein. Bei unzureichender
Ressourcenplanung, die Netzkapazitten und Systemressourcen bercksichti-
gen muss, kann die Akzeptanz der Benutzer fr eine Web-Seite sinken.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.95 Fehlendes Konzept zur Anbindung anderer E-

Mail-Systeme an Exchange/Outlook
Gegebene IT-Landschaften sind meist heterogen, sowohl in Bezug auf die
verwendeten Betriebssysteme als auch in Bezug auf die Anwendungen. Dies
spiegelt hufig die Historie des Wachsens und Zusammenwachsens der Orga-
nisationsstruktur im Unternehmen bzw. in der Behrde wider.
Exchange 2000 ist eng mit dem Betriebssystem Windows 2000 verzahnt und Connectors
harmoniert nur mhsam mit Fremdsystemen. Zur Interaktion mit anderen E-
Mail-Systemen bietet Exchange 2000 sogenannte Connectors an, mit denen
sich das Exchange-System mit Fremdsystemen verbinden lsst.
Aus Sicherheitssicht besteht die Gefahr, dass unter Windows 2000 getroffene
Sicherheitseinstellungen, die sich auf das Exchange 2000 E-Mail-System
beziehen, auerhalb des homogenen Microsoft-Umfeldes keine Gltigkeit
haben.
Ebenso besteht natrlich auch umgekehrt die Gefahr, dass die festgelegten Inkonsistenzen
Sicherheitsrichtlinien der Fremdsysteme keine Gltigkeit fr das Exchange
2000 System haben. Bei der separaten Administration verschiedener Teil-
systeme knnen stets Inkonsistenzen auftreten.
Eine unsachgeme Anbindung fremder E-Mail-Systeme kann zudem den
Verlust von Daten oder eine Blockade des Systems zur Folge haben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.96 Veraltete oder falsche Informationen in einem

Webangebot
Die Korrektheit und Aktualitt der Informationen, die eine Organisation in
einem Webangebot verffentlicht, hat nicht nur Einfluss auf den Erfolg des
Webangebots alleine. Werden im WWW falsche Informationen verffentlicht,
so kann das Ansehen der Organisation in der ffentlichkeit empfindlichen
Schaden nehmen.
In manchen Fllen drohen auch finanzielle Verluste oder rechtliche Konse-
quenzen (beispielsweise Abmahnungen), wenn falsche Informationen verf-
fentlicht werden. Noch schlimmer knnen die Auswirkungen sein, wenn irr-
tmlich interne (vertrauliche oder gar geheime) Informationen auf den Web-
server gelangen, die eigentlich gar nicht verffentlicht werden drften.
Selbst dann, wenn bestimmte Informationen auf dem Webserver nur veraltet
sind, kann dies nachteilige Auswirkungen haben. Wenn beispielsweise veral-
tete Kontaktinformationen verffentlicht werden, kann dies zu einer Strung
der betroffenen Geschftsprozesse fhren.
Beispiel:
Im Jahr 2002 fanden Reporter auf dem Webserver eines schwedischen
Unternehmens eine Datei mit einem Quartalsbericht dieses Unternehmens,
der erst einige Tage spter htte verffentlicht werden sollen. Dies fhrte
unter anderem zu zeitweiligen Kursverlusten der Aktien des Unterneh-
mens.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.97 Unzureichende Notfallplanung bei einem

Apache-Webserver
Eine unzureichende Planung fr Notflle kann Probleme, die beim Betrieb
eines Apache-Webservers auftreten, wesentlich verschlimmern und Ausfall-
zeiten verlngern.
Zustzlich zu allgemeinen Fehlern, die oft im Bereich Notfallvorsorge ge-
macht werden, knnen bei einem Apache-Webserver einige spezielle Fehler
passieren, die eine schnelle Reaktion auf Zwischenflle sehr erschweren oder
gar unmglich machen knnen. Einige dieser Fehler werden im folgenden
beschrieben.
- Wird nach einem Notfall (etwa einem Hackereinbruch) eine Neuinstalla- Nicht vorhandene In-
stallationspakete
tion eines Apache-Webservers ntig, so kann es zu erheblichen Verzge-
rungen fhren, wenn die bei der Installation verwendeten Pakete (Quell-
texte oder Distributionspakete) nicht mehr verfgbar sind. Sind die Instal-
lationspakete zwar verfgbar, aber beispielsweise auf dem Webserverrech-
ner selbst und nicht auf einem anderen Rechner oder einem schreibge-
schtzten Datentrger gespeichert, so mssen sie nach einem Hackerein-
bruch als unsicher angesehen werden.
- Ist nicht bekannt, mit welchen Kompilierungs- und Installationsoptionen Nicht dokumentierte
Installationsoptionen
der Apache-Webserver installiert wurde, so kann es sehr schwierig sein, und -prozeduren
wieder eine funktionell gleichwertige Installation herzustellen. Dies gilt
besonders dann, wenn beispielsweise externe Module bei der bersetzung
eingebunden wurden.
- Existiert keine oder nur eine unzureichende Dokumentation der Konfigura- Undokumentierte oder
schlecht dokumentierte
tion, so kann es sehr schwierig sein, nach einem Notfall berhaupt wieder Konfiguration
eine funktionierende Konfiguration herzustellen. Schlechte Dokumentation
kann auch dazu fhren, dass Konfigurationsfehler zunchst nicht entdeckt
werden und bei auftretenden Problemen eine aufwendige Fehlersuche er-
forderlich wird.
- Bei der Systemwiederherstellung nach einem Notfall kann es wnschens- Fehlende Versionsver-
waltung fr Konfigurati-
wert sein, einen lteren Stand der Konfiguration wieder herzustellen. Wird onsdateien
fr die Konfigurationsdateien (insbesondere die Datei httpd.conf) keine
Versionsverwaltung durchgefhrt, so kann dies schwierig oder gar unmg-
lich sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.98 Fehlerhafte Planung und Konzeption des

Einsatzes von Routern und Switches
Bei der Planung des Einsatzes aktiver Netzkomponenten stehen meistens die
Aspekte Funktionalitt und Leistungsfhigkeit im Vordergrund. Wenn der
Betrieb von Routern und Switches, die als zentrale Elemente in Netzen
fungieren, aber nicht in das unternehmensweite Sicherheitskonzept
eingebunden wird, kann der sichere Einsatz dieser Komponenten nicht
sichergestellt werden.
Die Fehler bei der Planung des Einsatzes von Routern und Switches fallen
meist in eine der folgenden Kategorien:
Unzureichende Bercksichtigung des Einsatzzwecks der Gerte
Bei der Planung des Einsatzes von Routern und Switches ist in erster Linie der
Einsatzzweck dieser Komponenten entscheidend. Oft wird der Einsatzzweck
der Komponenten bei der Planung nicht ausreichend bercksichtigt,
beispielsweise beim Einsatz von VLANs. Entgegen fters gehrter
Werbeaussagen wurden VLANs nicht entwickelt, um
Sicherheitsanforderungen bei der Trennung von Netzen zu erfllen. VLANs
bieten eine Vielzahl von Angriffspunkten, so dass insbesondere fr die
Trennung von schutzbedrftigen Netzen immer zustzliche Manahmen
umzusetzen sind.
Auch bei der Planung des Einsatzes von Routing-Protokollen knnen Fehler
gemacht werden. Wenn Router im Bereich von demilitarisierten Zonen
(DMZs) eingesetzt werden kann die Verwendung von dynamischen Routing-
Protokollen die Verfgbarkeit, Vertraulichkeit und die Integritt des zu
schtzenden Netzes gefhrden.
Unzureichende Bercksichtigung von Sicherheitsmechanismen
Bei der Planung werden oft die vorhandenen Sicherheitsmechanismen (sowohl
im bestehenden Netz als auch bei den Netzkomponenten, deren Einsatz
geplant wird) nicht ausreichend bercksichtigt. Beispielsweise knnen
zustzliche Manahmen erforderlich werden, falls ein Gert bestimmte
Sicherheitsmechanismen nicht untersttzt. Wenn dies nicht bereits in der
Planungsphase bercksichtigt wird, kann es spter zu Problemen fhren, wenn
die Notwendigkeit erkannt wird.
Ein wichtiger Punkt, der beispielsweise bei der Planung oft nicht
bercksichtigt wird, ist die Einrichtung eines gesonderten
Administrationsnetzes (Out-of-Band Management). Falls die gewhlten oder
vorhandenen Gerte nur unsichere Protokolle wie SNMPv1, SNMPv2 oder
Telnet untersttzen, so ist die Einrichtung eines Administrationsnetzes
unbedingt erforderlich. Dies wird in vielen Fllen nicht beachtet, mit der
Folge, dass spter unter Umstnden die Einrichtung des Administrationsnetzes
auf Schwierigkeiten stt, weil die notwendigen Anschlsse nicht vorhanden
sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fehlende oder mangelhafte Information und Dokumentation

Gelegentlich sind in der Planungsphase notwendige Informationen nicht
vorhanden, da entweder keine entsprechende Dokumentation vom Anbieter
zur Verfgung gestellt wurde oder die betreffenden Dokumente nicht
bercksichtigt werden. Fehlentscheidungen, die auf Grund mangelhafter
Dokumentation gemacht wurden, sind oft nur schwer zu korrigieren, wenn
sich beispielsweise spter herausstellt, dass ein Gert bestimmte Funktionen
nicht oder nur unzureichend untersttzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.99 Unzureichende oder fehlerhafte Konfiguration

der zSeries-Systemumgebung
Das Ressourcenangebot der zSeries-Architektur gestattet den Betrieb mehrerer
Produktions- und Testsysteme auf einem physischen Rechner. Daraus
resultiert ein hohes Gefahrenpotential, weil eine fehlerhafte Abgrenzung der
zSeries-Systemumgebungen unter Umstnden den ungewollten Zugriff auf
fremde Ressourcen ermglicht.
Shared DASD (Direct Access Storage Device)
- Im LPAR-Betrieb ist es mglich, die Platten eines z/OS-Betriebssystems so
zu konfigurieren, dass sie durch alle z/OS-Systeme des Rechners
verwendet werden knnen (durch Konfiguration entsprechender
Subchannel-Adressen ber den Host Configuration Definition Prozess).
Damit verbunden ist die Gefahr, dass die Datentrennung zwischen den
LPARs nicht mehr gewhrleistet ist.
- Es ist mglich, Platten einer LPAR1 an einer anderen LPAR2 Online zu
setzen. Die Daten der neuen Platte stehen dann an der LPAR2 zur
Verfgung und knnen entsprechend den RACF-Definitionen dieser
LPAR2 bearbeitet werden. Sind die RACF-Definitionen der LPAR2
schwcher als die der LPAR1, knnen die Daten unter Umstnden
unbefugt manipuliert oder gelesen werden.
Unsachgeme Trennung Test-Produktion
Sicherheitsprobleme knnen auch durch eine unsachgeme Trennung von
Test- und Produktionsumgebungen entstehen. Werden Test und Produktion
auf unterschiedlichen LPARs (noch besser unterschiedlichen zSeries
Systemen) betrieben, ist die Abgrenzung leichter zu realisieren. Der Betrieb
von Test und Produktion auf der gleichen LPAR ist prinzipiell mglich (hier
sollte auf jeden Fall die Gefhrdung G 3.70 Unzureichender Dateischutz des
z/OS-Systems beachtet werden), jedoch ist die Trennung hierbei ungleich
schwieriger. Werden die Umgebungen nicht richtig voneinander abgegrenzt,
so ist es mglich, dass Testdaten in die Produktion gelangen bzw.
Produktionsdaten zum Testen verwendet werden. Beides beinhaltet ein hohes
Gefahrenpotential.
Beispiel:
Ein Outsourcing-Dienstleister betrieb in seinem Rechenzentrum die
Anwendungen von zwei konkurrierenden Unternehmen aus dem Bereich
der Automobilindustrie auf dem gleichen z/OS-System. Aufgrund einer
unsicheren Konfiguration war es dem Kunden B mglich, Platten des
Kunden A online zu nehmen. Kunde B nutzte dies aus, um sich durch
Aussphen der Daten Wettbewerbsvorteile gegenber dem Kunden A zu
verschaffen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.100 Fehler bei der Beantragung und Verwaltung von

Internet-Domainnamen
Internet-Domainnamen (meist einfach kurz "Domains" genannt) knnen nicht
beliebig gewhlt werden, sondern mssen bei Registrierungsstellen
(Registrars) angemeldet werden. Eine Registrierungsstelle kann Namen fr
eine oder mehrere sogenannte "Top-Level-Domains" vergeben (beispielsweise
verwaltet die DeNIC GmbH die Top-Level-Domain .de). Domains werden
nicht "gekauft", sondern nur jeweils fr einen bestimmten Zeitraum registriert.
Ist dieser Zeitraum abgelaufen, so muss die Registrierung gegen Zahlung einer
Gebhr verlngert werden. Im Zusammenhang mit der Registrierung und dem
Verlngern der Registrierung von Domainnamen werden hufig Fehler
gemacht, die gegebenenfalls erhebliche Kosten und einen Ansehensverlust der
Institution zur Folge haben knnen. Einige dieser Fehler werden im folgenden
kurz erlutert:
Nichtbercksichtigung "verwandter" Domainnamen
Oft wird nur der "richtige" Domainname, den die Organisation wirklich
benutzen mchte (etwa firmenname.de), registriert. Dabei wird bersehen,
dass "verwandte" Domainnamen (bspw. firmenname.com oder
firmenname.info) von Internetbenutzern, welche die "richtige" Domain der
Firma noch nicht kennen, einfach ausprobiert werden.
Es kommt hufig vor, dass "verwandte" Domainnamen von unserisen Domain-Grabber
Anbietern registriert werden, die unter dem Namen dann beispielsweise
Websites mit pornographischen Inhalten betreiben. Zwar knnen solche
Angebote oft gerichtlich untersagt und abgeschaltet werden, da aber ein
solcher Prozess oft lngere Zeit dauert, kann inzwischen das Ansehen der
Organisation betrchtlichen Schaden nehmen.
Beispielsweise musste eine deutsche Universitt im Jahr 2000 gerichtlich
gegen einen Pornoanbieter vorgehen, der den "com-Domainnamen" der
Universitt benutzte. Im Jahr 2004 gelang es einem Jugendlichen, sich durch
Ausnutzung eines "Verfahrensfehlers" fr kurze Zeit die deutsche Domain
eines Online-Auktionshauses bertragen zu lassen, was fr ziemliches
Aufsehen in der Presse sorgte.
Schlimmere Folgen als nur einen Imageschaden kann es haben, wenn Betrger Diebstahl von
Zugangsdaten und
einen "verwandten" Domainnamen dazu benutzen, um dort einen Webauftritt Kreditkarten-
aufzubauen, der dem echten Webauftritt tuschend hnlich sieht und der informationen
arglose Besucher dazu verleitet, dort Zugangsdaten fr den echten Webauftritt
oder Kreditkarteninformationen fr Bezahlvorgnge einzugeben. Die Betrger
benutzen diese Daten dann, um sich Zugang zum echten Webserver zu
verschaffen oder mit den gestohlenen Kreditkarteninformationen einzukaufen.
Solche Vorflle wurden bereits mehrfach bekannt.
Verletzung von Markenrechten
Bei der Registrierung von Domainnamen wird oft nicht geprft, ob der
gewhlte Name nicht registrierte Markennamen anderer Firmen verletzt.
Solche Markenrechtsverletzungen werden meist prompt bemerkt. Marken-
inhaber oder auf Abmahnungen spezialisierte Anwlte bzw. Organisationen
recherchieren regelmig nach neuen Domains, die eventuell Markenrechte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
verletzen und schicken meist kostenpflichtige Abmahnungen. Zustzlich kann

der Inhaber einer Marke gerichtlich die Rckgabe oder Lschung der Domain
verlangen. Dies kann neben erheblichen Kosten auch erhebliche
Imageschden nach sich ziehen.
Fehler bei der Verlngerung von Domainnamen und beim Wechsel der
Registrierungsstelle
Domainnamen mssen regelmig gegen Zahlung einer Verwaltungsgebhr
beim zustndigen Registrar "verlngert" werden. Wird die Gebhr nicht
rechtzeitig bezahlt, so geht das Recht an dem Domainnamen verloren und
andere Organisationen knnen den Domainnamen registrieren. Ist der
betreffende Domainname nicht firmenspezifisch, so gibt es schlimmstenfalls
keine Mglichkeit, die verlorene Domain zurck zu erhalten. Der zustzliche
Imageschaden, der eventuell dadurch entsteht, dass eine derart "verwaiste"
Domain womglich von einem Pornoanbieter oder einer radikalen
Organisation registriert wird, die von dort aus denn anstige oder gar illegale
Inhalte verbreiten, kann in diesem Fall erheblich sein.
Es ist auch vorgekommen, dass weniger serise Registrierungsstellen Kunden Nepper, Schlepper,
Bauernfnger
ihrer Konkurrenten anriefen und behaupteten, die Registrierung sei abgelaufen
und msste gegen eine erneute Zahlung an sie erneuert werden. Wenn dadurch
berraschte Kunden dann die Gebhr an die betreffende Stelle bezahlten,
vollzogen sie gleichzeitig einen Wechsel der Registrierungsstelle.
Fehlerhafte Anordnung der Primary Nameserver
Bei der Registrierung eines Domainnamens mssen mindestens zwei
Nameserver angegeben werden, die als Primary Nameserver fr diese Domain
agieren. Falls diese beiden Nameserver in demselben Netzsegment angesiedelt
sind, so kann durch einen Ausfall des Netzkoppelelements, das dieses
Netzsegment mit dem Internet verbindet, die Namensauflsung fr die
komplette Domain lahmgelegt werden. Dies fhrt letztlich dazu, dass auf
keinen der unter dem Domainnamen angebotenen Dienste wie Webserver oder
E-Mail mehr zugegriffen werden kann.
Beispielsweise wurde im Jahr 2001 wurde die Domain eines groen
Softwarehauses durch einen DDoS (Distributed Denial of Service) Angriff auf
den Router, der die Primary Name Server fr die Domain mit dem Internet
verband, fr mehrere Stunden praktisch komplett lahmgelegt. Als Reaktion
auf diesen Angriff wurden die Nameserver in verschiedene Netzsegmente
verlegt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 2.101 Unzureichende Notfallvorsorge bei einem

Sicherheitsgateway
Eine unzureichende Planung fr Notflle kann Probleme, die beim Betrieb
eines Sicherheitsgateways auftreten, wesentlich verschlimmern und
Ausfallzeiten verlngern.
Zustzlich zu allgemeinen Fehlern, die oft im Bereich Notfallvorsorge
gemacht werden, knnen bei einem Sicherheitsgateway einige spezielle Fehler
gemacht werden, die eine schnelle Reaktion auf Zwischenflle sehr
erschweren oder gar unmglich machen knnen. Einige dieser Fehler werden
im folgenden beschrieben.
- Existieren keine Planungen fr das Vorgehen bei Notfllen und keine
entsprechenden Handlungsanweisungen, so ist eine effiziente Reaktion
meist berhaupt nicht mglich. Bei komplexen Systemen wie mehrstufigen
Sicherheitsgateways kann es zu zustzlichen Problemen kommen, wenn
Abhngigkeiten zwischen einzelnen Komponenten nicht bekannt oder
nicht dokumentiert sind, oder wenn sie bei der Planung nicht korrekt
- Sind fr wichtige Hardwarekomponenten keine Austauschteile
beziehungsweise -gerte verfgbar und sind mit den Herstellern oder
Lieferanten keine entsprechenden Vereinbarungen (beispielsweise Service-
Level-Agreements oder Vor-Ort-Austausch innerhalb eines garantierten
Zeitraums) getroffen, so kann dies zu erheblichen Ausfallzeiten und Kosten
fhren.
- Existiert keine oder nur eine unzureichende Dokumentation der
Konfiguration und der wichtigsten Betriebsparameter, so kann es sehr
schwierig sein, nach einem Notfall berhaupt wieder eine funktionierende
Konfiguration herzustellen. Schlechte Dokumentation kann auch dazu
fhren, dass Konfigurationsfehler zunchst nicht entdeckt werden und bei
auftretenden Problemen eine aufwendige Fehlersuche erforderlich wird.
- Sind die fr eine Fehlerdiagnose bentigten Werkzeuge und Programme
nicht verfgbar oder sind die Administratoren nicht in der Lage, diese
richtig einzusetzen, so kann dies zu erheblichen Verzgerungen fhren.
- Werden wichtige Daten bei der Protokollierung nicht erfasst, so kann dies
die korrekte Einschtzung von Art und Schwere eines Vorfalls erschweren
oder unmglich machen.
- Bei der Systemwiederherstellung nach einem Notfall kann es
wnschenswert sein, einen lteren Stand der Konfiguration wieder
herzustellen. Wird fr die Konfigurationsdaten (insbesondere die
Paketfilterregeln) keine Versionsverwaltung durchgefhrt, so kann dies
schwierig oder gar unmglich sein.
___________________________________________________________________ ..........................................
Gefhrdungskatalog Menschliche Fehlhandlungen G3 Bemerkungen
___________________________________________________________________ ..........................................
G3 Gefhrdungskatalog Menschliche Fehlhandlungen

G 3.1 Vertraulichkeits-/Integrittsverlust von Daten durch
Fehlverhalten der IT-Benutzer................................................... 1
G 3.2 Fahrlssige Zerstrung von Gert oder Daten ........................... 2
G 3.3 Nichtbeachtung von IT-Sicherheitsmanahmen........................ 3
G 3.4 Unzulssige Kabelverbindungen ............................................... 4
G 3.5 Unbeabsichtigte Leitungsbeschdigung..................................... 5
G 3.6 Gefhrdung durch Reinigungs- oder Fremdpersonal................. 6
G 3.7 Ausfall der TK-Anlage durch Fehlbedienung............................ 7
G 3.8 Fehlerhafte Nutzung des IT-Systems......................................... 8
G 3.9 Fehlerhafte Administration des IT-Systems .............................. 9
G 3.10 Falsches Exportieren von Dateisystemen unter Unix .............. 10
G 3.11 Fehlerhafte Konfiguration von sendmail ................................. 11
G 3.12 Verlust der Datentrger beim Versand .................................... 12
G 3.13 bertragung falscher oder nicht gewnschter
Datenstze................................................................................ 13
G 3.14 Fehleinschtzung der Rechtsverbindlichkeit eines Fax ........... 14
G 3.15 Fehlbedienung eines Anrufbeantworters ................................. 15
G 3.16 Fehlerhafte Administration von Zugangs- und
Zugriffsrechten......................................................................... 16
G 3.17 Kein ordnungsgemer PC-Benutzerwechsel.......................... 17
G 3.18 Freigabe von Verzeichnissen, Druckern oder der
Ablagemappe ........................................................................... 18
G 3.19 Speichern von Passwrtern unter WfW und
Windows 95 ............................................................................. 19
G 3.20 Ungewollte Freigabe des Leserechtes bei Schedule+.............. 20
G 3.21 Fehlbedienung von Codeschlssern......................................... 21
G 3.22 Fehlerhafte nderung der Registrierung ................................. 22
G 3.23 Fehlerhafte Administration eines DBMS................................. 23
G 3.24 Unbeabsichtigte Datenmanipulation........................................ 24
G 3.25 Fahrlssiges Lschen von Objekten......................................... 25
G 3.26 Ungewollte Freigabe des Dateisystems ................................... 26
G 3.27 Fehlerhafte Zeitsynchronisation............................................... 27
G 3.28 Ungeeignete Konfiguration der aktiven
Netzkomponenten .................................................................... 28
G 3.29 Fehlende oder ungeeignete Segmentierung ............................. 30
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.30 Unerlaubte private Nutzung des dienstlichen

Telearbeitsrechners .................................................................. 31
G 3.31 Unstrukturierte Datenhaltung .................................................. 32
G 3.32 Versto gegen rechtliche Rahmenbedingungen beim
Einsatz von kryptographischen Verfahren............................... 33
G 3.33 Fehlbedienung von Kryptomodulen ........................................ 34
G 3.34 Ungeeignete Konfiguration des Managementsystems............. 35
G 3.35 Server im laufenden Betrieb ausschalten................................. 36
G 3.36 Fehlinterpretation von Ereignissen .......................................... 37
G 3.37 Unproduktive Suchzeiten......................................................... 38
G 3.38 Konfigurations- und Bedienungsfehler.................................... 39
G 3.39 Fehlerhafte Administration des RAS-Systems ........................ 40
G 3.40 Ungeeignete Nutzung von Authentisierungsdiensten bei
Remote Access......................................................................... 42
G 3.41 Fehlverhalten bei der Nutzung von RAS-Diensten ................. 43
G 3.42 Unsichere Konfiguration der RAS-Clients .............................. 45
G 3.43 Ungeeigneter Umgang mit Passwrtern .................................. 46
G 3.44 Sorglosigkeit im Umgang mit Informationen .......................... 47
G 3.45 Unzureichende Identifikationsprfung von
Kommunikationspartnern ........................................................ 49
G 3.46 Fehlkonfiguration eines Lotus Notes Servers .......................... 50
G 3.47 Fehlkonfiguration des Browser-Zugriffs auf Lotus
Notes ........................................................................................ 52
G 3.48 Fehlkonfiguration von Windows 2000 Rechnern .................... 53
G 3.49 Fehlkonfiguration des Active Directory .................................. 54
G 3.50 Fehlkonfiguration von Novell eDirectory................................ 55
G 3.51 Falsche Vergabe von Zugriffsrechten im Novell
eDirectory ................................................................................ 56
G 3.52 Fehlkonfiguration des Intranet-Clientzugriffs auf Novell
eDirectory ................................................................................ 58
G 3.53 Fehlkonfiguration des LDAP-Zugriffs auf Novell
eDirectory ................................................................................ 59
G 3.54 Verwendung ungeeigneter Datentrger bei der
Archivierung ............................................................................ 60
G 3.55 Versto gegen rechtliche Rahmenbedingungen beim
Einsatz von Archivsystemen.................................................... 61
G 3.56 Fehlerhafte Einbindung des IIS in die Systemumgebung........ 62
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.57 Fehlerhafte Konfiguration des Betriebssystems fr den

IIS ............................................................................................ 63
G 3.58 Fehlerkonfiguration eines IIS .................................................. 64
G 3.59 Unzureichende Kenntnisse ber Sicherheitslcken und
Prfwerkzeuge fr den IIS ....................................................... 65
G 3.60 Fehlerkonfiguration von Exchange 2000 Servern ................... 66
G 3.61 Fehlerhafte Konfiguration von Outlook 2000 Clients ............. 68
G 3.62 Fehlerhafte Konfiguration des Betriebssystems fr den
Apache Webserver................................................................... 70
G 3.63 Fehlerhafte Konfiguration eines Apache Webservers ............. 71
G 3.64 Fehlerhfte Konfiguration von Routern und Switchen.............. 73
G 3.65 Fehlerhafte Administration von Routern und Switchen .......... 74
G 3.66 Fehlerhafte Zeichensatzkonvertierung beim Einsatz von
z/OS ......................................................................................... 75
G 3.67 Unzureichende oder fehlerhafte Konfiguration des
z/OS-Betriebssystems .............................................................. 76
G 3.68 Unzureichende oder fehlerhafte Konfiguration des
z/OS-Webservers ..................................................................... 79
G 3.69 Fehlerhafte Konfiguration der Unix System Services
unter z/OS ................................................................................ 80
G 3.70 Unzureichender Dateischutz des z/OS-Systems ...................... 81
G 3.71 Fehlerhafte Systemzeit bei z/OS-Systemen ............................. 82
G 3.72 Fehlerhafte Konfiguration des z/OS-Sicherheitssystems
RACF....................................................................................... 83
G 3.73 Fehlbedienung der z/OS-Systemfunktionen ............................ 85
G 3.74 Unzureichender Schutz der z/OS-Systemeinstellungen
vor dynamischen nderungen ................................................. 88
G 3.75 Mangelhafte Kontrolle der Batch-Jobs bei z/OS ..................... 90
G 3.76 Fehler bei der Synchronisation mobiler Endgerte.................. 91
___________________________________________________________________ ..........................................
Gefhrdungskatalog Menschliche Fehlhandlungen G 3.1 Bemerkungen
___________________________________________________________________ ..........................................
G 3.1 Vertraulichkeits-/Integrittsverlust von Daten

durch Fehlverhalten der IT-Benutzer
Durch Fehlverhalten knnen IT-Benutzer den Vertraulichkeits- bzw. Integri-
ttsverlust von Daten herbeifhren bzw. ermglichen. Die Folgeschden er-
geben sich aus der Schutzbedrftigkeit der Daten. Beispiele fr ein solches
Fehlverhalten sind:
- Mitarbeiter holen versehentlich Ausdrucke mit personenbezogenen Daten
nicht am Netzdrucker ab.
- Es werden Datentrger versandt, ohne dass die vorher darauf gespeicherten
Daten physikalisch gelscht wurden.
- Dokumente werden auf einem Webserver verffentlicht, ohne dass geprft
wurde, ob diese tatschlich zur Verffentlichung vorgesehen und frei-
gegeben sind.
- Aufgrund von fehlerhaft administrierten Zugriffsrechten vermag ein Mit-
arbeiter Daten zu ndern, ohne die Brisanz dieser Integrittsverletzung ein-
schtzen zu knnen.
- Neue Software wird mit nicht anonymisierten Daten getestet. Nicht befugte
Mitarbeiter erhalten somit Einblick in geschtzte Dateien bzw. vertrauliche
Informationen. Mglicherweise erlangen berdies auch Dritte Kenntnis
von diesen Informationen, weil die Entsorgung von "Testausdrucken" nicht
entsprechend geregelt ist.
- Beim Ausbau, Verleih, Einsendung zur Reparatur oder Ausmusterung von
Festplatten knnen Daten auf zum Teil intakten Dateisystemen in unbe-
fugte Hnde gelangen.
Betreut ein Outsourcing-Dienstleister mehrere Mandanten, so knnen Daten
einer auslagernden Organisation durch menschliches Versagen anderen Man-
danten des Outsourcing-Dienstleisters zugnglich werden.
Mgliche Ursachen knnen beispielsweise folgende sein:
- Falsches Routing einer Druckausgabe.
- Auswahl einer falschen E-Mail-Adresse aus dem Adressbuch.
- Fehler in einer Datenbank.
- Unbedachtes "copy - paste" (z. B. von Konfigurationsdateien von
Systemen verschiedener Auftraggeber).
- Postversand (z. B. von Backup-Medien, Vertrgen) an die falsche Adresse.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.2 Fahrlssige Zerstrung von Gert oder Daten

Durch Fahrlssigkeit, aber auch durch ungeschulten Umgang kann es zu
Zerstrungen an Gerten und Daten kommen, die den Betrieb des IT-Systems
empfindlich stren knnen. Dies ist auch durch die unsachgeme Verwen-
dung von IT-Anwendungen mglich, wodurch fehlerhafte Ergebnisse ent-
stehen oder Daten unabsichtlich verndert oder zerstrt werden. Durch
unachtsames Benutzen eines einzigen Lschbefehls knnen ganze Datei-
strukturen gelscht werden.
Beispiele:
- Benutzer, die aufgrund von Fehlermeldungen den Rechner ausschalten,
statt ordnungsgem alle laufenden Anwendungen zu beenden bzw. einen
Sachkundigen zu Rate zu ziehen, knnen hierdurch schwerwiegende
Integrittsfehler in Datenbestnden hervorrufen.
- Durch umgestoene Kaffeetassen oder beim Blumengieen eindringende
Feuchtigkeit knnen in einem IT-System Kurzschlsse hervorrufen
werden.
- In einem z/OS-System verfgte ein Systemprogrammierer ber die
Berechtigung, das Programm ICKDSF zum Formatieren von Festplatten
aufzurufen. Als er zur Ausbung seiner Ttigkeit dringend eine Festplatte
bentigte, whlte er aus dem vorhandenen Pool eine freie Festplatte aus,
gab jedoch aufgrund eines Tippfehlers eine falsche Adresse an. Den im
System-Log anstehenden Reply las er nur flchtig und beantwortete ihn
sofort. Die Formatierung einer bereits belegten Festplatte wurde dadurch
freigegeben und wichtige Produktionsdaten zerstrt.
- Ein Benutzer, der es sich zur Gewohnheit gemacht hat, unter Unix den
Lschbefehl rm grundstzlich ohne den Parameter fr die Sicherheits-
abfragen (-i) durchzufhren oder gar mit -f die Sicherheitsabfragen grund-
stzlich ausschaltet, riskiert in hohem Mae das versehentliche Lschen
von Dateien. hnliches gilt auch fr den Befehl del *.* unter MS-DOS.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.3 Nichtbeachtung von IT-Sicherheitsmanahmen

Aufgrund von Nachlssigkeit und fehlenden Kontrollen kommt es immer
wieder vor, dass Personen die ihnen empfohlenen oder angeordneten IT-
Sicherheitsmanahmen nicht oder nicht im vollen Umfang durchfhren. Es
knnen Schden entstehen, die sonst verhindert oder zumindest vermindert
worden wren. Je nach der Funktion der Person und der Bedeutung der
missachteten Manahme knnen sogar gravierende Schden eintreten.
Vielfach werden IT-Sicherheitsmanahmen aus einem mangelnden Sicher-
heitsbewusstsein heraus nicht beachtet. Ein typisches Indiz dafr ist, dass
wiederkehrende Fehlermeldungen nach einer gewissen Gewhnungszeit
ignoriert werden.
Beispiele:
- Der verschlossene Schreibtisch zur Aufbewahrung von Disketten bietet
keinen hinreichenden Schutz gegen einen unbefugten Zugriff, wenn der
Schlssel im Bro aufbewahrt wird, z. B. auf dem Schrank oder im Zettel-
kasten.
- Geheimzuhaltende Passwrter werden schriftlich fixiert in der Nhe eines
Terminals oder PCs aufbewahrt.
- Obwohl die schadensmindernde Eigenschaft von Datensicherungen hinrei-
chend bekannt ist, treten immer wieder Schden auf, wenn Daten unvorher-
gesehen gelscht werden und aufgrund fehlender Datensicherung die Wie-
derherstellung unmglich ist. Dies zeigen insbesondere die dem BSI
gemeldeten Schden, die z. B. aufgrund von Computer-Viren entstehen.
- Der Zutritt zu einem Rechenzentrum sollte ausschlielich durch die mit
einem Zutrittskontrollsystem (z. B. Magnetstreifenleser) gesicherte Tr
erfolgen. Die Fluchttr wird jedoch, obwohl sie nur im Notfall geffnet
werden darf, als zustzlicher Ein- und Ausgang genutzt.
- In einem z/OS-System liefen tglich Batch-Jobs fr die RACF-Datenbank-
Sicherungen. Die korrekte Ausfhrung dieser Ablufe sollte tglich von
den zustndigen Administratoren geprft werden. Da die Sicherungen
jedoch ber mehrere Monate ohne Probleme durchgefhrt wurden,
kontrollierte niemand mehr den Ablauf. Erst nachdem die RACF-Daten-
banken des Produktionssystems defekt waren und die Sicherungen zurck-
gespielt werden sollten, wurde festgestellt, dass die Batch-Jobs seit
mehreren Tagen nicht mehr gelaufen waren. Dies fhrte dazu, dass keine
aktuellen Sicherungen vorhanden waren und die nderungen der letzten
Tage von Hand nachgetragen werden mussten. Neben einem erheblichen
zustzlichen Administrationsaufwand ergab sich dadurch ein Unsicher-
heitsfaktor, da nicht alle Definitionen sicher rekonstruiert werden konnten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.4 Unzulssige Kabelverbindungen

Hauptursache unzulssiger Verbindungen ist neben technischen Defekten die
fehlerhafte Verkabelung, z. B. bei der Belegung von Rangier- und Spleiver-
teilern. Ungenaue Dokumentation und unzureichende Kabelkennzeichnung
fhren hufig zu versehentlichen Fehlbelegungen und erschweren das
Erkennen von absichtlichen Fehlbelegungen.
Durch unzulssige Verbindungen knnen Informationen zustzlich oder aus-
schlielich zu falschen Empfngern bertragen werden. Die normale Verbin-
dung kann gestrt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.5 Unbeabsichtigte Leitungsbeschdigung

Je ungeschtzter ein Kabel verlegt ist, desto grer ist die Gefahr einer unbe-
absichtigten Beschdigung. Die Beschdigung fhrt nicht unbedingt sofort zu
einem Ausfall von Verbindungen. Auch die zufllige Entstehung unzulssiger
Verbindungen ist mglich. Typische Beispiele fr solche Beschdigungen
sind:
Im Innenbereich:
- Herausreien der Gerteanschlussleitung mit dem Fu bei "fliegender"
Verlegung,
- Beschdigung unter Putz verlegter Leitungen durch Bohren oder Nageln,
- Eindringen von Wasser in Fensterbank-Kanle,
- Eindringen von Wasser in Fubodenkanle bei der Gebudereinigung,
- Beschdigung auf Putz oder Estrich verlegter Leitungen beim Transport
sperriger und schwerer Gegenstnde.
Im Auenbereich:
- Beschdigung bei Tiefbauarbeiten, sowohl durch Handschachtung als auch
durch Bagger,
- Eindringen von Wasser in Erdtrassen/Erdkabel,
Beispiel:
In einer Fugngerzone hatte es sich die Putzfrau eines kleinen Geschftes zu
Angewohnheit gemacht, das gebrauchte Putzwasser in den direkt vor der
Ladentr befindlichen Revisionsschacht einer Post-Kabeltrasse zu schtten.
Das Wasser verdunstete zwar mit der Zeit immer wieder, der Schmutz- und
Seifenanteil jedoch lagerte sich auf den Kabeln ab und musste fr Arbeiten
daran erst mhsam und zeitaufwendig entfernt werden.
- Beschdigung von Kabeln durch Nagetiere,
- Beschdigung von Trassen und Kabeln durch Wurzeln (Baumwurzeln
besitzen genug Kraft, um Kabel abzuquetschen),
- Beschdigung durch berschreitung zulssiger Verkehrslasten (Rohre
knnen brechen, Kabel knnen abscheren).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.6 Gefhrdung durch Reinigungs- oder

Fremdpersonal
Die Gefhrdung durch Reinigungs- und Fremdpersonal erstreckt sich von der
unsachgemen Behandlung der technischen Einrichtungen, ber den Versuch
des "Spielens" am IT-System ggf. bis zum Diebstahl von IT-Komponenten.
Beispiele:
- Durch Reinigungspersonal kann versehentlich eine Steckverbindung gelst
werden, Wasser kann in Gerte gelangen, Unterlagen knnen verlegt oder
sogar mit dem Abfall entfernt werden.
- In einem Rechenzentrum sollten in den Maschinenrumen Malerarbeiten
durchgefhrt werden. Der Maler stie mit der Leiter versehentlich an den
zentralen Notausschalter der Stromversorgung und lste diesen aus. Die
gesamte Stromversorgung der z/OS-Systeme in diesem Rechenzentrum
war sofort unterbrochen. Durch den Stromausfall waren mehrere Platten
(DASD - Direct Access Storage Device) nicht sofort verfgbar. Der
hinzugezogene Techniker bentigte mehrere Stunden, bis die Produktion
wieder anlaufen konnte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.7 Ausfall der TK-Anlage durch Fehlbedienung

Neben dem technischen Versagen durch Defekt von Bauteilen, Stromausfall
oder Sabotage gibt es eine Reihe weiterer Umstnde, die zum Ausfall einer
TK-Anlage fhren knnen. So knnen z. B. durch unzureichend ausgebildetes
Wartungspersonal nderungen an der Anlagenkonfiguration vorgenommen
werden, die solche Ausflle zur Folge haben. Das nicht rechtzeitige Erkennen
von Alarmsignalen oder abnormem Betriebsverhalten kann dieselbe Folge
haben, ferner unsachgemes oder unberlegtes Handeln bei eigentlich einfa-
chen Routinereparaturen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.8 Fehlerhafte Nutzung des IT-Systems

Eine fehlerhafte Nutzung des IT-Systems beeintrchtigt die Sicherheit eines
IT-Systems, wenn dadurch IT-Sicherheitsmanahmen missachtet oder umgan-
gen werden. Dies kann vermieden werden, wenn der Benutzer ber die
ordnungsgeme Funktion und den Betrieb eines IT-Systems ausreichend
informiert ist.
Beispiele:
Zu grozgig vergebene Rechte, leicht zu erratende Passwrter, versehent-
liches Lschen, Datentrger mit den Sicherheitskopien sind fr Unbefugte
zugnglich, das Terminal wird bei vorbergehender Abwesenheit nicht ver-
schlossen u.v.a.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.9 Fehlerhafte Administration des IT-Systems

Eine fehlerhafte Administration beeintrchtigt die Sicherheit eines IT-
Systems, wenn dadurch IT-Sicherheitsmanahmen missachtet oder umgangen
werden.
Eine fehlerhafte Administration liegt z. B. vor, wenn Netzzugangsmglich- unsichere Netzzugnge
keiten (Daemon-Prozesse) geschaffen oder nicht verhindert werden, die fr
den ordnungsgemen Betrieb des IT-Systems nicht notwendig sind oder auf
Grund ihrer Fehleranflligkeit eine besonders groe Bedrohung darstellen.
Unter keinen Umstnden sollten bei Arbeiten am System Zugangskonten unntige Zugriffsrechte
verwendet werden, die mehr Zugriffsrechte besitzen, als fr die Ttigkeit
unbedingt ntig sind, da sich hierdurch die Gefahr von Schden durch Viren
und Trojanischen Pferden unntig erhht.
Standard-Installationen von Betriebssystemen oder Systemprogrammen mangelhafte Anpassun-
gen
weisen in den seltensten Fllen alle Merkmale einer sicheren Installation auf.
Mangelnde Anpassungen an die konkreten Sicherheitsbedrfnisse knnen hier
ein erhebliches Risiko darstellen. Die Gefahr von Fehlkonfigurationen besteht
insbesondere bei komplexen Sicherheitssystemen, wie zum Beispiel RACF
unter z/OS. Viele Systemfunktionen beeinflussen sich gegenseitig.
Besondere Beachtung mssen Systeme finden, deren fehlerhafte Administra-
tion Einfluss auf den Schutz anderer Systeme haben (Firewalls).
Jede Modifikation von Sicherheitseinstellungen und die Erweiterung von
Zugriffsrechten stellt eine potentielle Gefhrdung der Gesamtsicherheit dar.
Beispiele:
ber das bei G 3.8 Fehlerhafte Nutzung des IT-Systems gesagte hinaus kann unzureichende Pro-
tokollierung
der Systemadministrator durch eine fehlerhafte Installation neuer oder
vorhandener Software Gefhrdungen schaffen. Eine fehlerhafte Administra-
tion liegt auch vor, wenn Protokollierungsmglichkeiten nicht genutzt oder
vorhandene Protokolldateien nicht ausgewertet werden, wenn zu grozgig
Zugangsberechtigungen vergeben und diese dann nicht in gewissen Abstnden
kontrolliert werden, wenn Login-Namen oder UIDs mehr als einmal vergeben
werden oder wenn vorhandene Sicherheitstools, wie z. B. unter Unix die
Benutzung einer shadow-Datei fr die Passwrter, nicht genutzt werden.
Mit dem Lebensalter von Passwrtern sinkt deren Wirksamkeit. Grund dafr Alterung von
Passwrtern
ist die sich stetig erhhende Wahrscheinlichkeit eines erfolgreichen Angriffes.
Der Administration eines Firewall-Systems gilt es besondere Aufmerksamkeit
zu schenken, da dieses Voraussetzung fr den Schutz einer Vielzahl anderer
Systeme ist.
- In einem z/OS-System wurden die Dateien der Anwender durch RACF-
Profile via Universal Access derart geschtzt, dass niemand unkontrolliert
darauf zugreifen konnte (UACC = NONE). Durch eine Unachtsamkeit des
Administrators erlaubte ein Eintrag in der Conditional Access List des
Profils allen IDs (* Eintrag) den Zugriff READ. Als Folge konnte trotz der
Definition UACC=NONE jeder Anwender im System ber die Conditional
Access List die Dateien einsehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.10 Falsches Exportieren von Dateisystemen unter

Unix
Exportierte Platten knnen von jedem Rechner, der sich mit dem in der Datei
/etc/exports bzw. /etc/dfs/dfstab angegebenen Namen meldet, gemountet
werden. Der Benutzer dieses Rechners kann jede UID und GID annehmen.
Solange Verzeichnisse nicht mit der Option root= exportiert wurden, stellt die
UID 0 (root) eine Ausnahme dar, die beim Zugriff auf einen NFS-Server
blicherweise auf eine andere UID (z. B. die des Benutzers nobody oder
anonymous) abgebildet wird. Es lassen sich daher nur Dateien schtzen, die
root gehren.
Fr die Verwendung der Protokolle NFS fr den Export von Dateisystemen
und die Verteilung von Systemdateien mittels NIS sind keine ausreichenden
Schutzmanahmen in geschtzten Umgebungen verfgbar. Der Einsatz stellt
somit eine Gefhrdung der Integritt der Systeme dar.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.11 Fehlerhafte Konfiguration von sendmail

Fehler in der Konfiguration oder Software von sendmail haben in der Vergan-
genheit schon mehrmals zu Sicherheitslcken auf den betroffenen IT-
Systemen gefhrt (Stichwort Internet-Wurm).
Beispiel:
Es ist durch verschiedene Verffentlichungen bekannt, dass es mglich ist, die
Benutzer- und Gruppenkennung, die mit den Optionen u und g eingestellt sind
(normalerweise daemon) zu erlangen. Dazu muss im Absenderfeld (From:)
eine Pipe angegeben werden, durch die eine fehlerhafte Mail zurckgeschickt
wird, und in der Mail selber muss ein Fehler erzeugt werden. Schickt man also
z. B. eine Mail mit dem Inhalt
cp /bin/sh /tmp/sh
chmod oug+rsx /tmp/sh
an einen unbekannten Empfnger und benutzt als Absender /bin/sh , so wird
die Mail als unzustellbar zurckgeschickt, was in diesem Falle einer
Ausfhrung des kurzen Shellskripts gleichkommt. Durch dieses Skript wird
dann eine Shell mit gesetztem suid-Bit erzeugt, die die im sendmail.cf gesetzte
Benutzer- und Gruppenkennung hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.12 Verlust der Datentrger beim Versand

Werden Datentrger in nicht sonderlich stabilen Behltnissen (Brief-
umschlgen oder sonstigen Verpackungen) versandt, besteht die Gefahr, dass
der Datentrger (insbesondere Disketten) bei Beschdigung der Verpackung
verloren geht. Auch besteht die Gefahr des Verlustes auf dem Postweg oder
durch Unachtsamkeit eines Boten. Falls beispielsweise eine Diskette
zusammen mit einem Anschreiben in einem Umschlag verschickt wird, der
wesentlich grer als die Diskette ist, so kann beim Empfang des Umschlages
die innenliegende Diskette bersehen und zusammen mit dem scheinbar leeren
Umschlag entsorgt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.13 bertragung falscher oder nicht gewnschter

Datenstze
Es ist denkbar, dass der fr den Versand vorgesehene Datentrger bereits
Daten frherer Arbeitsgnge enthlt, die dem Empfnger nicht zur Kenntnis
gelangen sollen. Werden diese Daten nicht gezielt physikalisch gelscht,
knnen diese vom Empfnger gelesen werden.
Befinden sich darber hinaus die zu bertragenden Daten in einem Verzeich-
nis mit weiteren Daten, die ebenfalls schutzbedrftig sind, besteht die Gefahr,
dass diese versehentlich mit auf den Datentrger bertragen werden (z. B.
durch copy *.*) und dem Empfnger unntig (unberechtigt) zur Kenntnis
gelangen.
Sollen Datenstze nicht ber das Medium "Datentrger", sondern ber Daten-
netze direkt versandt werden (E-Mail im Internet, Modem-Verbindung,
interne Firmennetze, X.400-Dienst), bieten Kommunikationsprogramme die
Mglichkeit der Verwendung von Kurzbezeichnungen fr komplexe
Adressstrukturen und Verteilerlisten fr die Mehrfachversendung. Werden
solche Verteilerlisten nicht zentral gefhrt oder nicht in regelmigen
Abstnden aktualisiert, knnen Datenstze an Adressen versendet werden, die
zu nicht mehr autorisierten Personen gehren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.14 Fehleinschtzung der Rechtsverbindlichkeit

eines Fax
Hufig wird versucht, bei eiligen Entscheidungen den Postweg einzusparen,
indem wichtige Unterlagen oder Informationen an den Geschftspartner per
Fax bermittelt werden. Dabei wird oft auer acht gelassen, dass so
bermittelte Unterlagen in einem Streitfall nicht immer als rechtsverbindlich
angesehen werden. Bestellungen mssen dann nicht vom Kunden ange-
nommen, Zusagen nicht eingehalten werden. Eine Rechtsmittelfrist kann trotz
rechtzeitigen Absendens eines Fax ablaufen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.15 Fehlbedienung eines Anrufbeantworters

Grundstzlich besteht die Gefahr der Fehlbedienung eines Anrufbeantworters.
Bei einigen Gerten ist die Gefahr eines Bedienungsfehlers recht hoch, da sie
beispielsweise mit Funktionstasten versehen sind, die doppelt oder zum Teil
sogar dreifach belegt sind. Erschwerend kann hinzukommen, dass die Bedien-
tasten so klein sind und so nahe nebeneinander liegen, dass Fehlgriffe kaum
vermeidbar sind.
So ist es durchaus mglich, dass der Anrufbeantworter aufgrund von Fehl-
bedienungen einen Anruf erst gar nicht entgegennimmt. Dies geschieht zum
Beispiel, wenn man versehentlich das Gert deaktiviert oder den Ansagetext
mittels Tastendruck gelscht hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.16 Fehlerhafte Administration von Zugangs- und

Zugriffsrechten
Zugangsrechte zu einem IT-System und Zugriffsrechte auf gespeicherte Daten
und IT-Anwendungen drfen nur in dem Umfang eingerumt werden, wie sie
fr die Wahrnehmung der Aufgaben erforderlich sind. Werden diese Rechte
fehlerhaft administriert, so kommt es zu Betriebsstrungen, falls erforderliche
Rechte nicht zugewiesen wurden, bzw. zu Sicherheitslcken, falls ber die
notwendigen Rechte hinaus weitere vergeben werden.
Beispiel:
Durch eine fehlerhafte Administration der Zugriffsrechte hat ein Sachbearbei-
ter die Mglichkeit, auf die Protokolldaten zuzugreifen. Durch gezieltes
Lschen einzelner Eintrge ist es ihm daher mglich, seine Manipulations-
versuche am Rechner zu verschleiern, da sie in der Protokolldatei nicht mehr
erscheinen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.17 Kein ordnungsgemer PC-Benutzerwechsel

Arbeiten mehrere Benutzer an einem PC, so kann es aufgrund von Nach-
lssigkeit oder Bequemlichkeit dazu kommen, dass sich bei einem Wechsel
der vorhergehende Benutzer nicht abmeldet und der neue sich nicht
ordnungsgem anmeldet. Dies wird von den Betroffenen meist damit
begrndet, dass die Zeit, die das IT-System zum Neustarten bentigt, sehr lang
ist und als nicht akzeptabel empfunden wird.
Dieses Fehlverhalten fhrt jedoch dazu, dass die Protokollierung von An- und
Abmeldevorgngen und damit ein Teil der Beweissicherung unwirksam wird.
Es lsst sich anhand der Protokolle nicht mehr zuverlssig feststellen, wer den
Rechner zu einem bestimmten Zeitpunkt genutzt hat.
Beispiel:
Ein PC wird abwechselnd von drei Benutzern eingesetzt, um Reisekosten-
abrechnungen durchzufhren. Nachdem der erste Benutzer den Anmelde-
vorgang durchgefhrt hat, erfolgt kein ordnungsgemer PC-Benutzerwechsel
mehr, weil die damit verbundenen Ab- und Anmeldevorgnge aus
Bequemlichkeit nicht durchgefhrt werden.
Aufgrund von Unregelmigkeiten wird geprft, wer welchen Vorgang am
Rechner bearbeitet hat. Da nach Protokollierung nur ein Benutzer am PC
gearbeitet hat, kann der Verursacher im Nachhinein nicht mehr festgestellt
werden bzw. der einzige angemeldete Benutzer muss die Konsequenzen
tragen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.18 Freigabe von Verzeichnissen, Druckern oder der

Ablagemappe
Unter Windows fr Workgroups sind bei der Benutzung des Datei- oder mangelhafter
Druckmanagers bzw. der Zwischenablage bei der Freigabe von Verzeich- Passwortschutz
nissen, Druckern oder Seiten der Ablagemappe Bedienungsfehler mglich. unter WfW
Dies kann zur Folge haben, dass ungewollt Ressourcen freigegeben werden.
Der notwendige Passwortschutz wird eventuell nicht oder nur unzureichend
eingesetzt, wenn die Benutzer nicht ausreichend ber die Peer-to-Peer-Funk-
tionalitt in Windows fr Workgroups unterrichtet worden sind.
Zu beachten ist weiterhin, dass ein freigegebenes Verzeichnis automatisch
beim nchsten Start wieder freigegeben wird, ohne dass der Benutzer es
bemerkt, falls die Freigabeoption Beim nchsten Start wieder freigeben
aktiviert ist.
Unter Windows 95 mssen bei der Freigabe explizit Zugriffsberechtigungen
vergeben werden, so dass sich jeder Benutzer bewusst machen muss, dass und
wem der Zugriff ermglicht werden soll. Unter Windows NT/2000 kann nur
ein Administrator bzw. Hauptbenutzer Dateien und Verzeichnisse freigeben.
Auf IT-Systemen unter Unix oder Linux existieren eine ganze Reihe von unterschiedliche
Protokolle unter Unix
Mglichkeiten, anderen IT-Systemen ber das Netz Ressourcen zur und Linux
Verfgung zu stellen. Dies kann beispielsweise durch die Installation von
SAMBA, die Einrichtung von NFS-Shares oder die Aktivierung des FTP-
Daemons erfolgen. Hierzu sind in der Regel Supervisor-Rechte erforderlich,
bestimmte Dienste lassen sich jedoch auch so konfigurieren, dass sie so
genannte nicht-privilegierte Ports nutzen und somit auch von normalen
Benutzern gestartet werden knnen. Dadurch besteht die Gefahr, dass
ungewollt Ressourcen ber das Netz zur Verfgung gestellt werden.
Da freigegebene Ressourcen (ausgenommen sind die Seiten der Ablage- Missbrauch der
freigegebenen
mappe) im Allgemeinen fr alle Teilnehmer angezeigt werden, knnen andere Ressourcen
Teilnehmer solche erkennen und ggf. missbrauchen. Unter Umstnden werden
vertrauliche Daten gelesen, Daten unautorisiert verndert oder gelscht.
Wurde beispielsweise ein Verzeichnis ohne Passwortschutz zum Beschreiben
freigegeben, ist es mglich, in dieses solange Dateien zu speichern, bis die
Kapazitt der Festplatte erschpft ist.
Beispiel:
Nach der Einfhrung der WfW-Benutzeroberflche in einem servergesttzten
LAN, die nicht durch eine Schulung begleitet war, hatten rund 10% der
Benutzer ungewollt die komplette Festplatte (Stammverzeichnis C:\) frei-
gegeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.19 Speichern von Passwrtern unter WfW und

Windows 95
Der Zugriff auf Verzeichnisse, Drucker oder Seiten der Ablagemappen, die
von anderen freigegeben wurden, wird unter WfW und Windows 95 dadurch
erleichtert, dass die dazu bentigten Passwrter in der Datei
[anmeldename].pwl gespeichert werden knnen. Dazu kann die Option
"Kennwort in der Kennwortliste speichern" gewhlt werden. Ist diese Option
durch Voreinstellung aktiviert, kann es auch ungewollt dazu kommen, dass
Passwrter gespeichert werden. Unter Windows 95 in Netware-Netzen werden
die Anmeldepasswrter automatisch in der Datei [anmeldename].pwl gespei-
chert, die Zugriffsrechte aber grundstzlich auf Benutzer-Ebene erteilt.
Ein Dritter, der sich Zugang zu einem WfW- oder Windows 95-Rechner ver-
schafft, hat unmittelbaren Zugriff auf die Kennwortliste ([anmeldename].pwl).
Die dort gespeicherten Passwrter fr den Zugriff auf Ressourcen anderer
werden durch das WfW- bzw. Windows 95-Anmeldepasswort geschtzt. Ist
dieses deaktiviert oder bekannt bzw. ist WfW oder Windows 95 bereits ohne
Bildschirmsperre aktiv, knnen Unberechtigte Verbindungen zu anderen
Rechnern herstellen.
Hinweis:
Mittlerweile werden im Internet Programme angeboten, die eine Entschlsse-
lung der PWL-Dateien unter WfW ohne Kenntnis des Anmeldepasswortes
ermglichen. Die in diesen Dateien gespeicherten Passwrter sind in vielen
Fllen auch ber die windows-spezifische, temporre Auslagerungsdatei
386spart.par im Klartext zu gewinnen. Daher muss ein entsprechender
Zugangsschutz zum PC oder ein Zugriffsschutz auf Dateiebene installiert sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.20 Ungewollte Freigabe des Leserechtes bei

Schedule+
Im Lieferumfang von WfW ist das Programm mail und der Terminplaner
Schedule+ enthalten. Wird von mehreren Benutzern ein gemeinsames Post-
Office unter mail genutzt, kann auch eine gemeinsame Terminplanung mit
Schedule+ erfolgen. Dort knnen dann Zugriffsprivilegien fr den eigenen
Terminkalender vergeben werden. Standardmig ist fr jeden Teilnehmer
desselben Post-Office das Zugriffsrecht "Offene/Besetzte Zeitblcke
anzeigen" fr den privaten Kalender aktiviert, so dass, falls dieses Recht nicht
explizit entzogen wird, das zeitliche Arrangement - nicht jedoch der Inhalt -
des privaten Kalenders von anderen eingesehen werden kann. Der private
Nutzer knnte jedoch in dem Glauben sein, dass seine offenen/besetzten
Zeitblcke nicht eingesehen werden knnen, da er keine Zugriffsrechte verteilt
hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.21 Fehlbedienung von Codeschlssern

Erfahrungsgem fhren Fehler in der Bedienung von mechanischen Code-
schlssern verhltnismig oft dazu, dass der Schrank nicht mehr ordnungs-
gem geffnet werden kann. Die Fehlbedienungen treten bei der Eingabe und
besonders hufig bei der nderung des Codes auf. Um die aufbewahrten
Datentrger oder informationstechnischen Gerte wieder zugnglich zu
machen, muss dann ein spezialisierter Schlsseldienst beauftragt werden, so
dass neben dem Schaden, der aus der fehlenden Verfgbarkeit der Datentrger
oder Gerte entsteht, auch erhebliche Reparaturkosten anfallen knnen. Im
ungnstigsten Falle muss ein neuer Schutzschrank beschafft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.22 Fehlerhafte nderung der Registrierung

Windows 95 bietet die Mglichkeit, die Benutzerumgebung eines PC fest
bzw. benutzerindividuell einzuschrnken. Dies geschieht in der Regel unter
Verwendung des Systemrichtlinieneditors (POLEDIT.EXE) oder des
Registrierungseditors (REGEDIT.EXE). Die Benutzung dieser Programme
sollte mit Bedacht und jede nderung der Registrierung mit uerster Sorgfalt
ausschlielich durch geschultes Personal erfolgen, weil sehr schnell ein
Systemzustand eingestellt werden kann, der ein Arbeiten mit dem PC nicht
mehr erlaubt. Im ungnstigsten Fall ist dann das Betriebssystem neu zu
installieren oder bestimmte Hardware-Komponenten erneut zu initialisieren
(durch Laden der entsprechenden Treiber).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.23 Fehlerhafte Administration eines DBMS

Wird ein Datenbankmanagementsystem (DBMS) nachlssig oder fehlerhaft
administriert, kann dies folgende Gefhrdungen nach sich ziehen:
- Verlust von Daten,
- (gezielte oder unbeabsichtigte) Datenmanipulation,
- unberechtigter Zugang zu vertraulichen Daten,
- Verlust der Datenbankintegritt,
- Crash der Datenbank und
- Zerstrung der Datenbank.
Die oben aufgefhrten Gefhrdungen knnen durch zu grozgig vergebene
Rechte fr die Benutzer, durch eine unregelmige oder gar keine Daten-
bankberwachung, durch mangelhafte Datensicherungen, durch ungltige,
aber noch nicht gesperrte Kennungen usw. hervorgerufen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.24 Unbeabsichtigte Datenmanipulation

Je umfangreichere Zugriffsberechtigungen auf eine Datenbank fr die
Anwender bestehen, um so grer ist auch das Risiko einer unbeabsichtigten
Datenmanipulation. Dies kann prinzipiell von keiner Anwendung verhindert
werden. Die grundstzlichen Ursachen fr unbeabsichtigte Datenmanipu-
lationen knnen z. B. sein:
- mangelhafte oder fehlende Fachkenntnisse,
- mangelhafte oder fehlende Kenntnisse der Anwendung,
- zu umfangreiche Zugriffsberechtigungen und
- Fahrlssigkeit (z. B. das Verlassen des Arbeitsplatzes ohne korrekte
Beendigung der Anwendung).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.25 Fahrlssiges Lschen von Objekten

Bei Novell Netware Version 4 ist es erstmalig mglich, das Objekt Admin,
welches bei der Installation automatisch angelegt wurde zu lschen. Das
Objekt Admin, welches den von Netware 3.x bekannten Supervisor ersetzt,
wird bei der Neuinstallation eines Netware 4-Netzes angelegt und besitzt zu
diesem Zeitpunk noch alle Administrationsrechte. Aus der Mglichkeit dieses
Objekt zu lschen entstehen folgende Gefhrdungen:
- Wird kein Ersatzadministrator ("Ersatz-Admin") als Objekt in der NDS zu
erzeugt, besteht die Gefhrdung das die NDS oder einzelne Container nicht
mehr administriert werden knnen. Daraus resultiert dann die Not-
wendigkeit, die NDS neu zu installieren und alle enthaltenen Objekte neu
zu erzeugen, was zu einem vollstndigen Ausfall des Netware 4-Netzes
fhren kann.
- Bei einer dezentralen Administration eines Netware 4-Netzes werden
blicherweise Administratoren auf Organisationsebene (Containerebene)
eingerichtet. Durch den IRF (Inherited Rights Filter) kann von diesen das
Vererben von Rechten anderer Administratoren auf untergeordnete Orga-
nisationen eingeschrnkt bzw. verhindert werden, so dass nur noch der
dezentrale Administrator alle Rechte hat. Wird dieser nun in der NDS
gelscht, kann eine komplette organisatorische Einheit nicht mehr
administriert werden, da die anderen Administratoren auf diesen Container
keinen Zugriff mehr haben. besser: Durch die dezentrale (Verteilung der
Administrationsaufgaben) Administration ist es nicht mehr mglich, den
Container durch andere Administratoren zu verwalten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.26 Ungewollte Freigabe des Dateisystems

Novell Netware Version 4 unterscheidet zwischen Objekt- und Dateirechten.
Objektrechte beinhalten die Berechtigungen zum Anlegen, ndern, Betrachten
oder Lschen von Objekten der NDS. Unter Dateirechten versteht man die
Berechtigungen zum Lesen, Schreiben, Lschen etc. von Dateien oder
Verzeichnissen. Das NDS Objekt "Server" stellt hierbei die einzige Schnitt-
stelle zwischen dem Objekt- und dem Dateisystem dar.
Aus diesem Grund erhlt jeder Benutzer, der als Supervisor fr ein Server-
objekt eingetragen ist, somit auch Supervisor-Rechte fr das komplette zuge-
hrige Dateisystem, da das Supervisor-Attribut nicht durch einen IRF
(Inherited Rights Filter) gefiltert werden kann. Dadurch bekommt er mg-
licherweise unbeabsichtigten Zugriff auf vertrauliche Daten, ohne dass dies
bemerkt wird, bzw. beabsichtigt war.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.27 Fehlerhafte Zeitsynchronisation

In Novell Netware 4.x knnen mehrere Server in einem Netz zusammen-
arbeiten. Um einen reibungslosen Ablauf der Netzdienste, wie z. B. Datums-
und Zeitangaben der Dateien, Revision und Protokollierung und die zeitlichen
Beschrnkungen bei der Anmeldung zu gewhrleisten, ist eine gleiche Uhrzeit
auf allen Servern von groer Bedeutung. Auch nderungen in einem
Verzeichnisbaum werden in Novell Netware Version 4.x mit einem Zeit-
stempel versehen, der die Reihenfolge der Abarbeitung bei der Aktualisierung
der NDS festlegt. Aus diesem Grund ist es wichtig, dass fr alle Netware 4.x
Server im Netz eine gemeinsame Zeit verwaltet wird.
Dabei knnen die folgenden Gefhrdungen auftreten:
- Wird vor der Installation eines Netware 4.x Servers die interne Hardware-
uhr des zugehrigen Rechners nicht berprft und ggf. angepasst, so kann
sich der neue Server u. U. nicht mit dem restlichen Netware 4.x Netz
abgleichen, und es besteht die Gefahr einer Fehlfunktion der NDS.
- Kommt es in einem Netz, welches das Einzelreferenz-Verfahren zur
Zeitsynchronisation nutzt, zum Ausfall der Zeitquelle, so ist keine Ersatz-
zeit mehr verfgbar. Dadurch knnen Datei- und Objektrechte unkontrol-
liert verndert werden.
- Vernderungen an der NDS, die aufgrund einer falschen Systemzeit einen
sehr weit in der Zukunft liegenden Zeitstempel haben, werden auch erst zu
diesem Zeitpunkt ausgefhrt. Dies kann zu Fehlern oder Problemen fhren,
die nur sehr schlecht oder gar nicht nachzuvollziehen sind, da eine sehr
groe Zeitspanne zwischen dem Absetzen und dem Ausfhren der
entsprechenden nderungen liegt.
- Wird an einem Netware 4.x Server nachtrglich eine Funkuhr angeschlos-
sen, aber die Sommer- bzw. Winterzeit-Umstellung nicht deaktiviert, so
wird eine zustzliche Stunde korrigiert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.28 Ungeeignete Konfiguration der aktiven

Netzkomponenten
Durch eine ungeeignete Konfiguration der Netzkomponenten kann es zu
einem Verlust der Verfgbarkeit des Netzes oder Teilen davon, zu einem
Verlust der Vertraulichkeit von Informationen oder zu einem Verlust der
Datenintegritt kommen. Dabei knnen insbesondere die folgenden Fehlkon-
figurationen unterschieden werden:
- Aktive Netzkomponenten, die zur Bildung von VLANs (Virtual LANs)
eingesetzt werden, segmentieren das Netz logisch. Im Fall einer Fehlkon-
figuration kann ggf. die Kommunikation innerhalb eines VLANs, zwischen
einzelnen oder zwischen allen VLANs zum Erliegen kommen. In
Abhngigkeit der VLAN-Strategie des betreffenden Herstellers betrifft dies
zum einen die Zuordnung von miteinander kommunizierenden Systemen
zu den gleichen VLANs, zum anderen auch das VLAN-Routing, insofern
ein solches durch die aktiven Netzkomponenten untersttzt wird.
Beispiel: Bei VLANs, die nur ber Router miteinander kommunizieren
knnen, werden die zentralen Infrastrukturserver, die beispielsweise Datei-
und Druckdienste bereitstellen, nicht gleichzeitig auch den VLANs der
Arbeitsplatzsysteme zugeordnet, Router sind ebenfalls nicht vorhanden. In
diesem Fall knnen einige Arbeitsplatzsysteme die Dienste der zentralen
Infrastrukturserver nicht nutzen, da diese in einem nicht erreichbaren Teil-
netz sind.
- Ein Netz kann durch den Einsatz von Routern mittels Teilnetzbildung
strukturiert werden. Fr eine Kommunikation zwischen den Teilnetzen ist
eine entsprechende Konfiguration der Router erforderlich, die hierzu die
Leitwege zwischen den verschiedenen Teilnetzen in Routing-Tabellen
vorhalten mssen. Routing-Tabellen knnen statisch oder dynamisch ver-
waltet werden. In beiden Fllen ist eine Kommunikation zwischen unter-
schiedlichen Teilnetzen nicht mglich, wenn die Routing-Tabellen keinen
Leitweg zwischen den betreffenden Teilnetzen enthalten. Zu einer Fehl-
konfiguration kann es dementsprechend durch eine fehlerhafte Definition
statischer Routing-Tabellen oder durch eine fehlerhafte Konfiguration der
Routing-Protokolle (wie z. B. RIP oder OSPF) kommen, die zum auto-
matischen Abgleich dynamischer Routing-Tabellen verwendet werden.
Beispiel: Eine Router-zu-Router-Verbindung ist durch einen statischen
Eintrag der entsprechenden IP-Adressen konfiguriert. Bei einer nderung
der IP-Adresse einer der Router oder durch das Zwischenschalten eines
weiteren Routers ist diese Kommunikationsstrecke nicht mehr verfgbar.
- Aktive Netzkomponenten, die in der Lage sind, Protokolle oder Netz-
adressen zu filtern, knnen mit dieser Technik eine Kommunikation
bestimmter Protokolle unterbinden oder eine Kommunikation zwischen
Systemen mit bestimmten Netzadressen verhindern. Eine Fehlkonfigu-
ration der betreffenden Filter kann entsprechend zu einer unerwnschten
Unterbindung der Kommunikation in Abhngigkeit des fehlkonfigurierten
Filters und der Art der Fehlkonfiguration fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ebenso knnen fehlkonfigurierte Filter dazu fhren, dass Verbindungen

aufgebaut werden, die Eindringlingen die Mglichkeit bieten, Angriffe
gegen IT-Systeme im geschtzten Netz durchzufhren. Je nach Art des
Angriffs kann daraus ein Verlust der Verfgbarkeit einzelner Netzkompo-
nenten oder auch des ganzen Netzes resultieren. Weiterhin knnen z. B.
durch die mgliche Manipulation der Verbindungswege Datenpakete
umgeleitet werden oder Datenpakete verndert oder mitgelesen werden.
Beispiele:
Ein Multiport-Repeater ist so konfiguriert, dass nur Systeme mit
bestimmten MAC-Adressen an bestimmte Ports angeschlossen werden
knnen. Nach einem Austausch der Netzkarte in einem der Endgerte und
der damit verbundenen nderung der MAC-Adresse, wird dieses System
keine Verbindung mehr zum Netz bekommen (Verlust der Verfgbarkeit).
Durch eine ungeeignete Konfiguration von aktiven Netzkomponenten
(insbesondere von VLANs oder Filterregeln) knnen Broadcast-Domnen
unntig gro werden oder es knnen unntige Kommunikationsverbin-
dungen entstehen. Dadurch kann es Unbefugten mglich sein, vertrauliche
Daten zu lesen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.29 Fehlende oder ungeeignete Segmentierung

Lokale Netze knnen physikalisch durch aktive Netzkomponenten oder
logisch durch eine entsprechende VLAN-Konfiguration segmentiert werden.
Dabei werden die angeschlossenen IT-Systeme eines Netzes auf verschiedene
Segmente verteilt. Dies verbessert die Lastverteilung innerhalb des Netzes und
erhht dessen Administrierbarkeit.
Dabei kann es zu folgenden konkreten Gefhrdungen kommen:
- Verlust der Verfgbarkeit
Durch eine hohe Anzahl von IT-Systemen innerhalb eines Schicht-2-
Segments erhht sich in diesem die Netzlast. Dies kann die Verfgbarkeit
dieses Netzsegmentes stark beeintrchtigen oder sogar zu dessen ber-
lastung und Ausfall fhren. Bei CSMA/CD-basierten Netzzugangs-
protokollen (z. B. Ethernet) kommt es daneben hufiger zu Kollisionen,
wodurch sich die verfgbare Bandbreite reduziert. Eine ungeeignete
Segementierung kann auch dann vorliegen, wenn Systeme durch aktive
Netzkomponenten der Schicht 2 oder 3 getrennt werden, die sehr viel
miteinander kommunizieren.
- Kein ausreichender Schutz der Vertraulichkeit
Um einen Schutz vertraulicher Daten gewhrleisten zu knnen, sollten
auch nur die unbedingt notwendigen Benutzer darauf Zugriff haben.
Broadcast-Domnen sind daher auf das unbedingt notwendige Ma zu
beschrnken. Wurden die einzelnen Segmente jedoch ungeeignet konfi-
guriert, knnen nun auch andere Benutzer die bertragenen Nachrichten
mit vertraulichen Daten mitlesen und ggf. auswerten.
Beispiele:
- Zwei IT-Systeme, die groe Datenmengen austauschen, sind durch einen
Router getrennt. Dies kann eine ungeeignete Segmentierung darstellen, da
der Datenverkehr durch einen relativ langsamen Router gefhrt werden
muss.
- Zwei IT-Systeme, die hufig Passwrter oder andere sensitive Informa-
tionen austauschen, sind durch eine Brcke getrennt. Dies bedingt, dass
dieser Datenverkehr in beiden Segmenten abgehrt werden kann. Die
Begrenzung des Datenverkehrs zwischen diesen beiden IT-Systemen auf
ein Segment wrde einen hheren Schutz der Vertraulichkeit mit sich
bringen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.30 Unerlaubte private Nutzung des dienstlichen

Telearbeitsrechners
Im huslichen Bereich ist es einfacher, den dienstlichen Telearbeitsrechner
privat zu nutzen, weil Kontrollen durch den Arbeitgeber nur bedingt mglich
sind. Dadurch besteht die Gefahr, dass nicht geprfte Software eingesetzt wird
oder virenverseuchte Daten auf den Telearbeitsrechner gelangen. Diese uner-
laubte Nutzung des Telearbeitsrechners kann nicht nur durch den Telearbeiter
selbst, sondern auch durch Angehrige oder Besucher erfolgen. Insbesondere
Kinder und Jugendliche knnen versucht sein, den Telearbeitsrechner fr
Spielzwecke zu verwenden, teilweise sogar, ohne dass der Telearbeiter dies
merkt. Mgliche Schden sind beispielsweise: gelschte Festplatten mit
Totalverlust der Daten, Reinstallationskosten oder Nacherfassungsarbeiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.31 Unstrukturierte Datenhaltung

Durch unzureichende Vorgaben und/oder fehlende Schulung der Mitarbeiter
kann es zu einer unbersichtlichen Speicherung der Daten auf den benutzten
Datentrgern kommen. Dadurch kann es zu verschiedenen Probleme kommen
wie:
- Speicherplatzverschwendung durch mehrfache Speicherung von Dateien,
- vorschnelle Lschung oder nicht erfolgte Lschung von Daten, da keiner
mehr wei, was in welchen Dateien gespeichert ist,
- unbefugte Zugriffe, wenn sich Dateien in Verzeichnisse oder auf
Datentrgern befinden, die Dritten zugnglich gemacht werden, oder
- nicht konsistente Versionsstnde in verschiedenen Verzeichnen und IT-
Systemen.
Beispiel:
Es wurde unterlassen, einen neuen Mitarbeiter mit wenig IT-Erfahrung in die
strukturierte Datenhaltung einzuweisen. Bereits nach kurzer Zeit traten
Probleme auf, weil der Benutzer alle Dateien im Hauptverzeichnis gespeichert
hatte, ohne auch nur ein Unterverzeichnis anzulegen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.32 Versto gegen rechtliche Rahmenbedingungen

beim Einsatz von kryptographischen Verfahren
Beim Einsatz kryptographischer Produkte sind diverse gesetzliche Rahmen-
bedingungen zu beachten. In einigen Lndern drfen beispielsweise krypto-
graphische Verfahren nicht ohne Genehmigung eingesetzt werden. Dies kann
dazu fhren, dass bei der bermittlung verschlsselter Datenstze in solche
Lnder die Empfnger diese nicht lesen knnen, da sie die bentigten
Kryptomodule nicht einsetzen knnen, oder sich vielleicht sogar strafbar
machen.
Auerdem ist in sehr vielen Lndern auch der Export von Produkten mit
starker Kryptographie erheblich eingeschrnkt. Hier sind insbesondere die
USA zu nennen. Bei Exportrestriktionen wird hufig die Strke von an sich
starken Verschlsselungsprodukten knstlich (durch Reduzierung der Schls-
selmannigfaltigkeit) herabgesetzt. Solche knstlich geschwchten Verfahren
bieten teilweise nicht einmal fr mittleren Schutzbedarf ausreichenden Schutz.
Dies gilt z. B. fr aus den USA stammende PC-Standardsoftware wie Internet-
Browser (SSL), in denen nur eine reduzierte Schlssellnge von 40 Bit
eingesetzt wird. Teilweise erfordern die Exportregelungen aber auch, dass
Teile der Schlssel hinterlegt werden, so dass die Kryptomodule zwar im
Prinzip uneingeschrnkt nutzbar sind, aber fr die auslndischen Nachrich-
tendienste eine Zugriffsmglichkeit im Bedarfsfall bleibt.
Auf der anderen Seite knnen solche Einschrnkungen, die beim Einsatz
innerhalb mancher Lnder bzw. beim Export gelten, dazu verleiten,
schtzenswerte Daten unverschlsselt zu lassen oder mit minderwertigen
Kryptoprodukten zu schtzen. Dies kann zum einen Angreifern Tr und Tor
ffnen und zum anderen auch zum Versto gegen nationales Recht fhren. So
kann durch Datenschutzgesetze der Einsatz adquater kryptographischer
Verfahren zum Schutz personenbezogener Daten vorgeschrieben sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.33 Fehlbedienung von Kryptomodulen

Die Fehlbedienung von Kryptomodulen hat in der Praxis schon fter zu
Schden gefhrt. Diese Fehlbedienung kann verschiedene Auswirkungen
haben:
- Daten werden unverschlsselt bertragen, weil versehentlich der Klartext-
Modus im Kryptomodul aktiviert wurde.
- Bei der Eingabe von kryptographischen Schlsseln werden Schlsselteile
falsch eingegeben. Die Folge ist, dass weder der Sender (dem die Falsch-
eingabe nicht aufgefallen ist) noch der Empfnger (der den wirklich ver-
wendeten Schlssel nicht kennen kann) die mit dem falsch eingegebenen
Schlssel chiffrierten Daten korrekt entschlsseln knnen.
- Whrend des Verschlsselungsvorgangs wird die Stromzufuhr des
Kryptomoduls versehentlich ausgeschaltet. Dies hat zur Folge, dass nur
Teile der Daten verschlsselt vorliegen, andere Teile unverschlsselt. In
einem solchen Fall ist es mglich, dass eine Entschlsselung nicht mehr
mglich ist, weil der Vorgang unkontrolliert abgebrochen wurde.
- Bei Eingabe von Verschlsselungsparametern werden falsche Parameter
eingegeben. Dies kann zur Folge haben, dass nicht ausreichend sichere
Kryptoalgorithmen oder unsichere kryptographische Schlssel verwendet
werden.
- Wird der Anwender bei der Schlsselerzeugung beteiligt, in dem er bei der
Generierung des Schlssels zur Eingabe von zuflligen Zeichen aufge-
fordert wird, besteht eine Fehlbedienung auch darin, an dieser Stelle keine
zuflligen Zeichen, sondern bekannte oder leicht erratbare Zeichenketten
(Worte) zu verwenden.
Derlei Fehlbedienungen eines Kryptomoduls knnen dazu fhren, dass die
Vertraulichkeit, die Integritt und die Verfgbarkeit von Daten beeintrchtigt
wird. Als Beispiele seien genannt:
- Daten werden nicht oder nicht mehr verschlsselt, obwohl die Verschls-
selung zur Wahrung der Vertraulichkeit erforderlich wre.
- Verschlsselte Daten knnen nicht mehr entschlsselt werden, weil durch
die Fehlbedienung eine ordnungsgeme Nutzung des Kryptomoduls nicht
mehr mglich ist.
- Daten werden ungewollt oder absichtlich in einer Weise verschlsselt, die
nicht mehr rekonstruierbar ist, weil der notwendige kryptographische
Schlssel unbekannt ist.
- Korrekt verschlsselte Daten werden verndert, so dass die Daten dann
nicht mehr entschlsselbar sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.34 Ungeeignete Konfiguration des

Managementsystems
Fr den sicheren Einsatz eines Netz- und/oder Systemmanagementsystems ist
eine konsistente Konfiguration aller beteiligten Komponenten ntig. Zwar
werden die einzelnen Komponenten in der Regel von einer zentralen Instanz
aus verwaltet (Managementkonsole), das Managementsystem besteht jedoch
aus vielen Einzelkomponenten, die auf die zu verwaltenden Netzkomponenten
verteilt sind. Eine konsistente Konfiguration eines solchen Systems lsst sich
in zwei Bereiche unterteilen:
- Einerseits mssen die mit Hilfe des Managementsystems eingestellten
Konfigurationen der Systemkomponenten (z. B. Rechner, Router) insge-
samt konsistent sein. Ein Server sollte also so konfiguriert sein, dass alle
berechtigten Client-Maschinen zugreifen knnen, aber auch nur diese.
- Andererseits muss auch die Managementsoftware selbst konsistent
konfiguriert werden.
Wird beabsichtigt oder unbeabsichtigt die Konsistenz der Konfigurationen
verletzt, so arbeiten die Komponenten nicht mehr reibungslos zusammen, was
zu Sicherheitsproblemen fhren kann. Beispielsweise knnte ein Server nicht
mehr zugreifbar oder Zugriffsrechte zu offen gesetzt sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.35 Server im laufenden Betrieb ausschalten

Wird ein Netz durch ein Managementsystem verwaltet, so existieren
(insbesondere im Bereich Systemmanagement) Server mit Sonderaufgaben.
Auf den so genannten Managementservern werden in der Regel Datenbanken
mit Managementinformationen gehalten. Werden solche Server im laufenden
Betrieb einfach ausgeschaltet, so werden z. B. die im Speicher des Rechners
gehaltenen Daten nicht mehr auf das Dateisystem geschrieben. Dies hat zur
Folge, dass beim nchsten Start der Maschine Inkonsistenzen auch in den
Managementdaten existieren knnen. Groe Managementsysteme benutzen
deshalb in der Regel Datenbanken, die durch den Einsatz so genannter Trans-
aktionsmechanismen dafr sorgen, dass die Informationen in einen (alten)
konsistenten Zustand zurckversetzt werden knnen. Dies verringert die
Gefahr, kann sie jedoch nicht vollstndig beseitigen und kann sogar zum
Angriff genutzt werden (Ausnutzen einer alten Konfiguration mit weniger
restriktiven Zugriffsrechten).
Auch bei der elektronischen Archivierung kann es zu Fehlern kommen, wenn Ausschalten von Archiv-
systemen
das Archivsystem vollstndig oder in Teilen im laufenden Betrieb abgeschal-
tet wird. Ein Abschalten kann dazu fhren, dass Dokumente als archiviert
gelten, tatschlich aber nur unvollstndig oder gar nicht auf das Speicher-
medium geschrieben worden sind und daher nicht mehr reproduziert werden
knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.36 Fehlinterpretation von Ereignissen

Beim Einsatz eines Managementsystems ist es eine Aufgabe des jeweils ver-
antwortlichen Systemadministrators, die Meldungen des Managementsystems
zu analysieren und zu interpretieren, um dann geeignete Manahmen einzu-
leiten. In der Regel basieren die Meldungen des Managementsystems auf
berwachungsmechanismen, die Systemprotokolle unterschiedlichster Art
automatisch nach gewissen Regeln durchsuchen. Es ist dabei nicht einfach,
aus der Flle der anfallenden Protokolldaten automatisiert Anomalien, die auf
Systemfehler hindeuten, zu erkennen und entsprechende Meldungen an den
Systemadministrator zu erzeugen. Darber hinaus kann ein Fehler hier sogar
unentdeckt bleiben. Die eingehenden Meldungen mssen daher immer vom
Systemadministrator gesichtet und interpretiert werden, da die Meldungen (im
Fehlerfall) auf Fehlersymptome und deren (automatischer) Interpretation
beruhen. Ein Systemadministrator muss hier auch Fehlalarme und Falsch-
meldungen erkennen knnen. Werden Systemmeldungen vom Administrator
falsch interpretiert, so fhren vermeintlich korrigierende Gegenmanahmen
u. U. zu einer Verschlimmerung der Situation.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.37 Unproduktive Suchzeiten

Im Internet werden Millionen von Informationsseiten, Dokumente und
Dateien angeboten. Zum Navigieren in diesem riesigen Informationsangebot
wird eine durch einfachen Mausklick zu bedienende Querverweistechnik ver-
wendet. Sie erlaubt den schnellen Wechsel auf weiterfhrende Informations-
seiten, die ihrerseits wieder neue Querverweise auf weitere Seiten beinhalten.
Das Springen ber Querverweise von einer Informationsseite zu weiteren wird
als "Surfen" bezeichnet und kann zu sehr langen Suchzeiten fhren.
In vielen Organisationen wurden Internet-Dienste eingefhrt, ohne die damit
verbundenen Ziele und erwarteten Auswirkungen vorher konkret zu unter-
suchen. Die Schulungen und Hilfen fr die Benutzer sind hufig nicht aus-
reichend, so dass es zu unproduktiven Suchzeiten im vielfltigen Angebot des
Internets kommt. Die Kosten fr diese Abfragen sind oft weder den Benutzern
noch den IT-Verantwortlichen bekannt. Nach Schtzung einer
Unternehmensberatung entstehen durch Surfen sowie unntige und lang-
atmige Recherchen im Internet vermeidbare Personal- und Kommunikations-
kosten in mehrstelliger Millionenhhe je Jahr.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.38 Konfigurations- und Bedienungsfehler

Konfigurationsfehler entstehen durch eine falsche oder nicht vollstndige Ein-
stellung der Parameter und Optionen, mit denen ein Programm gestartet wird.
In diese Gruppe fallen z. B. falsch gesetzte Zugriffsrechte fr Dateien. Bei
Bedienungsfehlern sind nicht nur einzelne Einstellungen falsch, sondern es
werden IT-Systeme oder IT-Anwendungen falsch behandelt. Ein Beispiel
hierfr ist das Starten von Programmen, die fr den Einsatzzweck des Rech-
ners nicht notwendig sind, aber evtl. von einem Angreifer missbraucht werden
knnen.
Beispiele fr aktuelle Konfigurations- bzw. Bedienungsfehler sind das Spei- ungeprfte Software
chern von Passwrtern auf einem PC, auf dem ungeprfte Software aus dem
Internet ausgefhrt wird (solche Software wurde z. B. im Frhjahr 98 fr das
Aussphen von T-Online-Passwrtern eingesetzt), oder das Laden und Aus-
fhren von schadhaften ActiveX-Controls. Diese Programme, die u. a. die
Aufgabe haben, WWW-Seiten durch dynamische Inhalte attraktiver zu
machen, werden mit den gleichen Rechten ausgefhrt, die auch der Benutzer
hat - sie knnen also beliebig Daten lschen, verndern oder versenden.
Viele Programme, die fr die ungehinderte Weitergabe von Informationen in Offenlegung von
Informationen
einem offenen Umfeld gedacht waren, knnen bei falscher Konfiguration
potentiellen Angreifern Daten zu Missbrauchszwecken liefern. So kann bei-
spielsweise der finger-Dienst darber informieren, wie lange ein Benutzer
bereits am Rechner sitzt. Aber auch WWW-Browser bermitteln bei jeder
Abfrage einer Datei eine Reihe von Informationen an den WWW-Server (z. B.
die Version des Browsers und des verwendeten Betriebssystems, den Namen
und die Internet-Adresse des PCs). In diesem Zusammenhang sind auch die
Cookies zu nennen. Hierbei handelt es sich um Dateien, in denen WWW-
Server-Betreiber Daten ber den WWW-Nutzer auf dem Rechner des Nutzers
speichern. Diese Daten knnen beim nchsten Besuch des Servers abgerufen
und vom Server-Betreiber fr eine Analyse der vom Benutzer vorher auf dem
Server besuchten WWW-Seiten verwendet werden.
Der Einsatz eines Domain Name Systems (DNS), das fr die Umsetzung eines
Internet-Namens wie rechner1.universitaet.de in die zugehrige numerische
Adresse zustndig ist, stellt eine weitere Gefahrenquelle dar. Zum einen er-
mglicht ein falsch konfigurierter DNS-Server die Abfrage von vielen Infor-
mationen ber ein lokales Netz. Zum anderen hat ein Angreifer durch die
bernahme dieses Servers die Mglichkeit, geflschte IP-Nummern zu ver-
schicken, so dass jeglicher Verkehr von ihm kontrolliert werden kann.
Eine groe Bedrohung geht auch von den automatisch ausfhrbaren Inhalten aktive Inhalte
(Executable Content) in E-Mails oder HTML-Seiten aus. Dies ist unter dem
Stichwort Content-Security-Problem bekannt. Dateien, die aus dem Internet
geholt werden, knnen Code enthalten, der nur beim "Betrachten" und ohne
Rckfrage beim Benutzer ausgefhrt wird. Dies ist z. B. bei Makros in
Winword-Dateien der Fall und wurde zum Erstellen von so genannten Makro-
Viren ausgenutzt. Auch neue Programmiersprachen und -schnittstellen wie
ActiveX, Javascript oder Java, die fr Anwendungen im Internet entwickelt
worden sind, besitzen bei falscher Implementierung der Kontrollfunktionen
ein Schadpotential.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Verfgbarkeit des Sicherheitssystems RACF ist bei z/OS- Fehlerhafte RACF-
Betriebssystemen von zentraler Bedeutung fr die Verfgbarkeit des gesamten Datenbanken
Systems. Durch unsachgemen Einsatz von z/OS-Utilities bei der RACF-
Datenbanksicherung oder fehlerhafte Bedienung der RACF-Kommandos kann
diese eingeschrnkt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.39 Fehlerhafte Administration des RAS-Systems

Die fehlerhafte Administration von RAS-Komponenten stellt ein nicht zu
vernachlssigendes Risikopotential dar. Auch RAS-Systeme sind - ab einer
gewissen Gre und Struktur - komplexe Systeme, deren korrekte und sichere
Konfiguration nur von geschulten Systemadministratoren zu leisten ist. Fehler
in der Administration wirken sich in der Regel sehr stark auf die Stabilitt und
Sicherheit aus, da ein Administrator privilegierte Rechte im System besitzt.
Fr RAS-Systeme sind hier u. A. folgende Probleme zu nennen:
- Sicherheitsrelevante Routineaufgaben auf dem RAS-Client werden hufig Vernachlssigung
sicherheitsrelevanter
vernachlssigt. Dazu gehren z. B. die regelmige Datensicherung oder Routineaufgaben
die Prfung auf Computer-Viren. Insbesondere mobile RAS-Clients
werden vom jeweiligen Benutzer mitgefhrt und sind daher nur selten fr
die Systemadministration verfgbar. Zwar kann auch eine entfernte
Administration whrend einer aufgebauten RAS-Verbindung erfolgen, je
nach Nutzungsprofil sind die Verbindungszeiten jedoch zu kurz, um eine
geregelte Fernwartung durchzufhren. Werden die regelmigen admini-
strativen Aufgaben jedoch nicht durchgefhrt, so kann es zu nicht abge-
stimmten Konfigurationen kommen.
- Die Fernadministration von Rechnern kann mit Hilfe von verbreiteten unautorisierte
Verwendung von Soft-
Software-Produkten erfolgen und wird vielfach schon in Anstzen durch ware zur entfernten
Mechanismen des Betriebssystems mglich. Die Verwendung unauto- Administration
risierter Software (durch den Benutzer oder den Administrator) fhrt oft
dazu, dass entweder nicht erlaubte Protokolle ber eine RAS-Verbindung
verwendet werden oder Einstellungen erfolgen, die nicht konform mit der
geltenden Sicherheitsrichtlinie sind und somit Sicherheitslcken ffnen
knnen.
- Wenn die Computer-Viren-Prfung ausschlielich auf dem Server statt- Verschlsselung und
Virenschutz
findet, ist die Client-seitige Datenverschlsselung problematisch. ber
RAS-Verbindungen knnen viele Applikationsprotokolle abgewickelt
werden, so dass auch der Transport von E-Mail, WWW-Inhalten oder
Dateien mglich ist. Verschlsselte Daten knnen in diesem Fall von
Server-seitigen Computer-Viren-Schutzprogrammen nicht mehr auf Viren
untersucht werden.
- Auf dem RAS-Client ist kein oder kein aktuelles Computer-Viren-Schutz- fehlender Virenschutz
auf RAS-Clients
programm installiert oder nicht aktiviert. Da RAS-Clients in vielen Fllen
in unsicheren Umgebungen betrieben werden und somit beispielsweise der
Austausch von Datentrgern praktisch nicht kontrolliert werden kann,
stellen Computer-Viren eine besonders starke Gefhrdung dar. Insbeson-
dere besteht die Gefahr, dass Computer-Viren oder Trojanische Pferde ber
den RAS-Client in das LAN gelangen.
- Werden bandbreitenintensive Funktionen ber RAS-Verbindungen ausge- lange Antwortzeiten
durch unzureichende
fhrt, so besteht die Gefahr, dass der Benutzer die RAS-Verbindung Bandbreite
unterbricht und neu aufbaut, weil er davon ausgeht, dass eine Strung vor-
liegt. In Wirklichkeit ist jedoch lediglich die Antwortzeit unakzeptabel
lang, da die Bandbreite nicht ausreicht. Hierdurch knnen einerseits
Inkonsistenzen in den Anwendungsdaten durch den nicht erwarteten Ver-
bindungsabbruch und andererseits erhhte Belastungen des RAS-Systems
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
durch die wiederholten Verbindungswnsche mit anschlieendem Abbruch

entstehen.
- Eine generelle Gefahr bei unzureichender Administration sind inkompa- falsch konfigurierte
Komponenten zur
tibel oder fehlerhaft konfigurierte Hard- oder Software-Komponenten zur Kommunikation
Kommunikation, da diese die RAS-Verbindungen erst ermglichen. Hier
reichen die Fehlkonfigurationen von fehlenden Sicherheitseinstellungen bis
hin zu inkompatiblen Kommunikationsprotokollen. Ebenso breit gestreut
sind auch die daraus resultierenden Konsequenzen, beispielsweise kommen
gewnschte Verbindungen nicht zustande oder nicht autorisierte Dritte
knnen sich erfolgreich verbinden.
Beispiele:
- Ein Auendienstmitarbeiter nutzt den Replikationsmechanismus eines
Groupware-Produktes, um seine lokale Kopie einer technischen
Referenzdatenbank regelmig auf den neuesten Stand zu bringen. Durch
die Fehlkonfiguration des Replikationsmechanismus wird die Replikation
auch immer nach dem RAS-Verbindungsaufbau angestoen, so dass die
Verbindung ber Mobiltelefon-Modem nach erfolgreichem Aufbau
scheinbar immer "stehen bleibt".
- Ein Unternehmen setzt ein Softwaremanagementsystem ein, das regel-
mig neue Software-Updates auf den einzelnen Benutzerrechnern instal-
liert. Aufgrund eines Konfigurationsfehlers werden in dieses Verfahren
auch die mobilen RAS-Clients mit einbezogen. Nach erfolgreichem Ver-
bindungsaufbau wird dann die gesamte Bandbreite durch die Manage-
mentsoftware in Anspruch genommen, die ein greres Update-Paket auf
dem Rechner installieren will.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.40 Ungeeignete Nutzung von

Authentisierungsdiensten bei Remote Access
Die Identitt der RAS-Benutzer muss beim Verbindungsaufbau festgestellt Inkonsistente RAS-
werden. Dazu werden typischerweise Authentisierungsmechanismen verwen- Benutzerverwaltung
det, die auf einer Benutzerverwaltung mit gespeicherten Authentisierungs-
daten beruhen. RAS-Systeme bieten fr die Speicherung der Benutzerdaten
mehrere Mglichkeiten an: eine eigene Benutzerverwaltung, Nutzung der
Benutzerverwaltung des Betriebssystems, Nutzung von Authentisierungs-
servern (mit eigener Benutzerverwaltung). Werden getrennte Benutzerver-
waltungen fr RAS und Betriebssystem verwendet, so kann es aufgrund von
Strungen im organisatorischen Ablauf zu Inkonsistenzen in den beiden
Datenbestnden kommen. Dies kann zu unerlaubten Verbindungsaufnahmen
und unberechtigten Zugriffen auf Daten fhren. Eine getrennte Verwaltung
empfiehlt sich daher nicht.
Beispiel:
- Beim Ausscheiden eines Mitarbeiters wird das Benutzerkonto nicht in der
RAS-Benutzerverwaltung gelscht. Der ehemalige Mitarbeiter kann sich
daher immer noch ber den RAS-Zugang einwhlen und auf allgemein
zugngliche Daten zugreifen. Der Zugang kann auch dazu benutzt werden,
weitere Angriffe durchzufhren.
Viele Client-Komponenten fr den Remote Access erlauben es, die zur Speichern von Authen-
tisierungsdaten auf dem
Authentisierung notwendigen Daten nach einmaliger Eingabe lokal zu RAS-Client
speichern, so dass beim erneuten Verbindungsaufbau die Eingabe der Daten
durch den Benutzer nicht mehr erforderlich ist. Dies birgt jedoch ein hohes
Risikopotential fr den Fall, dass der RAS-Client einem unberechtigten
Zugriff ausgesetzt ist. Der Authentisierungsmechanismus kann dann seine
Aufgabe nicht mehr erfllen. Dadurch knnen Unbefugte ggf. auf die lokalen
Netze zugreifen, die ber eine RAS-Verbindung vom jeweiligen Client aus
erreichbar sind. Die Sicherheit dieser lokalen Netze ist somit gefhrdet.
hnliche Gefhrdungen ergeben sich durch das Speichern von Schlsseln zur
Datenverschlsselung oder digitalen Signatur auf dem RAS-Client.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.41 Fehlverhalten bei der Nutzung von RAS-

Diensten
Ohne geeignete Schulung der Anwender kann es - wie bei jedem anderen IT-
System - durch (meist unbewusstes) Fehlverhalten bei der RAS-Nutzung bzw.
im Umfeld der RAS-Nutzung zu Sicherheitsproblemen (z. B. Versto gegen
die IT-Sicherheitsrichtlinien, Fehlkonfiguration) kommen.
Weiterhin werden stationre und mobile IT-Systeme, auf denen RAS-Client-
Software installiert ist, hufig nicht nur zum Zugriff auf ein LAN benutzt.
Insbesondere wenn die RAS-Verbindung ber das Internet aufgebaut wird,
erfolgt oft auch die Nutzung von WWW und E-Mail ber diese IT-Systeme.
In manchen Fllen wird auch auf fremde Netze zugegriffen, beispielsweise
wenn Auendienstmitarbeiter mit mobilen RAS-Clients Verbindungen zu
Kundennetzen aufbauen. Dadurch ergeben sich folgende Gefhrdungen:
- Durch den Aufbau nicht genehmigter Verbindungen wird das System Aufbau nicht
genehmigter RAS-
mindestens unntig belastet, da jeweils eine berprfung auf die Zulssig- Verbindungen
keit durchgefhrt werden muss. Auf diese Weise werden unntigerweise
Systemressourcen belegt. In Kombination mit Fehlkonfigurationen kann es
auch dazu kommen, dass unberechtigte Zugriffe erfolgreich durchgefhrt
werden.
- RAS-Clients knnen u. A. fr den Internet-Zugang eingesetzt werden. Hier Nutzung des RAS-
Clients im Internet
ergibt sich die Gefhrdung dadurch, dass bei Verbindungen mit dem
Internet ohne besondere Vorkehrungen (z. B. sichere Konfiguration, PC-
Firewall) u. U. auch von auen auf den Client-Rechner zugegriffen werden
kann. Dadurch ist der Rechner jedoch potentiellen Angriffen ausgesetzt.
Ein Angreifer kann so z. B. die Datenverschlsselung abschalten oder
andere RAS-Konfigurationsdaten verndern, so dass eine gesicherte RAS-
Kommunikation nicht mehr mglich ist. hnliche Probleme (Viren,
Trojanische Pferde) ergeben sich durch Software, die aus dem Internet
geladen und auf dem RAS-Client abgespeichert wurde.
- Wird ein RAS-Client an ein fremdes LAN angeschlossen (z. B. Anschluss des RAS-
Clients an ein fremdes
Kundennetz oder privates Heimnetz), so bestehen in diesem LAN oft Netz
weitere bergnge zu anderen Netzen (Internet, lokale Teilnetze). Je nach
Sicherheitsvorgaben der LAN-Verwaltung kann der unkontrollierte Zugriff
auf den RAS-Client mglich sein (siehe auch G 5.39 Eindringen in
Rechnersysteme ber Kommunikationskarten).
Beispiele:
- Auf einer Dienstreise verbindet sich ein Mitarbeiter ber Internet mit dem
Firmennetz. Vor dem Verbindungsaufbau mit dem RAS-System ldt er
eine ausfhrbare Datei von einem WWW-Server. Die Datei enthlt neben
der "offiziellen" Funktionalitt auch noch einen "bsartigen" Programm-
teil, der versucht, in der RAS-Konfiguration die Sicherheitsmechanismen
zu beeinflussen (z. B. Abschalten der Verschlsselung) und auf Daten im
Firmennetz zuzugreifen, wenn eine bestehende RAS-Verbindung vorge-
funden wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ein Auendienstmitarbeiter verbindet seinen Laptop mit dem Netz eines

Kunden. Um Daten mit dem Kunden austauschen zu knnen, gibt er lokale
Verzeichnisse fr Zugriffe aus dem Netz frei. Versehentlich wird bei dem
Datenaustausch auch die Datei bertragen, in der der Auendienst-
mitarbeiter seine Authentisierungsdaten abgelegt hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.42 Unsichere Konfiguration der RAS-Clients

Die Sicherheit des RAS-Systems hngt sowohl von der sicheren Konfigu- eingeschrnkte
ration der RAS-Server als auch der RAS-Clients ab. Unterliegt die Konfigu- Administrations-
ration des Servers noch der vollstndigen Kontrolle eines Administrators, so mglichkeiten bei RAS-
Clients
befinden sich RAS-Clients hufig auerhalb der Behrde bzw. des Unter-
nehmens. Damit kann der Rechner nur noch lose in administrative Ablufe
eingegliedert werden. Insbesondere beim Einsatz mobiler RAS-Clients knnen
Benutzer auch mit gewissen administrativen Rechten ausgestattet sein, um
Probleme beim RAS-Zugang durch ndern von RAS-Konfigurationspara-
metern selbst oder unter telefonischer Anleitung zu beheben.
Generell ergibt sich durch die eingeschrnkten Kontrollmglichkeiten der
Systemadministration die Gefahr, dass RAS-Clients unsicher konfiguriert
sind. Beispiele sind:
- Browser sind hufig sehr unbersichtlich zu konfigurieren, was immer unsichere Konfiguration
des Browsers
wieder zu Fehleinstellungen fhrt. Durch das Ausschalten von Sicher-
heitsmechanismen (z. B. Aktivieren von Java, JavaScript, ActiveX) kann
nicht vertrauenswrdige Software auf den Client gelangen.
- Problematisch ist auch die Installation nicht zugelassener Software auf dem
RAS-Client, da diese Sicherheitslcken aufweisen kann bzw. Computer-
Viren oder Trojanische Pferde eingeschleppt werden knnen.
- Die vorhandenen Sicherheitsmechanismen fr den RAS-Zugang werden
vom Benutzer in vielen Fllen nicht oder nicht korrekt eingestellt (siehe
auch G 5.91 Abschalten von Sicherheitsmechanismen fr den RAS-
Zugang).
- Zu weiteren Problemen kann es kommen, wenn inkompatible Authentisie- Nutzung inkompatibler
Authentisierungs-
rungsmechanismen zwischen RAS-Client und RAS-Server benutzt werden. mechanismen
So ist z. B. das Authentisierungsprotokoll MS-CHAP eines Windows 3.11-
RAS-Clients inkompatibel mit dem MS-CHAP-Protokoll eines
Windows NT 4.0-Servers. Dies fhrt dazu, dass Verbindungen nicht auf-
gebaut werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.43 Ungeeigneter Umgang mit Passwrtern

Selbst die Nutzung von durchdachten Authentikationsverfahren hilft wenig,
wenn die Benutzer nicht sorgfltig mit den bentigten Zugangsmitteln
umgehen. Unabhngig davon, ob Passwrter, PINs oder Authentikationstoken
zum Einsatz kommen, werden diese immer wieder weitergegeben oder
unsicher aufbewahrt.
Benutzer geben oft aus Bequemlichkeit Passwrter an andere Benutzer weiter. Weitergabe von
Passwrtern oder Token
Hufig werden Passwrter innerhalb von Arbeitsgruppen geteilt, um jedem
Mitarbeiter den Zugriff auf gemeinsam zu bearbeitende Dateien zu erleichtern.
Der Zwang zur Passwortbenutzung wird oft als lstig empfunden und dadurch
unterlaufen, dass Passwrter nie gewechselt werden oder alle Mitarbeiter
dasselbe Passwort benutzen.
Wird zur Benutzer-Authentisierung ein Token-basiertes Verfahren eingesetzt Verlust eines
Authentisierungs-
(z. B. Chipkarte oder Einmalpasswortgenerator), so ergibt sich bei Verlust die Tokens
Gefahr, dass das Token unberechtigt verwendet wird. Ein unberechtigter
Benutzer kann mit diesem Token u. U. erfolgreich eine Remote Access-
Verbindung aufbauen.
Durch die Vielzahl verschiedener Passwrter und PINs knnen sich Benutzer zu viele verschiedene
Passwrter
diese oftmals nicht alle merken. Daher werden Passwrter immer wieder
vergessen, was teilweise zu hohem Aufwand fhrt, um mit dem System
weiterarbeiten zu knnen. Authentikationstoken knnen ebenso verloren
werden. Bei sehr sicheren IT-Systemen kann der Verlust von Passwrtern
oder Token sogar dazu fhren, dass alle Benutzerdaten verloren sind.
Passwrter werden oft notiert, damit sie nicht vergessen werden. Dies ist Passwort unter der
Tastatur
solange kein Problem, wie sie sorgfltig, also vor unbefugtem Zugriff
geschtzt, aufbewahrt werden. Leider ist dies nicht immer der Fall. Ein
klassisches Beispiel ist die Passwortaufbewahrung unter der Tastatur oder auf
einem Klebezettel am Bildschirm. Auch Authentikationstoken finden sich
gerne unter der Tastatur.
Ein anderer Trick, um Passwrter nicht zu vergessen, ist die "geeignete" zu einfache Passwrter
Auswahl. Wenn Benutzer Passwrter selber auswhlen knnen und nicht
ausreichend fr die Probleme hierbei sensibilisiert sind, werden in vielen
Fllen Trivialpasswrter wie "4711" oder Namen von Freunden gewhlt.
Beispiele:
- In einem Unternehmen wurde bei Stichproben festgestellt, dass viele
Passwrter zu schlecht gewhlt bzw. zu selten gewechselt wurden. Es
wurde technisch erzwungen, dass die Passwrter monatlich gewechselt
wurden und auerdem Zahlen oder Sonderzeichen enthalten mussten. Es
stellte sich heraus, dass ein Administrator seine Passwrter wie folgt
auswhlte:
januar98, februar98, maerz98, ...
- In einer Behrde zeigte sich das Phnomen, dass Benutzer, die ihre Bros
zur Straenseite hatten, hufig dasselbe Passwort hatten: den Namen des
gegenberliegenden Hotels, der in groen Leuchtbuchstaben die Aussicht
dominierte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.44 Sorglosigkeit im Umgang mit Informationen

Hufig ist zu beobachten, dass zwar eine Vielzahl von organisatorischen oder
technischen Sicherheitsverfahren vorhanden sind, diese jedoch durch den
sorglosen Umgang mit der Technik wieder ausgehebelt werden. Ein typisches
Beispiel hierfr sind die fast schon sprichwrtlichen Zettel am Monitor, auf
denen alle Zugangspasswrter notiert sind. Auch andere Beispiele fr Nach-
lssigkeit, Pflichtvergessenheit oder Leichtsinn im Umgang mit schtzens-
werten Informationen finden sich in groer Menge.
Beispiele:
- In der Bahn oder im Restaurant geben Mitarbeiter oft intimste Unter- Mithrer
nehmensdetails ber ihr Mobiltelefon weiter. Dabei informieren sie jedoch
nicht nur den Gesprchspartner, sondern auch die Umgebung. Beispiele fr
besonders interessante Interna sind,
- warum der Vertrag mit einer anderen Firma nicht zustande kam oder
- wie viele Millionen der Planungsfehler in der Strategie-Abteilung gekostet
hat und wie das die Aktienkurse des Unternehmens drcken knnte, wenn
irgendjemand davon erfhre.
- Hufig ist es bei Dienstreisen erforderlich, ein Notebook, einen Organizer Mitnehmer
oder Datentrger mitzunehmen. Gerne werden diese dann whrend Pausen
im Besprechungsraum, im Zugabteil oder im Auto zurckgelassen. Bei
mobilen IT-Systemen sind die damit erfassten Daten oftmals nicht an
anderer Stelle gesichert. Wenn die IT-Systeme dann gestohlen werden,
sind damit die Daten unwiederbringlich verloren. Dazu kommt, dass sich
brisante Daten auch Gewinn bringend weiterveruern lassen, wenn der
Dieb mangels Verschlsselung und Zugriffsschutz einfach darauf zugreifen
kann.
- Ein Grund, ein Notebook oder Akten auf Dienstreisen mitzunehmen, ist Mitleser
auch, die Fahrzeiten produktiv nutzen zu knnen. Hierbei bieten sich Mit-
reisenden oft interessante Einblicke, da es in der Bahn oder im Flugzeug
kaum zu vermeiden ist, dass Sitznachbarn in den Unterlagen oder auf dem
Bildschirm mitlesen knnen.
ffentliche Rumlichkeiten, z. B. Hotel-Foyer, Hotel-Business-Center,
Zug-Abteil, bieten in der Regel nur wenig Sichtschutz. Gibt der Benutzer
Passwrter ein oder muss Vernderungen an den Konfigurationen vor-
nehmen, so kann ein Angreifer diese Informationen erlangen und miss-
bruchlich nutzen.
- Immer wieder sind in der Presse Artikel zu finden ber Behrden und brisante Informationen
im Altpapier
Unternehmen, in deren Hinterhfen sich hochbrisante Papiere im Alt-
papiercontainer fanden. Bekannt wurden auf diese Weise beispielsweise
die Gehaltszahlen aller Mitarbeiter eines Unternehmens und die geheimen
Telefonnummern von Unternehmensvorstnden.
- Wenn IT-Systeme Defekte aufweisen, werden diese schnell zur Reparatur Austausch von Kompo-
nenten bei Reparatur
gegeben. Meist besteht bei einem Defekt auch keine Mglichkeit mehr, die
auf dem IT-System gespeicherten Daten zu lschen. Bei einem Schaden
besteht aber hufig die erste Prioritt darin, mglichst schnell wieder ein
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
funktionierendes Gert zur Verfgung zu haben. Daher zeigen viele Fach-

hndler besonderen Kundenservice, indem sie die defekten Komponenten
einfach austauschen und die Kunden mit einem funktionsfhigen System
nach Hause schicken.
Es hat allerdings diverse Flle gegeben, bei denen der Kundendienst den
Fehler bei einer anschlieenden berprfung schnell beheben konnte und
der nchste Kunde ebenso kulant das jetzt reparierte Gert erhielt
- inklusive aller vom ersten Kunden erfassten Daten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.45 Unzureichende Identifikationsprfung von

Kommunikationspartnern
Bei persnlichen Gesprchen, am Telefon oder auch bei E-Mail sind viele Leichtfertige Weitergabe
Personen bereit, weit mehr Details zu uern, als sie das in schriftlicher Form von Interna
oder in grerer Runde tun wrden. Hierbei wird hufig vom Kommuni-
kationspartner stillschweigend erwartet, dass die Gesprchs- oder E-Mail-
Inhalte vertraulich gehandhabt werden. Darber hinaus besteht die Neigung,
die Identitt des Kommunikationspartners nicht zu hinterfragen, da dies als
unhflich empfunden wird. Dies gilt auch fr weitere Nachfragen zum Grund
des Anrufes oder dem Auftraggeber ("Ich arbeite fr die XY-Bank und ben-
tige noch einige detaillierte Angaben zu ihren Einkommensverhltnissen.").
Solche Verhaltensweisen werden auch beim "Social Engineering" ausgenutzt
(siehe auch G 5.42 Social Engineering).
Beispiel:
Es sind viele Flle bekannt, in denen Journalisten Prominente angerufen und
sich als andere Prominente ausgegeben haben. Damit gelang es ihnen, den
Prominenten Aussagen zu entlocken, die nicht fr die ffentlichkeit bestimmt
waren. Dies war besonders brisant bei einigen Direktbertragungen im Radio,
bei denen auch die Verffentlichung nicht mehr rckgngig zu machen war.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.46 Fehlkonfiguration eines Lotus Notes Servers

Fehlkonfigurationen eines Software-Systems sind hufig die Ursache fr
erfolgreiche Angriffe. Aufgrund der Komplexitt eines Notes-Servers besteht
auch hier die Gefahr, dass das Notes-System durch Fehlkonfiguration nicht
den geforderten Sicherheitsansprchen gengt. Durch die Flle an Konfi-
gurationseinstellungen und durch die sich gegenseitig beeinflussenden Para-
meter knnen auch viele Gefhrdungen entstehen. Einige typische Fehlkonfi-
gurationen werden im folgenden aufgefhrt:
- Fehlende Zugriffseinschrnkungen auf einen Server: In der Grundein-
stellung ist es generell jedem erlaubt, auf einen Notes-Server zuzugreifen.
Werden keine Zugriffsbeschrnkungen auf einen Server definiert, so wird
diese erste Hrde nicht genutzt. Insbesondere in der Kombination mit
schwachen oder falschen Zugriffsberechtigungen auf weitere Dienste oder
Datenbanken knnen so Sicherheitsprobleme entstehen.
- Fehlerhafte Zugriffslisten (Access Control Lists, ACLs) oder unsichere
Standard-ACLs: Jede Datenbank erhlt bei der Erzeugung eine (durch die
jeweilige Datenbankvorlage bestimmte) Zugriffsliste mit
Standardeintrgen. Je nach Vorlage bietet diese keinen ausreichenden
Schutz fr die Datenbank im Normalbetrieb. Dies gilt insbesondere dann,
wenn die Datenbank nach der Erzeugung initialisiert oder weiter konfi-
guriert werden muss. Oft sind dazu zunchst umfangreiche Rechte not-
wendig, die fr den laufenden Betrieb nicht mehr bentigt werden. Werden
die Standardzugriffslisten nicht verndert, kann dies dazu fhren, dass
Unbefugte auf die Datenbank zugreifen knnen oder Benutzern zu hohe
Rechte eingerumt werden.
- Es wird keine Verschlsselung eingesetzt: Die Verschlsselung der
Netzkommunikation (Port-Verschlsselung) und die Verschlsselung von
Datenbanken oder Datenbankfeldern ist in der Regel standardmig nicht
aktiviert. Um die Verschlsselung zu nutzen, muss diese explizit aktiviert
werden. Wird dies vergessen, so sind die Daten ungeschtzt.
- Unzureichende Berechtigungen fr Server oder administrative
Prozesse: Damit eine Notes-Datenbank korrekt funktionieren kann, muss
sie von einem dedizierten Server verwaltet und gewartet werden. Zu den
Verwaltungs- und Wartungsaufgaben eines Servers gehrt u. a. das Aktu-
alisieren von Datenbank-Kopien (Daten, Zugriffslisten, usw.). Sind dem
verantwortlichen Server keine ausreichenden Rechte eingerumt, so
schlagen die Verwaltungsaktionen fehl. Dies kann zu Sicherheitsproblemen
fhren, dass z. B. Vernderungen an den Zugriffsberechtigungen nicht an
die Kopien einer Datenbank weitergegeben werden knnen.
- Akzeptieren von Cross-Zertifikaten: Zwischen verschiedenen
Zertifikatshierarchien (ohne gemeinsame Zertifizierungsinstanz) knnen
Vertrauensstellungen eingetragen werden, indem eine sogenannte Cross-
Zertifizierung erfolgt (Anerkennen fremder Zertifikate). Cross-Zertifikate
knnen meist automatisch erzeugt werden, wenn ein unbekanntes Zertifikat
"entdeckt" wird. Dies gilt sowohl fr Notes-Zertifikate, als auch fr X.509-
Zertifikate. Dabei knnen Cross-Zertifikate auch von Benutzern einfach im
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
persnlichen lokalen Adressbuch erzeugt werden. Das Anlegen von Cross-

Zertifikaten im NAB kann dagegen nur durch einen berechtigten
Administrator erfolgen. Werden Zertifikate leichtfertig als
vertrauenswrdig anerkannt, so kann dies zu Sicherheitsproblemen (z. B.
bei aktiven Inhalten, die mit dem nun als vertrauenswrdig geltenden
Zertifikat signiert sind) fhren.
Die aufgefhrten Problemfelder sind Beispiele fr mgliche Gefhrdungen
durch Fehlkonfigurationen. Abhngig vom jeweiligen Einsatzumfeld knnen
weitere Gefhrdungen hinzukommen.
Beispiel:
Ein Server ist so konfiguriert, dass anonyme Zugriffe nicht gestattet sind. An
der Web-Schnittstelle sind nur SSL-Verbindungen erlaubt. Bei der Konfi-
guration der Datenbank-ACLs wird daher kein "Anonymous"-Eintrag erstellt.
Weiterhin wird auf das Erzwingen des SSL-geschtzen Web-Zugriffs verzich-
tet, da der Server nur SSL-Verbindungen an der Web-Schnittstelle annimmt.
Die "-Default-"-Rechte aus den Datenbank-Vorlagen wurden nicht gendert,
um den administrativen Aufwand bei Vorlagennderungen zu minimieren.
Durch die Einfhrung einer neuen Datenbank, die ffentliche Informationen
enthlt, wird der Server so konfiguriert, dass nun auch normale Web-Zugriffe
auf diese Datenbank erlaubt sind (anonym, nicht SSL geschtzt). Ab nun kann
auf alle Server-Datenbanken anonym zugegriffen werden, es gelten dabei die
"-Default-"-Rechte, die oft mindestens das Lesen erlauben. Dadurch besteht
die Gefahr, dass Unbefugte vertrauliche Daten einsehen oder Informationen
manipulieren knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.47 Fehlkonfiguration des Browser-Zugriffs auf

Lotus Notes
Erlaubt ein Notes-Server auch den Web-Zugriff, so erfolgt der Zugriff mit
zwei unterschiedlichen Mechanismen, die sich im benutzten Protokoll, in den
Authentisierungsmechanismen und in der Steuerung der Zugriffskontrolle
unterscheiden. Dadurch kann es insbesondere bei der Einfhrung des Web-
Zugriffes auf einen Notes-Server zu Fehlkonfigurationen kommen, die einem
Web-Benutzer u. U. mehr Rechte als gewnscht zuweist. Dies kann folgende
typische Ursachen haben:
- Der Web-Authentisierungsmechanismus ist zu schwach: Dies kommt in
der Regel durch eine Kombination von Problemen zustande:
- Wenn zur Authentisierung Benutzername und Passwort, aber kein
SSL zum Schutz der Authentisierungsdaten eingesetzt wird, kann
dadurch das Internet-Passwort abgehrt werden.
- Es werden SSL-Client-Zertifikate eingesetzt, der Client-Rechner ist
jedoch unzureichend geschtzt (z. B. kein Passwort auf der Zerti-
fikat-Datenbank). Hier besteht die Gefahr, dass die Client-Zertifikate
durch unberechtigte Dritte genutzt werden, ohne dass der
Zertifikatsinhaber dies bemerkt.
- Wenn die Option "anonymer Zugriff" freigeschaltet ist, kann dies in
Verbindung mit fehlerhaften Zugriffslisten (z. B. kein
"Anonymous"-Eintrag und "-Default-"-Eintrag erlaubt "Manager"
Rechte) zu unberechtigten Zugriffen auf Datenbanken fhren.
- Die Datenbank erzwingt nicht den SSL-geschtzten Zugriff: Obwohl
eine Datenbank sensitive Daten enthlt, die nur geschtzt bertragen
werden sollen, erzwingt die Datenbank-Konfiguration keine SSL-Verbin-
dung. Als Folge werden die Daten u. U. ungeschtzt bertragen, wenn SSL
nicht auf dem Server erzwungen wird oder die Konfiguration des Servers
gendert wird.
- Unzureichende Berechtigungseinschrnkungen: Fr den Web-Zugriff
knnen zustzliche Berechtigungseinschrnkungen auf Servern und
Datenbanken konfiguriert werden. Sind diese nicht konsistent eingestellt,
so kann z. B. durch direkte URL-Eingaben u. a. auf Datenbanken, Daten-
bankmasken oder Agenten zugegriffen werden.
Die aufgefhrten Problemfelder sind Beispiele fr mgliche Gefhrdungen
eines Notes-Systems durch Fehlkonfiguration der Web-Schnittstelle.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.48 Fehlkonfiguration von Windows 2000 Rechnern

Windows 2000 ist ein komplexes Betriebssystem, dessen Sicherheit im
Wesentlichen durch die eingestellten Parameter bestimmt wird. Dadurch erge-
ben sich insbesondere durch Fehlkonfiguration einzelner oder mehrerer
Komponenten Sicherheitsgefahren, die von Fehlfunktionen bis hin zur
Kompromittierung eines Windows 2000 Netzes fhren knnen.
- Bei der Migration von Windows NT zu Windows 2000 bleiben die Migration enthlt mehr
Risiken als
Zugriffsberechtigungen von Windows NT erhalten, die auch normalen Neuinstallation
Benutzern weitreichenden Zugriff auf Systemdateien erlauben. Damit ist
die Zugriffssicherheit bei migrierten Windows 2000 Systemen im
Allgemeinen niedriger als bei neu installierten Windows 2000 Systemen.
- Ist der Authentisierungsmechanismus NTLM unsicher konfiguriert, so ist
es durch Abhren des Netzverkehrs mglich, Benutzerpassworte zu rekon-
struieren. Dies war bisher vor allem bei der Nutzung alter NTLM-
Versionen kleiner 2.0 ein Problem, aber mittlerweile ist auch die Version
2.0 des NTLM Protokolls kompromittiert.
- Ist EFS falsch konfiguriert (etwa bei Verwendung lokaler Benutzerkonten Falsch konfigurierte
Verschlsselung schtzt
ohne aktiviertes SYSKEY-Kennwort), kann die EFS-Verschlsselung nicht
umgangen werden, wenn ein Angreifer physikalischen Zugriff auf den
Rechner hat.
Neben der reinen Betriebssystemkonfiguration ergeben sich Sicherheits-
probleme jedoch auch durch die fehlerhafte Konfiguration systemnaher
Komponenten wie DNS, WINS, DHCP, RAS oder IPSec. Gelingt es einem
Angreifer, diese Komponenten mit Erfolg anzugreifen, so ist die System-
sicherheit des gesamten Netzes gefhrdet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.49 Fehlkonfiguration des Active Directory

Windows 2000 gestattet die Delegation einzelner administrativer Rechte -
auch fr Teilbereiche des Active Directory - an bestimmte Benutzer. Diese
Delegation erfolgt durch die Vergabe detaillierter Einzelberechtigungen im
Active Directory.
Durch die hohe Komplexitt der Rechtevergabe, z. B. viele fr die einzelnen falsche Zugriffsrechte
Objekttypen spezifische Einzelberechtigungen, Vererbung von Berechti-
gungen, unzureichende Dokumentation, im Active Directory kann es gesche-
hen, dass
- Administratoren Zugriff auf Bereiche des Active Directory haben, zu deren
Administration sie nicht befugt sind, oder
- Bereiche des Active Directory nicht durch Zugriffsrechte geschtzt sind, so
dass jeder Benutzer auf diese Daten zugreifen kann.
Die Gefahr des unberechtigten Zugriffs bei Fehlkonfiguration der AD-
Zugriffsrechte erhht sich insbesondere dadurch, dass mehrere Zugriffs-
schnittstellen auf das AD existieren, z. B. ADSI, LDAP.
Besondere Gefhrdungen ergeben sich aus Handlungen, die die Datenbank-
struktur des Active Directory ndern:
- nderungen des Active Directory Schemas knnen dazu fhren, dass das Inkompatibilitten
bestehende Windows 2000 System zu anderen Softwarepaketen, die das
Active Directory nutzen, inkompatibel wird. Da sich nderungen des
Schemas z. T. nicht rckgngig machen lassen, kann dies bedeuten, dass
das bestehende System vllig neu aufgesetzt werden muss.
- Bei der Aufnahme eines personenbezogenen Attributes in den Global personenbezogene
Daten
Catalog des Active Directory besteht die Gefahr, dass personenbezogene
Daten auch jenseits des eigentlichen Adressatenkreises zugnglich sind.
Beispiel:
Innerhalb einer Firma werden die internen Telefonnummern der Mitarbeiter
im Active Directory abgelegt. Wenn die Rechner der Firma nur eine Domne
im Active Directory Baum eines greren Unternehmensverbundes bilden,
wrden diese internen Telefonnummern bei Aufnahme in den Global Catalog
an alle Domnen des Active Directory Baumes verteilt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.50 Fehlkonfiguration von Novell eDirectory

Fehlkonfiguration von Software ist eine der hufigsten Ursachen fr erfolg-
reiche Angriffe. Durch die hohe Komplexitt und die groe Zahl der verfg-
baren Parameter bei eDirectory knnen durch unbeachtete Seiteneffekte auch
zustzliche Sicherheitsprobleme eintreten.
Mgliche Fehlkonfigurationen betreffen unter anderem
- die Erstellung und Definition der Baumstruktur an sich,
- die Konfiguration des Zertifikatsservers,
- die Einrichtung der abzubildenden Objekte,
- die Konfiguration der Zugriffsmechanismen,
- die Vergabe der Zugriffsrechte (siehe G 3.51),
- die Konfiguration des Intranet-Clientzugriffs auf den Verzeichnisdienst
(siehe G 3.29),
- den LDAP-Zugriff auf eDirectory (siehe G 3.53),
- die Konfiguration der Partitionierung der Verzeichnisdatenbank,
- die Konfiguration der Replikation des eDirectory,
- die Konfiguration der aufzuzeichnenden eDirectory-Events,
- die Konfiguration des Real-time Alert-Mechanismus,
- die Konfiguration des iMonitor-Tools zur Web-basierten Fernberwachung
sowie
- die Konfiguration eines automatisierten Backup-Mechanismus.
Grundstzlich muss die Konfiguration des Systems an der Sicherheitsrichtlinie inkonsistente
Umsetzung der
ausgerichtet werden. Bei Fehlkonfiguration besteht die Gefahr, dass diese Sicherheitsrichtlinie
Richtlinie inkonsistent umgesetzt wird und damit die Zielsetzungen der
Sicherheitsvorgaben nicht erreicht werden.
eDirectory ermglicht die Konfiguration einer rollenbasierten Administration unautorisierte
Systemzugriffe
des Verzeichnissystems sowie die Delegation von Administrationsrechten. Bei
einer Fehlkonfiguration dieser Funktionalitten ergeben sich u. U. erhebliche
Probleme durch unautorisierte Systemzugriffe. Weiterhin besteht bei fehler-
hafter Konfiguration die Gefahr, dass eine geregelte Administration nicht
mehr mglich ist.
Folgende Liste gibt einen berblick ber die sicherheitsrelevanten mglichen
Konsequenzen einer Fehlkonfiguration des Novell eDirectory:
- Auswahl zu schwacher Authentisierungsmechanismen,
- Falsche Rechtevergabe fr den Zugriff auf die Objekte des Verzeichnis-
dienstes,
- unautorisierte Systemzugriffe ber die Administrationsschnittstelle,
- unzureichender Schutz vor Systemangriffen,
- Blockade der Administrationsmglichkeit des Systems,
- fehlerhafte oder langsame Replikation der Daten zwischen den Verzeich-
nisdatenbanken sowie
- Inkonsistenzen in der Umsetzung der Sicherheitsrichtlinie.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.51 Falsche Vergabe von Zugriffsrechten im Novell

eDirectory
Da eDirectory eine Reihe sensitiver Daten der Systembenutzer und -Ressour-
cen enthlt und zudem eine enge Beziehung zu dem unterliegenden Betriebs-
system besteht, ist die Vergabe von Zugriffsrechten auf das eDirectory beson-
ders wichtig.
Die Zugriffsrechte auf eDirectory-Objekte werden ber so genannte Access Access Control Lists
Control Lists (ACLs) vergeben. Dabei gibt es Zugriffsrechte auf das
eDirectory-Objekt an sich sowie auf einzelne Attribute eines Objekts.
Auf Objektebene sind dabei folgende Rechte (Privilegien) zu vergeben:
Browse, Create, Delete, Rename und Supervisor. Auf Attributsebene sind
dies: Compare, Read, Add or Delete Self, Write, Supervisor sowie Inheritance
Control. Compare wird dabei als Teil des Read-Rechtes behandelt, d. h.
sofern das Read-Recht vergeben ist, so besteht auch automatisch das Recht
Compare.
Die Access Control Lists selbst sind Attribute (Properties) zu den jeweiligen Inherited Rights Filter
eDirectory-Objekten. Die Zugriffsrechte auf eDirectory-Objekte vererben sich
standardmig von Vater- auf Kindobjekte innerhalb der Baumhierarchie. Um
zu verhindern, dass Brche dieses Vererbungsmechanismus durch Partitionie-
rung des eDirectory-Verzeichnisses entstehen, wird an das Wurzelobjekt der
Partition eine inherited ACL angehngt. Auf die Vererbung kann mit Hilfe so
genannter Masken oder Inherited Rights Filter Einfluss genommen werden.
Die Zugriffsrechte auf Attributsebene werden standardmig nicht entlang der
Verzeichnishierarchie weitergeleitet. Dies kann jedoch ber das Attributsrecht
Inheritance Control konfiguriert werden. Damit lsst sich auch das besonders
kritische Self-Recht kontrollieren.
Die Zugriffsrechte werden explizit mittels so genannter Trustee-Anweisungen Trustee-Anweisungen
vergeben. Dabei werden die Zugriffsrechte (Privilegien) auf das Target-Objekt
(Ziel) durch andere eDirectory-Objekte (Benutzer, Benutzergruppen, Services,
Anwendungen, Server, etc.) direkt in die ACL des Target-Objekts einge-
tragen.
Weiterhin knnen Zugriffsrechte indirekt durch so genannte Security-quiva- Security-quivalenzen
lenzen vergeben werden. Beispiel: Target-Objekt X erhlt (mindestens) die
gleichen Zugriffsmglichkeiten wie Target-Objekt Y, d. h. die Trustees von
Objekt Y werden automatisch auch Trustees von Objekt X. Dies wird eben-
falls als ACL-Eintrag von Objekt X konfiguriert.
Bei einem konkreten eDirectory-Zugriff werden stets die so genannten
effektiven Rechte berechnet, d. h. das Endresultat der oben beschriebenen
Konfigurationen.
Diese Vielfalt an Konfigurationsmglichkeiten der eDirectory-Zugriffsrechte
beinhaltet die Gefahr, dass inkonsistente oder falsche Zugriffsmglichkeiten
vergeben werden. Sofern die Zugriffsrechte im eDirectory falsch vergeben
werden, ist die Sicherheit des Gesamtsystems erheblich gefhrdet. Dies
betrifft die Vertraulichkeit und die Integritt von Daten sowie mgliche
Hintertren fr weitreichende Systemangriffe.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ein besonders kritischer Punkt ist auch die Vergabe der Administrations- Blockade der
rechte. eDirectory ermglicht die Umsetzung eines rollenbasierten Administ- Administration
rationskonzeptes sowie die Delegation einzelner Administrationsaufgaben
durch die Vergabe entsprechender Zugriffsrechte. Bei einer falschen Vergabe
dieser Rechte wird das gesamte Administrationskonzept in Frage gestellt und
unter Umstnden sogar die Administration des Verzeichnissystems blockiert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.52 Fehlkonfiguration des Intranet-Clientzugriffs auf

Novell eDirectory
Beim Einsatz des eDirectory-Verzeichnisdienstes im Intranet einer Organi-
sation werden fr den verteilten Benutzerzugriff auf das System entsprechende
Clients bentigt. Dabei gibt es fr die unterschiedlichen Betriebssysteme
jeweils eigene Client-Software:
- den Novell Client fr Windows-Betriebssysteme,
- eine Client-Library fr Linux,
- eine Client-Library fr Sun Solaris.
Der Clientzugriff auf den eDirectory-Verzeichnisdienst erfolgt ber das prop-
rietre NDAP-Protokoll (Novell Directory Access Protocol). Dieses setzt
seinerseits auf dem Novell NCP-Protokoll auf, welches ber IP oder IPX
betrieben werden kann.
Bei einem Zugriff mit Hilfe des Novell Clients fr Windows auf den
eDirectory-Baum (oder ein eDirectory-Objekt) muss der Benutzername und
das Passwort dem Client bermittelt werden. Der Client sucht dann beim
eDirectory nach dem entsprechenden Objekt und bermittelt dessen privaten
Schlssel, welcher mit dem Benutzerpasswort verschlsselt ist. Auf Client-
seite wird mittels des Benutzerpasswortes der private Schlssel entschlsselt
und daraus ein so genanntes Credential und eine Signatur berechnet. Der
private Schlssel wird anschlieend aus dem Speicher des Clients gelscht
und nur das Credential und die Signatur behalten. Diese knnen in der Folge
fr weitere "Hintergrundauthentisierungen" zu anderen Objekten oder
Diensten verwendet werden. Der Benutzer muss dafr nicht mehr in Inter-
aktion treten und nutzt somit einen Single-Sign-On.
Aus dem Credential und der Signatur wird mittels eines so genannten Zero-
Knowledge-Verfahrens ein Beweis (proof) generiert, welcher dem Zielsystem
bermittelt wird. Das Zielsystem kann mit dessen Hilfe die Identitt des
Clients verifizieren. Der Vorteil dieser Methode ist, dass die Signatur nicht
explizit ber das Netz bertragen wird und somit weniger Angriffsmglich-
keiten bestehen.
Trotzdem sind gewisse Angriffsszenarien, so genannte Man-in-the-middle-
Attacks, bekannt geworden, welche jedoch eher theoretischer Natur sind, da zu
deren Ausnutzung erheblicher technischer Aufwand betrieben werden muss.
Dessen ungeachtet kann es zu ernsthaften Sicherheitsproblemen kommen,
wenn
- die Authentisierungsmechanismen fr den Clientzugriff mangelhaft sind,
- ein unautorisierter Zugriff auf das eDirectory-Verzeichnis und dessen
Objekte mglich ist oder
- Administratorrechte fr den Verzeichnisdienst missbraucht oder unberech-
tigt erlangt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.53 Fehlkonfiguration des LDAP-Zugriffs auf Novell

eDirectory
Der LDAP-Zugriff auf den Verzeichnisdienst von eDirectory eignet sich vor
allem fr zwei Szenarien:
- den Benutzerzugriff auf den Verzeichnisdienst ber das Internet und
- den Zugriff auf den Verzeichnisdienst durch weitere Applikationen.
Prinzipiell gibt es aus Sicht des eDirectory drei Arten des Benutzerzugriffs
ber LDAP:
- als [Public] Objekt (Anonymous Bind),
- als Proxy User (Proxy User Anonymous Bind),
- als NDS User (NDS User Bind).
Dabei ist zu beachten, dass das [Public] Objekt im eDirectory standardmig bertragung der
Passwrter im Klartext
stets das Browse-Recht ber den Verzeichnisbaum besitzt, sofern dieses Recht
nicht explizit entzogen wurde. Weiterhin ist zu bercksichtigen, dass ohne die
Konfiguration geeigneter Authentisierungsmechanismen die Gefahr besteht,
dass die Benutzerpasswrter im Klartext bertragen werden. Eine Verschls-
selung der bertragung ist nur dann gegeben, wenn die Kommunikation
zwischen Client und eDirectory-Server ber SSL erfolgt.
Bei der SSL-Konfiguration ergeben sich ebenfalls Fehlermglichkeiten, fehlerhafte SSL-
Konfiguration
welche zu einer Herabsetzung des Sicherheitsniveaus oder der Performance
fhren knnen.
Weiter ist zu beachten, welche LDAP-Version die Clients untersttzen und
welche Konfigurationsmglichkeiten dort bestehen. Unter Umstnden kann es
dabei zu Missverstndnissen kommen und die Sicherheit des Betriebs beein-
trchtigt werden.
Fr die Anbindung von Netzapplikationen per LDAP an den eDirectory-
Verzeichnisdienst ergeben sich prinzipiell die gleichen Gefhrdungen wie
beim Zugriff von Clients, nmlich:
- der unautorisierte Zugriff auf das Verzeichnis,
- der Verlust der Integritt und der Vertraulichkeit der im Verzeichnis
gehaltenen Daten,
- die ungewollte Einrichtung einer Hintertr fr das System.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.54 Verwendung ungeeigneter Datentrger bei der

Archivierung
Fr die Speicherung von Daten werden Datentrger eingesetzt, die jeweils
einen definierten Einsatzbereich und Einsatzzeitraum aufweisen. Hierbei kann
es vorkommen, dass fr die Speicherung dauerhaft oder temporr Datentrger
verwendet werden, die den Anforderungen nicht gerecht werden.
Typische Ursachen hierfr sind beispielsweise
- Fehler bei der Beschaffung oder Bestellung der Datentrger,
- unzureichende Vorratshaltung, so dass nicht vorgesehene Datentrger
eingesetzt werden mssen, um Datenverlust zu vermeiden,
- falsche Kennzeichnung der Datentrger oder
- unzureichende Kenntnisse ber den Einsatzbereich des Datentrgers.
Der Einsatz ungeeigneter Datentrger kann zu einem Datenverlust fhren, der Datenverlust
auch erst nach einer lngeren Speicherdauer auftreten kann.
Beispiel:
Bei der routinemigen Beschaffung neuer Datentrger fr ein Archivsystem
werden anstatt einmalbeschreibbarer WORM-Medien (Write Once Read
Multiple) flschlicherweise wiederbeschreibbare Medien bestellt und geliefert.
In Folge der Verwechslung werden Archivdaten berschrieben. Da die
Speicherung der ursprnglichen Daten sehr lange zurckliegt, sind keine
Kopien der Originaldaten mehr vorhanden. Dadurch sind die ursprnglich
gespeicherten Dokumente unwiederbringlich verloren, da diese nur noch
elektronisch archiviert wurden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.55 Versto gegen rechtliche Rahmenbedingungen

beim Einsatz von Archivsystemen
Bei der Archivierung von elektronischen Dokumenten sind verschiedene
rechtliche Vorgaben zu beachten, deren Nichteinhaltung zivil- oder straf-
rechtliche Konsequenzen haben kann. Hervorzuheben sind hier u. a.
- Mindestaufbewahrungsfristen, die sich aus steuerlichen, haushaltsrecht-
lichen oder sonstigen Grnden ergeben,
- Vorgaben an die Hchstaufbewahrungsdauer, die sich aus Datenschutz-
regelungen ableiten,
- Zugriffsrechte, die fr Externe - wie z. B. Steuerbehrden - gewhrt wer-
den mssen, sowie
- die Rechtslage zur digitalen Signatur.
Einige Quellen fr rechtliche Rahmenbedingungen sind in der Manahme
M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr die elektronische
Archivierung aufgefhrt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.56 Fehlerhafte Einbindung des IIS in die

Systemumgebung
Der IIS wird weltweit in unterschiedlichen Umgebungen eingesetzt. Als
Einsatzumgebung wird die Netztopologie (Anordnung von weiteren Hard- und
Software-Komponenten, Netzkomponenten) verstanden, in der der IIS
betrieben wird. Als wesentlicher Aspekt ist dabei auch der Kommunikations-
bedarf des IIS mit anderen Systemen zu bercksichtigen.
Die Absicherung eines ffentlichen, aus dem Internet erreichbaren Servers ist
im Vergleich zu einem im Intranet installierten Server in der Regel mit einem
viel hheren Aufwand verbunden. Von entscheidender Bedeutung ist dabei
der sichere Einsatz geeigneter Trenneinrichtungen.
Eine unzureichend geplante Netzstruktur, z. B. ohne Demilitarisierte Zone
(DMZ) oder eine fehlerhaft konfigurierte Trenneinrichtung (Firewall), kann
fr einen Angriff aus dem Internet bzw. Intranet ausgenutzt werden.
Ein weiteres Risiko entsteht durch nicht ausreichend dimensionierte System-
ressourcen (Firewall, Netzanbindung). Wenn diese Systeme nicht den Anfor-
derungen an die Verfgbarkeit und Performance des eigentlichen Web-Servers
entsprechen, besteht die Gefahr eines Single-Point-of-Failure (SPOF).
Beispiel:
Mit Hilfe eines IIS und eines Datenbank-Servers wird eine E-Business-
Anwendung realisiert. Befindet sich der Datenbank-Server im gleichen Seg-
ment wie der IIS, auf den aus dem Internet zugegriffen werden darf, besteht
die Gefahr, dass ein Unbefugter auch auf die Datenbank zugreifen und die
vorhanden Datenbestnde auslesen oder manipulieren kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.57 Fehlerhafte Konfiguration des Betriebssystems

fr den IIS
Voraussetzung fr den sicheren Betrieb einer Applikation ist die Sicherheit
des verwendeten Betriebssystems. Da der IIS sehr stark mit dem Betriebs-
system verzahnt ist und z. B. die Benutzerdatenbank und Dateiberechtigungen
von Windows verwendet, ist eine sichere Konfiguration von Windows
NT/2000 von entscheidender Bedeutung fr den sicheren Betrieb.
Einige typische Fehlkonfigurationen werden im Folgenden aufgefhrt:
- Zu viele, nicht bentigte Dienste werden angeboten: Je mehr Dienste
und Services ein Server anbietet, desto grer sind die Angriffsmglich-
keiten auf die Verfgbarkeit des Rechners und die Vertraulichkeit und
Integritt der zu verarbeitenden Daten. Jeder Dienst bzw. Service kann
zustzliche Schwachstellen enthalten, die fr einen Angriff ausgenutzt
werden knnen. Insbesondere beim Netbios-Dienst besteht die Gefahr, dass
ein Angreifer Informationen ber vorhandene Benutzer, Freigaben usw.
abfragen kann.
- Grozgige Konfiguration der Netzeinstellungen: Windows ermglicht
eine Vielzahl von Netzeinstellungen in der Registry, ber die z. B.
Zeitbeschrnkungen fr eine Verbindung oder die Anzahl von gleichzei-
tigen Verbindungen definiert werden knnen. Fehlerhafte Einstellungen,
insbesondere von Timer-Werten, knnen einen DoS-Angriff auf den Server
ermglichen.
- Unzureichende Sicherung von Kennwrtern: Einen weiteren Angriffs-
punkt bilden leicht zu erratende oder nicht ausreichend geschtzte Pass-
wrter. Windows stellt verschiedene Werkzeuge zum Sichern der Pass-
wrter bereit, die bei der Auswahl von Passwrtern die Einhaltung einer
Sicherheitsrichtlinie erzwingen (z. B. passfilt.dll) oder den Zugriff und das
Auslesen von Passwrtern erschweren (z. B. passprop, syskey).
Die aufgefhrten Aspekte sind Beispiele fr mgliche Sicherheitsprobleme
durch Fehlkonfigurationen des Betriebssystems. Abhngig vom jeweiligen
Einsatzumfeld knnen weitere potentielle Sicherheitsprobleme hinzukommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.58 Fehlkonfiguration eines IIS

Fehlkonfigurationen eines Software-Systems sind hufig die Ursache fr
erfolgreiche Angriffe. Aufgrund der Komplexitt eines IIS und der vielfltigen
Einsatzmglichkeiten in Verbindung mit anderen Server-Systemen besteht
auch hier die Gefahr, dass das System durch Fehlkonfiguration nicht den
geforderten Sicherheitsansprchen gengt. Durch die Flle von Konfi-
gurationseinstellungen und durch die sich gegenseitig beeinflussenden Para-
meter knnen auch viele Sicherheitsprobleme entstehen. Einige typische
Fehlkonfigurationen werden im folgenden aufgefhrt:
- Zu viele, nicht bentigte Dienste werden angeboten: Je mehr Dienste
und Services ein Server anbietet, desto grer sind die
Angriffsmglichkeiten auf die Verfgbarkeit des Rechners und die
Vertraulichkeit und Integritt der zu verarbeitenden Daten. Jeder Dienst
bzw. Service kann zustzliche Schwachstellen enthalten, die fr einen
Angriff ausgenutzt werden knnen. Beispielsweise kann der FTP-Dienst
zum bertragen von Daten auf den Server ausgenutzt werden.
- Vertrauliche Informationen sind nicht ausreichend geschtzt, da sie
sich z. B. in zugnglichen Verzeichnissen befinden: In Abhngigkeit von
Aufgabe und Einsatzumgebung knnen auch persnliche Informationen,
z. B. durch die Auswertung von Formularen, auf dem Server vorhanden
sein. Sind diese Daten nicht ausreichend vor einem unberechtigten Zugriff
geschtzt, z. B. durch ACLs (Access Control Lists), knnen sie ggf. von
einem Angreifer ausgelesen werden.
- Eingabeparameter werden unzureichend geprft: Viele Programmierer
gehen bei der Entwicklung ihrer Anwendungen davon aus, dass vom
Benutzer geforderte Eingaben, z. B. in einem Formularfeld oder eine URL,
immer korrekt erfolgen. Die Prfung der Benutzereingaben wird oft auf die
fr die weitere Verarbeitung erforderlichen Bedingungen beschrnkt. Die
berprfung der Syntax oder der verwendeten Zeichen wird oft
vernachlssigt. Dabei besteht die Gefahr, dass Eingaben, die vom System
nicht erwartet werden, z. B. Sonderzeichen oder Buchstaben anstelle von
Zahlen, zu unntigen Ressourcenbelastungen und Pufferberlufen fhren
knnen und dadurch Sicherheitsfunktionen umgangen werden knnen.
- Fehlerhafte Zugriffslisten (Access Control Lists, ACLs): Der IIS ist eng
mit dem Betriebssystem verzahnt und nutzt auch die
Sicherheitsmechanismen von Windows fr den Zugriff auf Dateien und
Verzeichnisse. Oft werden die Zugriffsrechte sehr grozgig vergeben.
Beispielsweise gehrt das Konto IUSR_Computername, das bei der
Installation des IIS automatisch angelegt wird, standardmig der Gruppe
GAST an und besitzt somit die Rechte, auf Verzeichnisse auerhalb des
Webroot-Verzeichnisses zuzugreifen. Auch innerhalb von virtuellen
Verzeichnissen entstehen u. U. Risiken, wenn z. B. Scripts oder
ausfhrbare Programme verwendet werden. Sind die Zugriffsrechte nicht
restriktiv vergeben, besteht die Mglichkeit, dass diese Programme
ausgelesen oder verndert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.59 Unzureichende Kenntnisse ber aktuelle

Sicherheitslcken und Prfwerkzeuge fr den
IIS
Die Entwicklung in der Informationstechnik unterliegt einem stetigen Wandel.
Hard- und Software-Lsungen werden immer leistungsfhiger, Anwendungen
werden aktualisiert und durch neue Versionen ersetzt. Allerdings ergeben sich
durch diese Vernderungen auch neue Anforderungen an die Administratoren
und IT-Verantwortlichen. Sie unterliegen einer stndigen Informationspflicht,
um mit dem aktuellen Stand der Technik vertraut zu sein.
Bei unzureichenden Kenntnissen des Administrators besteht zum einen die
Gefahr, dass ein System fehlerhaft konfiguriert wird, zum anderen knnen
Bedrohungen in einer Situation falsch eingeschtzt werden. Insbesondere
durch die Komplexitt des IIS und das Zusammenwirken mit weiteren Syste-
men in einer heterogenen Systemumgebung knnen Risiken entstehen, die
vom Administrator zu bewerten sind.
Wichtige Informationsquellen fr den Administrator bilden die Verffent-
lichungen von aktuellen Schwachstellen (Bulletins) der eingesetzten Software.
Obwohl Microsoft bei Bedarf neue Service Packs fr Windows NT und
Windows 2000 verffentlicht, existieren fr Windows und den IIS Schwach-
stellen, die aufgrund ihrer Aktualitt noch nicht in die Service Packs aufge-
nommen worden sind. Aktuelle Schwachstellen werden von Microsoft oder
anderen Arbeitsgruppen und Organisationen verffentlicht.
Sind dem verantwortlichen Administrator die aktuellen Sicherheitslcken

nicht bekannt, kann dieser natrlich nicht die erforderlichen Sicherheitsma-
nahmen ergreifen, um das System gegen entsprechende Angriffe zu schtzen.
Zur Vereinfachung der Administration von Windows und des IIS bietet
Microsoft eine Reihe von Prfwerkzeugen an, die Bestandteil des
Windows NT/2000 Ressource Kit sind oder direkt aus dem Internet herunter-
geladen werden knnen. Beispielsweise besteht mit dem IIS Lockdown Tool
die Mglichkeit, in sehr kurzer Zeit eine Reihe von Sicherheitseinstellungen
vorzunehmen, insbesondere fr die Zugriffsbeschrnkung auf wichtige Da-
teien und Verzeichnisse. Ein weiteres Werkzeug ist das Hotfix Check Tool,
mit dem der Patchstatus von Windows NT und Windows 2000 geprft werden
kann.
Der Nachteil vieler Tools, die in die Administration eingreifen, besteht darin,
dass sie nur einen Teil der sicherheitsrelevanten Einstellungen vornehmen und
dass die einzelnen Funktionen nur unzureichend dokumentiert sind.
Beispiel:
Im Juli 2001 infizierte der Wurm Code Red in weniger als 14 Stunden ber
350.000 Computer in der ganzen Welt. Der Wurm nutzte eine Schwachstelle
aus, fr die seit einiger Zeit ein Patch von Microsoft verfgbar war. Selbst
Monate spter waren jedoch noch eine Vielzahl von Rechnern infiziert, weil
keine entsprechenden Sicherheitsmanahmen eingeleitet wurden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.60 Fehlkonfiguration von Exchange 2000 Servern

Generell ist die Fehlkonfigurationen eines Software-Systems hufig die
Ursache fr erfolgreiche Angriffe. Aufgrund der Komplexitt eines
Exchange 2000 Servers besteht auch hier die Gefahr, dass das Exchange
System durch Fehlkonfigurationen nicht den geforderten Sicherheitsan-
sprchen gengt. Durch die Flle an Konfigurationseinstellungen und durch
die sich gegenseitig beeinflussenden Parameter knnen zahlreiche Sicher-
heitsprobleme entstehen.
Einige typische Fehlkonfigurationen werden im folgenden aufgefhrt:
- Der Exchange 2000 Server wird auf einem Domnen-Controller und nicht Domnen-Controller
als Member Server innerhalb des Netzes installiert.
Dies hat erhebliche Konsequenzen fr die Administrationsrechte auf dem
Server und verhindert eine sinnvolle Rollentrennung der Administration.
Der Hintergrund ist, dass Exchange als Service unter dem Account Local
System abluft und somit die vollstndige Kontrolle ber den Rechner hat,
auf dem es abluft. Wrde Exchange auf einem Domnen Controller
laufen, so htte es unter anderem auch die Kontrolle ber die Kerberos-
Schlssel. Weiterhin ergeben sich Nachteile bezglich der Performance
und unter dem Aspekt der Ausfallsicherheit.
- Die Zugriffsbeschrnkungen auf einen Exchange 2000 Server sind unzu-
reichend.
Insbesondere in der Kombination mit schwachen oder falschen Zugriffsbe-
rechtigungen auf weitere Dienste oder E-Mail-Datenbanken knnen so
Sicherheitsprobleme entstehen.
- Zugriffslisten (Access Control Lists, ACLs) sind fehlerhaft oder es werden Access Control Lists
unsichere Standard-ACLs verwendet.
Jedes Exchange 2000 Objekt erhlt bei der Erzeugung eine Zugriffsliste
mit Standardeintrgen. Je nach Vorlage (Systemrichtlinie) bietet diese
keinen ausreichenden Schutz fr die E-Mail-Datenbank im Normalbetrieb.
Dies gilt besonders dann, wenn die E-Mail-Datenbank von Exchange 5.5
nach Exchange 2000 migriert wurde. Unter Exchange 5.5 haben einige
Objekte keinen Security Identifier (SID). Somit existiert fr diese Objekte
berhaupt keine ACL, bevor die SIDs nicht nachtrglich konfiguriert
wurden.
Oft sind fr die Erzeugung oder Initialisierung einer E-Mail-Datenbank
zunchst umfangreiche Rechte notwendig, die fr den laufenden Betrieb
nicht mehr erforderlich sind. Werden die Standard-ACLs nicht verndert,
kann dies dazu fhren, dass Unbefugte auf die E-Mail-Datenbank zugreifen
knnen oder Benutzern zu weitgehende Rechte eingerumt werden.
- Es wird keine Verschlsselung eingesetzt. keine Verschlsselung
Die Verschlsselung der Netzkommunikation (Port-Verschlsselung)

sowie der E-Mail-Kommunikation ist bei einer Standardinstallation nicht
aktiviert. Um die Verschlsselung zu nutzen, muss diese explizit einge-
richtet werden. Anderenfalls sind die E-Mail-Daten whrend des Zustell-
prozesses ungeschtzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die aufgefhrten Aspekte sind Beispiele fr mgliche Sicherheitsprobleme

durch Fehlkonfigurationen. Abhngig vom jeweiligen Einsatzumfeld knnen
weitere Problemfelder hinzukommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.61 Fehlerhafte Konfiguration von Outlook 2000

Clients
Der E-Mail-Client Outlook 2000 ist ein wichtiger Teil des E-Mail-Systems.
Die korrekte Konfiguration des Clients ist wichtig fr die Gesamtsicherheit
des Systems.
Folgende Aspekte sollten hierbei besonders erwhnt werden:
- Die Auswahl des Kommunikationsprotokolls kann spezielle Sicherheits- MAPI-Schnittstelle
probleme nach sich ziehen. Dabei sei besonders die MAPI-Schnittstelle
erwhnt, ber die sich in der Vergangenheit eine Reihe von Computer-
Viren und Wrmern verbreitet haben.
- Wird ein Client-PC von mehreren Benutzern in verwendet, so wird fr Benutzerprofile
jeden Benutzer ein eigenes Profil angelegt und gespeichert. Hierbei besteht
die Gefahr, dass dieses Profil durch einen Kollegen bernommen wird.
Dadurch kann unter Umstnden das Benutzerkonto einer Person gegenber
dem System unbefugt bernommen sowie die Vertraulichkeit von Daten
- Werden Verschlsselung und elektronische Signatur auf E-Mail-Ebene private Schlssel
eingesetzt, z. B. auf der Basis von S/MIME oder PGP, so kann unter
Umstnden der private Schlssel kompromittiert werden, sofern dieser
lokal abgespeichert wird. Mgliche Folgen sind, dass die Vertraulichkeit
der Daten beeintrchtigt und Rechte von Dritten unbefugt bernommen
werden.
- Wird Verschlsselung auf Netzebene eingesetzt, z. B. durch die Nutzung
von IPSec, SSL oder TLS, so besteht die Gefahr, dass diese Mechanismen
bei einer fehlerhaften Konfiguration des Client-PCs unwirksam werden.
- Eine fehlerhafte Konfiguration des E-Mail-Clients Outlook 2000 kann Datenverlust
auerdem zu einem Datenverlust sowie zu einer Blockade des Client-PCs
fhren. Weiterhin kann es zu einem berlauf und damit zu einer ber-
lastung des Exchange 2000 Servers kommen.
- Ist im Outlook 2000 Client die automatische Ausfhrung gefhrlicher Viren und aktive Inhalte
Dateiformate nicht in geeigneter Weise deaktiviert, so besteht die Gefahr,
dass Viren und schdliche aktive Inhalte eingeschleppt oder verbreitet
werden.
Die Terminverwaltung und die Aufgabenliste sind weitere Bestandteile des
Exchange/Outlook-Systems, die nicht direkt der Abwicklung des E-Mail-
Verkehrs dienen, sondern der Untersttzung des Workflows innerhalb einer
Organisation.
Diese Bereiche enthalten mitunter jedoch ebenso sensible und schtzenswerte
Informationen wie die elektronischen Nachrichten. Bei einer Fehlkonfigu-
ration dieser Teilsysteme bestehen somit folgende potentielle Sicherheits-
probleme:
- Verlust der Vertraulichkeit durch unbefugten Zugriff
- Verlust der Integritt der Informationen durch Datenmanipulation (zufllig
oder vorstzlich)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- unberechtigte bernahme der Rolle bzw. der Identitt eines anderen

Benutzers
- Verlust von Daten und Informationen durch unsachgeme Datenhaltung
und fehlende Backup-Vorkehrungen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.62 Fehlerhafte Konfiguration des Betriebssystems

fr einen Apache-Webserver
Eine fehlerhafte Konfiguration des Betriebssystems fr einen Apache-Web-
server kann den sicheren und fehlerfreien Betrieb des Servers stren oder die
Auswirkungen von Strungen verschlimmern.
Einige hufige Fehler bei der Konfiguration des Betriebssystems sind:
- Wenn die Partitionen bzw. Filesysteme nicht gro genug angelegt werden, Fehlerhaftes Filesystem-
Layout
dann kann es zu Betriebsstrungen kommen, wenn die Dateisysteme "voll-
laufen". Sind die Filesysteme auf einer einzigen Festplatte angelegt oder
schlecht auf verschiedene Festplatten verteilt, so kann dies zu einer deut-
lich verschlechterten Performance des Servers fhren.
- Falls auf dem Serverrechner unntige Netzdienste laufen, so kann dadurch Zu viele Netzdienste
die Sicherheit des Gesamtsystems gefhrdet sein. Oft sind in Standard-
installationen von Betriebssystemen auch zu viele Benutzer eingerichtet
oder Benutzer haben zu viele oder falsche Rechte.
- Sind auf dem Serverrechner Compiler oder Interpreter fr Skriptsprachen Zu viele installierte Pro-
gramme
installiert, so knnen diese von Angreifern, die sich Zugang zum Server
verschafft haben, fr weitere Angriffe benutzt werden. Oft erfordern be-
stimmte Schritte auch das Herunterladen von Dateien von Rechnern, die
der Angreifer kontrolliert. Dazu bentigt der Angreifer eventuell einen
Telnet-, ssh- oder ftp-Client oder Download-Tools wie wget, die fr den
normalen Serverbetrieb nicht ntig sind.
- Oft sind die betriebssystemseitigen Zugriffsberechtigungen fr die Pro- Zu grozgige Zugriffs-
berechtigungen
gramm- und Konfigurationsdateien eines Apache-Webservers und
fr .htpasswd-Dateien so gewhlt, dass zu viele lokale Benutzer Lese- oder
gar Schreibzugriff auf diese Dateien haben. Dadurch knnen Unbefugte
Informationen ber die Konfiguration des Servers erlangen, die eventuell
einen Angriff erleichtern oder erst ermglichen. Haben Unbefugte Lese-
berechtigung auf .htpasswd-Dateien, so knnen die Passwrter fr den
Zugriff auf geschtzte Bereiche des Webangebotes leicht ber einen Brute-
Force-Angriff geknackt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.63 Fehlerhafte Konfiguration eines Apache-

Webservers
Obwohl die Default-Konfiguration der Quelltext-Distribution eines Apache-
Webservers relativ sicher ist, kann es erhebliche Sicherheitslcken verur-
sachen, wenn fr den Apache-Webserver eine Default-Konfiguration einfach
bernommen oder nur geringfgig abgendert wird.
Bei der Konfiguration eines Apache-Webservers knnen verschiedene Fehler
gemacht werden. Einige hufige Fehler werden hier kurz erlutert:
- Apache-Distributionen von Betriebssystemherstellern oder Distributoren
enthalten oft zu zu viele Module, die im speziellen Einsatzszenario nicht
bentigt werden. Wird ein solches nicht bentigtes Modul geladen, so kann
dies die Sicherheit des Servers dadurch gefhrden, dass die Administrato-
ren nicht reagieren, wenn in einem solchen Modul eine Sicherheitslcke
bekannt wird, weil sie meinen, nicht davon betroffen zu sein.
- Werden Pfade fr Protokolldateien nicht angepasst, so werden diese im
Unterverzeichnis logs des Installationsverzeichnisses abgelegt. Da Proto-
kolldateien sehr schnell eine beachtliche Gre erreichen knnen, droht ein
"Voll-Laufen" der entsprechenden Partition. Dies kann zu ernsthaften
Strungen des Serverbetriebs fhren.
- Die Apache-Konfiguration enthlt Vorgabewerte fr bestimmte Ein-
stellungen, die Einfluss auf die Performance eines Apache-Webservers
haben. Werden diese Einstellungen ohne genaue Kenntnis der Aus-
wirkungen gendert, so kann dies die Performance bedeutend ver-
schlechtern. Oft sind auch die Auswirkungen einer nderung nicht sofort
- Werden mit der Direktive ScriptAlias Verzeichnisse fr den Apache-Web-
server als Verzeichnisse mit ausfhrbaren Programmen markiert, die zu
viele Skripte oder Programme enthalten, die eigentlich nicht bentigt
werden, so kann dies auf analoge Weise wie bei "vergessenen" Modulen zu
Sicherheitslcken fhren. Haben zu viele lokale Benutzer Schreibrechte
auf Verzeichnisse, die mittels ScriptAlias als Programmverzeichnisse
markiert sind, so knnen bswillige Benutzer dort Programme ablegen, die
sie spter ber einen WWW-Zugriff ausfhren knnen.
- Oft werden die "globalen" Vorgaben fr Verzeichnisoptionen nicht mit
einer geeigneten Options-Direktive auf einen restriktiven Vorgabewert ge-
setzt. Dies betrifft insbesondere die Option Includes, die die Ausfhrung
von Programmcode in Server-Side-Includes erlaubt. Jedoch knnen auch
andere Optionen wie Indexes zu Sicherheitslcken fhren.
- Die Konfiguration des Zugriffsschutzes fr HTTP-Zugriffe (ber die
Module mod_access und die verschiedenen mod_auth_-Module) kann auf
viele Arten und Weisen falsch gelst werden, so dass dadurch entweder
eine Vertraulichkeitsverlust entsteht, wenn Unbefugte Zugriff auf vertrau-
liche Informationen erhalten, oder aber die Verfgbarkeit der Informa-
tionen fr berechtigte Benutzer nicht gewhrleistet ist.
- Bei der Verwendung von mod_ssl kann durch verschiedene
Konfigurationsfehler das Serverzertifikat unzureichend geschtzt sein. Oft
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wird das Serverzertifikat nicht durch eine Passphrase geschtzt, so dass ein
Einbrecher, der sich eine Kopie der Zertifikatsdatei verschafft, einen "ge-
flschten" Server aufsetzen kann. Wird eine Passphrase verwendet, so kann
es zu Problemen mit der Verfgbarkeit des Webservers kommen, da in
diesem Fall ein automatischer unbeaufsichtiger Neustart des Servers nicht
mglich ist, weil die Passphrase eingegeben werden muss.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.64 Fehlerhafte Konfiguration von Routern und

Switches
Die Konfiguration aktiver Netzkomponenten hngt stark vom Einsatzzweck
der Gerte ab. Nachfolgend sind einige Beispiele aufgefhrt, die den sicheren
Einsatz der Gerte bedrohen knnen.
Betriebssystem
Oft werden auf Routern und Switches veraltete oder unsichere Versionen von
Betriebssystemen verwendet. Fr eine Vielzahl von Versionsstnden fr
Betriebssysteme unterschiedlicher Gerte und Hersteller stehen auf
einschlgigen Seiten im Internet Exploits zum Angriff auf diese Gerte zum
Download bereit.
Passwortschutz
Der Zugriff auf aktive Netzkomponenten wird oft nur unzureichend durch
Passwrter geschtzt.
Administrationszugnge
Administrationszugnge sind in der Praxis oft frei zugnglich. Es sind
beispielsweise keine Access Control Lists (ACL) eingerichtet.
Remote-Zugriff
Aktive Netzkomponenten bieten in der Regel die Mglichkeit mit Hilfe von
TELNET remote zuzugreifen. Bei der Nutzung von TELNET werden
Benutzername und Passwort im Klartext bertragen.
Login-Banner
Login-Banner von aktiven Netzkomponenten verraten hufig die Modell- und
Versionsnummer des Gerts.
Unntige Netzdienste
Hufig stehen auf Routern und Switches unntige Netzdienste bereit, mit
deren Hilfe Angreifer die Verfgbarkeit, Integritt oder Vertraulichkeit der
Komponenten gefhrden knnen.
Schnittstellen
Nicht genutzte Schnittstellen auf Routern sind hufig nicht deaktiviert.
VLAN
Trunk-Ports knnen auf alle konfigurierten VLANs zugreifen. Das heit, dass
der Zugang zu einem Trunk-Port den Zugriff auf alle VLANs ermglicht.
Hufig sind auf Switches die Trunking-Protokolle auf den Endgerte-Ports
nicht deaktiviert. Siehe auch G 5.114 berwindung der Grenzen zwischen
VLANs.
Routing-Protokolle
Routing-Protokolle ohne Authentisierungsverfahren knnen die
Vertraulichkeit, Verfgbarkeit und Integritt komplexer Netze bedrohen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.65 Fehlerhafte Administration von Routern und

Switches
Eine fehlerhafte Administration von Routern und Switches kann die
Verfgbarkeit, Vertraulichkeit und Integritt von Netzen bedrohen. Es gibt
unterschiedliche Zugriffsmglichkeiten, um Router und Switches zu
administrieren, die bei falscher Anwendung ein Sicherheitsrisiko darstellen
knnen:
Remote-Administration
Eine Vielzahl von aktiven Netzkomponenten bieten die Mglichkeit der
Remote-Administration mit Hilfe des Dienstes Telnet. Die Nutzung von
Telnet bietet allerdings eine Gefahr durch die unbefugte Erlangung von
Zugriffsrechten, da der Datenverkehr inklusive des Benutzernamens und
Passwortes im Klartext mitgelesen werden kann.
Viele Gerte bieten die Mglichkeit, Administrationsarbeiten mit Hilfe des
Dienstes HTTP durchzufhren. Auf dem Router bzw. dem Switch ist in
diesem Fall ein HTTP-Server gestartet, der Zugriff erfolgt von beliebigen
Clients ber Web-Browser. Die Standardeinstellungen fr den Zugriff auf das
Web-Interface sind nicht bei allen Herstellern einheitlich. So kann der Zugriff
deaktiviert sein, es ist aber auch mglich, dass dieser Dienst ungeschtzt ohne
Eingabe von Benutzerinformationen verwendet werden kann.
Wie bei der Nutzung des Dienstes Telnet werden auch beim HTTP der
Benutzername und das Passwort im Klartext bertragen. Zudem sind eine
Reihe von Exploits bekannt, die Schwachstellen der HTTP-Server
unterschiedlicher Hersteller ausnutzen.
SNMP
Die Authentisierung erfolgt bei SNMPv1 und SNMPv2 lediglich mittels eines
unverschlsselten "Community Strings". Als Standardeinstellung bei nahezu
allen Herstellern ist der read-Community-String auf den Wert "public"
eingestellt, whrend der write-Community-String auf den Wert "private"
gesetzt ist. Die SNMP Community Strings werden im Klartext ber das Netz
bertragen. Oft wird SNMP ber nicht abgesicherte Netze genutzt, so dass ein
Angreifer in der Lage ist, durch Mitlesen der Datenpakete (Sniffen) SNMP
Community Strings zu erraten. Nach Kenntnisnahme der Community Strings
kann ein Angreifer die Kontrolle ber die Netzkomponenten bernehmen.
Protokollierung
Hufig werden sicherheitsrelevante Ereignisse auf Routern und Switches nur
unzureichend protokolliert. Zudem kann sich eine fehlende
Alarmierungskomponente negativ auf die Verfgbarkeit, Vertraulichkeit und
Integritt der Systeme auswirken.
Fehlendes Backup und Dokumentation
Oft werden Konfigurationsnderungen auf Routern und Switches nicht
gesichert und nicht dokumentiert. Beim Ausfall der Komponenten stehen die
letzten nderungen beim Wiederanlauf des Ersatzsystems nicht zu Verfgung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.66 Fehlerhafte Zeichensatzkonvertierung beim

Einsatz von z/OS
EBCDIC (Extended Binary Coded Decimals Interchange Code) und ASCII
(American Standard Code for Information Interchange) sind
Kodierungstabellen, die festlegen, wie Buchstaben, Ziffern und andere
Zeichen mit Hilfe von 8 bzw. 7 Bits dargestellt werden.
z/OS-Systeme arbeiten mit EBCDIC-Code. Lediglich HFS- und zFS-
Dateisysteme (Hierarchical File Systems), die unter USS (Unix System
Services) eingesetzt werden, lassen sowohl ASCII- als auch EBCDIC-
Speicherung zu. Beim Datenaustausch zwischen z/OS-Systemen und
Systemen, die mit ASCII-Code arbeiten (z. B. auch von USS nach MVS),
besteht die Gefahr, dass Informationen verflscht werden, wenn fehlerhafte
bersetzungstabellen (Code Page Translation) zum Einsatz kommen.
Besonders hufig betroffen ist dabei die bersetzung von Sonderzeichen.
Beispiele:
- In einem Unternehmen wurden zwischen verschiedenen OS/390- und Probleme mit Umlauten
und Sonderzeichen
z/OS-Systemen ber einen lngeren Zeitraum mittels FTP-Protokoll Daten
bertragen, ohne dass es zu Problemen kam. Fr ein zustzliches Unix-
System wurde der gleiche FTP-Job eingesetzt und die EBCDIC-ASCII-
bersetzung mit der Default-Tabelle durchgefhrt. Der Transfer verlief
zunchst ohne Probleme, bei der weiteren Verarbeitung der Datenstze im
Unix-System zeigte sich jedoch, dass bestimmte Umlaute und
Sonderzeichen nicht richtig bersetzt worden waren. Erst nach der
Erstellung einer speziellen Translation Table, die nur fr diesen Transfer
zum Einsatz kam, war der Fehler bereinigt.
- Bei der bertragung einer Datei mittels FTP-Protokoll von einem z/OS- Datenfehler mglich
Betriebssystem zu einem Unix-Betriebssystem wurde die Option Binary
verwendet. Die Daten konnten auf dem Zielsystem nicht weiterverarbeitet
werden, da die Option Binary die Konvertierung von EBCDIC nach ASCII
unterdrckt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

des z/OS-Betriebssystems
Die Konfiguration eines z/OS-Betriebssystem ist sehr komplex und erfordert falsche Definitionen
an vielen Stellen den Eingriff des System-Administrators. Durch falsche oder
unzureichende Definitionen entstehen schnell Schwachstellen, die zu entspre-
chenden Sicherheitsproblemen fhren knnen.
Autorisierte Programme
Programme, die von einer autorisierten Bibliothek geladen werden und ent-
sprechend gekennzeichnet sind, knnen hoch autorisierte Funktionen ausfh-
ren. Gelingt es Anwendern eigene Programme unberechtigt zu autorisieren,
steht diesen Programmen nahezu die gleiche Funktionalitt wie den System-
Programmen zur Verfgung. Ein Deaktivieren von Sicherheitssperren in
RACF ist so z. B. jederzeit mglich.
System-Programme
Bei der Installation des z/OS-Betriebssystems und seiner Komponenten ist es
notwendig, bestimmte System-Bibliotheken (Partitioned Datasets) so zu defi-
nieren, dass das Betriebssystem auszufhrende System-Programme ber
interne Tabellen schnell findet. Die Bibliotheken dieser System-Programme
werden in sogenannten Linklists zusammengefasst und beinhalten in der Regel
hoch autorisierte Programme, die im Kernel-Mode laufen. Durch Fehler in der
Definition (oder durch Manipulation) knnen andere User-Bibliotheken zu
diesen Linklists hinzugefgt werden, die nicht dafr vorgesehen sind. Die
Programme dieser Bibliotheken sind dann ebenfalls hoch autorisiert und er-
lauben das Ausfhren von Funktionen, die Sicherheitsmechanismen umgehen
knnen.
Fehler beim Anlegen von Systembibliotheken
System-Bibliotheken, die als PDS (Partitioned Dataset) mit der Option
Secondary Space angelegt wurden, knnen zu Problemen im Betrieb fhren.
Whrend der Initialisierungsphase legt das System fr einige System-Biblio-
theken die Directory aus Geschwindigkeitsgrnden in den Hauptspeicher und
greift beim Laden des Programms nur ber dieses Verzeichnis auf die Biblio-
thek zu. Wird bei der Erweiterung einer Bibliothek im Rahmen einer Pro-
gramm-Pflege ein neuer Extent (dynamische Erweiterung des Dateibereiches
auf der Festplatte) angelegt, kann es passieren, dass das alte Programm statt
des neuen aktiv wird, da die interne Directory noch auf die alte Ladeadresse
zeigt. Ferner kann dadurch der Platzbedarf einer Datei permanent anwachsen,
ohne dass eine kontrollierte Begrenzung stattfindet.
Supervisor-Calls
Supervisor-Calls (SVCs) sind Aufrufe zu speziellen z/OS-Dienstprogrammen, Probleme mit SVCs
die im hochautorisierten Kernel-Modus laufen. Programme fr diesen Modus
mssen besonders sicher programmiert sein (IBM gibt hierfr entsprechende
Richtlinien vor). Unsichere SVC-Programme knnen unter Umstnden be-
nutzt werden, um z/OS-Sicherheitsmechanismen zu umgehen. Ein Angreifer
befindet sich nach einer erfolgreichen Attacke im hochautorisierten Kernel-
Modus. Vielfach gibt es heute noch sogenannte Autorisierungs-SVCs in
Gebrauch, die aus wenigen Instruktionen bestehen, ber Modeset den Kernel-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Modus an- oder ausschalten und es damit auch erlauben, unberechtigt im

Kernel-Modus Funktionen auszufhren.
TSO-Kommandos
Time-Sharing-Option-Kommandos (TSO) laufen normalerweise im Hoch autorisierte TSO-
Kommandos
Anwendungsmodus ab (mit normalen User-Privilegien), d. h. sie sind nicht
besonders privilegiert. z/OS verfgt jedoch ber Kommandos, die fr die
Ausfhrung bestimmter Funktionen (oder Teilfunktionen) eine hohe
Autorisierung bentigen. Kommandos, die nicht ber die Autorisierung
verfgen, die sie zur Verarbeitung bentigen, knnen im Betrieb Fehler
produzieren. Andererseits fhrt die unkontrollierte Freigabe von autorisierten
Kommandos zu einer Schwchung der Sicherheit.
Restricted Utilities
IBM und andere Software-Hersteller liefern, zusammen mit den Betriebs- Besondere
Dienstprogramme
systemkomponenten zustzliche Dienstprogramme (Utilities) aus. Diese
Programme fhren verschiedene verarbeitende Funktionen aus, wie das
Kopieren von Dateien oder das Anlegen von Katalogen (z/OS
Dateiverzeichnis zum Verwalten von Dateien). Die Mehrzahl dieser Utilities
bentigt zur Ausfhrung lediglich normale User-Privilegien, einige bentigen
jedoch eine hohe System-Autorisierung zur Durchfhrung ihrer Funktionen.
Sind diese Utilities nicht korrekt definiert, dann besteht die Gefahr, dass sie
nicht richtig funktionieren. Sind diese Utilities nicht hinreichend geschtzt,
dann besteht die Gefahr, dass sie von nicht autorisierten Mitarbeitern
missbraucht werden knnen. In der Folge kann die Integritt des z/OS-
Systems beeintrchtigt werden.
z/OS-Kommandos unter SDSF (System Display and Search Facility)
SDSF erlaubt es dem Anwender in einem JES2-System, sich die Ausgabe von
Batch-Jobs, das System-Log und weitere System-Optionen anzuschauen und
darber hinaus MVS- und JES2-Kommandos einzugeben. Falls keine oder nur
unzureichende Manahmen getroffen wurden, kann der Anwender von SDSF
unter Umstnden Manipulationen vornehmen, wie z. B. laufende Batch-Jobs
beenden, Initiators stoppen oder starten oder aber Systemkonfigurationen
umdefinieren. Darber hinaus kann er ggf. alle System-Nachrichten aus dem
Syslog und auch alle Job-Logs (u. U. auch Kunden-Daten) einsehen.
Enhanced MCS-Support
z/OS untersttzt ber die MCS-Konsole (Multiple Console Support) hinaus
die Enhanced-MCS-Konsole. Diese stellt eine Schnittstelle dar, ber die
Kommandos an MVS (JES2/3) bergeben und Nachrichten von MVS
empfangen werden knnen. Die Enhanced-MCS-Konsole steht unter TSO,
NetView und Applikationen - wie z. B. CICS - zur Verfgung. Wenn nicht
entsprechende Schutzdefinitionen vorgenommen werden, knnen unter
Umstnden Kommandos abgesetzt werden, die die Integritt eines Systems
stark beeintrchtigen knnen.
Beispiele:
- Auf einem OS/390-System wurde in der Vergangenheit ein Autorisierungs- Ein offenes System
SVC eingesetzt, um unter TSO/ISPF bestimmte Funktionen im
autorisierten. Modus (Kernel-Mode) zu nutzen. Obwohl diese Schwach-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
stelle seit lngerem bekannt war, wurde der SVC auch in neueren z/OS-
Umgebungen installiert und stand jedem Anwender zur Verfgung.
- Aus historischen Grnden wurde ein z/OS-Betriebssystem mit dem RACF- Zu viele Verantwortliche
Attribut OPERATIONS betrieben. Viele Benutzer, deren Konto ber dieses
Attribut verfgte, konnten nahezu alle Dateien lesen und modifizieren. Die
Integritt der Dateninhalte konnte bei diesem z/OS-System nur noch
bedingt gewhrleistet werden.
- In einem z/OS-System wurde das SDSF fr JES2 ohne jeden Schutz zur Keine System-Kontrolle
Verfgung gestellt. Schon nach kurzer Zeit hatten die Mitarbeiter
herausgefunden, wie sie die Prioritt des eigenen Benutzerkontos im
System erhhen konnten, um ihre Batch-Jobs im System schneller
bearbeiten zu lassen. Eine Kontrolle und effiziente Auslastung des Systems
waren nicht mehr mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

des z/OS-Webservers
Die bernahme der Default-Einstellungen oder eine fehlerhafte Konfiguration
des z/OS-Webservers kann zu Sicherheitsproblemen fhren.
- Bei Verwendung der standardmig vorgegebenen Einstellungen
(httpd.conf-Datei) und falsch eingestellten Userid-Regeln knnen durch die
MVSDS Funktion des Webservers unter Umstnden Dateien angezeigt
werden, die dem Anwender normalerweise unter seiner Kennung nicht zur
Verfgung stehen sollten, wie z. B. Systemdateien.
- Administrationsfehler knnen dazu fhren, dass Prozesse des z/OS-
Webservers unter der Started-Task-Kennung laufen. Besitzt diese Kennung
hohe Rechte im System (z. B. Superuser), kann dies zu
Sicherheitsproblemen fhren. Datei-Zugriffe und Kommandos erfolgen
dann unter der Autorisierung dieser Kennung. Als Folge sind u. U. Zugriffe
auf Dateien mit Kundendaten oder, wie vorher beschrieben, auf
Systemdateien ber die MVS-Dataset-Display-Funktion mglich.
- Der z/OS-Webserver untersttzt verschlsselte Datenkommunikation ber
das SSL-Protokoll. Bei falscher Konfiguration der Parameter besteht dabei
die Gefahr, dass die Verschlsselung deaktiviert ist oder die Prozesse unter
einer anderen RACF-Kennung laufen.
Weitere Gefhrdungen werden im Baustein 7.5 Webserver aufgefhrt.
Beispiel:
- Die Verwendung der Standarddefinitionen eines z/OS-Webservers
ermglichte es einem externen Angreifer, sich sensitive Dateien anzeigen
zu lassen. Darber hinaus war der Webserver so eingestellt, dass der Dienst
mit hohen Rechten unter der eigenen Started-Task-Kennung lief. Einem
externen Angreifer war es dadurch aus dem Internet mglich, die Dateien
SYS1.PROCLIB und SYS1.PARMLIB anzuzeigen. Aus diesen Angaben
konnte der Angreifer Informationen herauslesen, die den Angriff auf das
gesamte z/OS-System erleichterten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.69 Fehlerhafte Konfiguration der Unix System

Services unter z/OS
Unix System Services (USS) ist ein z/OS-Subsystem, das vor der Unix System Services
Inbetriebnahme angepasst werden muss.
Bei der Anpassung der USS-Parameter gibt es eine Reihe von Problemfeldern,
die beachtet werden mssen, damit es nicht zu Sicherheitsproblemen beim
z/OS-System bzw. bei Teilen des z/OS-Systems kommt.
Je nach Art der Fehlkonfiguration stehen nach dem Start des z/OS-Systems
bestimmte Teilfunktionen der Unix System Services nicht zur Verfgung bzw.
das USS-Subsystem startet nicht:
- Fallen Teilfunktionen der USS aus, knnen wichtige Subsysteme, wie z. B.
TCP/IP, fehlen.
- Startet das gesamte USS-Subsystem nicht, steht auch das z/OS-
Betriebssystem nicht zur Verfgung.
- Werden HFS-Dateien whrend der Startphase nicht allokiert (Mount),
knnen Applikationen, die diese Dateien bentigen, nicht betrieben
werden.
Im Folgenden sind einige typische Fehler bei der Konfiguration der USS
aufgefhrt:
- Der komplexe Aufbau der BPXPRMxx-Member kann zu
Administrationsfehlern fhren. Dies hat whrend des Initial Program Load
(IPL) einen fehlerhaften Start des Systems zufolge. Dies ist eine Frage der
Reihenfolge, in der die einzelnen Member-Definitionen durchlaufen
werden.
- Bestimmte Parameter im BPXPRM00-Member mssen auf die
Kapazittsgrenzen des Systems abgestimmt sein. Anderenfalls besteht die
Gefahr, dass mehr Unix-Prozesse anlaufen, als es das System verkraften
kann.
- Es knnen Fehler bei den Sysplex-Definitionen auftreten, z. B. bei der
VERSION-Angabe.
- Es sind Fehler bei der Definition der Mount-Policies von HFS- und zFS-
Files (Type, Mode und Mountpoint) mglich.
- Innerhalb der BPXPRMxx-Member knnen Variablen falsch verwendet
worden sein.
Beispiele:
- Der Aufruf eines rekursiven Unix-Kommandos erzeugte auf einem z/OS- Schwellwerte nicht
angemessen
System fortwhrend neue Prozesse, bis die z/OS-Auslagerungsdateien
(Page-Platten) nicht mehr ausreichten. Trotz vorhandener weiterer Page-
Platten, war es nicht mglich, das System zu retten, da nur noch wenige
Systemeingaben mglich waren. Das Problem konnte nur durch einen
Neustart (IPL) des Systems gelst werden.
- Auf einem z/OS-System mit mehreren BPXPRMxx-Membern wurde eine Komplexe Reihenfolgen
von Parametern
Parameternderung in einem falschen Member vorgenommen. Die
nderung wurde vom System nicht bercksichtigt, weil der Parameter
whrend des IPL von einem vorhergehenden Member gelesen wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.70 Unzureichender Dateischutz des z/OS-Systems

Im z/OS-Betriebssystem steuert und berwacht ein Sicherheitssystem, wie
RACF, den Dateizugriff. Eine fehlerhafte Administration des Dateischutzes
erlaubt es unter Umstnden einem Angreifer, unberechtigt auf wichtige
Dateien zuzugreifen, z. B. auf Betriebssystemprogramme, auf Konfigurations-
dateien oder auf Anwendungsdaten.
RACF sieht beispielsweise vor, dass Benutzerkonten mittels spezieller
Attribute (z. B. Special oder Operations) mit umfassenden Rechten
ausgestattet werden knnen.
Es sollte beachtet werden, dass Daten, auf die ein Anwender lesenden Zugriff
hat, unter z/OS immer auch von ihm kopiert werden knnen.
In diesem Zusammenhang sollte auch die Gefhrdung G 3.16 Fehlerhafte
Administration von Zugangs- und Zugriffsrechten beachtet werden.
Beispiele:
- Die Dateien mit den Lohndaten wurden als Kopie unter der Kennung eines Ungewollte Einsicht bzw.
Manipulation
Mitarbeiters angelegt, dessen Benutzerkonto in RACF mit dem Attribut
Universal Access UPDATE definiert war. Alle Mitarbeiter hatten dadurch
nicht nur lesenden Zugriff, sondern konnten die Daten auch modifizieren.
- Aufgrund eines nachlssigen Umgangs mit dem RACF-Attribut Operations-Attribut
Operations verfgte ein Anwender ber die Mglichkeit, nahezu alle
System- und Kundendaten zu lesen oder zu kopieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.71 Fehlerhafte Systemzeit bei z/OS-Systemen

Die Systemzeit (Datum und Uhrzeit) stellt fr eine ganze Reihe von Anwen- Falsche Zeit
dungen und Systemprogrammen eine wichtige Gre dar, von der die korrekte
Ausfhrung einer Vielzahl von Aktionen und die verlssliche Erstellung von
Ergebnissen und Daten abhngig ist.
Durch falsche Datums-/Zeitangaben knnen unter anderem folgende
Sicherheitsprobleme und resultierende Schden entstehen:
- Anwendungen, die Entscheidungen auf Basis des aktuellen Datums treffen,
liefern fehlerhafte Ergebnisse. Die Nacharbeitung ganzer Tagesproduk-
tionen kann die Folge sein. Dies gilt insbesondere fr Online-
Anwendungen und deren Transaktionsdaten. Korrekturen sind oft nicht
mehr mglich, wenn z. B. Kunden online auf das System zugreifen.
- Die Analyse von Sicherheitsvorfllen, die Zeitangaben bercksichtigt,
kann deutlich erschwert sein oder zu fehlerhaften Ergebnissen fhren.
- Differierende Systemzeiten in miteinander verbundenen Systemen sind
problematisch, wenn z. B. Log-Daten zu einer gemeinsamen Auswertung
herangezogen werden.
- Anwendungen, die Daten von mehreren Einzelsystemen empfangen und in
Abhngigkeit der Zeitstempel verarbeiten, liefern verflschte Ergebnisse.
Systemzeit bei z/OS-Systemen
Werden z/OS-Systeme nicht im Parallel-Sysplex-Cluster betrieben, muss die
Systemzeit in der Regel whrend des IPL (Initial Program Load) manuell
durch den Bediener eingegeben werden. Dabei kann es leicht passieren, dass
das Datums- oder Zeitfeld falsch gesetzt wird.
Die nderung der Systemzeit ist auch whrend des Betriebes mglich. Hier ist
die Gefahr von Fehleingaben durch Unachtsamkeit noch grer als bei einem
IPL.
In dem Member Clock00 wird die Zeitzone bzw. die Abweichung von der
Greenwich-Mean-Time (GMT) eingestellt. Eine falsche Einstellung der
Zeitzone fhrt zum gleichen Ergebnis als wre die Systemzeit selbst falsch
eingestellt worden.
Beispiele:
- Whrend des Betriebs sollte die Zeiteinstellung eines z/OS-Systems um Fehlerhafte Zeiteingabe
5 Minuten korrigiert werden. Ein Tippfehler bei der Eingabe des
Kommandos SET fhrte zu einer Systemzeit, die in den Abendstunden lag.
Der Job-Scheduler startete dementsprechend die abendliche Batch-
Produktion bereits whrend des Tages. Weil die Batch-Jobs exklusiv auf
die Datenbanken der Anwendung zugriffen, war online keine Dateneingabe
mehr mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.72 Fehlerhafte Konfiguration des z/OS-

Sicherheitssystems RACF
Im z/OS-Betriebssystem ist fr den Zugangs- und Zugriffsschutz auf Fehlerhafte
Ressourcen ein spezielles Sicherheitssystem zustndig. Hierfr kommt hufig Sicherheitseinstellungen
RACF (Resource Access Control Facility) zum Einsatz. Die Konfiguration in RACF
von RACF im Auslieferungszustand entspricht in der Regel nicht den
Sicherheitsanforderungen im jeweiligen Einsatzszenario.
Im Folgenden werden die am hufigsten vorzufindenden Problemfelder in
Bezug auf die RACF-Konfiguration beschrieben.
Gltigkeitsregeln fr Passwrter
Mit dem Kommando SETROPTS knnen in RACF systemweit gltige SETROPTS Definitionen
Sicherheitseinstellungen des z/OS-Systems, insbesondere fr Passwrter,
definiert werden. Zu den Parametern gehren die minimale Passwortlnge, die
Anzahl der erlaubten Anmeldeversuche, die maximale Gltigkeitsdauer, die
Passwort-Historie, Auditeinstellungen und die Klassenaktivierungen.
Missbrauch von Standard-Passwrter
Im Auslieferungszustand von z/OS sind fr die Kennung IBMUSER und das
RACF-Kommando RVARY Standard-Passwrter voreingestellt. Noch whrend
des Betriebs sind oft die Systemmonitore mit sicherheitskritischen Funktionen
ber Standard-Passwrter zugnglich.
Die Kennung IBMUSER dient als erste Kennung zum Aufbau eines neuen
Systems und besitzt Special- und Operations-Berechtigung. Da die Kennung
IBMUSER keinem eindeutigen Anwender zugeordnet ist, lsst sich kaum
herausfinden, wer diese Kennung benutzt bzw. benutzt hat.
Mit dem RACF-Kommando RVARY kann die RACF-Datenbank aktiviert und
deaktiviert, d. h. auch gewechselt werden.
Die Standard-Passwrter sind in der Produktdokumentation aufgefhrt und
damit allgemein bekannt.
Warning-Modus
RACF-Ressourcen knnen im Warning-Modus geschtzt werden. Dies
bedeutet, dass alle Zugriffe auf die Ressource gewhrt werden, auch wenn die
RACF-Definitionen einen Zugriff auf die Ressource eigentlich verbieten
wrden. Durch den Warning-Modus werden unter Umstnden sehr viel mehr
Nachrichten in das Syslog geschrieben und darber hinaus mehr SMF-Stze
(System Management Facility) erzeugt. Dies kann zu einer starken Erhhung
des Plattenspeicherplatzbedarfs fhren.
Eine irrtmliche Freigabe von Ressourcen ber den Warning-Modus kann zu
einem Verlust der Vertraulichkeit von Daten fhren.
Schutz von z/OS-System-Kommandos
Die z/OS-System-Kommandos werden ber spezielle Klassen im RACF
geschtzt. Durch unzureichende Definitionen dieser Klassen ist es mglich,
dass Anwender System-Befehle absetzen knnen, die unter Umstnden den
stabilen Systembetrieb beeintrchtigen. Beispiele hierfr sind das Starten oder
Stoppen von Started Tasks oder das Online-Setzen von Plattensystemen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Global Access Checking Table

Sind Dateien in der Global Access Checking Table (GAC) eingetragen, so
erfolgt beim Zugriff keine Prfung ber die RACF-Datenbank. Der Anwender
bekommt direkten Zugriff gem den in der GAC definierten Regeln. Werden
in der GAC irrtmlich Dateien eingetragen, so sind diese nicht mehr ber die
RACF-Profile geschtzt. Diese Dateien knnen z. B. von allen Anwendern
ausgelesen werden, falls sie in der GAC mit READ eingetragen sind.
RACF-Datenbank
Die RACF-Datenbank enthlt in verschlsselter Form alle Passwrter der
Benutzer und muss, wie jede andere Datei des z/OS-Betriebssystems, ber
entsprechende Definitionen geschtzt werden. Ist der Zugriffsschutz auf die
Datenbank so definiert, dass jeder Benutzer die Datei lesen (und damit auch
kopieren) kann (z. B. ber die Definition Universal Access(UACC) = READ),
ist ein Brute-Force-Angriff auf die Passwrter mglich.
Beispiele:
- ber das Kommando RVARY kann die RACF-Datenbank gewechselt Benutzung des RVARY-
Kommandos
werden. Ein Systemprogrammierer fand heraus, dass das Passwort des
Kommandos RVARY noch mit dem ausgelieferten Standardpasswort
bereinstimmte. Daraufhin konnte er eine andere speziell vorbereitete
RACF-Datenbank in das System bringen und aktivieren und hatte Zugriff
auf Daten, die er vorher nicht einsehen konnte.
- Nach dem Aufbau einer neuen RACF-Datenbank verga ein Bediener, die Benutzung des
IBMUSERs
Kennung IBMUSER zu sperren. Ein Sachbearbeiter entdeckte diese
Nachlssigkeit und es gelang ihm, unerlaubt Daten aus dem System zu
kopieren.
- Die Sicherungskopie einer RACF-Datenbank war aufgrund eines Brute-Force-Attacke auf
RACF-Datenbank
Administrationsfehlers lediglich ber die Definition UACC(READ)
geschtzt. Ein Angreifer nutzte dies aus, um die Datenbank auf seinen PC
zu kopieren. Auf dem PC fhrte er mit frei verfgbaren Programmen einen
Brute-Force-Angriff auf die Passwrter der RACF-Datenbank aus und war
in mehreren Fllen erfolgreich. Der Angreifer nutzte die ihm bekannten
Kennungen und Passwrter von anderen Anwendern aus, um
Produktionsdaten zu verndern. Der Verdacht fiel zunchst auf den
Besitzer der Kennung, die fr den Zugriff in den Protokolldateien
registriert wurde, und nicht auf den Verursacher des Schadens.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.73 Fehlbedienung der z/OS-Systemfunktionen

Whrend des Betriebs des z/OS-Systems sind von Zeit zu Zeit Eingriffe durch
die Bediener (Operators), wie Anpassungen von RACF-Einstellungen oder
anderen Systemdefinitionen, erforderlich.
Aufgrund der Komplexitt des z/OS-Betriebssystems und seiner Kompo-
nenten lassen sich Fehlbedienungen durch die Bediener nicht vollstndig
ausschlieen. Je nach Art der Fehlbedienung knnen in der Folge einzelne
Komponenten oder das gesamte System ausfallen. Nachfolgend sind einige
typische Beispiele fr Fehlbedienungen aufgefhrt.
Unbeabsichtigter Neustart ber die Hardware Management Console
(HMC)
Der Neustart eines Systems kann ber die HMC angefordert werden. Zur
Auswahl des Systems gengt ein einfaches Anklicken des System-Icons,
danach muss nur noch die Funktion ausgewhlt werden (z. B. Initial Program
Load). Nach Besttigung einer entsprechenden Rckfrage fhrt dieser
Vorgang umgehend zum Neustart des ausgewhlten Systems. Alle laufenden
Prozesse werden unkontrolliert beendet. Eine Verwechselung der Systeme
kann hierdurch schwerwiegende Folgen nach sich ziehen.
Da in der HMC auch Gruppen von Systemen zusammengefasst werden
knnen, bis hin zu allen z/OS-Systemen eines Rechenzentrums, knnen weite
Bereiche der Informationsverarbeitung betroffen sein.
Fehler beim JES3 DSI (Dynamic System Interchange)
Das Job Entry Subsystem JES3 gestattet den Betrieb eines Systemverbunds,
der aus einem Global-Rechner und verschiedenen Local-Rechnern bestehen
kann. Auf alle Rechner im Verbund (Global und Local) werden unter der
Kontrolle des Global-Rechners vor allem Batch-Jobs automatisch verteilt und
dann dort ausgefhrt (hnlich wie bei einem Parallel-Sysplex-Cluster, jedoch
auf JES3 beschrnkt). Der Global-Rechner bernimmt dabei die zentrale
Kontrolle des gesamten Lebenszyklus des Batch-Jobs, wie z. B. Interpretation
der Job Control Language, Systemzuordnung, Ressourcenkontrolle, Output-
Management usw.
Zur bernahme der Funktion des Global-Rechners auf einen Local-Rechner
sind eine Reihe von Systemfragen zu beantworten. Falsche Angaben knnen
im Extremfall zu einem IPL (Initial Program Load) aller Systeme des
Verbunds fhren.
Sperrung von z/OS-Kennungen
Kennungen mit dem Attribut Special erzeugen bei mehrmaliger aufeinander
folgender Falscheingabe des Passwortes whrend der Anmeldung eine
Konsol-Nachricht (Reply). Das Bedienpersonal (Operator) kann entscheiden,
ob diese Kennung gesperrt werden soll. Werden im Extremfall, z. B. bei einer
DoS-Attacke, alle Kennungen mit dem Attribut Special gesperrt (z. B. durch
Automatismen), existiert auf diesem System keine Kennung mehr, die RACF
bedienen kann. Das Sicherheitssystem ist dann in sich gesperrt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Offline-Setzen von Platten

Ein versehentliches Offline-Setzen einer Platte kann gravierende
Auswirkungen, bis hin zum Totalausfall des Systems, haben.
Lschen der Default Program Class in RACF
Wird versehentlich (z. B. durch Tippfehler) das Stern-Profil der Klasse
Program gelscht, kann dies zum Stillstand des Systems fhren. Ein IPL hilft
nicht weiter, da dadurch die Fehlerursache nicht beseitigt wird. Es muss erst
die RACF-Datenbank bereinigt werden. Ein solcher Fehler kann einen
stundenlangen Ausfall des kompletten Systems und einen erheblichen
Aufwand fr die Fehlerbeseitigung bedeuten.
Weiterleiten von fehlerhaften RACF Kommandos
Wenn ein System in eine RACF-Kommando-Synchronisierung (z. B. RACF
Remote Sharing Facility - RRSF) eingebunden ist, kann ein fehlerhaftes
RACF-Kommando alle anderen Systeme dieses Verbundes betreffen. Wird
beispielsweise das Lschen der Default Program Class via RRSF bertragen,
kann dies zum Stillstand aller Systeme im jeweiligen RRSF-Verbund fhren.
Fehlbedienung vordefinierter Programm-Funktionstasten
Auch durch die Benutzung vordefinierter Programm-Funktionstasten kann es
unter Umstnden zu Sicherheitsproblemen kommen. Besondere Sorgfalt ist
z. B. geboten, wenn Funktionstasten mit Kommandos belegt werden, die vor
der Ausfhrung noch um bestimmte Werte ergnzt werden mssen. Hier
besteht die Gefahr, dass der Operator die Funktionstaste versehentlich drckt,
ohne eine Ergnzung einzugeben. Wenn das entsprechende Kommando auch
ohne Ergnzung syntaktisch korrekt ist, wird es ausgefhrt und bewirkt unter
Umstnden unerwnschte Effekte oder sogar enorme Schden.
Falscheingaben im Allgemeinen
Generell besteht immer die Gefahr der Falscheingaben. Soll z. B. eine System-
Task (oder ein Batch-Job) gestoppt werden und der Bediener vertippt sich, so
kann es vorkommen, dass auf Grund von hnlichen Jobnamen der falsche Job
gestoppt wird. Das Gleiche gilt fr den Gebrauch von System Kommandos.
Wird z. B. beim Inaktivieren von SNA-Knoten statt eines einzelnen Terminal-
Namens versehentlich der Cross Domain Manager-Name eingegeben, so
bedeutet dies den Verlust aller SNA Sessions dieser Domain. Nach dem
Neustart des Knotens mssen sich die Anwender neu einloggen und die SNA-
Verbindung zum System neu aufbauen.
Verriegelung von Ressourcen
Bei einer gegenseitigen Verriegelung von Ressourcen (Enqueue Contention)
knnen Funktionen so lange nicht verfgbar sein, bis die Verriegelung wieder
gelst wird. Oft sind eine Reihe von System-Abfragen (Displays) und viel
Betriebserfahrung notwendig, um gegenseitige Verriegelungen mit Hilfe der
richtigen MVS-Kommandos wieder aufzulsen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Unbeabsichtigte Eingabe des Befehls "Z EOD"

Wird an einer MVS-Master-Konsole whrend des Betriebs der Befehl Z EOD
eingegeben, wird dieses System kontrolliert heruntergefahren. Alle Prozesse
werden beendet und mssen neu aufgesetzt werden. Dieser Vorgang und der
damit verbundene Betriebsausfall dauert in der Regel mindestens 30 Minuten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.74 Unzureichender Schutz der z/OS-

Systemeinstellungen vor dynamischen
nderungen
Viele z/OS-Systemeinstellungen lassen sich whrend des Betriebs verndern, Dynamische z/OS-
ohne dass ein IPL durchgefhrt werden muss. Nach Vernderung einer Anpassungen
vorhandenen oder Erstellung einer neuen Parameterdatei (Member der
Parmlib) lst ein Aktivierungskommando den nderungsvorgang aus.
Die Sicherheit von z/OS-Systemen kann beeintrchtigt werden, wenn
bestimmte Kommandos fehlerhaft bedient oder von Unbefugten missbraucht
werden. Die wichtigsten kritischen Parameterdateien und Systemkommandos,
durch die im laufenden Betrieb dynamisch Einstellungen gendert werden
knnen, sind im Folgenden aufgefhrt.
Erweiterung der APF-Dateien
Dateien, die ber das Authorized Program Facility (APF) autorisiert werden
mssen, knnen in einem Definitions Member festgelegt (PROGnn) und
anschlieend mit dem Kommando SET PROG=nn (Kommando SET und
Parameter PROG=m) aktiviert werden. Alternativ lassen sich mit dem
Kommando SETPROG APF (Kommando SETPROG und Parameter APF)
einzelne Bibliotheken in den APF-Mechanismus einbinden. Sind die Parmlib-
Definitionen oder die passenden Kommandos nicht richtig geschtzt, kann es
zu Sicherheitsproblemen kommen, da Dritte hierdurch unter Umstnden
eigene Programme mit hohen Autorisierungen versehen und whrend des
Betriebs aktivieren knnen.
Erweiterung des LINKLIST-Mechanismus
Programme, die ohne Steplib oder Joblib DD Statement in einem Batch-Job
verfgbar sein sollen, knnen in der LINKLIST definiert werden. Diese
Definitionen sind in einem PROGnn-Member der Parmlib abgelegt, wobei
Dateien durch das Kommando SETPROG LNKLST ber ein neu zu
definierendes Member dynamisch hinzugefgt werden knnen. Ist die
LINKLIST in der Systemdefinition (IEASYSnn) mit LNKAUTH=LNKLST
definiert, sind alle Programme, die ber diesen Mechanismus geladen werden,
automatisch APF-autorisiert. Auch hier ist die Integritt des Systems
gefhrdet, wenn das Kommando ungeschtzt zur Verfgung steht.
Deaktivierung und Modifizierung der User Exits
Durch das Kommando SETPROG EXIT ist es mglich, Exits zu deaktivieren
oder durch andere zu ersetzen. Ist das Kommando nur unzureichend geschtzt,
kann ein Angreifer unter Umstnden auf dem System eigene Exits ausfhren.
Damit lsst sich z. B. das Schreiben von SMF-Stzen (System Management
Facility) unterbinden und die Auditierung des Systems beeinflussen
(Verschleierung).
Vernderung der Message Processing Facility (MPF)
Viele Programme zur Automation von Vorgngen werten Nachrichten
(Messages) des Systems aus. Durch Setzen anderer MPF-Versionen (Message
Processing Facility) mit dem Kommando T MPF=nn kann die Automation
manipuliert oder vollstndig ausgeschaltet werden (T MPF=NO).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Austausch von Parmlibs

Parameterdateien (Parmlibs) sind die zentrale Stelle der z/OS-System-
Definitionen. Mit Hilfe des Kommandos SETLOAD lassen sich vorhandene
Parmlibs durch neue ersetzen.
Weitere kritische z/OS-Kommandos fr dynamische nderungen
Neben den oben beschriebenen Kommandos sind eine Reihe weiterer
Kommandos zum Verndern von z/OS-Systemeinstellungen verfgbar, wie
z. B. SETSSI zum Hinzufgen oder Lschen von Subsystemen oder SETSMS
zum Verndern der SMS-Definitionen.
Von allen diesen Kommandos, die dynamisch z/OS-Definitionen ndern,
knnen Sicherheitsprobleme ausgehen, wenn sie unkontrolliert im System zur
Verfgung stehen. Durch den Missbrauch dieser Kommandos knnen
hnliche Probleme entstehen wie durch die Manipulation von kritischen
Definitions-Dateien.
Beispiele:
- Ein Mitarbeiter eines Unternehmens konnte aufgrund eines unzureichenden Unberechtigter Zugriff
auf APF-Dateien
Schutzes des Kommandos SETPROG APF eine eigene Programmdatei
autorisieren. Unter Zuhilfenahme eines weiteren Programms, das von
dieser Datei geladen wurde, war es ihm mglich, wichtige Finanzdaten zu
verflschen.
- Ein Bediener schaltete mit dem Kommando T MPF=NO (T ist eine Beeinflussung der
Automation
Kurzform des SET-Kommandos) das z/OS-Message-Processing aus. Dies
fhrte zu einer berlastung der Konsole (Nachrichtenflut) und zur
Sperrung einiger dort definierter Exits, so dass die Automation des Systems
stark behindert wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.75 Mangelhafte Kontrolle der Batch-Jobs bei z/OS

z/OS-Betriebssysteme werden noch immer in hohem Mae fr die Durch-
fhrung von Batch-Jobs eingesetzt. Ein Batch-Job besteht aus einem oder
mehreren Einzelschritten (Job-Steps).
Die Eingabe zu einem Batch-Job sind entweder eine/mehrere Datei(en) oder
entsprechende Steuerkarten, die ber das Job Entry Subsystem (JES2/3)
zugefhrt werden. Die Ausgabeverwaltung erfolgt ebenfalls durch das Job
Entry Subsystem.
Die Steuerung der Batch-Jobs besteht im wesentlichen aus Start,
berwachung des Ablaufs und der Prfung des Ergebnisses (meist in Form
eines Returncodes). Je nach Returncode mssen darauf hufig Folge-Batch-
Jobs gestartet werden. Je hher die Anzahl der Jobs und die Komplexitt der
Ablufe ist, umso hher ist die Wahrscheinlichkeit eines Fehlers.
Manuelle Steuerung
Bei der manuellen Ausfhrung von Batch-Jobs besteht immer die Gefahr, dass
durch menschliche Fehlhandlungen Probleme in den Batch-Ablufen
entstehen. Betroffen sind neben dem zeitlichen Ablauf auch die
Abhngigkeiten der Batch-Jobs voneinander. Bei zunehmender Zahl der zu
steuernden Batch-Jobs erhht sich deshalb die Komplexitt der gesamten
Batch-Kette immer drastischer und fhrt zu einer immer greren Anzahl von
Fehlern. Einer manuellen Steuerung sind deshalb natrliche Grenzen gesetzt.
Zeitliche Verzgerungen knnen sich z. B. so auswirken, dass ein nach den
Batch-Jobs laufendes Online-Verfahren nicht termingerecht gestartet werden
kann oder dass Dateisicherungen mit dem Online-Verfahren kollidieren.
Maschinelle Steuerung (Job-Scheduler)
Ist ein maschinelles Verfahren (Job Scheduler) eingesetzt, stellt dieses zwar
den Ablauf sicher. Es knnen jedoch Fehler auftreten, wenn die Anweisungen
an diesen Job Scheduler nicht sachgerecht getestet wurden und sich Fehler bei
den Anweisungen eingeschlichen haben. Auch durch falsch definierte
Automation im Ablauf der Stapelverarbeitung kann es zu fehlerhaften
Reaktionen des Job Schedulers kommen.
Beispiel:
Der Abbruch eines Batch-Jobs wurde whrend der Stapelverarbeitung nicht Beeintrchtigung des
Online-Betriebes
registriert. Erst die Online-Verarbeitung am nchsten Tag zeigte die Fehler
in den Datenbestnden. Zur Korrektur musste die Online-Verarbeitung
gestoppt, Datenbestnde zurckgeladen und danach die Stapelverarbeitung
wiederholt werden. In dieser Zeit stand die Online-Verarbeitung nicht zur
Verfgung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 3.76 Fehler bei der Synchronisation mobiler Endge-

rte
Daten, die auf mobilen IT-Systemen wie Laptops, Mobiltelefone und PDAs
gespeichert sind, werden hufig mit stationren IT-Systemen abgeglichen.
Dies ist beispielsweise fr die Termin- und Adress-Verwaltung sinnvoll.
Bei der Synchronisation knnen allerdings auch Daten zerstrt werden. Im
allgemeinen muss vor einer Synchronisation eingestellt werden, wie mit
Konflikten beim Datenabgleich umzugehen ist: ob beispielsweise bei gleich-
lautenden Dateien die des PDA oder des anderen Endgert ungefragt ber-
nommen werden oder ob eine Abfrage erfolgt. Dies wird hufig bei Inbetrieb-
nahme der Dockingstation einmal konfiguriert und gert danach gerne in Ver-
gessenheit. Wenn dann aber Daten in einer anderen Reihenfolge gendert
werden als ursprnglich einmal gedacht, gehen dabei schnell wichtige Daten
verloren. Dies kann auch ein unangenehmer Nebeneffekt sein, wenn mehrere
Benutzer ihre PDAs mit demselben Endgert synchronisieren, ohne daran zu
denken, dass gleichnamige Dateien dabei berschrieben werden knnen.
___________________________________________________________________ ..........................................
Gefhrdungskatalog Technisches Versagen G4 Bemerkungen
___________________________________________________________________ ..........................................
G4 Gefhrdungskatalog Technisches Versagen

G 4.1 Ausfall der Stromversorgung..................................................... 1
G 4.2 Ausfall interner Versorgungsnetze ............................................ 2
G 4.3 Ausfall vorhandener Sicherungseinrichtungen .......................... 3
G 4.4 Leitungsbeeintrchtigung durch Umfeldfaktoren ...................... 4
G 4.5 bersprechen ............................................................................. 5
G 4.6 Spannungsschwankungen/berspannung/
Unterspannung........................................................................... 6
G 4.7 Defekte Datentrger................................................................... 7
G 4.8 Bekanntwerden von Softwareschwachstellen............................ 8
G 4.9 Ausfall der internen Stromversorgung....................................... 9
G 4.10 Komplexitt der Zugangsmglichkeiten zu vernetzten
IT-Systemen............................................................................. 10
G 4.11 Fehlende Authentisierungsmglichkeit zwischen NIS-
Server und NIS-Client ............................................................. 11
G 4.12 Fehlende Authentisierungsmglichkeit zwischen X-
Server und X-Client ................................................................. 12
G 4.13 Verlust gespeicherter Daten..................................................... 13
G 4.14 Verblassen spezieller Faxpapiere............................................. 14
G 4.15 Fehlerhafte Faxbertragung..................................................... 15
G 4.16 bertragungsfehler bei Faxversand ......................................... 16 entfallen
G 4.17 Technischer Defekt des Faxgertes ......................................... 17 entfallen
G 4.18 Entladene oder beralterte Notstromversorgung im
Anrufbeantworter..................................................................... 18
G 4.19 Informationsverlust bei erschpftem Speichermedium ........... 19
G 4.20 Datenverlust bei erschpftem Speichermedium ...................... 20
G 4.21 Ausgleichsstrme auf Schirmungen ........................................ 21
G 4.22 Software-Schwachstellen oder -Fehler ................................... 22
G 4.23 Automatische CD-ROM-Erkennung ....................................... 23
G 4.24 Dateinamenkonvertierung bei Datensicherungen unter
Windows 95 ............................................................................. 24
G 4.25 Nicht getrennte Verbindungen................................................. 25
G 4.26 Ausfall einer Datenbank .......................................................... 26
G 4.27 Unterlaufen von Zugriffskontrollen ber ODBC..................... 27
G 4.28 Verlust von Daten einer Datenbank......................................... 28
G 4.29 Datenverlust einer Datenbank bei erschpftem
Speichermedium ...................................................................... 29
___________________________________________________________________ ..........................................
Gefhrdungskatalog Technisches Versagen G4 Bemerkungen
___________________________________________________________________ ..........................................
G 4.30 Verlust der Datenbankintegritt/-konsistenz............................ 30

G 4.31 Ausfall oder Strung von Netzkomponenten........................... 31
G 4.32 Nichtzustellung einer Nachricht .............................................. 35
G 4.33 Schlechte oder fehlende Authentikation .................................. 36
G 4.34 Ausfall eines Kryptomoduls .................................................... 37
G 4.35 Unsichere kryptographische Algorithmen ............................... 38
G 4.36 Fehler in verschlsselten Daten ............................................... 40
G 4.37 Mangelnde Zeitauthentizitt von E-Mail ................................. 41
G 4.38 Ausfall von Komponenten eines Netz- und
Systemmanagementsystems..................................................... 42
G 4.39 Software-Konzeptionsfehler .................................................... 44
G 4.40 Ungeeignete Ausrstung der Betriebsumgebung des
RAS-Clients............................................................................. 45
G 4.41 Nicht-Verfgbarkeit des Mobilfunknetzes .............................. 46
G 4.42 Ausfall des Mobiltelefons oder des PDAs ............................... 47
G 4.43 Undokumentierte Funktionen .................................................. 48
G 4.44 Ausfall von Novell eDirectory................................................. 49
G 4.45 Verzgerte Archivauskunft...................................................... 50
G 4.46 Fehlerhafte Synchronisierung von Indexdaten bei der
Archivierung ............................................................................ 51
G 4.47 Veralten von Kryptoverfahren ................................................. 52
G 4.48 Ausfall der Systeme eines Outsourcing-Dienstleisters ............ 53
G 4.49 Unsichere Default-Einstellungen auf Routern und
Switches................................................................................... 54
G 4.50 berlastung des z/OS-Betriebssystems ................................... 55
G 4.51 Unzureichende Sicherheitsmechanismen bei PDAs ................ 57
G 4.52 Datenverlust bei mobilem Einsatz ........................................... 58
___________________________________________________________________ ..........................................
Gefhrdungskatalog Technisches Versagen G 4.1 Bemerkungen
___________________________________________________________________ ..........................................
G 4.1 Ausfall der Stromversorgung

Trotz hoher Versorgungssicherheit kommt es immer wieder zu Unter-
brechungen der Stromversorgung seitens der Energieversorgungsunternehmen
(EVU). Die grte Zahl dieser Strungen ist mit Zeiten unter einer Sekunde so
kurz, dass der Mensch sie nicht bemerkt. Aber schon Unterbrechungen von
mehr als 10 ms sind geeignet, den IT-Betrieb zu stren. Bei einer Messung mit
ca. 60 Messstellen wurden 1983 in Deutschland rund 100 solcher Netz-
einbrche registriert. Davon dauerten fnf Ausflle bis zu einer Stunde und
einer lnger als eine Stunde. Diese Unterbrechungen beruhten einzig auf
Strungen im Versorgungsnetz. Dazu kommen Unterbrechungen durch
Abschaltungen bei nicht angekndigten Arbeiten oder durch
Kabelbeschdigungen bei Tiefbauarbeiten.
Von der Stromversorgung sind nicht nur die offensichtlichen, direkten Strom-
verbraucher (PC, Beleuchtung usw.) abhngig. Alle Infrastruktureinrichtungen
sind heute direkt oder indirekt vom Strom abhngig, z. B. Aufzge,
Rohrpostanlagen, Klimatechnik, Gefahrenmeldeanlagen, Telefonneben-
stellenanlagen. Selbst die Wasserversorgung in Hochhusern ist wegen der zur
Druckerzeugung in den oberen Etagen erforderlichen Pumpen stromabhngig.
Die Liberalisierung des Strommarktes fhrte in einigen Industrielndern zu
einer Verschlechterung des Versorgungsniveaus. Auch in Deutschland knnte
daher die Gefahr wachsen, dass Probleme durch Ausflle der Strom-
versorgung oder durch Schaltvorgnge an nationalen Versorgungsbergngen
entstehen.
Beispiele:
- In einem groen sddeutschen Industriebetrieb war die gesamte Strom-
versorgung fr mehrere Stunden unterbrochen, da technische Probleme
beim Stromversorgungsunternehmen aufgetreten waren. Infolgedessen
fielen sowohl die Produktion als auch smtliche Rechner der Ent-
wicklungsabteilungen aus, die ber keine Ersatz-Stromversorgung ver-
fgten.
- Durch einen Fehler in der USV eines Rechenzentrums schaltete diese nach
einem kurzen Stromausfall nicht auf Normalbetrieb zurck. Nach
Entladung der Batterien nach etwa 40 Minuten fielen alle Rechner im
betroffenen Server-Saal aus.
- Anfang 2001 gab es ber 40 Tage einen Strom-Notstand in Kalifornien.
Die Stromversorgungslage war dort so angespannt, dass die Kalifornische
Netzberwachungsbehrde rotierende Stromabschaltungen anordnete. Von
diesen Stromabschaltungen, die bis zu 90 Minuten andauerten, waren nicht
nur Haushalte, sondern auch die High-Tech-Industrie betroffen. Weil mit
dem Stromausfall auch Alarmanlagen und berwachungskameras
ausgeschaltet wurden, hielten die Energieversorger ihre Abschaltplne
geheim.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.2 Ausfall interner Versorgungsnetze

Es gibt in einem Gebude eine Vielzahl von Netzen, die der Ver- und Entsor-
gung und somit als Basis fr die IT dienen. Der Ausfall von Versorgungs-
netzen wie:
- Strom,
- Telefon und
- Klima/Lftung
kann zu einer sofortigen Strung des IT-Betriebs fhren. Demgegenber kann
es bei Ausfall in den Bereichen:
- Heizung,
- Wasser,
- Lschwasserspeisungen,
- Abwasser,
- Rohrpost,
- Gas,
- Melde- und Steueranlagen (Einbruch, Brand, Hausleittechnik) und
- Sprechanlagen
unter Umstnden zu zeitverzgerten Strungen kommen.
Die Netze sind in unterschiedlich starker Weise voneinander abhngig, so dass
sich Betriebsstrungen in jedem einzelnen Netz auch auf andere auswirken
knnen.
Beispiele:
- Der Ausfall der Stromversorgung wirkt nicht nur auf die IT direkt, sondern
auch auf alle anderen Netze, die mit elektrisch betriebener Steuer- und
Regeltechnik ausgestattet sind. Selbst in Abwasserleitungen sind u. U.
elektrische Hebepumpen vorhanden.
- Mit modernen TK-Anlagen (ISDN-Technik) ist es mglich, LANs aufzu-
bauen. Strungen im TK-Netz wirken sich automatisch auf das dort reali-
sierte LAN aus.
- Der Ausfall der Wasserversorgung beeintrchtigt evtl. die Funktion von
Klimaanlagen.
- Der Ausfall der Klimaanlage kann die Nutzung des Gebudes durch zu
starke Erwrmung bzw. Abkhlung oder wegen mangelhaftem Luftaus-
tausch beeintrchtigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.3 Ausfall vorhandener Sicherungseinrichtungen

Durch technische Defekte oder uere Einflsse (z. B. aufgrund von Alterung,
Fehlbedienung, mangelhafter Wartung, Manipulation, Stromausfall) kann es
zum Ausfall von Sicherungseinrichtungen kommen, so dass ihre
Schutzwirkung stark herabgesetzt ist oder gnzlich ausfllt. Weiterhin kommt
es vor, dass in Problembereichen, z. B. durch starke Umwelteinflsse oder
besonders hohe Nutzungsfrequenzen, Kontrollen und Wartungsintervalle nicht
entsprechend angepasst werden. Auch hierdurch knnen
Sicherungseinrichtungen ausfallen.
Beispiele:
- Trschlsser knnen durch Alterung oder Fehlbedienung beschdigt
werden.
- Feuerlscher, die nicht ordnungsgem gewartet werden, funktionieren
u. U. unzureichend.
- Verschmutzte Brandmelder erkennen u. U. Brnde nicht ordnungsgem
oder geben Fehlalarm.
- Schlssel oder Ausweiskarten knnen durch unsachgeme Aufbewahrung
oder durch Abnutzung beschdigt werden.
- Riegelkontakte in Tren knnen festgeklemmt sein.
- Standbilder in berwachungsmonitoren knnen sich einbrennen.
- Brandschutztren werden oft unzulssigerweise durch Holzkeile
aufgehalten.
- Es kommt vor, dass Rauchmelder in Nichtraucherzonen manipuliert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.4 Leitungsbeeintrchtigung durch Umfeldfaktoren

Die bertragungseigenschaften von Kabeln mit elektrischer Signalber-
tragung knnen durch elektrische und magnetische Felder negativ beeinflusst
werden. Ob dies zu einer tatschlichen Strung der Signalbertragung fhrt,
hngt im wesentlichen von drei Faktoren ab:
- Frequenzbereich, Strke und Dauer der Einwirkung,
- Abschirmung des Kabels und
- Schutzmanahmen bei der Datenbertragung (Redundanz, Fehler-
korrektur).
Viele Beeintrchtigungen lassen sich im Vorfeld erkennen:
- Entlang von Starkstromtrassen und im Bereich groer Motoren entstehen
starke induktive Felder (Eisenbahn, Produktionsbetrieb, Aufzug).
- Im Bereich von Sendeeinrichtungen existieren starke elektromagnetische
Felder (Rundfunk, Polizei- bzw. Feuerwehrfunk, Betriebsfunk, Personen-
suchanlagen, Funknetze).
- Mobiltelefone berschreiten durch ihre Sendeleistung (2 bis 4 Watt) die
Strempfindlichkeit vieler IT-Systeme,
- Kabel beeinflussen sich gegenseitig durch wechselseitige Induktion.
Unabhngig von den rein elektrischen oder magnetischen Einflssen knnen
weitere Umfeldfaktoren auf ein Kabel wirken:
- hohe Temperaturen (in der Prozesssteuerung),
- aggressive Gase und
- hohe mechanische Belastungen (z. B. bei provisorischer Verlegung auf
dem Fuboden oder Leitungen zu beweglichen Gerten).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.5 bersprechen
bersprechen ist eine spezielle Form der Leitungsbeeintrchtigung. Dabei
wird die Strung nicht allgemein im Umfeld, sondern durch Strme und
Spannungen von Signalen erzeugt, die auf eine benachbarte Leitung ber-
tragen werden. Die Strke dieses Effektes ist vom Kabelaufbau
(Abschirmung, Kabelkapazitt, Isolationsgte) und von den elektrischen
Parametern bei der Informationsbertragung (Strom, Spannung, Frequenz)
abhngig.
Nicht jede Leitung, die durch bersprechen beeinflusst wird, muss ihrerseits
auch andere beeinflussen. Bekannt ist dies aus dem Telefonnetz. Dort sind
Gesprche anderer Netzteilnehmer zu hren. Diese reagieren aber auf die
Aufforderung "aus der Leitung zu gehen" oft deswegen nicht, weil das ber-
sprechen nur in eine Richtung geschieht. Das Prfen eigener Leitungen auf
eingekoppelte Fremdsignale gibt keine Auskunft darber, ob die eigenen
Signale auf andere Leitungen bersprechen und somit dort abhrbar sind.
Der wesentliche Unterschied zu anderen Leitungsstrungen ist der, dass neben
der Strung der Signalbertragung auf benachbarten Leitungen durch ber-
sprechen auswertbare Informationen auf fremden Leitungen zur Verfgung
stehen knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.6 Spannungsschwankungen/berspannung/
Unterspannung
Durch Schwankungen der Versorgungsspannung kann es zu Funktionsstrun-
gen und Beschdigungen der IT kommen. Die Schwankungen reichen von
extrem kurzen und kleinen Ereignissen, die sich kaum oder gar nicht auf die
IT auswirken, bis zu Totalausfllen oder zerstrerischen berspannungen. Die
Ursache dafr kann in allen Bereichen des Stromversorgungsnetzes entstehen,
vom Netz des Energieversorgungsunternehmens bis zum Stromkreis, an dem
die jeweiligen Gerte angeschlossen sind.
Auerhalb des Energieversorgungsnetzes ist auch auf allen anderen elektrisch
leitenden Netzen (wie Telefonanbindung, Gebudeleittechnik, Wasser- oder
Gasleitungen etc.) mit Einkopplungen von berspannungen zu rechnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.7 Defekte Datentrger

Der Ausfall bzw. der Defekt einzelner Datentrger durch technische Mngel
oder Beschdigung ist kein Einzelfall. Betroffen sind Massenspeicher wie
Festplatten, Bnder oder Kassettensysteme. Festplatten knnen durch den
"Headcrash" des Schreib-/Lesekopfes, Bnder oder Kassetten durch direkte
mechanische Einwirkung zerstrt werden. Auch CD-ROMs knnen durch
Verkratzen der Oberflche unbrauchbar werden. Vor allem aber Disketten
sind von Ausfllen betroffen. Hufig stellt man fest, dass diese nicht mehr
beschreibbar oder lesbar sind.
Beispiele:
- In einem mittelstndischen Unternehmen kam es aufgrund von Bauarbeiten Staubpartikel
zur Staubentwicklung. Die Staubpartikel gelangten auf die Magnetplatte
des im Unternehmen eingesetzten Rechners und fhrten zu einem
"Headcrash", in dessen Folge Daten zerstrt wurden.
- Beim Laptop eines Auendienstmitarbeiters kam es zu unerklrlichen Aus- Magnete
fallerscheinungen, obwohl der Laptop immer sorgfltig verpackt trans-
portiert wurde. Es stellte sich heraus, dass die Festplatte des Laptops durch
einen Magneten beschdigt worden war, der zur Befestigung eines Klapp-
tisches im Zug diente.
- Whrend der Datensicherung eines Multimedia-PCs wurden ZIP-Disketten
auf dessen Lautsprecher zwischengestapelt. Durch die Magnete in den
Lautsprechern wurden Teile der Datentrger gelscht.
- Aufgrund von Bit-Fehlern auf Archivdatentrgern konnten verschlsselte Bit-Fehler
Dokumente nicht mehr entschlsselt werden. Ebenso konnten elektronische
Signaturen nicht mehr verifiziert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.8 Bekanntwerden von Softwareschwachstellen

Unter Softwareschwachstellen sollen unbeabsichtigte Programmfehler
verstanden werden, die dem Anwender nicht oder noch nicht bekannt sind und
ein Sicherheitsrisiko fr das IT-System darstellen. Es werden stndig neue
Sicherheitslcken in vorhandener, auch in weit verbreiteter oder ganz neuer
Software gefunden.
Beispiele:
Bekannte Beispiele fr Softwareschwachstellen waren:
- Ein Sendmail Bug unter Unix, durch den es fr jeden Benutzer mglich
war, unter der UID und GID von sendmail Programme auszufhren und
Dateien zu verndern.
- Die Routine gets unter Unix. Diese wurde vom Programm fingerd zum
Einlesen einer Zeile benutzt, ohne dass eine berprfung der Variablen-
grenzen vorgenommen wurde. So konnte durch einen berlauf der Stack
so verndert werden, dass eine neue Shell gestartet werden konnte.
- cgi-scripte, die mit WWW-Servern mitgeliefert wurden. Entfernte
Anwender konnten sensible Informationen ber den WWW-Server
erlangen.
- Ein Bug in der DNS-Software ermglichte das Flschen zwischen-
gespeicherter DNS-Daten.
- Fehlerhafte Implementationen des TCP/IP-Stacks. Diese ermglichten das
Lahmlegen ganzer Netze mittels bergroer oder anders manipulierter
Pakete.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.9 Ausfall der internen Stromversorgung

Der Einsatz eines mobilen IT-Systems, z. B. eines Laptop, setzt voraus, dass
das System ber eine vom Versorgungsnetz unabhngige Stromversorgung
verfgt. Diese meist mit wiederaufladbaren Batterien konzipierte Stromver-
sorgung reicht blicherweise fr eine mehrstndige Betriebsdauer. Nach
dieser Zeit ist die ausreichende Stromversorgung nicht mehr gesichert, so dass
das IT-System auer Betrieb genommen bzw. an das Stromnetz angeschlossen
werden muss. Die berwiegende Zahl der mobilen Systeme berprft
kontinuierlich die Versorgungsspannung und zeigt einen kritischen
Spannungsabfall an. Wird diese Anzeige ignoriert, kann es passieren, dass das
System pltzlich seinen Dienst versagt und die letzten Arbeitsergebnisse im
Hauptspeicher verloren gehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.10 Komplexitt der Zugangsmglichkeiten zu

vernetzten IT-Systemen
Im Gegensatz zu Stand-alone-Systemen, bei denen im wesentlichen der
Login-Prozess fr die Zugangskontrolle verantwortlich ist und die somit nur
durch schlechte oder fehlende Passwrter korrumpiert werden knnen, gibt es
auf Netzrechnern sehr viele komplexe Prozesse, die die verschiedensten Arten
von Zugngen erlauben. So ermglicht z. B. unter Unix der sendmail-Daemon
das Einbringen von Texten (E-Mails) in den Netzrechner, der FTP-Daemon
einen, wenn auch etwas eingeschrnkten, Login, der u. U. (anonymous FTP)
nicht einmal durch ein Passwort geschtzt ist, der telnet-Daemon einen
kompletten Login.
Server-Systeme wie Windows NT oder Novell Netware vermeiden aus
Sicherheitsgrnden die bertragung von Klartext-Passwrtern. Dieser
Schutzmechanismus wird jedoch durch den Einsatz von Diensten wie FTP
oder Telnet unterlaufen, da hier wieder Klartext-Passwrter Verwendung
finden.
Abgesehen davon, dass alle diese Prozesse durch eine falsche oder fehlerhafte
Konfiguration eine Sicherheitslcke darstellen knnen, ist auf Grund ihres
Umfanges natrlich auch die Wahrscheinlichkeit, dass in einem dieser Pro-
zesse ein sicherheitsrelevanten Programmierfehler ist, wesentlich grer.
Es gibt zahlreiche verschiedene Mglichkeiten, ein z/OS-System an interne
und ffentliche Netze anzubinden. Es sind Zugriffe ber SNA und TCP/IP,
z. B. FTP, TELNET oder Browser, mglich. Viele der von Unix-Installationen
bekannten Netzfunktionen knnen unter den Unix System Services von z/OS
verwendet werden. Diese Vielfalt der Anschlussmglichkeiten macht eine
sichere Netzkonfiguration der z/OS-Systeme sehr komplex.
Beispiel:
Einem externen Angreifer gelang es, die Benutzerkennung und das Passwort Nichtautorisierter
Datenzugriff ber FTP
fr eine hochautorisierte Anwendung unter z/OS zu ermitteln. Obwohl die
Kennung ber kein TSO-Segment verfgte, konnte der Angreifer einen Batch-
Job ber FTP direkt in das JES2 einbringen und ausfhren lassen. Da der Job-
Output ebenfalls ber FTP ausgelesen werden konnte, war dadurch der Zugriff
auf vertrauliche Daten mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.11 Fehlende Authentisierungsmglichkeit

zwischen NIS-Server und NIS-Client
Kennt man den NIS-Domain-Namen, lsst sich jeder Rechner als Client
anmelden, und es lassen sich alle NIS-Maps, insbesondere also auch die
passwd-Map, abrufen.
Ist es mglich, Administrationsrechte auf einem Rechner zu bekommen, lsst
sich auf diesem ein NIS-Server-Prozess (ypserv) an einem privilegierten Port
starten. Startet man nun den Client-Prozess ypbind auf dem zu infiltrierenden
Rechner neu und sorgt dafr, dass der eigene Server-Prozess vor dem
korrekten NIS-Server antwortet, lsst sich jede beliebige Information an den
Client berspielen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.12 Fehlende Authentisierungsmglichkeit

zwischen X-Server und X-Client
Fr das X-Window-System gilt im besonderen Mae, dass es ohne geeignete
Sicherheitsmechanismen, wie z. B. "Magic Cookies" oder Verwendung von
Secure Shell, nur in einer vertrauenswrdigen Umgebung eingesetzt werden
sollte. Ohne Sicherheitsfunktionen besteht fr alle beteiligten Benutzer die
Mglichkeit, sowohl den X-Client als auch den X-Server zu korrumpieren.
Der X-Server-Prozess, der auf einem Rechner fr die Ein- und Ausgabe
zustndig ist, kann nicht erkennen, wem der X-Client-Prozess gehrt, der mit
ihm kommuniziert. Alle X-Clients knnen also auf alle Daten, die auf einem
X-Server eingegeben werden, zugreifen, und der X-Server hat keine
Mglichkeit festzustellen, von welchem X-Client er Daten erhlt. So simuliert
z. B. das Programm meltdown das optische "Schmelzen" des Bildschirms
eines beliebigen X-Servers. Genauso ist es mglich, Daten von einem xterm-
Client zu lesen oder ihm eigene Daten zu schicken, also z. B. Bild-
schirmabzge von einem anderen, mit X-Windows arbeitenden Rechner zu
machen.
Beispiele:
- Mit dem Tool xspy lassen sich automatisiert Tastatureingaben auf einem
Xterm remote protokollieren.
- Fenster, die von einem Angreifer auf einem X-Server dargestellt werden,
sind optisch nicht von denen des eigentlich gewnschten X-Clients zu
unterscheiden. Ein Angreifer kann auf diese Weise falsche Informationen
einschleusen oder mit Hilfe von geflschten Fenstern die Eingabe von
sensitiven Informationen provozieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.13 Verlust gespeicherter Daten

Der Verlust gespeicherter Daten kann erhebliche Auswirkungen auf den IT-
Einsatz haben. Sind die Anwendungsdaten oder die Kundenstammdaten ver-
loren oder verflscht, so knnen privatwirtschaftliche Betriebe in ihrer Exis-
tenz bedroht sein. Der Verlust oder die Verflschung wichtiger Dateien kann
in Behrden Verwaltungs- und Fachaufgaben verzgern oder sogar ausschlie-
en.
Dabei knnen die Grnde fr den Verlust gespeicherter Daten vielfltiger Art
sein:
- Entmagnetisierung von magnetischen Datentrgern durch Alterung oder
durch ungeeignete Umfeldbedingungen (Temperatur, Luftfeuchte),
- Strung magnetischer Datentrger durch uere Magnetfelder,
- Zerstrung von Datentrgern durch hhere Gewalt wie Feuer oder Wasser,
- versehentliches Lschen oder berschreiben von Dateien,
- vorstzliches oder versehentliches Setzen von Lschmarkierungen in
Archivsystemen (siehe auch G 5.106 Unberechtigtes berschreiten oder
Lschen von Archivmedien),
- technisches Versagen von Peripheriespeichern (Headcrash),
- fehlerhafte Datentrger,
- unkontrollierte Vernderungen gespeicherter Daten (Integrittsverlust) und
- vorstzliche Datenzerstrung durch Computer-Viren usw.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.14 Verblassen spezieller Faxpapiere

Bei Faxgerten, die im Thermodruckverfahren arbeiten, muss Spezialpapier
eingesetzt werden, auf dem oft bereits nach relativ kurzer Zeit die Schrift bis
zur Unlesbarkeit verblasst oder durch Schwrzung des Papieres unlesbar wird.
Auerdem knnen sich diese Papiere bei Kontakt mit Textmarkern oder Kleb-
stoffen so verfrben, dass der Text nicht mehr lesbar ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.15 Fehlerhafte Faxbertragung

Beim Faxversand knnen Strungen auf dem bertragungsweg oder an den Strungen auf dem
beteiligten Gerten auftreten. Dadurch knnen Faxsendungen unvollstndig, bertragungsweg
unlesbar oder gar nicht beim Empfnger ankommen. Entscheidungen, die von
diesen Informationen abhngig sind, knnen fehlerhaft sein und somit
Schden verursachen.
Weiterhin besteht die Gefahr, dass ein Fax an einen falschen Empfnger Zustellung an einen
falschen Empfnger
bermittelt wird. Ursache kann eine Fehlschaltung im ffentlichen Tele-
kommunikationsnetz sein. Ebenso ist denkbar, dass bei herkmmlichen
Faxgerten Rufnummern falsch gewhlt oder Zielwahltasten falsch
programmiert werden. Bei der Verwendung von Faxservern kann eine
Empfnger-Rufnummer falsch eingegeben oder im Adressbuch falsch abge-
speichert werden. Dadurch knnen unter Umstnden vertrauliche Infor-
mationen unbefugten Personen bekannt werden. Der mgliche Schaden ist von
der Vertraulichkeit der Informationen abhngig. Darber hinaus wird der
Absender im Glauben bleiben, dass das Fax ordnungsgem an den
gewnschten Adressaten bermittelt wurde. Hierdurch auftretende Zeitver-
zgerungen knnen zu Schden fhren.
Beispiel:
Eine bekannte deutsche Firma verlor einen Groauftrag, weil das Angebot
versehentlich an einen falschen Empfnger versandt wurde.
Hinweis:
Die Gefhrdungen G 4.16 bertragungsfehler bei Faxversand und
G 4.17 Technischer Defekt des Faxgertes wurden in die Gefhrdung
G 4.15 Fehlerhafte Faxbertragung integriert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.18 Entladene oder beralterte Notstromversorgung

im Anrufbeantworter
Bei Anrufbeantwortern mit einem digitalen Speicher wird der Ausfall der
Netzenergieversorgung durch Batterie oder Akkumulator berbrckt, um so
den Speicherinhalt zu erhalten. Ist die Kapazitt von Batterie oder Akkumu-
lator vor Ende der Netzunterbrechung erschpft, werden in der Regel der
Ansagetext und zustzlich bei digitaler Anrufaufzeichnung auch die bereits
aufgesprochenen Nachrichten gelscht.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.19 Informationsverlust bei erschpftem

Speichermedium
Ist das Speichermedium (digitaler Speicher oder Audiokassette) des Anruf-
beantworters mit aufgezeichneten Anrufen erschpft, so ist eine weitere Auf-
zeichnung entweder nicht mehr mglich oder vorher aufgesprochene Nach-
richten werden durch neue Anrufe berschrieben. In beiden Fllen entsteht ein
Informationsverlust.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.20 Datenverlust bei erschpftem Speichermedium

Jedes Speichermedium kann nur begrenzt viele Daten aufnehmen. Wenn diese
Grenze erreicht ist, kann das zu Datenverlusten fhren, aber auch dazu, dass
Dienste nicht mehr verfgbar sind, wie z. B. dass
- Benutzer keine Daten mehr abspeichern knnen,
- eingehende E-Mail abgewiesen wird und eventuell auerdem keine E-Mail
mehr versandt werden kann,
- eingehende und gegebenenfalls ausgehende Faxsendungen abgewiesen
werden,
- keine Protokollierung mehr mglich ist bzw. noch nicht ausgewertete
Protokolldaten berschrieben werden oder
- Dokumente nicht mehr elektronisch archiviert werden knnen.
Die Kapazitt des Speichermediums kann aus verschiedenen Grnden pltz-
lich erschpft sein, z. B. durch Fehler in Anwendungsprogrammen, erhhten
Speicherbedarf der Benutzer oder auch durch einen gezielten Angriff, bei dem
vorstzlich der vorhandene Speicherplatz reduziert wird, um eine Protokollie-
rung zu verhindern.
Bei der elektronischen Archivierung sind meist groe Datenmengen zu groe Datenmengen bei
der Archivierung
sichern. Die Datenmengen entstehen einerseits durch die groe Anzahl von
Dokumenten, die bei bestimmten Vorgngen zu archivieren sind. Hinzu
kommt andererseits, dass jede neu erstellte Version eines Dokuments unter
Vergabe einer neuen Versionsnummer neu gespeichert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.21 Ausgleichsstrme auf Schirmungen

Werden IT-Gerte, die ber ein TN-C-Netz elektrisch versorgt werden, durch
Datenleitungen mit beidseitig aufgelegtem Schirm miteinander verbunden,
kann es zu Ausgleichsstrmen auf dem Schirm kommen (eine erluternde
Zeichnung findet man in M 1.39 Verhinderung von Ausgleichsstrmen auf
Schirmungen).
Ursache dafr ist die Eigenart des TN-C-Netzes, dass bei ihm Schutz- (PE-)
und Neutral- (N-) Leiter bis zu den einzelnen Verteilungen gemeinsam als
PEN-Leiter gefhrt werden. Erst in der Verteilung erfolgt die Aufteilung in N-
Leiter und PE-Leiter. Diese Installation ist gem VDE 0100 zulssig!
Werden die mit PE verbundenen Schnittstellen-Schirmungen von Gerten, die
an verschiedenen Verteilungen angeschlossen sind, durch geschirmte Daten-
leitungen miteinander verbunden, kommt es zu einer Parallelschaltung des
PEN-Leiters zwischen den Verteilungen und der Schirmung zwischen den
Schnittstellen. Der dadurch ber die Schirmung flieende Ausgleichsstrom
kann zu Schden an den Schnittstellen und zu Personengefhrdungen bei
Arbeiten an den Datenleitungen fhren.
Zwischen Gerten, die in einem TN-C-Netz an der gleichen Verteilung oder
zwischen Gerten, die in einem TN-S-Netz - auch an verschiedenen Vertei-
lungen - angeschlossen sind, flieen keine Ausgleichsstrme ber die Schir-
mung von Datenleitungen.
Bei TN-CS-Netzen sind einige Teilbereiche als TN-C-Netz, andere als TN-S-
Netz ausgefhrt. Solange Datenleitungen mit beidseitig aufgelegtem Schirm
nur jeweils innerhalb gleichartiger Teilbereiche gefhrt werden, gelten dort
die gleichen Verhltnisse wie in den jeweiligen Netzen. Werden jedoch IT-
Gerte aus unterschiedlichen Bereichen ber Datenleitungen mit beidseitig
aufgelegter Schirmung verbunden, knnen auch im TN-S-Bereich Aus-
gleichsstrme flieen!
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.22 Software-Schwachstellen oder -Fehler

Wie fr jede Software gilt auch fr Standardsoftware: je komplexer sie ist,
desto hufiger treten Programmierfehler auf. Es ist zu beobachten, dass hohe
Erwartungen der Anwender und zeitlich zu knapp bemessene Erscheinungs-
termine bei Standardsoftwareprodukten auch dazu fhren, dass die Hersteller
ihre Produkte teilweise unausgereift oder nicht fehlerfrei anbieten. Werden
diese Softwarefehler nicht erkannt, knnen die bei der Anwendung entstehen-
den Fehler zu weitreichenden Folgen fhren.
Beispiele:
- Ein Software-Fehler in der Sicherheits-Software RACF des z/OS-Betriebs-
systems kann bedeuten, dass nicht nur RACF den Dienst einstellt, sondern
dadurch das ganze System nicht mehr funktionsfhig ist und neu gestartet
werden muss.
- Die Strke der in Standardsoftware implementierten Sicherheitsfunk-
tionalitten (wie Passwrter oder Verschlsselungsalgorithmen) wird vom
Anwender hufig zu hoch eingeschtzt. Hufig knnen diese Sicherheits-
funktionalitten einem sachkundigen Angriff nicht dauerhaft standhalten.
Dies gilt z. B. fr die Verschlsselungsfunktionen, die in vielen Textver-
arbeitungsprogrammen integriert sind. Fr fast alle davon gibt es im Inter-
net zahlreiche Tools, um diese Verschlsselung zu berwinden.
- Nachweislich fhrte das Auftreten eines bestimmten Wortes in der Recht-
schreibprfung eines Textverarbeitungsprogrammes immer zu dessen
Absturz.
- Vielfach enthlt Standardsoftware nicht dokumentierte Funktionen, wie
sog. "Ostereier" oder "Gagscreens", mit denen sich die Entwickler des
Produktes verewigt haben. Zum einen werden hierdurch zustzliche IT-
Ressourcen verbraucht, zum anderen wird dadurch auch deutlich, dass im
Softwaretest die gesamte Funktionalitt des Produktes nicht bis ins letzte
geklrt werden kann.
- Die meisten Warnmeldungen der Computer Emergency Response Teams
in den letzten Jahren bezogen sich auf sicherheitsrelevante Programmier-
fehler. Dies sind Fehler, die bei der Erstellung von Software entstehen und
dazu fhren, dass diese Software von Angreifern missbraucht werden kann.
Der grte Teil dieser Fehler wurde durch Speicherberlufe (Buffer
Overflow) hervorgerufen. Hierbei handelt es um Fehler, bei denen eine
Routine zum Einlesen von Zeichen nicht prft, ob die Lnge der einge-
gebenen Zeichenkette mit der Lnge des dafr vorgesehenen Speicher-
bereiches bereinstimmt. Dadurch ist es Angreifern mglich, eine ber-
lange Zeichenfolge zu bertragen, so dass hinter dem fr die Eingabe
reservierten Speicherbereich zustzliche Befehle gespeichert werden
knnen, die zur Ausfhrung gebracht werden. Diese Befehle knnen z. B.
beliebige Programme sein.
- Eine weitere groe Anzahl von Warnmeldungen wurde durch Verfgbar-
keitsangriffe (Denial of Service, DoS) verursacht, bei denen durch Fehler
in einzelnen Routinen, die fr die Netzdatenverarbeitung eingesetzt
werden, der gesamte Rechner zum Absturz gebracht werden kann (siehe
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
z. B. CERT Advisory 97.28 zu IP Denial-of-Service Attacks: Teardrop and

Land-Attack).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.23 Automatische CD-ROM-Erkennung

Bei eingeschalteter CD-ROM-Erkennung unter Windows 95 oder
Windows NT werden CD-ROMs automatisch erkannt und die Datei
AUTORUN.INF automatisch ausgefhrt, wenn diese sich im Wurzel-
verzeichnis der CD-ROM befindet. Diese Datei kann beliebige auf der CD-
ROM gespeicherte Programme (z. B. mit Schadfunktion) automatisch ausfh-
ren.
Ob diese Option eingeschaltet ist, erkennt man zum Beispiel unter
Windows 95 daran, dass der Explorer vor dem CD-ROM-Laufwerksbuch-
staben den Namen der CD-ROM automatisch einblendet. Ein Nebeneffekt
hierbei ist, dass Energiespar-Funktionen in der Regel nicht mehr aktiviert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.24 Dateinamenkonvertierung bei

Datensicherungen unter Windows 95
Werden zur Datensicherung unter Windows 95 Programme benutzt, die lange
Dateinamen nicht untersttzen, so sind alle langen Dateinamen vor der Daten-
sicherung mit dem zum Lieferumfang von Windows 95 gehrenden
Programm LFNBK.EXE und der Option /B in die 8.3er-Konvention zu
konvertieren. Anschlieend ist das Datensicherungsprogramm aufzurufen.
Schlielich sind die ursprnglichen Dateinamen mit LFNBK.EXE /R wieder
herzustellen.
Dieses Verfahren ist jedoch mit Vorsicht anzuwenden, da zum einen bei der
Namenskonvertierung Informationen verloren gehen knnen, zum anderen
sich Dateien nicht mehr herstellen lassen, sobald sich die Verzeichnisstruktur
nach der Datensicherung auf diesem PC gendert hat. Dies kann dann einen
Datenverlust zur Folge haben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.25 Nicht getrennte Verbindungen

Bei der Verwendung von ISDN-Kommunikationskarten kann es vorkommen,
dass eine ber die Kommunikationssoftware ausgelste Verbindung nicht
tatschlich durch die ISDN-Karte getrennt wird. Besteht der Verdacht eines
solchen Defekts, lsst sich dieser durch einen Anrufversuch bei der betreffen-
den ISDN-Rufnummer leicht verifizieren.
Beispiel:
Ein Netzadministrator hat vor seinem 14-tgigen Urlaub eine ISDN-Daten-
verbindung zu seinem Internet-Provider aufgebaut. Bei Beendigung der
Sitzung wurde die ISDN-Verbindung nicht korrekt ausgelst. Nach Beendi-
gung des Urlaubs wunderte sich der Administrator ber die recht hohe Rech-
nung fr Verbindungsentgelte von Seiten des ISDN-Carriers.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.26 Ausfall einer Datenbank

Steht eine Datenbank, z. B. aufgrund von Hardware- oder Software-Proble-
men bzw. durch Sabotage, nicht mehr zur Verfgung, so kann dies je nach
Einsatzzweck und Bedeutung der Datenbank weitreichende Folgen haben.
Smtliche Anwendungen, die auf die Daten der Datenbank angewiesen sind,
knnen nicht mehr benutzt werden und fallen ebenfalls aus. Die Benutzer
solcher Anwendungen knnen ihre Aufgaben nur noch teilweise oder gar nicht
mehr wahrnehmen, falls sie diese nicht mit manuellen Mitteln erfllen kn-
nen. Je nach Art der Aufgaben, die nur mittels IT-Untersttzung unter Benut-
zung der Datenbank ausgefhrt werden knnen, sind folgende Konsequenzen
mglich:
- wirtschaftlicher Schaden,
- Sicherheitsrisiken, die bis hin zu Beeintrchtigungen im persnlichen
Bereich fhren knnen (z. B. bei medizinischen Datenbanken),
- Vertrauensverlust durch die Nichtbeibringung archivierter Dokumente,
- bedingte oder komplette Handlungsunfhigkeit.
Beispiele:
- Elektronische Archive basieren auf einer Datenbank, in der alle archi- Index-Datenbank von
Archiven
vierten Dokumente indiziert sind. Bei einem Ausfall dieser Index-Daten-
bank knnen archivierte Dokumente nicht wiedergefunden bzw. nicht ge-
sucht werden. Dadurch ist, wenn berhaupt, nur ein stark eingeschrnkter
Betrieb des Archivs mglich.
- Die Inhalte sowie alle Zusatzinformationen einer regelmig erscheinen- Wartungsarbeiten
den Publikation wurden komplett in eine Datenbank verlagert. Da fr alle
Arbeiten im zustndigen Referat zumindest ein lesender Zugriff auf diese
Datenbank erforderlich ist, sind ohne das korrekte Funktionieren dieser
Datenbank keine inhaltlichen Arbeiten mehr mglich. Nachdem die Daten-
bank aufgrund von Wartungsarbeiten heruntergefahren wurde, entstanden
Verzgerungen bei der Wartung. Das Referat konnte insgesamt eine
Woche inhaltlich nur sehr eingeschrnkt arbeiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.27 Unterlaufen von Zugriffskontrollen ber ODBC

Existierende Zugangs- oder Zugriffskontrollen einer Datenbank knnen unter-
laufen werden, wenn auf die Datenbank auerhalb einer Anwendung ber
ODBC (Open Database Connectivity) zugegriffen wird und bei der Installa-
tion der ODBC-Treiber Fehler gemacht wurden. In diesem Fall kann ein
Schutz vertraulicher Daten nicht mehr gewhrleistet werden, ebenso ist auch
die Manipulation von Daten ohne weiteres mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.28 Verlust von Daten einer Datenbank

Ein Verlust von Daten einer Datenbank kann auf vielfltige Art und Weise
verursacht werden. Dies kann sich von ungewollten Datenmanipulationen
(z. B. durch das unbeabsichtigte Lschen von Daten) ber einen Verlust durch
einen Crash der Datenbank bis hin zu gezielten Angriffen erstrecken.
Dadurch ist die Verfgbarkeit und die Vollstndigkeit der Daten nicht mehr
gewhrleistet, und es kann zu folgenden Konsequenzen kommen:
- Bestimmte Anwendungen, die auf die Daten der Datenbank angewiesen
sind, knnen ggf. nicht mehr oder nicht mehr in vollem Umfang ausgefhrt
werden.
- Der Informationsgehalt der Daten in ihrer Gesamtheit geht verloren.
- Es entsteht ein hoher Aufwand, um die zerstrten Daten wiederzube-
schaffen.
Je nach Ursache des Datenverlusts kann es schwer bis unmglich sein festzu-
stellen, welche Daten nicht mehr vorhanden sind. Dies kann weitere wirt-
schaftliche Schden oder Sicherheitsrisiken nach sich ziehen.
Beispiel:
Bei nderungen des Datenmodells mssen zunchst die alten Tabellen und
Strukturen gesichert und dann gelscht werden. Anschlieend werden die
neuen Tabellen angelegt. Danach mssen die alten Datenbestnde konvertiert
und in die genderten Tabellen eingespielt werden. Durch Fehler bei diesen
Ablufen kann es schnell passieren, dass Daten verloren gehen oder sich nicht
mehr einspielen lassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.29 Datenverlust einer Datenbank bei erschpftem

Speichermedium
Jedes Speichermedium kann nur begrenzt viele Daten aufnehmen. Dies gilt
auch fr eine Datenbank, die fr die dauerhafte Speicherung ihrer Daten auf
ein physikalisches Speichermedium zurckgreifen muss. Ist dieses erschpft,
kann es zu einem Crash der Datenbank und einem Verlust von Daten
kommen. Die sich daraus ergebenden Konsequenzen werden in G 4.28
Verlust von Daten einer Datenbank beschrieben.
Die Kapazitt des Speichermediums kann aus verschiedenen Grnden pltz-
lich erschpft sein, z. B. durch Fehler in Anwendungsprogrammen, erhhtem
Speicherbedarf der Benutzer oder auch durch einen gezielten Angriff, bei dem
vorstzlich der vorhandene Speicherplatz reduziert wird, um z. B. eine Proto-
kollierung zu verhindern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.30 Verlust der Datenbankintegritt/-konsistenz

Ein Verlust der Datenbankintegritt/-konsistenz bedeutet, dass die Daten in
der Datenbank zwar noch vorhanden sind, aber einen fehlerhaften oder sinn-
losen Wert angenommen haben. Dadurch knnen die Daten nicht mehr korrekt
verarbeitet werden. Dies kann auf vielfltige Art und Weise verursacht
werden, von ungewollten Datenmanipulationen (z. B. durch das unbeabsich-
tigte ndern von Daten) ber eine fehlerhafte Synchronisationskontrolle der
Transaktionen bis hin zu gezielten Angriffen.
Dadurch kann es zu folgenden Konsequenzen kommen:
- Bestimmte Aufgaben, die auf die korrekten Daten der Datenbank ange-
wiesen sind, knnen ggf. nicht mehr oder nicht mehr in vollem Umfang
durchgefhrt werden.
- Der Informationsgehalt der Daten in ihrer Gesamtheit wird verflscht.
- Es entsteht ein hoher Aufwand, um die Datenintegritt und Datenkon-
sistenz der Datenbank wiederherzustellen.
Je nach Ursache der Verletzung der Datenbankintegritt/-konsistenz kann es
schwer bis unmglich sein festzustellen, welche Daten verndert wurden. Dies
kann weitere wirtschaftliche Schden oder Sicherheitsrisiken nach sich ziehen.
Beispiele:
- Aus Platzmangel und Zeitdruck wurde auf einem Unix-Server eine Datei
einer Datenbank im /tmp-Dateisystem angelegt. Dieses wurde durch einen
cron-Job ber Nacht gelscht, so dass daraufhin die gesamte Datenbank
nicht mehr nutzbar war.
- Elektronische Archive basieren auf einer Datenbank, in der alle archivier-
ten Dokumente indiziert sind. Bei Verlust der Indizierung oder der Refe-
renz auf einzelne Dokumente knnen diese unter Umstnden nicht mehr
mit vertretbarem Aufwand gefunden werden. Aus einem solchen Verlust
der Datenbankintegritt kann zu einem spteren Zeitpunkt ein erheblicher
wirtschaftlicher oder juristischer Schaden entstehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.31 Ausfall oder Strung von Netzkomponenten

Durch einen Ausfall oder eine Strung von aktiven Netzkomponenten kommt
es zu einem Verlust der Verfgbarkeit des Netzes oder von Teilbereichen
davon. Hier knnen 3 Varianten unterschieden werden:
- Bei Ausfall oder Strung der kompletten Netzkomponente ist das gesamte
Netz fr alle angeschlossenen Endgerte nicht mehr verfgbar. Beim Aus-
fall oder Strung nur eines Ports ist nur fr das dort angeschlossene End-
gert das Netz nicht mehr verfgbar.
Beispiel: Fllt, wie in der folgenden Abbildung dargestellt, der zentrale
Switch 1 vllig aus, ist keinerlei Kommunikation zwischen den ange-
schlossenen Endgerten mehr mglich.
- Es handelt sich um aktive Netzkomponenten, die zwar nicht direkt an den

Netzsegmenten von miteinander kommunizierenden Arbeitsplatz- und
Serversystemen angeschlossen sind, jedoch im Signalpfad zwischen
Arbeitsplatz- und Serversystemen liegen. Falls keine redundanten Signal-
pfade zwischen den betreffenden Arbeitsplatz- und Serversystemen zur
Verfgung stehen, kann bei Ausfall oder Strung einer oder mehrerer
dieser Komponenten keine oder nur eingeschrnkte Kommunikation
zwischen Arbeitsplatz- und Serversystemen mehr stattfinden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel: Fllt, wie in der folgenden Abbildung dargestellt, Switch 1 vllig

aus, ist von den Arbeitspltzen 3 und 4 weder eine Kommunikation mit den
beiden Servern noch mit den anderen Arbeitpltzen mglich.
- Es handelt sich um aktive Netzkomponenten, die nicht notwendigerweise

im Signalpfad zwischen Arbeitsplatz- und Serversystemen liegen, da ein
zweiter, redundanter Signalpfad existiert. Dies knnen z. B. aktive Netz-
komponenten sein, die aus Redundanzgrnden oder zum Load-Balancing
installiert sind. Bei Ausfall oder Strung einer oder mehrerer dieser
Komponenten ist eine Kommunikation zwischen Arbeitsplatz- und Server-
systemen weiter mglich, es tritt jedoch dennoch ein Bandbreitenverlust im
Netz ein, da redundante Signalpfade ggf. nicht mehr vorhanden sind oder
eine Lastverteilung im Netz nicht mehr im vollen Umfang mglich ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel: Fllt, wie in der folgenden Abbildung dargestellt, einer der

redundanten Switches 1-1 oder 1-2 aus, kann dies einen Bandbreitenverlust
in der Kommunikation zwischen den Arbeitspltzen und dem Server zur
Folge haben.
Zur Beurteilung des Ausfallrisikos knnen die herstellerseitig angegebenen

MTBFs (Mean Time Between Failure) der Komponenten herangezogen
werden.
Bei Hubs knnen prinzipiell zwei Techniken unterschieden werden, wie die
Verbindung zwischen den einzelnen Modulen und damit den angeschlossenen
Segmenten erfolgt. Bei Produkten mit passiver Backplane, dem Element,
welches die Verbindung zwischen Modulen herstellt, stellt diese lediglich die
elektrische Verbindung zwischen den Modulen her. Die eigentliche Steue-
rungselektronik ist auf den einzelnen Modulen untergebracht. Bei Produkten
mit aktiver Backplane stellt diese zustzliche Funktionalitt bereit, wie konfi-
gurierbare Kommunikation zwischen den Modulen, Signalverstrkung usw.
Generell sollte bercksichtigt werden, dass aktive Netzkomponenten mit
aktiver Backplane stranflliger sind, als aktive Netzkomponenten mit passi-
ver Backplane. Durch den Ausfall einer aktiven Backplane fllt die gesamte
Kommunikation innerhalb der entsprechenden Netzkomponente aus. Eine
passive Backplane kann aufgrund ihrer Bauweise dagegen nur durch mecha-
nische Gewalteinwirkung oder durch hhere Gewalt (z. B. Blitzschlag) zer-
strt werden. Weiterhin stellt das Netzteil der Komponenten eine hufige
Strungsursache dar, da alle aktiven Netzkomponenten auf eine stabile
Stromversorgung angewiesen sind. Viele Komponenten lassen sich deshalb
mit redundanten Netzteilen ausrsten oder sind hiermit bereits ausgestattet. Im
gleichen Mae kann der Ausfall einer passiven Netzkomponente den Verlust
der Verfgbarkeit eines Netzes bedingen. Dies trifft beispielsweise fr Kabel
und Steckverbinder zu, die Segmente miteinander verbinden. Diese
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Gefhrdung kann z. B. bei nicht sachgemer Installation der Kabel (z. B.

Nichtbeachtung des maximalen Biegeradiuses), fehlerhafter Konfektion der
Kabel mit Steckverbindern (insbesondere bei LWL) oder Strungen durch
elektromagnetische Unvertrglichkeit eintreten.
Beispiel: Fllt, wie in der folgenden Abbildung dargestellt, die Verbindung
zwischen Switch 3 und Switch 1 durch ein defektes Kabel oder einen defekten
Steckverbinder aus, knnen die Arbeitspltze 3 und 4 weder mit den Servern,
noch mit den Arbeitspltzen 1 und 2 kommunizieren. Eine Kommunikation
zwischen den Arbeitspltzen 3 und 4 ist jedoch weiterhin mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.32 Nichtzustellung einer Nachricht

Der Datenaustausch ber E-Mail ist schnell und komfortabel, aber nicht
immer sehr zuverlssig. Aufgrund von Hardware- oder Softwarefehlern bei
den beteiligten IT-Systemen oder durch Strungen auf dem bertragungsweg
kommt es immer wieder zum Nachrichtenverlust. Die technischen Probleme
knnen vielfltige Ursachen haben, z. B. knnen Leitungen beschdigt sein,
Netzkopplungselemente ausfallen oder die Kommunikationssoftware falsch
konfiguriert sein. E-Mails knnen auch verloren gehen, weil die Empfnger-
adresse nicht korrekt angegeben war. Dabei ist das grte Problem, dass die
Benutzer hufig nicht ber die unterbliebene Zustellung der E-Mail informiert
werden. Auf eine automatisierte Unterrichtung bei einer unterbliebenen
Zustellung kann nicht vertraut werden.
Viele E-Mailprogramme bieten Optionen wie "Zustellung besttigen" oder
"Empfang besttigen". Entsprechende Rckmeldungen sollten aber nicht
berbewertet werden. Zum einen werden die Zustellbesttigungen hufig nicht
durch die Ankunft einer E-Mail am Bildschirmarbeitsplatz des Empfngers
ausgelst wird, sondern durch die Ankunft bei einem Mailserver. Ob der
Mailserver die E-Mail erfolgreich an den Adressaten weitergeleitet hat, wird
dann nicht mehr mitgeteilt. Zum anderen erfolgt auch hufig keine
Zustellbesttigung, obwohl die E-Mail korrekt bertragen wurde, wenn diese
Option durch die Empfngerseite nicht untersttzt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.33 Schlechte oder fehlende Authentikation

Authentikationsmechanismen knnen zur Authentikation von Benutzern oder
Komponenten oder zur Bestimmung des Datenursprungs eingesetzt werden.
Wenn Authentikationsmechanismen fehlen oder zu schlecht sind, besteht die
Gefahr, dass
- Unbefugte auf IT-Systeme oder Daten Zugriff nehmen knnen,
- die Verursacher von Problemen nicht identifiziert werden knnen oder
- die Herkunft von Daten nicht bestimmt werden kann.
Sicherheitslcken entstehen
- bei der Benutzerauthentikation, wenn z. B. Benutzer Passwrter whlen,
die einfach zu erraten sind, oder wenn sie die Passwrter nie wechseln,
- bei der Komponentenauthentikation, wenn z. B. nach Inbetriebnahme eines
IT-Systems Default-Passwrter nicht durch individuell gewhlte ersetzt
werden, wenn die Passwrter, die bei vielen IT-Systemen fest eingegeben
werden, nie wieder gendert werden oder wenn die Passwrter nicht sicher
hinterlegt werden und sich nach einem Systemabsturz herausstellt, dass das
jetzt dringend bentigte Passwort vergessen wurde,
- bei der Wahl der Verfahren, wenn diese z. B. vllig untauglich sind oder
Sicherheitslcken bekannt werden, auf die im laufenden Betrieb aber nicht
reagiert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.34 Ausfall eines Kryptomoduls

Wird ein Kryptomodul zur Sicherung der Vertraulichkeit schtzenswerter
Daten eingesetzt, kommt dem fehlerfreien Funktionieren des Kryptomoduls
eine besondere Bedeutung zu. Der Ausfall eines solchen im Einsatz befind-
lichen Kryptomoduls kann auf verschiedene Ursachen zurckzufhren sein:
- technischer Defekt, der die Funktionsfhigkeit beeintrchtigt,
- Stromausfall, in dessen Folge die flchtig gespeicherten kryptographischen
Schlssel gelscht werden, so dass das Kryptomodul infolgedessen nicht
mehr ordnungsgem verschlsseln kann,
- unabsichtliche oder absichtliche Zerstrung durch mechanische Einwir-
kung, Fehlbedienung oder hnliches.
Die Folgeschden aufgrund des Ausfalls eines Kryptomoduls knnen eben-
falls vielseitig sein. Hier sind insbesondere zu nennen:
- Die kryptographische Absicherung einer Datenbertragungsstrecke ist
nicht mehr mglich, so dass die Vertraulichkeit temporr nicht mehr
gewahrt werden kann. Dies ist insbesondere dann kritisch, wenn der Aus-
fall nicht bemerkt wird und durch die Fehlfunktion keine Verschlsselung
mehr stattfindet, obwohl die Anwender auf die Sicherstellung der Vertrau-
lichkeit der Daten durch das Kryptomodul bauen.
- Verschlsselte Daten knnen nicht mehr entschlsselt werden, solange das
erforderliche Kryptomodul nicht mehr verfgbar ist. Daraus knnen sich
Verfgbarkeitsprobleme fr IT-Anwendungen ergeben, die die entschls-
selten Daten weiterverarbeiten.
- Arbeitet das Kryptomodul fehlerhaft, ohne dass ein vollstndiger Ausfall
eintritt, werden Daten unvollstndig oder inkorrekt verschlsselt. In beiden
Fllen kann es bedeuten, dass im Falle der Datenbertragung der Empfn-
ger der Daten bzw. bei lokaler Speicherung der Daten der Anwender die
Daten nicht mehr korrekt entschlsseln kann. Ohne entsprechende Daten-
sicherungen bedeutet dies ggf. einen Totalverlust der Daten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.35 Unsichere kryptographische Algorithmen

Der Sicherheitszugewinn durch Einsatz kryptographischer Verfahren ist
grundstzlich von zwei Parametern abhngig: es mssen sichere krypto-
graphische Algorithmen eingesetzt werden und die geheimen Schlssel
mssen vertraulich gehandhabt werden (zur Kompromittierung krypto-
graphischer Schlssel siehe G 5.83 Kompromittierung kryptographischer
Schlssel).
Unsichere kryptographische Algorithmen sind dadurch gekennzeichnet, dass
es einem potentiellen Angreifer mit vertretbaren Ressourcen gelingt, das
eingesetzte kryptographische Verfahren zu brechen. Bei Verschlsselungs-
algorithmen bedeutet dies, dass es gelingt, aus dem verschlsselten Text den
ursprnglichen Klartext zu ermitteln, ohne dass zustzliche Informationen
bekannt sind. Dabei sind als relevante Ressourcen auf Angreiferseite z. B. die
verfgbare Rechenleistung, Hilfsmittel wie Analysetools, vorhandene
Kenntnisse, verfgbare Arbeitszeit, Kenntnisse ber Schwachstellen etc. zu
bercksichtigen. Werden also unsichere kryptographische Algorithmen einge-
setzt, besteht fr Angreifer die Mglichkeit, den kryptographischen Schutz zu
unterlaufen.
Ob jedoch ein kryptographischer Algorithmus unsicher ist, muss jeweils im
Einzelfall untersucht werden. Es gibt jedoch einige Kriterien, die auf
Unsicherheiten schlieen lassen:
- Werden bei symmetrischen Verschlsselungsverfahren geheime Schlssel
benutzt, deren effektive Lnge geringer als 60 Bit ist, so knnen sie heute
mit moderatem Rechnereinsatz durch Ausprobieren aller potentiell mg-
lichen Schlssel gebrochen werden. Mit steigender Rechnerleistung ist
anzunehmen, dass diese Grenze in Zukunft ber 100 Bit steigen wird.
- Werden bei asymmetrischer Verschlsselungs- und Signaturverfahren
Algorithmen eingesetzt, deren Sicherheit auf dem Problem des Faktori-
sierens groer Zahlen basiert, so wird heute angenommen, dass Schlssel-
lngen von weniger als 1024 Bit als unsicher zu betrachten sind. Dies
begrndet sich in den Fortschritten bei der Entwicklung effizienter Fak-
torisierungsalgorithmen, die heute unter massivem Rechnereinsatz Faktori-
sierungen von Zahlen mit rund 500 Bit erlauben. Daneben ist die mgliche
Entwicklung von opto-elektronischen Beschleunigern fr einen
wesentlichen Teil-Rechenschritt bei diesen Verfahren in Betracht zu
ziehen, was diese wesentlich beschleunigen wrde.
- Hashfunktionen, die eine beliebig lange Zeichenkette auf einen Hashwert
mit konstanter Bitlnge abbilden, knnen als unsicher betrachtet werden,
wenn die konstante Lnge des Hashwertes geringer ist als 128 Bit, da sonst
zwei Zeichenketten ermittelt werden knnen, die den gleichen Hashwert
ergeben.
- Kryptographische Algorithmen, die von unerfahrenen Entwicklern entwor-
fen wurden und nicht in der wissenschaftlichen Szene untersucht wurden,
sollten als potentiell unsicher betrachtet werden, da die Entwicklung
sicherer kryptographischer Algorithmen langjhrige Erfahrung voraussetzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Nicht verffentlichte kryptographische Algorithmen, die auffllig schnell

in Software ablaufen, sollten ebenfalls als potentiell unsicher betrachtet
werden. Die Erfahrung zeigt, dass sichere Algorithmen meist auf kom-
plexen mathematischen Funktionen beruhen mssen.
- Bei der Anwendung kryptographischer Verfahren werden hufig Zufalls-
zahlen bentigt. Schlechte Zufallszahlengeneratoren knnen dazu fhren,
dass die damit erzeugten Werte vorhersagbar sind. Dadurch knnen z. B.
kryptographische Checksummen, die die Nachrichtenintegritt sicher-
stellen sollen, wertlos werden.
Von diesen Kriterien betroffen ist beispielsweise der weltweit sehr hufig
eingesetzte DES-Algorithmus zur symmetrischen Verschlsselung. Dieser
benutzt eine effektive Schlssellnge von 56 Bit. Der so genannte Triple-
DES-Algorithmus als dreifache Hintereinanderausfhrung mit zwei Schls-
seln hat eine effektive Schlssellnge von 112 Bit und kann zurzeit noch als
ausreichend sicher betrachtet werden. Auch betroffen ist der RSA-Algorith-
mus, der als asymmetrisches Verfahren auf dem Faktorisierungsproblem
basiert. Wird RSA mit einer Schlssellnge unter 768 Bit betrieben, muss
davon ausgegangen werden, dass dies keine ausreichende Sicherheit bietet.
Fr die nchsten Jahre kann eine Schlssellnge von mindestens 1024 Bit
noch als ausreichend sicher angesehen werden.
Ein hufiges Beispiel unsicherer, aber sehr schneller Algorithmen ist die so
genannte XOR-Funktion, bei der konstante Werte mit dem ursprnglichen
Klartext auf einfache Weise verknpft werden. Dies ist ein hochperformanter
Algorithmus, der jedoch sehr schnell gebrochen werden kann. Die XOR-
Funktion kann andererseits aber der sicherste Verschlsselungsalgorithmus
berhaupt sein, wenn die zu verschlsselnden Daten mit nicht vorhersagbaren
Zufallswerten XOR-iert werden (One-Time-Pad).
Fr den Laien ist es praktisch unmglich, festzustellen, ob ein krypto-
graphischer Algorithmus ausreichend sicher ist. Daher sollten nur solche
Algorithmen eingesetzt werden, die bekanntermaen von Experten entwickelt
wurden oder die einer langjhrigen Untersuchung durch die wissenschaftliche
Szene unterzogen wurden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.36 Fehler in verschlsselten Daten

Liegen Daten in verschlsselter Form vor und werden diese verndert, kann es
bei der Entschlsselung der Daten dazu kommen, dass die Daten nicht mehr
korrekt entschlsselt werden knnen. Je nach Betriebsart der Verschls-
selungsroutinen kann dies bedeuten, dass nur wenige Bytes falsch
entschlsselt werden oder dass smtliche Daten ab dem Fehler falsch
entschlsselt werden. Gibt es keine Datensicherung, kann dies einen
Totalverlust der Daten bedeuten.
Die genannten Fehler in den verschlsselten Daten knnen auf verschiedene
Weise entstehen:
- Bei der Datenbertragung der verschlsselten Daten kommt es zu einem
bertragungsfehler, der nicht behoben werden kann.
- Auf dem Speichermedium (Diskette, Festplatte) kommt es zu einem irre-
parablen Fehler.
- Ein Computer-Virus fhrt an den Daten Manipulationen durch.
- Ein Dritter fhrt absichtlich Manipulationen an den Daten durch,
beispielsweise indem die verschlsselten Daten mit einem Editorprogramm
an wenigen Stellen manipuliert werden.
In ungnstigen Fllen, wenn z. B. ein Bitverlust auftritt oder zu groe
Datenmengen verndert werden und eine Fehlerfortpflanzung stattfindet,
knnen die Daten selbst bei Kenntnis des kryptographischen Verfahrens und
der zur Verschlsselung benutzten Schlssel nicht mehr rekonstruiert werden.
Noch kritischer kann sich ein Fehler in den verwendeten kryptographischen
Schlsseln auswirken. Schon die nderung eines einzigen Bits eines krypto-
graphischen Schlssels fhrt dazu, dass smtliche damit verschlsselten Daten
nicht mehr entschlsselt werden knnen. Ohne eine Datensicherung des
kryptographischen Schlssels sind diese Daten verloren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.37 Mangelnde Authentizitt und Vertraulichkeit von

E-Mail
E-Mails ersetzen an vielen Stellen die herkmmliche Kommunikation per
Post. Dabei wird jedoch hufig nicht beachtet, dass "normale" E-Mail ohne
zustzliche Sicherungsmanahmen keine Gewhr fr die Authentizitt und
Vertraulichkeit von Nachrichten bietet.
Bei unverschlsselten E-Mails knnen alle Informationen auf jedem IT-
System gelesen werden, auf dem die Nachricht auf ihrem Weg durchs Netz
bearbeitet wird. Da der genaue Transportweg im Allgemeinen nicht
vorhersagbar ist und das zugrunde liegende Protokoll SMTP (Simple Mail
Transfer Protocol) keine Mechanismen anbietet, einen bestimmten Weg vor-
zugeben, kann eine E-Mail sehr viele verschiedene Systeme passieren.
Informationen, die nicht durch digitale Signaturen geschtzt sind, knnen
auch auf jedem beteiligten System verndert oder gelscht werden, ohne dass
dies vom Empfnger bemerkt werden kann. Abgesehen von Vernderungen
am Text oder an etwaigen Dateianhngen einer E-Mail knnen auch Informa-
tionen wie Absende- und Weiterleitungsdaten oder die Absenderadresse
selbst verndert werden, siehe auch G 5.73 Vortuschen eines falschen
Absenders.
Daher ist es falsch, E-Mails mit klassischen Briefen zu vergleichen. Ein
Vergleich mit Postkarten wre zutreffender.
Beispiele:
- Ein Angestellter verschickte mit der Absenderangabe seines Chefs E-Mails
mit Arbeitsauftrgen an verschiedene Kollegen.
- Praktisch alle der vielen Spam-E-Mails, die tglich die E-Mail-Postfcher
fllen tragen eine geflschte Absenderadresse.
- Als Absendedatum einer E-Mail wird meist die lokale Systemzeit auf dem
Rechner des Absenders eingetragen. Da diese oft selbst von normalen
Anwendern verstellt werden kann, stellt ein bestimmtes Absendedatum in
einer E-Mail keinen Beweis dafr dar, dass diese wirklich zu einem
bestimmten Zeitpunkt verschickt wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.38 Ausfall von Komponenten eines Netz- und

Systemmanagementsystems
Bei einem Netz- und Systemmanagementsystem kann es zu einem Ausfall
verschiedener Komponenten kommen. Einige der dadurch entstehenden
Probleme und Gefhrdungen sind im folgenden beschrieben.
Ausfall von verwalteten Komponenten
Fallen beim Einsatz eines Netz- und Systemmanagementsystems damit ver-
waltete Komponenten aus, so kann es je nach Managementsystem vorkom-
men, dass die Managementinformationen nicht automatisch aufgrund dieses
Ereignisses aktualisiert werden. In der Regel wird dem Systemadministrator
z. B. bei Netzmanagement-Systemen nur das Ausfallen der Komponente ange-
zeigt. Wird z. B. der Ausfall der Komponente von einem Angreifer beobachtet
oder bewusst herbeigefhrt, so kann dieser u. U. auerhalb des LANs einen
eigenen Rechner in das System einbringen und als die ausgefallene Kompo-
nente ausgeben (IP-Spoofing). Dieser Rechner kann dann zu weiteren Angrif-
fen genutzt werden, bei denen er dann mit den Rechten eines internen Rech-
ners ausgestattet ist (z. B. Einbringen falscher Managementinformationen).
Ausfall von berwachungskomponenten
Fallen beim Einsatz eines Managementsystems Teile des Systems (auch
unbemerkt) aus, so sind die durch die Komponente berwachten oder verwal-
teten Systemkomponenten nicht mehr an das Managementsystem ange-
schlossen. Neue eingehende Managementanweisungen werden dadurch nicht
mehr auf diesen Rechnern umgesetzt. Dies hat zur Folge, dass inkonsistente
Systemkonfigurationen entstehen, die wiederum zu Sicherheitsproblemen
fhren knnen.
Nicht-Verfgbarkeit der zentralen Managementstation
Fllt in einem durch ein Managementsystem verwalteten Netz die zentrale
Managementstation aus, so kann das System nicht mehr zentral verwaltet
werden. Dauert die Nicht-Verfgbarkeit lnger an, weil z. B. die Hardware
aufgrund fehlender Wartungsvertrge nicht kurzfristig ersetzt werden kann, so
werden unter Umstnden Routinefunktionen wie etwa Datensicherungen nicht
mehr angestoen. Werden nun "von Hand" nderungen an den einzelnen
verwalteten Systemen unkoordiniert durchgefhrt, so entstehen Inkon-
sistenzen und mglicherweise Sicherheitsprobleme.
Ausfall von Netzkoppelelementen whrend der bertragung von
Managementinformationen
Beim Einsatz eines Managementsystems zur Verwaltung eines Rechnernetzes
ist der Austausch von so genannter Managementinformation zwischen den
einzelnen Komponenten des Managementsystems ntig. Die Information wird
ber das lokale Netz bertragen. Lokale Netze bestehen in der Regel (je nach
verwendeter Netztechnik) aus mehreren Teilnetzen, die ber Netzkoppel-
elemente wie Router miteinander verbunden sind. Die Netzkoppelelemente
reichen dabei Daten aus einem Teilnetz in ein anderes Teilnetz weiter. Fallen
die Koppelelemente aus, so ist dies gleichbedeutend mit der physikalischen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Trennung der betroffenen Teilnetze. Managementinformationen knnen dann

nicht mehr ausgetauscht werden. Dabei existiert in der Regel ein Teilnetz, das
noch von der jeweiligen Managementstation verwaltet werden kann, und ein
Teilnetz, das nicht mehr verwaltet werden kann. Je nach Dauer der Nicht-
erreichbarkeit fhrt dies zu Inkonsistenzen und Sicherheitsproblemen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.39 Software-Konzeptionsfehler
Bei der Planung von Programmen und Protokollen knnen
sicherheitsrelevante Konzeptionsfehler entstehen. Hufig sind diese Fehler
historisch gesehen durchaus verstndlich. So ist sicherlich keiner der
Entwickler der im Internet verwendeten Protokolle Ende der 60er-Jahre davon
ausgegangen, dass diese Protokolle einmal die Grundlage fr ein
weltumspannendes und kommerziell hchst bedeutendes Computer-Netz
werden wrden.
Beispiele fr Konzeptionsfehler sind die offene bertragung der Daten im
Internet, so dass Daten (z. B. Passwrter) mitgelesen oder verndert werden
knnen, oder die Mglichkeit, Pakete mit Internet-Adressen zu versenden, die
einem anderen Rechner zugeteilt worden sind. Ein Spezialfall hiervon ist die
so genannte FTP-Bounce-Attacke, bei der ausgenutzt wird, dass die
Verbindung, die beim FTP-Protokoll fr die Datenbertragung eingesetzt
wird, zu einem beliebigen Rechner aufgebaut werden kann. Im ungnstigen
Fall knnen auf diese Weise sogar Firewalls mit dynamischen Paketfiltern
berwunden werden (siehe CERT Advisory 97-27). Weitere Fehler in den
Internet-Protokollen sind sicherlich vorhanden und werden zuknftig
publiziert werden.
Ein weiteres Beispiel fr einen Konzeptionsfehler ist das so genannte DNS-
Spoofing (siehe auch G 5.78 DNS-Spoofing). Das Domain Name System ist
der zentrale Auskunftsdienst im Internet, der die bersetzung der leicht
merkbaren Rechnernamen wie www.preiswert.de in die zugehrige Internet-
Adresse ermglicht. Bei DNS-Spoofing versucht ein Angreifer, einem
Rechnernamen einen falschen Rechner zuzuweisen, so dass Auskunftsuchende
fehlgeleitet werden.
Eine weiteres Beispiel fr einen Konzeptionsfehler ist die Mglichkeit,
anonym sehr viele Werbe-E-Mails zu versenden (Mail-Spamming). Hierbei
werden hufig fremde Mailserver als so genannte Remailer eingesetzt, so dass
Gegenaktionen durch den Empfnger ins Leere laufen. Die Ursache fr diese
Angriffe liegt eindeutig in den mangelhaften Authentisierungsmglichkeiten,
die das Internet zur Zeit bietet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.40 Ungeeignete Ausrstung der

Betriebsumgebung des RAS-Clients
Die Aufnahme von RAS-Verbindungen wird hufig durch die Inkompatibilitt
der technischen Ausstattung verhindert. Aber auch bei kompatibler Technik
kann die Verbindungsaufnahme scheitern, wenn Einwahlpunkte der entspre-
chenden Dienstleister fehlen oder nicht erreichbar sind. Die Gefhrdungen aus
diesem Bereich sind u. A.:
- Die Stromparameter zwischen RAS-Client und entferntem Standort sind
inkompatibel (220V/110V).
- Die Modemanschlsse zwischen RAS-Client und entferntem Standort sind
inkompatibel.
- Das blicherweise genutzte Vermittlungsnetz (Telekommunikationsdienst-
leister, Internetdienstleister) ist am entfernten Standort nicht verfgbar.
- Die bertragung der entfernten Telefonnummer zum RAS-Server ist
fehlerhaft oder inkompatibel (bei Authentisierung mittels CLIP - Calling
Line Identification Protocol).
Alle mglichen technischen Probleme fr beliebige Betriebsumgebungen bei
der Planung des RAS-Systems zu bercksichtigen, ist zudem kaum mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.41 Nicht-Verfgbarkeit des Mobilfunknetzes

Die Verfgbarkeit von Mobilfunknetzen ist deutlich geringer als die von
Festnetzen. Wie alle Systeme, die keine hundertprozentige Verfgbarkeit
gewhrleisten, stehen auch Mobilfunknetze hufig nicht an den Orten und
Zeiten zur Verfgung, zu denen sie am dringendsten bentigt werden. Es sind
auch nicht alle Mobilfunknetze darauf ausgelegt, flchendeckende
Anbindungen zu gewhrleisten.
Die hufigste Ursache fr eine fehlende Mobilfunkversorgung sind sicherlich
Funklcher, also Bereiche, die von keinem Netzbetreiber versorgt werden. Bei
einer sehr groen Nachfrage kann es aber auch zu einer berlastung von
Teilen des Netzes kommen. Dies kann dazu fhren, dass das Empfangen oder
Senden von Nachrichten verhindert wird.
Weiterhin kann es Strsender geben, die in einem rumlich abgegrenzten
Bereich den Funkbetrieb derart stren, dass dort kein Mobilfunkempfang
mglich ist. Es gibt auch Gerte, die genau fr diesen Zweck verkauft werden.
Allerdings ist der Betrieb solcher Gerte in Deutschland nicht zulssig.
Beispiel:
Die Funkkapazitt einer Sendestation reicht nicht, wenn nach einem groen
Unfall sehr viele Personen gleichzeitig ein Mobiltelefonat fhren wollen, um
Rettungsdienste zu benachrichtigen oder ihre Angehrigen zu informieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.42 Ausfall des Mobiltelefons oder des PDAs

Die Benutzung eines Mobiltelefons oder eines PDAs kann durch verschiedene
Faktoren negativ beeintrchtigt werden:
- Der Akku kann leer sein, weil vergessen wurde, ihn aufzuladen.
- Der Akku kann seine Fhigkeit, Energie zu speichern, verloren haben.
- Der Benutzer kann das Zugangspasswort bzw. die PIN vergessen haben
und kann deswegen das Gert nicht mehr benutzen.
- Komponenten wie Display, Tasten oder SIM-Karte knnen defekt sein.
Wenn ein Mobiltelefon oder PDA schdigenden Umwelteinflssen ausgesetzt
wird, kann seine Funktionsfhigkeit beeintrchtigt werden. Mobiltelefone und
PDAs knnen sowohl unter zu hohen als auch zu niedrigen Temperaturen
leiden, ebenso unter Staub oder Feuchtigkeit.
Beispiele:
- Fr eine lngere Dienstreise hat ein Mitarbeiter ein Mobiltelefon samt
Zubehr aus einem Mobiltelefon-Pool mitgenommen. Unterwegs stellte
sich dann heraus, dass er leider das falsche Ladegert eingesteckt hatte. Da
er damit das Mobiltelefon nicht wieder aufladen konnte, konnte er es die
restliche Zeit nicht mehr benutzen.
- Das Mobiltelefon oder der PDA werden in einem geparkten Auto
zurckgelassen. Dies erhht nicht nur die Diebstahlgefahr, sondern es wird
auch eventuell schdigenden Umwelteinflssen ausgesetzt. Durch direkte
Sonneneinstrahlung knnen im Sommer hinter einer Glasscheibe Tempe-
raturen von ber 60C entstehen. Ein analoges Problem besteht im Winter,
wo im geparkten Auto Temperaturen deutlich unter dem Gefrierpunkt herr-
schen knnen. Durch solche extremen Temperaturen kann der Akku oder
auch das Display beschdigt werden.
- Auf einer Dienstreise ist dem PDA zwischendurch der Strom ausgegangen,
weil die Ersatzbatterien zu spt eingesetzt wurden. Nach dem Wiederein-
schalten sind allerdings viele Konfigurationseinstellungen verloren gegan-
gen, da diese vom Betriebssystem nicht automatisch gesichert wurden.
Dadurch laufen anschlieend einige Anwendungen wie E-Mail und Inter-
netzugriff nicht mehr korrekt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.43 Undokumentierte Funktionen

Viele Anwendungsprogramme enthalten undokumentierte Funktionen, also
Funktionen, die nicht in der Dokumentation beschrieben sind und die den
Benutzern nicht bekannt sind. Bei einigen Betriebssystemen bzw.
Anwendungsprogrammen gibt es mittlerweile Bcher, die einen Groteil der
bekannt gewordenen, bis dato undokumentierten Funktionen beschreiben und
die im Allgemeinen dicker sind als die mitgelieferten Handbcher.
Undokumentierte Funktionen mssen sich allerdings nicht nur auf Hilfsmittel
mit ntzlichen Effekten beschrnken. Solange diese Funktionen nicht offen
gelegt sind, kann nicht ausgeschlossen werden, dass mit ihnen auch viel
Schaden angerichtet werden kann.
Dies ist insbesondere dann problematisch, wenn die undokumentierten
Funktionen Sicherheitsmechanismen des Produktes betreffen, beispielsweise
den Zugriffsschutz. Solche Funktionen dienen oft als "Hintertren" whrend
der Entwicklung oder der Verteilung von Anwendungsprogrammen.
Beispiele:
- Bei verschiedenen IT-Systemen fanden sich von den Entwicklern
eingebaute (und vergessene) Hintertren, um die Wartung zu erleichtern,
die es allerdings auch ermglichten, mit einem trivialen Passwort
Administratorrechte zu erlangen.
- Viele Programme knnen (oder mssen sogar) online beim Hersteller
registriert werden. Bei einigen dieser Programme wurden bei der Online-
Registrierung der Software gleichzeitig ein berblick ber alle auf der
Festplatte gespeicherten Programme mitgeliefert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.44 Ausfall von Novell eDirectory

Durch technisches Versagen aufgrund von Hardware- oder Software-Proble-
men kann es zum Ausfall eines eDirectory-Systems oder Teilen davon
kommen. Als Konsequenz davon knnen die im Verzeichnis gehaltenen Daten
temporr nicht mehr zugnglich sein, und zwar weder fr eDirectory-Benutzer
noch fr etwaige Netzapplikationen, die auf das eDirectory zugreifen. Im
Extremfall kann es auch zu Datenverlusten kommen.
Dadurch knnen Geschftsprozesse gestrt und der interne Workflow behin-
dert werden, durch die vielfltigen Funktionen von eDirectory und die starke
Einbindung in die Organisation kann es damit auch zu Produktivittsausfllen
kommen.
Sind Repliken der ausgefallenen Systemteile funktionsfhig vorhanden, so ist
der Zugriff zwar weiterhin mglich, jedoch unter Umstnden - abhngig von
der Netztopologie - mit reduzierter Performance.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.45 Verzgerte Archivauskunft

Verzgerungen bei der Wiederbeschaffung archivierter Dokumente knnen
Geschftsprozesse, in deren Kontext eine Archivanfrage erfolgt, stren oder
behindern. Fr derartige Verzgerungen kommen viele Ursachen in Betracht,
beispielsweise:
- veraltete Archivserver-Software,
- ungnstige Wahl von Index- und Suchkriterien bei Ablage oder Suche von
archivierten Daten,
- berlastete Hardware des Archivservers oder beteiligter Datenbankserver,
- Verzgerungen im Netz sowie
- unausgewogenes Verhltnis von Speichermedien zu Laufwerken.
Bei dem letztgenannten Punkt sind zwei Flle zu unterscheiden:
- Wird fr die Archivierung ein Laufwerk mit einem einzelnen Speicherme- ein groes Medium
dium genutzt, das eine sehr groe Kapazitt hat, knnen die Antwortzeiten
sehr gro werden, da nur jeweils ein Benutzer gleichzeitig auf das Archiv
zugreifen kann. Alle anderen Anfragen werden zwischengespeichert und
dann der Reihe nach abgearbeitet.
- Bei einer groen Anzahl kleiner Speichermedien sind im Verhltnis dazu viele kleine Medien
nur wenige Laufwerke verfgbar. Daher mssen die Datentrger bei An-
fragen entsprechend oft gewechselt werden, was zu lngeren Antwortzeiten
fhrt. Kleine Speichermedien sind darber hinaus schneller in ihrem
Speicherplatz erschpft (siehe G 4.20 Datenverlust bei erschpftem Spei-
chermedium).
Verzgerungen knnen sich auch bei der Einstellung von Dokumenten ins
Archiv ergeben, etwa wenn die Besttigung des Archivierungsvorgangs durch
lange bertragungszeiten im LAN verzgert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.46 Fehlerhafte Synchronisierung von Indexdaten

Bei der Archivierung werden sehr groe Datenvolumen gespeichert. Auf alle Index des
archivierten Daten muss zu einem spteren Zeitpunkt in annehmbarer Zeit Archivsystems ...
jederzeit kontrolliert und eindeutig zugegriffen werden knnen. Diese
Funktionalitt wird durch das Archivsystem gewhrleistet, das hierzu einen
Index der gespeicherten Dateien erzeugt.
Archivsysteme realisieren jedoch meist nur einfache Dateizugriffe. Um mehr
Komfort beim Zugriff zu erreichen, wird daher sehr oft ein bergeordnetes
Dokumentenmanagementsystem (DMS) eingesetzt, ber das der Zugriff auf
das Archiv gesteuert und weitergehende Funktionalitten, z. B. komplexe
Suchanfragen, realisiert werden.
Das DMS erzeugt bei der Archivierung die Referenzierung der Daten, ... und des Dokumenten-
managementsystems
kontrolliert deren Version und legt gegebenenfalls einen Volltextindex an, so
dass alle auf dem Speichermedium archivierten Daten zu einem spteren
Zeitpunkt eindeutig identifiziert werden knnen.
Letztlich gibt es daher zwei Indexdatenbanken (im Archivsystem und im
DMS), die beide synchronisiert werden mssen. Kommt es einseitig zu
Vernderungen in den im DMS gespeicherten Indexdaten oder zu Fehlern auf
dem Speichermedium, ohne dass die Vernderungen im anderen Teil
bercksichtigt werden, knnen archivierte Daten nicht mehr den Referenzen
im DMS zugeordnet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.47 Veralten von Kryptoverfahren

Die Zuverlssigkeit von Kryptosystemen ist direkt mit der fortschreitenden
Entwicklung der Rechenleistung von IT-Systemen, der Entwicklung neuerer
Algorithmen sowie der Forschung auf dem Gebiet der Kryptoanalyse
verknpft. Durch die Steigerung der Leistungsfhigkeit von IT-Systemen
knnen als sicher geltende Kryptoalgorithmen bzw. Schlssellngen zuknftig
mglicherweise kompromittiert werden.
Hierdurch besteht die Gefahr, dass im Falle der Kompromittierung von
Kryptoverfahren oder Kryptoschlsseln
- verschlsselte Daten unbefugt entschlsselt werden knnen,
- von Unbefugten Dokumente mit einer technisch gltigen Signatur versehen
werden knnen, so dass dann
- authentische, signierte Dokumente nicht mehr von geflschten
unterschieden werden knnen.
Beispiel:
Krankenhuser mssen die Akten ihrer Patienten auch nach Abschluss der DES mit 40 Bit langen
Schlsseln
Behandlung fr einen langen Zeitraum sicher aufbewahren. Ein deutsches
Krankenhaus hat dementsprechend 1980 angefangen, die elektronisch
gespeicherten Krankendaten zu verschlsseln. Das dazu verwendete Verfahren
basierte auf DES mit 40 Bit langen Schlsseln. Da sich im Krankenhaus
niemand mit Verschlsselung auskannte, wurde dieses Verfahren auch im
Jahr 2001 noch eingesetzt, obwohl mittlerweile bereits im Internet Programme
verfgbar waren, um die damit verschlsselten Daten auszulesen. Dies fiel erst
bei einer Datenschutzkontrolle auf.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.48 Ausfall der Systeme eines Outsourcing-

Dienstleisters
Bei einem Outsourcing-Dienstleisters knnen die IT-Systeme teilweise oder
ganz ausfallen, wodurch auch der Auftraggeber betroffen ist.
Auch wenn der IT-Ausfall nur einige Systeme oder Applikationen betrifft,
kann dies dazu fhren, dass die Datenverarbeitung inkonsistent oder fehlerhaft
ausgefhrt wird.
Auerdem ist zu bercksichtigen, dass bei unzureichender Strukturierung oder fehlende Mandantenf-
higkeit
Isolation der IT-Systeme des Dienstleisters bereits der Ausfall eines Systems,
das nicht dem Auftraggeber zugeordnet ist, trotzdem dazu fhren kann, dass
der IT-Betrieb des Auftraggebers beeintrchtigt wird. Dies kann immer dann
ein Problem sein, wenn einzelne IT-Komponenten (z. B. Host-Rechner, Fire-
walls) fr verschiedene Auftraggeber des Dienstleisters gemeinsam genutzt
werden. Dann kann unter Umstnden ein Fehler im Datenbestand eines belie-
bigen Kunden des Outsourcing-Dienstleisters dazu fhren, dass beispielsweise
bei der Host-Verarbeitung die Batch-Verarbeitung mehrerer Kunden einge-
stellt werden muss, wenn diese schlecht oder fehlerhaft konfiguriert ist.
hnliche Probleme ergeben sich, wenn die Anbindung zwischen auslagernder
Organisation und Outsourcing-Dienstleister ausfllt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.49 Unsichere Default-Einstellungen auf Routern

und Switches
Aktive Netzkomponenten werden von Herstellern oft mit unsicheren Default-
Konfigurationen ausgeliefert, die den sicheren Einsatz gefhrden. Bei einigen
Gerten zeigen auerdem die Systembefehle zur Anzeige einer Konfiguration
nicht alle Parameter an.
Folgende Aspekte sind hufig problematisch:
Betriebssystem
Aktive Netzkomponenten werden oft mit einem veralteten Versionsstand des
Betriebssystems ausgeliefert.
Hostname
Werkmig eingestellte Hostnamen verraten oft den Hersteller der Gerte.
Dienste
Werkseitig werden Gerte mit Standardkonfigurationen ausgeliefert, auf
denen eine Vielzahl von Diensten aktiviert sind. Beispielsweise knnen dies
HTTP, Telnet, FINGER oder sonstige Dienste sein.
Benutzerkonten und Passworte
Werksmig eingerichtete Benutzerkonten haben dokumentierte und damit
allgemein bekannte Standardnamen und -Passworte. Auf einschlgigen
Internet-Seiten stehen Listen mit herstellerspezifischen Standard-Accounts
und Passworten zum Download bereit.
Unsichere SNMP-Versionen
Die Authentisierung erfolgt bei SNMPv1 und SNMPv2 lediglich mittels eines
unverschlsselten sogenannten Community Strings. Als Standardeinstellung
bei nahezu allen Herstellern ist der Read-Community-String auf den Wert
"public" eingestellt, whrend der Write-Community-String auf den Wert
"private" gesetzt ist. Wenn die unsicheren SNMP-Versionen genutzt werden
und fr die Administration kein eigenes Administrationsnetz eingerichtet
wurde, kann ein Angreifer leicht die Kontrolle ber Netzkomponenten
erlangen, wenn diese Default-Einstellungen beibehalten werden.
Routing-Protokolle
Auf Routern und Switches verschiedener Hersteller sind standardmig
Routing-Protokolle aktiviert.
Login-Banner
Werksmig verraten Login-Banner unterschiedlicher Gerte beispielsweise
die Modell- und Versionsnummer des Gertes. Diese Angaben knnen fr die
gezielte Auswahl bekannter Exploits verwendet werden und erleichtern
Angreifern so die Durchfhrung von Angriffen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.50 berlastung des z/OS-Betriebssystems

Auch wenn durch den Workload Manager ein z/OS-Betriebssystem so
verwaltet wird, dass eine berlastung eigentlich nicht vorkommen sollte, gibt
es eine Reihe von Gefhrdungen, die zu einer berlastung fhren knnen.
Eine berlastung muss nicht zwangslufig zu einem kompletten System-
Stillstand fhren. Es knnen auch nur verschiedene System-Ressourcen nicht
mehr verfgbar sein, obwohl das System selbst noch reagiert. Die
nachfolgenden Situationen sind typisch, aber nicht die einzigen Gefhrdungen
dieser Art.
Spool-Full-Situation
Die Spool-Datei eines Job Entry Subsystem (JESx) ist nur fr eine bestimmte
Menge von Ausgabedaten vorgesehen. Es kann vorkommen, dass z. B. durch
eine Programmschleife unbegrenzt Daten auf die Spool-Datei des JESx
geschrieben werden. Dies kann zu einer Spool-Full-Situation fhren, neue
Batch-Jobs knnen nicht mehr gestartet werden. Nur die laufenden Online-
Verfahren sind u. U. noch aktiv, sofern keine Ausgabedateien auf die Spool-
Datei geschrieben werden. Da viele JES-Kommandos bei der Ausfhrung eine
benutzbare Spool-Datei voraussetzen, kann dies bedeuten, dass umfangreiche
(und zeitintensive) Recovery-Manahmen notwendig sind, um dieses Problem
zu bereinigen.
Vollstndiger System-Stillstand
Unix-Prozesse im USS-Subsystem (Unix System Services) werden in z/OS auf
Adressrume abgebildet. Steht nicht mehr gengend Hauptspeicher zur
Verfgung, mssen diese Adressrume ber den Auxiliary Storage Manager
(ASM) auf die Page-Platten ausgelagert werden. Reichen auch diese nicht aus,
kann kein Adressraum mehr angelegt werden.
Wenn die Anzahl der Unix-Prozesse im USS nicht beschrnkt ist und nicht
gengend Platz auf den Page-Platten zur Verfgung steht, knnen sich deshalb
Sicherheitsprobleme durch den Start von zu vielen Unix-Prozessen ergeben.
Ursache kann beispielsweise eine rekursive Funktion sein, die unentwegt neue
Unix-Prozesse startet. Als Folge kann es passieren, dass das System praktisch
stillsteht.
Von diesem Problem ist z/OS (mit 64 Bit-Adressierung) im Vergleich zu
seinem Vorgnger OS/390 (mit 31 Bit-Adressierung) durch die hhere
Adressierbarkeit deutlich weniger betroffen. Durch die hhere
Adressierbarkeit kann dem z/OS-System ein grerer Hauptspeicher zur
Verfgung gestellt werden. Dies hat zur Folge, dass die Page-Platten erst viel
spter bentigt werden.
Generell knnen Kommandos oder Programmteile, die stndig neue Prozesse
starten, sehr schnell das System berlasten. Dies kann letztendlich einen IPL
(Initial Program Load) erforderlich machen.
Systemberlastung durch zu viele JESx Initiators
ber die Anzahl der gestarteten Initiators steuert der Administrator die Batch-
Verarbeitung und deren Prioritten. Sind zu wenig Initiators gestartet, knnen
Staus bei der Batch-Verarbeitung entstehen. Sind zu viele Initiators gestartet,
kann dies zur berlastung von Ressourcen fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Werden zu viele Batch-Jobs gestartet, so besteht die Gefahr, dass die

Page Datasets nicht ausreichen. Dies erfordert ein manuelles Eingreifen in die
Systemsteuerung durch das Bedienpersonal.
Ist das Job Entry Subsystem mit einer sehr groen Anzahl von Initiators
definiert worden, die jedoch nicht sofort aktiviert werden, kann es
vorkommen, dass bei der Eingabe des JES2-Kommandos $SI (statt z. B. $SI1-
10) alle mglichen Initiators gestartet werden. Dadurch laufen unter
Umstnden mehr Batch-Jobs an als geplant. Dies fhrt zwar in der Regel nicht
zu einem System-Stillstand, die Antwortzeiten knnen sich jedoch erheblich
verlngern.
Verzgerte Bandverarbeitung
Wenn gleichzeitig mehr Bandeinheiten angefordert werden, als Stationen
vorhanden sind, verzgert sich die Sicherung der Daten auf Bnder. Die
Sicherungs-Jobs gehen in den Wait-Status und warten auf freie Bandstationen.
Beispiele
- In einer z/OS-Installation wurden zu viele Initiators gestartet. Dies hatte Zu viele Batch-Jobs
zur Folge, dass whrend der Batch-Verarbeitung zu viele Batch-Jobs
gleichzeitig aktiviert wurden, wodurch die CPU des Systems stark belastet
wurde. Obwohl das System die Last bewltigt hat, fhrte die Situation zu
langen Antwortzeiten bei der Time Sharing Option (TSO).
- Bei der USS-Basisdefinition eines z/OS-Betriebssystems wurden die Werte Zu groe USS-
Basisdefinitionen
von MAXPROCSYS und MAXFILEPROC auf sehr hohe Werte gesetzt. Als
ein Mitarbeiter einen rekursiven Funktionsaufruf, den er auf einer Unix-
Schulung kennen gelernt hatte, unter Unix System Services ausprobierte,
blieb das System nach kurzer Zeit wegen Auxiliary Storage Shortage
stehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.51 Unzureichende Sicherheitsmechanismen bei

PDAs
Ein IT-System, das sich im mobilen Einsatz befindet, kann ber ein VPN an
ein LAN angeschlossen sein, so dass die Kommunikationsverbindung sehr gut
geschtzt ist. Wenn allerdings dieses IT-System selber ungengend gegen
unbefugten Zugriff geschtzt ist, besteht die Gefahr, dass ein Unbefugter
dieses als "Gateway" missbraucht, um auf das interne Netz zuzugreifen.
Typische Endgerte fr den mobilen Einsatz sind Handys oder PDAs, bei
denen meistens keine Benutzertrennung mglich ist. Dadurch kann jeder, der
Zugriff auf das IT-System hat, auf alle Daten und Programme zugreifen, auch
auf interne Daten der Organisation oder sehr persnliche Daten des
Eigentmers.
Andere leider sehr typische Schwachstellen bei mobilen Komponenten wie
PDAs sind:
- unzureichende Zugriffschutz- und Authentisierungsmechanismen
- keine oder unzureichende Mglichkeiten zur Verschlsselung von Daten
- ungesicherte Synchronisation
- keine oder unzureichende Protokollierungsmglichkeiten
Es gibt eine Vielzahl verschiedener PDA-Modelle mit den unterschiedlichsten
Betriebssystemen. Die Sicherheitseigenschaften der verschiedenen PDA-
Plattformen sind unterschiedlich, einen sicheren Schutz gegen Manipulationen
bietet aber derzeit keines der kommerziell gebruchlichen Systeme.
Beispiel:
Bei Palm OS 3.5.2 und allen Vorgngerversionen kann ber eine Tasten-
kombination wahlweise in den sogenannten "Console Mode" oder den "Debug
Mode" gewechselt werden. Beide Modi erlauben, an allen
Sicherheitsmechanismen des Betriebssystems vorbei, den direkten Zugriff auf
Systemdaten. Dabei ist es vllig gleichgltig, ob der PDA-Zugriff ber ein
Passwort geschtzt ist oder nicht: beide Modi knnen unter Umgehung des
Zugriffsschutzes aktiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 4.52 Datenverlust bei mobilem Einsatz

Ein mobiles Endgert ist im Vergleich mit einem stationren wesentlich mehr
Risiken ausgesetzt, die zu einem Datenverlust fhren knnen. Ein Datenver-
lust kann aus Diebstahl oder Gerteverlust resultieren, aber auch durch
technische Probleme oder schlichten Strommangel entstehen.
Beispiele:
- Der nagelneue PDA fllt aus der Hemdtasche und zerschellt auf den
Fliesen, ein Handheld wird statt der Zeitung vom Hund apportiert, leider
mit Folgen. Vor allem Transportschden fhren hufig zu Datenverlusten
und Gerte- oder Komponentenausfllen. Staub, Verschmutzung, Feuch-
tigkeit und Strze, kurz "unsachgeme Behandlung", sind die Ursachen
von vielen Totalverlusten mobiler Endgerte.
- Die Daten knnen temporr nicht verfgbar sein, weil der Akku leer ist, da
vergessen wurde, ihn aufzuladen. Sie knnen aber auch vollstndig ver-
nichtet sein, wenn neben dem Akku auch die Sicherungsbatterie leer ist
und damit alle nicht bereits synchronisierten Daten verloren sind.
- Auch bei der Synchronisation knnen Daten zerstrt werden. Im allge-
meinen muss vor einer Synchronisation eingestellt werden, wie mit
Konflikten beim Datenabgleich umzugehen ist: ob beispielsweise bei
gleichlautenden Dateien die des mobilen oder des stationren Endgert
ungefragt bernommen werden oder ob eine Abfrage erfolgt. Dies wird
hufig bei Inbetriebnahme der Dockingstation einmal konfiguriert und
gert danach gerne in Vergessenheit. Wenn dann aber Daten in einer
anderen Reihenfolge gendert werden, als ursprnglich einmal gedacht,
gehen dabei schnell wichtige Daten verloren. Dies kann auch ein unange-
nehmer Nebeneffekt sein, wenn beispielsweise mehrere Benutzer ihre
PDAs mit demselben Endgert synchronisieren, ohne daran zu denken,
dass gleichnamige Dateien dabei berschrieben werden knnen.
Mobile Systeme sind naturgem nicht immer online. Daher befinden sich die Fehlende Aktualitt
auf diesen gespeicherten Daten nicht immer auf dem aktuellsten Stand. Dies
betrifft sowohl Kalendereintrge als auch allgemeine Informationen, kann aber
unter Umstnden auch sicherheitsrelevante Auswirkungen haben. Whrend
der Zeit, in der keine Verbindung zu den organisationseigenen IT-Systemen
und Informationsquellen besteht, knnen auch keine Informationen ber aktu-
elle Sicherheitsprobleme eingeholt werden, der Virenscanner nicht aktualisiert
werden etc.
___________________________________________________________________ ..........................................
Gefhrdungskatalog Vorstzliche Handlungen G5 Bemerkungen
___________________________________________________________________ ..........................................
G5 Gefhrdungskatalog Vorstzliche Handlungen

G 5.1 Manipulation/Zerstrung von IT-Gerten oder Zubehr ........... 1
G 5.2 Manipulation an Daten oder Software ....................................... 2
G 5.3 Unbefugtes Eindringen in ein Gebude ..................................... 3
G 5.4 Diebstahl .................................................................................... 4
G 5.5 Vandalismus .............................................................................. 5
G 5.6 Anschlag .................................................................................... 6
G 5.7 Abhren von Leitungen ............................................................. 7
G 5.8 Manipulation an Leitungen........................................................ 8
G 5.9 Unberechtigte IT-Nutzung......................................................... 9
G 5.10 Missbrauch von Fernwartungszugngen.................................. 10
G 5.11 Vertraulichkeitsverlust in TK-Anlagen gespeicherter
Daten........................................................................................ 11
G 5.12 Abhren von Telefongesprchen und
Datenbertragungen................................................................. 12
G 5.13 Abhren von Rumen .............................................................. 13
G 5.14 Gebhrenbetrug ....................................................................... 14
G 5.15 "Neugierige" Mitarbeiter ......................................................... 15
G 5.16 Gefhrdung bei Wartungs-/Administrierungsarbeiten
urch internes Personal.............................................................. 16
G 5.17 Gefhrdung bei Wartungsarbeiten durch externes
Personal.................................................................................... 17
G 5.18 Systematisches Ausprobieren von Passwrtern....................... 18
G 5.19 Missbrauch von Benutzerrechten............................................. 19
G 5.20 Missbrauch von Administratorrechten..................................... 20
G 5.21 Trojanische Pferde ................................................................... 21
G 5.22 Diebstahl bei mobiler Nutzung des IT-Systems ...................... 22
G 5.23 Computer-Viren....................................................................... 23
G 5.24 Wiedereinspielen von Nachrichten.......................................... 26
G 5.25 Maskerade................................................................................ 27
G 5.26 Analyse des Nachrichtenflusses............................................... 28
G 5.27 Nichtanerkennung einer Nachricht .......................................... 29
G 5.28 Verhinderung von Diensten ..................................................... 30
G 5.29 Unberechtigtes Kopieren der Datentrger ............................... 31
G 5.30 Unbefugte Nutzung eines Faxgertes ...................................... 32
G 5.31 Unbefugtes Lesen eingegangener Faxsendungen .................... 33
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.32 Auswertung von Restinformationen in Faxgerten ................. 34

G 5.33 Vortuschen eines falschen Absenders bei Faxgerten ........... 35
G 5.34 Absichtliches Umprogrammieren der Zieltasten eines
Faxgertes ................................................................................ 36
G 5.35 berlastung durch eingehende Faxsendungen......................... 37
G 5.36 Absichtliche berlastung des Anrufbeantworters ................... 38
G 5.37 Ermitteln des Sicherungscodes ................................................ 39
G 5.38 Missbrauch der Fernabfrage .................................................... 40
G 5.39 Eindringen in Rechnersysteme ber
Kommunikationskarten............................................................ 42
G 5.40 Abhren von Rumen mittels Rechner mit Mikrofon ............. 43
G 5.41 Mibruchliche Nutzung eines Unix-Systems mit Hilfe
von uucp................................................................................... 44
G 5.42 Social Engineering................................................................... 45
G 5.43 Makro-Viren ............................................................................ 46
G 5.44 Missbrauch von Remote-Zugngen fr
Managementfunktionen von TK-Anlagen ............................... 47
G 5.45 Ausprobieren von Passwrtern unter WfW und
Windows 95 ............................................................................. 48
G 5.46 Maskerade unter WfW............................................................. 49
G 5.47 Lschen des Post-Office .......................................................... 50
G 5.48 IP-Spoofing.............................................................................. 51
G 5.50 Missbrauch des ICMP-Protokolls............................................ 53
G 5.51 Missbrauch der Routing-Protokolle......................................... 54
G 5.52 Missbrauch von Administratorrechten im Windows NT
System...................................................................................... 55
G 5.53 Bewusste Fehlbedienung von Schutzschrnken aus
Bequemlichkeit ........................................................................ 56
G 5.54 Vorstzliches Herbeifhren eines Abnormal End.................... 57
G 5.55 Login Bypass ........................................................................... 58
G 5.56 Temporr frei zugngliche Accounts....................................... 59
G 5.57 Netzanalyse-Tools ................................................................... 60
G 5.58 "Hacking Novell Netware" ...................................................... 61
G 5.59 Missbrauch von Administratorrechten unter Novell
Netware 3.x.............................................................................. 62
G 5.60 Umgehen der Systemrichtlinien............................................... 63
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Managementfunktionen von Routern ...................................... 64
G 5.62 Missbrauch von Ressourcen ber abgesetzte IT-
Systeme.................................................................................... 65
G 5.63 Manipulationen ber den ISDN-D-Kanal................................ 66
G 5.64 Manipulation an Daten oder Software bei
Datenbanksystemen ................................................................. 67
G 5.65 Verhinderung der Dienste eines Datenbanksystems................ 68
G 5.66 Unberechtigter Anschluss von IT-Systemen an ein Netz ........ 69
G 5.67 Unberechtigte Ausfhrung von Netzmanagement-
Funktionen ............................................................................... 70
G 5.68 Unberechtigter Zugang zu den aktiven
Netzkomponenten .................................................................... 71
G 5.69 Erhhte Diebstahlgefahr am huslichen Arbeitsplatz.............. 72
G 5.70 Manipulation durch Familienangehrige und Besucher .......... 73
G 5.72 Missbruchliche E-Mail-Nutzung............................................ 75
G 5.73 Vortuschen eines falschen Absenders.................................... 76
G 5.74 Manipulation von Alias-Dateien oder Verteilerlisten.............. 77
G 5.75 berlastung durch eingehende E-Mails................................... 78
G 5.76 Mailbomben............................................................................. 79
G 5.77 Mitlesen von E-Mails............................................................... 80
G 5.78 DNS-Spoofing ......................................................................... 81
G 5.79 Unberechtigtes Erlangen von Administratorrechten
unter Windows NT................................................................... 83
G 5.80 Hoax......................................................................................... 84
G 5.81 Unautorisierte Benutzung eines Kryptomoduls ....................... 85
G 5.82 Manipulation eines Kryptomoduls........................................... 86
G 5.83 Kompromittierung kryptographischer Schlssel ..................... 87
G 5.84 Geflschte Zertifikate .............................................................. 88
G 5.85 Integrittsverlust schtzenswerter Informationen.................... 89
G 5.86 Manipulation von Managementparametern ............................. 90
G 5.87 Web-Spoofing.......................................................................... 91
G 5.88 Missbrauch aktiver Inhalte....................................................... 92
G 5.89 Hijacking von Netz-Verbindungen .......................................... 93
G 5.90 Manipulation von Adressbchern und Verteillisten ................ 94
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.91 Abschalten von Sicherheitsmechanismen fr den RAS-

Zugang ..................................................................................... 95
G 5.92 Nutzung des RAS-Clients als RAS-Server .............................. 96
G 5.93 Erlauben von Fremdnutzung von RAS-Komponenten ............ 97
G 5.94 Kartenmissbrauch .................................................................... 98
G 5.95 Abhren von Raumgesprchen ber Mobiltelefone ................ 99
G 5.96 Manipulation von Mobiltelefonen ......................................... 100
G 5.97 Unberechtigte Datenweitergabe ber Mobiltelefone ............. 101
G 5.98 Abhren von Mobiltelefonaten.............................................. 102
G 5.99 Auswertung von Verbindungsdaten bei der Nutzung
von Mobiltelefonen................................................................ 103
G 5.100 Missbrauch aktiver Inhalte beim Zugriff auf Lotus
Notes ...................................................................................... 104
G 5.101 "Hacking Lotus Notes" .......................................................... 105
G 5.102 Sabotage................................................................................. 106
G 5.103 Missbrauch von Webmail ...................................................... 107
G 5.104 Aussphen von Informationen ............................................... 109
G 5.105 Verhinderung der Dienste von Archivsystemen ................... 110
G 5.106 Unberechtigtes berschreiben oder Lschen von
Archivmedien......................................................................... 111
G 5.107 Weitergabe von Daten an Dritte durch den Outsourcing-
Dienstleister ........................................................................... 112
G 5.108 Ausnutzen von systemspezifischen Schwachstellen des
IIS .......................................................................................... 113
G 5.109 Ausnutzen systemspezifischer Schwachstellen beim
Apache-Webserver................................................................. 115
G 5.110 Web-Bugs .............................................................................. 116
G 5.111 Missbrauch aktiver Inhalte in E-Mails................................... 117
G 5.112 Manipulation von ARP-Tabellen........................................... 118
G 5.113 MAC-Spoofing ...................................................................... 119
G 5.114 Missbrauch von Spanning Tree ............................................. 120
G 5.115 berwindung der Grenzen zwischen VLANs ....................... 121
G 5.116 Manipulation der z/OS-Systemsteuerung .............................. 122
G 5.117 Verschleiern von Manipulationen unter z/OS........................ 124
G 5.118 Unbefugtes Erlangen hherer Rechte im RACF.................... 125
G 5.119 Benutzung fremder Kennungen unter z/OS-Systemen .......... 126
G 5.120 Manipulation der Linux/zSeries Systemsteuerung ................ 127
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.121 Angriffe ber TCP/IP auf z/OS-Systeme............................... 129

G 5.122 Missbrauch von RACF-Attributen unter z/OS ...................... 130
G 5.123 Abhren von Raumgesprchen ber mobile Endgerte......... 131
G 5.124 Missbrauch der Informationen von mobilen Endgerten....... 132
G 5.125 Unberechtigte Datenweitergabe ber mobile Endgerte ....... 133
G 5.126 Unberechtigte Foto- und Filmaufnahmen mit mobilen
Endgerten ............................................................................. 134
___________________________________________________________________ ..........................................
Gefhrdungskatalog Vorstzliche Handlungen G 5.1 Bemerkungen
___________________________________________________________________ ..........................................
G 5.1 Manipulation/Zerstrung von IT-Gerten oder

Zubehr
Auentter, aber auch Innentter, knnen aus unterschiedlichen Beweg- unterschiedliche Motive
grnden (Rache, Bswilligkeit, Frust) heraus versuchen, IT-Gerte, Zubehr,
Schriftstcke oder hnliches zu manipulieren oder zu zerstren. Die Manipu-
lationen knnen dabei umso wirkungsvoller sein, je spter sie entdeckt
werden, je umfassender die Kenntnisse des Tters sind und je tief greifender
die Auswirkungen auf einen Arbeitsvorgang sind. Die Auswirkungen reichen
von der unerlaubten Einsichtnahme in schtzenswerte Daten bis hin zur Zer-
strung von Datentrgern oder IT-Systemen, die erhebliche Ausfallzeiten nach
sich ziehen knnen.
Beispiel:
In einem Unternehmen nutzte ein Innentter seine Kenntnis darber, dass ein
wichtiger Server empfindlich auf zu hohe Betriebstemperaturen reagiert, und
blockierte die Lftungsschlitze fr den Netzteillfter mit einem hinter dem
Server aufgestellten Gegenstand. Zwei Tage spter erlitt die Festplatte im
Server einen temperaturbedingten Defekt und der Server fiel fr mehrere Tage
aus. Hinterher behauptete der Angreifer, dass es sich um ein Versehen
handelte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.2 Manipulation an Daten oder Software

Daten oder Software knnen auf vielfltige Weise manipuliert werden: durch
falsches Erfassen von Daten, nderungen von Zugriffsrechten, inhaltliche
nderung von Abrechnungsdaten oder von Schriftverkehr, nderungen in der
Betriebssystemsoftware und vieles mehr. Ein Tter kann allerdings nur die
Daten und Software manipulieren, auf die er Zugriff hat. Je mehr Zugriffs-
rechte eine Person besitzt, desto schwerwiegendere Manipulationen kann sie
vornehmen. Falls die Manipulationen nicht frhzeitig erkannt werden, kann
der reibungslose IT-Einsatz empfindlich gestrt werden.
Manipulationen an Daten oder Software knnen aus Rachegefhlen, um einen unterschiedliche Motive
Schaden mutwillig zu erzeugen, zur Verschaffung persnlicher Vorteile oder
zur Bereicherung vorgenommen werden.
Beispiele:
- 1993 wurde in einem schweizer Finanzunternehmen durch einen Mitar-
beiter die Einsatzsoftware fr bestimmte Finanzdienstleistungen manipu-
liert. Damit war es ihm mglich, sich illegal grere Geldbetrge zu ver-
schaffen.
- Sehr hufig werden Kundendatenbanken von Mitarbeitern beim Verlassen
der Firma kopiert. Auch das mutwillige Zerstren von Datenbanken oder
die Erpressung mit der Zerstrung stellen ein Risiko dar.
- Archivierte Dokumente stellen meist besonders schtzenswerte Daten dar.
Die Manipulation solcher Dokumente ist besonders schwerwiegend, da sie
unter Umstnden erst nach Jahren bemerkt wird und eine berprfung
dann oft nicht mehr mglich ist.
- In z/OS-Systemen gestattet das System Management Facility (SMF-Stze) Mainframe:
Verschleierung durch
die Protokollierung vieler sicherheitskritischer Aktivitten der Anwender. SMF-Manipulation
Kann ein Unbefugter diese SMF-Stze manipulieren, ist die Verschleierung
unerlaubter Handlungen im System mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.3 Unbefugtes Eindringen in ein Gebude

Das unbefugte Eindringen in ein Gebude geht verschiedenen Gefhrdungen
der IT wie Diebstahl oder Manipulation voraus. Manahmen, die dagegen
gerichtet sind, wirken dadurch auch gegen die entsprechenden Folgegefhr-
dungen. Bei qualifizierten Angriffen versierter Tter ist die Zeitdauer
entscheidend, in der die Tter ungestrt ihr Ziel verfolgen knnen. Ziel eines
Einbruchs kann der Diebstahl von IT-Komponenten oder anderer leicht
veruerbarer Ware sein, aber auch das Kopieren oder die Manipulation von
Daten oder IT-Systemen. Dabei knnen nicht offensichtliche Manipulationen
weit hhere Schden als direkte Zerstrungsakte verursachen.
Schon durch das unbefugte Eindringen knnen Sachschden entstehen.
Fenster und Tren werden gewaltsam geffnet und dabei beschdigt, sie
mssen repariert oder ersetzt werden.
Beispiele:
- Bei einem nchtlichen Einbruch in ein Brogebude konnten die Tter Vandalismus
keine lohnende Beute machen. Aus Frustration darber leerten sie die
Pulverlscher in die Brorume. Der Einbruchschaden war gering, der
Vandalismusschaden dagegen durch die Reinigungskosten und
Arbeitsunterbrechungen unverhltnismig hoch.
- Bei einem Einbruch in ein Unternehmen an einem Wochenende wurde nur Manipulationen
Bagatellschaden durch Aufhebeln eines Fensters angerichtet, lediglich eine
Kaffeekasse und kleinere Einrichtungsgegenstnde wurden entwendet. Bei
einer Routinekontrolle wurde jedoch spter festgestellt, dass ein zentraler
Server genau zum Zeitpunkt des Einbruchs geschickt manipuliert wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.4 Diebstahl
Durch den Diebstahl von IT-Gerten, Zubehr, Software oder Daten entstehen
einerseits Kosten fr die Wiederbeschaffung sowie fr die Wiederherstellung
eines arbeitsfhigen Zustandes, andererseits Verluste aufgrund mangelnder
Verfgbarkeit. Darber hinaus knnen Schden durch einen Ver-
traulichkeitsverlust und daraus resultierenden Konsequenzen entstehen.
Von Diebsthlen sind neben teuren IT-Systemen auch mobile IT-Systeme, die
unauffllig und leicht zu transportieren sind, hufig betroffen.
Beispiele:
- Im Frhjahr 2000 verschwand ein Notebook aus dem amerikanischen
Auenministerium. In einer offiziellen Stellungnahme wurde nicht ausge-
schlossen, dass das Gert vertrauliche Informationen enthalten knnte.
Ebenso wenig war bekannt, ob das Gert kryptographisch oder durch
andere Manahmen gegen unbefugten Zugriff gesichert war. Bei Sicher-
heitsuntersuchungen war bereits vor ungengenden Sicherheitskontrollen
gewarnt worden.
- In einem deutschen Bundesamt wurde mehrfach durch die gleichen
ungesicherten Fenster eingebrochen. Neben anderen Wertsachen ver-
schwanden auch mobile IT-Systeme. Ob Akten kopiert oder manipuliert
wurden, konnte nicht festgestellt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.5 Vandalismus
Vandalismus ist dem Anschlag sehr verwandt, nur dass er nicht wie dieser
gezielt eingesetzt wird, sondern meist Ausdruck blinder Zerstrungswut ist.
Sowohl Auentter (z. B. enttuschte Einbrecher, auer Kontrolle geratene
Demonstrationen) als auch Innentter (z. B. frustrierte oder alkoholisierte
Mitarbeiter) kommen in Betracht. Die tatschliche Gefhrdung durch Vanda-
lismus ist schwerer abschtzbar als die eines Anschlages, da ihm in der Regel
keine zielgerichtete Motivation zugrunde liegt. Persnliche Probleme oder ein
schlechtes Betriebsklima knnen dabei Ursachen sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.6 Anschlag
Die technischen Mglichkeiten, einen Anschlag zu verben, sind vielfltig:
geworfene Ziegelsteine, Explosion durch Sprengstoff, Schusswaffengebrauch,
Brandstiftung. Ob und in welchem Umfang ein IT-Betreiber der Gefahr eines
Anschlages ausgesetzt ist, hngt neben der Lage und dem Umfeld des Gebu-
des stark von seinen Aufgaben und vom politisch-sozialen Klima ab. IT-
Betreiber in politisch kontrovers diskutierten Bereichen sind strker bedroht
als andere. IT-Betreiber in der Nhe blicher Demonstrationsaufmarsch-
gebiete sind strker gefhrdet als solche in abgelegenen Randbereichen. Fr
die Einschtzung der Gefhrdung durch politisch motivierte Anschlge
knnen die Landeskriminalmter oder das Bundeskriminalamt beratend hin-
zugezogen werden.
Fr elektronische Archive ist bei dieser Einschtzung als besonderer Umstand viele Dokumente auf
kleinem Raum
zu bercksichtigen, dass darin eine groe Anzahl von Dokumenten auf ver-
gleichsweise kleinem Raum gespeichert wird. Dies knnen z. B. Kranken-
daten, Vertrge, Urkunden, Testamente privater Personen sowie Dokumente
und Vertrge von Unternehmen, Behrden und anderen staatlichen Einrich-
tungen sein. Deren Vernichtung kann weitreichende Auswirkungen haben,
nicht nur auf die speichernde Stelle, sondern auch auf eine Vielzahl anderer
Benutzer. Anschlge auf elektronische Archive knnen daher erhebliche
Schden verursachen.
Beispiele:
- In den 80er-Jahren wurde ein Sprengstoffanschlag auf das Rechenzentrum
einer groen Bundesbehrde in Kln verbt.
- Ein Finanzamt im rheinischen Raum wurde praktisch jhrlich durch Bom-
bendrohungen fr einige Stunden lahm gelegt.
- Ende der 80er-Jahre wurde von einem versuchten Anschlag der RAF auf
das Rechenzentrum einer groen deutschen Bank berichtet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.7 Abhren von Leitungen

Wegen des geringen Entdeckungsrisikos ist das Abhren von Leitungen eine
nicht zu vernachlssigende Gefhrdung der IT-Sicherheit. Grundstzlich gibt
es keine abhrsicheren Kabel. Lediglich der erforderliche Aufwand zum
Abhren unterscheidet die Kabel. Ob eine Leitung tatschlich abgehrt wird,
ist nur mit hohem messtechnischen Aufwand feststellbar.
Der Entschluss, eine Leitung abzuhren, wird im wesentlichen durch die Mglichkeiten und Inte-
ressen des Angreifers
Frage bestimmt, ob die Informationen den technischen (kostenmigen)
Aufwand und das Risiko der Entdeckung wert sind. Die Beantwortung dieser
Frage ist sehr von den individuellen Mglichkeiten und Interessen des
Angreifers abhngig. Somit ist eine sichere Festlegung, welche Informationen
und damit Leitungen ggf. abgehrt werden, nicht mglich.
Der Aufwand zum Abhren von Leitungen kann sehr gering sein. Bei
manchen Arten von LAN-Verkabelung kann der Zugang zu einer LAN-Dose
ausreichen, um den gesamten Netzverkehr des lokalen Netzes abzuhren.
Noch einfacher ist das Abhren des Netzverkehrs bei drahtlosen Netzen
(Wireless LAN / Funk-LAN, IEEE 802.11). Beim Abhren drahtloser Netze
ist zudem das Risiko der Entdeckung praktisch gleich null.
Besonders kritisch ist die bertragung von Authentisierungsdaten bei Klar- automatische Analyse
von Verbindungen bei
textprotokollen wie HTTP, ftp oder telnet, da sich hier die Position der vom Klartextprotokollen
Nutzer eingegebenen Daten in den bertragenen Paketen durch die einfache
Struktur der Protokolle leicht bestimmen lsst (siehe auch Unsichere
Protokolle in ffentlichen Netzen). Eine automatische Analyse solcher
Verbindungen lsst sich somit mit geringem Aufwand realisieren.
Mittels Password-Sniffings knnen in einem ersten Schritt Passwrter bei der
bertragung zu einem System abgefangen werden. Dies erlaubt dem
Angreifer anschlieend auf dieses IT-System zu gelangen, um dann weitere
Angriffe lokal auf dem Rechner durchzufhren.
Beispiele:
- So ist es z. B. falsch anzunehmen, dass per Electronic Mail versandte
Nachrichten mit klassischen Briefen vergleichbar sind. Da Mails whrend
ihres gesamten Weges durch das Netz gelesen werden knnen, ist ein
Vergleich mit Postkarten sehr viel realistischer.
- Einige Hersteller liefern Programme (Sniffer), die zum Debuggen der
Netze dienen, aber auch zum Abhren benutzt werden knnen, schon
zusammen mit ihren Betriebssystemen aus.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.8 Manipulation an Leitungen

Neben dem Abhren von Leitungen (siehe G 5.7, Abhren von Leitungen)
kann eine Manipulation an Leitungen noch andere Ziele haben:
- Frustrierte Mitarbeiter manipulieren Leitungen so, dass es zu unzulssigen unzulssige
Verbindungen
Verbindungen innerhalb und auerhalb der eigenen IT kommt. Dabei geht
es oft nur darum, den IT-Betrieb zu stren.
- Leitungen knnen so manipuliert werden, dass eine private Nutzung zu private Nutzung
Lasten des Netzbetreibers erfolgen kann. Neben den dadurch entstehenden
Kosten bei der Nutzung gebhrenpflichtiger Verbindungen werden
Leitungen und Ressourcen durch die private Nutzung blockiert.
- Durch die Manipulation von Leitungen kann es mglich werden, darauf Manipulation ber-
tragener Daten
bertragene Daten zum Vorteil des Tters zu verndern. Insbesondere bei
kassenwirksamen Verfahren, in der Lohnbuchhaltung und bei allen IT-
Anwendungen, die sich direkt oder indirekt mit der Verwaltung von
Sachwerten befassen, knnen sich durch Manipulationen hohe Schden
ergeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.9 Unberechtigte IT-Nutzung

Ohne Mechanismen zur Identifikation und Authentisierung von Benutzern ist
die Kontrolle ber unberechtigte IT-Nutzung praktisch nicht mglich. Selbst
bei IT-Systemen mit einer Identifikations- und Authentisierungsfunktion in
Form von Benutzer-ID- und Passwort-Prfung ist eine unberechtigte Nutzung
denkbar, wenn Passwort und zugehrige Benutzer-ID ausgespht werden.
Um das geheim gehaltene Passwort zu erraten, knnen Unbefugte innerhalb
der Login-Funktion ein mgliches Passwort eingeben. Die Reaktion des IT-
Systems gibt anschlieend Aufschluss darber, ob das Passwort korrekt war
oder nicht. Auf diese Weise knnen Passwrter durch Ausprobieren erraten
werden.
Viel Erfolg versprechender ist jedoch die Attacke, ein sinnvolles Wort als
Passwort anzunehmen und alle Benutzereintrge durchzuprobieren. Bei ent-
sprechend groer Benutzeranzahl wird damit oft eine gltige Kombination
gefunden.
Falls die Identifikations- und Authentisierungsfunktion missbruchlich nutz-
bar ist, so knnen sogar automatisch Versuche gestartet werden, indem ein
Programm erstellt wird, das systematisch alle mglichen Passwrter testet.
Beispiel:
1988 nutzte der Internet-Wurm eine Schwachstelle der betroffenen Unix-
Betriebssysteme aus, um gltige Passwrter zu finden, obwohl die gltigen
Passwrter verschlsselt gespeichert waren. Dazu probierte ein Programm
smtliche Eintragungen eines Wrterbuches aus, indem es sie mit der zur
Verfgung stehenden Chiffrierfunktion verschlsselte und mit den abge-
speicherten verschlsselten Passwrtern verglich. Sobald eine berein-
stimmung gefunden war, war auch ein gltiges Passwort erkannt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.10 Missbrauch von Fernwartungszugngen

Bei unzureichend gesicherten Fernwartungszugngen ist es denkbar, dass
Hacker Zugang zum Administrierungsport des IT-Systems erlangen. Sie
knnen somit nach berwindung des Anlagenpasswortes ggf. alle Admini-
strationsttigkeiten ausben. Der entstehende Schaden kann sich vom voll-
stndigen Anlagenausfall, ber schwerste Betriebsstrungen, den Verlust der
Vertraulichkeit aller auf der Anlage vorhandenen Daten bis hin zum groen
direkten finanziellen Schaden erstrecken.
Beispiel:
Zur Weitergabe von Systemfehlern an den Hersteller wird bei z/OS-Systemen RSF-Funktion bei z/OS-
Systemen
in der Regel das Remote Support Facility (RSF) eingesetzt. RSF kann auch
verwendet werden, um seitens des Herstellers Patches am sogenannten
Microcode vorzunehmen. Ein Missbrauch des RSF-Zugangs von z/OS-
Systemen stellt deshalb eine erhebliche Gefahr dar.
Auch bei Plattenherstellern fr z/OS-Systeme ist es inzwischen blich,
Probleme ber Fernwartungszugnge zu lsen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.11 Vertraulichkeitsverlust in TK-Anlagen

gespeicherter Daten
In TK-Anlagen werden personenbezogene und firmen-/behrdeninterne Daten
fr lngere Zeit auf Festplatten gespeichert. Personenbezogene Daten sind
hierbei Gebhrendaten, Konfigurationsdaten, Berechtigungen und ggf. Daten
fr die elektronischen Telefonbcher, Passwrter und Verrechnungsnummern.
Diese Daten knnen durch das Administrationspersonal eingesehen und ver-
ndert werden. Art und Umfang dieser Eingriffe sind vom Anlagentyp und,
falls vorgesehen, von der Rechtevergabe abhngig. Das Administrations-
personal hat diese Mglichkeit sowohl vor Ort als auch ber Fernwartung. Bei
einer externen Fernwartung hat der damit Beauftragte (im Regelfall der
Hersteller) jederzeit diese Mglichkeit!
Bei einer Aktualisierung der Anlagensoftware werden die Festplatten oft zu
den TK-Anlagen-Herstellern gebracht. Personenbezogene Daten knnen dann
vom Hersteller ausgelesen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.12 Abhren von Telefongesprchen und

Datenbertragungen
Durch missbruchliche Verwendung von Leistungsmerkmalen knnen
Gesprche unter Umstnden im Kollegenkreis mitgehrt werden. Als Beispiel
hierfr kann die Dreierkonferenz genannt werden. Erhlt der Teilnehmer A
einen Anruf fr den Teilnehmer B, so knnte er, anstatt den Anruf zu ber-
geben, versuchen, heimlich eine Dreierkonferenz herzustellen. Besitzt Teil-
nehmer B ein Telefon ohne Display, wrde er diese Tatsache nicht bemerken.
Desweiteren knnten Gesprche durch das Aktivieren von gesperrten, in
Deutschland zum Teil unzulssigen Leistungsmerkmalen von Dritten mitge-
hrt werden. Als ein Beispiel sei hier nur die Zeugenschaltung erwhnt. Eine
derartige Aktivierung erfordert genauere Systemkenntnisse.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.13 Abhren von Rumen

Grundstzlich mssen zwei Varianten des unbefugten Abhrens von Rumen
unterschieden werden. Bei der ersten Variante geht die Bedrohung aus-
schlielich vom Endgert aus. Hier sind intelligente Endgerte mit eingebau-
ten Mikrofonen wie Anrufbeantworter oder ISDN-Karten bzw. Multimedia-
PCs zu nennen. Solche Endgerte knnen, wenn entsprechende Funktiona-
litten implementiert sind, aus der Ferne, d. h. aus dem ffentlichen Netz,
dazu veranlasst werden, die eingebauten Mikrofone freizuschalten. Ein
bekanntes Beispiel hierfr ist die so genannte "Baby-Watch-Funktion" von
Anrufbeantwortern (vgl. Kapitel 8.3 Anrufbeantworter).
Die zweite Variante ist die Ausnutzung der Funktionalitt der TK-Anlage
selbst in Verbindung mit entsprechend ausgersteten Endgerten. Diese
Gefhrdung entsteht durch die missbruchliche Verwendung des Leistungs-
merkmals "direktes Ansprechen" in Kombination mit der Option
"Freisprechen". Die auf diese Weise realisierbare Funktion einer Wechsel-
sprechanlage kann unter gewissen Umstnden auch zum Abhren eines
Raumes ausgenutzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.14 Gebhrenbetrug
In letzter Zeit waren vermehrt Meldungen ber Gebhrenbetrug an TK-Anla-
gen durch Hacker in der Presse zu lesen. Solche Manipulationen sind auf ver-
schiedene Weisen durchfhrbar. Zum einen kann versucht werden, vorhan-
dene Leistungsmerkmale einer TK-Anlage fr diese Zwecke zu missbrauchen.
Geeignet hierfr sind beispielsweise aus der Ferne umprogrammierbare Ruf-
umleitungen oder Dial-In-Optionen. Zum anderen knnen die Berechtigungen
so vergeben werden, dass kommende "Amtsleitungen" abgehende
"Amtsleitungen" belegen knnen. Auf diese Weise kann bei Anwahl einer
bestimmten Rufnummer von auen der Anrufer automatisch wieder mit dem
"Amt" verbunden werden, wobei dies allerdings auf Kosten des TK-Anlagen-
betreibers geschieht.
Eine weitere Art des Gebhrenbetruges ist der durch den Benutzer selbst. Auf
unterschiedliche Arten, wie z. B. durch das Telefonieren von fremden
Apparaten, Auslesen fremder Berechtigungscodes (Passwort) oder Verndern
der persnlichen Berechtigungen kann versucht werden, auf Kosten des
Arbeitgebers oder der anderen Beschftigten zu telefonieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.15 "Neugierige" Mitarbeiter

Moderne TK-Anlagen verfgen in der Regel ber eine Vielzahl von
Leistungsmerkmalen, um den Benutzern grtmgliche Bequemlichkeit bei
der Kommunikation und eine mglichst weitgehende Anpassung an die
jeweilige Arbeitsumgebung zu bieten.
Einige dieser Leistungsmerkmale von TK-Anlagen knnen jedoch u. U. durch
"neugierige" Mitarbeiter missbraucht werden. Beispielsweise knnten
Mitarbeiter versuchen,
- unerlaubt Anrufe fr Kollegen auf ihren eigenen Telefonapparat
umzuleiten,
- unerlaubt Anrufe fr andere anzunehmen,
- unerlaubt fremde Anruf- und Wahlwiederholspeicher auszulesen und
- unerlaubt Telefongesprche Dritter mitzuhren.
Hierdurch besteht die Gefahr, dass "neugierige" Mitarbeiter unerlaubt
Kenntnis von Informationen erlangen, die nicht fr sie bestimmt oder sogar
vertraulich sind.
Beispiel:
Mit Hilfe der Funktion "Anruf heranholen" kann ein Benutzer einen Anruf,
der gerade auf dem Apparat eines Kollegen ankommt, aber noch nicht
angenommen ist, auf den eigenen Telefonapparat umleiten. Ein Mitarbeiter
eines Unternehmens verwendete diese Funktion, um Anrufe fr einen
abwesenden Kollegen entgegenzunehmen. Angeblich um Zeit zu sparen,
meldete er sich nur mit einem kurzen "Hallo?" und gab dadurch seine Identitt
nicht preis. Einige der Anrufer gingen daher flschlicherweise davon aus, dass
sie tatschlich mit der gewnschten Person sprachen und berichteten ber
vertrauliche Angelegenheiten. Auf dieses Weise erhielt der "neugierige"
Mitarbeiter unerlaubt Einblick in Projekte und Privatangelegenheiten seines
Kollegen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.16 Gefhrdung bei Wartungs-

/Administrierungsarbeiten durch internes
Personal
Zum eigenen Vorteil oder aus Geflligkeit fr Kollegen knnte bei Wartungs-
oder Administrationsarbeiten durch internes Personal versucht werden,
Berechtigungen (z. B. Auslandsberechtigung fr Telefongesprche oder
Zugriff auf Internetdienste) zu ndern oder Leistungsmerkmale zu aktivieren.
Dabei knnen durch Unkenntnis Systemabstrze verursacht werden oder
weitere Sicherheitslcken durch Konfigurationsfehler erffnet werden. Ferner
knnen durch unsachgeme Handhabung der Hardwarekomponenten diese
u. U. zerstrt werden. Zustzlich hat das Wartungspersonal vollen oder einge-
schrnkten Zugriff auf die gespeicherten Daten (lesend und schreibend) und
knnte diese unbefugt weitergeben oder manipulieren.
Auch die eigenhndige Steuerung oder zeitweilige Deaktivierung von Regel-
oder Alarmtechnik birgt ein hohes Gefhrdungspotential. Dies betrifft auch
Gefahrenmeldeanlagen und Leitsysteme.
Beispiele:
- Eine kurzfristig eingestellte Aushilfe, die die Aufgabe hatte, nicht mehr
genutzte Accounts zu sperren, nutzt ihre umfassende Berechtigung, um
sich urheberrechtlich geschtzte Software vom zentralen Applikations-
server fr private Zwecke herunterzuladen. Um das Programm auch gleich
an Freunde verteilen zu knnen, nutzt er dienstliche CD-ROM-Brenner und
Datentrger.
- Damit eine Kollegin auch whrend der Dienstzeit ihre privaten Homeban-
king-Transaktionen ausfhren kann, wird ihr aus Geflligkeit ein exklu-
siver Zugang zu ihrem Internet-Provider via ISDN zugnglich gemacht.
Als sie sich zu Ostern einen Bildschirmschoner aus dem Internet herunter-
ldt, infiziert sie ihren PC mit einem Virus. Da der Rechner mit dem Haus-
netz verbunden ist, verbreitet sich der Virus sehr schnell. Das Unter-
nehmensnetz ist bis zur Behebung des Problems fr mehrere Stunden nicht
nutzbar.
- Einbruchmeldeanlagen haben in vielen Fllen einen integrierten Protokol-
lierungsdrucker. Es kommt immer wieder vor, dass die Einbruchmelde-
anlage zum Auswechseln der hierzu erforderlichen Papierrolle
"vorsorglich" abgeschaltet wird. Beim anschlieenden Wiedereinschalten
besteht die Gefahr, dass das System unsachgem gestartet wird und sich
dadurch Fehlfunktionen ergeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.17 Gefhrdung bei Wartungsarbeiten durch

externes Personal
Ein IT-System kann bei Wartungsarbeiten auf jedwede Weise manipuliert
werden. Die Gefahr besteht in erster Linie darin, dass der Eigentmer oft nicht
in der Lage ist, die vorgenommenen Modifikationen nachzuvollziehen.
Darber hinaus hat der externe Wartungstechniker genau wie der interne auch
blicherweise Zugriff auf alle auf der Anlage gespeicherten Daten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.18 Systematisches Ausprobieren von Passwrtern

Zu einfache Passwrter lassen sich durch systematisches Ausprobieren heraus-
finden. Dabei ist zwischen dem simplen Ausprobieren aller mglichen
Zeichenkombinationen bis zu einer bestimmten Lnge (sogenannter Brute-
Force-Angriff) und dem Ausprobieren anhand einer Liste mit Zeichen-
kombinationen (sogenannter Wrterbuch-Angriff) zu unterscheiden. Beide
Anstze lassen sich auch kombinieren.
Die meisten Betriebssysteme verfgen ber eine Datei oder Datenbank (z. B.
passwd- bzw. shadow-Datei bei Unix oder RACF-Datenbank bei z/OS) mit
den Kennungen und Passwrtern der Benutzer. Allerdings werden zumindest
die Passwrter bei vielen Betriebssystemen nicht im Klartext gespeichert,
sondern es kommen kryptographische Mechanismen zum Einsatz. Ist die
Datei nur unzureichend gegen unbefugten Zugriff geschtzt, kann ein Angrei-
fer diese Datei mglicherweise kopieren und mit Hilfe leistungsfhigerer
Rechner und ohne Einschrnkungen hinsichtlich der Zugriffszeit einem Brute-
Force-Angriff aussetzen.
Die Zeit, die bei einem Brute-Force-Angriff zum Herausfinden eines Pass-
worts bentigt wird, hngt ab von
- der Dauer einer einzelnen Passwortprfung,
- der Lnge des Passworts und
- der Zeichenzusammensetzung des Passworts (z. B. Buchstaben/Zahlen).
Die Dauer einer einzelnen Passwortprfung hngt stark vom jeweiligen
System und dessen Verarbeitungs- bzw. bertragungsgeschwindigkeit ab. Im
Falle eines Angriffs spielen auch die Methode und die Technik des Angreifers
eine Rolle.
Lnge und Zeichenzusammensetzung des Passworts lassen sich dagegen durch
organisatorische Vorgaben oder sogar durch technische Manahmen beein-
flussen.
Beispiel:
Mit einem gut ausgestatteten PC lassen sich derzeit bei der Standard-Pass-
wort-Verschlsselung von Unix bzw. Linux etwa 400.000 Passwortprfungen
pro Sekunde durchfhren. Bei der Standard-Passwort-Verschlsselung von
Windows NT/2000/XP sind es sogar ber 6.000.000 Prfungen pro Sekunde
(Quelle: Der Hamburgische Datenschutzbeauftragte, 2003).
Bei einem Zeichenvorrat von 26 Zeichen dauert es somit etwa 6 Tage, um ein
8 Zeichen langes Passwort unter Unix bzw. Linux zu ermitteln (Standard-
Passwort-Verschlsselung). Die gleiche Aufgabe dauert unter Windows sogar
nur etwa 9 Stunden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.19 Missbrauch von Benutzerrechten

Eine missbruchliche Nutzung liegt vor, wenn man vorstzlich recht- oder
unrechtmig erworbene Mglichkeiten ausnutzt, um dem System oder dessen
Benutzern zu schaden.
In nicht wenigen Fllen verfgen Anwender aus systemtechnischen Grnden
ber hhere oder umfangreichere Zugriffsrechte, als sie fr ihre Ttigkeit
bentigen. Diese Rechte knnen zum Aussphen von Daten verwendet
werden, auch wenn Arbeitsanweisungen den Zugriff verbieten.
Beispiel:
- Auf vielen Unix-Systemen ist die Datei /etc/passwd fr jeden Benutzer
lesbar, so dass er sich Informationen ber dort eingetragene persnliche
Daten verschaffen kann. Auerdem kann er mit Wrterbuchattacken (siehe
G 5.18 Systematisches Ausprobieren von Passwrtern) versuchen, die
verschlsselten Passwrter zu erraten. Bei zu grozgiger Vergabe von
Gruppenrechten, insbesondere bei den Systemgruppen wie z. B. root, bin,
adm, news oder daemon, ist ein Missbrauch wie z. B. das Verndern oder
Lschen fremder Dateien leicht mglich.
- Ein fr die Verwaltung der Festplatten in z/OS-Systemen zustndiger
Storage-Administrator konnte dank des Attributes Operations, das er fr
die Ausfhrung seiner Ttigkeit von der RACF-Administration erhalten
hatte, Kundendateien einsehen. Er nutzte dieses Zugriffsrecht aus, um
unerlaubt Kopien zu erstellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.20 Missbrauch von Administratorrechten

Eine missbruchliche Administration liegt vor, wenn man vorstzlich recht-
oder unrechtmig erworbene Super-User- (root-) Privilegien ausnutzt, um
dem System oder dessen Benutzern zu schaden.
Beispiele:
-Da root auf Unix-Anlagen keinerlei Beschrnkungen unterliegt, kann der keine Beschrnkungen
fr root
Administrator unabhngig von Zugriffsrechten jede Datei lesen, verndern
oder lschen. Auerdem kann er die Identitt jedes Benutzers seines Systems
annehmen, ohne dass dies von einem anderen Benutzer bemerkt wird, es ist
ihm also z. B. mglich unter fremden Namen Mails zu verschicken oder
fremde Mails zu lesen und zu lschen.
-Es gibt verschiedene Mglichkeiten, missbruchlich Super-User-Privilegien Super-User-Dateien
auszunutzen. Dazu gehren der Missbrauch von falsch administrierten Super-
User-Dateien (Dateien mit Eigentmer root und gesetztem s-Bit) und des
Befehls su.
-Die Gefhrdung kann auch durch automatisches Mounten von austauschbaren automatisches Mounten
Datentrgern entstehen: Sobald das Medium in das Laufwerk gelegt wird,
wird es gemountet. Dann hat jeder Zugriff auf die dortigen Dateien. Mit sich
auf dem gemounteten Laufwerk befindenden s-Bit-Programmen kann jeder
Benutzer Super-User-Rechte erlangen.
-In Abhngigkeit von der Unix-Variante und der zugrunde liegenden Zugang zur Konsole
Hardware kann bei Zugangsmglichkeit zur Konsole der Monitor-Modus
aktiviert oder in den Single-User-Modus gebootet werden. Das ermglicht die
Manipulation der Konfiguration.
-Durch Softwarefehler kann es mglich sein, dass eine Anwendung nur eine Softwarefehler
begrenzt groe Menge an Daten verarbeiten kann. Werden dieser Anwendung
bergroe Datenmengen oder Parameter bergeben, knnen Bereiche im
Hauptspeicher mit fremden Code berschrieben werden. Dadurch knnen
Befehle mit den Rechten der Anwendung ausgefhrt werden. Dies war u. a
mit dem Befehl eject unter SunOS 5.5 mglich, der mit SetUID-Rechten
ausgestattet ist, also bei der Ausfhrung Super-User-Rechte besitzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.21 Trojanische Pferde

Ein Trojanisches Pferd, oft auch (eigentlich flschlicherweise) kurz Trojaner Anwenderprogramme,
genannt, ist ein Programm mit einer verdeckten, nicht dokumentierten Funk- Command Tables und
tion oder Wirkung. Der Benutzer kann daher auf die Ausfhrung dieser Scriptsprachen
Funktion keinen Einfluss nehmen - insoweit besteht eine gewisse Verwandt-
schaft mit Computer-Viren. Es ist jedoch keine Selbstreproduktion vorhanden.
Als Trger fr Trojanische Pferde lassen sich alle mglichen Anwenderpro-
gramme benutzen. Aber auch Scriptsprachen, wie Batch-Dateien, ANSI-Steu-
ersequenzen, REXX Execs und ISPF Command Tables bei z/OS-
Betriebssystemen, Postscript und hnliches, die vom jeweiligen
Betriebssystem oder Anwenderprogramm interpretiert werden, knnen fr
Trojanische Pferde missbraucht werden.
Die Schadwirkung eines Trojanischen Pferdes ist um so wirkungsvoller, je
mehr Rechte sein Trgerprogramm besitzt.
Beispiele:
- Ein gendertes Login-Programm kann ein Trojanisches Pferd enthalten, genderte Login-Pro-
gramme
das Namen und Passwort des Benutzers ber das Netz an den Angreifer
bermittelt und dann an das eigentliche Login-Programm weitergibt.
Solche Trojanischen Pferde sind z. B. bei Online-Diensten wie AOL oder
T-Online aufgetreten.
- Auch Bildschirmschoner, besonders solche, die aus dem Internet herunter Bildschirmschoner
geladen werden, knnen eine versteckte Funktion enthalten, mit der die
eingegebenen Passwrter des angemeldeten Benutzers protokolliert und an
einen Angreifer bermittelt.
- Bei dem Programm Back Orifice handelt es sich um eine Client-Server- Back Orifice und NetBUS
Anwendung, die es dem Client erlaubt, einen Windows-PC ber das Netz
fernzuwarten. Insbesondere knnen Daten gelesen und geschrieben sowie
Programme ausgefhrt werden. Eine Gefhrdung entsteht dadurch, dass
dieses Programm in ein anderes Anwendungsprogramm integriert und
somit als Trojanisches Pferd verwendet werden kann. Wird das Trojanische
Pferd gestartet und besteht eine Netzverbindung, so kann ein Angreifer die
Fernwartungsfunktion von Back Orifice fr den Benutzer unbemerkt
benutzen. In diesem Zusammenhang ist auch das Programm NetBUS zu
erwhnen, das hnliche Funktionen bietet.
- Mit Hilfe von Root-Kits fr verschiedene Unix-Varianten, die manipulierte manipulierte Programme
und Bibliotheken
Versionen von Systemprogrammen wie ps, who, netstat etc. enthalten, ist
es mglich, lngere Zeit unbemerkt Hintertren (so genannte Backdoors)
offen zu halten, die einen unbemerkten Einbruch in das System
ermglichen und dabei die Angriffsspuren verstecken. Hufig werden u. a.
die Dateien /sbin/in.telnetd, /bin/login, /bin/ps, /bin/who, /bin/netstat und
die C-Libraries ausgetauscht.
- Eine weitere Gefahrenquelle bei Unix-Systemen ist der "." in der Umge- aktuelles Verzeichnis im
Suchpfad
bungsvariable $PATH. Wenn das jeweils aktuelle Arbeitsverzeichnis (.) als
Pfad in der Variable PATH enthalten ist, werden zunchst die dort befind-
lichen Programme ausgefhrt. So knnte beim Auflisten des Inhaltes eines
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verzeichnisses vom Superuser unbeabsichtigt ein darin enthaltenes modi-

fiziertes "ls"-Programm mit root-Rechten ausgefhrt werden.
- Eine Mglichkeit, sich im z/OS-Betriebssystem hhere Rechte zu Einschleusen von
Programmcode
erschleichen, bietet sich dann, wenn fr den Angreifer ein Update-Zugriff
auf Dateien existiert, die entweder beim Logon-Vorgang durchlaufen (z. B.
eine REXX EXEC) oder whrend der Verarbeitung allgemein benutzt
werden (z. B. ISPF Command Tables). Der Angreifer kann dann den
vorhandenen Code durch eigene Programmteile ersetzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.22 Diebstahl bei mobiler Nutzung des IT-Systems

Wird ein IT-System mobil genutzt, so ergeben sich neue Gefhrdungen, die
stationre IT-Systeme in dem Mae nicht berhren. Mobile Systeme wie
Laptops werden blicherweise nicht in einem durch Schutzvorkehrungen
gesicherten Raum eingesetzt. Sie werden in PKW oder ffentlichen
Verkehrsmitteln transportiert, in fremden Brorumen in Pausen hinterlassen
oder in Hotelzimmern unbewacht aufgestellt.
Aufgrund dieser Umfeldbedingungen sind solche mobil eingesetzten IT-
Systeme naturgem einem hheren Diebstahlrisiko ausgesetzt. Der im
Kofferraum eines PKW eingeschlossene Laptop kann gestohlen werden, ohne
dass dies das originre Ziel des Diebstahl ist, denn mit dem gestohlenen
Wagen wrde auch der Laptop in die falschen Hnde geraten.
Beispiel:
Dem Geschftsfhrer einer greren Firma wurde auf einer Geschftsreise der
Laptop gestohlen. Der materielle Verlust war vernachlssigbar, innerhalb
eines Tages konnte ein neuer Laptop beschaft werden. Schmerzlicher war der
Verlust von wichtigen Kundendaten, die auf dem Laptop gespeichert waren.
Von diesen Informationen gab es keine Datensicherung, da sie erst im Verlauf
der Geschftsreise erfasst worden sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.23 Computer-Viren
Computer-Viren gehren zu den Programmen mit Schadensfunktionen. Als
Schaden ist hier insbesondere der Verlust oder die Verflschung von Daten
oder Programmen sicherlich von grter Tragweite. Solche Funktionen von
Programmen knnen sowohl unbeabsichtigt als auch bewusst gesteuert auf-
treten.
Die Definition eines Computer-Virus bezieht sich nicht unmittelbar auf eine
mglicherweise programmierte Schadensfunktion:
Ein Computer-Virus ist eine nicht selbstndige Programmroutine, die sich
selbst reproduziert und dadurch vom Anwender nicht kontrollierbare
Manipulationen in Systembereichen, an anderen Programmen oder deren
Umgebung vornimmt. (Zustzlich knnen programmierte Schadensfunktionen
des Virus vorhanden sein.)
Die Eigenschaft der Reproduktion fhrte in Analogie zum biologischen
Vorbild zu der Bezeichnung "Virus". Die Mglichkeiten der Manipulation
sind sehr vielfltig. Besonders hufig sind das berschreiben oder das
Anlagern des Virus-Codes an andere Programme und Bereiche des Betriebs-
systems.
Computer-Viren knnen im Prinzip bei allen Betriebssystemen auftreten. Die
grte Bedrohung ist jedoch im Bereich der IBM-kompatiblen Personal-
computer (PC) vorhanden. Bei den hier am meisten verbreiteten Betriebs-
systemen (MS-DOS, PC-DOS, DR DOS, NOVELL DOS etc.) werden derzeit
weltweit rund 20.000 Viren (einschlielich Varianten) gezhlt.
Spezielle Computer-Viren fr die Betriebssysteme Windows 3.x,
Windows NT, Windows 95, OS/2 und Unix spielen in der Praxis eine unter-
geordnete Rolle. Bei PC-typischer Hardware knnen jedoch die Festplatten
dieser Rechner von DOS-Boot-Viren infiziert werden, wenn die Boot-Reihen-
folge zuerst ein Booten von Diskette vorsieht.
Fr Apple-Computer sind ca. 100 spezielle Computer-Viren bekannt, fr die
es auch entsprechende Suchprogramme gibt.
Arten von Computer-Viren
Es werden drei Grundtypen von Computer-Viren unterschieden:
- Boot-Viren
- Datei-Viren
- Makro-Viren
Es sind auch Misch- und Sonderformen dieser drei Typen bekannt. Weitere
Unterteilungsmerkmale sind die Tarnmechanismen, mit denen die Viren oft
gegen die Erkennung durch Benutzer und Suchprogramme geschtzt sind.
Boot-Viren
Als "Booten" bezeichnet man das Laden des Betriebssystems. Hierbei werden
u. a. Programmteile ausgefhrt, die zwar eigenstndig sind, sich aber in sonst
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nicht zugnglichen und im Inhaltsverzeichnis der Disketten und Festplatten

nicht sichtbaren Sektoren befinden. Boot-Viren berschreiben diese mit ihrem
Programm. Der originale Inhalt wird an eine andere Stelle auf dem Daten-
trger verlagert und dann beim Start des Computers anschlieend an den
Virus-Code ausgefhrt. Dadurch startet der Computer scheinbar wie gewohnt.
Der Boot-Virus gelangt jedoch bereits vor dem Laden des Betriebssystems in
den Arbeitsspeicher des Computers und verbleibt dort whrend der gesamten
Betriebszeit. Er kann deshalb den Boot-Sektor jeder nicht schreibgeschtzten
Diskette infizieren, die whrend des Rechnerbetriebs benutzt wird. Boot-Viren
knnen sich nur durch Booten oder einen Boot-Versuch mit einer infizierten
Diskette auf andere Computer bertragen.
Datei-Viren
Die meisten Datei-Viren (auch File-Viren genannt) lagern sich an Programm-
dateien an. Dies geschieht jedoch so, dass beim Aufruf auch hier der Virus-
Code zuerst ausgefhrt wird und erst anschlieend das originale Programm.
Dadurch luft das Programm anschlieend scheinbar wie gewohnt und der
Virus wird nicht so schnell entdeckt. Es sind jedoch auch primitivere, ber-
schreibende Viren bekannt, die sich so an den Anfang des Wirtsprogramms
setzen, so dass dieses nicht mehr fehlerfrei luft. Datei-Viren verbreiten sich
durch Aufruf eines infizierten Programms.
Bei den Mischformen von Boot- und Datei-Viren haben so genannte multi-
partite Viren eine grere Bedeutung erlangt. Sie knnen sich sowohl durch
Aufruf eines infizierten Programms als auch durch Booten (oder einen Boot-
Versuch) von einer infizierten Diskette verbreiten.
Makro-Viren
Auch Makro-Viren sind in Dateien enthalten, diese infizieren jedoch nicht die
Anwendungsprogramme, sondern die damit erzeugten Dateien. Betroffen sind
alle Anwendungsprogramme, bei denen in die erzeugten Dateien nicht nur
einzelne Steuerzeichen, sondern auch Programme und andere Objekte einge-
bettet werden knnen. Davon sind insbesondere Microsoft Word- und Excel-
Dateien betroffen. Bei diesen steht eine leistungsfhige Programmiersprache
fr Makros zur Verfgung, die auch von weniger geschulten Benutzern leicht
zur Programmierung von Viren missbraucht werden kann (siehe auch G 5.43
Makro-Viren).
Makros sind Programme, mit deren Hilfe das Anwenderprogramm um
zustzliche Funktionen erweitert werden kann, die auf den Anwendungsfall
zugeschnitten sind (z. B. Erzeugen einer Reinschrift aus dem Entwurf eines
Textes). Diese Makros laufen erst mit dem jeweiligen Anwendungsprogramm
(Winword, Excel etc.) bei der Bearbeitung des Dokuments ab, indem der
Benutzer das Makro aktiviert oder das Makro automatisch gestartet wird.
Wird z. B. eine Word-Datei ber einen WWW-Browser empfangen, der das
Dokument automatisch mit Microsoft Word ffnet, kann hierdurch ein enthal-
tenes Makro aktiviert werden. Da Datendateien auch hufiger als her-
kmmliche Programmdateien ber Datentrger und vernetzte IT-Systeme
verteilt werden, ist die Gefhrdung durch Makro-Viren inzwischen grer als
durch Boot- und Datei-Viren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiele fr Schadensfunktionen von Computer-Viren

- Der Boot-Virus Michelangelo berschreibt an jedem 6. Mrz die ersten
Spuren der Festplatte mit stochastischem Inhalt und macht sie dadurch
unbrauchbar.
- Der multipartite Virus Onehalf verschlsselt maximal die Hlfte des
Inhalts der Festplatte. Wird der Virus entfernt, sind die verschlsselten
Daten nicht mehr verfgbar.
- Der Winword-Makro-Virus WAZZU fgt bei den befallenen Dokumenten
an zuflligen Stellen das Wort "Wazzu" ein.
- Der Winword-Makro-Virus Melissa erschien am 26.3.1999 und verbreitete
sich ber das Wochenende weltweit. Er ist in einer Datei von Word 97 oder
Word 2000 enthalten, die von einem befallenen Computer mittels
Microsoft Outlook an bis zu 50 gespeicherte Eintrge aus jedem
Adressbuch verschickt wird. Dies hat bei einigen greren Organisationen
das Mail-System berlastet.
- W32.Mypics.Worm ist ein in Visual Basic geschriebener Computerwurm,
der sich automatisch auf Windows 95/98 und Windows NT Rechnern
verbreitet. Er enthlt eine zerstrerische Schadenswirkung, die aktiv wird,
sobald die Jahreszahl 2000 ist. Dann wird u. a. das BIOS des Rechners
verndert, so dass der Rechner nicht mehr korrekt bootet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.24 Wiedereinspielen von Nachrichten

Angreifer zeichnen bei diesem Angriff eine Nachricht auf und spielen diese
Information zu einem spteren Zeitpunkt unverndert wieder ein.
Beispiele:
- Ein Angreifer zeichnet die Authentisierungsdaten (z. B. Benutzer-ID und
Passwort) whrend des Anmeldevorgangs eines Benutzers auf und benutzt
diese Informationen, um sich unter Vortuschen einer falschen Identitt
Zugang zu einem System zu verschaffen (siehe auch G 5.21 Trojanische
Pferde).
- Um finanziellen Schaden beim Arbeitgeber (Unternehmen oder Behrde)
zu verursachen, gibt ein Mitarbeiter eine genehmigte Bestellung mehrmals
auf.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.25 Maskerade
Die Maskerade benutzt ein Angreifer um eine falsche Identitt vorzutuschen. Manipulation des
Eine falsche Identitt erlangt er z. B. durch das Aussphen von Benutzer-ID Absenderfeldes oder der
und Passwort (siehe auch G 5.9 Unberechtigte IT-Nutzung), die Manipulation Kartenadresse
des Absenderfeldes einer Nachricht oder durch die Manipulation einer
Adresse (siehe beispielsweise auch G 5.48 IP-Spoofing oder G 5.87 Web-
Spoofing) im Netz. Weiterhin kann eine falsche Identitt durch die
Manipulation der Rufnummernanzeige (Calling Line Identification
Presentation) im ISDN oder durch die Manipulation der Absenderkennung
eines Faxabsenders (CSID - Call Subscriber ID) erlangt werden.
Ein Benutzer, der ber die Identitt seines Kommunikationspartners getuscht
wurde, kann leicht dazu gebracht werden, schutzbedrftige Informationen zu
offenbaren.
Ein Angreifer kann durch eine Maskerade auch versuchen, sich in eine bereits Aufschalten auf eine
bestehende Verbindung
bestehende Verbindung einzuhngen, ohne sich selber authentisieren zu
mssen, da dieser Schritt bereits von den originren Kommunikations-
teilnehmern durchlaufen wurde. (siehe dazu auch G 5.89 Hijacking von Netz-
Verbindungen)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.26 Analyse des Nachrichtenflusses

ber eine Verkehrsflussanalyse versucht ein Angreifer Auskunft darber zu
erhalten, wer wann welche Datenmengen an wen gesendet hat und wie oft.
Sogar wenn der Lauscher die Nachrichteninhalte nicht lesen kann, knnen
hierdurch Rckschlsse auf das Benutzerverhalten gezogen werden. Die
Informationen ber Datum und Uhrzeit der Erstellung einer Nachricht knnen
zu einem Persnlichkeitsprofil des Absenders ausgewertet werden. Daneben
forschen Adresssammler fr Adressverlage nach E-Mail- und Post-Adressen,
um unaufgefordert Werbung zuzuschicken.
Innerhalb des ISDN (Integrated Services Digital Network) wre der D-Kanal
einer Kommunikationsverbindung, welcher der Signalisierung zwischen End-
gert und Vermittlungsstelle dient, ein geeigneter Angriffspunkt. Die Analyse
der dort bertragenen Signalisierung mittels eines Protokollanalysators lsst
nicht nur die o. a. Rckschlsse auf das Benutzerverhalten zu (z. B. wer tele-
foniert wann mit wem wie lange?), sondern kann auch der Vorbereitung
komplexerer Angriffe ber den D-Kanal dienen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.27 Nichtanerkennung einer Nachricht

Bei jeder Art von Kommunikation kann ein Kommunikationsteilnehmer den
Nachrichtenempfang ableugnen (Repudiation of Receipt). Dies ist insbe-
sondere bei finanziellen Transaktionen von Bedeutung. Ein Nachrichten-
empfang kann beim Postversand ebenso abgeleugnet werden wie bei Fax-
oder E-Mail-Nutzung.
Beispiel:
Ein dringend bentigtes Ersatzteil wurde elektronisch bestellt. Nach einer
Woche Arbeitsausfall wurde das Fehlen reklamiert. Der Lieferant leugnet, je
eine Bestellung erhalten zu haben.
Ebenso kann es passieren, dass ein Kommunikationsteilnehmer den Nachrich-
tenversand ableugnet, z. B. also eine gettigte Bestellung abstreitet
(Repudiation of Origin).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.28 Verhinderung von Diensten

Ein solcher Angriff, auch "Denial of Service" genannt, zielt darauf ab, die IT-
Benutzer daran zu hindern, Funktionen oder Gerte zu benutzen, die ihnen
normalerweise zur Verfgung stehen. Dieser Angriff steht hufig im
Zusammenhang mit verteilten Ressourcen, indem ein Angreifer diese
Ressourcen so stark in Anspruch nimmt, dass andere Benutzer an der Arbeit
gehindert werden. Es knnen z. B. die folgenden Ressourcen knstlich
verknappt werden: Prozesse, CPU-Zeit, Plattenplatz, Inodes, Verzeichnisse.
Dies kann z. B. geschehen durch
- das Starten von beliebig vielen Programmen gleichzeitig,
- das mehrfache Starten von Programmen, die viel CPU-Zeit verbrauchen,
- das Belegen aller freien Inodes in einem Unix-System, so dass keine neuen
Dateien mehr angelegt werden knnen,
- unkoordiniertes Belegen von Bandstationen in z/OS-Systemen, so dass Sperren von
Bandstationen am z/OS-
Anwendungen auf freie Bandstationen warten mssen und die Online- System
Verarbeitung eingeschrnkt ist,
- bewusste Falscheingabe von Passwrtern (auch Skript-gesteuert) mit dem DoS-Attacke auf z/OS
Kennungen
Ziel der Sperrung aller Kennungen eines z/OS-Systems,
- das Anlegen sehr vieler kleiner Dateien in einem Verzeichnis auf einem
DOS-PC, so dass in diesem Verzeichnis keine neuen Dateien mehr ange-
legt werden knnen,
- die gezielte berlastung des Netzes,
- das Kappen von Netzverbindungen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.29 Unberechtigtes Kopieren der Datentrger

Werden Datentrger ausgetauscht oder transportiert, so bedeutet dies unter
Umstnden, dass die zu bermittelnden Informationen aus einer gesicherten
Umgebung heraus ber einen unsicheren Transportweg in eine ggf. unsichere
Umgebung beim Empfnger bertragen werden. Unbefugte knnen sich in
solchen Fllen diese Informationen dort durch Kopieren einfacher beschaffen,
als es in der ursprnglichen Umgebung der Fall war.
Wegen der groen Konzentration schtzenswerter Informationen auf Daten-
trgern elektronischer Archive (z. B. personenbezogene oder firmenvertrau-
liche Daten) stellen diese ein besonderes Angriffsziel fr Diebstahl oder Kopie
durch Unbefugte dar.
Beispiel:
Vertrauliche Entwicklungsergebnisse sollen vom Entwicklungslabor in X-
Stadt zur Produktion nach Y-Stadt transportiert werden. Werden die ent-
sprechenden Datentrger unkontrolliert ber den Postweg versandt, kann nicht
ausgeschlossen werden, dass diese unberechtigterweise kopiert und ggf. an die
Konkurrenz verkauft werden, ohne dass die Blostellung der Informationen
bemerkt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.30 Unbefugte Nutzung eines Faxgertes oder eines

Faxservers
Der unberechtigte Zugang zu einem Faxgert oder unberechtigte Zugriff auf
einen Faxserver kann fr manipulative Zwecke ausgenutzt werden. Dabei
knnen neben den Kosten fr die Faxbertragung (Gebhren und Material)
auch Schden dadurch entstehen, dass ein Unbefugter vorgibt, das Gert als
Berechtigter zu nutzen (Schreiben mit Firmenkopf vom entsprechenden Fax-
Anschluss).
Es muss zudem vermieden werden, dass Unbefugte Zugriff auf eingehende
Faxsendungen haben.
Beispiele:
- Ein Faxgert ist im Flur aufgestellt, so dass jeder im Vorbeigehen unkon-
trolliert Faxe lesen oder an sich nehmen kann.
- Bei einem Faxserver sind die Berechtigungen auf die gespeicherten
Faxdaten falsch gesetzt, so dass Unbefugte fremde Faxe lesen knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.31 Unbefugtes Lesen von Faxsendungen

Beim Einsatz von Faxgerten besteht dann die Gefahr des unbefugten Lesens
eingegangener Faxsendungen, wenn die Gerte in frei zugnglichen Bereichen
aufgestellt werden. Zudem knnen Unbefugte Kenntnis vom Inhalt vertrau-
licher Faxsendungen erlangen, wenn die Verteilung innerhalb der Organi-
sation fehlerhaft ist.
Beim Einsatz von Faxservern ist eine unbefugte Kenntnisnahme ein- und auszu weitgehende Zugriffs-
rechte
gehender Faxsendungen u. U. mglich, sofern die Zugriffsrechte auf dem
Faxserver nicht sorgfltig vergeben werden.
Faxserver verfgen zudem ber so genannte Adressbcher. Die Adressbcher manipulierte Adress-
bcher
erleichtern die Versendung von Faxen, da die Benutzer nur den jeweiligen
Empfnger auswhlen und nicht bei jedem Fax die Empfngerrufnummer
erneut eingeben mssen. Sofern in einem Adressbuch eine falsche Empfnger-
rufnummer eingetragen ist, wird bei Benutzung dieses Eintrages das Fax an
den falschen Empfnger gesendet. Hufig bieten Adressbcher auch die Mg-
lichkeit, mehrere Adressaten zu einer Gruppe zusammenzufassen. Der
Benutzer, der ein Fax an die Mitglieder einer solchen Gruppe senden will,
braucht als Empfnger nur die Gruppe und nicht jedes Gruppenmitglied anzu-
geben. Sofern sich in solch einer Gruppe unbefugte Adressaten befinden,
knnen diese Kenntnis von allen Faxsendungen erhalten, die ber diese
Gruppendefinition versandt werden. Die falsche Zuordnung kann durch
Unachtsamkeit oder aufgrund einer gezielten Manipulation erfolgen.
Auf einem Faxserver eingegangene Faxsendungen mssen an die Empfnger
verteilt werden. Dies kann entweder dadurch erfolgen, dass Eingangs-Fax-
sendungen ausgedruckt und manuell an die Empfnger weitergeleitet werden
oder dass der Faxserver die Verteilung automatisch ber das Netz vornimmt.
Eine unbefugte Kenntnisnahme von eingegangenen Faxsendungen ist u. U. bei unbefugte Kenntnis-
nahme am Drucker
der manuellen Verteilung mglich, wenn der Drucker, auf dem der Ausdruck
erfolgt, in einem allgemein zugnglichen Bereich aufgestellt wurde oder die
Verteilung innerhalb der Organisation fehlerhaft ist.
Bei der automatischen Weiterleitung von Faxsendungen bentigt der Fax- manipulierte Zuord-
nungstabellen
server eine Zuordnungstabelle, in der festgelegt wird, an welchen Benutzer
bzw. an welche Benutzergruppe Eingangs-Faxsendungen, die z. B. von einem
bestimmten Absender stammen oder ber eine bestimmte Rufnummer ge-
sendet wurden, weitergeleitet werden sollen. Sofern ein Unbefugter in einer
solchen Zuordnungstabelle - sei es durch Unachtsamkeit oder aufgrund einer
gezielten Manipulation - aufgenommen wird, erhlt er Faxsendungen, die
nicht fr ihn bestimmt sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.32 Auswertung von Restinformationen in

Faxgerten und Faxservern
Faxgerte
Abhngig vom technischen Verfahren, mit denen Faxgerte Informationen
speichern, weiterverarbeiten oder drucken, knnen sich nach dem Faxempfang
Restinformationen unterschiedlichen Umfanges im Faxgert befinden. Sie
knnen wiederhergestellt werden, wenn man in den Besitz des Gertes oder
der entsprechenden Bauteile kommt.
Bei Faxgerten, die mittels des Thermotransferverfahrens drucken, werden Thermotransferdruck
eingehende Faxsendungen zunchst auf eine Zwischentrgerfolie geschrieben,
mit deren Hilfe sie dann ausgedruckt werden. Diese Folie ist
Verbrauchsmaterial und muss regelmig ausgetauscht werden, das Entfernen
der Folie ist daher leicht mglich. Gelangt ein Unbefugter in den Besitz dieser
Folie (durch Diebstahl oder bei der Entsorgung), kann er den Inhalt mit ein-
fachen technischen Mitteln reproduzieren. Dabei knnen ihm die Informa-
tionen von mehreren hundert Faxseiten bekannt werden.
Die meisten Faxgerte verfgen ber einen Zwischenspeicher Zwischenspeicher im
Faxgert
(Dokumentenspeicher, Puffer), in den ausgehende Faxe bis zur erfolgreichen
bertragung eingelesen bzw. eingehende Faxe vor dem Ausdrucken
zwischengespeichert werden knnen. Dieser Speicher kann je nach Faxgert
eine grere Anzahl Faxseiten enthalten und kann im Allgemeinen von jedem,
der Zugang zum Faxgert hat, ausgedruckt werden.
Faxserver
Faxserver sind Applikationen, die auf IT-Systemen installiert sind, die in aller Restinformationen auf
Festplatten
Regel mit mindestens einer Festplatte ausgestattet sind oder ber das Netz auf
ein Laufwerk zugreifen knnen. Hierauf werden Faxsendungen solange
gespeichert, bis sie an einen Empfnger zugestellt werden knnen. Weiterhin
arbeiten moderne Betriebssysteme mit Auslagerungsdateien, die auch
Restinformationen enthalten knnen. Hier besteht die Gefahr, dass diese
Informationen bei Zugriff auf diesen Faxserver unerlaubt ausgewertet werden.
Fllt z. B. eine Festplatte whrend der Garantiezeit aus, muss diese zur
Geltendmachung von Garantieansprchen an den Hndler oder an den
Hersteller eingesandt werden. Problematisch ist dabei, dass sich noch Daten
auf der Festplatte befinden knnen, von denen Unbefugte auf diesem Weg
Kenntnis erlangen knnen. Bei defekten Festplatten ist eine Lschung der
Daten mit Softwaretools hufig nicht mglich.
Ein unbefugter Zugriff auf Faxdaten im Faxclient ist dann mglich, wenn ein unzureichender Schutz
des Arbeitsspeichers
Arbeitsplatzrechner bzw. die dort installierte Fax-Software nicht ausreichend
gesichert ist. Auch beim Zugriff auf die Festplatte des Arbeitsplatzrechners
knnen Informationen von Unbefugten ausgelesen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.33 Vortuschen eines falschen Absenders bei

Faxsendungen
So wie man einen Brief unter falschem Namen und mit falschem Briefkopf
schreiben kann, kann man auch ein entsprechend geflschtes Fax versenden.
Dadurch knnen Schden entstehen, wenn der Empfnger die darin enthal-
tenen Informationen als authentisch und ggf. als rechtsverbindlich ansieht
(vgl. G 3.14 Fehleinschtzung der Rechtsverbindlichkeit eines Fax).
Beispiele:
- Unterschriften knnen von anderen Schriftstcken eingescannt und auf die
Faxvorlage ausgedruckt bzw. beim Einsatz eines Faxservers als Grafikdatei
in das Schriftstck einkopiert werden. Auf dem empfangenen Fax ist kein
Unterschied zwischen einer so reproduzierten und einer authentischen
handschriftlichen Unterschrift erkennbar.
- Bei der bertragung wird in der Regel die Rufnummer des sendenden
Faxanschlusses bermittelt. Es ist jedoch mglich, eine andere Rufnummer
vorzutuschen. Daher ist auch die Auswertung des Empfangsprotokolls
keine verlssliche Besttigung des Absenders.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.34 Absichtliches Umprogrammieren der Zieltasten

eines Faxgertes
Um hufig wiederkehrende Empfnger-Faxnummern nicht stndig neu ein-
geben zu mssen, bieten einige Faxgerte programmierbare Zielnummern-
tasten an. Hufig werden die Empfngernummern beim Versenden des Fax
nicht einmal mehr kontrolliert. Kann ein Unbefugter die Programmierung der
Zieltasten ndern und veranlasst er dann noch, dass die bei der neuen Ziel-
adresse eingehenden Faxsendungen mglichst unverzglich zum berechtigten
Empfnger weitergeleitet werden, kann er bequem den Fax-Verkehr zu diesem
Empfnger mitverfolgen, ggf. ohne jemals entdeckt zu werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.35 berlastung durch Faxsendungen

Eine berlastung durch eingehende Faxsendungen kann entstehen, wenn nicht
gengend Faxanschlsse oder nicht gengend Telekommunikations-Leitungen
bzw. Kanle vorhanden sind. Darber hinaus kann ein Faxanschluss
absichtlich blockiert werden, indem
- andauernd umfangreiche Faxe (ggf. mit sinnlosem Inhalt) zugesandt
werden oder
- absichtlich solange Faxe zugesandt werden, bis der Papiervorrat eines
Faxgertes und der Pufferspeicher aufgebraucht sind.
Ein Faxserver kann ebenfalls berlastet werden, wenn solange Faxe berlastung durch
eingehende
zugesendet werden, bis der zur Verfgung stehende Platz auf der Festplatte Faxsendungen
ausgeschpft ist. Zu beachten ist aber, dass eine gefaxte Seite DIN A 4 etwa
70 kb gro ist. Bei heute blichen Festplattengren mssen dazu sehr viele
Faxsendungen dieser Art eingehen. Zudem muss bercksichtigt werden, dass
nur eine begrenzte Zahl an Leitungen bzw. Kanlen zur Verfgung steht und
jede Faxsendung auch fr die Abwicklung des Faxprotokolls Zeit bentigt.
Eine berlastung des Faxservers in diesem Sinne kann nur dann auftreten,
wenn eine zu klein dimensionierte Festplatte gewhlt wurde oder
Faxsendungen auf dem Faxserver archiviert werden.
Im Gegensatz zu herkmmlichen Faxgerten ist die berlastung eines berlastung durch
ausgehende
Faxservers durch ausgehende Faxsendungen durchaus mglich. So kann durch Faxsendungen
eine sehr groe Anzahl von Serien-Faxsendungen ein Faxserver vllig
ausgelastet werden und damit auch keine eingehenden Faxsendungen mehr
empfangen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.36 Absichtliche berlastung des

Anrufbeantworters
Es besteht die Mglichkeit fr einen Angreifer, das begrenzte Speicher-
medium (digitaler Speicher oder Audiokassette) whrend eines Anrufs (z. B.
mit unsinnigen Informationen) zu fllen, so dass weitere Aufzeichnungen
entweder nicht mehr mglich sind oder schon aufgezeichnete Nachrichten
verloren gehen (siehe dazu auch G 4.19 Informationsverlust bei erschpftem
Speichermedium).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.37 Ermitteln des Sicherungscodes

Nahezu alle modernen Anrufbeantworter verfgen ber die Anrufaufzeich-
nung hinaus noch ber eine Reihe zustzlicher Funktionen. Typische Beispiele
sind Fernabfrage, Umleitung eines Anrufes, Raumberwachung oder
Fernwirkung auf angeschlossene elektrische Gerte. Diese Funktionen lassen
sich ber Telefon whrend eines Anrufes am Anrufbeantworter fernsteuern
(bei Impulswahlverfahren ber einen zustzlichen Fernabfragesender, bei
Tonwahlverfahren direkt ber die Telefontastatur). Die Nutzung dieser
Fernabfrage- und Fernsteuerungsmglichkeit wird i. allg. durch einen Siche-
rungscode (Geheimzahl, PIN) geschtzt. Dieser Sicherungscode wird eben-
falls mittels des Fernabfragesenders durch Tne unterschiedlicher Frequenz an
den Anrufbeantworter bermittelt.
Wenn ein Dritter diesen Sicherungscode in Erfahrung gebracht hat, ist es ihm
mglich, ber die Fernsteuerung auf den Anfrufbeantworter Einfluss zu
nehmen, genauso als wre der Anrufbeantworter in seinem Besitz. Der ent-
stehende Schaden hngt davon ab, ob der Dritte schutzbedrftige Nachrichten
abhrt oder andere Leistungsmerkmale missbraucht.
Beispiel:
Es wurde berichtet, dass in letzter Zeit vermehrt die Sicherungscodes einiger
Anrufbeantworter ermittelt wurden, indem ein normaler Personalcomputer mit
Modem eingesetzt wurde, um innerhalb von kurzer Zeit smtliche nur
mglichen Zahlenkombinationen durchzuprobieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.38 Missbrauch der Fernabfrage

Ist einem Dritten der Sicherungscode eines Anrufbeantworters bekannt
geworden, kann er ber die Fernabfrage einen Groteil der im Anrufbe-
antworter implementierten Funktionen missbrauchen. Nachfolgend werden die
kritischsten Funktionen, die ber die Fernabfrage angesprochen und damit
missbraucht werden knnen, dargestellt:
- Raumberwachung
Die Funktion Raumberwachung aktiviert das Mikrofon des Anrufbe-
antworters und erlaubt so das Abhren des Raumes. Bemerkenswert
hierbei ist, dass die wenigsten Gerte dieses Abhren durch einen
Aufmerksamkeitston kenntlich machen - lediglich eine Anzeige mittels
Leuchtdiode ist Standard.
Wird diese Funktion missbruchlich bei Abwesenheit des Angerufenen
aktiviert, fllt die eingeschaltete Raumberwachung nach Rckkehr dem
Angerufenen nicht auf. Seine Gesprche innerhalb des Raumes knnen
dann unbemerkt abgehrt werden.
- Abhren oder Lschen gespeicherter Gesprche
Es knnen eingegangene Anrufe abgehrt und auch gelscht werden. Der
Schaden ist abhngig vom Schutzbedarf der aufgezeichneten Informa-
tionen.
- ndern oder Lschen des gespeicherten Ansagetextes
Bei einigen Gerten kann durch Fernabfrage eine Lschung des Ansage-
textes vorgenommen und damit Anrufbeantworter auer Betrieb gesetzt
werden. Durch gezielte Falschinformationen knnen Anrufer eventuell
verwirrt werden.
- nderung gespeicherter Rufnummern der Anrufmeldung oder
Anrufweiterschaltung
Das Leistungsmerkmal Anrufmeldung bewirkt, dass der Anrufbeantworter
nach Eingang eines Anrufes selbstndig eine vorher eingespeicherte Tele-
fonnummer anwhlt. Meldet sich der angerufene Teilnehmer, wird ein
bestimmtes Tonsignal bzw. ein Erinnerungstext durch den Anrufbeant-
worter gesendet und damit signalisiert, dass ein Anruf aufgezeichnet
wurde. Bei einzelnen Gerten werden die gespeicherten Nachrichten ohne
weitere Mitwirkung abgespielt. In der Regel jedoch muss die Wiedergabe
der aufgenommenen Anrufe durch Eingabe des Sicherungscodes aktiviert
werden. Das Leistungsmerkmal der Anrufweiterschaltung bewirkt, dass ein
Anrufer zu einer vorher eingespeicherten Telefonnummer weiterverbunden
wird.
Durch Abschaltung der Anrufmeldung oder Anrufweiterschaltung werden
die Funktionen nicht mehr ausgefhrt und der Benutzer wird von wichtigen
Anrufen nicht mehr in Kenntnis gesetzt bzw. ist nicht mehr erreichbar. Ein
Umprogrammieren dieser Funktionen gestattet es, Anrufe gezielt
umzuleiten, beispielsweise zu einem kostenpflichtigen Telefonansage-
dienst.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Vor- und Rckspulen eines Aufzeichnungsbandes

Einige analog aufzeichnende Anrufbeantworter erlauben das ferngesteuerte
Vor- und Rckspulen des Aufzeichnungsbandes. Durch Vorspulen bis ans
Bandende sind weitere Aufzeichnungen ausgeschlossen. Nach dem
Zurckspulen des Bandes werden bereits aufgesprochene Texte durch den
nchsten Anruf berspielt.
- Fernwirkmglichkeiten
Einige Gerte gestatten es, aus der Ferne ber den Anrufbeantworter elek-
trische Gerte zu steuern (Ein- und Ausschalten). Je nach Funktion und
Bedeutung der angeschlossenen Gerte kann dies beliebig hohen Schaden
nach sich ziehen.
- Abschalten des Gertes
Einige Gerte knnen ferngesteuert abgeschaltet werden, so dass die
Funktion des Anrufbeantworters nicht mehr zur Verfgung steht.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.39 Eindringen in Rechnersysteme ber

Kommunikationskarten
Eine Kommunikationskarte (z. B. eine ISDN-Karte oder ein internes Modem,
aber auch ein externes Modem) kann eingehende Anrufe automatisch ent-
gegennehmen. Abhngig von der eingesetzten Kommunikationssoftware und
deren Konfiguration besteht dann die Mglichkeit, dass ein Anrufer unbe-
merkt Zugriff auf das angeschlossene IT-System nehmen kann.
ber eine Kommunikationskarte kann ein externer Rechner als Terminal an
einen Server angeschlossen werden. Falls der Benutzer sich nach einer
Terminalsitzung abmeldet, aber die Leitung ansonsten bestehen bleibt, ist vom
externen Rechner ein Zugang wie ber ein lokales Terminal mglich. Damit
haben Dritte, die Zugang zu diesem Rechner haben, die Mglichkeit,
Benutzer-Kennungen und Passwrter zu testen. Wesentlich gefhrlicher ist der
Fall, dass die Verbindung unterbrochen wird, aber der Benutzer nicht auto-
matisch am entfernten System ausgeloggt wird. Dann kann der nchste
Anrufer unter dieser Benutzer-Kennung weiterarbeiten, ohne sich anmelden zu
mssen. Er hat somit vollen Zugriff auf das IT-System, ohne sich identifiziert
und authentisiert zu haben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.40 Abhren von Rumen mittels Rechner mit

Mikrofon
Viele IT-Systeme werden mittlerweile mit Mikrofon ausgeliefert. Das Mikro-
fon eines vernetzten Rechners kann von denjenigen benutzt werden, die ber
Zugriffsrechte auf die entsprechende Gertedateien verfgen (unter Unix ist
das zum Beispiel /dev/audio, unter Windows NT ist es ein Eintrag in der
Registrierung). Wenn diese Rechte nicht sorgfltig vergeben sind und dadurch
auch andere als die vorgesehenen Benutzer Zugriff haben, kann das Mikrofon
zum Abhren missbraucht werden.
Beispiel:
Im Mrz 2001 hat ein TV-Wirtschaftsmagazin gezeigt, wie ber das Mikrofon
eines Laptops ein Raum abgehrt werden kann, wenn der Rechner mit einer
ISDN-Telefonleitung verbunden ist. Dies wurde mit dem Laptop einer
deutschen Politikerin demonstriert. Zunchst wurde sie in einer geflschten
Virenwarnung per E-Mail aufgefordert, ein als Anlage mitgeschicktes
Schutzprogramm zu ffnen. Dieses Programm enthielt aber ein Trojanisches
Pferd, das spter ber die ISDN-Leitung eine Verbindung nach auen
herstellte und die Telefonnummer bermittelte.
Danach konnte der Rechner von auen angerufen werden, ohne dass der
Benutzer darber optisch oder akustisch informiert wurde. Anschlieend
wurde ber die offene Verbindung das eingebaute Mikrofon im Laptop
aktiviert und die Gerusche aus dem Bro nach auen bertragen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.41 Mibruchliche Nutzung eines Unix-Systems

mit Hilfe von uucp
Das Programmpaket UUCP (Unix-to-Unix Copy) erlaubt den Austausch von
ASCII- und Binrdateien zwischen IT-Systemen und die Ausfhrung von
Kommandos auf entfernten IT-Systemen. UUCP war ursprnglich auf Unix-
Systeme beschrnkt, ist aber mittlerweile auch fr viele andere Betriebs-
systeme verfgbar. Bei der Kommunikation ber UUCP werden IT-Benutzern
auf entfernten Rechnern Rechte auf dem lokalen Rechner eingerumt. Wenn
diese Rechte nicht sorgfltig und auf das Notwendige beschrnkt vergeben
werden, besteht die Gefahr der missbruchlichen Nutzung des lokalen
Systems. Denkbar ist auch eine Maskerade ber UUCP, indem z. B. ein Host -
bei Kenntnis des Passworts - vorgetuscht wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.42 Social Engineering

Social Engineering ist eine Methode, um nicht allgemein zugngliche Infor-
mationen durch "Aushorchen" zu erlangen. Oft gibt sich ein Angreifer bei
Gesprchen durch die Kenntnisse der richtigen Schlagworte als Insider zu
erkennen und erhlt so zustzliche Informationen, die an anderer Stelle aus-
genutzt werden knnen.
Das "Aushorchen" kann z. B. per Telefonanruf erfolgen, bei dem sich jemand
ausgibt:
- als Vorzimmerkraft, deren Vorgesetzter schnell noch etwas erledigen will,
aber sein Passwort vergessen hat und es jetzt dringend braucht,
- als Administrator, der wegen eines Systemfehlers anruft, da er zur Fehler-
behebung noch das Passwort des Benutzers bentigt,
- als Telefonentstrer, der einige technische Details wissen will, z. B. unter
welcher Rufnummer ein Modem angeschlossen ist und welche Einstel-
lungen es hat,
- als Externer, der gerne Herrn X sprechen mchte, der aber nicht erreichbar
ist. Die Information, dass Herr X drei Tage abwesend ist, sagt ihm auch
gleichzeitig, dass der Account von Herrn X in dieser Zeit nicht benutzt
wird, also unbeobachtet ist.
Wenn kritische Rckfragen kommen, ist der Neugierige angeblich "nur eine
Aushilfe" oder eine "wichtige" Persnlichkeit.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.43 Makro-Viren
Mit dem Austausch von Dateien (z. B. per Datentrger oder E-Mail) besteht
die Gefahr, dass neben der eigentlichen Datei (Textdatei, Tabelle etc.) weitere,
mit dem Dokument verbundene Makros bzw. eingebettete Editorkommandos
bersandt werden. Diese Makros laufen erst mit dem jeweiligen Anwen-
dungsprogramm (Winword, Excel etc.) bei der Bearbeitung des Dokuments
ab, indem der Benutzer das Makro aktiviert bzw. das Makro automatisch
gestartet wird. Wird ein Dokument ber einen WWW-Browser empfangen,
der das Dokument automatisch ffnet, kann hierdurch ein (Auto-) Makro
aktiviert werden.
Da die Makrosprachen ber einen sehr umfangreichen Befehlssatz verfgen,
besteht auch die Gefahr, dass einem Dokument ein Makro beigefgt wird, das
eine Schadfunktion enthlt (z. B. einen Virus).
In der Praxis hat diese Gefhrdung insbesondere bei den Dateien der Pro-
gramme Word fr Windows und Excel der Firma Microsoft weltweit
betrchtlich zugenommen. Fr den Benutzer ist dabei nicht transparent, dass
Dateien fr Word-Vorlagen (*.DOT), in denen Makros enthalten sein knnen,
durch Umbenennen in *.DOC-Dateien scheinbar zu Datendateien werden, die
keine Makros enthalten. Von Microsoft Word werden solche Dateien jedoch
ohne Hinweis auf diese Tatsache in nahezu gleicher Weise verarbeitet
(Ausnahme: Winword ab Version 7.0a).
Die Word-Makro-Viren haben inzwischen die Spitzenstellung bei gemeldeten
Infektionen eingenommen. Hervorzuheben ist, dass Makro-Viren auf ver-
schiedenen Betriebssystem-Plattformen auftreten knnen, nmlich auf allen,
auf denen Winword luft (Windows Versionen 3.1 und 3.11, Windows 95,
Windows NT, Apple-Computer).
Beispiel:
Der Winword-Makro-Virus "Winword.Nuclear" wurde im Internet ber die
Datei WW6ALERT.ZIP verbreitet. Der Makro-Virus bewirkt einerseits, dass
an Ausdrucken der Text "STOP ALL FRENCH NUCLEAR TESTIN IN
PACIFIC!" angehngt wird, andererseits aber auch den Versuch,
Systemdateien zu lschen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Managementfunktionen von TK-Anlagen
TK-Anlagen verfgen ber Remote-Zugnge fr Managementfunktionen.
ber diese Zugnge knnen alle Administrations- und Wartungsttigkeiten
sowie sonstige Managementfunktionalitten wie z. B. Alarmsignalisierung
und -bearbeitung abgewickelt werden.
Solche Remote-Zugnge sind besonders in TK-Anlagen-Verbnden
(Corporate Networks) ntzlich und teilweise unverzichtbar. Bei der Art des
Remote Zuganges lsst sich zwischen
- "Modem"-Zugang ber dedizierte Managementports und
- direkte Einwahl ber DISA (Direct Inward System Access)
unterscheiden. Desweiteren sind in neueren Protokollierungsverfahren wie
QSig und einigen anderen proprietren Protokollen Managementfunktionen
bereits im Signalisierungsspektrum enthalten. Hieraus ergeben sich potentielle
Missbrauchsmglichkeiten.
Bei unzureichend gesicherten Fernwartungszugngen ist es denkbar, dass
Hacker Zugang zu den Managementprogrammen des TK-Systems erlangen.
Sie knnen somit nach berwindung des Anlagenpasswortes ggf. alle
Administrationsttigkeiten ausben. Der entstehende Schaden kann sich vom
vollstndigen Anlagenausfall, ber schwerste Betriebsstrungen, den Verlust
der Vertraulichkeit aller auf der Anlage vorhandenen Daten bis hin zum
groen direkten finanziellen Schaden z. B. durch Gebhrenbetrug erstrecken.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.45 Ausprobieren von Passwrtern unter WfW und

Windows 95
In einem Peer-to-Peer-Netz unter WfW und Windows 95 werden Zugriffs-
rechte zu Verzeichnissen durch die Vergabe von Passwrtern realisiert. Es
findet keine Unterscheidung einzelner Benutzer statt. Der Zugriff auf ein frei-
gegebenes Verzeichnis und die darin gespeicherten Dateien wird lediglich bei
der Eingabe eines korrekten Passwortes erlaubt. Dies gilt nicht beim Einsatz
von Windows 95 in Netware-Netzen. Unter WfW und Windows 95 ist es
daher prinzipiell mglich, die Zugriffspawrter zu freigegebenen Verzeich-
nissen durch Ausprobieren zu ermitteln. Da keine Beschrnkung der Anzahl
von Fehlversuchen bei der Passworteingabe existiert, kann dies mittels einer
gewissen Systematik Erfolg versprechend sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.46 Maskerade unter WfW

Da jeder Benutzer eines WfW-Rechners den Rechner- und Anmeldenamen
ndern kann, ist WfW nicht in der Lage, Benutzer zuverlssig zu identifi-
zieren. Maskerade ist daher leicht mglich. Damit kann ein potentieller
Angreifer unter falschem Namen auf seinem Rechner ein Verzeichnis fr alle
am Netz unter WfW arbeitenden Mitarbeiter freigeben, in dem sich
Schadprogramme befinden. Er kann auch versuchen, sich unberechtigt Zugriff
auf Verzeichnisse anderer zu verschaffen. Der Geschdigte wird ber den
wahren Verursacher getuscht. Ebenso kann ein Angreifer Kommunikation in
WfW (z. B. ber die Telefonfunktion) in einfacher Weise unter falschem
Namen fhren und den Empfnger ber die Identitt des tatschlichen
Absenders tuschen. Auch ist es mglich, die Anmeldung eines bestimmten
Rechners unter WfW zu verhindern, indem man sich unter dessen Namen
zeitlich vor diesem unter WfW anmeldet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.47 Lschen des Post-Office unter WfW

Wird von mehreren Benutzern unter dem WfW-Programm mail ein
gemeinsames Post-Office genutzt, kann dieses unter Umgehung aller WfW-
Sicherheitsfunktionen unberechtigt gelscht werden, wenn zu einem dem
Post-Office bekannten Rechner kein ausreichender Zugangsschutz (z. B. ber
ein BIOS-Passwort) gewhrleistet ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.48 IP-Spoofing
IP-Spoofing ist eine Angriffsmethode, bei der falsche IP-Nummern verwendet
werden, um dem angegriffenen IT-System eine falsche Identitt vorzuspielen.
Bei vielen Protokollen der TCP/IP-Familie erfolgt die Authentisierung der
kommunizierenden IT-Systeme nur ber die IP-Adresse, die aber leicht
geflscht werden kann. Nutzt man darber hinaus noch aus, dass die von den
Rechnern zur Synchronisation beim Aufbau einer TCP/IP-Verbindung
benutzten Sequenznummern leicht zu erraten sind, ist es mglich, Pakete mit
jeder beliebigen Absenderadresse zu verschicken. Damit knnen entsprechend
konfigurierte Dienste wie rlogin benutzt werden. Allerdings muss ein
Angreifer dabei u. U. in Kauf nehmen, dass er kein Antwortpaket von dem
missbruchlich benutzten Rechner erhlt.
Weitere Dienste, die durch IP-Spoofing bedroht werden, sind rsh, rexec, X-
Windows, RPC-basierende Dienste wie NFS und der TCP-Wrapper, der
ansonsten ein sehr sinnvoller Dienst zur Einrichtung einer Zugangskontrolle
fr TCP/IP-vernetzte Systeme ist. Leider sind auch die in Schicht 2 des OSI-
Modells eingesetzten Adressen wie Ethernet- oder Hardware-Adressen leicht
zu flschen und bieten somit fr eine Authentisierung keine zuverlssige
Grundlage.
In LANs, in denen das Address Resolution Protocol (ARP) eingesetzt wird,
sind sehr viel wirkungsvollere Spoofing-Angriffe mglich. ARP dient dazu,
zu einer 32-Bit groen IP-Adresse die zugehrige 48-Bit groe Hardware-
oder Ethernet-Adresse zu finden. Falls in einer internen Tabelle des Rechners
kein entsprechender Eintrag gefunden wird, wird ein ARP-Broadcast-Paket
mit der unbekannten IP-Nummer ausgesandt. Der Rechner mit dieser IP-
Nummer sendet dann ein ARP-Antwort-Paket mit seiner Hardware-Adresse
zurck. Da die ARP-Antwort-Pakete nicht manipulationssicher sind, reicht es
dann meist schon, die Kontrolle ber einen der Rechner im LAN zu bekom-
men, um das gesamte Netz zu kompromittieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.49 Missbrauch des Source-Routing

Der Missbrauch des Routing-Mechanismus und -Protokolls ist eine sehr ein-
fache protokoll-basierte Angriffsmglichkeit. In einem IP-Paket lsst sich der
Weg, auf dem das Paket sein Ziel erreichen soll oder den die Antwortpakete
nehmen sollen, vorschreiben. Die Wegbeschreibung kann aber whrend der
bertragung manipuliert werden, so dass nicht die durch die Routing Eintrge
vorgesehenen sicheren Wege benutzt werden (z. B. ber die Firewall), sondern
andere unkontrollierte Wege.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.50 Missbrauch des ICMP-Protokolls

Das Internet Control Message Protocol (ICMP) hat als Protokoll der Trans-
portschicht die Aufgabe, Fehler- und Diagnoseinformationen zu trans-
portieren. Durch Missbrauch von ICMP-Nachrichten kann ein Angreifer
sowohl den Netzbetrieb stren als auch Informationen ber das interne Netz
herausfinden, die ihm bei der Planung eines Angriffs ntzen:
- Durch ICMP-Redirect Nachrichten knnen die Routing-Tabellen von
Rechnern manipuliert werden.
- ICMP-Unreachable Nachrichten knnen dazu benutzt werden, bestehende
Verbindungen zu stren oder ganz zu unterbrechen.
- Die verschiedenen ICMP-Request Nachrichtentypen (Echo Request,
Information Request, Timestamp Request, Address Mask Request) knnen
auf einfache Weise dazu benutzt werden, das interne Netz einer
Organisation zu "kartographieren" (ICMP Sweeps).
- Auch geflschte ICMP-Reply Nachrichten knnen dazu benutzt werden,
um Informationen ber das interne Netz herauszufinden, indem sie die
Zielrechner dazu bewegen, auf diese mit einer Fehlermeldung zu
antworten.
- Verschiedene Betriebssysteme unterscheiden sich in der Art und Weise,
wie sie auf bestimmte ICMP-Nachrichten reagieren. Neben der
Information darber, dass eine bestimmte Adresse aktiv ist knnen ICMP-
Antworten daher auch verraten, unter welchem Betriebssystem der
betreffende Rechner luft (Fingerprinting).
- Fehlerhafte Implementierungen von ICMP in einigen Betriebssystemen
haben in der Vergangenheit zu Sicherheitsproblemen gefhrt:
- Rechner mit Windows 95 konnten durch bestimmte ICMP-Echo
Pakete ("Ping of Death") zum Absturz gebracht werden.
- In ICMP-Antwortpaketen verschiedener Betriebssysteme konnten
Ausschnitte aus dem Arbeitsspeicher des betreffenden Rechners
enthalten sein. Im Extremfall knnten auf diese Weise Passwrter
oder kryptographische Schlssel an einen externen Rechner
bermittelt werden.
- Jede Art von ICMP-Nachrichten kann auch dafr benutzt werden, einen
verdeckten Informationskanal zu schaffen, auf dem Daten aus dem internen
Netz nach drauen zu transportiert werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.51 Missbrauch der Routing-Protokolle

Routing Protokolle wie RIP (Routing Information Protocol) oder OSPF (Open
Shortest Path First) dienen dazu, Vernderungen der Routen zwischen zwei
vernetzten Systemen an die beteiligten Systeme weiterzuleiten und so eine
dynamische nderung der Routing-Tabellen zu ermglichen. Es ist leicht
mglich, falsche RIP-Pakete zu erzeugen und somit unerwnschte Routen zu
konfigurieren.
Der Einsatz von dynamischem Routing ermglicht es, Routing-Informationen
an einen Rechner zu schicken, die dieser in der Regel ungeprft zum Aufbau
seiner Routing-Tabellen benutzt. Dies kann ein Angreifer ausnutzen, um
gezielt den bertragungsweg zu verndern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.52 Missbrauch von Administratorrechten im

Windows NT/2000 System
Eine missbruchliche Administration liegt vor, wenn vorstzlich recht- oder
unrechtmig erworbene Administratorberechtigungen und -rechte ausgenutzt
werden, um dem System oder dessen Benutzer zu schaden.
Beispiel:
-Durch missbruchliche Nutzung des Rechtes zur Besitzbernahme beliebiger Besitzbernahme
beliebiger Dateien
Dateien kann sich ein Administrator unter Windows NT/2000 Zugriff auf
beliebige Dateien verschaffen, obwohl deren Eigentmer ihm diesen Zugriff
explizit durch entsprechende Zugriffskontrollen verwehrt haben. Eine
Zugriffsbernahme kann allerdings vom ursprnglichen Eigentmer der
Dateien erkannt werden, da der Administrator sich hierbei zum Besitzer der
betreffenden Dateien machen muss und unter Windows NT/2000 keine Funk-
tion verfgbar ist, um diese nderung wieder rckgngig zu machen. Trotz-
dem kann der Administrator unbemerkt auf Benutzerdateien zugreifen, in dem
er sich z. B. in die Gruppe Sicherungs-Operatoren eintrgt und ein Backup der
Dateien durchfhrt, die er lesen will.
-Es gibt verschiedene Mglichkeiten, missbruchlich Administratorrechte Flschung von
Protokolldaten
auszunutzen. Dazu gehren unzulssige Zugriffe auf Dateien, Vernderungen
der Protokollierungseinstellungen und der Vorgaben fr Benutzerkonten.
Andere Mglichkeiten des Missbrauchs bestehen in der Flschung von Proto-
kollinformationen durch Verstellen der Systemzeit oder in der detaillierten
Verfolgung der Ttigkeiten einzelner Benutzer.
-In Abhngigkeit von der zugrunde liegenden Hardware kann bei Zugangs- Booten von
Fremdmedien
mglichkeit zur Konsole bzw. zum Systemgehuse das System gebootet
werden. Dies ermglicht ggf. die Manipulation der Konfiguration, wenn hier-
bei von einem Fremdmedium gebootet oder ein anderes Betriebssystem aus-
gewhlt werden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.53 Bewusste Fehlbedienung von Schutzschrnken

aus Bequemlichkeit
Eine hufig festzustellende Form der absichtlichen Fehlbedienung von
Schutzschrnken mit mechanischen Codeschlssern besteht darin, nach
Schlieen eines Schutzschrankes den Code nicht zu verwerfen, um den Code
beim ffnen nicht wieder eingeben zu mssen. Dieses Fehlverhalten reduziert
den Schutzwert des Schrankes gegen unbefugten Zugriff, da hierdurch einem
Dritten das ffnen des Schutzschrankes ohne Kenntnis des Codes ermglicht
wird.
Ebenso hufig anzutreffen ist der Umstand, dass Schutzschrnke bei kurz-
fristigem Verlassen des Raumes nicht verschlossen werden, um sich das
ffnen des Schrankes nach Rckkehr zu ersparen. Dies reduziert ebenfalls den
Schutzwert gegen unbefugten Zugriff.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.54 Vorstzliches Herbeifhren eines Abnormal End

Ein Netware ABEND (Abnormal End) wird hervorgerufen, wenn das Netware
Betriebssystem aufgrund von Hard- und/oder Softwareproblemen nicht mehr
in der Lage ist, Netzprozesse ordnungsgem weiterzufhren bzw. zu steuern.
Der Fileserver wird in diesen Fllen gestoppt und muss neu gestartet werden.
Hat ein Angreifer Zugriff auf die Konsole des Novell Netware Servers, so
kann ein Netware ABEND durch die Eingabe bestimmter Parameter vorstz-
lich herbeigefhrt werden.
Der ABEND eines Novell Netware Servers kann sogar von jedem, der Zugriff
auf das Netz hat, herbeigefhrt werden, ohne das ein autorisiertes Login auf
dem Novell Netware Server erfolgen muss. Durch den Aufruf des Programms
SYS:\PUBLIC\RENDIR.EXE mit zustzlichen Parametern kann jede Work-
station im Status "Attached" den ABEND eines Novell Netware Servers
provozieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.55 Login Bypass

Die Login-Scripts (System-Login-Script, User-Login-Script) eines Novell
Netware Servers erstellen, nach erfolgter Anmeldung am Novell Netware
Server, die persnliche Netzumgebung fr den Benutzer.
Durch die Verwendung von Optionen beim Ausfhren von LOGIN.EXE unter
Novell Netware werden weder das System-Login-Script noch das User-Login-
Script des ausgewhlten Novell Netware Servers ausgefhrt. Sicher-
heitseinstellungen die in die Login-Scripts implemetiert wurden werden somit
umgangen. Hierdurch ist es dem Benutzer nach dem autorisierten Login
mglich, sich mit Hilfe des Map Kommandos unabhngig von den in den
Login-Scripts (System-Login-Script, User-Login-Script) festgelegten Para-
metern auf dem Novell Netware Server zu "bewegen". In Verbindung mit
einer unzureichenden Rechtevergabe kann dies dazu fhren, dass Informa-
tionen, die nicht fr den Benutzer zugnglich sein sollen, diesem zugnglich
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.56 Temporr frei zugngliche Accounts

Bei der Einrichtung eines neuen User-Accounts wird dieser standardmig
ohne Passwort eingerichtet. Von Seiten des Netzbetriebssystems besteht hier-
bei keinerlei Zwang, ein Passwort zu vergeben, obwohl dieses in den
Standardeinstellungen ("Default Account Balance/Restrictions") eingestellt
werden kann. Diese neu eingerichteten Accounts sind somit fr jederman frei
zugnglich, ohne dass eine Passwortabfrage erfolgt. Die Gefhrdung des soge-
nannten "race on new accounts" ist hierbei umso hher einzuschtzen, je
privilegierter der neue Account auf dem Novell Netware Server ist.
In diesem Zusammenhang wird darauf hingewiesen, dass verschiedene Ver-
sionen (z. B. Vers. 3.75, Vers. 3.76) des Netware Utilities
SYS:\PUBLIC\SYSCON.EXE bei der Vergabe eines neuen Passwortes durch
einen Systemverwalter dieses Passwort unverschlsselt ber das Netz ber-
tragen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.57 Netzanalyse-Tools
Werden die im Netzsegment bertragenen Informationen nicht verschlsselt,
so knnen diese Informationen mit Hilfe von Netzanalyse-Tools, den soge-
nannten "Sniffern", im Klartext ausgelesen werden. Hierbei ist auch zu beach-
ten, dass diese "Sniffer" keineswegs immer als "Hackingsoftware" betrachtet
werden knnen, da viele Produkte, die dem Management des Netzes dienen,
eine derartige Funktion beinhalten.
Trace-Funktionen des z/OS-Betriebssystems
Unter z/OS stehen dem Bediener sogenannte Trace-Funktionen zur Ver- Trace-Funktionen unter
z/OS
fgung. Mit Hilfe der Generalized Trace Facility (GTF) lassen sich in SNA-
oder TCP/IP-Netzen unter anderem Terminal-Sessions berwachen. Wird die
Trace-Funktion auf die Session des RACF-Administrators angewandt, kann
unter Umstnden dessen Passwort ermittelt werden, wenn die Inhalte der
Session nicht verschlsselt sind. Eine hnliche Trace-Funktion ist in der
Network Logical Data Manager-Komponente (NLDM) des Produktes NetView
enthalten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.58 "Hacking Novell Netware"

"Hacking Novell Netware" kann prinzipiell auf zwei Arten durchgefhrt wer-
den.
Zum einen kann, ausgehend von einer Workstation, eine gezielte Attacke
gegen einen User Account erfolgen, um dessen Passwort in Erfahrung zu
bringen.
Die gezielte Attacke gegen einen User Account kann hierbei ber einen soge-
nannten Brute Force Angriff erfolgen, bei dem eine Workstation (Status: At-
tached) Login-Versuche unter einem zuvor festgelegten User Account durch-
fhrt und hierbei mit Hilfe eines Algorithmus oder eines mitgelieferten
Wrterbuches Passwrter generiert bzw. ausprobiert.
Mit Hilfe des Programms HACK.EXE kann ein autorisierter Benutzer einen
Angriff gegen den Account des Supervisors durchfhren. Es kann, eine
Schwachstelle im Betriebssystem ausnutzend, alle Benutzer des Novell Net-
ware Servers in einen Supervisor-quivalenten Zustand versetzten, den Super-
visor ausloggen sowie dessen Passwort verndern, vorausgesetzt der Account
des Supervisors ist zum Zeitpunkt der Aktivierung von HACK.EXE auf dem
Novell Netware Server eingeloggt.
Weiterhin kann eine Attacke durch eine direkte Manipulation am Server
durchgefhrt werden, um beispielsweise einen Supervisor-quivalenten
Account zu generieren.
Durch das Einspielen und Aktivieren von NLMs (Netware Loadable
Modules), die als Notfalltools entwickelt worden sind, besteht beispielsweise
die Mglichkeit, einen speziellen Benutzer zu erzeugen, dessen Rechte auf
dem Novell Netware Server quivalent zu denen des Supervisors sind.
Diese Tools, wie z. B. SETPWD.NLM, arbeiten auch in Netware 4 Netzen.
Deshalb sei an dieser Stelle noch einmal auf M 1.42 Gesicherte Aufstellung
von Novell Netware Servern hingewiesen.
Die meisten dieser Programme sind frei ber das Internet erhltlich. Sie sind,
hinsichtlich ihrer Handhabung, auch von "Computer-Laien" zu bedienen, da
sie keine spezifischen Novell Netware Kenntnisse erfordern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.59 Missbrauch von Administratorrechten unter

Novell Netware 3.x
Der Supervisor Account bzw. ein Supervisor-quivalenter Account besitzt, mit
Ausnahme der Bindery Informationen (z. B. Passwrter), die vollstndige
Kontrolle ber einen Novell Netware Server.
Hierdurch ist es einem Account der Sicherheitsstufe "Supervisor" mglich, auf
alle gespeicherten Informationen des Servers zuzugreifen, wenn diese nicht
durch zustzliche Sicherheitsmechanismen, wie z. B. Verschlsselung
geschtzt werden. Damit haben autorisierte Benutzer dieser Accounts die
Mglichkeit, Daten anderer Benutzer zu lesen, zu lschen bzw. zu verndern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.60 Umgehen der Systemrichtlinien

Besteht lokaler Zugang zu einem nicht vernetzten PC unter Windows 95, ist es
mglich, die Passwortdatei (name.PWL), die zu einer bestimmten Benutzer-
Kennung gehrt, zu lschen. Der Zugang mit dieser Benutzer-Kennung ist
dann ohne Kenntnis des Benutzer-Passwortes mglich. Dies ist insbesondere
dann kritisch, wenn ein nicht vernetzter Windows 95-Rechner durch
Systemrichtlinien fr bestimmte Benutzer eingeschrnkt ist, aber eine
Administrator-Kennung (z. B. ADMIN) existiert, die alle Rechte besitzt.
Durch lschen der ADMIN.PWL durch einen auf diesem PC eingeschrnkten,
aber dennoch berechtigten Benutzer kann dieser sich anschlieend als
Administrator anmelden. Die fr den Benutzer eingestellten Einschrnkungen
bzw. Systemrichtlinien werden somit umgangen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Managementfunktionen von Routern
Router verfgen ber Remote-Zugnge fr Managementfunktionen. ber
diese Zugnge knnen alle Administrations- und Wartungsttigkeiten sowie
Signalisierungsfunktionalitten abgewickelt werden. Solche Remote-Zugnge
sind besonders in greren Netzen mit mehreren Routern bzw. bei der LAN-
Kopplung ber Weitverkehrsnetze ntzlich und teilweise unverzichtbar.
Bei der Art des Remote-Zugangs lsst sich unterscheiden zwischen:
- "Modem"-Zugang ber dedizierte Schnittstelle (z. B. V.24) und
- direkter Zugang ber reservierte Bandbreiten.
Wird fr das Netzmanagement das Protokollverfahren SNMP (Simple
Network Management Protocol) eingesetzt, ergeben sich aufgrund fehlender
bzw. noch nicht umgesetzter Sicherheitsfunktionalitten weitere Gefhr-
dungen, die ber den direkten Missbrauch der ungeschtzten Remote-Schnitt-
stellen hinausgehen:
- Ein nicht autorisierter Benutzer fngt Datenpakete einer SNMP-Manage-
ment-Station ab und verndert die darin enthaltenen Parameterwerte fr
seine Zwecke. Nach dieser Manipulation werden die manipulierten Daten-
pakete zur eigentlichen Zielstation gesendet. Das Empfngergert hat keine
Mglichkeit, diese Datenmanipulation zu erkennen und reagiert deshalb
auf die im Paket enthaltenen Informationen so, als ob diese von der
Management-Station direkt abgesandt worden wren.
- Erhlt der Besitzer einer Netzmanagement-Station Zugang zum mittels
SNMP verwalteten Netz, ist das Vorspiegeln einer Community
(Verwaltungsbereich innerhalb von SNMP) mglich. Durch diese
Maskerade tuscht ein nicht autorisierter Benutzer eine autorisierte
Identitt vor und kann alle Informationen der Agents (im Netz zu
verwaltende Objekte, bspw. Router) auslesen sowie smtliche
Managementoperationen durchfhren. Der Agent hat keine Mglichkeit
zwischen der richtigen und der falschen Identitt zu unterscheiden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.62 Missbrauch von Ressourcen ber abgesetzte IT-

Systeme
Abgesetzte IT-Systeme (z. B. Telearbeitspltze) knnen meist auf vielfltige
Ressourcen eines unternehmensweiten Netzes zugreifen. Grundstzlich
besteht deshalb immer die Gefahr des Daten- und Programmdiebstahls.
Bestehen zu einem Unternehmensnetz auch Zugriffsmglichkeiten von abge-
setzten IT-Systemen (z. B. Telearbeitspltzen), besteht grundstzlich die
Gefahr, dass in dem Unternehmensnetz angebotenen Dienstleistungen
missbraucht werden knnen. Die Bereitstellung von Kommunikationsservern
im Netz (z. B. Fax-Gateway, Internet-Anbindung usw.) kann bei einer nicht
erlaubten privaten Nutzung zu einem Gebhrenbetrug fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.63 Manipulationen ber den ISDN-D-Kanal

Die Summe aller physikalischen Verbindungen der Kommunikationsteil-
nehmer zu einer ihnen zugeordneten digitalen Vermittlungsstelle bezeichnet
man als Anschlussnetz. Innerhalb des Anschlussnetzes existieren zahlreiche
Verteiler und bergabepunkte, die teilweise frei zugnglich und nicht auf-
wendig gesichert sind (z. B. Kabelverzweiger). Die Kommunikation auf dem
Anschlussnetz kann im einfachsten Fall durch das mechanische Beschdigen
einer Anschlussleitung unterbrochen werden.
Weiterhin ist es mit Hilfe eines ISDN-Protokollanalysators mglich,
Kommunikationsinhalte aufzuzeichnen und auszuwerten. Mittels Einschleifen
eines Protokollanalysators ist ebenfalls das Manipulieren von Steuerungs-
informationen im D-Kanal des ISDN mglich. Die Kommunikationskom-
ponenten des angegriffenen Kommunikationsteilnehmers (also ISDN-Karten,
ISDN-Router, TK-Anlagen etc.) knnen so zu Reaktionen veranlasst werden,
die ihren ordnungsgemen Betrieb beeintrchtigen oder zur Kompromittie-
rung gespeicherter Daten fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.64 Manipulation an Daten oder Software bei

Datenbanksystemen
Durch ein gezieltes Manipulieren von Daten werden diese vorstzlich
verflscht oder unbrauchbar gemacht. Die entsprechenden Folgen sind in
G 4.28 Verlust von Daten einer Datenbank und G 4.30 Verlust der
Datenbankintegritt/-konsistenz beschrieben.
Werden die Dateien einer Datenbank oder der Datenbank-Standardsoftware
gezielt gelscht oder verndert, so fhrt dies zur vorstzlichen Zerstrung des
gesamten Datenbanksystems (siehe G 4.26 Ausfall einer Datenbank).
Es ist prinzipiell nicht verhinderbar, dass Benutzer mit den entsprechenden
Zugangs- und Zugriffsberechtigungen gezielt Datenmanipulationen durch-
fhren oder eine Datenbank zerstren knnen. Ist es auerdem mglich, die
Zugangs- und Zugriffsberechtigungen zu umgehen (z. B. durch eine fehler-
hafte Administration des DBMS), so knnen sich auch unberechtigte Benutzer
Zugang zur Datenbank verschaffen und dort Manipulationen vornehmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.65 Verhinderung der Dienste eines

Datenbanksystems
Ein solcher Angriff zielt darauf ab, die IT-Benutzer daran zu hindern, die
Funktionen und Dienste eines Datenbanksystems benutzen zu knnen, die
ihnen normalerweise zur Verfgung stehen. Neben den in G 5.28 Verhinde-
rung von Diensten aufgefhrten Beispielen, kann dies im Bereich Daten-
banken zustzlich z. B. dadurch erreicht werden, dass groe Datenmengen
selektiert werden, deren Auswertung das gesamte Datenbanksystem lahmlegt,
oder dass die Datenstze durch Sperren blockiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.66 Unberechtigter Anschluss von IT-Systemen an

ein Netz
Grundstzlich kann der unberechtigte Anschluss eines IT-Systems in ein
bestehendes Netz (durch ein Aufschalten auf die zugehrige Verkabelung oder
durch die Nutzung von Schnittstellen in Verteiler- oder Brorumen) nicht
verhindert werden. Es gibt keinen Verkabelungstyp, der ein solches
Ankoppeln verhindern wrde, lediglich der erforderliche Aufwand zum
Auftrennen der Verkabelung und zum Lesen bzw. Einspielen von Daten
unterscheidet die verschiedenen Typen.
Die unberechtigte Integration eines Rechners in ein Netz ist nur sehr schwer
zu entdecken und bleibt meistens unbemerkt. Ein solcher Zugriff betrifft den
gesamten Netzverkehr in dem zugehrigen Segment und kann z. B.
- die Manipulation an Daten oder Software,
- das Abhren von Leitungen,
- die Manipulation an Leitungen,
- das Wiedereinspielen von Nachrichten,
- die Maskerade als anderer Kommunikationsteilnehmer,
- eine Analyse des Nachrichtenflusses,
- die Verhinderung von Diensten,
- die unberechtigte Ausfhrung von Netzmanagement-Funktionen oder
- den unberechtigten Zugang zu den aktiven Netzkomponenten
begnstigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.67 Unberechtigte Ausfhrung von

Netzmanagement-Funktionen
Durch die unberechtigte Ausfhrung von Netzmanagement-Funktionen
knnen aktive Netzkomponenten teilweise oder vollstndig kontrolliert
werden. Die Kontrollmglichkeiten werden u. a. durch das verwendete
Netzmanagement-Protokoll, wie z. B. SNMP oder CMIP/CMOT bestimmt.
Daraus kann ein Verlust der Netzintegritt, der Verfgbarkeit einzelner oder
aller Netzbestandteile sowie der Vertraulichkeit bzw. Integritt von Daten
resultieren.
Unter Verwendung eines Serviceprotokolls, wie z. B. SNMP, knnen
dedizierte Ports aktiver Netzkomponenten aktiviert oder insbesondere auch
deaktiviert werden. Weiterhin knnen z. B. die VLAN-Konfiguration,
Routing-Tabellen, die Router-Konfiguration sowie die Konfiguration von
Filtern manipuliert werden (siehe G 3.28 Ungeeignete Konfiguration der
aktiven Netzkomponenten). Daneben kann die Mglichkeit einer Verteilung
von Firmware-Updates ber das Netz genutzt werden, um unberechtigt Soft-
ware auf aktiven Netzkomponenten zu installieren, mit deren Untersttzung
wiederum vielfltige Angriffe auf Komponenten innerhalb des Netzes durch-
gefhrt oder untersttzt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.68 Unberechtigter Zugang zu den aktiven

Netzkomponenten
Aktive Netzkomponenten haben blicherweise eine serielle Schnittstelle (RS-
232), an die von auen ein Terminal oder ein tragbarer PC angeschlossen
werden kann. Dadurch ist es mglich, aktive Netzkomponenten auch lokal zu
administrieren.
Bei unzureichend gesicherten Schnittstellen ist es denkbar, dass Angreifer
einen unberechtigten Zugang zur Netzkomponente erlangen. Sie knnen somit
nach berwindung der lokalen Sicherheitsmechanismen (z. B. des
Passwortes) ggf. alle Administrationsttigkeiten ausben.
Dabei knnen durch das Auslesen der Konfiguration aktiver Netzkompo-
nenten ggf. schutzbedrftige Informationen ber die Topologie, die Sicher-
heitsmechanismen und die Nutzung eines Netzes in Erfahrung gebracht
werden. Ein Auslesen der Konfigurationsdaten ist z. B. durch den Anschluss
eines Terminals oder tragbaren PCs an die serielle Schnittstelle der aktiven
Netzkomponente, durch den Zugriff auf die aktive Netzkomponente ber das
lokale Netz oder durch das Mitlesen der Daten auf einem Bildschirm oder
Display mglich, falls die aktive Netzkomponente gerade administriert bzw.
konfiguriert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.69 Erhhte Diebstahlgefahr am huslichen

Arbeitsplatz
Der husliche Arbeitsplatz ist in der Regel nicht so abgesichert wie der
Arbeitsplatz in einem Unternehmen oder einer Behrde. Dort ist, bedingt
durch aufwendigere Vorkehrungen (Verwendung von Sicherheitstren,
Einbruchschutz, Pfrtnerdienst usw.) die Gefahr, dass jemand in das Gebude
unbefugt eindringt, weit geringer als bei einem Privathaus.
Einbruch und Diebstahl im Privathaus dienen meist der Bereicherung. Dabei
gestohlene dienstliche IT wird mit dem Ziel der Veruerung gestohlen. Die
mitentwendeten Daten knnen ggf. auch einen Wert darstellen, der zum
Beispiel durch Erpressung oder Informationsweitergabe an Konkurrenzunter-
nehmen realisiert werden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.70 Manipulation durch Familienangehrige und

Besucher
Am huslichen Arbeitsplatz ist mit Angehrigen und Besuchern der Familie
zu rechnen, so dass die Gefahr besteht, dass bei unzureichender Sicherung die
dienstliche IT durch diese manipuliert werden kann. So sollte auch betrachtet
werden, dass durch Familienangehrige private Software (z. B. Computer-
spiele) aufgespielt werden knnte, dass durch Kinder die IT zerstrt werden
kann oder dass dienstliche Datentrger zweckentfremdet weitergegeben
werden knnen. Diese teils fahrlssigen oder auch absichtlichen Manipu-
lationen knnen sowohl die Vertraulichkeit und Integritt der dienstlichen
Daten betreffen als auch die Verfgbarkeit von Daten und IT beeintrchtigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.71 Vertraulichkeitsverlust schtzenswerter

Informationen
Fr Informationen, die einen Schutzbedarf bezglich ihrer Vertraulichkeit
besitzen (wie Passwrter, personenbezogene Daten, firmen- oder amtsver-
trauliche Informationen, Entwicklungsdaten), besteht die inhrente Gefahr,
dass die Vertraulichkeit durch Unachtsamkeit oder auch durch vorstzliche
Handlungen beeintrchtigt wird. Dabei kann auf diese vertraulichen Informa-
tionen an unterschiedlichen Stellen zugegriffen werden, beispielsweise
- auf Speichermedien innerhalb von Rechnern (Festplatten),
- auf austauschbaren Speichermedien (Disketten, Magnetbnder),
- in gedruckter Form auf Papier (Ausdrucke, Akten) und
- auf bertragungswegen whrend der Datenbertragung.
Auch die Art und Weise, wie die vertraulichen Informationen gewonnen
werden, kann sehr unterschiedlich sein:
- Auslesen von Dateien,
- Kopieren von Dateien,
- Wiedereinspielen von Datensicherungsbestnden,
- Diebstahl des Datentrgers und anschlieendes Auswerten,
- Abhren von bertragungsleitungen und
- Mitlesen am Bildschirm.
Je hher der Vertraulichkeitsbedarf der Informationen ist, umso grer ist
auch der Anreiz fr Dritte, diese Informationen zu erlangen und zu
missbrauchen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.72 Mibruchliche E-Mail-Nutzung

Der Missbrauch von E-Mailsystemen kann an verschiedenen Punkten auf-
setzen, beim Benutzer, im internen Netz, bei einem der bertragenden Mail-
server oder beim Empfnger.
Wenn der Zugang zum E-Mail-Programm eines Benutzers oder zum E-Mail-
System einer Organisation nicht gut genug geschtzt ist, kann ein Unbefugter
sich unberechtigt Zugang fr manipulative Zwecke verschaffen. Dabei knnen
neben den bertragungskosten auch Schden dadurch entstehen, dass ein
Unbefugter sich als Berechtigter ausgibt.
Ebenso muss verhindert werden, dass E-Mails von Unbefugten gelesen
werden knnen. Vertrauliche Informationen knnen so bekannt werden, ihren
Wert verlieren oder zum Schaden des Empfngers genutzt werden.
Beispiele:
- Ein Abteilungsleiter verlie fr kurze Zeit sein Bro mit ungesichertem IT-
System, auf dem das Mailprogramm bereits gestartet war und fr das er
sich bereits authentisiert hatte. Ein zufllig vorbeigekommener Kollege
hielt es fr einen gelungenen Scherz, unter dessen E-Mail-Kennung
anderen Kollegen "Kndigungen" oder Arbeitsauftrge zu schicken.
- Ein Mitarbeiter verbreitet unter seiner dienstlichen E-Mail-Adresse private
Ansichten, die dem Ansehen seines Arbeitgebers schaden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.73 Vortuschen eines falschen Absenders

Es ist relativ einfach, beim Versand von E-Mail einen falschen Absender
anzugeben, da bei der Weiterleitung von SMTP-basierender E-Mail meist
nicht berprft wird, wo die Nachricht herkommt, nur wo sie hingehen soll.
Darber hinaus erlauben es viele E-Mail-Clients, beliebige Absenderangaben
einzutragen. Dadurch knnen Schden entstehen, wenn der Empfnger die
darin enthaltenen Informationen als authentisch und verbindlich ansieht.
Beispiele:
- Die meisten der zahllosen Spam-E-Mails, die tglich die Postfcher der
Benutzer vertopfen, tragen einen geflschten Absender.
- Einige der verschiedenen E-Mail-Wrmer, die seit mehreren Jahren im
Internet ihr Unwesen treiben, benutzen als Absenderadresse eine Adresse
aus dem E-Mail-Adressbuch des Benutzers, dessen E-Mail-Programm sie
gerade befallen haben. So erhalten die nchsten Opfer die E-Mail, die den
Wurm enthlt, mit einer bekannten Absenderadresse und sind so eher
gefhrdet, die E-Mail oder gar das infizierte Attachment zu ffnen.
- Mit vielen verbreiteten E-Mail-Programmen ist es ohne Probleme mglich,
eine E-Mail mit geflschten Absenderangaben ohne Passwortberprfung
auf den E-Mail-Server weiterzuleiten. Die so versandte E-Mail wird zwar
eventuell bei nicht erfolgter Benutzer-Authentisierung im Feld "X-Sender"
mit "Unverified" gekennzeichnet. Dies wird aber erfahrungsgem von
kaum einem Empfnger bemerkt, ohnehin werden diesese Felder von den
meisten E-Mail-Programmen in der Standardkonfiguration nicht angezeigt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.74 Manipulation von Alias-Dateien oder

Verteilerlisten
Um hufig wiederkehrende E-Mailadressen nicht stndig neu eingeben zu
mssen, kann ber die Vergabe von Alias-Namen eine "sprechende"
Schreibweise fr E-Mailadressen gewhlt werden oder es kann ber die
Erstellung von Verteilerlisten ein grerer Empfngerkreis komfortabel
angewhlt werden. Werden solche Alias-Namen oder Verteilerlisten unbefugt
gendert, kann auf diese Weise die Weiterleitung einer E-Mail an einen
gewnschten Empfnger unterbunden oder die Weiterleitung zu einem uner-
wnschten Empfnger erfolgen. Besonders gefhrdet sind hier Alias-Dateien
oder Adressbcher, die zentral gefhrt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.75 berlastung durch eingehende E-Mails

Eine E-Mail-Adresse kann absichtlich blockiert werden, indem andauernd
umfangreiche E-Mails (ggf. mit sinnlosem Inhalt) zugesandt werden. Dies
kann beispielsweise passieren, weil der Benutzer die Netiquette nicht beachtet
hat und sich dadurch in Newsgruppen unbeliebt gemacht hat. Als Netiquette
(die Netz-Etiquette) werden die Hflichkeitsregeln bezeichnet, die sich mit der
Zeit bei der Nutzung des Internet, insbesondere in den Newsgruppen,
eingebrgert haben und deren Einhaltung gewhrleisten soll, dass jeder das
Internet effizient und zu aller Zufriedenheit benutzen kann.
Durch vorstzlich erzeugtes hohes Verkehrsaufkommen kann das lokale
Mailsystems berlastet werden, so dass es funktionsuntchtig wird. Dies kann
sogar solche Ausmae annehmen, dass der Provider den Benutzer bzw. dessen
ganze Organisation vom Netz nimmt.
Ein Mailsystem kann auch berlastet werden, wenn die Mitarbeiter an E-Mail-
Kettenbrief-Aktionen teilnehmen. So hat schon Mitte der achtziger Jahre eine
Kettenmail-Aktion zu Weihnachten weltweit viele IT-Systeme lahm gelegt.
Hierbei erhielten Benutzer eine E-Mail mit Weihnachtsgren und einer
ansprechenden Graphik und wurden aufgefordert, diese E-Mail zu kopieren
und zehn andere Benutzer weiterleiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.76 Mailbomben
Unter dem Begriff Mailbomben werden E-Mails verstanden, die absichtlich
eingebaute Schadfunktionen enthalten. Diese sind blicherweise in den
Anlagen der E-Mail enthalten. Eine solche Anlage erzeugt z. B. beim Aktivie-
ren zum Lesen oder nach dem Auspacken Unmengen von Unterverzeichnissen
oder beansprucht sehr viel Festplattenplatz. Vielfach wird auch die gezielte
berlastung von E-Mailadressen durch eingehende E-Mails mit meist
sinnlosem Inhalt (siehe G 5.75 berlastung durch eingehende E-Mails) als
Mailbombing bezeichnet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.77 Mitlesen von E-Mails

E-Mail wird im Normalfall im Klartext bertragen. Auf allen IT-Systemen, bertragung im Klartext
ber die die Daten bertragen werden, knnen diese mitgelesen oder sogar
unbemerkt verndert werden, wenn sie nicht kryptographisch gesichert sind.
Bei der bertragung von E-Mails ber das Internet knnen sehr viele IT-
Systeme beteiligt sein, ohne dass der genaue bertragungsweg vorher bekannt
ist. Der bertragungsweg hngt von der Auslastung und Verfgbarkeit der
Gateways und Teilen des Netzes ab. Eine E-Mail von einem Stadtteil in den
anderen kann sogar ber das Ausland weitergeleitet werden.
Der Zugriff auf eingehende E-Mails kann auch ber die beim Mailserver des Speicherung auf dem
Mailserver
Empfngers gefhrte Mailbox erfolgen. Sie enthlt alle empfangenen E-Mails,
je nach Konfiguration nicht nur die ungelesenen, sondern ein Archiv aller in
den letzten Monaten eingegangenen Nachrichten. Hierauf hat mindestens der
Systemadministrator des Mailservers Zugriff. In manchen Fllen werden auch
Kopien ausgehender E-Mails auf dem Mailserver gespeichert. Hufig jedoch
legt das Benutzer-Mailprogramm diese auf dem Rechner des Absenders ab.
Beispiele:
- Mehrere Microsoft-interne E-Mails wurden im Antitrust-Verfahren von der
Gegenseite benutzt, um deren Position zu untermauern. Diese E-Mails ent-
hielten teilweise diffamierende Aussagen ber Microsofts Konkurrenten.
- Ein Anbieter stellt Dienstleistungen ber das Internet zur Verfgung. Fr
die Nutzung ist eine Anmeldung am Server des Dienstleisters erforderlich.
Die dafr notwendigen Authentisierungsinformationen werden per E-Mail
an die Kunden versandt. Durch Mitlesen dieser E-Mails ist ein Angreifer in
der Lage, sich unberechtigt am Server des Dienstleisters anzumelden und
auf Kosten der registrierten Kunden Dienste in Anspruch zu nehmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.78 DNS-Spoofing
Um im Internet mit einem anderen Rechner kommunizieren zu knnen,
bentigt man dessen IP-Adresse. Diese Adresse setzt sich aus vier Zahlen
zwischen 0 und 255 zusammen, also zum Beispiel 194.95.176.226. Da solche
Nummern nicht sehr einprgsam sind, wird einer solchen IP-Adresse fast
immer ein Name zugeordnet. Das Verfahren hierzu nennt sich DNS (Domain
Name System). So kann der WWW-Server des BSI sowohl unter
http://www.bsi.bund.de als auch unter http://194.95.176.226 angesprochen
werden, da der Name bei der Abfrage in die IP-Adresse umgewandelt wird.
Die Datenbanken, in denen den Rechnernamen die zugehrigen IP-Adressen
zugeordnet sind und den IP-Adressen entsprechende Rechnernamen, befinden
sich auf so genannten Nameservern. Fr die Zuordnung zwischen Namen und
IP-Adressen gibt es zwei Datenbanken: In der einen wird einem Namen seine
IP-Adresse zugewiesen und in der anderen einer IP-Adresse der zugehrige
Name. Diese Datenbanken mssen miteinander nicht konsistent sein! Von
DNS-Spoofing ist die Rede, wenn es einem Angreifer gelingt, die Zuordnung
zwischen einem Rechnernamen und der zugehrigen IP-Adresse zu flschen,
d. h. dass ein Name in eine falsche IP-Adresse bzw. umgekehrt umgewandelt
wird.
Dadurch sind unter anderem die folgenden Angriffe mglich:
- r-Dienste (rsh, rlogin, rsh)
Diese Dienste erlauben eine Authentisierung anhand des Namens des
Clients. Der Server wei die IP-Adresse des Clients und fragt ber DNS
nach dessen Namen.
- Web-Spoofing
Ein Angreifer knnte die Adresse www.bsi.bund.de einem falschen
Rechner zuweisen, und bei Eingabe von http://www.bsi.bund.de wrde
dieser falsche Rechner angesprochen werden.
Wie leicht es ist, DNS-Spoofing durchzufhren, hngt davon ab, wie das Netz
des Angegriffenen konfiguriert ist. Da kein Rechner alle DNS-Informationen
der Welt besitzen kann, ist er immer auf Informationen anderer Rechner
angewiesen. Um die Hufigkeit von DNS-Abfragen zu verringern, speichern
die meisten Nameserver Informationen, die sie von anderen Nameservern
erhalten haben, fr eine gewisse Zeit zwischen.
Ist ein Angreifer in einen Nameserver eingebrochen, kann er auch die zur
Verfgung gestellten Informationen abndern. Der Fall eines direkten
Einbruchs auf einen Nameserver soll hier nicht weiter betrachtet werden.
Vielmehr geht es darum, prinzipielle Schwchen im DNS aufzuzeigen.
Beispiele:
1. Ein Benutzer auf dem Rechner pc.kunde.de will zuerst auf www.firma-x.de
und dann auf den Konkurrenten www.firma-y.de zugreifen. Um auf
www.firma-x.de zugreifen zu knnen, muss er erst die zugehrige IP-
Adresse bei seinem Nameserver ns.kunde.de nachfragen. Dieser kennt die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Adresse auch nicht und fragt beim Nameserver von ns.firma-x.de nach.
Dieser antwortet mit der IP-Adresse, die von ns.kunde.de an den Benutzer
weitergeleitet und gespeichert wird. Befindet sich in dem Antwortpaket
von ns.firma-x.de neben der IP-Adresse von www.firma-x.de auch noch
eine beliebige IP-Adresse fr den Rechnernamen www.firma-y.de, so wird
auch diese gespeichert. Versucht der Benutzer nun, auf www.firma-y.de
zuzugreifen, fragt der eigene Nameserver ns.kunde.de nicht mehr bei dem
Nameserver ns.firma-y.de nach, vielmehr gibt er die Informationen weiter,
die ihm von ns.firma-x.de untergeschoben wurden.
2. Firma X wei, dass ein Benutzer mit dem Rechner pc.kunde.de auf den
Konkurrenzrechner www.firma-y.de zugreifen will. Firma X verhindert
dies, indem sie den Nameserver ns.kunde.de nach der Adresse www.firma-
x.de fragt. Dieser muss beim Nameserver ns.firma-x.de nachfragen und
bekommt wie in Beispiel 1 auch die falschen Angaben ber www.firma-
y.de zurck.
Diese beiden Beispiele beruhen darauf, dass ein Nameserver auch zustzliche
Daten, die er gar nicht angefordert hat, akzeptiert. In neuen Versionen
bestimmter Software (z. B. bind) ist dieser Fehler beseitigt, so dass diese Art
von Angriffen verhindert wird. Es ist allerdings unter Verwendung von IP-
Spoofing noch immer mglich, falsche DNS-Eintrge zu erzeugen. Dieser
Angriff ist jedoch technisch viel anspruchsvoller.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.79 Unberechtigtes Erlangen von

Administratorrechten unter Windows NT/2000
Systemen
Bei jeder Standardinstallation von Windows NT/2000 wird ein Administrator- Admin-Konto kann nicht
konto angelegt. Dies betrifft sowohl die Versionen Workstation und Server als gesperrt werden
auch Domnen-Controller. Im Gegensatz zu selbst angelegten Konten kann
dieses vordefinierte Administratorkonto weder gelscht noch gesperrt werden,
um zu verhindern, dass der Administrator vorstzlich oder versehentlich
ausgesperrt wird und somit die Verwaltung unmglich wird. Problematisch in
diesem Zusammenhang ist, dass das vordefinierte Administratorkonto selbst
dann nicht gesperrt wird, wenn die in der Kontorichtlinie fr eine Sperre
eingetragene Anzahl ungltiger Kennworteingaben berschritten wird. Dies
ermglicht das planmige Ausprobieren von Passwrtern mit Hilfe von
Crack-Programmen.
Es gibt aber noch weitere Mglichkeiten, um in den Besitz eines zu einem Admin-Passwort im
Klartext bei der
Administratorkonto gehrenden Passwortes zu kommen, um damit Adminis- bertragung
tratorrechte zu erlangen. Wird ein Rechner unter dem Betriebssystem
Windows NT/2000 fernadministriert, so besteht die Gefahr, dass beim
Authentisierungsvorgang das Anmeldepasswort, je nach verwendetem
Authentisierungsverfahren, im Klartext bertragen und damit von einem
Angreifer aufgezeichnet werden kann. Selbst wenn durch Eingriffe in das
System sichergestellt ist, dass die Anmeldepasswrter nur verschlsselt ber-
tragen werden, ist es mglich, dass ein Angreifer das verschlsselte Passwort
aufzeichnet und mit Hilfe entsprechender Software entschlsselt. Dies gilt
insbesondere fr Windows NT, da hier das NTLM-Verfahren eingesetzt wird.
Unter Windows 2000 wird standardmig das Kerberos-Verfahren eingesetzt,
das robuster gegen solche Angriffe ist.
Weiterhin wird jedes Passwort in der Registrierung und in einer Datei, die sich Admin-Passwort auf
Notfalldiskette
im Verzeichnis %SystemRoot%\System32\Repair bzw. auf den Notfalldis-
ketten und ggf. auf Bandsicherungen befindet, verschlsselt gespeichert.
Gelangt ein Angreifer in den Besitz der entsprechenden Datei, so kann er mit
Hilfe entsprechender Software versuchen, das bentigte Passwort zu ent-
schlsseln.
Schlielich ist es mit einer speziellen Schadsoftware mglich, dass ein Schadsoftware
Angreifer auf dem Windows NT Rechner, an dem er lokal angemeldet ist, ein
beliebiges Benutzerkonto der Gruppe Administratoren hinzufgt und dem
Kontoinhaber damit Administratorrechte verschafft.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.80 Hoax
Ein Hoax (englisch fr Streich, Trick, falscher Alarm) ist eine Nachricht, die Falschmeldung
eine Warnung vor neuen spektakulren Computer-Viren oder anderen
IT-Problemen enthlt und Panik verbreitet, aber nicht auf realen technischen
Fakten basiert. Meist werden solche Nachrichten ber E-Mails verbreitet.
Beispielsweise wird dabei vor Computer-Viren gewarnt, die Hardware-
Schden verursachen knnen oder durch das bloe ffnen einer E-Mail (nicht
eines Attachments) zu Infektionen und Schden fhren knnen und die durch
keine Antiviren-Software erkannt werden. Neben dieser Warnung wird darum
gebeten, die Warnmeldung an Freunde und Bekannte weiterzuleiten. Noch
wirksamer wird ein solcher Hoax, wenn als Absender eine geflschte Adresse
angegeben wird, wie zum Beispiel die eines namhaften Herstellers.
Ein solcher Hoax ist nicht zu verwechseln mit einem Computer-Virus, der Ein Hoax ist kein Virus!
tatschlich Manipulationen am IT-System vornehmen kann. Vielmehr handelt
es sich um eine irrefhrende Nachricht, die ohne Schaden gelscht werden
kann und sollte. Die einzigen Schden, die ein Hoax herbeifhrt, sind die
Verunsicherung und Irritation der Empfnger und ggf. die Kosten an Zeit und
Geld fr den Weiterversand des Hoax.
Im Bereich des Mobilfunks gab es eine ganze Reihe solcher Hoax-Nachrich-
ten, bei denen davor gewarnt wurde, dass an Mobiltelefonen die Eingabe
bestimmter Tastenkombinationen oder die Wahl bestimmter Rufnummern
dazu fhren knnten, Gesprche abzuhren oder auf Kosten anderer zu tele-
fonieren. Durch die Nennung bestimmter Mobiltelefon-Marken und einiger
technischer Ausdrcke wird der Anschein von Seriositt erweckt. Solche
Gerchte halten sich hartnckig und verunsichern die Benutzer.
Beispiel:
Im Frhjahr 2000 kursierte folgende Falschmeldung per E-Mail (und teilweise
sogar per Brief):
"Wenn sie eine Nachricht auf Ihr Handy erhalten, dass sie unter der
Nummer 0141-455xxx zurckrufen sollen, antworten sie auf keinen Fall
darauf. Ihre Rechnung steigt sonst ins Unermessliche.
Diese Information wurde von der "Zentralstelle zur Unterdrckung von
betrgerischen Machenschaften" (Office Central de Repression du
Banditisme) herausgegeben. ..."
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.81 Unautorisierte Benutzung eines Kryptomoduls

Gelingt es einem Dritten, ein Kryptomodul unautorisiert zu benutzen, so
knnen Schden verschiedenster Art die Folge sein. Beispiele fr solche
Schden sind:
- Bei der unautorisierten Nutzung gelingt es dem Angreifer, geheime
Schlssel auszulesen, die Schlssel zu verndern oder auch kritische
Sicherheitsparameter zu manipulieren. Die Folge wre, dass die krypto-
graphischen Verfahren keine ausreichende Sicherheit mehr bieten.
- Bei der unautorisierten Nutzung manipuliert der Angreifer das Krypto-
modul so, dass es zwar auf den ersten Blick korrekt arbeitet, sich jedoch
tatschlich in einem unsicheren Zustand befindet.
- Der Angreifer nutzt das Kryptomodul in Form einer Maskerade. Signiert er
oder verschlsselt er Daten bei der unautorisierten Benutzung des
Kryptomoduls, so wird dies vom Empfnger der Daten so interpretiert, als
htte der autorisierte Benutzer dies vorgenommen.
Beispiel:
Eine unautorisierte Benutzung eines Kryptomoduls wird dann mglich, wenn
der regulre Benutzer kurzfristig seinen Arbeitsplatz verlsst und das funkti-
onsfhige Kryptomodul einsetzbar ist, ohne dass es vor unbefugtem Zugriff
geschtzt ist, also beispielsweise wenn eine Signatur- oder Verschlsselungs-
chipkarte im Rechner stecken bleibt. Damit kann jeder, der zufllig vorbei-
kommt, E-Mail im Namen des regulren Benutzers signieren oder auf dem
IT-System gespeicherte Dateien so verschlsseln, dass der Benutzer sie nicht
mehr verwenden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.82 Manipulation eines Kryptomoduls

Ein Angreifer kann versuchen, ein Kryptomodul zu manipulieren, um geheime
Schlssel auszulesen oder die Schlssel zu verndern oder auch um kritische
Sicherheitsparameter zu verndern. Ein Kryptomodul kann auf verschiedene
Art und Weise manipuliert sein, es kann z. B.
- ein Super-Passwort, mit dem alle anderen Passwrter umgangen werden
knnen,
- nicht dokumentierte Testmodi, ber die jederzeit Zugriff auf sensitive
Bereiche genommen werden kann,
- Trojanische Pferde, d. h. Software, die neben ihrer eigentlichen Aufgabe
andere, nicht direkt erkennbare Aktionen wie das Aufzeichnen von
Passwrtern, durchfhrt,
- manipulierte Zugriffsrechte auf bestimmte Kommandos
enthalten. Andere Beispiele fr solche Angriffe sind
- die Modifikation von kryptographischen Schlsseln,
- die Beeintrchtigung der internen Schlsselgenerierung, z. B. durch Mani-
pulation des Zufallszahlengenerators,
- die Modifizierung der Ablufe innerhalb des Kryptomoduls,
- Modifikationen am Sourcecode oder am ausfhrbaren Code des Krypto-
moduls,
- ber- oder Unterschreitung des zulssigen Arbeitsbereichs bzgl.
Spannungsversorgung, Temperatur, EMV-Grenzwerte etc. des Krypto-
moduls.
Bei Manipulationen am Kryptomodul wird der Angreifer meist versuchen,
diesen Angriff zu vertuschen, so dass das Kryptomodul fr Benutzer zwar auf
den ersten Blick vermeintlich korrekt arbeitet, sich jedoch in einem unsicheren
Zustand befindet. Es gibt allerdings auch zerstrerische Angriffe, bei denen
auch die Zerstrung des Kryptomoduls bewusst in Kauf genommen wird,
beispielweise wenn ein Angreifer Informationen ber die Funktionsweise des
Kryptomoduls erhalten will oder wenn die kryptographischen Schlssel
ausgelesen werden sollen.
Ein Angreifer kann versuchen, seine Angriffe am Aufstellungsort des
Kryptomoduls durchzufhren oder es entwenden. Bei einem schlecht
geschtzten Aufstellungsort lassen sich die Manipulationen unter Umstnden
sehr schnell durchfhren und bleiben dadurch evtl. lange unbemerkt. Durch
den Diebstahl von Kryptomodulen kann ein Angreifer wichtige Informationen
darber bekommen, wie eine Komponente am einfachsten manipulierbar ist.
Er kann die entwendeten Komponenten benutzen, um daraus sensitive Infor-
mationen wie Schlssel, Software oder Kenntnis ber Hardwaresicherheits-
mechanismen zu gewinnen. Er kann aber auch die entwendete Komponente
dazu benutzen, um ein authentisches Kryptomodul vorzutuschen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.83 Kompromittierung kryptographischer Schlssel

Beim Einsatz kryptographischer Verfahren hngt der Sicherheitszugewinn
entscheidend davon ab, wie vertraulich die verwendeten geheimen krypto-
graphischen Schlssel bleiben. Mit Kenntnis sowohl des verwendeten
Schlssels als auch des eingesetzten Kryptoverfahrens ist es meist einfach, die
Verschlsselung umzukehren und den Klartext zu gewinnen. Daher wird ein
potentieller Angreifer versuchen, die verwendeten Schlssel zu ermitteln.
Angriffspunkte dazu sind:
- Bei der Schlsselerzeugung werden ungeeignete Verfahren eingesetzt,
beispielsweise zur Bestimmung von Zufallszahlen oder zur Ableitung der
Schlssel.
- Bei der Schlsselerzeugung werden Schlssel ausgelesen, bevor sie auf
sicheren Speichermedien gespeichert werden.
- Im laufenden Betrieb werden Schlssel aus Kryptomodulen durch tech-
nische Angriffe ausgelesen.
- Als Backup hinterlegte Schlssel werden entwendet.
- Bei der Eingabe von kryptographischen Schlsseln werden die Schlssel
ausgespht.
- Die eingesetzten Kryptoverfahren werden gebrochen. So ist es heute
beispielsweise bei symmetrischen Verschlsselungsverfahren wie dem
DES mglich, den verwendeten Schlssel mittels massiv paralleler Rech-
ner durch Ausprobieren zu ermitteln (Brute-Force-Attacke).
- Verwendete kryptographische Schlssel werden durch Innentter verraten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.84 Geflschte Zertifikate

Zertifikate dienen dazu, einen ffentlichen kryptographischen Schlssel an
eine Person zu binden. Diese Bindung des Schlssels an den Namen der Per-
son wird wiederum kryptographisch mittels einer digitalen Signatur einer
vertrauenswrdigen dritten Stelle abgesichert. Diese Zertifikate werden von
Dritten dann verwendet, um digitale Signaturen der im Zertifikat ausgewiese-
nen Person zu prfen bzw. um dieser Person Daten mit dem im Zertifikat
aufgezeichneten Schlssel verschlsselt zuzusenden.
Ist ein solches Zertifikat geflscht, werden digitale Signaturen flschlicher-
weise als korrekt geprft und der Person im Zertifikat zugeordnet oder es
werden Daten mit einem ggf. unsicheren Schlssel verschlsselt und versandt.
Beide Angriffsmglichkeiten knnen einen Tter bewegen, geflschte
Zertifikate in Umlauf zu bringen.
Geflschte Zertifikate knnen auf verschiedene Weise erzeugt werden:
- Ein Innentter der vertrauenswrdigen Stelle erstellt mit dem eigenen
Signaturschlssel ein Zertifikat mit geflschten Angaben. Dieses Zertifikat
ist authentisch und wird bei einer Prfung als korrekt verifiziert.
- Ein Tter gibt sich als eine andere Person aus und beantragt ein Zertifikat,
welches auf diese andere Person ausgestellt wird, obwohl der Tter im
Besitz des geheimen Schlssels ist, der mit dem ffentlichen Schlssel im
Zertifikat korrespondiert.
- Ein Tter erzeugt ein Zertifikat und signiert es mit einem eigenen Schls-
sel. Die Flschung fllt nur auf, wenn das Zertifikat geprft wird und dabei
festgestellt werden kann, dass das Zertifikat von einer nichtvertrauens-
wrdigen Stelle ausgestellt wurde.
Wenn ein Tter erst einmal ein Zertifikat mit falschen Angaben auf irgend-
einem Weg erhalten hat, kann er sich gegenber Kommunikationspartnern
jederzeit als eine andere Person ausgegeben, und zwar sowohl beim Versand
als auch beim Empfang von Nachrichten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.85 Integrittsverlust schtzenswerter

Informationen
Wenn Daten nicht mehr integer sind, kann es zu einer Vielzahl von Problemen
kommen:
- Daten knnen im einfachsten Fall nicht mehr gelesen, also weiterverar-
beitet werden.
- Daten knnen versehentlich oder vorstzlich so verflscht werden, dass
dadurch falsche Informationen weitergegeben werden. Hierdurch knnen
beispielsweise berweisungen in falscher Hhe oder an den falschen
Empfnger ausgelst werden, die Absenderangaben von E-Mails knnten
manipuliert werden oder vieles mehr.
- Wenn verschlsselte oder komprimierte Datenstze ihre Integritt verlieren
- und hier reicht die nderung eines Bits, knnen sie u. U. nicht mehr ent-
schlsselt bzw. entpackt werden.
- Dasselbe gilt auch fr kryptographische Schlssel, auch hier reicht die
nderung eines Bits, damit die Schlssel unbrauchbar werden. Dies fhrt
dann ebenfalls dazu, dass Daten nicht mehr entschlsselt oder auf ihre
Authentizitt berprft werden knnen.
- Dokumente, die in elektronischen Archiven gespeichert sind, verlieren an
Beweiskraft, wenn ihre Integritt nicht nachgewiesen werden kann.
Zu Integrittsverlusten kann es auf verschiedene Weise kommen:
- Durch die Alterung von Datentrgern kann es zu Informationsverlusten
kommen.
- Bei der Datenbertragung kann es zu bertragungsfehlern kommen. bertragungsfehler
- Durch Computer-Viren knnen ganze Datenbestnde verndert oder zer- Computer-Viren

strt werden.
- Durch Fehleingaben kann es zu so nicht gewnschten Transaktionen kom- Fehleingaben
men, die sogar hufig lange Zeit nicht bemerkt werden.
- Angreifer knnen versuchen, Daten fr ihre Zwecke zu manipulieren, z. B.
um Zugriff auf weitere IT-Systeme oder Datenbestnde zu erlangen.
- Durch Manipulation der Index-Datenbank knnen elektronische Archive
veranlasst werden, geflschte Dokumente zu archivieren oder wieder-
zugeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.86 Manipulation von Managementparametern

Auch Managementsysteme knnen durch bewusst herbeigefhrte Fehlkonfi-
gurationen zu einem Angriff auf ein lokales Rechnersystem benutzt werden.
Die Fehlkonfigurationen knnen dabei auf verschiedene Arten herbeigefhrt
werden. Dabei sind Manipulationen sowohl an der Managementplattform als
auch an den verwalteten Gerten mglich. Insbesondere Netzmanage-
mentsysteme, die SNMP benutzen, sind fr Angriffe anfllig, bei denen
bewusst Managementparameter fehlkonfiguriert werden (z. B. durch einen
eigenen SNMP-Client). Je nach einstellbaren Parametern reichen die Attacken
von einfachen "Denial-of-service-Attacken" (z. B. durch Verstellen von IP-
Adressen) bis hin zur Datenvernderung (z. B. nach Verstellen von
Zugriffsrechten).
Werden Netzkomponenten durch ein Managementsystem verwaltet, so sollten
alle durch das Managementsystem verwalteten Konfigurationsparameter auch
nur durch das Managementsystem verndert werden. Je nach Management-
system ist es jedoch immer noch mglich, die Konfigurationsparameter der
Komponente auch lokal zu verndern. Wird ein PC z. B. ber SNMP durch
ein Netzmanagementsystem verwaltet, so kann ein lokaler Benutzer mit einem
lokalen SNMP-Client-Programm (mit Kenntnis des SNMP-Passwortes) oder
aber ber ein lokales Bedienelement (z. B. bei einem Drucker) die Ein-
stellungen verndern. Dies fhrt u. U. zumindest zu Inkonsistenzen im Netz-
managementsystem, kann jedoch auch bewusst zur Herbeifhrung von Sicher-
heitslchern benutzt werden. Beispielsweise knnte das Abfragen freige-
gebener Verzeichnisse ber SNMP ber Netz fr einen Windows NT Rechner
nachtrglich ermglicht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.87 Web-Spoofing
Bei Web-Spoofing "flscht" ein Angreifer WWW-Server, d. h. er spiegelt
durch die Gestaltung seines WWW-Servers vor, dass dieser ein bestimmter,
vertrauenswrdiger WWW-Server ist. Dazu whlt er eine WWW-Adresse so,
dass viele Benutzer alleine durch die Adresswahl davon ausgehen, mit einer
bestimmten Institution verbunden zu sein. Selbst bei Verwendung eines
richtigen Rechnernamens ist Web-Spoofing mglich, wenn ein Angreifer
DNS-Spoofing verwendet (siehe G 5.78 DNS-Spoofing).
Beispiel:
- Unter der Adresse www.whitehouse.com findet sich nicht die offizielle
Homepage des weien Hauses, sondern die eines Scherzboldes.
- Die XY Bank hat die WWW-Adresse www.xy-bank.de. Ein Angreifer kann
unter www.xybank.de oder www.xy-bank.com WWW-Seiten einrichten, die
auf den ersten Blick denjenigen der XY Bank hneln. Dazu trgt er diese
Adressen auf diversen Suchmaschinen ein, wobei er Stichworte whlt,
nach denen XY-Kunden voraussichtlich suchen knnten.
Benutzer, die diese Seiten aufrufen, werden annehmen, dass sie mit dem
WWW-Server ihrer Bank kommunizieren. Daher sind sie bereit, ihre
Kontonummer und PIN oder andere Zugangscodes einzugeben. Vielleicht
lesen sie dort auch fr sie interessante, aber geflschte Angebote wie
gnstige Geldanlagen oder Immobilien und wollen diese wahrnehmen.
Kann die Bank diese nicht zu diesen Konditionen oder berhaupt nicht
anbieten, sind die Kunden im besten Fall nur unzufrieden, im schlechtesten
Fall kann es sogar zu Rechtsstreitigkeiten kommen.
Statt zu versuchen, einen vorhandenen WWW-Server zu manipulieren oder
nachzuahmen, kann ein Angreifer auch ein eigenes WWW-Angebot ins
Internet einbringen und dieses so gestalten, dass jeder Besucher den Eindruck
hat, mit einer etablierten, serisen Institution verbunden zu sein.
Beispiele:
- Es knnte ein Warenangebot angepriesen werden, das nur zu dem Zweck
gestaltet wurde, um Kreditkartennummern von potentiellen Kufern zu
erhalten.
- Es hat Flle gegeben, in denen gutglubige Kunden bei vermeintlichen
Banken zu lukrativen Konditionen Geld anlegen wollten. Diese Banken
waren ihnen nur bers Internet bekannt und erst, als die erwarteten Zinsen
nicht eintrafen, fiel ihnen auf, dass es sich nur um eine, inzwischen
gelschte, private WWW-Seite handelte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.88 Missbrauch aktiver Inhalte

Whrend des Surfens im Internet knnen WWW-Seiten mit aktiven Inhalten
auf den Anwenderrechner geladen werden (z. B. ActiveX oder Java-Applets).
Diese Software kann gezielt zu dem Zweck erstellt worden sein, dass sie ver-
trauliche Daten des Benutzers ausspioniert und anschlieend so ausgesphte
Informationen an den Angreifer ber das Internet zurckgibt.
Ein Java-fhiger Browser erlaubt es dem Benutzer, Java-Applets vom Netz zu
laden und auszufhren, ohne dass der Benutzer das Applet erkannt hat. Dies
stellt Java-Benutzer vor bedeutende Sicherheitsrisiken:
- Ein Java-Applet kann Standardnetzprotokolle (wie zum Beispiel SMTP)
benutzen, um Daten vom Rechner des Benutzers aus zu verschicken.
- Ein Java-Applet kann das Java-System angreifen, indem es dessen Spei-
cher korrumpiert, oder es kann das darunterliegende Betriebssystem
angreifen, indem es Dateien flscht oder wichtige Prozesse beendet.
- Ein Java-Applet kann den gesamten Speicher des Systems belegen oder
hochprioritre Nachrichten erzeugen. Der Verfgbarkeitsangriff ist auch
bei der korrekten Interpretation des Java-Sicherheitsmodells mglich.
Bei ActiveX ist anders als bei Java die Funktionsvielfalt kaum eingeschrnkt:
Bis hin zur Formatierung der Festplatte kann ein ActiveX-Programm alle
Befehle enthalten. Diese kleinen ausfhrbaren Codes nennt man Controls. Die
meist zur Illustration oder Unterhaltung verteilten Controls knnen auch
bswillige Elemente besitzen, die dann Zugriff auf den Datenspeicher des
Anwenderrechners haben oder andere Programme - fr den Benutzer unbe-
merkt - fernsteuern. ActiveX-Controls knnen die Festplatte lschen, einen
Virus oder ein Trojanisches Pferd enthalten oder die Festplatte nach bestimm-
ten Informationen durchsuchen. All dies kann passieren, ohne dass der Nutzer
bzw. Betrachter des Controls dies bemerkt. Whrend der Betrachter ein durch
Controls bertragenes Spiel ausfhrt, kann im Hintergrund dieses Control die
E-Mail nach bestimmten Informationen durchsuchen.
Bei entsprechender Voreinstellung seines WWW-Browsers kann ein Benutzer
zwar dafr sorgen, dass nur digital signierte ActiveX-Controls ausgefhrt
werden. Eine solche digitale Signatur beweist allerdings nur, dass der
Hersteller des ActiveX-Controls bei einer Zertifizierungsstelle bekannt ist und
dass das von diesem Hersteller bereitgestellte Control unverndert geladen
wurde. Hierdurch wird nichts ber die Funktionsweise oder Schadensfreiheit
eines solchen Controls ausgesagt und auch keine Gewhr dafr bernommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.89 Hijacking von Netz-Verbindungen

Weit aus kritischer als das Abhren einer Verbindung ist das bernehmen
einer Verbindung. Hierbei werden Pakete in das Netz eingeschleust, die ent-
weder zum Abbruch oder Blockieren des Clients fhren. Der Serverprozess
kann daraufhin nicht erkennen, dass ein anderes Programm an die Stelle des
Original-Clients getreten ist. Bei dieser bernahme einer bestehenden
Verbindung kann der Angreifer nach erfolgreicher Authentisierung einer
berechtigten Person beliebige Aktionen im Namen dessen ausben.
Beispiel:
Es gibt bereits eine Reihe von Programmen, die es ermglichen, eine beste-
hende Telnet-Verbindung zu bernehmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.90 Manipulation von Adressbchern und

Verteillisten
Auf Faxservern besteht in der Regel die Mglichkeit, Adressbcher und Manipulation von
Verteillisten zu fhren. In Adressbchern werden u. a. die Empfnger- Adressbchern
Faxnummern gespeichert. Auch ist es mglich, mehrere Faxempfnger in
einer Gruppe z. B. fr den Versand von Serien-Faxsendungen zusammen-
zufassen. Der Gebrauch von solchen Adressbchern ist fr den Benutzer sehr
komfortabel, da eine einmal gespeicherte Empfngernummer nicht noch
einmal manuell eingegeben werden muss. Vielfach wird von den Benutzern
eines Faxservers vor dem Faxversand nicht mehr die Richtigkeit einer im
Adressbuch eingetragenen Empfngernummer berprft. Gleiches gilt auch
fr die Zuordnung einzelner Empfnger zu Gruppen. Hufig wird vor dem
Versand von Serien-Faxsendungen nicht mehr berprft, ob sich der
gewnschte Kreis von Empfngern mit den Mitgliedern einer Gruppe deckt.
Mittels Verteillisten knnen eingehende Faxsendungen (mehreren)
Empfngern zugeordnet werden.
Sofern ein Unbefugter Adressbcher und Verteillisten verndern kann, besteht Manipulation von
Verteillisten
die Gefahr, dass Faxsendungen an unerwnschte Empfnger bermittelt
werden. Es ist damit auch mglich, dass der Versand eines Faxes an den
gewnschten Empfnger unterbunden wird. Besonders gefhrdet sind hier
naturgem die zentral gefhrten Adressbcher und Verteillisten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.91 Abschalten von Sicherheitsmechanismen fr

den RAS-Zugang
Die Sicherheit eines RAS-Zugangs hngt wesentlich von der korrekten
Nutzung der angebotenen Sicherheitsmechanismen ab. In der Regel ist es
jedoch mglich, das RAS-System so zu konfigurieren (Client und/oder
Server), dass schwache oder keine Sicherheitsmechanismen zum Einsatz
kommen. Werden z. B. die zur Datenverschlsselung eingesetzten Mecha-
nismen beim Verbindungsaufbau dynamisch zwischen Client und Server ver-
handelt (dies kann beispielsweise bei der Nutzung von IPSec oder SSL
geschehen), so erfolgt diese Verhandlung meist dadurch, dass der Client dem
Server eine Liste von untersttzten Verfahren (so genannte Cipher-Suites) zur
Auswahl anbietet, aus denen sich der Server eines auswhlt. Die Liste der
verwendbaren Verfahren kann durch entsprechende Konfiguration verndert
werden. Meist ist auch die Option "keine Verschlsselung" mglich.
Ist die unverschlsselte Verbindungsaufnahme eine erlaubte Option zwischen
Client und Server, so besteht grundstzlich die Gefahr, dass die Absicherung
der bertragenen Daten deaktiviert wird. Dies betrifft insbesondere RAS-
Clients, wenn den Benutzern die Mglichkeit gegeben wird, die Konfiguration
des RAS-Systems bei Problemen an die lokalen Gegebenheiten anzupassen.
Beispiele:
- Die Absicherung der RAS-Kommunikation soll mittels IPSec unter
Windows 2000 erfolgen. Auf dem RAS-Server ist eingestellt, dass die
IPSec-Verschlsselung angefordert, jedoch nicht erzwungen wird, so dass
RAS-Clients potentiell auch ungesicherte Verbindungen aufbauen knnen.
Da einem RAS-Benutzer die mit der Verschlsselung einhergehenden
Leistungseinbuen auf seinem lteren Laptop nicht akzeptabel erscheinen,
schaltet er die IPSec-Verschlsselung ab. Die RAS-Verbindung wird nun
unverschlsselt aufgebaut.
- Unter lteren Windows NT-Versionen kann die Verschlsselung der RAS-
Verbindung mittels MPPE (Microsoft Point to Point Encryption) nur dann
durchgefhrt werden, wenn als Authentisierungsverfahren MS-CHAP ein-
gesetzt wird. Nur bei Verwendung von MS-CHAP werden die zur Ver-
schlsselung notwendigen Parameter zwischen Client und Server ausge-
tauscht. Um ein standardisiertes Authentisierungsverfahren zu benutzen,
stellt ein Benutzer das CHAP-Verfahren ein. Eine Verschlsselung der
RAS-Verbindung mittels MPPE kann nun nicht mehr erfolgen, obwohl die
entsprechende Option aktiviert ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.92 Nutzung des RAS-Clients als RAS-Server

Die auf RAS-Clients eingerichtete RAS-Software erlaubt es u. U., dass auch
der Client als RAS-Server fungieren kann und eingehende Verbindungen
entgegennimmt (z. B. Windows-RAS). Ist diese Option aktiviert, so kann sich
jeder, der die Nummer des Telefonanschlusses kennt, an den der Client ange-
schlossen ist, mit diesem Rechner verbinden. Gelingt es einem Angreifer, den
RAS-Authentisierungsmechanismus zu berwinden (beispielsweise durch
Ausprobieren oder Raten von Passwrtern, Nutzung nicht passwortgeschtzter
Benutzerkonten, Nutzung von Gast-Kennungen mit Standardpasswrtern), so
kann auf die Daten des RAS-Clients zugegriffen werden. Ist der Client ber
ISDN angebunden, so kann sogar eine weitere ausgehende Verbindung (z. B.
in das Firmennetz) aufgebaut werden. Ist die Verbindungsaufnahme automa-
tisiert (Speicherung des RAS-Passwortes), so kann der Angreifer auch unbe-
rechtigt auf Daten im LAN zugreifen. Die Nutzung eines RAS-Clients als
RAS-Server muss daher auf jeden Fall verhindert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.93 Erlauben von Fremdnutzung von RAS-

Komponenten
Werden RAS-Komponenten Unbefugten absichtlich zugnglich gemacht, so
kann die Sicherheit des RAS-Systems nicht mehr gewhrleistet werden (siehe
auch G 3.30 Unerlaubte private Nutzung des dienstlichen Telearbeits-
rechners). Mgliche Gefhrdungen sind:
- RAS-Zugnge knnen unautorisiert verwendet werden, wenn die Sicher- Unautorisierte Verwen-
dung von RAS-Zugngen
heitsrichtlinien nicht eingehalten werden. Beispielsweise geschieht es
immer wieder, dass Administratoren aus falsch verstandener Freundlichkeit
die RAS-Einwahl fr nicht berechtigte Personen erlauben (beispielsweise
zur Internet-Nutzung).
- RAS-Benutzer geben Authentisierungsdaten oder -Token an unberechtigte Weitergabe von Pass-
wrtern oder Token
Dritte weiter, um diesen den entfernten Zugang zum LAN (unter ihrer
Kennung) zu gewhren. Mgliche Motive dafr sind z. B., dass der Kolle-
ge gem RAS-Sicherheitskonzept nicht zur Nutzung von Remote Access
berechtigt ist oder vergessen hat, die RAS-Nutzung rechtzeitig vor Antritt
einer Dienstreise zu beantragen. Da nun ein RAS-Benutzerkonto von
mehreren Benutzern verwendet wird, ist im Schadensfall keine eindeutige
Identifizierung des Verursachers mehr mglich.
- Fr den Bereich der Telearbeit ergibt sich hufig die Problematik, dass der Unautorisierte Nutzung
im privaten Umfeld
RAS-Client durch Familienmitglieder oder Freunde von Familienmitglie-
dern benutzt wird. Arbeiten organisationsfremde Personen mit dem RAS-
Client, so werden von diesen die fr den RAS-Client geltenden Sicher-
heitsvorschriften in der Regel nicht beachtet. Hierdurch kann die Sicherheit
des LANs beeintrchtigt werden.
Die Fremdnutzung von IT-Systemen an entfernten Standorten kann nie ganz
ausgeschlossen werden, da die Sicherheitsmechanismen eines IT-Systems bei
physikalischem Zugriff unterlaufen werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.94 Kartenmissbrauch
Jeden Tag werden Mobiltelefone verloren oder gestohlen. Neben dem unmit-
telbaren Verlust kann dabei weiterer finanzieller Schaden entstehen. Gelangt
ein Unbefugter in den Besitz einer SIM-Karte (z. B. durch Fund oder Dieb-
stahl), kann er auf Kosten des rechtmigen Karteninhabers telefonieren,
sofern ihm die PIN bekannt ist oder er sie leicht erraten kann.
Daten wie Telefonbuch oder Kurznachrichten, die im Mobiltelefon oder auf
der SIM-Karte gespeichert sind, knnen durchaus einen vertraulichen Charak-
ter haben. Ein Verlust des Mobiltelefons oder der Karte bedeutet dann unter
Umstnden die Offenlegung dieser gespeicherten Informationen.
Die kryptographischen Sicherheitsmechanismen der SIM-Karten einiger
Netzbetreiber waren in der Vergangenheit zu schwach ausgelegt. Dadurch war
es mglich, SIM-Karten dieser Netzbetreiber zu kopieren. Dazu muss
allerdings die Original-Karte dem Angreifer zur Verfgung stehen. Auerdem
muss die PIN bekannt sein oder die PIN-Abfrage abgeschaltet sein, damit die
IMSI ausgelesen werden kann.
Ein solcher Angriff kann von Privatbenutzern leicht verhindert und erkannt
werden. Bei Mobiltelefonen, auf die unterschiedlichste Personen Zugriff
haben, knnte ein solcher Angriff durchgefhrt werden und wrde vermutlich
erst spt bemerkt werden. Dies betrifft z. B. Mobiltelefone aus einem Pool
oder professionelle Mobiltelefon-Verleiher.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.95 Abhren von Raumgesprchen ber

Mobiltelefone
Mobiltelefone knnen dazu benutzt werden, unbemerkt Gesprche aufzu- unauffllig aktivieren
zeichnen oder abzuhren. Im einfachsten Fall kann hierzu ein Mobiltelefon
benutzt werden, mit dem eine Verbindung zu einem interessierten Mithrer
aufgebaut wurde und das unauffllig in einem Raum platziert wurde, z. B. bei
einer Besprechung. Da aber die Akkukapazitt begrenzt ist und auch das
Mikrofon nicht auf Raumberwachung ausgelegt ist, hat ein solcher Abhr-
versuch nur eine begrenzte Wirkung.
Durch geschickte Wahl von Leistungsmerkmalen und der Kombination mit Ausnutzen von
Leistungsmerkmalen
zustzlichen Sprechgarnituren kann evtl. auch erreicht werden, dass ein
Mobiltelefon durch einen Anruf von auen in den Gesprchszustand versetzt
wird, ohne dass es dies durch einen Rufton oder anderweitig signalisiert. So
gibt es z. B. einen Gertetyp, bei dem durch Bettigen bestimmter Tasten-
kombinationen das Display des Mobiltelefons abgeschaltet werden kann,
obwohl zu dem Gert eine Gesprchsverbindung existiert.
Fr diesen Zweck knnen aber auch speziell manipulierte Mobiltelefone manipulierte Mobiltele-
fone
benutzt werden, denen nicht einmal angesehen werden kann, dass sie einge-
schaltet sind. Das Mobiltelefon dient dabei als Abhranlage, die ber das
Telefonnetz von jedem Ort der Welt aktiviert werden kann, ohne dass dies am
Mobiltelefon erkennbar wre. Es sind Gerte bekannt, bei denen diese
Sonderfunktion mittels zustzlicher Schaltungseinbauten realisiert ist. Diese
Manipulation ist durch eine Sichtprfung nach Zerlegen des Gertes oder
durch spezielle Untersuchungsmethoden relativ leicht nachzuweisen. Der
Betrieb solcher Gerte ist in Deutschland illegal.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.96 Manipulation von Mobiltelefonen

Der in G 5.95 Abhren von Raumgesprchen ber Mobiltelefone erwhnte
Einbau zustzlicher elektronischer Schaltungen ist eine typische Hardware-
Manipulation. Damit diese Manipulation durchgefhrt werden kann, muss sich
das zu manipulierende Gert fr eine gewisse Zeit im Besitz des Angreifers
befinden.
Eine andere Mglichkeit, Mobiltelefone fr Abhrzwecke nutzbar zu machen, Manipulation der
Firmware
besteht in der Manipulation der gerteinternen Steuersoftware (Firmware).
Derartige Manipulationen sind weitaus schwerer zu entdecken als Hardware-
Manipulationen.
Eine versteckte, nicht dokumentierte Abhrfunktion knnte schon bei der
Entwicklung des Gertes (bewusst oder unbewusst) in die Steuersoftware
einprogrammiert sein.
Denkbar ist jedoch auch eine nachtrgliche Vernderung der Steuersoftware
durch einen Dritten, z. B. wenn das Gert bei einer Reparatur oder aus sonsti-
gen Grnden (Verlust, Entwendung) fr den Benutzer (kurzzeitig) nicht
kontrollierbar ist. Die Manipulation ist nur mit eingehender Spezialkenntnis,
die neben den Firmware-Entwicklern nur wenigen Angreifern zugnglich ist,
machbar. Fr Auenstehende ist diese Manipulation praktisch nicht nach-
weisbar.
Durch die Erweiterung der Menfunktionen der Mobiltelefone mittels "SIM-
Toolkit" und einer neuen Generation von SIM-Karten, die diese Funktionalitt
untersttzen, werden Mobiltelefone noch flexibler. Ein so ausgestattetes
Mobiltelefon lsst sich per Mobilfunk vom Service-Provider mit neuen Funk-
tionen programmieren. So kann der Kartenanbieter zum Beispiel die Men-
struktur individuell an die Bedrfnisse eines Kunden anpassen.
Dies birgt nun erst recht die Gefahr der Firmware-Manipulation, da Funktio-
nen bereits serienmig in der Firmware enthalten sein knnen, die auch fr
den Umbau als Lauschsender notwendig sind. Die Wahrscheinlichkeit steigt,
dass Funktionen von "auen" aufgerufen werden knnen, die das Mobiltelefon
zu einem Lauschsender umfunktionieren. Denkbar ist auch, dass diese
Funktionen ein- und ausschaltbar sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.97 Unberechtigte Datenweitergabe ber

Mobiltelefone
Mobiltelefone ermglichen den Datentransport von einem IT-System, z. B.
einem PC oder Notebook, zum anderen, ohne dass eine drahtgebundene
Verbindung hergestellt werden muss.
Informationen knnen dort, wo ein offener Zugang zu IT-Systemen mglich
ist, unauffllig abgefragt und bermittelt werden. Mit Hilfe eines Mobil-
telefons mit angeschlossenem oder eingebautem Modem knnen gespeicherte
Informationen drahtlos an nahezu jeden beliebigen Ort der Welt bertragen
werden.
Diese Art der unbefugten Datenweitergabe kann sowohl mit einem eigens
dafr mitgebrachten oder sogar mit einem internen Mobiltelefon durchgefhrt
werden. Auf diese Weise lassen sich groe Datenbestnde unbemerkt nach
auen schaffen. Derzeit noch bestehende Bandbreitenbeschrnkungen, die die
bertragung groer Datenmengen unattraktiv machen, werden in den nchsten
Jahren durch neue Technologien aufgehoben. Bei GSM betrgt die maximale
Datenbertragungsrate derzeit 9600 bps, bei den Protokollen der nchsten
Generationen (GPRS, UMTS) sind wesentlich hhere bertragungsraten
vorgesehen.
Auch eine nachtrgliche berprfung ist nicht immer mglich, da die
Verbindungsdaten beim Netzbetreiber schon gelscht sein knnen.
Beispiel:
- Ein Mitarbeiter eines Unternehmens wird aus einer Besprechung mit einem
Externen gerufen, um ein wichtiges Telefonat entgegenzunehmen. Der
Externe nutzt die kurze Zeitspanne ohne Beaufsichtigung, um den im
Besprechungsraum aufgestellten PC mit seinem GSM-Modem zu verbin-
den. Anschlieend initiiert er eine Datenbertragung zu einem Anschluss
seiner Wahl.
- Bei der Nutzung von Remote Access ber Mobiltelefon-Netze wird hufig
der CLIP-Mechanismus (Rufnummernbertragung) als Authentisierungs-
merkmal eingesetzt. Wird das Mobiltelefon gestohlen oder geht es ver-
loren, kann der Authentisierungsvorgang seine Funktion nicht mehr
ordnungsgem erfllen. Zwar muss nach dem Einschalten von Mobil-
telefonen meist eine PIN eingegeben werden, in der Regel sind die Tele-
fone jedoch eingeschaltet. Wird das Telefon in eingeschaltetem Zustand
gestohlen, so kann es prinzipiell sofort von Dritten benutzt werden. Durch
rechtzeitiges Aufladen der Akkus kann die Zwangsabschaltung wegen
Strommangel beliebig hinausgezgert werden und damit auch die Eingabe
der PIN nach dem erneuten Einschalten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.98 Abhren von Mobiltelefonaten

Die einfachste Art, ein ber ein Mobiltelefon gefhrtes Gesprch mitzuhren,
ist einfaches Zuhren in unmittelbarer Nhe. Sehr hufig kann man erleben,
wie durch lautes Telefonieren in der ffentlichkeit sehr viele Interna preis-
gegeben werden (siehe auch G 3.45 Unzureichende Identifikationsprfung von
Kommunikationspartnern).
Generell sind mit sehr hohem Aufwand aber auch technische Abhr-Metho-
den denkbar.
Wenn sich z. B. ein Angreifer Zugang zu den technischen Einrichtungen des
Netzbetreibers (Leitungen, Vermittlungseinrichtungen, Basisstationen) ver-
schaffen kann, ist er in der Lage, alle Telefongesprche abzuhren, die ber
diese Einrichtungen gefhrt werden. Dies gilt sowohl fr Verbindungen im
Mobilfunknetz als auch im Festnetz. Ein gezieltes Abhren von Gesprchen,
die einer bestimmten Rufnummer zugeordnet sind, ist aber angesichts der
riesigen Datenflut extrem aufwendig.
Werden die Verbindungen ber leitungsgebundene Wege von der Basisstation
zu der Mobilfunkvermittlung gefhrt, ist ein physikalischer Angriff auf den
Leitungswegen erforderlich. Wird eine Basisstation ber eine unverschlsselte
Richtfunkverbindung an die Mobilfunkvermittlung angebunden, was bei
einigen Netzbetreibern der Fall sein kann, besteht die Mglichkeit, diese
Funksignale mit Antennen und Spezialempfngern unbemerkt aufzufangen
und abzuhren. Die Gefhrdung kann sich ggf. dadurch erhhen, dass auf
diesen Richtfunkstrecken alle Telefonate der angebundenen Basisstation
bertragen werden.
Auch im Festnetz werden Telefongesprche gebndelt ber Richtfunkstrecken
bertragen. Da diese bertragung in der Regel unverschlsselt erfolgt, sind
die bertragenen Gesprche mit einigem technischen Aufwand auch dort
abhrbar.
Die Funkbertragung zwischen dem Mobiltelefon und der Basisstation wird in
Deutschland in allen GSM-Mobilfunknetzen verschlsselt. Es gibt spezielle
Angriffsgerte, die die Schwche der einseitigen Authentisierung im GSM-
Netz (nur Mobiltelefon gegenber Basisstation) ausnutzen, indem sie den
Mobiltelefonen eine Basisstation vortuschen, die Verschlsselung abschalten
und Klarbetrieb vorgeben. Abhngig von gesetzlichen Regelungen kann auch
in einigen Lndern die bertragungsverschlsselung ganz abgeschaltet sein.
Auch andere Sicherheitsparameter wie die Hufigkeit des Schlsselwechsels
knnen schwcher sein.
Andere denkbare Mglichkeiten zur Abschaltung dieser Verschlsselung sind
technische Manipulationen am Mobiltelefon oder an technischen Einrichtun-
gen des Netzbetreibers.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.99 Auswertung von Verbindungsdaten bei der

Nutzung von Mobiltelefonen
Bei der Mobil-Kommunikation knnen die bertragenen Signale auf der
Funkstrecke nicht physikalisch gegen unbefugtes Mithren und Aufzeichnen
abgeschirmt werden. Deshalb knnte ein Angreifer seinen Angriff ohne das
bei leitungsgebundener Kommunikation bekannte Zugriffsproblem
durchfhren. Ein zweites, generell bei den meisten Funkdiensten auftretendes
Problem resultiert daraus, dass die mobilen Kommunikationspartner aus
technischen Grnden geortet werden mssen, um erreichbar zu sein. Sofern
sie selbst eine Verbindung aufbauen, geben sie ebenfalls - im Zuge des
Verbindungsaufbaus - Informationen ber ihren Standort ab. Diese Standort-
Informationen knnten durch den Netzbetreiber oder Dienstbetreiber - aber
auch von Dritten - zur Bildung von Bewegungsprofilen verwendet werden.
Wenn einem Angreifer bestimmte Filtermerkmale ber ein Mobiltelefon
bekannt sind, knnte er (mit einem hohen technischen Aufwand) ber solche
Merkmale einzelne Telefonate identifizieren. Fr diese oder andere Angriffe
werden Kundennummer (IMSI), Mobilfunkgertenummer (IMEI) bzw.
Teilnehmerrufnummer (MSISDN) bentigt.
Die Ermittlung der Rufnummer MSISDN knnte durch einen Innentter
erfolgen, der z. B. in einer Firma Zugriff auf die dienstlichen oder privaten
Telefonlisten hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.100 Missbrauch aktiver Inhalte beim Zugriff auf

Lotus Notes
Funktionen von Lotus Notes Datenbanken werden vielfach dadurch imple-
mentiert, dass aktive Komponenten beim Eintreten gewisser Ereignisse (z. B.
Eingabe von Daten in ein Feld) ausgefhrt werden. Die aktiven Komponenten
bestehen dabei z. B. aus LotusScript- oder auch Java-Programmen und werden
auch Agenten genannt. Durch die Ausfhrung eines Agenten knnen
wiederum andere Agenten gestartet werden (z. B. wenn ein Agent Daten in
eine andere Datenbank kopiert und diese Aktion das Ausfhren von Agenten
der Zieldatenbank auslst). Generell kann zwischen serverseitiger und client-
seitiger Ausfhrung von Agenten unterschieden werden, es sind jedoch immer
beide Varianten mglich. Beim Web-Zugriff wird zustzlich die Benutzer-
schnittstelle der Datenbank durch aktive Inhalte, die im Browser ausgefhrt
werden (JavaScript, Java-Applets) realisiert.
Welche aktiven Inhalte in einem Notes-Client ausgefhrt werden knnen und fehlkonfigurierte ECL
welche Berechtigungen ihnen zugestanden werden, wird ber die Execution
Control List (ECL) gesteuert. Ist die ECL fehlkonfiguriert, so knnen die
aktiven Inhalte auch zum Angriff auf den Client genutzt werden. Dies gilt in
hnlicher Weise fr die Web-Schnittstelle, bei der keine ECL existiert,
sondern nur die Sicherheitsmechanismen des Browsers genutzt werden
knnen.
Bei falsch konfigurierter ECL knnten ber aktive Inhalte beispielsweise:
- Zugriff auf lokale Datenbestnde des Client-Rechners (Datenbanken,
Dateien, usw.) genommen und Daten "geraubt" werden,
- auf den Clients lokale Daten verndert oder gelscht werden und
- schdliche Programme, beispielsweise Computer-Viren oder trojanische
Pferde installiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.101 "Hacking Lotus Notes"

Die in den Datenbanken eines Notes-Servers gespeicherten Daten knnen
auch fr den ffentlichen Zugriff aus dem Internet bereitgestellt werden. Dies
stellt besondere Anforderungen an die Sicherheit des dazu benutzten Notes-
Servers. Sicherheitslcken knnen in diesem Fall dazu fhren, dass ein
Angreifer nicht nur unerlaubt auf den Notes-Server selbst zugreifen kann,
sondern u. U. auch in der Lage ist, in das dahinterliegende interne Netz einzu-
dringen.
Nachfolgend sind einige Problemfelder und potentielle Sicherheitslcken
aufgefhrt, die insbesondere beim ffentlichen Zugriff auf einen Notes-Server
aus dem Internet beachtet werden mssen.
- Das Kommunikations-Protokoll von Lotus Notes ist zur Zeit nicht Mechanismen nicht
offengelegt
offengelegt, so dass keine gesicherten Aussagen ber die Sicherheits-
mechanismen gemacht werden knnen. Auch bei entsprechender
Konfiguration muss mit einem Restrisiko gerechnet werden.
- Ein Notes-Server ist ein komplexes System. Ein Serververbund erhht die hohe Komplexitt
Komplexitt weiter. Durch die Komplexitt (auch der sicherheitsrelevanten
Einstellungen) kann es zu Fehlkonfigurationen und somit auch zu
Sicherheitslcken kommen.
- Durch den groen Funktionsumfang eines Notes-Servers und die mgliche Auswirkung auf andere
Systeme
Einbindung in entsprechende Hintergrundsysteme knnen Sicherheits-
lcken unter Umstnden von einem Notes-Server auf die Hintergrund-
systeme durchschlagen. Dabei gengt es in der Regel, eine einzelne
Schwachstelle in einem einzelnen Funktionspaket auszunutzen.
- An der Web-Schnittstelle existiert keine Beschrnkung fr Fehlversuche Brute-Force-Angriff
bei der Authentisierung. Mit Hilfe von Browser-Clients knnen Angreifer
deshalb beliebig oft versuchen, sich mit wechselnden Benutzernamen und
Passwrtern an einem Notes-Server anzumelden und auf diese Weise
unberechtigt Zugriff zu erlangen.
- Ist der Web-Zugriff auf einen Notes-Server aktiviert, betrifft dies immer direkter
Datenbankzugriff
alle Datenbanken auf dem jeweiligen Server. Dies kann leicht fr
vorstzliche Angriffe ausgenutzt werden, wenn nicht fr jede Datenbank
sichere Zugriffsrechte vergeben sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.102 Sabotage
Sabotage bezeichnet die mutwillige Manipulation oder Beschdigung von
Sachen mit dem Ziel, dem Opfer Schaden zuzufgen. Besonders attraktive
Ziele knnen Rechenzentren oder Kommunikationsanbindungen von Behr-
den bzw. Unternehmen sein, da hier mit relativ geringen Mitteln eine groe
Wirkung erzielt werden kann.
Die komplexe Infrastruktur eines Rechenzentrums kann durch gezielte Beein- punktuelle Manipulation
flussung wichtiger Komponenten, gegebenenfalls durch Tter von auen, vor
allem aber durch Innentter punktuell manipuliert werden, um Betriebsst-
rungen hervorzurufen. Besonders bedroht sind hierbei nicht ausreichend
geschtzte gebudetechnische oder kommunikationstechnische Infrastruktur
sowie zentrale Versorgungspunkte, die organisatorisch oder technisch gegebe-
nenfalls auch nicht berwacht werden und fr Externe leicht und unbeobachtet
zugnglich sind.
Beispiele:
- In einem groen Rechenzentrum fhrte die Manipulation an der USV zu Stromversorgung
einem vorbergehenden Totalausfall. Der Tter, er wurde ermittelt, hatte
wiederholt die USV von Hand auf Bypass geschaltet und dann die Haupt-
stromversorgung des Gebudes manipuliert. Der Totalausfall - insgesamt
fanden in drei Jahren vier Ausflle statt - fhrte partiell sogar zweimal zu
Hardware-Schden. Die Betriebsunterbrechungen dauerten zwischen 40
und 130 Minuten.
- Innerhalb eines Rechenzentrums sind auch sanitre Einrichtungen unterge- Wassereinbruch
bracht. Durch Verstopfen der Abflsse und gleichzeitiges ffnen der
Wasserzufuhr entstehen durch Wassereinbruch in zentralen Technikkom-
ponenten Schden, die zu Betriebsunterbrechungen des Produktivsystems
fhren.
- Fr elektronische Archive stellt Sabotage ein besonderes Risiko dar, da elektronische Archive
hier meist auf kleinem Raum viele schtzenswerte Dokumente verwahrt
werden. Dadurch kann unter Umstnden durch gezielte, wenig aufwendige
Manipulationen ein groer Schaden verursacht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.103 Missbrauch von Webmail

Wenn Benutzerangaben nicht ausreichend geprft werden, kann sich ein Vorspiegelung einer
Angreifer eine E-Mail-Adresse auf den Namen einer anderen Person besorgen falschen Identitt
und damit z. B. durch Spammails oder Beschimpfungen unter diesem Namen
deren Ruf unterminieren. Wenn die E-Mail-Adressen bei einem Anbieter frei
gewhlt werden knnen, kann sich ein Angreifer eine Adresse aussuchen, mit
der andere Benutzer bestimmte Assoziationen verbinden und diese damit zu
unvorsichtigem Verhalten animieren.
Bei vielen Webmail-Anbietern ist der Benutzername fr den Zugriff auf die Passwort austesten
Postfcher identisch mit der E-Mail-Adresse bzw. lsst sich daraus einfach
ableiten. Wenn dann das Passwort nicht gut genug gewhlt worden ist oder
beliebig viele Fehleingaben mglich sind, kann ein Angreifer durch simples
Ausprobieren das Passwort herausbekommen und hat dann freien Zugriff auf
das Benutzerkonto.
Durch falsch verstandene Benutzerfreundlichkeit wird es potentiellen Passwort "vergessen"
Angreifern auch teilweise sehr einfach gemacht, sich ein Passwort und damit
vollen Zugriff fr ein fremdes Postfach geben zu lassen. Ein typisches
Beispiel ist ein Mailprovider, der auf der Einstiegsseite schon einen Link
"Passwort vergessen?" anbietet, durch den man dann zu einer Seite weiter-
geleitet wird, auf der nach einem vorher vereinbarten, nicht schwer zu errate-
nen Angabe des Postfach-Inhabers gefragt wird. Beliebt ist hier das Geburts-
datum, bei dessen Erraten auch noch durch Angaben wie "Der Monat ist nicht
korrekt" weitergeholfen wird.
Beispiele:
- In dem Beispiel in G 5.40 Abhren von Rumen mittels Rechner mit
Mikrofon wird geschildert, wie eine deutsche Politikerin in einer geflsch-
ten Virenwarnung per E-Mail aufgefordert wurde, ein als Anlage mitge-
schicktes Schutzprogramm zu ffnen, welches aber ein Trojanisches Pferd
enthielt. Diese E-Mail hatte den Absender support@xyz.de und kam aus
der Domain ihres E-Mail-Providers XYZ. Eine E-Mail von einem Absen-
der, den sie als unbekannt eingestuft htte, htte sie wahrscheinlich nicht
geffnet.
- Im Webmail-Angebot Hotmail sind bereits mehrmals Sicherheitslcken
bekannt geworden. Zu Problemen fhrt insbesondere in E-Mails eingebet-
tetes Javascript, das dann beim Lesen der E-Mail im Browser des Empfn-
gers ausgefhrt wird. Dadurch kann der Benutzer beispielsweise durch
einen Angreifer dazu aufgefordert werden, sein Passwort erneut
einzugeben und dieses anschlieend an den Angreifer bermittelt wird. Da
Javascript auf mehrere unterschiedliche Arten in HTML-formatierte
E-Mails eingebettet werden kann, gab es in der Vergangenheit Lcken
beim Herausfiltern dieser aktiven Inhalte.
Bei aktuellen Virenwarnungen kann es einige Stunden dauern, bis die unsicheres Zeitfenster
beim Virenschutz
Hersteller der Virenschutzprogramme die ersten wirksamen Updates bereit
stellen knnen und diese erfolgreich auch auf allen IT-Systemen installiert
sind. E-Mails, die in dieser Zeit auf dem E-Mail-Server eintreffen, knnen
dort solange in Quarantne genommen werden. Wenn nicht gleichzeitig auch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
verhindert wird, dass E-Mails ber Webmail-Accounts abgerufen werden,

knnen hierber PCs und Server im LAN infiziert werden.
Beispiel:
- Ende September 2001 verursachte der Virus Nimda etliches an rger und
Aufregung. Nimda ist ein Wurm mit mehreren Schadfunktionen. Er
verbreitet sich mittels Anhang von E-Mails, ber eine bekannte Schwach-
stelle des Internet Information Server (IIS) von Microsoft sowie ber frei-
gegebene Laufwerke. Es dauerte teilweise bis zu 24 Stunden, ehe nach
Bekanntwerden des ersten Auftretens wirksame Signaturen fr Viren-
schutzprogramme zur Verfgung standen. In einigen groen Unternehmen
infizierten Benutzer ihre PCs ber Webmail mit Nimda. ber diese wurden
dann IIS-Webserver innerhalb des Firmennetzes infiziert, was wiederum zu
erheblichen Beeintrchtigungen im LAN fhrte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.104 Aussphen von Informationen

Neben einer Vielzahl technisch komplexer Angriffe gibt es oft auch viel
einfachere Methoden, um an wertvolle Informationen zu kommen. Da sensi-
tive Daten oft nicht ausreichend geschtzt werden, knnen diese oft auf
optischem, akustischem oder elektronischen Weg ausgespht werden.
Beispiele:
- Die meisten IT-Systeme sind durch Identifikations- und Authentisierungs- unverschlsseltes
Passwort
mechanismen gegen eine unberechtigte Nutzung geschtzt, z. B. in Form
von Benutzer-ID- und Passwort-Prfung. Wenn das Passwort allerdings
unverschlsselt ber die Leitung geschickt wird, ist es einem Angreifer
mglich, dieses auszulesen.
- Um mit einer ec- oder Kreditkarte Geld an einem Geldausgabeautomaten unzureichender
Sichtschutz
abheben zu knnen, muss die korrekte PIN eingegeben werden. Leider ist
der Sichtschutz an diesen Gerten hufig unzureichend, so dass ein Angrei-
fer einem Kunden bei der Eingabe der PIN ohne Mhe ber die Schulter
schauen kann. Wenn er ihm hinterher die Karte stiehlt, kann er damit das
Konto plndern. Der Kunde hat anschlieend auerdem das Problem, dass
er nachweisen muss, nicht fahrlssig mit seiner PIN umgegangen zu sein,
sie also beispielsweise nicht auf der Karte notiert hat.
- Um Zugriffsrechte auf einem Benutzer-PC zu erhalten oder diesen ander- Trojanisches Pferd
weitig zu manipulieren, kann ein Angreifer dem Benutzer ein Trojanisches
Pferd schicken, das er als vorgeblich ntzliches Programm einer E-Mail
beigefgt hat. Erfahrungsgem ffnen Benutzer trotz aller Aufklrung
sogar dann E-Mail-Anhnge, wenn diese nicht erwartet wurden oder
merkwrdige Namen tragen. Neben unmittelbaren Schden knnen ber
Trojanische Pferde Informationen nicht nur ber den einzelnen Rechner,
sondern auch ber das lokale Netz ausspht werden. Insbesondere verfol-
gen viele Trojanische Pferde das Ziel, Passwrter oder andere Zugangs-
daten auszusphen.
- In vielen Bros sind die Arbeitspltze akustisch nicht gut gegeneinander Mithren von
Gesprchen
abgeschirmt. Dadurch knnen Kollegen, aber auch Besucher unter
Umstnden Gesprche mitgehren und dabei Kenntnis von Informationen
erlangen, die nicht fr sie bestimmt oder sogar vertraulich sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.105 Verhinderung der Dienste von Archivsystemen

Die Dienste eines elektronischen Archivs bestehen aus den folgenden Grund-
funktionen:
- Erfassen und Indizieren der zu archivierenden Dokumente,
- Verwalten und Speichern der Dokumente,
- Suchen und Finden archivierter Dokumente,
- Visualisieren und Reproduzieren der Dokumente sowie
- Pflegen und Administrieren des Archivsystems.
Wenn die Dienste eines Archivsystems gestrt werden, knnen Schden ent-
stehen, wie die folgenden Beispiele erlutern sollen:
- Wird die Indizierung von archivierten Daten verhindert oder gestrt, z. B. Indizierung
durch die Angabe falscher Kontextdaten, so hat das unter Umstnden zur
Folge, dass Daten spter gar nicht oder nur unter erheblichem Aufwand
wiedergefunden werden knnen.
- Wird die Archivierung neuer Daten verhindert oder blockiert, indem z. B. Archivierung
durch einen Denial-of-Service-Angriff die Netzverbindung des Archivsys-
tems blockiert wird, so kann das zur Folge haben, dass je nach Datenauf-
kommen ein erheblicher Rckstau entsteht, der nicht durch Backup gesi-
chert ist. Bei einem Systemausfall wre dann mit dem Verlust derjenigen
Dokumente zu rechnen, die noch zur Archivierung anstehen. Wenn ein Ar-
chivsystem ausgewhlt wird, das keine fr den Benutzer sichtbare Archiv-
besttigung erzeugt, so besteht das Risiko, dass eventuelle Dokumentver-
luste zunchst unerkannt bleiben. Wenn andererseits ein System mit Ar-
chivbesttigung eingesetzt wird, so kann ein Ausbleiben der Besttigung
nachfolgende Geschfts- oder Verwaltungsvorgnge ebenfalls verzgern.
- Wird die Reproduktion archivierter Daten unterbunden, gestrt oder ver- Reproduktion
zgert, so kann das zur Folge haben, dass erforderliche Dokumente nicht
termingerecht beigebracht werden knnen, wodurch sich wirtschaftliche
Schden oder rechtliche Nachteile ergeben knnen.
- Wenn die Administration des Archivsystems behindert oder verzgert Administration
wird, z. B. durch berlastung des Personals mit Anfragen, so kann es vor-
kommen, dass Personen, denen der Zugriff gesperrt werden soll, weiterhin
Zugriff auf das Archiv haben und dort unberechtigt Dokumente einstellen
oder abrufen.
- Durch Behinderung der Administration knnen auch dann Schden
hervorgerufen werden, wenn dadurch die Wartung des Archivsystems be-
eintrchtigt oder verzgert wird. Mglicherweise knnen dadurch sicher-
heitsrelevante Software-Updates nicht zeitgerecht eingespielt oder nicht
ausreichend getestet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.106 Unberechtigtes berschreiben oder Lschen

von Archivmedien
Auf Archivmedien sollen wichtige Daten langfristig und unverndert ge-
speichert werden. Daher drfen diese nicht unberechtigt berschrieben, ge-
lscht oder anderweitig verndert werden. Unberechtigtes Lschen ist dann
mglich, wenn Benutzerrechte falsch vergeben worden sind, d. h. wenn
- Benutzer das Recht zum "Lschen" haben, sie aber aufgrund der ihnen zu
Verfgung stehenden Informationen keine sinnvolle Entscheidung treffen
knnen, ob Datenstze gelscht werden drfen oder nicht, oder
- durch fehlerhafte Administration Benutzer flschlicherweise die Berech-
tigung zum "Lschen" haben.
Hierbei sind wiederbeschreibbare Medien und WORM-Medien zu unter-
scheiden:
- Bei wiederbeschreibbaren Medien ist ein physikalisches Lschen oder
berschreiben von Datenstzen grundstzlich mglich.
- Bei WORM-Medien ist ein physikalisches Lschen oder berschreiben
grundstzlich nicht mglich. Allerdings bieten Archivierungssysteme in
der Regel die Mglichkeit, Datenstze logisch als gelscht zu markieren.
Diese Datenstze werden beim Umkopieren auf einen neuen Datentrger
dann nicht mehr mitkopiert. Sie werden also erst im Moment des
Kopierens auf den neuen Datentrger aus den Datenbestnden entfernt.
In beiden Fllen kann es also bei falschem Umgang mit den Medien zu einem
Integrittsverlust der gespeicherten Informationen und Daten kommen (siehe
hierzu auch G 5.85 Integrittsverlust schtzenswerter Informationen).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.107 Weitergabe von Daten an Dritte durch den

Outsourcing-Dienstleister
Outsourcing-Dienstleister haben in der Regel mehrere Kunden. Es ist daher Weitergabe von Daten an
immer mglich, dass sich darunter auch Wettbewerber befinden. Dies ergibt Konkurrenten
sich vor allem bei groen Outsourcing-Dienstleistern und solchen, die spe-
zielle Anforderungsbereiche wie IT-Sicherheitsdienstleistungen abdecken.
Wenn ein Outsourcing-Partner parallel die Auftrge zweier Konkurrenzorga-
nisationen bearbeitet, kann es zu Interessenskonflikten kommen, sofern keine
strikte Trennung der Auftragsbearbeitung vorgenommen wird (Mandantenf-
higkeit des Outsourcing-Dienstleisters).
In derartigen Situationen knnten mglicherweise Arbeitsergebnisse und Er-
kenntnisse aus der Projektbearbeitung durch Mitarbeiter oder Unterauftrag-
nehmer des Dienstleisters absichtlich dem Mitbewerber direkt verfgbar ge-
macht werden. Ein so entstandener Schaden ist in aller Regel nicht mehr zu
beheben, auch wenn einzelne Personen oder der Outsourcing-Dienstleister als
ganzes spter juristisch zur Verantwortung gezogen werden kann.
Werden im Rahmen des Outsourcing-Vorhabens personenbezogene Daten Datenschutz
beim Dienstleister verarbeitet oder gespeichert, so mssen auch zustzliche
Datenschutzgesichtspunkte beachtet werden. Werden etwa Kundeninformati-
onen eines Auftraggebers kompromittiert und verffentlicht, so besteht die
Gefahr, dass das Vertrauensverhltnis zwischen dem Auftraggeber und seinen
Kunden nachhaltig gestrt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.108 Ausnutzen von systemspezifischen

Schwachstellen des IIS
Wie bei fast jeder Software zeigen sich viele kleinere Programmier- und Ent-
wicklungsfehler erst im praktischen Einsatz. Auch bei Windows und beim IIS
werden immer wieder systemspezifische Schwachstellen entdeckt, die auf
Programmier- und Entwicklungsfehler zurckzufhren sind. Unter bestimm-
ten Voraussetzungen wird z. B. ein Buffer-Overflow verursacht. Insbesondere
beim Zusammenwirken mit anderen Sofware-Komponenten besteht die
Gefahr, dass Parameter ungengend geprft werden und die Funktionsweise
des System beeinflussen knnen.
Sicherheitsrisiken entstehen nicht nur durch Programmier- und Entwicklungs-
fehler, auch vorhandene Beispielanwendungen und Scriptdateien knnen fr
einen Angriff auf das System ausgenutzt werden.
Bei der Standardinstallation eines IIS wird eine Reihe von Beispielanwen-
dungen und Scriptdateien mit installiert. Diese Beispiele zeigen dem Admi-
nistrator bzw. Entwickler Anwendungsmglichkeiten des Web-Servers auf
oder dienen als Vorlage fr erweiterte Funktionen, z. B. Suchfunktionen.
Viele Administratoren und Entwickler haben keine Kenntnisse ber den voll-
stndigen Funktionsumfang und ggf. die Existenz solcher Beispielanwendun-
gen. Da diese Anwendungen und Scriptdateien u. U. von einem Angreifer
ausgenutzt werden knnen, geht von ihnen eine erhebliche Gefahr fr das
Informationssystem aus.
Beispiel 1:
Mit Hilfe so genannter Escape-Sequenzen in URLs kann eine DoS-Attacke
(Denial-of-Service) auf den IIS durchgefhrt werden. Escape-Sequenzen bie-
ten die Mglichkeit, nicht druckbare Zeichen oder Sonderzeichen einzufgen.
Diese Sequenzen bestehen aus einem Escape-Character, z. B. "%", und zwei
hexadezimalen Ziffern. Auf dem Zielsystem werden diese Zeichen in den
entsprechenden ASCII-Code umgesetzt. Beispielsweise wird der Zeichenfolge
%20 ein Leerzeichen (Blank, Space) zugeordnet.
Werden sehr viele Escape-Sequenzen in einer URL verwendet, kann dies bei
der Umsetzung zu einer vollstndigen Auslastung des Prozessors fhren,
wodurch der IIS z. B. keine regulren Anfragen mehr beantworten kann. Ein
Beispiel hierfr zeigt der Microsoft Security Bulletin MS00-023
(http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/fq00-023.asp).
Beispiel 2:
Im Umfang der Standardinstallation eines IIS 4.0 ist eine Anwendung enthal-
ten, die es einem Web-Benutzer erlaubt, das Passwort eines Benutzerkontos
auf dem Web-Server zu ndern. Jeder Benutzer, der Zugriff auf diese Seite hat
(ber HTTP), kann darber gltige Benutzerkonten auf dem Server
herausfinden. Da die Rckmeldungen des Web-Servers Auskunft ber
getestete Benutzerkonten geben, kann diese Schnittstelle fr eine Brute-Force-
Attacke auf die Konten ausgenutzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel 3:
Durch eine Schwachstelle in der Web-Seite showcode.asp sind Internet-
Benutzer in der Lage, sich Dateien vom Web-Server anzeigen zu lassen. Wenn
nicht sichergestellt ist, dass ein Ausbrechen aus dem Webroot-Verzeichnis mit
Hilfe der Zeichenfolge /../ ausgeschlossen ist, knnen mit diesem Script auch
Dateien aus anderen Verzeichnissen, z. B. WINNT, ausgelesen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.109 Ausnutzen systemspezifischer Schwachstellen

beim Apache-Webserver
Wie jede Software ist auch der Apache-Webserver nicht frei von
Schwachstellen und Programmierfehlern. Insgesamt ist der Apache-Webserver
zwar von so spektakulren Vorfllen wie dem Nimda-Wurm bisher
weitgehend verschont geblieben, jedoch trat beispielsweise im Herbst 2002
der Wurm Slapper auf, der sich eine Sicherheitslcke in der OpenSSL-
Bibliothek zu Nutze machte und sich ber Apache-Webserver verbreitete, die
SSL benutzten. Systemspezifische Schwachstellen beim Apache-Webserver
finden sich entweder im eigentlichen Webserver oder in Modulen wie
mod_ssl, mod_dav, mod_rewrite, mod_php oder hnlichen Erweiterungen.
Durch Ausnutzen von Schwachstellen (beispielsweise Buffer-Overflows) im
Apache-Webserver oder in Erweiterungsmodulen knnen Angreifer im
Extremfall den Serverrechner kompromittieren. Da der Apache-Webserver
meist unter einem nicht privilegierten Account luft, ist zwar das direkte
Erlangen von root- oder Administratorrechten meist nicht mglich, hat ein
Angreifer aber bereits einen Zugang zum Serverrechner selbst erlangt, so kann
er durch Ausnutzen lokaler Schwachstellen des Betriebssystems oder anderer
installierter Programme oft recht leicht erweiterte Berechtigungen erlangen.
Selbst wenn fr eine Schwachstelle kein Exploit bekannt ist, der dadurch, dass
ein Angreifer eigenen Code auf dem Serverrechner ausfhren kann, zu einer
Kompromittierung des Rechners fhrt, knnen Buffer-Overflows und hnliche
Schwachstellen dazu ausgenutzt werden, den Apache-Webserver zum Absturz
zu bringen und so einen Denial-of-Service herbei zu fhren.
Schwachstellen im Apache-Webserver oder in Erweiterungsmodulen knnen
auch dazu fhren, dass Zugriffsbeschrnkungen umgangen werden knnen
und so eventuell vertrauliche Dateien an unberechtigte Besucher ausgeliefert
werden. Auerdem ist es mglich, dass durch eine Sicherheitslcke
Konfigurationsinformationen (wie Installationspfade oder Systempfade zu
WWW-Dateien) nach auen gelangen. Solche Informationen knnen Angriffe
erleichtern, da die Angreifer in einem solchen Fall keine Pfade durchprobieren
mssen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.110 Web-Bugs
Als Web-Bugs werden in E-Mail oder WWW-Seiten eingebettete Bilder be-
zeichnet, die beim ffnen von einem fremden Server nachgeladen werden.
Diese Bilder knnen sehr klein sein, beispielsweise ein mal ein Pixel groe
Minigrafiken. Die Bilder sind so eingebettet, dass sie im allgemeinen nicht
sichtbar sind, aber beim Laden vom Ursprungsserver die Ausfhrung eines
Skripts oder Programms veranlassen.
Werden Web-Bugs in HTML-formatierte E-Mails eingebettet, kann dadurch E-Mail
der Absender z. B. erkennen, welche E-Mail wann gelesen wurde. Beispiels-
weise im Zusammenhang mit unverlangt versendeten Massen-E-Mails kann
dies unerwnscht sein.
Bei der Nutzung des World Wide Web mssen Benutzer grundstzlich damit WWW
rechnen, dass auer zu dem Server, dessen WWW-Angebot sie gerade nutzen,
auch zu anderen Servern Verbindungen aufgebaut werden. Dies ist zum Bei-
spiel der Fall, wenn von einer WWW-Seite aus Bilder referenziert werden, die
auf einem anderen Server liegen. Obwohl dies im Prinzip ein normaler Vor-
gang ist, knnen unter Umstnden ber diesen Mechanismus ungewollt In-
formationen an Dritte bertragen werden, wie das unten beschriebene Beispiel
zeigt. Insbesondere knnen hierdurch vertrauliche Daten des Benutzers oder
des Server-Betreibers kompromittiert werden.
Beispiel:
Eine Universitt verwendet ein frei im Internet erhltliches Software-Paket,
um dynamische Inhalte auf dem WWW-Server anzubieten (CGI-Skripten).
Abhngig von den Eingaben des Benutzers generiert die Software auf dem
WWW-Server passende Antwort-Seiten und schickt sie an den Benutzer. Ne-
ben den eigentlichen Inhalten enthalten die generierten HTML-Seiten aber
auch Verweise auf Bilder, die sich nicht auf dem Server der Universitt, son-
dern des Programmierers der CGI-Skripten befinden. Als Folge werden diese
Bilder jedesmal vom Server des Programmierers abgerufen, wenn ein Benut-
zer auf das Internet-Angebot der Universitt zugreift. Auf diese Weise erhlt
der Programmierer ausfhrliche Informationen ber die Nutzung des von ihm
entwickelten Software-Pakets, aber leider auch ber die Nutzung des Internet-
Angebots der Universitt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.111 Missbrauch aktiver Inhalte in E-Mails

Immer mehr E-Mails sind heutzutage auch HTML-formatiert. Einerseits ist Bunt, aber gefhrlich!
dies oft lstig, weil nicht alle E-Mail-Clients dieses Format anzeigen knnen.
Andererseits kann dies auch dazu fhren, dass bereits bei der Anzeige solcher
E-Mails auf dem Client ungewollte Aktionen ausgelst werden, da HTML-
Mail z. B. eingebetteten JavaScript- oder VisualBasic-Skript-Code enthalten
kann.
Durch Kombination verschiedener Sicherheitslcken in E-Mail-Clients und
Browsern ist es in der Vergangenheit immer wieder zu Sicherheitsproblemen
mit HTML-formatierten E-Mails gekommen (siehe auch G 5.110 Web-Bugs).
Ein Beispiel hierfr findet sich unter anderem im CERT-Advisory CA-2001-
06 (unter http://www.cert.org/advisories/CA-2001-06.html).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.112 Manipulation von ARP-Tabellen

ARP-Spoofing
Im Gegensatz zu einem Hub kann bei einem Switch grundstzlich die
Kommunikation zwischen zwei Stationen von keiner der anderen Stationen
abgehrt werden. Zu diesem Zweck pflegt der Switch eine Tabelle, die die
MAC-Adressen der beteiligten Stationen den verschiedenen Ports zuordnet.
Datenpakete beziehungsweise Ethernet-Frames, die an eine bestimmte MAC-
Adresse adressiert sind, werden nur an den Port weitergeleitet, an dem der
betreffende Rechner angeschlossen ist.
Doch nicht nur der Switch pflegt eine ARP-Tabelle, sondern auch die
beteiligten Rechner. Ziel des ARP-Spoofings ist es, diese Tabellen zu
manipulieren (ARP-Cache-Poisoning). Dazu schickt ein Angreifer eine ARP-
Antwort an das Opfer, in der er seine eigene MAC-Adresse als die des Routers
ausgibt, der fr das betreffende Subnetz als Standard-Gateway fungiert.
Sendet das Opfer anschlieend ein Paket zum eingetragenen Standard-
Gateway, landet dieses Paket in Wirklichkeit beim Angreifer. Auf die selbe
Weise wird der ARP-Cache des Routers so manipuliert, dass Ethernet-Frames,
die eigentlich an das Opfer adressiert wurden, in Wirklichkeit beim Angreifer
landen. Auf einschlgigen Internet-Seiten sind eine Reihe von Tools
verfgbar, die diese Angriffsmethode ermglichen.
MAC-Flooding
MAC-Flooding ist eine Angriffsmethode, die die Funktionsweise eines
Switches beeinflusst. Switches erlernen angeschlossene MAC-Adressen
dynamisch. Die MAC-Adressen werden in der Switching-Tabelle gespeichert.
Der Switch wei dadurch, an welchen Ports die entsprechenden MAC-
Adressen angeschlossen sind.
Wenn nun eine angeschlossene Station mit Hilfe eines geeigneten Tools eine
Vielzahl von Paketen mit unterschiedlichen Quell-MAC-Adressen sendet,
speichert der Switch diese MAC-Adressen in seiner Switching-Tabelle.
Sobald der Speicherplatz fr die Switching-Tabelle gefllt ist, sendet ein
Switch smtliche Pakete an alle Switch-Ports. Durch dieses "Fluten" der
Switching-Tabelle mit sinnlosen MAC-Adressen kann ein Switch nicht mehr
feststellen, an welche Ports tatschliche Ziel-MAC-Adressen angeschlossen
sind. Diese Angriffsmethode wird verwendet, um das Mitlesen von Paketen in
geswitchten Netzen zu ermglichen. Es sind frei verfgbare Tools auf
einschlgigen Seiten im Internet verfgbar, die auf einem Switch 155.000
MAC-Adress-Eintrge innerhalb einer Minute erzeugen knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.113 MAC-Spoofing
Die MAC-Adresse ("media access control") eines Gerts ist eine vom
Hersteller vorgegebene Adresse, mit der Gerte auf der OSI-Schicht 2
adressiert werden.
Verschiedene Sicherungsmechanismen auf der Netzebene (beispielsweise
Port-Security bei Switches) beruhen darauf, dass eine Verbindung nur von
einem Gert mit einer bestimmten MAC-Adresse aufgebaut werden darf.
Mit Hilfe entsprechender Programme kann ein Angreifer die MAC-Adresse
seines Gertes ndern und Ethernet-Frames mit einer fremden Kennung in das
Netzsegment schicken. Auf diese Weise knnen Sicherungsmechanismen
umgangen werden, die allein auf der Verwendung einer MAC-Adresse
beruhen. Der Angreifer muss sich dabei allerdings im selben Netzsegment
befinden oder sogar Zugang zu demselben Switchport haben wie das Gert,
als das er sich mittels MAC-Spoofing ausgibt.
Eine Gefhrdung durch MAC-Spoofing besteht auch bei drahtlosen Netzen
(WLAN), bei denen am Access-Point eine entsprechende Zugangskontrolle
konfiguriert wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.114 Missbrauch von Spanning Tree

Das Spanning Tree Protokoll ist in IEEE 802.1d spezifiziert. Spanning Tree
wird verwendet, um Schleifenbildungen innerhalb eines Netzes mit mehreren
Switches zu vermeiden. Bei diesem Verfahren werden redundante
Netzstrukturen ermittelt und in eine zyklenfreie Struktur abgebildet. Diese
Manahme reduziert die aktiven Verbindungswege einer beliebig vermaschten
Netzstruktur auf eine Baumstruktur.
In der folgenden Abbildung ist zu erkennen, dass ein Port des unteren
Switches mit Hilfe von Spanning Tree geblockt wurde. Durch Aussenden von
Bridge Protocol Data Units (BPDUs), wird eine Root-Bridge, basierend auf
der eingestellten Prioritt und MAC-Adresse des Switches, ermittelt. In der
Abbildung stellt der Switch rechts oben die Root Bridge dar.
Abbildung 1: Spanning Tree

Spanning Tree bietet keine Authentisierung beim Austausch von BPDUs. Dies
kann in geswitchten Netzen durch Angreifer ausgenutzt werden. Wenn ein
Angreifer von einer am Switch angeschlossenen Station in der Lage ist,
BPDUs auszusenden, wird mit Hilfe des Spanning Tree-Algorithmus die
Topologie neu berechnet. Die Konvergenz zur Berechnung der Topologie-
nderung kann beim Spanning-Tree 30 Sekunden betragen. Dadurch kann bei
der Aussendung von BPDUs die Verfgbarkeit des Netzes empfindlich gestrt
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.115 berwindung der Grenzen zwischen VLANs

Virtual LANs (VLANs) werden zur logischen Strukturierung von Netzen
verwendet. Dabei wird innerhalb eines physikalischen Netzes eine logische
Netzstruktur abgebildet, indem funktionell zusammengehrende
Arbeitsstationen und Server zu einem virtuellen Netz verbunden werden. Ein
VLAN bildet gleichzeitig eine separate Broadcast-Domne. Das bedeutet, dass
Broadcasts nur innerhalb des VLANs verteilt werden. Ein VLAN kann sich
hierbei ber ein ganzes geswitchtes Netz hinziehen und braucht nicht nur auf
einen einzelnen Switch beschrnkt zu bleiben.
VLANs ber mehrere Switches auszudehnen, wird durch unterschiedliche
sogenannte Trunking-Protokolle realisiert. Hierbei wird pro Switch ein
physischer Port fr die Inter-Switch-Kommunikation reserviert, die logische
Verbindung zwischen den Switches wird als Trunk bezeichnet. Ein Ethernet-
Rahmen wird beim Informationsaustausch zwischen den Switches in das
Trunking-Protokoll gekapselt. Dadurch ist der Ziel-Switch in der Lage, die
Information dem entsprechenden VLAN zuzuordnen. Als Standards werden
IEEE 802.1q und die proprietren Protokolle ISL (Inter Switch Link) und VTP
(VLAN Trunking Protocol) des Herstellers Cisco verwendet.
Wenn sich ein Angreifer, der an einem Switch angeschlossen ist
beispielsweise durch die Verwendung der Trunking-Protokolle ISL (Inter
Switch Link) oder IEEE 802.1q als Switch ausgibt, ist es mglich, dadurch auf
alle konfigurierten VLANs Zugriff zu erhalten und so Daten mitzulesen, die
zu einem VLAN gehren, auf das der Angreifer normalerweise keinen Zugriff
hat.
Mit Hilfe des proprietren Protokolls VTP werden Informationen ber
konfigurierte VLANs zwischen Cisco-Switches ausgetauscht. Dabei ist es
mglich, die VLAN-Konfiguration eines zentralen VTP-Servers innerhalb
einer VTP-Domne auf alle beteiligten Switches zu verteilen. Dies vereinfacht
zwar die Verwaltung von VLANs mit mehreren Switches, stellt gleichzeitig
aber ein zustzliches Sicherheitsrisiko dar: VTP untersttzt zwar die
Authentisierung innerhalb einer VTP-Domne, falls jedoch kein Passwort fr
die Authentisierung von Switches innerhalb einer Domne gesetzt ist, kann
ein Angreifer (beispielsweise auf einem eigenen Switch, der als VTP-Server
konfiguriert ist) die gesamte VLAN-Architektur auf Switches der VTP-
Domne berschreiben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.116 Manipulation der z/OS-Systemsteuerung

z/OS-Systeme lassen sich ber vielfltige Schnittstellen beeinflussen, zum
Beispiel ber die Hardware Management Console, die MVS-Master-Konsole,
den Enhanced MVS Console Service, Automationsverfahren, entfernte MVS-
Konsole und Fernwartungszugnge. Einige Sicherheitsprobleme, die mit der
Verwendung dieser Schnittstellen verbunden sein knnen, werden
nachfolgend aufgezeigt.
HMC (Hardware Management Console)
Der unbefugte Zugriff auf die HMC kann zu erheblichen
Sicherheitsproblemen fhren. Denn von der HMC aus kann das
Systemverhalten whrend des Betriebs beeinflusst werden. Es knnen
einzelne LPARs (Logical Partitions) bis hin zu einem ganzen Rechner-
Verbund neu initialisiert werden. Darber hinaus lassen sich ber die HMC
auch neue Input/Output Control Datasets einspielen, die beim nchsten Initial
Program Load (IPL) aktiv werden. Dadurch besteht zum Beispiel die Gefahr,
dass einer LPAR eigentlich nicht zugehrige Platten zugewiesen werden.
MVS-Master-Konsole
z/OS-Betriebssysteme werden unter anderem ber MVS-Konsolen gesteuert.
Die Standard-Konsolen sind mit dem System fest verbunden und bentigen
weder Kennung noch Passwort. Das bedeutet, dass Personen, die physischen
Zugriff auf eine hoch autorisierte MVS-Konsole haben (z. B. auf die Master-
Konsole), jedes beliebige MVS-Kommando eingeben knnen. In der Folge
knnen unbefugt Batch-Jobs oder Started Tasks gestoppt oder gestartet
werden. Ferner lassen sich Platten an jedem System Online setzen, falls sie
dort generiert sind. Unter Umstnden lassen sich auch ber MVS-Kommandos
Kanalpfade nachgenerieren, und danach Platten anhngen, die gar nicht zu
dieser LPAR gehren.
Enhanced MVS Console Service
ber die normalen MVS-Konsolen hinaus stellt das z/OS-Betriebssystem den
EMCS (Enhanced MVS Console Service) zur Verfgung. Dieser wird von
verschiedenen Anwendungen, wie zum Beispiel TSO, CICS oder NetView,
auch als Funktion angeboten. ber EMCS knnen dynamisch Konsolen im
Rahmen eines Script-Ablaufs angelegt werden, die nahezu alle Kommandos
untersttzen, die auch bei den normalen Konsolen benutzt werden knnen.
Wird EMCS nicht oder unzureichend ber RACF-Profile geschtzt, kann
u. U. von jedem Terminal aus das z/OS-Betriebssystem manipuliert werden.
Gefahren bei Automation
Automationsverfahren knnen so programmiert sein, dass sie durch
Nachrichten ausgelst werden. Wenn die Automationsverfahren nicht speziell
geschtzt werden, besteht die Gefahr, dass durch das Erzeugen einer
geflschten Nachricht Automationsfunktionen unbefugt gestartet werden.
Entfernte MVS-Konsole
z/OS-Systeme knnen an unterschiedlichen Standorten von einer zentralen
Konsole aus gesteuert werden. Hierfr wird hufig ein Software-Tool
eingesetzt, das es z. B. erlaubt, die LPARs der z/OS-Systeme auch ber groe
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Entfernungen zu steuern. Das Software-Tool emuliert eine MVS-Konsole auf

einem gewhnlichen PC. Wenn der physische oder der logische Zugang zu
solchen Steuerkonsolen unzureichend geschtzt ist, besteht die Gefahr, dass
von dort aus unbefugt Manipulationen an entfernten z/OS-Systemen
vorgenommen werden.
Fernwartungszugnge
Eine weitere Gefhrdung des z/OS-Systems kann durch unsachgeme
Konfiguration der RSF-Konsole (Remote Support Facility) bestehen. Ein
externer Angreifer kann unter Umstnden Fehler in der Konfiguration
ausnutzen und sich in diese Konsole einwhlen (siehe auch G 5.10
Missbrauch von Fernwartungszugngen).
Beispiele:
RACF wurde in einem Rechenzentrum so eingerichtet, dass RACF- Erschleichen des
Special-Privilegs
Kommandos auch von einer MVS-Master-Konsole aus eingegeben werden
konnten. Ein nicht autorisierter Mitarbeiter hatte Zutritt zu dem Raum, in dem
diese Konsolen standen. Als Folge konnte er das Special-Privileg seiner
eigenen User-ID zuweisen. Dies blieb ber einen lngeren Zeitraum
unbemerkt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.117 Verschleiern von Manipulationen unter z/OS

Durch nderungen an Protokolldateien oder Abschalten von Protokollierungs-
Funktionen ist es mglich, Manipulationen am z/OS-System zu verschleiern.
Die meisten Komponenten des z/OS-Systems erzeugen Protokollierungsinfor-
mationen ber Systemaktivitten und -ereignisse. Diese werden regelmig
entladen und in entsprechenden Protokolldateien (z. B. System-Log, SMF-
Datenstze) gespeichert, die spter ausgewertet werden knnen.
Protokolldateien sind vernderbar oder manipulierbar, wenn ein
entsprechendes Zugriffsrecht auf die Datei besteht. Dieses kann beispielsweise
durch Nachlssigkeiten bei der Systemadministration unabsichtlicht vergeben
worden sein, oder ein Angreifer hat sich - etwa durch entsprechende
Manipulationen - dieses Zugriffsrecht verschafft.
Eine weitere Angriffsmglichkeit auf die Systemprotokollierung besteht darin,
die Erzeugung von Protokolldaten durch entsprechende Manipulation der
generierenden Komponente zu verhindern. Welche SMF-Datenstze
geschrieben werden, ist bei z/OS beispielsweise in einem Konfigurations-
Member eingetragen. Durch nderungen an diesem Member oder durch das
Setzen von Exits lsst sich erreichen, dass bestimmte SMF-Stze nicht mehr
geschrieben werden. Die blichen Sicherheitsmonitore sind nicht in der Lage,
unterdrckte Verste zu erkennen und zu melden, wenn keine SMF-Stze
oder keine Systemnachrichten geschrieben werden.
Beispiel:
In einem Rechenzentrum gelang es einem Anwender, das Schreiben von Abschalten von SMF-
Stzen
SMF-Datenstzen abzustellen. Daraufhin nahm er bestimmte Manipulationen
vor und schaltete die SMF-Funktion anschlieend wieder ein. Die in diesem
Zeitraum am z/OS-System vorgenommenen nderungen lieen sich spter
nicht mehr nachvollziehen, denn es fehlten die Protokolldaten. Es konnte
lediglich im System-Log nachgewiesen werden, dass die Kommandos von
einer MVS-Konsole aus eingegeben wurden, die mehreren Personen zur
Verfgung stand.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.118 Unbefugtes Erlangen hherer Rechte im RACF

Gelingt es einem Anwender, seine Berechtigungen im z/OS-Sicherheitssystem
RACF zu erhhen, kann er unter Umstnden unbefugt auf Dateien zuzugreifen
und das System manipulieren.
Trace im Netz
Mit einem sogenannten Trace (Abhren des Netzverkehrs) der TCP/IP- oder
TPX-Protokolle kann ein Angreifer je nach Absicherung des Netzes die
Kennung und das Passwort eines Anwenders mit Special-Rechten aussphen.
Unter Ausnutzung dieser Kenntnisse knnen die eigenen Berechtigungen
erhht werden, bis zur Vergabe der Special-Rechte an die eigene Kennung.
APF, SVC
Zwei weitere Mglichkeiten, sich als Benutzer im z/OS-System hhere
Berechtigungen zu verschaffen, sind das APF (Authorized Programming
Facility) und die SVCs (SuperVisor Calls).
Gelingt es dem Anwender, Programme in APF-autorisierte Dateien
einzustellen, oder gelingt es ihm, SVCs zu installieren, so kann er sich ber
diese mit Special- oder Operations-Rechten ausstatten (Manipulation des
eigenen ACEE-Kontrollblocks). Diese stehen zwar nur temporr fr die
jeweilige Sitzung zur Verfgung, das Programm kann aber jedesmal neu
aufgerufen werden.
Akkumulierte Rechte
Eine weitere Gefahr besteht durch sogenannte akkumulierte Rechte aufgrund
eines unzureichenden Berechtigungsmanagements. Typisch ist dabei das
folgende Szenario:
Ein Anwender wechselt in ein neues Ttigkeitsfeld. Der Anwender erhlt die
Rechte, die seine neue Aufgabe fordern, ohne dass die alten Rechte gelscht
werden. Auf diese Weise akkumuliert der Anwender ber einen langen
Zeitraum Rechte, die erheblich ber die eigentlich bentigten Berechtigungen
hinaus gehen.
Beispiel:
Fachwissen ist im z/OS-Umfeld wenig verbreitet. Als Folge hielten sich
fachkundige z/OS-Berater ber lange Zeit in einer Firma auf und
akkumulierten Rechte. Ein Administrator hat dies nur zufllig bemerkt, als das
Berechtigungskonzept der Firma vollstndig berarbeitet wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.119 Benutzung fremder Kennungen unter z/OS-

Systemen
Die Surrogat-Berechtigung des z/OS-Sicherheitssystems RACF ermglicht es
einem Benutzer A, einen Batch-Job unter der Kennung eines anderen
Benutzers B laufen zu lassen, ohne dass Benutzer A das Passwort von
Benutzer B kennt. Alle Sicherheitsprfungen erfolgen fr die Kennung von
Anwender B und die Protokoll- und SMF-Daten notieren Anwender B als
Ausfhrenden der Befehle.
Es besteht die Gefahr, dass die Berechtigung Surrogat missbruchlich
verwendet wird, wenn nicht die notwendigen Sicherheitsvorkehrungen bei der
Vergabe und bei der berwachung eingehalten werden:
- Benutzer knnen u. U. unbefugt Aktionen ausfhren, zu denen sie mit ihrer
eigenen Kennung nicht berechtigt sind.
- Benutzer knnen u. U. vortuschen, dass ein anderer Benutzer fr eigene
(unerlaubte) Aktionen verantwortlich sei.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.120 Manipulation der Linux/zSeries

Systemsteuerung
Es sind drei unterschiedliche Betriebsarten von Linux unter zSeries mglich:
- Linux Native auf zSeries Hardware
- Linux in einer zSeries LPAR
- Linux unter dem Trger-System z/VM
Weitere Informationen zu den Betriebsarten von Linux unter zSeries finden
sich in der Manahme M 3.41 Einfhrung in Linux und z/VM fr zSeries-
Systeme.
In allen drei Betriebsarten von Linux unter zSeries bestehen die in
Baustein 6.2 Unix-Server beschriebenen Gefhrdungen.
Mainframe-spezifische Gefhrdungen beim Einsatz von Linux
ber die in Baustein 6.2 Unix-Server beschriebenen Gefhrdungen hinaus
knnen beim Einsatz von Linux auf zSeries-Mainframes unter anderem die
folgenden Sicherheitsprobleme bestehen:
Linux in einer zSeries LPAR
Mainframe-spezifische Gefhrdungen ergeben sich aus den mglichen
Einwirkungen auf die zSeries Hardware:
- Durch den Zugang zu HCD-Funktionen (Hardware Configuration
Definition) knnen Mitarbeiter Hardware-Ressourcen, wie z. B.
Festplatten, unbefugt zur Linux-Partition zuordnen. Damit hat das Linux-
Betriebssystem Zugriff auf die Hardware-Ressourcen.
- Der Zugang zur HMC (Hardware Management Console) erlaubt
Manipulationen wie Starten, Stoppen und Zuordnung von Ressourcen zu
einer LPAR. Analog ist dies in G 5.116 Manipulation der z/OS-
Systemsteuerung fr das z/OS-Betriebssystem beschrieben. hnlich
sicherheitskritisch ist der Zugriff auf SEs (Service Elements). Das Service
Element ist eine Komponente der zSeries-Hardware, die die gleichen
Funktionalitten wie eine HMC bietet.
Linux unter dem Trger-System z/VM
In diesem Szenario wird Linux auf einer emulierten Hardware einer virtuellen
Maschine betrieben. Die emulierte Hardware der virtuellen Maschine wird
von z/VM auf der realen zSeries-Hardware realisiert. Der physische Zugriff
auf die realen Ressourcen erfolgt nur ber z/VM.
Die Mainframe-spezifischen Gefhrdungen ergeben sich einerseits aus den
mglichen Einwirkungen auf die emulierte Hardware, andererseits aus den
mglichen Einwirkungen auf z/VM.
- Der Zugang zu HCD-Funktionen und zur HMC kann - wie in der
Betriebsart Linux in einer zSeries LPAR - missbraucht werden.
- Mitarbeiter, die kritische z/VM-Kommandos absetzen drfen, knnen u. U.
die Betriebsstabilitt des z/VM und damit die darauf laufenden Linux-
Betriebssysteme erheblich gefhrden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Mitarbeiter, die unbefugt Zugriff auf das DIRMAINT Utility erhalten,

knnen darber z. B. neue virtuelle Systeme generieren oder Minidisks
eines Linux einem anderen zuordnen. Wird z/VM RACF nicht benutzt,
knnen ber DIRMAINT auch Benutzerkennungen administriert werden.
- Ist im z/VM-Betriebssystem die Sicherheitskomponente z/VM RACF
(Resource Access Control Facility) eingesetzt, so bestehen unter z/VM
vergleichbare Gefhrdungen, wie in G 3.72 Fehlerhafte Konfiguration des
z/OS-Sicherheitssystems RACF fr das z/OS-Betriebssystem beschrieben.
Mitarbeiter, die hohe RACF/VM-Autorisierungen besitzen (z. B.
SPECIAL), knnen ber RACF/VM andere z/VM-Kennungen und
-Berechtigungen manipulieren.
- Falls die Authentisierung unter Linux ber eine LDAP-Anbindung mit
PAM-Modul (Pluggable Authentication Module) durch ein z/OS-RACF
erfolgt, knnen Linux-Kennungen und -Berechtigungen auch von
Mitarbeitern mit hoher z/OS-RACF-Autorisierung beeinflusst werden.
Beispiel:
- Ein Mitarbeiter hatte aus historischen Grnden noch die Berechtigung, Unberechtigte Nutzung
der z/VM-Administration
unter z/VM die Funktion DIRMAINT zu verwenden. Dies nutzte er aus,
um fr sich ein privates Linux zu generieren und zu benutzen. Dies fhrte
zum Verbrauch von Ressourcen, die dadurch den ordnungsgemen
Prozessen auf der zSeries-Maschine nicht mehr zur Verfgung standen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.121 Angriffe ber TCP/IP auf z/OS-Systeme

Um ein z/OS-System ber die Netzanbindung anzugreifen, sind hufig keine
Spezialkenntnisse der SNA-Netzarchitektur oder von MVS erforderlich.
Durch die TCP/IP-Anbindung an ffentliche Netze und die Unix System
Services sind viele z/OS-Systeme ber Standardprotokolle und Dienste, wie
z. B. HTTP oder FTP, fr externe Angreifer erreichbar.
Externe Angreifer knnen unter Umstnden ber die TCP/IP-Anbindung an
ffentliche Netze Denial-of-Service-Angriffe gegen die angebotenen Dienste
durchfhren oder bertragene Daten unbefugt lesen oder manipulieren.
Interne Angreifer knnen ber die TCP/IP-Anbindung an interne Netze
versuchen, ihre Berechtigungen zu erhhen, indem sie etwa Kennung und
Passwort eines Anwenders mit Special-Rechten aussphen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.122 Missbrauch von RACF-Attributen unter z/OS

Im z/OS-Sicherheitssystem RACF sind die Attribute SPECIAL,
OPERATIONS und AUDITOR mit besonders hohen Berechtigungen
ausgestattet.
Attribut SPECIAL
Die Kennung mit dem Attribut SPECIAL ist fr die Administration des
Sicherheitssystems RACF erforderlich. Der Besitzer dieses Attributs verfgt
ber die Mglichkeit, im RACF Einstellungen zu ndern. Er gibt
beispielsweise den Benutzern den Zugriff auf Systemressourcen und Dateien
frei. Der Inhaber der Berechtigung kann sich selbst auf smtliche Ressourcen
und Dateien des Systems Rechte vergeben. Er kann auch die im Weiteren
aufgefhrten Attribute an alle Benutzerkennungen vergeben.
Eine mgliche Schwachstelle besteht beim Einsatz von Systemmonitoren, die
ber hoch autorisierte Programmteile ihre eigene Kennung mit dem Attribut
SPECIAL versehen knnen. Anwender mit Zugang zu den Systemmonitoren
knnen dies - bei entsprechenden RACF-Rechten - ausnutzen, um ihre eigene
Kennung mit hheren Zugriffsrechten zu versehen.
Attribut OPERATIONS
Die Kennung mit dem Attribut OPERATIONS wird hauptschlich fr das
Space-Management im z/OS-System angefordert. Es beinhaltet die Rechte
zum Kopieren, Lesen, Lschen oder Neuanlagen von Dateien, ohne dass ein
explizites Recht fr die Datei und die Benutzerkennung vergeben wurde. Dies
ermglicht es prinzipiell einem Anwender, das Attribut OPERATIONS fr
unbefugte Datenzugriffe zu missbrauchen.
Attribut AUDITOR
Auditoren sollen sicherheitsrelevante Ereignisse erkennen, nachvollziehen und
berprfen knnen. nderungen an RACF-Definitionen sind mit dieser
Berechtigung nur fr audit-relevante Definitionen mglich (im Gegensatz zu
SPECIAL), d. h. hhere Autorisierungen lassen sich damit nicht erreichen.
Allerdings birgt das Attribut AUDITOR die Gefahr, dass umfassende
Informationen, z. B. smtliche RACF-Einstellungen, ber das System
ausgespht werden knnen.
Beispiele:
- Ein Systemprogrammierer verfgte nicht ber das Attribut SPECIAL. Er Erschleichen des
Special-Attributes
schrieb ein spezielles Programm und stellte es in eine APF-autorisierte
Datei. Den Zugriff auf die APF-Dateien bentigte er fr seine regulre
Arbeit. ber das selbst geschriebene Programm gelang es dem
Systemprogrammierer, sich das Attribut SPECIAL zuzuweisen und
unbefugt nderungen an RACF-Einstellungen durchzufhren.
- Als in einem Unternehmen bekannt wurde, dass ein Konkurrent Kunden Ausnutzen des
Operation-Attributes
abwarb, wurden umgehend Nachforschungen angestellt. Wie sich
herausstellte, verfgte die Benutzerkennung eines Anwenders ber das
Attribut OPERATIONS. Mit Hilfe dieses Attributs gelang es ihm, die
Kundenadressen regelmig unerlaubt zu kopieren und weiterzugeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.123 Abhren von Raumgesprchen ber mobile

Endgerte
Viele mobile Endgerte wie Laptops, PDAs oder Mobiltelefone werden
mittlerweile mit integriertem Mikrofon oder Kamera ausgeliefert. Mit diesen
knnen nicht nur Ideen oder Schnappschsse unterwegs aufgenommen
werden, sie knnen auch dazu benutzt werden, unbemerkt Gesprche aufzu-
zeichnen oder abzuhren (siehe auch G 5.95 Abhren von Raumgesprchen
ber Mobiltelefone).
Hierzu kann beispielsweise ein PDA benutzt werden, der unauffllig in einem Unauffllig aktivierbar
Raum platziert wurde, z. B. bei einer Besprechung.
Besprechungsteilnehmer rechnen normalerweise nicht damit, dass die kom-
plette Besprechung mitgeschnitten wird.
Beispiel:
In einer Besprechung haben fast alle Beteiligten ihre Laptops dabei und benut-
zen diese auch fortwhrend. Einer der Teilnehmer hat unauffllig sein Rech-
nermikrofon aktiviert. Wie bei den meisten mobilen Endgerten ist auch hier
fr die anderen Teilnehmer nicht erkennbar, dass das Mikrofon eingeschaltet
ist. Er fertigt darber einen kompletten Mitschnitt der Besprechung an und
schneidet daraus kleinere Beitrge heraus. Da diese aus dem Sinnzusammen-
hang herausgerissen wurden, kann er damit erfolgreich ein anderes Bespre-
chungsergebnis vorspiegeln.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.124 Missbrauch der Informationen von mobilen End-

gerten
Mobile Endgerte gehen leicht verloren und sind einfach zu stehlen (siehe
auch G 5.22 Diebstahl bei mobiler Nutzung des IT-Systems). Je kleiner und
begehrter solche Gerte sind, desto strker ist dieses Risiko. Neben dem
unmittelbaren Verlust kann dabei durch den Verlust bzw. die Offenlegung
wichtiger Daten weiterer Schaden entstehen. Dieser mittelbare Schaden ist in
vielen Fllen deutlich schwerwiegender als der rein materielle Verlust des
Gertes.
Beispiele:
- Daten wie Notizen von Besprechungen oder Adressen, die im PDA gespei- Vertrauliche Daten auf
dem PDA
chert sind, knnen durchaus einen vertraulichen Charakter haben. Ein
Verlust des Gerts bedeutet dann unter Umstnden die Offenlegung dieser
gespeicherten Informationen.
- Viele mobile Endgerte haben Sicherheitsmechanismen, die diese vor
einem unbefugten Zugriff schtzen sollen. Diese Sicherheitsmechanismen
sind aber meistens zu schwach ausgelegt, wodurch es Angreifern ein
leichtes ist, diese zu berwinden. Selbst wo sie vorhanden sind, werden sie
aber hufig aus Bequemlichkeit nicht benutzt, so dass die vertraulichen
Daten im Verlustfall berhaupt nicht geschtzt sind.
- Hufig sind auf mobilen Endgerten Zugangsdaten fr andere IT-Systeme
oder das LAN der Behrde bzw. des Unternehmens gespeichert. Wenn ein
Unbefugter in den Besitz eines Laptops oder PDA mit (statischen)
Zugangskennungen gelangt, ist damit ein missbruchlicher Zugriff auf
interne Daten mglich.
- Bei PDAs mit eingebautem Mobiltelefon (Smartphones) kann ein unehr-
licher Finder oder Dieb auf Kosten des rechtmigen Besitzers telefo-
nieren, sofern ihm die PIN bekannt ist, er sie leicht erraten kann oder wenn
die Sicherheitsmechanismen des Gertes leicht berwunden werden
knnen.
- Viele PDAs und Laptops haben Schnittstellen fr den Einsatz austausch-
barer Datenspeicher wie z. B. Speicherkarten oder USB-Tokens. Bei einem
unbeaufsichtigten PDA oder Laptop mit der entsprechenden Hard- und
Software besteht die Gefahr, dass ber diese Speichermedien groe
Datenmengen schnell herunterkopiert werden knnen. Dabei werden nicht
einmal Spuren hinterlassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.125 Unberechtigte Datenweitergabe ber mobile

Endgerte
Mobile Endgerte wie Notebooks oder PDAs sind im allgemeinen darauf aus-
gelegt, einen einfachen Datenaustausch mit anderen IT-Systemen zu ermg-
lichen. Dies kann ber ein Verbindungskabel oder auch drahtlos, z. B. ber
Infrarot, Bluetooth oder GSM, erfolgen.
Wo ein offener Zugang zu IT-Systemen mglich ist, knnen Informationen
unauffllig abgefragt und bermittelt werden. Die gesammelten Daten knnen
dann mit dem mobilen Endgert unbemerkt mitgenommen oder modifiziert
werden. Eine nachtrgliche berprfung oder gar ein Nachweis ist nicht
immer mglich, da hufig die Zugriffe nicht entsprechend protokolliert
wurden.
Falls das Gert ber eine drahtlose Kommunikationsschnittstelle verfgt
(beispielsweise eine integrierte WLAN-Karte oder eine Schnittstelle zu einem
Mobiltelefon), so knnen die gespeicherten Informationen auch unmittelbar an
jeden Ort der Welt bermittelt werden (siehe auch G 5.97 Unberechtigte
Datenweitergabe ber Mobiltelefone).
Wird in einer Organisation ein eigenes drahtloses Netz (WLAN) betrieben, so
kann ein Besucher mit seinem mitgebrachten PDA den WLAN-Verkehr
belauschen. Falls das drahtlose Netz nicht ausreichend abgesichert ist kann der
Angreifer problemlos alle bermittelten Daten "mitschneiden" oder gar auf
diesem Weg direkten Zugriff auf das Netz erlangen.
Beispiel:
Ein Mitarbeiter eines Unternehmens wird aus einer Besprechung mit einem
Externen gerufen, um ein wichtiges Telefonat entgegenzunehmen. Der
Externe nutzt die kurze Zeitspanne ohne Beaufsichtigung, um den im
Besprechungsraum aufgestellten PC mit seinem mobilen Endgert zu ver-
binden. Anschlieend transferiert er alle zugreifbaren Daten auf sein mobiles
Endgert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
G 5.126 Unberechtigte Foto- und Filmaufnahmen mit

mobilen Endgerten
Immer mehr mobile Endgerte sind inzwischen mit eingebauten oder auf- Vorsicht Kamera!
steckbaren Kameras ausgerstet. Teilweise ist mit solchen Kameras sogar die
Aufzeichnung von Filmen mglich. Solche mobilen Endgerte knnen leicht
dazu benutzt werden, in sensiblen Bereichen (beispielsweise in einer Ent-
wicklungsabteilung) unauffllig Foto- oder gar Filmaufnahmen anzufertigen.
Die Bildqualitt reicht zwar meist nicht an die Qualitt "richtiger" Kameras
heran, trotzdem ist es wichtig, sich dieser Gefahr bewusst zu sein.
Wie beim "allgemeinen Datenklau" (siehe G 5.125 Unberechtigte Daten-
weitergabe ber mobile Endgerte) knnen die gemachten Bilder unmittelbar
nach drauen bermittelt und anschlieend wieder vom Gert gelscht
werden. In diesem Fall ist selbst dann, wenn jemand Verdacht schpft, ein
Nachweis praktisch nicht mehr mglich.
Beispiel:
In viele Schwimmbder und Sportstudios drfen mittlerweile keine Foto-
Handys mehr mitgenommen werden, da es verschiedene Beschwerden ber
heimlich aufgenommene Fotos aus Umkleidekabinen gab. Unter anderem
wurde dies ffentlich, da einige Hobby-Paparazzi ihre Fotos stolz auf
Webseiten prsentiert haben.
___________________________________________________________________ ..........................................
Manahmenkatalog Infrastruktur M1 Bemerkungen
___________________________________________________________________ ..........................................
M1 Manahmenkatalog Infrastruktur
M 1.1 Einhaltung einschlgiger DIN-Normen/VDE-
Vorschriften ............................................................................... 1
M 1.2 Regelungen fr Zutritt zu Verteilern.......................................... 2
M 1.3 Angepasste Aufteilung der Stromkreise .................................... 3
M 1.4 Blitzschutzeinrichtungen ........................................................... 4
M 1.5 Galvanische Trennung von Auenleitungen.............................. 5
M 1.6 Einhaltung von Brandschutzvorschriften................................... 6
M 1.7 Handfeuerlscher ....................................................................... 7
M 1.8 Raumbelegung unter Bercksichtigung von Brandlasten.......... 8
M 1.9 Brandabschottung von Trassen.................................................. 9
M 1.10 Verwendung von Sicherheitstren und -fenstern .................... 10
M 1.11 Lageplne der Versorgungsleitungen ...................................... 11
M 1.12 Vermeidung von Lagehinweisen auf schtzenswerte
Gebudeteile ............................................................................ 12
M 1.13 Anordnung schtzenswerter Gebudeteile .............................. 13
M 1.14 Selbstttige Entwsserung ....................................................... 14
M 1.15 Geschlossene Fenster und Tren ............................................. 15
M 1.16 Geeignete Standortauswahl...................................................... 16
M 1.17 Pfrtnerdienst........................................................................... 17
M 1.18 Gefahrenmeldeanlage .............................................................. 18
M 1.19 Einbruchsschutz ....................................................................... 19
M 1.20 Auswahl geeigneter Kabeltypen unter physikalisch-
mechanischer Sicht .................................................................. 20
M 1.21 Ausreichende Trassendimensionierung ................................... 21
M 1.22 Materielle Sicherung von Leitungen und Verteilern ............... 22
M 1.23 Abgeschlossene Tren
M 1.24 Vermeidung von wasserfhrenden Leitungen ......................... 24
M 1.25 berspannungsschutz .............................................................. 25
M 1.26 Not-Aus-Schalter .................................................................. 26.1
M 1.27 Klimatisierung ...................................................................... 26.2
M 1.28 Lokale unterbrechungsfreie Stromversorgung......................... 28
M 1.29 Geeignete Aufstellung eines IT-Systems................................. 30
M 1.30 Absicherung der Datentrger mit TK-Gebhrendaten ............ 31
M 1.31 Fernanzeige von Strungen ..................................................... 32
___________________________________________________________________ ..........................................
Manahmenkatalog Infrastruktur M1 Bemerkungen
___________________________________________________________________ ..........................................
M 1.32 Geeignete Aufstellung von Konsole, Gerten mit

austauschbaren Datentrgern und Druckern ............................ 33
M 1.33 Geeignete Aufbewahrung tragbarer IT-Systeme bei
mobilem Einsatz ...................................................................... 34
M 1.34 Geeignete Aufbewahrung tragbarer PCs im stationren
Einsatz...................................................................................... 35
M 1.35 Sammelaufbewahrung mehrerer tragbarer PCs ....................... 36
M 1.36 Sichere Aufbewahrung der Datentrger vor und nach
Versand .................................................................................... 37
M 1.37 Geeignete Aufstellung eines Faxgertes.................................. 38
M 1.38 Geeignete Aufstellung eines Modems ..................................... 39
M 1.39 Verhinderung von Ausgleichsstrmen auf Schirmungen
................................................................................................. 40
M 1.40 Geeignete Aufstellung von Schutzschrnken .......................... 43
M 1.41 Schutz gegen elektromagnetische Einstrahlung....................... 44
M 1.42 Gesicherte Aufstellung von Novell Netware Servern ............. 45
M 1.43 Gesicherte Aufstellung aktiver Netzkomponenten .................. 46
M 1.44 Geeignete Einrichtung eines huslichen Arbeitsplatzes .......... 47
M 1.45 Geeignete Aufbewahrung dienstlicher Unterlagen und
Datentrger .............................................................................. 48
M 1.46 Einsatz von Diebstahl-Sicherungen ......................................... 49
M 1.47 Eigener Brandabschnitt............................................................ 50
M 1.48 Brandmeldeanlage ................................................................... 51
M 1.49 Technische und organisatorische Vorgaben fr das
Rechenzentrum ........................................................................ 52
M 1.50 Rauchschutz............................................................................. 55
M 1.51 Brandlastreduzierung ............................................................... 56
M 1.52 Redundanzen in der technischen Infrastruktur ........................ 57
M 1.53 Videoberwachung .................................................................. 58
M 1.54 Brandfrhesterkennung / Lschtechnik ................................... 59
M 1.55 Perimeterschutz........................................................................ 60
M 1.56 Sekundr-Energieversorgung................................................... 62
M 1.57 Aktuelle Infrastruktur- und Bauplne ...................................... 64
M 1.58 Technische und organisatorische Vorgaben fr
Serverrume ............................................................................. 65
M 1.59 Geeignete Aufstellung von Archivsystemen ........................... 67
M 1.60 Geeignete Lagerung von Archivmedien .................................. 68
___________________________________________________________________ ..........................................
Manahmenkatalog Infrastruktur M 1.1 Bemerkungen
___________________________________________________________________ ..........................................
M 1.1 Einhaltung einschlgiger DIN-Normen/VDE-

Vorschriften
Verantwortlich fr Initiierung: Leiter Beschaffung, Planer
Verantwortlich fr Umsetzung: Bauleiter, Errichterfirma
Fr nahezu alle Bereiche der Technik gibt es Normen bzw. Vorschriften, z. B.
DIN, VDE, VDMA, Richtlinien des VdS. Diese Regelwerke tragen dazu bei,
dass technische Einrichtungen ein ausreichendes Ma an Schutz fr den
Benutzer und Sicherheit fr den Betrieb gewhrleisten.
Bei der Planung und Errichtung von Gebuden, bei deren Umbau, beim
Einbau technischer Gebudeausrstungen (z. B. interne Versorgungsnetze wie
Telefon- oder Datennetze) und bei Beschaffung und Betrieb von Gerten sind
entsprechende Normen und Vorschriften unbedingt zu beachten.
- Werden VDE-Vorschriften bei Ausschreibungen, Bestellungen oder
Beschaffungen bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.2 Regelungen fr Zutritt zu Verteilern

Verantwortlich fr Initiierung: Leiter Haustechnik
Verantwortlich fr Umsetzung: Haustechnik
Die Verteiler (z. B. fr Energieversorgung, Datennetze, Telefonie) sind nach
Mglichkeit in Rumen fr technische Infrastruktur (siehe Kapitel 4.3.4 Raum
fr technische Infrastruktur) unterzubringen. Die dort geforderten Manahmen
sind zu bercksichtigen.
Der Zutritt zu den Verteilern aller Versorgungseinrichtungen (Strom, Wasser,
Gas, Telefon, Gefahrenmeldung, Rohrpost etc.) im Gebude muss mglich
und geordnet sein.
Mit mglich ist gemeint,
- dass Verteiler nicht bei Malerarbeiten mit Farbe oder Tapeten so verklebt
werden, dass sie nur noch mit Werkzeug zu ffnen oder unauffindbar sind,
- dass Verteiler nicht mit Mbeln, Gerten, Paletten etc. zugestellt werden,
- dass fr verschlossene Verteiler die Schlssel verfgbar sind und die
Schlsser funktionieren.
Mit geordnet ist gemeint, dass festgelegt ist, wer welchen Verteiler ffnen
darf. Verteiler sollten verschlossen sein und drfen nur von den fr die jewei-
lige Versorgungseinrichtung zustndigen Personen geffnet werden. Die
Zugriffsmglichkeiten knnen durch unterschiedliche Schlieungen und eine
entsprechende Schlsselverwaltung geregelt werden (siehe dazu M 2.14
Schlsselverwaltung).
Sind in Verteilern des Stromversorgungsnetzes Schmelzsicherungen einge-
baut, sollten entsprechende Ersatzsicherungen (im Verteiler) bereit liegen.
Eine Dokumentation der Verteiler ist entsprechend M 2.19 Neutrale
Dokumentation in den Verteilern auszufhren.
Alle im Verteiler eingebauten Einrichtungen sind exakt und verstndlich zu
beschriften.
- Gibt es Regelungen fr den Zutritt zu Verteilern?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.3 Angepasste Aufteilung der Stromkreise

Die Raumbelegung und die Anschlusswerte, fr die eine Elektroinstallation
ausgelegt wurde, stimmen erfahrungsgem nach einiger Zeit nicht mehr mit
den tatschlichen Gegebenheiten berein. Es ist also unerlsslich, bei
nderungen der Raumnutzung und bei nderungen und Ergnzungen der
technischen Ausrstung (IT, Klimatruhe, Beleuchtung etc.) die Elektroin-
stallation zu prfen und ggf. anzupassen. Das kann durch Umrangierung von
Leitungen geschehen. Andernfalls kann die Neuinstallation von Einspeisung,
Leitungen, Verteilern etc. erforderlich werden.
- Wird berprft, ob die Absicherung und Auslegung der Stromkreise den
tatschlichen Bedrfnissen entspricht?
- Wann erfolgte die letzte berprfung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.4 Blitzschutzeinrichtungen
Die direkten Auswirkungen eines Blitzeinschlages auf ein Gebude
(Beschdigung der Bausubstanz, Dachstuhlbrand u..) lassen sich durch die
Installation einer Blitzschutzanlage gem DIN/VDE 0185 verhindern. ber
diesen "ueren Blitzschutz" hinaus ist fast zwingend der "Innere Blitz-
schutz", der berspannungsschutz, erforderlich. Denn der uere Blitzschutz
schtzt die elektrischen Betriebsmittel im Gebude nicht. Dies ist nur durch
einen berspannungsschutz mglich (siehe dazu M 1.25
berspannungsschutz), dessen hohe Kosten dem Schutzgut gegenber
gerechtfertigt sein mssen.
Fr einen umfassenden Blitzschutz ist es notwendig, dass sich alle Schutz-
einrichtungen auf das gleiche Potential beziehen. Der uere Blitzschutz ist
entsprechend den Forderungen der DIN VDE 0185 "Blitzschutzanlagen" mit
der Potentialausgleichschiene (PAS) verbunden. Diese ist ihrerseits mit dem
PEN- bzw. N- und PE-Leiter der elektrischen Installation im Gebude ver-
bunden. Bei einem Blitzeinschlag fllt eine dem eingeprgten Strom propor-
tionale Spannung am Erdungswiderstand der Blitzschutzanlage ab. Das
Potential der PAS und somit von N- und PE-Leitern im Gebude steigt an und
kann Werte von mehreren zehntausend Volt erreichen. Es werden Spannungen
zwischen N-/PE-Leitern und den Leitern L1/L2/L3 erreicht, die das betriebs-
bliche Ma von 230/400 V deutlich berschreiten. Es kommt zu Schden an
Gerten und Leitungen. Ausgleichsstrme zwischen Daten- und Energie-
versorgungsnetz, beispielsweise aufgrund defekter Schirmungen, knnen zur
Zerstrung von IT fhren (siehe dazu M 1.39 Verhinderung von
Ausgleichsstrmen auf Schirmungen). Die Betrachtung aller Netze
(Gebudeleittechnik, Weitverkehrsnetze) ist wegen mglicher
Parallelverlegungen im Hinblick auf berkopplungen genauso notwendig wie
die Einbeziehung in das Gebude fhrender Auenleitungen (siehe dazu
M 1.5 Galvanische Trennung von Auenleitungen).
Beispiel:
Durch Blitzschlag entstand in der sddeutschen Niederlassung eines Dienst-
leistungsunternehmens ein Schaden an IT-Gerten (PCs, Server, Laserdrucker)
in Hhe von ca. 10.000 Euro. Aufgrund dieses Ereignisses wurde das Gebude
mit einem ueren Blitzschutz ohne inneren Blitzschutz
(berspannungsschutz) ausgestattet. Ein erneuter Blitzschlag fhrte nun trotz
ueren Blitzschutzes zu Schden in annhernd gleicher Hhe.
- Ist die Notwendigkeit des ueren Blitzschutzes tatschlich gegeben?
- Gibt es Auflagen von Behrden oder Versicherungen?
- Wird die Blitzschutzanlage regelmig geprft und gewartet?
- Existiert ggf. ein ausreichender berspannungsschutz im Gebude?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.5 Galvanische Trennung von Auenleitungen

Viele hausinterne Netze stehen in direkter galvanischer Verbindung mit
Auenleitungen. Telefon-, Strom- und Datennetze mit DF-Anschlssen sind
davon betroffen, aber auch Gas- und Wasserleitungen.
ber diese Netzanschlsse knnen Fremd- und berspannungen in das
Gebude verschleppt werden. Es gibt eine Reihe von elektrischen,
elektronischen oder softwaregesttzten Manahmen, Netze gegen Einflsse
von auen zu schtzen. Ein absolut sicherer Schutz lsst sich aber nicht in
allen Fllen garantieren. Hier bleibt nur noch die konsequente galvanische
Trennung der Netzbergnge ins Gebude. Dies kann z. B. durch den Einbau
eines Schalters geschehen, der die Leitung nur bei Bedarf durchschaltet
(Fernwartung).
Zum Schutz nicht trennbarer Leitungen (Telefon, Daten, Strom, Gas, Wasser)
gegen berspannungen ist die Einrichtung eines berspannungsschutzes
(M 1.25 berspannungsschutz) in Erwgung zu ziehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.6 Einhaltung von Brandschutzvorschriften

Verantwortlich fr Initiierung: Leiter Haustechnik, Brandschutzbeauftragter
Verantwortlich fr Umsetzung: Brandschutzbeauftragter, Haustechnik
Die bestehenden Brandschutzvorschriften (z. B. DIN 4102) und die Auflagen Feuerwehr hinzuziehen
der Bauaufsicht fr Gebude sind unbedingt einzuhalten. Die rtliche Feuer-
wehr sollte bei der Brandschutzplanung hinzugezogen werden.
Es sollte eine Person benannt werden, die fr die Einhaltung von Brand-
schutzvorschriften verantwortlich ist. Dies kann ein Brandschutzbeauftragter
oder eine mit dem Aufgabengebiet betraute Person sein, die auch entsprechend
geschult ist.
Es ist empfehlenswert, weitere Hinweise zum Brandschutz zu beachten, wie
sie zum Beispiel in den Publikationen der VdS Schadenverhtung GmbH zu
finden sind.
Besonders wichtig ist es, die Fluchtwege gut auszuschildern. Dafr sind die Fluchtwege
vorgeschriebenen Kennzeichen zu verwenden und die Vorschriften zu deren
Anbringung einzuhalten. Die Fluchtwege mssen immer offen gehalten
werden, das heit insbesondere, dass sie nicht versperrt werden drfen, z. B.
durch im Flur abgestelltes Inventar oder indem die Fluchttren abgeschlossen
werden.
Damit die Feuerwehr im Brandfall schnell mit der Brandbekmpfung begin-
nen kann, ist es wichtig, dass die Brandmeldezentrale, das Brandmeldetableau
und die Einspeisepunkte fr Lschwasser durch Beschilderung schnell gefun-
den werden knnen.
Zur Verwirklichung eines effizienten Brandschutzes ist die Zusammenarbeit
aller zustndigen Verfahrensbeteiligten notwendig. Hierunter fallen die Funk-
tionen des Brandschutz-Verantwortlichen (Arbeitgeber ist fr die Einhaltung
der Brandschutzvorschriften verantwortlich), die Fachkraft fr Arbeitssicher-
heit (erforderlich nach 5, 6 Arbeitssicherheitsgesetz, Ausgestaltung des
betrieblichen Brandschutzes) und der Sicherheitsbeauftragte ( 22 SGB VII,
ausfhrende Ttigkeiten, arbeitet der Fachkraft fr Arbeitssicherheit zu).
- Besteht ein Gedankenaustausch mit der rtlichen Feuerwehr?
- Gibt es einen Brandschutzbeauftragten oder eine mit dem Aufgabengebiet
betraute Person, die auch entsprechend geschult ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.7 Handfeuerlscher
Verantwortlich fr Umsetzung: Brandschutzbeauftragter, Haustechnik
Die meisten Brnde entstehen aus kleinen, anfangs noch gut beherrschbaren Brnde mglichst im
Keim ersticken
Brandherden. Besonders in Bros findet das Feuer reichlich Nahrung und
kann sich sehr schnell ausbreiten. Der Sofortbekmpfung von Brnden kommt
also ein sehr hoher Stellenwert zu.
Diese Sofortbekmpfung ist nur mglich, wenn Handfeuerlscher in der
jeweils geeigneten Brandklasse (DIN EN 3) in ausreichender Zahl und Gre
(Beratung durch die rtliche Feuerwehr) im Gebude zur Verfgung stehen.
Dabei ist die rumliche Nhe zu schtzenswerten Bereichen und Rumen wie
Serverraum, Raum mit technischer Infrastruktur oder Belegarchiv anzu-
streben.
Wasserlscher mit Eignung fr Brandklasse A bis 1000 V sind durchaus fr
elektrisch betriebene Gerte geeignet.
Fr elektronisch gesteuerte Gerte, z. B. Rechner, sollten vorzugsweise
Kohlendioxyd-Lscher (Brandklasse B) zur Verfgung stehen. Die Lsch-
wirkung wird durch Verdrngung des Sauerstoffs erreicht, deshalb ist bei
Anwendung in engen, schlecht belfteten Rumen Vorsicht geboten.
Pulverlscher, die die Brandklassen A (feste Stoffe), B (brennbare Flssig-
keiten) und C (Gase) abdecken, sollten in Bereichen mit elektrischen und
elektronischen Gerten nicht eingesetzt werden, weil die Lschschden in der
Regel unverhltnismig hoch sind.
Die Feuerlscher mssen regelmig geprft und gewartet werden. Die Feuer- Mitarbeiter mssen mit
Feuerlschern umgehen
lscher mssen so angebracht werden, dass sie im Brandfall leicht erreichbar knnen
sind. Die Beschftigten sollten sich die Standorte des nchsten Feuerlschers
einprgen. Die Standorte von Lschern und Hydranten sind durch vorge-
schriebene Schilder kenntlich zu machen. Tragbare Feuerlscher sind zugelas-
sen bis zu einem Gesamtgewicht von 20 kg. Mit den berwiegend einge-
setzten Gerten von 6 und 12 kg lassen sich grere Brandherde lschen als
von Laien blicherweise angenommen wird, dies ist allerdings nur bei
konsequenter Vorgehensweise gegeben. Bis zur vollstndigen Entladung des
Lschmittels vergehen nur wenige Sekunden. Daher sind bei entsprechenden
Brandschutzbungen die Mitarbeiter in die Benutzung der Handfeuerlscher
einzuweisen.
- Sind die Mitarbeiter ber den Aufbewahrungsort der Handfeuerlscher
informiert?
- Wird die Nutzung der Handfeuerlscher gebt?
- Sind die Handfeuerlscher im Brandfall berhaupt erreichbar?
- Werden die Handfeuerlscher regelmig inspiziert und gewartet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.8 Raumbelegung unter Bercksichtigung von

Brandlasten
Verantwortlich fr Umsetzung: Haustechnik, Brandschutzbeauftragter
Eine Brandlast entsteht durch alle brennbaren Stoffe, die ins Gebude einge-
bracht werden. Sie ist von der Menge und vom Heizwert der Stoffe abhngig.
IT-Gerte und Leitungen stellen ebenso eine Brandlast dar wie Mbel,
Fubodenbelge und Gardinen. Maximale Brandlasten, standardisierte Heiz-
werte, weitere Informationen und Bestimmungen sind in der DIN 4102
zusammengestellt.
Bei der Unterbringung von IT-Gerten, Datentrgern etc. sollte eine vorherige
Beachtung der vorhandenen Brandlasten im gleichen Raum und in den
benachbarten Rumen erfolgen. Z. B. sollte das Datentrgerarchiv nicht in der
Nhe von oder ber einem Papierlager untergebracht sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.9 Brandabschottung von Trassen

Verantwortlich fr Umsetzung: Haustechnik, Brandschutzbeauftragter
Bei Gebuden mit mehreren Brandabschnitten lsst es sich kaum vermeiden, Durchbrche abschotten
dass Trassen durch Brandwnde und Decken fhren. Die Durchbrche sind
nach Verlegung der Leitungen entsprechend dem Brandwiderstandswert der
Wand bzw. Decke zu schotten. Um die Nachinstallation zu erleichtern, knnen
geeignete Materialien (z. B. Brandschutzkissen) verwendet werden.
Entsprechende VdS-Richtlinien sind zu beachten.
Hufig werden in einer Trasse unterschiedliche Kabel, z. B. Telefon, LAN und Trassennutzung
koordinieren
Haustechnik gefhrt. Falls nderungen der Verkabelung anstehen, sollte
bereits in der Planungsphase geklrt werden, ob in absehbarer Zeit auch
andere Kabelsysteme ausgewechselt werden sollen. Entsprechende Zusam-
menlegung von Projekten minimiert Ausfallzeiten und erspart zustzliche
Kosten fr eine mehrmalige Brandschottung.
Negativbeispiel:
In einem mehrgeschossigen Brogebude in Bonn wurden verschiedene Netze
ber eine gemeinsame Steigetrasse aus dem Keller bis in das oberste Geschoss
gefhrt. Alle Deckendurchbrche waren mit reichlich Reserve hergestellt,
nach Verlegung der Leitungen allerdings nicht wieder verschlossen worden.
Im Keller wurden im Bereich des Trassenbeginns groe Papier- und
Stoffmengen gelagert. Die direkt darber beginnende Steigetrasse htte im
Brandfall wie ein Kamin gewirkt. Rauch und Feuer htten sich in krzester
Zeit ber alle Etagen ausgebreitet.
- Wurde bei der Trassenplanung der fr den Brandschutz Zustndige hinzu-
gezogen?
- Wurden mgliche Alternativen der Trassenfhrung geprft?
- Werden im Anschluss an Installationsarbeiten und regelmige Kontrollen
der Brandabschottungen durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.10 Verwendung von Sicherheitstren und -fenstern

Sicherheitstren wie z. B. Stahlblechtren, bieten gegenber normalen Bro-
tren Vorteile:
- Sie bieten aufgrund ihrer Stabilitt einen hheren Schutz gegen Einbruch Schutz vor Einbruch
(z. B. bei Keller- und Lieferanteneingngen) und
- sie verzgern in der Ausfhrung als selbstschlieende feuerhemmende Tr Schutz bei Brnden
(FH-Tr T30, DIN 18 082) die Ausbreitung eines Brandes.
Es ist zu gewhrleisten, dass die Sicherungsmanahmen aller raumum-
schlieenden Bauelemente gleichwertig sind:
- Bei Verwendung einbruchhemmender Tren ist im Fassadenbereich die
Verwendung einbruchhemmender Fenster oder Fassadenelemente (DIN V
ENV 1627 - 1630) zu erwgen.
- Weiterhin ist es z. B. nicht zweckmig, eine einbruchhemmende Tr der
hchsten Widerstandsklasse in eine Gipskartonwand einzubauen.
Anforderungen zur Ausfhrung von Sicherheitstren finden sich in den Ma-
nahmen M 1.47 Eigener Brandabschnitt und M 1.19 Einbruchsschutz.
Der Einsatz von Sicherheitstren ist ber den von der Bauaufsicht und der
Feuerwehr vorgeschriebenen Bereich hinaus (vgl. M 1.6 Einhaltung von
Brandschutzvorschriften) besonders bei schutzbedrftigen Rumen wie
Serverraum, Beleg- oder Datentrgerarchiv sinnvoll. Bei hochschutzbe-
drftigen Rumen ist ein ausgewogenes Schutzkonzept zu erstellen, welches
Gefahrenmeldung und Alarmierung und den Einbau von Sicherheitstren
bercksichtigt. Denn hat ein potentieller Angreifer ein ganzes Wochenende
Zeit fr einen Einbruchsversuch, wird ihn auch eine hochwertige einbruch-
hemmende Tr nicht von seinem Ziel abhalten, Daten oder Einrichtung zu
entwenden oder zu zerstren.
Hinweis: Ziel eines Einbruches knnte es auch gewesen sein, Daten oder IT-
Systeme zu manipulieren. Daher sollten zentrale IT-Systeme nach Einbrchen
auf ihre Integritt berprft werden (siehe dazu auch M 6.60 Verhaltensregeln
und Meldewege bei Sicherheitsvorfllen).
Es ist dafr zu sorgen, dass Brand- und Rauchschutztren auch tatschlich
geschlossen und nicht (unzulssigerweise) z. B. durch Keile offen gehalten
werden. Alternativ knnen Tren mit einem automatischen Schliemecha-
nismus, der im Alarmfall aktiviert wird, eingesetzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.11 Lageplne der Versorgungsleitungen

Es sind genaue Lageplne aller Versorgungsleitungen (Strom, Wasser, Gas,
Telefon, Gefahrenmeldung, Rohrpost etc.) im Gebude und auf dem dazu-
gehrenden Grundstck zu fhren und a l l e die Leitungen betreffenden
Sachverhalte aufzunehmen:
- genaue Fhrung der Leitungen (Einzeichnung in bemate Grundriss- und
Lageplne),
- genaue technische Daten (Typ und Abmessung),
- evtl. vorhandene Kennzeichnung,
- Nutzung der Leitungen, Nennung der daran angeschlossenen Netzteil-
nehmer,
- Gefahrenpunkte und
- vorhandene und zu prfende Schutzmanahmen.
Es muss mglich sein, sich anhand der Plne einfach und schnell ein genaues
Bild der Situation zu machen. Nur so kann das Risiko, dass Leitungen bei
Arbeiten versehentlich beschdigt werden, auf ein Mindestma reduziert
werden. Eine Schadstelle ist schneller zu lokalisieren, die Strung schneller zu
beheben.
Es ist sicherzustellen, dass alle Arbeiten an Leitungen rechtzeitig und voll-
stndig dokumentiert werden. Die Plne sind gesichert aufzubewahren und der
Zugriff ist zu regeln, da sie schtzenswerte Informationen beinhalten.
- Wer ist fr die Plne zustndig?
- Werden die Plne aktualisiert?
- Werden die Plne sicher aufbewahrt und sind sie nur von Befugten einseh-
bar?
- Welche Plne existieren bereits?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.12 Vermeidung von Lagehinweisen auf

schtzenswerte Gebudeteile
Schtzenswerte Gebudeteile sind z. B. Serverraum, Rechenzentrum, Daten-
trgerarchiv, Klimazentrale, Verteilungen der Stromversorgung, Schalt- und
Rangierrume, Ersatzteillager.
Solche Bereiche sollten keinen Hinweis auf ihre Nutzung tragen. Trschilder
wie z. B. RECHENZENTRUM oder EDV-ARCHIV geben einem potentiellen
Angreifer, der zum Gebude Zutritt hat, Hinweise, um seine Aktivitten
gezielter und damit Erfolg versprechender vorbereiten zu knnen.
Ist es unvermeidbar, IT in Rumen oder Gebudebereichen unterzubringen,
die fr Fremde leicht von auen einsehbar sind (siehe auch M 1.13 Anordnung
schtzenswerter Gebudeteile), so sind geeignete Manahmen zu treffen, um
den Einblick zu verhindern oder so zu gestalten, dass die Nutzung nicht offen-
bar wird. Dabei ist darauf zu achten, dass z. B. nicht nur ein Fenster einer
ganzen Etage mit einem Sichtschutz versehen wird.
- Welche Lagehinweise knnen von auerhalb erkannt werden?
- Welche Lagehinweise gibt es innerhalb eines Gebudes?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.13 Anordnung schtzenswerter Gebudeteile

Verantwortlich fr Initiierung: Planer, Behrden-/Unternehmensleitung
Verantwortlich fr Umsetzung: Bauleiter, Leiter Haustechnik
Schtzenswerte Rume oder Gebudeteile sollten nicht in exponierten oder
besonders gefhrdeten Bereichen untergebracht sein:
- Kellerrume sind durch Wasser gefhrdet.
- Rume im Erdgeschoss - zu ffentlichen Verkehrsflchen hin - sind durch
Anschlag, Vandalismus und hhere Gewalt (Verkehrsunflle in Gebude-
nhe) gefhrdet.
- Rume im Erdgeschoss mit schlecht einsehbaren Hfen sind durch
Einbruch und Sabotage gefhrdet.
- Rume unterhalb von Flachdchern sind durch eindringendes Regenwasser
gefhrdet.
Als Faustregel kann man sagen, dass schutzbedrftige Rume oder Bereiche
im Zentrum eines Gebudes besser untergebracht sind als in dessen
Auenbereichen.
Optimal ist es, diese Aspekte schon in die Bauplanung fr ein neues Gebude
oder in die Raumbelegungsplanung bei Einzug in ein bestehendes einzubezie-
hen. Bei bereits genutzten Gebuden wird eine entsprechende Nutzungsanord-
nung oft mit internen Umzgen verbunden sein. Ersatzweise sollten die sich
aus ohnehin erforderlichen nderungen der Raumbelegung ergebenden
Gelegenheiten konsequent genutzt werden.
- Welche schtzenswerten Rume befinden sich in exponierter Lage?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.14 Selbstttige Entwsserung

Verantwortlich fr Initiierung: Planer, Behrden-/Unternehmensleitung
Verantwortlich fr Umsetzung: Bauleiter, Leiter Haustechnik
Alle Bereiche, in denen sich Wasser sammeln und stauen kann oder in denen
flieendes oder stehendes Wasser nicht oder erst spt entdeckt wird und in
denen das Wasser Schden verursachen kann, sollten mit einer selbstttigen
Entwsserung und ggf. mit Wassermeldern ausgestattet sein. Zu diesen Berei-
chen gehren u. a.:
- Keller,
- Luftrume unter Doppelbden,
- Lichtschchte,
- Heizungsanlage.
Erfolgt die Entwsserung passiv, also durch Bodengullys direkt in das
Abwassersystem des Gebudes, sind Rckstauklappen unerlsslich. Ohne
solche Klappen wird diese Entwsserung zur Wassereintrittsffnung, wenn
das Abwassersystem berlastet wird. Nach extremen Niederschlgen dringt in
der Mehrzahl aller Flle Wasser ber diesen Weg in Keller ein. Die Rck-
stauklappen mssen regelmig auf ihre Funktionstchtigkeit hin untersucht
werden.
Ist eine passive Entwsserung nicht mglich, weil das Niveau des Abwasser-
systems zu hoch ist, knnen Pumpen eingesetzt werden, die ber Schwim-
merschalter oder Wassersensoren automatisch eingeschaltet werden. Beim
Einsatz dieser Technik sind insbesondere folgende Punkte zu beachten:
- Die Pumpenleistung muss ausreichend bemessen sein.
- Die Druckleitung der Pumpe ist mit einem Rckstauventil auszustatten.
- Es sind Vorkehrungen zu treffen, damit die Pumpe nicht durch mitge-
schwmmte Gegenstnde blockiert werden kann (Ansaugfilter etc.).
- Das Anlaufen der Pumpe sollte automatisch (z. B. beim Hausmeister oder
der Haustechnik) angezeigt werden.
- Die Funktion von Pumpe und Schalter ist regelmig zu testen.
- Die Druckleitung der Pumpe darf nicht an eine in unmittelbarer Nhe vor-
beigefhrte Abwasserleitung angeschlossen werden. Bei einem Leck dieser
Leitung wrde die Pumpe das Wasser nur "im Kreis pumpen".
- Sind die wasserbedrohten Rume mit einer selbstttigen Entwsserung
ausgestattet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.15 Geschlossene Fenster und Tren

Verantwortlich fr Umsetzung: Haustechnik, Mitarbeiter
Fenster und nach auen gehende Tren (Balkone, Terrassen) sind in Zeiten, in
denen ein Raum nicht besetzt sind, zu schlieen. Im Keller- und Erdgeschoss
und, je nach Fassadengestaltung, auch in den hheren Etagen bieten sie einem
Einbrecher auch whrend der Betriebszeiten eine ideale Einstiegsmglichkeit.
Whrend normaler Arbeitszeiten und sichergestellter kurzer Abwesenheit des
Mitarbeiters kann von einer zwingenden Regelung fr Brorume abgesehen
werden.
- Gibt es eine Anweisung, die das Verschlieen der Fenster und Auentren
fordert?
- Wird regelmig berprft, ob die Fenster und Tren nach Verlassen der
Rume verschlossen sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.16 Geeignete Standortauswahl

Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung
Verantwortlich fr Umsetzung: Planer
Bei der Planung des Standortes, an dem ein Gebude angemietet werden oder
entstehen soll, empfiehlt es sich, neben den blichen Aspekten wie Raum-
bedarf und Kosten, auch Umfeldgegebenheiten die Einfluss auf die IT-Sicher-
heit haben zu bercksichtigen:
- In Zusammenhang mit Schwchen in der Bausubstanz kann es durch
Erschtterungen naher Verkehrswege (Strae, Eisenbahn, U-Bahn) zu
Beeintrchtigungen der IT kommen.
- Gebude, die direkt an Hauptverkehrstrassen (Bundesbahn, Autobahn,
Bundesstrae) liegen, knnen durch Unflle beschdigt werden.
- Die Nhe zu optimalen Verkehrs- und somit Fluchtwegen kann die Durch-
fhrung eines Anschlages erleichtern.
- In der Nhe von Sendeeinrichtungen kann es zu Strungen der IT kommen.
- In der Nhe von Gewssern und in Niederungen ist mit Hochwasser zu
rechnen.
- In der Nhe von Kraftwerken oder Fabriken kann durch Unflle oder
Betriebsstrungen (Explosion, Austritt schdlicher Stoffe) die Verfgbar-
keit des Gebudes (z. B. durch Evakuierung oder grorumige Absper-
rung) beeintrchtigt werden.
- Gibt es standortbedingte Gefhrdungen?
- Wie wird diesen Gefhrdungen begegnet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.17 Pfrtnerdienst
Verantwortlich fr Initiierung: Leiter Innerer Dienst
Verantwortlich fr Umsetzung: Innerer Dienst
Die Einrichtung eines Pfrtnerdienstes hat weitreichende positive Auswir-
kungen gegen eine ganze Reihe von Gefhrdungen. Voraussetzung ist aller-
dings, dass bei der Durchfhrung des Pfrtnerdienstes einige Grundprinzipien
beachtet werden.
- Der Pfrtner beobachtet bzw. kontrolliert alle Personenbewegungen an der
Pforte.
- Unbekannte Personen ("selbst der neue Chef") haben sich beim Pfrtner zu
legitimieren.
- Der Pfrtner hlt vor Einlassgewhrung eines Besuchers bei dem Besuch-
ten Rckfrage.
- Der Besucher wird zu dem Besuchten begleitet oder an der Pforte abgeholt.
- Dem Pfrtner mssen die Mitarbeiter bekannt sein. Scheidet ein Mitar-
beiter aus, ist auch der Pfrtner zu unterrichten, ab wann diesem Mitar-
beiter der Einlass zu verwehren ist.
- In einem Besucherbuch kann der Zutritt von Fremdpersonen zum Gebude
dokumentiert werden. Die Ausgabe von Besucherausweisen oder
Besucherbegleitscheinen ist zu erwgen.
Die Arbeitsbedingungen des Pfrtners sind fr die Aufgabenwahrnehmung
geeignet auszugestalten. Die Aufgabenbeschreibung muss verbindlich fest-
schreiben, welche Aufgaben dem Pfrtner im Zusammenspiel mit weiteren
Schutzmanahmen zukommt (z. B. Gebudesicherung nach Dienst- oder
Geschftsschluss, Scharfschaltung der Alarmanlage, Kontrolle der Auentren
und Fenster).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.18 Gefahrenmeldeanlage
Verantwortlich fr Initiierung: Leiter Haustechnik, Brandschutzbeauftragter,
IT-Sicherheitsmanagement
Eine Gefahrenmeldeanlage (GMA) besteht aus einer Vielzahl lokaler Melder,
die mit einer Zentrale kommunizieren, ber die auch der Alarm ausgelst
wird. Ist eine Gefahrenmeldeanlage fr Einbruch, Brand, Wasser oder auch
Gas vorhanden und lsst sich diese mit vertretbarem Aufwand entsprechend
erweitern, sollten zumindest die Kernbereiche der IT (Serverrume,
Datentrgerarchive, Rume fr technische Infrastruktur u. .) in die
berwachung durch diese Anlage mit eingebunden werden. So lassen sich
Gefhrdungen wie Feuer, Einbruch, Diebstahl frhzeitig erkennen und
Gegenmanahmen einleiten. Um dies zu gewhrleisten, ist die Weiterleitung
der Meldungen an eine stndig besetzte Stelle (Pfrtner, Wach- und
Sicherheitsdienst, Feuerwehr, etc.) unumgnglich. Dabei muss sichergestellt
sein, dass diese Stelle auch in der Lage ist, technisch und personell auf den
Alarm zu reagieren. Hierbei sind die Aufschaltrichtlinien der jeweiligen
Institutionen zu beachten.
Eine Gefahrenmeldeanlage ist ein komplexes Gesamtsystem, das dem Ge- Planung und Installation
bude und dem Risiko entsprechend geplant und installiert werden muss.
Planung, Installation und Wartung einer Gefahrenmeldeanlage sollte daher
durch Experten durchgefhrt werden. Falls diese nicht im eigenen Haus vor-
handen sind, sollte auf externe Untersttzung zurckgegriffen werden. So gibt
es beispielsweise eine Vielzahl unterschiedlicher Meldesysteme, die ent-
sprechend der Sicherheitsanforderungen und der Umgebung ausgewhlt
werden mssen. Zur Einbruchserkennung knnen z. B. Bewegungsmelder,
Glasbruchsensoren, ffnungskontakte, Videokameras u. a. eingesetzt werden.
Die Melder knnen untereinander auf verschiedene Arten vernetzt werden. In Vernetzung der Melder
Abhngigkeit von Art und Gre der zu schtzenden Bereiche und der
geltenden Richtlinien mssen passende Systeme ausgewhlt und installiert
werden. Bei der Planung oder Erweiterung einer GMA sollte darauf geachtet
werden, dass die Trassen fr die Vernetzung ausreichend dimensioniert sein
mssen und mglichst wenig nderungen an der Trassenbelegung vorge-
nommen werden sollten.
Um die Schutzwirkung der GMA aufrechtzuerhalten, ist eine regelmige Wartung und Funktions-
prfung
Wartung und Funktionsprfung (DIN VDE 0833 Teil 1-3) vorzusehen.
Ist keine GMA vorhanden oder lsst sich die vorhandene nicht nutzen,
kommen als Minimallsung lokale Gefahrenmelder in Betracht. Diese
arbeiten vllig selbstndig, ohne Anschluss an eine Zentrale. Die Alarmierung
erfolgt vor Ort oder mittels einer einfachen Zweidrahtleitung (evtl. Telefon-
leitung) an anderer Stelle.
Fr den Betrieb eines Rechenzentrums muss eine GMA zur Brand- und
Einbruchdetektion installiert sein. Weitere Detektionsbereiche knnen nach
Lage des Standorts und dessen Infrastruktur sinnvoll sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es gibt Rume wie Serverraum, Datentrgerarchiv, die einen erhhten Frherkennung

Schutzbedarf haben. Wenn keine zentrale GMA vorhanden ist, sind dort
lokale Gefahrenmelder zu installieren. Bei der Verwendung lokaler
Gefahrenmelder fr die Frherkennung muss dafr gesorgt werden, dass ein
Alarm auch auerhalb der betroffenen Rume wahrgenommen wird. Die
Meldung kann ber verschiedene Wege erfolgen und sollte an eine Stelle
weitergeleitet werden, die rund um die Uhr besetzt ist. Beispielsweise gibt es
Lsungen, die ber die TK-Anlage oder Funk Mitarbeiter ber ein Mobil-
telefon alarmieren knnen.
Vor der Planung einer GMA muss ein konsistentes Schutzkonzept fr das
betrachtete Gebude erarbeitet werden. Detaillierte Informationen hierzu
finden sich in der BSI-Publikation "IT-Sicherheit durch infrastrukturelle
Manahmen" (siehe Anhang). Bei der Planung von Gefahrenmeldeanlagen fr
private bzw. gewerbliche Objekte sollte mit dem Sachversicherer geklrt
werden, ob eine Minderung der Versicherungsprmie, insbesondere fr die
Einbruch-Diebstahlversicherung in Frage kommt.
- Gibt es ein Konzept fr die Gefahrenerkennung, Weiterleitung und
Alarmierung und wird dieses an Vernderungen bei der Nutzung ange-
passt?
- Wird die Gefahrenmeldeanlage regelmig gewartet bzw. geprft?
- Wurden alle Mitarbeiter ber die im Alarmfall einzuleitenden Schritte
unterrichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.19 Einbruchsschutz
Verantwortlich fr Initiierung: Leiter Haustechnik, IT-
Sicherheitsmanagement
Erfahrungsgem whlen Einbrecher ihre Ziele danach aus, wie hoch das Erfolgsaussichten
minimieren
Risiko und der Aufwand im Verhltnis zum erwarteten Gewinn sind. Daher
sollten ale Manahmen zum Einbruchsschutz darauf zielen, die
Erfolgsaussichten von Ttern zu minimieren. Die gngigen Manahmen zum
Einbruchsschutz sollten den rtlichen Gegebenheiten entsprechend angepasst
werden. Dazu gehren:
- Rollladensicherungen bei einstiegsgefhrdeten Tren oder Fenster,
- besondere Schliezylinder, Zusatzschlsser und Riegel,
- Sicherung von Kellerlichtschchten,
- Verschluss von nichtbenutzten Nebeneingngen,
- einbruchgesicherte Notausgnge (soweit seitens der rtlichen Bauaufsicht
zugelassen),
- einbruchhemmende Tren, beispielsweise in der Qualitt ET1 oder
hherwertig, wenn die Gefhrdungslage es erforderlich macht,
- Verschluss von Personen- und Lastenaufzgen auerhalb der Dienstzeit.
Empfehlungen hierzu geben die rtlichen Beratungsstellen der Kriminal-
polizei.
Bei der Planung materieller Sicherungsmanahmen ist darauf zu achten, dass Brand- und
Einbruchschutz
Bestimmungen des Brand- und Personenschutzes, z. B. die Nutzbarkeit von abstimmen
Fluchtwegen, nicht verletzt werden. Dies gilt insbesondere fr nderungen an
Brandschutzelementen, die einer Typenfreigabe unterliegen.
Den Mitarbeitern ist durch Regelungen bekanntzugeben, welche Manahmen
zum Einbruchsschutz beachtet werden mssen.
Auch innerhalb eines Gebudes kann der Einbau von einbruchhemmenden
Elementen sinnvoll sein, wie z. B. besonderen zutrittskontrollierten Bereichen
wie Serverrumen oder den Kerneinheiten eines Rechenzentrums.
- Wird geprft, ob die Manahmen zum Einbruchschutz befolgt werden?
- Sind die Regelungen zum Einbruchsschutz den Mitarbeitern bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.20 Auswahl geeigneter Kabeltypen unter

physikalisch-mechanischer Sicht
Verantwortlich fr Initiierung: Netzplaner, Leiter Haustechnik, IT-
Bei der Auswahl von Kabeln ist neben der Bercksichtigung von ber-
tragungstechnischen Notwendigkeiten das Umfeld, in dem die Kabel verlegt
werden sollen, zu beachten. Fr die meisten Verlegebedingungen gibt es
Kabel mit entsprechenden Qualitten. Die wichtigsten sind hier zusammen-
gestellt:
- Innen- bzw. Auenkabel,
- lngswassergeschtztes Kabel fr Feucht- oder Nassbereiche,
- zugentlastete Kabel fr Freileitungen und extreme Steigungen,
- funktionserhaltende Kabel in feuergefhrdeten Bereichen,
- geschirmte Kabel fr Bereiche mit starken elektrischen und induktiven
Strfeldern,
- gepanzerte Kabel fr Flle, in denen ein ausreichender mechanischer
Schutz auf andere Weise nicht realisierbar ist, z. B. bei der provisorischen
Verlegung auf Boden und Wnden.
- Wurde bei der Kabelauswahl der fr die Betriebstechnik Zustndige ber
bekannte oder zu erwartende widrige Umfeldbedingungen befragt?
- Wurden mglich Alternativen der Kabelfhrung geprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.21 Ausreichende Trassendimensionierung

Verantwortlich fr Initiierung: Netzplaner, Leiter IT, Leiter Haustechnik
Kabeltrassen (z. B. Fubodenkanle, Fensterbank-Kanle, Pritschen, Rohr-
trassen im Auenbereich) sind ausreichend zu dimensionieren, d. h., dass
einerseits gengend Platz vorhanden ist, um evtl. notwendige Erweiterungen
des Netzes vornehmen zu knnen. Andererseits sind zur Verhinderung des
bersprechens (gegenseitige Beeinflussung von Kabeln) ggf. Mindestab-
stnde zwischen Kabeln einzuhalten.
Ist es aus unterschiedlichen Grnden nicht mglich, Trassen sofort mit aus-
reichenden Reserven zu errichten, sollte zumindest darauf geachtet werden,
dass im Bereich der Trassenfhrung Platz ist, um Erweiterungen unterzu-
bringen. Bei der Auslegung von Wand- und Deckendurchbrchen erspart dies
sptere lrm-, schmutz- und kostenintensive Arbeiten.
Diese Manahme kann ersetzt werden durch die Auswahl anderer Kabeltypen
(M 2.20 Kontrolle bestehender Verbindungen und M 5.3 Auswahl geeigneter
Kabeltypen unter kommunikationstechnischer Sicht). Durch Verwendung
weniger hochadriger Kabel kann gegenber vielen kleinen Kabeln Platz
eingespart werden. Durch den Einsatz von geschirmten Kabeln oder Licht-
wellenleitern kann bersprechen verhindert werden.
- Wurde die Mglichkeit geprft, durch die Auswahl anderer Kabel Platz zu
sparen und bersprechen zu verhindern?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.22 Materielle Sicherung von Leitungen und

Verteilern
Verantwortlich fr Initiierung: Netzplaner, Leiter Haustechnik, Leiter IT
In Rumen mit Publikumsverkehr oder in unbersichtlichen Bereichen eines
Gebudes kann es sinnvoll sein, Leitungen und Verteiler zu sichern. Dies kann
auf verschiedene Weise erreicht werden:
- Verlegung der Leitungen unter Putz,
- Verlegung der Leitungen in Stahlpanzerrohr,
- Verlegung der Leitungen in mechanisch festen und abschliebaren
Kanlen,
- Verschluss von Verteilern und
- bei Bedarf zustzlich elektrische berwachung von Verteilern und
Kanlen.
Bei Verschluss sind Regelungen zu treffen, die die Zutrittsrechte, die
Verteilung der Schlssel und die Zugriffsmodalitten (was muss der
Berechtigte ggf. vor dem Zugriff auf Leitungen tun?) festlegen.
- Wurde die Zahl der Stellen, an denen das Kabel zugnglich ist, auf ein
Mindestma reduziert?
- Wurde die Lnge zu schtzender Verbindungen mglichst klein gehalten?
- Werden Zutrittsrechte restriktiv vergeben? Werden Personalwechsel und
Vertretungsflle dabei bercksichtigt?
- Werden Zutrittsrechte regelmig auf ihre Berechtigung/Notwendigkeit hin
berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.23 Abgeschlossene Tren

Verantwortlich fr Initiierung: Leiter Haustechnik, Leiter IT
Die Tren nicht besetzter Rume sollten abgeschlossen werden. Dadurch wird
verhindert, dass Unbefugte Zugriff auf darin befindliche Unterlagen und IT-
Einrichtungen erlangen. Das Abschlieen einzelner Bros ist insbesondere
dann wichtig, wenn sich diese in Bereichen mit Publikumsverkehr befinden
oder der Zutritt nicht durch andere Manahmen kontrolliert wird.
Auf das Verschlieen der Tren kann verzichtet werden, wenn diese flurseitig
ber einen Blindknauf verfgen. Voraussetzung hierfr ist allerdings, dass die
befugten Mitarbeiter ihren Schlssel stets mit sich fhren.
In manchen Fllen, z. B. in Groraumbros, knnen Bros nicht abge- Aufrumen statt Ab-
schlieen
schlossen werden. Dann sollte alternativ jeder Mitarbeiter vor seiner Ab-
wesenheit seine Unterlagen ("Clear-Desk-Politik") und den persnlichen
Arbeitsbereich verschlieen: Schreibtisch, Schrank und PC (Schloss fr
Diskettenlaufwerk, Tastaturschloss), Telefon.
Auf das Verschlieen der Tren kann verzichtet werden, wenn keine schutz-
bedrftigen Gegenstnde wie Unterlagen oder Datentrger offen ausliegen und
keine unbefugten Zugriffe auf die IT-Systeme im Raum (und die damit
vernetzten IT-Systeme) mglich sind.
Bei laufendem Rechner kann auf das Abschlieen der Tren verzichtet
werden, wenn eine Sicherungsmanahme installiert ist, mit der die Nutzung
des Rechners nur unter Eingabe eines Passwortes weitergefhrt werden kann
(passwortuntersttzte Bildschirmschoner), der Bildschirm gelscht wird und
wenn das Booten des Rechners die Eingabe eines Passwortes verlangt.
Bei ausgeschaltetem Rechner kann auf das Verschlieen des Bros verzichtet
werden, wenn das Booten des Rechners die Eingabe eines Passwortes ver-
langt. Die gleiche Funktion erfllen Zugangsmechanismen, die auf Token
oder Chipkarten basieren.
- Wird sporadisch berprft, ob Bros beim Verlassen verschlossen werden?
- Werden Mitarbeiter angewiesen, bei Abwesenheit ihr Bro zu ver-
schlieen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.24 Vermeidung von wasserfhrenden Leitungen

Verantwortlich fr Umsetzung: Haustechnik, Administrator
In Rumen oder Bereichen, in denen sich IT-Gerte mit zentralen Funktionen Absperrventile vorsehen
(z. B. Server) befinden, sollten wasserfhrende Leitungen aller Art vermieden
werden. Die einzigen wasserfhrenden Leitungen sollten, wenn unbedingt
erforderlich, Khlwasserleitungen, Lschwasserleitungen und Heizungsrohre
sein. Zuleitungen zu Heizkrpern sollten mit Absperrventilen, mglichst
auerhalb des Raumes oder Bereiches, versehen werden. Auerhalb der Heiz-
periode sind diese Ventile zu schlieen.
Sind wasserfhrende Leitungen unvermeidbar, mssen Vorkehrungen getrof-
fen werden, einen Wasseraustritt mglichst frhzeitig zu erkennen bzw. die
negativen Auswirkungen zu minimieren. Als Minimalschutz kann eine
Wasserauffangwanne oder -rinne unter der Leitung angebracht werden, deren
Ablauf auerhalb des Raumes fhrt. Gnstig ist es, dazu den Flur zu nutzen,
da so ein eventueller Leitungsschaden frher entdeckt wird. Zur frhzeitigen
Erkennung von Wassereinbrchen oder undichten Leitungen hat es sich
bewhrt, Decken hell zu streichen.
Optional knnen Wassermelder mit automatisch arbeitenden Magnetventilen Wassermelder
eingebaut werden. Diese Magnetventile sind auerhalb des Raumes bzw.
Bereiches einzubauen. Damit die Ventile auch bei Stromausfall ihre Schutz-
funktion erfllen, mssen sie im stromlosen Zustand geschlossen sein.
Als zustzliche oder alternative Manahme empfiehlt sich ggf. eine selbst-
ttige Entwsserung (siehe M 1.14 Selbstttige Entwsserung).
Alle Mitarbeiter im Bereich der IT und der Haustechnik sollten darber
informiert sein, dass in Gebudeteilen mit IT-Systemen mit hohen Verfgbar-
keitsanforderungen wasserfhrende Leitungen problematisch sind und was zu
beachten ist.
- Werden evtl. vorhandene Wasserleitungen regelmig auf ihre Dichtigkeit
hin berprft (Sichtprfung)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.25 berspannungsschutz
Verantwortlich fr Initiierung: Leiter IT, Leiter Haustechnik, IT-
Verantwortlich fr Umsetzung: Haustechnik, Administrator
Je nach Qualitt und Ausbau des Versorgungsnetzes des Energieversorgungs-
unternehmens und des eigenen Stromleitungsnetzes, abhngig vom Umfeld
(andere Stromverbraucher) und von der geographischen Lage, knnen durch
Induktion oder Blitzschlag berspannungsspitzen im Stromversorgungsnetz
entstehen. berspannungsschutzmanahmen dienen zur Reduzierung mgli-
cher Schden an IT-Gerten in Netzen durch direkten Blitzeinschlag,
Einkopplung und Schalthandlungen.
Auch ber andere elektrisch leitende Auenanbindungen wie Telefon-,
Wasser- oder Gasleitungen knnen berspannungen in ein Gebude und die
dort betriebene IT gelangen. Darber hinaus knnen berspannungen auch
auf interne Leitungen eingekoppelt werden.
Ein komplettes berspannungsschutzkonzept bercksichtigt alle externen und Alle Verbindungen
beachten
internen elektrisch leitenden Verbindungen und baut sich in drei Stufen auf,
die sich im Wesentlichen an den Bemessungsstospannungen fr die
berspannungskategorien gem DIN VDE 0110/IEC Publikation 664
orientieren:
- Der Grobschutz in der Gebudeeinspeisung ist in der Lage berspannun- Grobschutz
gen abzufangen, wie sie durch direkten Blitzeinschlag entstehen und sie
auf Werte kleiner als 6000 V zu begrenzen. Bei vorhandenem ueren
Blitzschutz muss der Grobschutz blitzstromfhig sein, da mit Strmen im
100 kA-Bereich zu rechnen ist.
- Der Mittelschutz in den Etagenverteilern begrenzt die verbleibenden ber- Mittelschutz
spannungen auf ca. 1500 V und ist darauf angewiesen, dass die von ihm
abzufangenden berspannungen 6000 V nicht berschreiten.
- Der Feinschutz an den jeweiligen Steckdosen und den Steckverbindungen Feinschutz
aller anderen Leitungen reduziert die verbleibenden berspannungen auf
das von den angeschlossenen Gerten verkraftbare Ma. Die Hersteller
elektrischer und elektronischer Gerte sind in den meisten Lndern
verpflichtet, ihre Gerte mit einem fr den sicheren Betrieb erforderlichen
Feinschutz auszustatten (CE-Zeichen deutet darauf hin). In Deutschland ist
dies durch das Gesetz ber die elektromagnetische Vertrglichkeit von
Gerten (EMVG) geregelt.
Die Schutzwirkung jeder Stufe baut auf der vorherigen auf. Der Verzicht auf
eine Stufe macht den gesamten berspannungsschutz nahezu unwirksam.
Ist der gebudeweite Aufbau eines berspannungsschutzes nicht mglich, so Aufbau von Schutzzonen
kann man zumindest wichtige Teile der IT (Server etc.) mit einer entsprechen-
den Schutzzone umgeben. Netze mit einer Vielzahl angeschlossener Gerte
knnen, um einen mglichen Schaden klein zu halten, durch Optokoppler oder
berspannungsableiter in kleine, gegeneinander geschtzte Bereiche aufgeteilt
werden. Dabei mssen geschtzte und nicht geschtzte Bereiche bis zurck zu
der Schutzeinrichtung, bei der die Teilung erfolgt, konsequent getrennt
werden. Die Zuleitungen mssen mit ausreichendem Abstand gefhrt werden,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
eine gemeinsame Verlegung in einem Kabelkanal wrde die Schutzwirkung

aufheben. berspannungsschutzeinrichtungen sollten periodisch und nach
bekannten Ereignissen geprft und ggf. ersetzt werden. Insbesondere bei
Neugestaltung eines Schutzkonzeptes fr berspannung sind Auslegung und
Funktionsweise bestehender USV (unterbrechungsfreier Stromversorgung)
und NEA (Netzersatzanlage) zu bercksichtigen.
Neben dem berspannungsschutz im Versorgungsnetz mssen in Server- Antistatische Boden-
belge
rumen und den Kerneinheiten eines Rechenzentrums Manahmen gegen
elektrostatische Aufladung getroffen werden. Der Durchgangswiderstand der
Bodenbelge in solchen Rumen muss zwischen 10 und 100 Megaohm liegen.
Die Einstufung nach DIN-Vorschrift 4102-1 muss mindestens "B1 schwer
entflammbar" erreichen. Dies gilt auch fr einen Doppelboden oder
Installationsboden.
Zwei Grundvoraussetzungen sind unabhngig von Umfang und Ausbau des
berspannungsschutzes zu beachten:
- Die Leitungslnge zwischen dem Feinschutz und zu schtzenden Gerten
sollte 20 m nicht berschreiten. Falls doch, ist ein erneuter Feinschutz
zwischenzuschalten. Verfgt ein Gert ber einen Feinschutz im Eingang,
entfllt die 20 m Begrenzung.
- Fr einen funktionierenden berspannungsschutz ist ein umfassender Potentialausgleich
Potentialausgleich aller in den berspannungsschutz einbezogenen elek-
trischen Betriebsmittel erforderlich! Die Mehrzahl der Schden an IT-
Gerten durch berspannungen ist auf nicht konsequent umgesetzten
Potentialausgleich zurckzufhren.
- Werden Blitz- und berspannungsschutzeinrichtungen periodisch und nach
bekannten Ereignissen geprft und gegebenenfalls ersetzt?
- Ist ein durchgngiger Potentialausgleich realisiert?
- Wird bei Nachinstallationen darauf geachtet, dass der Potentialausgleich
mitgefhrt wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.26 Not-Aus-Schalter
Bei Rumen, in denen elektrische Gerte in der Weise betrieben werden, dass
z. B. durch deren Abwrme, durch hohe Gertedichte oder durch Vorhanden-
sein zustzlicher Brandlasten ein erhhtes Brandrisiko besteht, ist die Instal-
lation eines Not-Aus-Schalters sinnvoll. Dies sind z. B. Server- oder
Technikrume. Da zur Bettigung des Not-Aus-Schalters Personal erforderlich
ist, kommt er jedoch nur in solchen Bereichen in Frage, in denen stndig oder
meistens Personen anwesend sind. In nicht oder nur sporadisch besetzten
Bereichen ist eine Notabschaltung durch eine Brandfrhesterkennung
wesentlich effektiver.
Mit Bettigung des Not-Aus-Schalters wird dem Brand eine wesentliche
Energiequelle genommen, was bei kleinen Brnden zu deren Verlschen
fhren kann. Zumindest ist aber die Gefahr durch elektrische Spannungen
beim Lschen des Feuers beseitigt.
Zu beachten ist, dass lokale unterbrechungsfreie Stromversorgungen (USV) USV darf bei Not-Aus
nicht anspringen!
nach Ausschalten der externen Stromversorgung die Stromversorgung selbst-
ttig bernehmen und die angeschlossenen Gerte unter Spannung bleiben.
Daher ist bei der Installation eines Not-Aus-Schalters zu beachten, dass auch
die USV abgeschaltet und nicht nur von der externen Stromversorgung ge-
trennt wird.
Der Not-Aus-Schalter sollte innerhalb des Raumes neben der Eingangstr
(evtl. mit Lagehinweis auen an der Tr) oder auerhalb des Raumes neben
der Tr angebracht werden. Dabei ist allerdings zu bedenken, dass dieser Not-
Aus-Schalter auch ohne Gefahr versehentlich oder absichtlich bettigt werden
kann. Daher ist der Not-Aus-Schalter mit einer Abdeckung gegen versehent-
liche Bettigung zu schtzen.
Negativbeispiel:
Ein Serverraum einer mittleren Behrde wurde mit ca. 10 Servern, 5 Laser-
druckern und weiteren Gerten bestckt. Der Raum war nach den Gesichts-
punkten des Einbruchschutzes mit entsprechenden Wnden, Fenstern und
Tren ausgestattet. Ein Not-Aus-Schalter war nicht vorhanden. Es gab nur
zwei Punkte, um diesen Raum gezielt stromlos schalten zu knnen: die
Gebudehauptverteilung im Keller oder die Verteilung des Raumes. Diese
befand sich jedoch an der Wand, die der Eingangstr gegenberlag, im Brand-
falle nahezu unerreichbar.
- Ist fr alle Technikrume berprft worden, ob die Installation eines Not-
Aus-Schalters sinnvoll ist?
- Sind alle Not-Aus-Schalter gegen unbeabsichtigte Bettigung geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.27 Klimatisierung
Um den zulssigen Betriebstemperaturbereich von IT-Gerten zu gewhr-
leisten, reicht der normale Luft- und Wrmeaustausch eines Raumes manch-
mal nicht aus, so dass der Einbau einer Klimatisierung erforderlich wird.
Deren Aufgabe ist es, die Raumtemperatur innerhalb der von der IT vorgege-
benen Toleranzgrenzen zu halten.
Werden darber hinaus Forderungen an die Luftfeuchtigkeit gestellt, um
beispielsweise elektrostatische Aufladungen zu vermeiden, kann ein Klima-
gert durch Be- und Entfeuchtung auch diese erfllen. Dazu muss das Klima-
gert allerdings an eine Wasserleitung angeschlossen werden. M 1.24
Vermeidung von wasserfhrenden Leitungen ist zu beachten.
Um die Schutzwirkung aufrechtzuerhalten, ist eine regelmige Wartung der Wartung und ber-
wachung
Klimatisierungseinrichtung vorzusehen. Eine zustzliche berwachungs-
einrichtung fr die Klimatisierung ist zu empfehlen, insbesondere bei Voll-
klimatisierung.
Da bei einem Ausfall der Klimatisierung unter Umstnden viele (insbesondere
wichtige) IT-Systeme abgeschaltet werden mssen, sollte diese auf eine hohe
Verfgbarkeit ausgelegt sein. Sie sollte mit einer grozgigen Leistungs-
reserve dimensioniert sein, auerdem sollte sie einfach erweiterbar sein. Die
Klimatisierung sollte bei der Notfallplanung (siehe Kapitel 3.3
Notfallvorsorge-Konzept) nicht vergessen werden.
Fr einen Serverraum oder ein Rechenzentrum ist zur Bestimmung der Wrmelastberechnung
ntigen Khlleistung eine exakte Wrmelastberechnung durchzufhren. Eine
Frischluft-Beimischung ist dann erforderlich, wenn der oder die klimatisierten
Rume stndig mit Personal besetzt sind.
Ebenso ist durch mehrere Messungen zu verschiedenen Tageszeiten zu
bestimmen, ob eine Luftbefeuchtung oder -entfeuchtung in solchen Rumen
erforderlich ist. Hier sind auch Herstellervorgaben fr die betriebenen IT-
Komponenten zu beachten.
Wrmetauscher und Rckkhlwerke sollten mglichst nicht direkt in einem
Serverraum oder Rechenzentrum aufgestellt sein, um zu verhindern, dass
Schden an der Klimaanlage weitere Beeintrchtigungen verursachen, z. B.
durch austretende Khlflssigkeit oder Kurzschlsse.
Die Rckkhlwerke der Klimaanlage sind bei Aufstellung im Freien gegen
direkten Blitzeinschlag zu schtzen. Insbesondere in Hochsicherheitsbereichen
sollten die Rckkhlwerke nicht fr jedermann zugnglich sein und
gegebenenfalls gegen Sabotage materiell geschtzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- In welchen fr IT genutzten Rumen knnen erhhte Temperaturen auf-
treten?
- Werden eingesetzte Klimagerte regelmig gewartet?
- Welches sind die fr die IT zulssigen Hchst- und Tiefstwerte fr Tempe-
ratur und Luftfeuchte?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.28 Lokale unterbrechungsfreie Stromversorgung

Verantwortlich fr Initiierung: Leiter Haustechnik, Leiter IT, IT-
Verantwortlich fr Umsetzung: Administrator, Haustechnik
Mit einer unterbrechungsfreien Stromversorgung (USV) kann ein kurzzeitiger
Stromausfall berbrckt werden oder die Stromversorgung solange aufrecht-
erhalten werden, dass ein geordnetes Herunterfahren angeschlossener Rechner
mglich ist. Dies ist insbesondere dann sinnvoll,
- wenn im Rechner umfangreiche Daten zwischengespeichert werden (z. B.
Cache-Speicher im Netz-Server), bevor sie auf nichtflchtige Speicher
ausgelagert werden,
- beim Stromausfall ein groes Datenvolumen verloren gehen wrde und
nachtrglich nochmals erfasst werden msste,
- wenn die Stabilitt der Stromversorgung nicht ausreichend gewhrleistet
ist.
Zwei Arten der USV sind zu unterscheiden: offline / online
- offline-USV: Hierbei werden die angeschlossenen Verbraucher im

Normalfall direkt aus dem Stromversorgungsnetz gespeist. Erst wenn
dieses ausfllt, schaltet sich die USV selbstttig zu und bernimmt die
Versorgung.
- online-USV: Hier ist die USV stndig zwischen Netz und Verbraucher
geschaltet. Die gesamte Stromversorgung luft immer ber die USV.
Beide USV-Arten knnen neben der berbrckung von Totalausfllen der
Stromversorgung und Unterspannungen auch dazu dienen, berspannungen
zu gltten. Auch hier gilt hinsichtlich des berspannungsschutzes die in
M 1.25 berspannungsschutz erluterte Begrenzung auf 20 m.
Werden IT-Gerte in einem Gebude mit TN-S-Netz (siehe dazu M 1.39
Verhinderung von Ausgleichsstrmen auf Schirmungen) mit einer lokalen
USV versorgt, ist Folgendes zu beachten: Um die Schutzwirkung des TN-S-
Netzes gegen Ausgleichsstrme auf Schirmen von Datenleitungen aufrecht zu
erhalten, ist darauf zu achten, dass USV-ausgangsseitig keine Verbindung
zwischen N- und PE-Leiter (Nullung) besteht. Ggf. sind solche oft serien-
mig eingebauten Verbindungen vor Einbau in das TN-S-Netz zu entfernen.
Bei der Dimensionierung einer USV kann man in der Regel von einer Dimensionierung
blichen berbrckungszeit von ca. 10 bis 15 Minuten ausgehen. Die Mehr-
zahl aller Stromausflle ist innerhalb von 5 bis 10 Minuten behoben, so dass
nach Abwarten dieser Zeitspanne noch 5 Minuten brig bleiben, um die ange-
schlossene IT geordnet herunterfahren zu knnen, sollte der Stromausfall
lnger andauern. Die meisten modernen USV-Gerte bieten Rechnerschnitt-
stellen an, die nach einer vorher festgelegten Zeit, entsprechend dem Zeit-
bedarf der IT und der Kapazitt der USV, ein rechtzeitiges automatisches
Herunterfahren (Shut-down) einleiten knnen.
Fr spezielle Anwendungsflle (z. B. TK-Anlagen) kann die erforderliche
berbrckungszeit auch mehrere Stunden betragen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Um die Schutzwirkung aufrechtzuerhalten, ist eine regelmige Wartung der

USV vorzusehen.
Falls die Mglichkeit besteht, die Stromversorgung unterbrechungsfrei aus
einer anderen Quelle zu beziehen (z. B. durch Anschluss an eine zentrale
USV), so stellt dies eine Alternative zur lokalen USV dar.
- Werden die Wartungsintervalle der USV eingehalten?
- Ist ein automatisches Shut-down vorgesehen?
- Wird die Wirksamkeit der USV regelmig getestet?
- Haben sich Vernderungen ergeben, so dass die vorgehaltene Kapazitt der
USV nicht mehr ausreichend ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.29 Geeignete Aufstellung eines IT-Systems

Verantwortlich fr Umsetzung: Haustechnik, IT-Benutzer
Bei der Aufstellung eines IT-Systems sollten verschiedene Voraussetzungen
beachtet werden, die die Lebensdauer und Zuverlssigkeit der Technik ver-
bessern und die Ergonomie bercksichtigen. Einige seien hier genannt:
- ein IT-System sollte nicht in unmittelbarer Nhe der Heizung aufgestellt
werden, um eine berhitzung zu vermeiden,
- ein IT-System sollte nicht der direkten Sonneneinstrahlung ausgesetzt sein,
- Staub und Verschmutzungen sollten vermieden werden, da die mecha-
nischen Bauteile (Diskettenlaufwerke, mechanische Maus, Festplatten)
beeintrchtigt werden knnen,
- direkte Lichteinstrahlung auf den Bildschirm sollte aus ergonomischen
Grnden vermieden werden,
- der Standort in der Nhe eines Fensters oder einer Tr erhht die Gefahr
des Beobachtens von auerhalb.
Weitere Hinweise sind den Empfehlungen der Berufsgenossenschaften zu
entnehmen.
- Sind durch den Aufstellungsort bedingte Ausflle in der Vergangenheit zu
beobachten gewesen?
- Beklagen sich Benutzer von IT-Systemen ber unzureichende ergono-
mische Bedingungen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.30 Absicherung der Datentrger mit TK-

Gebhrendaten
Verantwortlich fr Initiierung: TK-Anlagen-Verantwortlicher,
Verantwortlich fr Umsetzung: Administrator
Auf den TK-Anlagen fallen whrend des Betriebes Gebhrendaten an. Diese
enthalten Informationen ber:
- Zeit und Datum eines Gesprches,
- Quell- und Zielrufnummer sowie die
- Gesprchsdauer.
Gebhrendaten sind personenbezogene Daten im Sinne der einschlgigen
Bundes- und Landesdatenschutzgesetze. Hieraus folgt, dass auch nach den im
folgenden vorgeschlagenen Manahmen des IT-Grundschutzes in jedem Fall
eine gesonderte Betrachtung im Hinblick auf die Anforderungen der Daten-
schutzgesetze (z. B. aus der Anlage zum 9 Bundesdatenschutzgesetz)
durchzufhren ist.
Diese Daten knnen sowohl auf der Festplatte der TK-Anlage selbst als auch
auf einem externen Gebhrenrechner gespeichert werden. In vielen Fllen
wird es eine Kombination beider Varianten geben. Die Rechner sind - wenn
mglich - so zu schtzen, dass nur Berechtigte auf die Gebhrendaten zugrei-
fen knnen. Dazu ist es erforderlich, den Gebhrenrechner in einem besonders
geschtzten Raum (vgl. Kapitel 4.3.2 Serverraum) aufzustellen. Fr Ein-
richtungen, auf denen Gebhrendaten gespeichert sind, mssen ferner die
Manahmen M 1.23 Abgeschlossene Tren, M 2.5 Aufgabenverteilung und
Funktionstrennung, M 2.6 Vergabe von Zutrittsberechtigungen, M 2.7
Vergabe von Zugangsberechtigungen, M 2.8 Vergabe von Zugriffsrechten,
M 2.13 Ordnungsgeme Entsorgung von schtzenswerten Betriebsmitteln
und M 2.17 Zutrittsregelung und -kontrolle realisiert werden.
- Wer hat Zugriff auf die Gebhrendaten?
- Wie wird der Zugriffsschutz realisiert?
- Haben nur die Benutzer mit berechtigtem Interesse Zugriffsrecht?
- Wo befinden sich die Sicherungskopien und wer hat dort Zugang?
- Wie werden die Datentrger entsorgt?
- Wie lange werden die Daten gespeichert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.31 Fernanzeige von Strungen

Verantwortlich fr Initiierung: Leiter IT, TK-Anlagen-Verantwortlicher, IT-
IT-Gerte und Supportgerte, die keine oder nur seltene Bedienung durch eine
Person erfordern, werden oft in ge- und verschlossenen Rumen untergebracht
(z. B. Serverraum). Das fhrt dazu, dass Strungen, die sich in ihrem
Frhstadium auf die IT noch nicht auswirken und einfach zu beheben sind,
erst zu spt, meist durch ihre Auswirkungen auf die IT, entdeckt werden.
Feuer, Funktionsstrungen einer USV oder der Ausfall eines Klimagertes
seien als Beispiele fr solche "schleichenden" Gefhrdungen angefhrt.
Durch eine Fernanzeige ist es mglich, solche Strungen frher zu erkennen.
Viele Gerte, auf die man sich verlassen muss, ohne sie stndig prfen oder
beobachten zu knnen, haben heute einen Anschluss fr Strungsfern-
anzeigen. Die technischen Mglichkeiten reichen dabei von einfachen
Kontakten, ber die eine Warnlampe eingeschaltet werden kann, bis zu
Rechnerschnittstellen mit dazugehrigem Softwarepaket fr die gngigen
Betriebssysteme. ber die Schnittstellen ist es oft sogar mglich, jederzeit den
aktuellen Betriebszustand der angeschlossenen Gerte festzustellen und so
Ausfllen rechtzeitig begegnen zu knnen.
- Wissen die durch die Fernanzeige Alarmierten, welche Handlungen auszu-
fhren sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.32 Geeignete Aufstellung von Konsole, Gerten mit

austauschbaren Datentrgern und Druckern
Verantwortlich fr Initiierung: Leiter IT, TK-Anlagen-Verantwortlicher, IT-
Diese Manahme dient der Absicherung der Schnittstellen eines IT-Systems
zur Auenwelt, um auch dort den Sicherheitsanforderungen in bezug auf die
gespeicherten und verarbeiteten Daten zu entsprechen, die im IT-System
durch die internen Sicherheitsmechanismen und durch die Manahmen im
Bereich Hardware/Software gewhrleistet sind. Der Schutz vor unbefugtem
Lesen von Informationen, der innerhalb des Systems durch die Mechanismen
der Zugriffskontrolle gegeben ist, muss an diesen Shnittstellen hauptschlich
durch infrastrukturelle oder organisatorische Manahmen gewhrleistet
werden.
Um Manipulationen an der Konsole, an Gerten mit austauschbaren Daten-
trgern und an Druckern zu verhindern, mssen diese so aufgestellt werden,
dass nur Berechtigte Zugang haben.
Insbesondere gilt:
- Bei Unix-Systemen drfen Unbefugte keinen Zugang zur Konsole erhalten,
weil sie dort unter Umstnden den Unix-Rechner in den Single-User-
Modus booten bzw. den Monitor-Modus aktivieren knnen und damit
Systemadministrator-Rechte erlangen.
- Es ist sicherzustellen, dass an den Gerten fr austauschbare Datentrger
- wie Streamern, Diskettenlaufwerken, Wechselplatten usw. - kein
missbruchliches Ein- und Auslesen von Dateien mglich ist.
- Nur Berechtigte drfen Zutritt zu Rumen mit Druckern / Ausdrucken
haben. Dieses kann z. B. durch Aufstellung der Drucker in einem
geschlossenen Raum und Verteilung der Ausdrucke in nur fr den jewei-
ligen Empfnger zugngliche Fcher durch eine vertrauenswrdige Person
erreicht werden. Druckerausgaben mssen daher mit dem Namen des
Empfngers gekennzeichnet sein. Dieses kann automatisch durch die
Druckprogramme erfolgen.
Diese Manahme wird ergnzt durch folgende Manahmen:
M 4.18 Administrative und technische Absicherung des Zugangs zum
Monitor- und Single-User-Modus,
M 4.21 Verhinderung des unautorisierten Erlangens von
Administratorrechten
- Sind Konsole, Gerte fr austauschbare Datentrger und Druckerausgaben
vor unbefugtem Zugriff geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.33 Geeignete Aufbewahrung tragbarer IT-Systeme

bei mobilem Einsatz
Verantwortlich fr Umsetzung: Benutzer
Da die Umfeldbedingungen bei mobilem Einsatz meist auerhalb der direkten
Einflussnahme der Benutzer liegen, mssen diese versuchen, mobile IT-
Systeme wie Laptops oder PDAs auch auer Haus sicher aufzubewahren.
Hierfr knnen nur einige Hinweise gegeben werden, die bei der mobilen
Nutzung zu beachten sind:
- Schutz vor Diebstahl
- Nach Mglichkeit sollten die Zeiten, in denen das Gert unbeauf- Nicht unbeobachtet
zurcklassen
sichtigt bleibt, minimiert werden.
- Wird ein tragbarer PC oder PDA in einem Kraftfahrzeug aufbe-
wahrt, so sollte das Gert von auen nicht sichtbar sein. Das
Abdecken des Gertes oder das Einschlieen in den Kofferraum
bieten Abhilfe. Ein mobiles IT-System kann einen hohen Wert dar-
stellen, der potentielle Diebe anlockt, zumal tragbare IT-Systeme
leicht veruert werden knnen.
- Wird das mobile IT-System in fremden Brorumen vor Ort benutzt,
so ist entweder dieser Raum nach Mglichkeit auch bei kurzzeitigem
Verlassen zu verschlieen oder das Gert mitzunehmen. Wird der
Raum fr lngere Zeit verlassen, sollte zustzlich das mobile IT-
System ausgeschaltet werden oder ein Zugriffsschutz aktiviert, um
eine unerlaubte Nutzung zu verhindern.
- In Hotelrumen sollte das mobile IT-System nicht offen herum- Gelegenheit macht Diebe
liegen. Das Verschlieen des Gertes in einem Schrank behindert
Gelegenheitsdiebe.
- Einige neuere Gerte bieten zustzlich die Mglichkeit zum Anket-
ten des Gertes. Der Diebstahl setzt dann den Einsatz von Werkzeug
voraus.
- Ein mobiles IT-System sollte nie extremen Temperaturen ausgesetzt Vorsicht vor extremen
Temperaturen
werden. Insbesondere der Akku, aber auch das Display knnen anderen-
falls beschdigt werden. Insbesondere sollten weder IT-Gerte noch Akkus
in geparkten Autos zurckgelassen werden.
- Ebenso sollten mobile Endgerte vor Umwelteinflssen geschtzt werden, Auch Feuchtigkeit
schadet
die diese schdigen knnen, also beispielsweise vor Feuchtigkeit durch
Regen oder Spritzwasser.
- Mobile Endgerte sind auch nicht unzerstrbar, daher sollten sie auch bei
krzeren Transportwegen mglichst stogeschtzt befrdert werden. Bei
Laptops sollte beispielsweise das Gert zusammengeklappt werden, da
sowohl die Scharniere als auch der Bildschirm bei einem Sturz leicht
beschdigt werden knnen. Grundstzlich ist es immer empfehlenswert, fr
den Transport ein schtzendes Behltnis zu verwenden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es ist empfehlenswert, fr die Benutzer mobiler IT-Systeme ein Merkblatt zu

erstellen, das die wichtigsten Hinweise und Vorsichtsmanahmen zur geeig-
neten Aufbewahrung und zum sicheren Transport der Gerte enthlt.
- Werden die Benutzer von tragbaren IT-Systemen auf die geeignete Aufbe-
wahrung hingewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.34 Geeignete Aufbewahrung tragbarer PCs im

stationren Einsatz
Verantwortlich fr Umsetzung: IT-Benutzer
Wird ein tragbarer PC zeitweise stationr in einem Bro betrieben, so sind die
in Kapitel 4.3.1 Broraum beschriebenen Manahmen zu beachten. Da ein
tragbarer PC jedoch besonders leicht zu transportieren und zu verbergen ist,
sollte das Gert auerhalb der Nutzungszeit in einem Schrank verschlossen
werden.
- Wie werden tragbare PCs in den Bros aufbewahrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.35 Sammelaufbewahrung mehrerer tragbarer PCs

Sind in einer Behrde bzw. einem Unternehmen eine Vielzahl von tragbaren
PCs im (mobilen) Einsatz und wechseln die Benutzer hufig, kann es ange-
bracht sein, die zeitweise nicht genutzten tragbaren PCs in einer Sammel-
aufbewahrung (Pool) zu halten. Der dafr genutzte Raum sollte den Anforde-
rungen, die in Kapitel 4.3.4 Raum fr technische Infrastruktur beschriebenen
werden, entsprechen.
Darber hinaus ist die Stromversorgung der tragbaren PCs sicherzustellen,
damit die Batterien dieser Gerte den sofortigen Einsatz erlauben. Zustzlich
mssen die Rcknahme und die Ausgabe von tragbaren PCs dokumentiert
werden.
- Wer hat Zutritt zur Sammelaufbewahrung der tragbaren PCs?
- Wird die Ausgabe und Rcknahme der PCs dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.36 Sichere Aufbewahrung der Datentrger vor und

nach Versand
Verantwortlich fr Initiierung: IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: IT-Benutzer, Poststelle
Vor dem Versand eines Datentrgers ist zu gewhrleisten, dass fr den Zeit-
raum zwischen dem Speichern der Daten auf dem Datentrger und dem
Transport ein ausreichender Zugriffsschutz besteht. Sind die zu bermitteln-
den Daten auf den Datentrger geschrieben, so sollte dieser bis zum Transport
in entsprechenden Behltnissen (Schrank, Tresor) verschlossen aufbewahrt
werden. Die fr den Transport oder fr die Zustellung Verantwortlichen (z. B.
Poststelle) sind auf sachgerechte und sichere Aufbewahrung und Handhabung
des Datentrgers hinzuweisen.
- Sind die Mitarbeiter darauf hingewiesen worden, fr den Transport vorge-
sehene Datentrger nicht frei zugnglich aufzubewahren?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.37 Geeignete Aufstellung eines Faxgertes

Verantwortlich fr Umsetzung: Haustechnik, IT-Benutzer, Fax-
Verantwortlicher
Ein Faxgert sollte in einem Bereich installiert werden, der nicht ffentlich
zugnglich ist. Eine Kontrolle des Zutritts zu diesem Bereich oder der
Nutzung des Faxgertes ist sinnvoll.
Sinnvollerweise kann dies durch die Aufstellung in einem stndig besetzten
Raum (z. B. Geschftszimmer, Sekretariat, Poststelle) erreicht werden.
Auerhalb der Dienstzeiten oder bei Abwesenheit der berechtigten Benutzer
sollte das Gert eingeschlossen werden (Raum oder Schrank). Wichtig ist in
diesem Zusammenhang, dass verhindert werden muss, dass eingegangene
Faxsendungen von Unberechtigten eingesehen oder entnommen werden
knnen (vgl. M 2.48 Festlegung berechtigter Faxbediener).
- Wer kann das Faxgert unkontrolliert nutzen?
- Zu welchen Zeiten ist dies einfach mglich (Mittagspause, Schichtwechsel,
...)?
- Wie wird der Zugang zum Faxgert kontrolliert?
- Wie wird das Gert auerhalb der Dienstzeiten geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.38 Geeignete Aufstellung eines Modems

Verantwortlich fr Umsetzung: IT-Benutzer, Administrator
Um den Missbrauch von Modems zu verhindern, muss sichergestellt werden,
dass nur Berechtigte physikalischen Zugriff darauf haben. Missbrauch
bedeutet hier zum einem die Durchfhrung unbefugter Datenbertragungen,
durch die Kosten verursacht, Viren eingeschleppt oder Interna nach auen
transferiert werden knnen, und zum anderen das unbefugte ndern oder
Auslesen der Modem-Konfiguration, wodurch Sicherheitslcken entstehen
knnen.
Um den physikalischen Zugriff auf ein externes Modem oder ein PCMCIA-
Modem abzusichern, ist z. B. bei einem stndig benutzten Modem das
Abschlieen des Raumes oder bei einem nur zeitweise benutzten Modem das
sichere Aufbewahren des inaktiven Modems in einem Schrank zu gewhr-
leisten. Die Manahmen des Kapitels 4.3.1 Broraum, sind zu beachten.
Ein internes Modem besitzt aufgrund des Einbaus in ein IT-System einen
hheren inhrenten physikalischen Zugriffsschutz. Hier wrde es reichen, die
Manahmen der Kapitel 4.3.1 Broraum oder 4.3.2 Serverraum zu beachten.
Wenn ber ein Modem oder einen Modem-Pool Zugnge zum internen Netz
geschaffen werden, ist das Kapitel7.3 Sicherheitsgateway (Firewall) zu
beachten. ber Modems darf kein Zugang zum internen Netz unter
Umgehung einer bestehenden Firewall geschaffen werden.
Wenn mit einem Modem-Pool weitere externe Zugnge zu einem durch eine
Firewall geschtzten Netz geschaffen werden sollen, muss dieser auf der
unsicheren Seite der Firewall aufgestellt werden (siehe auch M 2.77
Integration von Servern in das Sicherheitsgateway). Der Modem-Pool sollte
zusammen mit dem zugehrigen Server in einem gesicherten Serverraum
aufgestellt sein. Die Manahmen des Kapitels 4.3.2 Serverraum Serverraum
sind zu beachten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.39 Verhinderung von Ausgleichsstrmen auf

Schirmungen
Verantwortlich fr Initiierung: Leiter IT
Um Ausgleichsstrme auf den Schirmungen von Datenleitungen in Gebuden
zu verhindern, gibt es verschiedene Mglichkeiten:
Ausgleichsstrme knnen im TN-C-Netz vermieden werden, indem nur solche geschirmte
Datenleitungen
IT-Gerte miteinander ber geschirmte Datenleitungen miteinander verbunden
werden, die an einer gemeinsamen Elektro-Verteilung angeschlossen sind. Bei
jeder Erweiterung des Datennetzes ist diese Bedingung zu prfen und sicher-
zustellen.
Als Manahme gegen Ausgleichsstrme im TN-C- bzw. TN-CS-Netz wird Einseitiges Auflegen der
Schirmung
hufig das ausschlielich einseitige Auflegen der Schirmung von Daten-
leitungen vorgeschlagen. Hinsichtlich der Ausgleichsstrme ist dieses Vor-
gehen auch tatschlich wirksam. Aus anderen Grnden sollte dieses Mittel
aber als absolute Ausnahme uerst restriktiv angewandt werden:
- Geschirmte Leitungen, deren Schirmung nur einseitig aufgelegt ist, werden
deutlich strker durch Strstrahlungen von auen beeinflusst. Gleichzeitig
strahlen sie selbst strker ab, als ungeschirmte symmetrische Leitungen. Es
muss also bei einseitiger Schirmauflegung mit mehr Strungen der Daten-
bertragung (z. B. der Verfgbarkeit bzw. Integritt) gerechnet werden, als
bei allen anderen Kabeln. Die strkere Aussendung auswertbarer Abstrah-
lung derartiger Leitungen kommt als Risiko bei der Betrachtung der Ver-
traulichkeit von Informationen hinzu.
- Selbst wenn man alle technischen Nachteile der einseitigen Schirmauf-
legung hinzunehmen bereit ist, bleibt das Problem der Durchgngigkeit. Es
bedarf konsequenter Kontrolle bei allen Arbeiten im Datennetz, um sicher
zu stellen, dass einseitig aufgelegte Schirmungen nicht doch irgendwann
beidseitig aufgelegt werden. Solche Fehlauflegungen sind nachtrglich nur
mit sehr groen Suchaufwand festzustellen.
Die optimale, weil sicherste Mglichkeit besteht darin, das Stromverteilnetz Potentialausgleich
im gesamten Gebude komplett als TN-S-Netz auszulegen. Dabei wird der
PE- und der N-Leiter ab der Potentialausgleichsschiene (PAS) getrennt
gefhrt. Einzelmanahmen an IT-Gerten sind dann in der Regel nicht mehr
erforderlich. Zu beachten ist jedoch der Hinweis in M 1.28 Lokale
unterbrechungsfreie Stromversorgung hinsichtlich der Bildung eines neuen
TN-S-Netzes fr die angeschlossenen Gerte.
Die nachfolgenden Zeichnungen erlutern die Entstehung von Ausgleichs-
strmen auf Schirmungen und die mglichen Gegenmanahmen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abb. 1: Entstehung von Ausgleichsstrmen auf Schirmungen und die

mglichen Gegenmanahmen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welche Netzart ist in der Liegenschaft vorhanden?
- Wie und durch wen werden die Schutzbedingungen (eine gemeinsame
Verteilung oder nur einseitig aufgelegter Schirm) geprft?
- Werden nderungen im Datennetz mit der Haustechnik abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.40 Geeignete Aufstellung von Schutzschrnken

Aufgrund des in der Regel hohen Gewichts von Schutzschrnken muss vor der
Aufstellung die Tragfhigkeit des Fubodens am Aufstellungsort geprft
werden.
Schutzschrnke, die aufgrund ihrer geringen Gre relativ einfach weggetra-
gen werden knnten, sollten in der Wand oder im Boden verankert werden.
Eventuell vorhandene Herstellerhinweise zur geeigneten Aufstellung (z. B.
freie Lftungsffnungen, Kabelfhrungen) sind zu bercksichtigen.
- Wie wird der Diebstahl eines Schutzschrankes verhindert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.41 Schutz gegen elektromagnetische Einstrahlung

Verantwortlich fr Umsetzung: Beschaffer, Haustechnik
Werden in einem Schutzschrank informationstechnische Gerte untergebracht,
so kann durch benachbarte Einrichtungen elektromagnetische Strahlung
erzeugt werden, die die Funktion der Gerte beeintrchtigt (insbesondere in
industriellen Produktionsbereichen). Durch Nachrstung von Filtern und
Trdichtungen kann die Einstrahlung innerhalb des Schutzschrankes reduziert
werden. Gleichzeitig verhindern diese Manahmen auch eine Verbreitung von
kompromittierender Abstrahlung der im Schrank befindlichen Gerte.
- Ist eine Gefhrdung durch elektromagnetische Einstrahlung gegeben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.42 Gesicherte Aufstellung von Novell Netware

Servern
Um den manipulationssicheren Betrieb von Novell Netware Servern sicher-
zustellen, ist es zwingend erforderlich, die Novell Netware Server in einer
gesicherten Umgebung aufzustellen. Dies kann entweder ein Serverraum sein
(vgl. Kapitel 4.3.2 Serverraum) oder ein Serverschrank, wenn kein separater
Serverraum zur Verfgung steht (vgl. Kapitel 4.4 Schutzschrnke). Unbefugte
drfen zum Aufstellungsort von Novell Netware Servern keinen unbeaufsich-
tigten Zugang erhalten. Das Diskettenlaufwerk von Novell Netware Servern
ist darber hinaus standardmig mit einem Diskettenschloss zu verschlieen.
Weiterhin sollte mit Hilfe von SYS:SYSTEM\MONITOR.NLM die unmittelbare
Dateneingabe an der Serverkonsole durch ein Passwort verhindert werden.
Dabei sollte der Befehl LOAD MONITOR.NLM -L bereits in der Datei
SYS:SYSTEM\AUTOEXEC.NCF mit eingepflegt werden. Dies veranlasst den
Server, bei jedem Start die Serverkonsole mit einem Passwort zu schtzen.
Dabei muss allerdings bercksichtigt werden, dass hier das Passwort des
Bindery-Benutzers SUPERVISOR zum Entriegeln des Servers notwendig ist.
Dieses ist zum Zeitpunkt der Installation des Netware 4.x Servers identisch
mit dem Passwort des Benutzers, der den Server in der NDS installiert hat.
Dies ist in der Regel der NDS-Benutzer ADMIN. Wird allerdings das Passwort
des Benutzers ADMIN regelmig gendert, ist dies nicht gleichbedeutend mit
der nderung der Passwrter der Bindery-Benutzer SUPERVISOR auf den
jeweiligen NDS-Servern. Daraus ergibt sich das Problem, dass die jeweiligen
SUPERVISOR Passwrter, von denen jeder Novell NDS-Server jeweils sein
eigenes besitzt, hufig auf einem alten Stand verbleiben, der zudem leicht in
Vergessenheit geraten kann.
Ein weiterer wichtiger Befehl, mit dem die Serverkonsole gesichert werden
muss, ist SECURE CONSOLE. Dieser Befehl deaktiviert den Debugger des
Servers. Ohne diesen Befehl wre es z. B. auch mglich, den Debugger zu
erreichen, obwohl die Konsole des Servers mit einem Passwort geschtzt ist.
Weitere wichtige Funktionen des Befehls SECURE CONSOLE sind:
- Netware Loadable Modules (NLM) knnen nur noch von SYS:SYSTEM
und eventuell anderen vorhandenen Suchpfaden geladen werden, wobei
DOS-Suchpfade automatisch entfernt werden,
- einige SET Parameter knnen nicht mehr verndert werden,
- Datum und Zeit knnen an der Serverkonsole nicht mehr eingestellt
werden und
- der Systemdebugger des Servers kann nicht mehr erreicht werden.
- Ist auch im Vertretungsfall ausschlielich der autorisierte Zugriff auf den
Novell Netware Server sichergestellt?
- Ist jeder Novell Netware Server in einem Serverraum oder Serverschrank
untergebracht?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.43 Gesicherte Aufstellung aktiver

Netzkomponenten
Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement,
Netzplaner
Verantwortlich fr Umsetzung: Leiter Haustechnik, Administrator
Um den manipulationssicheren Betrieb eines Netzes sicherzustellen, ist es
erforderlich, aktive Netzkomponenten (wie Router, Switches, ISDN-Router)
in einer gesicherten Umgebung zu betreiben. Dies kann entweder ein
Serverraum sein (siehe Kapitel 4.3.2 Serverraum) oder, wenn kein separater
Serverraum zur Verfgung steht, ein Serverschrank (siehe Kapitel 4.4
Schutzschrnke). Unbefugte Personen drfen zum Aufstellungsort der Gerte
keinen unbeaufsichtigten Zugang erhalten.
Dabei sollte beachtet werden, dass Hersteller von Schutzschrnken oft
Standardschlsser einsetzen, so dass mit einem beliebigen Schlssel des
Schrankherstellers alle Schrnke geffnet werden knnen. Daher muss
gegebenenfalls das serienmige Schloss eines Schutzschranks gegen ein
individuelles Schloss ausgetauscht werden.
Auerdem sollten die Gerte so aufgestellt werden, dass sie vor
elektromagnetischen oder magnetischen Feldern geschtzt sind. Zustzlich
sollten sie mit Kontrollmechanismen ausgestattet sein, die eine
berschreitung der zulssigen Toleranzen bei Feuchtigkeit und Temperatur
signalisieren.
Der Schutz von Routern und Switches vor unbefugtem Zugriff ist auch
deswegen sehr wichtig, weil fr viele Gerte Passwort-Recovery-Prozeduren
fr das Rcksetzen von Passwrtern bekannt sind, die zumeist den
physikalischen Zugang zu den Gerten (Konsolenanschluss) voraussetzen. Oft
verfgen die Gerte auch ber PCMCIA-Slots: Entsprechende PCMCIA-
Karten knnen fr die allgemeine Speicherung von Daten verwendet werden
und bieten eine komfortable Mglichkeit, Konfigurationsdaten auszutauschen,
Updates vorzunehmen oder Image-Dateien einzuspielen.
Das serielle Konsolen-Interface (RS-232-Port) ermglicht den Anschluss
eines PC oder Terminals, um Administrations- oder Konfigurationsarbeiten
durchzufhren. Das Passwort fr den Zugriff auf die Konsole muss schriftlich
an einem sicheren Ort hinterlegt sein (siehe auch M 2.22 Hinterlegen des
Passwortes).
Zustzlich muss den Gefahren durch Diebstahl, Vandalismus und unbefugtem
Ausschalten des Gerts vorgebeugt werden.
- Sind die aktiven Netzkomponenten in verschlossenen Schrnken
untergebracht?
- Wurden die Standardschlsser ausgewechselt?
- Wurde die Konsole mit einem sicheren Passwort gesichert?
- Sind die Passwrter hinterlegt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.44 Geeignete Einrichtung eines huslichen

Arbeitsplatzes
Verantwortlich fr Initiierung: Leiter Haustechnik, Personalrat/Betriebsrat,
Vorgesetzte
Fr den huslichen Arbeitsplatz ist die Nutzung eines Arbeitszimmers
wnschenswert. Zumindest sollte der husliche Arbeitsplatz von der brigen
Wohnung durch eine Tr abgetrennt sein.
Die Einrichtung sollte unter Bercksichtigung von Ergonomie, Sicherheit und
Gesundheitsschutz ausgewhlt werden.
Dies bedeutet u. a.:
- ausreichend Platz fr Mbel und Bildschirmarbeitsplatz,
- regelbare Raumtemperatur und ausreichende Lftungsmglichkeiten,
- Abschirmung gegenber Lrmquellen,
- Tageslicht sowie ausreichend knstliche Beleuchtung,
- Sichtschutz des Monitors, falls er durch ein Fenster beobachtet werden
knnte,
- Vermeidung von strenden Blendungen, Reflexen oder Spiegelungen am
Arbeitsplatz und
- Anschlsse fr Telefon und Strom.
Dienstlich genutzte IT sollte vom Arbeitgeber bereitgestellt werden, um z. B.
per Dienstanweisung ausschlieen zu knnen, dass die IT fr private Zwecke
benutzt wird.
- Werden betroffene Mitarbeiter mit einem huslichen Arbeitsplatz regel-
mig oder sporadisch befragt, ob der Arbeitsplatz ihren gesundheitlichen
oder betrieblichen Ansprchen entsprechen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.45 Geeignete Aufbewahrung dienstlicher

Unterlagen und Datentrger
Verantwortlich fr Umsetzung: Mitarbeiter
Dienstliche Unterlagen und Datentrger drfen auch am huslichen Arbeits-
platz nur dem autorisierten Mitarbeiter zugnglich sein und mssen auerhalb
der Nutzungszeit in einem geeigneten Behltnis verschlossen aufbewahrt
werden.
Aus diesem Grund muss ein verschliebares Behltnis (Schreibtisch,
Rollcontainer, Schrank o. .) verfgbar sein. Der Verschluss muss mindestens
Angriffen mit einfach herzustellenden oder einfach zu erwerbenden
Nachschliemittel (Broklammer, Dietrich etc.) standhalten. Es sollten
Mbelschlsser mit mindestens 4 Zuhaltungen und mindestens 1000
Schlievarianten eingesetzt werden. Zudem ist darauf zu achten, dass der
Verschluss nicht durch einfaches Entfernen z. B. einer Rckwand leicht
umgangen werden kann. Insgesamt sollte die Schutzwirkung des Behltnisses
den Sicherheitsanforderungen der darin zu verwahrenden Unterlagen und
Datentrger entsprechen.
- Steht fr den huslichen Arbeitsplatz ein verschliebares Behltnis zur
Verfgung?
- Ist der Mitarbeiter darauf hingewiesen worden, dass die Unterlagen und
Datentrger verschlossen aufzubewahren sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.46 Einsatz von Diebstahl-Sicherungen

Verantwortlich fr Umsetzung: Leiter IT
Diebstahl-Sicherungen sind berall dort einzusetzen, wo groe Werte zu
schtzen sind bzw. dort, wo andere Manahmen - z. B. geeignete
Zutrittskontrolle zu den Arbeitspltzen - nicht umgesetzt werden knnen.
Diebstahl-Sicherungen machen z. B. dort Sinn, wo Publikumsverkehr herrscht
oder die Fluktuation von Benutzern sehr hoch ist.
Mit Diebstahl-Sicherungen sollten je nach zu schtzendem Objekt nicht nur
das IT-System selber, sondern auch Monitor, Tastatur und anderes Zubehr
ausgestattet werden.
Mittlerweile sind die unterschiedlichsten Diebstahl-Sicherungen auf dem
Markt erhltlich. Es gibt hier zum einem Hardware-Sicherungen, die dem
Diebstahl von IT-Gerten vorbeugen, z. B. durch das Verbinden des IT-
Systems mit dem Schreibtisch. Es gibt auch eine Reihe von Sicherungs-
mechanismen, die das ffnen des Gehuses verhindern sollen, um dem
Diebstahl von Teilen oder der Manipulation von sicherheitsrelevanten Ein-
stellungen wie dem Entfernen von Sicherheitskarten vorzubeugen.
Bei Neuanschaffung von IT-Gerten sollte darauf geachtet werden, dass diese
sen am Gehuse besitzen, um sie an anderen Gegenstnden befestigen zu
knnen, und dass die Gehuse abschliebar sind.
- Sind im letzten Jahr IT-Systeme oder IT-Komponenten gestohlen worden?
- Wie werden IT-Systeme oder IT-Komponenten vor Diebstahl geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.47 Eigener Brandabschnitt

Die Festlegung von Brandabschnitten ist fr den Brandschutz eines Rechen-
zentrums von grter Wichtigkeit. Die Wirkung zuverlssiger Brand- und
Rauchabschnitte hat sich bei vielen Grobrnden eindrucksvoll besttigt.
Die an Brandwnde bzw. an die Gre der Brandabschnitte von Rechen-
zentren gestellten Anforderungen sollten ber die in einschlgigen Normen,
wie z. B. den Landesbauordnungen bzw. der DIN 4102, gestellten Forderun-
gen hinaus gehen.
Schutzziel fr die Brandwand bzw. den Brandabschnitt sollte nicht nur der
Personen- und Gebudeschutz, sondern auch der Schutz des Inventars und
dessen Verfgbarkeit sein. Somit ist nicht nur die Brandausbreitung durch
Flammenwirkung und heie Rauchgase, sondern auch Wrmestrahlung und
Ausbreitung von kaltem Rauch zu verhindern.
Die nach DIN 4102 noch zulssige Wrmestrahlung kann fr die Gebudeein-
richtung, insbesondere im wrmeempfindlichen IT-Bereich, bereits vernich-
tende Wirkung haben. Aus diesen Grnden sollten mehrere Brand- und
Rauchabschnitte im Bauvorhaben realisiert werden, die so gro wie ntig und
so klein wie mglich sind.
Fr ein Rechenzentrum ist zu prfen, inwieweit weitere interne Brandab-
schnitte geschaffen werden sollten. Sollte ein eigener Brandabschnitt fr die
Kerneinheiten (IT-Rume, Datentrgerarchiv) erforderlich sein, so mssen
Wnde, Tren und auch notwendige Wand- und Deckendurchbrche den F90-
Anforderungen gengen.
Wenn der Brandabschnitt des Rechenzentrums z. B. Broeinheiten beherbergt,
so sind innerhalb des Brandabschnitts F30-Wnde und T30-Tren zwischen
diesen Bros und dem RZ-Kernbereich hinreichend. Die Bros sind dann in
die Brandmeldeanlage mit einzubeziehen.
Es ist in der Planung und auch im Betrieb sicherzustellen, dass in solchen
Rumen, die im Brandabschnitt des RZ liegen, keine besonderen Brandlasten
vorhanden sind.
- Sind die Rumlichkeiten in sinnvolle Brandabschnitte unterteilt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.48 Brandmeldeanlage
Neben der Aufstellung einer speziell auf den IT-Bereich zugeschnittenen
Brandschutzordnung sowie von Alarm- und Einsatzplnen, ist die Installation
einer Brandmeldeanlage von grter Wichtigkeit.
Da mehr als 90 % aller Brandschden in Rechenzentren durch Feuer im
Umfeld verursacht werden, empfiehlt es sich, diese Bereiche in die ber-
wachung durch die Brandmeldeanlage zu integrieren. Zum Einsatz sollten
Puls- bzw. Trendmelder (optisches Streulichtprinzip) kommen.
Die Identifikation des auslsenden Melders muss mglich sein. Zur Lokalisie-
rung des Brandherdes und der Brandausbreitung ist diese Identifikation der
Brandmelder ein besonders wichtiges Hilfsmittel.
Eine empfehlenswerte Mindestkonfiguration einer Brandmeldeanlage in der
Infrastruktur besteht aus
- Kanalmeldern in den Klimakanlen fr Zuluft und Abluft
- Meldern in der Frischluftansaugung, mit automatischer Sperrung der
Frischluft, wenn Strgren erkannt werden.
Alle Meldungen der Brandmeldeanlage und auch Strmeldungen sollten,
sofern mglich, auf einer stndig besetzte Stelle, z. B. der Pfrtnerloge, auf-
laufen.
Nach Mglichkeit sollte direkte Aufschaltung zur Berufsfeuerwehr erfolgen.
Beispiel:
Whrend einer Besprechung der Leitungsebene eines Rechenzentrums
bemerkte ein Teilnehmer, der sich kurz in einem Nebenzimmer aufhielt,
zufllig das Entstehen eines Grobrandes in einen nahegelegenen Chemie-
betrieb. Sein Hinweis auf den Brand ermglichte dem Leiter des Rechen-
zentrums, die Abschaltung der Frischluftzufuhr zu veranlassen. Nur wenige
Minuten spter wre der ruige Brandrauch von der Ansaugung, die ber
keine Detektion verfgte, in die Rechnerrume befrdert worden.
Die Funktionsfhigkeit aller Komponenten einer Brandmeldeanlage muss regelmige
berprfung
regelmig berprft werden. Auch wenn die Instandhaltung und Betrieb der
Brandmeldeanlage ber eine Wartungsfirma erfolgt, sollten zwei Mitarbeiter
mit elementaren Grundfunktionen (zumindest mit allen Betriebszustnden und
Statusmeldungen) der Anlage vertraut sein und als Ansprechpartner fr die
Wartungsfirma dienen.
Es sollten sporadisch einige der Melderlinien manuell auf ihre Funktions-
fhigkeit getestet werden.
- Wann wurde die Funktionsfhigkeit der Brandmeldeanlage zuletzt ber-
prft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

das Rechenzentrum
Ein Rechenzentrum sollte als geschlossener Sicherheitsbereich konzipiert sein.
Dieser sollte mglichst nur eine Zugangstr und keine Fenster haben, da alle
Zutrittsmglichkeiten berwacht werden mssen (siehe auch M 1.10
Verwendung von Sicherheitstren und -fenstern). Der Zutritt sollte durch
hochwertige Zutrittskontrollmechanismen geschtzt werden. Bei der Planung
eines Rechenzentrums bzw. der Auswahl geeigneter Rumlichkeiten sollten
potentielle Gefhrdungen durch Umgebungseinflsse mglichst minimiert
werden. So ist Gefahrenpotentialen wie Wassereinbrchen bei Flachdchern
oder in Kellerrumen genauso zu begegnen wie EMV-Strquellen, z. B.
Mobilfunk-Sendeeinrichtungen oder Drehstromaggregaten.
Ein angemessener baulicher und technischer Einbruchsschutz ist fr ein Einbruchsschutz
Rechenzentrum unabdingbar. Empfehlungen hierzu sind in Manahme M 1.19
Einbruchsschutz und in der BSI-Publikation "IT-Sicherheit durch
infrastrukturelle Manahmen" (siehe Anhang) aufgefhrt.
Fr die in Rechenzentren betriebenen IT-Komponenten wird in vielen Fllen Redundanz
ein hohes Ma an Verfgbarkeit gefordert. Diesen Anforderungen kann durch
redundante Auslegung der infrastrukturellen und technischen Einrichtungen
Rechnung getragen werden (siehe Manahme M 1.52 Redundanzen in der
technischen Infrastruktur).
Um eine Mischung zwischen der Grobtechnik (Energieversorgung, Klima- Trennung von Grob- und
Feintechnik
technik) und der Feintechnik (Rechner) im Rechenzentrum zu vermeiden,
sollten getrennte Raumeinheiten geplant werden. Die technische Infrastruktur
des Rechenzentrums ist in separaten Rumen zu installieren. In Rechenzentren
hoher Verfgbarkeit drfen bei der Schutzkonzeption die kommunikations-
bzw. nachrichtentechnischen Komponenten "nach drauen" nicht auer acht
gelassen werden. Ist ihr Schutz nicht im gleichen Ma, wie der der
technischen Kernkomponenten sichergestellt, ist die Verfgbarkeit nicht ge-
whrleistet. Beispielweise ist zu beachten, dass der Schutzbedarf der aktiven
Netzkomponenten, die an der Auenkommunikation beteiligt sind (wie Router
und Switches), dem Schutzbedarf der Kernbereiche des Rechenzentrums ent-
spricht. Dies betrifft sowohl den materiellen Schutz, als auch Detektion,
Meldung und Alarmierung.
Wnschenswert wre es, wenn die Gewerke fr
- Nachrichtentechnik,
- Klimatisierung und Lftung
- Energieversorgung,
- Lager usw.
jeweils in einem eigenen Raum (optional auch eigenen Brandabschnitt) unter-
gebracht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei der Planung sollte auch darauf geachtet werden, dass die Trassen der Ver- Versorgungsleitungen
sorgungsleitungen des Gebudes, z. B. fr Wasser oder Gas, (siehe M 1.24 vermeiden
Vermeidung von wasserfhrenden Leitungen) nicht in unmittelbarer Nhe oder
gar durch sensible Bereiche des Rechenzentrums verlaufen.
Ein Rechenzentrum ist ein sicherheitsrelevanter Bereich, daher sollten dort nur Zutritt nur fr Admini-
stratoren
die Administratoren der dort aufgestellten IT-Systeme Zutritt haben. Durch
eine darauf abgestimmte Zutrittsregelung muss fr eigene Mitarbeiter und
wichtiger noch fr nur zeitweilig Beschftigte, z. B. zu Wartungsarbeiten im
Rechenzentrum ttige, sichergestellt werden, dass sie keinen Zugriff auf
Systeme auerhalb ihres Ttigkeitsbereiches erhalten.
Es sollte verboten werden, in ein Rechenzentrum tragbare IT-Systeme,
Mobiltelefone oder Kameras mitzubringen, wenn diese nicht unter der
Kontrolle der jeweiligen Institution stehen. Generell sollte der Betrieb von
Mobiltelefonen in Rechenzentren untersagt werden, da diese den Betrieb der
IT-Systeme erheblich stren knnen. Ausnahmen hiervon mssen abgestimmt
sein (siehe M 2.188 Sicherheitsrichtlinien und Regelungen fr die Mobil-
telefon-Nutzung).
Bei der Planung von Umbau- oder Neubaumanahmen eines Rechenzentrums
sollten die im folgenden beschriebenen Parameter bercksichtigt werden.
In der Praxis hat sich fr einen Rechnersaal ein Seitenverhltnis von 1:1 bis
maximal 2:3 als gnstig erwiesen. Diese Aufteilung erleichtert die struktu-
rierte Anordnung von IT-Komponenten und deren Verkabelung im Rechen-
zentrum.
Sofern die baulichen Gegebenheiten es zulassen, ist die Installation eines
Doppelbodens empfehlenswert. Seine Hhe ist abhngig von der technischen
Ausstattung und Nutzung. Wenn der Doppelboden zur Klimatisierung genutzt
wird, sollte er ca. 50 cm Hhe haben.
Bei der Bemaung von IT-Rumen sind mindestens folgende Rahmenmae
empfehlenswert:
Lichte Raumhhe ab Doppelboden: 3,00 m
Sttzenabstnde 6,00 m
Rohbauma Trenbreite 1,10 m
Rohbauma Trenhhe 2,10 m
Decken und Doppelbden sollten auf eine Traglast von mindestens
1000 kg/m2 ausgelegt sein.
Der Doppelboden muss eine hohe Passgenauigkeit und ab einer Hhe von
20 cm eine Brandschutzqualitt von F30 in geschlossenem Zustand aufweisen.
Generell sollten die Sicherheitsrichtlinien fr Doppelbden vom Bundesver-
band Systembden e. V., Dsseldorf beachtet werden.
Hinweis: Die Doppelbden und abgehngten Decken mssen mit dem IT-
Raum abschlieen. Es drfen durch solche Konstruktionen keine unge-
sicherten Zugnge geschaffen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Flure sollten mindestens eine Breite von 1,80 m aufweisen und mit rutsch-
festen, glatten Bodenbelgen, die hheren Transportlasten widerstehen, aus-
gelegt sein.
Aufzge als vertikale Transportwege innerhalb des Rechenzentrums sollten
eine Tragkraft von mindestens 1500 kg haben. Die lichten Kabineninnenmae
sollten mindestens 2,80 m in der Tiefe, 1,50 m in der Breite und 2,20 m in der
Hhe betragen.
- Gibt es technische und organisatorische Vorgaben fr das Rechenzentrum?
- Ist das Rechenzentrum als geschlossener Sicherheitsbereich konzipiert
worden?
- Ist der Zutritt zum Serverraum geregelt?
- Wurde bei der Planung auf eine ausreichende Trennung der Grob- und
Feintechnik geachtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.50 Rauchschutz
Rauch stellt bei Brnden die grte Personengefhrdung dar. Mehr als 90 %
der Brandtoten sind durch Raucheinwirkungen (Vergiftungen) zu beklagen.
Aber auch die IT-Hardware kann durch Rauch erheblich in Mitleidenschaft
gezogen werden. Daher ist auf einen umfassenden Rauchschutz Wert zu legen.
Die folgenden Empfehlungen sollten zum Rauchschutz bercksichtigt werden:
- Brandschutztren sollten Rauchschutzqualitt aufweisen.
- Rauchschutztren in Fluren sollten durch Rauchschalter gesteuert werden. Rauchschutztren
Solche Tren knnen immer offen stehen, da sie bei Rauchdetektion
selbstttig schlieen.
- Die Lftungsanlage bzw. die Klimaanlage sollte eine Entrauchung von IT-
Rumen gestatten.
- In Klimakanlen (Zu- und Abluft) sollten Kanalmelder installiert sein. Kanalmelder
- In der Frischluftansaugung sollten Melder installiert sein, die automatisch

diese sperren, wenn Strgren (Rauch) erkannt werden.
Die Mitarbeiter mssen unterrichtet werden, welche Warnsignale die Rauch-
schutz-Komponenten haben und wie sie darauf zu reagieren haben.
Die Funktionsfhigkeit aller Rauchschutz-Komponenten muss regelmig
berprft werden.
- Wann wurde die Funktionsfhigkeit der Rauchschutz-Komponenten zuletzt
berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.51 Brandlastreduzierung
Verantwortlich fr Umsetzung: Planer, Leiter IT, Leiter Haustechnik
Hohe Brandlasten entstehen z. B. durch die Konzentration von IT-Systemen,
falsche Auswahl von Baumaterialien, leicht brennbare Broausstattung und
groe Papiermengen. In vielen Fllen knnen solche Brandlasten auf einfache
Weise vermieden werden.
Bei Rechenzentren - ebenso wie bei anderen Gebuden - sollte bereits in der
Planungsphase die Reduzierung unntiger Brandlasten bercksichtigt werden.
Nicht brennbare Materialien sind fr den Ausbau zu bevorzugen (Baustoff-
klasse A).
Um den sicheren Betrieb unter Gesichtspunkten des Brandschutzes zu ge-
whrleisten und Grenzwerte nicht zu berschreiten, sollte schon in der
Planungsphase eine berschlgige Berechnung der spteren Brandlasten er-
folgen. Dabei sind die Brandklassen der Einrichtungen bzw. der Baustoff-
klassen der Materialien zu bercksichtigen. Dadurch werden spter
Schwierigkeiten bei der brandschutztechnischen Abnahme durch Bauauf-
sichtsbehrden und Feuerwehr vermieden.
Andererseits ist im laufenden Rechenzentrums-Betrieb dafr Sorge zu tragen,
dass beispielsweise Brandlasten im Doppelboden in Form von nicht mehr
bentigten Kabeln entfernt werden.
Aus Brorumen sollten nicht mehr bentigte Akten entfernt und in speziell
dafr vorgesehenen Archiven gelagert werden.
Eine der hufigsten Beispiele fr unntige Brandlasten in Rumen, die fr die
IT genutzt werden, ist Verpackungsmaterial, beispielsweise Pappe oder
Styropor. Aus den IT-Rumen ist Verpackungsmaterial umgehend zu
entfernen und in dafr vorgesehene Lagerrume zu transportieren, wenn es
noch bentigt wird.
- Wird regelmig berprft, ob sich Brandlasten in den genutzten Rum-
lichkeiten anhufen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.52 Redundanzen in der technischen Infrastruktur

Bestehen besondere Anforderungen an die Verfgbarkeit eines Rechen-
zentrums bzw. eines Serverraums, so sind Redundanzen auch im Bereich der
technischen Infrastruktur zu schaffen.
Es bietet sich beispielsweise an, beim Einsatz von Klimaanlagen ausreichend N+1 Prinzip
Redundanz vorzuhalten. Werden beispielweise von einer Komponente 6 Stck
bentigt, so sollten 7 beschafft werden. Damit knnen Lastspitzen, z. B. in
heien Sommern abgefangen werden und auch bei Ausfall eines Gertes oder
bei Wartungsarbeiten bleibt die Verfgbarkeit der Klimatisierung insgesamt
erhalten.
Auch fr Kommunikationsverbindungen sollte geprft werden, in welchen
Bereichen Redundanzen vorgehalten werden mssen (siehe auch M 6.18
Redundante Leitungsfhrung). Dies gilt um so mehr, wenn sich zentrale
Netzknoten oder zentrale aktive Komponenten in unkontrollierten Bereichen
befinden.
In einem Rechenzentrum ist auch die Stromversorgung redundant auszulegen.
Empfehlungen hierzu finden sich in Manahme M 1.56 Sekundr-
Energieversorgung.
Falls sich die sekundre Stromversorgung nicht in einem angrenzenden
Brandabschnitt befindet, sollte ber eine redundante Verkabelung der Strom-
versorgung nachgedacht werden.
- Ergibt sich aus der Schutzbedarfsfeststellung die Notwendigkeit von
Redundanzen in der technischen Infrastruktur?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.53 Videoberwachung
Verantwortlich fr Umsetzung: Planer,
Die Manahmen zur Auenhautsicherung (siehe M 1.55 Perimeterschutz) und
Zutrittskontrolle knnen durch den Einsatz von Videotechnik ergnzt werden.
Videoberwachungsanlagen, ob eigenstndig oder ergnzend zu anderen
Sicherheitstechniken, werden zur Erreichung folgender Schutzziele eingesetzt:
- Abschreckung
- Fassadenberwachung
- Identifizierung
- berwachung
- Alarmierung
- Erkennung und Lokalisierung von Gefahren
- Schadenverhtung
- Dokumentation und Auswertung von Regelabweichungen
Bei der Planung einer Videoberwachung ist auf eine konsistente Einbettung
in das gesamte Schutzkonzept zu achten. Dies gilt umso mehr, wenn die
berwachungsterminals weit vom zu schtzenden Bereich entfernt sind. Eine
Videoberwachung ohne Auswertungs- und Alarmierungsmechanismen
macht auer zur Abschreckung keinen Sinn. Die bentigten zentralen
Technikkomponenten sind in geeigneter Umgebung aufzustellen und zu
schtzen.
Bei der Planung bzw. Installation einer Videoberwachung sollte der Daten-
schutzbeauftragte und der Personal- bzw. Betriebsrat hinzugezogen werden.
- Ist die Videoberwachung konsistent in das Schutzkonzept eingebettet?
- Wird die Funktionsfhigkeit der Videoberwachungsanlage regelmig
berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.54 Brandfrhesterkennung / Lschtechnik

Bei entstehenden Brnden in IT-Anlagen kann das Wegschalten der elek-
trischen Energie bereits ausreichend sein, um den Brand zu verzgern oder zu
beenden.
Fr die berwachung von IT-Systemen kann eine objektbezogene ber-
wachung durch sogenannte Multidetektoren vorgenommen werden. In Ergn-
zung der konventionellen Brandmeldetechnik (geometrische Raumber-
wachung) stellt die Objektberwachung (also die berwachung innerhalb
einzelner IT-Komponenten) eine zustzliche Melderebene dar. Diese Multi-
detektoren knnen sowohl fr eine objektbezogene Lschung als auch fr die
Abschaltung der Sttzenergie des betroffenen Gertes herangezogen werden.
Wenn eine zustzliche Lschung als notwendig anzusehen ist, bietet es sich
aus Kosten- und Personenschutz-Grnden an, nur einzelne Objekte (z. B.
19 Zoll Schrnke) mit Lschgasen individuell abzusichern. Die Objektschutz-
anlagen sollten sich an der VdS-Richtlinie 2304 bezglich Planung, Brand-
meldung, Lschung orientieren sowie an den Einbauhinweisen der Hersteller
und deren Vorgaben fr den Betrieb und die Instandhaltung.
Fr die Raumberwachung im IT-Bereich eignet sich die Installation von
optischen Rauchmeldern. Auch der Doppelboden sollte durch ebensolche
Rauchmelder berwacht werden
Bestehen besondere Anforderungen an die Verfgbarkeit eines Rechenzen-
trums bzw. Serverraums oder beinhalten diese besonders hochwertige oder
schwer nachzubeschaffende IT-Komponenten, ist der Einsatz einer automa-
tischen Lschanlage mit Inertgasen (Kohlendioxid, Inergen, Argon, Stickstoff,
FM 200, etc.) zu erwgen.
Der Erstickungseffekt fr Flammen gilt ebenso fr Menschen, wenn sauer- Erstickungsgefahr bei
Lschgasen
stoff-verdrngende Lschgase eingesetzt werden. So besteht bei einer
Kohlendioxid-Konzentration von mehr als 8 Volumenprozent akute Lebens-
gefahr. Daher fordern in der Bundesrepublik Deutschland die berufsgenossen-
schaftlichen Richtlinien (ZH 1/206 Sicherheitsregeln fr Kohlendioxid-Feuer-
lschanlagen vom April 1988) den Einsatz von Verzgerungseinrichtungen,
"wenn die Einsatzmenge bezogen auf das Gesamtvolumen des Raumes, in
dem das geschtzte Objekt untergebracht ist, eine hhere Lschkonzentration
als 5 Volumenprozent herbeifhrt".
Die Planung einer Lschgasanlage sollte grundstzlich nur durch einen Fach-
planer erfolgen.
- Wie wird sichergestellt, dass Brnde so frh wie mglich erkannt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.55 Perimeterschutz
Falls das Gebude oder Rechenzentrum innerhalb eines Grundstcks liegt, auf
dem zustzliche Sicherheitseinrichtungen installiert werden knnen, sollten
Manahmen ergriffen werden, um von auen wirkende Gefhrdungen vom
Rechenzentrum abzuhalten.
Insbesondere kann hier die erste Stufe einer Zutritts- und vor allem Zufahrts-
regelung geschaffen werden.
Je nach Schutzbedarf und topologischen Gegebenheiten kann ein Perimeter-
schutz aus folgenden Komponenten bestehen:
- uere Umschlieung oder Umfriedung, z. B. Zaunanlage, Mauerwerk uere Umfriedung
und Zaunberwachung
Dies bietet
- Schutz gegen unbeabsichtigtes berschreiten einer Grundstcks-
grenze,
- Schutz gegen beabsichtigtes gewaltloses berwinden der Grund-
stcksgrenze sowie
- Schutz gegen beabsichtigtes gewaltsames berwinden der Grund-
stcksgrenze.
- Freiland-Sicherungsmanahmen, z. B. Gelndegestaltung, Zufahrtssperren, Freiland-Sicherungs-
manahmen
Beleuchtung des Gelndes und des Gebudes, Bewachungsunternehmen,
Videoberwachung und Detektionssensorik auf dem Gelnde
Dies bietet Schutz gegen unbemerkten Zutritt eines Eindringlings fr die
Flche zwischen Umfriedung und Gebude.
- uere Personen- und Fahrzeugidentifikation, z. B. Videogegensprech- Personen- und Fahr-
zeugkontrollen
anlage, Personen- bzw. Fahrzeugschleuse, Tr- bzw. Torffnung und
Zutrittskontrolleinheiten
Dies bietet Schutz gegen erkennbar (visuell, akustisch oder sensorisch)
unberechtigte Zutrittsversuche als erste Stufe des Zutrittskontrollkonzeptes.
Diese Aufgabe kann durch einen Pfrtnerdienst untersttzt werden (siehe
auch M 1.17 Pfrtnerdienst).
Bevor Manahmen aus dem Bereich Perimeterschutz realisiert werden, muss
in jedem Fall ein stimmiges Schutzkonzept erarbeitet werden, das die oben
genannten Aspekte und den Gebudeschutz umfasst. Anderenfalls besteht die
Gefahr, dass vergleichsweise teure Sicherheitsmanahmen umgesetzt werden,
beispielsweise aufwndige Zaunanlagen und ausgefeilte Gelnde-Videober-
wachung, die in keinem Verhltnis zur Gebudesicherung stehen und daher
nicht angemessen sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Schutzkonzept sollte darauf ausgerichtet sein, mit den zur Verfgung
stehenden Ressourcen mglichst wirksame Schutzmanahmen aufzubauen.
Dies betrifft besonders den Bereich Perimeterschutz. Die hier ergriffenen
Manahmen sollten die Gesamtsicherheit erhhen und nicht nur das Image
einer "Hochsicherheitskulisse" vermitteln, da sich qualifizierte Angreifer
allein durch den Anblick von hohen Zunen und Videoberwachung kaum
von ihrem Vorsatz abbringen lassen.
Beispiel:
Wenn ein Angreifer zwei Minuten bentigt, um den Weg ber den Zaun bis
zum Gebude zu nehmen und anschlieend nur eine halbe Minute fr das
Eindringen ins Gebude, stimmt die Relation nicht. Dies gilt um so mehr,
wenn das Eintreffen von Einsatzkrften der rtlichen Polizei nach Alarmie-
rung durch ein privates Bewachungsunternehmen beispielsweise acht Minuten
dauert. In dieser Zeit knnte ein Einbrecher schon wieder nach vollbrachter
Tat das Gelnde verlassen haben. Er wre zwar bemerkt und auf Videomate-
rial aufgenommen worden, bei geeigneter Maskierung jedoch kaum zu identi-
fizieren.
- Gibt es ein Schutzkonzept, das sowohl den Perimeterschutz als auch den
Gebudeschutz umfasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.56 Sekundr-Energieversorgung
Verantwortlich fr Initiierung: Leiter Haustechnik, Leiter IT, IT-
Die primre Energieversorgung aus dem Netz eines Energieversorgungs-
Unternehmens (EVU) muss bei erhhten Anforderungen an die Verfgbarkeit
um Manahmen zur Notfall-Versorgung des Rechenzentrums selbst ergnzt
werden. Dabei sollte auch nicht weitere wichtige Infrastruktur des Gebudes,
wie z. B. die Notbeleuchtung und die Feuerwehr-Aufzge, vergessen werden.
Die Sekundr-Energieversorgung eines Rechenzentrums besteht dann
blicherweise aus einer zentralen USV fr das Rechenzentrum und einer
Netzersatzanlage (NEA). Falls die rtlichen Gegebenheiten und das Anforde-
rungsprofil an die Verfgbarkeit des Rechenzentrums es zulassen, kann statt
einer NEA auch eine zweite Einspeisung aus dem Netz eines zweiten Ener-
gieversorgungs-Unternehmens diese Auffang-Funktion erfllen.
Whrend eine Online-USV (siehe M 1.28 Lokale unterbrechungsfreie
Stromversorgung) Schwankungen oder kurzfristige Unterbrechungen der
Stromversorgung berbrckt, fngt eine Netzersatzanlage auerdem
lngerfristige Stromausflle auf.
Der gesamten IT-Umgebung wird eine zentrale Online-USV vorgeschaltet.
Die Regel-Elektronik dieser USV muss fr das frequenz- und phasenrichtige
Einkoppeln bei Anlauf der Netzersatzanlage und nach Wiederanlauf der
Stromversorgung des EVU sorgen.
Bei der Dimensionierung der Notstromaggregate sollte darauf geachtet
werden, dass die Nennleistung des Netzersatzes ber der Volllast-Betriebs-
leistung des Rechenzentrums liegen sollte. Damit kann sichergestellt werden,
dass die Netzersatzanlage, z. B. bei gleichzeitigem Anlauf mehrerer Verbrau-
cher, die bentigte Leistung zur Verfgung stellen kann.
Bei der bergabe der Versorgung von der USV an die NEA ist sicherzu-
stellen, dass eine schrittweise Weiterschaltung ohne berlastung der NEA und
daraus resultierendem Wiederanlauf der USV erfolgt. Dabei mssen die indi-
viduellen Anforderungen der IT-Infrastruktur und der sonstigen von der NEA
versorgten Gebudeteile mit Hilfe eines abgestimmten Lastmanagements
Fr die Dimensionierung der Batterien der zentralen USV ist die ber-
brckungszeit bei Netzausfall entscheidend. Diese setzt sich aus folgenden
Faktoren zusammen:
- Wartezeit auf Netzrckkehr. Erst nach dieser Wartezeit von 1 bis 5 Minu-
ten luft die NEA an.
- Umschaltzeit bis zur Lastbernahme durch die NEA. In dieser Zeit
versorgt die USV alle Verbraucher der IT-Anlage mit Strom.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zeit mit verminderter Leistungsabnahme. Bei Absinken der Batterielade-

kapazitt sollte eine verminderte Leistungsabnahme eingeleitet werden.
Hierzu mssen unkritischere Verbraucher vom Netz genommen werden.
- Zeit mit Leistungsabnehmer fr notwendige kritische Verbraucher. Bei
weiterem Absinken der Batteriekapazitt drfen nur noch die wichtigsten
Leistungsverbraucher mit Strom versorgt werden. Sptestens hier muss
automatisch ein Not-Shutdown mit kontrollierter Zwangsabschaltung des
IT-Betriebes erfolgen, auch wenn reversible Datenverluste dabei in Kauf
genommen werden mssen.
Um die Schutzwirkung der Sekundr-Energieversorgung aufrechtzuerhalten,
ist eine regelmige Wartung vorzusehen.
- Werden die Wartungsintervalle von USV und NEA eingehalten?
- Werden die USV und die NEA in regelmigen Testlufen unter realisti-
scher Belastung auf Funktionsfhigkeit geprft?
- Wird der Tankinhalt bei dieselbetriebenen NE-Anlagen regelmig
kontrolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.57 Aktuelle Infrastruktur- und Bauplne

Bauplne, Fluchtwegplne, Feuerwehrlaufkarten etc. (siehe auch M 1.11
Lageplne der Versorgungsleitungen und M 5.4 Dokumentation und
Kennzeichnung der Verkabelung) sollten umgehend nach jeder
Umbaumanahme, Erweiterung der Infrastruktur und Sicherheitstechnik auf
den aktuellen Stand gebracht werden.
Dies ist erforderlich, um
- das definierte Sicherheitsniveau halten,
- Notfallsituationen optimal begegnen,
- Revisionen erleichtern und
- Manahmen vollstndig und angemessen planen und durchfhren zu
knnen.
Es ist nicht ausreichend, die Plne beispielsweise nur bei der zustndigen
Bauverwaltung zu lagern. Im Schadens- oder Notfall, z. B. bei Kabelschden
oder Wasserrohrbrchen kann wichtige Zeit fr die Fehlerlokalisierung und -
beseitigung verloren gehen. Derjenige, der die Plne verwaltet, z. B. im
Hausdienst, sollte auch in der Lage sein, sie zu lesen. Gegebenenfalls ist
Personal entsprechend zu schulen und einzuweisen.
- Wurde der Architekt oder der Standortplaner bei Umbaumanahmen auch
mit der Aktualisierung der Plne beauftragt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Serverrume
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement
Ein Serverraum sollte als geschlossener Sicherheitsbereich konzipiert sein.
Dieser sollte mglichst gut zu sichernde Zugangstren und Fenster haben, da
alle Zutrittsmglichkeiten berwacht werden mssen (siehe auch M 1.10
Verwendung von Sicherheitstren und -fenstern). Der Zutritt sollte durch
hochwertige Zutrittskontrollmechanismen geschtzt werden. Bei der Planung
eines Serverraumes bzw. der Auswahl geeigneter Rumlichkeiten sollten
potentielle Gefhrdungen durch Umgebungseinflsse mglichst minimiert
werden. So ist Gefahrenpotentialen wie Wassereinbrchen bei Flachdchern
oder in Kellerrumen genauso zu begegnen wie EMV-Strquellen, z. B.
Mobilfunk-Sendeeinrichtungen oder Drehstromaggregaten.
Bei der Planung sollte auch darauf geachtet werden, dass die Trassen der Versorgungsleitungen
vermeiden
Versorgungsleitungen des Gebudes, z. B. fr Wasser oder Gas (siehe M 1.24
Vermeidung von wasserfhrenden Leitungen), nicht in unmittelbarer Nhe
oder gar durch sensible Bereiche des Serverraums verlaufen.
Fr die in Serverrumen betriebenen IT-Komponenten wird in vielen Fllen
ein hohes Ma an Verfgbarkeit gefordert. Diesen Anforderungen kann durch
redundante Auslegung der infrastrukturellen und technischen Einrichtungen
Rechnung getragen werden (siehe Manahme M 1.52 Redundanzen in der
technischen Infrastruktur).
Ein Serverraum ist ein sicherheitsrelevanter Bereich, daher sollten dort nur die Zutritt nur fr
Administratoren
Administratoren der dort aufgestellten IT-Systeme Zutritt haben. Durch eine
darauf abgestimmte Zutrittsregelung muss fr eigene Mitarbeiter und
wichtiger noch fr nur zeitweilig Beschftigte, z. B. zu Wartungsarbeiten
ttige, sichergestellt werden, dass sie keinen Zugriff auf Systeme auerhalb
ihres Ttigkeitsbereiches erhalten.
IT-Systeme, die von Externen betreut werden, sollten in separaten Rumen
aufgestellt werden. Es ist auerdem zu berlegen, IT-Systeme mit unter-
schiedlichem Schutzbedarf oder aus verschiedenen Bereichen in getrennten
Serverrumen aufzustellen, um den Kreis der Zutrittsberechtigten klein zu
halten.
In einem Serverraum sollten sich auf keinen Fall Gerte oder Ausrstung
befinden, die den Zutritt fr einen groen Benutzerkreis erforderlich machen,
also z. B. Fax-Gerte oder Fotokopierer. Brennbare Materialen wie Drucker-
papier sollten ebenfalls nicht in einem Serverraum gelagert werden.
Es sollte verboten werden, in einen Serverraum tragbare IT-Systeme, Mobil-
telefone oder Kameras mitzubringen, wenn diese nicht unter der Kontrolle der
jeweiligen Institution stehen. Generell sollte der Betrieb von Mobiltelefonen
in Rechenzentren untersagt werden, da diese den Betrieb der IT-Systeme
erheblich stren knnen. Ausnahmen hiervon mssen abgestimmt sein (siehe
M 2.188 Sicherheitsrichtlinien und Regelungen fr die Mobiltelefon-Nutzung).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gibt es technische und organisatorische Vorgaben fr Serverrume?
- Sind die Serverrume als geschlossene Sicherheitsbereiche konzipiert
worden?
- Ist der Zutritt zum Serverraum geregelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.59 Geeignete Aufstellung von Archivsystemen

Verantwortlich fr Umsetzung: Leiter IT, Administrator
Da in Archivsystemen wichtige Behrden- bzw. Unternehmensdaten konzen- Aufstellungsort
absichern
triert aufbewahrt werden, mssen deren IT-Komponenten so aufgestellt wer-
den, dass nur Berechtigte Zutritt haben. Dies betrifft neben den eingesetzten
Servern und Netzkomponenten insbesondere die Speichereinheiten (Platten-
arrays, Bandlaufwerke, Disc-Jukeboxen). Fr die geeignete Aufstellung dieser
IT-Komponenten sind alle relevanten Manahmen, die in Kapitel 4 des IT-
Grundschutzhandbuchs zur Infrastruktur-Sicherheit beschrieben sind, zu reali-
sieren. Je nach Art und Gre des Archivsystems sind die Bausteine 4.1 Ge-
bude, 4.6 Rechenzentrum, 4.3.2 Serverraum bzw. 4.4 Schutzschrnke heran-
zuziehen. Hierbei sollte besonders auf eine ausreichende Zuverlssigkeit der
infrastrukturellen Komponenten (Stromzufuhr, etc.) geachtet werden.
Fr die langfristige Aufbewahrung der verwendeten Archiv-Speichermedien
sind die in M 1.60 Geeignete Lagerung von Archivmedien genannten Lager-
bedingungen einzuhalten. Vor allem die zweckmige Klimatisierung von
Speichermedien, aber auch der Archivsysteme selbst ist hier zu beachten.
Hufig werden elektronische Archive so realisiert, dass Archivmedien im Lagerbedingungen in
Speicherkomponenten
dauerhaften Zugriff durch die Speichereinheit gehalten werden. Hierzu kom-
men vielfach dedizierte Speichereinheiten zum Einsatz, die selbstttig Wech-
selmedien verwalten und einlegen knnen, beispielsweise Roboter fr Band-
laufwerke oder Jukeboxen fr Disc-Medien. Wenn ein Archivsystem solche
Komponenten beinhaltet, werden in der Regel die Archivmedien whrend
ihrer gesamten Lebensdauer nicht mehr aus der Speichereinheit ausgelagert.
Das bedeutet, dass die an Archivmedien zu stellenden Lagerbedingungen (be-
zglich Klimatisierung, Zugriffsschutz, etc.) bereits in der Speicherkompo-
nente erfllt und berwacht werden mssen.
Bei Auswahl des Archivsystems ist daher als Kriterium zu bercksichtigen,
dass die erforderlichen Lagerbedingungen fr Archivmedien in Speicherkom-
ponenten eingehalten werden knnen bzw. welcher Zusatzaufwand hierfr
entsteht.
- Sind die IT-Grundschutzmanahmen fr den Aufstellungsort des elektroni-
schen Archivs realisiert?
- Sind die Lagerbedingungen fr Archivmedien bekannt und dokumentiert?
- Werden die Lagerbedingungen fr Archivmedien in den verwendeten
Dauer-Speichereinheiten eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 1.60 Geeignete Lagerung von Archivmedien

Fr den Langzeiteinsatz von Archivmedien sind besonders der Zugriffsschutz
sowie klimatische Lagerbedingungen zu beachten und deren Einhaltung zu
berwachen.
Sofern Archivmedien im Online-Zugriff, also im Archivsystem bzw. in Spei- Online-Zugriff
cherlaufwerken gehalten werden, ist keine rumliche Trennung zwischen
Archivsystem und Archivmedium realisierbar. Fr die geeignete Lagerung
von Archivmedien sind damit die in M 1.59 Geeignete Aufstellung von
Archivsystemen genannten Empfehlungen umzusetzen.
Wenn Archivmedien auerhalb des Archivsystems "offline" gelagert werden, Offline-Lagerung
so sind die im Baustein 4.3.3 Datentrgerarchiv beschriebenen Manahmen
unter besonderer Bercksichtigung der Anforderungen an die Klimatisierung
anzuwenden.
Klimatisierung
Die klimatischen Anforderungen an die Haltbarkeit von Archivmedien hngen
von den eingesetzten Archivmedien ab. Hersteller geben hierzu vereinzelt
unverbindliche Hinweise zu den Lagerbedingungen (z. B. hinsichtlich der
Temperatur und Luftfeuchte) und zur Haltbarkeit der Medien an.
Fr den langfristigen Einsatz elektronischer Archivsysteme mssen die kon-
kreten Lagerbedingungen jedoch von den Herstellern der eingesetzten Ar-
chivmedien verbindlich erfragt werden. Da hiervon die Haltbarkeit der Ar-
chivmedien abhngt, sollten folgende Punkte vor der Auswahl der verwende-
ten Archivmedien geklrt werden (siehe auch M 4.169 Verwendung geeig-
neter Archivmedien):
- Die klimatischen und physikalischen Lagerbedingungen fr die betrachte- Herstellerangaben ein-
fordern
ten Archivmedien sollten seitens des Herstellers ausreichend detailliert be-
schrieben sein (inklusive der Auswirkungen auf die maximale Lebens-
dauer). Diese Angabe sollte verbindlich sein, mglichst mit einer Garantie-
erklrung des Herstellers bei Einhaltung der Lagerbedingungen.
- Die technische Realisierung einer geeigneten Lagerung kann unter Um- technische Realisierbar-
keit prfen
stnden sehr komplex sein. Je nach den vorhandenen technischen und
infrastrukturellen Vorgaben knnen bestimmte Archivmedien auch gnz-
lich ungeeignet sein. Daher mssen im Vorfeld die Mglichkeit und der
Aufwand fr die technische Realisierung einer geeigneten Lagerung ge-
prft werden.
Die Lagerbedingungen sollten im Betriebshandbuch des Archivsystems do-
kumentiert werden. Zustzlich muss sichergestellt werden, dass die Lagerbe-
dingungen kontinuierlich eingehalten und berwacht werden (siehe auch
M 1.27 Klimatisierung).
Physikalische Schutzmanahmen
ber die klimatischen Bedingungen hinaus mssen die verwendeten Archiv-
medien vor unautorisiertem Zugriff und mechanischer Beschdigung oder
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vernderung geschtzt werden. Hierzu wird insbesondere auf die im Bau-

stein 4.3.3 Datentrgerarchiv genannten Manahmen verwiesen.
Neben einer Kontrolle des Zutritts zum Datentrgerraum, Brandschutz und Zutrittskontrolle
Schutz vor Wassereinwirkung sind je nach Art der verwendeten Archivmedien
weitere Manahmen zu realisieren, z. B. zum Schutz vor Einwirkung von
Magnetfeldern auf Magnetbnder.
Hierfr sind verbindliche Empfehlungen von Herstellern zu mechanischen
Lagerbedingungen einzuholen und zu beachten.
Bei Nichteinhaltung der Lagerbedingungen muss eine Alarmierung und Re- Alarmierung und Reak-
tion
aktion erfolgen. Hierzu sind organisationsspezifisch Eskalationsprozeduren
und -wege zu definieren.
- Bestehen verbindliche Herstelleraussagen zu klimatischen und physikali-
schen Lagerbedingungen?
- Knnen die vom Hersteller empfohlenen klimatischen und physikalischen
Lagerbedingungen eingehalten werden?
- Sind die Lagerbedingungen im Betriebshandbuch des Archivsystems doku-
mentiert?
- Bestehen Eskalationsprozeduren bei Nichteinhaltung der Lager-
bedingungen?
___________________________________________________________________ ..........................................
Manahmenkatalog Organisation M2 Bemerkungen
___________________________________________________________________ ..........................................
M2 Manahmenkatalog Organisation
M 2.1 Festlegung von Verantwortlichkeiten und Regelungen
fr den IT-Einsatz ...................................................................... 1
M 2.2 Betriebsmittelverwaltung........................................................... 3
M 2.3 Datentrgerverwaltung............................................................... 5
M 2.4 Regelungen fr Wartungs- und Reparaturarbeiten .................... 7
M 2.5 Aufgabenverteilung und Funktionstrennung ............................. 9
M 2.6 Vergabe von Zutrittsberechtigungen........................................ 10
M 2.7 Vergabe von Zugangsberechtigungen...................................... 11
M 2.8 Vergabe von Zugriffsrechten ................................................... 12
M 2.9 Nutzungsverbot nicht freigegebener Hard- und
Software................................................................................... 17
M 2.10 berprfung des Hard- und Software-Bestandes .................... 18
M 2.11 Regelung des Passwortgebrauchs ............................................ 19
M 2.12 Betreuung und Beratung von IT-Benutzern............................. 21
M 2.13 Ordnungsgeme Entsorgung von schtzenswerten
Betriebsmitteln......................................................................... 22
M 2.14 Schlsselverwaltung ................................................................ 23
M 2.15 Brandschutzbegehungen .......................................................... 24
M 2.16 Beaufsichtigung oder Begleitung von Fremdpersonen............ 25
M 2.17 Zutrittsregelung und -kontrolle................................................ 26
M 2.18 Kontrollgnge .......................................................................... 27
M 2.19 Neutrale Dokumentation in den Verteilern.............................. 28
M 2.20 Kontrolle bestehender Verbindungen ...................................... 29
M 2.21 Rauchverbot ............................................................................. 30
M 2.22 Hinterlegen des Passwortes ..................................................... 31
M 2.23 Herausgabe einer PC-Richtlinie............................................... 32
M 2.24 Einfhrung eines PC-Checkheftes ........................................... 34
M 2.25 Dokumentation der Systemkonfiguration ................................ 35
M 2.26 Ernennung eines Administrators und eines Vertreters............. 36
M 2.27 Verzicht auf Fernwartung der TK-Anlage............................... 37
M 2.28 Bereitstellung externer TK-Beratungskapazitt....................... 38
M 2.29 Bedienungsanleitung der TK-Anlage fr die Benutzer............ 39
M 2.30 Regelung fr die Einrichtung von Benutzern /
Benutzergruppen...................................................................... 40
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.31 Dokumentation der zugelassenen Benutzer und

Rechteprofile............................................................................ 42
M 2.32 Einrichtung einer eingeschrnkten Benutzerumgebung .......... 43
M 2.33 Aufteilung der Administrationsttigkeiten unter Unix ............ 44
M 2.34 Dokumentation der Vernderungen an einem
bestehenden System................................................................. 45
M 2.35 Informationsbeschaffung ber Sicherheitslcken des
Systems .................................................................................... 46
M 2.36 Geregelte bergabe und Rcknahme eines tragbaren
PC ............................................................................................ 48
M 2.37 "Der aufgerumte Arbeitsplatz"............................................... 49
M 2.38 Aufteilung der Administrationsttigkeiten .............................. 50
M 2.39 Reaktion auf Verletzungen der Sicherheitspolitik ................... 51
M 2.40 Rechtzeitige Beteiligung des Personal-/Betriebsrates.............. 52
M 2.41 Verpflichtung der Mitarbeiter zur Datensicherung.................. 53
M 2.42 Festlegung der mglichen Kommunikationspartner ................ 54
M 2.43 Ausreichende Kennzeichnung der Datentrger beim
Versand .................................................................................... 55
M 2.44 Sichere Verpackung der Datentrger ....................................... 56
M 2.45 Regelung des Datentrgeraustausches ..................................... 57
M 2.46 Geeignetes Schlsselmanagement ........................................... 59
M 2.47 Ernennung eines Fax-Verantwortlichen .................................. 63
M 2.48 Festlegung berechtigter Faxbediener ....................................... 64
M 2.49 Beschaffung geeigneter Faxgerte........................................... 65
M 2.50 Geeignete Entsorgung von Fax-Verbrauchsgtern und -
Ersatzteilen .............................................................................. 66
M 2.51 Fertigung von Kopien eingehender Faxsendungen.................. 67
M 2.52 Versorgung und Kontrolle der Verbrauchsgter...................... 68
M 2.53 Abschalten des Faxgertes auerhalb der Brozeiten.............. 69
M 2.54 Beschaffung geeigneter Anrufbeantworter .............................. 70
M 2.55 Einsatz eines Sicherungscodes................................................. 72
M 2.56 Vermeidung schutzbedrftiger Informationen auf dem
Anrufbeantworter..................................................................... 73
M 2.57 Regelmiges Abhren und Lschen aufgezeichneter
Gesprche ................................................................................ 74
M 2.58 Begrenzung der Sprechdauer ................................................... 75
M 2.59 Auswahl eines geeigneten Modems in der Beschaffung ......... 76
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.60 Sichere Administration eines Modems .................................... 79

M 2.61 Regelung des Modem-Einsatzes.............................................. 80
M 2.62 Software-Abnahme- und Freigabe-Verfahren ......................... 82
M 2.63 Einrichten der Zugriffsrechte................................................... 85
M 2.64 Kontrolle der Protokolldateien................................................. 86
M 2.65 Kontrolle der Wirksamkeit der Benutzer-Trennung am
IT-System ................................................................................ 88
M 2.66 Beachtung des Beitrags der Zertifizierung fr die
Beschaffung ............................................................................. 89
M 2.67 Festlegung einer Sicherheitsstrategie fr Peer-to-Peer-
Dienste ..................................................................................... 91
M 2.68 Sicherheitskontrollen durch die Benutzer beim Einsatz
von Peer-to-Peer-Diensten....................................................... 97
M 2.69 Einrichtung von Standardarbeitspltzen ................................ 100
M 2.70 Entwicklung eines Konzepts fr Sicherheitsgateways........... 101
M 2.71 Festlegung einer Policy fr ein Sicherheitsgateway .............. 105
M 2.72 Anforderungen an eine Firewall ............................................ 108
M 2.73 Auswahl geeigneter Grundstrukturen fr
Sicherheitsgateways............................................................... 109
M 2.74 Geeignete Auswahl eines Paketfilters.................................... 113
M 2.75 Geeignete Auswahl eines Application-Level-Gateways........ 115
M 2.76 Auswahl und Einrichtung geeigneter Filterregeln ................. 116
M 2.77 Integration von Servern in das Sicherheitsgateway ............... 118
M 2.78 Sicherer Betrieb eines Sicherheitsgateways........................... 123
M 2.79 Festlegung der Verantwortlichkeiten im Bereich
Standardsoftware ................................................................... 125
M 2.80 Erstellung eines Anforderungskatalogs fr
M 2.81 Vorauswahl eines geeigneten
Standardsoftwareproduktes.................................................... 140
M 2.82 Entwicklung eines Testplans fr Standardsoftware............... 144
M 2.83 Testen von Standardsoftware................................................. 152
M 2.84 Entscheidung und Entwicklung der
Installationsanweisung fr Standardsoftware ........................ 164
M 2.85 Freigabe von Standardsoftware.............................................. 166
M 2.86 Sicherstellen der Integritt von Standardsoftware ................. 168
M 2.87 Installation und Konfiguration von Standardsoftware........... 169
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.88 Lizenzverwaltung und Versionskontrolle von

M 2.89 Deinstallation von Standardsoftware ..................................... 172
M 2.90 berprfung der Lieferung.................................................... 173
M 2.91 Festlegung einer Sicherheitsstrategie fr das Windows
NT Client-Server-Netz........................................................... 175
M 2.92 Durchfhrung von Sicherheitskontrollen im Windows
NT Client-Server-Netz........................................................... 180
M 2.93 Planung des Windows NT Netzes.......................................... 182
M 2.94 Freigabe von Verzeichnissen unter Windows NT ................. 189
M 2.95 Beschaffung geeigneter Schutzschrnke................................ 193
M 2.96 Verschluss von Schutzschrnken........................................... 195
M 2.97 Korrekter Umgang mit Codeschlsser................................... 196
M 2.98 Sichere Installation von Novell Netware Servern.................. 197
M 2.99 Sichere Einrichtung von Novell Netware Servern................. 200
M 2.100 Sicherer Betrieb von Novell Netware Servern....................... 207
M 2.101 Revision von Novell Netware Servern .................................. 214
M 2.102 Verzicht auf die Aktivierung der Remote Console................ 216
M 2.103 Einrichten von Benutzerprofilen unter Windows 95 ............. 217
M 2.104 Systemrichtlinien zur Einschrnkung der
Nutzungsmglichkeiten von Windows 95 ............................. 219
M 2.105 Beschaffung von TK-Anlagen ............................................... 224
M 2.106 Auswahl geeigneter ISDN-Karten in der Beschaffung.......... 225
M 2.107 Dokumentation der ISDN-Karten-Konfiguration .................. 226
M 2.108 Verzicht auf Fernwartung der ISDN-
Netzkoppelelemente............................................................... 227
M 2.109 Rechtevergabe fr den Fernzugriff ........................................ 228
M 2.110 Datenschutzaspekte bei der Protokollierung.......................... 229
M 2.111 Bereithalten von Handbchern .............................................. 233
M 2.112 Regelung des Akten- und Datentrgertransports
zwischen huslichem Arbeitsplatz und Institution ................ 234
M 2.113 Regelungen fr Telearbeit ..................................................... 235
M 2.114 Informationsfluss zwischen Telearbeiter und Institution....... 237
M 2.115 Betreuungs- und Wartungskonzept fr Telearbeitspltze...... 238
M 2.116 Geregelte Nutzung der Kommunikationsmglichkeiten........ 239
M 2.117 Regelung der Zugriffsmglichkeiten des Telearbeiters ......... 241
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.118 Konzeption der sicheren E-Mail-Nutzung ............................. 242

M 2.119 Regelung fr den Einsatz von E-Mail.................................... 244
M 2.120 Einrichtung einer Poststelle ................................................... 247
M 2.121 Regelmiges Lschen von E-Mails ..................................... 248
M 2.122 Einheitliche E-Mail-Adressen................................................ 249
M 2.123 Auswahl eines Mailproviders ................................................ 250
M 2.124 Geeignete Auswahl einer Datenbank-Software ..................... 251
M 2.125 Installation und Konfiguration einer Datenbank.................... 254
M 2.126 Erstellung eines Datenbanksicherheitskonzeptes .................. 257
M 2.127 Inferenzprvention ................................................................. 260
M 2.128 Zugangskontrolle einer Datenbank........................................ 262
M 2.129 Zugriffskontrolle einer Datenbank......................................... 263
M 2.130 Gewhrleistung der Datenbankintegritt ............................... 266
M 2.131 Aufteilung von Administrationsttigkeiten bei
Datenbanksystemen ............................................................... 268
M 2.132 Regelung fr die Einrichtung von
Datenbankbenutzern/-benutzergruppen ................................. 270
M 2.133 Kontrolle der Protokolldateien eines Datenbanksystems....... 272
M 2.134 Richtlinien fr Datenbank-Anfragen ..................................... 274
M 2.135 Gesicherte Datenbernahme in eine Datenbank .................... 278
M 2.136 Einhaltung von Regelungen bzgl. Arbeitsplatz und
Arbeitsumgebung................................................................... 280
M 2.137 Beschaffung eines geeigneten Datensicherungssystems........ 281
M 2.138 Strukturierte Datenhaltung..................................................... 283
M 2.139 Ist-Aufnahme der aktuellen Netzsituation ............................. 285
M 2.140 Analyse der aktuellen Netzsituation ...................................... 287
M 2.141 Entwicklung eines Netzkonzeptes ......................................... 289
M 2.142 Entwicklung eines Netz-Realisierungsplans.......................... 292
M 2.143 Entwicklung eines Netzmanagementkonzeptes..................... 294
M 2.144 Geeignete Auswahl eines Netzmanagement-Protokolls ........ 296
M 2.145 Anforderungen an ein Netzmanagement-Tool....................... 300
M 2.146 Sicherer Betrieb eines Netzmanagementsystems................... 302
M 2.147 Sichere Migration von Novell Netware 3.x Servern in
Novell Netware 4.x Netze...................................................... 304
M 2.148 Sichere Einrichtung von Novell Netware 4.x Netzen ............ 306
M 2.149 Sicherer Betrieb von Novell Netware 4.x Netzen.................. 314
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.150 Revision von Novell Netware 4.x Netzen.............................. 328

M 2.151 Entwurf eines NDS-Konzeptes.............................................. 330
M 2.152 Entwurf eines Zeitsynchronisations-Konzeptes..................... 334
M 2.153 Dokumentation von Novell Netware 4.x Netzen................... 336
M 2.154 Erstellung eines Computer-Virenschutzkonzepts .................. 339
M 2.155 Identifikation potentiell von Computer-Viren
betroffener IT-Systeme .......................................................... 341
M 2.156 Auswahl einer geeigneten Computer-Virenschutz-
Strategie ................................................................................. 343
M 2.157 Auswahl eines geeigneten Computer-Viren-
Suchprogramms ..................................................................... 348
M 2.158 Meldung von Computer-Virusinfektionen............................. 350
M 2.159 Aktualisierung der eingesetzten Computer-Viren-
Suchprogramme ..................................................................... 351
M 2.160 Regelungen zum Computer-Virenschutz............................... 352
M 2.161 Entwicklung eines Kryptokonzepts ....................................... 354
M 2.162 Bedarfserhebung fr den Einsatz kryptographischer
Verfahren und Produkte......................................................... 358
M 2.163 Erhebung der Einflussfaktoren fr kryptographische
Verfahren und Produkte......................................................... 362
M 2.164 Auswahl eines geeigneten kryptographischen
Verfahrens.............................................................................. 371
M 2.165 Auswahl eines geeigneten kryptographischen Produktes ...... 375
M 2.166 Regelung des Einsatzes von Kryptomodulen ........................ 378
M 2.167 Sicheres Lschen von Datentrgern....................................... 380
M 2.168 IT-System-Analyse vor Einfhrung eines
Systemmanagementsystems................................................... 383
M 2.169 Entwickeln einer Systemmanagementstrategie...................... 385
M 2.170 Anforderungen an ein Systemmanagementsystem ................ 389
M 2.171 Geeignete Auswahl eines Systemmanagement-
Produktes ............................................................................... 391
M 2.172 Entwicklung eines Konzeptes fr die WWW-Nutzung ......... 396
M 2.173 Festlegung einer WWW-Sicherheitsstrategie ........................ 397
M 2.174 Sicherer Betrieb eines WWW-Servers................................... 399
M 2.175 Aufbau eines WWW-Servers................................................. 402
M 2.176 Geeignete Auswahl eines Internet Service Providers ............ 405
M 2.177 Sicherheit bei Umzgen......................................................... 406
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.178 Erstellung einer Sicherheitsleitlinie fr die Faxnutzung........ 410

M 2.179 Regelungen fr den Faxserver-Einsatz .................................. 412
M 2.180 Einrichten einer Fax-Poststelle .............................................. 416
M 2.181 Auswahl eines geeigneten Faxservers ................................... 418
M 2.182 Regelmige Kontrollen der IT-Sicherheitsmanahmen....... 424
M 2.183 Durchfhrung einer RAS-Anforderungsanalyse.................... 425
M 2.184 Entwicklung eines RAS-Konzeptes....................................... 426
M 2.185 Auswahl einer geeigneten RAS-Systemarchitektur............... 430
M 2.186 Geeignete Auswahl eines RAS-Produktes............................. 434
M 2.187 Festlegen einer RAS-Sicherheitsrichtlinie............................. 439
M 2.188 Sicherheitsrichtlinien und Regelungen fr die
Mobiltelefon-Nutzung ........................................................... 441
M 2.189 Sperrung des Mobiltelefons bei Verlust ................................ 450
M 2.190 Einrichtung eines Mobiltelefon-Pools ................................... 451
M 2.191 Etablierung des IT-Sicherheitsprozesses ............................... 453
M 2.192 Erstellung einer IT-Sicherheitsleitlinie .................................. 457
M 2.193 Aufbau einer geeigneten Organisationsstruktur fr IT-
Sicherheit ............................................................................... 464
M 2.194 Erstellung einer bersicht ber vorhandene IT-Systeme ...... 471
M 2.195 Erstellung eines IT-Sicherheitskonzepts................................ 473
M 2.196 Umsetzung des IT-Sicherheitskonzepts nach einem
Realisierungsplan................................................................... 477
M 2.197 Erstellung eines Schulungskonzepts fr IT-Sicherheit .......... 479
M 2.198 Sensibilisierung der Mitarbeiter fr IT-Sicherheit................. 481
M 2.199 Aufrechterhaltung der IT-Sicherheit...................................... 483
M 2.200 Erstellung von Managementreports zur IT-Sicherheit........... 487
M 2.201 Dokumentation des IT-Sicherheitsprozesses ......................... 489
M 2.202 Erstellung eines Handbuchs zur IT-Sicherheit ...................... 490
M 2.203 Aufbau einer Informationsbrse zur IT-Sicherheit................ 492
M 2.204 Verhinderung ungesicherter Netzzugnge ............................. 493
M 2.205 bertragung und Abruf personenbezogener Daten ............... 494
M 2.206 Planung des Einsatzes von Lotus Notes................................. 496
M 2.207 Festlegen einer Sicherheitsrichtlinie fr Lotus Notes ............ 498
M 2.208 Planung der Domnen und der Zertifikatshierarchie von
Lotus Notes............................................................................ 500
M 2.209 Planung des Einsatzes von Lotus Notes im Intranet .............. 503
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.210 Planung des Einsatzes von Lotus Notes im Intranet mit

Browser-Zugriff ..................................................................... 505
M 2.211 Planung des Einsatzes von Lotus Notes in einer DMZ.......... 508
M 2.212 Organisatorische Vorgaben fr die Gebudereinigung.......... 510
M 2.213 Wartung der technischen Infrastruktur .................................. 512
M 2.214 Konzeption des IT-Betriebs ................................................... 513
M 2.215 Fehlerbehandlung................................................................... 517
M 2.216 Genehmigungsverfahren fr IT-Komponenten...................... 519
M 2.217 Sorgfltige Einstufung und Umgang mit Informationen,
Anwendungen und Systemen................................................. 520
M 2.218 Regelung der Mitnahme von Datentrgern und IT-
Komponenten......................................................................... 522
M 2.219 Kontinuierliche Dokumentation der
Informationsverarbeitung....................................................... 524
M 2.220 Richtlinien fr die Zugriffs- bzw. Zugangskontrolle............. 525
M 2.221 nderungsmanagement ......................................................... 527
M 2.222 Regelmige Kontrollen der technischen IT-
Sicherheitsmanahmen .......................................................... 529
M 2.223 Sicherheitsvorgaben fr die Nutzung von
M 2.224 Vorbeugung gegen Trojanische Pferde.................................. 534
M 2.225 Zuweisung der Verantwortung fr Informationen,
Anwendungen und IT-Komponenten .................................... 536
M 2.226 Regelungen fr den Einsatz von Fremdpersonal ................... 537
M 2.227 Planung des Windows 2000 Einsatzes................................... 539
M 2.228 Festlegen einer Windows 2000 Sicherheitsrichtlinie............. 544
M 2.229 Planung des Active Directory ................................................ 550
M 2.230 Planung der Active Directory-Administration....................... 556
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000 .......... 559
M 2.232 Planung der Windows 2000 CA-Struktur .............................. 567
M 2.233 Planung der Migration von Windows NT auf Windows
2000 ....................................................................................... 571
M 2.234 Konzeption von Internet-PCs................................................. 576
M 2.235 Richtlinien fr die Nutzung von Internet-PCs ....................... 579
M 2.236 Planung des Einsatzes von Novell eDirectory ....................... 581
M 2.237 Planung der Partitionierung und Replikation im Novell
eDirectory .............................................................................. 586
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.238 Festlegung einer Sicherheitsrichtlinie fr Novell

eDirectory .............................................................................. 590
M 2.239 Planung des Einsatzes von Novell eDirectory im
Intranet................................................................................... 595
Extranet.................................................................................. 597
M 2.241 Durchfhrung einer Anforderungsanalyse fr den
Telearbeitsplatz...................................................................... 598
M 2.242 Zielsetzung der elektronischen Archivierung ........................ 600
M 2.243 Entwicklung des Archivierungskonzepts............................... 603
M 2.244 Ermittlung der technischen Einflussfaktoren fr die
elektronische Archivierung.................................................... 606
M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr die
elektronische Archivierung.................................................... 610
M 2.246 Ermittlung der organisatorischen Einflussfaktoren fr
die elektronische Archivierung.............................................. 612
M 2.247 Planung des Einsatzes von Exchange/Outlook 2000 ............. 617
M 2.248 Festlegung einer Sicherheitsrichtlinie fr Exchange/
Outlook 2000 ......................................................................... 621
M 2.249 Planung der Migration von "Exchange 5.5-Servern"
nach "Exchange 2000"........................................................... 623
M 2.250 Festlegung einer Outsourcing-Strategie................................. 626
M 2.251 Festlegung der Sicherheitsanforderungen fr
Outsourcing-Vorhaben........................................................... 630
M 2.252 Wahl eines geeigneten Outsourcing-Dienstleisters................ 633
M 2.253 Vertragsgestaltung mit dem Outsourcing-Dienstleister......... 635
M 2.254 Erstellung eines IT-Sicherheitskonzepts fr das
Outsourcing-Vorhaben........................................................... 640
M 2.255 Sichere Migration bei Outsourcing-Vorhaben....................... 643
M 2.256 Planung und Aufrechterhaltung der IT-Sicherheit im
laufenden Outsourcing-Betrieb.............................................. 646
M 2.257 berwachung der Speicherressourcen von
Archivmedien......................................................................... 648
M 2.258 Konsistente Indizierung von Dokumenten bei der
Archivierung .......................................................................... 650
M 2.259 Einfhrung eines bergeordneten
Dokumentenmanagements..................................................... 652
M 2.260 Regelmige Revision des Archivierungsprozesses.............. 655
M 2.261 Regelmige Marktbeobachtung von Archivsystemen ......... 658
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.262 Regelung der Nutzung von Archivsystemen ......................... 659

M 2.263 Regelmige Aufbereitung von archivierten
Datenbestnden...................................................................... 661
M 2.264 Regelmige Aufbereitung von verschlsselten Daten
bei der Archivierung .............................................................. 662
M 2.265 Geeigneter Einsatz digitaler Signaturen bei der
Archivierung, ......................................................................... 664
M 2.266 Regelmige Erneuerung technischer Archivsystem-
Komponenten,........................................................................ 673
M 2.267 Planen des IIS-Einsatzes,....................................................... 674
M 2.268 Festlegung einer IIS-Sicherheitsrichtlinie.............................. 676
M 2.269 Planung des Einsatzes eines Apache Webservers.................. 678
M 2.270 Planung des SSL-Einsatzes beim Apache Webserver
(zustzlich),............................................................................ 680
M 2.271 Festlegung einer Sicherheitsstrategie fr den WWW-
Zugang, .................................................................................. 683
M 2.272 Einrichtung eines WWW-Redaktionsteams, ......................... 684
M 2.273 Zeitnahes Einspielen sicherheitsrelevanter Patches und
Updates, ................................................................................. 685
M 2.274 Vertretungsregelungen bei E-Mail-Nutzung,......................... 687
M 2.275 Einrichtung funktionsbezogener E-Mailadressen, ................ 689
M 2.276 Funktionsweise eines Routers................................................ 691
M 2.277 Funktionsweise eines Switches.............................................. 696
M 2.278 Typische Einsatzszenarien von Routern und Switches.......... 701
M 2.279 Erstellung einer Sicherheitsrichtlinie fr Router und
Switches................................................................................ 708
M 2.280 Kriterien fr die Beschaffung und geeignete Auswahl
von Routern und Switches ..................................................... 711
M 2.281 Dokumentation der Systemkonfiguration von Routern
und Switches.......................................................................... 716
M 2.282 Regelmige Kontrolle von Routern und Switches............... 718
M 2.283 Software-Pflege auf Routern und Switches ........................... 722
M 2.284 Sichere Auerbetriebnahme von Routern und Switches........ 725
M 2.285 Festlegung von Standards fr z/OS-Systemdefinitionen ....... 727
M 2.286 Planung und Einsatz von zSeries-Systemen .......................... 729
M 2.287 Batch-Job-Planung fr z/OS-Systeme ................................... 733
M 2.288 Erstellung von Sicherheitsrichtlinien fr z/OS-Systeme ....... 735
M 2.289 Einsatz restriktiver z/OS-Kennungen .................................... 737
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.290 Einsatz von RACF-Exits........................................................ 739

M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS............... 741
M 2.292 berwachung von z/OS-Systemen ........................................ 745
M 2.293 Wartung von zSeries-Systemen ............................................. 747
M 2.294 Synchronisierung von z/OS-Passwrtern und RACF-
Kommandos ........................................................................... 752
M 2.295 Systemverwaltung von z/OS-Systemen................................. 754
M 2.296 Grundstzliche berlegungen zu z/OS-
Transaktionsmonitoren .......................................................... 756
M 2.297 Deinstallation von z/OS-Systemen ........................................ 764
M 2.298 Verwaltung von Internet-Domainnamen ............................... 766
M 2.299 Erstellung einer Sicherheitsrichtlinie fr ein
M 2.300 Sichere Auerbetriebnahme oder Ersatz von
Komponenten eines Sicherheitsgateways .............................. 772
M 2.301 Outsourcing des Sicherheitsgateway ..................................... 774
M 2.302 Sicherheitsgateways und Hochverfgbarkeit......................... 777
M 2.303 Festlegung einer Strategie fr den Einsatz von PDAs ........... 783
M 2.304 Sicherheitsrichtlinien und Regelungen fr die PDA-
Nutzung.................................................................................. 785
M 2.305 Geeignete Auswahl von PDAs .............................................. 789
M 2.306 Verlustmeldung...................................................................... 792
___________________________________________________________________ ..........................................
Manahmenkatalog Organisation M 2.1 Bemerkungen
___________________________________________________________________ ..........................................
M 2.1 Festlegung von Verantwortlichkeiten und

Regelungen fr den IT-Einsatz
Verantwortlich fr Umsetzung: Leiter IT, Leiter Organisation
Fr die Aufgabenbereiche "IT-Einsatz" und "IT-Sicherheit" mssen sowohl
Verantwortlichkeiten als auch Befugnisse festgelegt sein.
Fr den "IT-Einsatz" ist eine Festlegung der Fachverantwortung und der
Betriebsverantwortung vorzunehmen. Der Fachverantwortliche ist zustndig
fr die Erarbeitung der fachlichen Vorgaben, die es in einem IT-Verfahren
umzusetzen gilt. Hingegen umfasst die Betriebsverantwortung unter anderem
folgende Aufgaben:
- Datenerfassung,
- Arbeitsplanung und -vorbereitung,
- Datenverarbeitung,
- Nachbereitung von Datenausgaben,
- Datentrgerverwaltung und
- berwachung des Verfahrensbetriebes.
bergreifende Regelungen zur "IT-Sicherheit" als ein Aspekt des IT-Einsatzes
mssen verbindlich festgelegt werden. Es empfiehlt sich, Regelungen ber
- Datensicherung,
- Datenarchivierung,
- Datentrgertransport,
- Datenbertragung,
- Datentrgervernichtung,
- Dokumentation von IT-Verfahren, Software, IT-Konfiguration,
- Gebrauch von Passwrtern,
- Zutrittsberechtigungen,
- Zugangsberechtigungen,
- Zugriffsberechtigungen,
- Betriebsmittelverwaltung,
- Kauf und Leasing von Hardware und Software,
- Wartungs- und Reparaturarbeiten,
- Software: Abnahme und Freigabe,
- Software: Anwendungsentwicklung,
- Datenschutz,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Schutz gegen Computer-Viren,

- Revision,
- Notfallvorsorge und
- Vorgehensweise bei der Verletzung der Sicherheitspolitik
zu treffen. Hinweise dazu finden sich in den nachfolgenden Manahmenbe-
schreibungen.
Diese Regelungen sind den betroffenen Mitarbeitern in geeigneter Weise
bekannt zu geben (siehe M 3.2 Verpflichtung der Mitarbeiter auf Einhaltung
einschlgiger Gesetze, Vorschriften und Regelungen). Es empfiehlt sich, die
Bekanntgabe zu dokumentieren. Darber hinaus sind smtliche Regelungen in
der aktuellen Form an einer Stelle vorzuhalten und bei berechtigtem Interesse
zugnglich zu machen.
Die getroffenen Regelungen sind regelmig zu aktualisieren, um Miver-
stndnisse, ungeklrte Zustndigkeiten und Widersprche zu verhindern.
- Welche Regelungen sind in Kraft?
- Werden die Regelungen regelmig berarbeitet?
- Wie werden die Regelungen den Mitarbeitern bekannt gegeben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.2 Betriebsmittelverwaltung
Betriebsmittel (oder Sachmittel) fr den IT-Einsatz sind alle erforderlichen
Mittel wie Hardware-Komponenten (Rechner, Tastatur, Drucker usw.), Soft-
ware (Systemsoftware, Individualprogramme, Standardprogramme u. .),
Verbrauchsmaterial (Papier, Toner, Druckerpatronen), Datentrger
(Magnetbnder, Disketten, Streamertapes, Festplatten, Wechselplatten, CD-
ROMs u. .).
Die Betriebsmittelverwaltung umfasst die Abwicklung der Aufgaben:
- Beschaffung der Betriebsmittel,
- Prfung vor Einsatz,
- Kennzeichnung und
- Bestandsfhrung.
Die Beschaffung von Betriebsmitteln ist beim Einsatz von Informations- Regelung der
Beschaffung
technik von besonderer Bedeutung. Mit einem geregelten Beschaffungs-
verfahren lassen sich insbesondere die Ziele untersttzen, die mit dem Einsatz
von Informationstechnik angestrebt werden: Leistungssteigerung, Wirtschaft-
lichkeit, Verbesserung der Kommunikationsmglichkeiten.
Neben reinen Wirtschaftlichkeitsaspekten kann durch ein geregeltes Beschaf-
fungsverfahren - das von zentraler Stelle aus vorgenommen werden kann -
auch die Neu- und Weiterentwicklung im Bereich der Informationstechnik
strker bercksichtigt werden.
Eine zentrale Beschaffung sichert darber hinaus die Einfhrung und Einhal- Hausstandards
tung eines "Hausstandards", der die Schulung der Mitarbeiter und Wartungs-
aktivitten vereinfacht.
Mit einem geregelten Prfverfahren vor Einsatz der Betriebsmittel lassen
sich unterschiedliche Gefhrdungen abwenden. Beispiele sind:
- berprfung der Vollstndigkeit von Lieferungen (z. B. Handbcher), um
die Verfgbarkeit aller Lieferteile zu gewhrleisten,
- Test neuer PC-Software sowie neuer vorformatierter Datentrger mit einem
Computer-Viren-Suchprogramm,
- Testlufe neuer Software auf speziellen Test-Systemen,
- berprfung der Kompatibilitt neuer Hardware- und Softwarekompo-
nenten mit den vorhandenen.
Erst mit Hilfe einer Bestandsfhrung der eingesetzten Betriebsmittel ist es
mglich, den Verbrauch zu ermitteln und Nachbestellungen zu veranlassen.
Darber hinaus ermglicht die Bestandsfhrung Vollstndigkeitskontrollen,
berprfung des Einsatzes von nicht genehmigter Software oder die Feststel-
lung der Entwendung von Betriebsmitteln. Hierzu bedarf es einer eindeutigen
Kennzeichnung der wesentlichen Betriebsmittel mit eindeutigen Identifi-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zierungsmerkmalen (z. B. gruppierte fortlaufende Inventarnummern). Zustz-

lich sollten die Seriennummern vorhandener Gerte wie Bildschirm, Drucker,
Festplatten etc. dokumentiert werden, damit sie nach einem Diebstahl identi-
fiziert werden knnen.
Fr die Bestandsfhrung mssen die Betriebsmittel in Bestandsverzeichnissen Bestandsverzeichnisse
aufgelistet werden. Ein solches Bestandsverzeichnis muss Auskunft geben
knnen ber:
- Identifizierungsmerkmale,
- Beschaffungsquellen, Lieferzeiten,
- Verbleib der Betriebsmittel,
- Lagervorhaltung,
- Aushndigungsvorschriften und
- Wartungsvertrge, Wartungsintervalle.
Um den Missbrauch von Daten zu verhindern, sollte die Lschung oder Lschung und
Vernichtung
Vernichtung von Betriebsmitteln geregelt sein. Insbesondere ist der Umgang
mit Altpapier zu regeln. Es sollte geeignete Entsorgungsmglichkeit fr
Verbrauchsgter mit hherem Schutzbedarf geben, z. B. so genannte
Schredder fr Papier. Alle Verbrauchsgter, aus denen Informationen
gewonnen werden knnten, wie z. B. Zwischentrgerfolien oder fehlerhafte
Ausdrucke, sollten vor der Entsorgung vernichtet oder durch eine zuverlssige
Fachfirma entsorgt werden. Das Gleiche gilt beim Austausch
informationstragender Ersatzteile, wie z. B. photoelektrische Trommeln.
- Ermglicht die Bestandsfhrung eine Vollstndigkeitskontrolle?
- Welche Prfverfahren vor Einsatz sind eingefhrt worden? Welche
Ergebnisse wurden erzielt?
- Ist der Beschaffungsgang geregelt oder gibt es die Mglichkeit, die
Betriebsmittelverwaltung bei Beschaffungvorgngen zu umgehen?
- Wie aktuell ist das Bestandsverzeichnis?
- Auf welche Weise wird nicht mehr bentigtes Verbrauchsmaterial
entsorgt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.3 Datentrgerverwaltung
Verantwortlich fr Umsetzung: Archivverwalter, IT-Verfahrensverantwortli-
cher,
Aufgabe der Datentrgerverwaltung als Teil der Betriebsmittelverwaltung ist
es, den Zugriff auf Datentrger im erforderlichen Umfang und in angemesse-
ner Zeit gewhrleisten zu knnen. Dies erfordert eine geregelte Verwaltung
der Datentrger, die eine einheitliche Kennzeichnung sowie eine Fhrung von
Bestandsverzeichnissen erforderlich macht. Weiterhin ist im Rahmen der Da-
tentrgerverwaltung die sachgerechte Behandlung und Aufbewahrung der
Datentrger, deren ordnungsgemer Einsatz und Transport und schlielich
auch noch die Lschung bzw. Vernichtung der Datentrger zu gewhrleisten.
Bestandsverzeichnisse ermglichen einen schnellen und zielgerichteten
Zugriff auf Datentrger. Bestandsverzeichnisse geben Auskunft ber: Aufbe-
wahrungsort, Aufbewahrungsdauer, berechtigte Empfnger.
Die uerliche Kennzeichnung von Datentrgern ermglicht deren schnelle
Identifizierung. Die Kennzeichnung sollte jedoch fr Unbefugte keine Rck-
schlsse auf den Inhalt erlauben (z. B. die Kennzeichnung eines Magnetban-
des mit dem Stichwort "Telefongebhren"), um einen Missbrauch zu erschwe-
ren. Eine festgelegte Struktur von Kennzeichnungsmerkmalen (z. B. Datum,
Ablagestruktur, lfd. Nummer) erleichtert die Zuordnung in Bestandsverzeich-
nissen.
Fr eine sachgerechte Behandlung von Datentrgern sind die Herstelleran-
gaben, die blicherweise auf der Verpackung zu finden sind, heranzuziehen.
Hinsichtlich der Aufbewahrung von Datentrgern sind einerseits Manahmen
zur Lagerung (magnetfeld-/staubgeschtzt, klimagerecht) und andererseits
Manahmen zur Verhinderung des unbefugten Zugriffs (geeignete Behlt-
nisse, Schrnke, Rume) zu treffen.
Der Versand oder Transport von Datentrgern muss in der Weise erfolgen,
dass eine Beschdigung der Datentrger mglichst ausgeschlossen werden
kann (z. B. Magnetbandversandtasche, luftgepolsterte Umschlge). Die Ver-
packung des Datentrgers ist an seiner Schutzbedrftigkeit auszurichten (z. B.
mittels verschliebaren Transportbehltnissen). Versand- oder Transportarten
(z. B. Kuriertransport) mssen ebenso festgelegt werden wie das Nachweis-
verfahren ber den Versand (z. B. Begleitzettel, Versandscheine) und den
Eingang beim Empfnger (z. B. Empfangsbesttigung). Der Datentrger darf
ber die zu versendenden Daten hinaus, keine "Restdaten" enthalten. Dies
kann durch physikalisches Lschen erreicht werden. Stehen hierzu keine
Werkzeuge zur Verfgung, so sollte der Datentrger zumindest formatiert
werden. Dabei sollte sichergestellt werden, dass mit dem zugrunde liegenden
Betriebssystem eine Umkehr des Befehls nicht mglich ist. Weiterhin ist zu
beachten, dass vor Abgabe wichtiger Datentrger eine Sicherungskopie erstellt
wird. Weitere Ausfhrungen zum Versand und Transport von Datentrgern
enthlt das Kapitel 7.1 Datentrgeraustausch.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr die interne Weitergabe von Datentrger knnen Regelungen getroffen

werden wie Quittungsverfahren, Abhol-/Mitnahmeberechtigungen sowie das
Fhren von Bestandsverzeichnissen ber den Verbleib der Datentrger.
Fr den Fall, dass von Dritten erhaltene Datentrger eingesetzt werden,
sind Regelungen ber deren Behandlung vor dem Einsatz zu treffen. Werden
zum Beispiel Daten fr PCs bermittelt, sollte generell ein Computer-Viren-
Check des Datentrgers erfolgen. Dies gilt entsprechend auch vor dem erst-
maligen Einsatz neuer Datentrger. Es ist empfehlenswert, nicht nur beim
Empfang, sondern auch vor dem Versenden von Datentrgern diese auf Com-
puter-Viren zu berprfen.
Eine geregelte Vorgehensweise fr die Lschung oder Vernichtung von Da-
tentrgern verhindert den Missbrauch der gespeicherten Daten. Vor der Wie-
derverwendung von Datentrgern muss die Lschung der gespeicherten Daten
vorgenommen werden; siehe hierzu: M 2.167 Sicheres Lschen von Datentr-
gern.
- Liegt ein (tages-)aktuelles Bestandsverzeichnis vor?
- Prft der Archivverwalter die Berechtigung einer Datentrgeranforderung?
- Werden Vollstndigkeitskontrollen des Datentrgerbestands vorgenom-
men?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.4 Regelungen fr Wartungs- und

Reparaturarbeiten
Verantwortlich fr Umsetzung: Leiter IT, Administrator, IT-Benutzer
Als vorbeugende Manahme, um die IT vor Strungen zu bewahren, ist die
ordnungsgeme Durchfhrung von Wartungsarbeiten von besonderer Be-
deutung. Die rechtzeitige Einleitung von Wartungsarbeiten und die ber-
prfung ihrer Durchfhrung sollte von einer zentralen Stelle aus wahrge-
nommen werden (z. B. Beschaffungsstelle). Dabei sollten die Wartungs-
arbeiten von vertrauenswrdigen Personen oder Firmen durchgefhrt werden.
Die Hinweise des Herstellers mssen dabei unbedingt beachtet werden.
Fr jedes IT-System sollte dokumentiert werden, wann es gewartet wurde und
welche Fehler dabei behoben wurden. Es empfiehlt sich auerdem, ein Infor-
mationssystem fr Wartungs- und Reparaturarbeiten einzurichten. Mit einem
solchen System knnen anstehende Arbeiten geplant und durchgefhrte
Arbeiten dokumentiert werden.
Regelmige Reinigung von IT-Gerten
Alle Arten von IT-Gerten sollten regelmig gereinigt werden. Die hierfr Sicherheit = Ordnung +
Sauberkeit
empfehlenswerten Intervalle hngen von der Art des Gertes bzw. der
Einsatzumgebung ab. Mindestens einmal pro Jahr sollte aber eine Reinigung
erfolgen, nicht nur weil es unangenehm ist, mit verschmutzten Gerten zu
arbeiten, sondern auch weil Verschmutzungen deren Funktionsfhigkeit be-
eintrchtigen kann.
Beispiele: Tastaturen sollten sptestens dann gesubert werden, wenn sie
klebrig werden oder einzelne Tasten klemmen. Ein Arbeitsplatz-PC sollte
auch von innen von Staub befreit werden, sofern die Herstellerangaben nicht
eine andere Vorgehensweise vorschlagen. Bei Druckern kann bei nachlssiger
Reinigung die Druckqualitt leiden oder Komponenten beschdigt werden.
Typische Problempunkte hier sind die Druckerwalze und der Druckkopf.
Zu viel Staub in IT-Systemen kann zu einem Hitzestau fhren. Durch Verun-
reinigungen auf Platinen (besonders wirkungsvoll sind Kombinationen aus
Staub und Teer- und Nikotinablagerungen) knnen Kriechstrme verursacht
werden.
Ablagerungen sollten daher regelmig vorsichtig entfernt werden. Insbe- Vorgaben der Hersteller
beachten
sondere sollte fr eine wirkungsvolle Lftung aller IT-Systeme gesorgt
werden. Alle Belfter und Lftungskomponenten mssen von strenden Ver-
unreinigungen frei gehalten werden. Bei der Reinigung von IT-Gerten sind
unbedingt die Vorgaben des Herstellers zu beachten, sowohl bei der Vor-
gehensweise und Werkzeug-Auswahl als auch bei den Mindest-Intervallen.
Wartungs- und Reparaturarbeiten im Hause
Fr Wartungs- und Reparaturarbeiten, insbesondere wenn sie durch Externe
durchgefhrt werden, sind Regelungen ber deren Beaufsichtigung zu
treffen: whrend der Arbeiten sollte eine fachkundige Kraft die Arbeiten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
soweit beaufsichtigen, dass sie beurteilen kann, ob whrend der Arbeit un-
autorisierte Handlungen vollzogen werden. Weiterhin ist zu berprfen, ob der
Wartungsauftrag ausgefhrt wurde.
Als Manahmen vor und nach Wartungs- und Reparaturarbeiten sind
einzuplanen:
- Wartungs- und Reparaturarbeiten sind gegenber den betroffenen Mit- Arbeiten ankndigen
arbeitern rechtzeitig anzukndigen.
- Wartungstechniker mssen sich auf Verlangen ausweisen.
- Der Zugriff auf Daten durch den Wartungstechniker ist soweit wie mglich
zu vermeiden. Falls erforderlich, sind Speichermedien vorher auszubauen
oder zu lschen (nach einer kompletten Datensicherung), insbesondere
wenn die Arbeiten extern durchgefhrt werden mssen. Falls das Lschen
nicht mglich ist (z. B. aufgrund eines Defektes), sind die Arbeiten auch
extern zu beobachten bzw. es sind besondere vertragliche Vereinbarungen
zu treffen.
- Die dem Wartungstechniker eingerumten Zutritts-, Zugangs- und Rechte fr Wartungs-
techniker minimieren
Zugriffsrechte sind auf das notwendige Minimum zu beschrnken und nach
den Arbeiten zu widerrufen bzw. zu lschen.
- Nach der Durchfhrung von Wartungs- oder Reparaturarbeiten sind - je Passwrter hinterher
ndern!
nach "Eindringtiefe" des Wartungspersonals - Passwortnderungen er-
forderlich. Im PC-Bereich sollte ein Computer-Viren-Check durchgefhrt
werden.
- Die durchgefhrten Wartungsarbeiten sind zu dokumentieren (Umfang,
Ergebnisse, Zeitpunkt, evtl. Name des Wartungstechnikers).
- Beauftragte Firmen sollten schriftlich zusichern, dass sie einschlgige
Sicherheitsvorschriften und Richtlinien (z. B. Brandschutz, VdS 2008
Schwei-, Lt- und Trennschleifarbeiten) beachten. Dies gilt fr alle
Ttigkeiten, bei denen eine direkte oder indirekte Gefahr fr Gebude oder
Menschen entstehen knnen. Letztlich kommt es darauf an, dass das vor
Ort eingesetzte Personal mit diesen Regeln vertraut ist.
- Im Anschluss an die Wartungs- oder Reparaturarbeiten ist die ordnungs- Nach Reparatur Funk-
tionsfhigkeit prfen
geme Funktion der gewarteten Anlage zu berprfen. Insbesondere die
Rcknahme der fr Testzwecke vorgenommenen Eingriffe ist zu kontrol-
lieren.
Externe Wartungs- und Reparaturarbeiten
Werden IT-Systeme zur Wartung oder Reparatur auer Haus gegeben, sind
alle sensitiven Daten, die sich auf Datentrgern befinden, vorher physikalisch
zu lschen. Ist dies nicht mglich, weil aufgrund eines Defekts nicht mehr auf
die Datentrger zugegriffen werden kann, sind die mit der Reparatur beauf-
tragten Unternehmen auf die Einhaltung der erforderlichen IT-Sicherheits-
manahmen zu verpflichten. Entsprechend M 3.2 Verpflichtung der
Mitarbeiter auf Einhaltung einschlgiger Gesetze, Vorschriften und
Regelungen sind mit diesen vertragliche Regelungen ber die Geheimhaltung
von Daten zu treffen. Insbesondere ist festzulegen, dass Daten, die im Rahmen
der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wartung extern gespeichert wurden, nach Abschluss der Arbeiten sorgfltig

gelscht werden. Ebenso sind die Pflichten und Kompetenzen des externen
Wartungspersonals sorgfltig festzulegen.
Bei der Durchfhrung externer Wartungsarbeiten muss protokolliert werden, Protokollierung aller
Wartungsarbeiten
welche IT-Systeme oder Komponenten wann an wen zur Reparatur gegeben
wurden, wer dies veranlasst hat, was der Wartungs- bzw. Reparaturauftrag
umfasst, zu welchem Zeitpunkt die Reparatur abgeschlossen sein sollte und
wann das Gert wieder zurckgebracht wurde. Um dies nachhalten zu knnen,
ist eine Kennzeichnung der IT-Systeme oder Komponenten erforderlich, aus
der zum einem hervorgeht, welcher Organisation diese gehren, und zum
anderen eine eindeutige Zuordnung innerhalb der Organisation mglich ist.
Bei Versand oder Transport der zu reparierenden IT-Komponenten sollte
darauf geachtet werden, dass Beschdigungen und Diebstahl vorgebeugt wird.
Befinden sich auf den IT-Systemen noch sensitive Informationen, mssen sie
entsprechend geschtzt transportiert werden, also z. B. in verschlossenen
Behltnissen oder durch Kuriere. Weiterhin mssen Nachweise ber den Ver-
sand (Begleitzettel, Versandscheine) und den Eingang beim Empfnger
(Empfangsbesttigung) gefhrt und archiviert werden.
Bei IT-Systemen, die durch Passwrter geschtzt sind, mssen je nach Um- Passwrter
fang der Reparaturarbeiten und der Art der Passwortabsicherung, alle oder
einige Passwrter entweder bekannt gegeben oder auf festgelegte Ein-
stellungen wie "REPARATUR" gesetzt werden, damit die Wartungstechniker
auf die Gerte zugreifen knnen.
Nach der Rckgabe der IT-Systeme oder Komponenten sind diese auf Voll- berprfung nach
Fertigstellung
stndigkeit zu berprfen. Alle Passwrter sind zu ndern. PC-Datentrger
sind nach der Rckgabe mittels eines aktuellen Viren-Suchprogramms auf
Computer-Viren zu berprfen. Alle Dateien oder Programme, die sich auf
dem reparierten Gert befinden, sind auf Integritt zu berprfen.
Fernwartung
Regelungen fr die Fernwartung knnen der Manahme M 5.33 Absicherung
der per Modem durchgefhrten Fernwartung entnommen werden.
- Werden die Mitarbeiter zur Wahrnehmung der Aufsicht angehalten?
- Werden Nachweise ber durchgefhrte Wartungsarbeiten gefhrt?
- Liegt ein Fristenplan fr Wartungsarbeiten vor?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.5 Aufgabenverteilung und Funktionstrennung

Verantwortlich fr Umsetzung: Leiter IT, Leiter Organisation, IT-
Die von der Behrde bzw. dem Unternehmen im Zusammenhang mit dem IT-
Einsatz wahrzunehmenden Funktionen sind festzulegen. Zu unterscheiden
sind hier zwei Ebenen:
- Die erste Ebene besteht aus den Funktionen, die den IT-Einsatz ermg-
lichen oder untersttzen wie Arbeitsvorbereitung, Datennachbereitung,
Operating, Programmierung, Netzadministration, Rechteverwaltung,
Revision.
- Die zweite Ebene besteht aus den Funktionen, die die zur Aufgabenerfl-
lung bereitstehenden IT-Verfahren anwenden. Beispiele solcher Funktio-
nen sind: Fachverantwortlicher, IT-Anwendungsbetreuer, Datenerfasser,
Sachbearbeiter, Zahlungsanordnungsbefugter.
Im nchsten Schritt ist die Funktionstrennung festzulegen und zu begrnden,
d. h. welche Funktionen nicht miteinander vereinbar sind, also auch nicht von
einer Person gleichzeitig wahrgenommen werden drfen. Vorgaben hierfr
knnen aus den Aufgaben selbst oder aus gesetzlichen Bestimmungen
resultieren. Beispiele dafr sind:
- Rechteverwaltung und Revision,
- Netzadministration und Revision,
- Programmierung und Test bei eigenerstellter Software,
- Datenerfassung und Zahlungsanordnungsbefugnis,
- Revision und Zahlungsanordnungsbefugnis.
Insbesondere wird deutlich, dass meistens operative Funktionen nicht mit
kontrollierenden Funktionen vereinbar sind.
Nach der Festlegung der einzuhaltenden Funktionstrennung kann die Zuord-
nung der Funktionen zu Personen erfolgen.
Die hier getroffenen Festlegungen sind zu dokumentieren und bei Vernde-
rungen im IT-Einsatz zu aktualisieren. Sollte bei dieser Zuordnung eine
Person miteinander unvereinbare Funktionen wahrnehmen mssen, so ist dies
in einer entsprechenden Dokumentation ber die Funktionsverteilung beson-
ders hervorzuheben.
- Ist die Aufzhlung der relevanten Funktionen umfassend?
- Sind die definierten Funktionstrennungen vollstndig?
- Wird die Funktionstrennung personell aufrechterhalten?
- Wird die Zuordnung Personen/Funktionen aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.6 Vergabe von Zutrittsberechtigungen

Verantwortlich fr Umsetzung: Leiter Organisation, Leiter Haustechnik
Vor der Vergabe von Zutrittsberechtigungen fr Personen sind die schutz-
bedrftigen Rume eines Gebudes zu bestimmen, z. B. Bro, Datentrger-
archiv, Serverraum, Operating-Raum, Maschinensaal, Belegarchiv, Rechen-
zentrum. Der Schutzbedarf eines Raumes ist festzustellen anhand der im
Raum befindlichen Informationstechnik sowie am Schutzbedarf der einge-
setzten IT-Anwendungen und ihrer Informationen.
Anschlieend ist festzulegen, welche Person zur Ausbung der wahrgenom-
menen Funktion welches Zutrittsrecht bentigt. Dabei ist die vorher erarbei-
tete Funktionstrennung (M 2.5 Aufgabenverteilung und Funktionstrennung) zu
beachten. Unntige Zutrittsrechte sind zu vermeiden.
Um die Zahl zutrittsberechtigter Personen zu einem Raum mglichst gering zu
halten, sollte auch beim IT-Einsatz der Grundsatz der Funktionstrennung
bercksichtigt werden. So verhindert z. B. eine getrennte Lagerung von IT-
Ersatzteilen und Datentrgern den unerlaubten Zugriff eines Wartungstech-
nikers auf die Datentrger.
Die Vergabe und Rcknahme von Zutrittsberechtigungen ist zu dokumen-
tieren. Bei der Rcknahme einer Zutrittsberechtigung muss die Rcknahme
des Zutrittsmittels gewhrleistet sein. Zustzlich ist zu dokumentieren, welche
Konflikte bei der Vergabe der Zutrittsberechtigungen an Personen aufgetreten
sind. Grnde fr Konflikte knnen vorliegen, weil Personen Funktionen
wahrnehmen, die bezglich der Zutrittsberechtigungen der Funktionstrennung
entgegenstehen, oder aufgrund rumlicher Notwendigkeiten.
Zur berwachung der Zutrittsberechtigung knnen Personen (Pfrtner,
Schliedienst) oder technische Einrichtungen (Ausweisleser, Schloss) einge-
setzt werden (vgl. M 2.14 Schlsselverwaltung). Der Zutritt zu schutzbedrf-
tigen Rumen von nicht autorisiertem Personal (z. B. Besuchern) darf nur bei
Anwesenheit oder in Begleitung Zutrittsberechtigter erfolgen.
Regelungen ber die Vergabe und Rcknahme von Zutrittsberechtigungen fr
Fremdpersonal und Besucher mssen ebenfalls getroffen werden.
- Liegt eine Dokumentation vor, die den Schutzbedarf von IT-Rumen
ausweist?
- Wird die Dokumentation schutzbedrftiger Rume und zutrittsberechtigter
Personen aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.7 Vergabe von Zugangsberechtigungen

Verantwortlich fr Umsetzung: Leiter IT, Fachverantwortliche
Zugangsberechtigungen erlauben der betroffenen Person, bestimmte IT-
Systeme bzw. System-Komponenten und Netze zu nutzen. Dies ist fr jede
nutzungsberechtigte Person aufgrund ihrer Funktion, unter Beachtung der
Funktionstrennung (vgl. M 2.5 Aufgabenverteilung und Funktionstrennung),
im einzelnen festzulegen. Entsprechend der Funktion ist der Zugang zum
Rechner zu definieren, z. B. Zugang zum Betriebssystem (Systemverwalter)
oder Zugang zu einer IT-Anwendung (Anwender). Ergnzend hierzu muss
sichergestellt sein, dass personelle und aufgabenbezogene nderungen unver-
zglich bercksichtigt werden.
Der Zugang soll - sofern DV-technisch mglich - erst nach einer Identifikation
(z. B. durch Name, User-ID oder Chipkarte) und Authentisierung (z. B. durch
ein Passwort) des Nutzungsberechtigten mglich sein und protokolliert
werden.
Die Ausgabe bzw. der Einzug von Zugangsmitteln wie Benutzer-Kennungen
oder Chipkarten ist zu dokumentieren. Regelungen ber die Handhabung von
Zugangs- und Authentifikationsmitteln (z. B. Umgang mit Chipkarten,
Passworthandhabung, vgl. M 2.11 Regelung des Passwortgebrauchs) mssen
ebenfalls getroffen werden.
Die vorbergehende Sperrung einer Zugangsberechtigung sollte bei lnger-
whrender Abwesenheit der berechtigten Person vorgenommen werden, um
Missbruche zu verhindern.
Es ist notwendig, die vorgenannten Festlegungen auf ihre korrekte Einhaltung
sporadisch zu kontrollieren.
- Wird die Vergabe sowie der Einzug von Zugangsberechtigungen und
Zugangsmitteln dokumentiert?
- Wird bei der Vergabe von Zugangsberechtigungen die Funktionstrennung
eingehalten?
- Werden die Benutzer zum korrekten Umgang mit Zugangsmitteln
geschult?
- Falls die Nutzung von Zugangsmitteln protokolliert wird, werden diese
Protokolle auch ausgewertet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.8 Vergabe von Zugriffsrechten

Verantwortlich fr Umsetzung: Administrator, Fachverantwortliche
ber Zugriffsrechte wird geregelt, welche Person im Rahmen ihrer Funktion
bevollmchtigt wird, IT-Anwendungen oder Daten zu nutzen. Die Zugriffs-
rechte (z. B. Lesen, Schreiben, Ausfhren) auf IT-Anwendungen, Teilanwen-
dungen oder Daten sind von der Funktion abhngig, die die Person wahr-
nimmt, z. B. Anwenderbetreuer, Arbeitsvorbereiter, Systemprogrammierer,
Anwendungsentwickler, Systemadministrator, Revisor, Datenerfasser, Sach-
bearbeiter. Dabei sollten immer nur so viele Zugriffsrechte vergeben werden,
wie es fr die Aufgabenwahrnehmung notwendig ist ("Need-to-know-
Prinzip"). Umgesetzt werden mssen die Zugriffsrechte durch die Rechte-
verwaltung des IT-Systems.
Eine Vielzahl von IT-Systemen lassen es zu, dass verschiedene Rechte als
Gruppenrechte bzw. als Rechteprofil definiert werden (z. B. Gruppe Datener-
fasser). Diese Definition entspricht der technischen Umsetzung der Rechte, die
einer Funktion zugeordnet werden. Fr die Administration der Rechte eines
IT-Systems ist es vorteilhaft, solche Gruppen oder Profile zu erstellen, da
damit die Rechtezuteilung und deren Aktualisierung erheblich vereinfacht
werden kann.
Die Festlegung und Vernderung von Zugriffsrechten ist vom jeweils Verant-
wortlichen zu veranlassen und zu dokumentieren. Aus der Dokumentation
muss hervorgehen:
- welche Funktion unter Beachtung der Funktionstrennung (vgl. M 2.5
Aufgabenverteilung und Funktionstrennung) mit welchen Zugriffsrechten
ausgestattet wird,
- welche Gruppen bzw. Profile eingerichtet werden,
- welche Person welche Funktion wahrnimmt,
- welche Zugriffsrechte eine Person erhlt und
- welche Konflikte bei der Vergabe von Zugriffsrechten aufgetreten sind.
Diese Konflikte knnen z. B. daraus resultieren, dass eine Person unverein-
bare Funktionen wahrnimmt oder daraus, dass abhngig vom IT-System
die Trennung bestimmter Zugriffsrechte nicht vorgenommen werden kann.
- Liegt eine aktuelle Dokumentation der vergebenen Zugriffsrechte vor?
- Werden beantragte Zugriffsrechte oder nderungen erteilter Zugriffsrechte
von den Verantwortlichen besttigt und geprft?
- Existiert ein geregeltes Verfahren fr den Entzug von Zugriffsrechten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Vorgehensweise bei der Funktionstrennung und der Rechtevergabe

wird am nachfolgenden Beispiel erlutert.
Die betrachtete IT-Anwendung sei ein Reisekosten-Abrechnungssystem. Die
relevanten Rume sind in nachfolgender Graphik erlutert. Das IT-System
besteht aus einem LAN, an dem neben der Bedienkonsole drei PCs als
Arbeitsplatzrechner angeschlossen sind.
Schritt 1: Aufgabenverteilung und Funktionstrennung

Folgende Funktionen sind fr das betrachtete Reisekosten-Abrechnungs-
system notwendig:
1. LAN-Administration
2. Revision
3. Datenerfassung
4. Sachbearbeitung mit Feststellung der rechnerischen Richtigkeit
5. Sachbearbeitung mit Feststellung der sachlichen Richtigkeit
6. Sachbearbeitung mit Anordnungsbefugnis
Folgende Funktionen sind aufgrund der Sachzwnge nicht miteinander verein-

bar:
- Funktion 1 und Funktion 2 (die Administration darf sich nicht selbst kon-
trollieren)
- Funktion 2 und Funktion 6 (der Anordnungsbefugte darf sich nicht selbst
kontrollieren)
- die Kombination der Funktionen 4 oder 5 mit 6 (das Vier-Augen-Prinzip
wre verletzt fr Zahlungsanweisungen)
Diese Funktionen werden durch folgende Personen wahrgenommen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hr. Mayer Fr. Hr. Mller Fr. Flei

Schmidt
1. LAN- X
Administration
2. Revision X
3. Datenerfassung X
4. Sachbearbeitung X
rechn.
sachl.
6. Anordnungsbefugn X
is
Tabelle 1: Zuordnung von Funktionen und Personen
Schritt 2: Vergabe von Zutrittsrechten
Nachfolgend wird der Schutzbedarf der einzelnen Rume begrndet und in der
Tabelle die Vergabe der Zutrittsrechte dokumentiert:
- Serverraum:
der unbefugte Zutritt zum Server muss verhindert werden, weil die Verfg-
barkeit Integritt und Vertraulichkeit der gesamten Anwendung von dieser
zentralen Komponente abhngig ist
- Belegarchiv:
fr die Rechnungslegung bedarf es der Aufbewahrung der Reisekostenab-
rechnungen. Es ist sicherzustellen, dass die Belege vollstndig und
unverndert aufbewahrt werden
- Bro 1:
in diesem Bro erfolgt die Dateneingabe in Verbindung mit der Fest-
stellung der rechnerischen Richtigkeit und die Feststellung der sachlichen
Richtigkeit. Fr die Gewhrleistung der Korrektheit dieser Vorgnge muss
verhindert werden, dass Unbefugte Zutritt zu den Arbeitsplatzrechnern
erhalten.
- Bro 2:
hier erfolgt die Anordnungsbefugnis fr die Auszahlung der Reisekosten
am APC. Dieser Vorgang darf nur von einer befugten Person vorgenom-
men werden. Unbefugten ist der Zutritt zu verwehren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Server- Beleg- Bro 1 Bro 2

raum archiv
1. LAN- X
Administration
2. Revision X X X X
3. Datenerfassung X
4. Sachbearbeitung X X
rechn.
5. Sachbearbeitung X X
sachl.
6. Anordnungs- X X X
befugnis
Tabelle 2: Zuordnung Funktionen zu Rumlichkeiten
Schritt 3: Vergabe von Zugangsberechtigungen

Aufgrund der Funktionen ergeben sich folgende Zugangsberechtigungen:
Betriebs- Anwen- Anwen- Anwen-

system dung Pro- dung dung
Server tokollaus- Datener- Belegbe-
wertung fassung arbeitung
1. LAN- X
Administration
2. Revision X X X
3. Datenerfassung X
rechn.
sachl.
6. Anordnungs- X
befugnis
Tabelle 3: Vergabe von Zugangsberechtigungen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schritt 4: Vergabe von Zugriffsrechten

Im folgenden werden die Zugriffsrechte, die eine Funktion zur Ausbung
bentigt, dargestellt. Es bezeichnen:
A = Recht zur Ausfhrung der Anwendung/Software
L = Leserecht auf Daten
S = Schreibrecht, d. h. Erzeugen von Daten
M = Recht zum Modifizieren von Daten
= Recht zum Lschen von Daten
U = Recht zum Unterschreiben von Zahlungsanweisungen
Betriebs- Protokoll- Anwen- Anwen-

system aus- dung dung
Server wertung Datener- Belegbe-
fassung arbeitung
1. LAN-Administration A,L,S,M,
2. Revision A,L A,L, A,L
3. Datenerfassung A,S
4. Sachbearbeitung A,L,M
rechn.
5. Sachbearbeitung A,L,M
sachl.
6. Anordnungsbefugnis A,L,U
Tabelle 4: Zugriffsrechte, die eine Funktion zur Ausfhrung bentigt
Eine solche Dokumentation erleichtert die Rechteverteilung. Angenommen,

dass Frau Schmidt den Arbeitgeber wechseln wrde und ihre Stelle neu
besetzt werden msste, so lsst sich anhand der obigen Tabellen einfach
feststellen, welche der ehemaligen Rechte Frau Schmidts zu lschen und fr
die neue Kraft einzurichten sind. Wenn die neue Kraft zustzlich
vertretungsweise die Funktion Sachbearbeitung mit Anordnungsbefugnis
bernehmen soll, so wird anhand der durchzufhrenden Rechteverteilung der
Konflikt offenbar, dass die neue Kraft im Vertretungsfall Manipulationen
unbemerkt durchfhren knnte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.9 Nutzungsverbot nicht freigegebener Hard- und

Software
Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, Leiter IT,
Es ist durchaus blich, dass Mitarbeiter eigene Hard- und Software wie bei-
spielsweise private Mobiltelefone, PDAs oder Kameras auch dienstlich oder
zumindest in den Dienstrumen verwenden. Da die Nutzung von zustzlicher
Hardware ber Standardschnittstellen wie USB und weitgehende Plug-and-
Play-Funktionalitt immer einfacher wird, muss deren Einsatz geregelt
werden. Die IT-Sicherheit kann dabei beispielsweise durch externe USB-
Speichermedien (z. B. Festplatten, Memory-Sticks) oder private PDAs beein-
trchtigt werden.
Es muss daher geregelt sein, wie Hard- und Software abgenommen, freige-
geben, installiert bzw. benutzt werden darf. Manahmen, die zu diesem
Zweck umgesetzt werden sollten, sind z. B.: M 2.216 Genehmigungsverfahren
fr IT-Komponenten, M 2.62 Software-Abnahme- und Freigabe-Verfahren
bzw. Kapitel 9.1 Standardsoftware und M 4.4 Geeigneter Umgang mit
Laufwerken fr Wechselmedien und externen Datenspeichern.
Das Einspielen bzw. Benutzen nicht freigegebener Hard- und Software muss
verboten und auerdem durch technische Mglichkeiten soweit mglich ver-
hindert werden. Bei den meisten Betriebssystemen kann dies durch Ein-
schrnkung der Benutzerumgebung erreicht werden. Damit soll verhindert
werden, dass Programme mit unerwnschten Auswirkungen eingebracht
werden. Zustzlich soll verhindert werden, dass das System ber den festge-
legten Funktionsumfang hinaus unkontrolliert genutzt wird. Es kann sinnvoll
sein (z. B. um Makro-Viren vorzubeugen), dieses Nutzungsverbot auch auf
das Einspielen privater Daten auszudehnen.
Bei Software ist zu dokumentieren, welche Versionen ausfhrbarer Dateien
freigegeben wurden (inklusive Erstellungsdatum und Dateigre). Die freige-
gebenen Programme sind regelmig auf Vernderungen zu berprfen.
Nutzungsverbote nicht freigegebener Hard- und Software sollten schriftlich
fixiert werden, alle Mitarbeiter sind darber zu unterrichten. Ausnahme-
regelungen sollten einen Erlaubnisvorbehalt vorsehen.
- Gibt es ein Genehmigungs- und Registrierverfahren fr Hard- und Soft-
ware?
- Sind Nutzungsverbote schriftlich fixiert?
- Sind alle Mitarbeiter ber Nutzungsverbote unterrichtet?
- Wird in regelmigen Abstnden an Nutzungsverbote erinnert?
- Welche Mglichkeiten bestehen, unautorisiert Software einzuspielen oder
zu nutzen?
- Welche Mglichkeiten bestehen an den einzelnen Rechnern, Software
selbstndig zu entwickeln?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gibt es Regelungen ber die Programmierung und die Weitergabe von

Makros aus leistungsfhigen Standardprodukten wie z. B. Textverarbei-
tung, Tabellenkalkulation und Datenbanken?
- Existieren Listen mit den freigegebenen Versionen ausfhrbarer Dateien,
die insbesondere Erstellungsdatum und Dateigre beinhalten?
- Wird regelmig berprft, ob die freigegebenen Versionen ausfhrbarer
Dateien verndert wurden?
- Besteht die Mglichkeit, das Einspielen von Software technisch zu ver-
hindern?
- Ist die Nutzung von externen Speichermedien aller Art (z. B. USB-
Memory-Sticks, Kameras, PDAs und Mobiltelefonen) geregelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.10 berprfung des Hard- und Software-Bestandes

IT-Sicherheitsmanagement, Vorgesetzte
Um Verste gegen das Verbot der Nutzung nicht freigegebener Hard- und
Software feststellen zu knnen, ist eine regelmige berprfung des Hard-
und Software-Bestandes notwendig. Ist die Zahl der IT-Systeme sehr gro,
kann eine stichprobenartige berprfung durchgefhrt werden. Die
Ergebnisse der berprfung sind zu dokumentieren, um auch
Wiederholungsflle feststellen zu knnen.
Wird bei der berprfung nicht genehmigte Hardware gefunden, muss dafr
gesorgt werden, dass die IT-Komponenten nicht weiter vorschriftswidrig
betrieben werden. Es muss zudem ermittelt werden, wer fr den Betrieb
verantwortlich ist, um geeignete Konsequenzen ergreifen zu knnen. Bei
konkreten Verdachtsfllen ist bei der Kontrolle der Hardware auf
Manipulationen und Zusatzgerte, die z. B. zur Aufzeichnung von
Tastaturanschlgen verwendet werden, zu achten.
Sollte bei der berprfung nicht freigegebene Software gefunden werden, so
ist die Entfernung zu veranlassen. Um diese berprfung durchfhren zu
knnen, muss der berprfenden Instanz die entsprechende Befugnis durch die
Unternehmens- bzw. Behrdenleitung verliehen werden. Zustzlich muss der
prfenden Instanz bekannt sein, welche Software auf welchem IT-System
freigegeben ist (Software-Bestandsverzeichnis).
Um bei der Vielzahl der blicherweise eingesetzten Software effizient ein
Software-Bestandsverzeichnis fhren zu knnen, sollte hierfr ein
entsprechendes Tool eingesetzt werden. Fr die typische Client-Server-
Umgebung sollte es netzfhig sein.
Vor der Festlegung einer Regelung zur berprfung des Hard- und Software-
Bestandes sollte der Betriebs- bzw. Personalrat hinzugezogen werden.
Fr solche IT-Systeme, die fr den Wirkbetrieb des IT-Verbunds nicht
erforderlich sind wie z. B. Testsysteme, kann anstelle einer regelmigen
berprfung eine anlassbezogene berprfung durchgefhrt werden.
Beispielsweise kann die Prfung auf solchen IT-Systemen immer dann
vorgenommen werden, wenn nderungen an der Konfiguration vorgenommen
werden oder wenn das IT-System nach lngerer Pause wieder in Betrieb
gesetzt wird. Voraussetzung ist jedoch, dass fr alle IT-Systeme die
Manahme M 2.9 Nutzungsverbot nicht freigegebener Hard- und Software in
Kraft ist.
- In welchem Turnus werden berprfungen des Hard- und Software-
Bestandes durchgefhrt?
- Sind Flle aufgetreten, dass unautorisierte Software genutzt wurde?
- Wie wird verfahren, wenn ein Versto festgestellt wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.11 Regelung des Passwortgebrauchs

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, IT-Benutzer
Werden in einem IT-System Passwrter zur Authentisierung verwendet, so ist
die Sicherheit der Zugangs- und Zugriffsrechteverwaltung des Systems ent-
scheidend davon abhngig, dass das Passwort korrekt gebraucht wird. Dafr
ist es empfehlenswert, eine Regelung zum Passwortgebrauch einzufhren und
den IT-Benutzer diesbezglich zu unterweisen.
Vorgaben fr die Passwortgestaltung mssen immer einen praktikablen praktikabler
Kompromiss
Kompromiss zwischen folgenden Sicherheitszielen darstellen:
1. Die Zeichenzusammensetzung des Passwortes muss so komplex sein, dass
es nicht leicht zu erraten ist.
2. Die Anzahl der mglichen Passwrter im vorgegebenen Schema muss so
gro sein, dass es nicht in kurzer Zeit durch einfaches Ausprobieren
ermittelt werden kann.
3. Das Passwort darf nicht zu kompliziert sein, damit der Besitzer mit
vertretbarem Aufwand in der Lage ist, es auswendig zu lernen.
Folgende Regeln zum Passwortgebrauch sollten deshalb beachtet werden: Regeln fr Benutzer
- Das Passwort darf nicht leicht zu erraten sein. Namen, Kfz-Kennzeichen,

Geburtsdatum usw. drfen deshalb nicht als Passwrter gewhlt werden.
- Innerhalb des Passwortes sollte mindestens ein Zeichen verwendet werden,
das kein Buchstabe ist (Sonderzeichen oder Zahl).
- Wenn fr das Passwort alphanumerische Zeichen gewhlt werden knnen,
sollte es mindestens 8 Zeichen lang sein.
- Wenn fr das Passwort nur Ziffern zur Verfgung stehen, sollte es Sperrung nach
Fehlversuchen
mindestens 6 Zeichen lang sein und das Authentisierungssystem sollte den
Zugang nach wenigen Fehlversuchen sperren (fr eine bestimmte
Zeitspanne oder dauerhaft).
- Es muss getestet werden, wie viele Stellen des Passwortes vom Rechner
wirklich berprft werden.
- Voreingestellte Passwrter (z. B. des Herstellers bei Auslieferung von
Systemen) mssen durch individuelle Passwrter ersetzt werden.
- Passwrter drfen nicht auf programmierbaren Funktionstasten gespeichert
werden.
- Das Passwort muss geheim gehalten werden und sollte nur dem Benutzer
persnlich bekannt sein.
- Das Passwort sollte allenfalls fr die Hinterlegung schriftlich fixiert Hinterlegung in
verschlossenem
werden, wobei es in diesem Fall in einem verschlossenen Umschlag sicher Umschlag
aufbewahrt werden muss. Wird es darber hinaus aufgeschrieben, ist das
Passwort zumindest so sicher wie eine Scheckkarte oder ein Geldschein
aufzubewahren (siehe M 2.22 Hinterlegen des Passwortes).
- Das Passwort muss regelmig gewechselt werden, z. B. alle 90 Tage.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ein Passwortwechsel ist durchzufhren, wenn das Passwort unautorisierten

Personen bekannt geworden ist.
- Alte Passwrter sollten nach einem Passwortwechsel nicht mehr gebraucht
werden.
- Die Eingabe des Passwortes sollte unbeobachtet stattfinden.
Falls IT-technisch mglich, sollten folgende Randbedingungen eingehalten Anforderungen an
IT-Systeme
werden:
- Die Wahl von Trivialpasswrtern (z. B. "BBBBBBBB", "123456") sollte
verhindert werden.
- Jeder Benutzer muss sein eigenes Passwort jederzeit ndern knnen.
- Fr die Erstanmeldung neuer Benutzer sollten Einmalpasswrter vergeben Einmalpasswrter
werden, also Passwrter, die nach einmaligem Gebrauch gewechselt
werden mssen. In Netzen, in denen Passwrter unverschlsselt bertragen
werden, empfiehlt sich die dauerhafte Verwendung von Einmalpasswrtern
(siehe M 5.34 Einsatz von Einmalpasswrtern).
- Nach dreifacher fehlerhafter Passworteingabe sollte eine Sperrung erfol-
gen, die nur vom Systemadministrator aufgehoben werden kann.
- Bei der Authentisierung in vernetzten Systemen sollten Passwrter selbst
im Intranet nicht unverschlsselt bertragen werden. Erfolgt die
Authentisierung ber ein ungesichertes Netz hinweg, so drfen Passwrter
keinesfalls unverschlsselt bertragen werden.
- Bei der Eingabe sollte das Passwort nicht auf dem Bildschirm angezeigt
werden.
- Die Passwrter mssen im System zugriffssicher gespeichert werden, z. B.
mittels Einweg-Verschlsselung (Hashfunktionen).
- Der Passwortwechsel sollte vom System regelmig initiiert werden.
- Die Wiederholung alter Passwrter beim Passwortwechsel sollte vom IT-
System verhindert werden (Passworthistorie).
- Sind die Benutzer ber den korrekten Umgang mit Passwrtern unterrichtet
worden?
- Wird die Passwort-Gte kontrolliert?
- Wird der Passwort-Wechsel erzwungen?
- Ist jeder Benutzer im Netz mit einem Passwort ausgestattet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.12 Betreuung und Beratung von IT-Benutzern

Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, Leiter IT
Der Einsatz von IT-Systemen erfordert eine umfassende Schulung der IT-
Benutzer. Neben der Schulung, die die IT-Benutzer in die Lage versetzt, die
eingesetzte Informationstechnik sachgerecht einzusetzen, bedarf es einer
Betreuung und Beratung der IT-Benutzer fr die im laufenden Betrieb auftre-
tenden Probleme. Diese Probleme knnen aus Hardware-Defekten oder
fehlerhafter Software-Installation resultieren, aber auch aus Bedienungs-
fehlern.
In greren Behrden bzw. Unternehmen kann es daher sinnvoll sein, eine
zentrale Stelle mit der Betreuung der IT-Benutzer zu beauftragen und diese
allen Mitarbeitern bekannt zu geben. Diese Notwendigkeit kann sich insbeson-
dere bei einer hohen Zahl dezentraler Systeme wie PCs als praktikabel erwei-
sen.
- An wen wendet sich ein IT-Benutzer in Problemfllen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.13 Ordnungsgeme Entsorgung von

schtzenswerten Betriebsmitteln
Verantwortlich fr Umsetzung: Leiter Haustechnik, Mitarbeiter
Betriebsmittel oder Sachmittel, die schtzenswerte Daten enthalten
(Druckerpapier, Disketten, Streamertapes, Magnetbnder, Festplatten, aber
auch spezielle Tonerkassetten, Kohlepapier oder Carbonbnder) und nicht
mehr gebraucht werden oder aufgrund eines Defektes ausgesondert werden
sollen, sind so zu entsorgen, dass keine Rckschlsse auf vorher gespeicherte
Daten mglich sind. Bei funktionstchtigen Datentrgern sollten die Daten
physikalisch gelscht werden. Nicht funktionierende oder nur einmal
beschreibbare Datentrger wie CD-ROMs mssen mechanisch zerstrt werden
(siehe M 2.167 Sicheres Lschen von Datentrgern).
Die Art der Entsorgung schutzbedrftigen Materials sollte in einer speziellen
Anordnung geregelt werden, entsprechende Entsorgungseinrichtungen sind
vorzuhalten (siehe auch DIN 32757).
Wird schutzbedrftiges Material vor der Entsorgung gesammelt, so ist die
Sammlung verschlossen zu halten und vor unberechtigtem Zugriff zu
schtzen.
Soweit im Unternehmen bzw. in der Behrde keine umweltgerechte und
sichere Entsorgung durchgefhrt werden kann, sind damit beauftragte Unter-
nehmen auf die Einhaltung erforderlicher IT-Sicherheitsmanahmen zu ver-
pflichten. Ein Mustervertrag ist als Hilfsmittel diesem Handbuch beigefgt.
- Werden in der genannten Regelung alle schutzbedrftigen Materialien
behandelt?
- Ist der Entsorgungsvorgang verlsslich?
- Werden die genannten Entsorgungsbestimmungen eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.14 Schlsselverwaltung
Verantwortlich fr Initiierung: Leiter Organisation, IT-
Verantwortlich fr Umsetzung: Leiter Haustechnik
Fr alle Schlssel des Gebudes (von Etagen, Fluren und Rumen) ist ein
Schlieplan zu fertigen. Die Herstellung, Aufbewahrung, Verwaltung und
Ausgabe von Schlsseln ist zentral zu regeln. Reserveschlssel sind vorzu-
halten und gesichert aufzubewahren. Das gleiche gilt auch fr alle Identifi-
kationsmittel wie Magnetstreifen- oder Chipkarten. Zu beachten bleibt:
- Ist eine Schlieanlage vorhanden, sind fr schutzbedrftige Bereiche
eigene Schliegruppen zu bilden, ggf. einzelne Rume aus der Schlie-
gruppe herauszunehmen und mit Einzelschlieung zu versehen.
- Nicht ausgegebene Schlssel und die Reserveschlssel sind gegen unbe-
fugten Zugriff geschtzt aufzubewahren.
- Die Ausgabe der Schlssel erfolgt gegen Quittung und ist zu dokumen-
tieren.
- Es sind Vorkehrungen zu treffen, wie bei Verlust einzelner Schlssel zu
reagieren ist (Meldung, Ersatz, Kostenerstattung, Austausch des Schlosses,
Austausch von Schliegruppen etc.).
- Bei Zustndigkeitsnderungen von Mitarbeitern sind deren Schlieberech-
tigungen zu prfen, Schlssel ggf. einzuziehen.
- Beim Ausscheiden von Mitarbeitern sind alle Schlssel einzuziehen
(Aufnahme der Schlsselverwaltung in den Laufzettel).
- Schlsser und Schlssel zu besonders schutzbedrftigen Bereichen (zu
denen nur sehr wenige Schlssel ausgegeben werden sollten) knnen bei
Bedarf getauscht werden, um so illegal nachgefertigten Schlsseln die
Funktion zu nehmen.
- Welche Regelungen gibt es zur Schlsselverwaltung?
- Werden diese Regelungen von den Mitarbeitern angenommen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.15 Brandschutzbegehungen
Verantwortlich fr Initiierung: Leiter Haustechnik , Leiter IT
Verantwortlich fr Umsetzung: Brandschutzbeauftragter
Bei der Errichtung und der Nutzung von Gebuden sind alle geltenden
Brandschutzvorschriften zu beachten. Diese werden durch DIN- und VDE-
Vorschriften festgeschrieben und durch Auflagen der Bauaufsicht ergnzt
(siehe auch M 1.6 Einhaltung von Brandschutzvorschriften).
Die Erfahrungen zeigen, dass nach Nutzungsbeginn im tglichen Betrieb diese
Regelungen immer nachlssiger gehandhabt werden - bis hin zur vlligen
Ignoranz. Einige Beispiele:
- Fluchtwege werden blockiert, z. B. durch Mbel und Papiervorrte.
- Brandabschnittstren bzw. Rauchschutztren werden durch Keile offen
gehalten.
- Zulssige Brandlasten werden durch anwachsende Kabelmengen oder
genderte Nutzungen berschritten.
- Brandabschottungen werden bei Arbeiten geffnet und/oder beschdigt
und nicht ordnungsgem wiederhergerichtet.
- Rauchmelder in der Nhe von "Raucherecken" werden bewusst auer
Funktion gesetzt.
Brandschutzbegehungen sollten ein- bis zweimal im Jahr angekndigt oder
unangekndigt erfolgen.
Da die Handlungsweise der Mitarbeiter in der Regel nicht vom bswilligen
Vorsatz, sondern von der betrieblichen Notwendigkeit oder Bequemlichkeit
bestimmt wird, kann es nicht Sinn einer Brandschutzbegehung sein, Tter zu
finden und zu bestrafen. Vielmehr sollten die vorgefundenen Mngel dazu
Anlass geben, die Zustnde sofort und ggf. auch deren Ursachen unverzglich
zu beheben.
- Werden Brandschutzbegehungen regelmig durchgefhrt und festgestellte
Mngel behoben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.16 Beaufsichtigung oder Begleitung von

Fremdpersonen
Verantwortlich fr Initiierung: Leiter Organisation
Fremde (Besucher, Handwerker, Wartungs- und Reinigungspersonal) sollten,
auer in Rumen, die ausdrcklich dafr vorgesehen sind, nicht unbeauf-
sichtigt sein (siehe auch M 2.6 Vergabe von Zutrittsberechtigungen). Wird es
erforderlich, einen Fremden allein im Bro zurckzulassen, sollte man einen
Kollegen ins Zimmer oder den Besucher zu einem Kollegen bitten.
Ist es nicht mglich, Fremdpersonen (z. B. Reinigungspersonal) stndig zu
begleiten oder zu beaufsichtigen, sollte zumindest der persnliche Arbeits-
bereich abgeschlossen werden: Schreibtisch, Schrank und PC (Schloss fr
Diskettenlaufwerk, Tastaturschloss). Siehe auch M 2.37 "Der aufgerumte
Arbeitsplatz".
Fr den huslichen Arbeitsplatz gilt, dass Familienmitglieder und Besucher
sich nur dann alleine im Arbeitsbereich aufhalten drfen, wenn alle Arbeits-
unterlagen verschlossen aufbewahrt sind und die IT ber einen aktivierten
Zugangsschutz gesichert ist.
Die Notwendigkeit dieser Manahme ist den Mitarbeitern zu erlutern und
ggf. in einer Dienstanweisung festzuhalten. Eine Dokumentation ber den
Aufenthalt von Fremdpersonen kann in einem Besucherbuch gefhrt werden.
- Werden die Mitarbeiter dazu angehalten, entsprechend zu handeln?
- Wie sieht die tatschliche Praxis im Hause aus?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.17 Zutrittsregelung und -kontrolle

Verantwortlich fr Initiierung: Leiter Organisation, Leiter Haustechnik
Verantwortlich fr Umsetzung: Leiter Haustechnik, Mitarbeiter, Planer
Der Zutritt zu schutzbedrftigen Gebudeteilen und Rumen ist zu regeln und
zu kontrollieren (siehe M 2.6 Vergabe von Zutrittsberechtigungen). Die
Manahmen reichen dabei von einer einfachen Schlsselvergabe bis zu auf-
wendigen Identifizierungssystemen mit Personenvereinzelung, wobei auch die
Nutzung eines mechanischen Schlssels nebst Schloss eine Zutrittsregelung
darstellt. Fr eine Zutrittsregelung und -kontrolle ist es erforderlich, dass
- der von der Regelung betroffene Bereich eindeutig bestimmt wird,
- die Zahl der zutrittsberechtigten Personen auf ein Mindestma reduziert
wird; diese Personen sollen gegenseitig ihre Berechtigung kennen, um
Unberechtigte als solche erkennen zu knnen,
- der Zutritt anderer Personen (Besucher) erst nach vorheriger Prfung der
Notwendigkeit erfolgt,
- erteilte Zutrittsberechtigungen dokumentiert werden.
Die Vergabe von Rechten allein reicht nicht aus, wenn deren Einhaltung bzw.
berschreitung nicht kontrolliert wird. Die Ausgestaltung von Kontroll-
mechanismen sollte nach dem Grundsatz erfolgen, dass einfache und prakti-
kable Lsungen oft ebenso effizient sind wie aufwendige Technik. Beispiele
hierfr sind:
- Information und Sensibilisierung der Berechtigten,
- Bekanntgabe von Berechtigungsnderungen,
- sichtbares Tragen von Hausausweisen, ggf. Vergabe von Besucheraus-
weisen,
- Begleitung von Besuchern,
- Verhaltensregelungen bei erkannter Berechtigungsberschreitung und
- Einschrnkung des ungehinderten Zutritts fr nicht Zutrittsberechtigte
(z. B. Tr mit Blindknauf, Schloss fr Berechtigte mit Schlssel, Klingel
fr Besucher).
Bei der Zutrittskontrolle werden verschiedene bauliche, organisatorische und
personelle Manahmen bentigt. Deren Zusammenwirken sollte in einem
Zutrittskontrollkonzept geregelt sein, das die generellen Richtlinien fr den
Perimeter-, Gebude- und Gerteschutz festlegt. Dazu gehren:
- Festlegung der Sicherheitszonen
Zu schtzende Bereiche knnen etwa Grundstcke, Gebude, Serverrume,
Rume mit Peripheriegerten, Archive, Kommunikationseinrichtungen und
die Haustechnik sein. Da diese Bereiche hufig sehr unterschiedliche
Sicherheitsanforderungen aufweisen, kann es sinnvoll sein, diese in
verschiedene Sicherheitszonen aufzuteilen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Vergabe von Zutrittsberechtigungen (siehe M 2.6 Vergabe von

Zutrittsberechtigungen)
- Bestimmung eines Verantwortlichen fr Zutrittskontrolle
Dieser vergibt die Zutrittsberechtigungen an die einzelnen Personen
entsprechend den in der Sicherheitspolitik festgelegten Grundstzen.
- Definition von Zeitabhngigkeiten
Es ist zu klren, ob zeitliche Beschrnkungen der Zutrittsrechte erforder-
lich sind. Solche Zeitabhngigkeiten knnen etwa sein: Zutritt nur whrend
der Arbeitszeit, Zutritt einmal tglich oder befristeter Zutritt bis zu einem
fixierten Datum.
- Festlegung der Beweissicherung
Hier ist zu bestimmen, welche Daten bei Zutritt zu und Verlassen von
einem geschtzten Bereich protokolliert werden. Dabei bedarf es einer
sorgfltigen Abwgung zwischen den Sicherheitsinteressen des System-
betreibers und den Schutzinteressen der Privatsphre des Einzelnen.
- Behandlung von Ausnahmesituationen
Es ist u. a. sicherzustellen, dass im Brandfall die Mitarbeiter schnellst-
mglich die gefhrdeten Zonen verlassen knnen.
Ergnzend kann der Einbau von Ausweislesern verschiedenster Qualitten,
von Schleusen und Vereinzelungseinrichtungen sinnvoll sein. Zur Schlssel-
verwaltung siehe M 2.14 Schlsselverwaltung.
Im Betrieb eines Rechenzentrums ist die Absicherung der Kerneinheiten durch
starke Zutrittskontrollmechanismen zwingend erforderlich. Als Identi-
fikations- bzw. Authentikationskennzeichen kommen dabei Besitz, Wissen
und biometrische Merkmale in Frage. Ein starker Zutrittskontrollmechanismus
muss mindestens zwei dieser drei Kennzeichen bercksichtigen. Aus heutiger
Sicht sind biometrische Verfahren als alleinige Zutrittskontrolle nicht zu
empfehlen.
Die Terminals zur Zutrittskontrolle mssen gegen Manipulationen geschtzt
werden. Dafr mssen diese so angebracht werden, dass Vertraulichkeit bei
der Eingabe von Daten gewhrleistet ist. Auerdem sollten alle zur Daten-
eingabe erforderlichen Einheiten in einem Gert kombiniert sein, also
beispielweise eine Tastatur zur PIN-Eingabe.
Befinden sich nicht alle Einheiten in einem Gert, muss die Datenbertragung
zwischen diesen verschlsselt erfolgen. Werden also z. B. berhrungslose
Ausweisleser eingesetzt, so muss die Datenbertragung zwischen Karte und
Leser verschlsselt erfolgen.
- Existiert ein Konzept fr die Zutrittskontrolle?
- Werden die Zutrittskontroll-Manahmen regelmig auf ihre Wirksamkeit
berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.18 Kontrollgnge
Verantwortlich fr Initiierung: Haustechnik, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: Haustechnik, IT-Sicherheitsmanagement
Eine Manahme kann nur so gut wirken, wie sie auch tatschlich umgesetzt
wird. Kontrollgnge bieten das einfachste Mittel, die Umsetzung von
Manahmen und die Einhaltung von Auflagen und Anweisungen zu ber-
prfen.
Die Kontrollgnge sollen nicht dem Finden von Ttern dienen, um diese zu
bestrafen. Sinn der Kontrollen soll es in erster Linie sein, erkannte Nach-
lssigkeiten mglichst sofort zu beheben (Fenster zu schlieen, Unterlagen in
Aufbewahrung zu nehmen etc.). In zweiter Linie knnen Ursachen fr diese
Nachlssigkeiten erkannt und evtl. in der Zukunft vermieden werden.
Die Kontrollgnge sollten durchaus auch whrend der Dienstzeit erfolgen und
zur Information der Mitarbeiter ber das Wie und Warum von Regelungen
genutzt werden. So werden sie von allen Beteiligten eher als Hilfe denn als
Gngelung angesehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.19 Neutrale Dokumentation in den Verteilern

Verantwortlich fr Umsetzung: Leiter Haustechnik, Netzplaner
In jedem Verteiler sollte sich eine Dokumentation befinden, die den derzei-
tigen Stand von Rangierungen und Leitungsbelegungen wiedergibt. Diese
Dokumentation ist mglichst neutral zu halten. Nur bestehende und genutzte
Verbindungen sind darin aufzufhren. Es sollen, soweit nicht ausdrcklich
vorgeschrieben (z. B. fr Brandmeldeleitungen) keine Hinweise auf die
Nutzungsart der Leitungen gegeben werden. Leitungs-, Verteiler-, und Raum-
nummern reichen in vielen Fllen aus. Alle weitergehenden Informationen
sind in einer Revisions-Dokumentation aufzufhren.
- Wie wird sichergestellt, dass die Dokumentation immer aktuell ist?
- Wie wird sichergestellt, dass keine unzulssigen Informationen in dieser
Dokumentation enthalten sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.20 Kontrolle bestehender Verbindungen

Verantwortlich fr Umsetzung: Leiter Haustechnik, Netzplaner
Alle Verteiler und Zugdosen sind einer (zumindest stichprobenartigen) Sicht-
prfung zu unterziehen. Dabei ist auf folgende Punkte zu achten:
- Spuren von gewaltsamen ffnungsversuchen an verschlossenen Verteilern,
- Aktualitt der im Verteiler befindlichen Dokumentation,
- bereinstimmung der tatschlichen Beschaltungen und Rangierungen mit
der Dokumentation,
- Unversehrtheit der Kurzschlsse und Erdungen nicht bentigter Leitungen
und
- unzulssige Einbauten/Vernderungen.
Neben der reinen Sichtkontrolle kann zustzlich eine funktionale Kontrolle
durchgefhrt werden. Dabei werden bestehende Verbindungen auf ihre Not-
wendigkeit und die Einhaltung technischer Werte hin geprft. In zwei Fllen
ist diese Prfung anzuraten:
- bei Verbindungen, die sehr selten genutzt und bei denen Manipulationen
nicht sofort erkannt werden,
- bei Verbindungen, auf denen hufig und regelmig schtzenswerte
Informationen bertragen werden.
- In welchem Turnus werden bestehende Verbindungen kontrolliert?
- Wie werden festgestellte Unregelmigkeiten dokumentiert und verfolgt?
- Wem sind welche festgestellten Unregelmigkeiten zu melden?
- Wer fhrt die Beseitigung von Unregelmigkeiten durch und wer
kontrolliert diese Arbeiten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.21 Rauchverbot
In Rumen mit IT oder Datentrgern (Serverraum, Datentrgerarchiv, aber
auch Belegarchiv), in denen Brnde oder Verschmutzungen zu hohen Schden
fhren knnen, sollte ein Rauchverbot erlassen werden. Dieses Rauchverbot
dient gleicherweise dem vorbeugenden Brandschutz wie der Betriebssicherheit
von IT mit mechanischen Funktionseinheiten.
- Wird das Rauchverbot in schutzbedrftigen Rumen eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.22 Hinterlegen des Passwortes

Ist der Zugriff auf ein IT-System durch ein Passwort geschtzt, so mssen
Vorkehrungen getroffen werden, die bei Abwesenheit eines Mitarbeiters, z. B.
im Urlaubs- oder Krankheitsfall, seinem Vertreter den Zugriff auf das IT-
System ermglichen.
Hierfr gibt es verschiedene Mglichkeiten, die von den benutzten IT-
Systemen bzw. IT-Anwendungen und von den IT-Sicherheitsrichtlinien der
jeweiligen Organisation abhngen. So kann z. B. das Passwort an einer
geeigneten Stelle hinterlegt werden. Bei typischen Mehrbenutzersystemen
kann auch der Administrator die bentigten Benutzerrechte freigeben oder das
Passwort auf einen neuen Wert setzen. Bei vielen IT-Systemen bzw. IT-
Anwendungen knnen aber Gruppen eingerichtet werden, so dass die
eingetragenen Vertreter im Abwesenheitsfall Zugriff auf das System haben.
Alle genannten Lsungen haben verschiedene Vor-, aber auch Nachteile, so
dass genau abgewogen werden muss, welche Lsung die in der jeweiligen
Situation am geeignetesten ist.
Die folgenden Beispiele sollen dies aufzeigen:
Die Buchhalterin Frau Mller arbeitet an einem Windows-PC, der als Client in
einem LAN angeschlossen ist. Um fr den Vertretungsfall alle potentiellen
Problembereiche abzudecken, wurden ihre Ttigkeitsbereiche mit ihr
durchgegangen und Lsungen entwickelt.
- Sie ist fr die Bearbeitung aller Vorgnge mit den Partnerfirmen A-K Gruppen-
Berechtigungen
zustndig. Die zu bearbeitenden Daten befinden sich in einer Datenbank
auf dem Server PF1. Im Vertretungsfall knnen ihre Kollegen Schmidt und
Eifrig unter ihren eigenen Benutzer-Kennungen diese Daten bearbeiten, da
sie die entsprechenden Berechtigungen in der Datenbank haben.
- Einige von ihr erstellte Dokumente befinden sich auf ihrem PC. Es wurde Arbeitsergebnisse
gehren auf den Server
eine Vereinbarung getroffen, dass sie alle fr den Betrieb wichtigen
Dateien in Projektverzeichnisse auf den Server einstellt. Falls im
Vertretungsfall ein Zugriff notwendig wird, kann der Administrator diesen
ermglichen. Dies muss schriftlich dokumentiert werden. Frau Mller
erhlt darber anschlieend eine E-Mail.
- Viele von Frau Mller betreute Firmen schicken Informationen per E-Mail.
Da das genutzte E-Mail-System es technisch nicht zulsst, dass
Vertretungsregelungen auf dem Weg von Zugriffsberechtigungen
eingefhrt werden, erhlt der Vertreter Herr Schmidt das Passwort fr
ihren E-Mail-Zugang. Dadurch kann er bei ihrer Abwesenheit eingehende
E-Mails zgig beantworten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Einige finanzrelevante Vorgnge mssen mit einer digitalen Signatur

autorisiert werden. Allen Mitarbeitern sind dafr persnliche
kryptographische Schlssel auf Chipkarten ausgehndigt worden, die nicht
weitergegeben werden drfen. Im Vertretungsfall unterzeichnet ihr
Vertreter mit seiner digitalen Signatur.
Eine Hinterlegung von Passwrtern ist immer mit einem groen Passwort-Hinterlegung
muss durchdacht sein
organisatorischen Aufwand verbunden: Bei der Passwort-Hinterlegung sind
die bentigten aktuellen Passwrter durch jeden Mitarbeiter an einer
geeigneten Stelle (z. B. im Sekretariat in einem Safe in einem geschlossenen
Umschlag) zu hinterlegen. Bei jeder nderung eines der Passwrter ist dieses
zu aktualisieren. Es darf kein Passwort dabei vergessen werden. (Manchmal
werden fr den Zugriff auf eine Anwendung auf einem Rechner bis zu fnf
verschiedene Passwrter bentigt.) Es darf nicht mglich sein, dass Unbefugte
auf die hinterlegten Passwrter Zugriff nehmen. Wird es notwendig, eines der
hinterlegten Passwrter zu nutzen, so sollte dies nach dem Vier-Augen-
Prinzip, d. h. von zwei Personen gleichzeitig, geschehen. Jeder Zugriff darauf
muss dokumentiert werden.
Passwrter sollten mglichst nur dann hinterlegt werden, wenn es keine
andere (technische) Lsung gibt. Dabei ist immer zu beachten, dass die
Hinterlegung von Passwrtern einen falschen Signalcharakter fr den sicheren
Umgang mit Passwrtern vermittelt. Passwrter drfen nicht unter Tastaturen
oder hnlichen Orten "hinterlegt" und auch nicht unter Kollegen
weitergegeben werden, nur weil es einfacher ist, als den Administrator um die
Vergabe einer notwendigen Zugriffsberechtigung zu bitten.
Passwrter sollten aber immer dann sicher hinterlegt werden, wenn diese die
einzige Mglichkeit sind, auf das IT-System oder die IT-Anwendung Zugriff
zu nehmen. Dies ist z. B. meistens bei Administrator-Zugngen oder
Einzelplatz-Systemen der Fall.
Es sollte daher eine Regelung geben, in der beschrieben ist, welche Art von
Passwrtern hinterlegt werden sollten und welche Rahmenbedingungen dafr
geschaffen werden mssen.
Bei einem Telearbeiter ist sicherzustellen, dass dessen Passwrter fr die IT- Telearbeiter
Systeme am huslichen Arbeitsplatz auch in der Institution hinterlegt werden,
damit im Notfall sein Vertreter auf die im Telearbeitsrechner gespeicherten
Daten zugreifen kann.
Bei allen von Administratoren betreuten Systemen, insbesondere bei ver- Administratoren
netzten Systemen, ist durch regelmige berprfung sicherzustellen, dass
das aktuelle Systemadministrator-Passwort hinterlegt ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Existiert eine Regelung zur Hinterlegung von Passwrtern?
- Sind die hinterlegten Passwrter vollstndig und aktuell?
- Ist die ordnungsgeme Verwendung eines hinterlegten Passwortes gere-
gelt?
- Wird anhand der Aktualisierungen der hinterlegten Passwrter die
Wechselsystematik kontrolliert?
- Wurde berprft, ob es Alternativen zur Passwort-Hinterlegung gibt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.23 Herausgabe einer PC-Richtlinie

Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, IT-Sicher-
heitsmanagement, Leiter IT
Verantwortlich fr Umsetzung: Leiter IT, IT-Benutzer,
Um einen sicheren und ordnungsgemen Einsatz von Personalcomputern in
greren Unternehmen bzw. Behrden zu frdern, sollte eine PC-Richtlinie
erstellt werden, in der verbindlich vorgeschrieben wird, welche Randbedin-
gungen eingehalten werden mssen und welche IT-Sicherheitsmanahmen zu
ergreifen sind. Diese PC-Richtlinie soll zumindest den Einsatz von unver-
netzten PCs regeln; werden PCs vernetzt betrieben oder als intelligente Ter-
minals genutzt, ist die Richtlinie um diese Punkte zu erweitern. Im folgenden
soll grob umrissen werden, welche Inhalte fr eine solche PC-Richtlinie sinn-
voll sind.
Mglicher inhaltlicher Aufbau einer PC-Richtlinie:
- Zielsetzung und Begriffsdefinitionen
Dieser erste Teil der PC-Richtlinie dient dazu, die PC-Anwender fr IT-Si-
cherheit zu sensibilisieren und zu motivieren. Gleichzeitig werden die fr
das gemeinsame Verstndnis notwendigen Begriffe definiert, wie z. B. PC,
Anwender, Benutzer, schutzbedrftige Objekte.
- Geltungsbereich
In diesem Teil muss verbindlich festgelegt werden, fr welche Teile des
Unternehmens bzw. der Behrde die PC-Richtlinie gilt.
- Rechtsvorschriften und interne Regelungen
Hier wird dargestellt, welche Rechtsvorschriften, z. B. das Bundesdaten-
schutzgesetz und das Urheberrechtsgesetz, einzuhalten sind. Darber hin-
aus kann diese Stelle genutzt werden, um alle relevanten betriebsinternen
Regelungen aufzufhren.
- Verantwortungsverteilung
In diesem Teil wird definiert, welcher Funktionstrger im Zusammenhang
mit dem PC-Einsatz welche Verantwortung tragen muss. Dabei sind insbe-
sondere die Funktionen IT-Benutzer, Vorgesetzte, Revisionsbeauftragter,
Datenschutzbeauftragter und IT-Sicherheitsmanagement zu unterscheiden.
- Umzusetzende und einzuhaltende IT-Sicherheitsmanahmen
Im letzten Teil der PC-Richtlinie ist festzulegen, welche IT-Sicherheits-
manahmen vom IT-Benutzer einzuhalten bzw. umzusetzen sind. Es kann
je nach Schutzbedarf auch ber die IT-Grundschutz-Manahmen hinaus-
gehen.
Sind Telearbeiter im Unternehmen bzw. in der Behrde beschftigt, sollte die
PC-Richtlinie um die Telearbeitsplatz-spezifischen Regelungen ergnzt wer-
den. Vgl. dazu Kapitel 9.3.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Existiert eine PC-Richtlinie?
- Wie wird die Einhaltung der PC-Richtlinie berprft?
- Mssen die Inhalte, insbesondere die IT-Sicherheitsmanahmen, aktuali-
siert werden?
- Besitzt jeder PC-Benutzer ein Exemplar dieser PC-Richtlinie?
- Ist die PC-Richtlinie Inhalt der Schulungen zu IT-Sicherheitsmanahmen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.24 Einfhrung eines PC-Checkheftes

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Leiter IT
Um die durchgefhrten IT-Sicherheitsmanahmen am PC zu dokumentieren,
bietet es sich an, ein PC-Checkheft einzufhren, in dem der PC-Nutzer folgen-
des dokumentieren kann:
- Name des PC-Benutzers,
- Aufstellungsort des PC,
- Beschreibung der Konfiguration,
- Zugangsmittel,
- eingesetzte Hard- und Software,
- planmige Zeitpunkte fr die Datensicherungen,
- durchgefhrte Wartungen und Reparaturen,
- durchgefhrte Computer-Viren-Kontrollen,
- Zeitpunkt von Passwort-nderungen,
- zur Verfgung stehendes Zubehr,
- durchgefhrte Revisionen,
- Ansprechpartner fr Problemflle und
- Zeitpunkte der durchgefhrten Datensicherungen.
Ein Muster eines solchen PC-Checkheftes ist der CD-ROM zum Handbuch
beigefgt.
Wird das Fhren eines solchen PC-Checkheftes angeordnet, so werden Kon-
trollttigkeiten entschieden erleichtert, da die Dokumentation aller durchge-
fhrten PC-relevanten nderungen und IT-Sicherheitsmanahmen aus diesem
PC-Checkheft hervorgehen. Auerdem untersttzt das Fhren dieses Heftes
fr den PC-Benutzer eine notwendige Selbstkontrolle, damit er regelmig
Datensicherungen, Passwort-nderungen und Viren-Checks durchfhrt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.25 Dokumentation der Systemkonfiguration

Planung, Steuerung, Kontrolle und Notfallvorsorge des IT-Einsatzes basieren
auf einer aktuellen Dokumentation des vorhandenen IT-Systems. Nur eine
aktuelle Dokumentation der Systemkonfiguration ermglicht im Notfall einen
geordneten Wiederanlauf des IT-Systems.
Bei einem Netzbetrieb ist die physikalische Netzstruktur (vgl. M 5.4 physikalische und
logische Netzkonfi-
Dokumentation und Kennzeichnung der Verkabelung) und die logische guration
Netzkonfiguration zu dokumentieren. Dazu gehren auch die Zugriffsrechte
der einzelnen Benutzer (siehe M 2.31 Dokumentation der zugelassenen
Benutzer und Rechteprofile) und der Stand der Datensicherung. Weiterhin sind
die eingesetzten Applikationen und deren Konfiguration sowie die
Dateistrukturen auf allen IT-Systemen zu dokumentieren.
Dabei ist auf Aktualitt und Verstndlichkeit der Dokumentation zu achten, Verfgbarkeit der
Dokumentation
damit auch ein Vertreter die Administration jederzeit weiterfhren kann. Die
System-Dokumentation ist so aufzubewahren, dass sie im Bedarfsfall jederzeit
verfgbar ist. Wenn sie in elektronischer Form gefhrt wird, sollte sie ent-
weder regelmig ausgedruckt oder auf einem transportablen Datentrger
gespeichert werden. Der Zugriff auf die Dokumentation ist auf die zustndigen
Administratoren zu beschrnken.
In der System-Dokumentation sollten alle Schritte dokumentiert sein, die beim Vorgehensweise zum
Herauf- bzw. Herunter-
Herauf- bzw. Herunterfahren von IT-Systemen zu beachten sind. Dies ist fahren
insbesondere bei vernetzten IT-Systemen wichtig. Hier muss z. B. hufig eine
bestimmte Reihenfolge beim Mounten von Laufwerken oder Starten von
Netzdiensten eingehalten werden.
- Ist die vorhandene Dokumentation aktuell?
- Kann aufgrund der Dokumentation die Administration weitergefhrt
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.26 Ernennung eines Administrators und eines

Vertreters
Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement, TK-
Anlagen-Verantwortlicher
Verantwortlich fr Umsetzung: -
Um einen geordneten Betrieb von IT-Systemen zu ermglichen, sind fr alle
IT-Systeme und Netze Administratoren zu bestimmen. Ihnen obliegt neben
allgemeinen Administrationsarbeiten insbesondere die Benutzerverwaltung
einschlielich der Verwaltung der Zugriffsrechte. Zustzlich sind sie fr die
Sicherheitsbelange aller von ihnen betreuten IT-Systeme zustndig.
Bei greren Behrden bzw. Unternehmen mit einer Vielzahl verschiedener berschneidungen und
Lcken in der Aufgaben-
IT-Systeme und Teilnetzen muss auerdem sichergestellt sein, dass die Auf- verteilung vermeiden
gaben zwischen den verschiedenen Administratoren so verteilt sind, dass es zu
keinen Zustndigkeitsproblemen kommt, also weder zu berschneidungen
noch zu Lcken in der Aufgabenverteilung. Darber hinaus sollte die Kom-
munikation zwischen den verschiedenen Administratoren mglichst reibungs-
los ablaufen. Hierzu knnen z. B. regelmige Administratoren-Treffen
durchgefhrt werden, bei denen typische Probleme und Lsungsmglichkeiten
bei der tglichen Arbeit thematisiert werden.
Beim Einsatz von Protokollierung sollte auf die Rollentrennung von Admini- Rollentrennung
zwischen Administration
stration und Revision geachtet werden. Hier ist zu berprfen, inwieweit die und Revision
IT-Systeme dies untersttzen.
Um bei Verhinderung eines Administrators die Funktionen weiter aufrecht- separate Administra-
torkennung fr den
zuerhalten, ist ein Vertreter zu benennen. Hierbei ist darauf zu achten, dass Vertreter
dieser eine eigene Administratorkennung erhlt (siehe auch M 2.38 Aufteilung
der Administrationsttigkeiten). Auf keinen Fall darf aus Bequemlichkeit im
Vertretungsfall einfach das Passwort weitergegeben werden.
Fr die bernahme von Administrationsaufgaben muss gewhrleistet sein,
dass jedem Administrator und ebenso den Vertretern fr eine sorgfltige Auf-
gabenerfllung auch die hierfr erforderliche Zeit zur Verfgung steht.
Hierbei muss auch bercksichtigt werden, dass Aus- und Fortbildungs-
manahmen erforderlich sind.
Die spezifischen Administrationsttigkeiten beim Einsatz von z/OS-Systemen z/OS-spezifische
Administrations-
werden in M 2.295 Systemverwaltung von z/OS-Systemen erlutert. aufgaben
- Wurden alle Administratoren und Vertreter ausreichend geschult?
- Wurden Zustndigkeiten fr die Administration gendert und die notwen-
digen Schulungsmanahmen eingeleitet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.27 Verzicht auf Fernwartung der TK-Anlage

Der Verzicht auf Fernwartung ist eine wirkungsvolle Manahme, um Externe
an Manipulationen an der TK-Anlagenkonfiguration zu hindern. Fr Einzel-
anlagen und kleine Anlagenverbunde mit geringen rumlichen Entfernungen
zwischen den einzelnen Verbundmitgliedern kann dies auch aus kono-
mischen Grnden sinnvoll sein.
Vorteil: Im Gegensatz zu allen anderen in Kapitel 8.1 TK-Anlage aufge-
fhrten Manahmen kann hierdurch garantiert werden, dass auch bei direktem
Zugriff auf die Leitungen der Telekom keine Zugriffsmglichkeit auf den
Wartungseingang der Anlage mglich ist. Eine hnliche Sicherheit wre sonst
nur unter Zuhilfenahme von Kryptomitteln erreichbar.
Nachteil: Alle Wartungsarbeiten mssen direkt an der Anlage durchgefhrt
werden. Ohne zustzliche Manahmen, z. B. Verlagerung des Wartungs-PCs
in den Nachbarraum, hat das Wartungspersonal auch immer Zutritt zur TK-
Anlage. Oft werden die Remote-Schnittstellen nicht nur fr den Zweck der
Fernwartung genutzt. ber dieselben Schnittstellen werden teilweise auch
Fernsignalisierungen gefhrt, die fr den Betrieb eines TK-Netzes notwendig
sind. In solchen Fllen wre mit dem Verzicht auf Fernwartung auch ein
Verzicht auf ein zentrales Netzmanagement verbunden. Soll eine Remote-
Schnittstelle nur fr Fernsignalisierungszwecke via Modem benutzt werden,
so sollte dieses Modem so konfiguriert werden, dass keine Rufe entgegen-
genommen werden.
- Welche Grnde sprechen fr und welche gegen den Verzicht der Fern-
wartung?
- Wurde die Entscheidung ber die Fernwartung herbeigefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.28 Bereitstellung externer TK-Beratungskapazitt

Um in schwierigen Fllen schnell auf fachkundige Hilfe zurckgreifen zu
knnen, sollte schon beim Kauf bzw. der Miete einer TK-Anlage an die
Bereitstellung entsprechender Beratungsdienstleistung gedacht werden.
Wichtig hierbei ist, dass in einer Notfallsituation die Untersttzung schnell
erfolgen kann, da der Ausfall einer TK-Anlage die Handlungsfhigkeit einer
gesamten Institution erheblich beeintrchtigen und ggf. nur fr kurze Zeit
toleriert werden kann.
- Wie lange kann auf die TK-Anlage verzichtet werden?
- In welcher Zeit kann Untersttzung seitens des Herstellers in Anspruch
genommen werden?
- Welche Zeit wird fr einen kompletten "Restart" der Anlage auf Basis der
Datensicherungsbestnde bentigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.29 Bedienungsanleitung der TK-Anlage fr die

Benutzer
Dem Benutzer der TK-Anlage sind die notwendigen Unterlagen zur Bedie-
nung seiner Endgerte (z. B. Bedienungsanleitung fr das Telefon) zur Verf-
gung zu stellen. Neben der normalen Bedienung seines Telefons sollte der
Benutzer vor allem in der Lage sein, etwaige Warnanzeigen (LEDs oder
Piktogramme im Display) und -tne zu interpretieren (siehe M 3.12
Information aller Mitarbeiter ber mgliche TK-Warnanzeigen, -symbole und
-tne).
- Liegen an allen Endgerten die richtigen Bedienungsanleitungen vor?
- Kann der Benutzer die ihm zur Verfgung stehenden Leistungsmerkmale
richtig anwenden?
- Kennt der Benutzer die Warnanzeigen und -tne?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.30 Regelung fr die Einrichtung von Benutzern /

Benutzergruppen
Regelungen fr die Einrichtung von Benutzern / Benutzergruppen bilden die
Voraussetzung fr eine angemessene Vergabe von Zugriffsrechten und fr die
Sicherstellung eines geordneten und berwachbaren Betriebsablaufs.
Es sollte ein Formblatt existieren, um von jedem Benutzer bzw. fr jede
Benutzergruppe zunchst die erforderlichen Daten abzufragen:
- Name, Vorname,
- Vorschlag fr die Benutzer- bzw. Gruppenkennung, wenn diese nicht
durch Konventionen vorgegeben sind,
- Organisationseinheit,
- Erreichbarkeit (z. B. Telefon, Raum),
- ggf. Projekt,
- ggf. Angaben ber die geplante Ttigkeit im System und die dazu erfor-
derlichen Rechte sowie die Dauer der Ttigkeit,
- ggf. Restriktionen auf Zeiten, Endgerte, Plattenvolumen, Zugriffsberech-
tigungen (fr bestimmte Verzeichnisse, Remote-Zugriffe, etc.), einge-
schrnkte Benutzerumgebung,
- ggf. Zustimmung von Vorgesetzten.
Falls Zugriffsberechtigungen vergeben werden, die ber den Standard hinaus-
gehen, sollte dies begrndet werden. Dieses kann auch in elektronischer Form
erfolgen durch ein spezielles Login, dessen Name und Passwort den einzurich-
tenden Benutzern bekanntgegeben wird. Dort wird ein entsprechendes
Programm durchlaufen, das mit einem Logout endet. Die erfassten Daten
knnen zur Vorlage beim Vorgesetzten ausgedruckt werden. Ein Passwort,
das einem neuen Benutzer fr die erstmalige Systemnutzung mitgeteilt wird,
muss danach gewechselt werden. Dies sollte vom System initiiert werden.
Es sollte eine begrenzte Anzahl von Rechteprofilen festgelegt werden. Ein
neuer Benutzer wird dann einem solchen Profil zugeordnet und erhlt damit
genau die fr seine Ttigkeit erforderlichen Rechte. Dabei sind die system-
spezifischen Mglichkeiten bei der Einrichtung von Benutzern und Gruppen
zu beachten. Es ist sinnvoll, Namenskonventionen fr die Benutzer- und
Gruppennamen festzulegen (z. B. Benutzer-ID = Krzel Organisationseinheit
|| lfd. Nummer).
Die Zugriffsberechtigung fr Dateien ist auf Benutzer bzw. Gruppen mit
berechtigtem Interesse zu beschrnken. Wenn mehrere Personen auf eine
Datei zugreifen mssen, soll fr diese eine Gruppe eingerichtet werden. In der
Regel muss jedem Benutzer eine eigene Benutzer-Kennung zugeordnet sein,
es drfen nicht mehrere Benutzer unter derselben Kennung arbeiten. Fr jeden
Benutzer muss ein eindeutiges Heimatverzeichnis angelegt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr die Einrichtungsarbeiten im System sollte eine administrative Rolle spezielle Logins fr die
geschaffen werden: Die Einrichtung sollte mit Hilfe eines speziellen Logins, Benutzerverwaltung
unter dem ein entsprechendes Programm oder Shellskript gestartet wird, erfol-
gen. Die zustndigen Administratoren knnen Benutzer bzw. Benutzergrup-
pen somit nur auf definierte Weise einrichten, und es ist nicht erforderlich,
ihnen Rechte fr andere Administrationsaufgaben zu geben.
Diese Manahme wird unter Unix ergnzt durch folgende Manahmen: Besondere Unix-
Manahmen
- M 4.13 Sorgfltige Vergabe von IDs
- M 4.19 Restriktive Attributvergabe bei Unix-Systemdateien und
-verzeichnissen
- M 4.20 Restriktive Attributvergabe bei Unix-Benutzerdateien und
-verzeichnissen
Diese Manahme wird unter z/OS ergnzt durch folgende Manahmen: Besondere z/OS-
Manahmen
- M 2.289 Einsatz restriktiver z/OS-Kennungen
- M 2.297 Deinstallation von z/OS-Systemen
- M 4.211 Einsatz des z/OS-Sicherheitssystems RACF
Bei anderen Betriebssystemen sind die dort beschriebenen Hinweise in hn- Andere Betriebssysteme
licher Weise umzusetzen (siehe dazu auch die betriebssystemspezifischen
Bausteine in Kapitel 6).
- Gibt es organisatorische Regelungen zur Einrichtung von Benutzern bzw.
Benutzergruppen?
- Gibt es ein Programm zur Einrichtung von Benutzern bzw. Benutzergrup-
pen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.31 Dokumentation der zugelassenen Benutzer und

Rechteprofile
Die Dokumentation dient der bersicht ber die zugelassenen Benutzer,
Benutzergruppen und Rechteprofile und ist Voraussetzung fr Kontrollen.
Es soll jede der folgenden drei Dokumentationsmglichkeiten genutzt werden:
- vorgegebene Administrationsdateien des Systems,
- individuelle Dateien, die vom zustndigen Administrator verwaltet werden,
- in Papierform.
Dokumentiert werden sollen insbesondere Umfang der
Dokumentation
- die zugelassenen Benutzer mit folgenden Angaben: zugeordnetes Rechte-
profil (ggf. Abweichungen vom verwendeten Standard-Rechteprofil),
Begrndung fr die Wahl des Rechteprofils (und ggf. der Abweichungen),
Erreichbarkeit des Benutzers, Zeitpunkt und Grund der Einrichtung,
Befristungen,
- die zugelassenen Gruppen mit den zugehrigen Benutzern, Zeitpunkt und
Grund der Einrichtung, Befristung.
Die Dokumentation der zugelassenen Benutzer und Rechteprofile sollte regel- regelmige Prfung der
Dokumentation
mig (mindestens alle 6 Monate) daraufhin berprft werden, ob sie den
tatschlichen Stand der Rechtevergabe wiederspiegelt und ob die Rechte-
vergabe noch den Sicherheitsanforderungen und den aktuellen Aufgaben der
Benutzer entspricht.
Fr das Betriebssystem z/OS finden sich weitere Empfehlungen in den z/OS-spezifische
Empfehlungen
folgenden Manahmen:
- M 2.289 Einsatz restriktiver z/OS-Kennungen
- M 2.297 Deinstallation von z/OS-Systemen
- M 4.211 Einsatz des z/OS-Sicherheitssystems RACF
- Sind Aufzeichnungen ber die zugelassenen Benutzer und Gruppen und
deren Rechteprofile vorhanden?
- Sind die Aufzeichnungen aktuell?
- Wann wurden die Aufzeichnungen das letzte Mal berprft?
- Sind die Aufzeichnungen vor unberechtigten Zugriffen ausreichend
geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.32 Einrichtung einer eingeschrnkten

Benutzerumgebung
Falls Benutzer nur bestimmte Aufgaben wahrzunehmen brauchen, ist es oft-
mals nicht erforderlich, ihnen alle mit einem eigenen Login verbundenen
Rechte (ggf. sogar Systemadministrator-Rechte) zu geben. Beispiele sind
bestimmte Ttigkeiten der routinemigen Systemverwaltung (wie Erstellung
von Backups, Einrichten eines neuen Benutzers), die mit einem Programm
mengesteuert durchgefhrt werden, oder Ttigkeiten, fr die ein Benutzer nur
ein einzelnes Anwendungsprogramm bentigt. Insbesondere bei
Aushilfskrften sollte darauf geachtet werden, dass diese nur die Dienste
verwenden und nur auf die Daten zugreifen drfen, die sie tatschlich
bentigen. Wenn ihre Ttigkeit beendet ist, sollte deren Accounts deaktiviert
und alle anderen Zugangsberechtigungen entfernt werden (siehe auch M 4.17
Sperren und Lschen nicht bentigter Accounts und Terminals).
Fr diese Benutzer sollte eine eingeschrnkte Benutzerumgebung geschaffen Restricted Shell und
chroot verwenden
werden. Sie kann z. B. unter Unix durch eine Restricted Shell (rsh) und eine
Beschrnkung der Zugriffspfade mit dem Unix-Kommando chroot realisiert
werden. Fr einen Benutzer, der nur ein Anwendungsprogramm bentigt,
kann dieses als Login-Shell eingetragen werden, so dass nach dem Einloggen
dieses direkt gestartet und er bei Beendigung des Programms automatisch
ausgeloggt wird.
Der verfgbare Funktionsumfang des IT-Systems kann fr einzelne Benutzer Nutzung von Editoren
und Compilern ein-
oder Benutzergruppen eingeschrnkt werden. Die Nutzung von Editor- schrnken
programmen oder Compilern sollte verhindert werden, wenn dies nicht fr die
Aufgabenerfllung des Benutzers erforderlich ist. Dies kann bei Stand-alone-
Systemen durch die Entfernung solcher Programme und bei vernetzten
Systemen durch die Rechtevergabe geregelt werden.
- Welche Benutzerumgebung und welche Startprozedur ist fr die jeweiligen
Benutzer eingerichtet worden?
- Gibt es Regelungen fr die Benutzerumgebungen von Aushilfskrften?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.33 Aufteilung der Administrationsttigkeiten unter

Unix
In den meisten Unix-Systemen gibt es nur eine Administrationsrolle (den
Super-User namens root mit der Benutzer-ID (UID) 0). Personen mit Zugang
zu dieser Rolle haben die volle Kontrolle ber das System. Insbesondere
knnen sie unabhngig von Zugriffsrechten jede Datei lesen, verndern und
lschen.
Das Super-User-Passwort darf nur den Administratoren bekannt sein. Die Vier-Augen-Prinzip
Weitergabe des Passworts ist auf die in Regelungen festgelegte Flle zu
beschrnken und zu dokumentieren. Der Super-User-Login root kann durch
Anwendung des Vier-Augen-Prinzips zustzlich geschtzt werden, z. B. durch
organisatorische Manahmen wie ein geteiltes Passwort. Dabei muss das
Passwort eine erhhte Mindestlnge (12 oder mehr Zeichen) haben. Hierbei
muss darauf geachtet werden, dass das Passwort in voller Mindestlnge vom
System berprft wird.
Bei etlichen Unix-Systemen ist eine Aufgabenteilung durch die Ausnutzung Rollentrennung
vorhandener Administratorrollen mglich. Diese Rollen sollen dann durch
verschiedene Personen wahrgenommen werden.
Eine Reihe von Administrationsttigkeiten knnen auch ohne Zugang zum
Login root ausgefhrt werden. Wenn es Administratoren mit solchen Spezial-
aufgaben gibt, sollte davon Gebrauch gemacht werden. Insbesondere, wenn in
groen Systemen mehrere Personen mit Administrationsaufgaben betraut
werden mssen, kann das Risiko durch eine entsprechende Aufgabenteilung
vermindert werden. Es gibt dazu zwei Mglichkeiten:
- Schaffung administrativer Logins: Sie haben zwar die UID 0, jedoch wird
beim Login nur ein Programm gestartet, mit dem die administrative
Aufgabe ausgefhrt werden kann und das mit einem Logout endet.
Beispiele: Einrichten neuer Benutzer, Mounten eines Laufwerks. Zu UNIX
V.4 knnen z. B. die administrativen Login-Namen setup, sysadm,
powerdown, checkfsys, mountfsys und umountfsys mit den gleichnamigen
Programmen eingerichtet werden.
- Benutzung von Logins ohne UID 0: Diese Login-Namen (sys, bin, adm,
uucp, nuucp, daemon und lp) sind Eigentmer von Dateien und
Programmen, die fr die Funktionalitt des Systems entscheidend sind und
die daher besonderem Schutz unterliegen. Sie sind in den meisten Unix-
Systemen zur Verwaltung der entsprechenden Dienste vorgegeben.
Um festzustellen, welche Logins Administratorrechte haben, sollten Hilfsprogramme ein-
setzen
regelmig Hilfsprogramme (z. B. USEIT, cops, tiger) eingesetzt werden, die
nach Logins mit der UID 0 in der Passwort-Datei suchen.
- Welchen Personen ist das Super-User-Passwort bekannt?
- Sind Administrator-Rollen getrennt worden?
- Welche Logins haben die UID 0?
- Gibt es Logins mit UID 0 und Shell-Zugriff?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.34 Dokumentation der Vernderungen an einem

bestehenden System
Um einen reibungslosen Betriebsablauf zu gewhrleisten, muss der berblick ber das
System
Administrator einen berblick ber das System haben bzw. sich verschaffen
knnen. Dieses muss auch fr seinen Vertreter mglich sein, falls der
Administrator unvorhergesehen ausfllt. Der berblick ist auch Voraus-
setzung, um Prfungen des Systems (z. B. auf problematische Einstellungen,
Konsistenz bei nderungen) durchfhren zu knnen.
Daher sollten die Vernderungen, die Administratoren am System vornehmen,
dokumentiert werden, nach Mglichkeit automatisiert. Dieses gilt
insbesondere fr nderungen an Systemverzeichnissen und -dateien.
Bei Installation neuer Betriebssysteme oder bei Updates sind die vorge- neue Betriebssysteme
oder Updates
nommenen nderungen besonders sorgfltig zu dokumentieren. Mglicher-
weise kann durch die Aktivierung neuer oder durch die nderung bestehender
Systemparameter das Verhalten des IT-Systems (insbesondere auch Sicher-
heitsfunktionen) mageblich verndert werden.
Unter Unix mssen ausfhrbare Dateien, auf die auch andere Benutzer als der Freigabe und Dokumen-
tation ausfhrbarer
Eigentmer Zugriff haben oder deren Eigentmer root ist, vom System- Dateien
administrator freigegeben und dokumentiert werden (siehe auch M 2.9
Nutzungsverbot nicht freigegebener Hard- und Software). Insbesondere
mssen Listen mit den freigegebenen Versionen dieser Dateien gefhrt
werden, die auerdem mindestens das Erstellungsdatum, die Gre jeder
Datei und Angaben ber evtl. gesetzte s-Bits enthalten. Sie sind
Voraussetzung fr den regelmigen Sicherheitscheck und fr berprfungen
nach einem Verlust der Integritt.
- Werden Logbcher ber Systemvernderungen gefhrt?
- Sind die Aufzeichnungen aktuell und vollstndig?
- Kann aufgrund der Aufzeichnungen die Administration weitergefhrt
werden?
- Sind die Aufzeichnungen vor unberechtigtem Zugriff geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.35 Informationsbeschaffung ber

Sicherheitslcken des Systems
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Administrator
Gegen bekannt gewordene und durch Verffentlichungen zugnglich
gemachte Sicherheitslcken mssen die erforderlichen organisatorischen und
administrativen Manahmen ergriffen werden. Sicherheitsrelavante Updates
oder Patches fr die eingesetzte Hard- und Software mssen gegebenenfalls
installiert werden (siehe auch M 2.273 Zeitnahes Einspielen
sicherheitsrelevanter Patches und Updates). Sind keine entsprechenden
Updates oder Patches verfgbar, so muss eventuell zustzliche
Sicherheitshardware bzw. Sicherheitssoftware eingesetzt werden.
Es ist daher sehr wichtig, dass sich die Systemadministratoren regelmig
ber neu bekannt gewordene Schwachstellen informieren. Informationsquellen
zu diesem Thema sind beispielsweise:
- Das Bundesamt fr Sicherheit in der Informationstechnik (BSI) (siehe
http://www.bsi.bund.de/)
- Hersteller bzw. Distributoren von Programmen und Betriebssystemen.
Diese informieren oft registrierte Kunden ber bekannt gewordene Sicher-
heitslcken ihrer Systeme und stellen korrigierte Varianten des Systems
oder Patches zur Behebung der Sicherheitslcken zur Verfgung.
- Computer Emergency Response Teams (CERTs). Dies sind Computer-
Notfallteams, die als zentrale Anlaufstelle fr prventive und reaktive
Manahmen in bezug auf sicherheitsrelevante Vorflle in Computer-
systemen dienen. CERTs informieren in sogenannten Advisories ber
aktuelle Schwachstellen in Hard- und Softwareprodukten und geben Emp-
fehlungen zu deren Behebung. Verschiedene Organisationen oder Ver-
bnde unterhalten eigene CERTs.
Das ursprngliche CERT der Carnegie Mellon Universitt diente als Vor-
bild fr viele weitere derartige Teams und ist heute eine Art "Dach-CERT":
Computer Emergency Response Team / Coordination Center (CERT/CC),
Software Engineering Institute, Carnegie Mellon University, Pittsburgh,
PA 15213-3890,
Telefon: +1-412-268-7090 (24-Stunden-Hotline), E-Mail: cert@cert.org,
WWW: http://www.cert.org
Die CERT-Mitteilungen werden in Newsgruppen (comp.security.announce
und info.nsfnet.cert) und ber Mailinglisten (Aufnahme durch E-Mail an:
cert-advisory-request@cert.org) verffentlicht.
In Deutschland exisiteren unter anderem folgende CERTs:
- CERT-Bund, Bundesamt fr Sicherheit in der Informationstechnik,
Postfach 20 03 63, D-53133 Bonn, Telefon: 01888-CERTBUND
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
bzw. 01888-23782863, Fax: 01888-9582-427, E-Mail:

certbund@bsi.bund.de, WWW: http://www.bsi.bund.de/certbund/
- DFN-CERT, DFN-CERT, Zentrum fr sichere Netzdienste GmbH,
Heidenkampsweg 41, D-20097 Hamburg, Telefon: 040-808077-555,
Fax: -556, E-Mail: info@dfn-cert.de, WWW:
http://www.dfn-cert.de. Das DFN-CERT bietet verschiedene
Mailinglisten an, siehe http://www.dfn-cert.de/infoserv/dml.html.
- An verschiedenen Hochschulen existieren CERTs, die auch Informa-
tionen ffentlich zur Verfgung stellen. Ein Beispiel ist das RUS-
CERT der Universitt Stuttgart (siehe http://cert.uni-stuttgart.de).
- Hersteller- und systemspezifische sowie sicherheitsspezifische News-
gruppen oder Mailinglisten. In solchen Foren werden Hinweise auf
existierende oder vermutete Sicherheitslcken oder Fehler in diversen
Betriebssystemen und sonstigen Softwareprodukten diskutiert. Besonders
aktuell sind meist die englischsprachigen Mailinglisten wie Bugtraq, von
denen es an vielen Stellen ffentlich zugngliche Archive gibt, beispiels-
weise unter http://www.securityfocus.com.
- manche IT-Fachzeitschriften verffentlichen ebenfalls regelmig Beitrge
mit einer bersicht ber neue Sicherheitslcken in verschiedenen Pro-
dukten.
Idealerweise sollten sich die Administratoren und der IT-Sicherheitsbeauftrage Verschiedene
Informationsquellen
bei mindestens zwei verschiedenen Stellen ber Sicherheitslcken nutzen
informieren. Dabei ist es empfehlenswert, neben den Informationen des Her-
stellers auch eine "unabhngige" Informationsquelle zu benutzen.
Die Administratoren sollten jedoch in jedem Fall auch produktspezifische
Informationsquellen des Herstellers nutzen, um beispielsweise darber
Bescheid zu wissen, ob fr ein bestimmtes Produkt beim Bekanntwerden von
Sicherheitslcken berhaupt Patches oder Updates bereitgestellt werden. Bei
Produkten, fr die der Hersteller keine Sicherheitspatches mehr zur Verfgung
stellt, muss rechtzeitig geprft werden, ob ein Einsatz unter diesen Umstnden
noch zu verantworten ist und durch welche zustzlichen Manahmen ein
Schutz der betroffenen Systeme trotzdem gewhrleistet werden kann.
- Steht der Administrator in regelmigem Kontakt zu den Herstellern der
betreuten Systeme? Sind diese Systeme registriert? Sind Wartungsvertrge
abgeschlossen worden?
- Welche Informationsmglichkeiten sind bekannt? Welche werden genutzt?
- Werden neue Informationsquellen erschlossen?
- Werden bekannt gewordene Sicherheitslcken schnellstmglich behoben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.36 Geregelte bergabe und Rcknahme eines

tragbaren PC
Verantwortlich fr Umsetzung: Administrator, IT-Benutzer
Bei der bergabe und Rcknahme eines tragbaren PCs sind folgende Punkte
zu beachten:
bergabe:
- Die fachliche Notwendigkeit der Benutzung eines tragbaren PCs sollte
vorab geprft sein.
- Der neue Benutzer wird aufgefordert, direkt bei der bergabe das alte
Passwort des tragbaren PCs bzw. das Standardpasswort zu ndern.
- Dem neuen Benutzer wird ein Merkblatt fr den sicheren Umgang mit dem
tragbaren PC bergeben (optional).
- Der neue Benutzer wird mit Namen, Organisationseinheit, Telefonnummer,
Einsatzzweck in das bergabe-/Rcknahmejournal eingetragen.
Rcknahme bzw. Weitergabe:
- Der Benutzer gibt sein zuletzt benutztes Passwort bekannt bzw. stellt ein
Standardpawort wie "LAPTOP" ein.
- Die Vollstndigkeit des Gertes, des Zubehrs und der Dokumentation ist
sicherzustellen.
- Der Benutzer muss sicherstellen, dass vor bergabe des Gertes smtliche
Daten, die der Benutzer noch bentigt, auf ihm zugngliche Datentrger
(z. B. seinen PC) bertragen werden. Darber hinaus hat der Benutzer
dafr Sorge zu tragen, dass smtliche von ihm erzeugten Dateien und
Daten (nach Mglichkeit physikalisch) gelscht sind.
- Die empfangende Stelle prft den tragbaren PC mittels eines aktuellen
Viren-Suchprogramms auf einen Computer-Viren-Befall.
- Die Rckgabe des tragbaren PC und das Untersuchungsergebnis der
Virensuche werden dokumentiert.
- Zurckgegebene Disketten werden neu formatiert. Beim Formatieren von
DOS-Datentrgern ist darauf zu achten, dass der Parameter /U (in DOS 6.2
enthalten) benutzt wird, damit das Formatieren nicht ber den Befehl
unformat wieder rckgngig gemacht werden kann.
- Wird die Weitergabe eines tragbaren PC an Kollegen dokumentiert?
- Werden die dabei zu beachtenden Sicherheitsmanahmen eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.37 "Der aufgerumte Arbeitsplatz"

Jeder Mitarbeiter sollte dazu angehalten werden, seinen Arbeitsplatz
"aufgerumt" zu hinterlassen. Ein IT-Benutzer hat nicht nur dafr Sorge zu
tragen, dass bei Verlassen seines Arbeitsplatzes entsprechende Vorkehrungen
getroffen sind, dass Unbefugte keinen Zugang zu IT-Anwendungen oder
Zugriff auf Daten erhalten. Der IT-Benutzer muss mit der gleichen Sorgfalt
auch seinen Arbeitsplatz berprfen und sicherstellen, dass durch den Zugriff
Unbefugter auf Datentrger (Diskette, Festplatte) oder Unterlagen
(Ausdrucke) kein Verlust an Verfgbarkeit, Vertraulichkeit oder Integritt
entstehen kann.
Fr eine kurze Abwesenheit whrend der Arbeitszeit ist das Verschlieen des
Raumes ausreichend; auerhalb der Arbeitszeit ist der Arbeitsplatz so aufzu-
rumen, dass keine schutzbedrftigen Datentrger oder Unterlagen unver-
schlossen am Arbeitsplatz zurckgelassen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.38 Aufteilung der Administrationsttigkeiten

Viele Netzbetriebssysteme bieten die Mglichkeit, die Administratorrolle
aufzuteilen und Administrationsttigkeiten an verschiedene Benutzer zu ver-
teilen.
So knnen z. B. unter Novell Netware 3.11 die folgenden Administratorrollen
eingerichtet werden: Workgroup Manager, User Account Manager, File
Server Console Operator, Print Server Operator, Print Queue Operator.
Unter Windows NT knnen durch die gezielte Vergabe von Benutzerrechten
an einzelne Benutzer oder besser an Gruppen definierte Administratorrollen
geschaffen werden. Neben der Gruppe der Administratoren sind hier die
Gruppen Hauptbenutzer (d. h. Administratoren mit eingeschrnkten Rechten),
Sicherungs-Operatoren, Druck-Operatoren, Server-Operatoren sowie
Reproduktions-Operatoren zu nennen. Darber hinaus knnen weitere Rollen
durch explizite Zuweisung von Benutzerrechten definiert werden (siehe auch
M 4.50 Strukturierte Systemverwaltung unter Windows NT).
Wenn es Administratorrollen fr Spezialaufgaben gibt, sollte davon Gebrauch
gemacht werden. Insbesondere, wenn in groen Systemen mehrere Personen
mit Administrationsaufgaben betraut werden mssen, kann das Risiko der
bergroen Machtbefugnis der Administratorrollen durch eine entsprechende
Aufgabenteilung vermindert werden, so dass Administratoren nicht unkon-
trolliert unautorisierte oder unbeabsichtigte Vernderungen am System vor-
nehmen knnen.
Trotz des Aufteilens von Administrationsttigkeiten legt das System meist
noch automatisch einen Account fr einen Administrator an, der keinen
Beschrnkungen unterliegt, den Supervisor. Das Supervisor-Passwort sollte,
wenn berhaupt, nur einem kleinen Personenkreis bekannt sein. Es darf
keinem der Subadministratoren bekannt sein, damit diese nicht auf diese
Weise ihre Rechte erweitern knnen. Das Passwort ist gesichert zu hinterlegen
(siehe M 2.22 Hinterlegen des Passwortes). Das Supervisor-Login kann durch
Anwendung des Vier-Augen-Prinzips zustzlich geschtzt werden, z. B. durch
organisatorische Manahmen wie ein geteiltes Passwort. Dabei muss das
Passwort eine erhhte Mindestlnge (12 oder mehr Zeichen) haben. Hierbei
muss darauf geachtet werden, dass das Passwort in voller Mindestlnge vom
System berprft wird.
- Welchen Personen ist das Supervisor-Passwort bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.39 Reaktion auf Verletzungen der Sicherheitspolitik

Es ist festzulegen, welche Reaktion auf Verletzungen der Sicherheitspolitik
erfolgen soll, um eine klare und sofortige Reaktion gewhrleisten zu knnen.
Untersuchungen sollten durchgefhrt werden, um festzustellen, wie und wo
die Verletzung entstanden ist. Anschlieend mssen die angemessenen
schadensbehebenden oder -mindernden Manahmen durchgefhrt werden.
Soweit erforderlich, mssen zustzliche schadensvorbeugende Manahmen
ergriffen werden. Die durchzufhrenden Aktionen hngen sowohl von der Art
der Verletzung als auch vom Verursacher ab.
Es muss geregelt sein, wer fr Kontakte mit anderen Organisationen verant-
wortlich ist, um Informationen ber bekannte Sicherheitslcken einzuholen
(siehe auch M 2.35 Informationsbeschaffung ber Sicherheitslcken des
Systems) oder um Informationen ber aufgetretene Sicherheitslcken
weiterzugeben. Es muss dafr Sorge getragen werden, dass evtl. mitbetroffene
Stellen schnellstens informiert werden.
- Ist die Vorgehensweise bei Verdacht auf Verletzung der Sicherheitspolitik
klar definiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.40 Rechtzeitige Beteiligung des Personal-

/Betriebsrates
Bei allen Manahmen, die prinzipiell die Verhaltens- oder
Leistungsberwachung von Mitarbeiter ermglichen, z. B. Protokollierung,
bedarf es der Mitbestimmung der Personalvertretung. Manahmen, die
geeignet sind eine Verhaltens- oder Leistungsberwachung eines Mitarbeiters
zu ermglichen - z. B. Protokollierung -, bedrfen der Mitbestimmung der
Personalvertretung. Grundlage dessen sind die Betriebsverfassungs- und
Personalvertretungsgesetze von Bund und Lndern. Die rechtzeitige und
umfassende Information des Betriebs- oder Personalrates kann
Zeitverzgerung bei der Umsetzung von Manahmen im Bereich des IT-
Grundschutzes verhindern.
Groe Outsourcing-Dienstleister berichten aus der Praxis, dass eine
frhzeitige Einbindung der Personalvertretung des Auftraggebers, mglichst
schon in der Angebotsphase, sehr zum Gelingen des Projektes beitragen kann.
Wechselbereitschaft der Mitarbeiter, Motivation, Arbeitszufriedenheit und
zgige Projektabwicklung knnen durch Kooperation aller Beteiligten positiv
beeinflusst werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.41 Verpflichtung der Mitarbeiter zur

Datensicherung
Da die Datensicherung eine wichtige IT-Sicherheitsmanahmen ist, sollten die
betroffenen Mitarbeiter auf die Einhaltung des Datensicherungskonzeptes
bzw. des Minimaldatensicherungskonzeptes verpflichtet werden. Eine regel-
mige Erinnerung und Motivation zur Datensicherung sollte erfolgen.
- Wird die Verpflichtung zur Datensicherung schriftlich dokumentiert?
- Wird die Durchfhrung von Kontrollen auf Einhaltung der Datensiche-
rungsverpflichtung vorgenommen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.42 Festlegung der mglichen

Kommunikationspartner
Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement, Daten-
schutzbeauftragter,
Sollen Informationen an einen Kommunikationspartner bertragen werden, so
muss sichergestellt werden, dass der Empfnger die notwendigen Berechti-
gungen zum Weiterverarbeiten dieser Informationen besitzt. Werden
Informationen zwischen mehreren kommunizierenden Stellen ausgetauscht, so
soll fr alle Beteiligten ersichtlich sein, wer diese Informationen ebenfalls er-
halten hat bzw. erhalten wird. Um die oben genannten Kriterien zu erfllen,
bedarf es einer Festlegung, welche Kommunikationspartner welche Informa-
tionen erhalten drfen.
Auch aus Datenschutzgrnden (siehe z. B. BDSG, bermittlungskontrolle)
sollte eine bersicht erstellt werden, welche Empfnger berechtigt sind, Infor-
mationen, insbesondere personenbezogene Daten, per Datentrgeraustausch
erhalten knnen.
- Existiert eine Festlegung fr etwaige Kommunikationsbeziehungen?
- Werden die genannten bersichten regelmig aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.43 Ausreichende Kennzeichnung der Datentrger

beim Versand
Neben den in Manahme M 2.3 Datentrgerverwaltung dargestellten
Umsetzungshinweisen ist bei einer ausreichenden Kennzeichnung von auszu-
tauschenden Datentrgern darauf zu achten, dass Absender und (alle) Empfn-
ger unmittelbar zu identifizieren sind. Die Kennzeichnung muss den Inhalt des
Datentrgers eindeutig fr den Empfnger erkennbar machen. Es ist jedoch bei
schtzenswerten Informationen wichtig, dass diese Kennzeichnung fr
Unbefugte nicht interpretierbar ist.
Darber hinaus sollten die Datentrger mit den fr das Auslesen notwendigen
Parametern gekennzeichnet werden. So sind bei der bermittlung von
Magnetbndern unter anderem das Label, die Geschwindigkeit (z. B. 800 bpi),
die Satzlnge, Blocklnge und Satzformat (z. B. 132 Byte, 13200 Byte, Fixed)
auf einem Etikett zu vermerken.
Datum des Versandes, eventuelle Versionsnummern oder Ordnungsmerkmale
knnen gegebenenfalls ntzlich sein.
- Ist geregelt, wie auszutauschende Datentrger gekennzeichnet werden
mssen?
- Wird stichprobenartig die Einhaltung der Kennzeichnungsvorgaben
geprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.44 Sichere Verpackung der Datentrger

Neben den in Manahme M 2.3 Datentrgerverwaltung dargestellten Umset-
zungshinweisen sollte die Verpackung dergestalt sein, dass Manipulationen
am Datentrger durch Vernderungen an der Verpackung erkennbar sind.
Mgliche Manahmen sind die Verwendung von
- Umschlgen mit Siegel,
- verplombten Behltnissen oder
- Umschlgen, die mit Klebefilm berklebt und anschlieend mit nicht-was-
serlslicher Tinte mehrmals unregelmig berzeichnet werden.
Verfgt der Datentrger ber einen Schreibschutz (Schieber bei Disketten,
Schreibring bei Bndern) so sollte dieser genutzt werden. Sollen Manipulatio-
nen an den Informationen auf dem Datentrger selbst erkannt werden, sind
Verschlsselungs- oder Checksummen-Verfahren einzusetzen (siehe M 4.34
Einsatz von Verschlsselung, Checksummen oder Digitalen Signaturen).
- Sind fr den sicheren Transport verschiedener Datentrger entsprechende
Transportbehltnisse vorgesehen und vorrtig?
- Ermglichen die Transportbehltnisse dem Empfnger die Kontrolle, dass
keine Manipulationen am Inhalt stattgefunden haben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.45 Regelung des Datentrgeraustausches

Sollen zwischen zwei oder mehreren Kommunikationspartnern Datentrger
ausgetauscht werden, so sind zum ordnungsgemen Austausch folgende
Punkte zu beachten:
- Die Adressierung muss eindeutig erfolgen, um eine fehlerhafte Zustellung
zu vermeiden. So sollte neben dem Namen des Empfngers auch Organi-
sationseinheit und die genaue Bezeichnung der Behrde/des Unternehmens
angegeben sein. Entsprechendes gilt fr die Adresse des Absenders.
- Dem Datentrger sollte (optional) ein Datentrgerbegleitzettel beigelegt
werden, der folgende Informationen umfasst:
- Absender,
- Empfnger,
- Art des Datentrgers,
- Seriennummer (soweit vorhanden),
- Identifikationsmerkmal fr den Inhalt des Datentrgers,
- Datum des Versandes, ggf. Datum bis wann der Datentrger
sptestens den Empfnger erreicht haben muss,
- Hinweis, dass Datentrger auf Viren berprft sind,
- Parameter, die zum Lesen der Informationen bentigt werden, z. B.
Bandgeschwindigkeit.
Jedoch sollte nicht vermerkt werden,
- welches Passwort fr die eventuell geschtzten Informationen ver-
geben wurde,
- welche Schlssel ggf. fr eine Verschlsselung der Informationen
verwendet wurde,
- welchen Inhalt der Datentrger hat.
- Der Versand des Datentrgers kann (optional) dokumentiert werden. Fr
jede stattgefundene bermittlung ist dann in einem Protokoll festzuhalten,
wer wann welche Informationen erhalten hat. Je nach Schutzbedarf
beziehungsweise Wichtigkeit der bermittelten Informationen ist der
Empfang zu quittieren ein Quittungsvermerk und dem erwhnten Protokoll
beizufgen.
- Es sind jeweils Verantwortliche fr den Versand und fr den Empfang zu
benennen.
- Die Versandart ist festzulegen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind Regelungen bekanntgegeben worden, wie ein Datentrgeraustausch
stattzufinden hat?
- Sind die fr den Datentrgeraustausch Verantwortlichen hinsichtlich mg-
licher Gefhrdungen ausreichend sensibilisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.46 Geeignetes Schlsselmanagement

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, IT-Verfahrensver-
antwortlicher
Die Verwendung kryptographischer Sicherheitsmechanismen (z. B. Ver-
schlsselung, digitale Signatur) setzt die vertrauliche, integere und authen-
tische Erzeugung, Verteilung und Installation von geeigneten Schlsseln vor-
aus. Schlssel, die Unbefugten zur Kenntnis gelangt sind, bei der Verteilung
verflscht worden sind oder gar aus unkontrollierter Quelle stammen (dies gilt
auch fr die Schlsselvereinbarung zwischen Kommunikationspartnern),
knnen den kryptographischen Sicherheitsmechanismus genauso kompro-
mittieren wie qualitativ schlechte Schlssel, die auf ungeeignete Weise
erzeugt worden sind. Qualitativ gute Schlssel werden in der Regel unter
Verwendung geeigneter Schlsselgeneratoren erzeugt (s. u.). Fr das Schls-
selmanagement sind folgende Punkte zu beachten:
Schlsselerzeugung
Die Schlsselerzeugung sollte in sicherer Umgebung und unter Einsatz geeig-
neter Schlsselgeneratoren erfolgen. Kryptographische Schlssel knnen zum
einen direkt am Einsatzort (und dann meistens durch den Benutzer initiiert)
oder zum anderen zentral erzeugt werden. Bei der Erzeugung vor Ort mssen
meistens Abstriche an die Sicherheit der Umgebung gemacht werden, bei
einer zentralen Schlsselgenerierung muss sichergestellt sein, dass sie ihre
Besitzer authentisch und kompromittierungsfrei erreichen.
Geeignete Schlsselgeneratoren mssen kontrollierte, statistisch gleichver-
teilte Zufallsfolgen unter Ausnutzung des gesamten mglichen Schlssel-
raums produzieren. Dazu erzeugt z. B. eine Rauschquelle zufllige Bitfolgen,
die mit Hilfe einer Logik nachbereitet werden. Anschlieend wird unter
Verwendung verschiedener Testverfahren die Gte der so gewonnenen
Schlssel berprft.
Einige Kryptomodule, insbesondere solche, die keinen integrierten Zufalls-
zahlengenerator besitzen, greifen auf Benutzereingaben zur Schlsselerzeu-
gung zurck. Beispielsweise werden hier Passwrter abgefragt, aus denen
dann ein Schlssel abgeleitet wird, oder der Benutzer wird gebeten, beliebigen
Text einzutippen, um zufllige Startwerte fr die Schlsselgenerierung zu
erhalten. Solche Passwrter sollten dabei gut gewhlt sein und mglichst lang
sein. Wenn mglichst "zufllige" Benutzereingaben angefordert werden,
sollten diese auch zufllig, also schlecht vorhersagbar, sein.
Schlsseltrennung
Kryptographische Schlssel sollten mglichst nur fr einen Einsatzzweck
dienen. Insbesondere sollten fr die Verschlsselung immer andere Schlssel
als fr die Signaturbildung benutzt werden. Dies ist sinnvoll,
- damit bei der Offenlegung eines Schlssels nicht alle Verfahren betroffen
sind,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- da es manchmal erforderlich sein kann, Verschlsselungsschlssel weiter-

zugeben (Vertretungsfall),
- da es unterschiedliche Zyklen fr den Schlsselwechsel geben kann.
Schlsselverteilung / Schlsselaustausch
Kryptographische Kommunikationsbeziehungen knnen nur dann funktionie-
ren, wenn die Kommunikationspartner ber aufeinander abgestimmte krypto-
graphische Schlssel verfgen. Dazu mssen alle Kommunikationspartner mit
den dazu erforderlichen Schlsseln versorgt werden. Zur Schlsselverteilung
und zum Schlsselaustausch knnen unterschiedliche Verfahren verwendet
werden. Die Unterschiede ergeben sich aus der Anwendung verschiedener
kryptographischer Verfahren und Mechanismen bzw. aus ihrer Kombination
(siehe M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens).
Unter Schlsselverteilung wird hier die initiale Versorgung der
Kommunikationspartner mit Grundschlsseln verstanden. Die Schlssel
werden dazu von einer meist zentralen Schlsselerzeugungsstelle (z. B. einem
Trust Center) an die einzelnen Kommunikationspartner bermittelt.
Die Verteilung der Schlssel sollte auf geeigneten Datentrgern (z. B. Chip-
karten) oder ber Kommunikationsverbindungen (z. B. LAN, WAN) vertrau-
lich (z. B. mit KEK - Key Encryption Key - verschlsselt), integer (z. B.
MAC-gesichert) und authentisch (z. B. digital signiert gem Signatur-Gesetz)
erfolgen. Die unbefugte Kenntnisnahme bzw. Verflschung der Schlssel
muss verhindert oder wenigstens erkannt werden knnen.
Mit Schlsselaustausch wird die Schlsseleinigungsprozedur zwischen zwei
Kommunikationspartnern auf einen Sitzungsschlssel (Session Key) bezeich-
net. Der Session Key ist ein Schlssel, der nur eine begrenzte Zeit, etwa fr
die Dauer einer Kommunikationsverbindung, verwendet wird. Diese Zeit
muss festgelegt werden, da Sitzungen sehr lange dauern knnen. Die
Festlegung erfolgt z. B. durch einen relativen Zeitablauf oder durch einen
Paketzhler. Fr jede neue Verbindung wird ein neuer Session Key zwischen
den Kommunikationspartnern ausgehandelt.
Moderne Systeme bedienen sich heute asymmetrischer kryptographischer
Verfahren zur Schlsselverteilung und zum Schlsselaustausch. Zum Nach-
weis der Authentizitt der ffentlichen Schlssel kann eine vertrauenswrdige
Zertifizierungsstelle eingerichtet werden. Die Kommunikationsteilnehmer
mssen sich gegenber der Zertifizierungsstelle ausweisen und dort ihren
ffentlichen Schlssel mittels einer digitalen Signatur der Zertifizierungsstelle
beglaubigen lassen. Das so erzeugte digitale Zertifikat sollte mindestens den
ffentlichen Schlssel und ein Identifikationsmerkmal des Kommuni-
kationsteilnehmers, die Gltigkeitsdauer des Zertifikats und die digitale
Signatur der Zertifizierungsstelle enthalten. Mit Kenntnis des ffentlichen
Signaturschlssels der Zertifizierungsstelle ist jeder Kommunikations-
teilnehmer in der Lage, die Authentizitt des ffentlichen Schlssels des
Kommunikationspartners zu verifizieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schlsselinstallation und -speicherung

Im Zuge der Schlsselinstallation ist die authentische Herkunft sowie die
Integritt der Schlsseldaten zu berprfen. Generell sollten Schlssel nie in
klarer Form, sondern grundstzlich verschlsselt im System gespeichert
werden. Bei Software-Verschlsselungsprodukten muss bercksichtigt
werden, dass Schlssel zumindest zeitweise whrend des Ver-
/Entschlsselungsprozesses in Klarform im PC-System vorliegen mssen.
Bieten die IT-Systeme, auf denen das kryptographische Produkt eingesetzt ist,
keinen ausreichenden Zugriffsschutz fr die Schlssel, sollten diese nicht auf
diesem IT-System gespeichert werden. Es bietet sich dann eine bedarfsorien-
tierte manuelle Eingabe an. Eine andere Mglichkeit wre die Auslagerung
der Schlssel auf einen externen Datentrger, der dann aber sicher verwahrt
werden muss, wie unter Schlsselarchivierung beschrieben. Aus Sicherheits-
aspekten ist deshalb der Einsatz von Hardware-Verschlsselungskomponenten
vorzuziehen, bei denen die Schlssel vom Datentrger (z. B. Chipkarte)
verschlsselt auf direktem Weg in die Verschlsselungskomponente geladen
werden und diese nie in Klarform verlassen.
Auf jeden Fall muss sichergestellt werden, dass bei der Installation des Ver-
schlsselungsverfahrens voreingestellte Schlssel gendert werden.
Schlsselarchivierung
Fr Archivierungszwecke sollte das kryptographische Schlsselmaterial auch
auerhalb des Kryptomoduls in berschlsselter Form speicherbar und gege-
benenfalls wieder einlesbar sein. Dazu knnen mehrere Schlssel zu einem
Satz zusammengefasst werden, der dann ebenfalls mit Hilfe eines KEK (Key-
Encryption-Key: berschlsselungsschlssel) kryptiert wird. Der KEK muss
entsprechend sicher (z. B. auf Chipkarte im Safe) aufbewahrt werden. Teilt
man einen man den KEK in zwei Teilschlssel, so lsst sich das "Vier-Augen-
Prinzip" umsetzen: zwei verschiedene Personen haben Zugriff auf je einen
Datentrger (z. B. Chipkarte, Diskette), auf der sich nur jeweils einer der
beiden Teilschlssel befindet. Um den KEK zu generieren, mssen sich beide
Datentrger gleichzeitig oder nacheinander in der Leseeinheit des Krypto-
moduls befinden.
Zugriffs- und Vertreterregelung
In der Sicherheitsrichtlinie sollten Fragen bzgl. der Zugriffs- und Vertretungs-
rechte geregelt sein. Entsprechende Mechanismen mssen vom Schlssel-
management und von den einzusetzenden Kryptomodulen/-gerten untersttzt
werden (z. B. Schlsselhinterlegung fr den Fall, dass ein Mitarbeiter das
Unternehmen verlsst oder wegen Krankheit lngere Zeit ausfllt, siehe auch
Schlsselarchivierung).
Schlsselwechsel
Im Kryptokonzept muss basierend auf der Sicherheitsrichtlinie festgelegt
werden, wann und wie oft Schlssel gewechselt werden mssen. Je grer die
Menge verschlsselter Daten ist, die einem Angreifer fr eine Analyse zur
Verfgung steht, um so grer ist bei manchen Verfahren die Chance, dass
das Analyseverfahren erfolgreich ist. Ein regelmiger Schlsselwechsel
mini-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
miert die Angriffsmglichkeiten auf verschlsselte Daten. Die Wechsel-

frequenz ist von verschiedenen Faktoren abhngig. Dabei spielt die Art des
verschlsselten Mediums (z. B. Langzeitdatentrger, Datenbertragungs-
medium) ebenso eine Rolle wie der kryptographische Algorithmus, die
Detektion von Angriffen (z. B. Diebstahl oder Verlust eines Schlssels) und
die Schutzwrdigkeit der Daten. Weitere Faktoren bei der Festlegung der
Wechselfrequenz sind die Hufigkeit des Schlsseleinsatzes, das relevante
Bedrohungspotential und die Sicherheit der lokalen Aufbewahrung der
Schlssel.
Je nach verwendetem Verfahren sind fr jede einzelne Kommunikations-
verbindung neue Schlssel auszuhandeln, also Sitzungsschlssel (Session
Keys) zu verwenden. Dies sollte natrlich fr die Benutzer unbemerkt durch
die Verfahren gesteuert werden. Schlsselwechsel bedeutet hierbei den Aus-
tausch der Masterkeys, die die Grundlage bilden, auf der die Sitzungsschlssel
gebildet werden, und sollte natrlich auch regelmig durchgefhrt werden.
Besteht der Verdacht, dass ein verwendeter Schlssel offen gelegt wurde, so
ist dieser Schlssel nicht mehr zu verwenden und alle Beteiligten sind zu
informieren. Bereits mit diesem Schlssel verschlsselte Informationen sind
zu entschlsseln und mit einem anderen Schlssel zu verschlsseln.
Schlsselvernichtung
Nicht mehr bentigte Schlssel (z. B. Schlssel, deren Gltigkeitsdauer abge-
laufen sind) sind auf sichere Art zu lschen bzw. zu vernichten (z. B. durch
mehrfaches Lschen/berschreiben und/oder mechanische Zerstrung des
Datentrgers). Auf Produkte mit unkontrollierbarer Schlsselablage sollte
generell verzichtet werden.
- Ist ein Verantwortlicher fr das Schlsselmanagement benannt?
- Werden die zu schtzenden Daten getrennt von den bei der Verschlsse-
lung verwendeten Schlsseln bertragen?
- Werden die zu verwendenden Schlssel hinreichend hufig gewechselt?
- Kann eine lokale sichere Aufbewahrung der Schlssel sichergestellt
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.47 Ernennung eines Fax-Verantwortlichen

Verantwortlich fr Initiierung: Leiter Innerer Dienst, Vorgesetzte
Fr jedes Faxgert ist ein Verantwortlicher zu benennen, der folgende Auf-
gaben bernehmen muss:
- Verteilung der eingehenden Faxsendungen an die Empfnger,
- Koordination der Versorgung des Faxgertes mit notwendigen Ver-
brauchsgtern,
- geeignete Entsorgung von Fax-Verbrauchsgtern,
- Lschen von Restinformationen im Faxgert vor Wartungs- und Repara-
turarbeiten,
- Beaufsichtigung von Wartungs- und Reparaturarbeiten (vgl. M 2.4
Regelungen fr Wartungs- und Reparaturarbeiten),
- gelegentliche Kontrolle programmierter Zieladressen und Protokolle,
insbesondere nach Wartungs- und Reparaturarbeiten,
- Ansprechpartner bei Problemen bei der Faxnutzung.
- Ist der Fax-Verantwortliche in seine Aufgaben eingewiesen worden?
- Wird die Zuverlssigkeit des Fax-Verantwortlichen gelegentlich geprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.48 Festlegung berechtigter Faxbediener

Die Berechtigung zur Bedienung des Faxgertes ist auf einen ausgewhlten
Kreis zuverlssiger Mitarbeiter zu beschrnken. Diese Mitarbeiter sind in die
korrekte Handhabung des Gertes einzuweisen und mit den erforderlichen IT-
Sicherheitsmanahmen vertraut zu machen. Jeder berechtigte Benutzer sollte
darber unterrichtet werden, wer das Gert bedienen darf und wer der Fax-
Verantwortliche ist. Darber hinaus sollte am Faxgert eine verstndliche
Bedienungsanleitung ausliegen.
Durch die Einschrnkung des Faxbedienerkreises auf die fr den operativen
Einsatz notwendige Mindestzahl wird erreicht, dass die Anzahl der Personen,
die eingehende Faxsendungen mitlesen knnen, begrenzt ist.
- Ist die Anzahl der Fax-Benutzer so gewhlt, dass der betriebliche Einsatz
nicht eingeschrnkt ist?
- Wissen alle Benutzer, wer zur Bedienung des Faxgertes sonst noch
berechtigt ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.49 Beschaffung geeigneter Faxgerte

Verantwortlich fr Umsetzung: Beschaffungsstelle
Bei Neuanschaffungen von Faxgerten sollte darauf geachtet werden, dass
bliche Standardsicherheitsfunktionen implementiert sind wie:
- Austausch einer Teilnehmerkennung,
- Sendebericht,
- Journalfhrung.
Unter Beachtung des Preis-/Leistungsverhltnisses sind darber hinaus folgen-
de zustzliche Sicherheitsfunktionen zu begren:
- pawortgeschtzter Zugang,
- pawortgeschtzter Pufferspeicher,
- Einrichten einer geschlossenen Benutzergruppe,
- Ausschlieen bestimmter Faxanschlsse von Versendung oder Empfang.
- Werden bei der Neubeschaffung von Faxgerten Sicherheitsfunktionen als
Auswahlkriterien bercksichtigt?
- Wird bei der Beschaffung von Faxgerten mit zustzlichen Sicherheits-
funktionen die Angemessenheit und Wirtschaftlichkeit am Schutzbedarf
ausgerichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.50 Geeignete Entsorgung von Fax-

Verbrauchsgtern und -Ersatzteilen
Verantwortlich fr Initiierung: Leiter Innerer Dienst, IT-
Verantwortlich fr Umsetzung: Fax-Verantwortlicher
Alle Fax-Verbrauchsgter, aus denen Informationen ber Faxtexte gewonnen
werden knnten, wie z. B. Zwischentrgerfolien oder fehlerhafte Ausdrucke,
sollten vor der Entsorgung vernichtet oder durch eine zuverlssige Fachfirma
entsorgt werden.
Das gleiche gilt beim Austausch informationstragender Ersatzteile, wie z. B.
photo-elektrische Trommeln.
Wartungsfirmen, die Faxgerte periodisch warten oder reparieren, sind auf
eine entsprechende Handhabung zu verpflichten und ggf. zu kontrollieren.
- Auf welche Weise wird nicht mehr bentigtes Fax-Verbrauchsmaterial
entsorgt?
- Sind die Fax-Verantwortlichen auf die Schutzbedrftigkeit des zu entsor-
genden Materials und die bestehenden Entsorgungsmglichkeiten hinge-
wiesen worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.51 Fertigung von Kopien eingehender

Faxsendungen
Verantwortlich fr Initiierung: Fax-Verantwortlicher
Ein Fax auf Thermopapier kann nach einiger Zeit stark verblassen oder
schwarz werden. Daher sollten von Faxen auf Thermopapier, deren Informa-
tionsgehalt lnger bentigt wird, Kopien auf Normalpapier erstellt werden.
- Gibt es Faxgerte im Unternehmen/ der Behrde, die mit Thermopapier
arbeiten?
- Werden wichtige eingehende Faxsendungen kopiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.52 Versorgung und Kontrolle der Verbrauchsgter

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Leiter Innerer
Dienst
Verantwortlich fr Umsetzung: Innerer Dienst, Administrator, Benutzer
Viele im Broalltag eingesetzte Gerte wie Fax, Drucker, etc. sind auf
bestimmte Verbrauchsgter (z. B. Papier, Toner, Datensicherungsbnder)
angewiesen, um funktionieren zu knnen. Daher muss die Versorgung mit
diesen Verbrauchsgtern vor Ort sichergestellt sein. Es sollten klare und
eindeutige Regelungen existieren, welche Verbrauchsgter von wem nachge-
fllt bzw. bestellt werden sollten.
Bestimmte Ressourcen drfen nicht von jedem Mitarbeiter nachgefllt oder
beschafft werden, sondern nur von autorisierten Personen, beispielsweise sehr
teure Produkte oder technisch komplexe Komponenten.
Alle Benutzer sollten informiert sein, wer zu benachrichtigen ist, wenn
Verbrauchsgter nachbeschafft oder aufgefllt werden mssen. Fr jede Sorte
von Verbrauchsmaterial sollte jemand benannt werden, der fr Versorgung
und Kontrolle verantwortlich ist. Dieser ist dafr verantwortlich
- regelmig zu prfen, ob ausreichende Vorrte vorhanden sind und vor Ort
nachgefllt werden muss,
- die Beschaffungsstelle rechtzeitig zu benachrichtigen, wenn Verbrauchs-
material nachbestellt werden muss.
Die Versorgung mit Verbrauchsgtern ist von der Beschaffungsstelle ausrei-
chend sicherzustellen.
- Ist die Zustndigkeit fr den Nachschub an Versorgungsgtern geregelt?
- Fehlt hufig Verbrauchsmaterial?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.53 Abschalten des Faxgertes auerhalb der

Brozeiten
Verantwortlich fr Initiierung: IT-Sicherheitsmanagement,
Brandschutzbeauftragter
Verantwortlich fr Umsetzung: Fax-Verantwortlicher
Um die Brandgefahr, die von Faxgerten immer ausgehen kann, zu reduzieren,
sollten Gerte, die auerhalb der Arbeitszeit nicht bentigt werden
(Abteilungs-Faxgert, persnliches Gert) zum Dienstschluss abgeschaltet
werden. Damit kann auch erreicht werden, dass eingehende Faxsendungen
nicht unkontrolliert lngere Zeit im Faxgert verbleiben. Realisierbar ist die
Abschaltung auf einfache Weise durch Zeitschaltuhren, die die Stromversor-
gung des Gertes auf die blichen Brozeiten einschrnken.
Fr spter eingehende Sendungen kann ein anderer (mglichst stndig kon-
trollierter) Fax-Anschluss benannt werden oder bei modernen TK-Anlagen
eine Anrufumleitung eingerichtet werden.
Gleichzeitig kann mit dem Abschalten des Faxgertes die berlastung des
Gertes aufgrund eines technischen Versagens oder aufgrund beabsichtigter
Massenfaxsendungen auerhalb der Brozeit verhindert werden.
Das Abschalten sollte unterbleiben, wenn fr die Verfgbarkeit des Gertes
besondere Anforderungen bestehen, die bei den Ausweichlsungen nicht
umgesetzt werden knnen.
- Welche Faxgerte mssen auch auerhalb der Brozeiten aktiv sein?
- Werden die anderen Gerte ausgeschaltet?
- Besteht die Mglichkeit einer Anrufweiterleitung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.54 Beschaffung geeigneter Anrufbeantworter

Verantwortlich fr Umsetzung: Haustechnik, Beschaffungsstelle
Diese Manahme ist bei der Neubeschaffung von Anrufbeantwortern zu
beachten. Sollten vorhandene Gerte den Sicherheitsansprchen nicht
gengen, ist eine Neuanschaffung oder die Abschaltung dieser Gerte in
Erwgung zu ziehen.
Bei der Beschaffung von Anrufbeantwortern sollten unter Beachtung der
Wirtschaftlichkeit einige Kriterien beachtet werden, um Gefhrdungen mg-
lichst auszuschlieen:
- Zur Sicherstellung einwandfreier fernmeldetechnischer Funktionen mssen
die Gerte eine BZT-Zulassung (Postzulassung) besitzen.
- Bei ganz oder teilweise digital speichernden Gerten empfiehlt es sich,
solche auszuwhlen, die eine Notstromversorgung durch Batterien oder
vom Benutzer wechselbare Akkumulatoren bieten. Bei fest eingebauten
Akkumulatoren wird bei einem Austausch der Einsatz eines Servicetech-
nikers notwendig, was zu einem lngeren Ausfall des Anrufbeantworters
fhren kann.
- Aufgrund unterschiedlicher Gte der Nachrichtenaufzeichnung (z. B. bei
analoger oder digitaler Aufzeichnung) sollte vor der Beschaffung die
Aufzeichnungsqualitt getestet werden.
- Ganz oder teilweise digital speichernde Anrufbeantworter sollten mit einer
Anzeige der Batteriekapazitt sowie einem deutlichem Warnzeichen (evtl.
auch akustisch) ausgestattet sein, um verminderte Batterieleistung recht-
zeitig anzeigen zu knnen.
- Bei Anrufbeantwortern, die eine einzige Kassette sowohl fr Aufzeich-
nungen als auch fr den Ansagetext verwenden, entstehen durch Band-
spulvorgnge Wartezeiten. Es sollte abgewogen werden, ob diese Warte-
zeiten in Kauf genommen werden knnen.
- Die Bedienungsfreundlichkeit des Anrufbeantworters sollte beachtet
werden. Ergonomische und bersichtliche Tastenanordnung, Funktions-
tasten ohne Doppelbelegungen und fr jedermann verstndliche Bedie-
nungsanleitungen sind vorteilhaft.
- Die Fernabfrage sollte nach Mglichkeit mechanisch oder elektronisch
deaktivierbar, der Sicherungscode zumindest drei- bis vierstellig und frei
programmierbar sein. Eine zustzliche Sperrschaltung, die den Anrufbe-
antworter nach drei vergeblichen Versuchen die Verbindung unterbrechen
lsst, bietet einen erhhten Schutz. Hieraus ergeben sich zumindest ein
hherer Zeitaufwand und hhere Telefonkosten fr den potentiellen
Angreifer. Besser noch sind Gerte, bei denen die Fernabfragefunktionen
nach drei vergeblichen Versuchen vollkommen gesperrt werden und nur
noch am Gert selbst wieder aktivierbar sind. Auch Sperrzeiten, die nach
jedem Fehlversuch verlngert werden, sind sinnvoll.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind obige Hinweise der Beschaffungsstelle bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.55 Einsatz eines Sicherungscodes

Verfgt der Anrufbeantworter ber Fernabfragemglichkeiten und einen
Sicherungscode, so ist anzustreben, dass die Fernabfrage nur mittels eines
individuell gewhlten, geheim zu haltenden Sicherungscodes aktiviert werden
kann. Insbesondere ist ein evtl. werkseitig eingestellter Code zu ndern. Der
Sicherungscode ist wie ein Passwort zu hinterlegen (vgl. hierzu M 2.22
Hinterlegen des Passwortes) und auch regelmig zu ndern.
Bei der Bedienung des Anrufbeantworters mittels Fernabfragegert sollte
darauf geachtet werden, dass sich kein Fremder in der Nhe aufhlt, der die
Eingabe der Codes beobachten oder erlauschen knnte.
- Wurden die Benutzer ber den korrekten Umgang mit der Fernabfrage
unterrichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.56 Vermeidung schutzbedrftiger Informationen

auf dem Anrufbeantworter
Da sich zurzeit Anrufbeantworter nicht vollstndig gegen Missbrauch
absichern lassen, sollte die Aufzeichnung schutzbedrftiger Informationen
vermieden werden oder sogar in Bereichen, in denen typischerweise schutz-
bedrftige Informationen ausgetauscht werden, der Einsatz von Anrufbeant-
wortern berdacht werden. Im Ansagetext sollte daher darauf hingewiesen
werden, dass keine schutzbedrftigen Informationen auf dem Anrufbeant-
worter hinterlassen werden sollten.
- Werden Personen, die schutzbedrftigen Informationen aufsprechen, ber
die damit verbundenen Risiken aufgeklrt?
- Sind Anrufbeantworter in Bereichen installiert, in denen hufig schutzbe-
drftige Informationen anfallen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.57 Regelmiges Abhren und Lschen

aufgezeichneter Gesprche
Die im Anrufbeantworter gespeicherten Gesprche sollten regelmig
abgehrt und gelscht werden. Ist das Lschen bei analog aufzeichnenden
Gerten nicht mglich, sollte das Magnetband an den Anfang zurckgespult
werden, damit die Aufzeichnung neuer Gesprche gespeicherte alte
Nachrichten berschreibt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.58 Begrenzung der Sprechdauer

Zur Verhinderung von vorzeitiger Fllung des Speichermediums, sollte die
maximale Sprechdauer pro Anruf auf 2-4 Minuten begrenzt werden, wenn das
Gert eine solche Einstellung erlaubt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.59 Auswahl eines geeigneten Modems in der

Beschaffung
Verantwortlich fr Umsetzung: IT-Benutzer, Administrator,
Beschaffungsstelle
Bei der Beschaffung eines Modems sind folgende Punkte zu beachten:
- Modem-Zulassung
Ein Modem, dass in Deutschland an das ffentliche Telekommunikations-
netz angeschlossen werden soll, muss eine BZT-Zulassung (frher ZZF-
Zulassung, davor FTZ-Zulassung, im allgemeinen Sprachgebrauch auch
Post-Zulassung genannt) haben. Hinweis: Entgegen der Angaben in vielen
Modem-Handbchern muss die Inbetriebnahme eines zugelassenen
Modems nicht mehr der Telekom gemeldet werden.
- Bauweise
Ein internes Modem bietet den Vorteil, dass die Modem-Konfiguration nur
ber den Rechner, in dem es eingebaut ist, gendert werden kann. Verfgt
der Rechner ber Zugangs- oder Zugriffsschutzmechanismen, knnen sie
zum Schutz der Modem-Konfigurationsdaten eingesetzt werden. Gleich-
zeitig kann damit die Nutzung des Modems auf autorisierte Personen
beschrnkt werden. Manipulationen am Modem sind durch den Einbau im
Rechner erschwert. Bei vernetzten Systemen, die nicht ber derartige
Schutzmechanismen verfgen (einige Peer-to-Peer-Netze), besteht der
Nachteil eines internen Modems darin, dass das Modem unkontrolliert von
allen Arbeitspltzen genutzt werden kann.
Ein externes Modem kann nach Nutzung verschlossen aufbewahrt werden.
Es bietet auerdem den Vorteil, dass es blicherweise ber diverse Anzei-
gen sowie den Modem-Lautsprecher ber den aktuellen Status informieren
kann. ber den Modem-Lautsprecher kann auch gehrt werden, ob von
extern eine Verbindung aufgebaut wird oder ob eine Applikation unauf-
gefordert versucht, Informationen ber die Installation und die System-
Konfiguration an den Hersteller zu bertragen. Ein weiterer Vorteil eines
externen Modems ist, dass es unabhngig vom IT-System nur fr die
jeweilige Datenbertragung eingeschaltet werden kann und somit z. B.
sichergestellt werden kann, dass die letzte Verbindung getrennt worden ist
und dass keine Verbindung von auerhalb aufgebaut werden kann. Nach-
teilig ist, dass ein externes Modem zur Manipulation der Konfigurations-
daten oder zum Auslesen gespeicherter Passwrter einfach an ein nicht
geschtztes IT-System angeschlossen werden kann.
PCMCIA-Modems bieten aufgrund der Baugre den Vorteil, dass sie
nach Nutzung einfach verwahrt werden knnen. Eine sichere
Aufbewahrung verhindert, dass sie zur Manipulation an ungeschtzte
Rechner angeschlossen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- bertragungsgeschwindigkeit
Je hher die bertragungsgeschwindigkeit eines Modems ist, desto gerin-
ger sind die Kosten fr die bertragung groer Datenmengen aufgrund der
Zeiteinsparung.
Zunchst ist zu klren, welche bertragungsgeschwindigkeiten fr den
gewnschten Einsatzzweck notwendig ist. Ausreichend sind z. B. bei
ASCII-Terminalemulation 2400 bit/sec, bei Faxbertragung 9600 bit/sec,
bei Datex-J (T-Online) zurzeit 14400 bit/sec. Fr Datenbertragung groen
Ausmaes sind die aktuell grtmglichen bertragungs-
geschwindigkeiten einzusetzen. bertragungsgeschwindigkeiten von mehr
als 2400 bit/sec erschweren darber hinaus das Abhren erheblich.
Anschlieend muss bei Geschwindigkeiten ber 9600 bit/sec berprft
werden, ob die Schnittstelle des IT-Systems, an dem das Modem betrieben
werden soll, hhere Geschwindigkeiten zulsst.
Bei der Auswahl des Modems sollte beachtet werden, dass die Leistungs-
merkmale, die fr die tatschlich erreichte bertragungsgeschwindigkeit
ausschlaggebend sind, genormt sind. Dies sind zum einen Normen fr die
bertragungsgeschwindigkeit wie V.32bis fr 14400 bit/sec und zum
anderen Protokolle zur bertragungsoptimierung durch Datenkompression
und Fehlerkorrektur wie MNP 5 oder V.24bis.
- Befehlssatz
Die meisten Modems arbeiten heute nach dem herstellerabhngigen Hayes-
Standard (auch AT-Standard genannt). Aufgrund der weiten Verbreitung
dieses Standards kann bei Einsatz eines Modems, das diesen Standard
beherrscht, davon ausgegangen werden, dass die Kommunikation mit
anderen Modems meist problemlos mglich ist. Bei der Anschaffung von
Modems der neuesten Generation sollte bedacht werden, dass die ver-
sprochenen hohen bertragungsraten oftmals nur erreicht werden knnen,
wenn Gerten desselben Herstellers auf beiden Seiten eingesetzt werden.
- Handbuch
Ein gut lesbares und ausfhrliches Handbuch ist zur schnellen Installation
und bestmglichen Konfiguration eines Modems wichtig.
- Sicherheitsmechanismen
Es gibt vielfltige Sicherheitsmechanismen, die in Modems integriert sein
knnen wie Passwortmechanismus oder Callback-Funktion. Einige
Modems bieten sogar die Mglichkeit, die bertragenen Daten zu ver-
schlsseln.
Die Anschaffung eines Modems mit Verschlsselungsoption ist vorteilhaft,
wenn regelmig bertragungen groer Datenmengen innerhalb einer
Organisation mit verstreuten Liegenschaften durchgefhrt werden sollen.
Diese Online-Verschlsselung bedingt einen geringeren organisatorischen
Aufwand als das Verschlsseln der Daten mittels Zusatzprodukten.
Generelle Aussagen zur Sicherheit der eingesetzten Algorithmen knnen
nicht gemacht werden. Fr den IT-Grundschutz bietet der DES-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Algorithmus bei entsprechendem Schlsselmanagement ausreichende

Sicherheit.
Die vielfach angebotene Callback-Funktion bietet unter Sicherheits-
gesichtspunkten den Vorteil, dass auf einfache Weise unautorisierte
Anrufer abgewiesen werden knnen (siehe auch M 5.30 Aktivierung einer
vorhandenen Callback-Option).
- Sind IT-Benutzer oder die Beschaffungsstelle ber diese Hinweise infor-
miert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.60 Sichere Administration eines Modems

Der sichere Einsatz eines Modems bedingt einige administrative Manahmen:
- Die Telefonnummer eines Modem-Zugangs darf nur den Kommuni-
kationspartnern bekanntgegeben werden, um den Zugang vor Einwhl-
versuchen zu schtzen. Sie darf nicht im Telefonverzeichnis der Organi-
sation erscheinen.
- Ist ein Modem in einen Netzserver integriert, knnen Benutzer von ihren
Arbeitsplatzrechnern auf das Modem zugreifen. Dann darf ein Zugriff auf
die Kommunikationssoftware nur den Benutzern mglich sein, die fr die
Datenbertragung berechtigt sind (siehe auch M 2.42 Festlegung der
mglichen Kommunikationspartner).
- Auerdem mssen regelmig die Einstellungen des Modems und der
Kommunikationssoftware berprft werden sowie die durchgefhrten
Datenbertragungen protokolliert werden.
- Es muss sichergestellt sein, dass das Modem die Telefonverbindung unter-
bricht, sobald der Benutzer sich vom System abmeldet. Bei einem Stand-
alone-System kann dies dadurch realisiert sein, dass das Modem nur solan-
ge mit dem Telefonnetz verbunden ist, wie es fr die Datenbertragung
eingesetzt wird, und es anschlieend ausgeschaltet bzw. von der Leitung
getrennt wird. Bei einem im Netzserver integrierten Modem muss dies ber
die Konfiguration sichergestellt werden. Ein externes Modem kann einfach
ausgeschaltet werden. Auerdem mssen alle Benutzer darauf hingewiesen
werden, dass nach der Datenbertragung auch das Kommunika-
tionsprogramm zu beenden ist.
- Es muss auerdem darauf geachtet werden, dass nach einem Zusammen-
bruch der Modem-Verbindung der externe Benutzer automatisch vom IT-
System ausgeloggt wird. Andernfalls kann der nchste Anrufer unter dieser
Benutzer-Kennung weiterarbeiten, ohne sich einzuloggen.
- Wurden die gewhlten Einstellungen daraufhin getestet, ob eine unbefugte
Nutzung des Modems wirksam verhindert ist?
- Wird die Modemverbindung getrennt, wenn der Benutzer sich abmeldet?
- Wird der Benutzer abgemeldet, wenn die Modemverbindung getrennt
wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.61 Regelung des Modem-Einsatzes

Es ist festzulegen:
- wer der Verantwortliche fr den sicheren Betrieb des Modems ist
(beispielsweise im Stand-alone Einsatz der IT-Benutzer, in vernetzten
Systemen der Administrator),
- wer das Modem benutzen darf,
- in welchen Fllen vertrauliche Informationen bei der bertragung ver-
schlsselt werden sollten,
- in welchen Fllen durchgefhrte Datenbertragungen zu protokollieren
sind (z. B. bei bermittlung personenbezogener Daten). Bietet die
Kommunikationssoftware Protokollierungsfunktion an, sollte diesen im
sinnvollen Rahmen genutzt werden.
Alle Login-Vorgnge, ob erfolgreich oder erfolglos, mssen protokolliert
werden. Korrekt eingegebene Passwrter sollten nicht mitprotokolliert
werden, es ist aber zu berlegen, die bei erfolglosen Login-Versuchen einge-
gebenen Passwrter mitzuprotokollieren, um Passwort-Attacken zu entdecken.
Indizien fr Passwort-Attacken knnen z. B. sein: hufige erfolglose Login-
Versuche fr einen Benutzer, erfolglose Login-Versuche immer vom selben
Anschluss, Versuche sich auf verschiedene Benutzernamen anzumelden wh-
rend einer Verbindung oder von einem Anschluss.
Nach dem Verbindungsaufbau muss dem Anrufenden ein Anmelde-Prompt
angezeigt werden. Dabei sollte darauf geachtet werden, dass vor der erfolg-
reichen Anmeldung mglichst wenig Informationen ber das angewhlte IT-
System weitergegeben werden. Es sollte weder die Art der eingesetzten
Hardware noch des Betriebssystems gegeben werden. Der Anmelde-Prompt
sollte den Namen des IT-Systems und/oder der Organisation enthalten, einen
Hinweis, dass alle Verbindungen protokolliert werden und eine Eingabe-
aufforderung fr Benutzername und Passwort. Bei erfolglosen Anmeldever-
suchen darf keine Ursache angezeigt werden (falscher Benutzername, falsches
Passwort).
Trennung Dial-In / Dial-Out
Fr ein- bzw. abgehende Verbindungen sollten getrennte Leitungen und
Modems benutzt werden. Ein Anrufer sollte keine Mglichkeit haben, sich
ber das angewhlte IT-System wieder nach auen verbinden zu lassen.
(Wenn dies fr Auendienstmitarbeiter unbedingt notwendig ist, muss dem
eine starke Authentisierung vorangehen, z. B. ber Chipkarten.) Ansonsten
besteht die Gefahr, dass Hacker den Zugang missbrauchen, zum einen um
teure Fernverbindungen aufzubauen und zum anderen um ihre Spuren zu ver-
wischen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beim Callback sollte fr den Rckruf ein anderes Modem oder eine andere
Leitung benutzt werden, als das anrufende Modem benutzt hat (siehe auch
M 5.44 Einseitiger Verbindungsaufbau).
- Sind allen fr die Kommunikation zugelassenen Mitarbeitern die diesbe-
zglichen Regelungen bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.62 Software-Abnahme- und Freigabe-Verfahren

Der Einsatz von IT zur Aufgabenbewltigung setzt voraus, dass die maschi-
nelle Datenverarbeitung soweit wie mglich fehlerfrei arbeitet, da die Kon-
trolle der Einzelergebnisse in den meisten Fllen nicht mehr zu leisten ist. Im
Zuge eines Software-Abnahme-Verfahrens wird deshalb berprft, ob die
betrachtete Software fehlerfrei arbeitet, das heit, ob die Software die erfor-
derliche Funktionalitt zuverlssig bereitstellt und ob sie darber hinaus keine
unerwnschten Nebeneffekte hat. Mit der anschlieenden Freigabe der Soft-
ware durch die fachlich zustndige Stelle wird die Erlaubnis erteilt, die Soft-
ware zu nutzen. Gleichzeitig bernimmt diese Stelle damit auch die Verant-
wortung fr das IT-Verfahren, dass durch die Software realisiert wird.
Bei der Software-Abnahme unterscheidet man sinnvollerweise zwischen
Software, die selbst oder im Auftrag entwickelt wurde, und Standardsoftware,
die nur fr den speziellen Einsatzzweck angepasst wird.
Abnahme von selbst- oder im Auftrag entwickelter Software
Bevor der Auftrag zur Software-Entwicklung intern oder extern vergeben
wird, muss die Anforderungsdefinition fr die Software erstellt sein, aus der
dann das Grob- und Feinkonzept fr die Realisierung entwickelt wird. Anhand
dieser Dokumente erstellt die fachlich zustndige Stelle, nicht die fr die
Software-Entwicklung zustndige Stelle, im allgemeinen einen Abnahmeplan.
blicherweise werden hierzu Testflle und die erwarteten Ergebnisse fr die
Software erarbeitet. Anhand dieser Testflle wird die Software getestet und
der Abgleich zwischen berechnetem und erwartetem Ergebnis wird als Indiz
fr die Korrektheit der Software benutzt.
Zur Entwicklung der Testflle und zur Durchfhrung der Tests ist folgendes
zu beachten:
- die Testflle werden von der fachlich zustndigen Stelle entwickelt,
- fr Testflle werden keine Daten des Wirkbetriebs benutzt,
- Testdaten, insbesondere wenn sie durch Kopieren der Wirkdaten erstellt
werden, drfen keine vertraulichen Informationen beinhalten; personen-
bezogene Daten sind zu anonymisieren oder zu simulieren,
- die Durchfhrung der Tests darf keine Auswirkungen auf den Wirkbetrieb
haben; nach Mglichkeit sollte ein logisch oder physikalisch isolierter
Testrechner benutzt werden.
Eine Abnahme ist zu verweigern, wenn:
- Schwerwiegende Fehler in der Software festgestellt werden,
- Testflle auftreten, in denen die erwarteten Ergebnisse nicht mit den
berechneten bereinstimmen,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Benutzerhandbcher oder Bedienungsanleitungen nicht vorhanden oder

von nicht ausreichender Qualitt sind und
- Dokumentation der Software nicht vorhanden oder nicht ausreichend ist.
Die Ergebnisse der Abnahme sind schriftlich festzuhalten. Die Dokumentation
des Abnahmeergebnisses sollte umfassen:
- Bezeichnung und Versionsnummer der Software und ggf. des IT-Verfah-
rens,
- Beschreibung der Testumgebung,
- Testflle und Testergebnisse und
- Abnahmeerklrung.
Abnahme von Standardsoftware
Wird Standardsoftware beschafft, so sollte auch diese einer Abnahme und
einer Freigabe unterzogen werden. In der Abnahme sollte berprft werden,
ob
- die Software frei von Computer-Viren ist,
- die Software kompatibel zu den anderen eingesetzten Produkten ist,
- die Software in der angestrebten Betriebsumgebung lauffhig ist und
welche Parameter zu setzen sind,
- die Software komplett einschlielich der erforderlichen Handbcher
ausgeliefert wurde und
- die geforderte Funktionalitt erfllt wird.
Freigabe-Verfahren
Ist die Abnahme der Software erfolgt, muss die Software fr die Nutzung
freigegeben werden. Dazu ist zunchst festzulegen, wer berechtigt ist, Soft-
ware freizugeben. Die Freigabe der Software ist schriftlich festzulegen und
geeignet zu hinterlegen.
Die Freigabeerklrung sollte umfassen:
- Bezeichnung und Versionsnummer der Software und ggf. des IT-Verfah-
rens,
- Besttigung, dass die Abnahme ordnungsgem vorgenommen wurde,
- Einschrnkungen fr die Nutzung (Parametereinstellung, Benutzerkreis,...),
- Freigabedatum, ab wann die Software eingesetzt werden darf und
- die eigentliche Freigabeerklrung.
Falls IT-technisch mglich muss verhindert werden, dass Software nach der
Freigabe verndert oder manipuliert werden kann. Andernfalls ist dies durch
eine Regelung festzulegen.
Auch nach intensiven Abnahmetests kann es vorkommen, dass im laufenden
Einsatz Fehler in der Software festgestellt werden. Fr diesen Fall ist festzu-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
legen, wie in einem solchen Fehlerfall verfahren werden soll (Ansprech-

partner, Fehlerbeseitigungsablauf, Beteiligung der fachlich zustndigen Stelle,
Wiederholung der Abnahme und Freigabe, Versionskontrolle).
Fr weiterfhrende Erklrungen siehe Kapitel 9.1 Standardsoftware.
- Gibt es fr smtliche eingesetzte Software eine Abnahme- und Freigabe-
besttigung?
- Werden Fehler auch ohne Beteiligung der fachlich zustndigen Stelle
beseitigt?
- Kann im Einsatz befindliche Software unerkannt manipuliert werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.63 Einrichten der Zugriffsrechte

Verantwortlich fr Umsetzung: Verantwortliche der einzelnen IT-
Anwendungen, Administrator
Arbeiten mit einem IT-System mehrere Benutzer, so muss durch eine ord-
nungsgeme Administration der Zugriffsrechte sichergestellt werden, dass
die Benutzer das IT-System nur gem ihren Aufgaben nutzen knnen.
Vorausgesetzt sei, dass von den Fachverantwortlichen die Zugangs- und
Zugriffsberechtigungen fr die einzelnen Funktionen festgelegt wurden (vgl.
M 2.7 Vergabe von Zugangsberechtigungen und M 2.8 Vergabe von
Zugriffsrechten). Anschlieend werden die Benutzer des IT-Systems den
einzelnen Funktionen zugeordnet. Die Ergebnisse sind schriftlich zu doku-
mentieren.
Der Administrator muss dann das IT-System so konfigurieren, dass diese
Benutzer Zugang zum IT-System erhalten und mit den ihnen zugewiesenen
Zugriffsrechten nur ihre Aufgaben wahrnehmen knnen. Bietet das IT-System
keine Mglichkeit, Zugriffsrechte zuzuweisen (z. B. beim DOS-PC mit
mehreren Benutzern), so ist ein Zusatzprodukt zu diesem Zweck einzusetzen
(vgl. z. B. M 4.41 Einsatz eines angemessenen PC-Sicherheitsproduktes).
Lsst das IT-System es zu, so sind die sinnvoll einsetzbaren Protokollfunk-
tionen zur Beweissicherung durch den Administrator zu aktivieren. Dazu
gehren erfolgreiche und erfolglose An- und Abmeldevorgnge, Fehler-
meldungen des Systems, unerlaubte Zugriffsversuche.
Fr den Vertretungsfall muss der Administrator vorab kontrollieren, ob der
Vertreter vom Fachverantwortlichen autorisiert ist. Erst dann darf er die
erforderlichen Zugriffsrechte im akuten Vertretungsfall einrichten.
- Werden die vom Administrator eingerichteten Zugriffsrechte sporadisch
berprft?
- Liegt eine Dokumentation vor, welche Rechtestruktur im IT-System reali-
siert ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.64 Kontrolle der Protokolldateien

Verantwortlich fr Umsetzung: Verantwortliche der einzelnen IT-
Anwendungen, Revisor
Die Protokollierung sicherheitsrelevanter Ereignisse ist als Sicherheits- regelmige Auswertung
der Protokollierung
manahme nur wirksam, wenn die protokollierten Daten in regelmigen durch Revisor
Abstnden durch einen Revisor ausgewertet werden. Ist es personell oder
technisch nicht mglich, die Rolle eines unabhngigen Revisors fr Proto-
kolldateien zu implementieren, kann ihre Auswertung auch durch den
Administrator erfolgen. Fr diesen Fall bleibt zu beachten, dass damit eine
Kontrolle der Ttigkeiten des Administrators nur schwer mglich ist. Das
Ergebnis der Auswertung sollte daher dem IT-Sicherheitsbeauftragten, dem
IT-Verantwortlichen oder einem anderen besonders zu bestimmenden
Mitarbeiter vorgelegt werden.
Die regelmige Kontrolle dient darber hinaus auch dem Zweck, durch die Lschung/Archivierung
der Protokolldateien
anschlieende Lschung der Protokolldaten ein bermiges Anwachsen der
Protokolldateien zu verhindern. Je nach Art der Protokolldaten kann es
sinnvoll sein, diese auf externen Datentrgern zu archivieren.
Da Protokolldateien in den meisten Fllen personenbezogene Daten bein-
halten, ist sicherzustellen, dass diese Daten nur zum Zweck der Datenschutz-
kontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemen
Betriebes verwendet werden (vgl. 14 Abs. 4 BDSG und M 2.110
Datenschutzaspekte bei der Protokollierung). Der Umfang der Protokollierung
und die Kriterien fr deren Auswertung sollte dokumentiert und innerhalb der
Organisation abgestimmt werden.
Aus verschiedenen gesetzlichen Regelungen knnen sich einerseits Fristen fr Lschung
bzw. Aufbewahrung
Mindestaufbewahrungsfristen, aber andererseits auch Hchstaufbewahrungs-
fristen an Protokolldaten ergeben. So kann durch datenschutzrechtliche
Regelungen eine Lschung erforderlich sein (siehe dazu auch M 2.110
Datenschutzaspekte bei der Protokollierung).
Fr bestimmte Protokolldaten gelten aber unter Umstnden gesetzliche
Mindestaufbewahrungsfristen, z. B. wenn sie Aufschluss ber
betriebswirtschaftliche Vorgnge geben. Diese Fristen mssen auf jeden Fall
eingehalten werden. Vor der Lschung von Protokolldaten ist daher sorgfltig
zu prfen, ob entsprechende Rechtsvorschriften zu beachten sind und ggf.
welche Aufbewahrungsfristen sich daraus ergeben. Hierbei sollte die
Rechtsabteilung beteiligt werden.
Die nachfolgenden Auswertungskriterien dienen als Beispiele, die Hinweise
auf eventuelle Sicherheitslcken, Manipulationsversuche und Unregelmig-
keiten erkennen lassen:
- Liegen die Zeiten des An- und Abmeldens auerhalb der Arbeitszeit
(Hinweis auf Manipulationsversuche)?
- Hufen sich fehlerhafte Anmeldeversuche (Hinweis auf den Versuch,
Passwrter zu erraten)?
- Hufen sich unzulssige Zugriffsversuche (Hinweis auf Versuche zur
Manipulation)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gibt es auffllig groe Zeitintervalle, in denen keine Protokolldaten aufge-

zeichnet wurden (Hinweis auf eventuell gelschte Protokollstze)?
- Ist der Umfang der protokollierten Daten zu gro (eine umfangreiche
Protokolldatei erschwert das Auffinden von Unregelmigkeiten)?
- Gibt es auffllig groe Zeitintervalle, in denen anscheinend kein
Benutzerwechsel stattgefunden hat (Hinweis darauf, dass das konsequente
Abmelden nach Arbeitsende nicht vollzogen wird)?
- Gibt es auffallend lange Verbindungszeiten in ffentliche Netze hinein
(vgl. G 4.25 Nicht getrennte Verbindungen)?
- Wurde in einzelnen Netzsegmenten oder im gesamten Netz eine auffllig
hohe Netzlast oder eine Unterbrechung des Netzbetriebes festgestellt
(Hinweis auf Versuche, die Dienste des Netzes zu verhindern bzw. zu
beeintrchtigen oder auf eine ungeeignete Konzeption bzw. Konfiguration
des Netzes)?
Bei der Auswertung der Protokolldateien sollte besonderes Augenmerk auf
alle Zugriffe gelegt werden, die unter Administratorkennungen durchgefhrt
wurden.
Wenn regelmig umfangreiche Protokolldateien ausgewertet werden mssen,
ist es sinnvoll, ein Werkzeug zur Auswertung zu benutzen. Dieses Werkzeug
sollte whlbare Auswertungskriterien zulassen und besonders kritische
Eintrge (z. B. mehrfacher fehlerhafter Anmeldeversuch) hervorheben.
Das oben Gesagte gilt analog auch fr die Erhebung von Auditdaten, da es
sich dabei im Prinzip nur um die Protokollierung sicherheitskritischer
Ereignisse handelt.
- Wer wertet die Protokolldateien aus? Findet das Vier-Augen-Prinzip
Anwendung?
- Knnen die Aktivitten des Administrators ausreichend kontrolliert
werden?
- Wird das IT-Sicherheitsmanagement bei Aufflligkeiten unterrichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.65 Kontrolle der Wirksamkeit der Benutzer-

Trennung am IT-System
Verantwortlich fr Umsetzung: Revisor, Administrator, IT-Sicherheitsmana-
gement
Mittels Protokollauswertung oder durch Stichproben ist in angemessenen
Zeitabstnden zu berprfen, ob die Benutzer des IT-Systems sich regelmig
nach Aufgabenerfllung abmelden oder ob mehrere Benutzer unter einer Ken-
nung arbeiten.
Sollte festgestellt werden, dass tatschlich mehrere Benutzer unter einer Ken-
nung arbeiten, sind sie auf die Verpflichtung zum Abmelden nach Aufgaben-
erfllung hinzuweisen. Gleichzeitig sollte der Sinn dieser Manahme erlutert
werden, die im Interesse des einzelnen Benutzers liegt.
Stellt sich heraus, dass die An- und Abmeldevorgnge zu zeitintensiv sind und
trotz Aufforderung nicht akzeptiert werden, sollten alternative Manahmen
diskutiert werden wie zum Beispiel:
- Zuordnung des IT-Systems zu einem Benutzer fr bestimmte Zeitinter-
valle, in denen andere Benutzer das IT-System nicht nutzen drfen. Dies
setzt voraus, dass der Arbeitsprozess dementsprechend zeitlich variabel ist.
- Anschaffung zustzlicher IT-Systeme, mit denen die quasiparallele Arbeit
an einem IT-System vermieden werden kann. Zu beachten ist, dass zwar
die Anschaffungskosten fr die zustzlichen IT-Systeme anfallen, aber an-
dererseits die Anschaffungskosten fr PC-Sicherheitsprodukte entfallen
knnen. Anstelle des Bausteins 5.4 DOS-PC mit wechselnden Benutzern
ist dann die Umsetzung empfohlener Grundschutzmanahmen eines ande-
ren Bausteins, z. B. 5.1 DOS-PC (ein Benutzer), erforderlich.
- Sollten sich die Datenbestnde der einzelnen Benutzer separieren lassen
(beispielsweise Benutzer A bearbeitet die Daten A-L, Benutzer B die Da-
ten M-Z), so knnen dafr unterschiedliche Zugriffsrechte eingerumt
werden. Will ein Benutzer dann mit seinen Daten arbeiten, muss er sich
zuvor beim System anmelden, da seine Kollegen kein Zugriffsrecht auf
diese Daten besitzen.
- Wie hufig wird der ordnungsgeme Benutzerwechsel geprft?
- Gibt es Akzeptanzprobleme bezglich des Benutzerwechsels?
- Lassen sich die Datenbestnde separieren?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.66 Beachtung des Beitrags der Zertifizierung fr

die Beschaffung
Bei der Beschaffung von IT-Produkten und IT-Systemen muss frhzeitig fest-
gelegt werden, ob die bloe Zusicherung des Herstellers oder Vertreibers ber
implementierte Sicherheitsfunktionen als ausreichend vertrauenswrdig aner-
kannt werden kann. Insbesondere bei einem hohen oder sehr hohen Schutz-
bedarf kann die Vertrauenswrdigkeit der Produkte in Hinblick auf IT-
Sicherheit nur dadurch gewhrleistet werden, dass unabhngige Prfstellen die
Produkte untersuchen und bewerten (evaluieren).
Allgemein anerkannte Grundlage dieser Evaluierungen bilden seit 1991 die
europaweit harmonisierten "Kriterien fr die Bewertung der Sicherheit von
Systemen der Informationstechnik (ITSEC)" und das Evaluationshandbuch
ITSEM und seit 1998 die weltweit angestimmten "Gemeinsamen Kriterien fr
die Prfung und Bewertung der Sicherheit von Informationstechnik" /
Common Criteria (CC). In Deutschland fhren das BSI selbst und vom BSI
akkreditierte Prfstellen solche Evaluationen durch. Bei positivem Evalu-
ationsergebnis und bei Einhaltung der Rahmenbedingungen von ITSEC und
ITSEM bzw. der Common Criteria wird fr das untersuchte Produkt oder
System vom BSI als Zertifizierungsstelle ein Sicherheitszertifikat erteilt.
Aus dem dazugehrenden Zertifizierungsreport geht hervor, welche Funk-
tionalitt mit welcher Prftiefe untersucht wurde und welche Bewertung vor-
genommen wurde. Dabei reichen die Prftiefe von Evaluationsstufe E 1
(geringste Prftiefe) bis Evaluationsstufe E 6 (hchste Prftiefe) bei den
ITSEC bzw. von Vertrauenswrdigkeitsstufe EAL 1 (geringste Prftiefe) bis
Vertrauenswrdigkeitsstufe EAL 7 (hchste Prftiefe) bei den CC. Dabei
entspricht die Evaluationsstufe E 1 der ITSEC in etwa der Vertrauenswrdig-
keitsstufe EAL 2 der CC usw. Zustzlich wird die geprfte Mechanismen-
strke der Implementation der Sicherheitsfunktionen angegeben, die ein Ma
darstellt fr den Aufwand, den man zum berwinden der Sicherheits-
funktionen aufbringen muss. ITSEC und CC unterscheiden hier die Mecha-
nismenstrken niedrig, mittel und hoch. Darber hinaus werden Hinweise
gegeben, welche Randbedingungen beim Einsatz des Produktes beachtet
werden mssen.
Stehen bei der IT-Beschaffung mehrere Produkte mit angemessenem Preis-
/Leistungsverhltnis zur Auswahl, so kann ein eventuell vorhandenes Sicher-
heitszertifikat als Auswahlkriterium positiv bercksichtigt werden. Hierbei
sollten Sicherheitszertifikate insbesondere dann bercksichtigt werden, wenn
der evaluierte Funktionsumfang die Mindestfunktionalitt (weitestgehend)
umfasst und die Mechanismenstrke dem Schutzbedarf entspricht (vgl. M 4.41
Einsatz eines angemessenen PC-Sicherheitsproduktes). Je hher dann die im
Zertifikat angegebene Prfungstiefe ist, desto mehr Vertrauen in Wirksamkeit
und Korrektheit der Sicherheitsfunktionen kann dem Produkt entgegen-
gebracht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Zertifizierungsstellen geben regelmig bersichten heraus, welche Pro-

dukte ein Zertifikat erhalten haben. Eine Zusammenstellung der vom BSI
zertifizierten IT-Produkte und -Systeme kann beim BSI angefordert werden:
BSI 7148 - BSI-Zertifikate. Weiterhin verffentlicht das BSI neu erteilte Zer-
tifikate in der Zeitschrift KES, Zeitschrift fr Kommunikations- und EDV-
Sicherheit. Diese Informationen lassen sich ebenfalls vom BSI-Server abrufen.
- Sind die IT-Beschaffungsstellen/-mter ber den Beitrag der Eva-
luation/Zertifizierung unterrichtet worden?
- Sind fr die Beschaffungsstelle/-mter aktuelle bersichten ber zerti-
fizierte Produkte verfgbar?
- Werden von der Beschaffungsstelle die relevanten Zertifizierungsreports
angefordert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.67 Festlegung einer Sicherheitsstrategie fr Peer-

to-Peer-Dienste
Bevor mit der eigentlichen Konfiguration und Installation von Peer-to-Peer-
Diensten begonnen werden kann, mssen zuerst einige grundlegende ber-
legungen angestellt werden:
Zunchst muss geklrt werden, welche Dienstleistung das jeweilige Betriebs- Werden Peer-to-Peer-
Dienste wirklich
system erbringen und in welchem Rahmen es diesbezglich eingesetzt werden bentigt?
soll. Insbesondere ist zu klren, ob berhaupt Peer-to-Peer-Funktionalitten,
d. h. die Freigabe von Ressourcen, wie Verzeichnisse oder Drucker, auf einem
Arbeitsplatz-Computer, verwendet werden sollen.
Dies soll anhand einiger Beispiele veranschaulicht werden:
- Das IT-System wird fr eine Arbeitsgruppe von typischerweise drei bis
fnf Benutzern eingesetzt, bei denen jeder alle Rechte besitzen sollte. An
jedem Arbeitsplatz soll die komplette Peer-to-Peer-Funktionalitt unter-
sttzt werden.
- Das IT-System wird fr eine grere Arbeitsgruppe eingesetzt, in der
unterschiedliche Rechte vergeben werden knnen. Die Peer-to-Peer-Funk-
tionalitt soll aufgrund konkreter Anforderungen in eingeschrnkter Form
realisiert werden.
- Das IT-System wird in einem servergesttzten Netz eingesetzt, bei dem auf
die Peer-to-Peer-Funktionalitt zum Austausch von Daten in der Regel
verzichtet werden kann. Einzelne Drucker sollen jedoch ber Peer-to-Peer-
Funktionalitt gemeinsam benutzt werden knnen.
- Das IT-System wird in einem servergesttzten Netz eingesetzt, in dem
keine Peer-to-Peer-Funktionalitt vorgesehen ist. Dann sind alle Peer-to-
Peer-Dienste zu deaktivieren. In diesem Fall kann die Betrachtung der
folgenden Punkte entfallen, doch sollte dann die Manahme M 5.37
Einschrnken der Peer-to-Peer-Funktionalitten in einem servergesttzten
Netz beachtet werden.
Hinweis:
Servergesttzte Netze bieten wesentlich weitgehendere Sicherheitsfunktio-
nalitten als Peer-to-Peer-Netze. Darber hinaus entstehen durch die Verwen-
dung von Peer-to-Peer-Diensten in servergesttzten Netzen zustzliche
Sicherheitsprobleme. Deshalb sollte bei servergesttzten Netzen auf die
Verwendung von Peer-to-Peer-Funktionalitten verzichtet werden.
Sofern Peer-to-Peer-Dienste verwendet werden sollen, mssen anschlieend
diese berlegungen in eine Sicherheitsstrategie bersetzt werden.
Dabei zeigt sich, dass je nach bereits vorhandener Systemumgebung und
Organisationsstruktur sowie der vorzusehenden Restriktionen an die Peer-to-
Peer-Funktionalitten, ein mehr oder weniger groer Aufwand bei der Ent-
wicklung einer dazu passenden Sicherheitsstrategie notwendig ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es wird nachfolgend eine methodische Vorgehensweise aufgezeigt, mittels

derer eine umfassende Sicherheitsstrategie fr den Einsatz von Peer-to-Peer-
Diensten entwickelt werden kann. Da jedoch Peer-to-Peer-Dienste in ver-
schiedenen Konfigurationen eingesetzt werden knnen, ist fr die jeweilige
Ausprgung individuell zu entscheiden, welche der beschriebenen Schritte
anzuwenden sind.
In der Sicherheitsstrategie sollte aufgezeigt werden, wie Peer-to-Peer-Dienste
sicher installiert, administriert und betrieben werden. Nachfolgend werden die
einzelnen Entwicklungsschritte einer solchen Strategie vorgestellt:
1. Definition der Peer-to-Peer-Netzstruktur
Eine Peer-to-Peer-Netzstruktur wird definiert durch die Festlegung,
- welche Rechner als "Fileserver" (sie drfen Verzeichnisse freigeben),
- welche Rechner als "Druckserver" (sie drfen Drucker freigeben),
- welche Rechner als "Applikationsserver" fr bestimmte IT-Anwendungen
(Bei WfW sind das z. B. Mail, Schedule+, Fax. Sie sollten stndig verfg-
bar sein.) und
- welche Rechner nur als Clients (sie knnen sich nur mit anderen Rechnern
verbinden)
fungieren sollen. Dabei ist darauf zu achten, dass die Kapazitt der "Server"
den jeweiligen Anforderungen hinsichtlich Geschwindigkeit und Platten-
speicherplatz gengt. Auerdem sollte auch die Anzahl der "Server" auf das
notwendige Ma beschrnkt werden. Darber hinaus sollten keine Applika-
tionen auf "Server" ausgelagert werden, bei denen stndig groe Datenmengen
ber das Netz bertragen werden mssen, da dies zu Netzberlastungen fhren
kann.
2. Regelung der Verantwortlichkeiten
Peer-to-Peer-Dienste sollten mittels eines geschulten Administrators nebst
Stellvertreter sicher betrieben werden. Diese allein drfen Sicherheitspara-
meter der Peer-to-Peer-Funktionalitten verndern. Sie sind z. B. dafr
zustndig, auf eventuellen "Applikationsservern" oder "Fileservern" den ent-
sprechenden Verantwortlichen Administrationsrechte und -werkzeuge zur
Verfgung zu stellen, damit diese die Freigabe der von anderen bentigten
Verzeichnisse bzw. Anwendungen vornehmen knnen.
Auch in einem servergesttzten Netz, in dem zustzlich Peer-to-Peer-Funktio- Administratoren
benennen
nalitten zugelassen werden sollen, mssen explizit Peer-to-Peer-Administra-
toren ernannt werden, die aber mit den Netzadministratoren identisch sein
drfen.
Die Verantwortlichkeiten der einzelnen Benutzer beim Einsatz von Peer-to-
Peer-Diensten sind unter Schritt 7 dargestellt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Einschrnkung der Freigabemglichkeiten

Windows fr Workgroups:
Mit dem Administrationswerkzeug ADMINCFG.EXE fr WfW knnen die
folgenden Mglichkeiten fr jeden WfW-Rechner einzeln zugelassen oder
gesperrt werden:
- Freigabe von Verzeichnissen,
- Freigabe von Druckern,
- Restriktionen fr das WfW-Anmeldepasswort (Ablaufzeit, Mindestlnge
etc.),
- Freigabe von Netz-DDE (z. B. fr den Datenaustausch ber die Ablage-
mappe oder das Telefonieren unter WfW).
Die Datei ADMINCFG.EXE gehrt zwar zum Lieferumfang von WfW, wird
aber nicht standardmig auf den Rechnern installiert. Eine Dokumentation
erfolgt nur in den Anleitungen fr Systemverwalter (siehe M 4.45 Einrichtung
einer sicheren Peer-to-Peer-Umgebung unter WfW).
Es ist festzulegen, auf welchen Rechnern dieses Administrationswerkzeug
installiert werden soll.
Dieses Programm verfgt ber eine Passwortabfrage, mit der die eingestellte
Konfiguration geschtzt wird. Jeder, der Zugriff auf dieses Programm hat,
kann versuchen, das Passwort der jeweiligen Konfigurationsdatei herauszu-
finden und dann die Freigabeoptionen zu ndern.
Sinnvollerweise sollte es daher nur dem Administrator und seinem Stellver-
treter zur Verfgung gestellt werden. Darber hinaus ist es unter WfW
mglich, die Konfigurationsdateien zentral auf einem Server abzulegen, und
zwar entweder fr jeden Benutzer einzeln, fr Gruppen oder fr alle Benutzer
gemeinsam. Weitere Informationen hierzu finden sich im WfW Resource Kit,
Addendum for Operating System Version 3.11. Dies hat den Vorteil, nderun-
gen fr mehrere WfW-Benutzer gleichzeitig vornehmen zu knnen, insbeson-
dere wenn das Passwort der Konfigurationsdatei(en) gendert werden soll.
Hinweis: Eine durch ein Passwort geschtzte Konfiguration bietet nur einge-
schrnkte Sicherheit, da sie einem vorstzlichen Angriff kaum standhlt. Die
Einschrnkung der WfW-Funktionalitt beugt damit in erster Linie dem unbe-
absichtigten Fehlverhalten der Benutzer vor.
Windows 95:
Die Mglichkeit zur Freigabe von Verzeichnissen bzw. Druckern lsst sich
unter Windows 95 fr einzelne Rechner und/oder Benutzer durch entspre-
chende Eintrge in deren Profile einschrnken (siehe auch M 4.58 Freigabe
von Verzeichnissen unter Windows 95).
Windows NT/2000:
Unter Windows NT/2000 ist die Mglichkeit der Freigabe von Verzeichnissen
auf Administratoren bzw. Hauptbenutzer eingeschrnkt, so dass hier einem
Missbrauch durch Endbenutzer vorgebeugt ist. Ob und ggf. welche Ressour-
cen freigegeben werden sollen, ist bei der Planung des Netzes im Detail fest-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zulegen (siehe M 2.94 Freigabe von Verzeichnissen unter Windows NT und

M 4.149 Datei- und Freigabeberechtigungen unter Windows).
Unix bzw. Linux:
Auf IT-Systemen unter Unix oder Linux knnen Peer-to-Peer-Dienste durch
eine Reihe von Mechanismen bereitgestellt werden. Die wichtigsten Beispiele
sind NFS-Shares, SAMBA und durch den Daemon inetd bereitgestellte
Dienste. Durch geeignete Rechtevergabe (siehe auch M 4.19 Restriktive
Attributvergabe bei Unix-Systemdateien und -verzeichnissen) muss sicher-
gestellt werden, dass Benutzer die systemweiten Konfigurationsdaten
(beispielsweise /etc/inetd.conf) nicht modifizieren knnen. Anderenfalls
besteht die Gefahr, dass Benutzer zustzliche privilegierte Dienste aktivieren,
wodurch Sicherheitslcken entstehen knnen (siehe auch M 5.72 Deaktivieren
nicht bentigter Netzdienste).
Bestimmte Netzdienste knnen unter Unix bzw. Linux auch ohne Supervisor-
Rechte gestartet werden, in der Regel jedoch mit eingeschrnkter Funktiona-
litt. Dies kann nur dadurch verhindert werden, dass dem Benutzer der Zugriff
auf die entsprechenden Daemons verweigert wird. Auch auf Entwicklungs-
werkzeuge (z. B. Compiler) sollten Benutzer nur dann zugreifen knnen,
wenn sie sie zwingend bentigen (siehe auch M 2.9 Nutzungsverbot nicht
freigegebener Hard- und Software).
4. Festlegung einer Namenskonvention
Um eine Maskerade zu erschweren, sollten eindeutige Namen fr die Rechner, Eindeutige Namen fr
Rechner und Benutzer
Benutzergruppen und die Benutzer verwendet werden. Diese Namen sind vergeben
allen Benutzern bekannt zu geben. Erfolgt nun eine Anmeldung unter einem
Namen, den es nach der Konvention nicht geben kann, z. B. indem er einem
bestehenden nur hnlich ist, wird eine Maskerade offensichtlich. Eine Anmel-
dung unter einem bereits angemeldeten Rechnernamen wird von WfW
abgewiesen, jedoch ist eine Maskerade unter einem zugelassenen Namen dann
mglich, wenn der betreffende Anwender nicht angemeldet ist.
Unter Windows 95 ist durch die Systemrichtlinien sicherzustellen, dass die
Benutzer weder Rechner- noch Benutzernamen selbststndig ndern knnen.
Dazu sollte fr Standardbenutzer der Zugriff auf die Systemsteuerungsoption
Netzwerk deaktiviert werden (siehe auch M 2.103 Einrichten von
Benutzerprofilen unter Windows 95).
Unter Windows NT/2000 sind nur die vom Administrator definierten Benutzer
zugelassen und es knnen nur Administratoren den Rechnernamen ndern.
Allerdings knnen Benutzer versuchen, sich ber die Option Verbinden Als
unter Netzlaufwerk verbinden unter anderem Benutzernamen anzumelden.
Zustzlich knnen Namenskonventionen fr die Freigabenamen von Ver- Namenskonventionen fr
Freigabenamen
zeichnissen oder Druckern eingefhrt werden. Sollen keine Rckschlsse auf
den Inhalt des Verzeichnisses mglich sein, sind entsprechende Pseudonyme
zu verwenden. Soll eine unter Windows freigegebene Ressource nicht als
solche erkennbar sein, ist dem Freigabenamen das Zeichen "$" anzuhngen.
Letzteres empfiehlt sich immer dann, wenn Verzeichnisse nur zum bilateralen
Austausch von Informationen zwischen zwei Anwendern freigegeben werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei korrekter Rechtevergabe knnen Benutzer von IT-Systemen unter Unix

oder Linux weder die IP-Adresse noch den Rechnernamen ndern. hnlich
wie unter Windows NT/2000 knnen sie jedoch bei der Anmeldung an einem
anderen IT-System einen beliebigen Benutzernamen whlen.
5. Festlegung freizugebender Verzeichnisse bzw. Drucker und Vergabe
der Zugriffsrechte
Fr die "Applikationsserver" ist festzulegen, welche Verzeichnisse (z. B. das
Post-Office-Verzeichnis AGPO unter dem WfW-Programm Mail) fr den
Betrieb freizugeben sind. Fr die "Fileserver" sind diejenigen Verzeichnisse
auszuwhlen, die den Benutzern zur Verfgung gestellt werden sollen. Unter
WfW und Windows 95 knnen beliebige Benutzer Ressourcen fr den Netz-
zugriff freigeben, unter Windows NT/2000 ist dies nur den Administratoren
bzw. Hauptbenutzern erlaubt.
Dabei muss zwischen zwei Zugriffsmodellen unterschieden werden:
- der Sicherheit auf Freigabeebene (Share Level Security), bei der die
Zugriffe auf freigegebene Ressourcen ber Passwrter kontrolliert werden,
und
- der Sicherheit auf Benutzer-Ebene (User Level Security), bei der die
Zugangs- und Zugriffskontrolle eines Server-Betriebssystems genutzt
werden.
WfW untersttzt nur das erste dieser Modelle, Windows NT/2000 (als Client)
das zweite, whrend Windows 95 ber die Registerkarte Zugriffssteuerung der
Systemsteuerungsoption Netzwerk die Auswahl zwischen beiden Modellen
gestattet.
Bei Verwendung der Sicherheit auf Freigabeebene sind fr die freigegebenen
Verzeichnisse Zugriffsrechte (Lese- oder Lese-/Schreibrecht) zu definieren
und geeignete Passwrter auszuwhlen.
Durch die gezielte Weitergabe dieser Passwrter an einzelne Benutzer werden Zugriff hat, wer das
Passwort kennt!
nunmehr die Zugriffsrechte im Peer-to-Peer-Netz vergeben. Diese Passwrter
sind nur soweit erforderlich bekannt zu geben, da die Rcknahme der Freigabe
fr eine einzelne Person nur durch einen aufwendigen Passwortwechsel fr
alle anderen noch berechtigten Benutzer vorgenommen werden kann.
Bei Verwendung der Sicherheit auf Benutzer-Ebene unter Windows NT/2000
und Windows 95 werden die Zugriffsrechte dagegen explizit einzelnen
Benutzern und/oder Gruppen zugewiesen, so dass in diesem Fall die Eingabe
von Passwrtern entfllt. Dies setzt die Einbindung der Clients in eine
Arbeitsgruppe bzw. eine Domne zusammen mit wenigstens einem
Windows NT/2000-System voraus. Die Verwendung der Sicherheit auf
Freigabeebene ist in diesem Fall zu vermeiden, da sie einen wesentlich gerin-
geren Schutz bietet. Anschlieend ist zu entscheiden, ob die Verzeichnisse
automatisch beim Start des jeweiligen Servers freigegeben und ob sie automa-
tisch beim Start des zugreifenden Rechners verbunden werden sollen.
Das zuvor Gesagte gilt analog fr die Freigabe von Druckern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Unter Unix oder Linux ist nicht nur festzulegen, welche Ressourcen (z. B. Ressourcen und
Verzeichnisse oder Drucker) im Netz zur Verfgung gestellt werden sollen, Protokolle festlegen
sondern auch, ber welche Protokolle der Zugriff erfolgen soll. Dateien oder
Verzeichnisse knnen unter Unix beispielsweise via FTP, NFS oder SAMBA
fr die gemeinsame Nutzung bereitgestellt werden. Letzteres erlaubt auch
Windows-Systemen den Zugriff auf die Ressourcen, ohne dass dort zustz-
liche Software-Komponenten installiert werden mssten. Gngige Methoden
zur Bereitstellung von Druckdiensten unter Unix sind das LPR-Protokoll und
SAMBA.
Unter Unix untersttzen alle gngigen Netzdienste eine benutzerspezifische
Zugriffskontrolle. Diese sollte aktiviert und genutzt werden, sofern nicht alle
Benutzer im Netz unbeschrnkten Zugriff auf die Ressourcen haben sollen.
Beim Einsatz von SAMBA sollte die Einstellung security=share auf jeden
Fall vermieden werden (siehe auch M 5.82 Sicherer Einsatz von SAMBA).
6. Passwortwechselstrategie
Windows fr Workgroups:
Im WfW-Netz werden eine Reihe von Passwrtern gebraucht: die Anmelde-
passwrter, das Passwort fr den Aufruf von ADMINCFG.EXE und die
Passwrter fr die verschiedenen Rechte freigegebener Verzeichnisse,
Drucker und Ablagemappen. Die Anmeldepasswrter und das Passwort fr
den Aufruf von ADMINCFG.EXE sollten regelmig gewechselt werden
(siehe auch M 2.11 Regelung des Passwortgebrauchs). Eine maximale
Gltigkeitsdauer dieser Passwrter ist daher festzulegen. Damit auch der
Wechsel des ADMINCFG.EXE-Passwortes einfach mglich ist, knnen die
zugehrigen Konfigurationsdateien zentral auf einem Server hinterlegt
werden. Da ein Wechsel der Freigabe-Passwrter mit erheblichem organisa-
torischen Aufwand (siehe Nr. 5) verbunden sein kann, ist vorab festzulegen,
wie oft diese gewechselt und wie die neuen Passwrter den Betroffenen
bekannt gegeben werden sollen.
Windows 95:
Unter Windows 95 hngt die Anzahl der zu verwendenden Passwrter davon
ab, ob als Zugriffsmodell die Sicherheit auf Benutzer-Ebene oder die Sicher-
heit auf Freigabeebene verwendet wird. Im ersten Fall werden, analog zur
Situation bei Windows NT/2000, nur die Anmeldepasswrter zu den Rechnern
bentigt, die Ressourcen fr den Netzzugriff freigegeben haben. Dagegen
werden im zweiten Fall, hnlich wie bei WfW, auch Passwrter fr den
Zugriff auf freigegebenen Ressourcen bentigt. Eigene Passwrter zur
Verwaltung der Peer-to-Peer-Funktionalitt entfallen, da diese hier ber
Benutzerprofile gesteuert wird.
Der Zugriffsschutz auf Benutzer-Ebene basiert auf den Benutzerlisten, die auf Zugriffsschutz auf
Benutzer-Ebene
Windows NT/2000 oder Novell Netware Servern gefhrt werden, und kann
daher auch nur in solchen Netzen realisiert werden. Dieses Zugriffsmodell
bietet die grere Sicherheit und sollte daher vorzugsweise eingesetzt werden,
wenn trotz einer Vernetzung ber Windows NT/2000 oder Novell Netware
Server Peer-to-Peer-Funktionalitten eingesetzt werden sollen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Windows NT/2000:
Unter Windows NT/2000 erfolgt die Verwaltung der Peer-to-Peer-Funktiona-
litt unter der Kontrolle der allgemeinen Zugangs- und Zugriffskontrolle, so
dass hier keine eigenen Passwrter fr diese Verwaltungsttigkeiten erforder-
lich sind. Zur Verwaltung der Zugangspasswrter der betreffenden Benutzer
sollten die Vorgaben der Manahme M 2.11 Regelung des Passwortgebrauchs
Unix bzw. Linux:
Werden Ressourcen unter Unix oder Linux ber mehr als ein Protokoll im inkonsistente Passwort-
Datenbanken
Netz zur Verfgung gestellt, so werden dabei u. U. unterschiedliche Passwort-
Datenbanken verwendet (z. B. NIS, /etc/passwd und smb.passwd). Diese soll-
ten entweder manuell oder mit Hilfe geeigneter Administrations-Tools
synchronisiert werden. Inkonsistente Inhalte in den Passwort-Datenbanken
fhren mglicherweise zu Verwirrung bei den Benutzern und sollten daher
vermieden werden.
7. Verantwortlichkeiten fr Benutzer im Peer-to-Peer-Netz
Neben der Wahrnehmung der Peer-to-Peer-Managementaufgaben (siehe
Nr. 2) mssen weitere Verantwortlichkeiten festgelegt werden. Es ist festzu-
legen, welche Verantwortung die einzelnen Benutzer der Peer-to-Peer-Dienste
bernehmen mssen. Dies knnen zum Beispiel Verantwortlichkeiten sein fr
- die Auswertung der Protokolldateien auf den einzelnen Rechnern,
- die Vergabe von Zugriffsrechten,
- das Hinterlegen und den Wechsel von Passwrtern und
- die Durchfhrung von Datensicherungen.
8. Schulung
Abschlieend muss festgelegt werden, welche Peer-to-Peer-Benutzer zu
welchen Punkten geschult werden mssen. Erst nach ausreichender Schulung
kann der Wirkbetrieb aufgenommen werden.
Die so entwickelte Sicherheitsstrategie ist zu dokumentieren und im erforder-
lichen Umfang den Benutzern der Peer-to-Peer-Dienste mitzuteilen.
- Wird die Sicherheitsstrategie an Vernderungen im Einsatzumfeld ange-
passt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.68 Sicherheitskontrollen durch die Benutzer beim

Einsatz von Peer-to-Peer-Diensten
Da beim Einsatz von Peer-to-Peer-Diensten die wesentlichen Sicherheits-
eigenschaften lediglich dezentral kontrolliert werden knnen, obliegt es dem
einzelnen Benutzer, solche Sicherheitskontrollen durchzufhren. In geeigneten
Abstnden sollten daher von den Benutzern folgende Kontrollen durchgefhrt
werden:
- Kontrolle aktiver Verbindungen: Es sollte berprft werden, welcher
Rechner aktuell Zugriff auf den eigenen Rechner hat und wie die Art des
Zugriffs erfolgt. Hierzu kann
- unter WfW das Programm Netzwerkmonitor in der Programmgruppe
Netzwerk,
- unter Windows 95 das optional installierbare Programm Netzwerk-
monitor in der Programmgruppe Zubehr\Systemprogramme,
- unter Windows NT die Systemsteuerungsoption Server und
- unter Windows 2000 das MMC-Snap-in Freigegebene Ordner
(Sitzungen und Geffnete Dateien)
verwendet werden.
Beispiel:
Erkennbar sind die vom Rechner MUSTER aufgebauten Verbindungen. Dabei

bedeutet:
INFOS Es wird auf das Verzeichnis INFOS schreibend zugegriffen.
TEMP Es wird auf das Verzeichnis TEMP lesend zugegriffen.
HP$ Auf den lokalen Drucker mit dem Namen HP$ wird
zugegriffen.
CLIPSRV/SYSTEM Eine Verbindung zur Ablagemappe wurde hergestellt.
CLIPSRV/$SEITE12 Auf die Seite mit Namen SEITE12 der Ablagemappe wird
zugegriffen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Zeigt sich dabei, dass ein Rechner unberechtigt auf ein Verzeichnis oder
den Drucker zugreift, ist die Freigabe rckgngig zu machen. Eventuelle
Druckjobs knnen ber den Druckmanager abgebrochen werden. Im
Ereignisprotokoll (siehe nchste Grafik) werden die entsprechenden
Aktionen dokumentiert. Zeigt sich, dass unberechtigt auf die Ablagemappe
zugegriffen wird, ist ebenfalls zu trennen, jedoch empfiehlt es sich vorher
mit der Druck-Taste den Fensterinhalt des Netzwerkmonitors in die
Zwischenablage zu kopieren, da Zugriffe auf die Ablagemappe nicht
- Kontrolle der Protokolldaten: Sind auf einem Rechner Ressourcen
freigegeben, sollte das Ereignisprotokoll aktiviert und regelmig
ausgewertet werden. Die entsprechenden Optionen finden sich
- unter WfW in der Programmgruppe Systemsteuerung unter Netzwerk
bzw. in der Programmgruppe Netzwerk unter Netzwerkmonitor,
- unter Windows NT in der Programmgruppe Verwaltung unter
Benutzer-Manager bzw. unter Ereignisanzeige und
- unter Windows 2000 in den MMC-Snap-ins Gruppenrichtlinien und
Ereignisanzeige.
Windows 95 bietet standardmig keine Mglichkeit zur Ereignis-
protokollierung. Daher sollte unter Windows 95 der Netzwerkmonitor
offen gehalten werden, falls trotz dieser Schwachstelle die Peer-to-Peer-
Funktionalitten genutzt werden sollen.
Es sollte regelmig, beispielsweise wchentlich, berprft werden, ob Protokolle auswerten
sich unberechtigte Benutzer mit freigegebenen Verzeichnissen verbunden
hatten, ob es fehlerhafte Versuche zum Verbinden freigegebener
Verzeichnisse gab oder ob das System zu ungewhnlichen Zeiten gestartet
wurde. Da diese Protokolldaten auch personenbezogene Daten beinhalten,
sind sie nach ihrer Auswertung, wenn die Notwendigkeit der Speicherung
nicht mehr besteht, zu lschen.
Beispiel fr ein mgliches Ereignisprotokoll:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Kontrolle automatisch freigegebener Ressourcen: Sporadisch sollten

WfW- und Windows 95-Benutzer berprfen, welche ihrer Ressourcen
automatisch nach dem Systemstart ohne ihre direkte Beteiligung freigege-
ben werden. Dies kann zum Beispiel dadurch erfolgen, dass sie nach
Systemstart kontrollieren, welche Verzeichnisse, Drucker und Seiten der
Ablagemappe dann freigegeben sind. Ggf. ist die Freigabe zurckzu-
nehmen. Unerklrliche Unregelmigkeiten, wie die automatische Freigabe
eines Verzeichnisses, das der Benutzer selbst nie freigegeben hat, sind dem
Administrator zu melden. Es kann sich hier um Hinweise auf Trojanische
Pferde handeln, die unbemerkt Verzeichnisse freigeben.
Besteht Unsicherheit darber, ob oder was freigegeben wurde, sollte unter
WfW die Datei shares.pwl gelscht werden, die die Eintrge fr die auto-
matische Freigabe enthlt. Unter Windows 95 sind die Freigaben mit Hilfe
des Explorers zurckzunehmen. Dieses Problem stellt sich unter
Windows NT/2000 nicht, da hier nur Administratoren bzw. Hauptbenutzer
Ressourcen freigeben drfen.
Eine Kontrolle der Rechtevergabe ist in einem Peer-to-Peer-Netz unter WfW: Zugriffsrechte sind
schwierig zu prfen
WfW nicht auf direktem Wege mglich, da die Kenntnis eines gltigen
Passwortes gleichbedeutend mit dem Besitz des Rechtes ist. Lediglich
durch einen aufwendigen Passwortwechsel kann eine konsistente Rechte-
verteilung sichergestellt werden.
Auf IT-Systemen unter Unix oder Linux sollten die Sicherheitskontrollen
durch geeignete administrative Manahmen untersttzt und vereinfacht
werden. Hierzu wird empfohlen, regelmig Informationen ber die aktiven
Netzverbindungen zu sammeln (beispielsweise unter Benutzung des Befehls
netstat) und in einer Protokolldatei zu speichern. Es bietet sich an, diesen
Vorgang mit Hilfe des cron-Daemons zu automatisieren. Um das Daten-
volumen zu minimieren, sollten dabei irrelevante Informationen herausge-
filtert werden. Je nach Kenntnisstand der Benutzer sollten die Protokolldaten
dann entweder durch die Benutzer selbst kontrolliert oder in regelmigen
Abstnden dem Administrator zur Verfgung gestellt werden. In hnlicher
Weise kann mit anderen Protokolldateien verfahren werden, in denen
beispielsweise fehlgeschlagene Login-Versuche oder andere sicherheits-
relevanten Ereignisse festgehalten werden.
- Werden Unregelmigkeiten dem Administrator bekannt gegeben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.69 Einrichtung von Standardarbeitspltzen

Ein Standardarbeitsplatz ist gekennzeichnet durch einheitliche Hardware und
Software sowie deren Konfiguration. Die Planung und Einrichtung erfolgt
blicherweise unter den Aspekten der Aufgabenstellung, Zuverlssigkeit,
Ergonomie, Geschwindigkeit und Wartbarkeit. Sie wird durch fachkundiges
Personal durchgefhrt. Die Einrichtung von Standardarbeitspltzen ist in
mehrfacher Hinsicht vorteilhaft:
IT-Sicherheit:
- Standardarbeitspltze sind leichter in Sicherheitskonzepte einzubinden.
- Der Aufwand fr die Dokumentation des IT-Bestandes wird reduziert.
IT-Management:
- Die Beschaffung grerer Stckzahlen gleicher Komponenten ermglicht
Preisvorteile.
- Der Einsatz nicht zulssiger Software ist einfacher festzustellen.
- Durch gleiche IT-Ausstattung entfallen "Neidfaktoren" zwischen den
einzelnen Benutzern.
IT-Nutzer:
- Bei Gertewechsel ist keine erneute Einweisung in die IT-Konfiguration
erforderlich, Ausfallzeiten werden somit minimiert.
- Bei Fragen zu Hard- und Software knnen sich Anwender gegenseitig
helfen.
Systemadministration bei Installation und Wartung:
- Eine gewissenhaft geplante und getestete Installation kann fehlerfrei und
mit geringem Arbeitsaufwand installiert werden.
- Die einheitliche Arbeitsumgebung erleichtert den Benutzerservice
(Wartung, Support und Pflege).
Schulung:
- Die Teilnehmer werden in dem Umfeld geschult, das sie am Arbeitsplatz
vorfinden.
- Werden Abweichungen vom Standardarbeitsplatz begrndet?
- Werden die Begrndungen regelmig berprft?
- Welche Aspekte werden bei Planung und Einrichtung von
Standardarbeitspltzen bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.70 Entwicklung eines Konzepts fr

Sicherheitsgateways
Die Kopplung von lokalen Netzen mit globalen Netzen wie dem Internet fhrt
zu einem neuen Informationsangebot. Die lokale Vernetzung von Rechner-
systemen dazu, dass von jedem Arbeitsplatzrechner aus auf die vielfltigen
Informationen zugegriffen werden kann.
Diese Netzkopplung lsst aber auch neue Gefhrdungen entstehen, da prinzi-
piell nicht nur ein Datenfluss von auen in das zu schtzende Netz stattfinden
kann, sondern auch ein Datenabfluss in die andere Richtung. Darber hinaus
gefhrdet die Mglichkeit, von einem entfernten Rechner aus (z. B. aus dem
Internet) Befehle auf Rechnern im lokalen Netz ausfhren zu lassen, die
Integritt und die Verfgbarkeit der lokalen Rechner und dadurch indirekt
auch die Vertraulichkeit der lokalen Daten.
Ein zu schtzendes Teilnetz sollte daher nur dann an ein nicht-vertrauens-
wrdiges Netz angeschlossen werden, wenn dies unbedingt erforderlich ist.
Dies gilt insbesondere fr Anschlsse an das Internet, das aufgrund der hohen
Nutzerzahl das wohl am wenigsten vertrauenswrdige existierende Netz dar-
stellt. Dabei ist auch zu prfen, inwieweit das zu schtzende Netz in Teilnetze
segmentiert werden muss, weil bestimmte Rechner oder Bereiche des zu
schtzenden Netzes berhaupt nicht oder nur bedingt ans Internet
angeschlossen werden sollten, und ob fr die Kopplung mit dem Internet nicht
ein Stand-alone-System ausreicht (siehe M 5.46 Einsatz von Stand-alone-
Systemen zur Nutzung des Internets und Kapitel 5.8 Internet-PC).
Um die Sicherheit des zu schtzenden Netzes zu gewhrleisten, muss ein ge-
eignetes Sicherheitsgateway eingesetzt werden. Damit ein Sicherheitsgateway
effektiven Schutz bieten kann, mssen folgende grundlegende Bedingungen
erfllt sein:
Das Sicherheitsgateway muss
- auf einer umfassenden Sicherheitsrichtlinie aufsetzen,
- im IT-Sicherheitskonzept der Organisation eingebettet sein,
- korrekt installiert und
- korrekt administriert werden.
Der Anschluss an ein nicht-vertrauenswrdiges Netz darf erst dann erfolgen,
wenn berprft worden ist, dass mit dem gewhlten Sicherheitsgateway-Kon-
zept sowie den personellen und organisatorischen Randbedingungen alle
Risiken beherrscht werden knnen.
Es gibt verschiedene Arten, Sicherheitsgateways zu realisieren. Um festzu-
stellen, welches Konzept fr den Einsatzzweck am besten geeignet ist, muss
zunchst geklrt werden, welche Sicherheitsziele durch das Sicherheitsgate-
way erfllt werden sollen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiele fr Sicherheitsziele sind:

- Schutz des vertrauenswrdigen (internen) Netzes gegen unbefugten Zugriff
aus dem nicht-vertrauenswrdigen Netz,
- Schutz der lokal bertragenen und gespeicherten Daten gegen Angriffe auf
deren Vertraulichkeit oder Integritt,
- Schutz der lokalen Netzkomponenten gegen Angriffe auf deren Verfg-
barkeit (Insbesondere gilt dies auch fr Informationsserver, die Informa-
tionen aus dem internen Bereich fr die Allgemeinheit zu Verfgung
stellen.),
- Verfgbarkeit der Informationen des externen Netzes im zu schtzenden
internen Netz, (die Verfgbarkeit dieser Informationen muss aber gegen-
ber dem Schutz der lokalen Rechner und Informationen zurckstehen!),
- Schutz vor Angriffen, die auf IP-Spoofing beruhen, die Source-Routing
Option, das Protokoll ICMP oder Routing-Protokolle missbrauchen,
- Schutz vor Angriffen durch neue sicherheitsrelevante Softwareschwach-
stellen. (Da die Anzahl der potentiellen Angreifer und deren Kenntnisstand
bei einer Anbindung an das Internet als sehr hoch angesehen werden muss,
ist dieses Sicherheitsziel von besonderer Bedeutung.)
- Schutz vor ungewnschtem Datenabfluss
Auf den Sicherheitszielen aufbauend muss eine Sicherheitsrichtlinie erarbeitet
werden, in der Aufgaben und Anforderungen an das Sicherheitsgateway fest-
gelegt werden. Diese Sicherheitsrichtlinie muss in die IT-Sicherheitsstrategie
der jeweiligen Organisation eingebettet sein und daher mit dem IT-
Sicherheitsmanagement abgestimmt werden.
Die Entscheidungen, die bei der Erarbeitung der Sicherheitsrichtlinie fr das Entscheidungen doku-
mentieren
Sicherheitsgateway getroffen wurden, sollten - ebenso wie die Grnde fr
diese Entscheidungen - nachvollziehbar dokumentiert werden.
Die Umsetzung der Sicherheitsrichtlinie fr das Sicherheitsgateway erfolgt
dann durch die Realisierung des Sicherheitsgateways, durch geeignete Aus-
wahl von Hardware-Komponenten, Paketfilter und Application-Level-
Gateway und die sorgfltige Festlegung und Einrichtung von Filterregeln.
Die Begriffe Paketfilter und Application-Level-Gateway sind fr die weiteren
Abschnitte wichtig und werden daher kurz erlutert, um Missverstndnisse zu
vermeiden:
- Paketfilter sind IT-Systeme mit spezieller Software, die die Informationen Paketfilter
anhand der Header-Daten der unteren Schichten (Transportschicht oder
Verbindungsschicht) des OSI-Modells filtern und anhand spezieller Regeln
Pakete weiterleiten oder verwerfen (siehe M 2.74 Geeignete Auswahl eines
Paketfilters). Paketfilter treffen ihre Entscheidungen beispielsweise anhand
von Quell- und Ziel-Adressen oder -Ports eines Paketes, ohne den Inhalt zu
bercksichtigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ein Application-Level-Gateway ist ein IT-System, das die Informationen Application-Level-

der Anwendungsschicht (das heisst, den tatschlichen Inhalt (die Gateway
Nutzdaten) eines Paketes oder mehrerer zusammengehriger Pakete) filtert
und anhand spezieller Regeln Verbindungen oder auch bestimmte
Kommandos verbieten oder erlauben kann (siehe M 2.75 Geeignete
Auswahl eines Application-Gateway). Whrend Paketfilter auf Schicht 3
und 4 des OSI-Modells arbeiten, arbeiten Gateways auf Schicht 7. Ein
Application-Level-Gateway ist im Allgemeinen auf einem IT-System
implementiert, das ausschlielich fr diese Aufgabe eingesetzt wird und
dessen Befehlsumfang auf das Notwendigste reduziert ist.
Damit ein Sicherheitsgateway einen wirkungsvollen Schutz eines Netzes
gegen Angriffe von auen darstellt, mssen einige grundlegende Voraus-
setzungen erfllt sein:
- Die gesamte Kommunikation zwischen den beteiligten Netzen muss ber
das Sicherheitsgateway gefhrt werden. Dafr muss sichergestellt sein,
dass das Sicherheitsgateway die einzige Schnittstelle zwischen den beiden
Netzen darstellt. Es mssen Regelungen getroffen werden, dass keine
weiteren externen Verbindungen unter Umgehung des Sicherheitsgateways
geschaffen werden drfen.
- Ein Sicherheitsgateway darf ausschlielich als schtzender bergang zum
internen Netz eingesetzt werden. Daher drfen auf einem Sicherheitsgate-
way selbst nur die dafr erforderlichen Dienste verfgbar sein und keine
weiteren Dienste, wie z. B. ein Webserver, angeboten werden. Wie Infor-
mationsserver und andere Komponenten, die auf eigenen Systemen laufen,
geeignet in ein Sicherheitsgateway integriert werden knnen, wird in einer
Reihe eigener Manahmen fr verschiedene Systeme beschrieben, siehe
beispielsweise M 4.223 Integration von Proxy-Servern in das
Sicherheitsgateway oder M 5.115 Integration eines Webservers in ein
Sicherheitsgateway.
- Die Administration der Komponenten des Sicherheitsgateways darf nur
ber einen gesicherten Zugang mglich sein, also z. B. ber eine gesicherte
Konsole, eine verschlsselte Verbindung oder ein separates Netz (Admi-
nistrationsnetz). Zur Aufstellung einer gesicherten Konsole siehe M 1.32
Geeignete Aufstellung von Konsole, Gerten mit austauschbaren
Datentrgern und Druckern.
- Ein Sicherheitsgateway baut auf Sicherheitsrichtlinie auf, die fr das zu
schtzende Netz definiert wurde, und gestattet nur die dort festgelegten
Verbindungen. Diese Verbindungen mssen gegebenenfalls sehr detailliert
(bis hin zu einer individuellen Angabe von IP-Adresse, Dienst, Zeit,
Richtung und Benutzer getrennt) festgelegt werden knnen.
- Fr die Konzeption und den Betrieb eines Sicherheitsgateways muss geeig-
netes Personal zur Verfgung stehen. Der zeitliche Aufwand fr den Be-
trieb eines Sicherheitsgateways darf nicht unterschtzt werden. Alleine die
Auswertung der angefallenen Protokolldaten nimmt oft viel Zeit in An-
spruch. Der Administrator muss fundierte Kenntnisse der eingesetzten IT-
Komponenten besitzen und entsprechend geschult werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Benutzer des lokalen Netzes sollten durch den Einsatz eines
Sicherheitsgateways mglichst wenig Einschrnkungen hinnehmen
mssen.
Ein Sicherheitsgateway kann das interne Netz vor vielen Gefahren beim An- Sicherheitsgateways
haben auch Grenzen
schluss an das Internet schtzen, aber nicht vor allen. Beim Aufbau eines
Sicherheitsgateways und der Erarbeitung einer Sicherheitsrichtlinie sollte man
sich daher die Grenzen eines Sicherheitsgateways verdeutlichen:
- Es werden Protokolle berprft, nicht die bertragenen Informationen.
Eine Protokollprfung besttigt beispielsweise, dass eine E-Mail mit
ordnungsgemen Befehlen zugestellt wurde, kann aber keine Aussagen
zum eigentlichen Inhalt der E-Mail machen.
- Die Filterung von aktiven Inhalten ist unter Umstnden nur teilweise
erfolgreich, da eventuell nicht alle verschiedenen Mglichkeiten zur Ein-
bettung von aktiven Inhalten erkannt werden.
- Sobald ein Benutzer eine Kommunikation ber ein Sicherheitsgateway
herstellen darf, kann er ber das verwendete Kommunikationsprotokoll
beliebige andere Protokolle tunneln. Damit knnte ein Innentter einem
Externen den Zugriff auf interne Rechner ermglichen oder selbst
unerlaubte Protokolle nutzen. Die unberechtigte Nutzung von Tunnel-Ver-
fahren ist meist nur schwer feststellbar.
- Eine Einschrnkung der Internet-Zugriffe auf festgelegte Webserver ist
praktisch unmglich, da viele Webserver auch ber Proxies nutzbar sind.
Daher kann eine Sperrung bestimmter IP-Adressen leicht umgangen
werden.
- Software zum Filtern anhand von Web-Adressen ("URLs") ist hufig noch
unausgereift. Beispielweise ist es mglich, dass nicht alle Arten der
Adressierung erfasst werden. Das folgende Beispiel mit dem BSI-Web-
server soll aufzeigen, welche Mglichkeiten zur Adressierung vorhanden
sind. Die Liste ist bei weitem nicht vollstndig, da einzelne Buchstaben
auch durch Escape-Sequenzen dargestellt werden knnen.
www.bsi.bund.de
www.bsi.de
194.95.176.226
3261051106
Zudem knnen URL-Filter durch Nutzung von "Anonymizern" umgangen
werden.
- Die Filterung von Spam-Mails ist noch nicht ausgereift. Kein SMTP-Proxy
kann zweifelsfrei feststellen, ob eine E-Mail vom Empfnger erwnscht ist
oder nicht. Spam-Mails drften frhestens dann verschwinden, wenn die
Absender von E-Mails zweifelsfrei nachweisbar sind. Dies ist aber mit dem
herkmmlichen Protokoll SMTP alleine nicht realisierbar.
- Sicherheitsgateways schtzen nicht vor allen Denial-of-Service-Angriffen.
Wenn ein Angreifer z. B. die Anbindung zum Provider lahmlegt, hilft auch
das beste Sicherheitsgateway nicht. Auerdem gibt es immer wieder Fehler
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
in der Implementierung von Protokollen auf Endgerten, die von Sicher-

heitsproxies nicht abfangen werden knnen.
- Ein Sicherheitsgateway kann zwar einen Netzbergang sichern, er hat aber
keinen Einfluss auf die Sicherheit der Kommunikation innerhalb der
Netze!
- Auch die speziell unter Sicherheitsaspekten entwickelten Komponenten
von Sicherheitsgateways knnen trotz groer Sorgfalt Programmierfehler
enthalten.
- Sicherheitsgateways knnen nur begrenzt gegen eine absichtliche oder
versehentliche Fehlkonfiguration der zu schtzenden Clients und Server
schtzen.
- Eingebaute Hintertren in der verwendeten Software knnen eventuell
auch durch ein Sicherheitsgateway hindurch ausgenutzt werden. Im
Extremfall kann die Software des Sicherheitsgateways selbst Hintertren
enthalten.
- Die korrekte Konfiguration der Komponenten des Sicherheitsgateways ist
oft sehr anspruchsvoll. Fehler in der Konfiguration knnen zu Sicherheits-
lcken oder Ausfllen fhren.
- Ist die Dokumentation der technischen Ausstattung des Sicherheitsgate-
ways durch den Hersteller mangelhaft, so begnstigt dies Fehler bei Konfi-
guration und Administration.
- Wenn die Komponenten des Sicherheitsgateways falsch dimensioniert
sind, kann die Verfgbarkeit beeintrchtigt werden. Wird beispielsweise
der Rechner, auf dem ein HTTP-Sicherheitsproxy luft, zu schwach
dimensioniert (zu wenig Arbeitsspeicher, zu langsamer Prozessor), so kann
dies die Geschwindigkeit des Internetzugriffes stark beeintrchtigen.
- Es kann nicht verhindert werden, dass Angreifer die Komponenten des
Sicherheitsgateways mit Hilfe von Schwachstellenscannern analysieren.
- Ein Sicherheitsgateway kann nicht gegen die bewusste oder unbewusste
Missachtung von Sicherheitsrichtlinien und -konzepten durch die An-
wender schtzen.
- Ein Sicherheitsgateway schtzt nicht vor dem Missbrauch freigegebener
Kommunikation durch Innentter ("Insider-Angriffe").
- Ein Sicherheitsgetway schtzt nicht vor Social Engineering.
- Werden mobile Endgerte (Laptop, PDA etc.), die von Mitarbeitern auch
extern benutzt werden, an das interne Netz angeschlossen, so kann auf
diese Weise Schadsoftware (Viren, Wrmer, Trojaner) in das vertrauens-
wrdige Netz eingeschleppt werden.
- Ein Sicherheitsgateway schtzt auch nicht davor, dass Schadprogramme
auf Austauschmedien, z. B. CD-ROM, Diskette, USB-Stick in das ver-
trauenswrdige Netz eingeschleppt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind die Sicherheitsziele fr das Sicherheitsgateway dokumentiert?
- Ist die Sicherheitsrichtlinie fr das Sicherheitsgateway mit der allgemeinen
Sicherheitsstrategie abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.71 Festlegung einer Policy fr ein

Sicherheitsgateway
Die Policy des Sicherheitsgateways bestimmt das Verhalten des Sicherheits-
gateways. Sie definiert, welche Informationen, Dienste und Protokolle das
Sicherheitsgateway wie behandelt und wer sie nutzen darf. Die Policy ist nicht
zu verwechseln mit der Sicherheitsrichtlinie fr das Sicherheitsgateway, in der
Vorgaben fr den sicheren Betrieb des Sicherheitsgateway selbst gemacht
werden.
Kommunikationsanforderungen
Fr die Erstellung einer Policy muss als erstes festgelegt werden, welche
Arten der Kommunikation mit dem ueren Netz zugelassen werden. Bei der
Festlegung der Kommunikationsanforderungen mssen speziell die folgenden
Fragen beantwortet werden:
- Welche Informationen drfen durch das Sicherheitsgateway nach auen
hindurch- bzw. nach innen hereingelassen werden?
- Welche Informationen soll das Sicherheitsgateway verdecken (z. B. die
interne Netzstruktur oder die Benutzernamen)?
- Welche Authentisierungsverfahren sollen innerhalb des zu schtzenden
Netzes bzw. fr das Sicherheitsgateway benutzt werden (z. B. Einmal-
passwrter oder Chipkarten)?
- Welche Zugnge werden bentigt (z. B. nur ber einen Internet-Service-
Provider oder auch ber einen Modem-Pool)?
- Welcher Datendurchsatz ist zu erwarten?
Auswahl der Dienste
Aus den Kommunikationsanforderungen wird dann abgeleitet, welche Dienste
im zu sichernden Netz erlaubt werden.
Es muss unterschieden werden zwischen denjenigen Diensten, die fr die Be-
nutzer im zu schtzenden Netz und denjenigen, die fr externe Benutzer zu-
gelassen werden.
Wenn zum Beispiel E-Mail empfangen werden soll (was im allgemeinen die
Minimalanforderung ist) muss das Protokoll SMTP vom Sicherheitsgateway
durchgelassen werden knnen.
In der Policy muss explizit festgelegt werden, welche Dienste fr welche
Benutzer und/oder Rechner zugelassen werden sollen und fr welche Dienste
Vertraulichkeit und/oder Integritt gewhrleistet werden mssen. Es sollten
nur die Dienste zugelassen werden, die unbedingt notwendig sind. Alle
anderen Dienste mssen verboten werden. Dies muss auch die Voreinstellung
sein: Alle Dienste, fr die noch keine expliziten Regeln festgelegt wurden,
drfen nicht zugelassen werden.
Fr jeden erlaubten Dienst muss festgelegt werden, welche Funktionen des
verwendeten Protokolls genutzt werden drfen und welche unterbunden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden sollen (z. B. der "PORT"-Befehl von FTP zur Verhinderung von
aktivem FTP) und welche der bertragenen Nutzdaten gefiltert werden sollen
(z. B. zur Kontrolle auf Computer-Viren).
Es muss festgelegt werden, zu welchen Wochentagen und Tageszeiten die
bereitgestellten Dienste genutzt werden knnen.
Fr kurzzeitige nderungen (z. B. fr Tests) oder neue Dienste sollten Aus-
nahmeregelungen vorgesehen werden.
Es sind Forderungen an die Filter zu stellen, und zwar einmal an die Paket-
filter, die die Header-Informationen der Dienste der Schichten 3 und 4 des
OSI-Schichtenmodells (IP, ICMP, ARP, TCP und UDP) verwenden, sowie an
die Sicherheitsproxies, die die Informationen der Dienste der
Anwendungsschicht (z. B. Telnet, FTP, SMTP, DNS, NNTP, HTTP)
verwenden. Einen berblick, was fr einen sicheren Einsatz der einzelnen
Protokolle und Dienste zu beachten ist, gibt M 5.39 Sicherer Einsatz der
Protokolle und Dienste. Darauf aufbauend mssen Filterregeln formuliert
werden (siehe M 2.76 Auswahl und Einrichtung geeigneter Filterregeln).
Organisatorische Regelungen
Neben der sorgfltigen Aufstellung und Umsetzung der Filterregeln sind dar-
ber hinaus folgende organisatorische Regelungen erforderlich:
- Es mssen Verantwortliche sowohl fr den Entwurf als auch fr die Um-
setzung und das Testen der Filterregeln benannt werden. Es muss geklrt
werden, wer befugt ist, die Filterregeln z. B. fr Tests neuer Dienste zu
verndern.
- Es muss festgelegt werden, welche Informationen protokolliert werden und
wer die Protokolle auswertet. Es mssen sowohl alle korrekt aufgebauten
als auch die abgewiesenen Verbindungen protokolliert werden. Die Proto-
kollierung muss den datenschutzrechtlichen Bestimmungen entsprechen.
- Die Benutzer mssen ber ihre Rechte, insbesondere auch ber den Um-
fang der Nutzdaten-Filterung umfassend informiert werden.
- Es ist empfehlenswert, den Benutzern eine Dokumentation zur Verfgung
zu stellen, aus der hervorgeht, welche Dienste in welchem Umfang genutzt
werden knnen und ob dabei besondere Dinge zu beachten sind.
- Angriffe auf das Sicherheitsgateway sollten nicht nur erfolgreich ver-
hindert, sondern auch schnell erkannt werden knnen. Angriffe knnen
ber die Auswertung der Protokolldateien erkannt werden. Das Sicher-
heitsgateway sollte aber auch in der Lage sein, aufgrund von vordefinierten
Ereignissen, wie z. B. hufigen fehlerhaften Passworteingaben auf einem
Application-Level-Gateway oder Versuchen, verbotene Verbindungen auf-
zubauen, Warnungen auszugeben oder evtl. sogar Aktionen auszulsen.
- Es ist zu klren, welche Aktionen bei einem Angriff gestartet werden, ob
z. B. der Angreifer verfolgt werden soll oder ob die Netzverbindungen
nach auen getrennt werden sollen. Da hiermit starke Eingriffe in den
Netzbetrieb verbunden sein knnen, mssen Verantwortliche bestimmt
sein, die entscheiden knnen, ob ein Angriff vorliegt und die entsprechende
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Manahmen einleiten. Die Aufgaben und Kompetenzen fr die betroffenen

Personen und Funktionen mssen eindeutig festgelegt sein.
Folgende Fragen mssen bei der Festlegung der Policy geklrt werden:
- Welcher Schaden kann im zu schtzenden Netz verursacht werden, wenn
das Sicherheitsgateway berwunden wird? Da es keine absolute Sicherheit
geben kann, muss entschieden werden, ob der maximal auftretende
Schaden tragbar ist oder ob zustzliche Manahmen ergriffen werden
mssen.
- Welche Restrisiken existieren bei einem ordnungsgemen Betrieb des
Sicherheitsgateways? Dies sind z. B. Schwachstellen in den benutzten Ge-
rten und Betriebssystemen.
- Wie schnell wird ein Angriff auf das Sicherheitsgateway bemerkt?
- Welche Protokoll-Informationen sind auch nach einem erfolgreichen An-
griff noch verfgbar?
- Sind die Benutzer bereit, die Einschrnkungen durch das Sicherheitsgate-
way zu akzeptieren?
In der Policy mssen die getroffenen Entscheidungen dokumentiert werden. Entscheidungen und
Grnde dokumentieren
Darber hinaus ist es wichtig, dass auch die fr die Entscheidungen relevanten
Informationen und Entscheidungsgrnde so dokumentiert sind, dass sie zu
einem spteren Zeitpunkt (etwa bei der Revision der Policy) nachvollzogen
werden knnen. Diese Hintergrundinformationen brauchen nicht direkt in der
Policy selbst enthalten zu sein, sondern es ist eher empfehlenswert, sie in
einem eigenen Dokument festzuhalten.
- Welche Protokolle und Dienste sollen ber das Sicherheitsgateway genutzt
werden?
- Ist dokumentiert, nach welchen Kriterien die zu nutzenden Dienste ausge-
whlt wurden?
- Sind die Zustndigkeiten fr den Betrieb und die berwachung des
Sicherheitsgateways geregelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.72 Anforderungen an eine Firewall
entfallen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.73 Auswahl geeigneter Grundstrukturen fr

Sicherheitsgateways
Nachdem eine Sicherheitsrichtlinie fr das Sicherheitsgateway festgelegt
worden ist, muss entschieden werden, mit welchen Komponenten das
Sicherheitsgateway realisiert werden soll. Dafr ist eine geeignete Anordnung
auszuwhlen.
Grundlegende Strukturen von Sicherheitsgateways
Im Wesentlichen bieten sich zwei sinnvolle Grundstrukturen an, die als
Anhaltspunkt zum Aufbau eines Sicherheitsgateways dienen knnen. Die
grundlegenden Strukturen werden im Folgenden erlutert.
1. Paketfilter - Application-Level-Gateway - Paketfilter (P-A-P)
Bei dieser Grundstruktur werden ein Paketfilter, ein Application-Level-
Gateway (ALG) und ein weiterer Paketfilter "hintereinander geschaltet", so
dass jeglicher Datenverkehr alle drei Komponenten berqueren muss. In der
folgenden Abbildung sind beispielhaft einige Mglichkeiten zur Einrichtung
von "Demilitarisierten Zonen" (DMZ) eingezeichnet, in denen weitere
Komponenten des Sicherheitsgateways in einer geschtzten Umgebung
betrieben werden knnen.
Abbildung 1: Mehrstufiger Aufbau bestehend aus Paketfilter - ALG -

Paketfilter
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Der Einsatzbereich fr diesen Typ von Sicherheitsgateways ist vor allem die
Trennung zweier Netze, falls sich das Ma der Vertrauenswrdigkeit dieser
Netze erheblich unterscheidet (z. B. Trennung des Internets von einem
Intranet), oder Trennung zweier Teilnetze des internen Netzes mit deutlich
unterschiedlichen Sicherheitsanforderungen.
Bei den beiden Paketfiltern braucht es sich nicht notwendigerweise um
dedizierte IT-Systeme (Rechner oder Appliances) zu handeln. Falls die
eingesetzten Router eine integrierte Paketfilter-Funktionalitt besitzen, so
knnen die Router die Funktion des Paketfilters im Sicherheitsgateway mit
bernehmen.
Die Mglichkeiten der Paketfilter-Funktionalitt in Routern sind jedoch oft
eingeschrnkt, so dass in bestimmten Einsatzszenarien ein dedizierter
Paketfilter erforderlich sein kann.
2. Nur Paketfilter
Die einfachste Grundstruktur eines Sicherheitsgateways besteht ausschlielich
aus einem Paketfilter.
Das Grundproblem bei der Filterung der Kommunikation alleine mit einem
Paketfilter liegt darin, dass die Entscheidung darber, ob ein Zugriff erlaubt
oder abgewiesen werden soll, anhand der leicht zu flschenden Daten aus den
Headern der verschiedenen IP-basierten Protokolle gefllt wird.
Abbildung 2: Einstufiger Aufbau bestehend aus einem Paketfilter.

Einsatzbereiche sind deshalb vor allem:
1. Trennung zweier Netze, falls sich das Ma der Vertrauenswrdigkeit dieser
Netze nur wenig voneinander unterscheidet (z. B. Trennung des Internets
von einem Intranet mit nur geringem Schutzbedarf).
2. Trennung zweier organisationsinterner Netze.
3. Privater Bereich (Schutz des "heimischen" Rechners beim Zugriff auf das
Internet)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Verwendung eines zustzlichen IP-Proxys kann verhindern, dass

Informationen des IP-Headers, wie beispielsweise die IP-ID oder die TTL
("Time-To-Live"), das vertrauenswrdige Netz verlassen. Mittels der IP-ID
kann trotz NAT-Funktion die Anzahl der Rechner in einem
vertrauenswrdigen Netz bestimmt werden und die TTL lsst Rckschlsse
auf verwendete Betriebssysteme zu. ber Paketfilterregeln oder
entsprechendes Routing muss sichergestellt werden, dass der IP-Proxy nicht
umgangen werden kann.
Vor- und Nachteile der Grundstrukturen
Prinzipiell ist der oben dargestellte P-A-P-Aufbau zur Erzielung eines hohen
Sicherheitsniveaus in allen Anwendungszusammenhngen zu empfehlen.
Wird auf Komponenten dieses Aufbaus verzichtet, so ist dies stets mit
Sicherheitseinbuen verbunden.
In der folgenden Tabelle werden Vor- und Nachteile bzw. Einsatzumgebungen
sowohl fr den P-A-P-Aufbau, als auch fr einen einzelnen Paketfilter
beschrieben.
Paketfilter - ALG - Paketfilter Paketfilter

(P-A-P)
- Kann als Grundlage Sicherstellung - Kein hohes Sicherheitsniveau,
eines hohen Sicherheitsniveau hchstens fr normalen
dienen. Schutzbedarf ausreichend.
- Hohe Komplexitt aufgrund der - Gegenber einem P-A-P-Aufbau
Verwendung mehrerer Module. relativ einfache Administration.
- Nicht in jedem - Geringe Investitionskosten
Anwendungszusammenhang (kostenlose Software unter
einsetzbar. Beispielsweise kann verschiedenen Betriebssystemen
IPSEC-Verkehr nicht ber einen vorhanden)
TCP/IP-Proxy geleitet werden.
- Keine wesentliche Einschrnkung
- Einfache des maximalen Datendurchsatzes
Erweiterungsmglichkeiten, z. B. am Netzbergang.
kann ein Virenscanner oder ein
- Einfache, grundlegende
Spam-Filter ohne groen Aufwand
Absicherung.
an das ALG angeschlossen werden.
- Integration auf einem zu
- Die Ausnutzung von
schtzenden Rechner theoretisch
Sicherheitslcken in Client-
mglich (z. B. kann ein Web-
Software kann teilweise verhindert
Server gleichzeitig als Paketfilter
werden.
genutzt werden).
- Umfangreiche
Bereitstellung neuer Dienste
Protokollierungsmglichkeiten.
gegenber P-A-P-Aufbau stark
vereinfacht.
Tabelle 1: Vor- und Nachteile des P-A-P Aufbaus und von Paketfiltern
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Auf dem Application-Level-Gateway laufen so genannte Proxy-Prozesse (oft

auch Proxy-Server genannt), die den Verbindungsaufbau zum Zielrechner
durchfhren, nachdem eine Authentisierung des Benutzers stattgefunden hat,
und die Daten gem den Informationen der Anwendungsschicht filtern.
Verbindungen, fr die keine Proxy-Prozesse existieren, sind nicht mglich.
Rechner, auf denen einzelne Komponenten des Sicherheitsgateways realisiert
werden, mssen so eingerichtet werden, dass nur die unbedingt notwendigen
Programme auf ihnen laufen (Minimalsystem). Die eingesetzten Programme
mssen richtig konfiguriert sind und alle bekannten Schwachstellen mssen
beseitigt werden.
Werden zur Erzielung eines hohen Sicherheitsniveaus mehrere Systeme
hintereinander geschaltet, so ist es dringend zu empfehlen, diese Systeme auf
verschiedenen Systemen zu realisieren (z. B. mit unterschiedlichen
Betriebssystemen). Dadurch wird verhindert, dass ein Angreifer das
Sicherheitsgateway besonders leicht berwinden kann, indem er auf allen
beteiligten Systemen die gleiche Sicherheitslcke ausnutzt.
Hinweise zur Auswahl einer Grundstruktur
Die Frage, welcher Typ eines Sicherheitsgateways eingesetzt werden soll, ist
einerseits davon abhngig, wie gro der Unterschied der Vertrauenswrdigkeit
der zu trennenden Netze ist (d. h. "wie wenig vertrauenswrdig" das nicht-
vertrauenswrdige Netz ist), und andererseits davon, wie hoch der
Schutzbedarf des Netzes ist, das durch das Sicherheitsgateway geschtzt
werden soll.
Das Internet ist in diesem Zusammenhang das am wenigsten Sonderfall Internet
vertrauenswrdige Netz. Soll das eigene Netz mit dem Internet verbunden
werden, so sollte grundstzlich der mehrstufige P-A-P-Aufbau gewhlt
werden. Nur in Ausnahmefllen kann davon abgewichen werden,
beispielsweise bei sehr kleinen Netzen, bei denen ein mehrstufiges
Sicherheitsgateway einen unverhltnismig hohen Aufwand bedeuten wrde,
oder wenn das eigene Netz nur einen geringen Schutzbedarf hat. Auch in
solchen Fllen muss jedoch mindestens ein Paketfilter eingesetzt werden, der
besonders sorgfltig zu konfigurieren ist.
Falls das weniger vertrauenswrdige Netz "nur in geringem Mae nicht-
vertrauenswrdig" ist, brauchen die Netze nicht durch ein mehrstufiges
Sicherheitsgateway getrennt zu werden. In diesem Fall ist ein sorgfltig
konfigurierter Paketfilter meist ausreichend.
Nur in geringem Mae nicht-vertrauenswrdige Netze knnen beispielsweise
folgende Netztypen darstellen:
- andere (organisations-) interne Netze
- Netze ohne Verbindung zum Internet
- Netze mit Verbindung zum Internet, die ihrerseits durch besondere
Sicherheitsmanahmen (z. B. durch ein eigenes Sicherheitsgateway) vom
Internet abgeschottet sind
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Folgende Tabelle fasst die Empfehlungen zusammen:
Einsatzgebiet Empfohlener Aufbau

Trennung zweier Teilnetze des Paketfilter. Bei normalem Schutzbedarf
internen Netzes mit gleichem gengt ein Router mit integrierter
Schutzbedarf Paketfilter-Funktion.
Trennung zweier Teilnetze des Mindestens Paketfilter.
internen Netzes mit
Falls vom weniger vertrauenswrdigen
unterschiedlichem Schutzbedarf
Netz aus auf einen Dienst im Netz mit
(insbesondere: Teilnetz mit hohem
hohem Schutzbedarf zugegriffen werden
Schutzbedarf und Teilnetz mit
soll, dann ist es empfehlenswert, diesen
normalem Schutzbedarf)
Zugriff ber ein ALG abzusichern.
Trennung eines Teilnetzes mit Mehrstufiger Aufbau aus Paketfilter -
besonderen Sicherheitsanforder- ALG - Paketfilter.
ungen von einem anderen internen
Zustzlich ist in diesem Fall eine
Netz
ergnzende Sicherheitsbetrachtung
notwendig.
Der mehrstufige Aufbau kann hier nur als
Grundlage fr sehr hohe Sicherheit
dienen. In der Regel werden zustzliche
Manahmen notwendig sein, fr die aber
keine allgemeinen Empfehlungen mglich
sind.
Trennung des eigenen Netzes vom Grundstzlich mehrstufiger Aufbau aus
Internet Paketfilter - ALG - Paketfilter.
In Ausnahmefllen (sehr kleines Netz,
kein hoher Schutzbedarf) kann ein
Paketfilter (beispielsweise in Verbindung
mit einem NAT-Router) ausreichend sein.
Zumindest fr Dienste wie E-Mail und
HTTP wird der Einsatz eines
entsprechenden Proxyservers dringend
empfohlen.
Bei normalem Schutzbedarf kann
gegebenenfalls auf den inneren Paketfilter
verzichtet werden.
Falls kein P-A-P-Aufbau gewhlt wird,
wird eine zustzliche Risikobetrachtung
dringend empfohlen.
Tabelle 2: Empfehlungen fr Grundstrukturen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Andere Strukturen
Neben den bisher beschriebenen Strukturen sind weitere Strukturen mglich,
die meist aus einem Verzicht auf Komponenten des P-A-P-Aufbaus
resultieren. Dies ist jedoch immer mit Einbuen bei der Sicherheit verbunden.
Gelegentlich wird beispielsweise auf den "inneren" Paketfilter verzichtet, der Verzicht auf Paketfilter
ist nicht sinnvoll
das ALG vom vertrauenswrdigen (bzw. internen) Netz trennt. Da einerseits
die meisten Router bereits eine integrierte Paketfilter-Funktionalitt bieten und
angesichts der vergleichsweise geringen Kosten fr einen entsprechend
ausgestatteten Rechner gibt es jedoch kaum schlssige Grnde, auf einen der
Paketfilter zu verzichten.
Appliances
Verschiedene Hersteller bieten Sicherheitsgateways als Appliances an. Dabei
handelt es sich um vorkonfigurierte Gerte, die zwar teilweise aus normalen
Rechner-Komponenten aufgebaut sind und unter einem darauf angepassten
herkmmlichen Betriebssystem laufen, aber nur fr einen genau vorgegebenen
Einsatzzweck (hier: Paketfilter bzw. ALG) hergestellt und konfiguriert
wurden. Die Bandbreite der angebotenen Gerte reicht von reinen Paketfiltern
bis zu mehrstufigen Lsungen, die in einem Gert mehrere Komponenten
eines Sicherheitsgateway integrieren.
Gegenber einem Aufbau des Sicherheitsgateways aus "normalen" Rechnern,
die (in Eigenregie oder durch einen Dienstleister) entsprechend konfiguriert
werden, bieten Appliances oft den Vorteil einer einfacheren Konfiguration.
Dem steht jedoch meist der Nachteil gegenber, dass die Konfiguration
weniger flexibel ist und weniger Mglichkeiten zur Anpassung an individuelle
Bedrfnisse bietet.
Appliances, die mehrere Funktionen (z. B. Paketfilter und ALG) unter einer
Betriebssysteminstallation betreiben, haben gegenber einer Realisierung des
Sicherheitsgateways durch drei getrennte Systeme den weiteren Nachteil, dass
ein Angreifer nur die Sicherheitsmechanismen eines einzigen Betriebssystems
berwinden muss, um das Sicherheitsgateway komplett zu kompromittieren.
Dieser Aspekt muss bei der Planung des Sicherheitsgateways mit
bercksichtigt werden. Soll trotzdem ein entsprechendes Gert eingesetzt
werden, so knnen gegebenenfalls zustzliche Sicherheitsmanahmen
erforderlich werden, um das angestrebte Sicherheitsniveau zu erreichen.
Dokumentation
Die Entscheidung fr eine bestimmte Struktur sollte zusammen mit den
Grnden, die fr die Entscheidung ausschlaggebend waren, nachvollziehbar
- Welche Struktur wurde fr das Sicherheitsgateway ausgewhlt? Sind die
Entscheidungsgrnde dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.74 Geeignete Auswahl eines Paketfilters

Die Funktionen eines Sicherheitsgateways auf Transport- und Netzwerkebene
werden von den so genannten Paketfiltern bernommen. Aufgabe eines
Paketfilters ist es, Datenpakete anhand der Informationen in den Header-Daten
der UDP/IP- bzw. TCP/IP-Schicht (z. B. IP-Adresse und Portnummer) zu
verarbeiten. Diese Entscheidung trifft der Paketfilter anhand den vom
Administrator vorgegebenen Filterregeln. Vielfach bieten die Paketfilter auch
eine Mglichkeit zur "Network Address Translation" (NAT), bei der die
Absender-Adressen von IP-Paketen durch eine IP-Adresse des Paketfilters
ersetzt wird. Dadurch wird die Netzstruktur des zu schtzenden Netzes
verdeckt.
Die Filterregeln werden fr jedes eintreffende Datenpaket sequentiell
abgearbeitet. Sobald eine Regel auf ein Paket zutrifft, bricht in der Regel die
berprfung ab und die betreffende Regel wird auf dieses Paket angewendet.
Paketfilter lassen sich anhand der Filtermglichkeiten weiter unterteilen.
Statische Paketfilter
Paketfilter, die eine Entscheidung anhand der Header-Daten der UDP/IP- und
TCP/IP-Schichten (z. B. anhand der IP-Quelladresse, der IP-Zieladresse und
der TCP-Flags) treffen, werden statische Paketfilter genannt.
Dynamische Paketfilter/Stateful Inspection
Dynamische Paketfilter (oder auch Paketfilter mit "Stateful Inspection"
genannt) erweitern die Funktionalitt der statischen Paketfilter um die
Mglichkeit zur Betrachtung des Kommunikationkontextes. Dynamische
Paketfilter knnen auch bei verbindungslosen Protokollen (wie z. B. UDP)
eine Entscheidung treffen, ob ein eintreffendes Paket die Antwort auf eine
Anfrage ist oder ob dieses Paket zu einer Kommunikationsinitiierung gehrt.
Zudem ist es mglich, Dienste sicher bereitzustellen, die nicht mit festen
Portnummern verbunden sind, da auch hier Pakete unabhngig von
Portnummern immer dann weitergeleitet werden, wenn es vorher eine
passende Anfrage aus dem vertrauenswrdigen Netz gab.
Ein dynamischer Paketfilter speichert fr eine bestimmte Zeitspanne die
Quell-IP-Adresse und die Quell-Portnummer ausgehender Pakete.
Eintreffende IP-Pakete werden nur dann weitergeleitet, wenn deren Ziel-IP-
Adresse und Ziel-Portnummern noch im Speicher vorhanden sind, das heit,
wenn vorher eine Anfrage vom vertrauenswrdigen Netz aus gestartet wurde
und die festgelegte Wartezeit noch nicht berschritten wurde.
Paketfilter mit Stateful Inspection stellen zudem meist die Mglichkeit zur
Betrachtung der bertragenen Daten auf der Anwendungsebene bereit.
Realisierungsformen von Paketfiltern
1. Einrichtung eines Rechners als Paketfilter unter Nutzung eines
Betriebssystems, das die notwendigen Funktionalitten bereitstellt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorteile Nachteile
Je nach verwendetem Betriebssystem - Evtl. lange Ausfallzeiten bei
relativ geringe Investitionskosten. Defekten, da u. U. das
Betriebssystem aufgrund
ausgetauschter Hardware neu
installiert oder konfiguriert werden
muss.
- Relativ hoher Aufwand zur
Konfiguration als Minimalsystem
(im Vergleich zu einem Router mit
Paketfilterfunktion).
- Know-How-Aufbau notwendig zur
Konfiguration als Minimalsystem.
- Die Hardware von PC-Systemen
ist oft anflliger als die Hardware
von Appliances, da letztere z. B.
meist keine Festplatten oder Lfter
enthalten.
- Die Administrationskosten sind in
der Regel hher als bei Appliances,
da Konfigurationsoberflchen
meist nicht zur Verfgung stehen.
- Die Komplexitt ist oft hher als
bei Appliances.
Tabelle 1: Einrichten eines Rechners als Paketfilter
2. Einrichtung von Filterregeln auf einem Router
Vorteile Nachteile
- Keine Investitionskosten, falls ein - Die Erweiterungsmglichkeiten
Router schon vorhanden ist. von Routern sind oft
eingeschrnkt.
- Im Vergleich zu rechnerbasierten
Paketfiltern besteht eine geringe - Die Konfiguration ist evtl.
Ausfallwahrscheinlichkeit, da schwieriger als bei Appliances
Router in der Regel eine bessere oder rechnerbasierten Paketfiltern.
Verfgbarkeit aufweisen.
- Keine Kontrolle ber die
Sicherheitsfunktionen des Routers
durch organisationsinternes Personal,
falls dieser bei einem Dienstleister
aufgestellt ist und von diesem
administriert wird.
Tabelle 2: Vor- und Nachteile der Einrichtung von Filterregeln auf einem
Router
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Verwendung einer Appliance

Vorteile Nachteile
- Geringer Zeitaufwand ntig bis zur - Geringe
Inbetriebnahme. Erweiterungsmglichkeiten der
proprietren Hard- und Software.
- Vereinfachte Konfiguration der
bereitgestellten Funktionen (ggf. - Lange Ausfallzeiten, falls das
ber Web-Oberflche) Gert im Fehlerfalle oft zum
Hersteller gesandt werden muss,
- Einfache Konfiguration, da
falls keine entsprechenden
Appliances oft
Wartungsvertrge geschlossen
Administrationsoberflchen
wurden. Gegebenenfalls muss
anbieten.
deshalb ein Ersatzgert beschafft
- Appliances untersttzen oft werden, das als "Cold Standby"
Automatische Updates vorgehalten wird.
- Im Vergleich zu rechnerbasierten - Wenig Informationen zur sicheren
Paketfiltern eher geringere Konfiguration und zum sicheren
Ausfallwahrscheinlichkeit, da Betrieb zu speziellen Produkten
Appliances oft weniger erhltlich (ber die Informationen
"bewegliche Teile" enthalten (z. B. des Herstellers hinaus). Dies ist
Festplatte oder Lfter) als normale besonders dann problematisch,
Rechner. wenn der Hersteller den Support
einstellt.
- Bestimmte Appliances besitzen u.
U. eine geringe Verbreitung. In
diesem Fall existieren evtl. wenig
Berater bzw. Dienstleister zur
Administration.
Tabelle 3: Verwndung einer Appliance
Anforderungen an Paketfilter
Bei allen drei Realisierungsformen lsst sich gegebenenfalls die
Paketfilterkonfiguration aus den Einstellungen eines eventuell vorhandenen
ALGs automatisch ableiten. Dies besitzt zum einen den Vorteil des geringen
Konfigurationsaufwandes, zum anderen den Nachteil der geringeren
Sicherheit, da eine Fehlkonfiguration des ALGs automatisch eine
Fehlkonfiguration des Paketfilters bewirkt.
Vor der Beschaffung sollte berprft werden, welche der folgenden
Anforderungen das ALG erfllt. Je nach Anwendungszusammenhang kann
dabei auf einige Anforderungen verzichtet werden, d. h. es muss eine
Bewertung der aufgelisteten Anforderungen im Anwendungszusammenhang
erfolgen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Folgende Mglichkeiten sollten vom Paketfilter untersttzt werden:

1. Weiterleiten oder Verwerfen von Paketen anhand
- der Quell-IP- und Ziel-IP-Adresse einzelner Rechner oder Netze
- des Quell- und Zielports
- des ICMP-Typs
- aller TCP-Flags (URG, ACK, PSH, RST, SYN, FIN). Mit Hilfe des
ACK-Bits kann beispielsweise zwischen Paketen zum
Verbindungsaufbau und Paketen im Rahmen einer etablierten
Verbindung unterschieden werden. Durch Kontrolle der anderen Bits
knnen IP-Pakete mit unsinnigen Kombinationen von TCP-Flags
abgelehnt werden
- der IP-Optionen.
2. Untersttzung der Aktionen
- Weiterleiten des Pakets ("allow")
- Verwerfen des Pakets ("deny & drop")
- Verwerfen des Pakets und Meldung an den Absender ("deny &
reject")
3. Erstellung von Filterregeln getrennt fr jede Schnittstelle des Paketfilters
4. Getrennte Filterung kommender und gehender Pakete
5. Unvernderbare Festlegung der Reihenfolge zur Abarbeitung der
Filterregeln
6. Protokollierung von IP-Adresse, Dienst, Zeit und Datum fr jedes Paket,
aber auch eingeschrnkt auf bestimmte Pakete
7. Im Falle, dass ein Router als Paketfilter eingesetzt wird, muss das
dynamische Routing so konfigurierbar sein, dass Routing-Pakete (z. B.
RIP), die das zu schtzende Netz betreffen, nur an dem Interface
zugelassen werden, das auch mit dem zu schtzenden Netz verbunden ist.
8. Schutz vor IP-Spoofing
9. Falls nur ein Paketfilter ohne ALG als Sicherheitsgateway eingesetzt wird,
mssen zustzlich folgende Funktionen untersttzt werden:
- Port-Forwarding (auch oft "Destination NAT" genannt)
- Network Address Translation (NAT). Auch Untersttzung fr:
- Ersetzen der IP-ID
- Ersetzen der TTL
- Stateful Inspection
Die Anforderungen an den Paketfilter und die Grnde, die fr die getroffene
Auswahl ausschlaggebend waren, sollten nachvollziehbar dokumentiert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welche Anforderungen an den Paketfilter wurden festgelegt?
- Welche Formen von Paketfiltern (Rechner, Router, Appliance) werden
eingesetzt? Sind die Grnde fr die Auswahl dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.75 Geeignete Auswahl eines Application-Level-

Gateways
Die Funktionen eines Sicherheitsgateways auf Anwendungsebene werden von
den so genannten Application-Level-Gateways (ALG) bernommen. Implizit
nehmen ALGs auch Funktionen auf den Schichten 1-3 wahr. ALGs werden oft
auch Sicherheitsproxies genannt, im Folgenden wird aber abkrzend der
Begriff "Proxy" verwendet. Proxies unterbrechen den direkten Datenstrom
zwischen Quelle und Ziel. Bei einer Kommunikation zwischen Client und
Server ber einen Proxy hinweg nimmt der Proxy die Anfragen des Clients
entgegen und leitet sie an den Server weiter. Bei einem Verbindungsaufbau in
umgekehrter Richtung, also vom Server zum Client, verfhrt der Proxy
analog. Smtliche Kommunikationsbeziehungen zwischen den beiden
Rechnern verlaufen in diesem Fall also mittelbar ber den Proxy.
Einige Vor- und Nachteile von Sicherheitsproxies werden in der folgenden
Tabelle zusammengestellt:
Vorteile von Proxies

- Oft geringere Anzahl von Programmierfehlern als in den vom Proxy
geschtzten Client- bzw. Serverdienstprogrammen.
- Filterung einzelner Protokollbefehle (z. B. bei HTTP der Befehl POST) in
Abhngigkeit von der Parametrisierung der Befehle, der Zeit und des
Benutzer mglich.
- Entfernung unerwnschter Inhalte in den bertragenen Daten.
- Abwehr von Angriffen, die auf fehlerhaften Header-Daten beruhen.
- Ersetzung der Absender-Adresse eines weitergeleiteten IP-Pakets durch die
IP-Adresse der Netzschnittstelle, ber die das Paket den Proxy verlsst.
Dadurch werden IP-Adressen des vertrauenswrdigen Netzes verheimlicht.
Im DNS braucht zudem nur eine IP-Adresse eingetragen werden.
- Erzwingen einer starken Authentisierung mglich.
- Umfangreiche Protokollierungsmglichkeiten. Fr jede Verbindung auf der
Anwendungsebene kann protokolliert werden:
- Benutzeridentifikation
- IP-Adresse des Quell- und Zielrechners
- Portnummern
- Zeit und Datum
In Abhngigkeit vom Dienst knnen weitergehende Informationen
protokolliert werden (z. B. URL bei HTTP).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Nachteile von Proxies

- Verringerung des maximalen Datendurchsatzes.
- Lngere Antwortzeiten (Latenzzeiten) beim Abruf von Informationen.
Eventuell Einschrnkung der Funktionalitt der Clientprogramme (z. B. durch
Filterung aktiver Inhalte
Proxies knnen in zwei verschiedenen Betriebarten arbeiten, dem sogenannten Transparente und nicht-
transparente Proxies
transparenten und dem nicht-transparentem Modus. Ein transparenter Proxy
braucht den Clients nicht mitgeteilt zu werden. Er liest alle im Netz
befindlichen IP-Pakete mit und entscheidet anhand von IP-Adresse und
Portnummer, welche davon in ein anderes Netz weitergeleitet werden sollen.
Bei Verwendung eines nicht-transparenten Proxies hingegen muss dessen
IP-Adresse und Portnummer in der Client-Software (z. B. dem Webbrowser)
eingetragen werden, um eine Verbindung ber den Proxy hinweg zu
ermglichen.
Vor der Beschaffung sollte berprft werden, welche der folgenden
Anforderungen das ALG erfllt. Je nach Anwendungszusammenhang kann
dabei auf einige Anforderungen verzichtet werden.
Die aufgelisteten Anforderungen mssen im Anwendungszusammenhang
bewertet werden. Wenn ein bestimmtes Protokoll nicht genutzt wird, braucht
das ALG keine Untersttzung fr das Protokoll zu bieten. Untersttzt das
ALG Protokolle, die nicht genutzt werden, so sollte die Mglichkeit bestehen,
das betreffende Protokoll zu deaktivieren.
Wurde fr einige der im folgenden aufgefhrten Protokolle in der Policy des
Sicherheitsgateway festgelegt, dass sie nicht erlaubt sein sollen, so brauchen
Sie natrlich auch nicht untersttzt zu werden.
Die die Kriterien der Bewertung und die getroffenen Entscheidungen mssen
nachvollziehbar dokumentiert werden.
Allgemein
1. Untersttzung der wichtigsten verwendeten Protokolle (beispielsweise
Telnet, FTP, SMTP, NNTP, HTTP und HTTPS) auf Anwendungsschicht.
Fr die Nutzung anderer Dienste sollten generische Proxies fr TCP- und
UDP vorhanden sein.
2. Die Proxies des Application-Level-Gateways sollten transparent betrieben
werden knnen.
3. Es sollte ein eigener MTA auf dem ALG integriert werden knnen, um
gegebenenfalls mehrere MTAs in verschiedenen vertrauenswrdigen
Netzen bedienen zu knnen.
4. Es sollte eine Schnittstelle zum Anbinden von externen
Analyseprogrammen zum Auffinden von Schadsoftware (z. B.
Virensuchprogramme) vorhanden sein.
5. Die Kommunikation mit einem Directory-Dienst fr die Authentisierung
der Anwender sollte untersttzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
6. Fr jedes untersttzte Protokoll muss eine Filterung nach den in M 2.76

Auswahl und Einrichtung geeigneter Filterregeln spezifizierten Kriterien
mglich sein. Insbesondere mssen die Filterregeln benutzerabhngig
formulierbar sein, und es muss mglich sein, mehrere Benutzer zu einer
Gruppe zusammenzufassen.
7. Eine Filterung in Abhngigkeit von Inhalten sollte untersttzt werden,
damit eine zentrale Virenprfung und das Blockieren aktiver Inhalte
mglich ist (siehe G 5.23 Computer-Viren bzw. G 5.88 Missbrauch aktiver
Inhalte).
8. Bei dem Einsatz eines Application-Level-Gateways sollte keine nderung
der Software im zu schtzenden Netz oder im externen Netz ntig sein.
9. Fr jede aufgebaute und abgewiesene Verbindung auf der
Anwendungsschicht muss eine Protokollierung von IP-Adresse des Quell-
und Zielrechners, Portnummern, Zeit, Datum und der zutreffenden Regel
durchgefhrt werden, wobei auch Einschrnkungen auf bestimmte
Verbindungen mglich sein mssen.
10. Die bertragene Datenmenge sollte protokolliert werden knnen.
11. Die Uhrzeit des Verbindungsaufbaus und des Verbindungsabbaus sollten
protokolliert werden knnen.
Im Folgenden werden spezifischere Anforderungen fr einige hufig genutzte
Protokolle zusammengestellt:
HTTP:
12. Filtern anhand der Request-Methode, z. B. GET, HEAD, PUT oder
CONNECT
13. Sperren von Web-Seiten bzw. Web-Sites anhand der URL
14. Filtern anhand des MIME-Types
15. Entfernen von aktiven Inhalten und Cookies aus Web-Seiten
16. Filtern anhand von HTTP-Header-Daten
17. Filtern der folgenden Header-Felder sollte mglich sein:
- Referrer
- Via
- From
- Server
18. Filtern von "Web-Bugs"
19. Erzwingen einer starken Authentisierung am Proxy
20. Accounting zur Feststellung der von einen Nutzer abgerufenen
Datenmenge
21. Untersttzung zur Signaturprfung von signierten aktiven Inhalten
22. Protokollierung der abgerufenen Web-Seite
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
23. Protokollierung der Nutzung von gesperrten Request-Methoden

HTTPS:
24. Temporre Entschlsselung des Datenverkehrs, um das Entfernen aktiver
Inhalte aus Web-Seiten, die mittels HTTPS abgerufen werden, zu
ermglichen. Temporre Entschlsselung bedeutet, dass bermittelte Daten
erst entschlsselt, nach der Filterung auf aktive Inhalte aber wieder
verschlsselt werden.
25.Protokollierung der abgerufenen Web-Seite
26. Benachrichtigung des Administrators bei automatischem Update
abgelaufener oder ungltiger Zertifikate
SMTP:
27. Entfernen von aktiven Inhalten aus HTML-E-Mails
28. Filtern anhand des MIME-Types
29. Filtern anhand der Absender- und Empfngeradresse
30. Filtern anhand der IP-Adresse des MTAs
31. Kontrolle auf Mail-Relaying anhand des Domain-Namens
32. berprfung auf Zustellbarkeit der E-Mail anhand des Domain-Namens
33. Entfernung bedenklicher E-Mailanhnge anhand der Dateiendung. Zu
blockierende Anhnge sollen frei vorgegeben werden knnen.
34. Erkennung von Spam-Mails mit Hilfe einer Kombination verschiedener
Filter-Verfahren.
35. Erkannte Spam-Mails sollten wie folgt behandelt werden knnen:
- Lschen
- Isolierung ("Quarantne")
- Markieren
36. Erkannte E-Mails mit nicht spezifikationskonformen Headern ("Bad-
Mails"), sollten wie folgt behandelt werden knnen:
- Lschen
- Isolierung ("Quarantne")
- Markieren
37. Bereitstellung einer Schnittstelle, die die Anbindung eines Spam-Filters
ermglicht.
38. Blockieren von (ausgehenden) E-Mails aufgrund der Erkennung von
Schlsselwrtern
39. Protokollierung der E-Mail-Adressen des Absenders und des Adressaten
40. Protokollierung des Erfolgs bzw. des Fehlschlagens der E-Mail-
Weiterleitung
41. Mglichkeit zur Einrichtung eines
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Mail-Relay (Weiterleitung von einem MTA im vertrauenswrdigen

Netz zu einem MTA im nicht-vertrauenswrdigen Netz)
- Mail-Server (Mglichkeit zum Abruf mit POP3 oder IMAP und zur
Weiterleitung mit SMTP)
FTP (passiv und aktiv):
42. Filterung anhand von FTP-Befehlen (z. B. GET, PUT, PASV, PORT)
43. Nutzerbasierte Freigabe bzw. Sperrung von FTP-Befehlen
44. Restriktionen anhand des Dateinamens (z. B. Sperrung von *.exe)
47. Protokollierung des Benutzernamens im Falle einer Authentisierung und
des Dateinamens
NNTP:
48. Filtern anhand der Request-Methode, z. B. ARTICLE, BODY, HEAD und
STAT
50. Entfernen von aktiven Inhalten und Cookies aus Web-Seiten
52. Gezielte Sperrung einzelner Foren
Telnet:
54. Protokollierung des Benutzernamens im Falle einer Authentisierung
POP:
55. Filtern anhand der Request-Methode, z. B. STAT, LIST, RETR oder
DELE
56. Entfernen von aktiven Inhalten und Cookies aus HTML-E-Mails
UDP- und TCP-Relays:
59. Protokollierung des Benutzernamens im Falle einer Authentisierung
IP-Relay:
60. Der Aufbau von VPNs ber das Application-Level-Gateway sollte mittels
IP-Relays untersttzt werden.
DNS:
61. Bereitstellung einer integrierten Lsung bestehend aus ffentlichem und
privatem DNS-Server
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
62. Sichere Abschottung des DNS-Proxies vom Rest des Betriebssystems des
ALGs
Klartextprotokolle wie Telnet und FTP sollten nach Mglichkeit nicht mehr in
ffentlichen Netzen benutzt werden und durch sicherere Alternativen (SSH /
SCP) ersetzt werden. Auch im internen Netz sollten sie nur dann noch
verwendet werden, wenn aus zwingenden Grnden ein Umstieg auf SSH oder
ein anderes sicheres Protokoll nicht mglich ist.
Auch POP sollte nach Mglichkeit allenfalls noch intern verwendet werden.
Sollen von einem externen Mailserver (etwa bei einem Provider) E-Mails
abgerufen werden, so sollte der Variante "POP ber SSL" der Vorzug gegeben
werden. In diesem Fall ist allerdings ein SSL-Proxy (analog zum HTTPS-
Proxy) ntig, der die verschlsselte Verbindung am Sicherheitsgateway
unterbricht und es so ermglicht, E-Mails zentral auf Viren und andere
schdliche Inhalte zu prfen.
- Welche Protokolle untersttzt das ausgewhlte ALG? Knnen nicht
genutzte Protokolle deaktiviert werden?
- Wurde die Auswahl und Bewertung der Anforderungen an das ALG
dokumentiert?
- Erfllen die eingesetzten Proxies die aufgefhrten Anforderungen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.76 Auswahl und Einrichtung geeigneter

Filterregeln
Das Aufstellen und die notwendige Aktualisierung der Filterregeln fr ein
Sicherheitsgateway ist keine einfache Aufgabe. Der Administrator muss dafr
fundierte Kenntnisse der eingesetzten Protokolle besitzen und entsprechend
geschult werden.
Beim Aufstellen der Filterregeln sollten folgende Punkte beachtet werden:
- Grundstzlich sollte die "Whitelist" Strategie verwendet werden, das heit
die Regeln sollten so formuliert werden, dass alle Zugnge, die nicht
explizit erlaubt werden, verboten sind.
- Falls es Bedarf fr eine benutzerspezifische Authentisierung gibt, muss
geklrt werden, welche Benutzer aus dem internen Netz welche Dienste
verwenden drfen und welche Authentisierungsverfahren eingesetzt
werden sollen.
- Alle Rechner im inneren Netz mssen bercksichtigt werden.
- Es muss festgelegt werden, welche Dienste zu welchen Zeiten zur Verf- zeitliche
Beschrnkungen
gung stehen sollen. Wenn eine Organisation festgelegte Arbeitszeiten hat,
Mitarbeiter z. B. nur zwischen 7.00 und 19.00 Uhr anwesend sein knnen,
so sollte es auerhalb der blichen Arbeitszeiten auch nicht mglich sein,
Verbindungen aufzubauen.
Die Filterregeln sollten in einer Tabelle zusammengefasst werden, deren eine
Achse die Ziel-IP-Adressen und deren andere Achse die Quell-IP-Adressen
enthlt. Die Eintrge enthalten dann die erlaubten Portnummern, dabei ist die
obere der Quell-, die untere der Zielport. Paketfilter knnen die berprfung
der Pakete unter anderem unmittelbar nach dem Empfang oder unmittelbar vor
der Weiterleitung durchfhren. Normalerweise sollte die erste Variante
gewhlt werden. Auerdem mssen die Paketfilter so konfiguriert werden,
dass als Absenderadresse nur die Nummern der an dem Interface
angeschlossenen Rechner zugelassen werden ("Ingress-Filterung"). Adressen,
die mit den anderen Interfaces verknpft sind, drfen nicht durchgelassen
werden. Dies verringert die Gefahr von IP-Spoofing Angriffen.
Beispiel:
Die folgende Tabelle enthlt Filterregeln fr das interne Interface eines
Paketfilters zwischen einem internen Netz und dem Zwischennetz, das sich
zwischen dem internen und dem externen Paketfilter befindet und die
Verbindungen zwischen diesen kontrolliert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Eintrge enthalten die erlaubten Verbindungen, dabei bezeichnet der

obere Eintrag den Quellport und der untere Eintrag den Zielport.
Zwischennetz
an Appl.-Level- externen DNS- externen
von Gateway Server Mailserver
TCP > 1023
Internem Mailserver ---- ---- ----
TCP: 25
UDP: 53
Internem DNS-Server ---- ---- ----
UDP: 53
IT-System mit TCP > 1023
IP-Adresse ---- ---- -----
192.168.0.5
TCP: 20,21
IT-System mit TCP > 1023
IP-Adresse ---- ---- ----
192.168.0.7
TCP: 23
IT-Systeme mit TCP > 1023
IP-Adresse ---- ---- ----
192.168.0.*
TCP: 22,80
IT-Systeme mit TCP > 1023
IP-Adresse ---- ---- ----
192.168.1.*
TCP: 80
Tabelle 1: Filterregeln fr das interne Interface eines Paketfilters
Dies bedeutet beispielsweise, dass der interne Mailserver mit TCP von einem
Port mit einer Portnummer > 1023 auf Port 25 (SMTP) des externen
Mailservers im Zwischennetz zugreifen darf. Ports mit einer Portnummer >
1023 werden auch als unprivilegierte Ports bezeichnet, im Gegensatz zu Ports
mit niedrigeren Portnummern, die als privilegierte oder "well-known Ports"
bezeichnet werden, da die Dienste hinter diesen Portnummern von der
"Internet Assigned Numbers Authority" (IANA) zugewiesen sind.
Diese Tabelle muss dann in entsprechende Filterregeln umgesetzt werden.
Dies ist hufig nicht einfach und muss deshalb sehr genau kontrolliert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ggf. knnen die Filterregeln mit Hilfe von Tools umgesetzt werden, die ber
Bedienoberflchen die Modellierung des Netzes und der zugehrigen
Filterregeln erleichtern. Durch regelmige Tests muss berprft werden, dass
alle Filterregeln korrekt umgesetzt worden sind. Insbesondere muss
sichergestellt werden, dass nur die Dienste zugelassen werden, die in der
Sicherheitsrichtlinie vorgesehen sind.
Fr die Regeln eines Application-Level-Gateways sind analoge Tabellen zu
erstellen und in die entsprechenden Filterregeln umzusetzen.
Beispiel:
Benutzername Dienst Befehl Authentisierung

Frau Beispiel FTP ..., RETR, STOR Einmalpasswort
Herr Mustermann FTP ..., RETR Chipkarte
Tabelle 2: Tabelle fr die Regeln eines Application-Level-Gateways
Die Benutzerin Frau Beispiel darf (unter anderem) die Befehle RETR und
STOR des Dienstes FTP benutzen, d. h. sie darf ber FTP Dateien laden und
senden, whrend Herr Mustermann nur Dateien laden darf.
Ergnzende Kontrollfragen
- Besitzen die Administratoren die notwendigen Kenntnisse, um die
Filterregeln zu formulieren?
- Wurde die Tabelle der erlaubten IP- und Port-Kombinationen erstellt?
- Wurde die Umsetzung der Tabelle in Filterregeln berprft? Entsprechen
die Filterregeln den in der Tabelle formulierten Anforderungen?
- Wurden die Regeln des ALG entsprechend formuliert und umgesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.77 Integration von Servern in das

Sicherheitsgateway
Neben Installation und Betrieb des Sicherheitsgateways mssen oft auch
Server sicher angeordnet werden. Dazu gehren z. B. Informationsserver fr
die Bereitstellung von Informationen an interne oder externe Benutzer,
Mailserver und DNS-Server.
Fr die Anordnung von Servern ist zu unterscheiden, ob diese im zu
schtzenden Netz, im Netz zwischen den beiden Paketfiltern (im Folgenden
nur noch "Zwischennetz" genannt) oder auf der externen Seite des
Sicherheitsgateways angesiedelt werden sollen.
Externe Zugnge
Externe Zugnge zum vertrauenswrdigen Netz, beispielsweise mit SSH ber
einen Modem-Pool, sollten wie Zugnge aus dem nicht-vertrauenswrdigen
Netz behandelt werden. Dies lsst sich erreichen, indem z. B. ein
Terminalserver mit angeschlossenen Modems auf die externe Seite des
Sicherheitsgateways gestellt wird, so dass ein Zugang von dort nur ber SSH
zum internen Rechner durchgefhrt werden kann.
Es mssen klare Regelungen darber getroffen werden, dass keine externen Keine Zugnge am
Sicherheitsgateway
Zugnge unter Umgehung des Sicherheitsgateways geschaffen werden drfen. vorbei
Diese Regelungen mssen allen Mitarbeitern bekanntgemacht werden. Es
muss sichergestellt werden, dass sowohl das IT-Sicherheitsmanagement als
auch der Administrator des Sicherheitsgateways rechtzeitig ber
entsprechende Plne unterrichtet wird, um eine Einbettung in das IT-
Sicherheitskonzept und die Sicherheitsrichtlinie des Sicherheitsgateways zu
gewhrleisten.
Weitere Informationen zur Behandlung externer Zugnge finden sich auch im
Kapitel 7.6 Remote Access.
Anordnung von Informationsservern
Server, die der Bereitstellung von Informationen fr externe Benutzer dienen,
sollten generell "mglichst nahe" am nicht-vertrauenswrdigen Netz platziert
werden (z. B. hinter dem externen Paketfilter) und wie andere im nicht-
vertrauenswrdigen Netz vorhandene Server betrachtet werden. Die
Platzierung "mglichst weit auen" erschwert bei einer Kompromittierung des
Informationsservers den Zugriff auf das vertrauenswrdige Netz, da der
Angreifer noch mehrere Komponenten des Sicherheitsgateways berwinden
muss. Ihre Verwaltung sollte entweder nur lokal oder ber speziell
abgesicherte und gegebenenfalls sogar zeitlich begrenzte Zugnge vom
vertrauenswrdigen Netz aus erfolgen.
Da Informationsserver, die Informationen fr externe Benutzer anbieten, wie
Rechner des nicht vertrauenswrdigen Netzes behandelt werden sollten, sollte
durch Filterregeln und gegebenenfalls durch eine entsprechende Konfiguration
des Servers sichergestellt werden, dass von einem solchen Server aus keine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verbindungen ins vertrauenswrdige Netz hinein mglich sind, sondern nur

vom vertrauenswrdigen Netz aus zum Server.
Beispielsweise sollten fr einen Webserver, dessen Administration vom
vertrauenswrdigen Netz aus ber eine SSH-Verbindung erfolgt, keine SSH-
Verbindungen erlaubt werden, die vom Server ausgehen, sondern nur
Verbindungen, die vom vertrauenswrdigen Netz zum Server gehen.
Gibt es Daten, die nur fr die Benutzer des vertrauenswrdigen Netzes Getrennte Server fr
Intranet und externes
erreichbar sein sollen (etwa einen Intranet-Webserver), so sollten diese Netz
mglichst nicht auf einem Server gespeichert werden, der auch Dienste fr
externe Benutzer anbietet. In diesem Fall wird empfohlen, weitere
Informationsserver im Zwischennetz einzusetzen, die von auen nicht
erreichbar sind und gegen Angriffe von innen durch den Paketfilter geschtzt
werden.
Falls die Daten, die nur fr interne Benutzer erreichbar sein sollen einen hohen
Schutzbedarf bezglich der Vertraulichkeit haben, so darf der entsprechende
Informationsserver nicht im gleichen Zwischennetz angesiedelt werden, wie
Informationsserver fr externe Benutzer. In diesem Fall muss eine eigene
DMZ fr die betreffenden Server eingerichtet werden.
Fr folgende Informationsserver werden in eigenen Manahmen Hinweise zur
Integration in ein Sicherheitsgateway gegeben:
- Webserver (siehe M 5.115 Integration eines Webservers in ein
Sicherheitsgateway)
- E-Mailserver (siehe M 5.116 Integration eines E-Mailservers in ein
Sicherheitsgateway)
- Datenbankserver (siehe M 5.117 Integration eines Datenbank-Servers in
ein Sicherheitsgateway)
- DNS-Server (siehe M 5.118 Integration eines DNS-Servers in ein
Sicherheitsgateway)
- Webanwendung mit Web-, Applikations- und Datenbankserver (siehe
M 5.119 Integration einer Web-Anwendung mit Web-, Applikations- und
Datenbank-Server in ein Sicherheitsgateway)
- Werden Daten, die nur fr interne Benutzer verfgbar sein sollen, von
Daten fr externe Benutzer getrennt?
- Sind Server mit sensiblen Daten, die nur fr interne Benutzer zugnglich
sein sollen, in einer eigenen DMZ angesiedelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.78 Sicherer Betrieb eines Sicherheitsgateways

Fr einen sicheren Betrieb eines Sicherheitsgateways sind die umgesetzten
Sicherheitsmanahmen regelmig auf ihre korrekte Einhaltung zu
berprfen. Insbesondere mssen die fr den Betrieb des Sicherheitsgateways
getroffenen organisatorischen Regelungen regelmig/sporadisch auf ihre
Einhaltung berprft werden. Es sollte in regelmig kontrolliert werden, ob
neue Zugnge unter Umgehung des Sicherheitsgateways geschaffen wurden.
Durch regelmige Tests muss auerdem berprft werden, dass alle Filter- Filterregeln testen
regeln korrekt umgesetzt worden sind. Dabei ist zu testen, dass nur die Dienste
zugelassen werden, die in der Policy des Sicherheitsgateways erlaubt sind.
Falls nachtrgliche nderungen der Policy erforderlich sind, mssen diese
streng kontrolliert werden und insbesondere auf Seiteneffekte berprft
werden.
Die bei der Beschaffung an Paketfilter bzw. an Application-Level-Gateways
gestellten Forderungen sind umzusetzen. Sie sind regelmig zu aktualisieren
und auf Vollstndigkeit zu prfen.
Die Default-Einstellung der Filterregeln und die Anordnung der Komponenten
muss sicherstellen, dass alle Verbindungen, die nicht explizit erlaubt sind,
blockiert werden. Dies muss auch bei einem vlligen Ausfall der
Komponenten des Sicherheitsgateways gelten.
Es muss die Regel "Alles was nicht ausdrcklich erlaubt ist, ist verboten"
realisiert sein. So darf z. B. ein Benutzer, der keinen Eintrag in einer Access-
Liste hat, keine Mglichkeit haben, Dienste des Internets zu benutzen.
Darber hinaus sind die folgenden Punkte zu beachten:
- Alle Gerte (Rechner, Router oder Appliances), die Bestandteil eines Besonders sorgfltige
Konfiguration der
Sicherheitsgateways sind, mssen besonders sorgfltig und sicher Komponenten
- Auf den eingesetzten Komponenten drfen nur Programme vorhanden
sein, die fr die Funktionsfhigkeit des Sicherheitsgateways ntig sind. Der
Einsatz dieser Programme muss ausfhrlich dokumentiert und begrndet
werden. Beispielsweise sollten Dienste deaktiviert und Treiber entfernt
werden, die nicht bentigt werden. Treiber sollten nach Mglichkeit auch
aus dem Betriebssystem-Kern entfernt werden. Das Verbleiben von
Software muss dokumentiert und begrndet werden.
- Um ein Mitlesen oder Verndern der Authentisierungsinformationen zu Sicherer Zugriff
verhindern, drfen Administratoren und Revisoren nur ber einen vertrau-
enswrdigen Pfad auf das Sicherheitsgateway zugreifen, beispielsweise
direkt ber die Konsole, ber eine verschlsselte Verbindung oder ber ein
separates Administrationsnetz (Out-of-Band Management).
- Es muss dafr gesorgt werden, dass die Betriebssysteme und Programme Sicherer Patch-Stand!
auf den Komponenten des Sicherheitsgateways jederzeit auf einem
sicheren Patch-Stand sind. Die Systemadministratoren mssen sich daher
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
regelmig ber bekannt gewordene Software-Schwachstellen informieren

und sicherheitskritische Patches besonders sorgfltig zeitnah installieren
(siehe auch M 2.35 Informationsbeschaffung ber Sicherheitslcken des
Systems, M 2.273 Zeitnahes Einspielen sicherheitsrelevanter Patches und
Updates, sowie M 4.177 Sicherstellung der Integritt und Authentizitt von
Softwarepaketen).
- Es mssen in regelmigen Abstnden Integrittstests der eingesetzten Regelmige
Integrittstests
Software durchgefhrt werden (siehe auch M 4.93 Regelmige
Integrittsprfung). Im Fehlerfall muss das Sicherheitsgateway
abgeschaltet werden.
- Das Sicherheitsgateway muss auf sein Verhalten bei einem Systemabsturz
getestet werden. Insbesondere sollte kein automatischer Neustart mglich
sein und es muss mglich sein, die Access-Listen auf einem
schreibgeschtzten Medium zu speichern.
Die Access-Listen sind die wesentlichen Daten fr den Betrieb des
Sicherheitsgateways sind. Daher muss durch einen entsprechenden Schutz
sichergestellt werden, dass auch dann keine alten oder fehlerhaften Access-
Listen benutzt werden, falls es einem Angreifer gelingt, einen Neustart des
Sicherheitsgateways oder einzelner Komponenten zu verursachen.
- Bei einem Ausfall des Sicherheitsgateways muss sichergestellt sein, dass in
dieser Zeit keine Netzverbindungen aus dem zu schtzenden Netz heraus
oder zu diesem aufgebaut werden knnen (siehe auch M 2.302
Sicherheitsgateways und Hochverfgbarkeit und M 6.94 Notfallvorsorge
bei Sicherheitsgateways).
- Beim Wiedereinspielen von gesicherten Datenbestnden muss darauf
geachtet werden, dass fr den sicheren Betrieb des Sicherheitsgateways
relevante Dateien wie Access-Listen, Passwortdateien oder Filterregeln auf
dem aktuellsten Stand sind.
- Sind die Komponenten des Sicherheitsgateways sicher konfiguriert?
- Wie wird sichergestellt, dass die Betriebssysteme und Programme, die auf
den Komponenten des Sicherheitsgateways eingesetzt werden, stets auf
einem sicheren Patch-Stand sind?
- Auf welchem Weg greifen Administratoren oder Revisoren auf das
Sicherheitsgateway bzw. die Komponenten zu?
- In welchen Abstnden finden Integrittsprfungen statt?
- Was geschieht bei einem Absturz oder Neustart des Sicherheitsgateways?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.79 Festlegung der Verantwortlichkeiten im Bereich

Standardsoftware
Vor der Einfhrung von Standardsoftware mssen eine Reihe von Verant-
wortlichkeiten geregelt werden. Beispielhaft seien die Verantwortlichkeiten
genannt fr die Erstellung eines Anforderungskataloges, die Vorauswahl von
Produkten, das Testen und Freigeben und die Installation.
Nachfolgend wird zum Vergleich aufgezeigt, wie diese Verantwortlichkeiten
sinnvoll verteilt werden knnen. Da jedoch die Bezeichnungen in den meisten
Organisationen voneinander abweichen, werden vorab einige Instanzen
anhand ihrer Aufgaben definiert, denen anschlieend die einzelnen Verant-
wortlichkeiten zugeordnet werden knnen:
- Die Fachabteilung ist der Anwender der Standardsoftware. Sie uert
ihren Bedarf an neuer Software und gibt damit den Ansto zu deren
Beschaffung. Sie wird bei Vorauswahl und Test beteiligt, um die
Anforderungen der Anwender einzubringen.
- Die Behrden-/Unternehmensleitung ist verantwortlich fr die Freigabe
von Standardsoftware. Diese Verantwortung wird meist an den Leiter der
Fachabteilung delegiert, womit nach Freigabe die Verantwortung fr den
korrekten Einsatz der Standardsoftware auf die Fachabteilung bergeht.
- Der IT-Bereich hat die Aufgabe, IT-Lsungen fr die Erfllung der Auf-
gaben der Fachabteilung bereitzustellen und den sicheren und zuver-
lssigen Betrieb der IT zu gewhrleisten.
- Die Beschaffungsstelle muss die Interoperabilitt und Kompatibilitt der
zu beschaffenden Standardsoftware sowie die Einhaltung von Haus-
standards und gesetzlichen Vorschriften sicherstellen. Oft gibt es in den
einzelnen Fachabteilungen IT-Koordinatoren, die Teile der Aufgaben der
Beschaffungsstelle fr die Fachabteilung beratend wahrnehmen und evtl.
auch die Haushaltsmittel der Fachabteilung koordinieren.
- Der Haushalt ist verantwortlich fr das Rechnungswesen, die IT-
Budgetverwaltung und fr die Bereitstellung der bentigten Haus-
haltsmittel.
- Der IT-Sicherheitsbeauftragte muss berprfen, ob mit den eingesetzten
oder zu beschaffenden Produkte ein angemessenes IT-Sicherheitsniveau
gewhrleistet werden kann. Im Rahmen des IT-Sicherheitsmanagements
(vgl. Kapitel 1) muss er die IT-Sicherheit im laufenden Betrieb sicher-
stellen.
- Der Datenschutzbeauftragte muss die Einhaltung der datenschutz-
rechtlichen Bestimmungen und eines ausreichenden Schutzes personen-
bezogener Daten gewhrleisten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Personal- bzw. Betriebsrat muss in vielen Fllen bei der Auswahl
neuer Standardsoftware beteiligt werden, insbesondere wenn damit grere
nderungen im Arbeitsablauf verbunden sind oder wenn die zu
beschaffende Software zur Leistungskontrolle geeignet ist (siehe M 2.40
Rechtzeitige Beteiligung des Personal-/Betriebsrates).
Im Gesamtprozess "Standardsoftware" muss fr jeden einzelnen Schritt fest-
gelegt werden, welche der zuvor beschriebenen Instanzen fr die Durch-
fhrung verantwortlich sind und welche Instanzen dabei beteiligt werden
mssen. Eine mgliche sinnvolle Verantwortungsverteilung ist zur Orien-
tierung in nachfolgender Tabelle zusammengefasst:
verantwortlich zu beteiligen
Erstellung des Fachabteilung, IT- Beschaffungsstelle, Haushlter,
Anforderungs- Bereich IT-Sicherheitsbeauftragter,
katalogs Datenschutzbeauftragter,
Personal- oder Betriebsrat
Vorauswahl eines Beschaffungsstelle IT-Bereich, Fachabteilung
geeigneten
Produktes
Testen Fachabteilung und IT- IT-Sicherheitsbeauftragter,
Bereich Datenschutzbeauftragter,
Personal- oder Betriebsrat
Freigabe Behrden- -
/Unternehmensleitung
evtl. delegiert an Leiter
Fachabteilung
Beschaffung Beschaffungsstelle Haushalt
Sicherstellen der IT-Bereich -
Integritt der
Software
Installation und IT-Bereich -
Konfiguration
Versionskontrolle IT-Bereich -
und Lizenz-
verwaltung
Deinstallation IT-Bereich -
Kontrolle des IT- IT-Sicherheits- -
Betriebs beauftragter
Die getroffenen Zuordnungen sind verbindlich festzuschreiben und deren

Einhaltung ist periodischen Kontrollen zu unterziehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind alle Mitarbeiter ber bestehende Richtlinien und ber deren Kontrolle
unterrichtet?
- Werden alle relevanten Stellen (z. B. Personalrat, Haushalt, Datenschutz-
beauftragter, ...) entsprechend ihrer Funktion beteiligt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.80 Erstellung eines Anforderungskatalogs fr

Standardsoftware
Verantwortlich fr Initiierung: Leiter Fachabteilung
Verantwortlich fr Umsetzung: Fachabteilung, Leiter IT
Zur Lsung einer Aufgabe, die mit IT bearbeitet wird, bietet der Markt meist
eine Vielzahl gleichartiger Standardsoftwareprodukte an. In ihrer Grundfunk-
tionalitt vergleichbar, unterscheiden sie sich jedoch in Kriterien wie Anschaf-
fungs- und Betriebskosten, Zusatzfunktionalitten, Kompatibilitt,
Administration, Ergonomie und IT-Sicherheit.
Anforderungskatalog
Fr die Auswahl eines geeigneten Produktes muss daher zunchst ein Anfor-
derungskatalog erstellt werden. Der Anforderungskatalog sollte u. a. zu den
folgenden Punkten Aussagen enthalten:
- Funktionale Anforderungen, die das Produkt zur Untersttzung der Auf-
gabenerfllung der Fachabteilung erfllen muss. Die fr die Fachaufgabe
relevanten Einzelfunktionalitten sollten hervorgehoben werden.
Verkrzte Beispiele:
- Textverarbeitung mit den Zusatzfunktionen Einbinden von Graphi-
ken, Makro-Programmierung, Rechtschreibprfung und Silbentren-
nung. Makro-Programmierung muss abschaltbar sein, Rechtschreib-
prfung muss in Englisch, Franzsisch und Deutsch verfgbar sein.
Die spezifizierten Textformate mssen im- und exportiert werden
knnen.
- Datenbank (Front-End und Back-End) fr Multi-User-Betrieb mit
Untersttzung der Standardabfragesprache SQL und graphischer
Bedienoberflche
- Terminplaner zur Koordinierung und Kontrolle von Terminen der
Abteilungsangehrigen mit integrierter Terminabstimmung,
automatischem Versand von Einladungen und Aufgaben- und
Prioritten-Listen, Schnittstelle zum hausinternen Mailprogramm
- IT-Einsatzumgebung, diese wird einerseits beschrieben durch die
Rahmenbedingungen, die durch die vorhandene oder geplante IT-
Einsatzumgebung vorgegeben werden, und andererseits durch die
Leistungsanforderungen, die durch das Produkt an die Einsatzumgebung
vorgegeben werden.
Verkrzte Beispiele:
- Vorgegebene IT-Einsatzumgebung: Unter Novell 3.11 vernetzter
PC, 80486-Prozessor, 8 MB Hauptspeicher, 500 MB Festplatten-
kapazitt, Diskettenlaufwerk, CD-ROM-Laufwerk, MS-DOS 6.0,
Produkt darf maximal 50 MB der Festplatte belegen, es muss unter
Windows 3.11 laufen und netztauglich sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Leistungsanforderungen: Das Textverarbeitungsprogramm X ben-

tigt 16 MB Festplattenplatz, luft auf einem PC ab 80386-Prozessor,
8 MB Hauptspeicher, Windows 3.11.
- Kompatibilittsanforderungen zu anderen Programmen oder IT-Syste-
men, also Migrationsuntersttzung und Aufwrts- und Abwrtskompa-
tibilitt.
Verkrzte Beispiele:
- Datenbestnde aus der vorhandenen Datenbank XYZ mssen ber-
nommen werden knnen.
- Die Funktionen A, B, C mssen bei Versionswechseln erhalten blei-
ben.
- Der Datenaustausch mit dem Unix-System XYZ muss mglich sein.
- Performanceanforderungen beschreiben die erforderlichen Leistungen
hinsichtlich Durchsatz und Laufzeitverhalten. Fr die geforderten Funktio-
nen sollten mglichst genaue Angaben ber die maximal zulssige Bear-
beitungszeit getroffen werden.
Verkrzte Beispiele:
- Die maximale Antwortzeit bei Ausfhrung von Funktion X darf 2
Sekunden nicht berschreiten.
- Die Verschlsselungsrate sollte auf einem 486 DX 33 mindestens 60
KB/sec betragen.
- Andere gleichzeitig verarbeitete Prozesse drfen durch das Produkt
maximal um 30% verlangsamt werden.
- Interoperabilittsanforderungen, d. h. die Zusammenarbeit mit anderen
Produkten ber Plattformgrenzen hinweg muss mglich sein.
Verkrzte Beispiele:
- Versionen des Textverarbeitungsprogramms sollen fr Windows-,
Unix- und Macintosh-Plattformen verfgbar sein. Dokumente sollen
auf einem Betriebssystem erstellt und auf einem anderen weiterver-
arbeitet werden knnen.
- Das Textverarbeitungsprogramm muss mit dem eingesetzten Mail-
programm zusammenarbeiten knnen.
- Zuverlssigkeitsanforderungen betreffen die Stabilitt des Produktes,
also Fehlererkennung und Toleranz sowie Ausfall- und Betriebssicherheit.
Verkrzte Beispiele:
- Fehleingaben des Benutzers mssen erkannt werden und drfen
nicht zum Programmabbruch oder Systemabsturz fhren.
- Die Datenbank muss ber Mechanismen verfgen, die es erlauben,
bei einem Systemabbruch mit Zerstrung der Datenbank alle Trans-
aktionen zu rekonstruieren (Roll-Forward).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Konformitt zu Standards, dies knnen internationale Normen, De-facto-

Standards oder auch Hausstandards sein.
Verkrzte Beispiele:
- Das Produkt muss der EU-Bildschirmrichtlinie 90/270/EWG ent-
sprechen.
- Die Implementation eines Token-Ring-LANs muss konform sein zur
Norm ENV 41110.
- Das Produkt muss dem X/Open-Standard entsprechen.
- Einhaltung von internen Regelungen und gesetzlichen Vorschriften
(z. B. ausreichender Datenschutz bei der Verarbeitung personenbezogener
Daten)
Verkrzte Beispiele:
- Das Produkt muss den Grundstzen ordnungsmiger DV-gesttzter
Buchfhrungssysteme gengen.
- Da personenbezogene Daten verarbeitet werden, mssen die Bestim-
mungen des Bundesdatenschutzgesetzes mit den implementierten
Funktionen erfllt werden knnen.
- Anforderungen an die Benutzerfreundlichkeit, die durch die leichte
Bedienbarkeit, Verstndlichkeit und Erlernbarkeit gekennzeichnet ist, also
insbesondere durch die Gte der Benutzeroberflche sowie die Qualitt der
Benutzerdokumentation und der Hilfefunktionen.
Verkrzte Beispiele:
- Eine Online-Hilfefunktion muss implementiert sein.
- Die Benutzeroberflche muss so gestaltet sein, dass ungelernte
Krfte innerhalb von zwei Stunden in die Benutzung eingewiesen
werden knnen.
- Die Benutzerdokumentation und die Benutzeroberflche sollten in
der Landessprache vorliegen.
- Anforderungen an die Wartbarkeit ergeben sich fr den Anwender
hauptschlich aus der Fehlerbehandlung des Produktes.
Verkrzte Beispiele:
- Der Administrationsaufwand darf nicht zu hoch sein.
- Der Anbieter muss eine Hotline fr Fragen anbieten.
- Das Produkt muss einfach zu installieren und zu konfigurieren sein.
- Das Produkt muss einfach zu deinstallieren sein.
- die Obergrenze der Kosten, die durch die Beschaffung dieses Produktes
verursacht wrden, werden vorgegeben. Dabei mssen nicht nur die unmit-
telbaren Beschaffungskosten fr das Produkt selber einbezogen werden,
sondern auch Folgekosten, wie z. B. eine Aufrstung der Hardware, Perso-
nalkosten oder notwendige Schulungen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verkrzte Beispiele:
- Das Produkt darf maximal 15000.- kosten.
- Die Schulungskosten drfen 2000.- nicht berschreiten
- Aus den Anforderungen an die Dokumentation muss hervorgehen,
welche Dokumente in welcher Gte (Vollstndigkeit, Verstndlichkeit)
erforderlich sind.
Verkrzte Beispiele:
- Die Benutzerdokumentation muss leicht nachvollziehbar und zum
Selbststudium geeignet sein. Die gesamte Funktionalitt des Produk-
tes ist zu beschreiben.
- Die Systemverwalterdokumentation muss Handlungsanweisungen
fr mgliche Fehler enthalten.
- Bezglich der Softwarequalitt knnen Anforderungen gestellt werden,
die von Herstellererklrungen ber das eingesetzten Qualittssicherungs-
verfahren, ber ISO 9000 ff. Zertifikate bis hin zu unabhngigen Soft-
wareprfungen nach ISO 12119 reichen.
Verkrzte Beispiele:
- Der Software-Herstellungsprozess des Herstellers muss nach ISO
9000 zertifiziert sein.
- Die Funktionalitt des Produktes muss unabhngig gem ISO
12119 berprft worden sein.
- Sollen durch das Produkt IT-Sicherheitsfunktionen erfllt werden, sind sie
in Form von Sicherheitsanforderungen zu formulieren (vgl. M 4.42
Implementierung von Sicherheitsfunktionalitten in der IT-Anwendung).
Dies wird nachfolgend noch ausfhrlich erlutert.
Sicherheitsanforderungen
Abhngig davon, ob das Produkt Sicherheitseigenschaften bereitstellen muss,
knnen im Anforderungskatalog Sicherheitsfunktionen aufgefhrt werden.
Typische Sicherheitsfunktionen, die hier in Frage kommen, seien kurz erlu-
tert. Weitere Ausfhrungen findet man in den ITSEC.
- Identifizierung und Authentisierung
In vielen Produkten wird es Anforderungen geben, diejenigen Benutzer zu
bestimmen und zu berwachen, die Zugriff auf Betriebsmittel haben, die
vom Produkt kontrolliert werden. Dazu muss nicht nur die behauptete
Identitt des Benutzers festgestellt, sondern auch die Tatsache nachgeprft
werden, dass der Benutzer tatschlich die Person ist, die er zu sein vorgibt.
Dies geschieht, indem der Benutzer dem Produkt Informationen liefert, die
fest mit dem betreffenden Benutzer verknpft sind.
- Zugriffskontrolle
Bei vielen Produkten wird es erforderlich sein sicherzustellen, dass Be-
nutzer und Prozesse, die fr diese Benutzer ttig sind, daran gehindert
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden, Zugriff auf Informationen oder Betriebsmittel zu erhalten, fr die

sie kein Zugriffsrecht haben oder fr die keine Notwendigkeit zu einem
Zugriff besteht. Desgleichen wird es Anforderungen bezglich der unbe-
fugten Erzeugung oder nderung (einschlielich Lschung) von Infor-
mationen geben.
- Beweissicherung
Bei vielen Produkten wird es erforderlich sein sicherzustellen, dass ber
Handlungen, die von Benutzern bzw. von Prozessen im Namen solcher
Benutzer ausgefhrt werden, Informationen aufgezeichnet werden, damit
die Folgen solcher Handlungen spter dem betreffenden Benutzer zuge-
ordnet werden knnen und der Benutzer fr seine Handlungen verant-
wortlich gemacht werden kann.
- Protokollauswertung
Bei vielen Produkten wird sicherzustellen sein, dass sowohl ber gewhnli-
che Vorgnge als auch ber auergewhnliche Vorflle ausreichend Infor-
mationen aufgezeichnet werden, damit durch Nachprfungen spter festge-
stellt werden kann, ob tatschlich Sicherheitsverletzungen vorgelegen
haben und welche Informationen oder sonstigen Betriebsmittel davon
betroffen waren.
- Unverflschbarkeit
Bei vielen Produkten wird es erforderlich sein sicherzustellen, dass
bestimmte Beziehungen zwischen unterschiedlichen Daten korrekt bleiben
und dass Daten zwischen einzelnen Prozessen ohne nderungen ber-
tragen werden.
Daneben mssen auch Funktionen bereitgestellt werden, die es bei der
bertragung von Daten zwischen einzelnen Prozessen, Benutzern und
Objekten ermglichen, Verluste, Ergnzungen oder Vernderungen zu ent-
decken bzw. zu verhindern, und die es unmglich machen, die angebliche
oder tatschliche Herkunft bzw. Bestimmung der Datenbertragung zu
ndern.
- Zuverlssigkeit
Bei vielen Produkten wird es erforderlich sein sicherzustellen, dass zeit-
kritische Aufgaben genau zu dem Zeitpunkt durchgefhrt werden, zu dem
es erforderlich ist, also nicht frher oder spter, und es wird sicherzustellen
sein, dass zeitunkritische Aufgaben nicht in zeitkritische umgewandelt
werden knnen. Desgleichen wird es bei vielen Produkten erforderlich sein
sicherzustellen, dass ein Zugriff in dem erforderlichen Moment mglich ist
und Betriebsmittel nicht unntig angefordert oder zurckgehalten werden.
- bertragungssicherung
Dieser Begriff umfasst alle Funktionen, die fr den Schutz der Daten wh-
rend der bertragung ber Kommunikationskanle vorgesehen sind:
- Authentisierung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zugriffskontrolle
- Datenvertraulichkeit
- Datenintegritt
- Sende- und Empfangsnachweis
Einige dieser Funktionen werden mittels kryptographischer Verfahren
realisiert.
ber die ITSEC hinaus knnen weitere Sicherheitsanforderungen an Stan-
dardsoftware konkretisiert werden.
- Datensicherung
An die Verfgbarkeit der mit dem Produkt verarbeiteten Daten werden
hohe Anforderungen gestellt. Unter diesen Punkt fallen im Produkt inte-
grierte Funktionen, die Datenverlusten vorbeugen sollen wie die automa-
tische Speicherung von Zwischenergebnissen oder die automatische
Erstellung von Sicherungskopien vor der Durchfhrung grerer nde-
rungen.
- Verschlsselung
Verschlsselung dient der Wahrung der Vertraulichkeit von Daten. Bei vie-
len Produkten wird es erforderlich sein, Nutzdaten vor einer bertragung
oder nach der Bearbeitung zu verschlsseln und sie nach Empfang oder vor
der Weiterverarbeitung zu entschlsseln. Hierzu ist ein anerkanntes Ver-
schlsselungsverfahren zu verwenden. Es ist sicherzustellen, dass die zur
Entschlsselung bentigten Parameter (z. B. Schlssel) in der Weise
geschtzt sind, dass kein Unbefugter Zugang zu diesen Daten besitzt.
- Funktionen zur Wahrung der Datenintegritt
Fr Daten, deren Integrittsverlust zu Schden fhren kann, knnen Funk-
tionen eingesetzt werden, die Fehler erkennen lassen oder sogar mittels
Redundanz korrigieren knnen. Meist werden Verfahren zur Integrittspr-
fung eingesetzt, die absichtliche Manipulationen am Produkt bzw. den
damit erstellten Daten sowie ein unbefugtes Wiedereinspielen von Daten
zuverlssig aufdecken knnen. Sie basieren auf kryptographischen Ver-
fahren (siehe M 5.36 Verschlsselung unter Unix und Windows NT und
M 4.34 Einsatz von Verschlsselung, Checksummen oder Digitalen
Signaturen).
- Datenschutzrechtliche Anforderungen
Wenn mit dem Produkt personenbezogene Daten verarbeitet werden sollen,
sind ber die genannten Sicherheitsfunktionen hinaus zustzliche spezielle
technische Anforderungen zu stellen, um den Datenschutzbestimmungen
gengen zu knnen.
Strke der Mechanismen
Sicherheitsfunktionen werden durch Mechanismen umgesetzt. Je nach Ein-
satzzweck mssen diese Mechanismen eine unterschiedliche Strke besitzen,
mit der sie Angriffe abwehren knnen. Die erforderliche Strke der Mecha-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nismen ist im Anforderungskatalog anzugeben. Nach ITSEC unterscheidet

man drei verschiedene Mechanismenstrken:
- niedrig: bietet Schutz gegen zufllige unbeabsichtigte Angriffe, z. B.
Bedienungsfehler.
- mittel: bietet Schutz gegen Angreifer mit beschrnkten Gelegenheiten
oder Betriebsmitteln.
- hoch: kann nur von Angreifern berwunden werden, die ber sehr gute
Fachkenntnisse, Gelegenheiten und Betriebsmitteln verfgen, wobei ein
solcher erfolgreicher Angriff als normalerweise nicht durchfhrbar beur-
teilt wird.
Beispiele fr Anforderungen zu Sicherheitseigenschaften
Nachfolgend werden fr einige wichtige Sicherheitsfunktionen Beispiele
genannt, aus denen typische Anforderungen an Sicherheitseigenschaften deut-
lich werden.
Soll das Produkt ber einen Identifizierungs- und Authentisierungsmecha-
nismus verfgen, knnen beispielsweise folgende Anforderungen gestellt
werden:
- Der Zugang darf ausschlielich ber eine definierte Schnittstelle erfolgen.
Dabei kann z. B. ein Anmeldemechanismus zum Einsatz kommen, der eine
eindeutige Benutzer-Kennung und ein Passwort verlangt. Wird beim
Zugang zum IT-System bereits die Identitt des Benutzers sichergestellt, ist
eine anonyme Passworteingabe ausreichend. Andere Mglichkeiten sind
Verfahren, die auf dem Besitz bestimmter "Token" beruhen, wie z. B. einer
Chipkarte.
- Das Zugangsverfahren selbst muss die sicherheitskritischen Parameter, wie
Passwort, Benutzer-Kennung, usw., sicher verwalten. So drfen aktuelle
Passwrter nie unverschlsselt auf den entsprechenden IT-Systemen
gespeichert werden.
- Das Zugangsverfahren muss definiert auf Fehleingaben reagieren. Erfolgt
zum Beispiel dreimal hintereinander eine fehlerhafte Authentisierung, ist
der Zugang zum Produkt zu verwehren oder alternativ sind die zeitlichen
Abstnde, nach denen ein weiterer Zugangsversuch erlaubt wird, sukzessiv
zu vergrern.
- Das Zugangsverfahren muss das Setzen bestimmter Minimalvorgaben fr
die sicherheitskritischen Parameter zulassen. So sollte die Mindestlnge
eines Passwortes sechs Zeichen, die Mindestlnge einer PIN drei Ziffern
betragen. Ggf. ist auch die Syntax fr Passwrter vorzugeben.
Soll das Produkt ber eine Zugriffskontrolle verfgen, knnen beispielsweise
folgende Anforderungen gestellt werden:
- Das Produkt muss verschiedene Benutzer unterscheiden knnen.
- Das Produkt muss je nach Vorgabe Ressourcen einzelnen autorisierten
Benutzer zuteilen knnen und Unberechtigten den Zugriff gnzlich ver-
wehren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Mittels einer differenzierten Rechtestruktur (lesen, schreiben, ausfhren,

ndern, ...) sollte der Zugriff geregelt werden knnen. Die fr die Rechte-
verwaltung relevanten Daten sind manipulationssicher vom Produkt zu ver-
walten.
Soll das Produkt ber eine Protokollierung verfgen, knnen folgende Anfor-
derungen sinnvoll sein:
- Der Mindestumfang, den das Produkt protokollieren knnen muss, sollte
parametrisierbar sein. Beispielsweise sollten folgende Aktionen protokol-
lierbar sein:
- bei Authentisierung: Benutzer-Kennung, Datum und Uhrzeit, Erfolg,
...,
- bei der Zugriffskontrolle: Benutzer-Kennung, Datum und Uhrzeit,
Erfolg, Art des Zugriffs, was wurde wie gendert, gelesen, geschrie-
ben, ...,
- Durchfhrung von Administratorttigkeiten,
- Auftreten von funktionalen Fehlern.
- Die Protokollierung darf von Unberechtigten nicht deaktivierbar sein. Die
Protokolle selbst drfen fr Unberechtigte weder lesbar noch modifizierbar
sein.
- Die Protokollierung muss bersichtlich, vollstndig und korrekt sein.
Soll das Produkt ber eine Protokollauswertung verfgen, knnen folgende
Anforderungen sinnvoll sein:
- Eine Auswertefunktion muss nach den bei der Protokollierung geforderten
Datenarten unterscheiden knnen (z. B. "Filtern aller unberechtigten
Zugriffe auf alle Ressourcen in einem vorgegebenen Zeitraum").
Die Auswertefunktion muss auswertbare ("lesbare") Berichte erzeugen, so
dass keine sicherheitskritischen Aktivitten bersehen werden.
Soll das Produkt ber Funktionen zur Unverflschbarkeit verfgen, knnte
beispielsweise folgende Anforderung gestellt werden:
- Ein Datenbank-Managementsystem muss ber Mglichkeiten zur
Beschreibung von Regeln bestimmter Beziehungen zwischen den
gespeicherten Daten verfgen (z. B. referentielle Integritt). Auerdem
mssen geeignete Mechanismen existieren, die verhindern, dass es durch
nderungen der Daten zu Versten gegen diese Regeln kommt.
Soll das Produkt ber Funktionen zur Datensicherung verfgen, knnen bei-
spielsweise folgende Anforderungen gestellt werden:
- Es muss konfigurierbar sein, welche Daten wann gesichert werden.
- Es muss eine Option zum Einspielen beliebiger Datensicherungen existie-
ren.
- Die Funktion muss das Sichern von mehreren Generationen ermglichen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Datensicherungen von Zwischenergebnissen aus der laufenden Anwendung

sollen mglich sein.
Soll das Produkt ber eine Verschlsselungskomponente verfgen, sind
folgende Anforderungen sinnvoll:
- Der implementierte Verschlsselungsalgorithmus sollte - beim Einsatz in
Behrden - vom BSI anerkannt sein. Hier empfiehlt sich eine individuelle
Beratung durch das BSI. Auerhalb der Behrden ist bei mittlerem Schutz-
bedarf der DES geeignet.
- Das Schlsselmanagement muss mit der Funktionalitt des Produktes har-
monieren. Dabei sind insbesondere grundstzliche Unterschiede der Algo-
rithmen zu bercksichtigen:
- symmetrische Verfahren benutzen einen geheim zu haltenden
Schlssel fr die Ent- und Verschlsselung,
- asymmetrische Verfahren benutzen einen ffentlichen Schlssel fr
die Verschlsselung und einen privaten (geheim zu haltenden) fr
die Entschlsselung.
- Das Produkt muss die sicherheitskritischen Parameter wie Schlssel sicher
verwalten. So drfen Schlssel (auch mittlerweile nicht mehr benutzte) nie
ungeschtzt, das heit auslesbar, auf den entsprechenden IT-Systemen
abgelegt werden.
Soll das Produkt ber Mechanismen zur Integrittsprfung verfgen, sind
folgende Anforderungen sinnvoll:
- Das Produkt fhrt bei jedem Programmaufruf einen Integrittscheck durch.
- Bei der Datenbertragung mssen Mechanismen eingesetzt werden, mit
denen absichtliche Manipulationen an den Adressfeldern und den Nutz-
daten erkannt werden knnen. Daneben darf die bloe Kenntnis der einge-
setzten Algorithmen ohne spezielle Zusatzkenntnisse nicht ausreichen,
unerkannte Manipulationen an den obengenannten Daten vorzunehmen.
Werden personenbezogene Daten mit dem Produkt verarbeitet, knnen bei-
spielsweise folgende datenschutzrechtlichen Anforderungen gestellt
werden:
- Das Produkt darf keine freie Abfrage fr Datenauswertungen zulassen. Die
Auswertungen von Datenstzen mssen auf bestimmte Kriterien ein-
schrnkbar sein.
- Es muss parametrisierbar sein, dass fr bestimmte Dateien nderungen,
Lschungen oder Ausdrucke von personenbezogenen Daten nur nach dem
Vier-Augen-Prinzip mglich sind.
- Die Protokollierung muss parametrisierbar sein, so dass aufgezeichnet
werden kann, wer wann an welchen personenbezogenen Daten welche
nderungen vorgenommen hat.
- Die bermittlung personenbezogener Daten muss durch geeignete Stich-
probenverfahren festgestellt und berprft werden knnen (BDSG, 10).
Die Art der Stichprobe muss sich individuell einstellen lassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Das Produkt muss das Lschen von personenbezogenen Daten ermg-

lichen. Ersatzweise muss das Sperren personenbezogener Daten mglich
sein, um ihre weitere Verarbeitung oder Nutzung einzuschrnken bzw. zu
verhindern.
Bewertungsskala
Um einen Vergleich verschiedener Produkte im Sinne einer Nutzwertanalyse
durchfhren zu knnen, mssen Kriterien vorhanden sein, wie die Erfllung
der einzelnen Anforderungen gewertet wird. Dazu ist es erforderlich, vorab
die Bedeutung der einzelnen Anforderungen fr die angestrebte IT-gesttzte
Aufgabenerfllung quantitativ oder qualitativ zu bewerten.
Diese Bewertung kann beispielsweise in drei Stufen vorgenommen werden. In
der ersten Stufe wird festgelegt, welche im Anforderungskatalogs geforderten
Eigenschaften notwendig und welche wnschenswert sind. Wenn eine not-
wendige Eigenschaft nicht erfllt ist, wird das Produkt abgelehnt (so
genanntes K.O.-Kriterium). Das Fehlen einer wnschenswerten Eigenschaft
wird zwar negativ gewertet, dennoch wird aber das Produkt aufgrund dessen
nicht zwingend abgelehnt.
Als zweite Stufe wird die Bedeutung der geforderten wnschenswerte Eigen-
schaft fr die Aufgabenerfllung angegeben. Dies kann z. B. quantitativ mit
Werten zwischen 1 fr niedrig und 5 fr hoch erfolgen. Notwendige Eigen-
schaften mssen nicht quantitativ bewertet werden. Ist dies aber aus rechneri-
schen Grnden erforderlich, mssen sie auf jeden Fall hher bewertet werden
als jede wnschenswerte Eigenschaft (um die Bedeutung einer notwendigen
Eigenschaft hervorzuheben, kann sie z. B. mit 10 bewertet werden).
In der dritten Stufe wird ein Vertrauensanspruch fr die Korrektheit Aufga-
benerfllung der geforderten Eigenschaften angegeben (z. B. mit Werten zwi-
schen 1 fr niedrig und 5 fr hoch). Anhand des Vertrauensanspruchs wird
spter entschieden, wie eingehend die Eigenschaft getestet wird. Der Vertrau-
ensanspruch der Sicherheitsmechanismen muss entsprechend ihrer Mechanis-
menstrke bewertet werden, beispielsweise kombiniert man
- Mechanismenstrke niedrig mit Vertrauensanspruch 1
- Mechanismenstrke mittel mit Vertrauensanspruch 3
- Mechanismenstrke hoch mit Vertrauensanspruch 5
Diese Orientierungswerte mssen im Einzelfall verifiziert werden.
Beispiele:
Auszugsweise sollen fr einige typische Standardsoftwareprodukte Sicher-
heitsanforderungen erlutert werden:
Textverarbeitungsprogramm:
Notwendige Sicherheitseigenschaften:
- Automatische Datensicherung im laufenden Betrieb von Zwischen-
ergebnissen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wnschenswerte Sicherheitseigenschaften:
- Passwortschutz einzelner Dateien
- Verschlsselung einzelner Dateien
- Makro-Programmierung muss abschaltbar sein
Dateikompressionsprogramm:
- Im Sinne der Datensicherung drfen nach Kompression zu
lschende Dateien erst dann vom Kompressionsprogramm gelscht
werden, wenn die Kompression fehlerfrei abgeschlossen wurde.
- Vor der Dekomprimierung einer Datei muss deren Integritt ber-
prft werden, damit z. B. Bitfehler in der komprimierten Datei
erkannt werden.
- Passwortschutz komprimierter Dateien
Terminplaner:
- Eine sichere Identifikation und Authentisierung der einzelnen Benut-
zer muss erzwungen werden, z. B. ber Passwrter.
- Eine Zugriffskontrolle fr die Terminplne der einzelnen Mitarbeiter
ist erforderlich.
- Zugriffsrechte mssen fr Einzelne, Gruppen und Vorgesetzte
getrennt vergeben werden knnen.
- Eine Unterscheidung zwischen Lese- und Schreibrecht muss
mglich sein.
- Eine automatisierte Datensicherung in verschlsselter Form ist vor-
zusehen.
Reisekostenabrechnungssystem:
- Eine sichere Identifikation und Authentisierung der einzelnen Benut-
zer muss erzwungen werden, z. B. ber Passwrter.
- Eine Zugriffskontrolle muss vorhanden und auch fr einzelne Daten-
stze einsetzbar sein.
- Zugriffsrechte mssen fr Benutzer, Administrator, Revisor und
Datenschutzbeauftragter getrennt vergeben werden knnen. Eine
Rollentrennung zwischen Administrator und Revisor muss durch-
fhrbar sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Datensicherungen mssen so durchgefhrt werden knnen, dass sie

verschlsselt abgelegt werden und nur von Berechtigten wiederein-
gespielt werden knnen.
- Detaillierte Protokollierungsfunktionen mssen verfgbar sein.
- Ein optionaler Integrittscheck fr zahlungsrelevante Daten sollte
angeboten werden.
Beispiel fr eine Bewertungsskala:
Eine Fachabteilung will fr Datensicherungszwecke ein Komprimierungspro-
gramm beschaffen. Nach der Erstellung eines Anforderungskataloges knnten
die dort spezifizierten Eigenschaften wie folgt bewertet werden:
Eigenschaft notwen- wnschen Bedeu- Vertrau-

dig swert tung ensan-
spruch
korrekte Kompression und X 10 5

Dekompression
Erkennen von Bitfehlern in X 10 2
einer komprimierten Datei
Lschung von Dateien nur X 10 3
nach erfolgreicher Kom-
pression
DOS-PC, 80486, 8 MB X 10 5
Windows-tauglich X 2 1
Durchsatz bei 50 MHz ber 1 X 4 3
MB/s
Kompressionsrate ber 40% X 4 3
bei Textdateien des
Programms XYZ
Online-Hilfefunktion X 3 1
Maximale Kosten 50.- DM X 10 5
pro Lizenz
Passwortschutz fr X 2 5
komprimierte Dateien
(Mechanismenstrke hoch)
- Wer wird bei der Erstellung des Anforderungskatalogs beteiligt?
- Wer entscheidet, ob ein Produkt Sicherheitsfunktionen beinhalten muss?
- Gibt es einheitliche Vorgaben, wie eine Nutzwertanalyse aufgebaut sein
muss?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.81 Vorauswahl eines geeigneten

Standardsoftwareproduktes
Verantwortlich fr Initiierung: Beschaffungsstelle
Verantwortlich fr Umsetzung: Beschaffungsstelle, Leiter IT, Fachabteilung
Die Vorauswahl eines Standardsoftwareproduktes orientiert sich an dem durch
die Fachabteilung und den IT-Bereich aufgestellten Anforderungskatalog.
Zunchst sollte die fr die Vorauswahl zustndige Stelle eine Marktanalyse
durchfhren, bei der anhand des Anforderungskatalogs eine tabellarische
Marktbersicht erarbeitet werden sollte. In dieser Tabelle sollten fr die in
Frage kommenden Produkte Aussagen zu den im Anforderungskatalog
festgehaltenen Punkten gemacht werden.
Die Marktbersicht sollte vom IT-Bereich erarbeitet werden, sie kann anhand
von Produktbeschreibungen, Herstelleraussagen, Fachzeitschriften oder
Hndlerausknften erstellt werden. Alternativ ist eine Ausschreibung mglich
und teilweise vorgegeben. Der Anforderungskatalog ist Grundlage einer
Ausschreibung, so dass anhand der eingehenden Angebote eine vergleichbare
Marktbersicht erstellt werden kann.
Anschlieend mssen die in der Marktbersicht erfassten Produkte bzgl. der
Vorgaben des Anforderungskatalogs bewertet werden. Hierzu kann die in
M 2.80 Erstellung eines Anforderungskatalogs fr Standardsoftware
erarbeitete Bewertungsskala eingesetzt werden. Anhand der vorliegenden
Informationen wird festgestellt, welche der geforderten Eigenschaften des
Produktes vorhanden sind. Fehlen dem Produkt notwendige Eigenschaften,
wird es verworfen. ber die Bewertung der Bedeutung der einzelnen Eigen-
schaften jedes Produktes kann eine Summe ermittelt werden. Anhand dieser
Summen kann nun eine Hitliste fr die Produkte aus der Vorauswahl erstellt
werden.
Beispiel:
Die im Anforderungskatalog geforderten und bewerteten Eigenschaften fr ein
Komprimierungsprogramm werden nun wie folgt gewichtet:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Eigenschaft Notwen- Bedeu- Produkt Produkt Produkt Produkt

dig/ tung 1 2 3 4
Wnsch
enswert
korrekte Kompression N 10 j j j j
und Dekompression
Erkennen von N 10 j j K.O. j
Bitfehlern in einer
komprimierten Datei
Lschung von Dateien N 10 j j j j
nur nach erfolgreicher
Kompression
DOS-PC, 80486, 8 MB N 10 j j j j
Windows-tauglich W 2 n j j j
Durchsatz bei 50 MHz W 4 j j j n
ber 1 MB/s
Kompressionsrate ber W 4 j j n n
40% bei Textdateien
des Programms XYZ
Online-Hilfefunktion W 3 n n n j
Maximale Kosten 50.- N 10 j j j j
DM pro Lizenz
Passwortschutz fr W 2 j j n j
komprimierte Dateien
(Mechanismenstrke
hoch)
Bewertung 65 60 62 K.O. 57
(=Max.)
Als Ergebnis ergibt sich, dass Produkt 3 herausfllt, da eine notwendige

Eigenschaft nicht gegeben ist. Ansonsten wird die Hitliste angefhrt von Pro-
dukt 2, gefolgt von Produkt 1 und 4.
Die erstellte Hitliste zusammen mit der Marktbersicht sollte dann der
Beschaffungsstelle vorgelegt werden, damit dieser berprfen kann, inwieweit
die dort aufgefhrten Produkte den internen Regelungen und gesetzlichen
Vorgaben entsprechen. Dabei muss die Beschaffungsstelle auch darauf achten,
dass die anderen Stellen, deren Vorgaben eingehalten werden mssen, wie der
Datenschutzbeauftragte, der IT-Sicherheitsbeauftragte oder der Personal- bzw.
Betriebsrat, rechtzeitig beteiligt werden.
Es muss entschieden werden, wie viele und welche Kandidaten der Hitliste
getestet werden sollen. Sinnvollerweise sollten die ersten zwei oder drei
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Spitzenkandidaten ausgewhlt werden und daraufhin getestet werden, ob sie

die wichtigsten Kriterien des Anforderungskatalogs auch tatschlich erfllen.
Dies ist insbesondere fr die notwendigen Anforderungen wichtig. Hierfr
sollten Testlizenzen beschafft werden und, wie in M 2.82 Entwicklung eines
Testplans fr Standardsoftware und M 2.83 Testen von Standardsoftware
beschrieben, Tests durchgefhrt werden.
Neben den Kriterien des Anforderungskatalogs knnen fr die Entscheidung
noch die folgenden Punkte bercksichtigt werden:
- Referenzen
Kann der Hersteller oder Vertreiber fr sein Produkt Referenzinstallationen
angeben, so knnen die dort gemachten Erfahrungen hinterfragt und in die
Produktbeurteilung einbezogen werden.
Liegen externe Testergebnisse oder Qualittsaussagen fr das zu testende
Softwareprodukt vor (z. B. Testergebnisse in Fachzeitschriften, Konformi-
ttstests nach proprietren Standards, Prfungen und Zertifikate nach ein-
schlgigen Standards und Normen wie ISO 12119), so sollten auch diese
Ergebnisse bei der Vorauswahl bercksichtigt werden.
- Verbreitungsgrad des Produktes
Bei einem hohen Verbreitungsgrad hat der einzelne Anwender wenig oder
keinen Einfluss auf den Hersteller des Produkts, wenn es um die Behebung
von Fehlern oder die Implementation bestimmter Funktionalitten geht. Er
kann aber davon ausgehen, dass das Produkt weiterentwickelt wird. Oft
gibt es externe Tests, die durch den Hersteller beauftragt oder von Fach-
zeitschriften durchgefhrt wurden. Bei Produkten mit hohem Verbrei-
tungsgrad ist im allgemeinen mehr ber Schwachstellen bekannt, so dass
der Anwender davon ausgehen kann, dass die wesentlichen Schwachstellen
bereits bekannt sind, bzw. dass das Wissen ber Schwachstellen schnell
verbreitet wird und er nach dem Bekanntwerden Abhilfe schaffen kann.
Bei einem niedrigen Verbreitungsgrad kann ein Anwender mehr Einfluss
auf den Hersteller nehmen. Externe Tests liegen im allgemeinen nicht vor,
da sie fr Produkte kleiner Hersteller zu aufwendig und zu teuer sind.
Produkte mit niedrigem Verbreitungsgrad enthalten meist nicht mehr oder
weniger Schwachstellen als solche mit hohem Verbreitungsgrad. Nachteil
ist hier, dass diese evtl. nicht so schnell bekannt werden und damit behoben
werden knnen. Wenn es sich aber um Sicherheitslcken handelt, sind
diese aber wahrscheinlich auch potentiellen Angreifer nicht bekannt bzw.
keine lohnenden Angriffsziele.
- Wirtschaftlichkeit / Kosten fr Kauf, Betrieb, Wartung, Schulung
Vor der Entscheidung fr ein Produkt sollte immer die Frage stehen, ob die
Kosten fr das Produkt in einem angemessenen Verhltnis zu dem damit
erzielbaren Nutzen stehen. In die unmittelbaren Anschaffungskosten sind
darber hinaus alle Folgekosten fr Betrieb, Wartung und Schulung
einzubeziehen. Dazu muss z. B. geklrt werden, ob die vorhandene Hard-
ware-Plattform aufgerstet werden muss oder ob fr Installation und
Betrieb Schulungen erforderlich sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ist dann die Kaufentscheidung fr ein Produkt gefallen, sollte der Kauf natr-
lich beim gnstigsten Anbieter gettigt werden. Dieser hat sich evtl. schon bei
der Marktsichtung herauskristallisiert.
- Bietet die ausgewhlte Software alle im Anforderungskatalog zusammen-
gestellten Funktionen?
- Ist das Produkt kompatibel zu der aktuellen IT-Infrastruktur?
- Welche Folgekosten sind beispielsweise fr Schulung und Programm-
pflege zu erwarten?
- Sind Installation und Betrieb durch vorhandenes Personal mglich, wird
zustzlicher Personalaufwand erforderlich oder muss externe Fachkompe-
tenz verpflichtet werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.82 Entwicklung eines Testplans fr

Standardsoftware
Verantwortlich fr Umsetzung: Leiter Fachabteilung, Leiter IT
Die im nachfolgenden beschriebene Vorgehensweise beim Testen orientiert
sich an den Standardwerken DIN ISO/IEC 12119 "Software-Erzeugnisse,
Qualittsanforderungen und Prfbestimmungen", Vorgehensmodell fr die
Planung und Durchfhrung von IT-Vorhaben (V-Modell) und dem Handbuch
fr die Bewertung der Sicherheit von Systemen der Informationstechnik
(ITSEM), die als weiterfhrende Literatur empfohlen werden.
Vor der Entscheidung fr ein geeignetes Standardsoftwareprodukt mssen die
nach der Vorauswahl (siehe M 2.81 Vorauswahl eines geeigneten
Standardsoftwareproduktes) in die engere Wahl gezogenen Produkte als
Testlizenz beschafft und ausreichend getestet werden. War es aufgrund
zeitlicher Beschrnkungen, institutionsinterner Beschaffungsempfehlungen
(Einhaltung von Hausstandards) oder anderen Grnden nicht mglich, dass
Produkt vor der Beschaffung zu testen, mssen auf jeden Fall Tests vor der
endgltigen Inbetriebnahme durchgefhrt werden. Die Ergebnisse dieser Tests
liefern dann die Grundlage fr die Installationsvorschriften und anderer
Freigabe-Bedingungen.
Obwohl bereits bei der Vorauswahl eine berprfung der notwendigen Anfor-
derungen an das Produkt aufgrund der Herstelleraussagen stattgefunden hat,
kann man nicht davon ausgehen, dass diese Anforderungen auch im
gewnschten Mae erfllt werden. Vielmehr muss nun durch systematisches
Testen die Eignung und Zuverlssigkeit des Produktes auf Grundlage des
Anforderungskataloges berprft werden, um das geeignetste Produkt aus-
zuwhlen.
Dabei bietet es sich an, das Testen in vier Bereiche einzuteilen:
- Eingangsprfungen (Prfung auf Computer-Viren, Lauffhigkeit in der
gewnschten IT-Einsatzumgebung, ....),
- funktionale Tests (berprfung der funktionalen Anforderungen),
- Tests weiterer funktionaler Eigenschaften (berprfung von Kompatibili-
tt, Performance, Interoperabilitt, Konformitt mit Regelungen oder
Gesetzen, Benutzerfreundlichkeit, Wartbarkeit, Dokumentation), und
- sicherheitsspezifische Tests (berprfung der Sicherheitsanforderungen).
Das prinzipielle Vorgehen beim Testen von Standardsoftware zeigt die fol-
gende Abbildung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Anhand der bei der Vorauswahl erstellten Hitliste sind diejenigen Produkte
auszuwhlen, die getestet werden sollen. Anschlieend wird ein Testplan
entwickelt.
Dieser umfasst folgende Inhalte:
- Festlegung der Testinhalte anhand des Anforderungskataloges,
- berprfung von Referenzen,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Festlegung des Gesamtprfaufwandes,

- Zeitplanung einschlielich Prfaufwand je Testinhalt,
- Festlegung der Testverantwortlichen,
- Testumgebung,
- Inhalt der Testdokumentation,
- Festlegung von Entscheidungskriterien.
Die einzelnen genannten Punkte werden nachfolgend erlutert.
Festlegung der Testinhalte anhand des Anforderungskataloges

Aus dem Anforderungskatalog werden diejenigen Anforderungen ausgewhlt,
die berprft werden sollen. Dies sollten insbesondere diejenigen Eigenschaf-
ten sein, die eine groe Bedeutung oder einen hohen Vertrauensanspruch
besitzen.
berprfung von Referenzen
Bei der Vorauswahl (siehe M 2.81 Vorauswahl eines geeigneten
Standardsoftwareproduktes) wurden bereits erste Referenzen ber die zu
testenden Produkte eingeholt. Diese knnen ersatzweise herangezogen
werden, wenn man der jeweiligen externen Testgruppe ausreichendes
Vertrauen entgegenbringt.
Wurde fr das Produkt ein Zertifikat nach den Kriterien fr die Bewertung der
Sicherheit von Systemen der Informationstechnik (ITSEC) oder den Common
Criteria (CC) vergeben, ist anhand des Zertifizierungsreportes zu prfen,
inwieweit die dort dokumentierten Testergebnisse bercksichtigt werden
knnen.
Gegebenenfalls knnen dann eigene Test unterbleiben oder in geringerem
Umfang stattfinden. Die frei werdenden Kapazitten knnen auf andere
Testinhalte verteilt werden.
Festlegung des Gesamtprfaufwandes
Um den Aufwand fr die Tests nicht ausufern zu lassen, sollte vorab der
Gesamtprfaufwand festgelegt werden, z. B. in Personentagen oder durch
Fristsetzung.
Zeitplanung einschlielich Prfaufwand je Testinhalt
Beim Testen mehrerer Produkte empfiehlt es sich, diese vergleichend zu
testen. Das heit, alle Produkte werden von einer Testgruppe bzgl. einer
Anforderung des Anforderungskataloges getestet. Der Prfaufwand ist damit
fr jede Anforderung des Anforderungskataloges festzulegen und wird damit
automatisch gleichmig auf alle zu testenden Produkte verteilt. Der Prf-
aufwand ergibt sich dabei aus Prftiefe und Komplexitt der Eigenschaft. Die
Prftiefe der jeweiligen Eigenschaften sollte sich zum einen an ihrem Ver-
trauensanspruch, das heit an dem Vertrauen orientieren, das der Korrektheit
dieser Eigenschaft entgegengebracht werden muss. Zum anderen muss aber
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
auch die Fehleranflligkeit und Nutzungshufigkeit der jeweiligen Eigenschaft

bercksichtigt werden. Ausfhrlichere Informationen sind der Norm
ISO 12119 zu entnehmen.
Hinweise:
- Fr sicherheitsspezifische Anforderungen kann die Prftiefe entsprechend
der geforderten Mechanismenstrke zustzlich relativiert werden.
- Der Prfaufwand fr die Eingangsprfungen sollte gemessen an den
anderen Tests gering sein.
Abschlieend ist der Gesamtprfaufwand entsprechend dem relativen Prfauf-
wand der jeweiligen Eigenschaft auf die einzelnen Testabschnitte zu verteilen.
Festlegung der Testverantwortlichen
Fr jeden Testinhalt ist nun festzulegen, welche Aufgaben durchzufhren sind
und wer dafr verantwortlich ist. Insbesondere ist zu beachten, dass bei eini-
gen Testinhalten der Personal- bzw. Betriebsrat, der Datenschutzbeauftragte
und der IT-Sicherheitsbeauftragte zu beteiligen ist.
Testumgebung
Testen ist immer destruktiv, da vorstzlich nach Fehlern gesucht wird. Aus
diesem Grund muss das Testen immer in einer isolierten Testumgebung erfol-
gen.
Die Testumgebung sollte nach Mglichkeit ein genaues funktionales Abbild
der Produktionsumgebung sein. In der Regel ist es jedoch nicht wirtschaftlich,
die Produktionsumgebung in vollem Umfang nachzubilden.
Damit fr die ausgewhlten Produkte gleiche Randbedingungen gegeben sind,
sollte eine Referenztestumgebung definiert werden. Fr einzelne Tests kann
diese weiter angepasst oder eingeschrnkt werden.
Die fr die einzelnen Prfungen bentigten Ressourcen (Betriebsmittel, IT-
Infrastruktur) sind zu spezifizieren. Es sollte im Detail beschrieben werden,
wann und in welchem Umfang sie verfgbar sein mssen.
Wichtig ist, dass alle Betriebssysteme in allen im Produktionsbetrieb einge-
setzten Versionen (Releases) in der Testumgebung zur Verfgung stehen. Die
Intention ist dabei die Ermittlung von systembedingten Schwachstellen von
Komponenten der Produktionsumgebung im Zusammenspiel mit dem zu
installierenden Standardsoftwareprodukt. In Ausnahmefllen, wenn sich
Aspekte verallgemeinern lassen, kann auf einzelne Komponenten verzichtet
werden.
Folgende weitere Aspekte sind unbedingt zu beachten und helfen, eine sichere
und geeignete Testumgebung aufzubauen:
- Die Computer-Virenfreiheit der Testumgebung ist durch ein aktuelles
Virensuchprogramm sicherzustellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Testumgebung muss frei sein von Seiteneffekten auf den Echtbetrieb.
Um Wechselwirkungen von vornherein zu vermeiden, empfiehlt es sich,
dedizierte IT-Systeme zu installieren.
- Die Zugriffsrechte mssen in der Testumgebung derart konfiguriert
werden, wie sie dem Produktionsbetrieb entsprechen.
- Der Zutritt und Zugang zur Testumgebung muss geregelt sein.
- Es muss sichergestellt werden, dass das Produkt genau in der Test-
umgebung ermittelten Konfiguration in den Produktionsbetrieb ber-
nommen wird. Daher ist in der Testumgebung ein geeignetes Verfahren
zum Integrittsschutz einzusetzen (digitale Signaturen, Checksummen).
- Die Kosten fr den Aufbau der Testumgebung mssen angemessen sein.
Nach Beendigung aller geplanten Tests ist zu entscheiden, ob die Testumge-
bung abgebaut werden soll. Ggf. sind weitere Tests auch nach der Beschaf-
fung eines Produktes notwendig, so dass es eventuell wirtschaftlich ist, die
Testumgebung vorzuhalten. Vor dem Abbau der Testumgebung sind die
Testdaten zu lschen, falls sie nicht mehr bentigt werden (z. B. fr eine
sptere Installation). Druckerzeugnisse sind ordnungsgem zu entsorgen,
Programme sind zu deinstallieren. Die Testlizenzen der nicht ausgewhlten
Produkte sind zurckzugeben.
Inhalt der Testdokumentation
Im Testplan ist vorzugeben, wie ausfhrlich die Testdokumentation zu erstel-
len ist. Hierbei sind die Aspekte der Nachvollziehbarkeit, Reproduzierbarkeit
und Vollstndigkeit zu bercksichtigen.
Die Testdokumentation muss Testplne, -ziele, -verfahren und -ergebnisse
enthalten und die bereinstimmung zwischen den Tests und den spezifizierten
Anforderungen beschreiben. Smtliche Testaktivitten sowie die getroffene
Testbewertung (inklusive Entscheidungsargumentation) sind schriftlich fest-
zuhalten. Dazu gehren im einzelnen
- Produktbezeichnung und Beschreibung,
- Testbeginn, -ende und -aufwand,
- Testverantwortliche,
- Konfiguration der Testumgebung,
- Beschreibung der Testflle,
- Entscheidungskriterien, Testergebnisse und Argumentationsketten, und
- nicht erfllte Anforderungen des Anforderungskataloges.
Der Testgruppe sollte eine Mglichkeit zur bersichtlichen Dokumentation
und Protokollierung der Testaktivitten und -ergebnisse zur Verfgung gestellt
werden (z. B. Protokollierungstool, Formbltter o. .).
Wird beim Testen ein automatisiertes Werkzeug verwendet, muss die Test-
dokumentation ausreichende Informationen ber dieses Werkzeug und die Art
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
seines Einsatzes enthalten, damit die Entscheidung nachvollzogen werden

kann.
Festlegung von Entscheidungskriterien
Bei der Bewertung der jeweiligen Testinhalte kann beispielsweise folgende
dreistufige Skala verwendet werden:
Note Entscheidungskriterien
0 - Anforderungen sind nicht erfllt.
oder
- Es wurden nicht tolerierbare Fehler festgestellt, die sich
nicht beheben lassen.
1 - Anforderungen sind erfllt, aber es bestehen Vorbehalte
(z. B. Funktion ist nur eingeschrnkt geeignet).
oder
- Es sind geringfgige Fehler festgestellt worden. Diese
spielen nur eine untergeordnete Rolle, da sie tolerierbare
Auswirkungen auf den Produktionsbetrieb haben oder da
sie nur mit vernachlssigbarer Wahrscheinlichkeit
vorkommen knnen.
2 - Anforderungen sind in vollem Umfang erfllt.
oder
- Fehler, die ggf. aufgetaucht sind, sind entweder zu
beheben oder haben fr den Betrieb keinerlei Bedeutung.
Sind Fehler aufgetaucht, die nicht reproduziert werden knnen, hat der Prfer
zu entscheiden, welcher Kategorie (Note) der Fehler zuzuordnen ist.
Sind Fehler aufgetreten, die whrend des Tests behoben werden knnen, ist
nach deren Behebung erneut im erforderlichen Umfang zu testen.
Beispiel:
Das Beispiel des Kompressionsprogramms aus M 2.81 Vorauswahl eines
geeigneten Standardsoftwareproduktes wird hier fortgesetzt, um eine Mg-
lichkeit zu beschreiben, den Prfaufwand fr jede Anforderung des Anforde-
rungskataloges festzulegen. Hier wird der Prfaufwand aus Prftiefe und
Komplexitt abgeleitet. Der Vertrauensanspruch kennzeichnet den Bedarf an
Vertrauen in die Eigenschaft.
Die Nutzungshufigkeit, Fehleranflligkeit und Komplexitt einer Eigenschaft
werden wie folgt bewertet:
- 1 bedeutet "niedrig",
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- 2 bedeutet "mittel",
- 3 bedeutet "hoch".
Ein besonderer Fall ist gegeben, wenn eine unvernderbare Eigenschaft des
Produktes betrachtet werden soll, die unabhngig von der Fehleranflligkeit
oder Nutzungshufigkeit ist. Fr diesen Fall wird der Wert 0 vergeben. Fr
das Beispiel des Kompressionsprogramms ergibt sich folgende Tabelle:
in %
Prfaufwand
Komplexitt
Prftiefe
Nutzungshufigkeit
Fehleranflligkeit
Vertrauensanspruch
korrekte Kompression 5 2 3 10 2 20 23
und Dekompression
Erkennen von Bitfehlern 2 2 1 5 2 10 11
in einer komprimierten
Datei
Lschung von Dateien 3 2 1 6 1 6 7
nur nach erfolgreicher
Kompression
DOS-PC, 80486, 8 MB 5 0 0 5 1 5 6
Windows-tauglich 1 0 0 1 1 1 1
Durchsatz bei 50 MHz 3 1 2 6 1 6 7
ber 1 MB/s
Kompressionsrate ber 3 2 2 7 1 7 8
40% fr Textdateien des
Programms XYZ
Online-Hilfefunktion 1 1 2 4 1 4 5
Maximale Kosten 50.- 5 0 0 5 1 5 5
DM pro Lizenz
Passwortschutz fr kom- 5 1 2 8 3 24 27
primierte Dateien (Me-
chanismenstrke hoch)
In diesem Beispiel wurde der Prfaufwand folgendermaen definiert:

Prfaufwand = Komplexitt * Prftiefe,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
dabei ist
Prftiefe = Vertrauensanspruch + Fehleranflligkeit + Nutzungshufigkeit
(Die Prozentzahlen fr den Prfaufwand in der letzten Spalte der Tabelle erge-
ben sich aus den fr den Prfaufwand errechneten Werten bei Division durch
die Summe dieser Werte.)
Ein Beispiel fr eine andere Methode, den Prfaufwand zu berechnen und die
Prfergebnisse zu bewerten, findet sich in der Norm ISO 12119. Hier wird
folgende Gewichtung der einzelnen Anforderungen vorgenommen: Bewertung
jedes Prfinhaltes =(Komplexitt+Fehleranflligkeit) * (Benutzungshufigkeit
+ Wichtigkeit).
Letztendlich muss der Testverantwortliche eine dem Produkt und der Institu-
tion adquate Bewertungsmethode individuell festlegen.
Nach Erstellung des Testplans wird fr jeden im Testplan spezifizierten
Testinhalt ein Tester oder eine Testgruppe mit der Durchfhrung des ihr
zugeteilten Tests beauftragt. Der Testplan ist der Testgruppe zu bergeben und
die fr die Einzeltests vorgegebenen Zeiten sind mitzuteilen.
- Sind alle fr die Testdurchfhrung bentigten Formbltter und Checklisten
erstellt?
- Wurden alle Aufgaben fr das Testen zugeteilt?
- Wurden alle Prfinhalte entsprechend den Vorgaben in Testflle umge-
setzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.83 Testen von Standardsoftware

Verantwortlich fr Initiierung: Leiter Fachabteilung, Leiter IT
Verantwortlich fr Umsetzung: Testgruppe
Das Testen von Standardsoftware lsst sich in die Abschnitte Vorbereitung,
Durchfhrung und Auswertung unterteilen. In diesen Abschnitten sind fol-
gende Aufgaben wahrzunehmen:
Testvorbereitung
- Festlegung der Testmethoden fr die Einzeltests (Testarten, -verfahren und
-werkzeuge)
- Generierung von Testdaten und Testfllen
- Aufbau der bentigten Testumgebung
Testdurchfhrung
- Eingangsprfungen
- Funktionale Tests
- Tests weiterer funktionaler Eigenschaften
- Sicherheitsspezifische Tests
- Pilotanwendung
Testauswertung
Die einzelnen Aufgaben werden nachfolgend beschrieben.
Testvorbereitung
Festlegung der Testmethoden fr die Einzeltests (Testarten, -verfahren
und -werkzeuge)
Methoden zur Durchfhrung von Tests sind z. B. statistische Analyse, Simu-
lation, Korrektheitsbeweis, symbolische Programmausfhrung, Review,
Inspektion, Versagensanalyse. Hierbei muss beachtet werden, dass einige
dieser Testmethoden nur bei Vorliegen des Quellcodes durchfhrbar sind. In
der Vorbereitungsphase muss die geeignete Testmethode ausgewhlt und fest-
gelegt werden.
Es muss geklrt werden, welche Verfahren und Werkzeuge zum Testen von
Programmen und zum Prfen von Dokumenten eingesetzt werden. Typische
Verfahren zum Testen von Programmen sind z. B. Black-Box-Tests, White-
Box-Tests oder Penetrationstests. Dokumente knnen z. B. durch informelle
Prfungen, Reviews oder anhand von Checklisten kontrolliert werden.
Ein Black-Box-Test ist ein Funktionalittstest ohne Kenntnis der internen
Programmablufe, bei dem z. B. das Programm mit allen Datenarten fr alle
Testflle mit Fehlerbehandlung und Plausibilittskontrollen durchlaufen wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei einem White-Box-Test handelt es sich um einen Funktionalittstests unter

Offenlegung der internen Programmablufe, z. B. durch Quellcode-ber-
prfung oder Tracing. White-Box-Tests gehen in der Regel ber den IT-
Grundschutz hinaus und knnen fr Standardsoftware in der Regel nicht
durchgefhrt werden, da der Quellcode vom Hersteller nicht offengelegt wird.
Bei Funktionalittstests soll der Nachweis erbracht werden soll, dass der Test-
inhalt der Spezifikation entspricht. Durch Penetrationstests soll festgestellt
werden, ob bekannte oder vermutete Schwachstellen im praktischen Betrieb
ausgenutzt werden knnen, beispielsweise durch Manipulationsversuche an
den Sicherheitsmechanismen oder durch Umgehung von Sicherheits-
mechanismen durch Manipulationen auf Betriebssystemebene.
Weiterhin ist die Art und Weise der Ergebnissicherung und -auswertung fest-
zuschreiben, insbesondere im Hinblick auf die Wiederholbarkeit von Prfun-
gen. Es muss geklrt werden, welche Daten whrend und nach der Prfung
festzuhalten sind.
Generierung von Testdaten und Testfllen

Die Vorbereitung von Tests umfasst auch die Generierung von Testdaten.
Methode und Vorgehensweise sind zuvor festzulegen und zu beschrieben.
Fr jeden einzelnen Testinhalt muss eine dem Testaufwand angemessene
Anzahl von Testfllen generiert werden. Jede der folgenden Kategorien ist
dabei zu bercksichtigen:
Standardflle sind Flle, mit denen die korrekte Verarbeitung der definierten
Funktionalitten berprft werden soll. Die eingehenden Daten nennt man
Normalwerte oder Grenzwerte. Normalwerte sind Daten innerhalb, Grenz-
werte sind Eckdaten des jeweils gltigen Eingabebereichs.
Fehlerflle sind Flle, in denen versucht wird, mgliche Fehlermeldungen des
Programms zu provozieren. Diejenigen Eingabewerte, auf die das Programm
mit vorgegebenen Fehlermeldungen reagieren soll, nennt man Falschwerte.
Ausnahmeflle sind Flle, bei denen das Programm ausnahmsweise anders
reagieren muss als bei Standardfllen. Es muss daher berprft werden, ob das
Programm diese Flle als solche erkennt und korrekt bearbeitet.
Beispiele:
- Wenn die Eingabeparameter zwischen 1 und 365 liegen drfen, sind Test-
lufe mit Falschwerten (z. B. 0 oder 1000), den Grenzwerten 1 und 365,
sowie mit Normalwerten zwischen 1 und 365 durchfhren.
- Ein Programm zur Terminplanung soll Feiertage bercksichtigen. Ein
Sonderfall ist dann gegeben, wenn ein bestimmter Tag Feiertag in allen
Bundeslndern ist, auer in einem. Fr dieses Bundesland und fr diesen
Tag muss das Programm dann differenziert reagieren.
Ist die Generierung von Testdaten zu aufwendig oder schwierig, knnen auch
anonymisierte Echtdaten fr den Test eingesetzt werden. Aus Grnden des
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vertraulichkeitsschutzes mssen Echtdaten unbedingt zuverlssig anony-

misiert werden. Zu beachten bleibt, dass die anonymisierten Echtdaten u. U.
nicht alle Grenzwerte und Ausnahmeflle abdecken, so dass diese gesondert
erzeugt werden mssen.
ber die Testdaten hinaus sollten auch alle Arten mglicher Benutzerfehler
betrachtet werden. Problematisch sind insbesondere alle Benutzerreaktionen,
die im Programmablauf nicht vorgesehen und dementsprechend nicht korrekt
abgewiesen werden.
Aufbau der bentigten Testumgebung

Die im Testplan beschriebene Testumgebung muss aufgebaut und die zu
testenden Produkte dort installiert werden. Die eingesetzten Komponenten
sind zu identifizieren und deren Konfiguration ist zu beschreiben. Treten bei
der Installation des Produktes Abweichungen von der beschriebenen Konfigu-
ration auf, so ist dies zu dokumentieren.
Testdurchfhrung
Die Durchfhrung der Tests muss anhand des Testplans erfolgen. Jede Aktion
sowie die Testergebnisse mssen ausreichend dokumentiert und bewertet
werden. Insbesondere wenn Fehler auftreten, sind diese derart zu dokumen-
tieren, dass sie reproduziert werden knnen. Die fr den spteren Produktions-
betrieb geeigneten Betriebsparameter mssen ermittelt und fr die sptere
Erstellung einer Installationsanweisung festgehalten werden.
Werden zustzliche Funktionen beim Produkt erkannt, die nicht im Anforde-
rungskatalog aufgefhrt, aber trotzdem von Nutzen sein knnen, so ist hierfr
mindestens ein Kurztest durchzufhren. Zeigt sich, dass diese Funktion von
besonderer Bedeutung fr den spteren Betrieb sind, sind diese ausfhrlich zu
testen. Fr den zustzlich anfallenden Prfaufwand ist ggf. eine Fristverlnge-
rungen bei den Verantwortlichen zu beantragen. Die Testergebnisse sind in die
Gesamtbewertung mit einzubeziehen.
Zeigt sich bei Bearbeitung einzelner Testinhalte, dass eine oder mehrere
Anforderungen des Anforderungskataloges nicht konkret genug waren, sind
diese gegebenenfalls zu konkretisieren.
Beispiel: Im Anforderungskatalog wird zum Vertraulichkeitsschutz der zu
bearbeitenden Daten Verschlsselung gefordert. Whrend des Testens hat sich
gezeigt, dass eine Offline-Verschlsselung fr den Einsatzzweck ungeeignet.
Daher ist der Anforderungskatalog hinsichtlich einer Online-Verschlsselung
zu ergnzen. (Eine Offline-Verschlsselung muss vom Anwender angestoen
und die zu verschlsselnden Elemente jeweils spezifiziert werden; eine
Online-Verschlsselung erfolgt transparent fr den Anwender mit
voreingestellten Parametern.)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Eingangsprfungen
Vor allen anderen Tests sind zunchst die folgenden grundlegenden Aspekte
zu testen, da ein Misserfolg bei diesen Eingangsprfungen zu direkten
Aktionen oder dem Testabbruch fhrt:
- Die Computer-Virenfreiheit des Produktes ist durch ein aktuelles Viren-
suchprogramm zu berprfen.
- In einem Installationstest muss festgestellt werden, ob das Produkt fr den
spteren Einsatzzweck einfach, vollstndig und nachvollziehbar zu instal-
lieren ist. Ebenfalls muss berprft werden, wie das Produkt vollstndig
deinstalliert wird.
- Die Lauffhigkeit des Produktes ist in der geplanten Einsatzumgebung zu
berprfen; dies beinhaltet insbesondere eine berprfung der Bild-
schirmaufbereitung, der Druckerausgabe, der Mausuntersttzung, der
Netzfhigkeit, etc.
- Die Vollstndigkeit des Produktes (Programme und Handbcher) ist zu
berprfen, z. B. durch einen Vergleich mit dem Bestandsverzeichnis, der
Produktbeschreibung oder hnlichem.
- Es sollten Kurztests von Funktionen des Programms durchgefhrt werden,
die nicht explizit in den Anforderungen erwhnt wurden, im Hinblick auf
Funktion, Plausibilitt, Fehlerfreiheit, etc.
Funktionale Tests
Die funktionalen Anforderungen, die im Anforderungskatalog an das Produkt
gestellt wurden, sind auf folgende Aspekte zu untersuchen:
- Existenz der Funktion durch Aufruf im Programm und Auswertung der
Programmdokumentationen.
- Fehlerfreiheit bzw. Korrektheit der Funktion
Um die Fehlerfreiheit bzw. Korrektheit der Funktion sicherzustellen, sind
je nach Prftiefe bei der Untersuchung unterschiedliche Testverfahren wie
Black-Box-Tests, White-Box-Tests oder simulierter Produktionsbetrieb
anzuwenden.
Die in der Vorbereitungsphase erstellten Testdaten und Testflle werden
im Funktionalittstest eingesetzt. Bei den Funktionalittstests ist es not-
wendig, die Testergebnisse mit den vorgegebenen Anforderungen zu ver-
gleichen. Auerdem ist zu berprfen, wie das Programm bei fehlerhaften
Eingabeparametern oder fehlerhafter Bedienung reagiert. Die Funktion ist
auch mit den Grenzwerten der Intervalle von Eingabeparametern sowie mit
Ausnahmefllen zu testen. Diese mssen entsprechend erkannt und korrekt
behandelt werden.
- Eignung der Funktion
Die Eignung einer Funktion zeichnet sich dadurch aus, dass die Funktion
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- tatschlich die Aufgabe im geforderten Umfang und effizient erfllt

und
- sich leicht in die blichen Arbeitsablufe integrieren lsst.
Ist die Eignung der Funktion nicht offensichtlich, bietet es sich an, dies in
einem simulierten Produktionsbetrieb, aber immer noch in der Testum-
gebung zu testen.
- Widerspruchsfreiheit
Die Widerspruchsfreiheit der einzelnen Funktionen ist zu berprfen und
zwar jeweils zwischen Anforderungskatalog, Dokumentation und Pro-
gramm. Eventuelle Widersprche sind zu dokumentieren. Abweichungen
zwischen Dokumentation und Programm sind so festzuhalten, dass sie bei
einem spteren Einsatz des Produktes in den Ergnzungen zur Doku-
mentation aufgenommen werden knnen.
Tests weiterer funktionaler Eigenschaften

Die im Anforderungskatalog neben den funktionalen und den sicherheits-
spezifischen Anforderungen spezifizierten weiteren funktionalen Eigenschaf-
ten sind ebenfalls zu berprfen:
- Performance
Das Laufzeitverhalten sollte fr alle geplanten Konfigurationen des
Produktes ermittelt werden. Um die Performance ausreichend zu testen,
sind in der Regel Tests, in denen der Produktionsbetrieb simuliert wird
oder auch Pilotanwendung bei ausgewhlten Anwendern sinnvoll. Es muss
festgestellt werden, ob die gestellten Performanceanforderungen erfllt
sind.
- Zuverlssigkeit
Das Verhalten bei zuflligen oder mutwillig herbeigefhrten System-
abstrzen ("Crash-Test") ist zu analysieren und es ist festzustellen, welche
Schden dabei entstehen. Es ist festzuhalten, ob nach Systemabstrzen ein
ordnungsgemer und korrekter Wiederanlauf des Produktes mglich ist.
Es ist ebenfalls zu berprfen, ob ein direkter Zugriff auf Datenbestnde
unabhngig von der regulren Programmfunktion erfolgen kann. In vielen
Fllen kann ein solcher Zugriff zu Datenverlusten fhren und sollte dann
vom Produkt verhindert werden. Ebenfalls sollte festgehalten werden, ob
das Programm Mglichkeiten untersttzt, "kritische Aktionen" (z. B.
Lschen, Formatieren) rckgngig zu machen.
- Benutzerfreundlichkeit
Ob das Produkt benutzerfreundlich ist, ist in besonderem Mae vom
subjektiven Empfinden der Testperson abhngig. Jedoch knnen bei der
Beurteilung folgende Aspekte Anhaltspunkte liefern:
- Technik der Menoberflchen (Pull-Down-Mens, Scrolling, Drag
& Drop, etc.),
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Design der Menoberflchen (z. B. Einheitlichkeit, Verstndlichkeit,

Menfhrung),
- Tastaturbelegung,
- Fehlermeldungen,
- problemloses Ansprechen von Schnittstellen (Batchbetrieb, Kom-
munikation, etc.),
- Lesbarkeit der Benutzerdokumentation,
- Hilfefunktionen.
Die Analyse der Benutzerfreundlichkeit muss mgliche Betriebsarten des
Produktes beschreiben, einschlielich des Betriebes nach Bedien- oder
Betriebsfehlern, und ihre Konsequenzen und Folgerungen fr die Auf-
rechterhaltung eines sicheren Betriebes.
- Wartbarkeit
Der personelle und finanzielle Aufwand fr die Wartung und Pflege des
Produktes sollte whrend des Testens ermittelt werden. Dieser kann z. B.
anhand von Referenzen wie anderen Referenzinstallationen oder Tests in
Fachzeitschriften oder anhand des whrend des Testens ermittelten Instal-
lationsaufwandes geschtzt werden. Hierfr muss dokumentiert werden,
wie viele manuelle Eingriffe whrend der Installation notwendig waren,
um die angestrebte Konfiguration zu erreichen. Sind bereits Erfahrungen
mit Vorgngerversionen des getesteten Produktes gesammelt worden,
sollte hinterfragt werden, wie aufwendig deren Wartung war.
Es sollte nachgefragt werden, inwieweit Support durch den Hersteller oder
Vertreiber angeboten wird und zu welchen Konditionen. Wird vom Her-
steller oder Vertreiber eine Hotline angeboten, sollte auch deren Erreich-
barkeit und Gte betrachtet werden.
- Dokumentation
Die vorliegende Dokumentation muss daraufhin berprft werden, ob sie
vollstndig, korrekt und widerspruchsfrei ist. Darber hinaus sollte sie
verstndlich, eindeutig, fehlerfrei und bersichtlich sein.
Es muss weiterhin kontrolliert werden, ob sie fr eine sichere Verwendung
und Konfiguration ausreicht. Alle sicherheitsspezifischen Funktionen
mssen beschrieben sein.
Darber hinaus sind als weitere Punkte des Anforderungskatalogs zu testen:
- Kompatibilittsanforderungen
- Interoperabilitt
- Konformitt zu Standards
- Einhaltung von internen Regelungen und gesetzlichen Vorschriften
- Softwarequalitt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sicherheitsspezifische Tests
Wurden sicherheitsspezifische Anforderungen an das Produkt gestellt, so sind
zustzlich zu den vorgenannten Untersuchungen auch folgende Aspekte zu
untersuchen:
- Wirksamkeit und Korrektheit der Sicherheitsfunktionen,
- Strke der Sicherheitsmechanismen und
- Unumgnglichkeit und Zwangslufigkeit der Sicherheitsmechanismen.
Als Grundlage fr eine Sicherheitsuntersuchung knnte beispielsweise das
Handbuch fr die Bewertung der Sicherheit von Systemen der Informations-
technik (ITSEM) herangezogen werden, in dem viele der nachfolgend aufge-
zeigten Vorgehensweise beschrieben sind. Die weiteren Ausfhrungen dienen
zur Orientierung und zur Einfhrung in die Thematik.
Zu Beginn muss durch funktionale Tests zunchst nachgewiesen werden, dass
das Produkt die erforderlichen Sicherheitsfunktionen bereitstellt.
Anschlieend ist zu berprfen, ob alle erforderlichen Sicherheitsmechanis-
men im Anforderungskatalog genannt wurden, ggf. ist dieser zu ergnzen. Um
die Mindeststrke der Mechanismen zu besttigen oder zu verwerfen sind
Penetrationstests durchzufhren. Penetrationstests sind nach allen anderen
Tests durchzufhren, da sich aus diesen Tests Hinweise auf potentielle
Schwachstellen ergeben knnen.
Durch Penetrationstests kann das Testobjekt oder die Testumgebung besch-
digt oder beeintrchtigt werden. Damit solche Schden keine Auswirkungen
haben, sollten vor der Durchfhrung von Penetrationstests Datensicherungen
gemacht werden.
Penetrationstests knnen durch Verwendung von Sicherheitskonfigurations-
und Protokollierungstools untersttzt werden. Diese Tools untersuchen eine
Systemkonfiguration und suchen nach gemeinsamen Schwachstellen wie etwa
allgemein lesbaren Dateien und fehlenden Passwrtern.
Mit Penetrationstests soll das Produkt auf Konstruktionsschwachstellen unter-
sucht werden, indem dieselben Methoden angewandt werden, die auch ein
potentieller Angreifer zur Ausnutzung von Schwachstellen benutzen wrde,
wie z. B.
- ndern der vordefinierten Befehlsabfolge,
- Ausfhren einer zustzlichen Funktion,
- Direktes oder indirektes Lesen, Schreiben oder Modifizieren interner
Daten,
- Ausfhren von Daten, deren Ausfhrung nicht vorgesehen ist,
- Verwenden einer Funktion in einem unerwarteten Kontext oder fr einen
unerwarteten Zweck,
- Aktivieren der Fehlerberbrckung,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Nutzen der Verzgerung zwischen dem Zeitpunkt der berprfung und

dem Zeitpunkt der Verwendung,
- Unterbrechen der Abfolge durch Interrupts, oder
- Erzeugen einer unerwarteten Eingabe fr eine Funktion.
Die Mechanismenstrken werden anhand der Begriffe Fachkenntnisse, Gele-
genheiten und Betriebsmittel definiert, in der ITSEM werden diese nher
erlutert. Beispielsweise knnen zur Bestimmung der Mechanismenstrke
folgende Regeln angewandt werden:
- Kann der Mechanismus innerhalb von Minuten von einem Laien allein
berwunden werden, dann kann er nicht einmal als niedrig eingestuft
werden.
- Kann ein erfolgreicher Angriff von jedem bis auf einen Laien innerhalb
von Minuten durchgefhrt werden, dann ist der Mechanismus als niedrig
einzustufen.
- Wenn fr einen erfolgreichen Angriff ein Experte bentigt wird, der mit
der vorhandenen Ausstattung Tage braucht, dann ist der Mechanismus als
mittel einzustufen.
- Kann der Mechanismus nur von einem Experten mit Sonderausstattung
berwunden werden, der dafr Monate braucht und eine geheime
Absprache mit einem Systemverwalter treffen muss, dann ist er als hoch
einzustufen.
Es muss sichergestellt werden, dass die durchgefhrten Tests alle sicherheits-
spezifischen Funktionen umfassen. Wichtig ist zu beachten, dass durch Testen
immer nur Fehler oder Abweichungen von den Spezifikationen festgestellt
werden knnen, niemals jedoch die Abwesenheit von Fehlern.
An einigen Beispielen sollen typische Untersuchungsaspekte aufgezeigt
werden:
Passwortschutz:
- Gibt es vom Hersteller voreingestellte Passwrter? Typische Beispiele fr
solche Passwrter sind der Produktname, der Herstellername,
"SUPERVISOR", "ADMINISTRATOR", "USER", "GUEST".
- Welche Datei ndert sich, wenn ein Passwort gendert wurde? Kann diese
Datei durch eine alte Version aus einer Datensicherung ersetzt werden, um
alte Passwrter zu aktivieren? Werden die Passwrter verschlsselt gespei-
chert oder sind sie im Klartext auslesbar? Ist es mglich, in dieser Datei
nderungen vorzunehmen, um neue Passwrter zu aktivieren?
- Wird der Zugang tatschlich nach mehreren fehlerhaften Passworteingaben
gesperrt?
- Werden in Zeitschriften oder Mailboxen Programme angeboten, die die
Passwrter des untersuchten Produkts ermitteln knnen? Fr einige
Standardapplikationen sind solche Programme erhltlich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wenn Dateien mit Passwrtern geschtzt werden, kann durch einen Ver-
gleich einer Datei vor und nach der Passwortnderung die Stelle ermittelt
werden, an der das Passwort gespeichert wird. Ist es mglich, an dieser
Stelle nderungen oder alte Werte einzugeben, um bekannte Passwrter zu
aktivieren? Werden die Passwrter verschlsselt gespeichert? Wie ist die
Stelle belegt, wenn der Passwortschutz deaktiviert ist?
- Kann die Passwort-Prfroutine unterbrochen werden? Gibt es Tastenkom-
binationen, mit denen die Passworteingabe umgangen werden kann?
Zugriffsrechte:
- In welchen Dateien werden Zugriffsrechte gespeichert und wie werden sie
geschtzt?
- Knnen Zugriffsrechte von Unberechtigten gendert werden?
- Knnen Dateien mit alten Zugriffsrechten zurckgespielt werden und
welche Rechte bentigt man dazu?
- Knnen die Rechte des Administrators so eingeschrnkt werden, dass er
keinen Zugriff auf die Nutz- oder Protokolldaten erhlt?
Datensicherung:
- Knnen erstellte Datensicherungen problemlos rekonstruiert werden?
- Knnen Datensicherungen durch ein Passwort geschtzt werden? Wenn ja,
knnen die oben dargestellten Untersuchungsanstze fr Passwrter einge-
setzt werden.
Verschlsselung:
- Bietet das Produkt an, Dateien oder Datensicherungen zu verschlsseln?
- Werden mehrere verschiedene Verschlsselungsalgorithmen angeboten?
Hierbei ist im allgemeinen folgende Faustregel zu beachten: "Je schneller
ein in Software realisierter Verschlsselungsalgorithmus ist, um so
unsicherer ist er."
- Wo werden die zur Ver- oder Entschlsselung genutzten Schlssel gespei-
chert?
Bei einer lokalen Speicherung ist zu untersuchen, ob diese Schlssel
passwortgeschtzt oder mit einem weiteren Schlssel berschlsselt
geschtzt werden. Bei einem Passwortschutz sind die obigen Punkte zu
bercksichtigen. Bei einer berschlsselung ist zu betrachten, wie der
zugehrige Schlssel geschtzt wird.
Dazu knnen folgende Punkte betrachtet werden: Welche Datei ndert
sich, wenn ein Schlssel gendert wurde? Durch den Vergleich dieser
Datei vor und nach der Schlsselnderung kann die Stelle ermittelt werden,
an der dieser Schlssel gespeichert wird. Ist es mglich, an dieser Stelle
nderungen vorzunehmen, um neue Schlssel zu aktivieren, die dann vom
Anwender genutzt werden, ohne dass dieser die Kompromittierung
bemerkt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gibt es vom Hersteller voreingestellte Schlssel, die vor der erstmaligen

Benutzung des Programms gendert werden mssen?
- Was passiert, wenn bei der Entschlsselung ein falscher Schlssel einge-
geben wird?
- Wird nach der Verschlsselung einer Datei die unverschlsselte Variante
gelscht? Wenn ja, wird sie zuverlssig berschrieben? Wird vor der
Lschung berprft, ob die Verschlsselung erfolgreich war?
Protokollierung:
- Wird der Zugriff auf Protokolldaten fr Unbefugte verwehrt?
- Werden die zu protokollierenden Aktivitten lckenlos aufgezeichnet?
- Hat der Administrator die Mglichkeit aufgrund seiner privilegierten
Rechte, sich unberechtigt und unbemerkt Zugriff auf Protokolldaten zu
verschaffen oder kann er die Protokollierung unbemerkt deaktivieren?
- Wie reagiert das Programm, wenn der Protokollierungsspeicher berluft?
Darber hinaus muss festgestellt werden, ob durch das neue Produkt Sicher-
heitseigenschaften an anderer Stelle unterlaufen werden. Beispiel: das zu
testende Produkt bietet eine Schnittstelle zur Betriebssystemumgebung, das
IT-System war aber vorher so konfiguriert, dass keine solchen Schnittstellen
existierten.
Pilotanwendung
Nach Abschluss aller anderen Tests kann noch eine Pilotanwendung, also ein
Einsatz unter Echtbedingungen, fr notwendig gehalten werden.
Erfolgt der Test in der Produktionsumgebung mit Echtdaten, muss vorab
durch eine ausreichende Anzahl von Tests die korrekte und fehlerfreie
Funktionsweise des Programms besttigt worden sein, um die Verfgbarkeit
und Integritt der Produktionsumgebung nicht zu gefhrden. Dabei kann das
Produkt beispielsweise bei ausgewhlten Benutzern installiert werden, die es
dann fr einen gewissen Zeitraum im echten Produktionsbetrieb einsetzen.
Testauswertung
Anhand der festgelegten Entscheidungskriterien sind die Testergebnisse zu
bewerten, alle Ergebnisse zusammenzufhren und mit der Testdokumentation
der Beschaffungsstelle bzw. Testverantwortlichen vorzulegen.
Anhand der Testergebnisse sollte ein abschlieendes Urteil fr ein zu
beschaffendes Produkt gefllt werden. Hat kein Produkt den Test bestanden,
muss berlegt werden, ob eine neue Marktsichtung vorgenommen werden
soll, ob die gestellten Anforderungen zu hoch waren und gendert werden
mssen oder ob von einer Beschaffung zu diesem Zeitpunkt abgesehen
werden muss.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel:
Am Beispiel eines Kompressionsprogramms wird nun eine Mglichkeit
beschrieben, Testergebnisse auszuwerten. Getestet wurden vier Produkte, die
nach der dreistufigen Skala aus M 2.82 Entwicklung eines Testplans fr
Standardsoftware bewertet wurden.
Eigenschaft Notwend Bedeu- Produk Produk Produk Produk

ig/ tung t1 t2 t3 t4
wnsche
nswert
korrekte N 10 2 2 j 0
Kompression und
Dekompression
Erkennen von Bit- N 10 2 2 n 2
fehlern in einer
komprimierten Datei
Lschung von N 10 2 2 j 2
Dateien nur nach
erfolgreicher
Kompression
DOS-PC, 80486, N 10 2 2 j 2
8 MB
Windows-tauglich W 2 0 2 j 2
Durchsatz bei 50 W 4 2 2 j 2
MHz ber 1 MB/s
Kompressionsrate W 4 2 1 n 0
ber 40%
Online-Hilfefunktion W 3 0 0 n 2
Passwortschutz fr W 2 2 1 n 2
komprimierte
Dateien
Bewertung 100 98 K.O. K.O.
Preisermittlung 49,- 25,- 39,-
(maximale Kosten DM DM DM
50.- DM pro Lizenz)
Produkt 3 war bereits in der Vorauswahl gescheitert und wurde daher nicht
getestet.
Produkt 4 scheiterte in dem Testabschnitt "korrekte Kompression und
Dekompression", weil die Erfllung der Eigenschaft mit 0 bewertet wurde, es
sich dabei aber um eine notwendige Eigenschaft handelt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei der Berechnung der Bewertungspunktzahlen fr die Produkte 1 und 2

wurden die Noten als Multiplikatoren fr die jeweilige Bedeutungskennzahl
benutzt und schlielich die Summe gebildet:
Produkt 1: 10*2+10*2+10*2+10*2+2*0+4*2+4*2+2*2 = 120
Produkt 2: 10*2+10*2+10*2+10*2+2*2+4*2+4*1+2*1 = 118
Nach der Testauswertung ist somit Produkt 1 auf dem ersten Platz, wird aber
knapp gefolgt von Produkt 2. Die Entscheidung fr ein Produkt hat jetzt die
Beschaffungsstelle anhand der Testergebnisse und des daraus resultierenden
Preis-/Leistungsverhltnisses zu treffen.
- Ist die benutzte Hardware- und Softwarekonfiguration konform zum
Anforderungskatalog?
- Bieten Hersteller oder Vertreiber Untersttzung oder Wartungsdienste bei
der Anwendung des Produktes?
- Sind in der Benutzerdokumentation alle fr den Benutzer relevanten
Funktionen vollstndig und verstndlich beschrieben?
- Enthalten die vorliegenden Dokumentationen Inhaltsverzeichnis, Stich-
wortverzeichnis und Seitenangaben?
- Sind alle geforderten Funktionen ausfhrbar und korrekt?
- Ist das Produkt in seiner Einsatzumgebung zuverlssig und robust? Knnen
unter Grenzbelastungen oder bei Fehlbedienung Daten verflscht oder
zerstrt werden?
- Werden unzulssige und nicht definierte Eingaben wie zulssige ver-
arbeitet?
- Wurden Testdokumentationen entsprechend den Vorgaben angefertigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.84 Entscheidung und Entwicklung der

Installationsanweisung fr Standardsoftware
Verantwortlich fr Umsetzung: Leiter IT, Leiter Fachabteilung, Beschaffungs-
stelle
Nach Abschluss aller Tests mssen die Testergebnisse der Beschaffungsstelle
vorgelegt werden. Die Entscheidung fr ein Produkt hat jetzt die Beschaf-
fungsstelle unter Beteiligung der Leiter der Fachabteilung und des IT-Bereichs
aufgrund der Testergebnisse und des daraus resultierenden Preis-
/Leistungsverhltnisses zu treffen. Hierbei ist insbesondere der Erfllungsgrad
der einzelnen Produkte gegenber dem Anforderungskatalog in Relation zum
Kaufpreis zu stellen. Auch sollten zustzliche Funktionen der Produkte, die
nicht im Anforderungskatalog aufgefhrt wurden, aber dennoch fr den
Einsatz sinnvoll sind, bei der Entscheidung bercksichtigt werden.
Erstellen einer Installationsanweisung
Nach der Entscheidung fr ein Produkt muss anschlieend fr das aus-
gewhlte Produkt eine Installationsanweisung erstellt werden. Whrend des
Testens wurde diejenige Konfiguration des Produktes ermittelt, die einen
sicheren und effizienten Produktionsbetrieb erlaubt. Damit soll Benutzer-
freundlichkeit, Ordnungsmigkeit und Sicherheit am Arbeitsplatz sicher-
gestellt werden.
Um die geeignete Konfiguration des Produktes im Wirkbetrieb sicher-
zustellen, mssen bestimmte Parameter vorgegeben werden. Teilweise muss
dies durch organisatorische Regelungen begleitet werden.
Fr einige Eigenschaften eines Produktes wird im folgenden beispielhaft
aufgezeigt, was im Rahmen einer Installationsanweisung vorgegeben werden
kann.
Beispiel:
Benutzerfreundlichkeit:
- Mit dem Produkt sind die Treiber X, Y und Z (Bildschirm, Drucker, Maus,
Netz) zu installieren, um eine fr den Benutzer akzeptable Arbeits-
umgebung zu schaffen (Bildschirm flimmerfrei, vernnftige Druckaufbe-
reitung, etc.).
- Diejenigen Einstellungen, bei denen einzelne Funktionen die grte Verar-
beitungsgeschwindigkeit haben, sind vorzugeben, wenn nicht andere Krite-
rien wie Sicherheit dagegen sprechen (die Gre der Auslagerungsdateien
ist auf mindestens 10 MB festzusetzen, die Option Verifikation ist fr die
Datensicherung zu aktivieren, obwohl die Verifikation zustzlichen Zeit-
aufwand erfordert).
Sicherheit:
- Die Parameter fr Sicherheitsfunktionen sind voreinzustellen (z. B. die
Mindestlnge von Passwrtern muss festgelegt werden (siehe dazu auch
M 2.11 Regelung des Passwortgebrauchs), Datensicherungen sind tglich
zu erstellen, die Protokollierung ist im vollen Umfang zu akti-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
vieren, Zugriffsrechte auf personenbezogene Protokolldateien sind nur dem

Datenschutzbeauftragten einzurichten, ...).
- Werden mehrere sicherheitsrelevante Verfahren untersttzt (z. B.
Verschlsselungsalgorithmus, Hashfunktionen), sind diejenigen auszu-
whlen, mit denen ein angemessenes Schutzniveau erreicht wird (zur
Auswahl siehe M 2.164 Auswahl eines geeigneten kryptographischen Ver-
fahrens).
Funktion:
- Nur die Funktionen X, Y, und Z sind zu aktivieren, unerwnschte oder
nicht bentigte Funktionen sind abzuschalten.
- Die Funktion der automatischen Datensicherung ist mit dem Parameter
"alle 10 Minuten" zu aktivieren.
Organisation:
- Die Installation ist vom Administrator durchzufhren.
- Regelungen fr den Betrieb mssen erlassen werden (z. B. Datensiche-
rungen sind eigenverantwortlich vom Anwender durchzufhren, Pass-
wrter mssen nach 30 Tagen gewechselt werden).
Randbedingungen:
- Die Konfiguration der Plattform, auf der das Standardsoftwareprodukt zum
Einsatz kommen soll, muss insbesondere dann beschrieben und vor-
gegeben werden, wenn systembedingte Schwachstellen der Plattform damit
beseitigt werden.
- Sind in der Installationsanweisung alle Angaben fr eine erfolgreiche
Installation enthalten?
- Sind Angaben enthalten, wie das Produkt wieder deinstalliert wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.85 Freigabe von Standardsoftware

Verantwortlich fr Umsetzung: Leiter Fachabteilung, Leiter IT
Vor der bernahme der Standardsoftware in den Wirkbetrieb steht die
formelle Freigabe. Verantwortlich fr die Freigabe eines Produktes ist die
Behrden- bzw. Unternehmensleitung, sie kann dies aber an die Leitung der
Fachabteilung oder die Leitung des IT-Bereichs delegieren. Die Fachabteilung
kann die durch Behrden- bzw. Unternehmensleitung vorgegebene
Freigaberegelung durch eigene Restriktionen weiter einschrnken. Der Einsatz
nicht freigegebener Software ist zu untersagen (siehe M 2.9 Nutzungsverbot
nicht freigegebener Hard- und Software).
Der Freigabe geht immer der erfolgreiche Abschluss aller notwendigen Tests
voraus (siehe M 2.83 Testen von Standardsoftware). Eine Freigabe darf nicht
erfolgen, wenn whrend der Tests nicht tolerierbare Fehler, z. B. erhebliche
Sicherheitsmngel, festgestellt wurden.
Fr die Freigabe sind Installations- bzw. Konfigurationsvorschriften zu
erarbeiten, deren Detaillierungsgrad davon abhngig ist, ob die Installation
durch die Systemadministration oder den Benutzer vorgenommen werden soll.
Die Installations- bzw. Konfigurationsvorschriften sind Ergebnisse der im
Rahmen der Beschaffung durchgefhrten Tests (siehe M 2.83 Testen von
Standardsoftware). Wenn unterschiedliche Konfigurationen zulssig sind,
muss die Auswirkung der einzelnen Konfigurationen auf die Sicherheit
dargelegt werden. Insbesondere muss festgelegt werden, ob fr alle oder nur
einige Benutzer Einschrnkungen der Produktfunktionalitt oder der
Zugriffsrechte vorzunehmen sind. Fr die Festlegung dieser Randbedingungen
sind der Personal- bzw. Betriebsrat, der Datenschutzbeauftragter sowie der IT-
Sicherheitsbeauftragte rechtzeitig zu beteiligen.
Die Freigabe sollte in Form einer schriftlichen Freigabeerklrung erfolgen.
In der Freigabeerklrung sollten Aussagen gemacht werden zu den folgenden
Punkten:
- Programmname und Versionsnummer,
- Bezeichnung des IT-Verfahrens, in dem das Produkt eingesetzt werden
soll,
- Besttigung, dass die eingesetzten IT-Komponenten den fachlichen
Anforderungen entsprechen,
- Datum der Freigabe, Unterschrift des Freigabe-Verantwortlichen,
- Unbedenklichkeitserklrung seitens IT-Sicherheitsbeauftragter, Daten-
schutzbeauftragter, Personal- bzw. Betriebsrat,
- vorgesehener Zeitpunkt des Einsatzes im Wirkbetrieb,
- fr welche Benutzer das Produkt freigegeben wird,
- Installationsanweisung, insbesondere an welchen Arbeitspltzen es mit
welcher Konfiguration installiert wird,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- wer berechtigt ist, es zu installieren,

- wer Zugriff auf die Installationsdatentrger hat und
- welche Schulungen vor Nutzung des Produktes vorzunehmen sind.
Die Freigabeerklrung muss allen Beteiligten zur Kenntnis gegeben werden,
insbesondere sollten bei der Freigabeinstanz, dem IT-Bereich, der Fachabtei-
lung und ggf. beim IT-Anwender Kopien vorhanden sein.
Darber hinaus ist organisatorisch zu regeln, dass die Freigabe und ggf. die
notwendigen Tests wiederholt werden, wenn sich durch Versionswechsel oder
Patches grundlegende Eigenschaften, insbesondere im Bereich der
Sicherheitsfunktionen, gendert haben. nderungen der genannten Art sind
dem fr die Freigabe des Produktes Verantwortlichen mitzuteilen.
Weiterhin kann festgelegt werden, welche Standardsoftware-Produkte, ab-
hngig vom Einsatzort und -zweck, generell freigegeben werden.
Voraussetzung ist, dass sie zumindest auf Computer-Viren geprft, dass die
Lizenzfragen geklrt und dass sie registriert sind. Beispiele hierfr wren:
- Demo-Versionen zu Testzwecken, die auf speziellen Rechnern zur Verf-
gung gestellt werden,
- Public-Domain-Software, die auf speziellen Servern installiert werden,
- Spielprogramme auf speziellen Rechnern, die in Pausenrumen aufgestellt
werden.
- Wo werden die Freigabeerklrungen verwaltet und hinterlegt?
- Ist eine Installationsanweisung vorhanden?
- Ist sichergestellt, dass smtliche Software der Freigabeprozedur unterzogen
wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.86 Sicherstellen der Integritt von

Standardsoftware
Es ist sicherzustellen, dass die freigegebene Standardsoftware nur unverndert
installiert werden kann. Damit soll verhindert werden, dass zwischenzeitlich
gewollte oder ungewollte Vernderungen vorgenommen werden knnen, z. B.
durch Computer-Viren, Bitfehler aufgrund technischer Fehler oder Manipula-
tionen in Konfigurationsdateien.
Die Installation darf daher ausschlielich von Originaldatentrgern bzw. von
nummerierten Kopien der Originaldatentrger erfolgen. Eine Alternative zur
lokalen Installation von Datentrgern ist die Installation ber ein lokales Netz
von einer dafr freigegebenen Version. Dabei sollte sichergestellt sein, dass
nur berechtigte Personen darauf Zugriff haben.
Von den Originaldatentrgern sollten, falls der Datenumfang (z. B. CD-ROM)
es zulsst, Sicherungskopien angefertigt werden. Originaldatentrger und alle
Kopien mssen vor unberechtigtem Zugriff geschtzt aufbewahrt werden
(siehe M 6.21 Sicherungskopie der eingesetzten Software). Die angefertigten
Kopien sollten nummeriert und in Bestandsverzeichnisse aufgenommen
werden. Kopien, die nicht mehr bentigt werden, sind zu lschen. Vor der
Installation muss eine Computer-Virenprfung durchgefhrt werden.
Optional kann ber die Originaldatentrger oder ber eine whrend des Tests
installierte Referenzversion eine Checksumme (vgl. M 4.34 Einsatz von
Verschlsselung, Checksummen oder Digitalen Signaturen) gebildet werden,
anhand derer vor der Installation die Integritt der dafr eingesetzten Datentr-
ger bzw. der in lokalen Netzen hinterlegten Versionen oder anhand derer die
korrekte Installation berprft werden kann. Darber hinaus knnen installier-
ten Programme zustzlich zum Schutz vor unberechtigten Vernderungen der
freigegebenen Konfiguration mit Checksummen versehen werden. Auf diese
Weise knnen auch Infektionen mit bisher unbekannten Computer-Viren
erkannt werden. Damit kann auch festgestellt werden, ob eine Vireninfektion
vor oder nach der Installation stattgefunden hat.
- Auf welche Art wird die Integritt der Standardsoftware sichergestellt?
- Werden periodisch Kontrollen durchgefhrt, um die Integritt der
installierten Programme zu berprfen?
- Werden Manipulationsversuche an Programmen und Daten festgestellt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.87 Installation und Konfiguration von

Standardsoftware
Die freigegebene Software wird entsprechend der Installationsanweisung auf
den dafr vorgesehenen IT-Systemen installiert. Die Installationsanweisung
beinhaltet neben den zu installierenden Programmen auch Konfigurationspara-
meter und die Einrichtung der Hardware- und Softwareumgebung.
Abweichungen von der Installationsanweisung bedrfen der Zustimmung der
Freigabeinstanz.
Wenn die Benutzer die Software selbst installieren sollen, muss ihnen eine
Installationsanweisung zur Verfgung gestellt werden, die eine selbstndige
Installation ermglicht. Mindestens die Pilot-Installation durch einen ausge-
whlten typischen Benutzer sollte durch die IT-Abteilung begleitet werden,
um die Verstndlichkeit der Installationsanweisung zu berprfen.
Da Standardsoftware fr eine Vielzahl von Einsatzfelder entwickelt wird, ent-
hlt sie meist mehr Funktionen, als fr die Erfllung der Fachaufgabe bentigt
werden. Damit es zu weniger Problemen und Fehlern bei der Arbeit mit der
Software kommt, sollten nur die tatschlich bentigten Funktionalitten instal-
liert werden. Funktionalitten, die zu Sicherheitsproblemen fhren knnen,
drfen nicht freigegeben werden.
Sowohl vor als auch nach der Installation von Software sollte eine vollstn-
dige Datensicherung durchgefhrt werden. Die erste Datensicherung kann bei
nachfolgenden Problemen whrend der Installation zur Wiederherstellung
eines konsolidierten Aufsetzpunktes verwendet werden. Nach der erfolg-
reichen Installation sollte erneut eine vollstndige Datensicherung durch-
gefhrt werden, damit bei spteren Problemen wieder auf den Zustand nach
der erfolgreichen Installation des Produktes aufgesetzt werden kann.
Die erfolgreiche Installation wird schriftlich an die fr die Aufnahme des
Wirkbetriebes zustndige Stelle gemeldet.
Optional kann die Installation durch den Einsatz eines sog. "Delta-Tools"
begleitet werden, das alle Vernderungen in einer IT-Umgebung zwischen
zwei bestimmbaren Zeitpunkten dokumentiert. Diese Dokumentation von
Vernderungen ist insbesondere bei der Deinstallation der Software hilfreich.
Beim Einsatz eines neuen Produktes mssen evtl. Datenbestnde bernommen
werden, die mit einem Vorgngerprodukt erzeugt wurden. Hat sich bei den
Tests gezeigt, dass es dabei zu Schwierigkeiten kommen kann, sind
Hilfestellungen fr die Benutzer zu erarbeiten oder die bernahme von alten
Datenbestnden ist zentral durch geschultes Personal durchzufhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welche Regelungen bestehen bezglich mglicher Abweichungen von der
Installationsanweisung?
- Wie wird der Erfolg einer Installation berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.88 Lizenzverwaltung und Versionskontrolle von

Standardsoftware
Ohne eine geeignete Versionskontrolle und Lizenzkontrolle kommt es erfah-
rungsgem schnell zur Verwendung verschiedenster Versionen auf einem IT-
System oder innerhalb einer Organisationseinheit, von denen evtl. einige ohne
Lizenz benutzt werden.
Auf allen IT-Systemen einer Institution darf ausschlielich lizenzierte Soft-
ware eingesetzt werden. Diese Regelung muss allen Mitarbeitern bekannt-
gemacht werden, die Administratoren der verschiedenen IT-Systeme mssen
sicherstellen, dass nur lizenzierte Software eingesetzt wird. Dafr mssen sie
mit geeigneten Werkzeugen zur Lizenzkontrolle ausgestattet werden.
Hufig werden in einer Institution verschiedene Versionen einer Standardsoft-
ware eingesetzt. Im Rahmen der Lizenzkontrolle muss es auch mglich sein,
einen berblick ber alle eingesetzten Versionen zu erhalten. Damit kann
gewhrleistet werden, dass alte Versionen durch neuere ersetzt werden, sobald
dies notwendig ist, und dass bei der Rckgabe von Lizenzen alle Versionen
gelscht werden.
Darber hinaus sind die verschiedenen Konfigurationen der installierten Soft-
ware zu dokumentieren. Damit muss es mglich sein, sich einen berblick zu
verschaffen, an welchem IT-System welche sicherheitsrelevanten Einstel-
lungen eines Standardsoftwareproduktes durch die Freigabe vorgegeben und
welche tatschlich installiert wurden. Damit kann z. B. schnell geklrt werden,
an welchen Rechnern beim Produkt XYZ die Makro-Programmierung
installiert worden ist und an welchen nicht.
- Sind verschiedene Versionen eines Standardsoftwareproduktes im Einsatz?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.89 Deinstallation von Standardsoftware

Bei der Deinstallation von Software mssen alle Dateien entfernt werden, die
fr den Betrieb der Software auf dem IT-System angelegt worden sind, und
alle Eintrge in Systemdateien, die bezglich des Produktes vorgenommen
wurden, gelscht werden. Bei vielen Softwareprodukten werden whrend der
Installation in diversen Verzeichnissen auf dem IT-System Dateien angelegt
oder bestehende Dateien verndert. Hufig wird der Benutzer nicht einmal
ber alle bei der Installation durchgefhrten Vernderungen am IT-System
informiert.
Um eine vollstndige Deinstallation durchfhren zu knnen, ist es daher hilf-
reich, die bei der Installation durchgefhrten Systemnderungen nachzuhalten,
entweder manuell oder mit Hilfe von speziellen Tools. Wird dies nicht
vorgenommen, kommt es erfahrungsgem dazu, dass eine Deinstallation nur
rudimentr stattfindet oder dass sie unterlassen wird aus Furcht, wichtige
Dateien bei der Deinstallation zu lschen.
- Werden Stichproben durchgefhrt, ob bei einem Versionswechsel die
Vorgngerversion vollstndig deinstalliert wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.90 berprfung der Lieferung

Verantwortlich fr Initiierung: Leiter IT, Leiter Organisation
Nach Eingang einer Lieferung ist anhand der vorhandenen Unterlagen zu
berprfen,
- ob die Lieferung bestellt wurde,
- fr wen sie bestimmt ist,
- ob Transportschden zu erkennen sind,
- ob sie vollstndig ist, d. h. ob einerseits alle bestellten Komponenten und
andererseits alle gem Produktbeschreibung zum Lieferumfang des
Produktes gehrenden Komponenten vorhanden sind.
Die Ergebnisse dieser Prfungen sind in einem Wareneingangsverzeichnis zu
dokumentieren, zusammen mit:
- Produktname und Version,
- Produktart, z. B. Textverarbeitung,
- Lieferumfang, also Beschreibung der einzelnen Komponenten inklusive
Anzahl und Lieferform (Buch, Diskette, CD-ROM, ...),
- Lieferdatum,
- Lieferart,
- wer es in Empfang genommen hat,
- Aufbewahrungsort und
- an wen es weitergegeben wurde.
Fr die Durchfhrung der funktionalen Tests, sowie die anschlieende
formelle Freigabe, die Installation und Konfiguration mssen die gelieferten
Produkte an die IT-Abteilung weitergegeben werden.
Werden die Produkte nur vorbergehend eingesetzt oder zur Verfgung
gestellt, z. B. im Rahmen von Tests, mssen zumindest die Seriennummer und
andere produktspezifische Identifizierungsmerkmale in entsprechende
Bestandsverzeichnissen vermerkt werden. Wenn die gelieferten Produkte fr
den dauerhaften Verbleib vorgesehen sind, sind sie mit eindeutigen Identifi-
zierungsmerkmalen (z. B. gruppierte fortlaufende Inventarnummern) zu
kennzeichnen. Anschlieend mssen sie in ein Bestandsverzeichnis aufge-
nommen werden. Dieses muss Auskunft geben knnen ber:
- Identifizierungsmerkmale,
- Beschaffungsquellen, Lieferzeiten,
- Verbleib,
- Freigabedatum,
- Installationsdatum und Konfigurationsbesonderheiten und
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wartungsvertrge, Wartungsintervalle.
- Welche Regelungen zum Wareneingang von informationstechnischen
Produkten sind in Kraft?
- Wie wird verfahren, wenn unvollstndige Lieferungen festgestellt werden?
- Sind schon hufiger unvollstndige Lieferungen auffllig geworden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.91 Festlegung einer Sicherheitsstrategie fr das

Windows NT Client-Server-Netz
Bevor mit der eigentlichen Konfiguration und Installation von Windows NT in
einem Client-Server-Netz begonnen werden kann, mssen zuerst zwei
grundlegende berlegungen angestellt werden:
Zunchst muss geklrt werden, welche Dienstleistung das Betriebssystem
erbringen und in welchem Rahmen es diesbezglich eingesetzt werden soll.
Dies soll anhand einiger Beispiele veranschaulicht werden:
- Das System wird in einem servergesttzten PC-Netz als Server fr eine
grere Arbeitsgruppe eingesetzt, in der unterschiedliche Rechte vergeben
werden knnen. Ggf. sollen aufgrund konkreter Anforderungen zustzlich
Peer-to-Peer-Funktionalitten in eingeschrnkter Form realisiert werden.
Beispielsweise sollen einzelne Drucker ber Peer-to-Peer-Funktionalitt
gemeinsam benutzt werden knnen.
- Das System wird als Client in einem servergesttzten PC-Netz mit Win-
dows NT Servern eingesetzt, bei dem auf die Peer-to-Peer-Funktionalitt
zum Austausch von Daten verzichtet werden kann.
- Das System wird als Client in einem servergesttzten PC-Netz mit Novell
Netware Servern eingesetzt.
- Das System wird als Server in einem PC-Netz mit MS-DOS-,
MS-Windows-, WfW- oder Windows 95-Clients eingesetzt.
- Das System wird als Server in einem Netz eingesetzt, in dem ausschlie-
lich Windows NT-Clients vorhanden sind.
Durch die Verwendung von Peer-to-Peer-Funktionalitten innerhalb eines
Windows NT Netzes knnen zustzliche Sicherheitsprobleme entstehen (siehe
dazu auch Kapitel 6.3 Peer-to-Peer-Dienste). Deshalb sollte auf die
Verwendung von Peer-to-Peer-Funktionalitten innerhalb von
Windows NT Netzen verzichtet werden. Peer-to-Peer-Funktionalitten
sollten hchstens als bergangslsung eingeschrnkt zugelassen werden,
wenn z. B. WfW-Rechner oder nicht-netzfhige Drucker in das Windows NT-
Netz eingebunden werden sollen.
Anschlieend mssen diese berlegungen in eine Sicherheitsstrategie ber-
setzt werden.
Dabei zeigt sich, dass je nach bereits vorhandener Systemumgebung und
Organisationsstruktur sowie der ggf. vorzusehenden Restriktionen an even-
tuelle Peer-to-Peer-Funktionalitten ein mehr oder weniger groer Aufwand
bei der Entwicklung einer dazu passenden Sicherheitsstrategie notwendig ist.
Es wird nachfolgend eine methodische Vorgehensweise aufgezeigt, mittels
derer eine umfassende Sicherheitsstrategie fr ein Client-Server-Netz ent-
wickelt werden kann. Da jedoch Windows NT in verschiedenen Konfigu-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
rationen eingesetzt werden kann, ist fr die jeweilige Ausprgung individuell

zu entscheiden, welche der beschriebenen Schritte anzuwenden sind.
Festlegung einer Sicherheitsstrategie fr ein Client-Server-Netz
In der Sicherheitsstrategie muss aufgezeigt werden, wie ein Client-Server-
Netz fr die jeweilige Organisation sicher aufgebaut, administriert und
betrieben wird. Nachfolgend werden die einzelnen Entwicklungsschritte einer
solchen Strategie vorgestellt:
1. Definition der Client-Server-Netzstruktur
Im ersten Schritt sind die logische Struktur des Client-Server-Netzes, insbe-
sondere die Zuordnung der Server und der Netz-Domnen festzulegen (siehe
M 2.93 Planung des Windows NT Netzes). Nach Mglichkeit sollte auf die
Verwendung von Peer-to-Peer-Funktionalitten verzichtet werden, da diese
die Sicherheit des Client-Server-Netzes beintrchtigen knnen. Sofern sich
dies jedoch nicht vermeiden lsst, sind verbindliche Regelungen fr die
Nutzung von Peer-to-Peer-Funktionalitten zu treffen (siehe M 2.67
Festlegung einer Sicherheitsstrategie fr Peer-to-Peer-Dienste).
Ein Client-Server-Netz sollte von einem geschulten Netzadministrator nebst
Stellvertreter sicher betrieben werden. Diese allein drfen Sicherheitspara-
meter im Netz verndern. Sie sind z. B. dafr zustndig, auf den Servern den
entsprechenden Verantwortlichen Administrationsrechte und -werkzeuge zur
Verfgung zu stellen, damit diese die Vergabe von Datei- und Verzeichnisbe-
rechtigungen, die Freigabe der von anderen bentigten Verzeichnissen bzw.
Anwendungen, den Aufbau von Benutzergruppen und -konten sowie die
Einstellung der Systemrichtlinien fr Benutzer, Zugriffskontrolle und ber-
wachung vornehmen knnen.
Die Verantwortlichkeiten der einzelnen Benutzer im Client-Server-Netz sind
unter Schritt 11 dargestellt.
3. Festlegung von Namenskonventionen
Um die Verwaltung des Client-Server-Netzes zu erleichtern, sollten eindeutige
Namen fr die Rechner, Benutzergruppen und die Benutzer verwendet
werden.
Zustzlich sollten Namenskonventionen fr die Freigabenamen von Verzeich-
nissen oder Druckern eingefhrt werden (siehe M 2.67 Festlegung einer
Sicherheitsstrategie fr Peer-to-Peer-Dienste). Sollen keine Rckschlsse auf
den Inhalt eines freigegebenen Verzeichnisses mglich sein, sind ent-
sprechende Pseudonyme zu verwenden. Soll eine freigegebene Ressource
nicht als solche erkennbar sein, ist dem Freigabenamen das Zeichen "$"
anzuhngen. Letzteres empfiehlt sich immer dann, wenn Verzeichnisse nur
zum bilateralen Austausch von Informationen zwischen zwei Anwendern oder
zum Zugriff auf Ressourcen, die nur einzelnen Benutzern bekannt sein sollen,
freigegeben werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. Festlegung der Regeln fr Benutzerkonten

Vor der Einrichtung von Benutzerkonten sollten die Restriktionen, die fr alle
bzw. fr bestimmte dieser Konten gelten sollen, festgelegt werden. Dies
betrifft insbesondere die Regelungen fr Passwrter und fr die Reaktion des
Systems auf fehlerhafte Login-Vorgnge. Die festgelegten Regelungen
knnen mit Hilfe der Option "Richtlinien" des Benutzer-Managers umgesetzt
werden (siehe M 4.48 Passwortschutz unter Windows NT/2000).
5. Einrichtung von Gruppen
Zur Vereinfachung der Administration sollten Benutzerkonten, fr die die
gleichen Anforderungen gelten, zu Gruppen zusammengefasst werden.
Benutzerrechte sowie Datei-, Verzeichnis- und Freigabeberechtigungen und
ggf. weitere vordefinierte Funktionen werden dann den Gruppen und nicht
einzelnen Benutzerkonten zugeordnet. Die Benutzerkonten erben die Rechte
und Berechtigungen der Gruppen, denen sie angehren. So ist es z. B. denk-
bar, alle Mitarbeiter einer Abteilung in einer Gruppe zusammenzufassen. Eine
Zuweisung von Benutzerrechten und -berechtigungen an einzelne Benutzer
sollte nur erfolgen, wenn dies ausnahmsweise unumgnglich ist.
6. Festlegung der Benutzerrechte
Rechte gestatten einem Benutzer die Ausfhrung bestimmter Aktionen auf
dem System. Sie beziehen sich auf das gesamte System, sind keinem speziel-
len Objekt zugeordnet und knnen die Berechtigungen fr ein Objekt auer
Kraft setzen, da ein Recht Vorrang vor allen Datei- und Verzeichnisberechti-
gungen hat. Wenn sich ein Benutzer bei einem Konto anmeldet, dem die
gewnschten Rechte entweder direkt oder ber die Gruppenmitgliedschaft
erteilt wurden, kann er die entsprechenden Aktionen ausfhren. Besitzt ein
Benutzer nicht die geeigneten Rechte, so verhindert Windows NT jeden Ver-
such, die betreffenden Aktionen auszufhren.
Wie schon zuvor dargestellt, sollten Benutzerrechte mglichst nur Gruppen
und nicht einzelnen Benutzern zugeordnet werden.
Windows NT legt bei der Installation Voreinstellungen fest, die in der Regel
fr einen sicheren und effizienten Betrieb ausreichend sind. Empfehlenswert
erscheint jedoch, der Gruppe "Jeder" das Recht "System herunterfahren" und
der Gruppe "Jeder" und ggf. der Gruppe "Gste" das Recht "Lokale Anmel-
dung" zu entziehen (siehe M 4.50 Strukturierte Systemverwaltung unter
Windows NT).
7. Festlegung der Vorgaben fr Protokollierung
Windows NT stellt sehr ausfhrliche Mglichkeiten der Protokollierung
sicherheitsrelevanter Ereignisse zur Verfgung, die bei vollstndiger Nutzung
in der Lage sind, das System weitgehend mit Auditing zu beschftigen und
dabei groe Mengen an Plattenplatz zu verbrauchen. Dabei kann ein Spektrum
von Ereignisarten aufgezeichnet werden, das sich von systemweiten
Ereignissen, wie zum Beispiel dem Anmelden eines Benutzers bis hin zum
Versuch eines Benutzers, eine bestimmte Datei zu lesen, erstreckt. Sowohl die
erfolgreichen als auch die fehlgeschlagenen Versuche, eine Aktion durch-
zufhren, lassen sich aufzeichnen. Bei der Konfiguration der Protokollierung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ist jedoch zu beachten, dass ein Mehr an Protokollierung nicht unbedingt auch
die Sicherheit des berwachten Systems erhht. Protokolldateien, die nicht
ausgewertet werden oder die aufgrund ihres Umfangs nur mit groem Auf-
wand auswertbar sind, fhren nicht zu einer besseren Kontrolle der System-
ablufe, sondern sind letztlich nutzlos. Aus diesen Grnden sollte die Proto-
kollierung so eingestellt werden, dass sie im Normalfall nur die wirklich
bedeutsamen Ereignisse aufzeichnet (siehe M 4.54 Protokollierung unter
Windows NT).
8. Regelungen zur Datenspeicherung
Es ist festzulegen, wo Benutzerdaten gespeichert werden (siehe M 2.138
Strukturierte Datenhaltung). So ist denkbar, dass Benutzerdaten nur auf einem
Server abgelegt werden. Eine Datenspeicherung auf der lokalen Festplatte ist
bei diesem Modell nicht erlaubt. Mglich ist aber auch, bestimmte Benutzer-
daten nur auf der lokalen Festplatte abzulegen. Nach welcher Strategie
verfahren werden soll, muss an den konkreten Umstnden des Einzelfalles
festgelegt werden. Eine generelle Empfehlung auszusprechen, ist nicht
mglich.
9. Einrichtung von Projektverzeichnissen
Um eine saubere Trennung von Benutzer- und projektspezifischen Daten
untereinander sowie von den Programmen und Daten des Betriebssystems
durchzusetzen, sollte eine geeignete Verzeichnisstruktur festgelegt werden,
mit der eine projekt- und benutzerbezogene Dateiablage untersttzt wird. So
knnen beispielsweise zwei Hauptverzeichnisse \Projekte und \Benutzer ange-
legt werden, unter denen dann die Dateien und Verzeichnisse der Projekte
bzw. Benutzer in jeweils eigenen Unterverzeichnissen abgelegt werden.
10. Vergabe der Zugriffsrechte
Fr die Server ist festzulegen, welche Verzeichnisse und bei Nutzung von
NTFS-Partitionen welche Dateien fr den Betrieb freizugeben und welche
Zugriffsrechte ihnen zuzuweisen sind (siehe M 4.53 Restriktive Vergabe von
Zugriffsrechten auf Dateien und Verzeichnisse unter Windows NT). Zustzlich
ist bei Nutzung von Peer-to-Peer-Funktionalitten auf der Ebene der Clients
zu entscheiden, welche Verzeichnisse fr Netzzugriff freizugeben sind (siehe
M 2.94 Freigabe von Verzeichnissen unter Windows NT).
Das zuvor gesagte gilt analog fr die Freigabe von Druckern.
11. Verantwortlichkeiten fr Administratoren und Benutzer im Client-
Server-Netz
Neben der Wahrnehmung der Netzmanagement-Aufgaben (siehe Nr. 2)
mssen weitere Verantwortlichkeiten festgelegt werden. Es ist festzulegen,
welche Verantwortung die einzelnen Administratoren im Client-Server-Netz
- die Auswertung der Protokolldateien auf den einzelnen Servern oder
Clients,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Auch die Endbenutzer mssen in einem Client-Server-Netz bestimmte Verant-
wortlichkeiten bernehmen, sofern ihnen Rechte zur Ausfhrung administrati-
ver Funktionen gegeben werden. In der Regel beschrnken sich diese Verant-
wortlichkeiten jedoch auf die Vergabe von Zugriffsrechten auf die eigenen
Dateien, sofern diese explizit festgelegt und nicht von Voreinstellungen des
bergeordneten Verzeichnisses bernommen werden.
12. Schulung
Abschlieend muss festgelegt werden, welche Benutzer zu welchen Punkten
geschult werden mssen. Erst nach ausreichender Schulung kann der Wirkbe-
trieb aufgenommen werden. Insbesondere die Administratoren sind hinsicht-
lich der Verwaltung und der Sicherheit von Windows NT grndlich zu
schulen.
Die so entwickelte Sicherheitsstrategie ist zu dokumentieren und im erforder-
lichen Umfang den Benutzern des Client-Server-Netzes mitzuteilen.
- Wird die Sicherheitsstrategie an Vernderungen im Einsatzumfeld
angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.92 Durchfhrung von Sicherheitskontrollen im

Windows NT Client-Server-Netz
Die folgenden Punkte sollten auf der Ebene der Server in einem Windows NT
Client-Server-Netz regelmig auf Einhaltung und Effektivitt kontrolliert
werden (siehe auch M 4.54 Protokollierung unter Windows NT):
- System-Sicherheits-Einstellungen
Die korrekte Einstellung der sicherheitsrelevanten Eintrge in der
Registrierung, d. h. im wesentlichen die Eintrge im Bereich
HKEY_LOCAL_MACHINE, ist regelmig zu kontrollieren, indem die
Eintrge der Sicherheitsprotokolle, die sich auf die Registrierung beziehen,
berprft werden.
- Benutzung von privilegierten Benutzerkonten
Die Benutzung privilegierter Benutzerkonten, also von Konten mit erwei-
terten Rechten und Berechtigungen wie etwa Administratoren, ist regel-
mig durch berprfung der Eintrge im Sicherheitsprotokoll zu ber-
prfen. Ebenso ist das Protokoll auf Anmeldeversuche auf das Gastbe-
nutzerkonto zu berprfen.
- Fehlgeschlagene Zugriffsversuche (Berechtigungsverste)
Sofern Zugriffe auf Dateien und/oder die Registrierung aufgezeichnet
werden, ist das Sicherheitsprotokoll wchentlich, bei Bedarf auch fter, auf
das Vorliegen fehlgeschlagener Zugriffsversuche zu berprfen. Werden
Berechtigungsverste festgestellt, ist die Ursache zu ermitteln.
- Systemintegritt
Die Systemintegritt ist regelmig zu berprfen; insbesondere sind die
Daten der letzten Vernderung sowie die Zugriffsrechte auf die wichtigen
Systemdateien zu berprfen und mit den Werten, die unmittelbar nach der
Installation des Systems sowie bei der jeweils vorherigen berprfung
gegeben waren, zu vergleichen. Da diese Kontrolle mit Hilfe der von
Windows NT gebotenen Mglichkeiten relativ aufwendig ist, sollten hier
geeignete Zusatzwerkzeuge eingesetzt werden, beispielsweise das Share-
ware-Programm DumpACL oder das mit der Technischen Referenz (dem
"Resource Kit") zu Windows NT ausgelieferte Dienstprogramm WinDiff,
mit dem sich Inhalte von Verzeichnissen und Dateien vergleichen lassen.
- Unbenutzte Benutzerkonten
Es ist sicherzustellen, dass die Konten ehemaliger Beschftigter sofort
deaktiviert und nach einer geeigneten bergangszeit (ca. 1/2 Jahr) vom
System gelscht werden. Da die Zeit des letzten Anmeldens am System
nicht angezeigt wird, sind zu diesem Zweck nach Mglichkeit alle
Benutzerkonten mit einem Verfallsdatum einzurichten, das in gewissen
Zeitabstnden (z. B. jhrlich) auf Antrag des Benutzers aktualisiert werden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
muss. Inaktive, d. h. abgelaufene, Benutzerkonten sind zu lschen. Die

Eigentmer sind vorab zu informieren. Die Liste der definierten Benutzer
ist regelmig zu berprfen, um sicherzustellen, dass nur aktive Beschf-
tigte auf dem System arbeiten.
- Gruppenzugehrigkeit
Eine strukturierte Systemadministration setzt voraus, dass Systemrechte
und Objektberechtigungen mglichst nicht an einzelne Benutzer, sondern
an Benutzergruppen vergeben werden. Es ist sicherzustellen, dass bei
nderungen in den Beschftigungsverhltnissen die Mitgliedschaft der
einzelnen Benutzer in den Benutzergruppen den organisatorischen Vorga-
ben angepasst wird. Daher ist regelmig zu prfen, ob die Mitglied-
schaften der Benutzer in den verschiedenen Benutzergruppen noch dem
aktuellen Stand entspricht. Weiterhin ist bei der Vernderung der Gruppen-
mitgliedschaft eines Benutzers zu prfen, ob dies zu einer Anhufung von
Benutzerrechten fhrt. Insbesondere ist in regelmigen zu berprfen, ob
die Zuweisung von Sonderrechten an Gruppen oder einzelne Benutzer
noch den aktuellen organisatorischen Vorgaben entsprechen.
- Berechtigungskontrolle
Es ist sicherzustellen, dass die Eigentmer von Dateien und Verzeichnissen
ihre Verpflichtung verstehen, anderen Benutzern nur dann Zugriff zu
gewhren, wenn dies erforderlich ist. Mit dem Dateimanager bzw. Explorer
ist regelmig zu berprfen, dass auf sensitive Daten nicht zu
weitgehende Berechtigungen vergeben wurden. Kritisch sind insbesondere
Berechtigungen fr die Gruppen "Jeder" und "Gste" bzw. "Domnen-
Gste". Sofern temporre Berechtigungen zum Einsatz kommen, ist
sicherzustellen, dass dies nur dann geschieht, wenn es erforderlich ist, und
dass diese Berechtigungen sorgfltig berwacht werden.
Es sind Prozeduren bzw. Verfahren zu entwickeln fr den Fall, dass Abwei-
chungen von den festgelegten Einstellungen auftreten. Diese Prozeduren
mssen folgende Punkte enthalten:
- wer wird wann informiert,
- Begrndung fr die eventuelle Wahl abweichender Einstellungen und
Angaben, ob hierdurch mglicherweise eine Sicherheitslcke entsteht,
- Schritte zur Behebung der Sicherheitslcke,
- Schritte zur Identifizierung der Ursache der Sicherheitslcke.
Die Durchfhrung der hier beschriebenen Kontrollen auf der Ebene von
Clients sollte nur dann durchgefhrt werden, wenn sichergestellt ist, dass
damit keine unzulssigen Leistungskontrollen der Benutzer dieser Clients
verbunden sind und wenn die datenschutzrechtlich korrekte Behandlung der
Protokoll-Informationen gewhrleistet werden kann.
- Werden Unregelmigkeiten dem Netzadministrator bekanntgegeben?
- Werden Abweichungen der Sicherheitseinstellungen vom zulssigen Wert
unverzglich korrigiert?
- Werden die mglichen Konsequenzen solcher Abweichungen analysiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.93 Planung des Windows NT Netzes

Windows NT kann in einem Netz in verschiedenen Konfigurationen einge-
setzt werden. Um die Vor- und Nachteile der einzelnen Einsatzarten
abschtzen und nachvollziehen zu knnen, muss zunchst kurz auf das Sicher-
heitssystem von Windows NT eingegangen werden. Grundstzlich behlt das
Betriebssystem die Kontrolle ber alle Ressourcen. Ein Benutzer kann nur
dann auf Ressourcen zugreifen, wenn er die dazu notwendigen Rechte und
Berechtigungen hat. Der Zugang zum System ist nur ber ein gltiges
Benutzerkonto mglich, das mittels Passwort geschtzt werden kann. Durch
die Sicherheitskontenverwaltung (SAM - Security Account Manager) werden
die Informationen ber Benutzer- und Gruppenkonten in der Security Account
Database, die hufig auch als SAM-Datenbank bezeichnet wird, verwaltet.
Das Betriebssystem generiert bei der Anmeldung eines Benutzers fr diesen
unter Bercksichtigung der Eintragungen in der SAM-Datenbank ein Access-
Token. Der Sicherheitskontrollmonitor (Security Reference Monitor) ber-
prft anhand dieses Tokens, ob der Benutzer die Berechtigung hat, auf
bestimmte Objekte zuzugreifen, und ob er das Recht hat, die angeforderten
Aktionen durchzufhren (beispielsweise eine Datei lschen oder das System
herunterfahren).
Windows NT untersttzt die Arbeit im Netz mit folgenden Konzepten:
1. Arbeitsgruppen
Rechner knnen zu Arbeitsgruppen zusammengefasst werden und im Rahmen
des Peer-to-Peer Konzeptes ber das Netz Ressourcen gemeinsam nutzen
(siehe dazu auch Kapitel 6.3 Peer-to-Peer-Dienste).
Jeder Rechner in einem solchen Netz kann gleichzeitig sowohl als Server als
auch als Workstation benutzt werden. Realisiert wird dies durch Freigabe von
Ressourcen auf den einzelnen Rechnern. Jede Windows NT Workstation, die
in einer Arbeitsgruppe eingesetzt wird, verwaltet ihre eigene SAM-Datenbank
und damit auch eigene Benutzer- und Gruppenkonten. Die Eintragungen in
dieser Datenbank knnen von keinem anderen Rechner der Arbeitsgruppe
benutzt werden. Dies hat zur Folge, dass eine zentrale Administration nicht
mglich ist. Fr den Zugriff auf freigegebene Ressourcen wird in der Regel
ein Passwort bentigt.
Besonders nachteilig wirkt sich bei diesem Konzept aus, dass keine ausrei-
chende Kontrolle ber die Rechte der einzelnen Benutzer mglich ist. Die
Einrichtung von Arbeitsgruppen sollte daher mglichst vermieden werden.
2. Netz mit dediziertem Server
Hierbei handelt es sich um ein Netz mit Client-Server-Struktur. Es wird dabei
festgelegt, welche Rechner als Server und welche Rechner als Clients fungie-
ren. Server knnen Verzeichnisse und/oder Drucker freigeben bzw. Anwen-
dungen wie z. B. Mail, Schedule+, Fax global zur Verfgung stellen. Clients
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
knnen hingegen nur die von Servern zur Verfgung gestellten Ressourcen
nutzen.
Ein NT-Rechner kann mit dem Betriebssystem "Windows NT Server" oder
"Windows NT Workstation" betrieben werden. In kleinen Netzen kann auch
eine Lizenzversion "Windows NT Workstation" als Server betrieben werden.
Zu beachten ist aber, dass sich aufgrund der lizenzrechtlichen Einschrnkung
nicht mehr als 10 Benutzer gleichzeitig ber das Netz auf diesem Rechner
anmelden drfen. Reicht dies nicht aus, muss Windows NT Server installiert
werden. Auf Servern unter dem Betriebssystem Windows NT sollten generell
keine normalen Benutzer arbeiten. Die Clients mssen nicht zwingend unter
Windows NT betrieben werden.
Der Vorteil dieses Konzeptes liegt in der Zentralisierung der Datenhaltung
und -verwaltung. Sofern in einem solchen Netz nur ein Server zum Einsatz
kommt, ist fr die Arbeit im Netz auch nur auf diesem Rechner je Benutzer
ein Konto anzulegen. Fr die Benutzung von Ressourcen oder Diensten des
Servers ber das Netz ist lediglich die Anmeldung des Benutzers an diesem
einen Rechner notwendig. Fr kleinere Netze kann der Einsatz dieses Konzep-
tes durchaus wirtschaftlich sinnvoll sein.
Sofern jedoch die Kapazitt eines Servers nicht mehr ausreicht, um den
jeweiligen Anforderungen hinsichtlich Geschwindigkeit und Plattenspeicher-
platz zu gengen, nimmt der Verwaltungsaufwand erheblich zu, wenn ein oder
mehrere Server dem Netz hinzugefgt werden. Sollen alle Benutzer das Recht
erhalten, auf alle Server ber das Netz zuzugreifen, mssen die
Benutzerkonten auf jedem einzelnen Server eingerichtet und gepflegt werden.
3. Domnen-Konzept
Eine Domne unter Windows NT ist eine Gruppe von Rechnern, die ber eine
gemeinsame Sicherheits- und Benutzerkontendatenbank (SAM-Datenbank)
verfgt. Fr den Benutzer bedeutet dies, dass er sich nur einmal an der
Domne anmelden muss. Danach stehen ihm smtliche fr ihn freigegebene
Ressourcen zur Verfgung, unabhngig davon, auf welchem Server sich diese
befinden.
Ein Server der Domne unter dem Betriebssystem Windows NT Server dient
als primrer Domnencontroller (PDC). Daneben kann die Domne einen oder
mehrere Backup Domnencontroller (BDC), Mitgliedsserver, d. h. Server
ohne Domnencontrollerfunktionalitt (siehe auch weiter unten) und Windows
NT Workstations enthalten. Auerdem knnen zu einer Domne
Arbeitsstationen mit anderen Betriebssystemen wie z. B. Windows fr Work-
groups, Windows 95 oder MS-DOS gehren.
Die Entscheidung, ob ein Server als primrer Domnencontroller, als Backup
Domnencontroller oder als Mitgliedsserver fungieren soll, muss vor der
Installation getroffen werden, da spter eine nderung ohne Neuinstallation
nicht mehr mglich ist. Zum besseren Verstndnis soll zunchst nher auf die
verschiedenen Serverarten einer Domne eingegangen werden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
a) Primrer Domnencontroller (PDC)

Ein Server einer Windows NT Domne muss zwingend als primrer
Domnencontroller eingerichtet werden. Der Einsatz des Betriebssystems
Windows NT Server ist zwingend, da die Workstation-Version diese Funktio-
nalitt nicht enthlt. Auf dem PDC wird die zentrale Benutzerkontendaten-
bank (SAM-Datenbank) fr die Domne verwaltet. Alle nderungen knnen
nur an dieser Datenbank mit Hilfe des Benutzermanagers fr Domnen
durchgefhrt werden. Auerdem werden die Benutzeranmeldungen vom
primren Domnencontroller bearbeitet.
b) Backup Domnencontroller (BDC)
Andere Server der Domne knnen als Backup Domnencontroller eingerich-
tet werden. Auch hier ist der Einsatz des Betriebssystems Windows NT Server
zwingend. Auf jeden Backup Domnencontroller wird automatisch eine Read-
only-Kopie der Benutzerdatenbank der Domne repliziert. Die
Synchronisation erfolgt regelmig. Auch Backup Domnencontroller knnen
Benutzeranmeldungen fr die Domne bearbeiten. Dadurch ist es gerade bei
einer groen Anzahl von Benutzern mglich, die durch die Benutzeran-
meldungen entstehende Last auf mehrere Server zu verteilen.
Jede Domne sollte mglichst ber mindestens einen Backup Domnen-
controller verfgen, um die Verwaltung der Domne bei Ausfall des primren
Domnencontrollers sicherzustellen. In einem solchen Fall ist es mglich, den
Backup Domnencontroller zum primren Domnencontroller hochzustufen.
Sofern kein Backup Domnencontroller eingerichtet wurde, kann einer
Domne durch Neuinstallation kein neuer primrer Domnencontroller hinzu-
gefgt werden.
Wenn die Server der Domne auf verschiedene ber WAN-Verbindungen
zusammengeschaltete Liegenschaften verteilt sind, sollte in jeder Liegenschaft
wenigstens ein Backup Domnencontroller installiert sein.
c) Mitgliedsserver (Memberserver)
Hierbei handelt es sich um Server, die weder als primrer noch als Backup
Domnencontroller eingerichtet wurden. Diese Server verfgen ber keine
Kopien der Benutzerkontendatenbank der Domne. Die Benutzeranmeldung
fr die Domne kann von einem solchen Server daher nicht bearbeitet werden.
Folgende Grnde sprechen dafr, einen Server als Mitgliedsserver in die
Domne einzufgen:
- Ein Server hat zeitkritische Aufgaben durchzufhren oder es mssen auf
diesem Rechner umfangreiche Applikationen ausgefhrt werden, so dass
der Aufwand von Benutzeranmeldungen nicht akzeptabel ist.
- Ein Server soll in naher Zukunft in eine andere Domne eingefgt werden.
Dies ist dann einfacher mglich, als wenn er als Backup
Domnencontroller konfiguriert wre.
Wesentlicher Ansatz des Domnenkonzeptes ist es, dass alle Benutzerkonten
fr jede Domne nur einmal definiert werden mssen. Die Verwaltung erfolgt
in der zentralen Benutzerdatenbank auf dem primren Domnencontroller.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr die Benutzer bedeutet dies, dass sie sich bei der Benutzeranmeldung nur
gegenber dieser Datenbank authentisieren mssen. Danach knnen sie auf
alle Objekte und Ressourcen der Domne zugreifen, sofern sie die ent-
sprechenden Berechtigungen besitzen. Dabei spielt keine Rolle, auf welchem
Server sich diese Objekte und Ressourcen befinden. Arbeitet der Benutzer auf
einem Rechner unter dem Betriebssystem Windows NT Workstation, gengt
die Benutzeranmeldung gegenber der zentralen Benutzerdatenbank, um auch
auf diesen Rechner Zugang zu erhalten.
Organisation von Domnen
Innerhalb eines Netzes knnen mehrere Domnen eingerichtet werden; jede
muss dabei aber ber einen eindeutigen Namen verfgen. Jede Domne ver-
waltet ihre eigene zentrale SAM-Datenbank. Die jeweiligen Benutzer- und
Gruppenkonten sind daher auch nur in der Domne gltig, in der sie definiert
wurden.
Es kann aber innerhalb eines Netzes die Notwendigkeit bestehen, dass
Benutzer einer Domne auf Ressourcen einer anderen Domne zugreifen
mssen. Hierzu gibt es den Mechanismus der Vertrauensbeziehungen
zwischen Domnen.
Dabei unterscheidet man zwischen vertrauten Domnen (Trusted Domains)
und vertrauenden Domnen (Trusting Domains). Den Benutzerkonten und
globalen Gruppen der vertrauten Domne knnen in der vertrauenden Domne
Rechte und Berechtigungen zugewiesen werden, wodurch auch der Zugriff auf
freigegebene Ressourcen mglich wird.
Es sind folgende Domnen-Modelle mglich:
a) Single-Domnen-Modell
Dies ist das einfachste Domnen-Modell, da in einem Netz hierbei nur eine
einzige Domne existiert. Daher besteht nicht die Notwendigkeit, Vertrauens-
beziehungen zu verwalten. Im gesamten Netz existiert hierbei nur eine einzige
SAM-Datenbank, ber die die Verwaltung erfolgt. Eine Abwandlung dieses
Modells liegt vor, wenn in einem Netz mehrere Einzeldomnen eingerichtet
wurden, zwischen denen keine Vertrauensbeziehungen definiert wurden.
Hierbei verwaltet jede Domne ihre eigene SAM-Datenbank und ihre eigenen
Benutzer- und Gruppenkonten. Das Single-Domnen-Modell eignet sich
besonders gut fr Netze mit wenigen Benutzern (ca. 200 bis 300) und wenigen
Computerkonten. Nachteilig ist bei diesem Modell, dass die Performance bei
steigender Benutzer- und Gruppenanzahl abnimmt. Auerdem ist eine
Gruppierung der Ressourcen nach Organisationseinheiten in dem Sinne, dass
ein Server z. B. fr eine Abteilung reserviert ist, nicht mglich.
b) Master-Domnen-Modell
Kennzeichen dieses Modells ist, dass ein Netz in mehrere Domnen eingeteilt
wird, wobei eine Domne zentral alle Benutzer- und Gruppenkonten verwal-
tet. Diese Domne wird Master-Domne genannt. In den anderen Domnen
werden die Ressourcen zusammengefasst. Die Ressourcen-Domnen
vertrauen dabei der Domne mit den Benutzerkonten. Folgende Abbildung
zeigt das Master-Domnen-Modell:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Dieses Domnen-Modell lsst sich nach Angaben von Microsoft bis zu einer
Zahl von ca. 15.000 Benutzern einsetzen. Besonders geeignet ist dieses
Modell, wenn eine Organisation aus mehreren Abteilungen besteht und alle
Abteilungen ihre eigenen Ressourcen verwalten sollen, wobei die Benutzer-
administration zentral erfolgt. Es ist bei diesem Domnen-Modell mglich, fr
die Administration der Ressourcen-Domnen jeweils einen eigenen
Administrator zu benennen. Auerdem ist ein zentrales Sicherheitsmanage-
ment mglich.
c) Multiple-Master-Domnen
Dieses Modell besteht aus mehreren Master-Domnen, die sich gegenseitig
vertrauen. Die Benutzer- und Gruppenkonten werden in diesen Master-
Domnen gefhrt. Darber hinaus existieren Ressourcen-Domnen, die
einseitig allen Master-Domnen vertrauen. Die folgende Abbildung zeigt das
Modell der Multiple-Master-Domnen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die explizite Vertrauensbeziehung zwischen Domne 1 und Domne 3 ist

ntig, da Vertrauensstellungen nicht transitiv sind; d. h. vertrauen sich
Domne 1 und Domne 2 sowie Domne 2 und Domne 3 gegenseitig, folgt
nicht daraus, dass sich auch Domne 1 und 3 gegenseitig vertrauen.
Multiple-Master-Domnen-Konzepte kommen hufig zum Einsatz, wenn die
Benutzerzahl grer als 15.000 ist. Auerdem lsst es dieses Konzept zu, ein
Netz nach Hauptabteilungen aufzuteilen und die Ressourcen durch die einzel-
nen Abteilungen verwalten zu lassen. Dazu wird je Hauptabteilung eine
Master-Domne eingerichtet. Die Benutzer einer Hauptabteilung erhalten ihre
Benutzerkonten in der Master-Domne. Die Ressourcen werden durch die
Abteilungen in den Ressourcen-Domnen verwaltet. Auch ist es mglich, ein
Netz nach Standorten zu organisieren. Hierbei wird fr jeden Standort eine
Master-Domne und fr jede Abteilung eine Ressourcen-Domne eingerichtet.
Dieses Domnen-Modell ist skalierbar, wobei die Gre einer Organisation
keine Grenze setzt. Es besteht die Mglichkeit eines zentralen Sicher-
heitsmanagements, und globale Gruppen und Benutzerkonten brauchen
organisationsweit nur einmal eingerichtet zu werden.
Es sei abschlieend darauf hingewiesen, dass dieses Modell groe Disziplin
bei der Administration und sorgfltige Planung bentigt. Besondere Sorgfalt
ist auf die Definition der Vertrauensbeziehungen zu legen. Auerdem muss
zwingend verhindert werden, dass in den Ressourcen-Domnen Benutzer-
konten eingerichtet werden.
d) Complete-Trust-Modell (Vertrauensverbund)
Bei diesem Modell bestehen gegenseitige Vertrauensbeziehungen zwischen
allen Domnen eines Netzes. In jeder Domne werden sowohl Ressourcen als
auch Benutzer- und Gruppenkonten verwaltet. Ein Complete-Trust-Modell ist
in folgender Abbildung dargestellt:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei diesem Modell ist es mglich, den Abteilungen einer Organisation sowohl
die Verwaltung der Benutzerkonten als auch die Verwaltung der Ressourcen
zu berlassen. Es wird keine zentrale Abteilung zur Verwaltung bentigt. Das
Modell ist mit jeder Anzahl von Benutzern skalierbar. Dieses Modell hat aber
auch erhebliche Nachteile. So ist die Kontrolle, ob die Sicherheitspolitik ein-
gehalten wird, schwierig. Dies erschwert es, ein zentrales Sicherheits-
management aufzubauen. Auerdem ist es schwierig, die Ttigkeit der einzel-
nen Administratoren zu koordinieren. Wenn ein Netz sehr viele Domnen
umfasst, sind sehr viele Vertrauensbeziehungen zu verwalten, was letztlich
unbersichtlich ist.
Es knnen keine globalen Aussagen dazu gemacht werden, welches der
beschriebenen Domnen-Modelle in einer Organisation Anwendung finden
sollte. Dies kann nur in Abhngigkeit von der physischen und logischen
Netzstruktur sowie der Verteilung von Daten, Anwendungen und Benutzern
im Netz spezifisch festgelegt werden. Die Bestimmung der optimalen
Domnenstruktur bedarf daher einer detaillierten Analyse, die fr umfang-
reiche Netze aufwendig werden kann und ggf. durch Planungssoftware zu
untersttzen ist.
- Ist die gewhlte Netzstruktur einschlielich eventueller Vertrauens-
beziehungen zwischen Domnen dokumentiert?
- Wird sie an Vernderungen im Einsatzumfeld angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.94 Freigabe von Verzeichnissen unter Windows NT

Unter Windows NT werden verschiedene Ebenen der Zugriffskontrolle auf
Ressourcen unterschieden. Es gibt Zugriffsberechtigungen auf Freigabeebene
und auf Verzeichnis- und Dateiebene (sog. NTFS-Berechtigungen). Die
Zugriffsberechtigungen auf Verzeichnis- und Dateiebene stehen nur auf
Datentrgern mit NTFS-Dateisystem zur Verfgung und werden ausfhrlich
in M 4.53 Restriktive Vergabe von Zugriffsrechten auf Dateien und
Verzeichnisse unter Windows NT behandelt.
Die Freigabe von Verzeichnissen auf Servern ist notwendig, um Benutzern
den Zugriff ber das Netz auf diese Ressourcen zu ermglichen. Ohne die
Einrichtung einer entsprechenden Freigabe ist ein Netzzugriff auf ein
Verzeichnis nicht mglich. Dies gilt selbst dann, wenn entsprechende NTFS-
Berechtigungen vergeben wurden.
Es ist auf allen Rechnern unter dem Betriebssystem Windows NT, d. h.
sowohl auf Domnencontrollern als auch auf Servern und Workstations
(Clients) mglich, Verzeichnisse freizugeben. blicherweise sollten
Verzeichnisse aber nur auf Domnencontrollern und Servern freigegeben
werden. Verzeichnisfreigaben bzw. die Freigabe einzelner Laufwerke auf
Workstations (Clients) erfolgen im Rahmen der Peer-to-Peer-Funktionalitt
(siehe M 5.37 Einschrnken der Peer-to-Peer-Funktionalitten in einem
servergesttzten Netz) und sollten die absolute Ausnahme bleiben, da dies zu
unberschaubaren Rechtestrukturen und ggf. sogar zum Unterlaufen der
allgemeinen Sicherheitsvorgaben fhren kann.
Ein Verzeichnis kann unter dem Betriebssystem Windows NT u. a. mit dem
"Windows NT Explorer", ber das Desktop-Symbol "Arbeitsplatz" oder mit
dem Kommando "NET SHARE" freigegeben werden. Die Freigabe eines
Verzeichnisses bezeichnet man auch als Einrichtung eines Shares. Im
Windows NT Explorer oder im Desktop-Symbol "Arbeitsplatz" erfolgt die
Freigabe eines Verzeichnisses ber die Karte "Freigabe". Sie ist ber den
Menpunkt "Eigenschaften" des Kontextmens erreichbar. Die Freigabe wird
eingerichtet, indem die Option "Freigegeben als" angeklickt wird. Danach
kann ein Freigabename mit einer maximalen Lnge von 12 Zeichen einge-
geben werden. Standardmig vergibt Windows NT den Namen des
Verzeichnisses als Freigabenamen. Zur Erleichterung der Administration kann
in dem Feld "Kommentar" eine kurze, prgnante Beschreibung zu der
Freigabe eingegeben werden. Unter der Option "Benutzerbegrenzung" kann
angegeben werden, wie viele Benutzer gleichzeitig auf die Freigabe zugreifen
drfen. Die standardmige Einstellung ist "Maximum erlaubt", d. h. die
Anzahl ist nicht limitiert, und sollte beibehalten werden. Zur Lizenzkontrolle
ist dieses Merkmal nur bedingt geeignet, da nur die Anzahl von Clients
gezhlt wird, die sich mit der Freigabe verbunden haben. Den Benutzern, die
ber das Netz auf diese Freigabe zugreifen sollen, muss eine entsprechende
Freigabeberechtigung erteilt werden. Dies erfolgt ber die Zugriffs-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
kontrolliste, die nach Wahl des Feldes "Berechtigungen" durch das System
geffnet wird. Das Symbol des freigegebenen Verzeichnisses wird im
"Windows NT Explorer" oder im Desktop-Symbol "Arbeitsplatz" mit einer
Hand unterlegt, um anzuzeigen, dass es freigegeben wurde.
Das Recht, Verzeichnisse freizugeben sowie die Freigabeberechtigungen zu
verwalten, haben nur Mitglieder der Gruppen "Administratoren" und "Server-
Operatoren" auf Domnencontrollern bzw. Mitglieder der Gruppen
"Administratoren" und "Hauptbenutzer" auf Windows NT-Workstations und
Mitgliedsservern.
Unter Windows NT gibt es folgende Freigabeberechtigungen: "Kein Zugriff",
"Lesen", "ndern" und "Vollzugriff". Die Aktionen, die die einzelnen Frei-
gabeberechtigungen ermglichen, ergeben sich aus folgender Tabelle:
Kein Lesen ndern Voll-

Zugriff zugriff
Anzeigen von Unterverzeichnissen X X X
und Dateinamen
Anzeigen von Dateiinhalt und X X X
Dateiattributen
Programm ausfhren X X X
Wechsel in ein Unterverzeichnis X X X
Einrichten von Unterverzeichnissen X X
und Hinzufgen von Dateien
ndern der Dateiattribute X X
Lschen von Unterverzeichnissen X X
und Dateien
Zugriffsberechtigungen ndern (hat X
nur fr Verzeichnisse Relevanz, die
sich auf NTFS-Datentrgern
befinden)
Besitzbernahme (hat nur fr Ver- X
zeichnisse Relevanz, die sich auf
NTFS-Datentrgern befinden)
Freigaben knnen nur fr Verzeichnisse, nicht aber fr Dateien definiert
werden. Freigabeberechtigungen gelten nur fr Zugriffe ber das Netz, d. h.
sie haben keine Bedeutung fr Benutzer, die lokal an dem Rechner arbeiten
drfen, auf dem ein Verzeichnis freigegeben wurde. Auerdem gelten Frei-
gabeberechtigungen nur in einheitlicher Form fr alle Dateien und Unter-
verzeichnisse eines freigegebenen Verzeichnisses. Zwar ist es mglich, inner-
halb eines freigegebenen Verzeichnisses auch ein Unterverzeichnis freizu-
geben und dabei auch abweichende Freigabeberechtigungen einzustellen, dies
ist dann jedoch eine neue Freigabe mit folgenden Konsequenzen: Verbindet
sich der Benutzer mit dem freigegebenen Verzeichnis, so gelten fr ihn die
dort festgelegten Freigabeberechtigungen fr alle Dateien und Unter-
verzeichnisse. Daran ndert sich auch nichts, wenn ein Unterverzeichnis
gesondert freigegeben wurde. Verbindet sich der Benutzer hingegen direkt mit
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
dem Unterverzeichnis, so gelten die dort eingerichteten Freigabeberechti-

gungen.
Beispiel: Gegeben sei folgende Verzeichnisstruktur:
D:\ABTEILUNG\REFERAT. Eine Freigabe auf das Verzeichnis ABTEILUNG
mit Berechtigung "Vollzugriff" und eine weitere Freigabe auf das Unter-
verzeichnis REFERAT mit Berechtigung "Lesen" werden eingerichtet.
Verbindet sich der Benutzer mit dem Verzeichnis D:\ABTEILUNG, so kann er
sowohl Dateien in diesem Verzeichnis, als auch Dateien im Unterverzeichnis
D:\ABTEILUNG\REFERAT u. a. lesen, schreiben und lschen. Verbindet sich
der Benutzer hingegen direkt mit dem Verzeichnis
D:\ABTEILUNG\REFERAT, so kann er die in diesem Verzeichnis stehenden
Verzeichnisse nur lesen. Sofern wie im vorstehenden Beispiel Restriktionen
auf ein Unterverzeichnis gewnscht werden, kann dies nicht durch Freigabe-
berechtigungen sondern nur ber die sog. NTFS-Berechtigungen erreicht
werden (siehe M 4.53 Restriktive Vergabe von Zugriffsrechten auf Dateien
und Verzeichnisse unter Windows NT).
Wird ein Verzeichnis freigegeben, das sich auf einem NTFS-Datentrger
befindet, gelten neben der Freigabeberechtigung auch die NTFS-Berechti-
gungen auf dieses Verzeichnis und die enthaltenen Dateien und Unter-
verzeichnisse. Dabei gilt die jeweils restriktivere Berechtigung. Besitzt ein
Benutzer beispielsweise die Freigabeberechtigung "Lesen" fr das freige-
gebene Verzeichnis, andererseits aber nur die NTFS-Berechtigung "Anzeigen"
fr dieses Verzeichnis, so ist sein Zugriffsrecht auf "Anzeigen" beschrnkt.
ber die NTFS-Berechtigung ist es daher mglich, Zugriffsrechte individuell
auch auf Dateien und Unterverzeichnisse zu vergeben (nheres siehe M 4.53
Restriktive Vergabe von Zugriffsrechten auf Dateien und Verzeichnisse unter
Windows NT).
Freigabeberechtigungen durch Gruppenzugehrigkeiten sind kumulativ, d. h.
ist ein Benutzer Mitglied in verschiedenen Gruppen, denen unterschiedliche
Freigabeberechtigungen auf ein Verzeichnis eingerumt wurden, so gilt fr
diesen Benutzer die weitestgehende Berechtigung. Von dieser Regel gibt es
allerdings eine Ausnahme: Die Freigabeberechtigung "Kein Zugriff" domi-
niert alle anderen Freigabeberechtigungen.
Beispiel: Gegeben sei die Freigabe D:\ERGEBNISSE. Benutzer Meyer ist
Mitglied der Gruppe A und der Gruppe B. Die Gruppe A erhlt die Berech-
tigung "Lesen", die Gruppe B die Berechtigung "Vollzugriff" auf die o. g.
Freigabe. In diesem Fall ist fr den Benutzer Meyer die Freigabeberechtigung
"Vollzugriff" magebend. Nimmt man den Benutzer Meyer noch in der
Gruppe C auf, fr die auf die Freigabe D:\ERGEBNISSE die Freigabeberech-
tigung "Kein Zugriff" vergeben wurde, so ist es dem Benutzer Meyer ver-
wehrt, Zugriff ber das Netz auf dieses Verzeichnis zu nehmen. Ist dies nicht
gewnscht, kann der Administrator nur berprfen, welchen Gruppen auf die
Ressource die Freigabeberechtigung "Kein Zugriff" erteilt wurde und in
welcher dieser Gruppen der betroffene Benutzer Mitglied ist. Der Benutzer ist
dann aus der entsprechenden Gruppe zu entfernen.
Weiterhin ist zu beachten, dass Windows NT grundstzlich die Wurzel-
verzeichnisse aller Platten sowie das Windows-Verzeichnis %SystemRoot%
(in der Regel C:\WINNT) fr administrative Zugriffe freigibt. Die Zugriffs-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
rechte auf diese speziellen Freigaben sind nicht vernderbar und auf die
Benutzergruppe "Administratoren" eingeschrnkt. Diese Freigaben sind nicht
direkt sichtbar, da sie Freigabenamen der Form "Plattenname$", also z.B.
"C$" bzw. den Namen "ADMIN$" haben.
Dadurch besteht die Gefahr, dass
- jemand Administratorkennung und Passwort ausprobieren kann oder
- ein Administrator jederzeit unbemerkt auf Benutzerrechner zugreifen kann.
Falls diese Eigenschaft zur Erleichterung der Workstation-Betreuung
gewnscht ist, ist zu berlegen, ob ein Administrator fr alle von ihm betreu-
ten Workstations dasselbe Administrator-Passwort verwenden soll. Dies lsst
sich zwar leichter merken, fhrt aber dazu, dass ein Angreifer auf alle Work-
stations zugreifen kann, wenn er dieses eine Passwort herausgefunden hat.
Falls diese Zugriffsmglichkeiten nicht gewnscht sind, z. B. weil der
Administrator nicht auf lokale Benutzerdaten zugreifen knnen soll, sollte
ber den Benutzer-Manager, unter Richtlinien - Benutzerrechte das Recht
"Zugriff auf diesen Computer vom Netz" fr Administratoren gesperrt
werden.
Windows NT vergibt bei jeder Freigabe standardmig die Freigabeberechti-
gung "Vollzugriff" fr die Gruppe "Jeder". Dies ist insbesondere fr
Verzeichnisse, die sich auf Datentrgern ohne NTFS-Dateisystem befinden,
nicht akzeptabel, da es hier auer den Freigabeberechtigungen keine andere
Mglichkeit der Vergabe von Rechten und damit der Zugriffskontrolle gibt.
Die Gruppe "Jeder" muss daher aus der Zugriffskontrolliste entfernt und durch
die Gruppen und ggf. einzelnen Benutzer ersetzt werden, die auf das freige-
gebene Verzeichnis Zugriff nehmen sollen. Dabei sind dann auch entspre-
chende Freigabeberechtigungen zu vergeben.
Auch bei Verzeichnissen, die sich auf NTFS-Datentrgern befinden, sollte im
Falle der Freigabe die Gruppe "Jeder" aus der Zugriffskontrolliste entfernt
werden. Denkbar ist hier aber die Aufnahme der Gruppe "Benutzer" mit der
Vergabe der Zugriffsberechtigung "Vollzugriff". Die individuelle Vergabe
von Zugriffsberechtigungen auf das Verzeichnis bzw. auf enthaltene Dateien
und Unterverzeichnisse erfolgt dann auf der Ebene der NTFS-Berechtigungen
(siehe M 4.53 Restriktive Vergabe von Zugriffsrechten auf Dateien und
Verzeichnisse unter Windows NT).
- Ist dokumentiert, welche Verzeichnisse auf welchen Rechnern fr den
Netzzugriff freigegeben sind?
- Ist die Gruppe "Jeder" in den freigegebenen Verzeichnissen, die sich auf
Datentrgern ohne NTFS-Dateisystem befinden, entfernt und durch die
Gruppen und ggf. einzelnen Benutzer, die auf das jeweilige freigegebene
Verzeichnis ber das Netz zugreifen drfen, ersetzt worden?
- Werden die vorhandenen Freigaben an Vernderungen im Einsatzumfeld
angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.95 Beschaffung geeigneter Schutzschrnke

Schutzschrnke knnen ihren Inhalt gegen die Einwirkung von Feuer bzw.
gegen unbefugten Zugriff schtzen. Je nach angestrebter Schutzwirkung sind
bei der Auswahl geeigneter Schutzschrnke folgende Hinweise zu beachten:
- Schutz gegen Feuereinwirkung:
Bei Schutzschrnken unterscheidet man bezglich Schutz gegen Feuer-
einwirkung die Gteklassen S60 und S120 nach VDMA 24991 Teil 1. In
diesen Gteklassen werden die Schutzschrnke darauf geprft, ob in ihnen
bis zu einer Beflammungszeit von 60 bzw. 120 Minuten whrend eines
normierten Testes fr die geschtzten Datentrger vertrgliche
Temperaturen erhalten bleiben. Durch Zustze in der Klassifizierung
werden die zu schtzenden Datentrger bezeichnet. Die Krzel bedeuten
im einzelnen:
P = Papier aller Art
D = Datentrger (z. B. Magnetbnder, Filme)
DIS = Disketten, Magnetbandkassetten einschlielich aller anderen
Datentrger.
Die Unterschiede zwischen den Klassen liegen in der Isolationsleistung,
die bei DIS-Schrnken am hchsten ist.
Fr den IT-Grundschutz sollten bei Schutz gegen Feuer Schutzschrnke
der Gteklasse aS60 ausreichend sein. Zu beachten bleibt, dass Server-
schrnke damit einen Schutz gegen Feuer fr einen gewissen Zeitraum
bieten, so dass Datentrger nicht zerstrt werden, jedoch ist im Brandfall
davon auszugehen, dass der Betrieb des Servers nicht aufrechterhalten
werden kann.
Bei Schutzschrnken, die zum Schutz vor Feuer und Rauch dienen, sollte
eine Vorrichtung zum automatischen Schlieen der Tren im Brandfall
vorgesehen werden. Die Schlieung sollte lokal durch Rauchgasmelder
und/oder extern durch ein Signal einer Brandmeldeanlage (soweit vor-
handen) ausgelst werden knnen.
- Schutz gegen unbefugten Zugriff:
Der Schutzwert gegen unbefugten Zugriff wird neben der mechanischen
Festigkeit des Schutzschrankes entscheidend durch die Gte des Schlosses
beeinflusst. Fr den IT-Grundschutz sollten Wertschrnke nach RAL-RG
627 geeignet sein.
Sind Zugriffsschutz und Brandschutz in Kombination erforderlich, so
knnen Datensicherungsschrnke nach RAL-RG 626/9 verwendet werden.
Weitere relevante Normen und Informationen sind VDMA 24992 fr Stahl-
schrnke und RAL-RG 627 fr Wertschrnke. Hilfestellung bei der Be-
wertung des Widerstandswertes verschiedener Schutzschrnke gibt das
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
VDMA-Einheitsblatt 24990, in dem Sicherheitsmerkmale von Schutz-

schrnken kurz beschrieben werden.
Bei der Auswahl von Schutzschrnken ist auch die zulssige Deckenbelastung
am Aufstellungsort zu bercksichtigen.
Nach diesen Auswahlkriterien fr den Schutzwert des Schutzschrankes ist als
nchstes die Ausstattung des Schrankes bedarfsgerecht festzulegen. Dazu
sollte vor der Beschaffung eines Schutzschrankes festgelegt werden, welche
Gerte bzw. welche Arten von Datentrgern in ihm aufbewahrt werden sollen.
Die Innenausstattung des Schutzschrankes ist dieser Festlegung angemessen
auszuwhlen. Nachrstungen sind in der Regel schwierig, da der Schutzwert
des Schrankes und seine spezifische Zulassung beeintrchtigt werden knnen.
Es sollte auch Raum fr zuknftige Erweiterungen mit eingeplant werden.
In Serverschrnken sollte auer fr den Server und eine Tastatur auch Platz
fr einen Bildschirm und weitere Peripheriegerte wie z. B. Bandlaufwerke
vorgesehen werden, damit Administrationsarbeiten vor Ort durchgefhrt
werden knnen. Dazu ist zu beachten, dass die Ausstattung ergonomisch
gewhlt ist, damit Administrationsarbeiten am Server ungehindert durchge-
fhrt werden knnen. So ist zum Beispiel ein ausziehbarer Boden fr die
Tastatur wnschenswert, der in einer Hhe angebracht wird, dass der
Administrator seine Arbeiten sitzend durchfhren kann. Je nach Nutzung des
Schrankes knnen auch eine Klimatisierung und/oder eine USV-Versorgung
erforderlich sein. Die entsprechenden Gerte sollten dann im Schrank mit
untergebracht werden. Andernfalls muss zumindest eine Lftung vorhanden
sein. Die Ausstattung des Schrankes mit einem lokal arbeitenden Brand-
frherkennungssystem, das im Brandfall die Stromzufuhr der Gerte unter-
bricht (auf der Eingangs- und der Ausgangsseite der USV, sofern diese vor-
handen ist), ist empfehlenswert.
Nicht im gleichen Schrank untergebracht werden sollten Backup-Datentrger
und Protokolldrucker. Backup-Datentrger wrden im Falle einer
Beschdigung des Servers vermutlich ebenfalls beschdigt. Die
Protokollierung der Aktionen am Server dient auch zur Kontrolle des
Administrators. Es ist also nicht sinnvoll, ihm, ggf. sogar als Einzigem,
Zugriff auf die Protokollausdrucke zu gewhren.
- Welche Schutzfunktionen soll der Schrank erfllen?
- Werden diese durch den ausgewhlten Schrank erfllt?
- Welcher der genannten Gteklassen entspricht der Schutzschrank?
- Ist die Konsole des Servers nur fr den Administrator zugnglich?
- Ist der Schutzschrank ausreichend dimensioniert?
- Wurden unautorisierte nderungen am Schutzschrank durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.96 Verschluss von Schutzschrnken

Generell sind Schutzschrnke bei Nichtbenutzung zu verschlieen. Werden
Arbeiten, die ein ffnen des Schutzschrankes erfordern, unterbrochen, so ist
auch bei kurzfristigem Verlassen des Raumes der Schutzschrank zu verschlie-
en. Bei Verwendung von Codeschlssern sind diese jedesmal zu verwerfen.
- Wird sporadisch berprft, dass unbenutzte Schutzschrnke verschlossen
sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.97 Korrekter Umgang mit Codeschlsser

Werden Schutzschrnke mit mechanischen oder elektronischen Code-
schlssern verwendet, so muss der Code fr diese Schlsser gendert werden:
- nach der Beschaffung,
- bei Wechsel des Benutzers,
- nach ffnung in Abwesenheit des Benutzers,
- wenn der Verdacht besteht, dass der Code einem Unbefugten bekannt
wurde und
- mindestens einmal alle zwlf Monate.
Der Code darf nicht aus leicht zu ermittelnden Zahlen (z. B. persnliche
Daten, arithmetische Reihen) bestehen.
Die jeweils gltigen Codes von Codeschlssern sind aufzuzeichnen und gesi-
chert zu hinterlegen (vgl. M 2.22 Hinterlegen des Passwortes in analoger
Anwendung). Zu beachten ist, dass eine Hinterlegung im zugehrigen Schutz-
schrank sinnlos ist.
Wenn der Schutzschrank neben einem Codeschloss ein weiteres Schloss
besitzt, so ist abzuwgen, ob Code und Schlssel gemeinsam hinterlegt
werden, was im Notfall einen schnelleren Zugriff erlauben wrde, oder
getrennt hinterlegt werden, so dass es fr einen Angreifer schwieriger ist, sich
Zugriff zu verschaffen.
- Wird der Schlosscode nach den o. g. Ereignissen gewechselt?
- Wann wurde der Schlosscode zum letzten Mal gewechselt?
- Wird der Code der Codeschlsser hinterlegt?
- Wo und wie wird er hinterlegt?
- Wo werden evtl. vorhandene Reserveschlssel zum Schrank aufbewahrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.98 Sichere Installation von Novell Netware Servern

Im Vorfeld der Installation sowie bei der Einrichtung eines Novell Netware
Servers sollten die folgenden Aspekte beachtet werden, um eine mglichst
reibungslose und sichere Installation gewhrleisten zu knnen.
Dokumentation der Installation
Die Installation von Novell Netware Servern sollte nachvollziehbar dokumen-
tiert werden, damit im Vertretungsfall sowohl Auenstehende wie auch Neu-
einsteiger diese nach kurzer Einarbeitungszeit verstehen und nachvollziehen
knnen.
In der Dokumentation sollte insbesondere die Parametrisierung des Servers
(Netzeinbindung, Treiber), zustzliche NLMs (Netware Loadable Modules,
z. B. zur Datensicherung) und deren Konfiguration, sowie die eingespielten
Patches aufgefhrt werden. Weiterhin sollte die Installation und Einbindung
zustzlicher Hardware (z. B. Netzdrucker, Bandlaufwerke) ausfhrlich doku-
mentiert werden.
Desweiteren sollte die Dokumentation eine detaillierte Beschreibung der
Server-Hardware und der installierten Peripheriegerte (z. B. Netzdrucker)
beinhalten. In Abhngigkeit der Komplexitt des Novell-Netzes ist der Einsatz
von Administrationstools fr Dokumentations- und Revisionszwecke
erstrebenswert.
Die zur Installation und Konfiguration eines Novell Netware Servers
erforderliche Software sollte vollstndig an einem gesicherten Ort hinterlegt
werden, um im Bedarfsfall unntige Verzgerungen zu vermeiden. Dies sollte
insbesondere bei den aufzuspielenden Patches des Netzbetriebssystems,
zustzlichen NLMs sowie den einzusetzenden Treibern beachtet werden.
Das Laden des NLM-Utilities SYS:SYSTEM\CONLOG.NLM bewirkt, dass alle
Meldungen, die am Monitor des Servers erscheinen, gleichzeitig in die Datei
SYS:ETC\CONSOLE.LOG umgeleitet werden. Dieses NLM sollte bereits in
der Startdatei AUTOEXEC.NCF geladen werden, um Fehler, die in der Start-
phase des Servers gemeldet werden, nachvollziehen zu knnen.
Hardwareausstattung
Bei der Festlegung der erforderlichen Hauptspeicherkapazitt (RAM) von
Novell Netware Servern ist neben der Festplattenkapazitt, den eingesetzten
Betriebssystemen der Novell Netware Clients auch die RAM-
Speicherbelegung durch zustzlich geladene NLMs zu bercksichtigen.
Hinsichtlich der Festplattenkapazitt beim Einrichten einzelner Volumes auf
einem Novell Netware Server ist insbesondere das SYS: Volume ausreichend
zu dimensionieren, da alle Netware Prozesse standardmig auf diesem
Volume ausgefhrt werden. Eine zu kleine Dimensionierung des SYS: Volu-
mes kann unter Umstnden dazu fhren, dass nach einer gewissen Betriebszeit
temporre Prozesse, wie z. B. Druckjobs, die Kapazitten des Volumes
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
erschpfen und somit einen vermeidbaren ABEND (Abnormal End - Absturz

des Servers) hervorrufen.
Anforderungen an die Verfgbarkeit
Zur Erhhung der Verfgbarkeit von Novell Netware Servern bzw. der
gespeicherten Daten stellt das Netzbetriebssystem Novell Netware 3.x drei
hierarchische Fehlertolerierungsstufen (System Fault Tolerance Level) zur
Verfgung, die nachfolgend kurz aufgezeigt werden. Jede der hier
aufgezeigten Fehlertolerierungsstufen beinhaltet dabei die Funktionalitten der
vorherigen Stufe.
- SFT I (System Fault Tolerance I)
Novell Netware 3.x untersttzt standardmig SFT I. Hierbei werden
Datenverluste aufgrund physikalischer Festplattenfehler verhindert. Nach
einem Schreibzugriff auf eine Datei erfolgt ein Vergleich zwischen den
vernderten Daten auf der Festplatte mit den Originaldaten, die sich noch
im Arbeitsspeicher des Novell Netware Servers befinden. Ist dieses
Ergebnis fehlerhaft, so wird der entsprechende Sektor der Festplatte als
defekt markiert und fr zuknftige Zugriffe gesperrt.
Weiterhin werden die Daten des Arbeitsspeichers im Anschluss in dem
zuvor beschriebenen Fehlerfall in den so genannten "Hot Fix Bereich" der
Festplatte umgeleitet, fr den Novell Netware standardmig zwei Prozent
der Festplattenkapazitt beansprucht.
- SFT II (System Fault Tolerance II)
Die Fehlertolerierung der Stufe II (SFT II) kann auf zwei unterschiedliche
Arten realisiert werden.
- Disk Mirroring
Beim Disk Mirroring werden an einen Festplattencontroller des Ser-
vers zwei identische Festplatten angeschlossen. Die zu speichernden
Daten werden gleichzeitig auf beiden Festplatten gespeichert. Fllt
eine der Festplatten durch einen Fehler aus, wird ohne Ausfallzeit
und Datenverlust mit der zweiten Festplatte weitergearbeitet.
- Disk Duplexing
Beim Disk Duplexing werden zwei Festplatten und zwei Festplatten-
controller von gleicher Art bzw. Gre im File Server installiert.
Disk Duplexing gewhrleistet somit eine Fortfhrung des Betriebes
nicht nur beim Ausfall einer Festplatte, sondern auch beim Ausfall
eines Festplattencontrollers.
- SFT III (System Fault Tolerance III)
SFT III stellt die hchste Stufe der Toleranz gegen im Betrieb auftretende
Hardware-Fehler dar. Zwei identische Novell Netware Server arbeiten
hierbei gleichzeitig und parallel im Netz.
Die beiden Novell Netware Server sind hierbei durch ein eigenes Hochge-
schwindigkeitsnetz miteinander verbunden. Fllt einer der beiden Server
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
aus, so wird der Netzbetrieb, fast ohne Zeit- und Datenverlust, durch den
zweiten Novell Netware Server weitergefhrt.
Die Entscheidung, ob zustzlich zur Stufe SFT I weitere Manahmen (SFT II,
SFT III) ergriffen werden mssen, ist abhngig vom angestrebten Grad der
Verfgbarkeit des Netzes.
Notstromversorgung
Durch den Einsatz einer Notstromversorgung (UPS=Unterbrechungsfreie
Stromversorgung) knnen die Folgen eines pltzlichen Stromausfalles abge-
fangen werden. Novell Netware untersttzt den Einsatz geeigneter Gerte
durch das so genannte UPS-Monitoring. Im Falle eines pltzlichen
Stromausfalles wird der File Server am Ende der berbrckungszeit der UPS
geregelt heruntergefahren, d. h. die sich im Cache des Servers befindlichen
Daten werden auf die Festplatten bertragen, Verbindungen zum Server
ordnungsgem terminiert sowie die Serverprozesse geregelt beendet.
- Gengt die Dokumentation auch dem Vertretungsfall des Administrators?
- Wie wurde die Auswahl des SFT-Levels begrndet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.99 Sichere Einrichtung von Novell Netware Servern

Die im Lieferumfang von Novell Netware 3.x enthaltenen Sicherheitsfeatures
sind nach dem erstmaligen Start der Datei SERVER.EXE nicht automatisch
aktiviert, sondern mssen, jeweils einzeln durch die Systemadministration
installiert und konfiguriert werden.
Mit Hilfe des Programms SYS:PUBLIC\SETPASS.EXE sollte der Supervisor
nach dem erstmaligen Login sofort ein Passwort fr diesen Account vergeben.
Der standardmig vorhandene Guest-Account sollte ebenfalls mit einem
Passwort versehen werden. Wird der Guest-Account im spteren Betrieb nicht
bentigt, so sollte er entfernt werden.
Mittels DISABLE LOGIN (Serverkonsole) sollten whrend der Einrichtungs-
phase unautorisierte Login-Versuche unterbunden werden.
Mit Hilfe des Novell Utilities SYS:PUBLIC\SYSCON.EXE knnen im
Anschluss, unter dem Menpunkt Supervisor Options die meisten der Novell
Sicherheitsmechanismen installiert und konfiguriert werden. Hierbei ist zu
beachten, dass die unter Default Time Restrictions vorgenommenen Einstel-
lungen nur dann fr alle Accounts des Novell Netware Servers Gltigkeit
haben, wenn diese Einstellungen vor der Einrichtung von Benutzern und
Gruppen getroffen werden.
Nachfolgend werden sicherheitsrelevante Menpunkte aufgefhrt.
Default Account Balance/Restrictions
Mit Hilfe dieses Menpunktes werden folgende Sicherheitseinstellungen auf
dem Novell Netware Server aktiviert.
- Account has Expiration Date: Hiermit kann die Gltigkeitsdauer eines
Accounts zeitlich limitiert werden. Da ein Account normalerweise auf
Dauer angelegt ist, wird dieses Feature im Regelfall nur fr einen Guest
Account aktiviert.
- Limit Concurrent Connections: Hierdurch kann die Anzahl der gleich-
zeitigen Verbindungen eines Accounts zu dem Novell Netware Server
limitiert werden. Im Regelfall sollte hierbei der Wert "Eins" gewhlt
werden.
- Create Home Directory for User: Optionale Erstellung eines persn-
lichen Verzeichnisses fr jeden Benutzer. Es sollte die Option "Yes"
gewhlt werden.
- Require Password: Require Password installiert die Passwortabfrage fr
jeden Benutzer und bietet bei Aktivierung die Mglichkeit, Passwortregeln
zu installieren. Fr Require Password sollte die Option "Yes" gewhlt
werden.
- Minimum Password Lenght: Hierbei wird die erforderliche Mindestlnge
eines Passwortes eingestellt. Die Mindestlnge eines Passwortes sollte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
hierbei sechs Zeichen sein (s. u. M 2.11 Regelung des Passwortgebrauchs).

Wird die erforderliche Mindestlnge auf weniger als fnf Zeichen
eingestellt, so wird dieses beim Ausfhren von
SYS:\SYSTEM\SECURITY.EXE angezeigt (s. M 2.101 Revision von Novell
Netware Servern).
- Force Periodic Password Changes: Durch die Einstellung "Yes" wird
festgelegt, dass die Benutzer ihre Passwrter regelmig ndern mssen.
Dies sollte der Regelfall sein.
- Days Between Password Changes: Unter diesem Menpunkt wird die
generelle Gltigkeitsdauer von Passwrtern festgelegt. Die Gltigkeits-
dauer von Passwrtern muss fr das jeweilige System festgelegt werden.
Hinweis: Ist die Gltigkeitsdauer des Passwortes auf einen Wert
eingestellt, der mehr als 60 Tage betrgt, so wird dieses durch das Novell
Utility SYS:SYSTEM\SECURITY.EXE "beanstandet".
- Limit Grace Logins: Grace Logins ("Gnaden-Logins") sind die Logins,
die nach Ablauf der Gltigkeitsdauer eines Passwortes erfolgen. Die
Anzahl der Grace Logins sollte durch die Einstellung "Yes" grundstzlich
limitiert werden.
- Grace Logins Allowed: Die Anzahl der erlaubten Grace Logins sollte auf
den Wert "Eins" eingestellt werden, damit ein Benutzer, dessen Passwort
ungltig geworden ist, dieses sofort ndern muss.
- Require Unique Passwords: Die Aktivierung der Passworthistorie
(REQUIRE UNIQUE PASSWORDS) hat zur Folge, dass die letzten neun
Passwrter eines Accounts mit dem neu eingegebenen Passwort verglichen
werden und bei bereinstimmung das neue Passwort durch den Novell
Netware Server zurckgewiesen wird.
- Account Balance: Novell Netware Accounting Funktion
- Allow Unlimited Credit: Novell Netware Accounting Funktion
- Low Balance Limit: Novell Netware Accounting Funktion
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 1: Menu SYS:PUBLIC\SYSCON.EXE "Default Account Balan-

ce/Restrictions"
Default Time Restrictions
Mit Hilfe der Time Restrictions werden die erlaubten Arbeitszeiten fr
Accounts auf einem Novell Netware Server definiert. Auerhalb der hier fest-
gelegten Zeiten, die im Regelfall den blichen Arbeitszeiten entsprechen
sollten, ist es keinem Benutzer gestattet, sich am Novell Netware Server
anzumelden.
Hinweis: Fr die standardmig installierten Accounts Supervisor und Guest
ist der Netware-Default-Wert (keine Zeitbeschrnkungen) eingestellt. Es ist
empfehlenswert, zumindest den Guest-Account mit Hilfe von
SYS:PUBLIC\SYSCON.EXE (User Information - Time Restrictions) hinsicht-
lich der erlaubten Zugriffszeiten einzuschrnken.
Nachtrgliche nderungen der "Default Time Restrictions" bei der Einrich-
tung bzw. Pflege von Benutzer Accounts haben keine Auswirkungen auf die
erlaubten Zugangszeiten bereits eingerichteter Benutzer. Abweichende
Zugangszeiten einzelner Benutzer mssen mit Hilfe von
SYS:\PUBLIC\SYSCON.EXE (User Information - Time Restrictions) einge-
richtet werden.
Edit System AUTOEXEC File
Durch die Server Startdatei AUTOEXEC.NCF werden die Parameter (z. B.
Volumes, NLMs, zustzliche Protokolle etc.) eines Novell Netware Servers
konfiguriert.
Weiterhin knnen in der AUTOEXEC.NCF zustzliche Sicherheitseinstellun-
gen vorgenommen werden.
Das Novell Netware Konsolenkommando SECURE CONSOLE, das in die
AUTOEXEC.NCF eingebunden sein sollte, bewirkt dabei, dass NLMs nur
noch aus dem Serververzeichnis SYS:SYSTEM gestartet werden knnen, sowie
die Deaktivierung des Novell Netware Debuggers. Weiterhin wird
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
durch SECURE CONSOLE das DOS aus dem Hauptspeicher des Novell
Netware Servers entfernt, sowie die definierten Serversuchpfade auer Kraft
gesetzt, die zudem nicht erneut definiert werden knnen.
File Server Console Operators
Mit Hilfe des Menu-Utilities SYS:\PUBLIC\FCONSOLE.EXE kann,
ausgehend von einer Workstation, die begrenzte Kontrolle ber einen Novell
Netware Server bernommen werden.
Der File Server Operator, der neben der ausdrcklichen Berechtigung zur
Nutzung von SYS:\PUBLIC\FCONSOLE.EXE keine weiteren Privilegien
bentigt, kann hiermit Konsolennachrichten an die Benutzer versenden, den
Novell Netware Server wechseln sowie den Server herunterfahren. Weiterhin
knnen Statusanzeigen des Novell Netware Servers eingesehen und verndert
werden (Datum, Uhrzeit, etc.) sowie Informationen zu den aktuellen Verbin-
dungen eingesehen werden. Das Programm SYS:\PUBLIC\FCONSOLE.EXE
kann standardmig durch den Supervisor bzw. einen quivalenten Account
aufgerufen werden. Andere Benutzer sollten auf diese Dateien keine Rechte
besitzen.
Abbildung 2: Menu SYS:PUBLIC\FCONSOLE.EXE
Intruder Detection/Lockout
Durch die Aktivierung des "Detect Intruders" werden unautorisierte Login-
Versuche am Novell Netware Server erkannt und die hiervon betroffenen
Accounts ggf. gesperrt.
Die Aktivierung des "Detect Intruders" sowie die weitere Parametrisierung
dieses Menpunktes beugt somit einer "Brute Force Attacke" unter Novell
Netware vor.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Incorrect Login Attempts gibt hierbei die Anzahl der zulssigen Login Fehl-
versuche an; blicherweise sollte hierbei der Wert "Drei" eingestellt werden.
Mit Hilfe von Bad Login Count Retention Time kann die zeitliche Zurck-
verfolgung von fehlgeschlagenen Login-Versuchen eines Accounts aktiviert
werden. bersteigt die Anzahl der Login-Fehlversuche eines Accounts
innerhalb des definierten Zeitraumes den unter Incorrect Login Attempts
eingestellten Wert, so wird der Benutzer Account auf dem Novell Netware
Server gesperrt.
Der Menupunkt Lock Account After Detection sollte auf "Yes" eingestellt
sein, um einen Account, der die Anzahl der ungltigen Login Versuche ber-
schritten hat, zu sperren.
Der Zeitwert fr Length of Account Lockout sollte keinesfalls zu gering
gewhlt werden (> 1 Stunde) um sicherzustellen, dass die Ursache fr einen
Intruder Lockout durch die Systemadministration und den betroffenen
Benutzer aufgeklrt werden kann.
Abbildung 3: Menu SYS:PUBLIC\SYSCON.EXE "Supervisor Options -

Intruder Detection Logout"
System Login Script
In dem System Login Script werden die Einstellungen vorgenommen, die fr
alle Benutzer nach deren Anmeldung auf dem Novell Netware Server existie-
ren sollen. Das System Login Script wird, im Gegensatz zum User Login
Script, fr jeden Benutzer des Novell Netware Servers ausgefhrt. Es ist daher
sinnvoll, die Einstellungen, die fr alle Benutzer des Novell Netware Servers
gelten sollen, wie z. B. Laufwerkzuordnungen oder der Aufruf von externen
Programmen, im System Login Script des Novell Netware Servers
einzustellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Soll vermieden werden, dass ein Benutzer durch Verwendung des eigenen
UER-Login-Scripts die Standardeinstellungen verndert, muss beim Verlassen
des System-Login-Scripts der Befehl EXIT aufgenommen werden
Hinweis: Weiterhin ist fr jeden Benutzer ein User-Login-Script zu erstellen.
Dies ist erforderlich, da jeder Benutzer ber das Zugriffsrecht "Create" im
Verzeichnis SYS:MAIL verfgt. Einem Benutzer ohne User-Login-Script kann
daher in seinem SYS:MAIL-Verzeichnis eine Datei LOGIN erzeugt werden,
die Schadfunktionen ausfhren kann.
View File Server Error Log
Das File Server Error Log ist das Fehlerprotokoll eines Novell Netware Ser-
vers. In ihm werden alle Fehler und Warnmeldungen des Servers gespeichert
und knnen durch den Supervisor ausgewertet werden.
Abbildung 4: Menu SYS:PUBLIC\SYSCON.EXE "Supervisor Options - File

Server Error Log"
Workgroup Managers
Ein Arbeitsgruppenverwalter (Workgroup Manager) ist ein eingeschrnkter
Supervisor Account, der das Recht zum Erstellen und Lschen von Bindery
Objekten (Benutzer, Benutzergruppen, Druckerwarteschlangen) sowie deren
Verwaltung hat. Die Rechte, die ein Arbeitsgruppenverwalter hierbei einsetzt
bzw. an Benutzer und Benutzergruppen weitergeben darf, richten sich nach
den durch den Supervisor zugestandenen Rechten.
Arbeitsgruppenverwalter knnen keine neuen Arbeitsgruppenverwalter oder
einen Benutzer einrichten, dessen Sicherheitsstufe "Supervisor-quivalent" ist,
es sei denn, der Arbeitsgruppenverwalter verfgt ber Supervisor-quivalente
Rechte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Station Restrictions
Mit Hilfe des Menpunktes Station Restrictions knnen die Netzadressen fest-
gelegt werden, von denen aus sich ein Benutzer am Novell Netware Server
anmelden darf. Informationen ber die jeweilige Adresse einer Workstation
im Netz lassen sich z. B. mit SYS:PUBLIC\USERLIST.EXE /A in Erfahrung
bringen. Die Festlegung von erlaubten Netzadressen ist insbesondere fr den
Supervisor bzw. fr quivalente Accounts empfehlenswert. Dieses sollte
jedoch vor Ort, je nach Gegebenheit, entschieden werden.
Standardisierte Einrichtung von Benutzern und Benutzergruppen
Neben der Einrichtung von Benutzern unter Einsatz des Menu-Utilities
SYS:PUBLIC\SYSCON.EXE besteht zudem die Mglichkeit, Benutzer mit
Hilfe der Utilities SYS:\PUBLIC\MAKEUSER.EXE und
SYS:\PUBLIC\USERDEF.EXE einzurichten.
Diese eignen sich besonders fr die gleichzeitige Einrichtung einer greren
Anzahl von Benutzern.
SYS:\PUBLIC\MAKEUSER.EXE erzeugt eine Art Batch-Datei, mit deren
Hilfe mehrere Benutzer mit unterschiedlichen Rechten eingerichtet werden
knnen.
SYS:\PUBLIC\USERDEF.EXE dient zur Einrichtung mehrerer Benutzer mit
gleichen Rechten. Zu diesem Zweck wird eine Schablone (Template) erstellt,
in der eingetragen wird, nach welchen Vorgaben die Benutzer einzurichten
sind.
Diese Menu-Utilities sollten insbesondere in greren Netzen aus Grnden
einer vereinfachten und einheitlichen Administration eingesetzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.100 Sicherer Betrieb von Novell Netware Servern

Der sichere Betrieb eines Novell Netware Netzes setzt verschiedene Aktionen
voraus, die nachfolgend beschrieben werden.
Vergabe von Zugriffsrechten auf Verzeichnisse und Dateien
Die Vergabe von Zugriffsrechten (Trustee Assignments) auf Verzeichnisse
und Dateien von Novell Netware Servern spielt eine zentrale Rolle fr die
Sicherheit eines Novell Netware Servers.
Zugriffsrechte werden im Gegensatz zur Vergabe von Attributen einzelnen
Benutzern bzw. Benutzergruppen zugewiesen.
Verzeichnisse und Dateien knnen ber die Steuerung der Zugriffsrechte
aufgabenbezogen zugewiesen werden. Hierdurch kann sichergestellt werden,
dass Benutzergruppen bzw. Benutzer nur die Zugriffsrechte auf Verzeichnisse
und Dateien haben, die sie zur Durchfhrung ihrer Aufgaben bentigen.
Aus Grnden der bersichtlichkeit, einer vereinfachten Administration sowie
einer verbesserten Revisionsfhigkeit sollte die Vergabe von Zugriffsrechten
vorrangig ber die Zuweisung von Rechten an Benutzergruppen erfolgen.
Um die versehentliche Freigabe von Verzeichnissen durch einen Benutzer zu
verhindern, sollte die Systemadministration Benutzergruppen und Benutzern
in den ihnen zugewiesenen Verzeichnissen die Rechte "Supervisory" (S) und
"Access Control" (A) nicht erteilen.
Werden ausgewhlten Verzeichnissen oder Dateien mit Hilfe von Netware-
Attributen bestimmte Eigenschaften (z. B. schreibgeschtzte Dateien) zuge-
wiesen, so sollte beachtet werden, dass Benutzer, die das Zugriffsrecht
"Modify (M)" auf die entsprechenden Verzeichnisse und Dateien besitzen, in
der Lage sind, diese Attribute zu verndern. Daher sollte der Kreis der
Benutzer mit diesem Zugriffsrecht eingeschrnkt werden (s. u. Vergabe von
Netware-Attributen auf Verzeichnisse und Dateien).
Vergabe von Netware-Attributen auf Verzeichnisse und Dateien
Neben der Benutzer- bzw. gruppenbezogenen Erteilung von Zugriffsrechten
auf Verzeichnisse und Dateien kann durch die Vergabe von Netware-Attri-
buten auf Verzeichnisse und Dateien die Datensicherheit erhht werden.
Attribute sind immer verzeichnis- bzw. dateibezogen, d. h. sie sind unab-
hngig von den zugewiesenen Zugriffsrechten und gelten fr alle Benutzer
einschlielich des Supervisors.
Benutzer, denen das Zugriffsrecht "Modify (M)" auf die in Frage kommenden
Verzeichnisse und Dateien eingerumt wurde, knnen die vergebenen
Netware-Attribute ndern und somit jede Aktion, die sich aus ihren effektiven
Rechten ergibt, ausfhren.
Die Sicherheit durch den Einsatz von Netware-Attributen stellt sich somit als
ein Subsystem in der Verzeichnis- und Dateisicherheit dar.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei der Vergabe von Netware-Attributen auf Verzeichnisse und Dateien

sollten die folgenden Eigenschaften von Netware-Attributen beachtet werden.
- Verzeichnis-Attribute:
Hidden (H): Das Verzeichnis wird als versteckt gekennzeichnet; es
erscheint weder in einem Inhaltsverzeichnis unter DOS, noch kann es
gelscht oder kopiert werden.
System (Sy): Das Verzeichnis (z. B. SYS:SYSTEM\DELETED.SAV) wird
vom System benutzt; es erscheint ebenfalls nicht in einem Inhaltsver-
zeichnis unter DOS und kann weder kopiert noch gelscht werden.
Rename Inhibit (R): Das Verzeichnis kann nicht umbenannt werden.
Delete Inhibit (D): Das Verzeichnis kann nicht gelscht werden.
Purge (P): Das Verzeichnis sowie die in ihm befindlichen Dateien werden
beim Lschen sofort, auch physikalisch, gelscht. Eine Wiederherstellung
des Verzeichnisses mit Hilfe von SYS:\PUBLIC\SALVAGE.EXE ist nicht
mglich.
- Datei Attribute:
Read write (Rw): Auf die Datei ist sowohl Lese- wie auch Schreibzugriff
mglich.
Read only (Ro): Die Datei kann nur gelesen werden. Ein Schreibzugriff ist
nicht mglich. Um Datenverluste bei einer gemeinsamen Benutzung zu
vermeiden, sollten diese Dateien ebenfalls das Attribut "Shareable" (S)
besitzen.
Ausfhrbare Programmdateien (*.exe, *.com) sollten mit dem Attribut
"Read only" versehen werden, um einem mglichen Befall durch
Computer-Viren vorzubeugen.
Shareable (S): Diese Dateien knnen von mehreren Benutzern gleichzeitig
benutzt werden. Dateien, die mit dem Attribut "Shareable" versehen
worden sind, sollten gleichzeitig das Attribut "Read Only" (RO) besitzen.
Das Attribut "Shareable" ist nur relevant fr Programme, die Dateien nicht
netzfhig ffnen.
Purge (P): Dateien mit dem Attribut "Purge" werden beim Lschen nicht
nur logisch, sondern sofort physikalisch gelscht. Dies hat zur Folge, dass
die Datei nicht wiederhergestellt werden kann
(SYS:PUBLIC\SALVAGE.EXE).
In diesem Zusammenhang wird darauf hingewiesen, dass die physikalische
Lschung von Dateien nicht nur durch das Netware-Attribut "Purge"
erfolgen kann. Wenn das sichere Lschen von Verzeichnissen und Dateien
gewnscht wird, dann kann hierzu das Netware Programm
SYS:PUBLIC\PURGE.EXE eingesetzt werden.
Transactional (T): Dateien mit diesem Attribut unterliegen der Trans-
aktionskontrolle von Novell Netware. Als Transaktion wird hier eine
zusammenhngende Folge von Vernderungen in einer oder mehreren
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Dateien verstanden. Das Setzen dieses Attributes bewirkt, dass nur voll-
stndig durchgefhrte Transaktionen in den Datenbestand der Datei ber-
nommen werden. Transaktionen, die unkorrekt abgebrochen wurden,
werden von Novell Netware rckgngig gemacht.
Archive needed (A): Die so durch Novell Netware gekennzeichneten
Dateien sind seit der letzten Datensicherung inhaltlich verndert oder neu
auf dem Novell Netware Server aufgespielt worden. Datensicherungs-
software kann somit bei einer sequentiellen Datensicherung erkennen, dass
die Datei erneut gesichert werden muss.
Copy Inhibit (C): Derartige Dateien knnen nicht kopiert werden. Dieses
Netware-Attribut gilt allerdings nur fr APPLE Macintosh Workstations.
Delete Inhibit (D): Die Datei kann nicht gelscht werden.
Rename Inhibit (R): Die Datei kann nicht umbenannt werden.
Execute Only (X): Ausfhrbare Programmdateien (*.EXE, *.COM), die
mit diesem Attribut versehen werden, knnen ausschlielich ausgefhrt
oder gelscht werden. Ein Kopieren der Datei ist nicht mglich.
Hidden (H): Die Datei wird als versteckt gekennzeichnet. Sie erscheint
nicht in einem Inhaltsverzeichnis unter DOS und kann weder kopiert noch
gelscht werden.
System (S): Die Datei (z. B. Bindery Dateien -NET$OBJ.SYS,
NET$PROP.SYS, NET$VAL.SYS) wird vom Netzbetriebssystem verwen-
det; sie erscheint ebenfalls nicht in einem Inhaltsverzeichnis unter DOS
und kann weder kopiert noch gelscht werden.
Sicherung wichtiger Systemdateien
Die Server Startdateien AUTOEXEC.NCF und STARTUP.NCF sollten, in
ihrer jeweils aktuellen Fassung, durch den Systemadministrator auf Diskette
gesichert werden und vor unbefugtem Zugriff gesichert hinterlegt werden. Es
ist sinnvoll, diese Dateien durch Kommentierungszeilen zu ergnzen, damit
beim Auftreten von Problemen die jeweils eingestellten Parameter nachvoll-
zogen werden knnen.
Weiterhin sollte die Bindery (NET$OBJ.SYS, NET$PROP.SYS,
NET$VAL.SYS) eines Novell Netware Servers regelmig mit Hilfe des
Programms SYS:SYSTEM\BINDFIX.EXE gesichert werden. Die gesicherte
Bindery (SYS:SYSTEM\*.OLD) sollte im Anschluss auf einen Datentrger
gesichert und vor unbefugten Zugriff geschtzt hinterlegt werden.
Nach der Ausfhrung von SYS:SYSTEM\BINDFIX.EXE sollte die Integritt
der neuen Bindery auf jeden Fall getestet werden. Im Zweifelsfalle kann die
alte Bindery durch SYS:SYSTEM\BINDREST.EXE wiederhergestellt werden.
Da die aktuelle Bindery whrend der Ausfhrung von
SYS:SYSTEM\BINDFIX.EXE dem Zugriff der Benutzer entzogen wird, sollte
aus Grnden der Betriebssicherheit bei der Sicherung der Bindery eines
Novell Netware Servers auer dem Supervisor bzw. dem Supervisor-qui-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
valenten Benutzer kein Benutzer auf dem Novell Netware Server eingeloggt
sein.
Eingeschrnkte Nutzung des Supervisor Account bzw. eines Supervisor-
quivalenten Account
Der Account des Supervisors sollte bei der tglichen Administrationsarbeit
nicht verwendet werden, sondern nur in Notfllen benutzt werden. Um
dennoch die Systemadministration zu gewhrleisten, sollte daher fr jeden
Benutzer mit der Netware-Sicherheitsstufe "Supervisor" ein Supervisor-qui-
valenter Account eingerichtet werden, mit dem die Systemadministration
normalerweise erfolgt. Werden die Administrationsarbeiten nicht haupt-
amtlich wahrgenommen, so sollten fr die nicht-administrativen Aufgaben
zustzlich aufgabenbezogene Accounts eingerichtet werden.
Der Account des Supervisors bzw. eines Supervisor-quivalenten Account
sollte weiterhin nur auf hierzu definierten Workstations verwendet werden, da
die Integritt anderer Workstations u. U. durch Benutzer manipuliert sein
knnte.
Delegierung der Systemverwaltung
In greren Netzen (mehrere Novell Netware Server oder verschiedene
Liegenschaften) bzw. bei einer greren Anzahl von Benutzern empfiehlt es
sich, bestimmte Aufgaben der Systemadministration zu delegieren. Novell
Netware 3.x bietet hierzu die Mglichkeit, Benutzer zu User-Account-
Managern bzw. Workgroup-Managern zu bestimmen.
User-Account-Manager knnen die Benutzer und Gruppen verwalten, die
ihnen vom Systemverwalter zugewiesen wurden. Dabei sind sie in der Lage,
neben der nderung der Benutzerdaten (Passwort, Benutzungszeiten usw.)
alle Rechte, ber die sie selbst verfgen, weiter zu geben. Des weiteren kann
der User-Account-Manager einzelne Benutzer einer Gruppe zuweisen. Dabei
mssen sowohl die Gruppen als auch die Benutzer vom entsprechenden User-
Account-Manager verwaltet werden. Der User-Account-Manager ist nicht in
der Lage neue Benutzer oder Gruppen einzurichten. Allerdings kann er ihm
zugewiesene Benutzer oder Gruppen lschen.
Ein Workgroup-Manager hat alle Rechte eines User-Account-Managers.
Darber hinaus ist er in der Lage, neue Benutzer und Gruppen einzurichten.
Eine weitere Aufgabe des Workgroup-Managers ist das Einrichten von
Druckerwarteschlangen.
Nutzung von NCP-Paket-Signatur
Die Kommunikation eines Novell Netware Clients mit einem Novell Netware-
Server wird durch das Netware Core Protokoll (NCP) gesteuert. Client und
Server tauschen hierbei einzelne Pakete aus, in denen die Daten enthalten sind.
Ein potentieller Angreifer kann diese Pakete mittels spezieller Programme
(siehe G 5.58 "Hacking Novell Netware") berwachen und die Datenpakete
hher privilegierter Benutzer manipulieren.
Um dieser Bedrohung entgegenzuwirken, wurde die Paket-Signatur
entwickelt. Bei der Anmeldung eines Benutzers am Server wird ein geheimer
Schlssel ermittelt. Wann immer die Workstation daraufhin eine Anfrage ber
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
NCP an den Server sendet, wird diese mit einer Signatur versehen, die aus
dem geheimen Schlssel und der Signatur des vorherigen Pakets gebildet
wird. Diese Signatur wird an das betreffende Paket angehngt und zum Server
gesandt. Bevor die eigentliche Anfrage bearbeitet wird, verifiziert der Server
die Paket-Signatur.
Durch die Option Set NCP Packet Signature -Wert- kann die Paket-Signatur
am Server aktiviert werden.
Es sind folgende NCP-Paket-Signatur Level mglich:
Wert "0": Es findet keine NCP-Paket-Signatur statt.
Wert "1": Der Novell Netware Server arbeitet auf Anforderung des
Clients mit der NCP-Paket-Signatur.
Wert "2": Der Novell Netware Server fordert vom Client NCP-Paket-
Signatur an. Sollte der Client dieses nicht realisieren knnen,
so wird die Kommunikation zwischen Client und Novell
Netware Server trotzdem zugelassen.
Wert "3": Die NCP-Paket-Signatur ist zwingend vorgeschrieben.
Zur Gewhrleistung der IT-Sicherheit sollte die NCP-Paket-Signatur mit dem
Wert "3" gewhlt werden. Da sich jedoch die Netzlast beim Einsatz der NCP-
Paket-Signatur um bis zu 30% erhht, sollte im Vorfeld des Einsatzes geklrt
werden, ob die Performance hierdurch nicht unzumutbar eingeschrnkt wird.
Beschrnkung des nutzbaren Festplattenspeichers
Mit Hilfe des Programms SYS:PUBLIC\DSPACE.EXE sollte der auf einem
Volume oder einem Verzeichnis zur Verfgung stehende Festplattenspeicher
limitiert werden, da erfahrungsgem die Inanspruchnahme des zur Verfgung
stehenden Festplattenspeichers mit der Kapazitt des Festplattenspeichers
steigt.
Alternativ hierzu kann auch, soweit eingerichtet, die Kapazitt des jeweiligen
persnlichen Verzeichnis eines Benutzers beschrnkt werden, wenn fr die
Arbeitsdaten eigene Verzeichnisse eingerichtet wurden.
Sperrung von nicht bentigten Programmen
Die meisten der unter SYS:PUBLIC bereitgestellten Novell Netware
Programme werden durch die Netware-Benutzer im Regelfall nicht bentigt,
da viele der Funktionen (Druckerkonfigurationen, nderung des Passwortes,
Laufwerkszuweisungen) durch die Client- Software gehandhabt werden
knnen. Aus diesem Grund sowie der meist ungewohnten Handhabung der
Novell Netware Dienstprogramme empfiehlt es sich, nicht bentigte
Programme in das Verzeichnis SYS:SYSTEM zu verschieben. Insbesondere
das Programm SYS:PUBLIC\RENDIR.EXE sollte wegen der erkannten
Gefhrdung (G 5.54 Vorstzliches Herbeifhren eines Abnormal End) den
Benutzern nicht zur Verfgung gestellt werden.
Keinesfalls sollten, wie oftmals beobachtet, die unter SYS:SYSTEM gespei-
cherten Programme in das Verzeichnis SYS:PUBLIC verlagert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Information ber Patches von Novell Netware

Im Verlauf der Entwicklung des Netzbetriebssystems Novell Netware 3.x
haben sich diverse Schwachstellen bzw. Unzulnglichkeiten herausgestellt,
die durch den Hersteller mit Hilfe von so genannten Patches grtenteils
behoben wurden. Diese Patches werden durch den Hersteller im Internet zur
Verfgung gestellt (http://www.novell.com, ftp.novell.com bzw.
http://www.novell.de, ftp.novell.de). Informationen ber die Funktionalitt
sowie das ggf. erforderliche Einspielen der zur Verfgung gestellten Patches
knnen daher Schwachstellen im laufenden Produktionsbetrieb beseitigen.
Insbesondere zustzlich installierte Softwareprodukte, wie z. B. zur Daten-
sicherung, erfordern oftmals einen bestimmten Patchlevel des Netzbetriebs-
systems. Hierbei ist jedoch zu beachten, dass die angebotenen Patches keines-
wegs blind aufgespielt werden sollten, sondern nur im Bedarfsfall ("never
change a running system") sowie nach grndlicher Information.
Soweit vorhanden, sollten diese Patches zunchst auf einer Testkonfiguration
ausgetestet werden.
Im Internet (Usenet) ist, neben den internationalen Diskussionsforen zum
Thema Novell Netware (z. Z. comp.os.netware.announce,
comp.os.netware.misc, comp.os.netware.security, bit.listserv.novell), fr die
deutschsprachigen Benutzer ein deutsches Novell Forum (z. Z.
de.comp.sys.novell) vorhanden, in dem einige versierte Novelladminstratoren
aktiv sind, die oftmals auch die schwierigsten Probleme zu lsen helfen.
Auerdem werden zu den im Internet am hufigsten gestellten Fragen Dateien
(so genannte FAQs - Frequently Asked Questions) zur Verfgung gestellt, die
die hufigsten Probleme thematisieren und Lsungen anbieten.
Patches und Informationen ber Novell Netware werden darber hinaus auch
ber andere Anbieter von Netzdiensten, wie z. B. Compuserve, Fidonet und
Mailboxen bereitgestellt.
Fr die Richtigkeit und Vollstndigkeit der jeweiligen Informationen in den
Usenet Diskussionsforen sowie in den FAQs kann an dieser Stelle jedoch
keine Garantie gegeben werden. Es sei darauf hingewiesen, dass eine voll-
stndige Beschreibung des aufgetretenen Problems, sowie eine Beschreibung
der jeweiligen Konfiguration des Netzes (Client, Server) besonders vorteilhaft
bei der Hilfesuche im Internet (Usenet) ist.
Schwierigkeiten whrend des Netzbetriebes knnen darber hinaus oftmals
durch die Nachfrage bei dem Verkufer des Netzbetriebssystems oder im
Informationsaustausch mit Kollegen behoben werden; wobei auch hier die
Problemlsung durch eine vollstndige Konfigurationsbeschreibung erleich-
tert wird.
Prfung auf Computer-Viren
Computer-Viren, die sich in den auf einem Novell Netware Server
gespeicherten Programmen und Dateien befinden, knnen, aufgrund der zen-
tralen Verteilung durch den Novell Netware Server an die Workstations,
erhebliche Schden im Netzverbund hervorrufen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Aus diesem Grund sollten die Programme und Dateien eines Novell Netware
Servers regelmig mit einem aktuellen Virensuchprogramm auf evtl.
vorhandene Computer-Viren berprft werden.
Zu diesem Zweck empfiehlt es sich einen speziellen Benutzer-Account auf
dem Novell Netware Server einzurichten, der ber die Zugriffsrechte "Read"
(R) und "File Scan" (F) auf alle Dateien des Servers verfgt. Die Prfung auf
Computer-Viren sollte keinesfalls mit den Rechten des Supervisors, bzw.
Supervisor-quivalenten Rechten durchgefhrt werden, da ein Computer-
Viren-Checkprogramm, welches selbst mit einem Computer-Virus infiziert ist,
diesen auf alle Programme und Dateien des Novell Netware Servers ber-
tragen wrde.
Die Benutzer bzw. Benutzergruppen sollten auf die Verzeichnisse und Dateien
mit ausfhrbarem Programmcode lediglich die effektiven Rechte "Read" (R)
und "File scan" (F) erhalten, zudem sollten ausfhrbare Programme mit dem
Netware-Attribut "Read only" (RO) versehen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.101 Revision von Novell Netware Servern

Die vollstndige Revision eines Novell Netware 3.x Servers drfte in der
Praxis im Rahmen IT-Grundschutz kaum mglich sein. Folgende
Revisionsanstze sollten dennoch beachtet werden:
Durch das Programm SYS:SYSTEM\SECURITY.EXE werden die Bindery-
Dateien eines Novell Netware Servers auf die nachfolgenden Sicherheits-
schwachstellen hin untersucht und die erkannten Schwachstellen aufgelistet.
No password assigned
Benutzer, die kein Passwort fr das Login auf dem Novell Netware Server
bentigen, werden aufgelistet.
Insecure passwords
Hierbei wird die Bindery des Novell Netware Servers auf mehrere Aspekte hin
untersucht.
Zum einen werden die Benutzer angezeigt, deren Passwort gleich dem
Anmeldenamen auf dem Novell Netware Server ist; weiterhin werden alle
Benutzer aufgefhrt, deren Passwort weniger als fnf Zeichen lang sein darf.
Es wird weiterhin fr jeden Benutzer geprft, ob die Gltigkeitsdauer eines
Passwortes mehr als 60 Tage betrgt und ob eine unbegrenzte Anzahl von
"Frei-Anmeldungen" (Grace Logins) mglich ist.
Supervisor equivalence
SYS:SYSTEM\SECURITY.EXE berprft die Bindery eines Novell Netware
Servers dahingehend, ob Benutzer die Sicherheitsstufe "Supervisor"
(Supervisor equivalence) auf dem Novell Netware Server haben, und fhrt
diese auf.
Root directory privileges
Aufgrund der nach "unten" gerichteten Vererbung von Zugriffsrechten werden
alle Benutzer eines Novell Netware Servers dahingehend geprft, ob sie
Zugriffsrechte im Hauptverzeichnis (Volume Ebene) haben.
Login scripts
Es werden alle Benutzer ermittelt, die ber kein eigenes Login Script (User
Login Script) verfgen.
Da alle Benutzer, um elektronische Nachrichten austauschen zu knnen, stan-
dardmig ber das Zugriffsrecht "Create" in dem Verzeichnis SYS:MAIL
verfgen, knnte ein "Angreifer" einem Benutzer, der ber kein User Login
Script verfgt, in dessen SYS:MAIL\ Verzeichnis eine Datei LOGIN (User-
Login-Script) kopieren, mit dem dessen Novell Netware Umgebung verndert
wrde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Excessive rights
Novell Netware 3.x stellt im Rahmen der Installation standardmig mehrere
Verzeichnisse zur Verfgung (SYS:SYSTEM, SYS:PUBLIC, SYS:LOGIN).
SYS:SYSTEM\SECURITY.EXE berprft die Bindery des Novell Netware
Servers, ob Benutzer in diesen Verzeichnissen grere Rechte haben, als die
standardmig vorgegebenen. Weiterhin werden die SYS:MAIL Verzeichnisse
aller Benutzer auf das alleinige Verfgungsrecht (Ausnahme "Create" fr die
Gruppe "Everyone") des jeweiligen Inhabers geprft.
- Wann wurde die letzte Revision durchgefhrt?
- In welchen Intervallen erfolgt eine Revision?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.102 Verzicht auf die Aktivierung der Remote

Console
Das Netzbetriebssystem Novell Netware ermglicht mittels des Programmes
SYS:\SYSTEM\RCONSOLE.EXE die Fernsteuerung der Novell Netware
Serverkonsole durch eine Workstation. Der Novell Netware Server wird
hierzu in der AUTOEXEC.NCF durch das Laden von REMOTE.NLM mit dem
dazugehrenden Passwort und RSPX.NLM eingerichtet. Dabei muss
vermieden werden, dass das Passwort im Klartext in der AUTOEXEC.NCF
enthalten ist. Dazu kann nach Ausfhren des Programms REMOTE.NLM der
Befehl REMOTE ENCRYPT an der Serverkonsole eingegeben werden. Das
dann abgefragte Passwort wird verschlsselt und auf Wunsch mit dem
dazugehrigen Befehl in der Datei LDREMOTE.NCF abgelegt. Der Befehl in
der Datei LDREMOTE.NCF sieht z. B. wie folgt aus:
LOAD REMOTE -E 0613BB68060099
Netzanalyse-Tools, so genannte Sniffer, knnen die Daten, die zwischen der
Workstation und dem Novell Netware Server ausgetauscht werden, auslesen
und speichern. Hierzu gehrt auch das verschlsselte Passwort, welches zur
Fernsteuerung des Novell Netware Servers eingegeben werden muss.
Spezielle Software ist in der Lage, das verschlsselte Passwort zu ent-
schlsseln. Unbefugte knnen hierdurch in die Lage versetzt werden, mittels
der Fernsteuerung Zugriff auf die Konsole des Novell Netware Servers zu
erlangen.
Um zudem zu verhindern, dass Remote-Sitzungen mit Netzanalyse-Tools
aufgezeichnet und danach einfach wieder ins Netz eingespielt werden knnen,
sollte darauf geachtet werden, dass Signaturen bei den RSPX-Paketen aktiviert
sind. Dies kann berprft werden, indem der Befehl RSPX an der Konsole des
Servers ausgefhrt wird. Die Antwort sollte wie folgt aussehen:
RSPX Packet Signatures:
All packets must contain signatures.
Sollten hier keine Signaturen aktiviert sein, kann dies durch den Befehl RSPX
SIGNATURES ON veranlasst werden. Da diese Funktion erst ab Netware 3.12
untersttzt wird, sollte unbedingt auf die aktuelle Netware Version zurck-
gegriffen werden.
Soweit die rtlichen Gegebenheiten und die betrieblichen Ablufe dieses
zulassen, sollte aus Sicherheitserwgungen auf die Fernsteuerung von Novell
Netware Servern verzichtet werden.
Generell gilt jedoch, wenn C2-Sicherheit umgesetzt werden soll (siehe auch
M 4.102 C2-Sicherheit unter Novell 4.11), dann darf das Programm
SYS:\SYSTEM\RCONSOLE.EXE nicht eingesetzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.103 Einrichten von Benutzerprofilen unter Windows

95
Unter Windows 95 besteht die Mglichkeit, durch Einrichten von Benutzer-
profilen eine Benutzertrennung durchzufhren. Diese Trennung dient jedoch
(wenn nicht durch Systemrichtlinien eine Einschrnkung erfolgt, vgl. M 2.104
Systemrichtlinien zur Einschrnkung der Nutzungsmglichkeiten von Windows
95) ausschlielich dazu, benutzerspezifische Einstellungen zu konservieren
und damit fr den jeweiligen Benutzer eine individuelle Arbeitsumgebung zu
erhalten, die er nach seinen Bedrfnissen und Erfordernissen anpassen kann.
Ein Windows 95-Anmeldepasswort wird erst nach Aktivieren der
Benutzerprofile obligatorisch. Fr dieses Passwort gelten im brigen dieselben
berlegungen wie fr WfW-Anmeldepasswrter (vgl. M 4.46 Nutzung des
Anmeldepasswortes unter WfW und Windows 95).
Die den Benutzer betreffenden Einstellungen werden in einem Verzeichnis
C:\WINDOWS\PROFILES\Benutzername gespeichert.
Benutzerprofile sollten auf einem nicht vernetzten Windows 95-Rechner
immer dann aktiviert werden, wenn unerfahrenen Benutzern das Navigieren
unter Windows 95 erleichtert werden soll. Dies ist ebenfalls sinnvoll, wenn
eine Benutzertrennung, wenn auch nicht unter Sicherheitsgesichtspunkten, so
doch aus organisatorischen oder prinzipiellen Grnden gewnscht wird.
Dazu ffnet man die Programmgruppe SYSTEMSTEUERUNG, dann die
Schaltflche KENNWRTER und kann anschlieend die Benutzerprofile
aktivieren bzw. deaktivieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hinweis: In Novell Netware- oder Windows NT-Netzen knnen verpflich-

tende Benutzerprofile angelegt werden, indem das entsprechende Profil in
einem dem Benutzer zugeordneten Netzverzeichnis zugriffsgeschtzt gespei-
chert wird. Dieses Profil hat den Namen USER.MAN und wird bei jeder
Anmeldung am Server automatisch geladen (vgl. M 4.51 Benutzerprofile zur
Einschrnkung der Nutzungsmglichkeiten von Windows NT).
- Sollen an dem Windows 95 Rechner mehrere Benutzer arbeiten?
- Ist eine Benutzertrennung unter Sicherheitsgesichtspunkten oder aus
organisatorischen bzw. prinzipiellen Grnden sinnvoll?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.104 Systemrichtlinien zur Einschrnkung der

Nutzungsmglichkeiten von Windows 95
Soll unerfahrenen Benutzern das Navigieren unter Windows 95 erleichtert
werden oder ist aus betrieblicher Sicht die Einschrnkung bestimmter
Ressourcen notwendig, so kann unter Windows 95 mit so genannten System-
richtlinien die Benutzerumgebung benutzerspezifisch mit bestimmten
Restriktionen versehen werden. Jedoch sollte bercksichtigt werden, dass
Benutzer gegenber dem IT-System mglicherweise eine abweisende Haltung
einnehmen, wenn Einschrnkungen nicht unmittelbar einsichtig sind. Eine
Einschrnkung sollte also nur dann erfolgen, wenn sie tatschlich notwendig
ist oder wenn sie vom Benutzer nicht bemerkt wird.
Sobald Systemrichtlinien aktiviert sind, wird beim Starten von Windows 95
berprft, ob benutzerspezifische Einschrnkungen fr den aktuellen Benutzer
eingerichtet wurden. Ist dies der Fall, werden diese geladen. Ist dies nicht der
Fall, werden die Einschrnkungen fr den Standardbenutzer herangezogen. Im
folgenden werden zunchst die prinzipiellen Einschrnkungen beschrieben,
die mit den Systemrichtlinien eingestellt werden knnen. Anschlieend wird
aufgezeigt, wie diese mittels des Systemrichtlinieneditors (POLEDIT.EXE)
angelegt und aktiviert werden knnen.
Die wesentlichen mit Systemrichtlinien einzustellenden Restriktionen fr
einen nicht vernetzten Windows 95-Rechner sind:
- Der Zugriff auf die Systemsteuerung kann bezglich der Optionen
ANZEIGE, NETZWERK, KENNWRTER, DRUCKEREINSTELLUNGEN
und SYSTEM eingeschrnkt werden. Die jeweiligen Optionen knnen zum
Teil vollstndig deaktiviert oder auf einzelne Registerkarten beschrnkt
werden.
Wesentlich bei diesen Optionen sind folgende Punkte:
- Es knnen Vorgaben fr Bildschirmfarben unter Ergonomie-
gesichtspunkten gemacht werden.
- Es kann vorgesehen werden, eigene Kennwrter durch den Benutzer
ndern zu lassen.
- Druckerkonfiguration und Hardware-Einstellungen lassen sich fest
vorgeben.
- Der Zugriff auf einzelne Funktionen der Benutzeroberflche kann einge-
schrnkt werden. Beispielsweise knnen die Befehle AUSFHREN,
SUCHEN und BEENDEN entfernt werden. Damit wird zum Beispiel ver-
hindert, dass Benutzer nach sicherheitsrelevanten Dateien oder Program-
men suchen und diese dann ggf. ausfhren. Die Laufwerke lassen sich aus
dem ARBEITSPLATZ und fr den EXPLORER (dem frheren Datei-
manager) ausblenden. Partitionen (Laufwerke) knnen dann ggf. nur noch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
aus Anwendungen heraus gewechselt werden, da standardmig nur die

Start-Partition (z. B. C:\) zur Verfgung steht.
- Der Programmstart von ausfhrbaren Dateien kann eingeschrnkt und die
DOS-Eingabeaufforderung deaktiviert werden. Die fr den einzelnen
Benutzer erlaubten Anwendungen lassen sich explizit vorgeben (z. B.
WINWORD.EXE, EXCEL.EXE und EXPLORER.EXE)
Zustzlich kann fr den Rechner gefordert werden, dass die Windows 95-
Anmeldekennwrter sowohl aus Buchstaben als auch aus Sonderzeichen oder
Zahlen bestehen mssen und welche Mindestlnge sie aufweisen sollen.
Programme, die beim Systemstart ausgefhrt werden sollen, lassen sich eben-
falls vorgeben.
Im folgenden wird in einzelnen Schritten gezeigt, wie Systemrichtlinien ange-
legt und aktiviert werden knnen und welche Restriktionen fr einen nicht
vernetzten Windows 95-Rechner Sicherheit bieten:
1. Anlegen einer Systemrichtliniendatei
Mit Hilfe des Systemrichtlinieneditors wird eine Systemrichtliniendatei
erzeugt. Ihr Name ist zwar beliebig, jedoch wird an dieser Stelle der Einfach-
heit halber der Name CONFIG.POL gewhlt. Dazu wird das Programm
POLEDIT.EXE aufgerufen, eine neue Datei angelegt und diese unter dem
Namen CONFIG.POL abgespeichert. Diese Datei enthlt automatisch Ein-
trge fr den Standardbenutzer und den Standardcomputer, die im nchsten
Schritt ggf. einzuschrnken sind. Fr den Administrator sind ebenfalls Ein-
trge fr den Computer und den Benutzer anzulegen (im Men BEARBEITEN
mit BENUTZER HINZUFGEN und COMPUTER HINZUFGEN), die im
dritten Schritt zu spezifizieren sind.
2. Definition einer Richtlinie fr den Standardbenutzer und Standard-

computer
ffnet man mit dem Systemrichtlinieneditor die Einstellungen fr den
Standardbenutzer, so kann man mengefhrt die entsprechenden sicherheits-
relevanten Eintrge vornehmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispielsweise:
Fr einen Standardbenutzer sollten folgende Restriktionen eingestellt

werden:
Systemsteuerung
- Der Zugriff auf die Registerkarte BILDSCHIRMSCHONER sollte dann
deaktiviert werden, wenn der Benutzer die Bildschirmsperre nicht deakti-
vieren knnen soll. In diesem Fall ist ihm allerdings die Mglichkeit zu
geben, das Bildschirmpasswort zu ndern. Dazu darf die SYSTEM-
STEUERUNG (s. u.) nicht vollstndig und bei der Option KENNWRTER
die Registerkarte KENNWORT NDERN nicht deaktiviert sein.
- Damit der Benutzer die Systemrichtlinien nicht deaktivieren kann, ist
zwingend die Registerkarte BENUTZERPROFILE fr die System-
steuerungsoption KENNWRTER auszublenden.
- Die Einstellungen fr die Hardware-Konfiguration sind vorzunehmen und
der Zugriff auf die Register und Schaltflchen fr die Systemsteue-
rungsoption SYSTEM maximal zu beschrnken, damit fehlerhafte Konfigu-
rationen durch den Benutzer vermieden werden, die die Verfgbarkeit oder
Leistungsfhigkeit des Rechners einschrnken knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Shell-Zugriffsbeschrnkungen
- Der Befehl AUSFHREN sollte deaktiviert werden, wenn verhindert
werden soll, dass bestimmte Programme unter Angaben von Optionen
gestartet werden knnen.
- Die SYSTEM- und DRUCKERSTEUERUNG kann vollstndig deaktiviert
werden, wenn man die Option ORDNER UNTER "EINSTELLUNGEN" IM
MEN "START" ENTFERNEN aktiviert. Dies ist immer dann notwendig,
wenn dem Benutzer jegliche Mglichkeit genommen werden soll, System-
oder Druckereinstellungen zu ndern. Damit der Benutzer sein
Bildschirmpasswort ndern kann, ist unter der Systemsteuerungsoption
ANZEIGE die Registerkarte BILDSCHIRMSCHONER (s. o.) freizugeben.
Der Benutzer kann dann durch Klicken mit der rechten Maustaste auf den
Desktop ber EIGENSCHAFTEN auf die Bildschirmsperre zugreifen.
- Soll die Benutzung des EXPLORERS nicht erlaubt sein, so ist die Option
LAUFWERKE IM FENSTER "ARBEITSPLATZ" AUSBLENDEN zu akti-
vieren, da der EXPLORER ber den ARBEITSPLATZ gestartet werden
kann, selbst wenn die Nutzung explizit verboten wurde.
System-Zugriffsbeschrnkungen
- Die Option PROGRAMME ZUM BEARBEITEN DER REGISTRIERUNG
DEAKTIVIEREN ist zu whlen.
Hinweis: Diese Option betrifft nur den Registrierungseditor
(REGEDIT.EXE). Mit dem Systemrichtlinien-Editor (POLEDIT.EXE) lsst
sich die lokale Registrierung nach wie vor bearbeiten. Dieses Programm
sollte daher von der Festplatte gelscht werden.
- Es sollten nur zugelassene Anwendungen ausfhrbar sein.
Es sind diejenigen Anwendungen, wie etwa WINWORD.EXE,
ACCESS.EXE, EXPLORER.EXE, einzutragen, die der Benutzer ausfhren
knnen soll.
- Die MS-DOS-Eingabeaufforderung ist zu deaktivieren.
- Ggf. sind Single-Mode-Anwendungen fr MS-DOS zu deaktivieren.
Falls einige DOS-Anwendungen unter Windows 95 aufgerufen werden
sollen, der Benutzer aber nicht auf die DOS-Ebene gelangen soll, ist die
DOS-Eingabeaufforderung zu aktivieren, jedoch sind bei den
zugelassenen Anwendungen fr Windows nur diejenigen zu nennen, die
bentigt werden. Die COMMAND.COM darf dann dort nicht genannt
werden.
Fr einen Standardcomputer sollten folgende Restriktionen eingestellt
werden:
Netzwerk
- Unter KENNWRTER ist ein alphanumerisches Windows-Anmeldekenn-
wort und eine Mindestlnge von sechs Zeichen zu fordern.
- Unter UPDATE ist REMOTE-UPDATE nicht zu deaktivieren, da sonst die
Systemrichtlininen nicht geladen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
System
- Die BENUTZERPROFILE sind zu aktivieren.
3. Definition einer Richtlinie fr den Administrator
In einer Richtlinie fr den Administrator sollten keine der obigen Restrik-
tionen gesetzt werden. Hierfr ist ein eigener Benutzer unter Windows 95
sowie ein Benutzer und Computer mittels Systemrichtlinien einzurichten, da
sonst fr ihn die ber den Standardbenutzer eingestellten Einschrnkungen
gelten. Das dazugehrige Passwort darf nur dem Administrator und seinem
Vertreter bekannt sein.
Diese Richtlinie ist ebenfalls in der Datei CONFIG.POL abzulegen.
4. Definition von Richtlinien fr einzelne Benutzer basierend auf dem
Standardbenutzer und Standardcomputer
Werden weitere Benutzer bentigt, deren Restriktionen sich von den unter 1.
spezifizierten unterscheiden sollen, so sind analog zu 1. diese Richtlinien
zustzlich in der Datei CONFIG.POL einzurichten. Dazu kopiert man das
Standardprofil, gibt diesem den Namen des betreffenden Benutzers und stellt
die Restriktionen wie unter 1. fr diesen Benutzer ein.
5. Aktivieren der Richtlinien
Beim Einrichten der Systemrichtlinien durch den Administrator ist besondere
Vorsicht und Aufmerksamkeit geboten, da sehr leicht inkonsistente System-
zustnde eingestellt werden knnen, die ein Arbeiten mit dem Rechner ver-
hindern. Das Betriebssystem wre neu zu installieren. Die Systemrichtlinien
sollten also nur dann aktiviert werden, wenn die Richtlinien mit uerster
Sorgfalt definiert wurden.
Dazu ffnet der Administrator mit dem Systemrichtlinieneditor
(POLEDIT.EXE) die lokale Registrierung und setzt dort fr den LOKALEN
COMPUTER unter der Option NETZWERK-UPDATE den Schalter REMOTE-
UPDATE. Als Update-Modus muss INTERAKTIV gewhlt werden. Der Pfad
fr die oben definierte CONFIG.POL ist ebenfalls anzugeben.
Die notwendigen Einstellungen knnen von besonders erfahrenen Administra-
toren auch mit dem Registrierungseditor (Programm REGEDIT.EXE)
vorgenommen werden.
Darber hinaus sind in der Programmgruppe SYSTEMSTEUERUNG mit der
Schaltflche KENNWRTER die Benutzerprofile zu aktivieren.
- Ist die Einschrnkung der Benutzerumgebung aus betrieblicher Sicht not-
wendig?
- Ist die Einschrnkung bestimmter Ressourcen notwendig?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.105 Beschaffung von TK-Anlagen

Verantwortlich fr Umsetzung: Haustechnik, Beschaffungsstelle
Bei der Beschaffung neuer TK-Anlagen besteht die Mglichkeit, diese von
vornherein so auszugestalten, dass im spteren Betrieb mit geringem
personellen und organisatorischen Zusatzaufwand ein hohes Ma an
Sicherheit erreicht werden kann. Hierfr muss in erster Linie auf
- das Vorhandensein geeigneter Funktionalitten fr die Anlagenadministra-
tion,
- ausreichende Protokollmechanismen und Auswerte-Tools sowie
- die Revisionsfhigkeit der TK-Anlage
geachtet werden. Fr den Bereich der Bundesbehrden wurden entsprechende
Anforderungen vom Bundesamt fr Sicherheit in der Informationstechnik
(BSI) in Zusammenarbeit mit dem Zentralverband der Elektrotechnik- und
Elektronikindustrie (ZVEI) erarbeitet und in der Broschre
Sicherheitsanforderungen an TK-Anlagen
- Empfehlungen fr den Bereich der Bundesbehrden -
zusammengefasst. Diese Empfehlungen sind aus Sicht des BSI auch auf
andere Bereich der Verwaltung und der Privatwirtschaft bertragbar.
Die Broschre befindet sich auf der CD-ROM zum IT-Grundschutzhandbuch
(siehe Anhang: Hilfsmittel).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.106 Auswahl geeigneter ISDN-Karten in der

Beschaffung
Verantwortlich fr Umsetzung: Administrator, Beschaffungsstelle
Bei der Beschaffung von ISDN-Karten besteht die Mglichkeit, diese von
vornherein so auszuwhlen, dass im spteren Betrieb Sicherheitsfunktiona-
litten nicht teuer hinzugekauft werden mssen. Erforderliche Sicher-
heitsfunktionalitten sollten bereits auf der Karte vorhanden sein oder durch
mitgelieferte Kommunikationssoftware und Treiberprogramme realisiert
werden knnen.
Mgliche Kriterien fr die Auswahl geeigneter ISDN-Karten sind:
- Fhigkeit zur Durchfhrung einer Authentisierung ber PAP und CHAP
(Password Authentikation Protocol und Challenge Handshake Authenti-
cation Protocol, RFC 1994),
- Vorhandensein eines Verschlsselungsverfahrens (symmetrisch/asymme-
trisch) in Hard- oder Software,
- Mglichkeit der Auswertung von CLIP-Rufnummern (Calling Line
Identification Presentation) zur Authentisierung,
- Mglichkeit des Fhrens einer Rufnummerntabelle fr das Durchfhren
eines Callbacks,
- Mglichkeit der Protokollierung nicht erfolgreicher Verbindungsaufbauten
(Ablehnung aufgrund falscher Rufnummern- oder PAP/CHAP-
Authentisierung).
Auerdem sind die ISDN-Karten auf Funktionalitten hin zu untersuchen, die
fr einen sicheren Betrieb nicht vorhanden sein drfen, oder falls sie dennoch
vorhanden sind, zumindest durch Konfiguration eine Deaktivierung herbeige-
fhrt werden kann. Hierzu zhlt z. B. die "Remote-Control"-Funktionalitt,
die einen direkten Kommunikationsaufbau zum IT-System aus dem
ffentlichen Netz zulsst.
Beachtet werden sollte, dass sowohl im Bereich der IT-Systeme, die mit
ISDN-Karten ausgestattet werden sollen, als auch im Bereich der
Netzkoppelelemente (z. B. ISDN-Router) ISDN-Karten mit mglichst
gleichen Sicherheitsfunktionalitten eingesetzt werden. Ist dies nicht
gewhrleistet, entfalten Sicherheitsfunktionalitten, die auf beiden Seiten
erforderlich sind, nicht die gewnschte Wirkung.
Ergnzende Kontrollfrage:
- Sind der Beschaffungsstelle diese ergnzenden Anforderungen an ISDN-
Karten bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.107 Dokumentation der ISDN-Karten-Konfiguration

Je nach Einsatzgebiet ergeben sich fr eine ISDN-Karte nahezu beliebig
komplexe Konfigurationseinstellungen. Fr das Sicherstellen eines geordneten
Wiederanlaufs (z. B. nach Austausch einer ISDN-Karte oder deren
Kommunikationssoftware) wird empfohlen, mindestens die folgenden Ein-
stellungen zu dokumentieren:
- Typenbezeichnung der eingesetzten Karte und Seriennummer,
- Rufnummer(n) fr den Kommunikationsaufbau und eine evtl. durchzu-
fhrende Authentisierung,
- Verwendetes D-Kanal-Protokoll (1TR6, EDSS-1 etc.),
- Verwendetes B-Kanal-Protokoll (X.25, PPP, TCP/IP, Bittransparent etc.),
- Stand der verwendeten CAPI-Version,
- Stand der verwendeten Treiber-Software,
- Art der Datenkompression, wenn verwendet,
- Art der Authentisierung (z. B. PAP/CHAP), wenn verwendet.
Beim Einsatz von Authentisierungsverfahren, die auf dem Besitz eines
gemeinsamen Geheimnisses (z. B. Passwort) beruhen, kann auch dieses
Geheimnis dokumentiert werden. Beachtet werden muss dann allerdings, dass
die erstellte Dokumentation nur einem eingeschrnkten Personenkreis
zugnglich gemacht werden darf, um das Bekanntwerden des Geheimnisses zu
verhindern.
- Sind in der Dokumentation Passwrter beschrieben? Wird die Dokumen-
tation sicher aufbewahrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.108 Verzicht auf Fernwartung der ISDN-

Netzkoppelelemente
Der Verzicht auf Fernwartung ist eine wirkungsvolle Manahme, um Externe
an Manipulationen an ISDN-Routern und IT-Systemen mit ISDN-Karten zu
hindern.
Bei IT-Systemen mit ISDN-Karte sollte berprft werden, ob die verwendete
Kommunikationssoftware "Remote-Control"-Funktionalitten bietet. Hier-
durch kann das betreffende IT-System ber das ffentliche ISDN angerufen
werden, die ISDN-Karte nimmt den Anruf entgegen und der Anrufende
bedient das IT-System so, als ob es "vor Ort" wre. Diese Funktionalitt ist zu
deaktivieren.
Bei ISDN-Routern sollte die Fernwartung ber reservierte Bandbreiten (oder
reservierte ISDN-Rufnummern) deaktiviert werden, da hier i. d. R. eine nur
ber ein Passwort geschtzte Verbindung zur Management Information Base
des Routers hergestellt wird, in der nahezu alle Konfigurationseinstellungen
vorgenommen werden knnen.
- Welche Grnde sprechen fr und welche gegen den Verzicht der Fern-
wartung?
- Wurde die Entscheidung ber die Fernwartung herbeigefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.109 Rechtevergabe fr den Fernzugriff

Der externe Zugriff auf ein Unternehmensnetz muss hinsichtlich der einge-
rumten Rechte auf das erforderlich Ma eingeschrnkt werden. ber die in
M 2.8 Vergabe von Zugriffsrechten beschriebenen Anforderungen ist weiter-
hin zu bercksichtigen, dass die Rechtevergabe fr den Fernzugriff noch
restriktiver zu handhaben ist.
Beispielsweise mssen fr einen Telearbeitsplatz nicht zwingend Zugriffs-
rechte auf Verzeichnisse mit Software bestehen (siehe G 5.62 Missbrauch von
Ressourcen ber abgesetzte IT-Systeme).
- Wann wurden die fr den Fernzugriff eingerumten Rechte zuletzt ber-
prft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.110 Datenschutzaspekte bei der Protokollierung

Verantwortlich fr Initiierung: Leiter IT, Datenschutzbeauftragter
Verantwortlich fr Umsetzung: Administrator, Datenschutzbeauftragter
Unter Protokollierung beim Betrieb von IT-Systemen ist im datenschutz-
rechtlichen Sinn die Erstellung von manuellen oder automatisierten Auf-
zeichnungen zu verstehen, aus denen sich die Fragen beantworten lassen:
"Wer hat wann mit welchen Mitteln was veranlasst bzw. worauf zugegriffen?"
Auerdem mssen sich Systemzustnde ableiten lassen: "Wer hatte von wann
bis wann welche Zugriffsrechte?"
Art und Umfang von Protokollierungen hngen vom allgemeinen Daten-
schutzrecht und auch von bereichsspezifischen Regelungen ab.
Die Protokollierung der Administrationsaktivitten entspricht einer System-
berwachung, whrend die Protokollierung der Benutzeraktivitten im
wesentlichen der Verfahrensberwachung dient. Dementsprechend finden sich
die Anforderungen an die Art und den Umfang der systemorientierten
Protokollierung berwiegend im allgemeinen Datenschutzrecht, whrend die
verfahrensorientierte Protokollierung oft durch bereichsspezifische Rege-
lungen definiert wird. Beispiele fr verfahrensorientierte Protokollierung sind
u. a. Meldegesetze, Polizeigesetze, Verfassungsschutzgesetze.
Mindestanforderungen an die Protokollierung
Bei der Administration von IT-Systemen sind die folgenden Aktivitten voll-
stndig zu protokollieren:
- Systemgenerierung und Modifikation von Systemparametern
Da auf dieser Ebene in der Regel keine systemgesteuerten Protokolle
erzeugt werden, bedarf es entsprechender detaillierter manueller
Aufzeichnungen, die mit der Systemdokumentation korrespondieren
sollten.
- Einrichten von Benutzern
Wem von wann bis wann durch wen das Recht eingerumt worden ist, das
betreffende IT-System zu benutzen, ist vollstndig zu protokollieren. Fr
diese Protokolle sollten lngerfristige Aufbewahrungszeitrume vorge-
sehen werden, da sie Grundlage praktisch jeder Revisionsmanahme sind.
- Erstellung von Rechteprofilen
Im Rahmen der Protokollierung der Benutzerverwaltung kommt es insbe-
sondere auch darauf an aufzuzeichnen, wer die Anweisung zur Einrichtung
bestimmter Benutzerrechte erteilt hat (siehe auch M 2.31 Dokumentation
der zugelassenen Benutzer und Rechteprofile).
- Einspielen und nderung von Anwendungssoftware
Die Protokolle reprsentieren das Ergebnis der Programm- und Verfah-
rensfreigaben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- nderungen an der Dateiorganisation

Im Hinblick auf die vielfltigen Manipulationsmglichkeiten, die sich
bereits bei Benutzung der "Standard-Dateiverwaltungssysteme" ergeben,
kommt einer vollstndigen Protokollierung eine besondere Bedeutung zu
(vgl. z. B. Datenbankmanagement).
- Durchfhrung von Datensicherungsmanahmen
Da derartige Manahmen (Backup, Restore) mit der Anfertigung von
Kopien bzw. dem berschreiben von Datenbestnden verbunden sind und
hufig in "Ausnahmesituationen" durchgefhrt werden, besteht eine
erhhte Notwendigkeit zur Protokollierung.
- Sonstiger Aufruf von Administrations-Tools
Die Benutzung aller Administrations-Tools ist zu protokollieren, um fest-
stellen zu knnen, ob Unbefugte sich Systemadministrator-Rechte erschli-
chen haben.
- Versuche unbefugten Einloggens und berschreitung von Befugnissen
Geht man von einer wirksamen Authentisierungsprozedur und sachge-
rechten Befugniszuweisungen aus, kommt der vollstndigen Protokollie-
rung aller "aufflligen Abnormalitten" beim Einloggen und der Benutzung
von Hard- und Software-Komponenten eine zentrale Bedeutung zu.
Benutzer in diesem Sinne ist auch der Systemadministrator.
Bei der Verarbeitung von personenbezogenen Daten sind folgende Benutzer-
aktivitten in Abhngigkeit von der Sensibilitt der Verfahren bzw. Daten
vollstndig bzw. selektiv zu protokollieren:
- Eingabe von Daten
Die so genannte Eingabekontrolle erfolgt grundstzlich verfahrensorientiert
(z. B. Protokollierung in Akten, soweit vorhanden, Protokollierung direkt
im Datenbestand, sofern keine Akten gefhrt werden). Auch wenn man
davon ausgeht, dass Befugnisberschreitungen anderweitig protokolliert
werden, drfte eine vollstndige Protokollierung von Dateneingaben als
Regelfall angesehen werden mssen.
- Datenbermittlungen
Nur soweit nicht gesetzlich eine vollstndige Protokollierung vorgeschrie-
ben ist, kann eine selektive Protokollierung als ausreichend angesehen
werden.
- Benutzung von automatisierten Abrufverfahren
In der Regel drfte eine vollstndige Protokollierung der Abrufe und der
Grnde der Abrufe (Vorgang, Aktenzeichen etc.) erforderlich sein, um
unbefugte Kenntnisnahme im Rahmen der grundstzlich eingerumten
Zugriffsrechte aufdecken zu knnen.
- Lschung von Daten
Die Durchfhrung der Lschung ist zu protokollieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Aufruf von Programmen

Dies kann erforderlich sein bei besonders "sensiblen" Programmen, die
z. B. nur zu bestimmten Zeiten oder Anlssen benutzt werden drfen.
Deshalb ist in diesen Fllen eine vollstndige Protokollierung angezeigt.
Die Protokollierung dient auch der Entlastung der befugten Benutzer
(Nachweis des ausschlielich befugten Aufrufs der Programme).
Zweckbindung bei der Nutzung von Protokolldaten
Protokolldaten unterliegen aufgrund der nahezu bereinstimmenden Regelun-
gen im Datenschutzrecht des Bundes und der Lnder einer besonderen engen
Zweckbindung (z. B. 14 Abs. 4 und 31 BDSG, 13 Abs. 5 HDSG). Sie
drfen nur zu den Zwecken genutzt werden, die Anlass fr ihre Speicherung
waren. Dies sind in der Regel die in einem Sicherheitskonzept festgelegten
allgemeinen Kontrollen, die in den meisten Datenschutzgesetzen geforderte
"berwachung der ordnungsgemen Anwendung der Datenverarbeitungs-
programme, mit denen personenbezogene Daten verarbeitet werden " (vgl.
z. B. 18 Abs. 2 BDSG, 8 Abs. 3 LDSG-SH) und die Kontrollen durch
interne oder externe Datenschutzbeauftragte. Nur in Ausnahmefllen lassen
die bereichsspezifischen Regelungen die Nutzung dieser Daten fr andere
Zwecke, z. B. zur Strafverfolgung, zu.
Aufbewahrungsdauer
Soweit nicht bereichsspezifische Regelungen etwas anderes vorsehen, richtet
sich die Aufbewahrungsdauer der Protokolle nach den allgemeinen
Lschungsregeln der Datenschutzgesetze. Mastab ist die "Erforderlichkeit
zur Aufgabenerfllung". Gibt es keinen zwingenden Grund fr das weitere
Vorhalten von Protokolldateien, besteht eine Lschungspflicht (vgl. z. B. 20
Abs. 2 BDSG).
Als Anhaltspunkte knnen dienen:
- die Wahrscheinlichkeit, dass Unregelmigkeiten (noch) offenbar werden
knnen und
- die Mglichkeit, die Grnde von Unregelmigkeiten anhand der Proto-
kolle und anderer Unterlagen aufdecken zu knnen.
Erfahrungsgem sollte eine Frist von einem Jahr nicht berschritten werden.
Soweit Protokolle zum Zwecke gezielter Kontrollen angefertigt werden,
kommen krzere Speicherungsfristen in Betracht. In der Regel reicht eine
Aufbewahrung bis zur tatschlichen Kontrolle aus. Auch hier sind die
bereichsspezifischen Vorschriften zu beachten.
Technische und organisatorische Rahmenbedingungen
Die Effektivitt der Protokollierung und ihre Auswertung im Rahmen von
Kontrollen hngt im entscheidenden Mae von den technischen und organisa-
torischen Rahmenbedingungen ab. In diesem Zusammenhang sollten folgende
Aspekte Bercksichtigung finden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Es sollte ein Revisionskonzept erstellt werden, das den Zweck der Proto-
kolle und deren Kontrollen sowie Schutzmechanismen fr die Rechte der
Mitarbeiter und der sonstigen betroffenen Personen klar definiert.
- Die Zwangslufigkeit und damit die Vollstndigkeit der Protokolle muss
ebenso gewhrleistet werden wie die Manipulationssicherheit der Eintrge
in Protokolldateien.
- Entsprechend der Zweckbindung der Datenbestnde mssen wirksame
Zugriffsbeschrnkungen realisiert werden.
- Die Protokolle mssen so gestaltet sein, dass eine effektive berprfung
mglich ist. Dazu gehrt auch eine IT-Untersttzung der Auswertung.
- Die Auswertungsmglichkeiten sollten vorab abgestimmt und festgelegt
sein.
- Kontrollen sollten so zeitnah durchgefhrt werden, dass bei aufgedeckten
Versten noch Schden abgewendet sowie Konsequenzen gezogen
werden knnen. Kontrollen mssen rechtzeitig vor dem Ablauf von
Lschungsfristen von Protokolldateien stattfinden.
- Kontrollen sollten nach dem 4-Augen-Prinzip erfolgen.
- Es sollte vorab definiert werden, welche Konsequenzen sich aus Versten
ergeben, die durch die Kontrolle von Protokollen aufgedeckt werden.
- Die Mitarbeiter sollten darber informiert sein, dass Kontrollen durchge-
fhrt werden, ggf. auch unangekndigt.
- Fr Routinekontrollen sollten automatisierte Verfahren (z. B. watch dogs)
verwendet werden.
- Personal- bzw. Betriebsrte sollten bei der Erarbeitung des Revisionskon-
zeptes und bei der Festlegung der Auswertungsmglichkeiten der Proto-
kolle beteiligt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.111 Bereithalten von Handbchern

Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsmanagement
Bei der Beschaffung von Informationstechnik, egal ob es sich um Hardware
oder Software handelt, mssen die zugehrigen Handbcher und technischen
Referenzen in ausreichender Anzahl mitbeschafft werden.
Im Lieferumfang von IT-Produkten ist zunehmend keine weiterfhrende
Dokumentation mehr enthalten, sondern es werden neben Online-Hilfen nur
noch Installationshilfen und einfhrende Texte mitgeliefert. Dieser einge-
schrnkte Umfang an Dokumentationshilfen ist insbesondere bei auftretenden
Fehlern unzureichend. Es ist daher darauf zu achten, dass die erforderlichen
Handbcher, technische Referenzen und Fehlerkataloge zustzlich beschafft
werden. Hierbei muss nicht ausschlielich auf die vom Hersteller angebotene
Literatur zurckgegriffen werden.
Alle Handbcher zu einem IT-Produkt mssen jederzeit in der Anwendungs-
umgebung verfgbar sein. Beispielweise mssen die Handbcher zu einem
Server-Betriebssystem bei diesem Server aufbewahrt werden, und nicht in
einer evtl. geschlossenen Bibliothek. Bei der Notfallplanung ist der Zugriff auf
diese Literatur einzuplanen (siehe M 6.3 Erstellung eines Notfall-
Handbuches).
Kontrollfragen:
- Welche Handbcher gibt es zu den eingesetzten IT-Produkten?
- Wo werden die Handbcher verwahrt? Sind sie jederzeit verfgbar?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.112 Regelung des Akten- und Datentrgertransports

zwischen huslichem Arbeitsplatz und
Institution
Damit der Austausch von Akten und Datentrgern zwischen huslichem
Arbeitsplatz und Institution sicher vollzogen werden kann, ist eine Regelung
ber Art und Weise des Austauschs aufzustellen. Darin sollten zumindest
folgende Punkte betrachtet bzw. geregelt werden:
- welche Akten/Datentrger ber welchen Transportweg (Postweg, Kurier,
Paketdienst, ...) ausgetauscht werden drfen (vgl. M 5.23 Auswahl einer
geeigneten Versandart fr den Datentrger),
- welche Schutzmanahmen sind beim Transport zu beachten. Beispiele
dazu sind:
- geschlossener Behlter,
- Versandtasche,
- Einschreiben,
- Wertbrief,
- Begleitschreiben und
- Versiegelung.
- welche Akten/Datentrger nur persnlich transportiert werden drfen.
Da Schriftstcke, Dokumente und Akten oftmals Unikate sind, muss bei der
Auswahl eines geeigneten Aktenaustauschverfahrens beachtet werden,
welchen Schaden der Verlust bedeuten wrde. Hingegen kann beim Daten-
trgeraustausch vorab eine Datensicherung erfolgen.
- Sind betroffene Mitarbeiter darber informiert, wie Akten- und Datentrger
zu transportieren sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.113 Regelungen fr Telearbeit

Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, Leiter
Personal
Verantwortlich fr Umsetzung: Personalabteilung, Vorgesetzte
Da es bisher kein "Telearbeitsgesetz" mit eigenstndigen gesetzlichen
Regelungen gibt, sollten einige Punkte entweder durch Tarifvertrge,
Betriebsvereinbarungen oder zustzlich zum Arbeitsvertrag getroffene
individuelle Vereinbarungen zwischen Telearbeiter und Arbeitgeber geklrt
werden. Darin sollten unter anderem die Punkte "Freiwilligkeit der Teilnahme
an der Telearbeit", "Mehrarbeit und Zuschlge", "Aufwendungen fr Fahrten
zwischen Betrieb und huslicher Wohnung", "Aufwendungen z. B. fr Strom
und Heizung", "Haftung (bei Diebstahl oder Beschdigung der IT, aber auch
bei Arbeitsunfall oder Berufskrankheit)" und "Beendigung der Telearbeit"
geklrt bzw. geregelt werden.
Im Sinne der IT-Sicherheit sollten zustzlich folgende Punkte behandelt
werden:
- Arbeitszeitregelung: die Verteilung der Arbeitszeiten auf Ttigkeiten in
der Institution und am huslichen Arbeitsplatz muss geregelt sein und feste
Zeiten der Erreichbarkeit am huslichen Arbeitsplatz mssen festgelegt
werden.
- Reaktionszeiten: es sollte geregelt werden, in welchen Abstnden aktuelle
Informationen eingeholt werden (z. B. wie hufig E-Mails gelesen werden)
und wie schnell darauf reagiert werden sollte.
- Arbeitsmittel: es kann festgeschrieben werden, welche Arbeitsmittel der
Telearbeiter einsetzen kann und welche nicht genutzt werden drfen (z. B.
nicht freigegebene Software). So kann ein E-Mail-Anschluss zur
Verfgung gestellt werden, aber die Nutzung von anderen Internet-
Diensten wird untersagt. Weiterhin kann die Benutzung von Disketten
(Gefahr von Computer-Viren) untersagt werden, wenn der
Telearbeitsrechner dies nicht erfordert.
- Datensicherung: der Telearbeiter ist zu verpflichten, regelmig eine
Datensicherung durchzufhren. Darber hinaus sollte vereinbart werden,
dass jeweils eine Generation der Datensicherung bei der Institution zur
Untersttzung der Verfgbarkeit hinterlegt wird.
- IT-Sicherheitsmanahmen: der Telearbeiter ist zu verpflichten, die fr
die Telearbeit notwendigen IT-Sicherheitsmanahmen zu beachten und zu
realisieren. Die umzusetzenden IT-Sicherheitsmanahmen sind dem
Telearbeiter in schriftlicher Form zu bergeben.
- Datenschutz: der Telearbeiter ist auf die Einhaltung einschlgiger Daten-
schutzvorschriften zu verpflichten sowie auf die notwendigen Manahmen
bei der Bearbeitung von personenbezogenen Daten am huslichen Arbeits-
platz hinzuweisen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Datenkommunikation: es muss festgelegt werden, welche Daten auf

welchem Weg bertragen bzw. welche Daten nicht oder nur verschlsselt
elektronisch bermittelt werden drfen.
- Aktentransport: die Art und Absicherung des Aktentransports zwischen
huslichem Arbeitsplatz und Institution ist zu regeln.
- Meldeweg: der Telearbeiter ist zu verpflichten, IT-sicherheitsrelevante
Vorkommnisse unverzglich an eine zu bestimmende Stelle in der
Institution zu melden.
- Zutrittsrecht zum huslichen Arbeitsplatz: fr die Durchfhrung von
Kontrollen und fr die Verfgbarkeit von Akten und Daten im Vertretungs-
fall kann ein Zutrittsrecht zum huslichen Arbeitsplatz (ggf. mit vorheriger
Anmeldung) vereinbart werden.
- Ist dem Telearbeiter der vereinbarte Rahmen seiner Ttigkeit bekannt?
- Wird dem Telearbeiter ein Informationsblatt darber ausgehndigt?
- Wird dem Telearbeiter ein Merkblatt ausgehndigt, in dem die von ihm zu
beachtenden IT-Sicherheitsmanahmen erlutert werden? Wann wurde das
Merkblatt zuletzt aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.114 Informationsfluss zwischen Telearbeiter und

Institution
Verantwortlich fr Initiierung: Vorgesetzte, Telearbeiter
Verantwortlich fr Umsetzung: Vorgesetzte, Telearbeiter
Damit der Telearbeiter nicht vom betrieblichen Geschehen abgeschnitten wird,
sollte der Vorgesetzte einen regelmigen Informationsaustausch zwischen
dem Telearbeiter und den Arbeitskollegen ermglichen. Dies ist wichtig,
damit der Telearbeiter auch zuknftig ber Planungen und Zielsetzungen in
seinem Arbeitsbereich informiert ist, damit Frustrationen vermieden und ein
positives Telearbeitsklima geschaffen wird und erhalten bleibt.
Die Beteiligung der Telearbeiter an Umlaufverfahren fr Hausmitteilungen,
einschlgige Informationen und Zeitschriften ist zu regeln. Dies stellt dann ein
Problem dar, wenn der Telearbeiter ausschlielich zu Hause arbeitet. Eine
Lsung wre eventuell das Einscannen wichtiger Schriftstcke, um sie dann
dem Telearbeiter per E-Mail zuzustellen. Zustzlich ist der Telearbeiter ber
nderungen von IT-Sicherheitsmanahmen zu unterrichten.
Weiterhin mssen die Arbeitskollegen ber die Anwesenheits- und Erreich-
barkeitszeiten und die E-Mail-Adresse bzw. Telefonnummer des Telearbeiters
in Kenntnis gesetzt werden.
Folgende Punkte mssen darber hinaus bei der Telearbeit geklrt werden:
- Wer ist Ansprechpartner bei technischen und/oder organisatorischen bei
Problemen in der Telearbeit?
- Wem mssen Sicherheitsvorkommnisse mitgeteilt werden?
- Wie erfolgt die Aufgabenzuteilung?
- Wie erfolgt die bergabe der Arbeitsergebnisse?
Treten technisch-organisatorische Probleme auf, mssen diese vom Tele-
arbeiter unverzglich der Institution gemeldet werden.
- Wie erfhrt der Telearbeiter dienstliche Informationen?
- Wem meldet ein Telearbeiter Sicherheitsvorkommnisse?
- Gibt es einen Ansprechpartner (unabhngig vom Vorgesetzten) fr die
Telearbeiter?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.115 Betreuungs- und Wartungskonzept fr Tele-

arbeitspltze
Verantwortlich fr Umsetzung: Leiter IT, Administrator, Telearbeiter
Fr die Telearbeitspltze muss ein spezielles Betreuungs- und Wartungs-
konzept erstellt werden, das folgende Punkte vorsieht:
- Benennen von probelembezogenen Ansprechpartnern fr den
Benutzerservice: an diese Stelle wendet sich der Telearbeiter bei Soft-
ware- und Hardware-Problemen. Der Benutzerservice versucht (auch tele-
fonisch) kurzfristig Hilfestellung zu leisten bzw. leitet Wartungs- und
Reparaturarbeiten ein.
- Wartungstermine: die Termine fr vor Ort durchzufhrende Wartungs-
arbeiten sollten frhzeitig bekanntgegeben werden, damit die Telearbeiter
zu diesen Zeiten den Zutritt zum huslichen Arbeitsplatz gewhrleisten
knnen.
- Einfhrung von Standard-Telearbeitsrechnern: es sollten alle Tele-
arbeiter einer Institution einen definierten Standard-Telearbeitsrechner
haben, damit Problemlsungen fr den Benutzerservice erleichtert werden.
Dies erleichtert ebenso den konzeptionellen und administrativen Aufwand
fr den Aufbau eines sicheren Telearbeitsrechners.
- Fernwartung: falls der Telearbeitsrechner ber Fernwartung administriert
und gewartet werden kann, sind die notwendigen Sicherheitsmanahmen
sowie die erforderlichen online-Zeiten zu vereinbaren. Insbesondere ist ein
Sicherungsverfahren festzulegen, um den Missbrauch eines Fernwartungs-
zugangs zu verhindern (vgl. M 5.33 Absicherung der per Modem durch-
gefhrten Fernwartung).
- Transport der IT: es sollte aus Grnden der Haftung festgelegt werden,
wer autorisiert ist, die IT zwischen Institution und huslichen Arbeitsplatz
des Telearbeiters zu transportieren.
Weitere Regelungen knnen der Manahme M 2.4 Regelungen fr Wartungs-
und Reparaturarbeiten entnommen werden.
- Sind dem Telearbeiter die Ansprechpartner fr Hard- und Software-
probleme bekannt?
- Ist dem Benutzer-Service die Konfiguration eines Standard-Telearbeits-
rechners bekannt?
- Ist dem Benutzer-Service die Adresse des Telearbeiters bekannt, damit er
schnell vor Ort helfen kann?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.116 Geregelte Nutzung der

Kommunikationsmglichkeiten
Verantwortlich fr Umsetzung: Administrator, Telearbeiter
Grundstzlich verfgt ein Telearbeitsrechner ber elektronische Kommuni-
kationsmglichkeiten. Im Sinne der IT-Sicherheit muss geregelt werden, auf
welche Weise die vorhandenen Kommunikationsmglichkeiten genutzt
werden drfen. Grundstzlich sollte die private Nutzung der Kommuni-
kationsmglichkeiten untersagt werden.
Zu klren sind zumindest folgende Punkte:
- Datenflusskontrolle
- Welche Dienste drfen zur Datenbertragung genutzt werden?
- Welche Dienste drfen explizit nicht genutzt werden?
- Welche Informationen drfen an wen versendet werden?
- Welcher Schriftverkehr darf ber E-Mail abgewickelt werden?
- Falls der Telearbeitsrechner ein Faxmodem besitzt oder wenn am
Telearbeitsplatz ein Faxgert vorhanden ist, so ist zu klren, welche
Informationen per Fax an wen bermittelt werden drfen.
- Der elektronische Versand welcher Informationen bedarf der vor-
herigen Zustimmung der Institution?
- Informationsgewinnung
- Welche elektronischen Dienstleistungen (Datenbankabfragen, elek-
tronische Recherchen) drfen vom Telearbeitsrechner aus in
Anspruch genommen werden? Beispielsweise knnen aus der Art
der Abfragen u. U. Rckschlsse auf Unternehmensstrategien gezo-
gen werden.
- Welches Budget steht fr elektronische Dienstleistungen zur Verf-
gung?
- IT-Sicherheitsmanahmen
- Fr welche Daten sollen welche Verschlsselungsverfahren einge-
setzt werden?
- Fr welche Daten ist eine Lschung nach erfolgreicher bertragung
notwendig? Dies kann beispielsweise fr personenbezogene Daten
gelten.
- Von welchen Daten soll trotz der erfolgreichen bertragung eine
Kopie der Daten auf dem Telearbeitsrechner verbleiben?
- Wird vor Versand oder nach Erhalt von Daten ein Computer-Viren-
Check der Daten durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Fr welche Datenbertragung eine Protokollierung erfolgen soll?

Falls eine automatische Protokollierung nicht mglich sein sollte, ist
festzulegen, ob und in welchem Umfang eine handschriftliche Proto-
kollierung vorzusehen ist.
- Internet-Nutzung
- Wird die Nutzung von Internet-Dienst generell verboten?
- Welche Art von Daten darf aus dem Internet geladen werden?
Werden Daten von fremden Servern geladen, so besteht die Gefahr,
dass Computer-Viren importiert werden.
- Welche Optionen drfen im Internet-Browser aktiviert werden?
- Welche Sicherungsverfahren sollen im Internet-Browser aktiviert
werden?
- Ist die Zustimmung der Institution erforderlich, wenn der Tele-
arbeiter sich am Informationsaustausch mittels Newsgruppen
beteiligen will? Ggf. ist eine anonyme Nutzung erforderlich.
- Unterschriftenregelung
- Ist eine Unterschriftenregelung fr die Kommunikation vorgesehen?
- Werden gesetzkonforme digitale Signaturen eingesetzt?
- Werden andere Authentisierungsverfahren fr den Schriftverkehr
genutzt?
- Ist der Telearbeiter ber die Regelungen bzgl. der Nutzung der Kommuni-
kationsmglichkeiten informiert?
- Besttigt der Telearbeiter die Belehrung ber die Nutzung der Kommuni-
kationsmglichkeiten durch eine Unterschrift?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.117 Regelung der Zugriffsmglichkeiten des

Telearbeiters
Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Vorgesetzte
Verantwortlich fr Umsetzung: Administrator, Vorgesetzte
Erfordert die Telearbeit den Zugriff auf die IT der Institution (zum Beispiel
auf einen Server), muss zuvor festgelegt werden, welche Objekte (Daten, IT)
der Telearbeiter tatschlich fr die Erfllung seiner Aufgaben bentigt. Ent-
sprechend sind die notwendigen Rechte wie Lese- und Schreibrechte auf diese
Objekte zuzuweisen. Auf Objekte, die der Telearbeiter fr seine Aufga-
benwahrnehmung nicht braucht, sollte er auch nicht zugreifen knnen. Dies
gilt sowohl fr den Zugriff auf Daten wie auf in der Institution verfgbare IT.
Damit soll erreicht werden, dass der Schaden, der aufgrund eines Hacker-
Angriffs auf den Kommunikationsrechner entstehen kann, minimiert wird. Fr
die Erteilung der Zugangs- und Zugriffsrechte siehe M 2.7 Vergabe von
Zugangsberechtigungen und M 2.8 Vergabe von Zugriffsrechten.
- Ist dem Administrator bekannt, auf welche Objekte der Telearbeiter
zugreifen darf?
- Welche Voraussetzungen mssen vor einer Vergabe oder nderungen von
Zugriffsrechten erfllt sein?
- Ist der Server so administriert, dass der Telearbeiter nur auf die erlaubten
Objekte zugreifen kann?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.118 Konzeption der sicheren E-Mail-Nutzung

Bevor E-Mailsysteme fr die Nutzung freigeben werden, sollte festgelegt
werden, fr welchen Einsatzzweck und welche Informationen E-Mail
vorgesehen ist. Abhngig davon, wofr E-Mail eingesetzt werden soll,
unterscheiden sich auch die Ansprche an Vertraulichkeit, Verfgbarkeit, In-
tegritt und Verbindlichkeit der zu bertragenden Daten sowie des eingesetz-
ten E-Mail-Programms. Es muss geklrt werden, ob ber E-Mail ausschlie-
lich unverbindliche oder informelle Informationen weitergegeben werden sol-
len oder ob einige oder sogar alle der bisher schriftlich bearbeiteten Geschfts-
vorflle nun per E-Mail durchgefhrt werden sollen. Bei letzterem ist zu kl-
ren, wie Anmerkungen an Vorgngen wie Verfgungen, Abzeichnungen oder
Schlusszeichnungen, die bisher handschriftlich angebracht wurden, elektro-
nisch abgebildet werden sollen.
Bei der Konzeption der E-Mail-Nutzung muss auch festgelegt werden, ob und
wie kryptographische Sicherungsmechanismen zu implementieren sind (siehe
dazu auch M 5.108 Kryptographische Absicherung von E-Mail und M 5.110
Absicherung von E-Mail mit SPHINX (S/MIME)).
Die Institution muss darauf aufbauend eine E-Mail-Richtlinie festlegen, in der
folgende Punkte beschrieben sind:
- wer einen E-Mail-Anschluss erhlt,
- die Regelungen, die von den E-Mail-Administratoren und den E-Mail-Be-
nutzern zu beachten sind,
- bis zu welchem Anspruch an Vertraulichkeit oder Integritt Informationen
per E-Mail versandt werden drfen,
- welche Handbcher beschafft werden,
- wie die Benutzer geschult werden und
- wie jederzeit technische Hilfestellung fr die Benutzer gewhrleistet wird.
Durch organisatorische Regelungen oder durch die technische Umsetzung sind
dabei insbesondere die folgenden Punkte zum ordnungsgemen Dateitransfer
zu gewhrleisten:
- Die E-Mail-Progamme der Benutzer mssen durch den Administrator so
vorkonfiguriert sein, dass ohne weiteres Zutun der Benutzer maximale
Sicherheit erreicht werden kann (siehe auch M 5.57 Sichere Konfiguration
der Mail-Clients).
- Die bermittlung von Daten darf erst nach erfolgreicher Identifizierung
und Authentisierung des Senders beim bertragungssystem mglich sein.
- Die Benutzer mssen vor erstmaliger Nutzung von E-Mail in die Hand-
habung der relevanten Applikationen eingewiesen werden. Die organi-
sationsinternen Benutzerregelungen zu Dateibermittlung muss ihnen
bekannt sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zur Beschreibung des Absenders werden bei E-Mails so oft genannte

Signatures (Absenderangaben) an das Ende der E-Mail angefgt. Der
Inhalt einer Signature sollte dem eines Briefkopfs hneln, also Name,
Organisationsbezeichnung und Telefonnummer und hnliches enthalten.
Diese Signature darf jedoch weder mit einer Signatur im Sinne einer (ein-
gescannten) Unterschrift noch mit einer elektronischen Signatur, die die
Korrektheit und Authentizitt des Textinhaltes belegt, verwechselt werden.
Eine Signature sollte nicht zu umfangreich sein. Die Behrde bzw. das
Unternehmen sollte einen Standard fr die einheitliche Gestaltung von
Signatures festlegen.
- Von den eingesetzten Sicherheitsmechanismen hngt es ab, bis zu welchem
Vertraulichkeits- bzw. Integrittsanspruch Dateien per E-Mail versandt
werden drfen. Es sollte geregelt werden, ob und wann bertragene
Dateien verschlsselt bzw. digital signiert werden mssen (siehe auch
M 4.34 Einsatz von Verschlsselung, Checksummen oder Digitalen
Signaturen). Es ist zentral festzulegen, welche Applikationen fr die Ver-
schlsselung bzw. den Einsatz von Digitalen Signaturen von den Benutzern
zu verwenden sind. Diese mssen den Benutzern zur Verfgung gestellt
werden, die wiederum in deren Anwendung unterwiesen werden mssen.
- Es sollte vor der Einfhrung elektronischer Kommunikationssysteme fest-
gelegt werden, unter welchen Bedingungen ein- oder ausgehende E-Mails
zustzlich ausgedruckt werden mssen.
- Die Dateibertragung kann (optional) dokumentiert werden. Fr jede
stattgefundene bermittlung ist dann in einem Protokoll festzuhalten, wer
wann welche Informationen erhalten hat. Bei der bertragung personen-
bezogener Daten sind die gesetzlichen Vorgaben zur Protokollierung zu
beachten.
E-Mails, die intern versandt werden, drfen das interne Netz nicht verlassen.
Dies ist durch entsprechende administrative Manahmen sicherzustellen.
Beispielsweise sollte die bertragung von E-Mails zwischen verschiedenen
Liegenschaften einer Organisation ber eigene Standleitungen und nicht ber
das Internet erfolgen.
Grundstzlich sollten Nachrichten, die an interne Adressen verschickt wurden,
nicht an externe Adressen weitergeleitet werden. Sollen hiervon Ausnahmen
gemacht werden, sind alle Mitarbeiter darber zu informieren. Beispielsweise
kann fr Auendienstmitarbeiter oder andere Mitarbeiter, die viel unterwegs
sind, die E-Mail an externe Zugriffspunkte weitergeleitet werden.
Es wird immer wieder diskutiert, ob und in wieweit dienstliche E-Mail-Zugn- Private Nutzung
dienstlicher E-Mail-
ge fr private Zwecke benutzt werden drfen. Solange die private Nutzung Zugnge
sich in Grenzen hlt, wird dies sogar von vielen Organisationen untersttzt, da
die Mitarbeiter dadurch eine positivere Einstellung zu E-Mail bekommen.
Generell empfiehlt es sich aber, hierzu in der E-Mail-Richtlinie zu vereinba-
ren, welche Spielregeln bei der E-Mail-Nutzung allgemein und auch hinsicht-
lich privater Nutzung einzuhalten sind.
Bei der Nutzung von E-Mail in Institutionen sollte auch festgelegt, welche
E-Mail-Programme eingesetzt werden sollen. Neben unterschiedlicher
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Funktionalitt hat die Auswahl der E-Mail-Clients und -Server auch Einfluss
auf die Benutzungsfreundlichkeit und den Administrationsaufwand, aber auch
auf die Sicherheit der gesamten IT-Umgebung. Neben eigenstndigen Client-
Programmen kann auch auf Webmail zurckgegriffen werden.
Als Webmail werden Angebote bezeichnet, bei denen ber einen Browser auf Webmail
webbasierte E-Mail-Dienste zugegriffen wird. Verschiedene Anbieter von
Mailservern bieten entsprechende Erweiterungen entweder direkt in ihr Pro-
dukt integriert oder als Zusatzmodule an. Webmail hat den Vorteil, dass hier-
bei von jedem Rechner mit Internet-Anschluss weltweit auf die E-Mail-Post-
fcher zugegriffen werden kann, ohne dass hierfr in aufwendige Infrastruktur
investiert werden muss. Es ist allerdings schwieriger als beim Transport ber
die internen E-Mail-Server, die organisationsweit gltigen Sicherheitsricht-
linien durchzusetzen, beispielsweise im Hinblick auf Virenschutz oder Ver-
schlsselung. Auerdem ist die Gefahr, dass vertrauliche E-Mails mitgelesen
oder Passwrter abgehrt werden, beim externen Zugriff auf Webmailzugnge
wesentlich hher.
Bei der Nutzung von Webmail aus einem Behrden- bzw. Unternehmensnetz Webmail und
Virenschutz
heraus muss unbedingt der Virenschutz beachtet werden. Bei aktuellen Viren-
warnungen kann es einige Zeit in Anspruch nehmen, die neuen Virenschutz-
Updates auf alle Clients aufzuspielen. In einer solchen Situation kann es sinn-
voll sein, den Zugriff auf Webmail zumindest, solange zu verhindern, bis die
Verantwortlichen fr Virenschutz sicher sind, dass ein ausreichender Schutz
besteht.
Der Umgang mit Webmail in der Behrde bzw. dem Unternehmen sollte
daher geregelt sein. Hierbei gibt es mehrere Varianten:
- Organisationen knnen beschlieen, die Nutzung von Webmail generell zu
verbieten. Dies muss dann natrlich den Mitarbeitern bekannt gegeben
werden. Das Verbot kann auerdem technisch durch Filterung bezglich
der bekannten Anbieter untersttzt werden, wobei man sich hier darber
klar sein sollte, dass Benutzer immer neue Wege finden knnen, um auf
solche Dienste zuzugreifen.
- Es kann die Empfehlung ausgesprochen werden, Webmail fr private
E-Mails, die aus dem internen LAN verschickt werden sollen, zu nutzen.
Damit kann vermieden werden, dass Mitarbeiter trotz entsprechender Ver-
bote dienstliche E-Mail-Zugnge fr private Zwecke nutzen - beispielswei-
se, weil es dringend oder einfach praktisch ist.
- Es gibt auch Organisationen, in denen Webmail offiziell fr dienstliche
E-Mails freigegeben ist. Die Grnde hierfr sind unterschiedlich. So gibt es
z. B. eine Reihe kleinerer Organisationen, die keinen eigenen E-Mail-Ser-
ver haben und Webmail fr Kommunikation nach auen einsetzen. Web-
mail kann auch fr Mitarbeiter praktisch sein, die auf Dienstreisen auf ihre
E-Mail zugreifen mssen, fr die aber kein Zugang ber Remote Access
eingerichtet ist. Ein weiterer Grund fr die Nutzung von Webmail kann da-
rin bestehen, dass die jeweilige Organisation bei bestimmten E-Mails nicht
nach auen in Erscheinung treten will oder dass Webmail-Adressen dort
angegeben werden, wo Spam erwartet wird, also bei bestimmten
Downloads, Newsgruppen etc.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wenn Webmail eingesetzt wird, sollten die Empfehlungen in M 5.96 Sichere

Nutzung von Webmail beachtet werden.
- Existiert eine Sicherheitsrichtlinie fr die E-Mail-Nutzung?
- An wen knnen sich die Benutzer bei Fragen zur E-Mail-Nutzung wenden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.119 Regelung fr den Einsatz von E-Mail

Sollen zwischen zwei oder mehreren Kommunikationspartnern Daten elektro-
nisch ausgetauscht werden, so mssen diese zum ordnungsgemen Aus-
tausch folgende Punkte beachten:
- Die Adressierung von E-Mail muss eindeutig erfolgen, um eine fehlerhafte
Zustellung zu vermeiden. Innerhalb einer Organisation sollten Adress-
bcher und Verteilerlisten gepflegt werden, um die Korrektheit der
gebruchlichsten Adressen sicherzustellen. Durch den Versand von Test-
nachrichten an neue E-Mailadressen ist die korrekte Zustellung von
Nachrichten zu prfen.
- Wenn eine E-Mail an mehrere Empfnger geschickt wird, sollten diese
nicht so verschickt werden, dass jeder Empfnger die komplette
Empfngerliste sehen kann. Dies ist nmlich nicht nur fr die Empfnger
lstig, sondern kann auch aus Datenschutzgrnden unerwnscht sein und es
knnte dadurch auch Spam verursacht werden.
Ersatzweise knnte hierfr die E-Mail-Adressen statt unter "CC" unter
"BCC" eingetragen oder auch Verteilerlisten benutzt werden. BCC steht
fr Blind Carbon Copy; hier eingetragene weitere Empfnger werden den
anderen Empfnger nicht angezeigt.
Hinweis: Es sollte berprft werden, in welcher Form das eigene E-Mail-
System diese E-Mails dann an die Empfnger weiterleitet. Bei einigen E-
Mail-Systemen fhrt dies dazu, dass bei den Empfngern deren E-Mail-
Adresse nicht im "TO:"-Feld steht, wie es hufig auch bei Spam der Fall
ist. Besser ist in diesem Fall ein E-Mail-Programm, das eigene
Verteilerlisten untersttzt und dann an jeden Empfnger eine eigene Mail
schickt.
- Fr alle nach auen gehenden E-Mails ist eine Signature zu verwenden.
- Die Betreffangabe (Subject) des Kommunikationssystems sollte immer
ausgefllt werden, z. B. entsprechend der Betreffangabe in einem
Anschreiben.
- Die Korrektheit der durchgefhrten Datenbertragung sollte berprft
werden. Die Empfngerseite sollte den korrekten Empfang berprfen und
der Senderseite besttigen.
- Verwendung residenter Virenscanner fr ein- bzw. ausgehende Dateien.
Vor dem Absenden bzw. vor der Dateibermittlung sind die ausgehenden
Dateien explizit auf Computer-Viren zu berprfen. Siehe auch M 5.109
Einsatz eines E-Mail-Scanners auf dem Mailserver.
- Erfolgt ber die E-Mail noch eine Dateibertragung, so sollten die folgen-
den Informationen an den Empfnger zustzlich bermittelt werden:
- Art der Datei (z. B. Excel-Datei, OpenOffice Text oder hnliches),
- Kurzbeschreibung des Inhalts der Datei,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- eventuell ein Hinweis, dass Dateien auf Computer-Viren berprft

sind,
- ggf. Art des verwendeten Packprogramms (z. B. Winzip, gzip)
- ggf. Art der eingesetzten Software fr Verschlsselung bzw. Digitale
Signatur.
Jedoch sollte nicht vermerkt werden,
- welches Passwort fr die eventuell geschtzten Informationen verge-
ben wurde,
- welche Schlssel ggf. fr eine Verschlsselung der Informationen
verwendet wurde.
Bei den meisten E-Mail-Systemen werden die Informationen unverschlsselt Im Zweifel Rckfrage
beim Absender
ber offene Leitungen transportiert und knnen auf diversen Zwischen-
rechnern gespeichert werden, bis sie schlielich ihren Empfnger erreichen.
Auf diesem Weg knnen Informationen leicht manipuliert werden. Aber auch
der Versender einer E-Mail hat meistens die Mglichkeit, seine Absen-
deradresse (From) beliebig einzutragen, so dass man sich nur nach Rckfrage
oder bei Benutzung von Digitalen Signaturen der Authentizitt des Absenders
sicher sein kann. In Zweifelsfllen sollte daher die Echtheit des Absenders
durch Rckfrage oder - besser noch - durch den Einsatz von Verschlsselung
und/oder Digitalen Signaturen berprft werden. Grundstzlich gilt, dass man
sich nicht auf die Echtheit der Absenderangabe verlassen kann.
Beim Anschluss an E-Mail-Systeme ist mehrfach tglich zu berprfen, ob Regelmiges Lesen der
E-Mail, zeitnahe
neue E-Mails eingegangen sind. Bei lngerer Abwesenheit sollte eine Ver- Beantwortung
tretungsregelung getroffen werden, beispielsweise knnen eingehende
E-Mails an einen Vertreter weitergeleitet werden (siehe auch M 2.274
Vertretungsregelungen bei E-Mail-Nutzung).
Da in vielen Fllen nicht vorhergesagt werden kann, welchen E-Mail-Client
ein E-Mail-Empfnger benutzt und welche Software und Betriebssysteme auf
dem Transportweg eingesetzt werden, sollten die Benutzer wissen, dass so-
wohl bei der bertragung als auch bei der Darstellung von Nachrichten und
Anhngen beim Empfnger Probleme auftreten knnen. Dies tritt kann
insbesondere bei der Verwendung ungewhnlicher Zeichenstze oder Datei-
formate, oder auch beim Einsatz veralteter E-Mail-Software auftreten. Treten
Probleme auf, kann beispielsweise versucht werden, die Anhnge vor der
bertragung in eine 7-Bit-ASCII-Darstellung umwandeln, z. B. mit uuencode.
Alle Regelungen und Bedienungshinweise zum Einsatz von E-Mail sind Regelungen schriftlich
fixieren
schriftlich zu fixieren und sollten den Mitarbeitern jederzeit zur Verfgung
stehen. Ein entsprechendes Muster ist der dem IT-Grundschutzhandbuch
beiliegenden CD-ROM zu entnehmen.
Die Benutzer mssen vor dem Einsatz von Kommunikationsdiensten wie
E-Mail geschult werden, um Fehlbedienungen zu vermeiden und die Einhal-
tung der organisationsinternen Richtlinien zu gewhrleisten. Insbesondere
mssen sie hinsichtlich mglicher Gefhrdungen und einzuhaltender Sicher-
heitsmanahmen beim Versenden bzw. Empfangen von E-Mail sensibilisiert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Zur Vermeidung von berlastung durch E-Mail sind die Mitarbeiter ber Keine Kettenbriefe!
potentielles Fehlverhalten zu belehren. Sie sollten dabei ebenso vor der Teil-
nahme an E-Mail-Kettenbriefen wie vor der Abonnierung umfangreicher
Mailinglisten gewarnt werden.
Benutzer mssen darber informiert werden, dass Dateien, deren Inhalt
Ansto erregen knnte, weder verschickt noch auf Informationsservern ein-
gestellt werden noch nachgefragt werden sollten. Auerdem sollten Benutzer
darauf verpflichtet werden, dass bei der Nutzung von Kommunikations-
diensten
- die fahrlssige oder gar vorstzliche Unterbrechung des laufenden
Betriebes unter allen Umstnden vermieden werden muss. Zu unterlassen
sind insbesondere Versuche, ohne Autorisierung Zugang zu Netzdiensten
- welcher Art auch immer - zu erhalten, Informationen, die ber die Netze
verfgbar sind, zu verndern, in die individuelle Arbeitsumgebung eines
Netzbenutzers einzugreifen oder unabsichtlich erhaltene Angaben ber
Rechner und Personen weiterzugeben.
- die Verbreitung von fr die Allgemeinheit irrelevanten Informationen
unterlassen werden muss. Die Belastung der Netze durch ungezielte und
bermige Verbreitung von Informationen sollte vermieden werden.
- die Verbreitung von redundanten Informationen vermieden werden sollte.
- Sind Regelungen fr die Dateibertragung bzw. den Nachrichtenaustausch
mit Externen festgelegt worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.120 Einrichtung einer Poststelle

Zum reibungslosen Ablauf des E-Maildienstes muss ein Postmaster benannt
werden, der folgende Aufgaben wahrnimmt:
- Bereitstellen der Maildienste auf lokaler Ebene,
- Pflege der Adresstabellen,
- berprfung, ob die externen Kommunikationsverbindungen funktio-
nieren,
- Anlaufstelle bei Mailproblemen fr Endbenutzer sowie fr die Betreiber
von Gateway- und Relaydiensten.
Alle unzustellbaren E-Mails und alle Fehlermeldungen mssen an den Post-
master weitergeleitet werden, der versuchen sollte die Fehlerquellen zu behe-
ben. E-Mail, die unzustellbar bleibt, muss nach Ablauf einer vordefinierten
Frist an den Absender mit einer entsprechenden Fehlermeldung zurck-
geschickt werden.
Daneben mssen je nach Organisationsstruktur und -gre ein oder mehrere
Verantwortliche fr die Pflege der angebotenen Kommunikationsdienste
benannt werden. Neben dem Serverbetrieb wie Mail-, News- oder FTP-Server
mssen auch die von den Benutzer eingesetzten Kommunikationsclients
betreut werden.
Alle Betreuer bzw. deren Vertreter sollten jederzeit von den Benutzern tele-
fonisch erreicht werden knnten.
- Wer ist der verantwortliche Postmaster?
- Wo laufen fehlerhaft adressierte E-Mails auf?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.121 Regelmiges Lschen von E-Mails

E-Mails sollten nicht unntig lange im Posteingang gespeichert werden. Sie
sollten entweder nach dem Lesen gelscht werden oder in Benutzerverzeich-
nissen gespeichert werden, wenn sie erhalten bleiben sollen. Wenn im Post-
eingang zu viele E-Mails archiviert werden, kann es passieren, dass das IT-
System, das diesen verwaltet (der Mailserver bzw. Mail-Client), aus Speicher-
platzmangel neu ankommende E-Mails abweist.
Benutzer mssen andererseits darber informiert sein, dass eine E-Mail, die
sie selber ber ihre Mailanwendung gelscht haben, dadurch meistens nicht
unwiederbringlich gelscht ist. Viele Mailprogramme lschen E-Mails nicht
sofort, sondern transferieren sie in spezielle Ordner. Benutzer mssen darauf
hingewiesen werden, wie sie E-Mails auf ihren Clients vollstndig lschen
knnen.
Daneben knnen E-Mails nach dem Lschen auf den Clients trotzdem noch
auf Mailservern vorhanden sein. Viele Internet-Provider und Administratoren
archivieren die ein- und ausgehenden E-Mails. Viele Mailanwendungen
lschen E-Mails nicht, sondern verschieben sie in einen "Papierkorb"-Bereich,
der dann ebenfalls gelscht werden muss.
Die Benutzer mssen wissen, dass die Vertraulichkeit einer E-Mail nur durch
Verschlsselung gewhrleistet werden kann, und dass sie sich nicht auf
"schnelles Lschen" nach dem Empfang verlassen knnen.
- Wissen Benutzer, wie sie ihre E-Mail lschen knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.122 Einheitliche E-Mail-Adressen

E-Mailadressen sollten aufgrund von klaren Regelungen vergeben werden.
Dabei ist es sinnvoll, Namenskonventionen fr die personenbezogenen
E-Mailadressen festzulegen, die an die Benutzernamen auf den verwendeten
IT-Systeme angelehnt sind (z. B. E-Mail-Adresse = die ersten 8 Zeichen des
Nachnamens). Die Benutzernamen auf IT-Systemen, die von auerhalb des
geschtzten Netzes erreicht werden knnen, sollten nicht aus den
E-Mailadressen unmittelbar ableitbar sein, um mgliche Angriffe auf
Benutzer-Accounts zu erschweren. Wichtig ist, dass die Adressen nicht hufig
gendert werden und dass sie weder zu lang noch zu kompliziert aufgebaut
sind. Insbesondere ist darauf zu achten, dass keine Nicht-ASCII-Zeichen wie
Umlaute innerhalb von E-Mailadressen verwendet werden.
Um Angriffe zu erschweren, Werbe-E-Mail zu vermeiden bzw. um mglichst
wenig Information nach auen weiterzugeben, kann es sinnvoll sein, statt
benutzer- und organisationsbezogenen E-Mailadressen wie nachna-
me@organisation.de schwer erratbare E-Mailadressen zu verwenden. Dies
macht aber auch die Adressweitergabe unbequemer und kann die
Kommunikation mit Externen erschweren.
Wenn E-Mailadressen gendert werden oder wegfallen, ist darauf zu achten,
dass zumindest fr eine bergangszeit E-Mail, die noch an diese Adressen
gerichtet ist, an die jetzt aktuellen Adressen weitergeleitet wird.
Neben personenbezogenen E-Mailadressen knnen auch organisations- bzw.
funktionsbezogene E-Mailadressen eingerichtet werden, um unabhngig von
Personen die Zustellung zur richtigen Organisationseinheit zu garantieren.
Dies ist insbesondere bei zentralen Anlaufstellen wichtig. Siehe hierzu auch
M 2.275 Einrichtung funktionsbezogener E-Mailadressen.
- Wie ist die Vergabe von E-Mail-Adressen geregelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.123 Auswahl eines Mailproviders

Vor der Auswahl eines Mailproviders sollten sich die Verantwortlichen ber
die beim Provider geltenden Regelungen informieren, beispielsweise ob er
Obergrenzen fr den Umfang von E-Mails beim Empfang oder Versand
gesetzt hat, ob E-Mails gefiltert werden, und wenn ja, nach welchen Regeln.
Man sollte sich vom Mailprovider dokumentieren lassen, dass deren
Mailserver sicher betrieben wird, also die in M 5.56 Sicherer Betrieb eines
Mailservers beschriebenen Anforderungen erfllt sind.
Beim Mailprovider sind Daten ber die Benutzer fr Abrechnungszwecke
gespeichert (Name, Adresse, Benutzer-Kennung, Bankverbindung) ebenso
wie Verbindungsdaten und fr eine je nach Provider krzere oder lngere
Zeitspanne auch die bertragenen Inhalte.
Die Anwender sollten sich bei ihrem Mailprovider erkundigen, welche Daten
wie lange ber sie gespeichert werden. Bei der Auswahl von Providern sollte
bercksichtigt werden, dass deutsche Betreiber den einschlgigen datenschutz-
rechtlichen Regelungen fr die Verarbeitung dieser Daten unterliegen.
Die Benutzer knnen durch den Einsatz von Verschlsselung verhindern, dass
der Provider die Inhalte der bertragenen Informationen mitlesen kann.
Groe Provider mit groem eigenem Netz haben den Vorteil, dass E-Mail, die
nur innerhalb dieses Netzes ausgetauscht wird, sicherer vor Manipulationen ist
als bei Weiterleitung ber das Internet.
Bei Providern, die ihren Hauptsitz im Ausland haben, wird hufig auch alle
E-Mail ber dieses Land geroutet. Beispielsweise werden bei AOL und
Compuserve alle E-Mails ber die USA weitergeleitet. Dieser Punkt sollte
bercksichtigt werden, wenn man sich Gedanken darber macht, ber wie
viele Gateways die E-Mail weiterverteilt wird, also wer sie beispielsweise
mitlesen kann.
- Nach welchen Kriterien ist der Mailprovider ausgewhlt worden?
- Welche Sicherheitsmechanismen werden beim Mailprovider umgesetzt?
- Nach welchen Kriterien werden die E-Mails beim Mailprovider gefiltert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.124 Geeignete Auswahl einer Datenbank-Software

Bei der Beschaffung neuer Datenbank-Software besteht die Mglichkeit, diese
von vornherein so auszuwhlen, dass im spteren Betrieb mit nur geringem
personellen und organisatorischen Zusatzaufwand ein hohes Ma an
Sicherheit erreicht werden kann.
Zu Beginn muss der Einsatzbereich und Verwendungszweck des Datenbank-
systems geklrt werden, um die Anforderungen bezglich der Verfgbarkeit,
der Integritt und der Vertraulichkeit formulieren zu knnen. Weiterhin sind
die Anforderungen hinsichtlich der zu verarbeitenden Datenmengen, der
Verarbeitungsgeschwindigkeit und des Durchsatzes zu quantifizieren. Daraus
leiten sich die zu erfllenden Eigenschaften fr die zu beschaffende Daten-
bank-Software ab, wie z. B. Verfgbarkeit fr bestimmte Hardware-Platt-
formen bzw. Betriebssysteme oder Umfang von notwendigen Sicherheits-
mechanismen. In diesem Planungsstadium kann bereits erkannt werden, ob
und in welchem Mae fr den spteren Betrieb des Datenbanksystems Hard-
ware nach- bzw. umgerstet werden muss. Anhand der Verfgbarkeits-
anforderungen sind auch die bentigten berwachungsmglichkeiten zu
definieren, d. h. es muss festgelegt werden, welche Datenbankzustnde in
welcher Form erkennbar sein sollen (z. B. durch eine Protokollierung in einer
Datei), sowie die Art der Benachrichtigung verantwortlicher Personen bzw.
Personengruppen ber kritische Zustnde der Datenbank (z. B. durch eine
Meldung an der Konsole).
Fr die Beschaffung einer Datenbank-Software sollten insbesondere die
folgenden Punkte bercksichtigt werden:
- Die Datenbank-Software muss ber eigene geeignete Mechanismen zur
Identifikation und Authentisierung der Benutzer verfgen (siehe M 2.128
Zugangskontrolle einer Datenbank).
- Die Datenbank-Software muss ber geeignete Mechanismen zur Ressour-
cenbeschrnkung verfgen (siehe M 4.73 Festlegung von Obergrenzen fr
selektierbare Datenstze).
- Falls in der Datenbank vertrauliche Daten verwaltet werden sollen, so muss
einem unberechtigten Zugriff vorgebeugt werden knnen. Die zu beschaf-
fende Datenbank-Software muss in diesem Fall entsprechende
Zugriffskontrollmechanismen zur Verfgung stellen (siehe M 2.129
Zugriffskontrolle einer Datenbank).
Es sollte auch die Zusammenfassung mehrerer Benutzer mit gleichen
Zugriffsrechten zu Gruppen mglich sein. Eine Unterscheidung zwischen
der Gruppe der Administratoren und der Gruppe der Benutzer ist dabei
obligatorisch. Weiterhin sollte eine Trennung von verschiedenen
Administrator-Rollen untersttzt werden (siehe M 2.131 Aufteilung von
Administrationsttigkeiten bei Datenbanksystemen).
- Es gibt Datenbanken mit unterschiedlich starken Zugriffsschutzmechanis-
men. hnliche Sicherheitsmechanismen knnen dabei auch in unterschied-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
licher Granularitt angeboten werden. Im Vorfeld ist zu klren, welcher

Zugriffsschutz erforderlich ist und welche Datenbank-Software den defi-
nierten Sicherheitsanforderungen entspricht. Mageblich hierfr sind die
Mglichkeiten, Zugriffsrechte auf Datenbankobjekte und die Daten selbst
einzuschrnken.
Beispiele:
- Den Anwendern kann das Recht entzogen werden, Datenbank-
objekte (z. B. Tabellen) anzulegen oder zu modifizieren.
- Die Anwender knnen zwar eine lesende Zugriffsberechtigung auf
eine Tabelle erhalten, gleichzeitig knnen aber modifizierende
Zugriffsrechte ausgeschlossen werden.
- Fr bestimmte Tabellen oder bestimmte Felder einer Tabelle kann
der Zugriff je nach Anwender verboten werden.
- Anwender erhalten keinerlei Zugriffsberechtigungen auf Datenstze
mit bestimmten Merkmalen (z. B. ein Sachbearbeiter aus Bonn hat
keinen Zugriff auf die Daten eines Sachbearbeiters aus Kln).
- Einige Hersteller bieten sowohl die Mglichkeit der Definition von
Gruppen als auch die von Rollen an. Dadurch kann eine differenziertere
Zugriffskontrolle auf die Datenbankobjekte realisiert werden. Im Vorfeld
sind die diesbezglichen Anforderungen zu klren und mit den zur Aus-
wahl stehenden Datenbank-Softwareprodukten abzugleichen.
- Die Datenbank-Software muss ebenfalls hinsichtlich ihrer berwachungs-
und Kontrollmechanismen berprft werden. Die diesbezglichen Anfor-
derungen mssen definiert und mit den Leistungsprofilen der Produkte
abgeglichen werden (Beispiele siehe M 2.133 Kontrolle der
Protokolldateien eines Datenbanksystems bzw. M 2.126 Erstellung eines
Datenbanksicherheitskonzeptes).
- Es muss geprft werden, ob die Datenbank-Software eine Rollentrennung
zwischen Administrator und Revisor untersttzt. Es muss mglich sein, die
Rolle eines Revisors einzurichten, der als einziger in der Lage ist, die
Protokolldateien auszuwerten und zu lschen. Dies verhindert potentielle
Manipulationen durch den Datenbank-Administrator.
- Zum Schutz der Datenbankintegritt muss die Datenbank-Software ber
ein vollstndiges Transaktionssystem verfgen, welches dem ACID-Prin-
zip gengt. Diese Anforderung wird heutzutage von allen wesentlichen
relationalen DBMSen erfllt.
- Es mssen Mechanismen zur Datensicherung der Datenbank vorhanden
sein (siehe M 6.49 Datensicherung einer Datenbank).
Im Vorfeld muss in diesem Zusammenhang geklrt werden, welche Mg-
lichkeiten hinsichtlich der Datensicherung die Datenbank-Software zur
Verfgung stellen muss. So wird beispielsweise eine partielle Daten-
banksicherung nicht fr alle am Markt erhltlichen Produkte angeboten. Im
konkreten Fall gilt es also zu prfen, ob das erstellte Datensicherungs-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
konzept mit den zur Verfgung stehenden Mechanismen auch umgesetzt

werden kann.
Anhand dieser Kriterien mssen die zur Auswahl stehenden Datenbank-
systeme geprft und bewertet werden. Es ist dann diejenige Software auszu-
whlen, die die spezifischen Anforderungen am besten erfllt. Weitergehende
Anforderungen mssen entweder durch Zusatzprodukte oder durch Eigen-
entwicklung abgedeckt werden. Es sollte jedoch schon vor der Beschaffung
abgeklrt werden, zu welcher Datenbank-Software welche Zusatzprodukte
verfgbar sind, um nicht auf teure Eigenentwicklungen zurckgreifen zu
mssen.
Von den meisten Datenbankmanagementsystemen sind in der Regel mehrere
unterschiedliche Versionen auf dem Markt erhltlich. Dabei unterscheiden
sich auch die einzelnen Versionen desselben DBMS in ihrer Funktionalitt,
u. a. auch in sicherheitsrelevanten Bereichen. Der starke Wettbewerb fhrt
dazu, dass einige Hersteller auch noch nicht vollausgereifte Software auslie-
fern, bei der dann mit Fehlern und eingeschrnkter Funktionalitt gerechnet
werden muss.
In einer Testphase sollte deshalb berprft werden, ob die ausgewhlte Daten-
bank-Software die erforderlichen Funktionen in der vorgegebenen Einsatzum-
gebung auch erfllt. Dies gilt insbesondere fr die Anforderungen an die Per-
formance und die bentigten Mechanismen zur Notfallvorsorge.
Vor der Beschaffung sollten auch Erfahrungen aus vergleichbaren Installatio-
nen herangezogen werden.
- Wurden die Anforderungen an die Datenbank-Software formuliert und
dokumentiert?
- Wurde eine Bewertung der relevanten Datenbanksysteme anhand dieser
Anforderungen durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.125 Installation und Konfiguration einer Datenbank

Grundstzlich muss zwischen der Erstinstallation einer Datenbank-Software
und der Installation auf bestehenden Datenbanksystemen unterschieden
werden.
Da bei der erstmaligen Installation einer Datenbank-Software noch keine
Benutzer auf die Datenbank zugreifen wollen und auch noch keine Altdaten
vorhanden sind (es sei denn in anderen Datenbanksystemen), gestaltet sich
dies relativ unproblematisch und strt den normalen IT-Betrieb kaum.
Fr Installationen auf bestehenden Systemen sollten dagegen die Arbeiten,
wenn mglich, auerhalb der regulren Arbeitszeiten erfolgen, um Behinde-
rungen des normalen IT-Betriebs weitestgehend zu minimieren. In jedem Fall
sollten die Benutzer ber bevorstehende Arbeiten informiert werden, um sie
auf eventuell mgliche Strungen oder lngere Antwortzeiten hinzuweisen.
Die Installation und Konfiguration einer Datenbank gliedert sich in die fol-
genden Aktivitten:
1. Installation der Datenbank-Software
Vor der Installation der Datenbank-Software ist zu berprfen, ob das IT-
System entsprechend der Planung vorbereitet wurde, z. B. gengend
Speicherplatz zur Verfgung steht und die notwendigen Betriebssystem-
einstellungen vorgenommen wurden.
Bei der Installation der Datenbank-Software sind die Installationsanweisungen
des Herstellers zu befolgen. Wenn mglich, sollten die vom Hersteller
vorgeschlagenen Default-Einstellungen bernommen werden. Dies gilt vor
allem fr technische Parameter, die z. B. die Gre verschiedener interner
Tabellen des DBMS steuern. Fr Parameter, die sich auf sicherheitsrelevante
Eigenschaften beziehen, muss u. U. von den vorgegebenen Werten abge-
wichen werden.
Die Installation der Datenbank-Software ist geeignet zu dokumentieren. Dies
gilt insbesondere fr Abweichungen von den vom Hersteller vorgeschlagenen
Default-Einstellungen, die ausfhrlich zu begrnden sind.
Sollen vom Hersteller angebotene optionale Funktionalitten genutzt werden,
so ist whrend der Installation darauf zu achten, dass sie auch entsprechend
eingerichtet werden.
Alle Ttigkeiten in diesem Schritt werden vom fachlich bergreifenden
Administrator durchgefhrt.
2. Erstellen der Datenbank
Bereits bei der Erstellung der Datenbank sind Parameter anzugeben, die spter
whrend des Betriebs des Datenbanksystems nicht mehr gendert werden
knnen. Die Bedeutung dieser Parameter und die geeignete Auswahl ihrer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Werte werden in den Installationsunterlagen und Handbchern des Herstellers

ausfhrlich erlutert und sind dort entsprechend nachzulesen.
Dem Installationshandbuch bzw. Administrationshandbuch sind auerdem
Hinweise ber eventuell erforderliche Nacharbeiten nach der Erstellung der
Datenbank zu entnehmen.
Auch dieser Vorgang ist im Rahmen einer Dokumentation festzuhalten.
Administrator durchgefhrt, wobei ihm die anwendungsspezifischen
Administratoren beratend zur Seite stehen mssen (z. B. um die Gre der
Datenbank festlegen zu knnen).
3. Konfiguration der Datenbank
Im dritten Schritt ist das Benutzer- und Gruppenkonzept sowie das ggf. zum
Einsatz kommende Rollenkonzept umzusetzen. Dazu erstellt der fachlich
bergreifende Administrator die einzelnen Berechtigungsprofile und legt alle
Gruppen sowie die administrativen Benutzer-Kennungen (fr die
anwendungsspezifischen Administratoren) an. Dabei sind die in M 2.132
Regelung fr die Einrichtung von Datenbankbenutzern/-benutzergruppen
festgelegten Regelungen anzuwenden und zu berprfen. Hngen die
entsprechenden Zugriffsberechtigungen von einzelnen Datenbankobjekten ab,
knnen diese natrlich erst dann definiert werden, wenn die Datenbankobjekte
auch existieren (siehe Schritt 4).
Falls die Datenbank-Software eine Verteilung der Daten auf mehrere Dateien
oder Festplatten untersttzt, sind zustzliche Parametereinstellungen vorzu-
nehmen, die das Anlegen dieser Dateien respektive der zugehrigen
Speicherbereiche festlegen.
Alle vorgenommenen Einstellungen sind detailliert zu dokumentieren (siehe
M 2.25 Dokumentation der Systemkonfiguration).
Administrator durchgefhrt.
4. Erstellen und Konfigurieren von Datenbankobjekten
Gem des Datenbanksicherheitskonzeptes (siehe M 2.126 Erstellung eines
Datenbanksicherheitskonzeptes) werden im letzten Schritt die Datenbank-
objekte der einzelnen Anwendungen angelegt. Dieser Vorgang sollte, wenn
mglich, durch den Einsatz von Skripten automatisiert und protokolliert
werden. Nach Anlage der Datenbankobjekte sind die notwendigen Zugriffs-
berechtigungen fr Rollen, Gruppen und Benutzer zu ergnzen. Ebenso
knnen jetzt die konkreten Benutzer anhand der existierenden Berechtigungs-
profile erstellt werden.
Alle Ttigkeiten in diesem Schritt werden von den anwendungsspezifischen
Administratoren durchgefhrt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die Benutzer ber die bevorstehende Installation informiert?
- Sind vor Erstellen der Datenbank alle erforderlichen Parameter und deren
Werte bekannt, die whrend der Installation bentigt werden?
- Sind alle Nacharbeiten bekannt, die nach der Erstellung der Datenbank
durchgefhrt werden mssen?
- Wurde der Installationsvorgang, die Erstellung und Konfiguration der
Datenbank sowie der Datenbankobjekte dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.126 Erstellung eines

Datenbanksicherheitskonzeptes
Da eine zentrale Datenhaltung ber einen lngeren Zeitraum hinweg einen
zentralen und kritischen Aspekt des Informationsmanagements einer Behrde
bzw. eines Unternehmens darstellt, kommt der Erstellung eines Datenbank-
konzeptes eine besondere Bedeutung zu. Ein Datenbankkonzept beschftigt
sich mit den notwendigen Vorarbeiten zum eigentlichen Betrieb der Daten-
bank und sollte deshalb immer ein Datenbanksicherheitskonzept enthalten,
welches auch den laufenden Betrieb untersucht.
Werden die Daten nicht ausreichend geschtzt, kann es zu einem Verlust der
Vertraulichkeit, Verfgbarkeit oder der Integritt kommen. Um diesem vor-
zubeugen, ist es unumgnglich, ein schlssiges Datenbanksicherheitskonzept
zu erstellen.
Um die Sicherheit einer Datenbank zu gewhrleisten, muss ein geeignetes
Datenbankmanagementsystem (DBMS) eingesetzt werden. Damit ein DBMS
effektiven Schutz bieten kann, mssen folgende grundlegende Bedingungen
erfllt sein. Das DBMS muss
- auf einer umfassenden Sicherheitspolitik aufsetzen,
- im IT-Sicherheitskonzept der Organisation eingebettet sein,
- korrekt installiert und
- korrekt administriert werden.
Direkte Zugriffe auf die Datenbank (z. B. ber SQL-Interpreter wie
SQL*Plus) drfen nur fr administrative Nutzer zugelassen werden, um
Manipulationen an den Daten bzw. Datenbankobjekten (z. B. Tabellen und
Indizes) zu verhindern. Datenbankobjekte drfen ausschlielich ber spezielle
Kennungen kontrolliert modifiziert werden. Dementsprechend muss das
DBMS ber ein geeignetes Zugriffs- und Zugangskonzept verfgen (siehe
M 2.129 Zugriffskontrolle einer Datenbank und M 2.128 Zugangskontrolle
einer Datenbank). Benutzer-Kennungen, die nur ber eine Anwendung
Datenmodifikationen durchfhren knnen, drfen keinen direkten Zugang zur
Datenbank erhalten, whrend Kennungen zur Verwaltung der Datenbank-
objekte der kontrollierte direkte Zugriff erlaubt sein muss.
Weiterhin mssen folgende wichtige Aspekte in einem Datenbanksicherheits-
konzept geregelt werden:
- Die physische Speicherung bzw. Spiegelung der Datenbankdateien (z. B.
der DBMS-Software, der Datenbank an sich oder der Protokolldateien)
sowie deren Verteilung ist festzulegen, um z. B. die Verfgbarkeit und
Ausfallsicherheit zu erhhen. Aus Sicherheitsgrnden sollten gespiegelte
Kontrolldateien beispielsweise auf verschiedenen Festplatten abgelegt sein.
Der Ausfall einer Platte bedeutet dann nicht gleichzeitig den Verlust aller
Kontrolldateien. Falls die Datenbankobjekte einer Anwendung in
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
eigenen Datendateien abgelegt werden, so sollte man bei der Verteilung

der Datendateien darauf achten, dass bei einem Ausfall einer Festplatte
nicht alle Anwendungen betroffen sind.
Beispiel:
Eine Datenbank verwaltet die Daten zweier Anwendungen, mit jeweils
einer Datendatei fr die Tabellen und Indizes. Die Datendateien knnen
beliebig auf vier Festplatten verteilt werden.
Eine ungnstige Verteilung der Datendateien sieht folgendermaen aus:
Festplatte 1 Ablage der Datendateien fr die Indizes beider
Anwendungen
Festplatte 2 Ablage der Datendateien fr die Tabellen der ersten
Anwendung
Festplatte 3 Ablage der Datendateien fr die Tabellen der zweiten
Anwendung
Festplatte 4 -
Bei einem Ausfall der ersten Festplatte wren somit beide Anwendungen
betroffen und knnten nicht mehr genutzt werden.
Eine gnstigere Verteilung der Datendateien erhlt man dagegen so:
Festplatte 1 Ablage der Datendateien fr die Indizes der ersten
Anwendung
Festplatte 2 Ablage der Datendateien fr die Tabellen der ersten
Anwendung
Festplatte 3 Ablage der Datendateien fr die Indizes der zweiten
Anwendung
Festplatte 4 Ablage der Datendateien fr die Tabellen der zweiten
Anwendung
Bei einem Ausfall einer beliebigen Festplatte wre immer nur eine
Anwendung betroffen.
- Es muss eine regelmige Prfung des tatschlich anfallenden Daten-
volumens bzw. des Zuwachses des Datenvolumens im spteren laufenden
Betrieb durchgefhrt werden, um den bentigten Speicherplatz auch fr
zuknftige Bedrfnisse geeignet dimensionieren zu knnen.
- Geeignete Mechanismen zur Datensicherung mssen angewendet werden
(siehe M 6.49 Datensicherung einer Datenbank).
- Der Einsatz von berwachungs- und Kontrollmechanismen ist festzulegen,
d. h. ob und in welchem Umfang Datenbankaktivitten protokolliert
werden sollen. Hier stellt sich u. a. die Frage, ob beispielsweise nur der
Zeitpunkt einer Datenmodifikation festgehalten wird, oder ob auch die
Modifikation selbst protokolliert werden soll (siehe M 2.133 Kontrolle der
Protokolldateien eines Datenbanksystems).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr die Konzeption und den Betrieb eines Datenbanksystems muss geeignetes

Personal zur Verfgung stehen. Der zeitliche Aufwand fr den Betrieb eines
Datenbanksystems darf nicht unterschtzt werden. Alleine die Auswertung der
angefallenen Protokolldaten nimmt erfahrungsgem viel Zeit in Anspruch.
Ein Datenbank-Administrator muss fundierte Kenntnisse ber die eingesetzte
DBMS-Software besitzen und auch entsprechend geschult werden.
- Wurden die Sicherheitsziele fr den Einsatz eines Datenbanksystems for-
muliert und dokumentiert?
- Ist ein direkter Zugriff auf die Datenbanken ber eine interaktive Abfrage-
sprache ausgeschlossen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.127 Inferenzprvention
Zum Schutz personenbezogener und anderer vertraulicher Daten eines Daten-
banksystems ist grundstzlich jedem Benutzer nur der Zugriff auf diejenigen
Daten zu gestatten, die fr seine Ttigkeiten notwendig sind. Alle anderen
Informationen, die sich zustzlich in der Datenbank befinden, sind vor ihm zu
verbergen.
Zu diesem Zweck mssen die Zugriffsberechtigungen auf Tabellen bis hin zu
deren Feldern definiert werden knnen. Dies kann mittels Verwendung von
Views und Grants durchgefhrt werden (vgl. M 2.129 Zugriffskontrolle einer
Datenbank). Damit ist es einem Benutzer nur mglich, die fr ihn bestimmten
Daten einzusehen und zu verarbeiten. Stellt er Datenbankabfragen, die auf
andere Informationen zugreifen wollen, werden diese vom DBMS zurck-
gewiesen.
Im Zusammenhang mit statistischen Datenbanken, die Daten ber Personen-
gruppen, Bevlkerungsschichten oder hnliches enthalten, treten dagegen
andere Schutzanforderungen auf. In einer statistischen Datenbank unterliegen
die einzelnen, personenbezogenen Eintrge dem Datenschutz, statistische
Informationen sind jedoch allen Benutzern zugnglich.
Hier gilt es zu verhindern, dass aus Kenntnissen ber die Daten einer Gruppe
auf die Daten eines individuellen Mitglieds dieser Gruppe geschlossen werden
kann. Es muss auerdem verhindert werden, dass durch das Wissen der in der
Datenbank gespeicherten Informationen bzw. der Ablagestrukturen der Daten
in der Datenbank die Anonymitt dieser Daten durch entsprechend formulierte
Datenbankabfragen umgangen werden kann (z. B. wenn die Ergebnismenge
einer Datenbankabfrage nur einen Datensatz beinhaltet). Diese Problematik
wird Inferenzproblem, der Schutz vor solchen Techniken Inferenzprvention
genannt.
Auch wenn die Daten einer statistischen Datenbank anonymisiert sind, kann
durch Inferenztechniken der Personenbezug zu bestimmten Datenstzen
wiederhergestellt werden. Eine Zurckweisung bestimmter Anfragen (z. B.
Anfragen mit nur einem oder wenigen Ergebnistupeln) reicht im allgemeinen
nicht aus, da auch die Verweigerung einer Antwort durch das DBMS Infor-
mationen beinhalten kann.
Durch das Erstellen verschiedener Statistiken kann die Anonymitt der Daten
ebenfalls verloren gehen. Ein solcher indirekter Angriff zielt darauf ab, aus
mehreren Statistiken Rckschlsse auf die persnlichen Daten eines einzelnen
Individuums ziehen zu knnen. Eine Schutzmanahme ist in diesem Fall, die
Freigabe von so genannten sensitiven Statistiken nicht zu erlauben, was als
unterdrckte Inferenzprvention bezeichnet wird. Eine weitere Mglichkeit ist
die Verzerrung solcher Statistiken durch kontrolliertes Runden (gleiche
Statistiken sind gleich zu runden) oder die Beschrnkung auf statistisch rele-
vante Teilmengen mit der Auflage, dass gleiche Anfragen immer Bezug auf
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
die gleichen Teilmengen nehmen. Dieses Verfahren wird als verzerrende

Inferenzprvention bezeichnet.
Werden weitergehende Anforderungen an die Vertraulichkeit der Daten
gestellt, ist deren Verschlsselung erforderlich (vergleiche M 4.72 Datenbank-
Verschlsselung).
- Wurden die Vertraulichkeitsanforderungen an das Datenbanksystem erfasst
und dokumentiert?
- Sind die vertraulichen Daten ausreichend vor unbefugtem Zugriff
geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.128 Zugangskontrolle einer Datenbank

Die Datenbank-Software muss ber geeignete Mechanismen zur Identifikation
und Authentisierung der Benutzer verfgen, um eine wirkungsvolle Zugangs-
kontrolle zu gewhrleisten (siehe M 2.132 Regelung fr die Einrichtung von
Datenbankbenutzern/-benutzergruppen).
Generell sollte man fr normale Benutzer den Zugang zu einer Produktions-
datenbank ber einen interaktiven SQL-Interpreter unterbinden. Auf solche
Datenbanken sollte ausschlielich ein indirekter Zugang ber die entspre-
chenden Anwendungen mglich sein. Die einzige Ausnahme bilden hier
Datenbankkennungen zu Administrationszwecken.
Remote-Zugnge zu Datenbanken sollten uerst restriktiv gehandhabt
werden. Ist diese Art des Zugangs nicht zwingend erforderlich, so sind diese
zu unterbinden. Ansonsten sollte nur denjenigen Benutzern ein Remote-
Zugang ermglicht werden, die diesen auch tatschlich bentigen. Andere
Benutzer drfen nicht in der Lage sein, sich selbst einen Remote-Zugang zu
verschaffen. Keinesfalls darf ein Remote-Zugang ohne Angabe einer gltigen
Benutzer-Kennung und Eingabe eines Passwortes mglich sein.
- Werden die Kennungen einzelner Benutzer zur Zugangskontrolle direkt
verwaltet? Falls ja, aus welchem Grund erfolgt keine Verwaltung ber
Gruppen?
- Gibt es Benutzer-Kennungen, die direkten Zugang zu einer Datenbank
haben? Falls ja, aus welchem Grund haben sie direkten Zugang?
- Wurden die Mglichkeiten des Remote-Zugangs fr die derzeit im Einsatz
befindlichen Datenbanken geprft und ggf. deaktiviert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.129 Zugriffskontrolle einer Datenbank

Um einen wirkungsvollen Schutz der Vertraulichkeit und Integritt der Daten
einer Datenbank zu erreichen, mssen eine Reihe von Manahmen umgesetzt
werden. Neben einer Zugangskontrolle der Datenbank, die in M 2.128
Zugangskontrolle einer Datenbank beschrieben wird, sind dies im wesent-
lichen die folgenden Mglichkeiten der Zugriffskontrolle:
- Schutz der Datenbankobjekte
Es sollte eine logische Zuordnung der Datenbankobjekte, also der Tabel-
len, Indizes, Datenbankprozeduren, etc., zu den Anwendungen erfolgen,
die diese Objekte benutzen. Die daraus entstehenden Gruppen von Daten-
bankobjekten je Anwendung werden eigens hierfr einzurichtenden
Kennungen zugeordnet. Damit knnen die Zugriffsberechtigungen der
Datenbankobjekte so eingestellt werden, dass nur ber diese speziellen
Kennungen eine Modifikation der Objekte stattfinden kann. Greifen
mehrere Anwendungen auf dieselben Datenbankobjekte zu, sollten diese
als eigene Gruppe isoliert werden.
Werden beispielsweise die Daten zweier Anwendungen A und B in der
Datenbank verwaltet, so legt man zwei Datenbankkennungen AnwA und
AnwB an. Alle Datenbankobjekte, die eindeutig der Anwendung A zuge-
ordnet werden knnen, werden mit der Datenbankkennung AnwA angelegt
und verwaltet. Analog wird mit den Datenbankobjekten von Anwendung B
verfahren.
Ein Beispiel fr ein zentrales Datenbankobjekt, das von beiden Anwen-
dungen benutzt wird, sei eine Tabelle, die alle ansteuerbaren Drucker
beinhaltet. Datenbankobjekte dieser Kategorie sollten nicht einer Kennung
der Anwendungen (AnwA oder AnwB) zugeordnet werden, statt dessen
sollten solche Datenbankobjekte unter einer eigenen Kennung (z. B.
Druck) zusammengefasst und mit dieser zentralen Kennung verwaltet
werden.
Diese speziellen Kennungen sind nicht personenbezogen. Statt dessen
erhalten eigens hierfr autorisierte Personen (z. B. der Datenbank-
administrator oder der Administrator der zugehrigen Anwendung) das
Passwort der bentigten Kennung, falls Modifikationen an den Daten-
bankobjekten vorgenommen werden mssen.
- Schutz der Daten
Durch eine Definition von Views knnen spezielle Benutzer-Sichten
erzeugt werden, so dass die Daten der Datenbank nach bestimmten Krite-
rien sichtbar gemacht bzw. unsichtbar gehalten werden. ber einen View
wird explizit festgelegt, welche Felder aus einer oder mehreren Tabellen
ein Benutzer zu sehen bekommt. Durch die restriktive Vergabe von
Zugriffsrechten (den im folgenden beschriebenen Grants) auf solche Views
knnen vertrauliche Daten vor unberechtigtem Zugriff geschtzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es mssen Zugriffsrechte (Grants) auf Tabellen, Views oder sogar einzelne

Felder einer Tabelle vergeben werden. Diese Rechte sind immer an
bestimmte Benutzer, Rollen oder Benutzergruppen gebunden. Zugriffs-
rechte sollten jedoch immer fr Benutzergruppen oder Rollen und nicht fr
einzelne Personen vergeben werden, da dies sonst bei einer groen Anzahl
von Benutzern zu einem hohen administrativen Aufwand fhrt. Es knnen
Zugriffsberechtigungen lesender (read), ndernder (update), lschender
(delete) oder neu einfgender (insert) Art unterschieden werden. Mit der
Vergabe von Zugriffsberechtigungen sollte so sparsam wie mglich
umgegangen werden, da man sonst sehr schnell den berblick ber die
aktuellen Zugriffsrechte verliert und damit Sicherheitslcken geschaffen
werden. Insbesondere sollte die Mglichkeit, Rechte an alle zu vergeben
(GRANT ... TO PUBLIC), nicht genutzt werden.
Im allgemeinen ist es nur dem Besitzer eines Datenbankobjektes erlaubt,
Zugriffsberechtigungen an andere Benutzer weiterzugeben. Einige Daten-
banksysteme stellen jedoch die Mglichkeit zur Verfgung, dass der
Besitzer eines Datenbankobjektes auch das Recht, Zugriffsrechte weiter-
zugeben, an andere Benutzer vergeben kann. Von dieser Mglichkeit sollte
nur in begrndeten Ausnahmefllen Gebrauch gemacht werden, da man auf
diese Weise die Kontrolle ber den Zugriff auf die Daten bzw. die
Datenbankobjekte verliert.
- Restriktiver Datenzugriff ber Anwendungen
Anwendungen sollten einen restriktiven Zugriff auf die Daten untersttzen,
d. h. in Abhngigkeit der Benutzer-Kennung und der Gruppenzuge-
hrigkeit sollten nur diejenigen Funktionalitten und Daten zur Verfgung
gestellt werden, die ein Benutzer fr die Ausfhrung seiner Aufgaben
bentigt. Eine Form der Realisierung ist hier die Verwendung von soge-
nannten Stored Procedures.
Stored Procedures sind Abfolgen von SQL-Anweisungen, die in der
Datenbank voroptimiert gespeichert werden. Beim Aufruf einer Stored
Procedure mssen nur ihr Name und eventuelle Parameter angegeben
werden, um die dahinterstehenden SQL-Anweisungen auszufhren. Dies
hat zum einen den Vorteil, dass nicht die gesamten SQL-Anweisungen
zum Datenbank-Server bertragen werden mssen, was bei komplexeren
Operationen die Netzbelastung vermindert. Zum anderen kann das Daten-
banksystem die SQL-Anweisungen in einer optimierten Form ablegen, so
dass sie schneller ausgefhrt werden. Die strkste Einschrnkung bei der
Rechtevergabe ist die Vergabe von Zugriffsrechten auf Stored Procedures
statt auf Tabellen oder Views. Wenn Zugriffsrechte nur auf Stored
Procedures vergeben werden, knnen die Benutzer nur die von den Daten-
bankverantwortlichen ausgewhlten Operationen ausfhren.
Beispiele:
1. In MS Access knnen verschiedene Berechtigungen vergeben werden, die
sich entweder auf die Datenbank selbst (ffnen/Ausfhren, Exklusiv,
Verwalten) oder auf die Tabellen und Abfragen beziehen (Daten lesen,
Daten aktualisieren, Daten lschen, Daten einfgen). Diese Berechtigungen
knnen dann unterschiedlichen Benutzern oder Benutzergruppen zuge-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ordnet werden. Standardmig sind bei MS Access die Gruppen "Admini-

stratoren" und "Benutzer" eingerichtet, wobei die Gruppe "Benutzer" die
Berechtigungen "Daten lesen" und "Daten aktualisieren" fr Tabellen und
Abfragen und die Berechtigung "ffnen/Ausfhren" fr Datenbanken
enthlt. Fr eine detailliertere Kontrolle der Zugriffsrechte knnen eigene
Gruppen definiert werden, an die unterschiedliche Berechtigungen
vergeben werden knnen. Dies kann im Men Extras unter Zugriffsrechte
und Benutzer und Gruppenkonten durchgefhrt werden.
2. In einer Oracle-Datenbank kann mit dem folgendem Kommando die
Gruppe "Abteilung_1" erstellt werden:
CREATE ROLE Abteilung_1 IDENTIFIED BY <Passwort>;
Im folgenden Beispiel wird der Gruppe "Abteilung_1" die Berechtigung
erteilt, eine Verbindung zur Datenbank herzustellen sowie eine Session zu
erffnen:
GRANT CONNECT, CREATE SESSION TO Abteilung_1;
Im folgenden Beispiel wrde derselben Gruppe die Berechtigung gegeben,
ein SELECT auf die Tabelle "Test" durchzufhren:
GRANT SELECT ON Test TO Abteilung_1;
Im folgenden Beispiel wrde dieser Gruppe die Berechtigung erteilt, fr
die Spalte "Kommentar" der Tabelle "Test" nderungen durchzufhren:
GRANT UPDATE (Kommentar) ON Test TO Abteilung_1;
3. Ein Beispiel fr eine Stored Procedure unter Oracle mit PL/SQL Anwei-
sungen sieht wie folgt aus:
PROCEDURE Example (PArtikelnr IN NUMBER, PPreis OUT
NUMBER) IS
BEGIN
BEGIN <<Block>>
SELECT preis INTO PPreis
FROM TabB
WHERE artikelnr=PArtikelnr
END Block;
END;
Die Prozedur "Example" liest aus der Tabelle TabB den Preis eines
Artikels nach Angabe der Artikelnummer. Mitarbeiter, die auf die Tabelle
TabB ausschlielich mit dieser Methode zugreifen knnen sollen, erhalten
nur das Nutzungsrecht fr die Stored Procedure und keinerlei Rechte auf
die Tabelle. Damit werden z. B. auch zeitaufwendige Suchoperationen
verhindert.
- Wurden die Datenbankobjekte vor unberechtigtem Zugriff geschtzt?
- Wurden Views fr die einzelnen Benutzer definiert und dokumentiert?
- Wurden Zugriffsrechte auf die Daten vergeben und dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.130 Gewhrleistung der Datenbankintegritt

Verantwortlich fr Umsetzung: Administrator, Verantwortliche der einzelnen
IT-Anwendungen
Die Integrittssicherung und -berwachung in einer Datenbank soll die
Korrektheit der zugehrigen Daten bzw. einen korrekten Zustand der Daten-
bank gewhrleisten. Die folgenden Techniken sind zur Vermeidung inkorrek-
ter Daten bzw. Zustnde innerhalb einer Datenbank zu beachten:
- Zugriffskontrolle
Damit ist der Schutz der betreffenden Datenbank vor unautorisiertem
Zugriff mittels der Vergabe von Zugriffsrechten gemeint, wie in M 2.129
Zugriffskontrolle einer Datenbank beschrieben. Damit wird dem manipu-
lativen ndern von Daten bzw. Datenbankobjekten (wie z. B. Tabellen)
vorgebeugt.
Verantwortlich fr die Umsetzung der Zugriffskontrolle ist der Daten-
bankadministrator.
Auf eine detaillierte Ausfhrung wird an dieser Stelle verzichtet und statt
dessen auf die Manahme M 2.129 Zugriffskontrolle einer Datenbank
verwiesen
- Synchronisationskontrolle
Die Synchronisationskontrolle dient der Verhinderung von Inkonsistenzen,
die durch einen parallelen Zugriff auf denselben Datenbestand entstehen
knnen. Es gibt dazu verschiedene Techniken, wie z. B. das Sperren von
Datenbankobjekten (Locking) oder die Vergabe von Zeitstempeln
(Timestamps).
Verantwortlich fr die Umsetzung sind die Verantwortlichen der IT-
Anwendungen, insofern ein zustzlicher Mechanismus zur Verfgung
gestellt werden muss, der ber die Mglichkeiten des DBMS hinausgeht.
Auf eine detaillierte Ausfhrung wird verzichtet, da im allgemeinen jedes
DBMS eine Synchronisationskontrolle durchfhrt. Vom Einsatz eines
DBMS, welches dies nicht leisten kann, wird dringend abgeraten.
- Integrittskontrolle
Hierunter fllt die Vermeidung semantischer Fehler bzw. semantisch
unsinniger Zustnde der Datenbank durch Einhaltung und berwachung
der geforderten Integrittsbedingungen. Diese knnen sich auf einzelne
Relationen beziehen oder mehrere Relationen miteinander in Beziehung
setzen (referentielle Integritt). Beispiele sind die Angabe eines Primr-
schlssels fr eine Relation, die Definition von Wertebereichen zu den
einzelnen Attributen oder die Formulierung spezieller Bedingungen mittels
einer assertion-Klausel.
Dies kann durch das DBMS automatisch mittels eines Monitors berprft
werden, der z. B. durch die Verwendung von Triggern oder Stored
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Procedures realisiert werden kann. Damit sind prinzipiell beliebige Trans-

aktionen mglich, jedoch werden diejenigen vom DBMS zurckgewiesen,
die die Datenbank-Konsistenz verletzen wrden.
Verantwortlich fr die Umsetzung sind die Verantwortlichen der IT-
Anwendungen respektive der fachliche Administrator, falls es sich um eine
Umsetzung der Integrittsbedingungen in Form von Relationen,
Primrschlsseln oder allgemeinen Datenbankobjekten handelt.
Im Rahmen der Konzeption einer IT-Anwendung sind zu erstellen
- ein Datenmodell, welches neben den Datenbankobjekten auch deren
Beziehungen untereinander abbildet, und
- ein Fachkonzept, welches u. a. Bedingungen beschreibt, unter denen
Daten manipuliert werden drfen.
Im Rahmen der Realisierung einer IT-Anwendung sind die folgenden
Punkte zu beachten:
- Die konkrete Umsetzung des in der konzeptionellen Phase definier-
ten Datenmodells muss festgelegt werden. Hierzu gehren die
Definition und Anlage von Tabellen, Indizes, Wertebereichen usw.
- Die Definition von Triggern oder Stored Procedures erfolgt im
Rahmen der Realisierung des Fachkonzepts. Trigger und Stored
Procedures knnen dabei sowohl innerhalb der Anwendung (in den
Programmen), als auch der Datenbank (fr Tabellen) Verwendung
finden. Trigger, die auf Datenbankebene eingesetzt werden, wirken
unabhngig von darberliegenden Anwendungen und sind aus
diesem Grund zentral zu verwalten.
Beispiel: Trigger Update fr eine Tabelle:
Immer wenn ein Datensatz der Tabelle gendert wird, dann sind die
fr den Trigger definierten Anweisungen auszufhren. Eine dieser
Anweisungen kann der Aufruf einer Stored Procedure sein.
Im Rahmen von Anwendungen kann eine Integrittssicherung durch einen
geeigneten Einsatz von Commit bzw. Rollback fr das Bettigen bzw. Wider-
rufen von Transaktionen realisiert werden.
- Werden alle oben angegebenen Techniken zur Integrittssicherung einge-
setzt?
- Wurden die Integrittsbedingungen mit den Verantwortlichen der einzel-
nen IT-Anwendungen abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.131 Aufteilung von Administrationsttigkeiten bei

Datenbanksystemen
Verantwortlich fr Umsetzung: Administrator, IT-Sicherheitsmanagement
Um einen geordneten Betrieb von Datenbanksystemen zu ermglichen, sind
Administratoren zu bestimmen. Diesen obliegt neben allgemeinen Admini-
strationsarbeiten insbesondere die Benutzerverwaltung einschlielich der
Verwaltung der Zugriffsrechte. Zustzlich sind sie fr die Sicherheitsbelange
der betreuten Datenbanksysteme zustndig.
Neben den in M 2.26 Ernennung eines Administrators und eines Vertreters
und M 3.10 Auswahl eines vertrauenswrdigen Administrators und Vertreters
genannten Manahmen sind speziell fr Datenbanksysteme folgende Dinge zu
beachten.
Es sollten grundstzlich zwei verschiedene Administrator-Rollen unterschie-
den werden:
- die fachlich bergreifende Administration der Datenbank-Software und
- die Administration der anwendungsspezifischen Belange.
Diese beiden Aufgaben sollten von verschiedenen Personen durchgefhrt
werden, um eine Trennung der anwendungsspezifischen und fachlich ber-
greifenden Administration einer Datenbank zu erreichen.
Der grundstzliche Betrieb des DBMS, die Durchfhrung der Datensicherun-
gen oder die Archivierung von Datenbestnden sind beispielsweise Bestand-
teil der fachlich bergreifenden Datenbankadministration.
Bei der anwendungsspezifischen Administration werden dagegen die Erfor-
dernisse der einzelnen Anwendungen an die Datenbank bearbeitet. Dies kann
z. B. die Verwaltung der zugehrigen Datenbankobjekte, die Untersttzung
der Benutzer bei Problemen bzw. Fragen oder die Verwaltung der entspre-
chenden Datenbankkennungen beinhalten. Letzteres ist allerdings nur dann
mglich, wenn die Verwaltung der Datenbankkennungen je Anwendung ber
ein entsprechendes Berechtigungskonzept durch die Datenbank-Software
untersttzt wird, also von den fachlich bergreifenden Berechtigungen
getrennt werden kann.
Der fachlich bergreifende Administrator richtet die fr die anwendungsspe-
zifischen Belange zustndigen Administratorkennungen mit den zugehrigen
Berechtigungen ein. Dazu gehrt insbesondere das Recht, Datenbanken anzu-
legen. Die Rechtevergabe fr die einzelnen Benutzer sollte dagegen fr jede
anwendungsspezifische Datenbank getrennt durchgefhrt werden und zwar
vom jeweils zustndigen anwendungsspezifischen Administrator.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind die Administrator-Rollen getrennt worden?
- Welche Administratoren sind fr die fachlich bergreifende Administration
der Datenbank-Software und welche fr die Administration der
anwendungsspezifischen Belange benannt worden?
- Wie ist die Zusammenarbeit zwischen den Administratoren geregelt? Sind
deren Aufgaben und Zustndigkeitsbereiche schriftlich fixiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.132 Regelung fr die Einrichtung von

Datenbankbenutzern/-benutzergruppen
Fr die Einrichtung von Benutzern/Benutzergruppen in einer Datenbank
bilden die Voraussetzung fr eine angemessene Vergabe von Zugriffsrechten
(siehe M 2.129 Zugriffskontrolle einer Datenban) und fr die Sicherstellung
eines geordneten und berwachbaren Betriebsablaufs. Im allgemeinen erhlt
dazu jeder Datenbankbenutzer eine interne Datenbankkennung, ber die ihn
das Datenbanksystem identifiziert. Damit knnen nur autorisierte Personen
auf die Datenbank zugreifen.
In Anlehnung an M 2.30 Regelung fr die Einrichtung von Benutzern /
Benutzergruppen sollte ein Formblatt existieren, um von jedem Benutzer bzw.
fr jede Benutzergruppe zunchst die erforderlichen Daten abzufragen:
- Name, Vorname,
- Vorschlag fr die Benutzer-Kennung (wenn nicht durch Konventionen vor-
gegeben),
- Organisationseinheit,
- Erreichbarkeit (z. B. Telefon, Raum),
- ggf. Projekt,
- ggf. Anwendungen, die benutzt werden sollen und auf das Datenbanks-
ystem zugreifen,
- ggf. Angaben ber die geplante Ttigkeit im Datenbanksystem und die
dazu erforderlichen Rechte sowie die Dauer der Ttigkeit,
- ggf. Restriktionen auf Zeiten, Zugriffsberechtigungen (fr bestimmte
Tabellen, Views etc.), eingeschrnkte Benutzerumgebung,
- ggf. Zustimmung von Vorgesetzten.
Es sollte eine begrenzte Anzahl von Rechteprofilen festgelegt werden. Ein
neuer Benutzer wird dann einem oder mehreren Profilen zugeordnet und erhlt
damit genau die fr seine Ttigkeit erforderlichen Rechte. Dabei sind die
datenbankspezifischen Mglichkeiten bei der Einrichtung von Benutzern und
Gruppen zu beachten. Es ist sinnvoll, Namenskonventionen fr die Benutzer-
und Gruppenkennungen festzulegen (z. B. Benutzer-ID = Krzel
Organisationseinheit || lfd. Nummer).
Dabei knnen Benutzer-, Rollen- und Gruppenprofile benutzt werden. Soweit
mglich, sollten jedoch keine benutzerspezifischen Profile verwendet werden,
da dies bei einer groen Anzahl von Benutzern zu einem hohen administra-
tiven Aufwand fhrt. Bei der Definition von Gruppenprofilen muss man
zwischen restriktiven und grozgigen Berechtigungsprofilen abwgen.
Werden die Gruppenprofile zu restriktiv gehandhabt, muss eine groe Anzahl
von Gruppen verwaltet werden, was zu einem hohen administrativen Aufwand
fhrt. Werden die Gruppenprofile dagegen zu grozgig definiert,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
kann es zu Redundanzen zwischen verschiedenen Gruppen kommen oder zur

Einrumung von unntig umfangreichen Rechten, was wiederum zur Ver-
letzung der Vertraulichkeit von Daten fhren kann.
In der Regel muss jedem Benutzer eine eigene Datenbankkennung zugeordnet
sein, es drfen nicht mehrere Benutzer unter derselben Kennung arbeiten.
Normalerweise besteht zwischen der Datenbankkennung und der Benutzer-
Kennung des zugrunde liegenden Betriebssystems keine Verbindung. Einige
Hersteller bieten in ihrer Datenbank-Software jedoch die Mglichkeit an, die
Betriebssystemkennung in das Datenbanksystem zu bernehmen. Dies erspart
den Anwendern eine Passwortabfrage fr den Zugang zur Datenbank, falls
diese sich bereits mit Ihrer eigenen Betriebssystemkennung angemeldet haben.
So knnen beispielsweise unter Oracle so genannte OPS$-Kennungen ver-
wendet werden. Eine solche Kennung setzt sich aus dem Prfix "OPS$" und
der Betriebssystemkennung des Anwenders zusammen. Nur wenn sich ein
Anwender mit seiner Betriebssystemkennung am Datenbanksystem anmeldet,
wird kein Passwort vom DBMS abgefragt. Meldet sich der Anwender dagegen
unter einer anderen Kennung an, so erfolgt eine Passwortabfrage.
Diese Mglichkeit beinhaltet allerdings die Gefahr, dass bei einer Schutzver-
letzung auf Betriebssystemebene (z. B. das Knacken des entsprechenden
Passwortes) der Zugriff auf die Datenbank nicht mehr verhindert werden kann.
Der Schutz der Datenbank ist demnach stark von der Sicherheit des zugrunde
liegenden Betriebssystems abhngig. Dabei handelt es sich im allgemeinen
nicht um das blicherweise sichere Betriebssystem des Datenbank-Servers,
sondern um das eines Clients, der unter Umstnden wesentlich schwcher
geschtzt ist. Deshalb wird von der Verwendung dieser Mglichkeit
abgeraten, statt dessen sollte bei der Forderung nach einer einfachen
Handhabung fr die Benutzer (Stichwort Single-Sign-On) der Einsatz eines
Zusatzproduktes zur zentralen Benutzerverwaltung fr den gesamten IT-
Betrieb erwogen werden (z. B. ISM Access Master von Bull). Aber auch hier
mssen die konkreten Sicherheitsanforderungen mit dem entsprechenden
Zusatzprodukt abgeglichen werden.
- Welche organisatorischen Regelungen zur Einrichtung von Datenbankbe-
nutzern bzw. -benutzergruppen gibt es?
- Wurden Namenskonventionen fr die Benutzer- und Gruppenkennungen
festgelegt?
- Wurden Rechteprofile angelegt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.133 Kontrolle der Protokolldateien eines

Datenbanksystems
Verantwortlich fr Umsetzung: Administrator, Revisor
Die in einem Datenbanksystem mgliche Protokollierung bzw. Auditierung ist
in einem sinnvollen Umfang zu aktivieren. Werden zuviele Ereignisse
protokolliert, wird die Performance der Datenbank negativ beeinflusst und die
Protokolldateien wachsen stark an. Es muss also immer zwischen dem
Bedrfnis, mglichst viele Informationen zur Sicherheit der Datenbank zu
sammeln, und der Mglichkeit, diese Informationen zu speichern und auszu-
werten, abgewogen werden.
Dabei sind insbesondere folgende Vorkommnisse von Interesse:
- Anmeldezeiten und -dauer der Benutzer,
- Anzahl der Verbindungen zur Datenbank,
- fehlgeschlagene bzw. abgewiesene Verbindungsversuche,
- Auftreten von Deadlocks innerhalb des Datenbanksystems,
- I/O-Statistik fr jeden Benutzer,
- Zugriffe auf die Systemtabellen (siehe auch M 4.69 Regelmiger
Sicherheitscheck der Datenbank),
- Erzeugung neuer Datenbankobjekte und
- Datenmodifikationen (evtl. mit Datum, Uhrzeit und Benutzer).
Die Protokollierung sicherheitsrelevanter Ereignisse ist als Sicherheits-
manahme allerdings nur dann wirksam, wenn die protokollierten Daten auch
ausgewertet werden. Daher sind die Protokolldateien in regelmigen
Abstnden durch einen Revisor auszuwerten. Ist es organisatorisch oder
technisch nicht mglich, einen unabhngigen Revisor mit der Auswertung der
Protokolldateien zu betrauen, ist eine Kontrolle der Ttigkeiten des Admini-
strators nur schwer mglich.
Die Protokolldaten mssen regelmig gelscht werden, um ein bermiges
Anwachsen der Protokolldateien zu verhindern. Sie drfen allerdings nur dann
gelscht werden, wenn die Protokolldateien vorher ausgewertet und
kontrolliert wurden. Dies kann manuell oder automatisch geschehen, falls
entsprechende Werkzeuge zur Verfgung stehen.
Weiterhin ist der Zugriff auf die Protokolldateien strikt zu beschrnken.
Einerseits muss verhindert werden, dass Angreifer ihre Aktionen durch nach-
trgliche nderung der Protokolldateien verbergen knnen, andererseits
knnten ber die gezielte Auswertung von Protokolldateien Leistungsprofile
der Benutzer erstellt werden. Deshalb drfen beispielsweise nderungen
berhaupt nicht vorgenommen werden knnen und lesender Zugriff darf nur
den Revisoren gestattet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Um die Auswertung der Protokolldaten zu vereinfachen, knnen vom Daten-

bank-Administrator zustzliche Tools eingesetzt werden, die eine automa-
tisierte berwachung durchfhren. Solche Produkte knnen beispielweise die
Log-Dateien von Datenbanksystemen nach vorgegebenen Mustern auswerten
und bei Bedarf einen Alarm erzeugen.
Weitere Manahmen, die in diesem Zusammenhang beachtet werden mssen,
sind in M 2.64 Kontrolle der Protokolldateien zu finden.
- Wer wertet die Protokolldateien aus? Findet das Vier-Augen-Prinzip
Anwendung?
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.134 Richtlinien fr Datenbank-Anfragen

Verantwortlich fr Umsetzung: Anwendungsentwickler
Die relationale Datenbanksprache SQL (Standard Query Language) ist eine
international standardisierte Sprache fr relationale Datenbanksysteme, die
eine weite Verbreitung erfahren hat und in den meisten DBMS implementiert
ist. Mittels SQL knnen sowohl Modifikationen der Daten (UPDATE,
INSERT, DELETE), als auch der Datenbankobjekte formuliert (CREATE,
ALTER, DROP) sowie Informationen abgefragt werden (SELECT). Um einen
sicheren Betrieb eines Datenbanksystems zu gewhrleisten, sollten die folgen-
den Grundstze in einer Richtlinie fr Datenbank-Anfragen beschrieben sein.
- SQL-Anfragen sollten so exakt wie mglich formuliert werden. Dies gilt
insbesondere fr SQL-Anfragen, die aus Anwendungen heraus gestellt
werden. So fhrt beispielsweise die SQL-Anweisung
SELECT * FROM <Tabelle> WHERE <Bedingung>
bei nderungen des Tabellenschemas (Hinzufgen bzw. Lschen von Fel-
dern oder Vertauschen der Reihenfolge von Feldern) unweigerlich zu
Fehlern oder sogar zu einem Absturz der zugehrigen Anwendung.
- Felder sollten immer explizit angegeben werden. Damit ist sichergestellt,
dass die Daten in der erwarteten Reihenfolge zur Verfgung stehen und
beispielsweise nur diejenigen Daten selektiert werden, die man tatschlich
bentigt.
Beispiel:
Eine Tabelle besteht aus den folgenden Feldern (mit den zugehrigen
Datentypen):
Artikelnummer NUMBER(10)
Nettopreis NUMBER(10,2)
Artikelbezeichnung VARCHAR(30)
Verwendungszweck VARCHAR(200)
Es wird das neue Feld "Bestellnummer" vom Typ NUMBER(8) hinzuge-
fgt. Das Feld wird aus Grnden der optimalen Speicherausnutzung nicht
am Ende, sondern an die zweite Stelle der Tabelle plaziert. Die neue
Tabelle sieht also wie folgt aus:
Artikelnummer NUMBER(10)
Bestellnummer NUMBER(8)
Nettopreis NUMBER(10,2)
Artikelbezeichnung VARCHAR(30)
Verwendungszweck VARCHAR(200)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
In einem solchen Fall wrde eine SELECT-*-Anweisung in einer Anwen-

dung im schlimmsten Fall zu einem Absturz fhren, da die Daten automa-
tisch in der angegebenen Feldreihenfolge selektiert werden. Im obigen
Beispiel wrde dann nicht nur das Problem auftreten, dass die Tabelle um
ein Feld ergnzt wurde (dessen Daten zustzlich selektiert wrden),
sondern, dass durch die Vernderung der Feldreihenfolge die Daten nicht
mehr in der ursprnglichen Reihenfolge selektiert wrden. Dies fhrt
unweigerlich zu Typkonflikten und einem mglichen Programmabsturz.
- Fr einschrnkende Datenbankanfragen (WHERE-Klausel) ist die Reihen-
folge der angegebenen Selektionsbedingungen von groer Bedeutung. Die
WHERE-Klausel sollte so formuliert werden, dass als erstes diejenige
Bedingung angegeben wird, die die kleinstmgliche Ergebnismenge
selektiert und erst zum Schluss die Bedingung greift, die die grte Ergeb-
nismenge liefern wrde. Auf diese Weise wird die Performance des
Datenbanksystems optimiert, da sich durch die geschickte Anordnung der
Selektionsbedingungen der Suchvorgang erheblich verkrzen lsst. Das
gleiche gilt analog fr Datenbankanfragen, die ber mehrere Tabellen
hinweg formuliert werden (so genannte Joins).
Es sei an dieser Stelle erwhnt, dass Datenbankmanagementsysteme bereits
hufig Datenbankanfragen selbstndig optimieren. Oft werden sogar
mehrere Optimierungsstrategien zur Auswahl angeboten, die ber ver-
schiedene Parameter ausgewhlt werden knnen. Werden diese so genann-
ten Optimizer vom DBMS verwendet, kann dies allerdings dazu fhren,
dass sorgfltig formulierte Datenbankabfragen intern vom DBMS nicht in
der erwarteten Art und Weise abgearbeitet werden.
In diesem Zusammenhang bieten einige Datenbankmanagementsysteme
die Mglichkeit, die Abarbeitung von Datenbankanfragen zu untersuchen
(z. B. in Oracle mit EXPLAIN oder fr Ingres mittels SETOEP). Deswei-
teren besteht die Mglichkeit, ber so genannte HINTS in der Daten-
bankanfrage deren Abarbeitung explizit zu definieren und somit den
Optimizer im Prinzip auszuschalten. Von dieser Mglichkeit sollte aller-
dings so wenig wie mglich Gebrauch gemacht werden.
Welche Optimizer das DBMS untersttzt sowie deren Vor- und Nachteile
sind in den Handbchern des DBMS normalerweise dokumentiert. Falls
mehrere Optimizer zur Auswahl stehen, sollte beim Administrator nachge-
fragt werden, welcher Optimizer eingesetzt wird.
- Im Falle von Joins sollte zustzlich beachtet werden, dass die Zuordnung
von Feldern zu den Tabellen eindeutig erfolgt.
Beispiel:
TabA: ID NUMBER(4)
Herstellernr. NUMBER(6)
TabB: ID NUMBER(4)
Artikelnr. NUMBER(10)
Preis NUMBER(10,2)
Bezeichnung VARCHAR(30)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SELECT TabA.ID, TabB.Bezeichnung, TabB.Preis

FROM TabA, TabB
WHERE TabA.ID=TabB.ID
Das Feld "ID" ist in beiden Tabellen vorhanden und muss deshalb bei der
Datenbankanfrage explizit mit dem zugehrigen Tabellennamen angegeben
werden. Andernfalls ist die Eindeutigkeit der Auswahl nicht mehr
sichergestellt und die Datenbankanfrage wird mit einer entsprechenden
Fehlermeldung abgebrochen.
Alle anderen Felder sind in diesem Fall eindeutig zuordenbar. Eine
explizite Angabe des zugehrigen Tabellennamens fr jedes Feld wird von
SQL nicht gefordert. Trotzdem sollten fr die einzelnen Felder die ein-
deutige Zuordnung zur Tabelle erfolgen, wie im obigen Beispiel fr die
Felder "Preis" und "Bezeichnung" der Tabelle TabB. Nur so knnen
unvorhergesehene Probleme vermieden werden.
Das Hinzufgen eines Feldes "Bezeichnung" fr TabA wrde im obigen
Beispiel zu keinen Problemen fhren. Dies wre jedoch nicht der Fall,
wenn die SQL-Anweisung die Zuordnung der Felder zu den Tabellen nicht
explizit beinhalten wrde. Es wre nicht mehr eindeutig, ob das Feld
"Bezeichnung" von TabA oder TabB selektiert werden soll, da beide
Tabellen nach der nderung von TabA ein Feld mit diesem Namen haben.
Die SQL-Anweisung wrde mit einer Fehlermeldung abgebrochen.
- Existieren Views auf Tabellen, so sollten diese auch fr die Formulierung
von Datenbankanfragen benutzt werden.
- Alle Datenbanktransaktionen sollten explizit mit einem COMMIT besttigt
werden. Falls das DBMS ein automatisches COMMIT untersttzt, sollte
dieses nicht aktiviert werden, da es sonst u. U. zu ungewollten
Inkonsistenzen in der Datenbank kommen kann.
Beispiel: Mehrere einzelne Modifikationen gehren logisch zusammen,
werden aber automatisch durch ein COMMIT besttigt. Kommt es nun zu
einem unkontrollierten Abbruch der Transaktion und infolgedessen zu
einem Rollback, sind die zuerst ausgefhrten Operationen bereits besttigt
und verbleiben in der Datenbank, whrend der Rest noch gar nicht durch-
gefhrt werden konnte.
- Zur Vermeidung von Sperrkonflikten oder gar Deadlocks ist fr jede fach-
liche Datenbank eine Sperrstrategie festzulegen (z. B. hierarchisches
Sperren oder explizites Sperren aller Tabellen am Anfang der Transaktion).
- Anwendungsentwickler sollten nach jeder SQL-Anweisung den Fehler-
status prfen, so dass die Anwendung so frh wie mglich auf eingetretene
Fehler reagieren kann.
- Falls das DBMS bestimmte systemspezifische Kommandos untersttzt, mit
denen beispielsweise die Protokollierung ausgeschaltet oder das Locking-
Verfahren verndert werden kann, sollten die Berechtigungen fr diese
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kommandos den Benutzern entzogen werden. Hier ist also im Vorfeld

genau zu klren, welche systemspezifischen Einstellungen bzw.
Kommandos von den Benutzern bzw. den Anwendungsentwicklern gen-
dert bzw. benutzt werden drfen.
- Bei der Entwicklung von Anwendungen sollten alle Datenbankzugriffe in
einem Modul oder einem bestimmten Teil des Programmcodes zusammen-
gefasst werden, da sonst zur berprfung der obigen Grundstze der
gesamte Programmcode des Anwendungssystems herangezogen werden
msste. Hierdurch wird die Wartung und Pflege des Anwendungssystems,
z. B. bei nderungen des Datenmodells, erleichtert.
- Sind Richtlinien fr Datenbank-Anfragen erstellt worden?
- Sind den Anwendungsentwicklern die Richtlinien fr Datenbank-Anfragen
bekannt?
- Wie wird die Einhaltung dieser Richtlinien berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.135 Gesicherte Datenbernahme in eine Datenbank

In vielen Datenbanksystemen besteht aus Anwendungssicht die Notwendig-
keit, Daten aus anderen Systemen zu bernehmen. Dabei lassen sich prinzi-
piell die beiden folgenden Kategorien unterscheiden:
- Erst- oder Altdatenbernahme
Dies betrifft die bernahme von Daten aus Altsystemen, wenn beispiels-
weise ein neues Datenbanksystem beschafft wurde und produktiv einge-
setzt werden soll. Hierbei ist insbesondere sicherzustellen, dass
- die Daten in einem Format vorliegen, das in die Zieldatenbank
bernommen werden kann,
- die Daten vollstndig sind, d. h. fr alle Felder, die in der Zieldaten-
bank gefllt werden sollen, mssen Daten zur bernahme zur Ver-
fgung gestellt werden, und
- die Konsistenz und Datenintegritt der Datenbank gewhrleistet ist.
Im Vorfeld der Datenbernahme ist ein Konzept zu erstellen, wie die zu
bernehmenden Daten aufbereitet werden mssen und wie die bernahme
konkret durchgefhrt werden soll. Weiterhin ist unbedingt eine Komplett-
sicherung der Altdaten vorzunehmen. Erfolgt die Datenbernahme in
mehreren Schritten, sollte vor jedem einzelnen Schritt eine unabhngige
Datensicherung durchgefhrt werden.
- Regelmige Datenbernahme
Befinden sich in der Zieldatenbank bei einer Datenbernahme bereits
Daten, die nicht verndert werden drfen, oder werden in regelmigen
Zeitabstnden Daten in eine Datenbank bernommen, so
- ist vor der Datenbernahme eine Komplettsicherung der Datenbank
durchzufhren,
- sollte die Datenbernahme, wenn mglich, auerhalb der regulren
Betriebszeiten stattfinden,
- mssen die betroffenen Benutzer von der bevorstehenden Daten-
bernahme rechtzeitig informiert werden, insbesondere dann, wenn
mit Einschrnkungen hinsichtlich der Verfgbarkeit oder des
Antwortzeitverhaltens zu rechnen ist,
- ist vor der ersten Datenbernahme ein Konzept zu erstellen, wie die
zu bernehmenden Daten aufbereitet werden mssen bzw. wie die
bernahme konkret durchzufhren ist. Insbesondere muss in diesem
Konzept bercksichtigt werden, wie Konflikte zwischen den bereits
existierenden Daten in der Zieldatenbank und den zu bernehmen-
den Daten vermieden werden, d. h. inwieweit die Integritt und
Konsistenz der Zieldatenbank gewahrt bleibt. Des weiteren sind
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorkehrungen zu treffen, um eine mehrfache bernahme der glei-

chen Daten zu verhindern.
Vor der Durchfhrung einer Datenbernahme ist festzulegen, was beim Auf-
treten von Fehlern zu unternehmen ist. Dies beinhaltet z. B., ob beim Auftre-
ten eines fehlerhaften Datensatzes mit dem nchsten Satz fortgefahren werden
kann, oder ob die komplette Datenbernahme abgebrochen werden muss.
Weiterhin ist festzulegen, wie die Datenbernahme nach einem Abbruch
wieder aufgesetzt wird.
- Wurde ein Konzept zur Datenbernahme erstellt?
- Erfolgt vor einer Datenbernahme eine Komplettsicherung der Datenbank?
- Werden die Benutzer bei einer Datenbernahme rechtzeitig und umfassend
informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.136 Einhaltung von Regelungen bzgl. Arbeitsplatz

und Arbeitsumgebung
Verantwortlich fr Initiierung: Leiter Haustechnik, Personalrat/Betriebsrat
Verantwortlich fr Umsetzung: Vorgesetzte, Personalrat/Betriebsrat,
Mitarbeiter
Am huslichen Arbeitsplatz mssen dieselben Vorschriften und Richtlinien
bezglich der Gestaltung des Arbeitsplatzes (z. B. Einrichtung eines Bild-
schirmarbeitsplatzes) und der Arbeitsumgebung gelten wie in der Institution.
Dies sollte in Absprache mit dem Telearbeiter durch den in der Institution
Verantwortlichen fr den Arbeits- und Gesundheitsschutz, dem IT-Sicher-
heitsbeauftragten, dem Datenschutzbeauftragten sowie dem Betriebs- bzw.
Personalrat und dem direkten Vorgesetzten des Telearbeiters begutachtet wer-
den knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.137 Beschaffung eines geeigneten

Datensicherungssystems
Ein Groteil der Fehler, die beim Erstellen oder Restaurieren einer Daten-
sicherung auftreten, sind Fehlbedienungen. Daher sollte bei der Beschaffung
eines Datensicherungssystem nicht allein auf seine Leistungsfhigkeit geach-
tet werden, sondern auch auf seine Bedienbarkeit und insbesondere auf seine
Toleranz gegenber Benutzerfehlern.
Bei der Auswahl von Sicherungssoftware sollte darauf geachtet werden, dass
sie die folgenden Anforderungen erfllt:
- Die Datensicherungssoftware sollte ein falsches Medium ebenso wie ein
beschdigtes Medium im Sicherungslaufwerk erkennen knnen.
- Sie sollte mit der vorhandenen Hardware problemlos zusammenarbeiten.
- Es sollte mglich sein, Sicherungen automatisch zu vorwhlbaren Zeiten
bzw. in einstellbaren Intervallen durchfhren zu lassen, ohne dass hierzu
manuelle Eingriffe (auer dem eventuell notwendigen Bereitstellen von
Sicherungsdatentrgern) erforderlich wren.
- Es sollte mglich sein, einen oder mehrere ausgewhlte Benutzer automa-
tisch ber das Sicherungsergebnis und eventuelle Fehlermeldungen per E-
Mail oder hnliche Mechanismen zu informieren. Die Durchfhrung von
Datensicherungen inklusive des Sicherungsergebnisses und mglicher
Fehlermeldungen sollten in einer Protokolldatei abgespeichert werden.
- Die Sicherungssoftware sollte die Sicherung des Backup-Mediums durch
ein Passwort, oder noch besser durch Verschlsselung untersttzen.
Weiterhin sollte sie in der Lage sein, die gesicherten Daten in komprimier-
ter Form abzuspeichern.
- Durch Vorgabe geeigneter Include- und Exclude-Listen bei der Datei- und
Verzeichnisauswahl sollte genau spezifiziert werden knnen, welche Daten
zu sichern sind und welche nicht. Es sollte mglich sein, diese Listen zu
Sicherungsprofilen zusammenzufassen, abzuspeichern und fr sptere
Sicherungslufe wieder zu benutzen.
- Es sollte mglich sein, die zu sichernden Daten in Abhngigkeit vom
Datum ihrer Erstellung bzw. ihrer letzten Modifikation auszuwhlen.
- Die Sicherungssoftware sollte die Erzeugung logischer und physischer
Vollkopien sowie inkrementeller Kopien (nderungssicherungen) unter-
sttzen.
- Die zu sichernden Daten sollten auch auf Festplatten und Netzlaufwerken
abgespeichert werden knnen.
- Die Sicherungssoftware sollte in der Lage sein, nach der Sicherung einen
automatischen Vergleich der gesicherten Daten mit dem Original durchzu-
fhren und nach der Wiederherstellung von Daten einen entsprechenden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vergleich zwischen den rekonstruierten Daten und dem Inhalt des

Sicherungsdatentrgers durchzufhren.
- Bei der Wiederherstellung von Dateien sollte es mglich sein auszuwhlen,
ob die Dateien am ursprnglichen Ort oder auf einer anderen Platte bzw. in
einem anderen Verzeichnis wiederhergestellt werden. Ebenso sollte es
mglich sein, das Verhalten der Software fr den Fall zu steuern, dass am
Zielort schon eine Datei gleichen Namens vorhanden ist. Dabei sollte man
whlen knnen, ob diese Datei immer, nie oder nur in dem Fall, dass sie
lter als die zu rekonstruierende Datei ist, berschrieben wird, oder dass in
diesem Fall eine explizite Anfrage erfolgt.
Falls mit dem eingesetzten Programm die Datensicherung durch Passwort
geschtzt werden kann, sollte diese Option genutzt werden. Das Passwort ist
dann gesichert zu hinterlegen (siehe M 2.22 Hinterlegen des Passwortes).
Bei den meisten Betriebssystemen werden Programme fr Datensicherungen
mitgeliefert. Nicht alle erfllen allerdings die Ansprche an Produkte fr pro-
fessionelle und komfortable Datensicherungen. Stehen aber keine solchen
Produkte zur Verfgung, so sollten die systemzugehrigen Programme ver-
wendet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.138 Strukturierte Datenhaltung

Eine schlecht strukturierte Datenhaltung kann zu einer Vielzahl von Proble-
men fhren. Alle IT-Benutzer sind daher darauf hinzuweisen, wie eine gut
strukturierte und bersichtliche Datenhaltung aussehen sollte. Auf allen
Servern sollten entsprechende Strukturen durch die Administratoren vorge-
geben werden. Dies ist ohnehin Voraussetzung, um eine differenzierte Ver-
gabe von Zugriffsrechten realisieren zu knnen.
Programm- und Arbeitsdateien sollten immer in getrennten Bereichen gespei- Programme und Applika-
tionsdateien trennen
chert werden. Dies sorgt fr eine bessere bersicht und erleichtert auch die
Durchfhrung von Datensicherungen und die Sicherstellung des korrekten
Zugriffsschutzes. Bei den meisten Applikationsprogrammen ndern sich nach
der Installation keine oder nur sehr wenige Konfigurationsdateien. Soweit
mglich, sollten alle Dateien, die sich regelmig ndern, in gesonderten Ver-
zeichnissen abgespeichert werden, damit nur diese in die regelmigen
Datensicherungen mitaufgenommen werden mssen.
Bei einer sauberen Trennung von Programmen und Daten reicht es, die Daten
in die regelmigen Datensicherungen aufzunehmen. Wichtig ist es, die
Arbeitsdateien sorgfltig gesichert zu haben, diese knnen dann notfalls auch
auf anderen Systemen weiterverarbeitet werden.
Bei vernetzten Systemen stellt sich auerdem die Frage, welche Programme
bzw. Dateien auf den lokalen Festplatten oder auf einem Netzserver abgelegt
werden sollten. Beides hat Vor- und Nachteile und muss sowohl von der
organisatorischen Struktur als auch von der eingesetzten Hard- und Software
abhngig gemacht werden. So sollten z. B. Dateien mit hohen Verfgbar-
keitsansprchen zusammen mit den zugehrigen Applikationsprogrammen
besser auf den Arbeitsplatzrechnern gehalten werden als auf einem Netz-
server. Dann muss allerdings auch die entsprechende Notfallvorsorge fr diese
Arbeitsplatzrechner betrieben werden.
Es sollten aufgaben- oder projektbezogene Verzeichnisse eingerichtet werden, aufgaben- oder projekt-
bezogene Verzeichnisse
um die Zuordnung von Dateien zu erleichtern. Es sollten mglichst wenig
Daten in personenbezogenen Verzeichnissen abgelegt werden.
Um zu verhindern, dass fr die weitere Arbeit grundlegenden Dateien wie
Briefvorlagen, Formularen, Projektplnen o. . unterschiedliche Versions-
stnde existieren, sollten diese zentral verwaltet werden. Sie sollten bei-
spielsweise auf einem Server so vorgehalten werden, dass jeder lesend darauf
zugreifen kann, aber es sollte fr jede solche Datei jeweils nur eine Person
geben, die sie verndern darf.
Wie auf einem Server durch Verzeichnisvorgaben Daten strukturiert werden
knnten, wird in dem folgenden Beispiel gezeigt:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
\
\bin
\bin\program1
\bin\program2
\bin\program3
\user
\user\user1
\user\user2
\projekte
\projekte\p1
\projekte\p1\texte
\projekte\p1\bilder
\projekte\p2
\projekte\p2\projektplan
\projekte\p2\teilprojekt1
\projekte\p2\ergebnis
\vordrucke
Es sollte regelmig berprft werden, Verzeichnisse regel-
mig aufrumen
- ob Daten aus dem Produktionssystem entfernt werden knnen, weil sie
archiviert oder gelscht werden knnen,
- ob Zugriffsrechte entzogen werden knnen, weil Mitarbeiter die Projekt-
gruppe verlassen haben,
- ob auf allen IT-Systemen die aktuellsten Versionen von Formularen, Vor-
lagen, etc. gespeichert sind.
Dies ist durch die Benutzer fr deren IT-Systeme bzw. die von ihnen verwal-
teten Verzeichnisse und von den Administratoren der Server regelmig zu
berprfen. Diese Prfungen sollten mindestens vierteljhrlich durchgefhrt
werden, da sonst die Kenntnisse ber Inhalt und Herkunft der Dateien wieder
aus den Gedchtnissen der Mitarbeiter verschwunden sind.
- Werden ausschlielich aufgaben- bzw. projektbezogene Verzeichnisse fr
die Datenhaltung benutzt?
- Wann wurde zuletzt berprft, ob alte Dateien gelscht bzw. archiviert
werden knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.139 Ist-Aufnahme der aktuellen Netzsituation

Die Bestandsaufnahme der aktuellen Netzsituation ist Voraussetzung fr eine
gezielte Sicherheitsanalyse des bestehenden Netzes. Sie ist ebenso erforderlich
fr die Erweiterung eines bestehenden Netzes. Bei der Planung von Netzen
sind die im folgenden beschriebenen Punkte bei der Konzeption zu
bercksichtigen.
Hierzu ist eine Ist-Aufnahme mit einhergehender Dokumentation der folgen-
den Aspekte, die z. T. aufeinander aufbauen, notwendig:
- Netztopographie,
- Netztopologie,
- verwendete Netzprotokolle,
- Kommunikationsbergnge im LAN und zum WAN sowie
- Netzperformance und Verkehrsfluss.
In den einzelnen Schritten ist im wesentlichen folgendes festzuhalten:
Ist-Aufnahme der Netztopographie
Fr die Ist-Aufnahme der Netztopographie ist die physikalische Struktur des
Netzes zu erfassen. Dabei ist es sinnvoll, sich an den rumlichen Verhlt-
nissen zu orientieren, unter denen das Netz aufgebaut wird. Es ist ein Plan zu
erstellen bzw. fortzuschreiben, der
- die aktuelle Kabelfhrung,
- die Standorte aller Netzteilnehmer, insbesondere der verwendeten aktiven
Netzkomponenten,
- die verwendeten Kabeltypen sowie
- die festgelegten Anforderungen an den Schutz von Kabeln (M 1.22
Materielle Sicherung von Leitungen und Verteilern)
enthlt. Zur Pflege dieses Plans ist es sinnvoll, ein entsprechendes Tool zur
Untersttzung einzusetzen (z. B. CAD-Programme, spezielle Tools fr Netz-
plne, Kabelmanagementtools im Zusammenhang mit Systemmanagement-
tools o. .). Eine konsequente Aktualisierung dieser Plne bei Umbauten oder
Erweiterungen ist ebenso zu gewhrleisten wie eine eindeutige und nachvoll-
ziehbare Dokumentation (vgl. auch M 1.11 Lageplne der
Versorgungsleitungen und M 5.4 Dokumentation und Kennzeichnung der
Verkabelung).
Ist-Aufnahme der Netztopologie
Fr die Ist-Aufnahme der Netztopologie ist die logische Struktur des Netzes
zu betrachten. Dazu ist es notwendig, die Segmentierung der einzelnen OSI-
Schichten und ggf. die VLAN-Struktur zu erfassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Anhand der Darstellung der Netztopologie muss feststellbar sein, ber welche
aktiven Netzkomponenten eine Verbindung zwischen zwei beliebigen End-
gerten aufgebaut werden kann. Zustzlich sind die Konfigurationen der
aktiven Netzkomponenten zu dokumentieren, die zur Bildung der Segmente
verwendet werden. Dies knnen bei logischer Segmentierung die Konfigu-
rationsdateien sein, bei physikalischer Segmentierung die konkrete Konfigu-
ration der Netzkomponenten.
Ist-Aufnahme der verwendeten Netzprotokolle
Bezogen auf die gewhlte Segmentierung des Netzes, sind die in den einzel-
nen Segmenten verwendeten Netzprotokolle und die hierfr notwendigen
Konfigurationen (z. B. die MAC-Adressen, die IP-Adressen und die Sub-
netzmasken fr das IP-Protokoll) festzustellen und zu dokumentieren. Hier
sollte auch dokumentiert werden, welche Dienste zugelassen sind (z. B.
HTTP, SMTP, Telnet) und welche Dienste nach welchen Kriterien gefiltert
werden.
Ist-Aufnahme von Kommunikationsbergngen im LAN und WAN
Die Kommunikationsbergnge im LAN und WAN sind, soweit sie nicht in
der bereits erstellten Dokumentation enthalten sind, zu beschreiben. Fr jeden
Kommunikationsbergang zwischen zwei Netzen ist zu beschreiben,
- welche bertragungsstrecken (z. B. Funkstrecke fr eine LAN/LAN-
Kopplung) hierfr eingesetzt werden,
- welche Kommunikationspartner und -dienste in welche Richtung hierber
zugelassen sind, und
- wer fr die technische Umsetzung zustndig ist.
Hierzu gehrt auch die Dokumentation der verwendeten WAN-Protokolle
(z. B. ISDN, X.25). Bei einem Einsatz einer Firewall (siehe Kapitel 7.3
Sicherheitsgateway (Firewall)) ist zustzlich deren Konfiguration (z. B.
Filterregeln) zu dokumentieren.
Ist-Aufnahme der Netzperformance und des Verkehrsflusses
Es ist eine Messung der Netzperformance und eine Analyse des Verkehrs-
flusses in und zwischen den Segmenten oder Teilnetzen durchzufhren. Fr
jedes eingesetzte Netzprotokoll mssen die entsprechenden Messungen erfol-
gen.
Bei jeder nderung der Netzsituation sind die zuletzt durchgefhrten Ist-Auf-
nahmen zu wiederholen. Die im Rahmen der Ist-Aufnahmen erstellte Doku-
mentation ist so aufzubewahren, dass sie einerseits vor unbefugtem Zugriff
geschtzt ist, aber andererseits fr das Sicherheitsmanagement oder die
Administratoren jederzeit verfgbar ist.
- Werden regelmig Performance-Messungen und Verkehrsfluss-Analysen
durchgefhrt und ausgewertet?
- Wird die erstellte Dokumentation laufend aktualisiert?
- Ist die Dokumentation auch fr Dritte verstndlich und nachvollziehbar?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.140 Analyse der aktuellen Netzsituation

Diese Manahme baut auf den Ergebnissen der Ist-Aufnahme nach M 2.139
Ist-Aufnahme der aktuellen Netzsituation auf und erfordert spezielle Kennt-
nisse im Bereich der Netztopologie, der Netztopographie und von netzspezi-
fischen Schwachstellen. Darber hinaus ist Erfahrung bei der Beurteilung der
eingesetzten individuellen IT-Anwendungen hinsichtlich Vertraulichkeit,
Integritt bzw. Verfgbarkeit notwendig. Da dies ein komplexes Gebiet ist,
das neben tief gehenden Kenntnissen in allen genannten Bereichen auch viel
Zeit erfordert, kann es zur Analyse der aktuellen Netzsituation hilfreich sein,
externe Berater hinzuzuziehen. Im Bereich der deutschen Bundesverwaltung
kann hier das BSI Hilfestellung leisten.
Eine Analyse der aktuellen Netzsituation besteht im wesentlichen aus einer
Strukturanalyse, einer Schutzbedarfsfeststellung und einer Schwachstellen-
analyse.
Eine Strukturanalyse besteht aus einer Analyse der nach M 2.139 Ist-
Aufnahme der aktuellen Netzsituation angelegten Dokumentationen. Die
Strukturanalyse muss von einem Analyseteam durchgefhrt werden, das in der
Lage ist, alle mglichen Kommunikationsbeziehungen nachzuvollziehen oder
auch herleiten zu knnen. Als Ergebnis muss das Analyseteam die Funktions-
weise des Netzes verstanden haben und ber die prinzipiellen Kommunika-
tionsmglichkeiten informiert sein. Hufig lassen sich bei der Strukturanalyse
bereits konzeptionelle Schwchen des Netzes identifizieren.
Eine erfolgreich durchgefhrte Strukturanalyse ist unbedingte Voraussetzung
fr die sich anschlieende detaillierte Schutzbedarfsfeststellung bzw. der
Schwachstellenanalyse.
Detaillierte Schutzbedarfsfeststellung
An die Strukturanalyse schliet sich eine Schutzbedarfsfeststellung an, die
ber die in Kapitel 2 genannte hinausgeht. Hier werden zustzlich die Anfor-
derungen an Vertraulichkeit, Verfgbarkeit und Integritt in einzelnen Netz-
bereichen bzw. Segmenten bercksichtigt. Hierzu ist es notwendig festzu-
stellen, welche Anforderungen aufgrund der verschiedenen IT-Verfahren
bestehen und wie diese auf die gegebene Netzsegmentierung Einfluss nehmen.
Als Ergebnis muss erkenntlich sein, in welchen Netzsegmenten besondere
Sicherheitsanforderungen bestehen.
Analyse von Schwachstellen im Netz
Basierend auf den bisher vorliegenden Ergebnissen erfolgt eine Analyse der
Schwachpunkte des Netzes. Hierzu gehrt insbesondere bei entsprechenden
Verfgbarkeitsanforderungen die Identifizierung von nicht redundant ausge-
legten Netzkomponenten (Single-Point-of-Failures). Weiterhin mssen die
Bereiche benannt werden, in denen die Anforderungen an Verfgbarkeit,
Vertraulichkeit oder Integritt nicht eingehalten werden knnen bzw. beson-
derer Aufmerksamkeit bedrfen. Zudem ist festzustellen, ob die gewhlte Seg-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
mentierung hinsichtlich Bandbreite und Performance geeignet ist (anhand der

Ergebnisse der Verkehrsflussanalyse aus M 2.139 Ist-Aufnahme der aktuellen
Netzsituation).
Beispielhafte Schwachstelle: Die Performance- und Verkehrsflussanalyse
zeigt eine berlastete aktive Netzkomponente. Fr den betreffenden
Kommunikationsweg wurden im Rahmen der Schutzbedarfsfeststellung hohe
Anforderungen an die Verfgbarkeit und damit auch an die Performance fest-
gestellt. Diese Schwachstelle erfordert eine Anpassung der Segmentierung des
Netzes oder den Austausch der Netzkomponente gegen ein leistungsfhigeres
Modell (siehe M 5.61 Geeignete physikalische Segmentierung, M 5.62
Geeignete logische Segmentierung, M 5.60 Auswahl einer geeigneten
Backbone-Technologie und M 5.13 Geeigneter Einsatz von Elementen zur
Netzkopplung).
- Ist die aktuelle Netzsituation hinreichend dokumentiert?
- Steht ausreichendes "Know How" fr eine Sicherheitsanalyse der Netz-
situation zur Verfgung?
- Sind die Anforderungen bezglich der Vertraulichkeit, Verfgbarkeit und
Integritt des Netzes und der Daten definiert und dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.141 Entwicklung eines Netzkonzeptes

Um den Anforderungen bezglich Verfgbarkeit (auch Bandbreite und
Performance), Vertraulichkeit und Integritt zu gengen, muss der Aufbau, die
nderung bzw. die Erweiterung eines Netzes sorgfltig geplant werden.
Hierzu dient die Erstellung eines Netzkonzeptes.
Die Entwicklung eines Netzkonzeptes unterteilt sich in einen analytischen und
einen konzeptionellen Teil:
Analyse
Zunchst ist zu unterscheiden, ob ein bestehendes Netz zu erweitern bzw. zu
verndern ist oder ob das Netz vollstndig neu aufgebaut werden soll.
Im ersten Fall sind vorab die Manahmen M 2.139 Ist-Aufnahme der aktuellen
Netzsituation und M 2.140 Analyse der aktuellen Netzsituation zu bearbeiten.
Im zweiten Fall entfallen diese Manahmen. Stattdessen sind die
Anforderungen an die Netzkommunikation zu ermitteln sowie eine
Schutzbedarfsfeststellung des zuknftigen Netzes durchzufhren.
Zur Ermittlung der Kommunikationsanforderungen ist der zuknftig zu
erwartende Daten- und Verkehrsfluss zwischen logischen oder organisato-
rischen Einheiten festzustellen, da die zu erwartende Last die Segmentierung
des zuknftigen Netzes beeinflussen muss. Die notwendigen logischen bzw.
physikalischen Kommunikationsbeziehungen (dienste-, anwender-, gruppen-
bezogen) sind ebenfalls zu eruieren und die Kommunikationsbergnge zur
LAN/LAN-Kopplung oder ber ein WAN zu ermitteln.
Die Schutzbedarfsanforderungen des Netzes werden aus denen der geplanten
oder bereits bestehenden IT-Verfahren abgeleitet. Daraus werden physika-
lische und logische Segmentstrukturen gefolgert, so dass diesen Anforde-
rungen (z. B. hinsichtlich Vertraulichkeit) durch eine Realisierung des Netzes
Rechnung getragen werden kann. Zum Beispiel bestimmt der Schutzbedarf
einer IT-Anwendung die zuknftige Segmentierung des Netzes.
Schlielich muss versucht werden, die abgeleiteten Kommunikationsbe-
ziehungen mit den Schutzbedarfsanforderungen zu harmonisieren. Unter
Umstnden sind hierzu Kommunikationsbeziehungen einzuschrnken, um
dem festgestellten Schutzbedarf gerecht zu werden.
Abschlieend sind die verfgbaren Ressourcen zu ermitteln. Hierzu gehren
sowohl Personalressourcen, die erforderlich sind, um ein Konzept zu erstellen
und umzusetzen bzw. um das Netz zu betreiben, als auch die hierfr notwen-
digen finanziellen Ressourcen.
Die Ergebnisse sind entsprechend zu dokumentieren.
Konzeption
Unter den oben genannten Gesichtspunkten, anhand einer Planung, die
zuknftige Anforderungen (z. B. hinsichtlich Bandbreite) mit einbezieht, so-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wie unter Bercksichtigung der rtlichen Gegebenheiten, sind die Netzstruktur

und die zu beachtenden Randbedingungen nach den folgenden Schritten zu
entwickeln und im Konzept festzuhalten.
Die Erstellung eines Netzkonzeptes erfolgt analog M 2.139 Ist-Aufnahme der
aktuellen Netzsituation und besteht danach prinzipiell aus den folgenden
Schritten, wobei diese Schritte nicht in jedem Fall streng aufeinander folgend
ausgefhrt werden knnen. In einigen Teilen beeinflussen sich die Ergebnisse
der Schritte gegenseitig, so dass eine regelmige berprfung und Konsoli-
dierung der Teilergebnisse vorgenommen werden muss.
1. Konzeption der Netztopographie und der Netztopologie, der physikalischen
und logischen Segmentierung
2. Konzeption der verwendeten Netzprotokolle
3. Konzeption von Kommunikationsbergngen im LAN und WAN
In den einzelnen Schritten sind im wesentlichen die folgenden Ttigkeiten
auszufhren:
Schritt 1 - Konzeption der Netztopographie und Netztopologie
Basierend auf der Analysesituation (s. o.) und den konkreten baulichen Gege-
benheiten muss eine geeignete Netztopographie und Netztopologie ausgewhlt
werden (siehe hierzu M 5.60 Auswahl einer geeigneten Backbone-
Technologie, M 5.2 Auswahl einer geeigneten Netz-Topographie und M 5.3
Auswahl geeigneter Kabeltypen unter kommunikationstechnischer Sicht).
Aber auch zuknftige Anforderungen wie Skalierbarkeit mssen hier
Bercksichtigung finden. Die so erstellte Konzeption muss dokumentiert
werden (Verkabelungsplne usw.).
Ausgehend von den ermittelten Anforderungen und dem zu erwartenden bzw.
ermittelten Datenfluss muss bei der Konzeption der Netztopographie und -
topologie eine geeignete physikalische und logische Segmentierung durch-
gefhrt werden (siehe M 5.61 Geeignete physikalische Segmentierung, M 5.62
Geeignete logische Segmentierung und M 5.13 Geeigneter Einsatz von
Elementen zur Netzkopplung ).
Schritt 2 - Konzeption der Netzprotokolle
In diesem Schritt sind die einzusetzenden Netzprotokolle auszuwhlen und
diese entsprechend zu konzipieren. Hierzu gehrt beispielsweise fr das IP-
Protokoll die Erstellung eines Adressierungsschemas und die Teilnetzbildung.
Fr die Auswahl der Netzprotokolle ist zu beachten, dass diese durch die
Netztopologie und die geplanten oder vorhandenen aktiven Netzkomponenten
untersttzt werden knnen.
Schritt 3 - Konzeption der Kommunikationsbergnge im LAN und
WAN
Bezogen auf den ermittelten Datenfluss ber Kommunikationsbergnge hin-
weg und die Anforderungen bezglich der Sicherheit und Verfgbarkeit
knnen in diesem Schritt die Kommunikationsbergnge konzipiert werden.
Hierzu gehrt die Auswahl geeigneter Koppelelemente (siehe M 5.13
Geeigneter Einsatz von Elementen zur Netzkopplung) aber auch die sichere
Konfi-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
guration derselben (siehe Kapitel 7.3 Sicherheitsgateway (Firewall) und

M 4.82 Sichere Konfiguration der aktiven Netzkomponenten ).
Weitere Schritte
Ausgehend von dem erstellten Netzkonzept knnen nun die Manahmen zur
Erstellung eines Netzmanagement-Konzeptes durchgefhrt werden (siehe
M 2.143 Entwicklung eines Netzmanagementkonzeptes, M 2.144 Geeignete
Auswahl eines Netzmanagement-Protokolls und M 2.145 Anforderungen an
ein Netzmanagement-Tool) und ein Realisierungsplan nach M 2.142
Entwicklung eines Netz-Realisierungsplans ausgearbeitet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.142 Entwicklung eines Netz-Realisierungsplans

Fr die Erstellung eines Netz-Realisierungsplans ist zu unterscheiden, ob es
sich um einen vollstndigen Neuaufbau des Netzes, um eine Vernderung der
bestehenden Konzeption und/oder eine Erweiterung handelt.
Bei einer vollstndigen Neuplanung sind anhand der entwickelten Netz-
konzeption (vgl. M 2.141 Entwicklung eines Netzkonzeptes) die notwendigen
Schritte abzuleiten. Dabei erfolgt nach abgeschlossener Planung der Aufbau
des Netzes ber das Verlegen der notwendigen Kommunikationskabel, das
Einrichten von Rumen fr die technische Infrastruktur, das Installieren der
versorgenden technischen Infrastruktur, die Integration der notwendigen
Koppelelemente (Bridges, Switches, Router etc.), das Einrichten der
Netzmanagement-Stationen, den Einbau der entsprechenden Netzadapater in
den Endgerten, bis hin zur Konfiguration dieser Endgerte.
Soll ein bestehendes Netz verndert oder erweitert werden, ist in einem
Soll/Ist-Vergleich das nach M 2.141 Entwicklung eines Netzkonzeptes
erarbeitete Netzkonzept mit der vorhandenen Situation nach M 2.139 Ist-
Aufnahme der aktuellen Netzsituation zu vergleichen. Ausgehend von
Differenzen kann unter Bercksichtigung der o. g. Manahmen ein
Realisierungsplan fr die so genannte Netzmigration erstellt werden. Dabei ist
zu bercksichtigen, dass der Realisierungsaufwand um so grer ist, je mehr
das Netzkonzept vom Ist-Zustand abweicht.
Beispielhafte Migration eines "Shared Ethernet" zu einem "Switched
Fast-Ethernet"
Eine Migration von einer Netztopologie zu einer anderen erfolgt im allge-
meinen stufenweise. Im folgenden ist beispielhaft eine solche Migration von
einem "Shared Ethernet" auf ein Fast-Ethernet mit Switching-Technologie
skizziert. Fr eine Umsetzung in der Praxis mssen allerdings die Rand-
bedingungen genau geprft und entsprechend ein eigenes Migrationskonzept
erstellt werden.
- Migrationsschritt 1
Im ersten Migrationsschritt kann das existierende Backbone durch ein Fast-
Ethernet-Backbone ersetzt oder ggf. neu aufgebaut werden. Der Anschluss
der verbleibenden Shared Ethernet-Segmente erfolgt ber die Netzkompo-
nenten des Backbones, die dementsprechend auch Standard-Ethernet unter-
sttzen mssen.
Aufbau einer strukturierten Verkabelung, d. h. es wird von einem Stan-
dard-Ethernet mit Stichleitung zu einem Verkabelungskonzept bergegan-
gen, bei dem jeder Arbeitsplatz sternfrmig an einen Verteilerraum ange-
bunden wird, ohne die topologische Busstruktur aufzugeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Anbindung der Server erfolgt zentral an einen Switch mit Fast-
Ethernet Anschlssen (Installation einer so genannten Serverfarm).
Anwender, die eine hohe Bandbreite bentigen, werden durch Austausch
der entsprechenden Schnittstellen ebenfalls mit Fast-Ethernet angeschlos-
sen.
Migration der verbleibenden Ethernet-Segmente zu einem vollstndig
geswitchten System. Hierzu knnen beispielsweise Ethernet-Switches an
die Fast-Ethernet-Switches des Backbones angebunden werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.143 Entwicklung eines Netzmanagementkonzeptes

Die in einem lokalen Netz zusammengefassten vielfltigen IT-Systeme, wie
z. B. Serversysteme, Endgerte, Drucker, aktive Netzkomponenten usw.,
sollten auf Netzebene an einer geeigneten Stelle zentral administriert und
berwacht werden knnen. Eine zentrale Administration der Netzkompo-
nenten ist dabei einer dezentralen vorzuziehen, da in diesem Fall Admini-
strationsaufwnde verringert und Anforderungen an die Sicherheit zentral
definiert und kontrolliert werden knnen. In erster Linie wird ein zentrales
Netzmanagement verwendet, um die Verfgbarkeit und Integritt des Netzes
sowie die Integritt und Vertraulichkeit der bermittelten Daten zu gewhr-
leisten. Diese Aufgabe hat eine hohe Komplexitt und sollte durch den Einsatz
eines Netzmanagement-Tools untersttzt werden.
Vor der Beschaffung und dem Betrieb eines solchen Netzmanagement-
Systems ist im ersten Schritt ein Konzept zu erstellen, in dem alle Sicher-
heitsanforderungen an das Netzmanagement formuliert und angemessene
Manahmen fr den Fehler- oder Alarmfall vorgeschlagen werden. Dabei sind
insbesondere die folgenden Bestandteile eines Netzmanagement-Konzeptes
bei der Erstellung zu bercksichtigen und in einem Gesamtzusammenhang
darzustellen.
- Performance-Messungen zur Netzanalyse (siehe M 2.140 Analyse der
aktuellen Netzsituation),
- Reaktionen auf Fehlermeldungen der berwachten Netzkomponenten,
- Fernwartung / Remote-Control, insbesondere der aktiven Netzkompo-
nenten,
- Generierung von Trouble-Tickets und Eskalation bei Netzproblemen
(Hierber kann eine Anbindung an Systemmanagement- und User-Help-
Desksysteme bzw. an externe Nachrichtenbermittler, z. B. Pager, Fax
usw., erfolgen.),
- Protokollierung und Audit (Online und/oder Offline),
- Einbindung eventuell vorhandener proprietrer Systeme bzw. von
Systemen mit unterschiedlichen Managementprotokollen (z. B. im Tele-
kommunikationsbereich),
- Konfigurationsmanagement aller im Einsatz befindlichen IT-Systeme
(siehe u. a. M 4.82 Sichere Konfiguration der aktiven Netzkomponenten),
- Verteilter Zugriff auf die Netzmanagement-Funktionalitten (Fr die
Administration oder fr das Audit kann ein Remote-Zugriff auf die
Netzmanagement-Funktionalitten notwendig sein. Hier ist insbesondere
eine sorgfltige Definition und Vergabe der Zugriffsrechte notwendig.).
Die konkreten Anforderungen an ein Netzmanagement-Tool sind in M 2.145
Anforderungen an ein Netzmanagement-Tool beschrieben. Diese mssen eine
Umsetzung des Netzmanagement-Konzeptes ermglichen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wurden alle Sicherheitsanforderungen an das Netzmanagement formuliert
und dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.144 Geeignete Auswahl eines Netzmanagement-

Protokolls
Als Standardprotokolle fr Netzmanagement gelten derzeit:
- SNMP (Simple Network Management Protocol), SNMP ist in RFC 1157
beschrieben, Request for Comment (RFC) ist die Bezeichnung fr einen in
der Internet-Society etablierten Standard.
- CMIP (Common Management Information Protocol), CMIP ist in der ITU-
T-Norm X.711 bzw. in ISO/IEC 9596-1 beschrieben.
Im folgenden werden die wesentlichen Vor- und Nachteile der beiden Proto-
kolle als Entscheidungshilfe bei der Auswahl eines Netzmanagement-Proto-
kolls aufgezeigt.
SNMP
Fr SNMP sind zwei Komponenten definiert, Manager und Agent. In einem
lokalen Netz werden ein oder eventuell mehrere Manager und je ein Agent pro
IT-System, das mit SNMP berwacht bzw. konfiguriert werden soll,
installiert. Die Agenten sammeln ber diese Systeme Informationen und legen
sie in einer MIB (Management Information Base) ab. Sie tauschen mit dem
Manager ber ein verbindungsloses Protokoll Nachrichten aus, so dass SNMP
an kein bestimmtes Transportprotokoll gebunden ist. Es wird jedoch heute
blicherweise auf UDP/IP implementiert. Andere Implementationen sind
jedoch ebenfalls mglich und vorhanden (z. B. ber OSI, AppleTalk,
SPX/IPX). SNMP gibt es in verschiedenen Versionen. Neben der Urversion
SNMPv1 sind derzeit auch in geringem Umfang verschiedene Ausprgungen
der Version 2 (SNMPv2) im Einsatz (RFC 1901-1908).
SNMP ist ein sehr einfaches Protokoll, das fnf Nachrichtentypen kennt.
Damit tauschen Manager und Agenten die so genannten Managementinfor-
mationen aus, die hier im wesentlichen aus Werten von Statusvariablen
bestehen, die im Managementagenten vorgehalten werden und den jeweiligen
Zustand des zugehrigen verwalteten Objektes beschreiben. Welche
Statusvariablen (Name und Typ) in den einzelnen Agenten existieren, ist in
der Managementdatenbank (MIB) beschrieben. Dabei ist die Information
hierarchisch organisiert, und jedem Wert ist eine eindeutige Identifikations-
nummer zugeordnet, die auf den Variablen damit eine eindeutige Reihenfolge
definiert. Die Nachrichtentypen sind im Einzelnen:
1. GetRequest: wird vom Manager an Agenten geschickt, um von ihnen den
Wert einer oder mehrerer Statusvariablen abzufragen.
2. GetNextRequest: wird vom Manager an Agenten geschickt, um von ihnen
den Wert oder die nchsten Werte gem der Reihenfolge der Variablen in
der MIB abzufragen.
3. SetRequest: wird vom Manager an Agenten geschickt, um dort den Wert
einer Variablen zu setzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. GetResponse: wird vom Agenten zum Manager geschickt, um die ange-

fragten Werte zu senden oder das Setzen eines Variablenwertes zu bestti-
gen.
5. Trap: wird vom Agenten verwendet, um den Manager ber Ausnahme-
ereignisse zu informieren. Das Senden einer Trap-Nachricht erfolgt, im
Gegensatz zur GetResponse-Nachricht, ohne vorherige Anfrage vom
Manager.
Die wesentlichen Vor- und Nachteile sind:
+ SNMP zeichnet sich durch ein einfaches Design und damit auch durch eine
einfache Implementation aus. Dies reduziert die Fehleranflligkeit und
verbessert die Stabilitt des Protokolls.
+ SNMP ist sehr weit verbreitet und gilt als ein De-Facto-Standard. Dadurch
wird es durch fast jedes Produkt im Netz- und Systemtechnikumfeld
untersttzt.
+ Das Protokoll kann sehr einfach an zuknftige Bedrfnisse angepasst
werden. Aus diesem Grund und der oben genannten weiten Verbreitung
von SNMP kann es als sehr zukunftssicheres Protokoll (Investitionsschutz)
bezeichnet werden.
+ Es handelt sich um ein verbindungsloses, einfaches Protokoll auf Trans-
portebene. Damit ist die Performance der bertragung der SNMP-Pakete
im Netz besser als beim verbindungsorientierten CMIP.
- Der Einsatz von SNMP birgt Sicherheitsrisiken, die es u. U. einem Angrei-
fer ermglichen, weitgehende Informationen ber die System- und Netz-
umgebung zu erhalten. Insbesondere existiert, abgesehen von den
Community-Namen (die bei SNMP die Mglichkeit zur Bildung von
Gruppen und einen rudimentren Passwortschutz bieten), kein echter
Passwortschutz beim Zugriff auf die Netzkomponenten.
- Aufgrund der Einfachheit des Protokolls und der verfgbaren Mglich-
keiten weist SNMP Schwchen im Umgang mit sehr groen oder stark
expandierenden Netzen auf.
- Die Performance der Version 1 bei aufwendigeren MIB-Abfragen ist
ungengend, da immer der gesamte MIB-Baum angegeben werden muss.
Einer der groen Nachteile der Version 1 des SNMP liegt in der fehlenden
Untersttzung einer Authentisierung beim Zugriff auf die berwachten
Komponenten. Diese Nachteile gleicht die Version 2 von SNMP zum Teil aus,
zustzlich wurde die Performance bei der Abfrage der MIBs erhht.
Allerdings gibt es auch in SNMPv2 bezglich der untersttzten Sicherheit
unterschiedliche Varianten. Erst die Versionen SNMPv2* und SNMPv2u
bieten die Mglichkeit einer symmetrischen benutzerbasierten Authentisie-
rung, whrend SNMPv2c weiterhin auf Communities aufbaut. Communities
werden in SNMP zum einen genutzt, um die einzelnen Netzkomponenten zu
Bereichen zusammenzufassen, und zum anderen als Passwortersatz beim
Zugriff auf diese. Hinzu kommt in SNMPv2* die Mglichkeit der Datenver-
schlsselung nach dem Data Encryption Standard im Cipher Block Chaining
Modus (DES-CBC). Aufgrund der unterschiedlichen Varianten innerhalb von
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SNMPv2 ist derzeit die Unsicherheit bei den Herstellern von Netzkompo-
nenten und Netzmanagement-Systemen gro, so dass Implementierungen nach
SNMPv2 noch nicht flchendeckend anzutreffen und nur eingeschrnkt
interoperabel sind.
Die unterschiedlichen Ausprgungen von SNMPv2 sollen in der nchsten
SNMP-Version (SNMPv3) konsolidiert werden. Die Verabschiedung von
SNMPv3 ist zurzeit in Arbeit, aber noch nicht abgeschlossen.
Aus den oben genannten Grnden kann im Sinne des IT-Grundschutzes
bislang nur der Einsatz von SNMPv1 empfohlen werden. Werden weiter-
gehende Anforderungen an die Sicherheit des Netzmanagement-Protokolls
bzw. an die Sicherheitsmechanismen des Netzes gestellt, muss entweder
SNMPv2u oder SNMPv2* mit benutzerbasierter Authentisierung oder CMIP
eingesetzt werden. Prinzipiell lsst sich festhalten, dass Vertraulichkeits- bzw.
Authentizittsaspekte bei den neueren Versionen von SNMP strker berck-
sichtigt werden, Bandbreitenverluste dabei jedoch in Kauf zu nehmen sind.
CMIP
CMIP setzt im Gegensatz zu SNMP auf einem implementierten OSI-Proto-
kollstapel (die OSI-Schichten 1 bis 3 sind als Protokollstapel implementiert)
auf und arbeitet damit auch verbindungsorientiert. Hierdurch wird die Ver-
wendung des CMIP auf Komponenten eingeschrnkt, die die notwendigen
Hard- und Softwarevoraussetzungen fr die Implementation eines vollstn-
digen OSI-Stapels bieten. Aufgrund der hohen Anforderungen, die diese
Implementation stellt, wurde auch ein "CMIP Over TCP/IP" (CMOT) defi-
niert (RFC 1189). Hierdurch wird es mglich, CMIP auch in reinen TCP/IP-
Netzen zu betreiben.
Eines der Ziele bei der Entwicklung des CMIP war es, ein objektorientiertes
Management zu entwickeln. CMIP ist dementsprechend konsequent objekt-
orientiert aufgebaut. Im CMIP bernimmt eine CMIP-Maschine (CMIPM) die
Aufgaben, die unter SNMP der Manager durchfhrt. An diese CMIPM, die
wie der SNMP-Manager als Software realisiert ist, werden von den Agenten
der zu verwaltenden Objekte Service-Requests zur Einleitung verschiedener
Aktionen geschickt und umgekehrt versendet die CMIPM CMIP-Nachrichten
an die Agenten der zu verwaltenden Objekte. Die zu verwaltenden Objekte
werden nach den Grundstzen des objektorientierten Ansatzes in mehreren
Bumen verwaltet, die zueinander verschiedene Relationen und Zugriffsarten
aufweisen.
Das CMIP ist aufgrund der beschriebenen Objektstruktur sehr leistungsfhig
und komplex. Das Protokoll selbst besteht dagegen aus relativ wenigen
Operationen, mit denen das gesamte Management auf der Basis der o. g.
Objektstruktur ermglicht wird.
Die wesentlichen Vor- und Nachteile sind:
+ CMIP bietet durch den objektorientierten Ansatz wesentlich mehr Mg-
lichkeiten als SNMP, da z. B. auch Aktionen ausgefhrt und Instanzen von
Management-Objekten verwaltet werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
+ CMIP bietet grere Sicherheit als SNMP, insbesondere durch die Bereit-
stellung von Mechanismen zum Zugriffsschutz, zur Authentisierung der
Benutzer und zum Auditing.
+ CMIP ist ein durch OSI genormtes Protokoll und damit ein offizieller
internationaler Standard, whrend SNMP nur einen De-Facto-Standard auf
RFC-Basis darstellt.
+ Die genannten Schwchen von SNMP werden vermieden.
- CMIP ist ein sehr komplexes Protokoll, dessen gesamte Leistungsfhigkeit
jedoch nur selten bentigt und genutzt werden kann. Eine entsprechende
Konfiguration des Protokolls ist aufgrund der vielen mglichen Einstel-
lungen nur schwer mglich und erfordert ein erhebliches Know-how des
Administrators.
- CMIP bentigt ungefhr zehnmal soviel Systemressourcen wie SNMP.
Deshalb muss eine leistungsfhige Hardware verwendet werden, die nur in
wenigen aktiven Netzkomponenten vorhanden ist. Auerdem ist im allge-
meinen eine Implementation des OSI-Protokollstapels notwendig, der
zustzliche Ressourcen verbraucht. Eine Ausnahme bildet hier CMOT.
- Aufgrund der Komplexitt des Protokolls und der dementsprechenden
Implementationen ist CMIP potentiell fehleranflliger als SNMP-Imple-
mentationen.
- Von CMIP existieren derzeit nur wenig verfgbare Implementationen und
es wird in der Praxis, abgesehen vom Telekommunikationsbereich, kaum
eingesetzt.
Im konkreten Fall muss detailliert geprft werden, welches Netzmanagement-
Protokoll das fr den jeweiligen Verwendungszweck geeignete darstellt. Dazu
mssen die Sicherheitsanforderungen an das Netzmanagement formuliert und
abgestimmt sein. Wird der TCP/IP-Protokollstapel bereits im lokalen Netz
verwendet und sind die Sicherheitsanforderungen gering, bietet sich SNMPv1
als Lsung an. Dennoch knnen hhere Sicherheitsanforderungen auch hier
fr den Einsatz von SNMPv2 oder CMIP sprechen. Beim Einsatz von CMIP
muss dann erwogen werden, auf welchem Protokollstapel CMIP
implementiert werden soll. Entweder auf dem OSI-Stapel (CMIP) oder auf
dem TCP/IP-Stapel (CMOT).
Zu Bedenken ist auch, dass CMIP bzw. CMOT derzeit nicht von allen aktiven
Netzkomponenten und Netzmanagement-Systemen untersttzt wird. Vor dem
Einsatz von CMIP ist also sorgfltig zu untersuchen, ob die eingesetzten
Komponenten und Clients CMIP-fhig sind.
- Wurden die Sicherheitsanforderungen an das Netzmanagement formuliert
und dokumentiert?
- Wurde die Kompatibilitt der aktiven Netzkomponenten und der Clients
bzgl. der ausgewhlten SNMP-Version bzw. zu CMIP berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.145 Anforderungen an ein Netzmanagement-Tool

Um ein effektives Netzmanagement durchfhren zu knnen, ist der Einsatz
eines Netzmanagement-Tools hilfreich. Derzeit stellt der Markt eine Vielzahl
von Produkten fr das Netzmanagement zur Verfgung, die alle hinsichtlich
der eigenen individuellen Anforderungen geprft werden mssen, bevor eine
Entscheidung zur Beschaffung eines konkreten Tools gefllt werden kann.
Dabei gilt es vor allem, die Sicherheitsanforderungen nach M 2.143
Entwicklung eines Netzmanagementkonzeptes zu erfllen und die folgenden
Punkte zu beachten:
- Es muss das ausgewhlte Netzmanagement-Protokoll untersttzen (siehe
M 2.144 Geeignete Auswahl eines Netzmanagement-Protokolls).
- Das Produkt muss skalierbar sein, d. h. es muss an zuknftige Anforderun-
gen angepasst werden knnen.
- Es muss alle im lokalen Netz vorhandenen Netzkomponenten untersttzen.
- Es muss alle im lokalen Netz eingesetzten Netzprotokolle untersttzen.
- Es sollte modular aufgebaut sein, um auch spter weitere Funktionen ohne
groen Aufwand in das bestehende Netzmanagement-System integrieren
zu knnen.
- Es sollte eine grafische Oberflche (Graphical User Interface, GUI)
besitzen, um die relevanten Informationen bersichtlich und verstndlich
darstellen zu knnen.
- Werden auerdem Produkte zum Systemmanagement eingesetzt, sollte im
Sinne eines "single point of administration" eine Integration mit dem
Netzmanagement unter einer Oberflche mglich sein.
Neben diesen allgemein zu prfenden Anforderungen sind zustzlich die
funktionalen Anforderungen an ein Netzmanagementsystem zu definieren. Die
folgenden Kriterien stellen dazu eine bersicht ber die Mglichkeiten in
aktuell verfgbaren Produkten dar, nicht alle Funktionen sind jedoch in allen
Produkten realisiert. Vor einer Produktentscheidung muss deshalb festgelegt
werden, welche Funktionen notwendig sind und welche nicht bentigt werden:
- topologische Darstellung des Netzes (z. B. auch die Mglichkeit der Ein-
bindung von Hintergrundgrafiken wie Bauplne usw.),
- whlbare Darstellungsform der Topologie,
- topographische Darstellung des Netzes (z. B. auch die Mglichkeit der
Einbindung von Hintergrundgrafiken wie Bauplne usw.),
- automatisches Erkennen und Abbilden der Netztopologie und Segmentie-
rung (Auto-Discovery),
- Anzeige der Konfiguration der aktiven Netzkomponenten auf Portebene,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Anzeige der Performance auf Portebene,

- graphische Visualisierung der aktiven Netzkomponenten,
- interaktives Tool fr das Managementprotokoll (z. B. MIB-Browser),
- einfache Navigation im Netzmanagement-Tool, z. B. durch Zoomfunktio-
nen oder durch Ausschnittsvergrerungen,
- eventuell Integration eines VLAN-Managers und graphische Darstellung
der VLANs,
- intuitive Bedienbarkeit der Tool-Oberflche, insbesondere desjenigen
Teils, in dem die topologischen bzw. topographischen Abbildungen editiert
werden (beispielsweise durch "Drag & Drop"),
- Darstellung der Fehler- und Alarmmeldungen durch frei definierbare
Farben und nach selbst zu definierenden Kriterien,
- Mglichkeit eines verteilten Managements (Client/Server und Manager-of-
Manager) und
- Mglichkeit der Integration und Definition weiterer MIBs (Private-MIBs).
- Wurden alle Anforderungen an ein Netzmanagement-Tool formuliert und
dokumentiert?
- Kann mit dem Netzmanagement-Tool das Netzmanagement-Konzept
umgesetzt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.146 Sicherer Betrieb eines

Netzmanagementsystems
Fr den sicheren Betrieb eines Netzmanagement-Tools oder eines komplexen
Netzmanagementsystems, welches beispielsweise aus mehreren verschiedenen
Netzmanagement-Tools zusammengesetzt sein kann, ist die sichere Konfi-
guration aller beteiligten Komponenten zu berprfen und sicherzustellen.
Hierzu gehren die Betriebssysteme, auf denen das oder die Netzmanage-
mentsystem/e betrieben werden, die zumeist notwendigen externen Daten-
banken fr ein Netzmanagementsystem, das verwendete Protokoll (siehe
M 2.144 Geeignete Auswahl eines Netzmanagement-Protokolls) und die
aktiven Netzkomponenten selbst. Vor dem Betrieb eines Netzmanage-
mentsystems muss die Ermittlung der Anforderungen an den Betrieb und die
Erstellung eines Netzmanagement-Konzeptes stehen (siehe M 2.143
Entwicklung eines Netzmanagementkonzeptes).
Insbesondere sind folgende Punkte zu beachten:
- Um ein Mitlesen oder Verndern der Netzmanagement-Informationen zu
verhindern, muss der Rechner, auf dem die Netzmanagement-Konsole
betrieben wird, geeignet geschtzt werden. Dazu zhlen beispielsweise die
Aufstellung in einem besonders geschtzten Raum, der Einsatz von Bild-
schirmsperren, Passwortschutz fr die Netzmanagement-Konsole und
weitere Sicherheitsmechanismen des zugrunde liegenden Betriebssystems.
- Die Manahme M 2.144 Geeignete Auswahl eines Netzmanagement-
Protokolls ist vor dem Hintergrund des sicheren Betriebes zu
bercksichtigen. Insbesondere ist durch eine geeignete Konfiguration der
aktiven Netzkomponenten auf der Basis des verwendeten Protokolls ein
Auslesen der MIBs und anderer Informationen durch unautorisierte
Personen zu verhindern (siehe M 4.80 Sichere Zugriffsmechanismen bei
Fernadministration und M 4.82 Sichere Konfiguration der aktiven
Netzkomponenten).
- Werden Netzmanagement-Funktionen dezentral nach dem Client/Server-
Modell oder durch Benutzung der X-Windows-Technologie durchgefhrt,
muss fr diese ebenfalls der sichere Betrieb gewhrleistet werden.
- Es mssen in regelmigen Abstnden Integrittstests der eingesetzten
Software durchgefhrt werden, um unautorisierte nderungen frhzeitig zu
erkennen.
- Das Netzmanagement-System muss auf sein Verhalten bei einem System-
absturz getestet werden. Insbesondere sollte ein automatischer Neustart
mglich sein, um die Zeitspanne, in der das lokale Netz nicht berwacht
wird, so gering wie mglich zu halten. Die Netzmanagement-Datenbank
darf durch einen Systemabsturz nicht beschdigt werden und muss nach
einem Neustart wieder verfgbar sein, da die darin enthaltenen Konfigura-
tionsdaten wesentlich fr den Betrieb des Netzmanagementsystems sind.
Diese Daten mssen daher besonders gesichert werden, damit sie einerseits
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
noch verfgbar sind und andererseits keine alten oder fehlerhaften

Konfigurationsdaten bei einem Neustart benutzt werden, der ggf. durch
einen Angreifer aus diesem Grunde provoziert wurde. Fr den Schutz der
eingesetzten Datenbank ist u. U. auch der Baustein 9.2 Datenbanken zu
beachten.
- Beim Wiedereinspielen von gesicherten Datenbestnden muss darauf
geachtet werden, dass fr den sicheren Betrieb des Netzmanagement-
Systems relevante Dateien wie Konfigurationsdaten, Passwortdateien und
auch die Metakonfigurationsdateien fr die eigentlichen Netzkomponenten
auf dem aktuellsten Stand sind.
Fr den sicheren Betrieb eines Netzmanagement-Systems sind folgende
Daten relevant:
- Konfigurationsdaten des Netzmanagementsystems, die sich in ent-
sprechend geschtzten Verzeichnissen befinden mssen.
- Konfigurationsdaten der Netzkomponenten (Metakonfigurations-
dateien), die sich ebenfalls in entsprechend geschtzten
Verzeichnissen befinden mssen.
- Passwortdateien fr das Netzmanagementsystem. Hierbei ist
beispielsweise auf die Gte des Passworts und die Mglichkeit einer
verschlsselten Speicherung des Passworts zu achten (siehe M 2.11
Regelung des Passwortgebrauchs).
- Eine Administration der aktiven Netzkomponenten ber das Netz sollte
dann eingeschrnkt werden und eine Administration ber die lokalen
Schnittstellen erfolgen, wenn die Erfllung der Anforderungen an Ver-
traulichkeit und Integritt der Netzmanagement-Informationen nicht
gewhrleistet werden kann. In diesem Fall ist auf ein zentrales Netz-
management zu verzichten.
- Wurde eine Regelung des Passwortgebrauchs fr das Netzmanagement-
systems bzw. -tool erstellt?
- Untersttzt das Netzmanagementsystem die erforderlichen Sicherheits-
manahmen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.147 Sichere Migration von Novell Netware 3.x

Servern in Novell Netware 4.x Netze
Unter Novell Netware 3.x verwaltet jeder Server die Informationen ber seine
Benutzer in der so genannten Bindery. Dies hat den Nachteil, dass in einem
Netz mit mehreren Netware 3.x Servern jeder Benutzer-Account auf jedem
Server, auf den der Benutzer zugreifen will, separat angelegt werden muss.
Fr den Administrator ist dieses mehrfache Anlegen von Benutzern-Accounts
ein enormer zustzlicher Aufwand, der prinzipiell nicht zu verhindern ist.
Darber hinaus muss sich der Benutzer auf jedem Server einzeln anmelden.
In einem Netz mit mehreren Novell Netware 4.x Servern, die in einem NDS-
Baum installiert sind, meldet sich der Benutzer dagegen nur einmal am Netz
an und kann sofort alle ihm zugewiesenen Ressourcen benutzen (siehe
M 2.151 Entwurf eines NDS-Konzeptes).
Eine direkte Integration von Netware 3.x Servern in ein Netware 4.x Netz ist
nicht mglich, da diese weiterhin als eigenstndige Systeme arbeiten.
Benutzer, die sowohl auf Netware 4.x als auch auf Netware 3.x zugreifen
wollen, mssten bei dieser Konstellation weiterhin mehrfach angelegt werden.
Eine sinnvolle Alternative ist dagegen die Migration eines Netware 3.x
Servers in einen NDS-Baum. Dazu kann das von Novell bei Netware 4.x
mitgelieferte Produkt NETSYNC.NLM verwendet werden. Der Betrieb eines
Netware 3.x Servers in einem Netware 4.x Netz hat den Vorteil, dass die
Benutzer-Accounts zentral auf einem Netware 4.x Server administriert werden
knnen und nicht mehr auf jedem Netware 3.x Server einzeln gepflegt werden
mssen.
Hierfr muss ein Netware 4.x Server vorhanden sein, der bis zu 12
Netware 3.x Server verwalten kann. Dieser wird als Host bezeichnet und muss
fr die weitere Administration der Benutzer-Accounts verwendet werden, da
er die nderungen der NDS in die Bindery der Netware 3.x Server bertrgt.
Bei einer Migration wird ein Groteil der NLMs der Netware 3.x Server
ersetzt und diese dann mit einem Host verbunden. Eine eventuell gewnschte
Wiederherstellung eines eigenstndigen Netware 3.x Servers ist somit mit
einem erheblichen Aufwand verbunden.
Folgende Punkte mssen fr eine sichere Migration beachtet werden:
- Der Bindery Kontext muss fr den Behlter, in dem der Netware 3.x Server
erstellt werden soll, gesetzt werden.
- Die Bindery Emulation muss auf dem Netware 4.x Host in der Datei
AUTOEXEC.NCF mit dem Befehl SET BINDERY CONTEXT = ... einge-
tragen und damit aktiviert werden.
- Nach der Migration drfen nderungen nicht mehr mit dem Utility
SYS:PUBLIC\SYSCON.EXE durchgefhrt werden. Andere Utilities, wie
z. B. SYS:PUBLIC\FILER.EXE oder SYS:PUBLIC\PCONSOLE.EXE, wer-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
den im Rahmen der Migration durch NETSYNC.NLM ersetzt. Es wird

jedoch empfohlen, fr Administrationszwecke ausschlielich das
Programm SYS:PUBLIC\NWADMIN.EXE zu benutzen. Das Utility
SYS:PUBLIC\SYSCON.EXE sollte daher entfernt werden.
- Falls mehrere Netware 3.x Server in den gleichen Container migriert
werden sollen oder auch mehrere Bindery Emulations aktiviert sind,
mssen die entsprechenden Objekte zuvor auf Namenskonflikte berprft
werden, da sie nicht mehrfach mit dem selben Namen vorhanden sein
drfen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.148 Sichere Einrichtung von Novell Netware 4.x

Netzen
Verantwortlich fr Initiierung: Leiter IT, Leiter IT
Eine sichere Einrichtung eines Novell Netware 4.x Netzes beinhaltet die
beiden Schritte
- Installation der zugehrigen Software und
- Einrichtung der Netzumgebung.
Installation der zugehrigen Software
Um eine sichere Installation der Novell Netware 4.x Software zu gewhrl-
eisten, muss vor der Installation das Handbuch Installation fr Novell
Netware 4.x durchgearbeitet werden. Folgende Punkte sind unbedingt zu
beachten:
- Anforderungen an die Hardware: vor der Installation ist zu berprfen, ob
die vorgesehene Hardware alle Anforderungen (z. B. Massenspeicher- und
Hauptspeicherbedarf) erfllt,
- vorgezogene Funktionsberprfung aller Hardware-Komponenten unter
MS-DOS, bevor die Hardware in einer komplexen Umgebung wie z. B.
einem Multiprotokollrouter eingesetzt wird,
- Dokumentation der Hardware-Konfiguration (siehe M 2.153
Dokumentation von Novell Netware 4.x Netzen),
- Planung der NDS (siehe M 2.151 Entwurf eines NDS-Konzeptes).
Alle anderen wesentlichen Schritte zur Installation der Novell Netware 4.x
Software knnen den entsprechenden Handbchern Installation und Hand-
buch zu Netware 4 Netzwerken entnommen werden.
Anforderungen an die Verfgbarkeit
Zur Erhhung der Verfgbarkeit von Novell Netware Servern bzw. der
gespeicherten Daten stellt das Netzbetriebssystem hierarchische Fehlertolerie-
rungsstufen zur Verfgung, die nachfolgend kurz aufgezeigt werden. Jede der
hier aufgezeigten Fehlertolerierungsstufen beinhaltet dabei die Funktionali-
tten der vorherigen Stufe.
- Hot Fix I und Hot Fix II
Novell Netware 4.x untersttzt standardmig den sog. Hot Fix. Hierbei
werden Datenverluste aufgrund physikalischer Festplattenfehler verhindert.
Dabei wird zwischen Hot Fix I und II unterschieden. Bei Hot Fix I wird
nach einem Schreibzugriff auf eine Datei ein Vergleich zwischen den
vernderten Daten auf der Festplatte mit den Originaldaten veranlasst, die
sich noch im Arbeitsspeicher des Novell Netware Servers befinden. Ist
dieses Ergebnis fehlerhaft, so wird der entsprechende Sektor der Festplatte
als defekt markiert und fr zuknftige Zugriffe gesperrt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Weiterhin werden die Daten des Arbeitsspeichers im Anschluss an den

zuvor beschriebenen Fehlerfall in den so genannten "Hot Fix Bereich" der
Festplatte umgeleitet.
Seit Netware 4.11 ist diese Funktionalitt allerdings standardmig deak-
tiviert. Der dafr verantwortliche SET-Parameter des Netware Servers
lautet Enable Disk Read After Write Verify und ist bei Netware 4.11 auf
OFF gesetzt. Um die Funktion Hot Fix I zu aktivieren, muss dieser Para-
meter auf ON stehen.
Hot Fix II hingegen funktioniert auch in der Standardeinstellung von
Netware 4.11. Hot Fix II stellt eine hnliche Fehlertoleranz wie Hot Fix I
zur Verfgung, dies jedoch nur bei gespiegelten und geduplexten Platten.
Im Gegensatz zu Hot Fix I knnen hier auch Fehler erst beim Lesen kor-
rigiert werden, da die Information redundant vorhanden ist. Werden beim
Lesen Probleme erkannt, wird der Sektor der Platte als defekt markiert und
ersatzweise auf einen Sektor aus dem Hot Fix Bereich zurckgegriffen. In
diesem Fall werden dann die intakten Informationen der gespiegelten oder
geduplexten Platte gelesen und der defekte Sektor mit der Information der
Ersatzfestplatte fr diesen Bereich automatisch ergnzt.
Da heutige Platten eine sehr hohe Eigenintelligenz besitzen und hnlich
Mechanismen intern zur Verfgung stehen, sind Hot Fix I und II heutzu-
tage von geringerer Bedeutung. Sollten trotz moderner Platten Sektoren im
Hot Fix Bereich belegt sein, ist ein sehr schneller Plattentausch notwendig.
Der Hot Fix Bereich kann beim Erstellen einer Netware Partition konfigu-
riert werden. Novell Netware schlgt eine Gre fr den Hot Fix Bereich
vor, die sich an der Gre der Netware Partition orientiert und bei wach-
senden Partitionen prozentual abnimmt.
- Disk Mirroring
Beim Disk Mirroring sollten an einen Festplattencontroller des Servers
zwei identische Festplatten angeschlossen werden. Es lassen sich allerdings
auch nicht identische Platten spiegeln. Einzige Voraussetzung ist, dass die
Datenbereiche der beiden Netware Partitionen der zu spiegelnden Platten
gleich gro sind. Die zu speichernden Daten werden gleichzeitig auf
beiden Festplatten gespeichert. Fllt eine der Festplatten durch einen Fehler
aus, wird ohne Ausfallzeit und Datenverlust mit der zweiten Festplatte
weitergearbeitet.
- Disk Duplexing
Beim Disk Duplexing werden zwei Festplatten und zwei Festplatten-
controller von gleicher Art bzw. Gre im File Server installiert. Disk
Duplexing gewhrleistet somit eine Fortfhrung des Betriebes nicht nur
beim Ausfall einer Festplatte, sondern auch beim Ausfall eines Fest-
plattencontrollers. Zustzlich sollte beim Disk Duplexing auch das Netzteil
der Festplatten redundant vorhanden sein, was sich meist nur mit externen
Platten-Systemen realisieren lsst.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Serverspiegelung (System Fault Tolerance III)

Eine Serverspiegelung in der sog. SFT-III-Konfiguration stellt die hchste
Stufe der Toleranz gegen im Betrieb auftretende Hardware-Fehler dar.
Zwei identische Novell Netware 4.x Server arbeiten hierbei gleichzeitig
und "parallel" im Netz. Zu beachten ist dabei jedoch, dass der Secondary
Server nur Standby zur Verfgung steht und nur beim Ausfall des Primary
Servers die Arbeit im Netz bernimmt.
Die beiden Novell Netware Server sind hierbei durch ein eigenes Hochge-
schwindigkeitsnetz miteinander verbunden. Fllt hierbei der Primr-Server
aus, werden dessen Aufgaben von dem Sekundr-Server im Netz ber-
nommen.
Die Entscheidung, ob zustzlich zum sog. Hot Fix weitere Manahmen
(Disk Mirroring, Disk Duplexing, SFTIII) ergriffen werden mssen, ist
abhngig vom angestrebten Grad der Verfgbarkeit des Netzes.
- Notstromversorgung
Durch den Einsatz einer Notstromversorgung (USV=Unterbrechungsfreie
Stromversorgung bzw. im englischen UPS=Uninterruptible Power Supply)
knnen die Folgen eines pltzlichen Stromausfalles abgefangen werden.
Novell Netware untersttzt den Einsatz geeigneter Gerte durch das soge-
nannte UPS-Monitoring. Im Falle eines pltzlichen Stromausfalles wird
der Server am Ende der berbrckungszeit der USV geregelt herunter-
gefahren, d. h. die sich im Cache des Servers befindlichen Daten werden
auf die Festplatten bertragen, Verbindungen zum Server ordnungsgem
beendet sowie die Serverprozesse geregelt abgeschlossen.
Einrichtung der Netzumgebung
Novell Netware 4.x bietet ein eigenes Sicherheitssystem zum Schutz des
Netzes und seiner Ressourcen. Die zugehrigen Funktionen mssen jedoch
vom Administrator whrend der Einrichtung eines Netware 4.x Netzes
manuell aktiviert werden, so dass die Sicherheit eines Netzes in nicht unerheb-
lichem Mae in der Verantwortung des Administrators liegt.
Das wesentliche Hilfsmittel zur Verwaltung und Absicherung eines Net-
ware 4.x Netzes ist der Novell Netware Administrator. Dieses Programm gibt
es in folgenden Ausfhrungen:
- SYS:PUBLIC\NWADMIN.EXE fr Windows 3.11,
- SYS:PUBLIC\WIN95\ NWADMN95.EXE fr Windows 95,
- SYS:PUBLIC\WINNT\NWADMNNT.EXE fr Windows NT sowie die
neuere Version
- SYS:PUBLIC\WIN32\NWADMN32.EXE fr Windows NT und
Windows 95.
Das Programm Netware Administrator ermglicht eine Vielzahl von Einstel-
lungen, wie z. B. die Festlegung einer minimalen Passwortlnge oder der
maximalen Anzahl gleichzeitiger Verbindungen eines Benutzers. Nachfolgend
werden die sicherheitsrelevanten Funktionen des Netware Administrators auf-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
gefhrt und erlutert. Dazu sind die jeweiligen Parameter und ihre Werte
angegeben, die fr einen sicheren Betrieb eines Netware 4.x Netzes eingestellt
werden mssen.
Ein wesentlicher Punkt bei der sicheren Einrichtung von Netware 4.x Netzen
ist das Anlegen von Benutzer-Accounts. Zu diesem Zweck sollten Schablonen
(Templates) fr Standard-Benutzer des jeweiligen Kontextes angelegt werden.
Beim Einrichten konkreter Benutzer-Accounts werden dann die in der
Schablone eingestellten Werte bernommen, was den entsprechenden
Aufwand stark reduziert. Dazu muss die Option SCHABLONE BENUTZEN
bzw. USE TEMPLATE verwendet werden. Folgende Funktionen sollten in
einer Schablone eingestellt werden:
Login Restrictions
Abbildung: Netware Administrator Men "Template: Benutzer-

schablone/Login Restrictions"
- Limit Concurrent Connections
Hierdurch kann die Anzahl der gleichzeitigen Verbindungen eines
Benutzer-Accounts zu den Netware Servern limitiert werden. Im Regelfall
sollte hierbei der Wert "1" gewhlt werden, um nicht unntig Verbin-
dungslizenzen zu verbrauchen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Password Restrictions

schablone/Password Restrictions"
- Allow user to change password
Diese Option muss aktiviert werden, damit ein Benutzer sein Passwort
wechseln kann. Ist sie nicht aktiviert, knnen keine weiteren Mglichkeiten
angewhlt werden.
- Require Password
Diese Option installiert die Passwortabfrage fr jeden Benutzer und bietet
die Mglichkeit, die nachfolgenden Passwortregeln zu definieren. Require
Password sollte immer aktiviert werden.
- Minimum Password Length
Hiermit wird die erforderliche Mindestlnge eines Passwortes eingestellt.
Sie sollte mindestens sechs Zeichen betragen (vergleiche M 2.11 Regelung
des Passwortgebrauchs M 2.11 Regelung des Passwortgebrauchs).
- Force Periodic Password Changes
Durch die Aktivierung dieser Option wird festgelegt, dass die Benutzer
ihre Passwrter regelmig ndern mssen. Dies sollte der Regelfall sein.
- Days Between Password Changes
Unter diesem Menpunkt wird die allgemeine Gltigkeitsdauer von
Passwrtern festgelegt. Diese muss fr das jeweilige System individuell
festgelegt werden (vergleiche M 2.11 Regelung des Passwortgebrauchs).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Require Unique Passwords

Die Aktivierung der Passworthistorie (Require Unique Passwords) hat zur
Folge, dass die letzten neun Passwrter eines Benutzer-Accounts mit dem
neu eingegebenen Passwort verglichen werden und bei einer festgestellten
bereinstimmung das neue Passwort durch den Netware Server zurck-
gewiesen wird. Damit wird gewhrleistet, dass nicht immer dieselben
Passwrter verwendet werden knnen. Diese Option sollte immer aktiviert
werden.
- Limit Grace Logins
Grace Logins sind diejenigen Logins, die trotz Ablauf der Gltigkeitsdauer
eines Passwortes noch erfolgen drfen. Die Anzahl der Grace Logins sollte
durch die Aktivierung dieser Option grundstzlich limitiert werden.
- Grace Logins Allowed
Die Anzahl der erlaubten Grace Logins sollte auf den Wert "Eins" einge-
stellt werden, damit ein Benutzer, dessen Passwort ungltig geworden ist,
dieses sofort ndern muss.
- Set password after create
Diese Option sollte immer aktiviert sein. Durch sie wird der Administrator
bei der Erstellung eines neuen Benutzers-Accounts automatisch aufgefor-
dert, ein Passwort einzugeben. Dies verhindert somit, dass temporr frei
zugngliche Benutzer-Accounts angelegt werden knnen.
Login Time Restrictions

schablone/Login Time Restrictions"
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Default Time Restrictions

Mit Hilfe der Schablone Login Time Restrictions werden die erlaubten
Arbeitszeiten fr Benutzer-Accounts in einem Netware 4.x Netz definiert.
Auerhalb der hier festgelegten Zeiten ist es keinem Benutzer mglich,
sich am Netware 4.x Netz anzumelden.
Nachtrgliche nderungen der Default Time Restrictions bei der Einrich-
tung bzw. Pflege von Benutzer-Accounts haben keinerlei Auswirkungen
auf die erlaubten Zugangszeiten bereits existierender Benutzer. Abwei-
chende Zugangszeiten fr einzelne Benutzer knnen mit Hilfe von
SYS:\PUBLIC\NWADMIN.EXE (Objects / Details on multiple Users)
gendert werden.
Weiterhin knnen fr einzelne Behlterobjekte der NDS die folgenden
Sicherheitsmechanismen eingestellt werden:
Intruder Detection
Abbildung: Netware Administrator Men "Organizational Unit : Lab/Intruder

Detection"
- Detect Intruders
Durch die Aktivierung dieser Option werden unautorisierte Login-Versu-
che erkannt und die hiervon betroffenen Benutzer-Accounts gegebenenfalls
gesperrt. Dadurch wird einer "Brute Force Attacke" unter Novell
Netware 4.x vorgebeugt. Diese Einstellung muss mit dem Programm
Netware Administrator fr jeden Container durchgefhrt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Incorrect Login Attempts

Dies gibt die maximale Anzahl der zulssigen Login-Fehlversuche an;
blicherweise sollte hierbei der Wert "Drei" eingestellt werden.
- Intruder Attempt Reset Interval
Damit kann die zeitliche Zurckverfolgung von fehlgeschlagenen Login-
Versuchen eines Benutzer-Accounts aktiviert werden. bersteigt die
Anzahl der Login-Fehlversuche eines Benutzer-Accounts innerhalb des
definierten Zeitraumes den unter Incorrect Login Attempts eingestellten
Wert, so wird der Benutzer-Account gesperrt (falls die Option Lock
Account After Detection aktiviert ist).
- Lock Account After Detection
Dieser Menpunkt sollte immer aktiviert werden, um einen Benutzer-
Account, der die maximale Anzahl der ungltigen Login-Versuche ber-
schritten hat, zu sperren.
- Intruder Lockout Reset Interval
Dieser Zeitwert sollte keinesfalls zu gering gewhlt werden (> 1 Stunde),
um sicherzustellen, dass die Ursache fr einen Intruder Lockout (d. h.
Sperren des Benutzer-Accounts) durch die Systemadministration und den
betroffenen Benutzer aufgeklrt werden kann.
- Sind die Benutzer ber den korrekten Umgang mit Passwrtern unterrichtet
worden?
- Wird die Passwort-Gte kontrolliert?
- Wird der Passwort-Wechsel erzwungen?
- Ist jeder Benutzer im Netz mit einem Passwort ausgestattet?
- Wurde eine Benutzerschablone erzeugt? Wurde dabei auf die Sicherheits-
aspekte geachtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.149 Sicherer Betrieb von Novell Netware 4.x Netzen

Fr den sicheren Betrieb eines Novell Netware 4.x Netzes mssen die
nachfolgend beschriebenen Punkte umgesetzt werden.
Vergabe von Zugriffsrechten auf Verzeichnisse, Dateien, NDS-Objekte
und NDS-Objekteigenschaften
Durch die Vergabe von Zugriffsrechten (Trustee Assignments) auf NDS-
Objekte, NDS-Objekteigenschaften, Verzeichnisse und Dateien im Novell
Netware 4.x Netz kann die Sicherheit eines Novell Netware 4.x Netzes und
seiner Daten gewhrleistet werden. Wenn NDS-Objekten, z. B. Benutzern und
Gruppen, verschiedene Rechte auf andere NDS-Objekte, NDS-
Objekteigenschaften, Dateien oder Verzeichnisse gewhrt werden, so spricht
man von einem Trustee (Treuhnder oder Bevollmchtigten).
In Netware 4.11 existieren dazu drei Arten von Zugriffsrechten, die ersten
beiden beziehen sich auf die NDS-Objekt- und NDS-
Objekteigenschaftsrechte, das letzte auf Dateien bzw. Verzeichnisse.
- Objektrechte
Abbildung 1: Netware Administrator Container zenk_gmbh "Trustee of this

Object..."
Objektrechte steuern die Zugriffsmglichkeiten eines Trustees auf ein
Objekt, also z. B. auf Benutzer, Gruppen, Drucker oder Netware Server.
Folgende Objektrechte, wie dies auch in der obigen Abbildung zu
entnehmen ist, stehen zur Verfgung:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Supervisor
- Browse
- Create (nur bei Containern)
- Delete
- Rename
Ein Benutzer mit diesen Rechten auf ein anderes NDS-Objekt, z. B. einen
anderen Benutzer, kann der Reihe nach Benutzer-Accounts sehen,
erstellen, lschen bzw. umbenennen. Das Supervisor-Recht ist die Summe
der vier anderen Rechte. Mit den Rechten Browse, Create, Delete und
Rename erhlt man keinerlei Objekteigenschaftsrechte bzw. Dateirechte.
Ausnahme hiervon ist in diesem speziellen Fall das Supervisor-Recht auf
ein Objekt. Mit diesem Recht erhlt man auch Supervisor-Rechte auf die
Objekteigenschaften.
- Objekteigenschaftsrechte
Objekteigenschaftsrechte steuern den Zugriff eines Trustees auf die ber
ein Objekt gespeicherten Informationen, also auf die Eigenschaften des
betreffenden Objekts. Hierzu sind keinerlei Objektrechte notwendig. Mit
Ausnahme des Objektrechts Supervisor kann man mit Objektrechten auch
keinerlei Rechte auf Objekteigenschaften erlangen. Es gibt folgende
Objekteigenschaftsrechte, die wieder in obiger Abbildung erkennbar sind:
- Supervisor
- Compare
- Read
- Write
- Add Self
Die Objekteigenschaftsrechte setzen sich aus den Hauptrechten Schreiben
(Write) und Lesen (Read) zusammen. Im Recht Lesen ist das Recht
Vergleichen (Compare) und im Recht Schreiben ist das Recht Selbst
Hinzufgen (Add Self) enthalten. Das Supervisor-Recht ist hier die Summe
dieser vier Rechte und hat keinerlei weitere Auswirkungen. Mit dem Recht
Lesen knnen Objekteigenschaften wie z. B. die Eigenschaften des
Benutzers Nachname oder auch Login Script gelesen werden. Zum
Abndern bentigt man das Recht Schreiben. Das Recht Vergleichen
erlaubt es, Anfragen an die NDS abzusetzen, z. B. ob der Nachname des
Benutzers XY gleich Mustermann ist. Die Antwort lautet dann je nach dem
"wahr" oder "falsch". Das Recht Selbst Hinzufgen macht nur bei Objekten
Sinn, bei denen man sich selbst in eine Liste eintragen kann, wie dies z. B.
bei einer Gruppe der Fall ist. Da ein Objekt hufig sehr viele Eigenschaften
besitzt, gibt es zwei Mglichkeiten, Objekteigenschaften zu vergeben. Es
ist prinzipiell mglich, auf alle Eigenschaften dasselbe Recht zu vergeben.
Dann muss im Bereich Property Rights der Punkt All Properties markiert
sein. Andererseits ist es auch mglich, auf bestimmte Objekteigenschaften
explizit Rechte zu vergeben. Dazu dient die Option Selected Properties. Es
ist dabei zu beachten, dass mit der Funktion Selected Properties die
Rechte, die bei der Option All Properties vergeben wurden, berschrieben
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Rechte in der NDS mssen noch sorgfltiger vergeben werden als Rechte
im Dateisystem. Im Dateisystem bekommt ein NDS-Objekt Rechte auf
eine Datei oder ein Verzeichnis. In der NDS allerdings bekommt ein NDS-
Objekt Rechte auf ein anderes NDS-Objekt. Hierbei muss genau berprft
werden, wer eigentlich auf wen Rechte bekommen soll. So kann es leicht
vorkommen, dass ein Benutzer-Objekt Rechte auf ein Container-Objekt
bekommen soll, doch letztendlich dem Container-Objekt Rechte auf ein
Benutzer-Objekt gegeben werden.
- Datei- und Verzeichnisrechte
Abbildung 2: Netware Administrator Verzeichnis PUBLIC "Details:

Trustee of this Directory"
Datei- und Verzeichnisrechte steuern die Operationen, die ein Trustee, hier
der User RZenk, in einer Datei oder in einem Verzeichnis durchfhren
kann. Wie Objektrechte unabhngig von Objekteigenschaftsrechten sind,
sind wiederum Datei- und Verzeichnisrechte vollkommen unabhngig von
den beiden NDS-Rechten. Es gibt folgende Datei- und Verzeichnisrechte:
- Supervisor
- Read
- Write
- Create
- Erase
- Modify
- File Scan
- Access Control
Mit den Rechten Read, Write, Create und Erase kann ein Trustee Dateien
bzw. Verzeichnisse lesen, verndern, erstellen und lschen. Modify dient nicht
zum Verndern einer Datei, sondern zum Umbenennen von Dateien und
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verzeichnissen. Weiterhin knnen mit dem Recht Modify die Datei- und
Verzeichnisattribute gendert werden. Mit File Scan hat man das Recht, sich
Dateien und Verzeichnisse z. B. mit dem Befehl NDIR oder auch DIR
anzusehen. Mit dem Recht Access Control knnen anderen NDS-Objekten
Datei- und Verzeichnisrechte, mit Ausnahme des Supervisor-Rechts gewhrt
werden.
Im Gegensatz zu Objektrechten, wo es das Recht Create nur auf
Containerebene gibt, kann das Create Recht im Dateisystem auch auf Dateien
und nicht nur auf Verzeichnisse vergeben werden. Auf Dateien erlaubt dieses
Recht, eine logisch gelschte Datei durch den Mechanismus Salvage wieder
herzustellen. In der NDS knnen einmal gelschte Objekte nicht wieder
hergestellt werden, was dazu fhrt, dass dort das Recht Create nur auf
Containerebene Sinn macht.
Aus Grnden der bersichtlichkeit, einer vereinfachten Administration sowie
einer verbesserten Revisionsfhigkeit sollte die Vergabe von Zugriffsrechten
vorrangig ber die Zuweisung von Rechten an Benutzergruppen (Datei- und
Verzeichnisrechte) und Container-Objekte erfolgen. Ein Container ist dabei
stellvertretend fr alle Objekte, insbesondere alle Benutzer-Objekte, die sich
unterhalb des Container-Objekts in der NDS befinden. Dabei erhalten diese
Rechte wirklich alle Benutzer, nicht nur diejenigen, die sich im Container
direkt befinden.
Fr NDS-Rechte auf Objekte und Objekteigenschaften gibt es das Objekt
Organizational Role (OR). Die OR ist vergleichbar mit einer Gruppe. Gruppen
geben das erhaltene Datei- und Verzeichnisrecht an alle ihre Benutzer, die als
Mitglieder eingetragen sind, weiter. Mit einer Organizational Role werden die
Rechte an die Mitglieder der Organizational Role weitergereicht. Hier heien
die Mitglieder allerdings Occupant, was soviel wie Bewohner heit. Novell
bersetzt dies allerdings als Trger. Sowohl bei Gruppen als auch bei
Organizational Roles werden die Rechte auf ihre Mitglieder bzw. Trger mit
Hilfe von Security Equal To Mechanismen bergeben. Da in der Praxis weit
weniger NDS-Rechte als Dateirechte vergeben werden, wird die OR weit
weniger hufig benutzt als dies bei Gruppen der Fall ist.
Rechte knnen auch direkt an Benutzer und ber Security Equal To vergeben
werden. Hier kann aber sehr leicht die bersichtlichkeit verloren gehen und
deshalb sollten diese Mechanismen sehr moderat eingesetzt werden.
Zusammenfassend noch einmal die Mglichkeiten, wie Rechte vergeben
werden knnen:
- Gruppen (Datei- und Verzeichnisrechte)
- Organizational Role (NDS-Objekt- und NDS-Objekteigenschaftsrechte)
- Container
- Benutzer
- Security Equal To
Um die versehentliche Freigabe von Verzeichnissen durch einen Benutzer zu
verhindern, sollte die Systemadministration Benutzergruppen und Benutzern
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
in den ihnen zugewiesenen Verzeichnissen und Dateien die Rechte

"Supervisor" (S) und "Access Control" (A) nicht erteilen.
Werden ausgewhlten Verzeichnissen oder Dateien mit Hilfe von Netware-
Attributen bestimmte Eigenschaften, z. B. schreibgeschtzte Dateien (Ro),
zugewiesen, so sollte beachtet werden, dass Benutzer, die das Zugriffsrecht
"Modify" (M) auf die entsprechenden Verzeichnisse und Dateien besitzen, in
der Lage sind, diese Attribute zu verndern. Daher sollte der Kreis der
Benutzer mit diesem Zugriffsrecht eingeschrnkt werden.
Vererbung von Zugriffsrechten in der NDS und im Dateisystem
Alle bereits behandelten Rechte unterliegen hnlichen Mechanismen. Hierzu
gehren wichtige Begriffe wie Vererbung von Rechten, Vererbungsfilter
(IRF), Effektive Rechte (ER) und Access Control List (ACL), die im folgenden
erlutert werden.
Vererbung von Rechten
Rechte werden sowohl in der NDS als auch im Dateisystem grundstzlich
vererbt. Dies bedeutet z. B., dass ein Recht, das in der Root, entweder im
NDS-Baum oder auch im Dateisystem vergeben wird, sich auf alle Objekte
bzw. Verzeichnisse und Dateien, die sich unterhalb der jeweiligen Root
befinden, vererbt werden. Vergibt man ein Recht entsprechend tiefer in der
Baumstruktur, vererben sich die Rechte ab dieser Stelle im Baum. Hiervon
gibt es eine Ausnahme: Rechte, die selektiv auf Objekteigenschaften vergeben
werden (Selected Properies), vererben sich nicht.
Beispiel 1:
SYS: RZenk [Read; File Scan]
PUBLIC
NWADMIN.EXE
NDIR.EXE
Erhlt der User RZenk auf das Volume SYS: die Rechte [Read; File Scan],
vererben sich diese Rechte hier auch auf das Verzeichnis PUBLIC und die
Dateien NWADMIN.EXE und NDIR.EXE, die sich in PUBLIC befinden.
Vererbung kann aber auch gezielt ausgeschlossen werden. Dazu gibt es die
Inherited Rights Filter (IRF), die weiter unten besprochen werden. Im
Grundzustand werden keinerlei Rechte gefiltert. Es gibt noch einen zweiten
Mechanismus, bei dem die Vererbung ausgeschlossen wird. Erhlt das gleiche
NDS-Objekt tiefer im Baum noch einmal Rechte zugewiesen, werden dadurch
die ursprnglichen Rechte, die dasselbe Objekt weiter oben im Baum
bekommen hat, ab diesem Punkt nicht mehr weitervererbt.
Beispiel 2:
SYS: RZenk [Read; File Scan]
PUBLIC
NWADMIN.EXE RZenk [Write]
NDIR.EXE
In Beispiel 2 hat der User RZenk auf die Datei NWADMIN.EXE nur noch das
Recht [Write], da die Rechte [Read; File Scan] des Benutzers RZenk auf die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Datei NWADMIN.EXE nicht weitervererbt werden. Alle anderen NDS-

Objekte, die eventuell Rechte auf die Datei NWADMIN.EXE bekommen
haben, sind dadurch nicht betroffen. Auch die Rechte, die der User RZenk auf
die Datei NWADMIN.EXE ber andere Mechanismen erhlt, wie z. B.
Gruppen, Container, etc., werden dadurch nicht eingeschrnkt. Diese Rechte
sind somit additiv.
Inherited Rights Filter (IRF)
Whrend Trustee Assignments den Zugriff auf ein Objekt, eine
Objekteigenschaft oder eine Datei bzw. ein Verzeichnis gewhren, verhindert
ein IRF die Vererbung der Rechte von einem Objekt, einer Objekteigenschaft
oder einer Datei bzw. einem Verzeichnis auf andere NDS-Objekte bzw.
Dateien und Verzeichnisse im jeweiligen Baum. Jedes Objekt, jede
Objekteigenschaft und jede Datei bzw. jedes Verzeichnis in einem NDS
Verzeichnis bzw. im Dateisystem kann einen anderen IRF besitzen.
Der einzige Unterschied zwischen NDS und Dateisystem betrifft das Recht
Supervisor. Nur in der NDS kann dieses Recht gefiltert werden. Im
Dateisystem hingegen kann dieses Recht, einmal vergeben, nicht mehr
gefiltert werden.
Effektive Rechte
Die Kombination Inherited Rights Filter, Trustee Assignment und Security
Equivalences werden als Effektive Rechte (ER) bezeichnet. Die effektiven
Rechte, die ein NDS-Objekt auf andere NDS-Objekte bzw. deren
Eigenschaften hat, aber auch die effektiven Rechte die ein NDS-Objekt auf
das Dateisystem hat, knnen mit dem Programm Netware Administrator
bestimmt werden (vgl. auch vorherige Abbildungen).
Access Control List (ACL)
Die Informationen darber, wer auf ein Objekt und die Properties zugreifen
kann und mit welchen Rechten, wird im Objekt selbst gespeichert. Hierfr
existiert fr jedes Objekt eine spezielle Property: Access Control List (ACL).
Die ACL Property enthlt die Trustee Assignments und die Inherited Rights
Filter. Jedes eingetragene Objekt in der ACL kann dabei andere Trustee
Assignments aufweisen. Im Dateisystem ist die ACL und die IRF in der
Directory Entry Table (DET) gespeichert.
Vergabe von Netware-Attributen auf Verzeichnisse und Dateien
Neben der Benutzer- bzw. gruppenbezogenen Erteilung von Zugriffsrechten
auf Verzeichnisse und Dateien kann durch die Vergabe von Netware-
Attributen auf Verzeichnisse und Dateien die Datensicherheit erhht werden.
Attribute sind immer verzeichnis- bzw. dateibezogen, da NDS-Objekte keine
Attribute haben, d. h. sie sind unabhngig von den zugewiesenen
Zugriffsrechten und gelten fr alle Benutzer einschlielich fr Benutzer mit
Supervisor-Rechten.
Benutzer, denen das Zugriffsrecht "Modify" (M) auf die in Frage kommenden
Verzeichnisse und Dateien eingerumt wurde, knnen die vergebenen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Netware-Attribute ndern und somit jede Aktion, die sich aus ihren effektiven
Rechten ergibt, ausfhren.
Sicherheit durch den Einsatz von Netware-Attributen stellt sich somit als ein
Subsystem auf der Ebene der Verzeichnis- und Dateisicherheit dar. Das
bedeutet, dass obwohl jemand das ER hat eine Datei zu lschen, dies unter
Umstnden nicht tun kann, da das Attribut "Delete inhibit" (Di) gesetzt ist.
Bei der Vergabe von Netware-Attributen auf Verzeichnisse und Dateien
sollten die folgenden Eigenschaften von Netware-Attributen beachtet werden.
- Verzeichnis-Attribute:
Abbildung 3: Netzwerk Attribute im Public Directory

Delete Inhibit (Di): Das Verzeichnis kann nicht gelscht werden.
Hidden (H): Das Verzeichnis wird als versteckt gekennzeichnet; es
erscheint weder in einem Inhaltsverzeichnis unter DOS, noch kann es
gelscht oder kopiert werden.
Purge (P): Das Verzeichnis sowie die in ihm befindlichen Dateien werden
beim Lschen sofort, auch physikalisch, gelscht. Eine Wiederherstellung
des Verzeichnisses ist nicht mglich.
Rename Inhibit (Ri): Das Verzeichnis kann nicht umbenannt werden.
System (Sy): Das Verzeichnis wird vom System benutzt; es erscheint
ebenfalls nicht in einem Inhaltsverzeichnis unter DOS und kann weder
kopiert noch gelscht werden.
Don`t Migrate (Dm): Die in dem Verzeichnis enthaltenen Dateien drfen
nicht auf einen sekundren Datentrger (z. B. ein Bandlaufwerk)
ausgelagert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Immediate Compress (Ic): Die in das Verzeichnis hineinkopierten

Dateien werden umgehend komprimiert. Dateien, die sich schon im
Verzeichnis befinden, werden durch dieses Attribute nicht beeinflusst.
Don`t Compress (Dc): Die in dem Verzeichnis enthaltenen Dateien drfen
nicht komprimiert werden.
- Datei-Attribute:
Abbildung 4: Datei Attribute: FILE: KKDL/SYS:\PUBLIC\NDIR.EXE

Archive needed (A): Die so durch Novell Netware gekennzeichneten
Dateien sind seit der letzten Datensicherung inhaltlich verndert oder neu
auf dem Novell Netware Server aufgespielt worden. Datensicherungs-
software kann somit bei einer sequentiellen Datensicherung erkennen, dass
die Datei erneut gesichert werden muss.
Execute Only (X): Ausfhrbare Programmdateien (*.exe, *.com), die mit
diesem Attribut versehen werden, knnen ausschlielich ausgefhrt oder
gelscht werden. Ein Kopieren der Datei ist nicht mglich. Zu beachten ist
auch, dass Dateien mit diesem Attribut nicht gesichert werden (z. B. bei
einem Full-Backup)
Read write (Rw): Auf die Datei ist sowohl Lese- als auch Schreibzugriff
mglich.
Read only (Ro): Die Datei kann nur gelesen werden. Ein Schreibzugriff ist
nicht mglich. Um Datenverluste bei einer gemeinsamen Benutzung zu
vermeiden, sollten diese Dateien ebenfalls das Attribut "Shareable" (S)
besitzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ausfhrbare Programmdateien (*.exe, *.com) sollten mit dem Attribut

"Read only" versehen werden, um einem mglichen Befall durch
Computer-Viren vorzubeugen.
Shareable (Sh): Diese Dateien knnen von mehreren Benutzern
gleichzeitig benutzt werden. Dateien, die mit dem Attribut "Shareable"
versehen worden sind, sollten gleichzeitig das Attribut "Read Only" (Ro)
besitzen. Das Attribut "Shareable" ist nur relevant fr Programme, die
Dateien nicht netzfhig ffnen.
Hidden (H): Die Datei wird als versteckt gekennzeichnet. Sie erscheint
nicht in einem Inhaltsverzeichnis unter DOS und kann weder kopiert noch
gelscht werden.
System (Sy): Die Datei wird vom Netzbetriebssystem verwendet; sie
erscheint ebenfalls nicht in einem Inhaltsverzeichnis unter DOS und kann
weder kopiert noch gelscht werden.
Transactional (T): Dateien mit diesem Attribut unterliegen der
Transaktionskontrolle von Novell Netware. Als Transaktion wird hier eine
zusammenhngende Folge von Vernderungen in einer oder mehreren
Dateien verstanden. Das Setzen dieses Attributes bewirkt, dass nur
vollstndig durchgefhrte Transaktionen in den Datenbestand der Datei
bernommen werden. Transaktionen, die unvollstndig abgebrochen
wurden, werden von Novell Netware rckgngig gemacht.
Purge (P): Dateien mit dem Attribut "Purge" werden beim Lschen nicht
nur logisch, sondern sofort physikalisch gelscht. Dies hat zur Folge, dass
die Datei nicht wiederhergestellt werden kann. In diesem Zusammenhang
wird darauf hingewiesen, dass die physikalische Lschung von Dateien
nicht nur durch das Netware-Attribut "Purge" erfolgen kann, sondern
ebenso von einer Arbeitsstation mit dem Befehl "PURGE Dateiname"
durchgefhrt werden kann.
Copy Inhibit (Ci): Derartige Dateien knnen nicht kopiert werden. Dieses
Netware-Attribut gilt allerdings nur fr APPLE Macintosh Workstations.
Delete Inhibit (Di): Die Datei kann nicht gelscht werden.
Rename Inhibit (Ri): Die Datei kann nicht umbenannt werden.
Dont Migrate (Dm): Eine Datei, die mit diesem Attribut versehen ist,
kann nicht auf einen sekundren Datentrger (z. B. ein Bandlaufwerk)
ausgelagert werden.
Immediate Compress (Ic): Die Datei wird vom Betriebssystem
schnellstmglichst komprimiert und in dieser Form auf dem Volume
gespeichert.
Dont Compress (Dc): Die Datei wird vom Betriebssystem nicht
komprimiert, auch wenn fr das Volume die Kompression eingeschaltet ist.
Dont Suballocate (Ds): Bei der Speicherung dieser Dateien wird keine
Teilblockzuordnung (Suballocation) vorgenommen, obwohl dieses
Merkmal fr das System aktiviert wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
File Compressed (Co), Cant Compress (Cc), File Migrated (M): Mit
diesen Attributen werden vom Betriebssystem dementsprechende
Informationen ber eine Datei gespeichert. Diese Attribute knnen nur
vom Betriebssystem gendert werden.
Sorgfltige Vergabe von Rechten
Dateirechte, NDS-Objektrechte und NDS-Objekteigenschaftsrechte sind
vollkommen unabhngige Rechte. Hiervon gibt es zwei Ausnahmen. Erhlt
jemand Supervisor-Rechte auf ein NDS-Objekt, hat er automatisch auch
Supervisor-Rechte auf die NDS-Objekteigenschaften. Umgekehrt tritt dieses
Phnomen nicht auf. Supervisor-Rechte auf NDS-Objekteigenschaften sind
nicht gleichbedeutend mit Supervisor-Rechten auf das NDS-Objekt selbst.
Hierbei muss allerdings beachtet werden, dass die Objekteigenschaft Object
Trustees (ACL) eine Eigenschaft eines jeden NDS-Objekts ist. Erhlt man nun
Supervisor-Rechte auf die Eigenschaften eines NDS-Objekts oder nur das
Recht WRITE auf die Eigenschaft Object Trustees (ACL), ist man in der Lage,
sich selbst oder anderen NDS-Objekten beliebige Rechte zu gewhren. Eine
weitere wichtige Ausnahme ist das NDS-Objekt Server. Erhlt z. B. der
Benutzer RZenk, wie im obigen Beispiel, das Recht WRITE auf die
Objekteigenschaft Object Trustees (ACL) des Servers, ist dies gleichbedeutend
mit Supervisor-Rechten auf das komplette Dateisystem, das diesem Server
zugeordnet ist. Die Eigenschaft Object Trustees (ACL) des Servers ist somit
die Schnittstelle zwischen der NDS und dem Dateisystem.
Abbildung 5: Netware Administrator Server NW4_GT "Trustee of this

Object..."
Um zu verhindern, dass durch unsachgemes Vergeben von NDS-Rechten
Supervisor-Rechte im Dateisystem erlangt werden knnen, knnten Inherited
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Rights Filter (IRF) an jedem Server-Objekt aktiviert werden. Damit knnen

die Objektrechte von den Verzeichnisrechten getrennt werden. Dabei muss das
Supervisor-Recht sowohl auf NDS-Objekt- als auch auf NDS-
Objekteigenschafts-Ebene und das Recht WRITE der Eigenschaft Object
Trustees (ACL) gefiltert werden. Besser ist es natrlich, wenn man sich
bewusst ist, wie sich bestimmte Rechte im Detail auswirken.
Eingeschrnkte Nutzung von Accounts mit Supervisor-Berechtigung auf
Dateiebene
Der Account des Benutzers "Admin" sollte bei der tglichen
Administrationsarbeit nicht verwendet, sondern nur in Notfllen benutzt
werden. Um dennoch die Systemadministration zu gewhrleisten, sollte daher
fr jeden Benutzer mit der Netware Sicherheitsstufe "Supervisor" ein
Benutzer-Account eingerichtet werden, der ber dieselben Rechte wie das
Benutzer-Objekt "Admin" verfgt (ausdrckliche Trustee Zuweisung, siehe
auch Schutz vor Verlust der Administrierbarkeit), mit dem die System-
administration normalerweise erfolgt. Werden die Administrationsarbeiten
nicht hauptamtlich wahrgenommen, so sollten fr die nicht-administrativen
Aufgaben zustzlich aufgabenbezogene Accounts eingerichtet werden.
Der Account des Administrators bzw. seines Vertreters sollte weiterhin nur
auf hierzu definierten Workstations verwendet werden, da die Integritt
anderer Workstations manipuliert sein knnte.
Der Account "Admin", der standardmig die alleinigen administrativen
Rechte besitzt, sollte als potentielles Angriffsziel keine Rechte mehr besitzen.
Die notwendigen Supervisor-Rechte sollten einem anderen, weniger
aufflligen Benutzer-Account bertragen werden. Man kann aber auch ganz
einfach den Admin-Account umbenennen, um hierfr einen Namen zu
verwenden, der den allgemeinen Regeln zur Namensvergabe innerhalb der
NDS entspricht, so wie dies bei der Planung der NDS fr das Unternehmen
festgelegt worden ist.
Schutz vor Verlust der Administrierbarkeit
Eine neue Funktionalitt ab Netware Version 4.x ist die Mglichkeit der
dezentralen Administration von Novell Netware Netzen. Dies kann durch
bestimmte administrative Mglichkeiten erreicht werden, wie z. B. der
Definition eines eigenen Administrators fr jedes Behlterobjekt. Wird dafr
nur ein einziger Benutzer-Account verwendet und dieser versehentlich
gelscht, so kann der entsprechende Behlter nicht mehr administriert werden
(siehe G 3.25 Fahrlssiges Lschen von Objekten).
Als wirksame Manahme muss deswegen zustzlich eine ausdrckliche
Trustee-Zuordnung fr mindestens eines der Benutzer-Objekte des
Benutzerverwalters vorgenommen werden. Das Administratorrecht darf also
nicht mit dem Mechanismus Security Equal To erfolgen. Damit wird dem
Verlust der Administrierbarkeit des Behlters vorgebeugt, falls das
organisatorische Funktionsobjekt gelscht wird. Dies gilt insbesondere auch
fr die Rechtezuordnung an die zentralen Administratoren eines Netware 4.x
Netzes.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Information ber Patches von Novell Netware

Im Verlauf der Entwicklung des Netzbetriebssystems Novell Netware haben
sich diverse Schwachstellen bzw. Unzulnglichkeiten herausgestellt, die durch
den Hersteller mit Hilfe von so genannten Patches bzw. Service Packs fr die
entsprechenden Versionen 3.x und 4.x grtenteils behoben wurden. Diese
Patches werden durch den Hersteller im Internet zur Verfgung gestellt
(http://support.novell.com und http://support.novell.de). Informationen ber
die Funktionalitt sowie das ggf. erforderliche Einspielen der zur Verfgung
gestellten Patches knnen daher Schwachstellen im laufenden
Produktionsbetrieb beseitigen. Insbesondere zustzlich installierte
Softwareprodukte, wie z. B. zur Datensicherung, erfordern oftmals einen
bestimmten Patchlevel des Netzbetriebssystems. Hierbei ist jedoch zu
beachten, dass die angebotenen Patches keineswegs "blind" aufgespielt
werden sollten, sondern nur im Bedarfsfall ("never change a running system")
sowie nach grndlicher Information. Soweit vorhanden, sollten diese Patches
zunchst auf einer Testkonfiguration ausgetestet werden.
Im Internet (Usenet) ist, neben den internationalen Diskussionsforen zum
Thema Novell Netware (comp.os.netware.announce, comp.os.netware.misc,
comp.os.netware.security, comp.os.netware.connectivity), fr die deutsch-
sprachigen Benutzer ein deutsches Novell Forum (z. Z. de.comp.sys.novell)
vorhanden, in dem einige versierte Novelladminstratoren aktiv sind, die
oftmals auch die schwierigsten Probleme zu lsen helfen. Auerdem werden
zu den im Internet am hufigsten gestellten Fragen Dateien (so genannte
FAQs - Frequently Asked Questions) zur Verfgung gestellt, die die
hufigsten Probleme thematisieren und Lsungen anbieten.
Patches und Informationen ber Novell Netware werden darber hinaus auch
ber andere Anbieter von Netzdiensten, wie z. B. Compuserve, Fidonet und
Mailboxen bereitgestellt.
Fr die Richtigkeit und Vollstndigkeit der jeweiligen Informationen in den
Usenet Diskussionsforen sowie in den FAQs (Frequently Asked Questions)
kann an dieser Stelle jedoch keine Garantie gegeben werden. Es sei darauf
hingewiesen, dass eine vollstndige Beschreibung des aufgetretenen
Problems, sowie eine Beschreibung der jeweiligen Konfiguration des Netzes
(Client, Server) besonders vorteilhaft bei der Hilfesuche im Internet (Usenet)
ist.
Schwierigkeiten whrend des Netzbetriebes knnen darber hinaus oftmals
durch die Nachfrage bei dem Verkufer des Netzbetriebssystems oder im
Informationsaustausch mit Kollegen behoben werden; wobei auch hier die
Problemlsung durch eine vollstndige Konfigurationsbeschreibung
erleichtert wird.
Prfung auf Computer-Viren
Computer-Viren, die sich in den auf einem Novell Netware Server
gespeicherten Programmen und Dateien befinden, knnen erhebliche Schden
im Netzverbund hervorrufen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Aus diesem Grund sollten die Programme und Dateien eines Novell Netware
Servers regelmig mit einem aktuellen Virensuchprogramm auf evtl.
vorhandene Computer-Viren berprft werden.
Zu diesem Zweck empfiehlt es sich, einen speziellen Benutzer-Account im
Novell Netware 4.x Netz einzurichten, der ber die Zugriffsrechte "Read" (R)
und "File Scan" (F) auf alle Dateien verfgt. Die Prfung auf Computer-Viren
sollte keinesfalls mit den Rechten des Supervisors bzw. Supervisor-
quivalenten Rechten durchgefhrt werden, da ein Computer-Viren-
Checkprogramm, welches selbst mit einem Computer-Virus infiziert ist,
diesen auf alle Programme und Dateien bertragen wrde.
Auch die Benutzer bzw. Benutzergruppen sollten auf die Verzeichnisse und
Dateien mit ausfhrbarem Programmcode lediglich die effektiven Rechte
"Read" (R) und "File scan" (F) erhalten, um deren Infektion mit Computer-
Viren zu vermeiden, die auf lokalen Rechnern aufgetreten sind. Zudem sollten
ausfhrbare Programme mit dem Netware-Attribut "Read only" (Ro) versehen
werden.
Bei eingeschalteter Kompression ist zustzlich zu beachten, dass durch einen
kompletten Suchlauf auf den Netware Volumes alle komprimierten Dateien
dekomprimiert werden mssen. Dies ist sehr zeitaufwendig und verlngert die
Antwortzeiten eines Servers stark.
Regelmige berprfung der Zeitsynchronisation und der NDS-
Reproduktion
Um die Zeitsynchronisation und den Abgleich mehrerer NDS-Reproduktionen
zwischen verschiedenen Netware 4.x Servern zu beobachten, kann an der
Konsole ein separater Netware-Screen aktiviert werden. Dies erfolgt durch die
Eingabe der beiden Befehle
- SET TIMESYNC DEBUG = 7 und
- SET NDS TRACE TO SCREEN = ON.
An der Konsole werden dann die entsprechenden Pakete angezeigt, die
zwischen den Servern bertragen werden. Auf diesem NDS Trace Bildschirm
kann der Abgleich der einzelnen Reproduktionen des jeweiligen Servers
verfolgt werden. Wenn der Abgleich erfolgreich war, wird dies in grner
Schrift angezeigt, Fehlermeldungen werden in roter Schrift dargestellt. Da
dieser Bildschirm regelmig aktualisiert wird, knnen Informationen
bersehen werden. Es ist daher zwingend erforderlich, regelmig die
Konsole-Meldungen zu beobachten. Hier empfiehlt sich allerdings der Einsatz
eines Netzmanagement-Tools, mit welchem man wesentlich zuverlssiger den
Status des Netzes ermitteln und berwachen kann:
Im Fehlerfall ist jedoch das Utility NDS-Manager (SYS:\PUBLIC\WIN95\
NDSMGR32.EXE - fr Window 95 bzw. Windows NT) sehr hilfreich. Hiermit
kann ebenfalls der Reproduktionsstatus berwacht werden.
Regelmige berprfung der Auslastung der System-Festplatte
Damit ein strungsfreies Arbeiten gewhrleistet werden kann, muss
sichergestellt sein, dass das System-Volume eines jeden Netware Servers ber
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
gengend freien Speicherplatz verfgt. Dies ist vor allem bei eingeschalteter
Kompression sehr wichtig. Das System-Volume kann beispielsweise durch
temporre Dateien vollgeschrieben werden, falls deren Ausbreitung nicht
kontrolliert wird und diese nicht von Zeit zu Zeit gelscht werden. Weiterhin
knnen groe Druckerwarteschlangen zu einem berlauf des Systemvolumes
fhren, wenn sehr viele Benutzer gleichzeitig groe Dokumente drucken
wollen.
Es sollte deshalb ein separates Volume fr Druckerwarteschlangen und andere
Verzeichnisse angelegt werden, in denen temporre Dateien abgespeichert
werden. Ist dies nicht mglich, so sollten zumindest Grenbeschrnkungen
auf die entsprechenden Verzeichnisse vergeben werden, um deren
unkontrolliertes Anwachsen zu verhindern. Damit wird gewhrleistet, dass das
System-Volume nicht mehr vollgeschrieben werden kann und immer
gengend Platz fr systemspezifische Aktionen des Netware Servers
vorhanden ist.
- Wurden alle Aktionen fr einen sicheren Betrieb eines Netware 4.x Servers
beachtet?
- Wurden zum Schutz vor Verlust der Administrierbarkeit Ersatz-Benutzer-
Accounts eingerichtet und diese mit ausdrcklichen Trustee-Zuordnungen
fr die jeweiligen NDS-Objekte versehen?
- Werden die Plattenauslastungen und die Konsolenmeldungen regelmig
kontrolliert?
- Werden die Supervisor-Rechte auf die Serverobjekte regelmig geprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.150 Revision von Novell Netware 4.x Netzen

Verantwortlich fr Umsetzung: Revisor
Eine wichtige Methode zur Gewhrleistung der Sicherheit eines Netzes
besteht darin, unabhngigen Revisoren die berprfung der Vorgnge im
Netz zu gestatten. Netware 4.x bietet dazu die Mglichkeit, durch Aktivierung
der Revision mit dem Dienstprogramm SYS:PUBLIC\AUDITCON.EXE eine
Vielzahl von Ereignissen in der NDS und im Dateisystem zu verfolgen. Es ist
bei Netware 4.x mglich, beliebigen Benutzern die Rolle eines Revisors
zuzuweisen. Dieses Programm ermglicht u. a. die folgenden Funktionen:
- Die Revisoren knnen alle NDS-Dateiereignisse der Netware-Server, der
Container oder eines bestimmten Volumes berwachen.
- Die Dateisystemrevision auf Volume- und Behlterebene kann aktiviert
werden.
- Die Revisoren knnen Netzereignisse und -aktivitten zurckverfolgen,
jedoch knnen sie auer den Revisionsdaten- und Revisionsverlaufsdateien
nur diejenigen Dateien ffnen oder ndern, zu denen ihnen vom
Administrator die entsprechenden Rechte erteilt wurden.
Anmerkung: Bei der Aktivierung der Mglichkeiten zur Protokollierung ist
zu beachten, dass die Protokolldatei sehr gro werden kann. Daher sollte die
maximale Gre der Protokolldatei begrenzt werden, um einen Speicher-
platzmangel zu verhindern. Da dies abhngig von der Anzahl der Benutzer
und deren Aktivitten ist, knnen hier jedoch keine konkreten Richtlinien
angegeben werden.
Die dabei anfallenden Daten sind in den meisten Fllen personenbezogen und
unterliegen somit dem Bundesdatenschutzgesetz (BDSG). Es ist
sicherzustellen, dass diese Daten nur zum Zweck der Datenschutzkontrolle,
der Datensicherung oder zur Sicherstellung eines ordnungsgemen Betriebes
verwendet werden (siehe auch M 2.110 Datenschutzaspekte bei der
Protokollierung).
Um einen unabhngigen Revisor einzurichten, der keine sonstigen
administrativen Rechte im Netz hat, aber die Aktivitten eines Administrators
berprfen kann, sind folgende Manahmen durchzufhren:
- Fr Netware 4.10 muss das Auditing fr das Dateisystem bzw. fr die NDS
aktiviert sein und ein Passwort hierfr vergeben werden. Jeder, der dieses
Passwort kennt, ist in der Lage, das Auditing auszuwerten. Deshalb sollte
unter Netware 4.10 sehr sorgsam mit diesem Passwort umgegangen
werden. Weitere Rechtevergaben sind unter Netware 4.10 nicht notwendig.
Ab Netware 4.11 werden die Informationen in NDS-Audit-File-Objekte
abgelegt. Somit lsst sich eine wesentlich bessere Sicherheit hierfr
aufbauen. Zudem bestehen unter Netware 4.11 wesentlich bessere ber-
wachungsmglichkeiten, da man die Anzahl der Auditing-Mechanismen
und -Funktionen wesentlich erweitert hat.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Erstellen eines Benutzer-Objekts fr den Revisor. Die Berechtigung sollte

nicht fr einen herkmmlichen Benutzer-Account vergeben werden, da
dies die Sicherheit aushebeln knnte.
- Ab Netware 4.11 muss der Revisor notwendige NDS-Recht auf die
dementsprechenden NDS-Audit-File-Objekte erhalten.
- Aktivieren der Netzrevision. Die Person, die das NDS-Audit-File-Objekt
erstellt, bekommt das Supervisor-Recht auf das NDS-Audit-File-Objekt
und das Write-Recht auf das Access Control List Property. Zudem
kommen noch das Read- und Write-Recht auf das Audit Policy Property
und das Read-Recht fr das Audit Contents Property hinzu. Somit ist der
Ersteller dieses NDS-Audit-File-Objektes in der Lage, die Administration
fr das Auditing und Auswertungen hierzu durchzufhren.
- Vergabe eines Revisorpassworts im Utility
SYS:PUBLIC\AUDITCON.EXE, um Unabhngigkeit vom Administrator zu
erhalten (Netware 4.10 und aus Kompatibilittsgrnden auch in
Netware 4.11)
Ab Netware 4.11 sollte die Unabhngigkeit des Auditors vom
Administrator ber die Vergabe von NDS-Rechten erzielt werden. Hier
knnen auch noch Abstufungen stattfinden, ob ein bestimmter Revisor
Audit-Daten einsehen und/oder das Auditing administrieren darf.
Ist es aus wohl berlegten Grnden nicht gewnscht oder nicht mglich, die
Rolle eines unabhngigen Revisors einzurichten, kann die Auswertung der
Protokolldateien auch durch den Administrator erfolgen. Fr diesen Fall bleibt
zu beachten, dass damit eine Kontrolle der Ttigkeiten des Administrators nur
schwer mglich ist. Das Ergebnis der Auswertung sollte daher zumindest dem
IT-Sicherheitsbeauftragten, dem IT-Verantwortlichen oder einem anderen
besonders zu bestimmenden Mitarbeiter vorgelegt werden.
- Wer wertet die Revisionsdateien aus?
werden?
- Wurde die maximale Gre der Protokolldatei begrenzt, um einen
Speicherplatzmangel zu verhindern?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.151 Entwurf eines NDS-Konzeptes

Eine der wichtigsten Neuerungen in Novell Netware 4.x stellen die Novell
Directory Services (NDS) dar, die im deutschen Sprachgebrauch als Novell
Verzeichnis Dienste bezeichnet werden. Die NDS bezieht sich auf die logische
Struktur des Netzes und aller darin vorhandenen Ressourcen wie z. B.
Benutzer, Gruppen, Drucker oder Netware Server.
Die Technologie der NDS ersetzt die noch in Netware 2.x und Netware 3.x
verwendete Bindery. In der Bindery sind alle Benutzer, Gruppen usw. in einer
eindimensionalen Liste enthalten. Beim Einsatz mehrerer Netware 3.x Server
steht der Administrator jedoch vor dem "Problem", dass jede nderung
(beispielsweise das Hinzufgen eines Benutzers) auf jedem Netware 3.x
Server manuell ausgefhrt werden musste, d. h. auf allen Servern, fr die
einem Benutzer Zugriffsrechte gegeben werden sollten.
Die Novell Verzeichnis Dienste hingegen sind unabhngig von einem konkre-
ten Server und orientieren sich ausschlielich am zugrunde liegenden Netz.
Dies bedeutet, dass Administrationsarbeiten wie nderungen oder Einrichtun-
gen eines Benutzer-Accounts von den Novell Verzeichnis Diensten auf allen
betroffenen Servern vollzogen werden, ohne dass ein manuelles Eingreifen
des Administrators erforderlich ist.
Die Ressourcen werden in einer Datenbank baumfrmig verwaltet, deshalb
spricht man auch vom NDS-Tree bzw. NDS-Baum. Im NDS-Baum werden
alle Benutzer, Gruppen, Drucker, Netware Server usw. als Objekte in der so
genannten NDS-Verzeichnisdatenbank verwaltet. Hierbei unterscheidet man
zwei Arten von Objekten: Containerobjects (Behlterobjekte) und Leafobjects
(Blattobjekte). Whrend sich ein Blattobjekt am Ende eines Zweiges befindet
und keine weiteren Objekte mehr beinhaltet, kann ein Behlterobjekt weitere
Behlter oder Blattobjekte enthalten.
Es existieren u. a. folgende Behlterobjekte:
- Root (Stammobjekt)
Die Root stellt die Wurzel des NDS-Verzeichnisbaumes dar. Jeder NDS-
Verzeichnisbaum hat genau ein solches Objekt, das bei der Installation
angelegt wird und weder umbenannt noch gelscht werden kann. In jedem
NDS-Verzeichnisbaum kann sich nur ein solches Objekt befinden.
- Country (Land)
Das Objekt Country ermglicht eine geographische Unterteilung der
gesamten Struktur des NDS-Verzeichnisbaumes, d. h. eine Einteilung des
Netzes nach verschiedenen Lndern. Dieses Objekt ist jedoch optional und
wird deshalb bei der Installation der NDS auch nicht vorgegeben.
- Organization (Organisation)
Das Objekt Organization dient dazu, weitere Objekte im NDS-Verzeich-
nisbaum hierarchisch anzuordnen. Dabei gibt es keine festen Regeln, so
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
dass ein Unternehmen beispielsweise sowohl den Firmennamen als auch

verschiedene Niederlassungen als Bezeichnung der Organisation verwen-
den kann. Jeder NDS-Verzeichnisbaum muss mindestens eine Organisation
beinhalten.
- Organizational Unit (Organisatorische Einheit)
Die Organizational Unit kann nur unterhalb einer Organisation erstellt
werden und dient zur weiteren Unterteilung der NDS. Beispielsweise
lassen sich Niederlassungen, Abteilungen oder Projektgruppen in organisa-
torischen Einheiten anordnen. Die organisatorische Einheit ist optional und
wird zur besseren Strukturierung je nach Anzahl der Blattobjekte
eingesetzt.
Als Blattobjekte bezeichnet man z. B. Benutzer, Gruppen, Drucker, Server
oder Datentrger. Es ist nicht mglich, unter Blattobjekten weitere Objekte
anzulegen. Folgende Blattobjekte werden am hufigsten verwendet:
- Netware Server
Dieses Objekt reprsentiert einen Netware Server im Netz, von dem es
mindestens einen geben muss. Auf dieses Objekt wird von vielen anderen
Objekten verwiesen, die die vom Server bereitgestellten Dienste verwen-
den. Dieses Objekt wird bereits durch das Installationsprogramm erstellt.
- Drucker
Hiermit wird ein im Netz vorhandener Drucker dargestellt. Zu einem
Drucker gehren immer die Objekte Druckerwarteschlange und Druck-
server.
- Benutzer
Dieses Objekt dient zur Verwaltung und Speicherung von Informationen
ber einen Benutzer des Netzes, insbesondere ber seine Zugriffsrechte auf
Netzressourcen.
- Gruppen
Obwohl in einer Gruppe mehrere Benutzer zusammengefasst werden
knnen, stellt eine Gruppe ein Blattobjekt und kein Behlterobjekt dar. Sie
dient zur einfacheren Administration, da die Rechte einer Gruppe auf deren
Mitglieder bertragen werden.
- Volume
Hiermit wird ein physikalisches Volume zum Speichern von Daten darge-
stellt. Volumeobjekte werden in der Regel vom Installationsprogramm
erstellt.
Fr eine detailliertere Beschreibung der weiteren Blattobjekte wird auf die
Netware Handbcher verwiesen. Auch sind der Objektvielfalt keine Grenzen
gesetzt, da z. B. Objekte von Applikationen hinzugefgt, aber auch entfernt
werden knnen.
Die Verzeichnisobjekte und deren Attribute werden, wie bereits erwhnt, in
einer Datenbank verwaltet, die wesentlicher Bestandteil der NDS ist. In
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Netzen mit WAN-Verbindungen empfiehlt es sich, diese Datenbank in

logische Segmente aufzuteilen, welche auf verschiedene Netware-Server
kopiert werden. Es ist hierbei wichtig beim Planen der Reproduktionen auf
langsame WAN-Verbindungen zu achten.
Diese logische Segmentierung wird als Partitionierung bezeichnet. Der
Kopiervorgang der logischen Segmente auf die Netware-Server wird als
Reproduktion bezeichnet.
Jede Partition besteht aus mindestens einem Behlterobjekt und den darin
enthaltenen Objekten. Zustzlich kann es von einer Partition noch mehrere
Lese- bzw. Schreib/Lese-Kopien geben, jedoch immer nur eine Haupt-Repro-
duktion.
Die physische Unterteilung der NDS in Partitionen ist fr die Anwender
transparent; d. h. die Netware-internen Mechanismen sorgen dafr, dass der
Anwender nichts von der Aufteilung bemerkt.
Der Entwurf eines NDS-Verzeichnisbaumes unterliegt prinzipiell keinerlei
Beschrnkungen, so dass es zur Erzeugung der unterschiedlichsten Formen
mit beliebiger Komplexitt kommen kann. Dabei sollte jedoch eine grndliche
und sorgfltige Planung durchgefhrt werden, wobei folgende Grundstze zu
beachten sind:
- Eine bersichtliche NDS sollte maximal zwischen 4 und 8 Ebenen tief sein.
- Die maximale Anzahl aller Objekte in einer Organisation oder in einer
organisatorischen Einheit sollte nicht mehr als 1.500 betragen.
- Mehrere kleinere Abteilungen sollten zu einer organisatorischen Einheit
zusammengefasst werden, um deren Anzahl zu reduzieren und die ber-
sichtlichkeit zu erhhen.
- Es sollten aussagekrftige, aber nicht zu lange Namen verwendet werden
(z. B. "F&E" statt "Forschung und Entwicklung"), da die gesamte Pfad-
angabe innerhalb des NDS-Baumes maximal 255 Zeichen lang sein darf.
Diese Begrenzung kommt allerdings nur indirekt zustande, da DOS-
Zeilenkommandos keine lngeren Eingaben zulassen. Diese Pfadangabe
wird Kontext genannt.
- Von jeder Partition sollten zustzlich zur Hauptpartition zwei weitere
Schreib/Lese-Partitionen erstellt werden. Durch die somit vorhandene
Redundanz ist der Verlust von NDS-Informationen gering. Eine Sicherung
der NDS bleibt trotzdem obligatorisch.
- Das Netware Loadable Module (NLM) Directory Service (DS.NLM) ist auf
allen Netware Servern innerhalb eines NDS-Baumes, auf dem dieselben
Netware Versionen installiert sind, in derselben Version zu benutzen, da
sich verschiedene Versionen unter Umstnden nicht miteinander
synchronisieren. In NDS-Bumen, in denen z. B. Netware Server der Ver-
sionen 4.10, 4.11 und 5.0 installiert sind, mssen sich die Versionen der
DS.NLM auf den einzelnen Netware Servern sehr wohl unterscheiden. Nur
die DS.NLM auf allen Netware Servern der Versionen 4.10, 4.11 und 5.0
muss, um unntige Probleme zu vermeiden, in derselben Version installiert
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sein. Da prinzipiell Mischumgebungen erlaubt sind, zeigt die Praxis, dass

eine homogene Serverlandschaft - entweder nur Netware Server der
Versionen 4.10, 4.11 oder 5.0, die stabilsten und die am besten zu admini-
strierenden NDS-Netze sind.
Bei der Planung der NDS ist nicht vorrangig die Gre des Netzes, sondern
das Umfeld entscheidend, wie z. B. die Hardware, die Kommunikations-
verbindungen, die LAN/WAN-Topologie und die Struktur der Organisation.
Beispielsweise ist fr ein kleines Netz mit mehreren WAN-Verbindungen ein
grerer Aufwand fr die Planung erforderlich als fr ein groes Netz ohne
WAN-Verbindungen, da mit den verschiedenen WAN-Architekturtypen ein-
deutige physische Attribute verknpft sind. Eine Planung sollte zumindest die
folgenden Punkte abdecken:
- Festlegung eines Standards fr die Benennung von Objekten (insbesondere
Namenskonventionen fr Benutzer- und Druckerkennungen),
- Entwurf einer Verzeichnisbaumstruktur,
- Festlegung der Position von Netzressourcen (z.B. Drucker und Server)
innerhalb des NDS-Baumes bzw. Container, um Benutzern und Admini-
stratoren eine transparente Sicht des Netzes zu ermglichen,
- NDS-Baum sollte die Organisationsstruktur des abzubildenden Unterneh-
mens widerspiegeln,
- Einheitliche sowie abgestimmte Positionierung von Netzressourcen an
verschiedenen Standorten um Benutzern mit hufigen Standortwechsel ein
mglichst kurze Einarbeitungszeit zu ermglichen,
- Festlegung einer Partitions- und Reproduktionsstrategie, die unter anderem
stark abhngig von WAN-Verbindungen ist.
Fr weitergehende Informationen zur NDS-Planung sei an dieser Stelle auf
das Handbuch zu Netware 4 Netzwerken von Novell verwiesen, welches die
Implementierung eines Netware 4.x Netzes ausfhrlich beschreibt.
- Existieren regelmig Absprachen der einzelnen Administratoren der ver-
schiedenen Standorte?
- Wurden alle Planungsgrundstze eingehalten?
- Sind die NDS, Planungsgrundstze und die Absprachen der Administra-
toren dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.152 Entwurf eines Zeitsynchronisations-Konzeptes

Die Stabilitt eines Netware 4.x Netzes hngt wesentlich von der Zeit-
synchronisation ab und steht im direkten Zusammenhang mit den Novell
Directory Services (NDS).
Zeitsynchronisation bedeutet in diesem Fall, dass in einem Netz mit NDS und
mehreren Netware-Servern deren Uhrzeit bereinstimmen muss. Dabei betrgt
die Standardtoleranz zwei Sekunden. Die Uhren smtlicher Netware-Server
der NDS drfen also nicht mehr als zwei Sekunden voneinander abweichen.
Ist dies gewhrleistet, wird die Uhrzeit im Netz als synchron bezeichnet.
In einem Multiserver-Netz sind im allgemeinen mehrere Replikationen
und/oder Partitionen der NDS auf den Netware-Servern verteilt. Wird eine
nderung an einer Partition der NDS durchgefhrt, wird diese mit einem
Zeitstempel versehen. Diese nderung wird dann beim nchsten NDS-
Abgleich an die Partitionen und Replikationen auf den anderen Netware-Ser-
vern im Netz weitergegeben. Geht die Uhrzeit auf einem der Netware-Server,
der die nderung empfngt, um beispielsweise eine Stunde nach und ist somit
nicht in sync, knnen die nderung fr diese NDS-Replikation oder Partition
erst synchronisiert werden, wenn der betroffene Server wieder in sync ist.
Grundstzlich kann man die folgenden zwei Szenarien unterscheiden:
- Einzelreferenz
Dieses Zeitmodell wird von Novell fr Netze mit bis zu 30 Netware-
Servern empfohlen. Es ist sehr einfach einzurichten, und es bedarf keiner
detaillierteren Planung der Zeitsynchronisation.
In diesem Modell dient ein einziger Netware-Server als Zeitgeber
(Einzelreferenz), whrend die restlichen Netware-Server nur als Zeit-
nehmer fungieren. Der Einzelreferenz-Server gibt die Uhrzeit fr das
gesamte Netz vor und sollte deshalb mit einer externen Zeitquelle (z. B.
einer Funkuhr) verbunden werden.
Ein groer Nachteil dieses Zeitmodells ist, dass beim Ausfall des Einzel-
referenz-Servers kein Zeitabgleich mehr stattfinden kann, mit allen daraus
resultierenden Konsequenzen.
- Zeitgebergruppen
Bei greren Netzen empfiehlt es sich, Zeitgebergruppen zu verwenden.
Sie sind nicht schwer zu konfigurieren, erfordern jedoch eine angemessene
Planung. Hier teilen sich mehrere Netware-Server die Zeitgeber-Rolle.
Einer von ihnen ist der Referenz-Server, welcher mit einer externen Zeit-
quelle verbunden werden sollte.
Eine Stufe unter dem Referenz-Server stehen die primren Zeitserver, von
denen mindestens zwei existieren mssen. Dieser Zeitservertyp unter-
scheidet sich nicht grundlegend von einem Referenz-Server. Alle Refe-
renz- und Primr-Server bestimmen gemeinsam eine gltige Netzzeit und
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
geben diese Zeit an die Sekundr-Server weiter. Der Referenz-Server ist

der ruhende Pol im Netz. Da er seine Zeit nicht an die Netzzeit anpat,
muss sich zwangslufig die Netzzeit an ihn anpassen. Daher ist er auch
derjenige Server, an dem die Netzzeit, falls notwendig, korrigiert werden
muss. Im Gegensatz dazu passen Primr-Server ihre Zeit an die Netzzeit
an.
Ein entscheidender Vorteil dieses Modells ist, dass durch die Primr-Server
Ersatz-Zeitgeber vorhanden sind und bei einem Ausfall des Referenz-
Servers weiterhin eine Zeitsynchronisation stattfinden kann. Trotz der
Aussage von Novell, dass dieses Modell ab 30 Netware-Servern verwendet
werden soll, kann es auch mit bedeutend weniger Netware-Servern einge-
setzt werden.
Zeitgeber, Einzelreferenz-, Referenz- und Primr-Server werden in der
Standardkonfiguration dynamisch ber SAP/RIP-Mechanismen im Netz
bekannt gegeben. Dies hat den Nachteil, dass man keinen Einfluss darauf
hat, welcher Zeitserver mit welchem Zeitserver kommuniziert. Dies ist
unter Umstnden besonders bei WAN-Verbindungen nicht wnschenswert.
Darum gibt es hier die Mglichkeit, auch mit konfigurierbaren Listen zu
arbeiten und den SAP/RIP-Mechanismus auszuschalten.
Beim Entwurf eines Zeitsynchronisations-Konzeptes sollten die folgenden
Punkte beachtet werden:
- In jedem Netz mit mehr als einem Netware-Server sollte eine externe
Zeitquelle (z. B. Funkuhr) installiert werden.
- Bei WAN-Verbindungen innerhalb eines Netzes, in dem die NDS einge-
setzt wird, sollte an einem Standort mit mehreren Netware 4.x Servern
mindestens ein Zeitgeber vorhanden sein, so dass die lokalen Sekundr-
Server auf einen lokalen Zeitgeber zurckgreifen knnen.
- Sollte auf einem Netware-Server aufgrund einer Fehlkonfiguration die
eingestellte Uhrzeit sehr weit in der Zukunft liegen (beispielsweise 1 Jahr),
so wrde der Server nach Umstellung auf die korrekte Uhrzeit fr 1 Jahr
die Fehlermeldung "Synthetische Zeit ..." fr alle NDS-Ereignisse aus-
geben. Diese Fehlermeldung knnte beseitigt werden, wenn im Programm
DSREPAIR.NLM eine neue Zeitepoche deklariert werden wrde. Dabei
wrde die komplette NDS auf diesem Server gelscht und neu erstellt
werden. Dies ist ein relativ kritischer Eingriff in die NDS und sollte daher
wohl berlegt sein.
- Wurde die Zeitsynchronisation angemessen geplant?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.153 Dokumentation von Novell Netware 4.x Netzen

Eine wichtige Manahme zur Gewhrleistung eines sicheren Betriebs, welche
aus Zeit- oder Personalmangel oft vernachlssigt wird, ist die Dokumentation
der wesentlichen Informationen eines Novell Netware 4.x Netzes. Da die
Verantwortlichkeit ber bestimmte Bereiche des Netzes wechseln oder auch
ein Personalausfall auftreten kann, ist es unerlsslich, alle relevanten Informa-
tionen zu jedem Netware Server zu erfassen und in einer bersichtlichen
Dokumentation darzustellen. Dies erleichtert die Einarbeitung einer eventuell
erforderlichen Vertretung und verkrzt beim Auftreten eines Fehlers die Aus-
fallzeit.
In einer solchen Dokumentation sollten die folgenden Informationen (mit
allen erforderlichen Parametern) in einer transparenten und einfach zu aktua-
lisierenden Form dargestellt werden:
NDS
Auf die Dokumentation der NDS ist ein besonders hohes Augenmerk zu
richten, da sie unter Umstnden nicht auf einem einzigen zentralen Server
gehalten wird, sondern sich insbesondere in Netware Netzen mit vielen WAN-
Verbindungen in verschiedenen Partitionen befinden kann und auf
unterschiedlichen Netware Servern gespeichert wird. Im Einzelfall kann dies
bedeuten, dass z. B. ein Server mit einer Schreib/Lese-Partition zur Haupt-
Reproduktion-Partition gendert werden muss, wenn der eigentliche Haupt-
Reproduktionsserver einer Partition durch einen Hardwareausfall neu instal-
liert werden muss. Allerdings kann dieser Problemfall durch geeignete Siche-
rungsmechanismen umgangen werden. Man sieht schon anhand dieses Bei-
spiels, wie komplex der Aufbau einer weitverzweigten NDS ausfallen kann,
und somit die Notwendigkeit einer entsprechenden Dokumentation besteht.
Hierin sollten auf jeden Fall der Aufbau der NDS und auch Informationen
ber die vergebenen NDS- und Datei-Rechte zu finden sein.
Zeitsynchronisation
Da NDS und Zeitsynchronisation eng verwandte Themen sind, ist es sinnvoll,
sie auch in der Dokumentation miteinander zu verbinden. Dies ergibt sich aus
dem Umstand, dass alle relevanten Informationen, die ber das Netware 4.x
Netz ausgetauscht werden, mit Zeitstempeln versehen sind.
Damit die Zeitsynchronisation in einem Novell Netware 4.x Netz ordnungs-
gem funktioniert und die entsprechenden Zeitinformationen auch auf jedem
Server zum gewnschten Resultat fhren, muss klar festgelegt werden,
welcher Server als Zeitquelle fungiert und welches Zeitmodell verwendet
wird. Aus diesem Grund ist es auch unerlsslich, die Zeitsynchronisation und
die entsprechenden NDS Dienste korrekt darzustellen, um im Fehlerfall die
richtigen Schritte einleiten zu knnen.
Die unten aufgefhrte Tabelle zeigt ein Beispiel, wie eine entsprechende
Dokumentation aussehen kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SERVER ZEITTYP PARTITIO-

NEN
[Root] Public Hamburg Berlin
Hamburg-S1 Referenz Haupt- Haupt-
Repro- Repro-
duktion duktion
Hamburg-S2 Sekundr Lese/ Lese/
Schreib- Schreib-
Repro- Repro-
duktion duktion
Hamburg-S3 Sekundr Haupt- Haupt-
Repro- Repro-
duktion duktion
Berlin-S1 Primr Lese/ Lese/
Schreib- Schreib-
Repro- Repro-
duktion duktion
Berlin-S2 Primr Lese/
Schreib-
Repro-
duktion
Hardware-Konfiguration
Hier ist anzumerken, dass bei einer Neuinstallation des Netware Servers (z. B.
nach einem Systemabsturz) smtliche Informationen zu den Einstellungen der
Hardware bekannt sein mssen, um den Server sachgerecht und zgig konfi-
gurieren zu knnen. Sind diese nicht bekannt, so mssen sie im Einzelfall erst
ber entsprechende Programme abgefragt oder am Gert abgelesen werden,
was einen nicht zu unterschtzenden Zeitaufwand darstellt. Dies gilt insbe-
sondere fr das Beheben von zeitkritischen Fehlern.
Fr alle eingesetzten Hardware-Komponenten im Server, wie z. B. Netzadap-
terkarten, Grafikkarten, Kommunikationsschnittstellen (seriell, parallel, USB,
PS/2 usw.) oder SCSI-, IDE- und RAID-Controller, mssen u. a. folgende
Informationen vorgehalten werden:
- Interrupt,
- E/A-Schnittstelle,
- DMA-Kanal,
- SCSI- und LUN-Adresse,
- Speicheradresse,
- Knotenadresse,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Steckplatznummer,
- Externe IPX-Netzwerknummer und
- Rahmentyp.
Zur Dokumentation der Server-Hardware gehren auch die externen Gerte,
wie z. B.
- Drucker oder
- externe Sub-Systeme (Festplattenschrnke u. .).
Als Beispiel und Hilfe kann hierfr in der Original-Dokumentation zu Novell
Netware 4.11 (Handbuch zu Netware 4) im Anhang C: Beispiel zu Schablonen
unter C8 nachgeschlagen werden.
Softwarekonfiguration
Ein weiterer wichtiger Punkt ist die Konfiguration der Software. Dazu geh-
ren u. a. die folgenden Aspekte:
- Patchlevel,
- NLMs (Netware Loadable Modules),
- Treiber und
- Konfigurationsdateien (AUTOEXEC.NCF, STARTUP.NCF, DHCPTAB,
etc., siehe auch die Beschreibung CONFIG.NLM und Config-Reader).
Da wichtige Programme unter Umstnden nur ab einem bestimmten
Patchlevel arbeiten, muss dokumentiert werden, welche Systemupdates not-
wendig sind, um die betroffenen Programme (wie z. B. Backup-Utilities) aus-
fhren zu knnen. Aus diesem Grund sollte notiert werden, welche Updates
und Patches zu welchem Zweck auf dem Netware Server installiert wurden.
Es sei an dieser Stelle auch auf ein Tool hingewiesen, mit dem diese Einzel-
heiten der Konfiguration abgefragt und in einer ASCII-Datei gespeichert
werden knnen. Dabei handelt es sich um das Programm CONFIG.NLM.
Dieses Programm muss an der jeweiligen Server-Konsole gestartet werden
und erzeugt eine Datei CONFIG.TXT. Mit Hilfe des Windows-Programms
Config-Reader kann diese Konfigurationsdatei analysiert werden. Beide Pro-
gramme sind im Internet unter http://support.novell.com zu finden. In der
Datei CONFIG.TXT wird in wenigen Sekunden die komplette Konfiguration
des Netware Servers abgelegt. Dies vereinfacht den Wiederanlauf eines
Servers bei Hardwareausfall wesentlich.
- Wurden alle relevanten Informationen zu den Netware Servern dokumen-
tiert?
- Wird die Dokumentation regelmig aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.154 Erstellung eines Computer-

Virenschutzkonzepts
Um fr eine gesamte Organisation einen effektiven Computer-Virenschutz zu
erreichen, sind abgestimmte und angemessene Schutzmanahmen
auszuwhlen und umzusetzen. Dies setzt eine konzeptionelle Vorgehensweise
voraus, um smtliche betroffenen IT-Systeme mit geeigneten Manahmen zu
versehen und durch Aktualisierung den notwendigen Schutz aufrechtzuhalten.
Nachfolgend wird das Inhaltsverzeichnis eines Computer-Virenschutz-
konzeptes aufgezeigt.
Inhaltsverzeichnis Computer-Virenschutzkonzept
Teil A: Sensibilisierung
1 Abhngigkeit der Institution vom IT-Einsatz
2 Beschreibung des Gefhrdungspotentials
2.1 Computer-Viren
2.2 Makro-Viren
2.3 Trojanische Pferde
2.4 Hoax
3 Schadensszenarien
4 Potentiell betroffene IT-Systeme
Teil B: Erforderliche Schutzmanahmen
5 Computer-Virenschutz-Strategie
5.1 Nicht-vernetzte IT-Systeme
5.2 Vernetzte Endgerte
5.3 Server
6 Aktualisierung der Computer-Viren-Suchprogramme
6.1 Nicht-vernetzte IT-Systeme
6.2 Vernetzte Endgerte
6.3 Server
Teil C: Regelungen
7 Regelungen zum Schutz vor Computer-Viren
7.1 Nutzungsverbot nicht freigegebener Software
7.2 Schulung der IT-Benutzer
7.3 Umstellung der Boot-Reihenfolge
7.4 Anlegen einer Notfalldiskette
7.5 Verhaltensregeln bei Auftreten eines Computer-Virus
7.6 Manahmen bei nicht-resident virenkontrollierten IT-Systemen
7.6.1 Regelmiger Einsatz eines Computer-Viren-Suchprogramms
7.6.2 Virenkontrolle bei Datentrgeraustausch und Datenbertragung
7.6.3 Prfung eingehender Dateien auf Makro-Viren
8 Regelung der Verantwortlichkeiten
8.1 Ansprechpartner fr Computer-Viren
8.2 Verantwortlichkeit von Administratoren
8.3 Verantwortlichkeit des einzelnen IT-Benutzers
8.4 Verantwortlichkeit des IT-Sicherheitsmanagements
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Teil D: Hilfsmittel
10 Verhaltensregeln bei Auftreten eines Computer-Virus
11 Meldewege bei Auftreten eines Computer-Virus
12 Benutzerhandbuch des Computer-Viren-Suchprogramms
Die nachfolgenden Manahmen erlutern, wie einige wichtige Teile dieses

Konzepts erstellt werden knnen.
- Ist das Computer-Virenschutzkonzept vom Management in Kraft gesetzt
worden?
- Ist das Computer-Virenschutzkonzept allen Betroffenen bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.155 Identifikation potentiell von Computer-Viren

betroffener IT-Systeme
Fr die Erstellung eines Viren-Schutzkonzeptes mssen in einem ersten
Schritt die potentiell von Computer-Viren bedrohten IT-Systeme der
Behrde/Institution identifiziert werden. Aus einer bersicht aller IT-
Systeme, die im Einsatz sind oder deren Einsatz geplant ist, knnen dazu alle
IT-Systeme herausgefiltert werden, fr die Computer-Viren eine Bedrohung
darstellen oder ber die Computer-Viren verteilt werden knnen. Diese
bersicht kann auch aus den Ergebnissen der Schutzbedarfsfeststellung nach
IT-Grundschutzhandbuch Kapitel 2.2 gewonnen werden.
Durch Computer-Viren sind typischerweise alle IT-Systeme mit PC-basierten
Betriebssystemen wie DOS, Windows 3.x, 95/98 oder NT betroffen oder
solche mit Anwendungsprogrammen wie Microsoft Word oder Excel, die
durch Makro-Viren infiziert werden knnen.
Server werden zwar im allgemeinen nicht direkt durch Computer-Viren
bedroht, knnen aber eine Verteilstelle fr infizierte Programme und Dateien
sein.
Es kann nicht ausgeschlossen werden, dass Computer-Viren auch bei Verwen-
dung anderer Betriebssysteme oder IT-Anwendungsprogramme auftreten
knnen. Dies gilt zum Beispiel in wenigen Einzelfllen bei Unix-Systemen
und OS/2-Systemen, die jedoch aufgrund geringer Verbreitung nur ein
niedriges Bedrohungspotential darstellen (siehe G 5.23 Computer-Viren).
Fr jedes identifizierte IT-System kann in einem nchsten Schritt ergnzend
erfasst werden, welche mglichen Infektionswege fr Computer-Viren beste-
hen. Diese Informationen knnen fr die sptere Auswahl von Manahmen
genutzt werden. Eine Infektion durch Computer-Viren kann beispielsweise
erfolgen:
- bei Einsatz von Disketten, CD-ROMs oder anderen austauschbaren Daten-
trgern,
- bei der Installation neuer Software,
- durch den Zugriff auf Dateien, die nicht auf der lokalen Festplatte gespei-
chert sind, sondern auf einem Server im Netz bzw. in einem freigegebenen
Verzeichnis innerhalb eines Peer-to-Peer-Netzes,
- durch den Zugriff auf von externer Stelle erhaltene Dateien (z. B. Attach-
ment einer E-Mail, Dateien aus dem Internet),
- bei extern vorgenommenen Wartungsarbeiten.
Sinnvoll ist es, fr jedes identifizierte IT-System oder exemplarisch fr jeden
identifizierten IT-System-Typ tabellarisch zu erfassen, ber welche Schnitt-
stellen eine Computer-Vireninfektion erfolgen kann. Dies knnen sein:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- alle lokal am Rechner vorhandenen Lesegerte fr austauschbare Daten-

trger (Diskettenlaufwerk, CD-ROM-Laufwerk, Streamer, Wechselplatten
u. a.),
- alle mobilen, an die Rechner lokal anschliebaren Lesegerte fr
austauschbare Datentrger (Diskettenlaufwerk, CD-ROM-Laufwerk,
Streamer, Wechselplatten u. a.),
- die Anbindung an andere IT-Systeme im eigenen Sicherheitsbereich (LAN-
Server, Peer-to-Peer-Verbindungen),
- Schnittstellen, ber die ein Datentransfer von externen IT-Systemen auf
das lokale IT-System erfolgen kann (Modem, Internet-Anschluss).
Der wichtigste Punkt einer solchen bersicht ist die Benennung von
Ansprechpartnern fr die jeweiligen IT-Systeme, die fr die Realisierung der
notwendigen Manahmen verantwortlich sind und die Anlaufstellen fr die
Benutzer sind. Da die IT-Landschaft einer Organisation stndigen nde-
rungen unterworfen ist, mssen im Hinblick auf Vernderungen an beste-
henden Systemen diese Informationen bei Bedarf aktualisiert werden.
Beispiel fr die Erhebung:
Vorhandene und geplante IT-Systeme / Schnittstellen
Bezeichnung lokal lokale externe Kommuni- Ansprechpartner fr
und Art vernetzt Lesegerte Lesegerte kationskarten Virenproblematik
Server Abt. X, x Disketten-, Streamer Modem Administrator Mller
Novell 4 CD-ROM-
Laufwerk
Clients Abt. X x Disketten-, PC-Betreuer Meier
Windows 95 CD-ROM-
Laufwerk
Laptops, Disketten- Laptop-Verwaltung
Windows NT Laufwerk Schulze
Server Abt. XI, x Disketten-, Streamer Administratorin
Unix CD-ROM- Schmitz
Laufwerk
Workstations x -
Abt. XI
Unix
PCs Sekretariat x Frau Peze
Windows 95
... ... ... ... ...
- Wie wird sichergestellt, dass bei Vernderungen der eingesetzten IT-
Systeme oder bei Einsatz neuer IT-Systeme die erforderlichen Manahmen
des Virenschutz-Konzeptes bercksichtigt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.156 Auswahl einer geeigneten Computer-

Virenschutz-Strategie
Fr die Umsetzung eines Computer-Virenschutzes sind personelle und
finanzielle Ressourcen erforderlich, die in einem angemessenen Verhltnis zu
dem tatschlichen Bedrohungspotential stehen mssen. Fr die Gesamtheit der
identifizierten potentiell durch Computer-Viren bedrohten IT-Systeme sind
folgende Einflussfaktoren zu erheben:
- Wie hufig findet ber die vorhandenen Schnittstellen ein Datentransfer
statt, der zu einer Infektion bzw. Verbreitung von Computer-Viren fhren
kann?
- Mit welchen Folgen ist bei einer tatschlichen Infektion zu rechnen, wenn
keine Schutzmanahmen ergriffen werden?
- Wie zuverlssig werden von den IT-Benutzern IT-Sicherheitsmanahmen
durchgefhrt, die periodisch zu veranlassen sind?
- Wieviel Zeitaufwand kann den IT-Benutzern fr Computer-Viren-
Schutzmanahmen zugemutet werden?
Bei Kenntnis der daraus und aus Fachverffentlichungen ableitbaren
Hufigkeit von Computer-Viren-Infektionen und der daraus entstehenden
mglichen Folgeschden ist unter Einbeziehung des Managements zu
entscheiden, welche finanziellen Ressourcen fr notwendige Manahmen zur
Verfgung gestellt werden mssen und welche personellen Ressourcen
bereitgestellt werden.
In Kenntnis der finanziellen und personellen Ressourcen, die fr den
Computer-Virenschutz zur Verfgung stehen, und der identifizierten potentiell
bedrohten IT-Systeme knnen Strategien ausgewhlt werden, wie ein
geeigneter Schutz erreicht werden kann.
Einige mgliche Strategien werden im folgenden vorgestellt.
Computer-Viren-Suchprogramme auf jedem Endgert
Erfolgt auf einem IT-System der Einsatz eines aktuellen residenten Computer-
Viren-Suchprogramms (also eines Programmes, das permanent im
Hintergrund luft), wird sichergestellt, dass ein infiziertes Programm nicht
ausgefhrt oder eine Datei mit einem Makro-Virus nicht geladen werden kann.
Die Kontrolle der Schnittstellen am Endgert bernimmt das residente
Suchprogramm. Dadurch wird gewhrleistet, dass eine bertragung auf das
IT-System nicht erfolgt. Der ausschlieliche Einsatz nicht-residenter
Computer-Viren-Suchprogamme (die nur durch explizites Starten des
Programms durch den Benutzer aktiviert werden) empfiehlt sich nicht, da
hierdurch heute kein wesentlicher finanzieller Vorteil erzielbar ist, jedoch die
Nachteile auf Seiten des IT-Benutzers erheblich zunehmen, da er zuverlssig
regelmig das Programm aktivieren muss.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Werden alle Endgerte mit einem residenten Computer-Viren-Suchprogramm

ausgestattet, ist sichergestellt, dass Computer-Viren sofort nach Auftreten
identifiziert und dass sie nicht vom Endgert aus weitergegeben werden.
Darber hinaus sollte der Einzelaufruf auch bei residenten Viren-Such-
programmen auf jedem Client mglich sein, um bei Bedarf, z. B. vor dem
ffnen von E-Mail-Attachments diese gezielt berprfen zu knnen.
Vorteile:
- Ein geeignetes, aktuelles und residentes Computer-Viren-Suchprogramm
gewhrleistet einen maximalen Schutz bei gleichzeitig minimalen
Aufwand fr den IT-Benutzer
Nachteile:
- Anschaffungskosten sowie Administrationsaufwand fallen fr jedes
Endgert an.
- ltere IT-Systeme haben unter Umstnden nicht ausreichend
Hauptspeicher. Es knnte auerdem zu Komplikationen bei der
Zusammenarbeit mit anderen Programmen kommen.
Computer-Viren-Suchprogramme auf allen Endgerten mit externen
Schnittstellen
In vernetzten IT-Systemen wird ein residentes Computer-Viren-
Suchprogramm nur auf den IT-Systemen installiert, die neben Schnittstellen
zum eigenen internen Netz ber weitere externe Schnittstellen
(Diskettenlaufwerk, CD-ROM, Modem) verfgen. Vernetzte IT-Systeme ohne
direkte externe Schnittstellen werden nicht mit Computer-Viren-
Suchprogrammen ausgestattet.
Vorteile:
- Anschaffungskosten sowie Administrationsaufwand reduzieren sich auf die
IT-Systeme mit externen Schnittstellen.
Nachteile:
- nderungen an den IT-Systemen, die zur Einrichtung neuer externer
Schnittstellen fhren, mssen akribisch nachgehalten werden, da ggf. die
Nachrstung von IT-Systemen mit Computer-Virersuchprogammen
notwendig wird.
- Verschlsselte Dateien oder Programme, die Computer-Viren beinhalten
und erst auf einem ungeschtzten Endgert entschlsselt werden, fhren zu
Infektionen. Dies kann in gleicher Weise auch fr komprimierte Dateien
gelten, wenn das Suchprogramm nicht geeignet ist.
Computer-Viren-Suchprogramme auf allen Servern
In diesem Fall wird in einem vernetzten IT-System jeder Server mit einem
residenten Computer-Viren-Suchprogramm ausgestattet, die angeschlossenen
Endgerte jedoch nicht. Dadurch wird sichergestellt, dass keine bertragung
von Computer-Viren von einem Endgert auf ein anderes Endgert erfolgen
kann und so eine mgliche Infektion lokal isoliert bleibt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorteile:
- Anschaffungskosten sowie Administrationsaufwand reduzieren sich auf die
Server.
- Schutz der Server verhindert Re-Infektionen, z. B. nach dem Einspielen
von archivierten Dateien.
Nachteile:
- Fr die Endgerte mit externen Schnittstellen muss der Benutzer das auf
dem Server befindliche Computer-Viren-Suchprogramm manuell starten,
um damit eingehende externe Datentrger, aber auch zu versendende
Datentrger und Dateien zu berprfen.
- Verschlsselte Dateien oder Programme, die Computer-Viren beinhalten
und erst auf einem ungeschtzten Endgert entschlsselt werden, fhren
ohne Eingangskontrolle zu Infektionen. Dies kann in gleicher Weise auch
fr komprimierte Dateien gelten, wenn das Suchprogramm nicht geeignet
ist.
- Ein Computer-Viren-Befall eines Endgertes mit externen Schnittstellen
kann nicht ausgeschlossen werden.
- Wird zustzlich eine Peer-to-Peer-Funktionalitt genutzt, knnen
Computer-Viren ohne Kontrolle der geschtzten Server zwischen
Endgerten bertragen werden.
- Schlecht fr die Performance, da alle Kommunikationsinhalte berprft
werden mssen.
Computer-Viren-Suchprogramme auf allen Servern und Endgerten
Diese Kombination obiger Strategien bietet den maximalen Schutz, da
Computer-Viren sofort beim Auftreten erkannt werden und nicht ber Server
weiterverteilt werden. Darber hinaus knnen Computer-Viren-
Suchprogramme verschiedener Hersteller eingesetzt werden, um so die
Erkennungsrate fr Computer-Viren zu erhhen.
Vorteile:
- Ein geeignetes, aktuelles und residentes Computer-Viren-Suchprogramm
gewhrleistet einen maximalen Schutz bei gleichzeitig minimalen
Aufwand fr den IT-Benutzer.
- Computer-Viren werden nicht ber Server weiterverteilt.
Nachteile:
- Anschaffungskosten sowie Administrationsaufwand fr jeden Server und
jedes Endgert.
Computer-Viren-Suchprogramme auf den Kommunikationsservern
Computer-Virenschutzprogramme knnen ausschlielich oder zustzlich auf
allen Kommunikationsservern installiert werden, also den IT-Systemen ber
die der Datenaustausch mit externen IT-Systemen luft, z. B. Firewalls oder
Mailserver. Hierdurch sind aber die Endgerte nur dann vor Computer-Viren
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
geschtzt, wenn diese keine weiteren Schnittstellen wie CD-ROM-Laufwerke

o. . besitzen.
Vorteile:
- Alle Dateien werden am Eingang zum LAN berprft, nicht erst innerhalb.
- Computer-Viren werden nicht ber Server weiterverteilt. Allerdings
knnen sie sich auf den Endgerten weiterverbreiten, wenn zwischen
diesen Dateien direkt (z. B. ber Disketten) ausgetauscht werden.
Nachteile:
- Diese Methode ist fehleranfllig: Attachments an E-Mail werden u. U.
nicht alle erkannt. Hufig wird von solchen Programmen das
Vorhandensein von Attachments nur innerhalb der ersten Zeilen einer Mail
bzw. im Mail-Header berprft. Es kann auch vorkommen, dass das
Verfahren, mit dem das Attachment behandelt wurde (z. B. uuencode) vom
Virensuchprogramm nicht erfasst wird. Dies ist z. B. bei MIME mglich,
es kann zu Problemen kommen, wenn eine oder mehrere mit uuencode
codierte Dateien einfach in den Mailbody eingefgt werden.
- Schlecht fr die Performance, da alle Kommunikationsinhalte berprft
werden mssen.
- Auf allen Kommunikationsservern sollte nur ein minimales Betriebssystem
installiert sein, also nur die ntigsten Dienste (siehe auch M 4.95
Minimales Betriebssystem).
- Um Denial-of-Service-Angriffe zu vermeiden sollte ein Computer-Viren-
Suchprogramm nie auf einer Firewall installiert werden, hchstens auf
einem Proxy.
Datenhygiene und zentrale Prfung von Dateien
Hierbei werden smtliche eingehenden und ausgehenden Dateien und
Datentrger an zentraler Stelle durch ein Computer-Viren-Suchprogramm
kontrolliert. Darber hinaus wird geregelt, dass die IT-Benutzer keine Dateien,
Programme und Datentrger aus zweifelhafter Herkunft verwenden.
Vorteile:
- Die Anzahl der zu beschaffenden Lizenzen fr Computer-Viren-
Suchprogramme reduziert sich erheblich.
Nachteile:
- Bei hufigen Einsatz externer Datentrger nimmt eine zentrale Prfung auf
Computer-Viren sehr viel Zeit in Anspruch und verzgert den
Geschftsablauf. Ein Computer-Virenbefall kann grundstzlich nicht
ausgeschlossen werden, da ggf. die Prfung eines Datentrgers
versehentlich vergessen werden kann.
- In regelmigen Zeitabstnden mssen alle Rechner ohne Computer-
Viren-Suchprogramm auf einen mglichen Computer-Viren-Befall
untersucht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Unabhngig davon, welche Strategie fr den Computer-Virenschutz gewhlt

wird, verbleibt immer das Restrisiko, dass Computer-Viren-Suchprogramme
nur diejenigen Computer-Viren erkennen, die zum Entwicklungszeitpunkt des
Programms bekannt waren. Das heit, dass neue Viren ggf. nicht erkannt
werden und Schden anrichten knnen.
Die Wahl der richtigen und unter Kostengesichtspunkten angemessenen
Strategie ist von der jeweiligen IT-Landschaft abhngig. Da jedoch beim Kauf
von Mehrfach-Lizenzen der gngigen, geeigneten Computer-Viren-
Suchprogramme sich meist die Kosten pro Lizenz stark reduzieren, empfiehlt
es sich, ber eine Komplettausstattung aller Server und Endgerte
nachzudenken.
- Sind in der Vergangenheit Computer-Viren aufgetreten? Welche Schden
wurden verursacht (finanzielle Einbuen, Arbeitsausfall, ...)?
- Wird die Entscheidung ber den Ressourceneinsatz fr den Computer-
Virenschutz vom Management getragen?
- Ist sichergestellt, dass bei nderungen der IT-Landschaft ber eine
Anpassung der Computer-Virenschutz-Strategie nachgedacht wird?
- Wurden die mit der gewhlten Strategie verbundenen Nachteile dem IT-
Sicherheitsmanagement verdeutlicht?
- Werden die entstehenden Restrisiken getragen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.157 Auswahl eines geeigneten Computer-Viren-

Suchprogramms
Bundesbehrden erhalten ber das BSI aktuelle Viren-Schutzprogramme.
Benutzer aus anderen Bereichen mssen aus der Vielzahl der am Markt
verfgbaren Computer-Viren-Schutzprogramme fr sie geeignete auswhlen.
Fr die ITSEC, den Kriterien fr die Bewertung der Sicherheit von Systemen
der Informationstechnik, wurde eine Funktionalittsklasse fr Anti-Virus-
Produkte (F-AVIR) entwickelt. Auf diese kann bei der Auswahl eines
geeigneten Viren-Suchprogramms zurckgegriffen werden.
In dieser Funktionalittsklasse werden Sicherheitsfunktionen sowie
Voraussetzungen fr die sichere Arbeitsumgebung von Anti-Virus-Produkten
beschrieben, die als Kriterien fr die Auswahl eines geeigneten Computer-
Viren-Suchprogramms herangezogen werden sollten.
Band 2 der BSI-Schriftenreihe zur IT-Sicherheit "Informationen zu Computer-
Viren" enthlt einen Abdruck dieser Funktionalittsklasse. Als Hilfsmittel
wurde der entsprechende Auszug der CD-ROM zum IT-Grundschutz-
handbuch beigefgt.
Im wesentlichen sollten folgende Bedingungen vom auszuwhlenden
Computer-Viren-Suchprogramm erfllt werden:
- Der Umfang der erkannten Computer-Viren sollte mglichst gro sein und
dem aktuell bekannten Bestand entsprechen, insbesondere mssen alle sehr
stark verbreiteten Computer-Viren erkannt werden.
- Eine stndige Aktualisierung bezglich neuer Computer-Viren muss vom
Hersteller sichergestellt sein.
- Das Programm sollte Computer-Viren auch in komprimierter Form finden,
wobei gngige Komprimierungsfunktionen wie PKZIP untersttzt werden
sollten.
- Gefundene Computer-Viren mssen mit einer vollstndigen Pfadangabe
angezeigt werden.
- Das Programm muss seine eigene Virenfreiheit feststellen, bevor die
Suchfunktion ausgefhrt wird.
- Nach Mglichkeit muss das Produkt als residentes Programm eine
permanente Computer-Virenkontrolle ermglichen.
- Sinnvoll ist eine Funktionalitt, die es erlaubt, erkannte Computer-Viren zu
entfernen, ohne weitere Schden an Programmen oder Daten zu
verursachen.
- Das Programm sollte ber eine Protokollierungsfunktion verfgen, die
folgende Daten festhlt:
- Versionsstand des Programms,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Datum und Uhrzeit der berprfung,

- Angabe aller benutzten Parameter,
- Prfergebnis mit Prfumfang,
- Anzahl und Identifikation der Dateien und Objekte, die nicht geprft
werden konnten.
- Das Programm sollte eine Warnung ausgeben, wenn es feststellt, dass es
offensichtlich nicht aktualisiert wurde (zwischen Aktualittsstand des
Programms und Systemdatum liegen mehr als 6 Monate).
- Das Programm sollte eine Liste der erkennbaren Computer-Viren und ihre
Beschreibung beinhalten. Darber hinaus sind jeweils Beschreibungen von
Sofortmanahmen und Manahmen zum Entfernen des Computer-Virus
anzugeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.158 Meldung von Computer-Virusinfektionen

Bei Auftreten eines Computer-Virus muss vorrangig verhindert werden, dass
weitere IT-Systeme infiziert werden. Hierzu sollte ein Ansprechpartner in der
Institution benannt werden, dem unverzglich eine Computer-Virusinfektion
gemeldet wird. Dieser kann auf der Basis der gem M 2.155 Identifikation
potentiell von Computer-Viren betroffener IT-Systeme erstellten Unterlagen
sofort entscheiden, welche Benutzer ggf. ber das Auftreten eines Computer-
Virus zu informieren sind. Diese Alarmierungswege sind ebenfalls im
Rahmen dieses Meldewesens zu etablieren.
Neben den eigenen Mitarbeitern mssen auch alle Externen benachrichtigt
werden, die eventuell durch die Virusinfektion mitbetroffen sind. Hierzu
gehren insbesondere diejenigen, die mutmalich den Virus weitergegeben
oder erhalten haben.
Fr einen berblick ber die aktuelle Bedrohungslage durch Computer-Viren
fhrt das BSI eine Statistik ber alle aufgetretenen Viren-Infektionen. Dazu
wurde ein Virus-Meldebogen herausgegeben, mit dem ein Viren-Vorfall
erfasst wird. Diese Virus-Meldung wird vom BSI nur zu statistischen
Zwecken verwendet; sie kann auch anonym abgegeben werden (Vordruck
befindet sich im Anhang).
ber die benannten Ansprechpartner sind dann schlielich auch die Manah-
men einzuleiten, die zu der Beseitigung des festgestellten Computer-Viren-
befalls fhren. Diese sollten alle Infektionen mit Computer-Viren, deren
Auswirkungen und deren Beseitigung dokumentieren. Diese Informationen
bilden eine Grundlage fr die Aktualisierung des Virenschutzkonzeptes und
dokumentieren aufgetretene Schadensflle und die Aufwnde zu deren
Behebung.
Fr die Einrichtung des Meldewesens ist es erforderlich, dass allen Mitar-
beitern in geeigneter Form der Ansprechpartner bekannt gegeben wird. Dies
kann beispielsweise in Form eines Merkblattes erfolgen (vgl. M 6.23
Verhaltensregeln bei Auftreten eines Computer-Virus). Insbesondere beim
Auftreten von Hoax (siehe G 5.80 Hoax) ist es wichtig, dass die Benutzer
diese angeblichen Sicherheitshinweise nur an den fr Virenproblematik
benannten Ansprechpartner weitergeben und diesen nicht weiter streuen.
In gleicher Weise muss dieser Ansprechpartner sich regelmig ber neu
aufgetretene Computer-Viren informieren, damit er im Bedarfsfall eine
Aktualisierung der Computer-Viren-Suchprogramme oder eine Alarmierung
der Betroffenen veranlassen kann.
- Ist sichergestellt, dass der Ansprechpartner fr Computer-Virusinfektionen
allen IT-Benutzern bekannt ist?
- Ist sichergestellt, dass der Ansprechpartner schnellstmglich smtliche
potentiell von einem akuten Computer-Virus Betroffenen alarmieren kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.159 Aktualisierung der eingesetzten Computer-

Viren-Suchprogramme
Fr die mit Computer-Viren-Suchprogrammen ausgestatteten IT-Systeme
muss eine regelmige Aktualisierung des Programms erfolgen, damit neu
aufgetretene Computer-Viren zuverlssig erkannt werden knnen. Hierzu ist
die Festlegung einer Vorgehensweise hinsichtlich der Verantwortlichkeit, der
Beschaffung und der Verteilung der Updates erforderlich.
Bereits bei der Beschaffung eines geeigneten Computer-Viren-Suchpro-
gramms (siehe M 2.157 Auswahl eines geeigneten Computer-Viren-
Suchprogramms) sollte darauf geachtet werden, dass es in kurzen Zeit-
abstnden (maximal halbes Jahr) aktualisiert wird. Da Virensuchprogrammen
auch zu gegebenen Anlssen, z. B. aufgrund neuer Viren, aktualisiert werden,
sollte der fr die Virenproblematik Verantwortliche regelmig (zumindest
wchentlich) die Informationen des Herstellers abfragen.
Das BSI hat fr den Bereich der Bundesbehrden eine Mailingliste fr die
Bekmpfung von Computer-Viren aufgebaut. ber diese Adressen-Liste
werden aktuelle Informationen zur Viren-Problematik verteilt. Bei akuter
Virengefahr wird in Zukunft eine Virenwarnung ausgegeben. Auerdem
werden ber diesen Weg Extra-Treiber fr neue, bisher nicht erkannte Viren
verteilt. In diese Mailingliste knnen Mitarbeiter von Behrden ber das
IVBB-Intranet unter http://www.bsi.ivbb.bund.de/antivir/mailing.htm oder
ber eine formlose E-Mail an antivir@bsi.de aufgenommen werden.
Bei der Verteilung der Updates des Viren-Suchprogramms muss auch sicher-
gestellt werden, dass das Update auch tatschlich - zeitnah mit der Beschaf-
fung des Updates - auf den IT-Systemen eingespielt wird. Sofern dies nicht
automatisiert (bei vernetzten IT-Systemen) erfolgen kann, sollte das Update
den entsprechenden IT-Benutzern schnell zur Verfgung gestellt werden.
Durch die hufige Aktualisierung und die dadurch geringen Testzeiten der
Virensuchprogramme sind diese fehleranfllig und mssen vor der Freigabe
bzw. Installation im Wirkbetrieb getestet werden (siehe auch M 2.83 Testen
von Standardsoftware). Bei der Installation von Updates ist insbesondere
darauf zu achten, dass durch voreingestellte Parameter die bestehende Konfi-
guration des Computer-Viren-Suchprogramms nicht verndert wird. So knnte
beispielsweise durch ein Update ein zuvor residentes Computer-Viren-
Suchprogramm in einen Offline-Modus geschaltet werden.
Auerdem ist sicherzustellen, dass Rechner, die keiner einzelnen Person zuge-
ordnet sind und nicht vernetzt sind, zum Beispiel Laptops, ebenfalls mit
Updates versorgt werden.
- Wurden die fr die Verteilung der Updates erzeugten Duplikate auf einem
nachgewiesenermaen nicht infiziertem IT-System erzeugt?
- Wie lange dauert die Einspielung eines Updates fr alle IT-Systeme?
- Wird sporadisch berprft, ob Aktualisierungen durchgefhrt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.160 Regelungen zum Computer-Virenschutz

Um einen effektiven Computer-Virenschutz zu erreichen, mssen ber den
Einsatz von Computer-Viren-Suchprogrammen hinaus einige zustzliche
Manahmen realisiert werden. In diesem Sinne sind unter anderem folgende
Punkte zu regeln:
Einsatz von Computer-Viren-Suchprogrammen
Entsprechend der ausgewhlten Strategie und des ausgewhlten Produktes ist
der Einsatz festzulegen und zu dokumentieren (vgl. M 2.156 Auswahl einer
geeigneten Computer-Virenschutz-Strategie, M 2.157 Auswahl eines
geeigneten Computer-Viren-Suchprogramms). Darber hinaus ist zu regeln,
wie, in welchen Abstnden und durch wen die Computer-Viren-
Suchprogramme aktualisiert werden (vgl. M 2.159 Aktualisierung der
eingesetzten Computer-Viren-Suchprogramme).
Schulung der IT-Benutzer
Die betroffenen IT-Benutzer sind bezglich der Gefahren durch Computer-
Viren, Makro-Viren, Trojanische Pferde und Hoax (vgl. G 5.23 Computer-
Viren, G 5.43 Makro-Viren, G 5.21 Trojanische Pferde, G 5.80 Hoax), der
notwendigen IT-Sicherheitsmanahmen, der Verhaltensweise beim Auftreten
von Computer-Viren und im Umgang mit dem Computer-Viren-Such-
programm zu informieren bzw. zu schulen (vgl. M 3.5 Schulung zu IT-
Sicherheitsmanahmen, M 3.4 Schulung vor Programmnutzung, M 6.23
Verhaltensregeln bei Auftreten eines Computer-Virus).
Verbot der Nutzung nicht freigegebener Software
Die Installation und Nutzung nicht freigegebener, insbesondere nicht viren-
kontrollierter Software ist zu verbieten (vgl. M 2.9 Nutzungsverbot nicht
freigegebener Hard- und Software). Darber hinaus ist ggf. zu regeln, dass
regelmig Prfungen auf Einhaltung des Verbots durchgefhrt werden (vgl.
M 2.10 berprfung des Hard- und Software-Bestandes).
Schutzmanahmen am IT-System
Die Boot-Reihenfolge beim Betriebssystemstart ist so umzustellen, dass gene-
rell zuerst von der Festplatte (oder vom Netz) und dann erst von einem exter-
nen Medium (Diskette, CD-ROM) gestartet wird (vgl. M 4.84 Nutzung der
BIOS-Sicherheitsmechanismen). Zustzlich ist fr jeden vorhandenen
Rechnertyp eine Notfalldiskette anzulegen, um im Falle einer Computer-
Vireninfektion eine erfolgreiche Suberung zu ermglichen (vgl. M 6.24
Erstellen einer PC-Notfalldiskette). Fr den Fall, dass ein neuer Computer-
Virus dennoch Schden verursacht, muss auf eine Datensicherung
zurckgegriffen werden. Es sind daher regelmig Datensicherungen
anzulegen (vgl. M 6.32 Regelmige Datensicherung). Beim
Wiedereinspielen von Datensicherungen muss darauf geachtet werden, dass
damit keine vom Computer-Virus befallenen Dateien wiederaufgespielt
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Manahmen bei nicht-resident virenkontrollierter IT-Systeme

Auf IT-Systemen, auf denen kein residentes Computer-Viren-Suchprogramm
installiert worden ist, sind ersatzweise ein regelmiger Einsatz eines Compu-
ter-Viren-Suchprogramms (vgl. M 4.3 Regelmiger Einsatz eines Viren-
Suchprogramms), eine Virenkontrolle bei Datentrgeraustausch und Daten-
bertragung (vgl. M 4.33 Einsatz eines Viren-Suchprogramms bei
Datentrgeraustausch und Datenbertragung) sowie eine Makro-
Virenprfung bei eingehenden Dateien (vgl. M 4.44 Prfung eingehender
Dateien auf Makro-Viren) festzulegen, um eine rasche Erkennung und
Verhinderung der Weiterverbreitung von Computer-Viren sicherzustellen.
Meldung von Computer-Viren
Es ist zu regeln, an wen ein entdeckter Computer-Virus unverzglich zu
melden ist. Die Form der Meldung (Formblatt) und der bermittlungsweg
(telefonisch, persnlich, schriftlich, E-Mail) ist ebenfalls zu reglementieren
(siehe M 2.158 Meldung von Computer-Virusinfektionen).
Regelung der Verantwortlichkeiten
Die Aufgaben, Kompetenzen und Verantwortlichkeiten fr den Computer-
Virenschutz sind zu regeln fr
- den Ansprechpartner fr Computer-Viren,
- den Administrator von Netzservern,
- den IT-Benutzer von Endgerten und
- das IT-Sicherheitsmanagement.
Aktualisierung des Computer-Virenschutzkonzeptes
Bei nderungen an IT-Systemen, bei Installation neuer IT-Systeme und bei
nderungen der Vernetzung ist das Computer-Virenschutzkonzept zu aktua-
lisieren und anzupassen (vgl. M 2.34 Dokumentation der Vernderungen an
einem bestehenden System).
Diese Regelungen sind den Betroffenen zur Kenntnis zu geben. Die ber-
prfung der Einhaltung dieser Regelungen sollte sporadisch erfolgen, um ein
durchgngig umgesetztes Computer-Virenschutzkonzept sicherzustellen.
- Wann wurde die letzte berprfung vorgenommen? Wurde das Ergebnis
dokumentiert?
- Wie werden Betroffene ber die relevanten Regelungen unterrichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.161 Entwicklung eines Kryptokonzepts

Unternehmen und Behrden sind mittlerweile zunehmend von ihrer informa-
tionstechnischen Infrastruktur abhngig. Aus diesem Grund sind Sicherheits-
dienste erforderlich und in ein Gesamtsystem zu integrieren, die ber die
bloe Verschlsselung hinausgehen.
Aufgrund der Vielfalt kryptographischer Problemstellungen und unterschied-
licher Einflussfaktoren gibt es auch vielfltige Lsungsanstze und Reali-
sierungsmglichkeiten. Man kann nicht davon ausgehen, dass es eine Lsung
gibt, die alle Sicherheitsprobleme in Rechnernetzen und/oder Kommuni-
kationssystemen beseitigen kann. Vielmehr kommt es auf ein abgestimmtes
Zusammenspiel passend ausgewhlter Komponenten an, um den bentigten
Grad an Sicherheit zu erreichen. Daher ist es erforderlich, ein Kryptokonzept
zu entwickeln, das in das IT-Sicherheitskonzept der Behrde bzw. des Unter-
nehmens integriert wird.
Die Auswahl geeigneter kryptographischer Komponenten muss dabei auf
diesem Konzept basieren. Dabei ist das Schlsselmanagement ein kritisches
Element im gesamten Kryptokonzept. Konzepte und Lsungsanstze knnen
nur dann erfolgreich erarbeitet und gezielt umgesetzt werden, wenn deutlich
wird, welche speziellen Sicherheitsfunktionalitten bzw. Sicherheitsdienste
bentigt werden. Darber hinaus gibt es eine Reihe systemrelevanter Frage-
stellungen und Aspekte, die nicht speziell in den Bereich der Sicherheits-
technik fallen. Dies umfasst z. B. Performanceanforderungen, System-
anbindungs- oder Interoperabilitts- und Standardkonformittsanforderungen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
In vernetzten IT-Infrastrukturen ist es nicht mehr ausreichend, die Sicherheit

einer einzelnen Domne zu gewhrleisten. Vielmehr muss die Sicherheit aller
beteiligten Endeinrichtungen und bertragungssysteme aufeinander abge-
stimmt werden. Diese Abstimmung gestaltet sich insbesondere in solchen
Fllen als besonders schwierig, in denen es sich nicht nur um vernetzte
Einrichtungen innerhalb einer organisatorischen Einheit (z. B. LAN-Umge-
bung), sondern um einen Verbund von IT-Installationen unterschiedlicher
Zustndigkeits- und Anwendungsbereiche handelt.
Der Einsatz - aber auch die Funktionalitt und technologische Ausgestaltung -
eines IT-Sicherheitssystems wird von zahlreichen Einflussfaktoren bestimmt,
wie z. B. Lokalisierung, Sicherheitsniveau, Hufigkeit und Umfang der
Anwendung, die fr das IT-Sicherheitsmanagement wichtige Rahmen- und
Entscheidungsbedingungen darstellen. Des weiteren sind die technischen
Mglichkeiten fr die Realisierung und Gestaltung eines
IT-Sicherheitssystems vielfltig, z. B. integriert in einer Applikation auf dem
Arbeitsplatzrechner, in einer Firewall oder als Spezialkomponente fr
Netzkomponenten wie Switch oder Router. Ein erschwingliches Preisniveau
fr ein Kryptoprodukt ist nur durch eine querschnittliche Nutzbarkeit zu
erzielen. Hier spielen z. B. eine standardisierte Systemanbindung, einheitliche
Einsatzbedingungen etc. eine wichtige Rolle. Ein letzter Punkt betrifft das
Zusammenwirken der Sicherheitsdienste auf unterschiedlichen
Protokollschichten. Die Sicherheitsdienste der hheren Protokollschichten
(nach OSI-Referenzmodell) schtzen in aller Regel nur dann ausreichend,
wenn die unteren Schichten ebenso einen Schutz bieten (siehe M 4.90 Einsatz
von kryptographischen Verfahren auf den verschiedenen Schichten des
ISO/OSI-Referenzmodells).
Des weiteren ist die Definition einer organisationseigenen Kryptopolitik
wichtig. Dabei muss aus Sicht des Managements geklrt werden,
- welcher Schutzbedarf besteht bzw. welches Sicherheitsniveau es zu errei-
chen gilt,
- welches Budget und wieviel Personal zur Verfgung stehen, um die
geplanten Sicherheitsmechanismen einzurichten und - ganz wichtig - auch
den Betrieb zu gewhrleisten,
- welche Systemanbindung angestrebt wird bzw. welche Einsatzbedingun-
gen fr Sicherheitskomponenten vorherrschen,
- welcher Funktions- und Leistungsumfang anzupeilen ist und
- wer letztendlich die Verantwortung bernimmt.
Im Kryptokonzept ist auerdem der technische bzw. organisatorische Einsatz
der kryptographischen Produkte zu beschreiben, also z. B.
- wer welche Zugriffsrechte erhlt,
- welche Dienste remote angeboten werden,
- wie die Verwaltung von Passwrtern und Schlsseln bezglich Gltig-
keitsdauer, Verwendung von Zeichen, Lnge, Vergabe gehandhabt werden
soll,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- ob, wann und wie die Daten verschlsselt oder signiert werden mssen,
- wer mit wem kryptographisch gesichert bzw. ungesichert kommunizieren
darf,
- wer bestimmte Rechte vergeben darf, u.s.w.
In Abhngigkeit von den systemtechnischen Rahmenbedingungen bezglich
- des zu betrachtenden Datenvolumens und der Zeitabhngigkeit,
- der Verfgbarkeitsanforderungen und Gefhrdungslage,
- Art und Hufigkeit der zu schtzenden Anwendungen etc.
knnen darauf basierend geeignete Realisierungsmglichkeiten analysiert und
fr konkrete Einsatzbereiche wie z. B. einen PC-Arbeitsplatz, im LAN-
Bereich oder in Verbindung mit einer TK-Anlage konzipiert und technisch
ausgestaltet werden. Nur aufgrund einer solch ganzheitlichen Betrachtungs-
weise gelingt es, Entscheidungsgrundlagen und -bedingungen fr kryptogra-
phische Produkte zusammenzutragen, deren Einsatz bzw. Verwendung sowohl
sicherheitstechnisch angemessen als auch wirtschaftlich vertretbar ist. Es
sollte jedoch darauf hingewiesen werden, dass die vorgenommene Einteilung
keinesfalls zwingend oder von grundstzlicher Bedeutung, sondern bestenfalls
hilfreich ist. Wesentlich ist nur, dass der Fragenumfang die Vorstellung nach
einer mglichst umfassenden Klrung der Ausgangslage konsequent wider-
spiegelt. Natrlich ergeben sich in der Praxis zwischen einigen Frage-
stellungen bzw. Antworten Wechselwirkungen und Abhngigkeiten, die im
allgemeinen allerdings zur Vervollstndigung des Gesamtbildes beitragen.
Die diversen Einflussgren fr den Einsatz kryptographischer Verfahren sind
zu bestimmen und nachvollziehbar zu dokumentieren (siehe M 2.163
Erhebung der Einflussfaktoren fr kryptographische Verfahren und Produkte).
Anschlieend muss eine geeignete Verfahrensweise fr ihren Einsatz ent-
wickelt und dokumentiert werden. Zum Abschluss muss durch die Behrden-
bzw. Unternehmensleitung die Durchfhrung angeordnet werden.
Die Ergebnisse sollten aktualisierbar und erweiterbar im Kryptokonzept
niedergelegt werden. Ein mglicher Aufbau eines Kryptokonzepts ist im
nachfolgenden Inhaltsverzeichnis beispielhaft aufgezeigt:
Inhaltsverzeichnis Kryptokonzept
1. Definitionen
- Kryptographische Verfahren
- ...
2. Gefhrdungslage zur Motivation
- Abhngigkeit der Institution vom Datenbestand
- Typische Gefhrdungen wie ...
- Institutionsrelevante Schadensursachen
- Schadensflle im eigenen Haus
3. Festlegung einer organisationsinternen Sicherheitspolitik
- Festlegung von Verantwortlichkeiten
- Zielsetzung, Sicherheitsniveau
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. Einflussfaktoren
- Identifikation der zu schtzenden Daten
- Vertraulichkeitsbedarf der Daten
- Integrittsbedarf der Daten
- Verfgbarkeitsanforderungen an die Daten
- Anforderungen an die Performance
- Schlsselverteilung
- Datenvolumen
- Art der Daten (lokal / verteilt (LAN/WAN) )
- Art der Anwendungen, bei denen kryptographische Verfahren zum Einsatz
kommen sollen
- Hufigkeit des Einsatzes des kryptographischen Verfahrens
- Anforderungen an die Widerstandsfhigkeit der Algorithmen bzw. Verfah-
ren (Manipulationsresistenz)
- Wiederherstellbarkeit der gesicherten Daten
- Personalaufwand
- Erforderliche Funktionalitt
- Kosten einschlielich Folgekosten (Wartung, Administration, Updates, ...)
- Kenntnisse/datenverarbeitungsspezifische Qualifikationen der IT-Benutzer
5.Festlegung des Einsatzes
- Art der kryptographischen Verfahren
- Einsatzbedingungen an die kryptographischen Produkte
- Hufigkeit und Zeitpunkt des Einsatzes
- Benennung der Verantwortlichen
- Festlegung der organisatorischen Regelungen
- Durchfhrung der personellen Manahmen (Schulung, Vertretungs-
regelungen, Verpflichtungen, Rollenzuteilung)
- Dokumentation der Einsatzbedingungen / Konfiguration
- Interoperabilitt, Standardkonformitt, Investitionsschutz
6. Schlsselmanagement
Einzelne Punkte dieses Konzepts werden in den Manahmen M 2.162
Bedarfserhebung fr den Einsatz kryptographischer Verfahren und Produkte,
M 2.163 Erhebung der Einflussfaktoren fr kryptographische Verfahren und
Produkte, M 2.166 Regelung des Einsatzes von Kryptomodulen etc. nher
ausgefhrt.
Bei der Erstellung eines Kryptokonzepts handelt es sich nicht um eine ein-
malige Aufgabe, sondern um einen dynamischen Prozess. Ein Kryptokonzept
muss daher regelmig den aktuellen Gegebenheiten angepasst werden.
- Ist das vorliegende Konzept aktuell?
- Sind smtliche betroffenen IT-Systeme in diesem Konzept aufgefhrt?
- Wie werden Mitarbeiter ber den sie betreffenden Teil des Konzepts
unterrichtet?
- Wird die Einhaltung dieses Konzepts kontrolliert?
- Wie werden nderungen der Einflussfaktoren bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.162 Bedarfserhebung fr den Einsatz

kryptographischer Verfahren und Produkte
IT-Anwendungen
Um bei der Verarbeitung und bertragung sensitiver Informationen zu rea-
listischen, verlsslichen und anwendungsgerechten Bedarfsanforderungen und
Rahmenbedingungen fr den Einsatz kryptographischer Verfahren und Pro-
dukte zu kommen, mssen zunchst die schtzenswerten Daten identifiziert
und bewertet werden.
Identifikation der zu schtzenden Daten
Zunchst muss festgestellt werden, fr welche Aufgaben kryptographische
Verfahren eingesetzt werden sollen und welche Daten damit gesichert werden
sollen. Der Einsatz kryptographischer Verfahren kann aus verschiedenen
Grnden erforderlich sein (siehe auch M 3.23 Einfhrung in kryptographische
Grundbegriffe):
- zum Schutz der Vertraulichkeit bzw. der Integritt von Daten,
- zur Authentisierung,
- fr Sende- oder Empfangsnachweise.
Je nach Einsatzzweck knnen verschiedene kryptographische Methoden wie
z. B. Verschlsselung oder Hashverfahren sinnvoll sein. Die typischen Ein-
satzfelder fr kryptographische Verfahren sind:
1. lokale Verschlsselung,
2. Kommunikationssicherung, auf Anwendungsebene bzw. auf ber-
tragungsebene,
3. Authentikation,
4. Nichtabstreitbarkeit,
5. Integritt.
Im folgenden werden einige Beispiele aus den verschiedenen typischen Ein-
satzfeldern fr kryptographische Verfahren gegeben:
- Auf einer PC-Festplatte befinden sich Daten, die vor unbefugtem Zugriff
durch Verschlsselung geschtzt werden sollen.
- Es sollen Informationen ber Telefon, Fax oder Datennetze weitergegeben
werden, z. B. sollen sie per E-Mail oder per Datentrgeraustausch versandt
werden.
- Die zu schtzenden Informationen sind nicht unter alleiniger Kontrolle der
verantwortlichen Organisationseinheit (LAN fhrt durch Gebudeteile, die
von Fremdfirmen benutzt werden; ein Server mit Personaldaten wird durch
Mitarbeiter betreut, die nicht zum Personalreferat gehren).
- Remote-Zugriffe sollen durch eine starke Authentisierung abgesichert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Bei E-Mails soll zweifelsfrei feststellbar sein, wer die Absender waren und
ob die Inhalte unverndert bertragen wurden.
Um festzustellen, welche kryptographischen Verfahren bzw. Produkte ben-
tigt werden und welche Daten damit zu schtzen sind, sollte zunchst die
aktuelle IT-Struktur ermittelt werden (siehe zur Erfassung von IT-Systemen
und Anwendungen auch Kapitel 2). Ermittelt werden sollte,
- welche IT-Systeme es gibt, auf denen Daten verarbeitet bzw. gespeichert
(PCs, Laptops, Server, ...) oder mit denen Daten bermittelt werden
(Bridge, Router, Gateway, Firewall, ...) und
- welche bertragungswege es gibt. Dazu sollte die logische und physi-
kalische Vernetzungsstruktur erfasst werden (siehe auch M 2.139 Ist-
Aufnahme der aktuellen Netzsituation).
Schutzbedarf der Daten (Vertraulichkeit, Integritt, Authentizitt,
Nichtabstreitbarkeit)
Es sollten alle Anwendungen bzw. Daten ermittelt werden, bei denen ein
besonderer Anspruch an Vertraulichkeit, Integritt, Authentizitt bzw.
Nichtabstreitbarkeit besteht (siehe Kapitel 2). Allerdings werden nicht nur fr
IT-Systeme, Anwendungen oder Informationen mit hherem Schutzbedarf
kryptographische Produkte bentigt, sondern auch fr solche mit mittlerem
Schutzbedarf.
Beispiele fr Daten mit besonderem Vertraulichkeitssanspruch sind
- personenbezogene Daten,
- Passwrter und kryptographische Schlssel,
- vertrauliche Informationen, deren Verffentlichung Regressforderungen
nach sich ziehen knnte,
- Daten, aus denen ein Konkurrenzunternehmen finanzielle Gewinne ziehen
knnte,
- Daten, ohne deren Vertraulichkeit die Aufgabenerfllung gefhrdet ist
(z. B. Ermittlungsergebnisse, Standortregister ber gefhrdete Pflanzen),
- Daten, deren Verffentlichung eine Rufschdigung verursachen knnte.
Hinweis: Durch die Kumulation von Daten erhht sich der Schutzbedarf einer
Datensammlung, so dass eine Verschlsselung erforderlich sein kann, auch
wenn deren einzelne Datenstze nicht so sensitiv sind.
Beispiele fr Daten mit besonderem Integrittsanspruch sind
- finanzwirksame Daten, durch deren Manipulation finanzielle Schden
entstehen knnen,
- Informationen, deren verflschte Verffentlichung Regressforderungen
nach sich ziehen knnte,
- Daten, deren Verflschung zu falschen Geschftsentscheidungen fhren
kann,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Daten, deren Verflschung zu einer verminderten Produktqualitt fhren

kann.
Ein Beispiel fr Anwendungen mit besonderem Anspruch an Authentizitt
sind Remote-Zugriffe. Ein Beispiel fr Daten mit besonderem Anspruch an
Nichtabstreitbarkeit sind Bestellungen oder Reservierungen, bei denen der
Besteller identifizierbar sein sollte.
Als Ergebnis der Schutzbedarfsfeststellung sollte festgelegt werden, welche
Anwendungen oder Daten kryptographisch gesichert werden sollen. Diese
Festlegung kann spter noch verfeinert werden und sollte regelmig ber-
arbeitet werden.
Als Resultat ergibt sich somit ein berblick ber alle Speicherorte und ber-
tragungsstrecken, die kryptographisch gesichert werden mssen. Damit erhlt
man praktisch eine IT-Landschaftskarte mit markierten Kryptobereichen.
Bedarfs- und Anforderungsabfrage
Als Hilfsmittel fr eine derartige Bedarfserhebung bietet sich ein Fragen-
katalog mit den in der Abbildung dargestellten Gliederungspunkten an. Dabei
knnen die technischen, organisatorischen und wirtschaftlichen Aspekte
jeweils in 4 weitere Unterkategorien aufgeteilt werden.
Technische Aspekte Organisatorische Wirtschaftliche Aspekte

Aspekte
Benutzerdienste und Einsatzbereich Rationalisierungsaspekte
Anwendungen / Kosteneinsparungen
Nutzungsprofil Migrationskonzept Stckzahlen
Netzinfrastruktur Zeitvorstellungen Beschaffungskosten
IT-Endgert Betriebliche Rahmen- Administrations- und
bedingungen Wartungsaufwendungen
Abb: Gliederungsgesichtspunkte zur Erstellung eines Fragenkataloges
Bei den technischen Aspekten ist es unter "Benutzerdienste und Anwen-

dungen" beispielsweise wichtig zu erfahren, ob vornehmlich Echtzeit- oder
Nicht-Echtzeit-Daten betrachtet werden. In der Kategorie Nutzungsprofil ist
zu erfragen, fr welche Anwendungen und Daten kryptographische Verfahren
eingesetzt werden sollen, z. B. fr die externe Kommunikation oder fr die
kurzzeitige oder lngerfristige Bearbeitung von VS-Daten. Weiterhin sind die
Netzinfrastruktur und das Endgert betreffende Informationen zu ermitteln,
wie z. B. Anschlusskonfiguration.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Als organisatorische Aspekte sind der Einsatzbereich, d. h. Teilnehmer- oder

Netzbereich; die Frage nach einem existierenden Migrationskonzept sowie die
Zeitvorstellungen und betrieblichen Rahmenbedingungen des Endbenutzers zu
betrachten.
Aus wirtschaftlicher Sicht sind die wesentlichen Punkte:
- Rationalisierungsaspekte, z. B. durch Einsatz eines Produktes mit trans-
parenter Verschlsselung statt manueller Ansteuerung,
- eine Abschtzung im Hinblick auf Stckzahlen und Beschaffungskosten
sowie
- die zu erwartenden Administrations- und Wartungskosten.
Auf Basis dieser Abfrage kann ein mglichst praxisnahes Einsatz- und
Anforderungskonzept erstellt werden, was dann als Ausgangspunkt fr kon-
krete Realisierungsentscheidungen bzw. die Auswahl geeigneter Krypto-
komponenten/-produkte (siehe M 2.165 Auswahl eines geeigneten
kryptographischen Produktes) dient.
Die hier vorgestellte Vorgehensweise soll dem Sicherheitsverantwortlichen
helfen, den Einsatz und den Umfang einzusetzender Sicherheitstechnik in
unterschiedlichen Systemlokalitten, Netzbergngen und Endeinrichtungen
festzustellen, zu bewerten und zu koordinieren. Ferner soll im Verlauf der
Planungsphase durch die Ermittlung des notwendigen Schutzes (Schutzbedarf)
die Frage nach Angemessenheit der IT-Sicherheit beantwortet werden. Die
skizzierte Vorgehensweise stellt einen pragmatischen Ansatz dar und
bercksichtigt Sicherheitsaspekte in offenen, verteilten IT-Infrastrukturen, so
wie sie sich vielerorts darstellen.
Die so betrachteten Sicherheitsinvestitionen mssen fr den betroffenen Ein-
satzbereich wirtschaftlich vertretbar sein. Die Funktions- und Betriebsweise
von realisierten Sicherheitsstrategien mssen den Erwartungen der End-
benutzer hinsichtlich der Flexibilitt, Transparenz und Performance Rechnung
tragen. Die geplanten und integrierten Sicherheitsdienste drfen den
Endbenutzer nicht ber das notwendige Ma hinaus einschrnken.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.163 Erhebung der Einflussfaktoren fr

kryptographische Verfahren und Produkte
IT-Anwendungen
Bevor eine Entscheidung getroffen werden kann, welche kryptographischen
Verfahren und Produkte eingesetzt werden sollen, mssen eine Reihe von
Einflussfaktoren ermittelt werden. Dazu knnen die Systemadministratoren
und die Verantwortlichen der einzelnen IT-Systeme bzw. IT-Anwendungen
befragt werden. Die Ergebnisse sind nachvollziehbar zu dokumentieren.
Fr smtliche in M 2.162 Bedarfserhebung fr den Einsatz kryptographischer
Verfahren und Produkte festgelegten Speicherorte und bertragungsstrecken
sind folgende Einflussfaktoren zu ermitteln:
Sicherheitsaspekte
- Welcher Schutzbedarf besteht bzw. welches Sicherheitsniveau gilt es zu
erreichen?
- Welche kryptographischen Funktionen sind dafr notwendig
(Verschlsselung, Integrittsschutz, Authentizitt und/oder Nichtabstreit-
barkeit)?
- Angreiferpotential: Mit welchen Angreifern wird gerechnet (zeitliche und
finanzielle Ressourcen, technische Fhigkeiten)?
Die Antworten auf diese Fragen ergeben sich aus M 2.162 Bedarfserhebung
fr den Einsatz kryptographischer Verfahren und Produkte.
Technische Aspekte
Der Betrieb von weitverzweigten IT-Infrastrukturen mit ihrer Vielzahl von
Einzelkomponenten und Spezialeinrichtungen (Netzknoten, Server, Daten-
banken, etc.) macht ein ebenfalls weit verzweigtes Sicherheitssystem mit meh-
reren Funktionseinheiten (Sicherheitsmanagement, Sicherheitsserver, Sicher-
heitsanwenderkomponente, etc.) erforderlich. In der Regel mssen dabei
Systembetrachtungen angestellt werden, die nicht nur auf die eigentlichen
Funktionalitten abzielen, sondern auch bauliche und organisatorische
Aspekte einbeziehen. Auch in bezug auf die konkrete technische Platzierung
von Sicherheitskomponenten sowie deren Integration in Nicht-Sicherheits-
komponenten gilt es zu differenzieren, da dies einen unmittelbaren Einfluss
auf die Implementierung der Sicherheitsfunktionen, auf die notwendige
Untersttzung durch die Betriebssysteme, die Aufwnde und den Kostenfaktor
und nicht zuletzt auf die erreichbare Sicherheit hat. Ganz entscheidend fr die
Sicherheitsbewertung ist der Umstand, an welchen geographischen
Lokalitten und in welchen Ebenen des Protokollstacks die jeweiligen
Sicherheitsdienste realisiert sind und wie diese in die Prozesse des zu
schtzenden IT-Systems eingebunden sind. Somit ergeben sich als Fragen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Umfeldschutz: Welchen Schutz bietet das Umfeld (infrastrukturell

(Zutritt), organisatorisch, personell, technisch (Schutz durch Betriebs-
system, ...))?
- IT-Systemumfeld: Welche Technik wird eingesetzt, welche Betriebs-
systeme, etc.?
- Datenvolumen: Welches Datenvolumen ist zu schtzen?
- Hufigkeit: Wie hufig besteht Kryptierbedarf?
- Performance: Wie schnell mssen kryptographische Funktionen arbeiten
(Offline, Online-Rate)?
Personelle und organisatorische Aspekte
- Benutzerfreundlichkeit: Bentigen die Benutzer fr die Bedienung krypto-
graphische Grundkenntnisse? Behindert der Einsatz eines Kryptoprodukts
die Arbeit?
- Zumutbarkeit: Wie viel Belastung durch zustzliche Arbeit ist dem
Anwender zumutbar (Arbeitszeit, Wartezeit)?
- Zuverlssigkeit: Wie zuverlssig werden die Benutzer mit der Krypto-
technik umgehen?
- Schulungsbedarf: Inwieweit mssen die Benutzer geschult werden?
- Personalbedarf: Ist zustzliches Personal erforderlich, z. B. fr Installation,
Betrieb, Schlsselmanagement?
- Verfgbarkeit: Kann durch den Einsatz eines Kryptoprodukts die Ver-
fgbarkeit reduziert werden?
Wirtschaftliche Aspekte
- Finanzielle Randbedingungen: Wie viel darf der kryptographische Schutz
kosten? Wie hoch sind die
- einmaligen Investitionen,
- laufenden Kosten, inklusive der Personalkosten,
- Lizenzgebhren?
- Investitionsschutz: Sind die geplanten kryptographischen Verfahren bzw.
Produkte konform zu bestehenden Standards? Sind sie interoperabel mit
anderen Produkten?
Key Recovery
Falls die zur Verschlsselung benutzten Schlssel verloren gehen, sind im
allgemeinen auch die damit geschtzten Daten verloren. Viele Kryptoprodukte
bieten daher Funktionen zur Datenwiedergewinnung fr solche Flle an.
Bevor solche Funktionen eingesetzt werden, sollte man sich auch deren
Risiken klar machen: Wenn dadurch vertrauliche Schlssel wiederhergestellt
werden knnen, muss sichergestellt sein, dass dies nur Berechtigte knnen.
Wenn es mglich ist, ohne Wissen des Original-Schlsselbenutzers auf dessen
Daten zuzugreifen, hat dieser keine Mglichkeit, bswillige Manipulationen
zu beweisen. Der Einsatz von Key Recovery Mechanismen fhrt auch hufig
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
aufgrund des entgegengebrachten Misstrauens zu Vorbehalten innerhalb des

eigenen Unternehmens bzw. Behrde, aber auch bei den Kom-
munikationspartnern. Bei der Datenbertragung sollte daher generell auf Key
Recovery verzichtet werden. Hierfr gibt es auch keine Notwendigkeit, da
beim Schlssel- oder Datenverlust diese einfach noch einmal ausgetauscht
werden knnen. Bei der lokalen Speicherung von Daten sollte der Einsatz
sorgfltig berlegt werden (siehe auch M 6.56 Datensicherung bei Einsatz
kryptographischer Verfahren). Auf der CD-ROM zum IT-Grundschutzhand-
buch befindet sich im Verzeichnis Hilfsmittel ein Artikel zu Mglichkeiten
und Risiken des Key-Recovery.
Lebensdauer von kryptographischen Verfahren
Kryptographische Verfahren und Produkte mssen regelmig daraufhin
berprft werden, ob sie noch dem Stand der Technik entsprechen. Die ver-
wendeten Algorithmen knnen durch neue technische Entwicklungen, z. B.
schnellere, billigere IT-Systeme, oder durch neue mathematische Erkenntnisse
zu schwach werden. Die eingesetzten kryptographischen Produkte knnen
Implementierungsfehler aufweisen. Bereits bei der Auswahl krypto-
graphischer Verfahren sollte daher eine zeitliche Grenze fr deren Einsatz
festgelegt werden. Zu diesem Zeitpunkt sollte noch einmal grndlich ber-
dacht werden, ob die eingesetzten Kryptomodule noch den erwarteten Schutz
bieten.
Gesetzliche Rahmenbedingungen
Beim Einsatz kryptographischer Produkte sind diverse gesetzliche Rahmen-
bedingungen zu beachten. In einigen Lndern drfen beispielsweise krypto-
graphische Verfahren nicht ohne Genehmigung eingesetzt werden. Daher
muss untersucht werden (siehe M 2.165 Auswahl eines geeigneten
kryptographischen Produktes),
- ob innerhalb der zum Einsatzgebiet gehrenden Lnder Einschrnkungen
beim Einsatz kryptographischer Produkte zu beachten sind (innerhalb
Deutschland gibt es keinerlei Einschrnkungen) und
- ob fr in Frage kommende Produkte Exportbeschrnkungen beachtet
werden mssen.
Es gibt allerdings nicht nur Maximalanforderungen, sondern auch Minimal-
anforderungen an die verwendeten kryptographischen Algorithmen oder
Verfahren. So mssen z. B. bei der bermittlung von personenbezogenen
Daten Verschlsselungsverfahren mit ausreichender Schlssellnge eingesetzt
werden.
Technische Lsungsbeispiele:
Im folgenden finden sich einige Anwendungsbeispiele zu den verschiedenen
Einsatzfeldern fr kryptographische Verfahren. Dabei ist zu sehen, dass die
meisten Produkte gleich mehrere Einsatzfelder abdecken.
Beispiel 1: Festplattenverschlsselung
Die auf der Festplatte eines Stand-Alone-PC gespeicherten sensitiven Daten
sollen so geschtzt werden, dass
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- der PC nur von autorisierten Nutzern gebootet werden kann,

- nur autorisierte Nutzer Zugriff auf die gespeicherten Daten erhalten,
- die gespeicherten Daten bei abgeschaltetem PC - auch im Falle des Dieb-
stahls - hinreichend vor Kenntnisnahme durch Unberechtigte geschtzt
sind.
Im Vordergrund soll hier der Schutz der Vertraulichkeit stehen. Dabei soll der
PC gegen die folgenden Bedrohungen geschtzt werden:
- Unbefugte Kenntnisnahme der auf der Festplatte gespeicherten Daten
- Manipulation der auf der Festplatte gespeicherten Daten
- Manipulation des Kryptosystems
Bei Diebstahl bzw. Verlust des PC oder der Festplatte steht dem Angreifer
sehr viel Zeit fr die unbefugte Kenntnisnahme zur Verfgung. Eine
Schutzmanahme muss auch bei solchen Langzeitangriffen die Vertraulichkeit
der gespeicherten Daten gewhrleisten.
Als Schutzmanahme soll daher ein Produkt mit Boot-Schutz und Festplatten-
verschlsselung eingesetzt werden. Auf dem Markt sind verschiedene Lsun-
gen verfgbar. Zum Einsatz kann entweder eine Verschlsselungs-Software
(Lsung A), eine Verschlsselungs-Hardware-Komponente (Lsung B) oder
eine Kombination aus Hardware- und Software-Komponente (Lsung C)
kommen. Lsung C wird typischerweise aus einer Verschlsselungs-Software
in Kombination mit einem Chipkartenleser zur Zugangskontrolle bestehen.
Welche Lsung gewhlt werden sollte, hngt von verschiedenen Entschei-
dungskriterien ab:
- Sicherheit (Kryptoalgorithmus und Schlssellnge, Betriebsart der
Verschlsselung, Zugriffsschutz, Schlsselerzeugung/ -verteilung/
-speicherung/ -eingabe, Einbindung in das Betriebssystem, etc.)
Je nachdem, auf welcher Betriebssystem-Plattform Verschlsselung betrie-
ben wird, stt man mit Software-Lsungen (Lsungen A oder C) unwei-
gerlich an Grenzen. Kann man kein sicheres Betriebssystem mit strikter
Task- und Speicherbereichs-Trennung voraussetzen (bisher ist das bei
keinem Betriebssystem sicher nachgewiesen!), muss der whrend der Ver-
bzw. Entschlsselung verwendete Schlssel zumindest kurzzeitig unge-
schtzt im Speicher des PC gehalten werden. Die Vertraulichkeit des
Schlssels ist somit nicht mehr sichergestellt. Hardware-Verschlsselungs-
Komponenten (Lsung B) knnen (mssen aber nicht!) mehr bieten. Der
Schlssel kann in die Hardware-Komponente geladen und dort - gegen
Auslesen gesichert - gespeichert werden. Der Schlssel wird die Hardware-
Komponente nicht mehr verlassen und ist vor Aussphversuchen geschtzt.
Er kann nur durch berechtigte Benutzer mittels Besitz und Wissen (z. B.
Chipkarte und Passwort) aktiviert werden. Wichtig sind weitere Aspekte
wie die zur Verschlsselung verwendeten Algorithmen (meist ein
Blockchiffrier-Algorithmus), deren Betriebsarten (z. B. CBC) sowie die
Art und Weise der Einbindung in das PC-System. Die Verschlsselungs-
Hardware sollte idealerweise so eingebunden werden, dass sie die gesamte
Festplatte zwangsweise kryptiert und durch Angriffe nicht unbemerkt
abgeschaltet bzw. umgangen werden kann. Werden im Gegensatz dazu le-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
diglich einzelne Dateien verschlsselt besteht die Gefahr, dass die Inhalte
dieser Dateien unkontrollierbar zumindest teilweise zustzlich im Klartext
auf die Festplatte geschrieben werden (z. B. in den Auslagerungsdateien
verschiedener Betriebssysteme oder in Backup-Dateien).
- Performance (Geschwindigkeit der ausfhrbaren Programme)
Software-Verschlsselung nutzt die Systemressourcen des PC, belastet also
die CPU und bentigt Arbeitsspeicher. Sptestens bei der Verschlsselung
der gesamten Festplatte wird die Performance des PC sinken. Hardware-
Komponenten mit eigenem Prozessor knnen die Verschlsselung ohne
Belastung der PC-CPU und somit ohne nennenswerten Performanceverlust
durchfhren. Hier ist je nach Bauart die Durchsatzrate der verwendeten
Kryptier-Hardware mitentscheidend.
- Organisatorischer/Personeller Aufwand (Administration, Keymanagement,
Schulung, etc.)
Der organisatorische bzw. personelle Aufwand ist von der Umsetzung der
Sicherheitspolitik und dem "Komfort" der Verschlsselungs-Komponenten
abhngig. Generelle Entscheidungskriterien fr oder gegen eine der drei
Lsungen knnen nicht allgemein gltig formuliert werden.
- Wirtschaftlichkeit (Anschaffung, Schulungs-/Administrationskosten, ...)
Eine allgemeine Aussage zur Wirtschaftlichkeit ist schwierig. Betrachtet
man nur die Anschaffungskosten, so werden Software-Lsungen oft
preiswerter sein als Hardware-Lsungen. Kalkuliert man dagegen auch die
Schden ein, die durch unzureichenden Schutz auf lngere Sicht entstehen
knnen, kann sich im Vergleich die Investition in sicherere und vielleicht
teurere Lsungen lohnen. Wirtschaftliche Nachteile knnen u. U. durch
Performanceverlust des PC-Systems entstehen.
- Restrisiken (Betriebssystem, Kompromittierung des Festplattenschlssels,
etc.)
Bei der Auswahl der geeigneten Verschlsselungs-Komponente spielt die
Restrisikobetrachtung eine wesentliche Rolle. Es stellen sich u. a. die
Fragen
- Welche Restrisiken kann man in Kauf nehmen? und
- Welche Restrisiken werden bzw. knnen durch andere Manahmen
(z. B. materielle oder organisatorische Manahmen) minimiert
werden?
Es knnen sich durchaus mehrere tragbare Lsungsmglichkeiten durch
die Kombination verschiedener Manahmen ergeben.
Beispiel 2: E-Mail-Verschlsselung
Der Austausch von elektronischer Post (E-Mail) ber bzw. in Computer-
Netzen gewinnt zunehmend an Bedeutung. Werden dabei sensible Informa-
tionen (z. B. Firmengeheimnisse) ber ungesicherte Netze ausgetauscht, so
sind dabei Mechanismen zum Schutz der Vertraulichkeit bzw. fr die Gewhr
der Authentizitt von Nachrichten erforderlich. Zu diesen Zwecken dienen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
E-Mail-Verschlsselungsprogramme. Am weitesten verbreitet sind dabei zwei

Programmpakete bzw. Standards amerikanischer Herkunft:
- PGP ("Pretty Good Privacy") und
- S/MIME (Secure Multipurpose Internet Mail Extensions).
Dabei ist PGP ein Programmpaket, das ursprnglich als Freeware im Internet
erhltlich war und sich daher weit verbreitet hat. Der S/MIME Standard wird
u. a. von den Secure-E-Mail Anwendungen der Firmen Microsoft, Netscape
und RSA Data Security Inc. verwendet.
Was muss ein solches E-Mail-Verschlsselungsprogamm leisten?
Die Antwort hngt zu einem gewissen Grad natrlich von den umgebenden
Sicherungsmanahmen ab. Die Anforderungen sind sicherlich dann am
grten, wenn die Nachrichten ber ein groes, offenes, ungesichertes Netz
wie z. B. das Internet verschickt werden sollen. Hier wollen evtl. sogar einan-
der persnlich Unbekannte vertraulich und authentisch miteinander kommu-
nizieren. Welche kryptographischen Dienste sind dazu erforderlich?
Vertraulichkeit
Da die Nachrichten verschlsselt werden sollen, mssen (einer oder mehrere)
Verschlsselungsalgorithmen implementiert sein. Dazu bieten sich wegen der
hheren Performance symmetrische Verfahren an.
Schlsselmanagement
- Erzeugung: die Schlssel fr das symmetrische Verfahren mssen durch
einen geeigneten (Zufalls-) Prozess so erzeugt werden, dass Erraten bzw.
Vorhersage weiterer Schlssel auch bei Kenntnis einiger vorhergehender
Schlssel praktisch unmglich ist.
- Schlsseleinigung/Austausch: da eine zentrale Schlsselversorgung mittels
symmetrischer Verfahren im Internet schon wegen der schieren Masse der
mglichen Kommunikationspartner ausscheidet, ist die Verwendung
asymmetrischer Verfahren fr Schlsseleinigung bzw. Schlsselaustausch
geboten.
Authentizitt
Da aufgrund der Anforderungen aus dem Schlsselmanagement ohnehin ein
asymmetrisches Verfahren implementiert ist (und evtl. Verbindlichkeit ver-
langt wird), wird man zu diesem Zweck eine digitale Signatur einsetzen.
Signaturschlssel sollten dabei ausschlielich zu Signaturzwecken verwendet
werden. Dabei muss - wie immer bei der Verwendung von Public-Key-
Verfahren - das Problem der Authentizitt der ffentlichen Schlssel gelst
werden.
Verbindlichkeit
Verbindlichkeit setzt eine Public-Key-Infrastruktur voraus (PKI, Registrierung
von Teilnehmern und Zertifizierung von ffentlichen Schlsseln durch eine
vertrauenswrdige dritte Instanz, inkl. Einsatzregeln). Bisher existiert
allerdings keine globale PKI, daher ist es schwierig, fr E-Mails von vorher
unbekannten Teilnehmern einen verbindlichen Herkunftsnachweis zu bekom-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
men. In einem lokalen Netz wre zu diesem Zweck eine geeignete PKI zu
schaffen.
Standardkonformitt
Aus Interoperabilittsgrnden und zum Investitionsschutz ist es sinnvoll, mg-
lichst weit verbreitete und akzeptierte Internet-Standards zu verwenden.
Sowohl S/MIME als auch PGP befinden sich im Stadium der
Standardisierung.
Beispiel 3: Sichere Sprach- und Datenkommunikation bei ISDN-Netz-
anbindungen
Beim folgenden Anwendungsbeispiel wird die Kommunikation per ISDN
betrachtet. Geschtzt werden sollen die Anwendungen "Telefonverkehr" und
"Videokonferenzen" sowie der Datenverkehr zwischen Rechnernetzen. Als
Ziel soll ein wirkungsvoller Schutz bermittelter vertraulicher Informationen
und verbindlicher personenbezogener Daten gewhrleistet werden. Es wird
davon ausgegangen, dass alle zu bertragenen Informationen in digitaler Form
(PCM-Code) vorliegen und dass die in firmeneigenen Netzen und
TK-Anlagen bliche Sprachkomprimierung fr verschlsselte Anwendungen
abgeschaltet werden kann, damit die Nutzkanle (B-Kanle) verschlsselt
werden knnen.
Dafr soll eine ISDN-Sicherheitskomponente eingesetzt werden, mit der ein
S0-Anschluss mit zwei 64 kbit/s-Kanlen abgesichert werden kann. Dabei ist
es unerheblich, ob am S0-Bus einzelne ISDN-Endgerte (Telefon, Fax, PC mit
ISDN-Einsteckkarte etc.) angeschlossen sind oder eine kleine TK-Anlage
nachgeschaltet ist. Alle Verbindungen sollen wahlweise verschlsselt oder
unverschlsselt aufgebaut und betrieben werden. Folgende Abbildung zeigt
die entsprechende Systemkonfiguration.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es wurde ein ISDN-Kryptogert ausgewhlt, das mittels einer Chipkarte

gegen unbefugte Benutzung abgesichert werden kann. Alternativ steht auch
eine serielle V.24-Schnittstelle zur Verfgung, um die Sicherheitskomponente
mit Hilfe eines PC konfigurieren zu knnen. Der Benutzer oder die Endan-
wendung kann die Verschlsselung direkt mit der Chipkarte bzw. durch die
Vorwahl einer speziellen Kennziffer steuern. Auch ist es mglich, die ISDN-
Sicherheitskomponente so zu konfigurieren, dass bestimmte Verbindungen
(Nummern) verschlsselt oder unverschlsselt voreingestellt sind. Fr das
Schlsselmanagement, d. h. die Generierung und Verteilung von Schlssel-
zertifikaten wird an einer zentralen Stelle des ISDN-Netzes eine Manage-
mentstation angeschlossen. Somit ist sichergestellt, dass die einzelnen ISDN-
Sicherheitskomponenten netzweit registriert und mit aktuellem Schlssel-
material versorgt werden knnen.
Die Mglichkeit des sicheren Transports von Informationen und schtzens-
werten Daten in einem ISDN-Netz sind vielfltig und komplex. Dabei muss
jeder relevanten Grundbedrohung mit einer konkreten Sicherheitsmanahme
begegnet werden. Zur Gewhrleistung der Vertraulichkeit erfolgt eine Online-
Verschlsselung des bertragenen Datenstroms am wirkungsvollsten auf der
Sicherungsschicht. Hierzu werden die Daten vor ihrer bertragung von einer
Kryptohardware automatisch verschlsselt und auf der Empfngerseite wieder
entschlsselt. Die Verschlsselung ist dabei vollstndig transparent fr den
Endteilnehmer und fr Anwenderprogramme. Das verwendete Kryptomodul
ermglicht nicht nur eine Echtzeitverarbeitung, sondern bietet - im Vergleich
zu einer Dateiverschlsselung (Softwarelsung) - einen hheren Schutz gegen
Angriffsversuche. Zur Sicherung der bersendung von verbindlichen oder
beweispflichtigen Daten knnen diese zustzlich mit einer digitalen Signatur
des Absenders versehen werden. Damit kann die Herkunft und Echtheit der
bertragenen Nachricht vom Empfnger verifiziert und eventuelle
Manipulationen innerhalb des ffentlichen Netzes zuverlssig erkannt werden.
Fr die sichere Erzeugung und Speicherung des Signaturschlssels wird
wiederum auf die Chipkarte zurckgegriffen, die ein wesentlicher Bestandteil
des Sicherheitskonzeptes ist. Auerordentlich wichtig fr die Verbindung von
Rechnern ist es, dass der Mglichkeit einer ungewollten Fehlvermittlung, die
- anders als bei Telefongesprchen - meist nicht vor oder whrend der
bertragung erkannt werden, angemessen begegnet wird. Dies kann durch
eine eingebaute Firewall-Funktionalitt in der ISDN-Sicherheitskomponente
erreicht werden. Durch eine berwachung des Signalisierungskanals
(D-Kanal) kann dann die Sicherheitskomponente so eingestellt werden, dass
ausschlielich explizit vorkonfigurierte Kryptoverbindungen zustande
kommen. In Verbindung mit TK-Anlagen ist ferner vorgesehen, dass
bestimmte Rufnummern und Funktionen dieser Nebenstellenanlagen gesperrt
werden. Damit lt sich die Ausnutzbarkeit der Schwachstellen "Fernwartung"
und "Rufweiterleitung" einschrnken.
Um sowohl ein sicheres Schlsselmanagement als auch eine schnelle Echt-
zeitverschlsselung der Nutzdaten zu erreichen, sollten Hybridverfahren ein-
gesetzt werden. Unter Beibehaltung der symmetrischen Informations-
verschlsselung wird der so genannte Sitzungsschlssel mit Hilfe eines
asymmetrischen Verfahrens ausgetauscht. Dies luft im Praxisbetrieb vllig
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
automatisch ab. Ohne nennenswerte Beeintrchtigung des Bedienungs-

komforts knnen auf diese Weise fr jede neue ISDN-Verbindung neue
Sitzungsschlssel vereinbart werden.
Aus sicherheitstechnischer Sicht sollte der Endteilnehmer folgende Einsatz-
kriterien und -auflagen bei der Auswahl bzw. beim Einsatz einer ISDN-
Sicherheitskomponente heranziehen:
(Bewertung: + = wichtig bis +++ = sehr wichtig):
- Die individuellen Teilnehmerschlssel und Authentisierungsinformationen
sind auf einem sicheren Medium (z. B. einer Chipkarte) zu speichern und
mit Hilfe einer vertrauenswrdigen Signatur zu sichern (+++).
- Fr die Verschlsselung einer Kommunikationsbeziehung (Sprache, Daten,
Bild, etc.) ist pro bertragung ein geheimer Schlssel, der sogenannte
Sitzungsschlssel, neu zu vereinbaren (++).
- Die ausgefhrten Sicherheitsdienste erfolgen automatisch und fr das End-
system bzw. den Endteilnehmer vllig transparent (+).
- Fr ausgewhlte Verbindungen ist die Sicherheitskomponente immer im
Kryptobetrieb eingerichtet (+++).
- Die bestehende Infrastruktur sollte bei Verwendung der Sicherheits-
komponenten voll erhalten bleiben (+).
- Die Sicherheitsadministration der Sicherheitskomponenten sollte netzweit
und mglichst von zentraler Stelle aus mglich sein (+).
- Wnschenswert ist eine Online-Betriebsberwachung und Registrierung
aller Sicherheitskomponenten im Dialog mit der Managementstation (+).
Es sollten ISDN-Sicherheitskomponenten ausgewhlt werden, die normierte
Schnittstellen haben, keine nderungen in den zu schtzenden Endgerten
erfordern und die leicht in eine bestehende Kommunikationslandschaft zu
integrieren sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Verfahrens
Die Auswahl eines kryptographischen Verfahrens zerfllt in die beiden Teil-
aufgaben
- Auswahl des kryptographischen Algorithmus und
- Auswahl einer technischen Realisierung.
Bevor der Anwender sich auf bestimmte Verfahren festlegt, sollte er genaue
Vorstellungen davon haben, welche Anforderungen er an Vertraulichkeit und
Authentizitt der bearbeiteten Daten in jedem "Punkt" seines informations-
verarbeitenden Systems stellt.
Auswahl von kryptographischen Algorithmen
Bei der Auswahl von kryptographischen Algorithmen ist zunchst zu klren,
welche Art kryptographischer Verfahren bentigt werden, also symmetrische,
asymmetrische oder hybride Verfahren, und dann sind geeignete Algorithmen,
also solche mit entsprechender Mechanismenstrke auszuwhlen.
Verschlsselungsverfahren
- symmetrische Verschlsselung: Die Vor- bzw. Nachteile symmetrischer
Verfahren sind in M 3.23 Einfhrung in kryptographische Grundbegriffe
beschrieben. Geeignete Algorithmen sind z. B. Triple-DES, IDEA, RC 5,
wobei bei RC 5 die Schlssellnge mindestens 80 Bit sein sollte.
- asymmetrische Verschlsselung: Die Vor- bzw. Nachteile asymmetrischer
Verfahren sind ebenfalls in M 3.23 Einfhrung in kryptographische
Grundbegriffe beschrieben. Geeignete Algorithmen sind z. B. RSA oder
auf Elliptischen Kurven basierende Verschlsselungsverfahren (zur
Schlssellnge siehe unten).
Authentisierungsverfahren
- Nachrichtenauthentisierung
Zur Nachrichtenauthentisierung knnen verschiedene Verfahren eingesetzt
werden, etwa ein Message Authentication Code (MAC) oder ein digitales
Signaturverfahren. Der Einsatz eines MACs ist von Vorteil, wenn extrem
hohe Durchsatzraten gefordert sind (oder nur eine geringe Rechenkapazitt
zur Verfgung steht) und das Risiko der Schlsseloffenlegung auf beiden
Seiten sehr gering ist. Der Einsatz eines digitalen Signaturverfahrens ist
von Vorteil, wenn das Risiko der (Signatur-) Schlsseloffenlegung auf
einer Seite wesentlich hher ist als auf der anderen Seite; und in aller Regel
geboten, wenn Verbindlichkeitsdienste verlangt werden. Es sei noch
einmal bemerkt, dass fr den Dienst Verbindlichkeit eine Infrastruktur
vertrauenswrdiger Dritter vorhanden sein muss.
Der bekannteste MAC-Algorithmus ist die Verschlsselung einer
Nachricht mit DES oder einem anderen Block-Chiffrierverfahren im CBC-
oder CFB-Mode. Dabei wird als MAC der letzte verschlsselte Block an
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
die Nachricht angehngt. Solche Varianten sind z. B. in den Normen ANSI

X9.9, ANSI X9.19, ISO 8731-1 oder ISO 9797 spezifiziert.
Geeignete Algorithmen fr Digitale Signaturen sind z. B. RSA, DSA
(Digital Signature Algorithm) oder auf elliptischen Kurven basierende
DSA-Varianten, z. B. ISO/IEC 15946-2, IEEE-Standard P1363, Abschnitt
5.3.3 ("Nyberg-Rueppel Version"), IEEE-Standard P1363, Abschnitt 5.3.4
("DSA Version").
- Authentisierung von Benutzern oder Komponenten
Ein einfaches Verfahren zur Authentisierung ist eine Passwortabfrage.
Werden die Passwrter dabei aber unverschlsselt ber ein Netz ber-
tragen, knnen diese verhltnismig einfach mitgelesen werden. Daher
sollten hier bessere Verfahren verwendet werden. Geeignete Verfahren
sind beispielsweise
- Einmalpasswrter (siehe auch M 5.34 Einsatz von
Einmalpasswrtern), die software- oder hardwaregesttzt erzeugt
werden knnen. Hierbei sind die hardwarebasierten
Authentifikationsmethoden vorzuziehen, da sie einen geringeren
organisatorischen Aufwand und hhere Sicherheit bieten.
- Die Authentisierung mittels PAP oder besser CHAP, die bei der
Nutzung des Point-to-Point-Protocol eingesetzt werden (siehe auch
M 5.50 Authentisierung mittels PAP/CHAP).
- Die Authentisierung mittels CLIP/COLP, die bei der
Kommunikation ber ISDN eingesetzt wird (siehe auch M 5.48
Authentisierung mittels CLIP/COLP).
- Ein weiteres bekanntes Verfahren ist das Authentikationsprotokoll
Kerberos, das am MIT (Massachusetts Institute of Technology)
entwickelt wurde. Es wird in Netzen zur gegenseitigen
Authentisierung von Benutzer/Client und Servern eingesetzt. Die
zentrale Autoritt bei Kerberos ist der Ticket-Granting-Server, der
Tickets ausstellt, mit denen sich Clients und Server gegenseitig
authentisieren knnen. Mit Hilfe dieser Tickets knnen Benutzer
sich nach einmaliger Authentikation Sitzungsschlssel fr die
verschiedensten Dienste anfordern.
Hashverfahren
Geeignete Algorithmen sind z. B. SHA-1 und RIPEMD-160.
Auswahlkriterien
- Mechanismenstrke / Schlssellnge
Ein wesentliches Kriterium fr die Auswahl von kryptographischen Ver-
fahren ist ihre Mechanismenstrke. Bei symmetrischen Verfahren sollte
insbesondere die Schlssellnge ausreichend gro sein. Je grer die ver-
wendete Schlssellnge bei einem kryptographischen Verfahren ist, desto
lnger dauert es, ihn z. B. durch eine Brute-Force-Attacke zu berechnen.
Andererseits werden die Verfahren bei der Verwendung lngerer Schlssel
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
langsamer, so dass immer zu berlegen ist, welche Schlssellnge unter

Nutzen-/Leistungsgesichtspunkten angemessen ist. Als Faustregel fr gute
Verfahren (Triple-DES, IDEA, RC5,...) und mittleren Schutzbedarf gilt
derzeit, dass die eingesetzten Schlssel mindestens 100 Bit lang sein
sollten. Bei Verwendung von Blockchiffren sollten grere, strukturierte
Datenmengen nicht im ECB-Modus verschlsselt werden. Stattdessen
sollten dazu der CBC-Modus oder der CFB-Modus verwendet werden.
Mindestens eine dieser Betriebsarten sollte daher implementiert sein.
Bei asymmetrischen Verfahren sollte die Mechanismenstrke so gewhlt
werden, dass die Lsung der zu Grunde liegenden mathematischen Pro-
bleme einen unvertretbar groen bzw. praktisch unmglichen Rechen-
aufwand erfordert (die zu whlende Mechanismenstrke hngt daher vom
gegenwrtigen Stand der Algorithmik und der Rechentechnik ab). Gegen-
wrtig kann man davon ausgehen, dass man mit
- Modullngen von 1024 Bit bei RSA bzw.
- Untergruppenordnungen in der Gre von 160 Bit bei ElGamal-
Verfahren auf einer geeigneten elliptischen Kurve
"auf der sicheren Seite" ist.
Es sollten keine "unbekannten" Algorithmen verwendet werden, d. h. es
sollten Algorithmen eingesetzt werden, die verffentlicht sind, die von
einem breiten Fachpublikum intensiv untersucht worden sind und von
denen keine Sicherheitslcken bekannt sind. Hufig bieten Hersteller
Sicherheitsprodukte an mit neuen Algorithmen, die "noch viel sicherer und
noch viel schneller" sein sollen als andere Algorithmen. Aber vor der
Verwendung von unbekannten Algorithmen aus Quellen, deren krypto-
graphische Kompetenz nicht ausreichend nachgewiesen ist, kann nur
gewarnt werden.
- Symmetrische oder hybride Verfahren?
Aus Performancegrnden werden fr Verschlsselungszwecke keine reinen
Public-Key-Implementierungen eingesetzt. Alle gngigen Imple-
mentierungen von Public-Key-Kryptographie nutzen hybride Verfahren
(siehe auch M 3.23 Einfhrung in kryptographische Grundbegriffe).
In Anwendungen mit groen oder offenen Nutzergruppen empfiehlt sich
meist die Verwendung eines hybriden Verfahrens (wegen der Vorzge fr
das Schlsselmanagement). Bei kleinen, geschlossenen Nutzergruppen
(insbesondere natrlich bei einem einzelnen Benutzer) kann man sich auf
symmetrische Verfahren beschrnken. Bei Einsatz hybrider Verfahren ist
es sinnvoll, die Strken des symmetrischen und des asymmetrischen
Anteils aufeinander abzustimmen. Da mit dem asymmetrischen Verfahren
vor einem Schlsselwechsel in der Regel viele Schlssel fr das
symmetrische Verfahren berschlsselt werden, sollte der asymmetrische
Algorithmus eher etwas strker ausgelegt werden.
- Realisierbarkeit von technischen Anforderungen
Die Chiffrieralgorithmen mssen so beschaffen sein, dass die technischen
Anforderungen, insbesondere die geforderte Performance, durch eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
geeignete Implementation erfllt werden knnen. Hierunter fallen Anfor-

derungen an die Fehlerfortpflanzung (z. B. falls ber stark rauschende
Kanle gesendet wird), aber auch Anforderungen an Synchronisations-
overhead und Zeitverzgerung (z. B. falls "Echtzeit"-Verschlsselung von
groen Datenmengen erfordert wird).
Beispiel: Sprachverschlsselung bei ISDN
Fr die Planung eines Kommunikationsnetzes sind eine Reihe von Para-
metern zu bercksichtigen, die einen Einfluss auf die zu erwartende
Sprachqualitt haben und sich in Form von Rauschen, Knacken, Neben-
sprechen oder Pfeifen bemerkbar machen. Zu solchen Einflussfaktoren
zhlen beispielsweise die eingesetzten Verschlsselungsverfahren. Um
eine zufrieden stellende Sprachqualitt erzielen zu knnen, mssen alle
Einrichtungen lngs eines bertragungsweges betrachtet und bewertet
werden. Eine isolierte Betrachtungsweise einer Einzelkomponente ist zwar
aufgrund der Verkopplung aller relevanten Einzeleffekte als nicht gerecht-
fertigt anzusehen, dennoch ist die Kenntnis der Einflussfaktoren jeder
Einzelkomponente (z. B. der Kryptokomponente) wichtig. Hieraus knnen
sowohl die Rahmenbedingungen fr die Realisierung als auch fr die
Auswahl abgeleitet werden. Das Verhalten einer Verschlsse-
lungskomponente wird dabei hauptschlich durch folgende Faktoren
charakterisiert:
- die verstreichende Zeitdauer bei der Verschlsselung eines Daten-
blocks (fhrt i. allg. zu Verzgerungen),
- die fr Synchronisationszwecke zustzlich in den Datenstrom einge-
fhrten Steuerinformationen (fhren u. U. zu Schwankungen),
- der von der Kryptokomponente maximal zu leistende Datendurch-
satz (fhrt - wenn Zwischenspeicherung notwendig - ebenfalls zu
Schwankungen),
- die durch die Verschlsselung resultierende Fehlerfortpflanzung
(fhrt i. allg. zu einem Anstieg der Fehlerrate).
Gerade bei einer Sprachverschlsselung (Echtzeitdienst) machen sich die
vorgenannten Einflussfaktoren in einer Erhhung der Ende-zu-Ende-Lauf-
zeit, in Laufzeitschwankungen sowie in einer hheren Fehlerrate negativ
bemerkbar, d. h. in einer Qualittsminderung, die messtechnisch ermittelt
und der Kryptokomponente zugeordnet werden kann.
- Andere Einflussfaktoren
Manche kryptographische Algorithmen (z. B. IDEA) sind patentiert, fr
ihren Einsatz in kommerziellen Anwendungen (wozu auch der behrdliche
Bereich zhlt) sind evtl. Lizenzgebhren zu entrichten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verffentlichungen der Reg TP

Die Regulierungsbehrde fr Telekommunikation und Post (Reg TP) ver-
ffentlicht regelmig im Bundesanzeiger eine bersicht ber die Algorith-
men, die zur Erzeugung von Signaturschlsseln, zum Hashen zu signierender
Daten oder zur Erzeugung und Prfung qualifizierter elektronischer Signa-
turen als geeignet angesehen werden knnen. Diese Verffentlichungen kn-
nen auch vom Webserver der Reg TP (http://www.regtp.de) herunter geladen
werden. Sie knnen zustzliche Hinweise zur Auswahl liefern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Produktes
Das Spektrum kryptographischer Anwendungen ist sehr breit, es reicht von
einem einfachen Programm zur Dateiverschlsselung auf einem Single-User
PC ber Firewall-Rechner mit Kryptofunktionen zur Absicherung eines
lokalen Netzes bis hin zur "Echtzeit"-Hardwareverschlsselung von Video-
konferenzen. Es ist klar, dass bei dieser Breite Empfehlungen zur Auswahl
von kryptographischen Produkten allgemein gltig gehalten sind.
Vor einer Auswahl sollte der Nutzer smtliche Anforderungen an das Produkt
festlegen. Das ausgewhlte Produkt sollte die Benutzeranforderungen in
einem mglichst hohen Grad abdecken.
Funktionalitt
Das ausgewhlte Produkt muss die vom Anwender spezifizierte Funktionalitt
aufweisen, insbesondere muss es
- die geforderten kryptographischen Grunddienste leisten,
- evtl. besonderen Anforderungen durch die Einsatzumgebung gengen
(z. B. Single-User/Multi-User-PC, LAN-Umgebung, WAN-Anbindung),
- die geforderten technischen Leistungsmerkmale aufweisen (z. B. Durch-
satzraten),
- die geforderten Sicherheitsfunktionalitten aufweisen, insbesondere
mssen die eingesetzten kryptographischen Mechanismen die erforderliche
Strke aufweisen.
Interoperabilitt
Das ausgewhlte Produkt wird in der Regel in eine bestehende IT-Umgebung
eingefgt. Es muss dort mglichst interoperabel sein. Die Einhaltung interner
Standards ist ntig, um die Interoperabilitt mit dem bereits vorhandenen IT-
System bzw. Systemkomponenten zu gewhrleisten. Die Anwendung inter-
nationaler Standards fr kryptographische Techniken sollte selbstverstndlich
sein, sie erleichtert auch eine Sicherheitsevaluierung der kryptographischen
Komponente.
Wirtschaftlichkeit
Das ausgewhlte Produkt sollte mglichst wirtschaftlich sein. Dabei mssen
Anschaffungskosten, Stckzahlen, Kosten fr Wartung und Produktpflege,
aber auch Einsparungen durch etwaige Rationalisierungseffekte bercksichtigt
werden.
Zertifizierte Produkte
In den letzten Jahrzehnten hat sich eine international anerkannte Methodologie
zur Bewertung von IT-Sicherheitsprodukten durchgesetzt: die europischen
ITSEC (Information Technology Security Evaluation Criteria) bzw. deren
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Weiterentwicklung CC (The Common Criteria for Information Technology

Security Evaluation). Die ITSEC bzw. CC bieten einen Rahmen, innerhalb
dessen die Sicherheitsfunktionalitten eines IT-Produktes durch Anlegen von
etablierten Kriterien in eine genau spezifizierte Hierarchie von
Sicherheitsstufen eingeordnet werden knnen. Die Informationssicherheits-
behrden mehrerer Staaten haben jeweils ein nationales Zertifizierungsschema
nach diesen Kriterien aufgebaut.
Der Einsatz eines zertifizierten Produktes bietet die Gewhr, dass die Sicher-
heitsfunktionalitt dieses Produktes unabhngig geprft wurde und den im
Evaluationslevel spezifizierten Standard nicht unterschreitet (siehe auch
M 2.66 Beachtung des Beitrags der Zertifizierung fr die Beschaffung).
Importprodukte
In mehreren Staaten, insbesondere den USA, unterliegt der Export von starker
Kryptographie gegenwrtig (noch) starken Beschrnkungen. Insbesondere
wird die Strke von an sich starken Verschlsselungsprodukten knstlich
(durch Reduzierung der Schlsselmannigfaltigkeit) herabgesetzt. Solche
knstlich geschwchten Verfahren erreichen i.d.R. nicht die fr mittleren
Schutzbedarf erforderliche Mechanismenstrke.
In Deutschland und den meisten anderen Lndern unterliegen kryptogra-
phische Produkte beim Einsatz innerhalb der Landesgrenzen keinerlei Ein-
schrnkungen. Beim Einsatz von Importprodukten sollte immer darauf geach-
tet werden, ob sie den vollen Leistungsumfang bieten.
Grenzberschreitender Einsatz
Viele Unternehmen und Behrden haben zunehmend das Problem, das sie
auch ihre internationale Kommunikation, z. B. mit auslndischen Tochter-
unternehmen, kryptographisch absichern wollen. Hierfr muss zunchst unter-
sucht werden,
- ob innerhalb der jeweiligen Lnder Einschrnkungen beim Einsatz krypto-
graphischer Produkte zu beachten sind und
- ob fr in Frage kommende Produkte Export- oder Importbeschrnkungen
beachtet werden mssen.
Fehlbedienungs- und Fehlfunktionssicherheit
Das Gefhrliche an kryptographischen Produkten ist, dass sie den Anwender
in einer - mitunter trgerischen - Sicherheit wiegen: Es ist ja "alles verschls-
selt"! Insofern kommt Manahmen gegen Kompromittierungen durch Bedie-
nungsfehler oder technisches Versagen besondere Bedeutung zu, da deren
Folgen eben nicht nur auf einen schlichten Defekt beschrnkt werden knnen,
sondern sogleich einen Sicherheitseinbruch nach sich ziehen. Allerdings ist
die Bandbreite bezglich redundanter Systemauslegung und zustzlicher
berwachungsfunktionen - und damit an Gertekosten - gro, so dass hier die
Manahmen im Einzelfall in Abhngigkeit von den Anforderungen festzu-
legen sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Implementierung in Software, Firmware oder Hardware

Kryptographische Algorithmen knnen sowohl in Software, in Firmware als
auch in Hardware implementiert werden. Softwarerealisierungen werden in
der Regel vom Betriebssystem des jeweiligen IT-Systems gesteuert. Unter
Firmware versteht man Programme und Daten, die permanent so in Hardware
gespeichert sind, dass die Speicherinhalte nicht dynamisch verndert werden
knnen, und die whrend ihres Ablaufs nicht modifiziert werden knnen. Bei
Hardware-Lsungen wird das kryptographische Verfahren direkt in Hardware
realisiert, z. B. als separates Sicherheitsmodul oder als Einsteckkarte.
Dazu, welche Art der Implementierung gewhlt werden sollte, kann keine
generelle Empfehlung abgegeben werden, da die Entscheidung eine Abw-
gung von verschiedenen Faktoren erfordert:
- den Schutzbedarf der durch das kryptographische Verfahren zu schtzen-
den Daten bzw. das angestrebte Sicherheitsniveau,
- den angestrebten Datendurchsatz,
- wirtschaftliche berlegungen und Zwnge,
- die Einsatzumgebung sowie umgebende Sicherungsmanahmen,
- eine evtl. vorliegende nationale Einstufung der bearbeiteten Daten.
Softwarelsungen bieten den Vorteil, leicht anpassbar und kostengnstig zu
sein. Hardware-Realisierungen bieten im allgemeinen sowohl hhere Manipu-
lationsresistenz (und damit Sicherheit) als auch hheren Datendurchsatz als
Softwarerealisierungen, sie sind aber normalerweise auch teurer.
Firmwarelsungen kann man als Kompromiss der beiden vorangegangenen
Mglichkeiten verstehen. Die Vor- und Nachteile der jeweiligen Realisierung
beziehen sich jedoch immer nur auf lokale Aspekte (dazu gehrt vor allem das
Schlsselmanagement). Sind die Daten einmal verschlsselt und befinden sie
sich auf dem Kommunikationsweg, ist im Prinzip das Zustandekommen der
Verschlsselung nicht mehr relevant.
Ein Beispiel fr (relativ) preiswerte, transportable und benutzerfreundliche
Kryptomodule sind Chipkarten, die im Bereich der lokalen Verschlsselung
als sicheres Speichermedium fr die kryptographischen Schlssel oder im
Bereich der Authentikation zur Passwort-Generierung und Verschlsselung
eingesetzt werden knnen.
Wenn alle Anforderungen an das kryptographische Produkt festgelegt worden
sind, erhlt man damit einen Anforderungskatalog, der dann auch direkt fr
eine Ausschreibung verwendet werden kann, sofern eine solche notwendig ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.166 Regelung des Einsatzes von Kryptomodulen

Auch im laufenden Betrieb mssen eine Reihe von Sicherheitsanforderungen
an den Einsatz von Kryptomodulen gestellt werden. Diese mssen adquat in
das technische und organisatorische Umfeld eingebunden sein, in dem sie
eingesetzt werden.
Dafr mssen einige organisatorische Regelungen getroffen werden:
- Es mssen Verantwortliche benannt werden, und zwar fr die Erstellung
des Kryptokonzepts, fr die Auswahl sowie fr den sicheren Betrieb der
kryptographischen Produkte.
- Es sind geeignete personelle Manahmen festzulegen bzw. durchzufhren
(Schulung, Benutzer-Support, Vertretungsregelungen, Verpflichtungen,
Rollenzuteilungen).
- Die Benutzer sollten nicht nur im Umgang mit den von ihnen zu bedie-
nenden Kryptomodulen geschult werden, sie sollten darber hinaus fr den
Nutzen und die Notwendigkeit der kryptographischen Verfahren sensibili-
siert werden und einen berblick ber kryptographische Grundbegriffe
erhalten (siehe auch M 3.23 Einfhrung in kryptographische
Grundbegriffe).
- Falls Probleme oder gar der Verdacht auf Sicherheitsvorflle beim Einsatz
von Kryptomodulen auftritt, muss klar definiert sein, was in solchen Fllen
zu unternehmen ist. Alle Benutzer mssen ber die entsprechenden Ver-
haltensregeln und Meldewege informiert sein.
- Im Rahmen des Kryptokonzepts ist festzulegen, wer wann welche
Kryptoprodukte benutzen muss bzw. darf und welche Randbedingungen
dabei zu beachten sind (z. B. Schlsselhinterlegung).
- Der korrekte Einsatz der Kryptomodule sollte regelmig berprft
werden. Ebenso ist regelmig zu hinterfragen, ob die eingesetzten
kryptographischen Verfahren noch dem Stand der Technik entsprechen
(siehe dazu auch M 2.35 Informationsbeschaffung ber Sicherheitslcken
des Systems).
- Je nach den definierten Verfgbarkeitsanforderungen sollten Ersatz-
Kryptomodule vorrtig gehalten werden, um einen reibungslosen Betrieb
zu gewhrleisten. Dies ist insbesondere dort wichtig, wo der Zugriff auf
verschlsselte Daten von der Funktionsfhigkeit eines einzelnen Krypto-
moduls abhngt, z. B. bei der Datenarchivierung oder der ISDN-
Verschlsselung.
Es ist ein sicherer Betrieb der Kryptomodule zu gewhrleisten, dazu gehren:
- Vor der Inbetriebnahme muss die optimale Konfiguration der Krypto-
module festgelegt werden, z. B. hinsichtlich Schlssellnge, Betriebsmodi
oder Kryptoalgorithmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die festgelegte Konfiguration muss dokumentiert sein, damit sie nach

einem Systemversagen oder einer Neuinstallation schnell wieder einge-
richtet werden kann.
- Fr die Benutzer mssen die Kryptoprodukte durch den Administrator so
vorkonfiguriert sein, dass ohne weiteres Zutun der Benutzer maximale
Sicherheit erreicht werden kann.
- Bei komplexeren Kryptoprodukten mssen geeignete Handbcher verfg-
bar sein.
- Die Kryptomodule mssen sicher installiert werden und anschlieend
getestet werden (z. B. ob sie korrekt verschlsseln und ob sie von Benutzer
bedient werden knnen).
- Die Anforderungen an die Einsatzumgebung mssen festgelegt sein,
eventuell sind dafr ergnzende Manahmen im IT-Umfeld zu treffen. Die
sicherheitstechnischen Anforderungen an die IT-Systeme, auf denen die
kryptographischen Verfahren eingesetzt werden, sind den jeweiligen
systemspezifischen Bausteinen zu entnehmen, z. B. fr Clients (inkl.
Laptops) aus Kapitel 5, fr Server aus Kapitel 6.
- Es muss festgelegt werden, wer wie hufig die Kryptomodule zu warten
hat.
Auch im Rahmen des Schlsselmanagements (siehe M 2.46 Geeignetes
Schlsselmanagement) mssen diverse Vorgaben gemacht werden:
- Vorgaben zur Schlsselerzeugung und -auswahl,
- Vorgaben zur gesicherten Speicherung kryptographischer Schlssel,
- Festlegung der Schlsselwechsel-Strategie und -Intervalle.
- Sind Regelungen fr den Einsatz kryptographischer Verfahren festgelegt
worden?
- Ist das Kryptokonzept aktuell?
- An wen knnen sich die Benutzer bei Fragen zum Einsatz von Krypto-
modulen wenden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.167 Sicheres Lschen von Datentrgern

Verantwortlich fr Umsetzung: IT-Verfahrensverantwortlicher,
Eine geregelte Vorgehensweise fr die Lschung oder Vernichtung von
Datentrgern verhindert einen Missbrauch der gespeicherten Daten. Bevor
Datentrger wieder verwendet werden, mssen die gespeicherten Daten voll-
stndig gelscht werden, z. B. durch vollstndiges berschreiben oder
Formatieren. Dies ist insbesondere wichtig, wenn Datentrger an Dritte
weitergegeben werden sollen. Auch der Empfnger des Datentrgers muss
nach dem Empfang prfen, ob der Schutzwert der Daten ein sofortiges
Lschen des Datentrgers erfordert, nachdem die Daten auf ein anderes IT-
System bertragen wurden.
Es gibt verschiedene Methoden um Informationen auf Datentrgern zu
lschen, z. B. ber Lschkommandos, durch Formatieren, durch berschrei-
ben oder durch Zerstrung des Datentrgers. Welche Methode gewhlt werden
sollte, hngt hierbei auch vom Schutzbedarf der zu lschenden Daten ab, der
Schutz gegen die Restaurierung von Restdaten steigt in der genannten
Reihenfolge.
Lschkommandos
Bei der Benutzung von Lschkommandos ist insbesondere bei DOS-/
Windows-basierten Betriebssystemen zu beachten, dass dabei nicht tatschlich
die Dateiinformationen gelscht werden, sondern nur der Verweis auf diese
Informationen im "Inhaltsverzeichnis" des Datentrgers. Die Datei ist weiter-
hin vorhanden. Es gibt eine Vielzahl von Programmen, mit denen die gelscht
geglaubten Informationen wiederhergestellt werden knnen (z. B.
UNDELETE unter DOS).
Um Dateien unwiederbringlich zu lschen, mssen alle Eintrge auf dem
Datentrger berschrieben werden. Dafr knnen Programme wie PC-Tools
(Option "berschreiben" um Datentrger oder Programm WIPE um einzelne
Dateien zu berschreiben) oder Norton Utilities (Programm WIPEINFO)
eingesetzt werden.
Formatieren
Um Datentrger wieder in den "Urzustand" zu versetzen und damit auch vor-
handene Informationen zu lschen, knnen diese formatiert werden. Wie
zuverlssig dabei allerdings die alten Daten gelscht werden, ist stark abhn-
gig vom zu Grunde liegenden Betriebssystem. Ein berschreiben der alten
Daten ist auf jeden Fall zuverlssiger.
Beim Formatieren von DOS-Datentrgern ist beispielsweise darauf zu achten,
dass der Parameter /U (z. B. bei DOS 6.2 format a: /U) benutzt wird, damit
das Formatieren nicht ber den Befehl unformat wieder rckgngig gemacht
werden kann. Unter Windows 95 und Windows NT ist aus gleichem Grunde
eine Formatierung mit dem Parameter Vollstndig und nicht mit Quick-
Format durchzufhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
berschreiben
Eine fr den mittleren Schutzbedarf ausreichende physikalische Lschung
kann erreicht werden, indem der komplette Datentrger oder zumindest die
genutzten Bereiche mit einem bestimmten Muster berschrieben werden. Es
werden einige handelsbliche Produkte angeboten, die sogar die physikalische
Lschung einzelner Dateien gewhrleisten.
Zum berschreiben sollten keine gleichfrmigen Muster wie "0000" benutzt
werden, sondern es sollten Muster wie "C1" (hexadezimal, entspricht der Bit-
folge 11000001) benutzt werden. Dazu sollte bei einem zweitem Durchlauf
ein dazu komplementres Muster (also z. B. 3E, entspricht der Bitfolge
00111110) benutzt werden, damit mglichst jedes Bit einmal gendert wird.
Die berschreibprozedur sollte daher mindestens zweimal, besser aber drei-
mal wiederholt werden, da hierdurch eine verbesserte Schutzwirkung erzielt
wird.
Schreibgeschtzte oder nicht mehrfach beschreibbare Datentrger wie CD-
ROMs oder CD-Rs knnen selbstverstndlich auch nicht gelscht werden und
sollten vernichtet werden.
Lschgerte
Flexible magnetische Datentrger (Disketten, Bnder) knnen mit einem
Lschgert gelscht werden. Dabei werden die Datentrger einem externen
magnetischen Gleich- oder Wechselfeld ausgesetzt (Durchflutungslschen).
Geeignete Lschgerte, die die Norm DIN 33858 erfllen, sind in der BSI-
Publikation 7500 aufgefhrt.
Grundstzlich sind die Datentrger nach dem Lschen wiederverwendbar. Es
ist aber zu beachten, dass Datentrger mit einer magnetisch geschriebenen
Servospur (z. B: Bandkassetten IBM 3590, Travan 4, MLR und ZIP-Disket-
ten) nach einem solchen Lschen unbrauchbar werden.
Lschen von Festplatten
Auch Festplatten, die weitergegeben werden, mssen gelscht werden. Dies
gilt insbesondere dann, wenn auf der Festplatte sensitive Daten gespeichert
waren, oder wenn die Festplatte ausgesondert oder zur Reparatur gegeben
werden soll.
Fr Festplatten, die lediglich innerhalb einer Organisation weitergegeben
werden, ist es normalerweise ausreichend, die Dateien mit den normalen
Lschfunktionen des Betriebssystems zu lschen oder die Platte zu forma-
tieren.
Festplatten, die an Externe weitergegeben werden, sollten zumindest auf die
folgende Weise gelscht werden: Zunchst sollten alle vorhandenen Parti-
tionen gelscht werden (z. B. unter DOS mit dem Befehl fdisk) und eine groe
Partition angelegt werden. Danach sollte die gesamte Festplatte formatiert
werden (z. B. unter DOS mit dem Befehl format /U). Dabei muss jedoch be-
achtet werden, dass die Daten auf der Festplatte selbst dann noch mit
geeigneten Tools zumindest teilweise ausgelesen werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Als zustzliche Sicherheitsmanahme sollte daher auch fr Fesplatten ein

Lsch-Tool verwendet werden, das die ganze Platte mehrmals mit verschiede-
nen Mustern berschreibt.
Defekte Festplatten
Bei defekten Festplatten ist ein Lschen durch berschreiben nicht mehr
mglich. Daher bleibt nur das Lschen mit einem Lschgert, obwohl diese
Gerte nicht fr das Lschen von Festplatten vorgesehen sind. Wegen des
unterschiedlichen Aufbaus von Festplattenlaufwerken, insbesondere der
Anzahl von Platten, kann keine generelle Aussage ber die erzielbare
Lschwirkung gemacht werden. Die Anwendung eines Lschgertes auf eine
Festplatte macht diese im allgemeinen unbrauchbar.
Vernichtung der Datentrger
Eine einfache Mglichkeit, Datentrger zu vernichten, besteht darin, dass Dis-
ketten und Magnetbnder zerschnitten und Festplatten mechanisch zerstrt
werden. Dies ist allerdings zu umstndlich bei greren Mengen zu vernich-
tender Datentrger und auch nicht ausreichend bei hherem Schutzbedarf.
Geeignete Vernichtungsgerte fr Magnetbnder, Disketten und CD-ROMs,
die der Norm DIN 32757 entsprechen, sind in der BSI-Publikation 7500
aufgefhrt. Bei diesen Vernichtungsgerten werden die Datentrger entweder
zerkleinert oder eingeschmolzen. Vernichtungsgerte fr Festplatten sind nicht
bekannt.
- Gibt es ein geregeltes Vorgehen zum Lschen von Datentrgern?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.168 IT-System-Analyse vor Einfhrung eines

Vor der Einfhrung eines Systemmanagementsystems mssen die IT-Systeme,
die zuknftig verwaltet werden sollen, untersucht und analysiert werden. Die
daraus resultierende Systemdokumentation kann dann als Planungs- und
Entscheidungsgrundlage fr die festzulegende Systemmanagementstrategie
(siehe M 2.169 Entwickeln einer Systemmanagementstrategie) dienen.
Wichtig ist, dass schon zum Zeitpunkt der Planung alle relevanten
Informationen ber die zu verwaltenden Systeme mglichst vollstndig
vorliegen, um Fehlentscheidungen aufgrund mangelnder Information
auszuschlieen. Aus den lokalen Gegebenheiten lassen sich auerdem
konkrete Anforderungen formulieren, die von dem zu beschaffenden
Managementsystem erfllt werden mssen (K.O.-Kriterien).
Es sind folgende Manahmen (mit den dort beschriebenen Untermanahmen)
durchzufhren, die idealerweise bei der Planung und im laufenden Betrieb des
Systems gem Grundschutzhandbuch schon durchgefhrt wurden bzw.
werden:
- Ist-Aufnahme der aktuellen Netzsituation (siehe M 2.139 Ist-Aufnahme der
aktuellen Netzsituation)
- Dokumentation der Systemkonfiguration (siehe M 2.25 Dokumentation der
Systemkonfiguration): Es sollten alle IT-Systeme erfasst und dokumentiert
werden. Insbesondere in heterogenen Systemen mssen z. B. alle
vorhandenen Betriebssysteme erfasst werden, um die entsprechenden
Anforderungen an das Managementsystem formulieren zu knnen.
- Feststellung und berprfung des Softwarebestandes (siehe M 2.10
berprfung des Hard- und Software-Bestandes): Soll im Rahmen des
Systemmanagements auch Software verwaltet werden
(Applikationsmanagement), so sollte hier eine Bestandsaufnahme erfolgen.
Alternativ kann als Anforderung an das Managementsystem das
automatische Feststellen des Softwarebestandes ("Autodiscovery",
"Software-Discovery") formuliert werden. Welche der beiden Varianten im
Einzelfall notwendig ist, hngt von der Aufgabe ab, die im Bereich
Softwaremanagement erbracht werden soll. Wird das Managementsystem
z. B. dazu angeschafft, um einen existierenden Softwarebestand, dessen
Zusammensetzung nicht in Gnze bekannt ist, automatisch zu verwalten
(Softwareupdate, Einspielen neuer Software), so muss dass Management-
system nach seiner Installation in der Lage sein, den Softwarebestand
automatisch zu erfassen. Sollen im Rahmen des Applikationsmanagements
einzelne Softwarepakete zustzlich auf Anwendungsebene verwaltet
werden, so muss geprft werden, ob die Software dies aktiv untersttzt
(z. B. durch ein entsprechendes Protokoll), was eine vorherige Bestands-
aufnahme der vorhandenen Software ntig macht. Daraus ergeben sich
dann Anforderungen an den Funktionsumfang des zu beschaffenden
Managementsystems (z. B. Untersttzung des Applikationsverwaltungs
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
protokolls). Soll z. B. ein Webserver ber ein HTTP-basiertes Manage-

mentinterface verwaltet werden, so muss das Managementsystem HTTP-
basierte Managementfunktionen besitzen oder aber ein Erweiterungs-
interface anbieten, das es erlaubt, Eigenentwicklungen zu integrieren.
Neben der Dokumentation des Ist-Zustandes sollte auch die zuknftige
Planung fr das IT-System bercksichtigt werden, da ein Managementsystem
auch auf zuknftige nderungen im IT-System ausgelegt sein sollte (z. B.
Skalierbarkeit).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.169 Entwickeln einer Systemmanagementstrategie

Die in einem Netz angesiedelten Komponenten mssen von einem Admini-
strator regelmig verwaltet werden. Die zu erledigenden Aufgaben reichen
von der Einrichtung neuer Benutzer bis hin zur Installation neuer Software,
deren verteilte Natur die Installation von Teilsoftware auf jedem einzelnen
Rechner verlangt (Workflowsystem, Dokumentenverwaltungssystem, o. .).
In groen Organisationen bedeutet alleine die Einrichtung eines neuen
Benutzers, der sich auf allen fr ihn freigegebenen Rechnern anmelden
knnen soll, einen hohen administrativen Aufwand, da beim Stand-alone-
Betrieb jeder einzelne dieser Rechner dementsprechend konfiguriert werden
muss. Moderne netzfhige Betriebssysteme (z. B. Unix, Windows NT, Novell)
sind daher mit Mechanismen ausgestattet, die den administrativen Aufwand
verringern sollen (z. B. zentrale Benutzerverwaltung). Soll allerdings die
Verwaltung aller Hard- und Software-Komponenten eines lokalen Netzes auf
allen Ebenen (technisch und organisatorisch) in einheitlicher Weise erfolgen,
so mssen einerseits technische Hilfsmittel in Form von Management-
systemen eingesetzt werden, deren erfolgreicher Einsatz andererseits aber
auch von einer zu erstellenden Managementstrategie abhngt. Die Vorgaben
und Regeln der Managementstrategie werden dann durch die Systemad-
ministration mit Hilfe der Managementsoftware umgesetzt. Eine Manage-
mentstrategie muss individuell auf die Bedrfnisse der jeweiligen Unter-
nehmen bzw. Behrden angepasst sein. Hierzu mssen folgende Schritte
durchgefhrt werden:
Festlegung der vom Managementsystem zu verwaltenden Objekte
Nach der Durchfhrung der Bestandsaufnahme (siehe M 2.168 IT-System-
Analyse vor Einfhrung eines Systemmanagementsystems) muss festgelegt
werden, welche Bereiche des IT-Systems durch ein zu beschaffendes
Managementsystem verwaltet werden sollen:
- Welche Rechner bzw. Hardware sollen in das Managementsystem einbe-
zogen werden?
- Welche Software soll einbezogen werden?
- Welche Benutzer bzw. Benutzergruppen werden einbezogen?
Festlegung der im Managementsystem anzuwendenden Sicherheitsricht-
linien
Neben diesen Entscheidungen mssen aber auch schon existierende Vor-
schriften und Methoden einbezogen werden. So muss z. B. die festgelegte
Sicherheitspolitik der Behrde bzw. des Unternehmens, die Datenschutzricht-
linien und die Richtlinien zur Einfhrung neuer Software in das Manage-
mentkonzept einflieen, da die geltenden Vorschriften auch beim Einsatz
eines Managementsystems beachtet und umgesetzt werden mssen. Auch fr
den Gebrauch des Managementsystems selbst sind Regelungen zu treffen bzw.
existierende Regelungen auf Validitt zu prfen und gegebenenfalls anzupas-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sen, und dann auch anzuwenden. Dies gilt insbesondere in den Bereichen:
- Zugriffsrechte auf Managementinformationen
- Dokumentation des Managementsystems
- Erstellung oder Abgleich von Notfallplnen fr den Ausfall des Manage-
mentsystems oder einzelner Komponenten
Im Vorfeld sollten auch bereits die Reaktionen auf Verletzung der Sicher-
heitspolitik im Bereich Systemmanagement festgelegt werden. hnlich wie in
anderen IT-Bereichen, muss auch fr den Bereich des Systemmanagements
eine Sicherheitspolitik festgelegt bzw. die vorhandene Sicherheitspolitik des
Unternehmens bzw. der Behrde auch auf den Bereich Systemmanagement
angewandt werden. Da ein Managementsystem mit wichtigen Netz- und
Systemkomponenten interagiert und deren Funktion verwaltet und berwacht,
sind Verletzungen der Sicherheitspolitik in diesem Bereich als besonders
schwer anzusehen. Insbesondere sind hier Regelungen und Vorgehensweisen
zu definieren, die nach einer solchen Sicherheitsverletzung zum Einsatz
kommen. Diese sind einerseits technischer Natur (z. B. Vergabe neuer
Passwrter fr alle Benutzer nach Kompromittierung der Management-
konsole), aber auch organisatorischer Natur.
Revision, Datenschutzbeauftragte und IT-Sicherheitsmanagement sollten
schon in der Planungsphase einbezogen werden. Nach Einfhrung des
Managementsystems mssen die ihnen hier obliegenden Aufgaben in Bezug
auf das Managementsystem klar sein. Beispiel: Der Datenschutzbeauftragte
kann schon in der Planungsphase auf die Einhaltung der Datenschutzricht-
linien achten, z. B. welche Benutzerinformationen im Rahmen des System-
managements erfasst werden sollen bzw. drfen. Nach Einfhrung des
Systems muss er zudem in der Lage sein, die Einhaltung der Richtlinien zu
berprfen. hnliches gilt fr die Zustndigkeitsbereiche des Revisors und
des IT-Sicherheitsbeauftragten.
Festlegung der Randbedingungen fr die Produktauswahl des Manage-
mentsystems
Die Einfhrung eines Systemmanagementsystems erfordert eine umfangreiche
und sorgfltige Planung. Teile der Systemmanagementstrategie hngen zudem
davon ab, ob sie mit einem konkreten Produkt realisiert werden knnen oder
nicht. Dies fhrt dazu, dass die Erstellung der Managementstrategie und die
(Vor-)Auswahl eines Produktes iteriert werden mssen.
Folgende Punkte sollten bei der Erstellung der Systemmanagementstrategie
Bercksichtigung finden:
- Ist mehr als eine Managementdomne ntig? Wenn ja: Wie sind diese zu
bilden? Managementdomnen erlauben die Einteilung der Komponenten
des zu verwaltenden Systems in Gruppen. Die einzelnen Gruppen knnen
voneinander getrennt verwaltet werden. Die Aufteilung in verschiedene
Managementdomnen ist fr kleinere und mittlere zu verwaltende Systeme
nicht zwingend, untersttzt jedoch ein strukturierteres Systemmanagement.
Fr groe zu verwaltende Systeme ist die Aufteilung in verschiedene Ma-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nagementdomnen in der Regel zwingend. Die Planung der Manage-

mentregionen hngt dabei von mehreren Faktoren ab:
- Netztopologie
Insbesondere fr mittlere Systemgren bietet sich die Aufteilung
des Systems in Managementdomnen entsprechend der konkreten
Netztopologie an (gerade auch, wenn es z. B. keine unterschied-
lichen Verantwortlichkeiten gibt).
- Organisatorische Verantwortlichkeiten innerhalb des Unternehmens
oder der Behrde
So kann die Organisationsstruktur mit dem Managementsystem
nachgebildet werden, so dass z. B. Domnen wie "Rechnungs-
wesen", "Programmierung" oder auch "Bereich Produktion",
"Bereich Softwareentwicklung" entstehen.
Auch sicherheitstechnische Grnde, die sich in der Management-
politik niederschlagen, knnen zu mehreren Managementregionen
fhren. Dies ist insbesondere dann der Fall, wenn Management-
aufgaben fr bestimmte Organisationseinheiten delegiert werden
sollen, ohne dass der lokale Administrator Zugriffsrechte auf die
Managementfunktionen fr die Komponenten auerhalb seines
Zustndigkeitsbereiches haben soll.
- vorhandene Infrastruktur
Hier ist z. B. die geographische Verteilung von Filialen oder die
rumliche Verteilung von Arbeitsgruppen ber die Stockwerke eines
Gebudes zu betrachten.
- Sicherheitsbetrachtungen
- Mehrere Managementregionen knnen dann ntig werden,
wenn das Managementprodukt zwar verschiedene Verschls-
selungsmechanismen pro Region untersttzt, von denen
jedoch pro Region in der Regel nur eine zum Einsatz kommen
kann. Sollen zwischen einzelnen Managementkomponenten
tatschlich verschiedene Mechanismen zum Einsatz kommen,
so sind mehrere Managementregionen ntig. Beispiel: Ein
System aus mehreren Datenbank-Servern mit sensitiven Daten
und den zugehrigen Clients, die selbst keine Daten speichern,
wird verwaltet. Die Managementkonsole soll mit den Servern
nur stark verschlsselt kommunizieren, da auch die
Datenbanken ber das Managementsystem verwaltet werden.
Die Kommunikation mit den Clients soll hingegen aus
Performancegrnden nur schwach verschlsselt geschehen. In
diesem Fall mssen in der Regel zwei Managementregionen
gebildet werden: eine Region, in der die Server enthalten sind,
und eine zweite Region, die die Clients umfasst.
- Mehrere Managementregionen erhhen die Ausfallsicherheit,
da z. B. beim Ausfall einer Managementregion die restlichen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Regionen unabhngig davon weiterhin verwaltet werden

knnen.
- Einfluss hat auch die Anzahl der zu verwaltenden Rechner pro
Managementregion. Die meisten Produkte geben Empfehlun-
gen ber die Anzahl der Rechner, die durch den Manage-
mentserver einer Region verwaltet werden knnen. Eine Zahl
von 200 Rechnern pro Server ist aber keine Seltenheit.
- Welche Maschinen sollen als Managementserver dienen? In der Regel ist
mit steigender Anzahl von Clients an einem Managementserver mit
Performanceeinbuen zu rechnen. Dies muss bei der Planung berck-
sichtigt werden.
- Welche physikalische Anordnung mssen die Managementserver haben
und wo werden sie aufgestellt? Die Lokation eines Servers hat z. B.
Einfluss darauf, wie Rechner, die von diesem Server verwaltet werden
sollen, ber das Netz an diesen angebunden sind. Bei einigen Plattformen
gibt es z. B. Mindestanforderungen an die Kommunikationsbandbreite
zwischen Server und Client (so untersttzt z. B. TME 10 keine Anbindung
von Clients ber Leitungen mit weniger als 14.4 Kbps). Dies hat direkte
Auswirkungen auf die mgliche Managementsystemkonfiguration und
macht z. B. die Neuanschaffung von Rechnern oder den Ausbau von Netz-
verbindungen ntig.
- Sind so genannte Gateways oder Proxies ntig, die ein hierarchisch aufge-
bautes Management und/oder den Anschluss an Produkte von Drittan-
bietern ermglichen?
- Einige Systeme unterscheiden zwischen so genannten "Managed Nodes"
und "Endpoints". Bei beiden handelt es sich um Arbeitsplatzrechner, sie
unterscheiden sich aber in der Art und Weise, wie diese in das Manage-
mentsystem eingebunden sind: So halten "Endpoints" z. B. im Unterschied
zu "Managed Nodes" keine eigene lokale Datenbank mit Management-
informationen vor und knnen auch nicht zur Weiterleitung von Manage-
mentinformationen an weitere Rechner benutzt werden. Hier muss ent-
schieden werden, welche Maschinen als "Managed Nodes" in das
Managementsystem eingebunden sein sollen und welche lediglich als
"Endpoints" verwaltet werden. In der Regel sollte das Gros der Arbeits-
platzrechner als "Endpoint" eingebunden werden.
Die so erstellte Managementstrategie induziert eine Reihe von Anforderungen
an das zu beschaffende Managementprodukt. Durch die Gewichtung der
Anforderungen ergibt sich eine konkrete Produktauswahl. Die Management-
strategie muss nun dahingehend berprft werden, ob sie mit dem zur Verf-
gung stehenden Funktionsumfang vollstndig umgesetzt werden kann. Eine
Reformulierung der Strategie kann dadurch in einzelnen Bereichen notwendig
sein. Beispiel: Die Produktauswahl ergibt, dass das System, das starke Ver-
schlsselung untersttzt, leider nicht die Delegation von Verwaltungsaufgaben
an "Subadministratoren" erlaubt. Daraufhin muss die Managementstrategie
angepasst werden (korrekte Gewichtung der Anforderungen vorausgesetzt).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.170 Anforderungen an ein

Systemmanagementsystem
Ein Systemmanagementsystem dient zur Untersttzung eines Administrators
eines lokalen Netzes (oder Virtuellen Lokalen Netzes). Ein Systemmanage-
mentsystem muss daher gewisse Voraussetzungen erfllen, um den Admini-
strator geeignet untersttzen zu knnen. Die Anforderungen an ein solches
System hngen jedoch wesentlich vom geplanten Einsatz (siehe M 2.169
Entwickeln einer Systemmanagementstrategie) und von der gewhlten
Architektur des Systemmanagementsystems ab (siehe M 2.171 Geeignete
Auswahl eines Systemmanagement-Produktes).
Ein Systemmanagementsystem sollte folgende Funktionen bereitstellen:
- Benutzermanagement
Hierzu gehren das Hinzufgen, Verndern und Lschen von Benutzer-
und Gruppenkonten.
- Policymanagement
Zugriffsrechte sollten sowohl fr Zugriffe aus dem und in das lokale Netz
als auch fr Zugriffe auf das bzw. vom Internet verwaltet werden knnen.
- Softwaremanagement
Das Hinzufgen, Lschen und Aktualisieren von Softwarekomponenten
sollte mit dem Systemmanagementsystem mglich sein.
Daneben ist insbesondere fr die Einfhrungsphase das automatische
Feststellen der installierten Software u. U. wichtig. Eine Verwaltung von
Softwarelizenzen ist zwar wnschenswert, wird von heutigen Systemen
jedoch kaum untersttzt (siehe auch Applikationsmanagement unten.
Ausnahme: Lizenzen liegen z. B. als Dateien vor, so dass die Lizenzdateien
im Rahmen der Dateiverteilungsmechanismen eines Managementsystems
verwaltet werden knnen).
- Feststellen, Verndern und Verwalten von Systemkonfigurationsdaten.
- Verwalten von Applikationsdaten
Es muss mglich sein, Dateien eines Datenbanksystems oder Konfigura-
tionsdateien einer Applikation zu verwalten, so dass z. B. das Verteilen
einer neuen Version einer Datenbank oder die Verteilung neuer Konfigu-
rationsdateien mglich ist.
- berwachen von Systemkomponenten
Dies kann auch fr externe Komponenten sinnvoll sein, die nicht der
eigenen Administration unterliegen, zum Beispiel fr den Router des
Internet Service Providers (ISP), ber den der Internet-Anschluss realisiert
ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Applikationsmanagement
Das Verwalten von Software auf Anwendungsebene sollte mglich sein,
z. B. die Verwaltung von HTTP-Zugriffsrechten auf die Daten eines
WWW-Servers ("Realms"). Diese Art von Management wird in der Regel
kaum untersttzt, da hierzu die Kooperation der Applikation selbst erfor-
derlich ist.
Idealerweise lsst ein solches System die Delegation von administrativen Auf-
gaben zu, so dass z. B. ein Systemverwalter einem Arbeitsgruppensystem-
administrator das Recht zum Installieren von Software auf den Rechnern der
Arbeitsgruppe einrumen kann. Dieser Mechanismus ist insbesondere in
mittleren und groen Netzen notwendig.
Die Netz- und Systemadministration werden in der Regel durch die gleichen
administrativen Einheiten in einem Unternehmen bzw. einer Behrde durch-
gefhrt. Da in einigen Bereichen die Aufgabentrennung zwischen
Netzadministration und Systemadministration nicht klar ist, empfiehlt es sich
darauf zu achten, inwieweit ein vorhandenes Netzmanagementsystem in ein zu
beschaffendes Systemmanagementsystem integriert werden kann.
Neben diesen vorwiegend funktionalen Anforderungen ergeben sich auch
technische Anforderungen im Rahmen der Kriterien, die fr die Auswahl einer
Systemmanagementsoftware relevant sind (siehe M 2.171 Geeignete Auswahl
eines Systemmanagement-Produktes). Besonders sind hier folgende
hervorzuheben:
- Das Managementsystem muss in der Lage sein, die Betriebssysteme aller
fr das Management genutzten und aller verwalteten Rechner zu
untersttzen (betriebssystemspezifische Komponenten des Management-
systems, graphische Benutzungsoberflche).
- Existiert bereits ein lokales Datenbanksystem, so sollte das Management-
system die Mglichkeit besitzen, seine Managementinformationen im vor-
handenen Datenbanksystem zu speichern.
- Das Managementsystem sollte erweiterbar sein. Dies betrifft einerseits die
Komponenten des Managementsystems (z. B. Modulkonzept mit der
Mglichkeit, Module jederzeit nachkaufen und integrieren zu knnen),
aber auch die Funktion des Managementsystems (z. B. Programmier-API,
um eigene Komponenten anschlieen zu knnen).
Generell knnen die in M 2.171 Geeignete Auswahl eines Systemmanagement-
Produktes vorgestellten Kriterien zur Kategorisierung von Anforderungen im
Rahmen der vorliegenden Manahme herangezogen werden. Fr ausgesuchte
Kategorien ergeben sich die Anforderungen durch die Festlegung einer
Vorgabe im Rahmen des jeweiligen "Wertebereiches".
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.171 Geeignete Auswahl eines Systemmanagement-

Produktes
Nach Aufnahme der aktuellen Systemsituation (siehe M 2.168 IT-System-
Analyse vor Einfhrung eines Systemmanagementsystems) und Festlegung der
Managementstrategie (siehe M 2.169 Entwickeln einer
Systemmanagementstrategie) muss ein geeignetes Systemmanagementsystem
ausgewhlt werden. Je nach Gre des zu verwaltenden Systems knnen hier
unterschiedliche Realisierungen zweckmig sein:
- Fr kleine Systeme kann das Systemmanagement von der Systemadmini-
stration "von Hand" erledigt werden.
- Fr kleine und mittlere Systeme kann das Systemmanagement auch durch
eine Sammlung von einzelnen Tools durchgefhrt werden.
- Fr groe Systeme sollte ein Systemmanagementsystem benutzt werden.
Moderne netzfhige Betriebssysteme sind in der Regel schon mit Funktionen
ausgestattet, die eine zentrale Verwaltung z. B. von Benutzern und Benutzer-
gruppen erlauben. Fr den Unix-Bereich kann hier z. B. NIS oder NIS+
genannt werden, im Windows-Bereich erlaubt das Windows NT-Domnen-
Konzept eine zentrale Benutzerverwaltung ber den Domain Controller.
hnliche Mglichkeiten bietet auch Novell mit Intranetware an. In der Regel
existieren zudem auch Mglichkeiten, ein netzweites Policymanagement zu
betreiben.
In kleineren und mittleren Netzen stellen daneben das Softwaremanagement,
das Management der Rechnerkonfigurationen sowie das berwachen von
Systemkomponenten die drngensten Problembereiche dar. Hier knnen dann
zustzliche Softwaretools eingesetzt werden, die die Aufgaben einzeln ber-
nehmen knnen. Insbesondere in den Bereichen, die auch durch die Diszipli-
nen des Netzmanagements abgedeckt sind (Konfigurationsmanagement,
berwachung), kann der Einsatz eines Netzmanagement-Tools in Betracht
gezogen werden.
Fr den Windows-Bereich lassen sich z. B. Tools wie das "Novell Zero
Administration Kit", das den Administrator bei der Installation neuer Rechner
untersttzt, die "Microsoft Management Console", die eine einheitliche
zentrale Sicht auf alle Administrationstools anbietet, sowie den "Microsoft
Systems Management Server (SMS)" nennen. So bietet z. B. das Produkt SMS
dem Administrator folgende Mglichkeiten:
- Inventarisieren von Hard- und Software-Komponenten
- Installieren und Verteilen von Daten und Applikationen auf Netzrechnern
- Kontrolle bei der Ausfhrung von Netzanwendungen
- Untersttzung bei der Administration von Rechnern ber das Netz
- berwachung des Netzverkehrs
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SMS ist dabei allerdings nicht fr eine heterogene Umgebung ausgelegt.

Zudem erfolgt die Fernwartung nur halbautomatisch und erfordert einen
Administrator vor Ort, so dass der Einsatz nur fr kleinere und rumlich
zusammenliegende Netze angezeigt ist.
Fr den Unix-Bereich kann z. B. zur Verwaltung und Verteilung von Software
das Programm "rdist" eingesetzt werden, mit dem auf entfernten Rechnern
Software installiert oder aktualisiert werden kann. Dabei ist es mglich, aus
einem zentralen Softwarepool genau die Produkte auf den jeweiligen
Rechnern zu installieren, die von den Mitarbeitern fr die Erledigung ihrer
Aufgaben bentigt werden. Weitere, auch kostenfrei, erhltliche Zusatz-
programme (meist aus dem universitren Umfeld) erlauben z. B. die ber-
wachung des Netzes ber SNMP.
Die so zusammengestellten Lsungen bieten fr kleinere und mittlere Netze
eine kostengnstige Alternative. Allerdings setzen sie in der Regel einen ver-
sierten Administrator voraus, der auch u. U. durch Eigenprogrammierung
Anpassungen an lokale Gegebenheiten vornimmt oder Zusatzfunktionalitt
integriert.
Fr grere und groe Netze sind solche Lsungen jedoch ungeeignet, da die
Funktionalitten in verschiedenen, nicht integrierten Tools angesiedelt ist. Fr
groe Unternehmens- oder Behrdennetze kommen nur Systemmanage-
mentsysteme in Frage. Vor der Einfhrung eines solchen Systems sollte
beachtet werden, dass dies in der Regel einen betrchtlichen Eingriff in das
laufende System darstellt und gut geplant werden muss. Nicht selten dauert
die Einfhrung mehr als 12 Monate, bei einer mindestens sechsstelligen
Investitionssumme fr grere Netze. Die Wahl des richtigen
Managementsystems ist deshalb wichtig. Folgende Kriterien sollten bei der
Wahl des zu beschaffenden Systems beachtet werden:
- Welchen Funktionsumfang bietet das Produkt an?
- Kosten
- fr die Anschaffung der Software
- fr die Anschaffung zustzlicher Hardware (Bei einigen Systemen
mssen ein oder mehrere zentrale Managementserver angeschafft
werden.)
- fr Installations- und Betriebsaufwand (U. U. mssen sogar Externe
engagiert werden.)
- fr die Schulung der Mitarbeiter
- andere (z. B. Migrationskosten bei einer existierenden Plattform,
Anpassung/Neuentwicklung lokaler Software, bauliche Manahmen
z. B. gesicherter Serverraum)
- Investitionssicherung
- Inwieweit ist das Systemmanagement-Produkt skalierbar (z. B.
Anzahl der Rechner erweiterbar)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Kann die Plattform mit dem Unternehmen wachsen (z. B. Anzahl

der mglichen Managementdomnen, Delegation von Aufgaben)?
- Wie sind die Migrationspfade zur Plattform?
- Wie sind die Migrationspfade von dieser Plattform zu einer anderen
Plattform?
- Integrationsmglichkeit mit anderen Produkten
- Welche Server- bzw. Client-Systemplattformen werden untersttzt?
- Kann ein bestehendes Netzmanagementsystem integriert werden?
- Kann ein bestehendes Datensicherungssystem integriert werden?
- Welche Applikationen von Drittanbietern gibt es fr dieses Produkt?
- Zuverlssigkeit und Ausfallsicherheit
- Gibt es Aussagen oder sogar Garantien ber maximale
Ausfallzeiten?
- Ist ein Hotswap fr zentrale Komponenten mglich?
- Existiert ein systemeigener Backup- und Recovery-Mechanismus?
Bei einem Ausfall des Managementsystems mssen innerhalb des
Managementsystems Mechanismen zum geregelten Wiederanlaufen
existieren. Dies umfasst u. U. das Einspielen von Daten aus einer
Datensicherung und die automatische Konsistenzprfung -
idealerweise mit Konfliktauflsung bei der Feststellung von
Inkonsistenzen.
- Werden regelmig Updates zur Verfgung gestellt? Sind sie
einfach einspielbar?
- Sicherheit: Zugriffsbeschrnkungen auf die Managementfunktionen
- Kann der Zugriff auf Benutzer-ID-Ebene (Welcher Benutzer darf
was?) eingeschrnkt werden?
- Kann der Zugriff auf Komponentenebene (Welcher Rechner darf
was?) eingeschrnkt werden?
- Kann der Zugriff auf die ausfhrbaren Kommandos Benutzer- oder
Systemabhngig eingeschrnkt werden?
- Kann eine Aufteilung der Administrationsttigkeiten vorgenommen
werden? Kann also z. B. die Verwaltung von Komponenten auf
bestimmte Bereiche eingeschrnkt werden (z. B. nur die Abteilungs-
rechner)?
- Sicherheit: Administration von Rechnern ber das Netz
- Wie sind Fernzugriffe abgesichert?
- Knnen Fernzugriffe verschlsselt erfolgen?
- Ist sichergestellt, dass eine (starke) Authentisierung vor einer
Fernadministration erforderlich ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist es mglich, die Berechtigung fr Fernadministration auf

bestimmte Personen oder Rollen einzuschrnken?
- Wird der Benutzer automatisch ber Fernzugriffe informiert?
- Sicherheit: Datensicherheit, Datenschutz
- Werden die gesammelten Daten sicher abgelegt (Zugriffsbeschrn-
kungen, Verschlsselung)?
- Findet die Datenbertragung zwischen den Managementkompo-
nenten gesichert statt (Authentisierung, Verschlsselung, Integri-
ttssicherung)?
- Kann die Art der gesammelten Informationen reguliert werden
(Anonymisierung, Rckverfolgung, Beweisbarkeit)?
- Ist die Integration von Virensuchprogrammen mglich?
- Welche Protokollierungsmglichkeiten werden angeboten?
- Kann die lokale Softwareeinspielung berwacht oder verhindert
werden?
- Benutzerfreundlichkeit
- Gibt es ein graphisches Benutzungsinterface (z. B. X-Windows,
Motif, Windows-Oberflche, Web-Browser)?
- Wie einfach ist die Navigation?
- Wird die lokale Sprache oder auch mehrere Sprachen (bei globalem
Einsatz) untersttzt?
- Lassen sich Programme einfach ausfhren (auch auf entfernten
Rechnern)?
- Wie einfach lsst sich das Interface vom Benutzer umgestalten?
- Werden Ausnahmen und Alarmierungen geeignet angezeigt?
- Ist das Monitoring, auch im Detailgrad, einstellbar?
- Wird die Komplexitt von Netzkomponenten geeignet "versteckt"
(So dass der Benutzer nicht ein Experte fr die jeweilige
Komponente, die verwaltet werden soll, sein muss)?
- Knnen alle Funktionen ber das gleiche Benutzungsinterface
erreicht werden?
- Sind Onlinehilfen und Anleitungen vorhanden?
- Ergonomie beim Management komplexer Systeme
- Werden verschiedene Netzprotokolle, Netzkomponenten und
Betriebssysteme untersttzt?
- Wie geht die Plattform mit geographisch verteilten Systemen um
und wie ist deren Reprsentation?
- Wie einfach ist es, neue Komponenten zu integrieren oder aus dem
System zu entfernen (Autodiscovery, manuell)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Konformitt zu Standards (je nach Umgebung kann die Konformitt zu

mindestens einem Standard erforderlich sein)
- Plattformen
- Distributed Management Environment (DME) von der Open
Software Foundation (OSF)
- Spezifikation der Desktop Management Task Force (DMTF)
- OMNIpoint Spezifikation des Network Management Forum
(NMF)
- Datenbank
- Welche DBMSe (Data Base Management Systeme) werden
untersttzt?
- Wird SQL als Anfragesprache untersttzt, fr den Fall, dass
die Managementsoftware eine eigene Datenbank enthlt?
- CORBA (Common Object Request Broker Architecture) der Object
Management Group (OMG)
- Application Program Interface (API), fr den Fall, dass eigene
Erweiterungen des Managementsystems notwendig sind (z. B. APIs
fr SNMP, XMP, DMI).
Die hier angefhrten Aspekte sind als Anhaltspunkte bei der Bewertung von
Managementsystemen zu verstehen. Je nach lokalen Gegebenheiten sollten
aufgrund der aktuellen Systemsituation (siehe M 2.168 IT-System-Analyse vor
Einfhrung eines Systemmanagementsystems) und aufgrund der
Managementstrategie (siehe M 2.169 Entwickeln einer
Systemmanagementstrategie) Anforderungen an das Managementsystem
formuliert werden, die als "K.O.-Kriterien" bei der Entscheidung her-
angezogen werden knnen. Die obigen Kriterien sollten immer eine Gewich-
tung erfahren, die die lokalen Prferenzen wiedergeben.
Die Anforderungen an das Managementsystem und die Leistungen des ausge-
whlten Managementsystems sind in der Regel nicht vollstndig in Einklang
zu bringen. Dies macht es notwendig, die erstellte Managementstrategie nach
Auswahl des konkreten Produktes an dessen Funktionsumfang anzupassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.172 Entwicklung eines Konzeptes fr die WWW-

Nutzung
Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, IT-
Bevor ein Webangebot eingerichtet wird, muss zunchst in einem Konzept
dargestellt werden, welche Informationen und Dienste angeboten werden
sollen. Das Konzept sollte mindestens einen allgemeinen und einen organisa-
torischen Teil enthalten:
- Im allgemeinen Teil sollte beschrieben werden, Ziele und Inhalte fest-
legen
- welche Ziele die Organisation mit dem Webangebot verfolgt,
- welches die Zielgruppen des Webangebots sind und
- welche Informationen oder Dienstleistungen in dem Webangebot zur Ver-
fgung gestellt werden sollen.
- Im organisatorischen Teil sollte eine grobe bersicht darber gegeben Erscheinungsbild und
Redaktion
werden, wer in der Organisation verantwortlich ist fr
- die Bereitstellung und Aktualisierung der Informationen und
- die Ausarbeitung und Pflege des optischen Erscheinungsbildes des Web-
angebots (Webdesign).
Im organisatorischen Teil des WWW-Konzepts sollte auch festgelegt werden, Technik
wer fr die technischen Aspekte des Betriebs des Webservers verantwortlich
ist.
Das Konzept fr das Webangebot sollte regelmig auf Aktualitt berprft
werden. Bei nderungen in den Zielen oder Strategien der Organisation muss
geprft werden, welche Auswirkungen diese auf das WWW-Konzept haben.
Bei der Entwicklung des Konzeptes sollten folgende Aspekte bercksichtigt
werden:
Ein Webangebot kann als rein interner Informationsdienst eingesetzt werden, Verwendungszweck
beeinflusst Sicherheits-
als Mittelpunkt eines Intranets, oder als ffentliches Angebot im Internet, das anforderungen
verschiedene Dienste anbietet. Je nach Art der geplanten Ausgestaltung unter-
scheiden sich auch die Sicherheitsanforderungen, die an den Webserver ge-
stellt werden mssen. In einer kleinen Organisation, in der ein Webserver als
Intranet-Server ohne kritische Anwendungen betrieben wird, sehen die Anfor-
derungen ganz anders aus als fr einen Webserver, der ans Internet ange-
schlossen werden soll und vielleicht sogar Daten enthlt, die nicht jeder ab-
rufen knnen soll.
Wenn sowohl im Intranet als auch im Internet WWW-Dienste angeboten wer- Firewall
den sollen, empfiehlt es sich, hierfr zwei getrennte Systeme einzusetzen:
einen Intranet-Webserver und einen Internet-Webserver. Wenn der Internet-
Webserver auch mit dem internen Netz verbunden werden soll, muss der
bergang zum internen Netz durch eine Firewall geschtzt werden, siehe Ka-
pitel 7.3 Sicherheitsgateway (Firewall). Wenn vorgesehen ist, dass Teile der
Inhalte des Webservers
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
aus einer Datenbank kommen sollen, muss auch die Verbindung zur Daten-
bank in das Firewall-Konzept fr den Webserver einbezogen werden. Was bei
der Anordnung von Informationsservern zu beachten ist, ist in M 2.77
Integration von Servern in das Sicherheitsgateway beschrieben. Bei der
Erarbeitung des Konzepts fr das Webangebot sollte zumindest grob
festgelegt werden, wie die Anbindung ans Internet geregelt ist und welche
Arten von Verbindungen zum internen Netz bentigt werden.
Der Anschluss ans Internet darf erst dann erfolgen, wenn berprft worden ist,
dass mit dem gewhlten WWW-Konzept sowie den personellen und organi-
satorischen Randbedingungen alle Risiken beherrscht werden knnen.
Ein Webserver fr die Prsenz einer Organisation im Internet muss nicht Outsourcing in Betracht
ziehen
zwangslufig von dieser selbst betrieben werden. Wenn die Betriebskosten
oder der Administrationsaufwand zu hoch oder die Restrisiken zu unkalku-
lierbar erscheinen, knnen auch die entsprechenden Angebote von Internet
Service Providern oder anderen Dienstleistern in Anspruch genommen wer-
den, einen Webserver durch diese betreiben zu lassen. In diesem Fall muss das
Kapitel 3.10 Outsourcing bercksichtigt werden.
- Existiert ein Konzept fr das Webangebot?
- Wird das Konzept regelmig berprft und ntigenfalls angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.173 Festlegung einer WWW-Sicherheitsstrategie

Webserver sind fr Angreifer sehr attraktive Ziele, da einem erfolgreichen
Angriff oft sehr groe Publizitt zuteil wird. Daher muss der Absicherung
eines Webservers ein hoher Stellenwert eingerumt werden. Vor dem Einrich-
ten eines Webservers sollte in einer WWW-Sicherheitsstrategie beschrieben
werden, welche Sicherheitsmanahmen in welchem Umfang umzusetzen sind.
Anhand der in der WWW-Sicherheitsstrategie festgelegten Anforderungen
kann dann regelmig berprft werden, ob die getroffenen Manahmen aus-
reichend sind.
In der Sicherheitsstrategie fr den Betrieb eines Webservers sollten die folgen-
den Fragen beantwortet werden:
- Wer darf welche Informationen einstellen?
- Wer ist fr die Aktualitt und Korrektheit der Informationen verantwort-
lich? Falls in einem Bereich mehrere Organisationseinheiten oder Personen
Informationen einstellen drfen, so muss auerdem ein Gesamtverantwort-
licher benannt sein, der bei Konflikten entscheidet.
- Welche anderen Systeme und welche Netzverbindungen sind fr den siche-
ren Betrieb des Webservers wichtig? Knnen zeitweise Strungen oder
Ausflle dieser Systeme gegebenenfalls berbrckt werden?
- Wie werden die Verantwortlichen geschult, insbesondere hinsichtlich mg-
licher Gefhrdungen und einzuhaltender Sicherheitsmanahmen?
- Welche Informationen drfen nicht auf dem Webserver eingestellt werden
(z. B. weil die Inhalte vertraulich sind, nicht zur Verffentlichung geeignet
sind oder nicht der Firmen- bzw. Behrdenpolitik entsprechen)?
- Welche Zugriffsbeschrnkungen auf den Webserver sollen realisiert wer-
den (siehe auch M 2.175 Aufbau eines WWW-Servers)?
Insbesondere wenn der Webserver ein ffentliches Webangebot beherbergt, Vorgehen bei Sicher-
heitsvorfllen
mssen in der Sicherheitsstrategie auch Reaktionen auf bestimmte webserver-
spezifische Sicherheitsvorflle festgelegt werden (siehe auch Kapitel 3.8 Be-
handlung von Sicherheitsvorfllen).
- Es sollte festgelegt werden, wie verfahren wird, wenn falsche Informatio- Informationsleck
nen auf dem Webserver verffentlicht wurden. Eventuell reicht das bloe
Lschen der entsprechenden Dokumente nicht aus, da diese schon von Be-
suchern gelesen wurden. Ein solcher Vorfall muss zumindest dokumentiert
werden. In Abhngigkeit von der Brisanz der Informationen mssen even-
tuell die Pressestelle oder die Behrden- oder Unternehmensleitung infor-
miert werden.
- Es sollte beschrieben werden, was beim Verdacht auf einen Hackerangriff Hackerangriff
auf dem Webserver zu tun ist. Wichtig ist vor allem die Frage, wann der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Server notfalls vom Netz genommen werden muss und wer die Entschei-
dung dazu trifft.
- Es sollte eine Reaktion auf ein Defacement des Webservers festgelegt wer- Defacement
den, also fr den Fall, dass nach einem erfolgreichen Einbruch auf dem
Webserver Daten oder besonders die Homepage von den Angreifern vern-
dert wurden. In einem solchen Fall mssen grundstzlich auch die Behr-
den- oder Unternehmensleitung sowie die Pressestelle bzw. die fr ffent-
lichkeitsarbeit zustndige Organisationseinheit informiert werden.
Diese Punkte sollten selbst dann bercksichtigt werden, wenn der Schutzbe-
darf des Webangebots ansonsten nur als niedrig eingeschtzt wird. Insbeson-
dere ein Hackerangriff oder ein Defacement knnen unabhngig vom konkre-
ten Schutzbedarf bei allen ffentlichen Webangeboten passieren.
Teil einer Sicherheitsstrategie muss auch die regelmige Informationsbe-
schaffung ber potentielle Sicherheitslcken sein, um rechtzeitig Vorsorge
dagegen treffen zu knnen. Neben den in M 2.35 Informationsbeschaffung
ber Sicherheitslcken des Systems angesprochenen Informationsquellen ist
fr Sicherheitshinweise zur WWW-Nutzung besonderes die "World Wide
Web Security FAQ" eine wertvolle Quelle. Die Master-Kopie dieses Doku-
mentes ist unter http://www.w3.org/Security/Faq/ zu finden.
- Existiert eine Sicherheitsstrategie fr den Betrieb eines WWW-Servers?
- Werden die getroffenen Regelungen regelmig berprft und gegebenen-
falls angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.174 Sicherer Betrieb eines WWW-Servers

WWW-Server sind attraktive Ziele fr Angreifer und mssen daher sehr sorg-
fltig konfiguriert werden, damit sie sicher betrieben werden knnen. Das
Betriebssystem und die Software mssen so konfiguriert sein, dass der Rech-
ner so gut wie mglich gegen Angriffe geschtzt wird. Solange der Rechner
nicht entsprechend konfiguriert ist, darf er nicht ans Netz genommen werden.
Daher sollte ein WWW-Server, der Informationen im Internet anbietet, ent-
sprechend den folgenden Vorgaben installiert werden:
- Auf einem WWW-Server sollte nur ein Minimum an Programmen vorhan- Minimales Betriebs-
system
den sein, d. h. das Betriebssystem sollte auf die unbedingt erforderlichen
Funktionalitten reduziert werden und auch sonst sollten sich nur unbe-
dingt bentigte Programme auf dem WWW-Server befinden (siehe M 4.95
Minimales Betriebssystem).
- Ein WWW-Server sollte insbesondere keine unntigen Netzdienste enthal-
ten, verschiedene Dienste gehren auf verschiedene Rechner (siehe M 4.97
Ein Dienst pro Server).
- Der Zugriff auf Dateien oder Verzeichnisse muss geschtzt werden (siehe Zugriffsschutz
M 4.94 Schutz der WWW-Dateien).
- Die Kommunikation mit dem WWW-Server sollte durch einen Paketfilter
auf ein Minimum beschrnkt werden (siehe M 4.98 Kommunikation durch
Paketfilter auf Minimum beschrnken).
- Die Administration des WWW-Servers darf nur ber eine sichere Verbin-
dung erfolgen, d. h. die Administration sollte an der Konsole direkt, nach
starker Authentisierung (bei Zugriff aus dem LAN) oder ber eine ver-
schlsselte Verbindung (bei Zugriff aus dem Internet) erfolgen.
- Weiterhin sollte der WWW-Server vor dem Internet durch einen Firewall-
Proxy oder aber zumindest durch einen Paketfilter (siehe M 4.98
Kommunikation durch Paketfilter auf Minimum beschrnken beschrnken)
abgesichert werden. Er darf sich nicht zwischen Firewall und internem
Netz befinden, da ein Fehler auf dem WWW-Server sonst Zugriffe auf
interne Daten ermglichen knnte.
Je nach Art des WWW-Servers bieten sich unterschiedliche Mglichkeiten Minimale Rechte
zum Schutz an. Allen diesen Mglichkeiten gemeinsam ist allerdings, dass der
eigentliche Serverproze des WWW-Servers, der sogenannte http-Daemon
oder http-Dienst, nur mit eingeschrnkten Rechten ausgestattet sein sollte.
Nicht alle Webserver-Produkte ermglichen es, den Prozess direkt mit sehr
eingeschrnkten Rechten zu starten. Je nach eingesetztem Produkt muss daher
individuell geprft werden, wie ein minimales Rechteprofil realisiert werden
kann.
Der Webserver-Prozess sollte, wenn mglich, nur auf einen Teil des Datei-
baumes zugreifen knnen. Unter Unix kann dies z. B. mit dem chroot-Pro-
gramm realisiert werden. Kann ein Angreifer nun eine Schwachstelle ber den
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Webserver-Prozess ausnutzen, so hat er trotzdem keinen Zugriff zum eigentli-

chen Betriebssystem.
Auerdem sollten vom Hersteller mitgelieferte cgi-Skripte, asp-Dateien oder Beispielskripte entfernen
sonstige serverseitige Programme, die meist nur Beispielcharakter haben, voll-
stndig entfernt werden, da sie oft Schwachstellen enthalten.
Das Verzeichnis, in dem die abrufbaren Dateien gespeichert sind, sollte auf
einer eigenen Partition einer Festplatte liegen, um eine leichtere Wiederher-
stellung nach einem Festplattenschaden zu ermglichen. Auerdem sollten die
Unterverzeichnisse und Dateien einem speziellen Benutzer gehren (zum Bei-
spiel wwwadmin) und durch minimale Zugriffsrechte vor unbefugtem Zugriff
geschtzt werden.
Bei der Konfiguration der Webserver-Anwendung sollten, unabhngig von der
eingesetzten Webserveranwendung, einige grundlegende Aspekte bercksich-
tigt werden. Wie diese im einzelnen konfiguriert werden, hngt von der Web-
server-Anwendung ab.
Meist existieren Optionen, mit denen festgelegt werden kann, ob bei einer Indexdateien und Ver-
zeichnisinhalte
HTTP-Anfrage nach einem Verzeichnis (also ohne Angabe eines konkreten
Dateinamens), der Inhalt des betreffenden Verzeichnisses aufgelistet werden
soll, oder ob stattdessen bestimmte Dateien (beispielsweise index.html) zu-
rckgegeben werden sollen. Dies sollte folgendermaen konfiguriert werden:
- Falls eine Index-Datei existiert, wird diese zurckgeliefert.
- Falls nicht, wird eine entsprechende Fehlermeldung zurckgegeben.
Falls festgelegt werden kann, dass Programme oder cgi-Skripte nur in be- Ausfhrung von Pro-
grammen und Skripten
stimmten Verzeichnissen ausgefhrt werden drfen, so sollte diese Option auf
jeden Fall sehr eng eingestellt werden. Keinesfalls sollte die Ausfhrung von
Programmen fr den gesamten WWW-Bereich freigegeben werden. Es ist
empfehlenswert, wenn mglich fr Programme und Skripte ein eigenes Ver-
zeichnis anzulegen und die Ausfhrung nur in diesem Verzeichnis zu ge-
statten.
Oft kann festgelegt werden, ob Dateien oder Verzeichnisse, die mittels eines Symbolische Links oder
Verknpfungen
symbolischen Links (Unix) oder einer Verknpfung (Windows) in den
WWW-Dateibaum "eingeblendet" wurden, angezeigt werden sollen. Dies
sollte mglichst unterbunden werden, da auf diese Weise leicht Dateien zu-
greifbar werden knnen, die eigentlich nicht verffentlicht werden sollen.
Folgende Checkliste wird empfohlen:
1. Sind nur die bentigten Komponenten installiert?
2. Ist die Webserver-Anwendung so restriktiv wie mglich konfiguriert? Bei-
spielsweise sollten cgi-Programme entweder ganz gesperrt werden oder
aber die cgi-Programme auf ein eigenes Verzeichnis beschrnkt sein. Der
Dateizugriff des Webserver-Prozesses sollte auf einen Teil des Verzeich-
nisbaums eingeschrnkt sein. Fr Administration und Betrieb des Servers
sollten eigene unprivilegierte Benutzerkennungen verwendet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Sind alle berflssigen cgi-Programme, asp-Seiten, sonstige Demo-An-

wendungen und WWW-Seiten gelscht?
4. Sind nur die unbedingt ntigen Ports zugnglich (siehe auch M 4.97 Ein
Dienst pro Server)? Auf einem Webserver wird der HTTP-Dienst bli-
cherweise ber Port 80 angesprochen. Falls die Administration des Servers
oder die Pflege der WWW-Dateien ber das Netz erfolgt, knnen noch
weitere Dienste erforderlich sein. In diesem Fall sollte aber der Zugriff auf
diese Dienste so restriktiv wie mglich geregelt werden (siehe auch M 4.98
Kommunikation durch Paketfilter auf Minimum beschrnken)
5. Ist eine angemessene regelmige Sicherung des Datenbestandes gewhr-
leistet (siehe Kapitel 3.4 Datensicherungskonzept)?
6. Falls cgi-Programme genutzt werden, sind diese ausreichend sicher pro-
grammiert? Es drfen keine Eingabewerte ungeprft bernommen werden.
Es muss sichergestellt sein, dass Buffer-Overflows und Race-Conditions
ausgeschlossen sind. In allen Perl-Skripten sollte der Taint-Check aktiviert
sein.
7. Gibt es eine funktionierende Routine fr einen regelmigen Integritts-
check (z. B. Tripwire, siehe M 4.93 Regelmige Integrittsprfung)?
8. Wird die Konfiguration regelmig berprft? Werden Konfigurations-
nderungen dokumentiert?
Beispiel: Aufbau eines einfachen WWW-Servers
Als einfacher WWW-Server wird ein Server betrachtet, bei dem sich die In-
halte einzelner Seiten nur selten ndern, keine cgi-Programme verwendet
werden und es keinen besonderen Zugriffsschutz gibt. Die einzelnen WWW-
Dokumente werden ber einen Datentrger auf den WWW-Server eingespielt.
Bei einem solchen Server knnen alle Systemdateien und auch alle HTML-
Seiten mit einem Schreibschutz versehen werden. Ein Angreifer kann bei
einem solchen Aufbau zwar noch temporre Dateien und Protokolleintrge
abndern, das System selber aber nicht mehr. Ein solcher Zugriffsschutz sollte
durch ein physikalisch schreibgeschtztes Medium realisiert werden, z. B.
eine oder mehrere CD-ROMs oder eine schreibgeschtzte Wechselplatte. Zu-
mindest aber sollten regelmige Integrittsprfungen (siehe M 4.93
Regelmige Integrittsprfung.
In dem http-Daemon sollten die nicht bentigten Funktionalitten abgeschaltet
werden, wie z. B. die Mglichkeit zum Ausfhren von cgi-Skripten. Auf jeden
Fall sollten mitgelieferte cgi-Programme entfernt werden.
Bei einer hufig vorkommenden Variante eines einfachen Webservers knnen
die Dokumente mit entsprechenden Berechtigungen auf dem WWW-Server
interaktiv abgendert werden. In diesem Fall ist der Schutz vor unbefugten
Vernderungen und eine regelmige Integrittsprfung in kurzen Intervallen
besonders wichtig.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.175 Aufbau eines WWW-Servers

Um einen Webserver aufbauen zu knnen, muss neben adquater Hardware Inbetriebnahme eines
Webservers
auch entsprechende Software beschafft werden. Dafr stehen eine Vielzahl
von Produkten zur Verfgung. Bei der Auswahl ist neben der Stabilitt insbe-
sondere Wert auf die Sicherheitsmechanismen zu legen (zur Beschaffung und
Installation siehe auch Kapitel 9.1 Standardsoftware).
Organisationsstruktur anpassen
Es muss berlegt werden, welche Informationen im Internet bzw. in einem
Intranet zur Verfgung gestellt werden sollen. Weiterhin ist zu klren, wie und
wo Dokumente erstellt werden, wer welche Dokumente erzeugt, welche Do-
kumente wo zum Einsatz kommen und wer diese Dokumente bentigt. Auf
Basis dieser Erkenntnisse sollten dann Richtlinien fr ein einheitliches Er-
scheinungsbild von Dokumenten, Dateinamen und Verzeichnisnamen aufge-
stellt und nach Mglichkeit standardisierte Entwicklungswerkzeuge bestimmt
werden. Eventuell sollte ein eigenes WWW-Redaktionsteam eingerichtet wer-
den (siehe M 2.272 Einrichtung eines WWW-Redaktionsteams).
Verantwortliche benennen
Beim Betrieb eines Webservers, egal ob intern oder extern, sollte nicht jeder
Benutzer beliebig Dateien einstellen knnen. Es sollte daher ein Verantwortli-
cher fr das Einstellen von Informationen benannt werden, der neue Dateien
auch auf die Einhaltung der Richtlinien berprft. Je nach Gre der Organi-
sation knnen auch weitere Teil-Verantwortliche fr einzelne Organisations-
einheiten oder Teilbereiche des Webservers benannt werden. Entsprechend der
hier gewhlten Organisationsstruktur ist auch die Rechtevergabe und die Ver-
zeichnisstruktur auf dem Webserver festzulegen. Vor allem sollte jeder Teil-
Verantwortliche nur Zugriff auf die von ihm betreuten Unterverzeichnisse
haben.
Um sicherzustellen, dass die angelegten Dateien und Verzeichnisse immer den Automatische Kontrolle
der Richtlinien
jeweiligen Richtlinien gengen, sollte deren Einhaltung automatisiert ber-
prft werden, z. B. ber geeignete Skripten oder Makros. Ein entsprechend
vorbereitetes Programm sollte fr alle zur Verfgung gestellt werden und nach
jeder nderung aufgerufen werden. Dabei sollte insbesondere berprft wer-
den, ob die Zugriffsrechte aller
- Verzeichnisse,
- Dateien und
- CGI-Skripte (falls eingerichtet)
korrekt gesetzt wurden.
Ein Protokoll ber die durchgefhrten nderungen sollte ebenfalls direkt er-
zeugt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ein allgemeines Problem bei der Einrichtung und beim Betrieb eines Webser- Rechte- und Rollen-
vers ist die notwendige Zusammenarbeit vieler verschiedener Personen mit konzept
unterschiedlichen Kompetenzen. So werden Aufgaben wie
- Erstellen neuer Inhalte,
- Administration des Webservers,
- Durchfhrung des Designs des Webauftritts,
- Entwurf einzelner Grafiken,
- Programmierung von Zusatzfunktionalitt fr den Webserver (z.B.
eine Datenbankanbindung) und
- Programmieren von Zusatzfunktionalitt, die auf dem WWW-Client
genutzt wird (Javascript, etc.),
in der Regel von unterschiedlichen Personen wahrgenommen. Aus techni-
schen Grnden ist in der Regel eine vollstndige Trennung der Zugriffsrechte
nicht oder zumindest nicht vollstndig mglich. Die oben geforderten
Zugriffsbeschrnkungen lassen sich auf einem Entwicklungssystem daher in
der Regel nicht durchsetzen. In diesem Fall muss darauf geachtet werden, dass
das Entwicklungssystem keine sensitiven Daten enthlt. Die Zugriffsrechte
auf einem produktiven Webserver lassen sich jedoch auch in einer solchen
Umgebung restriktiv handhaben. Neben der Zustndigkeit mssen auch die fr
den Transfer notwendigen Ttigkeiten geplant werden. Dies umfasst neben der
oben erwhnten Kontrolle der vergebenen Zugriffsrechte auch eine berpr-
fung der zu verffentlichenden Inhalte.
Zugriffsbeschrnkungen auf den Webserver
Vor der Inbetriebnahme bzw. jeder Aktualisierung eines Webservers muss
festgelegt werden, wer Informationen vom Webserver abfragen darf. Es ist zu
klren, ob nur Personen innerhalb der eigenen Organisation, eventuell zustz-
lich Telearbeiter, oder auch jeder Externe oder nur ein eingeschrnkter Kreis
auf bereitgestellte Informationen zugreifen drfen. Diese Einschrnkungen
knnen auch abhngig von den jeweiligen Informationen variieren
Wenn der Zugriff auf den Webserver nur einem begrenzten Personenkreis
mglich sein soll, sind entsprechende Manahmen zu implementieren, wie
z. B. in M 4.94 Schutz der WWW-Dateien.
Es muss auerdem geklrt werden, ob grundstzlich nur Informationen abge-
rufen werden drfen oder ob es auch fr Benutzer mglich sein soll, selber
neue Informationen einzustellen. Auch hier ist wieder festzulegen werden,
welcher Personenkreis welche Rechte hat.
bersichtliche Strukturierung
Da HTML-Dateien nicht hierarchisch angeordnet werden mssen, ist die Ver-
zeichnisstruktur innerhalb eines Webservers fr die Funktionsweise irrelevant.
Um die Wartung zu erleichtern, sollte allerdings auf eine bersichtliche
Struktur geachtet werden.
Es ist empfehlenswert, die Verzeichnisstruktur so zu whlen, dass der URL, Sprechende Pfadnahmen
unter dem eine Datei erreichbar ist, bereits gewisse Informationen ber die
Datei gibt. Dies fhrt zwar unter Umstnden zu relativ langen Pfadnamen,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
aber es macht es Besuchern leichter, sich bestimmte Stellen zu merken und

wieder zu finden. Da viele Internet-Suchmaschinen bei einer Suche den voll-
stndigen WWW-Pfad eines Treffers ausgeben, verbessert diese Art der
Strukturierung auch die Auffindbarkeit der Informationen.
Da unter Umstnden in anderen Webservern Links auf ihre Dokumente ange-
legt werden, sind nderungen an Dokument- und Verzeichnisnamen zu ver-
meiden. Die Verzeichnisstruktur muss deshalb erweiterungsfhig geplant wer-
den.
Dokumente bereitstellen
Ein ffentliches Webangebot im Internet ist eine Form der Auendarstellung
einer Organisation. Entsprechend sorgfltig sollte daher die Internet-Prsenz
vorbereitet werden.
Es empfiehlt sich, mit einem Webangebot im Intranet erste Erfahrungen zu
sammeln, bevor ein Webserver an das Internet angebunden wird. Hier sollte
mit wenigen, einfachen Anwendungen begonnen werden.
Informationen in einem Webangebot werden normalerweise in HTML-Da-
teien bereitgestellt, die direkt im Webbrowser dargestellt werden knnen. Es
knnen aber auch Dateien in beliebigen anderen Formaten zum Download
bereitgestellt werden. In diesem Fall muss die Anwendung zum Anzeigen des
Dokuments beim Benutzer vorhanden sein und die Dateien mssen im Allge-
meinen zunchst auf dem IT-System des Benutzers gespeichert werden, bevor
sie weiterverarbeitet werden knnen.
Sofern es nicht erforderlich ist, dass Benutzer in den bereitgestellten Doku-
menten nderungen vornehmen (beispielsweise Ausfllen von Formularen),
sollten Dokumente in Formaten bereitgestellt werden, bei denen Vernderun-
gen nicht einfach mglich sind. Proprietre Dokumentenformate sollten so
weit wie mglich vermieden werden.
Alle fr die Verffentlichung im Internet vorgesehenen HTML-Dokumente Qualittssicherung
und WWW-Dateien sollten vor der Verffentlichung genauso qualittsge-
sichert und inhaltlich genehmigt werden wie jede andere Verffentlichung.
HTML-Dokumente werden meist mit speziellen HTML-Editoren erstellt. In
anderen Formaten erstellte Dokumente knnen mit HTML-Konvertern in
HTML umgewandelt werden.
Sollen viele, sich oft ndernde Dokumente zur Verfgung gestellt werden,
empfiehlt es sich, den Webserver mit einer Dokumentendatenbank zu verbin-
den. Diese Lsung bietet dem Benutzer schnelle Such-, Ansichts- und Doku-
mentenverwaltungsmglichkeit. Ntzlich ist es auch, wenn mit Hilfe einer
Datenbankanbindung der Zugriff auf bereits vorhandene Firmendaten ermg-
licht wird. In diesem Fall muss jedoch der Datenbankserver bzw. die Doku-
mentendatenbank in das WWW-Sicherheitskonzept mit einbezogen werden.
Vor dem Einstellen neuer Dateien auf einem Webserver sind diese auf eventu-
ell noch enthaltene Restinformationen zu berprfen (siehe M 4.64 Verifi-
zieren der zu bertragenden Daten vor Weitergabe / Beseitigung von Rest-
informationen).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Konfigurationsmanagement
Da sich die Inhalte von WWW-Seiten erfahrungsgem hufig ndern, ist es
wichtig, ein funktionierendes Konfigurationsmanagement aufgebaut zu haben.
Die Aktualitt von Links und Verweisen ist zu berprfen, ebenso wie vor
Verffentlichung eine Virenkontrolle mit einem aktuellen Computer-Viren-
suchprogramm durchzufhren ist.
Kontrolle und Freigabeverfahren
Es ist ebenso wichtig, dass alle Verffentlichungen ein festgelegtes und nach- Freigabeverfahren
vollziehbares Kontrollverfahren durchlaufen. Dies sollte eine inhaltliche Qua-
littskontrolle ebenso umfassen wie eine formale Freigabe. Hier muss auch
berprft werden, ob die Informationen berhaupt fr eine Verffentlichung
geeignet sind oder ob sie z. B. vertraulich sind, dem Datenschutz unterliegen,
Copyright-geschtzt sind oder hnliches.
Bei greren Webangeboten kann es sinnvoll sein, ein Web-Content-Mana-
gement-System einzusetzen. Solche Systeme vereinfachen viele Arbeitsab-
lufe, die im Zusammenhang mit der Pflege eines Webangebots anfallen.
Informationen, die zur Verffentlichung ber elektronische Medien freigege-
ben worden sind, sollten digital signiert werden, um allen Lesern die Mg-
lichkeit zu geben, die Authentizitt der Informationen zu berprfen.
Verffentlichungen, die nicht die Meinung der Organisation widerspiegeln,
mssen als solche gekennzeichnet sein.
Beachtung rechtlicher Rahmenbedingungen
Beim Betrieb eines Webservers mssen verschiedene rechtliche Rahmenbe-
dingungen (in Deutschland sind dies unter anderem das Teledienstegesetz, der
Mediendienste-Staatsvertrag, Vorschriften zum Datenschutz) bercksichtigt
werden.
Beispielsweise wird fr ein gewerbliches WWW-Angebot das Vorhandensein
eines Impressums gefordert, in dem der Name der verantwortlichen Person
und eine Kontaktadresse genannt werden mssen. Je nach dem Inhalt des
WWW-Angebots oder der Branche des Anbieters sind unter Umstnden wei-
tere Angaben erforderlich. Bevor ein WWW-Angebot freigeschaltet wird,
sollte geklrt sein, welche Informationen dies sind und wo und in welcher
Form diese verffentlicht werden mssen.
- Existieren Richtlinien fr Inhalt und Form von Dokumenten, die auf dem
Webserver verffentlicht werden? Gibt es Richtlinien fr ein einheitliches
Erscheinungsbild?
- Wie werden Dokumente vor ihrer Verffentlichung qualittsgesichert?
- Existiert ein Rechte- und Rollenkonzept?
- Gibt es ein Freigabeverfahren bei der Verffentlichung von Dokumenten
auf dem Webserver?
- Werden Links regelmig berprft?
- Sind alle vorgeschriebenen Angaben wie Impressum vorhanden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.176 Geeignete Auswahl eines Internet Service

Providers
Bei einem Provider, ber den ein Benutzer an das Internet angeschlossen ist,
fallen nicht nur Informationen ber ein- und ausgehende E-Mail an, sondern
auch ber alle WWW-Seiten, die die Benutzer aufrufen. Auerdem laufen alle
Daten, die zwischen dem Rechner des Benutzers und einem Server im Internet
ausgetauscht werden, ber die IT-Systeme des Providers.
Bei der Auswahl eines Internet Service Providers sollte hinterfragt werden,
- ob Ansprechpartner zu technischen Problemen rund um die Uhr zur Ver-
fgung stehen und wie kompetent diese sind,
- wie er auf den Ausfall einer oder mehrerer seiner IT-Systeme vorbereitet
ist (Notfallplanung, Datensicherungskonzept),
- welche Verfgbarkeit (maximale Ausfallzeit) er garantieren kann,
- ob er regelmig berprft, ob die Verbindungen zum Kunden noch stabil
sind und im negativen Fall entsprechende Schritte unternimmt,
- was er zur Absicherung seiner IT-Systeme und der seiner Kunden
unternimmt.
Man sollte sich vom Provider dokumentieren lassen, dass dessen IT-Systeme Sicherheitsrichtlinien
des Providers vorlegen
sicher betrieben werden, also z. B. die in M 2.174 Sicherer Betrieb eines lassen
WWW-Servers beschriebenen Anforderungen erfllt sind. Alle relevanten
Manahmen der Kapitel 6 zu vernetzten Systemen und der Kapitel 7 zu
Datenbertragungseinrichtungen sollten umgesetzt sein. Bei jedem Provider
sollte ein IT-Sicherheitskonzept und Sicherheitsrichtlinien selbstverstndlich
sein. Die Sicherheitsrichtlinien sollten fr Externe einsehbar sein. Die Mit-
arbeiter des Providers sollten fr IT-Sicherheitsaspekte sensibilisiert sein, auf
die Einhaltung der Sicherheitsrichtlinie verpflichtet worden sein und regel-
mig geschult werden (nicht nur in Sicherheitsfragen).
Beim Provider sind Daten ber die Benutzer fr Abrechnungszwecke ge- Datenschutz
speichert (Name, Adresse, Benutzer-Kennung, Bankverbindung) ebenso wie
Verbindungsdaten und fr eine je nach Provider krzere oder lngere Zeit-
spanne auch die bertragenen Inhalte.
Die Anwender sollten sich bei ihrem Provider erkundigen, welche Daten wie
lange ber sie gespeichert werden. Bei der Auswahl von Providern sollte
bercksichtigt werden, dass deutsche Betreiber den einschlgigen daten-
schutzrechtlichen Regelungen fr die Verarbeitung dieser Daten unterliegen.
- Nach welchen Kriterien ist der Provider ausgewhlt worden?
- Welche Sicherheitsmechanismen werden beim Provider umgesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.177 Sicherheit bei Umzgen

Verantwortlich fr Umsetzung: Leiter Organisation, Leiter Haustechnik,
Leiter IT, IT-Sicherheitsmanagement
Bei einem Umzug mssen neben Mbeln auch die verschiedensten Daten-
trger (z. B. Papier, Disketten, Magnetbnder) und IT-Systeme hin und her
transportiert werden. Dabei verlassen Informationen, IT-Systeme und sonsti-
ges Material den gesicherten Bereich der Broumgebung und werden durch
Personal transportiert, das normalerweise keine Zugriffsrechte hat. Bei einem
Umzug, insbesondere wenn grere Teile der Organisation davon betroffen
sind, ist ein gewisses Chaos nie auszuschlieen und es kann auch nicht jede
Umzugskiste permanent persnlich beaufsichtigt werden. Trotzdem ist dafr
Sorge zu tragen, dass bei einem Umzug sensitive Daten weder verloren,
beschdigt noch Unbefugten zugnglich werden.
In die Umzugsplanung sollte mglichst frhzeitig das IT-Sicherheitsmanage-
ment und der Datenschutzbeauftragte einbezogen werden, um die aus Sicht
der IT-Sicherheit festzulegenden Rahmenbedingungen festzulegen:
- Bei der Planung eines Umzuges muss im Vorfeld detailliert festgelegt
werden, wer mit welchem Transportgut wann wohin umzieht. Dies sollte
ohnehin eine Selbstverstndlichkeit sein, damit die Arbeit nach dem
Umzug mglichst reibungslos wieder aufgenommen werden kann.
- In Abhngigkeit vom Schutzbedarf der Daten muss festgelegt werden,
welche Randbedingungen fr den Transport einzuhalten sind. Beispiels-
weise sollten fr sensiblere Daten verschliebare Transportbehlter (siehe
M 2.44 Sichere Verpackung der Datentrger) benutzt werden oder die
Datentrger vor dem Transport verschlsselt werden.
- Vor jedem Transport von IT-Systemen sollten Datensicherungen ange-
fertigt werden. Hierbei ist neben den in M 6.35 Festlegung der
Verfahrensweise fr die Datensicherung beschriebenen Modalitten
insbesondere zu beachten, dass die Datensicherungen auf keinen Fall
zusammen mit den gesicherten IT-Systemen transportiert werden drfen.
Hierdurch wird sichergestellt, dass nicht alle Speichermedien gleichzeitig
beschdigt werden oder abhanden kommen.
- Es sollte ein Merkblatt fr alle betroffenen Mitarbeiter ausgearbeitet
werden, in dem alle durchzufhrenden IT-Sicherheitsmanahmen genau
beschrieben sind.
Bei einem Umzug ist nicht nur der Transport eine kritische Phase, sondern
auch der Zeitraum kurz vor bzw. danach. In dieser Phase kommen erfah-
rungsgem viele Sachen abhanden, da zu diesem Zeitpunkt die Standard-
sicherheitsverfahren wie z. B. die Zutrittskontrolle noch nicht greifen. Auch
whrend des Umzugs sollten daher gewisse organisatorische Mindestan-
forderungen erfllt sein:
- Fr alle zu transportierenden Materialen sollten Transportpapiere ausge-
stellt werden, aus denen hervorgeht,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- ob eine bestimmte Transportart zu beachten ist (z. B. zerbrechlich,

Computerspezialtransport, etc.),
- wohin sie gebracht werden sollen,
- wer berechtigte Empfnger sind,
- wer sie abgeholt bzw. angeliefert hat (inkl. Datum und Uhrzeit).
- Das Transportgut selber muss so gekennzeichnet sein, dass es eindeutig
identifiziert werden kann, so dass auch der Transportweg nachvollzogen
werden kann. Die Kennzeichnung sollte jedoch keine Rckschlsse auf die
Sensitivitt des Inhalts erlauben. Die Art der Kennzeichnung sollte so
gewhlt sein, dass sie nicht problemlos nachgemacht und werden kann.
Hierfr knnten die Umzugsvorbereiter spezielle Etiketten zur Verfgung
stellen.
- Auch whrend eines Umzuges sollte kein ungeordnetes Kommen und
Gehen herrschen. Die beauftragten Umzugsfirmen sollten die Personalien
der vorgesehenen Mitarbeiter vorher bekannt geben. Bei pltzlichen
Personalwechsel (Urlaub, Krankheit, etc.) sollten die Namen des Ersatz-
personals kurzfristig mitgeteilt werden. Mit einer Namensliste der am
Umzug Beteiligten knnen dann die Pfrtner oder andere interne Mitar-
beiter je nach Liegenschaft und Gegebenheit sporadisch oder kontinuierlich
kontrollieren. Die am Umzug beteiligten externen Krfte sollten mit
Ausweisen versehen werden, damit klar erkennbar ist, wer zutrittsberech-
tigt ist.
- Das Transportgut, insbesondere die Datentrger sind vor und nach dem
Umzug sicher aufzubewahren. Die Rume, in denen keine Umzugsttig-
keiten stattfinden, in denen sich aber keine Mitarbeiter aufhalten, also z. B.
die, die noch nicht ausgerumt bzw. bereits eingerumt wurden, sollten
abgeschlossen werden.
Nach erfolgtem Umzug sollte mglichst rasch ein geordneter Betrieb aufge-
nommen werden. Als Erstes ist die infrastrukturelle und organisatorische
Sicherheit in den neuen Bros wiederherzustellen, also z. B.
- sollte die Zutrittskontrolle wieder in vollem Umfang aufgenommen
werden,
- sollten die Brandlasten aus den Fluren entfernt werden, d. h. die Umzugs-
kartons in die neuen Arbeitsrume geschafft werden,
- ist das angelieferte Umzugsgut darauf zu berprfen, ob es vollstndig und
voll funktionsfhig ist und nicht manipuliert wurde.
Besondere Sorgfalt sollte auf die Umzugsplanung fr alle Server und Netz-
koppelelemente verwendet werden, da auch bei Ausfall nur einer Komponente
unter Umstnden das ganze Netz nicht betriebsfhig ist.
Vor einem Umzug sollten daher auf Seiten der zentralen IT-Administration
verschiedene Vorkehrungen getroffen werden, um den reibungslosen Arbeits-
ablauf sicherzustellen:
- Vor Beginn der Umzugsphase sollte frhzeitig ein Plan fr die erforder-
lichen nderungen der Benutzeranbindung erstellt werden. Hierbei sollte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
besonders analysiert werden, ob neue Beschaffungen fr den reibungslosen

Wechsel der Rechneranbindung von Mitarbeitern erforderlich sind. Auch
aus Sicherheitsgrnden ist es wichtig zu wissen, welche nderungen sich
durch den Umzug im Kommunikationsverhalten der IT-Systeme ergeben.
Je nach dem Schutzbedarf der Arbeit von Mitarbeitern kann es
beispielsweise erforderlich werden, eine Netzverbindung zu verschlsseln
oder den Zugriff auf bestimmte Datenbestnde zu unterbinden.
- Bevor ein Mitarbeiter umzieht, sollte sichergestellt sein, dass er in seinem
neuen Bro ber das lokale Netz erreichbar ist und seine Applikationen
und Dienste betriebsbereit sind. Dies erfordert gegebenenfalls neben
nderungen am Endgert (Routing, Softwarekonfiguration etc.) auch
baldige nderungen auf Serverseite im LAN oder gar auf Routern im
WAN. Hier kann es erforderlich sein, neue Adressen oder Routen einzu-
richten und alte zu lschen. Mglicherweise mssen vorher neue Netz-
komponenten beschafft und eingerichtet werden.
- Bei einem Umzug ist es oft auch erforderlich, fr die betroffenen Mitarbei-
ter Benutzer-Accounts auf einem neuen Server einzurichten. Es ist darauf
zu achten, dass die erforderlichen Rechte und Zugriffe auf Applikationen
und Protokolle eingerichtet werden. Auch die Sicherheitseinstellungen der
Benutzerumgebung mssen seinem Sicherheitsprofil entsprechend gewahrt
bleiben. Alte Benutzereintrge und Endgert-Zugangseintrge mssen auf
dem alten System angepasst oder gelscht werden. Der Zugriff auf
benutzereigene Datenbereiche sollte ihm dennoch fr eine bergangszeit,
jedoch mit verbindlichem Hinweis auf Lschung nach einer Karenzzeit,
gewhrt bleiben. Nach dieser Karenzzeit muss die Lschung durch den
Administrator vollzogen werden.
Besondere Vorkehrungen sind beim Umzug der Komponenten des Rechen-
zentrums, wie Daten- oder Kommunikationsservern, zu treffen. Im Folgenden
werden Manahmen beschrieben, die mglichst kurze Ausfallzeiten der
Komponenten gewhrleisten sollen.
- Wenn mglich, sollte ein neuer Server vorab installiert und in der neuen
Rumlichkeit getestet werden. Ist dies nicht mglich, so sollte der alte
Server so gut wie mglich vorkonfiguriert werden und erst zu einer Zeit, zu
der wenig Zugriffe zu erwarten sind, nach ausreichender Vorankndigung
umgestellt werden. Hierbei sollte die alte Konfiguration immer vorab
gesichert sein.
- Der Server sollte vor dem Umzug komplett gesichert werden. Wenn nicht
bereits vorhanden, ist auch ein bootfhiges Sicherungsmedium zu erzeu-
gen. Sensible Serverteile wie Festplatten sollten fr den Ausfall des
Originals als Image redundant vorgehalten sein und getrennt vom Server
transportiert werden. Es ist darauf zu achten, dass die Datensicherung und
das Image ebenso wie der Server beim Transport gesichert ist (z. B.
Verschlsselung, verschlossene Box, Bewachung).
- Vor dem Umzug ist sicherzustellen, dass die Infrastruktur in den neuen
Rumlichkeiten fr den einwandfreien Serverbetrieb vorhanden und
getestet sind. Hier ist neben dem Vorhandensein des Netzes (Strom, LAN,
WAN) auch auf die richtige Reihenfolge des Umzuges der Komponenten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zu achten. Es ist beispielsweise wenig sinnvoll, zuerst den Internet-

Webserver umziehen zu lassen, wenn der Firewall mit seinem Kommuni-
kationsrouter erst wesentlich spter aufgebaut wird.
- Vor dem Umzug sollte berprft werden, ob unter den zu transportierenden
IT-Komponenten solche sind, die besondere Umgebungsbedingungen
whrend des Umzuges bentigen. Beispielsweise gibt es Controller fr
grere (und teurere!) IT-Systeme, die nicht nur in klimatisierten Rumen
betrieben, sondern auch klimatisiert transportiert werden mssen.
Weiterhin sollte sichergestellt sein, dass die neuen Telefonnummern bereits
erreichbar sind, sobald die Mitarbeiter ihre neuen Bros bezogen haben. Bei
einem Umzug innerhalb eines Ortes sollte versucht werden, die alten
Telefonnummern zumindest bergangsweise zu behalten. Whrend des
Umzugs sollte sowohl in der alten als auch in der neuen Liegenschaft die tele-
fonische Erreichbarkeit gewhrleistet sein, damit bei auftretenden Problemen
Rckfragen jederzeit mglich sind.
- Sind rechtzeitig vor einem geplanten Umzug Sicherheitsrichtlinien
erarbeitet worden?
- Sind alle Mitarbeiter ber die vor, whrend und nach dem Umzug zu
beachtenden IT-Sicherheitsmanahmen informiert worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.178 Erstellung einer Sicherheitsleitlinie fr die

Faxnutzung
Vor der Installation, Konfiguration und Freigabe von Faxservern sollte
zunchst eine Sicherheitsleitlinie fr die Faxnutzung festgelegt werden.
Folgende Punkte werden blicherweise mit solch einer Sicherheitsleitlinie
geregelt:
1. Einsatzkonzept
Bevor ein Faxserver fr die Nutzung freigegeben wird, muss zunchst fest-
gelegt werden, in welcher Einsatzart das System betrieben werden soll. So ist
z. B. denkbar, dass ein Faxserver nur dazu dient, Faxe ber das LAN entge-
genzunehmen und dann nach auen zu versenden. Ein Faxserver kann aber
auch von auen eingehende Faxsendungen entgegennehmen. In diesem Fall
muss festgelegt werden, wie die Eingangs-Faxsendungen an die Empfnger
weitergeleitet werden. Die erste Mglichkeit besteht dabei in der Weiter-
leitung durch den Faxserver selbst, ggf. mit Anbindung an bereits bestehende
E-Mail oder Workflow-Systeme. Eine andere Mglichkeit ist die manuelle
Weiterleitung der Eingangs-Faxsendungen durch die Poststelle. Hier besteht
einmal die Mglichkeit der Weiterleitung per E-Mail. Denkbar ist aber auch,
dass die Poststelle eingehende Faxe ausdruckt und diese Ausdrucke an den
Empfnger weiterleitet (siehe M 2.181 Auswahl eines geeigneten Faxservers).
2. Integration in den Geschftsablauf
Von der Betriebsart hngt auch ab, wie bei Benutzung eines Faxservers ver-
sandte oder empfangene Faxe in den Geschftsablauf integriert werden.
Sofern die Poststelle alle Faxeingnge ausdruckt und die Ausdrucke an den
jeweiligen Empfnger weiterleitet, entspricht dies dem Ablauf, wie er auch bei
herkmmlichen Faxgerten blich ist. Werden aber Faxe direkt aus einer
Applikation vom Arbeitsplatzrechner des Benutzers versandt oder werden
Faxeingnge direkt vom Faxserver an den Empfnger bermittelt, unter-
scheiden sich diese Verfahren erheblich von denen bei der Benutzung her-
kmmlicher Faxgerte. Daher sollte in diesem Fall in der Richtlinie fr die
Faxnutzung festgelegt werden, von welchen Faxeingngen und Faxausgngen
Ausdrucke fr die Akten gefertigt werden mssen.
3. Regelungen zum Faxserver-Einsatz
Um den sicheren Betrieb und Einsatz eines Faxservers sicherstellen zu
knnen, mssen eine Reihe von Regelungen getroffen werden (siehe M 2.179
Regelungen fr den Faxserver-Einsatz).
4. Inhaltliche Restriktionen
Weiterhin sollte in der Fax-Sicherheitsleitlinie festgelegt werden, welche
Informationen berhaupt per Fax weitergegeben werden drfen. Es kann in
der Fax-Sicherheitsleitlinie zudem festgelegt werden, welche Kommuni-
kationspartner welche Informationen erhalten drfen. Damit wird erreicht,
dass der Empfnger auch die notwendigen Berechtigungen zum Weiterverar-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
beiten der Information besitzt. Beispielsweise kann festgelegt werden, dass

Preislisten nur an Einkufer oder Projektunterlagen nur an Projektbeteiligte
per Fax versendet werden drfen.
5. Notfallvorsorge und Ausfallsicherheit
Auerdem sollten in der Faxsicherheitsleitlinie Aussagen zur Notfallvorsorge
und zur Ausfallsicherheit des Faxbetriebes enthalten sein. Abhngig von den
Anforderungen an den Wert Verfgbarkeit ist ggf. der Einsatz redundanter
Faxserver sinnvoll. In diesen Bereich fallen auch berlegungen, ob fr den
Notfall noch herkmmliche Faxgerte verfgbar gehalten werden (siehe auch
M 6.69 Notfallvorsorge und Ausfallsicherheit bei Faxservern).
6. Datensicherung
Der Faxserver sollte in das Datensicherungskonzept der Organisation
aufgenommen werden (siehe Kapitel 3.4 Datensicherungskonzept).
Insbesondere ist dabei festzulegen, wer fr die Durchfhrung der
Datensicherungen zustndig ist und was zu sichern ist. Gegenstand der
Datensicherung knnen dabei die Software, Konfigurationsdaten, gespeicherte
bzw. archivierte Faxdaten oder auch Protokolldateien sein. Auerdem sind
Festlegungen hinsichtlich des Sicherungsintervalls und der Anzahl der
aufzubewahrenden Generationen notwendig. Es muss festgelegt werden, wer
fr die berprfung der bei der Datensicherung anfallenden Protokolle
zustndig ist. Schlielich sollten sowohl die Durchfhrung der Datensicherung
als auch die Auswertung der Protokolle dokumentiert werden.
7. Schulung
Die Faxsicherheitsleitlinie sollte zudem um ein organisationsweites
Schulungskonzept ergnzt werden. Zunchst ist das Personal, dass das IT-
System und die Faxserver-Applikation administriert, entsprechend zu schulen.
Dann sollten die Benutzer fr die Gefhrdungen sensibilisiert werden, die
durch einen Faxserver im Vergleich zu einem herkmmlichen Faxsystem
entstehen.
- Existiert eine Sicherheitsleitlinie fr die Faxnutzung?
- Wird die Sicherheitsleitlinie fr die Faxnutzung regelmig an das
Einsatzumfeld angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.179 Regelungen fr den Faxserver-Einsatz

Verantwortlich fr Umsetzung: Administrator, Fax-Poststelle
Um den reibungslosen Betrieb des oder der Faxserver zu gewhrleisten,
mssen folgende Punkte geregelt werden:
1. Festlegung von Zustndigkeiten
Ein Faxserver besteht aus einem IT-System, dem darauf installierten
Betriebssystem sowie der Faxserver-Applikation. Dazu kommen dann noch
die Faxclients der Benutzer. Dementsprechend muss auch die Betreuung
geregelt werden. Je nach der vorhandenen Organisationsstruktur mssen
Verantwortliche fr diese Bereiche benannt werden. Im Extremfall kann dies
heien, dass jeder dieser Bereiche von anderen Administratoren betreut wird.
Die Administration des Betriebssystems kann z. B. durch die Organisations-
einheit erfolgen, die auch fr die Administration der sonstigen IT-Systeme
zustndig ist. Die Administration der Faxapplikation sollte hingegegen durch
die Fax-Poststelle erfolgen. Je nach Einsatzart ist diese Stelle auch dafr
verantwortlich, dass eingehende Faxsendungen an den zustndigen Bearbeiter
weitergeleitet werden. Diese Stelle sollte dann auch fr die Vergabe von
Berechtigungen auf dem Faxserver verantwortlich sein. Weitere Aufgaben
sind z. B. die Rcksetzung von Passwrtern und die Einrichtung von neuen
Benutzern. Von besonderer Bedeutung ist daher die Festlegung der Aufgaben
und Zustndigkeiten der Fax-Poststelle (siehe M 2.180 Einrichten einer Fax-
Poststelle).
2. Festlegung des Benutzerkreises
Auerdem sollte der Personenkreis festgelegt werden, der berechtigt ist, den
Faxserver zu benutzen. Dabei sind u. a. folgende Berechtigungen fr einge-
hende Faxsendungen denkbar:
- lesen,
- weiterleiten,
- lschen.
Fr ausgehende Faxsendungen sind folgende Berechtigungen denkbar:
- senden,
- anhalten,
- lschen,
- Sendeoptionen verndern.
Diese Berechtigungen sollten, wie in der Administration allgemein blich,
mglichst nur an Benutzergruppen und nur im Ausnahmefall an einzelne
Benutzer vergeben werden (siehe auch M 2.30 Regelung fr die Einrichtung
von Benutzern / Benutzergruppen).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Festlegung von Nutzungsprofilen

Es sollte auch geregelt werden, in welchem Umfang berechtigte Benutzer den
Faxserver in Anspruch nehmen drfen. Dies ist insbesondere wichtig, um
berlastungen durch Serienfaxe zu verhindern.
4. Nutzungszeiten
Auerdem sollte berlegt werden, ob die Nutzung von Faxservern nur zu
bestimmten Zeiten zugelassen wird. So kann z. B. verhindert werden, dass
auerhalb der Arbeitszeiten Faxe versendet werden knnen.
Sofern Faxeingnge automatisch an die Empfnger durch den Faxserver
weitergeleitet werden, sollten fr bestimmte Funktionen und Aufgaben eigene
Faxnummern eingerichtet werden. Allen Mitgliedern einer Gruppe kann dann
der Zugriff auf die fr die entsprechende Rufnummer eingehenden Fax-
sendungen gewhrt werden. Dies erleichtert auch etwaige Vertretungs-
regelungen.
Beispiel: In einem Unternehmen wird ein Faxserver betrieben, der eingehende
Faxsendungen automatisch an die Empfnger weiterleitet. Eine -Rufnummer
wird die Bestellannahme vergeben. Der Faxserver leitet alle Faxsendungen
mit Bestellungen, die ber diese Rufnummer an das Unternehmen bermittelt
werden, nicht an einen einzelnen Mitarbeiter, sondern an alle Mitglieder der
Bestellannahme weiter. Dabei muss durch das Unternehmen festgelegt
werden, in welcher Reihenfolge die Mitarbeiter Eingangsfaxsendungen
bearbeiten, um Bestellungen nicht doppelt auszufhren.
6. Vertretungsregelung
Gerade beim Einsatz von Faxservern, die Faxeingnge an einzelne Benutzer
zustellen, ist eine Vertretungsregelung im Falle der Abwesenheit unumgng-
lich und daher eine entsprechende Verpflichtung in die Sicherheitspolitik
aufzunehmen. Ansonsten kann nicht ausgeschlossen werden, dass wichtige
Faxeingnge ber einen lngeren Zeitraum nicht zur Kenntnis genommen
werden. Insoweit unterscheidet sich das Verfahren beim Einsatz von Fax-
servern erheblich von dem beim Einsatz herkmmlicher Faxgerte. Bei
letzteren werden Eingnge durch die Vertreter eher wahrgenommen, da die
Faxe in Papierform vorliegen.
7. Protokollierung
Es sollten Regelungen fr den Umgang mit anfallenden Protokolldaten
erarbeitet werden. So sollte festgelegt werden, wer welche Protokolldaten in
welchen Abstnden auswerten muss (siehe M 2.64 Kontrolle der
Protokolldateien).
8. Adressbcher
Auch sollte festgelegt werden, welche Adressbcher zum Einsatz kommen
und wer die Pflege bernimmt. Viele Faxserver-Applikationen bieten die
Mglichkeit, sowohl individuelle als auch unternehmensweit gltige Adress-
bcher anzulegen. Zudem ist es hufig auch mglich, die Adressbcher von
Faxservern mit den Verteilerlisten/Adressbchern bereits vorhandener E-Mail-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
systeme zu synchronisieren. Whrend organisationsweit gltige Adressbcher

zentral durch die Fax-Poststelle gepflegt werden sollten, muss dies bei den
individuellen Adressbchern durch die Benutzer selbst erfolgen. Die Benutzer
sollten auerdem verpflichtet werden, bei wichtigen Faxsendungen (z. B.
individuelle Angebote) die Empfngerrufnummer zu berprfen.
9. Nutzung des Faxservers
Auerdem mssen auch Regelungen fr die Nutzung des Faxservers durch die
Mitarbeiter erarbeitet werden (siehe M 3.15 Informationen fr alle Mitarbeiter
ber die Faxnutzung). Schlielich ist festzulegen, welche Rechte die
Mitarbeiter auf dem Faxserver ausben drfen.
10. Schutz der Faxclients
Es muss durch geeignete organisatorische und technische Manahmen sicher-
gestellt werden, dass keine Faxe unbefugt gelesen oder unbefugt bzw. unbe-
absichtigt gesendet werden. Die Benutzer sind daher fr die Benutzung der
Fax-Programme zu schulen und hinsichtlich der auftretenden Risiken zu
sensibilisieren.
Von besonderer Bedeutung ist die Authentisierung der Mitarbeiter am
Faxserver. Diese kann explizit ber einen Faxclient oder aber auch mit der
Anmeldung an einem Verzeichnisdienst, einem Domnen-Controller (bei
Verwendung von Microsoft Windows NT) oder an einem E-Mail-System
erfolgen. Sofern die Authentisierung zwischen Mitarbeiter und Faxserver ber
einen Client erfolgt, sollte mglichst darauf verzichtet werden, das Anmelde-
Passwort auf der Festplatte abzulegen, da dadurch dieser Sicher-
heitsmechanismus seinen Wert verliert. Jeder, der auf den entsprechenden
Faxclient Zugriff hat, kann unter fremdem Namen Faxe versenden und unbe-
fugt eingehende Faxsendungen lesen. Weiterhin sind die Mitarbeiter dazu
anzuhalten, sich nach der Abholung eingegangener Faxsendungen und nach
der Versendung von Ausgangsfaxen wieder am Faxserver abzumelden. Es ist
darauf hinzuwirken, dass Mitarbeiter beim Verlassen des Arbeitsplatzes den
Rechner schtzen, z. B. durch die Benutzung eines Bildschirmschoners mit
Passwort oder ber Mechanismen des eingesetzten Betriebssystems (siehe
M 4.1 Passwortschutz fr IT-Systeme und M 4.2 Bildschirmsperre).
11. Reparatur und Wartung
Es sollten auch Regelungen zur Durchfhrung von Reparatur- und Wartungs-
arbeiten des Faxservers festgelegt werden. Fr die Administratoren des
Systems muss klar sein, wer im Wartungs- und Reparaturfall zu benachrich-
tigen ist. Auch sollte geregelt werden, wie mit defekten Datentrgern, insbe-
sondere defekten Festplatten umgegangen werden muss.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die Regelungen fr den Faxserver-Einsatz regelmig an das
Einsatzumfeld angepasst?
- Sind Regelungen fr die Weiterleitung von eingehenden Faxsendungen bei
Abwesenheit des Empfngers in Kraft?
- Sind Regelungen fr die Schulung der Mitarbeiter ber die Nutzung der
Faxprogramme vorhanden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.180 Einrichten einer Fax-Poststelle

Um den reibungslosen Betrieb des oder der Faxserver zu gewhrleisten, muss
eine Fax-Poststelle eingerichtet und damit ein Fax-Verantwortlicher benannt
werden. Die Fax-Poststelle hat dabei diverse organisatorische und technische
Aufgaben wahrzunehmen, die auch von der Betriebsart des Faxservers
abhngen.
Da die Mitarbeiter der Fax-Poststelle im Regelfall Zugriff auf alle eingehen- sorgfltige Auswahl der
Mitarbeiter
den und ausgehenden Faxsendungen haben, muss an die Auswahl des Perso-
nals ebenso hohe Anforderungen gestellt werden, wie dies bei Administra-
toren notwendig ist.
Die Fax-Poststelle muss auerdem mit den Verantwortlichen fr die sonstigen
Kommunikationsdienste (insbesondere E-Mail und Telekommunikationsan-
lage) eng zusammenarbeiten.
Die Fax-Poststelle sollte fr alle Benutzer jederzeit erreichbar sein. Im stndige Erreichbarkeit
Rahmen von Vertretungsregelungen ist sicherzustellen, dass die Fax-Poststelle
stndig besetzt ist.
Typische Aufgaben einer Faxserver-Poststelle sind:
- Administration der Faxserver-Applikation. Dazu gehrt:
- Einrichtung neuer Benutzer,
- Vergabe von Berechtigungen an Benutzer und Benutzergruppen,
- Rcksetzen von Passwrtern,
- berprfung der Kommunikationsverbindungen,
- Auswertung der anfallenden Protokolle,
- Anlaufstelle der Benutzer bei Problemen,
- Pflege der zentralen Adressbcher und Verteilerlisten,
- Durchfhrung von Datensicherungen, sofern dies nicht Aufgabe der
Administration des Betriebssystems ist,
- Faxzustellung und Archivierung,
- Fehlerbehebung bei der Faxzustellung
- Koordination der Zusammenarbeit mit TK-Anlagen- und E-Mail-Verant-
wortlichen.
Schlielich sollte auch die Faxclient-Software auf den Arbeitsplatzrechnern Betreuung der Faxclients
betreut werden. Diese Aufgabe kann sowohl durch die Fax-Poststelle als auch
durch die Organisationseinheit erfolgen, die die Arbeitsplatzrechner betreut.
Einer besonderen Betrachtung bedrfen noch die Aufgaben im Zusammen-
hang mit den Faxeingngen, da diese von der Betriebsart des Faxservers
abhngig sind.
Manuelle Weiterleitung von Eingangs-Faxsendungen
Sofern Eingangs-Faxsendungen nicht automatisch an den Empfnger zuge-
stellt werden, mssen diese durch die Fax-Poststelle manuell weitergeleitet
werden. Dies kann z. B. in der Form erfolgen, dass durch die Fax-Poststelle
von den Faxeingngen ein Ausdruck gefertigt wird, der dann an den Empfn-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ger auf dem blichen Weg weitergeleitet wird. Dieses Verfahren unterscheidet
sich nicht wesentlich von dem beim Einsatz eines herkmmlichen Faxgertes.
Denkbar ist allerdings, dass eingegangene Faxsendungen digital auf externen
Datentrgern archiviert werden.
Automatische Weiterleitung von Eingangs-Faxsendungen
Bei der automatischen Weiterleitung von Eingangs-Faxsendungen an den
Empfnger (automatisches Fax-Routing) ist ebenfalls mglich, dass durch die
Fax-Poststelle Ausdrucke zum Zwecke der Archivierung gefertigt werden.
Auch hier besteht die Mglichkeit, eingehende Faxsendungen digital auf
externen Datentrgern zu archivieren.
Sofern Faxsendungen nicht zugestellt werden knnen, muss die Fax-Poststelle Behandlung nicht
zustellbarer Faxeingnge
hiervon Kenntnis erlangen und versuchen, die Fehlerquelle zu beheben.
Sofern die Zustellung endgltig scheitert, ist der Absender entsprechend zu
informieren. Grnde dafr, dass Faxeingnge unzustellbar sind, knnen sein:
- Der Absender hat eine falsche Durchwahl benutzt
- Der Empfnger ist nicht mehr Mitglied der Organisation.
- Die automatische Weiterleitung von Eingangs-Faxsendungen erfolgt
aufgrund der Absenderkennung (CSID) und der Absender ist in der
Organisation noch nicht bekannt oder es existiert keine entsprechende
Zuordnungsregel.
In all diesen Fllen muss von der Fax-Poststelle die Weiterleitung von
Faxeingngen manuell erfolgen. Sofern Faxeingnge endgltig nicht zugestellt
werden knnen, muss der Absender benachrichtigt werden.
- Wer ist Fax-Verantwortlicher?
- Wo laufen nicht zustellbare Faxsendungen auf?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.181 Auswahl eines geeigneten Faxservers

Ein Faxserver besteht im Regelfall aus folgenden Komponenten: Dem IT-
System selbst, dem Betriebssystem, der Kommunikationskomponente (z. B.
Faxmodem, aktive oder passive ISDN-Karte bzw. dedizierte Faxkarte) und der
eigentlichen Faxserver-Applikation. Zustzlich wird u. U. fr die
Arbeitsplatzrechner ein entsprechender Faxclient bentigt.
Bevor Faxserver beschafft werden, sind zunchst die wesentlichen Einfluss-
faktoren fr deren Einsatz zu erheben. Dies sind:
- Das voraussichtlich abzuwickelnde Faxvolumen,
- die Anzahl der Mitarbeiter, die den Faxserver benutzen sollen,
- die Anforderungen an die Verfgbarkeit des Faxservers,
- die Anforderungen an die Einbindung in bereits bestehende E-Mail- und
Workflow-Systeme,
- die Anforderungen an die Protokollierung auf dem Faxserver,
- Anforderungen an die Art der Weiterleitung eingehender Faxsendungen an
den Empfnger.
IT-System
Die Wahl des IT-Systems wird in der Regel durch die Anforderungen der
Software und des Betriebssystems an die Leistungsfhigkeit bestimmt. Das
IT-System muss zudem kompatibel zum ausgewhlten Betriebssystem sein. Je
nach Anforderungen an die Verfgbarkeit des Faxservers kann ber den
Einsatz zustzlicher Schutzmechanismen nachgedacht werden. Mglichkeiten,
die Verfgbarkeit sicherzustellen bzw. zu erhhen, sind:
- RAID
- Replikation
- Lastverteilung
Betriebssystem
Faxserver-Applikationen gibt es fr alle gngigen Netzbetriebssysteme wie
Unix, Microsoft Windows NT und Novell Netware. Bei der Wahl des
Betriebssystems sollte die Integrationsmglichkeit in das bestehende Netz und
die Anforderungen durch die Faxserver-Applikation den Ausschlag geben.
Sofern bisher in einer Organisation ausschlielich ein Netzbetriebssystem zum
Einsatz kommt, also z. B. nur Server unter dem Betriebssystem Unix im
Einsatz sind, so sollte auch mglichst dieses Netzbetriebssystem ausgewhlt
und eine geeignete Faxserver-Applikation beschafft werden. Hiervon wird
man abweichen mssen, wenn eine bestimmte Applikationssoftware als
Einzige ein dringend bentigtes Leistungsmerkmal anbietet, aber nur auf einer
anderen als der bisher eingesetzten Betriebssystemplattform einsetzbar ist. Ein
neues Netzbetriebssystem bedeutet einen erheblichen Mehraufwand bei der
Administration. Sofern im Netz bereits verschiedene Netzbetriebssysteme im
Einsatz sind, ist das zu whlen, das sich am einfachsten integrieren lsst,
sofern die gewnschte Faxserver-Applikation dies zulsst.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kommunikationskomponente
Die Kommunikationskomponenten stellen die Verbindung zwischen dem
Server und dem ffentlichen Telefonnetz her. Die Kommunikation wird auf
der Grundlage des T.30 Protokolls abgewickelt. Durch dieses Protokoll wird
u. a. der Verbindungsaufbau, der Austausch der Absender-Faxnummer und die
bertragung und die Quittierung des Dokuments geregelt. Die bertragung
im Gruppe-3-Standard erfolgt hauptschlich bei 9.600 bps und 14.400 bps.
Auerdem sind die Kompressionsverfahren Modified Huffmann, Modified
Read und Modified Modified im Einsatz. Der Gruppe-3-Standard ist am
weitesten verbreitet. Daneben gibt es noch den Gruppe-4-Standard, der
allerdings ISDN voraussetzt. Hier werden bertragungsgeschwindigkeiten
von 64 kBit pro Sekunde erreicht. Der Standard Gruppe 4 hat sich gleichwohl
in den vergangenen Jahren nicht durchsetzen knnen, da entsprechende Stand-
alone-Gerte relativ teuer sind. Es besteht auerdem keine Kompatibilitt
zwischen dem Gruppe-3- und dem Gruppe-4-Standard.
Bei Beginn der Kommunikation wird zwischen den Gerten sowohl die
bertragungsgeschwindigkeit als auch das Kompressionsverfahren ausge-
handelt. Es wird die hchste Geschwindigkeit und das bestmgliche
Kompressionsverfahren gewhlt, das von beiden Gerten untersttzt wird.
Folgende Kommunikationskomponenten sind beim Einsatz eines Faxservers
denkbar:
a) Faxmodem
Faxmodems sind recht preisgnstig verfgbar. Sie sind aber u. U. nicht aus-
reichend manipulationsresistent und werden zudem nicht von allen Faxserver-
Applikationen im Dauereinsatz untersttzt. Daher sollte ihr Einsatz auf den
privaten Gebrauch und auf einzelne Arbeitspltze beschrnkt bleiben.
b) passive ISDN-Karten
Passive ISDN-Karten sind einfach aufgebaut und damit preiswert. Die
Hauptlast der Kommunikation trgt der Rechner. Dies ist bei starker Inan-
spruchnahme des Faxservers (z. B. Serien-Faxsendungen) problematisch. Bei
passiven ISDN-Karten ist - ein entsprechendes Gert auf Empfngerseite
vorausgesetzt - generell auch die bertragung nach dem Gruppe-4-Standard
mglich. Mssen Faxdaten nach dem Gruppe-3-Standard bertragen werden,
so sind die Daten entsprechend zu konvertieren. Wie beim Faxmodem gilt
auch hier, dass das Hauptanwendungsgebiet auf einen einzelnen Arbeitsplatz
oder auf den privaten Bereich beschrnkt bleiben sollte.
c) aktive ISDN-Karten
Aktive ISDN-Karten, auch ISDN-Controller genannt, verfgen ber einen
eigenen Prozessor. Sie knnen daher das ISDN-Protokoll weitestgehend
eigenstndig abwickeln. Gem der Spezifikation des Common-ISDN-API
(CAPI) mssen die Faxdaten im Structured Fax File (SFF)-Format an die
ISDN-Karte bergeben werden. Die Konvertierung muss auf dem Faxserver
erfolgen. Genau wie Modems untersttzen aktive ISDN-Karten im Gruppe-3-
Standard nur die bertragungsgeschwindigkeiten 9.600 und 14.400 bps unter
Benutzung des Kompressionsverfahrens Modified Huffmann. Ein wesent-
licher Nachteil sowohl von Faxmodems als auch von aktiven und passiven
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ISDN-Karten ist, dass diese auch zu anderen Zwecken als der Faxbertragung
benutzt werden knnen, z. B. im Modembetrieb oder als Remote-Access-
Komponente. Dies ist aber bei einem Faxserver aus Grnden der Netzsicher-
heit gerade nicht erwnscht. Aktive ISDN-Karten knnen bis zu 30 ISDN-
Kanle zur Verfgung stellen. Beim Einsatz von aktiven ISDN-Karten sind
auch die ISDN-Signalisierungsmglichkeiten fr das automatische Fax-
Routing verfgbar. Trotz der Verwendbarkeit fr nicht-Fax-Betrieb sind
aktive ISDN-Karten fr den Einsatz in Faxservern durchaus empfehlenswert.
d) Faxkarten (ggf. mit ISDN-Schnittstelle)
Spezielle Faxkarten sind auf die Abwicklung des T.30-Protokolls optimiert.
Sie bernehmen den Verbindungsaufbau und das "Aushandeln" der Kommu-
nikationsparameter. Die Konvertierung der Daten und die Kompression
knnen auf der Karte erfolgen. Der Faxserver wird damit deutlich entlastet. Es
gibt Faxkarten, die die bertragung von Faxdaten mit 9.600 und 14.400 bps
und Anwendung aller drei Kompressionsverfahren bieten. Vorteil dieser
Karten ist auch, dass sie im Regelfall nur das T.30-Protokoll beherrschen und
daher nicht fr den Modembetrieb oder als Remote-Access-Komponente ein-
setzbar sind. Teilweise werden Faxkarten um eine ISDN-Schnittstelle erwei-
tert. Der Vorteil davon ist, dass die Signalisierungsmglichkeiten von ISDN
fr das Fax-Routing nutzbar werden.
Zusammenfassend folgt, dass in Faxservern im Regelfall nur aktive ISDN- aktive ISDN-Karten oder
Faxkarten verwenden
Karten und Faxkarten zum Einsatz kommen sollten. Die Karte muss kompa-
tibel zur Applikationssoftware sein, da nicht jede Karte durch alle Faxserver-
Applikationen untersttzt wird. Die Anzahl der notwendigen Karten hngt von
der Auslastung des Faxservers ab. Je Stunde und Leitung bzw. je Kanal ist die
bertragung von ca. 40-50 Seiten Faxdaten mglich.
Faxserver-Applikation
Bei der Auswahl der Applikationssoftware ist sowohl das Faxvolumen, das
ber den Faxserver abgewickelt werden soll, als auch die Anzahl der Benutzer
zu bercksichtigen.
Ist in der Organisation bereits ein E-Mail- bzw. Workflow-System vorhanden, Integration in ein E-Mail-
bzw. Workflow-System
so sollte eine Integration der Applikationssoftware mit diesen Systemen
mglich sein. Es ist dann z. B. denkbar, dass Faxeingnge und Fax-Ausgnge
zwischen dem Arbeitsplatzrechner des Benutzers und dem Faxserver ber das
bereits bestehende Workflow- bzw. E-Mail-System ausgetauscht werden.
Interessant ist in diesem Zusammenhang auch, ob und wie ggf. bestehende
Adressbcher bzw. Verteilerlisten mit den Adressbchern des Faxservers
synchronisiert werden knnen. Auerdem sollte die Archivierung von ein- und
ausgehenden Faxsendungen in bestehenden Workflow-Systemen mglich
sein.
Auch ist in die berlegungen mit einzubeziehen, wie Faxsendungen vom bertragung vom
Arbeitsplatz zum
Arbeitsplatz des Benutzers zum Faxserver gelangen und wo eine Umwand- Faxserver
lung der Daten in ein fr den Faxserver kompatibles Datenformat erfolgt. Die
Konvertierung der Faxdaten am Arbeitsplatz erfolgt beim Senden im Regelfall
mittels eines Druckertreibers oder einer besonderen Faxclient-Applikation.
Die konvertierten Daten knnen dann entweder ber E-Mail oder auch mittels
der Faxclient-Applikation an den Faxserver bermittelt werden. Denkbar ist
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
auch, dass der Benutzer die konvertierten Daten in ein spezielles Verzeichnis
auf dem Faxserver kopiert. Schlielich gibt es Faxserver, bei denen eine
Druckerwarteschlange im Netz eingerichtet wird, in die die Faxdaten von der
Anwendungssoftware, z. B. einem Textverarbeitungsprogramm, geschrieben
werden. Auerdem ist es mglich, dass die Daten auf dem Faxserver komplett
konvertiert werden. In diesem Fall erstellt der Benutzer mit einer
entsprechenden Anwendungssoftware, z. B. einem Text-
verarbeitungsprogramm, die als Fax zu versendende Datei, die dann dem
Faxserver bergeben werden muss. Dies kann mittels E-Mail, einer entspre-
chenden Faxclient-Applikation oder durch Kopieren in ein auf dem Faxserver
freigegebenes Verzeichnis erfolgen. Zu bedenken ist, dass die Konvertierung
der Faxdaten am Arbeitsplatz dort Ressourcen verbraucht. Dies kann in der
Regel vernachlssigt werden, wenn nur wenige Faxe am Tag versendet
werden. Gerade bei Serien-Faxsendungen kann es aber passieren, dass der
Arbeitsplatzrechner fr lngere Zeit blockiert wird. Andererseits verlangt eine
Konvertierung auf dem Faxserver bei hoher Inanspruchnahme entsprechend
leistungsfhige Hard- und Software.
Schlielich sollten bei der Auswahl geeigneter Applikationssoftware auch die Protokollierung am
Faxserver
Protokollierungmglichkeiten am Faxserver mit bercksichtigt werden. Neben
den Fehlerprotokollen sind auch die Sendeprotokolle von Interesse. Zunchst
sollten den Benutzern durch den Faxserver die Sendeprotokolle zu den
jeweiligen Faxsendungen zur Verfgung gestellt werden. Nur so knnen die
Benutzer kurzfristig z. B. auf Verbindungsfehler reagieren. Weiterhin sollte
die Mglichkeit bestehen, die anfallenden Gebhren mittels der Sende-
protokolle zu ermitteln und auf die entsprechenden Kostenstellen zu verteilen.
Ein weiterer Einflussfaktor fr die Auswahl der Applikationssoftware ist die bertragung vom Fax-
server zum Arbeitsplatz
Frage, wie Faxeingnge den Empfnger erreichen. Die digitale Weiterleitung
von Faxeingngen ber das Netz wird auch als Fax-Routing bezeichnet.
Die technisch am einfachsten zu realisierende Mglichkeit ist natrlich der Ausdruck auf Papier
Ansatz, Faxeingnge an zentraler Stelle (Fax-Poststelle) auszudrucken und
den Ausdruck an den Empfnger weiterzuleiten. Der Vorteil dieser Lsung ist,
dass die Faxeingnge fr die Akten zentral ausgedruckt werden. Zudem
knnen die eingehenden Faxsendungen sowohl digital als auch manuell
archiviert werden. Auerdem sind bestehende Vertretungsregelungen pro-
blemlos zu bernehmen. Nachteilig an diesem Verfahren ist die u. U. daraus
entstehende Arbeitsbelastung der Fax-Poststelle. Auerdem stehen die Fax-
daten dann nicht in elektronischer Form an den Arbeitspltzen zur Verfgung.
Eine weitere Mglichkeit besteht darin, dass von der Fax-Poststelle Fax- manuelle Weiterleitung
mittels E-Mail
eingnge per E-Mail an den Empfnger gesandt werden. Der Nachteil dieses
Verfahrens besteht ebenfalls in der Arbeitsbelastung der Fax-Poststelle. Dabei
wird nicht automatisch von jedem Eingangs-Fax ein Ausdruck gefertigt. Wenn
ein solcher Ausdruck aus organisatorischen oder sonstigen Grnden
gewnscht wird, mssen entsprechende Regelungen getroffen werden.
Fr die automatische Weiterleitung von Eingangs-Faxsendungen an den automatische
Weiterleitung
Empfnger ber das Netz gibt es folgende Mglichkeiten:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
a) Linerouting
Hier wird jeder Leitung ein fester Empfnger zugeordnet. Die Anzahl der
direkt erreichbaren Empfnger ist auf die Anzahl der zur Verfgung stehenden
Leitungen begrenzt.
b) Auswertung der Absenderkennung
Ein weiteres Verfahren stellt auf die bermittelte Absenderkennung eines
Faxeingangs (CSID - Call Subscriber ID) ab. Hierbei wird auf dem Faxserver
festgelegt, dass Faxeingnge bestimmter Absender jeweils an einen bestimm-
ten Empfnger weitergeleitet werden. Der Nachteil dieses Verfahrens besteht
darin, dass nur Faxeingnge bereits bekannter Absender automatisch weiter-
geleitet werden. Alle anderen Faxeingnge mssen manuell an die Empfnger
weitergeleitet werden. Problematisch ist zudem, dass Absenderkennungen
vom Absender frei gewhlt werden knnen und daher u. U. nicht zuverlssig
sind.
c) Signalisierung mittels ISDN
Sofern ISDN zum Einsatz kommt, gibt es weitere Mglichkeiten des automa-
tischen Fax-Routings. Hierbei muss allerdings zwischen dem so genannten
Mehrgerteanschluss und dem Anlagenanschluss unterschieden werden.
Bei einem Mehrgerteanschluss stehen 2 Leitungen und bis zu maximal
10 Rufnummern je Anschluss zur Verfgung. Die Rufnummern werden durch
die jeweilige Telefongesellschaft vergeben. Sofern im Faxserver eine ISDN-
Karte oder eine Faxkarte mit ISDN-Schnittstelle vorhanden ist, kann anhand
der durch den Sender benutzten Rufnummer der Empfnger bestimmt werden.
Aufgrund der Begrenzung auf 10 Rufnummern ist es somit auch nur mglich,
an maximal 10 Empfnger Faxeingnge automatisch zu verteilen.
Beim ISDN-Anlagenanschluss ist zwischen dem ffentlichen Telefonnetz und
dem organisationsinternen Telefonnetz eine Telekommunikationsanlage
geschaltet. Auch bei dieser Anschlussart kann der Faxserver die durch den
Sender benutzte Rufnummer erkennen und einen Faxeingang anhand dieser
Nummer automatisch zum entsprechenden Empfnger routen. Die maximal
mgliche Anzahl der Empfnger ist dabei deutlich hher. Die Realisierung
erfolgt dadurch, dass jeder Mitarbeiter, der vom Faxserver Faxeingnge erhal-
ten soll, eine zweite Durchwahlnummer erhlt. Die Telefonanlage leitet
Eingnge, die auf dieser zweiten Nummer erfolgen, direkt an den Faxserver
weiter. Einziger Nachteil dieses Verfahrens ist, dass der Rufnummernpool
einer Organisation strker belastet wird. Die Telekommunikationsanlage muss
also entsprechend leistungsfhig sein.
d) Auswertung des Empfngers mittels optischer Zeichenerkennung
Ein weiteres, aber wenig verbreitetes Verfahren zum automatischen Routing
von Faxeingngen ist die optische Zeichenerkennung (OCR). Dabei wird ver-
sucht, im Faxeingang z. B. im Anschriftenfeld, Namen oder Nummern zu
erkennen. Dieses Verfahren setzt leistungsfhige OCR-Software und entspre-
chende Rechenleistung sowie mglichst genormte Adressfelder bei Fax-
eingngen voraus.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
e) weitere Verfahren
Es gibt zwei weitere Verfahren zur automatischen Weiterleitung von Fax-
eingngen, das Dual Tone Multi Frequency Verfahren und das Direct Inward
Dialing Verfahren. Da beide Verfahren in Deutschland nicht anwendbar sind,
werden sie hier nur aus Grnden der Vollstndigkeit erwhnt.
Die automatische Weiterleitung von eingehenden Faxsendungen hat den automatische Weiter-
leitung bei hohem
Vorteil, dass das Personal der Fax-Poststelle entlastet wird. Zudem erreichen Faxvolumen
eingehende Faxsendungen den Empfnger schneller. Nachteilig ist insbeson-
dere bei der Signalisierung mittels ISDN, dass der Rufnummernpool entspre-
chend belastet wird. Dafr ist die automatische Weiterleitung von Eingangs-
Faxsendungen hiermit am besten zu realisieren. Bei einem hohen Aufkommen
an eingehenden Faxsendungen sollte dieser Lsung der Vorzug gegeben
werden. Sofern eingehende Faxsendungen nur fr wenige Arbeitspltze bzw.
Gruppen bestimmt sind und berwiegend immer von den gleichen Absendern
kommen, ist die Auswertung der Absenderkennung auch eine praktikable
Lsung. Bei nur geringem Aufkommen an Eingangs-Faxsendungen kann die
manuelle Verteilung eine sinnvolle Alternative darstellen.
- Werden bei der Auswahl des Faxservers Kompatibilittsgesichtspunkte
bercksichtigt?
- Ist sichergestellt, dass das zu erwartende Faxvolumen durch die
ausgewhlten Kommunikationskarten bewltigt werden kann?
- Untersttzt die ausgewhlte Faxserver-Applikation alle bentigten
Leistungsmerkmale?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.182 Regelmige Kontrollen der IT-

Sicherheitsmanahmen
Im IT-Grundschutzhandbuch werden eine Vielzahl von Regelungen unangekndigte
Kontrollen
vorgestellt, die fr die Erreichung der angestrebten IT-Sicherheit notwendig
sind. Es ist aber nicht ausreichend, diese Regelungen bekannt zu geben, es
muss auch regelmig deren Einhaltung kontrolliert werden. Regelmig
heit hierbei aber nicht, dass die Kontrollen an vorhersagbaren Terminen
stattfinden, da angekndigte Kontrollen meist ein verzerrtes Bild des
Untersuchungsgegenstands ergeben.
Kontrollen sollten vor allen Dingen darauf ausgerichtet sein, Mngel abzu-
stellen. Fr die Akzeptanz von Kontrollen ist es wichtig, dass dies allen
Beteiligten als Ziel der Kontrollen erkennbar ist und dass die Kontrollen nicht
den Charakter von Schulmeisterei haben. Es ist daher sinnvoll, whrend einer
Kontrolle mit den Beteiligten ber mgliche Problemlsungen zu sprechen
und entsprechende Abhilfen vorzubereiten.
Wenn Mitarbeiter eine Regelung ignorieren oder umgehen, ist das meist ein Regelungen auf Arbeits-
ablufe abstimmen
Zeichen dafr, dass diese nicht mit den Arbeitsablufen vereinbar ist oder
durch die Mitarbeiter nicht umgesetzt werden kann. Beispielsweise ist eine
Anweisung, vertrauliche Schreiben nicht unbeaufsichtigt am Drucker liegen
zu lassen, unsinnig, wenn zum Drucken nur ein weit entfernter Netzdrucker
zur Verfgung steht.
Wenn bei Kontrollen Mngel festgestellt werden, kommt es nicht darauf an, Ursachen der Sicher-
heitsdefizite beseitigen
nur die Symptome zu beseitigen. Vielmehr ist es wichtig, die Ursachen fr
diese Probleme festzustellen und Lsungen aufzuzeigen. Diese knnen bei-
spielsweise in der nderung bestehender Regelungen oder in der Hinzunahme
technischer Manahmen bestehen.
Kontrollen sollen helfen, Fehlerquellen abzustellen. Es ist fr die Akzeptanz Schuldzuweisungen
vermeiden
von Kontrollen extrem wichtig, dass dabei keine Personen blogestellt werden
oder als "Schuldige" identifiziert werden. Wenn die Mitarbeiter dies
befrchten mssen, besteht die Gefahr, dass sie nicht offen ber ihnen
bekannte Schwachstellen und Sicherheitslcken berichten, sondern versuchen,
bestehende Probleme zu vertuschen.
- Werden alle Regelungen und IT-Sicherheitsmanahmen auf ihre
Umsetzbarkeit untersucht?
- Wie hufig werden die bestehenden Regelungen und IT-Sicher-
heitsmanahmen auf ihre Einhaltung kontrolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.183 Durchfhrung einer RAS-Anforderungsanalyse

Bevor ein System fr den entfernten Zugang eingesetzt wird, sollte eine
Anforderungsanalyse durchgefhrt werden. Ziel der Anforderungsanalyse ist
es einerseits, alle im konkreten Fall in Frage kommenden Einsatzszenarien zu
bestimmen und andererseits daraus Anforderungen an die bentigten Hard-
und Softwarekomponenten abzuleiten. Durch das Aufstellen und
"Durchspielen" von Nutzungsszenarien knnen insbesondere spezielle
Anforderungen aufgedeckt werden, so dass sich entsprechende Anforderungen
(K.-o.-Kriterien) an die RAS-Systemarchitektur oder die RAS-Software
stellen lassen.
Im Rahmen der Anforderungsanalyse sind u. a. folgende Fragen zu klren:
- Welche Benutzer werden den RAS-Zugang nutzen (Telearbeiter,
Auendienstmitarbeiter, Mitarbeiter auf Dienstreise)?
- Soll der RAS-Zugang von mobilen Benutzern genutzt werden?
- Zu welchem Zweck wird der RAS-Zugang jeweils genutzt (Abfragen von
Informationen, Einstellen von Informationen, Programmnutzung)?
- Mssen die entfernten Benutzer auf das komplette LAN, d. h. alle dort
verfgbaren Daten und Dienste) Zugriff haben?
- Mssen spezielle Softwareprodukte ber den RAS-Zugang genutzt
werden?
- Mssen spezielle Protokolle ber den RAS-Zugang genutzt werden?
- Von welchen (entfernten) Orten wird der RAS-Zugang genutzt (national,
international)?
- Welche Telekommunikations-Zugangstechnologien kommen zum Einsatz
(Festnetz, Mobiltelefon, Internet)?
Die Anforderungen fr die geplanten Szenarien sollten dokumentiert und mit
den Netzadministratoren und dem technischen Personal abgestimmt werden.
Sie bilden u. a. die Grundlage fr das weitere Vorgehen (Architektur,
Beschaffung, Einsatz).
- Wurde eine RAS-Anforderungsanalyse durchgefhrt?
- Sind alle speziellen Anforderungen erfasst, die aus den lokalen Gegeben-
heiten resultieren?
- Wurde die Anforderungsliste mit den Netzadministratoren und dem tech-
nischen Personal abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.184 Entwicklung eines RAS-Konzeptes

Der Aufbau eines RAS-Systems erfordert, dass nach der Durchfhrung der
Anforderungsanalyse (siehe Manahme M 2.183 Durchfhrung einer RAS-
Anforderungsanalyse) und vor der technischen Realisierung des Systems ein
RAS-Konzept entworfen wird. Das Konzept legt im Wesentlichen fest, welche
RAS-Systemarchitektur gewhlt werden soll und welche Regeln fr den
Umgang mit dem RAS-System fr alle Betroffenen gelten. Das Konzept kann
grob in drei Teilbereiche unterteilt werden:
1. Das organisatorische Konzept, durch das alle organisatorischen Belange Organisation
fr das RAS-System erfasst werden. Es ist darauf zu achten, dass das RAS-
System in existierende organisatorische Ablufe integriert wird, so dass
deren Homogenitt und Konsistenz gewahrt bleibt.
2. Das technische Konzept, das eine technische Realisierung des RAS- Technik
Systems beschreibt. Dieses sollte den Bedarf abdecken, der durch die
Anforderungsanalyse festgestellt wurde, und - so weit realisierbar - alle
erforderlichen Zugangsszenarien ermglichen. Bei der technischen
Planung sind alle existierenden Rahmenbedingungen aus der aktuellen
technischen Situation zu bercksichtigen, um technische Inkompatibilitten
zu vermeiden.
3. Das Sicherheitskonzept, das die sicherheitsrelevanten Belange des RAS- IT-Sicherheit
Systems umfasst. Da die Sicherheit in der Regel nur durch organisatorische
und technische Manahmen gemeinsam zu gewhrleisten ist, sollte die
Konzeption der Sicherheit eine separate Einheit bilden und nicht innerhalb
des organisatorischen und des technischen Konzeptes lediglich als
Unterabschnitt enthalten sein.
Im Folgenden werden jeweils die wesentlichen Fragestellungen aufgezeigt,
die im Rahmen der Teilkonzepte beantwortet werden mssen. Je nach konkre-
ter Situation ergibt sich naturgem ein speziell auf die jeweiligen organisato-
rischen und technischen Gegebenheiten zugeschnittener zustzlicher
Abstimmungsbedarf.
Das organisatorische Konzept sollte folgende Punkte beinhalten bzw. regeln:
- Es sollten die Verantwortlichkeiten fr das RAS-System festgelegt werden Verantwortlichkeiten
festlegen
(Installation, Verwaltung, berprfung, berwachung). Je nach organisa-
torischer Struktur mssen die Verantwortlichkeiten existierender Rollen
erweitert werden oder es ist die Schaffung neuer Rollen notwendig (siehe
auch Manahme M 2.1 Festlegung von Verantwortlichkeiten und
Regelungen fr den IT-Einsatz).
- Es sollten verbindliche Regelungen darber festgelegt werden, welchen Berechtigungskonzept
Benutzern der entfernte Zugang ber das RAS-System erlaubt werden soll.
Es empfiehlt sich, auch fr den RAS-Zugang unterschiedliche Gruppen mit
verschiedenen Berechtigungen zu definieren. Die Gruppenzugehrigkeit
von einzelnen Benutzern sollte durch ein entsprechendes
Anforderungsprofil geregelt werden, das festlegt, welche Voraussetzungen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
fr die Mitgliedschaft in einer Gruppe erfllt werden mssen. Mgliche

Voraussetzungen sind die Notwendigkeit (Telearbeiter, Auendienstler),
die Lnge der Betriebszugehrigkeit und eine Befrwortung durch
Vorgesetzte. Ob und wie die Erlaubnis zum entfernten Zugriff
reglementiert werden soll, muss jeweils innerhalb der Organisation
entschieden werden. Oft existieren schon entsprechende Regelungen, z. B.
fr die Erlaubnis zur Nutzung von Internetzugngen, die dann adaptiert
werden knnen.
Die erteilten Zugangs- und Zugriffsberechtigungen sind im Rahmen der
RAS-System-Dokumentation zu erfassen und mssen bei nderungen
fortgeschrieben werden.
- Fr feste entfernte Standorte (wie Telearbeitspltze) mssen Anforderungen an
Betriebsorte
Anforderungen festgelegt werden, die beschreiben, welchen Ansprchen
(z. B. in Bezug auf Sicherheit und technischer Ausstattung) der entfernte
Arbeitsplatz gengen muss, damit von dort RAS-Verbindungen in das
lokale Netz erlaubt werden knnen. Das Konzept kann weiterhin eine
anfngliche sowie eine periodisch wiederkehrende berprfung der
Rumlichkeiten vorsehen und regeln, wie und durch wen diese erfolgt.
- Die Betriebsorte von RAS-Clients unterliegen in der Regel nicht der Kon-
trolle des LAN-Betreibers und besitzen daher auch ein besonderes Gefhr-
dungspotential. Kann das Gefhrdungspotential fr stationre Clients
(beispielsweise bei Telearbeit) durch entsprechende Vorgaben noch einge-
schrnkt werden, so muss fr mobile RAS-Clients in der Regel ein sehr
hohes Gefhrdungsma angenommen werden. Nicht jeder Ort, der die
technischen Voraussetzungen zum RAS-Verbindungsaufbau bereitstellt, ist
auch dafr geeignet. Daher mssen Regelungen dafr getroffen werden,
von welchen entfernten Standorten aus RAS-Verbindungen zum Ziel-LAN
aufgebaut werden drfen. Je nach geplantem Einsatzszenario kann es aber
zweckmiger sein, eine Negativliste von besonders ungeeigneten
Standorten zu fhren. Dazu knnen z. B. Hotel-Foyers, Hotel-Business-
Center oder Zug-Abteile gehren.
- Fr die RAS-Administration sollten Prozeduren festgelegt werden, wie nderungsmanagement
nderungen an der RAS-Konfiguration durchzufhren sind. Da Verlet-
zungen der Sicherheit von RAS-Zugngen u. U. die Kompromittierung des
gesamten LANs nach sich ziehen knnen, sollten nderungen an der RAS-
Konfiguration nur durch eine festgelegte Vorgehensweise erfolgen
(Beispiel: Beantragung, berprfung der geplanten Konfiguration, Durch-
fhrung, berprfung der durchgefhrten Vernderung).
Das technische Konzept sollte folgende Punkte beinhalten bzw. regeln:
- Es sollte beschrieben sein, wie das RAS-System durch Hard- und Soft- technische Ausstattung
ware-Komponenten technisch realisiert ist. Die Komponenten werden
lediglich durch ihre Funktion definiert. Durch eine nachgeschaltete Analy-
se vorhandener Systemkomponenten und am Markt beschaffbarer neuer
Komponenten knnen dann die Elemente des Konzeptes tatschlichen
Gerten und Software-Komponenten zugeordnet werden (siehe M 2.186
Geeignete Auswahl eines RAS-Produktes).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Alle mglichen Zugangspunkte und die darber verwendeten Zugangs-

protokolle sind zu beschreiben.
- Alle Dienste und Protokolle, die ber den RAS-Zugang zugelassen werden,
sowie die darber zugreifbaren Ressourcen sind aufzufhren.
- Es ist zu planen, welche Teilnetze ber den RAS-Zugang erreichbar sein
sollen bzw. mssen (vgl. auch RAS-Sicherheitskonzept).
Das RAS-Sicherheitskonzept sollte folgende Punkte beinhalten bzw. regeln:
- Fr die RAS-Nutzung sollte eine Sicherheitsrichtlinie formuliert werden. RAS-Sicherheitsrichtlinie
Diese RAS-Sicherheitsrichtlinie muss sich an den existierenden
bergreifenden Sicherheitsrichtlinien orientieren. In der Regel gilt der
Grundsatz, dass beim Zugriff ber das RAS-System geringere Berech-
tigungen gelten und strkere berprfungen stattfinden sollten, als beim
lokalen Zugriff.
- Die Art und Weise der Benutzer-Authentisierung sowie die dafr zu ver- Authentisierung
wendenden Mechanismen sollten festlegt werden.
- Alle an der Authentisierung beteiligten Komponenten sollten erfasst und
deren Aufgaben und Interaktionen beschrieben werden.
- Alle an der Zugriffskontrolle beteiligten Komponenten sollten erfasst und Zugriffskontrolle
deren Aufgaben und Interaktionen beschrieben werden. Auf diese Weise
kann festgestellt werden, ob z. B. existierende Zugriffskontrollmecha-
nismen so konfiguriert werden knnen, dass beim entfernten Zugriff
automatisch restriktivere Einstellungen gelten.
- Im Rahmen der Sicherheitskonzeption sind alle RAS-Zugangspunkte zum Erfassung aller RAS-
Zugangspunkte
lokalen Netz zu erfassen und es ist zu beschreiben, wie diese
Zugangspunkte an das LAN angeschlossen werden (siehe auch Kapitel 7.3
Sicherheitsgateway (Firewall) ).
- Das Sicherheitskonzept muss analysieren, aufbauend auf der aktuellen Eingrenzen der externen
Zugriffe
Netzstruktur, welche Teilnetze bei Nutzung eines RAS-Zugangs erreichbar
sind. Fr Bus-basierte Netze (beispielsweise Ethernet) sind typischerweise
alle Rechner des Teilnetzes zugreifbar, in dem der RAS-Zugang angesie-
delt ist. Hier sollte berlegt werden, dedizierte Zugangsnetze (Access
Network) zu bilden, aus denen nur kontrolliert (ber Router, Paketfilter
bzw. interne Firewall) in das produktive Netz zugegriffen werden kann.
Die Bildung von Zugangsnetzen erfordert dabei die Anschaffung und
Wartung zustzlicher Hard- und Software (siehe auch M 5.77 Bildung von
Teilnetzen).
- Fr den Fall von Sicherheitsvorfllen sind organisatorische Meldewege zu Meldewesen fr
Sicherheitsprobleme
planen, ber die gezielt und schnell auf Sicherheitsvorflle reagiert werden
kann. Im technischen Konzept sollten entsprechend Mechanismen geplant
werden, die das Erkennen von Sicherheitsvorfllen erlauben und diese
Vorflle zu dem zustndigen Administrator leiten, der den Anfang des
organisatorischen Meldewegs bildet.
- Da beim entfernten Zugriff auf ein LAN besondere Sicherheitsrisiken Schulung und
Sensibilisierung
durch die meist ungesicherte Umgebung eines RAS-Clients bestehen, sollte
jeder Benutzer, fr den der RAS-Zugang erlaubt werden soll, eine besonde-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
re Schulung erhalten. Im Rahmen dieser Schulung sollen die Benutzer

einerseits fr die Gefahren sensibilisiert und andererseits im Umgang mit
den technischen Gerten und der Software unterrichtet werden.
- Falls Authentisierungs-Token zum Einsatz kommen sollen, mssen die
Benutzer ber deren ordnungsgeme Handhabung informiert werden.
- Ebenso mssen auch die Administratoren sowohl fr die eingesetzten
Produkte grndlich ausgebildet als auch fr Sicherheitsrisiken sensibilisiert
werden.
- Den Administratoren muss nicht nur fr den Betrieb der RAS-Systeme
ausreichend Zeit zur Verfgung stehen, sondern auch fr die
Informationssuche ber aktuelle Sicherheitslcken und die Einarbeitung in
neue Komponenten.
- Bestehende Regelungen zur Rollentrennung (z. B. Administrator und
Revisor) sollten auf die Verwaltung des RAS-Systems bertragen werden.
- Schlielich mssen die Anforderungen an die Verfgbarkeit der RAS- Anforderungen an die
Verfgbarkeit
Systeme festgelegt werden. Falls erforderlich sind auerdem
Ausweichlsungen vorzusehen, die beim Ausfall eines RAS-Systems
ersatzweise verwendet werden knnen.
Aus der RAS-Anforderungsanalyse und -Konzeption ergeben sich naturgem
konkrete Anforderungen an die Hard- und Software-Komponenten, die
eingesetzt werden sollen. Diese sollten fr eine Beschaffung verfeinert und
konkretisiert werden, wie in Manahme M 2.186 Geeignete Auswahl eines
RAS-Produktes beschrieben.
- Existiert ein Sicherheitskonzept fr die RAS-Nutzung?
- Existieren Sicherheitsrichtlinien fr die RAS-Nutzung, an denen sich die
Benutzer orientieren knnen?
- Ist ein Berechtigungskonzept fr entfernte Zugriffe vorhanden?
- Werden die Manahmen des RAS-Sicherheitskonzepts regelmig auf
deren korrekte Umsetzung geprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.185 Auswahl einer geeigneten RAS-

Systemarchitektur
Je nach den geplanten Einsatzszenarien knnen unterschiedliche RAS-
Systemarchitekturen genutzt werden, um den entfernten Zugang zu einem
LAN zu realisieren. Die verschiedenen Systemarchitekturen haben natur-
gem unterschiedliche Eigenschaften und sind daher fr die einzelnen
Einsatzzwecke unterschiedlich gut geeignet. Prinzipiell ist zwar jede Kombi-
nation mglich, erfordert jedoch bei einer ungnstigen Wahl zustzlichen
Aufwand (z. B. zustzliche Hardware, administrativer Mehraufwand).
Die folgenden RAS-Szenarien, denen jeweils eine typische Systemarchitektur
zugeordnet werden kann, kommen in der Praxis hufig zum Einsatz.
1. Anbindung einzelner Rechner an ein LAN
In diesem Fall kommt oft eine Architektur in Frage, die mit "Direct Dial-
In" (Direkte Einwahl) bezeichnet wird. Die RAS-Software wird auf dem
Rechner des entfernten Benutzers installiert. Der Rechner besitzt eine
Verbindung zu einem Telekommunikationsnetz. Der Anschluss kann hier
beispielsweise ber ein analoges Modem, eine ISDN-Karte oder auch ber
ein Mobiltelefon erfolgen. Zur Verbindungsaufnahme whlt die RAS-
Client-Software die Telefonnummer, unter der die RAS-Server-Software
zu erreichen ist. Auch der RAS-Server ist ber ein Modem oder eine
ISDN-Karte mit dem Telekommunikationsnetz verbunden. Je nach RAS-
Server-Produkt (auch Access-Server genannt) kann ein Server mehrere
Kommunikationsverbindungen aufbauen (z. B. ber so genannte "Modem-
Pools"), so dass sich gleichzeitig mehrere RAS-Clients einwhlen knnen.
Vorteilhaft ist hier, dass durch dieses Verfahren ein einzelner Rechner von
einem beliebigen Ort aus an das LAN angeschlossen werden kann. Dies ist
insbesondere fr mobile Benutzer gnstig. Durch die direkte Einwahl auf
dem RAS-Server des Ziel-LANs wird die Verbindung zwar nur ber die
Telekommunikationsnetze der benutzten Telekommunikationsanbieter
geschaltet, der Einsatz von Mechanismen zur Kommunikationsabsicherung
ist jedoch auch hier zu empfehlen, also z. B. Verschlsselung, digitale
Signaturen, Authentisierung.
Nachteilig ist hier, dass je nach Entfernung zum Ziel-LAN unterschiedlich
hohe Telefonkosten entstehen knnen, die (ohne besondere Vorkehrungen)
in der Regel beim entfernten Benutzer anfallen. Fr die Anbindung
mehrerer Benutzer, die sich gemeinsam an einem entfernten Ort befinden,
ist diese Variante nicht geeignet, da jeweils eine dedizierte Verbindung
zwischen Client und Server aufgebaut wird. Jeder Client muss daher mit
einem entsprechenden Modem ausgestattet sein; die gleichzeitige Nutzung
genau einer gemeinsamen Verbindung durch mehrere Client-Rechner ist
auf diese Weise nicht mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2. Anbindung mehrerer Rechner an ein LAN

In diesem Fall kommt oft eine Architektur in Frage, die mit "Direct LAN-
to-LAN-Dial-In" bezeichnet wird. Die Rechner der entfernten Benutzer
bilden hier ein eigenes LAN. Die RAS-Client-Software ist dabei in der
Regel nicht auf einem der Benutzerrechner installiert, stattdessen wird die
RAS-Funktionalitt durch eine dedizierte Hardware in Form eines Routers
zur Verfgung gestellt. Mssen Datenpakete von einem LAN in das andere
bertragen werden, so stellt der im Router enthaltene RAS-Client automa-
tisch eine Verbindung mit dem Ziel-LAN her, indem er den dortigen RAS-
Server anwhlt. In dieser Konfiguration wird meist eine symmetrische
Architektur fr beide LANs gewhlt, so dass der anzuwhlende RAS-
Server auch in einem Router enthalten ist und eine Punkt-zu-Punkt
Verbindung entsteht. Alternativ knnen mehrere entfernte LANs ber
einen Access-Server (RAS-Server, der mehrere gleichzeitige Verbindun-
gen erlaubt) angebunden werden.
Vorteilhaft ist hier, dass durch die Funktionstrennung von RAS-Client und
Rechner des entfernten Benutzers ber eine Verbindung zum Ziel-LAN
mehrere entfernte IT-Systeme angebunden werden knnen. Der Router, der
den RAS-Client enthlt, stellt dabei die aufgebaute Verbindung fr alle am
entfernten LAN angeschlossenen Rechner zur gleichzeitigen Nutzung
bereit. Dies ist jedoch zugleich auch nachteilig, da die Verbindungskapa-
zitt unter den zugreifenden entfernten IT-Systemen aufgeteilt wird und
nicht exklusiv genutzt werden kann.
Selbstverstndlicher Nachteil ist hier, dass die Clients nicht mehr mobil
sind.
3. Anbindung eines Rechners oder eines LANs ber einen Service
Provider
Als Erweiterung der beiden vorangegangenen Szenarien kann die Anbin-
dung eines Rechners oder eines LANs auch ber eine spezielle Zugangs-
rufnummer eines Service Providers erfolgen. In diesem Fall kontaktiert der
RAS-Client eine besondere Telefonnummer, die hufig eine Ortsgesprch-
Rufnummer oder eine kostenfreie Rufnummer ist. Anrufe fr diese
spezielle Nummer werden vom anbietenden Service Provider innerhalb des
Kommunikationsnetzes an den RAS-Server des Ziel-LANs weitergeleitet.
Diese Variante erlaubt insbesondere Mitarbeitern auf Dienstreise eine fr
sie kostengnstige Verbindungsaufnahme.
4. Anbindung eines Rechners oder eines LANs ber Internet
Dieser Fall unterscheidet sich von den obigen Szenarien dadurch, dass vom
Client zunchst eine Verbindung zu einem Internet-Dienstanbieter (Internet
Service Provider - ISP) aufgebaut wird. Erst im zweiten Schritt verbindet
sich der Client ber die bestehende Internet-Anbindung mit dem Ziel-LAN.
Dazu muss der entfernte Benutzer eine Zugangsberechtigung fr den
Internet-Zugang des jeweiligen ISP besitzen und das Ziel-LAN ber einen
Internet-Anschluss verfgen. Die Kommunikation mit dem Ziel-LAN
erfolgt in diesem Fall ber Internetprotokolle. Ein eigener RAS-Server (fr
direkte Verbindungen ber ein Telekommunikationsnetz) ist im Ziel-LAN
nicht erforderlich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese Variante wird in der Regel genutzt, um die Telefonkosten fr den

entfernten Benutzer gering zu halten (z. B. Ortsgesprchsgebhren), kann
sich jedoch in der Konfiguration als relativ komplex erweisen. Da der
Internet-Zugang eines LANs in der Regel durch eine Firewall geschtzt
wird, muss bei der Planung der Firewall-Architektur die Mglichkeit des
Internet-basierten Zugangs entfernter Benutzer bercksichtigt werden
(siehe auch Kapitel 7.3 Sicherheitsgateway (Firewall)).
5. Aufbau eines Virtuellen Privaten Netzes (VPN)
Neben der Mglichkeit, mit Hilfe von Internet-basierten Protokollen und
Programmen (z. B. telnet, ftp, POP3) auf Daten des internen Netzes zuzu-
greifen, knnen auch so genannte Tunnel-Protokolle benutzt werden. Diese
erlauben es, ber das Internet als Transportmedium eine Direktverbindung
zwischen dem RAS-Client und dem RAS-Server des Ziel-LANs zu simu-
lieren. ber diese scheinbare Direktverbindung erfolgt die eigentliche
RAS-Kommunikation (siehe auch M 5.76 Einsatz geeigneter Tunnel-
Protokolle fr die RAS-Kommunikation). Der RAS-Server des Ziel-LANs
muss hierzu ber das Internet erreichbar sein. Oft bieten Firewall-Produkte
RAS-Untersttzung an, so dass die Konfiguration des RAS-Zugangs mit
Hilfe des Werkzeugs zur Firewall-Administration erfolgen kann.
Der Vorteil einer solchen Lsung liegt darin, dass Internetzugnge
mittlerweile weit verbreitet sind, so dass hier in einfacher Weise auf einem
existierenden Verbindungsnetz aufgebaut werden kann. Nachteilig ist
jedoch, dass das Internet aufgrund seiner offenen Struktur nicht als sicheres
Netz konzipiert wurde. Aus diesem Grund ist hier die Absicherung der
Kommunikation besonders wichtig. Beim Tunneling geschieht dies durch
den Einsatz kryptographischer Verfahren. Hierdurch wird ein so genanntes
Virtuelles Privates Netz (VPN) realisiert.
Nach erfolgreichem Verbindungsaufbau besteht eine Verbindung ber das
Internet zwischen dem entfernten Rechner und dem LAN, meist ber die
Firewall hinweg. Unter dem Gesichtspunkt der IT-Sicherheit ist dies
jedoch problematisch, da ein Angreifer u. U. weitreichende Zugriffs-
mglichkeiten auf das Ziel-LAN hat, wenn es ihm gelingt, in einen Client-
Rechner einzudringen. Der ausreichende Schutz aller Clients ist also
entscheidend fr die Sicherheit des Gesamtsystems. Aufgrund der fehlen-
den Durchsatzgarantien bei der Internet-Kommunikation muss zustzlich
davon ausgegangen werden, dass die Dienstqualitt in der Regel geringer
ausfllt als bei direkten und dedizierten Verbindungen zum LAN ber das
Telefonnetz. Bei dieser Architektur sollten daher die Auswirkungen auf die
IT-Sicherheit und die Performance sorgfltig geprft werden.
Die vorgestellten Szenarien und Systemarchitekturen sind gngige Varianten
fr die Realisierung von RAS-Zugngen, knnen jedoch trotzdem nur als
Beispiele verstanden werden. Welche konkrete Systemarchitektur zu whlen
ist, hngt sehr von den geplanten Einsatzszenarien ab. Oft besteht auch die
Anforderung, mehrere Szenarien gleichzeitig zu realisieren (z. B. Telearbeit
und mobile Benutzer). Insbesondere mobilen Benutzern soll eine grtmg-
liche Freiheit bei der Wahl der Zugangstechnologie angeboten werden, damit
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sie von mglichst vielen Orten und Arbeitsumgebungen aus auf das lokale
Netz zugreifen knnen.
Unter dem Gesichtspunkt der IT-Sicherheit ist jedoch zu bercksichtigen, dass
die Verwendung von unterschiedlichen Zugangstechnologien in der Regel
auch unterschiedliche Zugangspunkte im Ziel-LAN erfordert. Generell ist ein
LAN, das ber mehrere externe Zugnge verfgt, einer greren Zahl von
Gefhrdungen ausgesetzt als ein LAN, das nur ber genau einen externen
Zugang erreichbar ist. Andererseits kann jedoch durch unterschiedliche
Zugangspunkte die Verfgbarkeit des RAS-Systems erhht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.186 Geeignete Auswahl eines RAS-Produktes

RAS-Produkte unterscheiden sich in ihrem Leistungsumfang, den angebote-
nen Sicherheitsmechanismen, Bedienkomfort und Wirtschaftlichkeit. Zudem
stellen sie unterschiedliche Voraussetzungen an Hard- und Software-Kompo-
nenten im Einsatzumfeld.
Bevor ein "RAS-Produkt" beschafft wird, sollte daher eine Anforderungsliste
erstellt werden, anhand derer die am Markt erhltlichen Produkte bewertet
werden. Aufgrund der Bewertung kann dann eine fundierte Kaufentscheidung
erfolgen, die sicherstellt, dass das zu beschaffende Produkt im praktischen
Betrieb den Anforderungen gengt.
Ein RAS-System besteht in der Regel aus mehreren Hard- und Software-
Komponenten, so dass genau genommen, nicht von "einem RAS-Produkt"
gesprochen werden kann: Zunchst kann grob zwischen LAN-seitigen und
Client-seitigen Komponenten unterschieden werden. Die konkret zu beschaf-
fenden Komponenten hngen von der gewhlten RAS-Systemarchitektur ab.
So knnen im einfachsten Fall z. B. ein Windows-basierter PC und ein
Laptop, die jeweils mit einer ISDN-Karte ausgestattet sind (siehe auch
M 2.106 Auswahl geeigneter ISDN-Karten in der Beschaffung), als RAS-
Server und -Client fungieren und den RAS-Dienst von Windows NT nutzen.
Hingegen betreiben groe Institutionen oft gleichzeitig viele RAS-
Verbindungen fr unterschiedliche Einsatzzwecke. Hierfr geeignete
Lsungen erfordern in der Regel besondere IT-Systeme (Hardware mit
Software), die speziell fr den Einsatz als RAS-Server konzipiert sind.
Die folgende Liste gibt einen groben berblick ber mgliche allgemeine
Bewertungskriterien, erhebt jedoch keinen Anspruch auf Vollstndigkeit und
kann um weitere allgemeine Anforderungen erweitert werden. Neben den hier
aufgefhrten Kriterien mssen im Rahmen der RAS-Anforderungsanalyse
(siehe Manahme M 2.183 Durchfhrung einer RAS-Anforderungsanalyse)
weitere spezifische Anforderungen erarbeitet werden, die aus den geplanten
konkreten Einsatzszenarien resultieren.
1 Allgemeine Kriterien
1.1 Performance und Skalierbarkeit
- Kann das System den Ansprchen an die Performance gerecht
werden?
- Kann fr das System ein transparentes Load-balancing oder
Datenkompression konfiguriert werden?
- Kann das System so konzipiert werden, dass es einem
zuknftigen Wachstumsbedarf gerecht werden kann (z. B.
durch modularen Systemaufbau, einfaches Einbinden neuer
RAS-Server, keine getrennte Benutzerverwaltung fr neue
RAS-Zugnge)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
1.2 Wartbarkeit
- Ist das Produkt einfach wartbar?
- Bietet der Hersteller regelmige Software-Updates an?
- Wird fr das Produkt die Mglichkeit des Abschlusses von
Wartungsvertrgen angeboten?
- Knnen im Rahmen der Wartungsvertrge maximale Reakti-
onszeiten fr die Problembehebung festgelegt werden?
- Bietet der Hersteller einen kompetenten technischen
Kundendienst (Call-Center, Hotline) an, der in der Lage ist,
sofort bei Problemen zu helfen?
1.3 Zuverlssigkeit/Ausfallsicherheit
- Wie zuverlssig und ausfallsicher ist das Produkt?
- Bietet der Hersteller Hochverfgbarkeitslsungen an?
- Ist das Produkt im Dauerbetrieb einsetzbar?
1.4 Benutzerfreundlichkeit
- Lsst sich das Produkt einfach installieren, konfigurieren und
nutzen? Gengt das Produkt den geltenden Ergonomievor-
schriften?
- Ist insbesondere fr den RAS-Client die Benutzerfhrung so
gestaltet, dass auch ungebte Benutzer damit arbeiten knnen,
ohne Abstriche in der Sicherheit in Kauf nehmen zu mssen
(kontextsensitive Hilfen, Online-Dokumentation, schrittweise
Anleitung mit verstndlichen Erklrungen - "Wizards",
detaillierte Fehlermeldungen)?
- Ist die Nutzung des RAS-Clients so konfigurierbar, dass die
Benutzer mglichst wenig mit technischen Details belastet
werden? Ist die Sicherheit dabei trotzdem immer gewhrlei-
stet?
1.5 Kosten
- Wie hoch sind die Anschaffungskosten der Hard- und Soft-
ware?
- Wie hoch sind die voraussichtlichen laufenden Kosten der
Hard- und Software (Wartung, Betrieb, Support)?
- Wie hoch sind die voraussichtlichen laufenden Kosten fr das
Personal (RAS-Administrator/Revisor)?
- Mssen zustzliche Soft- oder Hardware-Komponenten ange-
schafft werden (z. B. Einwahl-Server, Server fr zustzliche
Authentisierungsdienste)?
- Wie hoch sind die Kosten fr die Schulung von Mitarbeitern
und Administratoren, die mit dem RAS-Produkt umgehen
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2. Funktion
2.1 Installation und Inbetriebnahme
- Garantieren die Default-Einstellungen des RAS-Systems nach
der Installation eine sichere RAS-Konfiguration?
- Kann die Installation der RAS-Client-Software automatisiert
mit vorgegebenen Konfigurationsparametern erfolgen?
- Ist die Installation der RAS-Client-Software auch fr weniger
versierte Mitarbeiter durchfhrbar?
- Knnen wichtige Konfigurationsparameter vor Vernde-
rungen durch Benutzer geschtzt werden?
- Arbeitet das Produkt mit gngiger Hard- und Software
zusammen (Betriebssysteme, Einschubkarten, Treiber)?
- Ist das RAS-System mit gngigen Systemmanagement-
systemen kompatibel?
2.2 Verhalten im Fehlerfall
- Bleibt die Sicherheit des RAS-Zugangs auch nach einem
kritischen Fehler gewhrleistet (indem z. B. jegliche
Verbindungen nach einem Programmabbruch verhindert
werden)?
- Kann das Systemverhalten nach einem kritischen Fehler kon-
figuriert werden? Kann z. B. eingestellt werden, dass nach
einem kritischen Fehler automatisch ein Neustart durchgefhrt
oder der Administrator benachrichtigt wird?
2.3 Administration
- Enthlt die mitgelieferte Produktdokumentation eine genaue
Darstellung aller technischen und administrativen Details?
- Kann die Administration ber eine graphische Benutzer-
schnittstelle erfolgen, die sich intuitiv bedienen lsst? Ist die
administrative Schnittstelle so gestaltet, dass auf fehlerhafte,
unsichere oder inkonsistente Konfigurationen hingewiesen
wird oder diese verhindert werden?
- Wird neben der graphischen administrativen Schnittstelle auch
ein kommandozeilenbasiertes Interface angeboten?
- Ist der Zugriff auf die administrative Schnittstelle durch eine
adquate Zugriffskontrolle geschtzt, beispielsweise durch
Passworteingabe, Umsetzung eines Rollenkonzeptes
(Administrator, Revisor), Vier-Augen-Prinzip?
2.4 Protokollierung
- Bietet das Produkt Protokollierung an?
- Ist der Detailgrad der Protokollierung konfigurierbar? Werden
durch die Protokollierung alle relevanten Daten erfasst?
- Ist die Protokollierung so mglich, dass die Daten nach unter-
schiedlichen Kategorien erfasst werden knnen (z. B. verbin-
dungsorientiert, benutzerorientiert, protokollorientiert, dienst-
orientiert)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist der Zugriff auf die Protokolldaten mit einem Zugriffs-

schutz versehen?
- Bietet das Produkt die Mglichkeit an, die Protokolldaten
nicht nur lokal zu speichern, sondern auch auf entfernten
Rechnern (zentrales Protokoll)? Werden fr die entfernte
Speicherung unterschiedliche Datenbertragungstechniken
angeboten, so dass auch Fremdsysteme zur Protokollierung
benutzt werden knnen (z. B. syslog)? Kann die bertragung
der Protokolldaten abgesichert erfolgen?
- Bietet das Produkt eine Komponente zur Auswertung der
Protokolldaten an?
- Kann der Protokollmechanismus mit dem eingesetzten
Systemmanagementsystem zusammenarbeiten (bertra-
gungsformat, bertragungsprotokoll)?
- Bietet das Produkt die Mglichkeit an, beim Auftreten
bestimmter Ereignisse (z. B. Zugriffsverweigerung, mehrere
fehlgeschlagene Authentisierungsversuche in Folge) den
Administrator zu informieren oder auch geeignete Schutz-
manahmen (Abweisen des RAS-Clients, Sperren von
Benutzerkonten) automatisch durchzufhren?
- Kann die Protokollierung so erfolgen, dass die Bestimmungen
des Datenschutzes erfllt werden knnen?
2.5 Kommunikation und Datenbertragung
- Untersttzt die Server-Software LAN-seitig alle lokal existie-
renden Netzwerktechnologien (z. B. Ethernet, Token Ring,
ATM)?
- Untersttzt die Client- und Server-Software WAN-seitig alle
geplanten Zugangstechnologien (z. B. ISDN, Mobiltelefon,
analoge Telefonleitung, X.25)?
- Erlaubt der RAS-Server die gleichzeitige Einwahl mehrerer
RAS-Clients?
- Untersttzt das RAS-Produkt verschiedene Protokolle fr den
entfernten Zugang ber Telekommunikationsnetze (z. B. PPP,
SLIP)?
- Untersttzt das RAS-Produkt verschiedene Dienstprotokolle
fr den entfernten Zugriff (z. B. TCP/IP, NetBEUI, XPC,
DECnet)?
- Werden fr den Internet-basierten Zugriff Tunnel-Protokolle
(z. B. PPTP, L2F, IPSec) untersttzt?
- Erlaubt das RAS-Produkt je nach verwendeter Zugangstech-
nologie die Nutzung von zustzlichen, technologieabhngigen
Mechanismen (z. B. Kanalbndelung fr ISDN, Rckruf des
RAS-Clients durch den RAS-Server)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2.6 Sicherheit: Kommunikation, Authentisierung und Zugriff

- Gestattet das Produkt eine gesicherte Datenbertragung?
- Erlaubt das Produkt die alternative Nutzung von Sicherungs-
mechanismen (IPv4-Mechanismen, IPSec)?
- Erfolgt die Absicherung der Kommunikation durch standar-
disierte Mechanismen? Insbesondere sollten alle verwendeten
kryptographischen Algorithmen etabliert sein und dem Stand
der Technik entsprechen. Das Produkt sollte konform zu
aktuellen Standards sein.
- Erlaubt die Produktarchitektur die nachtrgliche Installation
neuer Sicherheitsmechanismen?
- Wird dem entfernten Benutzer nur nach erfolgreicher
Authentisierung der Zugang zum lokalen Netz erlaubt?
- Bietet das System die Mglichkeit an, die Authentisierung
entfernter Benutzer durch mehrere Authentisierungs-
mechanismen durchzufhren (z. B. Benutzername und Pass-
wort, Challenge-Response, Calling Line Identification - CLI)?
- Ist die Systemarchitektur so aufgebaut, dass neue Authentisie-
rungsmechanismen nachtrglich integriert werden knnen?
- Erlaubt das RAS-System die Nutzung einer oder mehrerer
gngiger externer Authentisierungsdienste (z. B. SecureID,
Radius, TACACS+)?
- Ist es mglich, zustzliche externe Authentisierungsdienste
einzubinden?
- bertrgt das RAS-System die zur Zugriffskontrolle fr den
Zugriff auf Daten im lokalen Netz notwendigen Informationen
(Benutzer-Kennung, Sicherheits-ID) an die lokalen
Mechanismen zur Zugriffskontrolle?
Sind alle Anforderungen an das zu beschaffende Produkt dokumentiert, so
mssen die am Markt erhltlichen Produkte dahin gehend untersucht werden,
inwieweit sie diese Anforderungen erfllen. Es ist zu erwarten, dass nicht
jedes Produkt alle Anforderungen gleichzeitig oder gleich gut erfllt. Daher
sollten die einzelnen Anforderungen mit Gewichten versehen werden, die
reflektieren, wie wichtig die Erfllung der jeweiligen Anforderung ist. Analog
kann auch der Erfllungsgrad einer Anforderung durch das einzelne Produkt
in mehrere Stufen eingeteilt werden. Aufgrund der durchgefhrten Produkt-
bewertung (gem dem erstellten Anforderungskatalog) kann dann eine
fundierte Kaufentscheidung getroffen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.187 Festlegen einer RAS-Sicherheitsrichtlinie

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement-Team
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement-Team,
Administrator
Im Rahmen der Planung eines RAS-Zugangs zu einem LAN muss auch fr Regelungen
dokumentieren und
den entfernten Zugang eine Sicherheitsrichtlinie festgelegt werden. Die durch fortschreiben
die organisationsweiten IT-Sicherheitsrichtlinien geltenden Vorschriften sind
dazu entsprechend anzupassen und zu erweitern. Die Regelungen sind zu
dokumentieren und bei nderungen fortzuschreiben.
Die fr den entfernten Zugriff auf das lokale Netz geltenden Sicherheitsvor- alle Benutzer informieren
schriften sind allen Benutzern, denen der entfernte Zugriff erlaubt wird, mit-
zuteilen (siehe auch M 2.184 Entwicklung eines RAS-Konzeptes). Im Rahmen
der Sicherheitsrichtlinie sollten Regelungen fr folgende Bereiche festgelegt
werden:
- Welcher Benutzer darf auf welche Daten zugreifen?
- Welcher Benutzer darf welche Applikationen nutzen?
- Welcher Benutzer darf auf welche Dienste bzw. Rechner zugreifen?
- Welcher Benutzer darf sich zu welchen Zeiten mit welchem RAS-Zugang
verbinden?
- Welche Administratoren haben welche Aufgaben?
- Welche Authentisierungsmechanismen sind fr den Zugriff zu benutzen?
- Welche Zugriffsrechte werden beim RAS-Zugriff jeweils vergeben?
- Ist der schreibende Zugriff auf Daten erlaubt?
- Ist fr den schreibenden Zugriff nur ein spezieller Datenbereich zu nutzen
(z. B. Incoming-Verzeichnis)?
- Wie werden mehrfache Authentisierungsfehler behandelt (z. B. Time-out
verlngern, Benutzer sperren, RAS-Zugang sperren)?
- Unter welchen Umstnden kann ein gesperrter RAS-Zugang wieder freige-
schaltet werden? Wie ist der organisatorische Ablauf dafr?
- Unter welchen Umstnden kann die Freischaltung auch aus der Entfernung
veranlasst werden? Wie ist der organisatorische Ablauf dafr?
- Welche Daten werden protokolliert?
Dieser Fragenkatalog muss entsprechend den lokalen Gegebenheiten erwei- existierende Richtlinien
bercksichtigen
tert, angepasst und konkretisiert werden. Dabei sind die existierenden Sicher-
heitsrichtlinien zu bercksichtigen. Die bergreifenden Sicherheitsvorgaben
drfen durch die RAS-Sicherheitsrichtlinien nicht ausgehhlt werden.
Im Rahmen des IT-Sicherheitskonzepts sollten fr die durch die RAS-Sicher-
heitsrichtlinie vorgegebenen Regeln auch mgliche Reaktionen bei Versten
festgelegt werden. Diese mssen jedem RAS-Benutzer bekannt sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden alle relevanten RAS-Komponenten (Client, Server, Netzkoppel-
elemente) durch die RAS-Sicherheitsrichtlinie erfasst?
- Wie wird die Einhaltung der RAS-Sicherheitsrichtlinie berprft?
- Unterliegt die RAS-Sicherheitsrichtlinie einer Fortschreibung, so dass
vernderte Rahmenbedingungen erfasst werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Mobiltelefon-Nutzung
Bei der Nutzung von Mobiltelefonen gibt es eine Vielzahl von Mglichkeiten,
diese vor Missbrauch zu schtzen. Damit diese Mglichkeiten auch genutzt
werden, sollte eine Sicherheitsrichtlinie erstellt werden, in der alle umzu-
setzenden Sicherheitsmechanismen beschrieben werden. Zustzlich sollte fr
die Benutzer ein kurzes und bersichtliches Merkblatt fr die sichere Nutzung
von Mobiltelefonen erstellt werden.
Anfallende Datenarten
Sobald ein Mobiltelefon eingeschaltet wird, meldet es sich ber die nchst-
gelegene Basisstation beim Netzbetreiber an. Bei diesem werden Daten zur
Identitt des Nutzers, die Seriennummer des Mobiltelefons und die Kennung
der Basisstation, ber die die Anmeldung erfolgt ist, protokolliert und gespei-
chert. Dies erfolgt auch dann, wenn kein Gesprch gefhrt wird. Weiterhin
wird jeder Verbindungsversuch, unabhngig vom Zustandekommen der
Verbindung, gespeichert.
Die bei der Telekommunikation anfallenden Datenarten lassen sich grob in
drei Gruppen untergliedern:
- Bestandsdaten (oder auch Stammdaten) sind diejenigen Daten, die in einem
Dienst oder Netz dauerhaft gespeichert und bereit gehalten werden. Hierzu
gehren die Rufnummer und gegebenenfalls der Name und die Anschrift
des Teilnehmers, Informationen ber die Art des Endgertes,
gegebenenfalls fr den Anschluss jeweils verfgbare Leistungsmerkmale
und Berechtigungen sowie Daten ber die Zuordnung zu Teilnehmer-
gruppen.
- Inhaltsdaten sind die eigentlichen "Nutzdaten", d. h. die bertragenen
Informationen und Nachrichten.
- Verbindungsdaten geben Auskunft ber die nheren Umstnde von
Kommunikationsvorgngen. Hierzu gehren Angaben ber Kommunikati-
onspartner (z. B. Rufnummern des rufenden und des angerufenen
Anschlusses), Zeitpunkt und Dauer der Verbindung, in Anspruch genom-
mene Systemleistungen, benutzte Anschlsse, Leitungen und sonstige
technische Einrichtungen, Dienste und - bei mobilen Diensten - die Stand-
ortkennungen der mobilen Endgerte.
Im Folgenden werden Empfehlungen gegeben, wie diese Daten vor Miss-
brauch geschtzt werden knnen.
Schutz vor Kartenmissbrauch
Das Mobiltelefon und die SIM-Karte mssen stets sicher aufbewahrt werden.
Bei Dienstreisen sollten sie nicht unbeaufsichtigt gelassen werden. Insbeson-
dere sollten sie nicht in Fahrzeugen zurckgelassen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Mobiltelefone und dazu angebotene Dienstleistungen knnen an verschie-

denen Stellen durch PINs oder Passwrter abgesichert werden. Dazu gehren:
- der Zugriff auf die SIM-Karte,
- der Zugriff auf das eigentliche Endgert, also das Mobiltelefon,
- der Zugriff auf bestimmte Funktionen des Mobiltelefons, z. B. das Tele-
fonbuch,
- der Zugriff auf die Mailbox, also die Anrufbeantworterfunktion, oder
andere Dienstleistungen des Netzbetreibers,
- der Zugriff auf Daten beim Netzbetreiber (bei Fragen an die Hotline wegen
der Abrechnung muss u. U. ein Kennwort genannt werden).
Alle diese Sicherheitsmechanismen sollten auch genutzt werden (siehe auch
M 4.114 Nutzung der Sicherheitsmechanismen von Mobiltelefonen). Am
wichtigsten ist dabei sicherlich der Schutz der SIM-Karte, da deren
Missbrauch zu hohen finanziellen Schden fhren kann. Die persnliche
Geheimzahl (PIN) darf keinesfalls zusammen mit der zum Mobiltelefon
gehrigen SIM-Karte aufbewahrt werden.
Bei Verlust der SIM-Karte sollte sofort beim Netzbetreiber eine Kartensperre
veranlasst werden, um einen eventuellen Missbrauch und damit auch einen
finanziellen Schaden abzuwehren (siehe M 2.189 Sperrung des Mobiltelefons
bei Verlust).
Um die missbruchliche Nutzung der SIM-Karte rechtzeitig zu bemerken,
sollte in jedem Fall der Einzelverbindungsnachweis auf unerklrliche Gebh-
ren und Zielrufnummern geprft werden.
Einzelverbindungsnachweis
Der Netzbetreiber speichert die Anrufdaten fr die Abrechnung. In Deutsch-
land darf er sie nur bis zur Rechnungsstellung speichern, maximal aber
80 Tage gem TDSV (Telekommunikationsdienstunternehmen-Daten-
schutzverordnung - Verordnung ber den Datenschutz fr Unternehmen, die
Telekommunikationsdienstleistungen erbringen). Es kann aber fr den
Kunden sinnvoll sein, dem Netzbetreiber zu erlauben, die Anrufdaten lnger
zu speichern, falls nachtrglich Probleme mit der Rechnung auftreten.
Jeder Kunde sollte einen Einzelverbindungsnachweis verlangen, um die
Mobiltelefon-Nutzung kontrollieren zu knnen. In Deutschland haben die
Kunden das Recht auf einen kostenlosen Einzelverbindungsnachweis. Aus
diesem knnen z. B. folgende Daten entnommen werden:
- Rechnungsdatum,
- angerufene Rufnummer (vollstndig bzw. die letzten Ziffern unkenntlich),
- Beginn, Ende oder Dauer der Verbindung,
- Kosten des Gesprchs.
Alle Mitbenutzer des Telefons mssen darber informiert werden, dass ein
Einzelverbindungsnachweis beantragt wurde und welche Daten dadurch
erfasst werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wenn in einer Behrde bzw. einem Unternehmen zur Kostenkontrolle

Einzelverbindungsnachweise gefhrt und ausgewertet werden, ist das Verfah-
ren mit dem Betriebs- bzw. Personalrat und dem Datenschutzbeauftragten
abzustimmen und den Benutzern bekannt zu geben.
Die Einzelverbindungsnachweise sollten immer nach Erhalt berprft werden,
ob sie korrekt sind. Hierdurch lsst sich auch ersehen, wo evtl. Kosten
reduziert werden knnen.
Weitergabe der Rufnummer
Es kann gewhlt werden, ob und welche Daten ber den Mobiltelefon-
Anschluss in ffentliche Telefonbcher eingetragen werden bzw. fr Abfragen
ber Telefonausknfte zur Verfgung gestellt werden. Ein Rufnum-
merneintrag erleichtert es Kommunikationspartnern anzurufen. Dies ist aber
nicht fr alle Einsatzzwecke sinnvoll, z. B. bei Mobiltelefonen aus einem Pool
oder wenn die Zahl der Anrufer klein gehalten werden soll.
Wenn die Rufnummernanzeige aktiviert ist, knnen die Gesprchspartner (je
nach Ausstattung) sehen, von welcher Telefonnummer sie angerufen werden.
Dieser Dienst kann vom Netzbetreiber generell fr ein Mobiltelefon an- oder
Rufnummernunterdrckung
Im GSM-Netz knnen den beteiligten Kommunikationspartnern die jeweiligen
Rufnummern signalisiert werden. Wenn dies nicht gewnscht ist, sollte
M 5.79 Schutz vor Rufnummernermittlung bei der Mobiltelefon-Nutzung
beachtet werden.
Schutz vor Abhren von Telefonaten
Der einzige wirksame Schutz gegen das Abhren des Inhaltes von Telefonaten
ist die interoperable, netzbergreifende Ende-zu-Ende-Verschlsselung. Da
diese Verschlsselung nicht realisiert ist, kann jede Verbindung, ob im
Festnetz oder im Mobilfunknetz, potentiell abgehrt werden. Die Kommuni-
kation zwischen Mobiltelefon und Basisstation wird aber in Deutschland und
den meisten anderen Lndern automatisch verschlsselt.
Folgende Manahmen knnen zur Verringerung der Gefhrdung empfohlen
werden:
- Es sollte nicht immer und berall telefoniert werden. Zum Telefonieren
sollte ein ungestrter Bereich aufgesucht werden (dadurch werden auch
andere weniger gestrt).
- Grundstzlich sollten keine Telefongesprche mit vertraulichem Inhalt
gefhrt werden.
- Manche Mobiltelefone zeigen auf dem Display an, wenn die bertragung
zwischen Mobiltelefon und Basisstation nicht verschlsselt wird. Wenn
diese Anzeige vorgesehen ist, sollten die Benutzer darber informiert
werden. Ab und zu sollten sie sich durch einen Blick auf das Display davon
berzeugen, dass tatschlich verschlsselt wird. So gibt es z. B. einige
Lnder, in denen die Kommunikation zwischen Mobiltelefon und
Basisstation nicht verschlsselt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Es gibt auch einige wenige und verhltnismig teure Mobiltelefone, mit

denen die Kommunikation von Ende zu Ende verschlsselt werden kann.
Dafr mssen aber beide Gesprchspartner kompatible Gerte einsetzen.
Wenn hufiger hochsensitive Informationen ber Mobiltelefon weiter-
gegeben werden sollen, kann dies sinnvoll sein.
- Bei der Datenbertragung z. B. von einem Laptop ber GSM sollten die
bertragenen Daten vorher auf dem Endgert verschlsselt werden. Hierzu
gibt es eine Vielzahl von Programmen, die dies einfach ermglichen.
- Wenn Mobiltelefone bzw. SIM-Karten gewechselt werden, ist es enorm
aufwendig, gezielt Telefonate abzuhren. Dies kann daher bei der ber-
tragung hochsensitiver Information bzw. Daten zweckmig sein.
- Es sollte geprft werden, ob alle Gesprchsgebhren dem Teilnehmer in
Rechnung gestellt wurden. Fehlende Gebhren fr bestimmte Verbindun-
gen knnen auf Abhren hindeuten.
Sensibilisierung der Benutzer
Da oft leichtfertig mit der Abhrgefahr im Telekommunikationsbereich
umgegangen wird, sollten Behrden bzw. Unternehmen prfen, inwieweit die
bisherigen Manahmen zur Aufklrung ihrer Mitarbeiter ber Gefhrdungen
im Telekommunikationssektor ausreichen. Gegebenenfalls ist es angebracht,
die Mitarbeiter regelmig ber die Abhrgefahren zu informieren und damit
auch zu sensibilisieren.
Die Mitarbeiter sollten auch darber aufgeklrt werden, dass sie vertrauliche Sorgfalt bei der Weiter-
gabe von Informationen
Informationen nicht ohne weiteres telefonisch weitergeben sollten. Insbeson-
dere sollte die Identitt des Kommunikationspartners hinterfragt werden,
bevor detaillierte Ausknfte gegeben werden (siehe auch G 3.45 Unzu-
reichende Identifikationsprfung von Kommunikationspartnern). Bei der
Benutzung von Mobiltelefonen sollten sie auerdem darauf achten, dass ver-
trauliche Mitteilungen nicht in der ffentlichkeit besprochen werden.
Immer wieder kursieren spektakulre, aber falsche Warnmeldungen (siehe
auch G 5.80 Hoax). Damit nicht wertvolle Arbeitszeit auf die Prfung des
Wahrheitsgehaltes solcher Nachrichten verschwendet wird, sollten alle Mitar-
beiter schnellstmglich ber das Auftreten eines neuen Hoax informiert
werden. Es gibt verschiedene Informationsdienste, die entsprechende
Warnungen weitergeben.
Regelungen zur Mobiltelefon-Nutzung
Bei der Nutzung von Mobiltelefonen in einer Behrde oder einem Unterneh-
men sind einige Punkte zu regeln. Dies betrifft sowohl die Nutzung von priva-
ten als auch von dienstlichen Mobiltelefonen.
Nutzung von privaten Mobiltelefonen
Aufgrund einer unzureichenden Ausstattung kann es vorkommen, dass private
Mobiltelefone fr dienstliche Zwecke benutzt werden. Hierbei sind aber
folgende Aspekte vorher zu regeln:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wer bezahlt dienstliche Gesprche und wie werden sie abgerechnet?

- Moderne Mobiltelefone beinhalten Terminkalender, Adressbcher, E-Mail-
Untersttzung und mehr. Die sinnvolle Nutzung dieser Funktionen
erfordert im Allgemeinen eine Synchronisation mit einem PC. Daher muss
geklrt werden, ob die Installation der dafr bentigten Hard- und Software
erlaubt wird.
Nutzung von dienstlichen Mobiltelefonen
Ebenso sind bei der Nutzung von dienstlichen Mobiltelefonen diverse Punkte
zu regeln:
- Es muss geklrt werden, ob bzw. in welcher Menge Privatgesprche mit
dienstlichen Mobiltelefonen gefhrt werden drfen.
- Es sollte berlegt werden, ob die Nutzung der Mobiltelefone auf bestimmte
Kommunikationspartner eingeschrnkt werden sollte, z. B. um unntigen
Kosten vorzubeugen oder auch um die Informationsweitergabe ein-
zuschrnken (siehe auch M 2.42 Festlegung der mglichen
Kommunikationspartner). Hierzu kann eine organisatorische Vorgabe
erfolgen, es kann aber auch technisch geregelt werden, wie weiter unten
unter den Stichworten "Anrufsperrungen" und "Geschlossene
Benutzergruppe" beschrieben.
- Auch bei dienstlichen Mobiltelefonen sollten die Benutzer ber die entste-
henden Kosten informiert werden, damit diese mglichst gering gehalten
werden knnen. So sollten die Benutzer ber die Tarifstruktur und
Roaming-Abkommen unterrichtet sein, damit sie beispielsweise im Aus-
land die gnstigsten Netzbetreiber auswhlen knnen.
- Die Benutzer sollten darauf hingewiesen werden, wie sie sorgfltig mit den
Mobiltelefonen umgehen sollten, um einem Verlust oder Diebstahl
vorzubeugen bzw. um eine lange Lebensdauer zu gewhrleisten (z. B.
Akkupflege, Aufbewahrung auerhalb von Bro- oder Wohnrumen,
Empfindlichkeit gegenber zu hohen oder zu niedrigen Temperaturen).
- Die Verwaltung, Wartung und Weitergabe von Mobiltelefonen sollte gere-
gelt werden. Hierzu empfiehlt sich die Einrichtung eines Mobiltelefon-
Pools (siehe M 2.190 Einrichtung eines Mobiltelefon-Pools).
- Bei jedem Benutzerwechsel mssen alle bentigten PINs gesichert weiter-
gegeben werden (siehe M 2.22 Hinterlegen des Passwortes).
Allgemeine Regelungen
Unabhngig davon, ob privat oder dienstlich angeschaffte Mobiltelefone
genutzt werden, sollte der Arbeitgeber schriftlich regeln,
- dass der Fahrer in dienstlich genutzten Fahrzeugen whrend der Fahrt nicht
telefonieren darf, da sonst bei einem Unfall Mithaftung droht.
- dass Dienstgeheimnisse nicht ber das Mobiltelefon weitergegeben werden
drfen. Gefahr droht hier weniger durch Mithren der Kommunikation auf
der Verbindungsstrecke (ber das Netz) als durch die Personen in der
unmittelbaren Umgebung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- dass man sich von der Identitt seiner Gesprchspartner berzeugen sollte
bzw. keine voreiligen Schlussfolgerungen ziehen sollte, bevor Interna
weitergegeben werden.
Ein Mobiltelefon sollte mglichst nicht unbeaufsichtigt bleiben. Falls ein
Mobiltelefon in einem Kraftfahrzeug zurckgelassen werden muss, so sollte
das Gert von auen nicht sichtbar sein. Das Abdecken des Gertes oder das
Einschlieen in den Kofferraum bieten Abhilfe. Ein Mobiltelefon stellt einen
Wert dar, der potentielle Diebe anlocken knnte.
Wird das Mobiltelefon in fremden Brorumen vor Ort benutzt, so sind die
Sicherheitsregelungen der besuchten Organisation zu beachten.
In fremden Rumlichkeiten wie Hotelzimmern sollte ein Mobiltelefon nicht
ungeschtzt ausliegen. Alle Passwort-Schutzmechanismen sollten sptestens
jetzt aktiviert werden. Das Verschlieen des Gertes in einem Schrank behin-
dert Gelegenheitsdiebe.
Information ber Kosten
GSM-Telefonate werden zwar jedes Jahr preiswerter, es gibt aber einige
Optionen, die auf Dauer hohe Kosten verursachen knnen. Da sich die
Gebhrenstruktur hufig ndert, sollten sich die Benutzer regelmig
informieren, was welche Verbindungsarten, welche Verbindungszeiten und
andere Optionen kosten.
So kann bei der Nutzung von Mobilfunktelefonen auch die Entgegennahme
eines Anrufs Geld kosten, wenn sich der Angerufene z. B. im Ausland befin-
det oder eine Anrufweiterleitung ins Festnetz geschaltet hat. Da der Anrufer
nicht wissen kann, wo sich der Angerufene befindet, werden ihm die Weiter-
leitungskosten auch nicht in Rechnung gestellt.
Regelung der Erreichbarkeit
Auch mit einem Mobiltelefon kann oder will ein Benutzer nicht jederzeit
angerufen werden. So macht es einen schlechten Eindruck, wenn Mobiltele-
fone bei jeder Gelegenheit benutzt werden. Bei Besprechungen oder Vortr-
gen sollten Mobiltelefone mglichst ausgeschaltet werden. Zumindest sollte
der Klingelton abgeschaltet oder leise und unauffllig eingestellt sein. Bei
allen Gelegenheiten, bei denen ohnehin nicht frei gesprochen werden kann
(Besprechungen, Restaurant, etc.) sollte die Benutzung des Mobiltelefons von
vorneherein vermieden werden.
Andererseits sollte auch die Erreichbarkeit des Benutzers sichergestellt
werden. Dafr bieten sich verschiedene Mglichkeiten an, beispielsweise
- knnen Erreichbarkeits-Zeiten festgelegt werden,
- kann die Anrufbeantworter-Funktionalitt genutzt werden oder
- es kann eine Rufumleitung auf ein Sekretariat eingerichtet werden.
Nutzungsverbot von Mobiltelefonen
Es sollte berlegt werden, ob die Nutzung oder sogar das Mitbringen von
Mobiltelefonen in allen oder bestimmten Bereichen einer Behrde oder eines
Unternehmens eingeschrnkt werden sollte. Dies kann z. B. fr Besprechungs-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
rume sinnvoll sein (siehe dazu auch M 5.80 Schutz vor Abhren der
Raumgesprche ber Mobiltelefone). Wenn die IT-Sicherheitspolitik der
Institution es nicht zulsst, dass Mobiltelefone mitgebracht werden, muss an
allen Eingngen deutlich darauf hingewiesen werden. Dies sollte dann auch
regelmig kontrolliert werden.
Durch die Nutzung von Mobiltelefonen knnen unter Umstnden auch andere Mobiltelefon nicht auf
Server legen!
technische Gerte in ihrer Funktionsfhigkeit beeintrchtigt werden. Deswe-
gen mssen z. B. in Flugzeugen oder Intensivstationen Mobiltelefone ausge-
schaltet werden. Auch andere, empfindliche IT-Systeme knnen durch Mobil-
telefone gestrt werden. Dies ist z. B. schon in Serverrumen und Rechen-
zentren beobachtet worden. Mgliche Strungen sind umso unwahrschein-
licher, je geringer die Sendeleistung des Mobiltelefons ist bzw. je weiter
dieses entfernt ist.
Bei IT-Systemen, auf denen sensitive Daten verarbeitet werden oder die an ein Schutz vor der Daten-
weitergabe ber Mobil-
Rechner-Netz angebunden sind, sollten keine Mobilfunkkarten zugelassen telefone
werden (siehe auch M 5.81 Sichere Datenbertragung ber Mobiltelefone).
Einen absoluten Schutz gegen unberechtigte Datenweitergabe ber
Mobiltelefone - insbesondere bei Innenttern - gibt es nicht. Es sollte aber die
Mitnahme von Mobiltelefonen in sensitive Bereiche untersagt und die Umset-
zung dieses Verbotes regelmig berprft werden.
Telefonbuch
Im Telefonbuch eines Mobiltelefons knnen Rufnummern und zugehrige
Namen oder weitere Details gespeichert werden. Ein Telefonbuch kann im
Endgert, also dem Mobiltelefon, oder auf der SIM-Karte gespeichert werden.
Deren Inhalte mssen nicht bereinstimmen. Dementsprechend kann ber
PINs auch wahlweise der Zugriff auf das Telefonbuch im Speicher des End-
gerts und/oder der SIM-Karte geschtzt werden.
Ob Telefonnummern bevorzugt im Endgert oder auf der SIM-Karte gespei-
chert werden, hngt von verschiedenen Erwgungen ab, beispielsweise wie
einfach das Sichern der Daten auf anderen Medien ist (siehe M 6.72
Ausfallvorsorge bei Mobiltelefonen). Im Allgemeinen bietet sich das
Speichern der Daten auf der SIM-Karte an, da
- diese damit bei einem Wechsel der SIM-Karte auch auf anderen Gerten
zur Verfgung stehen und
- diese eventuell sensitiven Daten leicht aus dem Gert entfernt werden
knnen (wichtig z. B. bei Reparaturarbeiten oder Benutzerwechsel).
Es sollte mglichst nur eine Art der Speicherung gewhlt werden. In diesem
Telefonbuch sollten alle wichtigen Rufnummern gespeichert werden, damit
diese jederzeit verfgbar sind. Die gespeicherten Rufnummern sollten gele-
gentlich kontrolliert werden, ob sie noch korrekt bzw. notwendig sind. Alle
Rufnummern sollten so gespeichert werden, dass sie weltweit angerufen
werden knnen, d. h. inklusive Landes- und Ortsvorwahl. Da nur der Lnder-
code international abgestimmt ist, nicht die Null, sollte dazu jede Rufnummer
mit einem "+" am Anfang, gefolgt vom Lndercode (z. B. +49 fr Deutsch-
land), Ortsvorwahl ohne fhrende Null und dann Telefonnummer eingegeben
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden. Ein Eintrag knnte also wie folgt aussehen: +492289582369 GS-
Hotline.
Wenn das Mobiltelefon von mehreren Benutzern eingesetzt wird, sollten hier
nur die gemeinsam genutzten Telefonnummern gespeichert werden. Auer-
dem sollte die Mglichkeit genutzt werden, ber die vorhandenen Sperrmg-
lichkeiten nderungen am Telefonbuch zu verhindern.
Nutzung der Anrufbeantworter-Funktionalitt
ber die Netzbetreiber kann im Allgemeinen zu einem Mobiltelefon eine
Anrufbeantworter-Funktionalitt aktiviert werden. Eingehende Anrufe werden
dabei beim Netzbetreiber in einer so genannten Mail- oder Mobilbox
gespeichert, die vom Benutzer jederzeit abgerufen werden kann. Dies kann
sehr sinnvoll sein, verursacht aber in der Regel zustzliche Kosten.
Der Zugriff auf die Mailbox sollte durch eine PIN geschtzt werden. Selbst
wenn die Mailbox nicht genutzt wird, sollte die voreingestellte PIN schnell
gendert werden, um eine Fremdnutzung zu verhindern.
Eingegangene Aufzeichnungen sollten regelmig abgehrt werden. Alle
Benutzer mssen darber informiert werden, wie dies funktioniert.
Rufumleitung
Mit der Funktion Rufumleitung knnen eingehende Anrufe auf die Mailbox
oder auf eine andere Rufnummer weitergeleitet werden. Dafr gibt es mehrere
Varianten:
- Es knnen alle eingehenden Anrufe weitergeleitet werden.
- Anrufe werden nur dann weitergeleitet, wenn besetzt ist.
- Anrufe werden nur dann weitergeleitet, wenn der Anschluss nicht erreich-
bar ist, z. B. wegen eines Funklochs oder weil das Mobiltelefon ausge-
schaltet ist.
- Es knnen bestimmte Arten von Anrufen weitergeleitet werden, z. B.
Sprach-, Daten- oder Faxanrufe.
Dabei sollte allerdings bercksichtigt werden, dass Rufumleitungen auf Fest-
netzanschlsse hohe Kosten verursachen knnen, da der Angerufene die
Weiterleitungskosten selbst tragen muss.
Anrufsperrungen
ber Anrufsperrungen knnen Gesprche zu oder von einer Rufnummer
gesperrt werden. Diese Funktionen werden ber den Netzbetreiber zur Verf-
gung gestellt und knnen ber das Mobiltelefon gendert werden. Dafr ist im
Allgemeinen die Eingabe eines Passwortes erforderlich.
Anrufsperrungen knnen sinnvoll sein, wenn das Mobiltelefon an Dritte
weitergegeben werden soll. Es gibt verschiedene Mglichkeiten von Anruf-
sperrungen:
- Sperren aller abgehenden Anrufe
Damit knnen nur noch Anrufe empfangen, aber keine Rufnummern mit
Ausnahme von Notruf-Nummern mehr angerufen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sperren aller abgehenden internationalen Anrufe

Mit dieser Sperrung knnen nur noch Nummern innerhalb des Landes
angewhlt werden, in dem man sich gerade befindet. Anrufe aus dem
Ausland knnen weiterhin empfangen werden.
- Sperren aller abgehenden internationalen Anrufe auer ins Heimatland
Damit knnen im Ausland Gesprche in das Heimatland (des Netzbetrei-
bers) gefhrt werden. Das Anrufen in andere Lnder ist gesperrt.
- Sperren aller ankommenden Anrufe
Jede beliebige Nummer kann angewhlt werden. Strungen durch einge-
hende Anrufe sind ausgeschlossen.
- Sperren aller ankommenden Anrufe bei Aufenthalt im Ausland
Innerhalb des Heimatlandes kann weiterhin wie gewohnt telefoniert
werden. Im Ausland knnen dagegen keine Telefonate mehr empfangen
werden. Diese Option kann sinnvoll sein, da fr den Empfang von Gespr-
chen im Ausland teilweise hohe Gebhren anfallen.
Ob und welche Art von Anrufsperrungen gewhlt werden sollte, hngt von der
Einsatzart des jeweiligen Mobiltelefons ab.
Geschlossene Benutzergruppe
ber den Dienst "Geschlossene Benutzergruppe" kann die Kommunikation
auf die Mitglieder dieser Gruppe beschrnkt werden (siehe auch M 5.47
Einrichten einer Closed User Group).
Die Gruppenmitglieder mssen beim Netzbetreiber eingetragen werden. Die
Option "Geschlossene Benutzergruppe" kann am Mobiltelefon aktiviert
werden. Die Einrichtung von geschlossenen Benutzergruppen kann z. B.
sinnvoll sein, um die Datenbertragung ber Mobilfunk einzuschrnken.
- Existiert eine aktuelle Sicherheitsrichtlinie fr die Mobiltelefon-Nutzung?
- Wie wird die Einhaltung der Sicherheitsrichtlinie fr die Mobiltelefon-
Nutzung berprft?
- Besitzt jeder Mobiltelefon-Benutzer ein Exemplar dieser Mobiltelefon-
Richtlinie oder ein Merkblatt mit einem berblick der wichtigsten Sicher-
heitsmechanismen?
- Ist die Sicherheitsrichtlinie fr die Mobiltelefon-Nutzung Inhalt der
Schulungen zu IT-Sicherheitsmanahmen?
- Werden die Benutzer von Mobiltelefonen auf die Regelungen hingewiesen,
die von ihnen einzuhalten sind?
- Werden die Benutzer von Mobiltelefonen auf die geeignete Aufbewahrung
hingewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.189 Sperrung des Mobiltelefons bei Verlust

Benutzer
Bei Verlust der SIM-Karte bzw. des Mobiltelefons trgt der Inhaber der SIM-
Karte die Kosten fr eine missbruchliche Nutzung des Mobiltelefon-
anschlusses. Daher sollte sofort beim Netzbetreiber eine Sperrung der SIM-
Karte veranlasst werden, um einen eventuellen Missbrauch, und damit einen
zustzlichen finanziellen Schaden, abzuwehren.
Darber hinaus sollte die PIN-Abfrage der SIM-Karte stets aktiviert sein
(siehe M 4.114 Nutzung der Sicherheitsmechanismen von Mobiltelefonen). Bei
einem Diebstahl oder Verlust verhindert dies, dass die SIM-Karte von einem
Unbefugten benutzt oder ausgewertet werden kann. Die PIN wird allerdings
nur abgefragt, wenn das Mobiltelefon eingeschaltet wird. Wird ein einge-
schaltetes Mobiltelefon gestohlen, kann hiermit zumindest solange miss-
bruchlich telefoniert werden, bis der Akku leer ist!
Bei Verlust oder Diebstahl des Mobiltelefons kann der Netzbetreiber auer-
dem die weitere Nutzung des Mobiltelefons unterbinden, indem er es auf eine
"schwarze Liste" setzt. Hierzu bentigt er die Angabe der Gertenummer
(IMEI - International Mobile Equipment Identifier). Sie steht hufig auf der
Rckseite des Gertes und sollte daher notiert und unabhngig vom Gert
aufbewahrt werden.
Bereits beim Kauf sollte darauf geachtet werden, dass die zum Mobiltelefon
gehrende IMEI schriftlich mitgeteilt wurde. Sie kann auch aus dem Mobil-
telefon ausgelesen werden, allerdings ist das Verfahren nicht fr alle Gerte
einheitlich. Die Gertenummer steht hufig auf dem Typenschild unter dem
Akku oder kann mit der Eingabe "*#06#" angezeigt werden.
Um die missbruchliche Nutzung der SIM-Karte rechtzeitig zu bemerken,
sollte in jedem Fall der Einzelverbindungsnachweis auf unerklrliche Gebh-
ren und Zielrufnummern geprft werden.
Alle Daten, die fr die Sperrung der SIM-Karte bzw. des Mobiltelefons ben- SIM-Karte bei Verlust
sofort sperren lassen!
tigt werden, sollten griffbereit, aber getrennt vom Mobiltelefon aufbewahrt
werden. Das sind
- die Rufnummer des Mobilfunkanschlusses sowie die zugehrige SIM-
Kartennummer,
- die Seriennummer des Mobiltelefons,
- die Servicenummer des Netzbetreibers, unter der der Sperrwunsch gemel-
det werden kann sowie
- das Servicenummer-Passwort und Kundennummer, also die Daten, die fr
die Authentikation gegenber dem Netzbetreiber bentigt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.190 Einrichtung eines Mobiltelefon-Pools

Einrichtung eines Mobiltelefon-Pools
Sind in einer Behrde bzw. einem Unternehmen eine Vielzahl von Mobiltele-
fonen im Einsatz und wechseln die Benutzer hufig, kann es angebracht sein,
die zeitweise nicht genutzten Mobiltelefone in einer Sammelaufbewahrung
(Pool) zu halten.
Fr alle Mobiltelefone ist die Stromversorgung sicherzustellen, damit die
Akkus dieser Gerte den sofortigen Einsatz erlauben. Dabei ist zu beachten,
dass sich ein Akku im Laufe der Zeit entldt, auch wenn er nicht verwendet
wird. Wenn die Mobiltelefone hufiger ber lngere Zeitrume eingesetzt
werden, sollten zustzlich Ersatzakkus vorrtig gehalten werden.
Hinweis: Die Ladegerte sollten den Mobiltelefonen eindeutig und leicht
erkennbar zugeordnet werden. Die Ladegerte sehen sich zwar alle sehr
hnlich, sind aber leider meist nicht austauschbar.
Zustzlich mssen die Rcknahme und die Ausgabe von Mobiltelefonen
dokumentiert werden, so dass jederzeit nachvollziehbar ist, welche Gerte bei
wem im Einsatz sind. Jeder Benutzer sollte mit Namen, Organisationseinheit,
Datum und Uhrzeit in das bergabejournal eingetragen werden.
Bei der bergabe und Rcknahme von Mobiltelefonen sind auerdem
folgende Punkte zu beachten:
bergabe:
- Der neue Benutzer erhlt alle bentigten PINs und Passwrter fr die
Nutzung des Mobiltelefons. Wenn diese auf selbstgewhlte Werte gendert
werden, mssen die neuen Werte bei der Rckgabe dokumentiert werden.
- Auerdem erhlt er die Rufnummer des Mobiltelefons.
- Dem neuen Benutzer wird ein Merkblatt fr den sicheren Umgang mit dem
Mobiltelefon bergeben. Der Benutzer sollte auerdem die Bedie-
nungsanleitung des Mobiltelefons bekommen. Neben der normalen Bedie-
nung seines Telefons sollte der Benutzer vor allem in der Lage sein,
etwaige Warnanzeigen (wie Piktogramme im Display) zu interpretieren.
- Das Mobiltelefon sollte geladen und zusammen mit dem passenden Lade-
gert bergeben werden. Wenn das Mobiltelefon ber lngere Zeitspannen
einsetzbar sein soll, sollte ein geladener Ersatzakku mit bergeben werden.
Rcknahme bzw. Weitergabe:
- Der Benutzer gibt die zuletzt benutzten PINs und Passwrter bekannt. Es
muss berprft werden, ob diese korrekt sind. Sie mssen notiert (und
sicher verwahrt) werden.
- Die Vollstndigkeit des Gertes, des Zubehrs und der Dokumentation ist
zu berprfen. Das Gert sollte auf Defekte berprft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Benutzer muss sicherstellen, dass vor Rckgabe des Gertes smtliche
Daten, die der Benutzer noch bentigt, auf ihm zugngliche Datentrger
(z. B. seinen PC) bertragen werden. Darber hinaus hat der Benutzer
selber dafr Sorge zu tragen, dass smtliche von ihm erzeugten Daten
(z. B. Telefonnummern) gelscht sind.
- Im Nummernspeicher des Mobiltelefons werden die zuletzt angerufenen
Rufnummern gespeichert. Ebenso werden die Rufnummern der letzten
Anrufer gespeichert, wenn die Funktion Anruferkennung verfgbar und
aktiviert ist. Diese sollten vor einem Benutzerwechsel gelscht werden.
Auerdem knnen in Telefonbchern sowohl im Mobiltelefon selbst als
auch auf der SIM-Karte Rufnummern gespeichert werden. Persnliche
Rufnummern sollten vor der Weitergabe ebenfalls gelscht werden. Die fr
die dienstliche Kommunikation wichtigen Rufnummern sollten allen
Benutzern dauerhaft zur Verfgung stehen.
- Im Mobiltelefon bzw. auf der SIM-Karte knnen auerdem Kurznachrich-
ten, Faxe oder E-Mails gespeichert sein. Auch diese sollten vor einer
Weitergabe gelscht werden.
- Werden die Benutzer bei der Ausgabe von Mobiltelefonen auf die Rege-
lungen und Sicherheitsmanahmen hingewiesen, die von ihnen einzuhalten
sind?
- Werden die Benutzer bei der Ausgabe von Mobiltelefonen auf deren
geeignete Aufbewahrung hingewiesen?
- Wird die Ausgabe und Rcknahme der Mobiltelefone dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.191 Etablierung des IT-Sicherheitsprozesses

Verantwortlich fr Umsetzung: Behrden-/Unternehmensleitung
Die Durchsetzung und Aufrechterhaltung eines angemessenen und ausrei-
chenden IT-Sicherheitsniveaus kann fr einen komplexen IT-Verbund nur
durch geplantes und organisiertes Vorgehen aller Beteiligten gewhrleistet
werden. Es sind strategische Leitaussagen zu formulieren, konzeptionelle
Vorgaben zu erarbeiten und die organisatorischen Rahmenbedingungen zu
schaffen, um das ordnungsgeme und sichere IT-gesttzte Arbeiten des
Unternehmens oder der Behrde zu ermglichen. Sinnvollerweise wird durch
die Behrden- bzw. Unternehmensleitung ein gesteuerter IT-Sicherheits-
prozess initiiert, der die Voraussetzungen fr die durchdachte Gestaltung
sowie sinnvolle Umsetzung und Erfolgskontrolle von IT-Sicherheits-
manahmen gewhrleistet.
Da mit der allgemeinen Verantwortung fr das zielgerichtete und ordnungs- Optimale Rahmenbe-
dingungen
geme Funktionieren einer Organisation auch die Gewhrleistung der
IT-Sicherheit der obersten Leitungsebene obliegt, muss diese den IT-Sicher-
heitsprozess initiieren, steuern und kontrollieren. Idealerweise sollten folgende
Randbedingungen erfllt werden:
- Die Initiative fr IT-Sicherheit geht von der Behrden- bzw. Unter-
nehmensleitung aus.
- Die Verantwortung fr IT-Sicherheit verbleibt dort.
- Die Aufgabe "IT-Sicherheit" wird durch die Behrden- bzw. Unter-
nehmensleitung aktiv untersttzt.
Wenn diese Randbedingungen in einer konkreten Situation nicht gegeben Alternativen
sind, so sollte zunchst versucht werden, auf Arbeitsebene die Umsetzung der
fehlenden IT-Sicherheitsmanahmen durchzufhren. In jedem Fall sollte aber
darauf hingewirkt werden, dass die Behrden- bzw. Unternehmensleitung fr
die Belange der IT-Sicherheit zu sensibilisieren, so dass sie zuknftig ihrer
Verantwortung Rechnung trgt. Der vielfach zu beobachtende sich selbst auf
Arbeitsebene initiierende IT-Sicherheitsprozess fhrt zwar zu einer Verbesse-
rung der Sicherheitssituation, garantiert jedoch kein dauerhaftes Fortent-
wickeln des IT-Sicherheitsniveaus.
Die Etablierung eines funktionierenden IT-Sicherheitsprozesses kann mit
folgenden Schritten erreicht werden:
Schritt 1: Erstellung einer IT-Sicherheitsleitlinie
Abgeleitet aus den bergeordneten Geschftszielen, der Marketingstrategie
und den allgemeinen Sicherheitsanforderungen des Unternehmens bzw. der
Behrde sollten IT-Sicherheitsziele definiert werden. Je grer die Abhngig-
keit von der eingesetzten IT ist und je mehr es auf deren Funktionsfhigkeit
ankommt, desto wichtiger ist die Bercksichtigung der IT-Sicherheitsziele auf
allen Ebenen der Organisation.
Basierend auf den von der Leitungsebene beschlossenen IT-Sicherheitszielen
ist die IT-Sicherheitsleitlinie zu erstellen. Diese definiert die zur Erreichung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
der IT-Sicherheitsziele notwendigen internen Organisationsstrukturen, Richt-

linien, Regeln und Vorgaben. Je nach Gre der Organisation kann es ange-
bracht sein, zustzlich zu der unternehmensweiten IT-Sicherheitsleitlinie eine
(oder mehrere) hiervon abgeleitete abteilungs- oder standortbezogene
IT-Sicherheitsleitlinien zu erstellen.
Die IT-Sicherheitsleitlinie ist allen davon betroffenen Mitarbeitern in geeig-
neter Form bekannt zu geben. Damit wird die Bedeutung der IT-Sicherheit fr
die Organisation durch die Behrden- bzw. Unternehmensleitung sichtbar
gemacht.
Ausfhrlich wird diese Aufgabe in M 2.192 Erstellung einer IT-
Sicherheitsleitlinie beschrieben.
Schritt 2: Auswahl und Etablierung einer geeigneten Organisations-
struktur fr IT-Sicherheit
Voraussetzung fr einen funktionierenden IT-Sicherheitsprozess ist, dass ein
geeigneter organisatorischer Rahmen geschaffen wird und die relevanten
Verantwortlichkeiten delegiert werden. Die Auswahl einer solchen Organi-
sationsstruktur erfolgt in Abhngigkeit von der Behrden- bzw. Unter-
nehmensgre. Dabei muss in geeigneter Weise die Einsetzung eines
IT-Sicherheitsmanagement-Teams und/oder die Benennung eines IT-Sicher-
heitsbeauftragten erfolgen. Darber hinaus ist die Zuordnung von Verant-
wortlichkeiten, Aufgaben und Kompetenzen zu regeln und bekannt zu geben.
Ausfhrlich wird diese Thematik in M 2.193 Aufbau einer geeigneten
Organisationsstruktur fr IT-Sicherheit beschrieben.
Schritt 3: Erstellung einer bersicht ber vorhandene IT-Systeme
Unabdingbare Voraussetzung fr das im nchsten Schritt zu erstellende
IT-Sicherheitskonzept ist eine vollstndige bersicht ber die in einem Unter-
nehmen bzw. einer Behrde eingesetzten IT-Systeme sowie die auf ihnen
betriebenen IT-Anwendungen und die dabei verarbeiteten Daten. Sofern eine
solche bersicht nicht ohnehin bereits existiert, muss sie sptestens jetzt
erstellt werden.
Eine Auflistung der fr die Erstellung des IT-Sicherheitskonzepts unbedingt
bentigten Informationen findet sich in M 2.194 Erstellung einer bersicht
ber vorhandene IT-Systeme.
Schritt 4: Festlegen der Vorgehensweise fr die Erstellung des
IT-Sicherheitskonzepts
Um die IT-Sicherheit auf ein angemessenes Niveau anzuheben, ist es erfor-
derlich, die bestehenden Schwachstellen zu identifizieren sowie geeignete
IT-Sicherheitsmanahmen auszuwhlen und zu realisieren. Fr die Erhebung
der Schwachstellen und die Auswahl der Manahmen knnen verschiedene
Verfahren eingesetzt werden. Hier sind zu nennen:
- IT-Grundschutzerhebung nach dem vorliegenden Handbuch,
- Risikoanalyse nach dem IT-Sicherheitshandbuch,
- Schwachstellenanalyse fr ausgewhlte Bereiche (z. B. Vernetzung) und
- Penetrationstests.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Neben der Auswahl des methodischen Ansatzes ist zu entscheiden, in welcher

Reihenfolge und in welchem Umfang die vorhandene IT bearbeitet wird.
Generell ist zu bemerken, dass Standardsicherheitsmanahmen nach
IT-Grundschutz auch fr hochschutzbedrftige IT-Systeme unverzichtbar
sind. Ebenso ist allerdings zu beachten, dass Standardsicherheitsmanahmen
fr Hochsicherheitssysteme ggf. um adquate hherwertige Manahmen
ergnzt werden mssen. Bei der Auswahl der Vorgehensweise ist zu beachten,
dass fr die Methodik nach IT-Grundschutz nur geringe Vorkenntnisse
notwendig sind. Fr detaillierte Risikoanalysen, insbesondere fr die Identifi-
kation von Schwachstellen und Manahmen, ist ein hoher Grad von Exper-
tenwissen erforderlich.
Seitens des BSI wird daher empfohlen, die fehlenden IT-Grundschutz-
manahmen fr smtliche IT-Systeme umzusetzen und ggf. parallel dazu eine
detaillierte Sicherheitsanalyse fr hochschutzbedrftige Teile durchzufhren.
Auf diese Weise wird in relativ kurzer Zeit ein umfassendes
IT-Sicherheitsniveau erreicht, das auch in der bergangszeit bis zum
Abschluss der detaillierten Sicherheitsanalysen die hochschutzbedrftigen
IT-Systeme nicht ungeschtzt lsst.
Die Vorgehensweise bei der Erstellung eines Sicherheitskonzepts wird aus-
fhrlich in M 2.195 Erstellung eines IT-Sicherheitskonzepts behandelt.
Schritt 5: Umsetzung der IT-Sicherheitsmanahmen
Die Umsetzung der bei der Erstellung des IT-Sicherheitskonzepts identifizier-
ten IT-Sicherheitsmanahmen ist in einem Realisierungsplan zu organisieren
und festzuhalten. Dieser dient als Planungsinstrument bei der Koordinierung
der Manahmenumsetzung und als Steuerungsinstrument fr die eigentliche
Umsetzung. Alle zur Aktualisierung oder Implementierung von Manahmen
notwendigen Aktionen und Verantwortlichkeiten sollten hierin schriftlich
fixiert werden
Nach Abschluss der Implementierung ist auf jeden Fall festzustellen, ob alle
Manahmen plangem umgesetzt sind und auch so "funktionieren", wie es
beabsichtigt war. Bei der Funktionalittsprfung knnen ggf. in vorher fest-
gelegten Bereichen auch Stichproben ausreichen.
Die Vorgehensweise fr die Erstellung eines Realisierungsplans fr
IT-Sicherheitsmanahmen und dessen Umsetzung wird in M 2.196 Umsetzung
des IT-Sicherheitskonzepts nach einem Realisierungsplan dargestellt.
Schritt 6: IT-Sicherheit im laufendem Betrieb
Damit ein IT-Sicherheitskonzepts im Alltag wirksam werden kann, ist es
erforderlich, dass alle Mitarbeiter eines Unternehmens bzw. einer Behrde die
sie jeweils betreffenden Manahmen korrekt umsetzen sowie verbleibende
Schwachstellen erkennen und sich aktiv an deren Beseitigung beteiligen.
Voraussetzung dafr ist zuerst eine hinreichende Schulung aller Mitarbeiter zu
Fragen der IT-Sicherheit, sowie darauf aufbauend deren kontinuierliche
Sensibilisierung fr Risiken und Verbesserungsmglichkeiten im laufendem
Betrieb. Diese Punkte sind auch fr die Akzeptanz der
IT-Sicherheitsmanahmen durch die Mitarbeiter wesentlich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
In den Manahmen M 2.197 Erstellung eines Schulungskonzepts fr IT-

Sicherheit und M 2.198 Sensibilisierung der Mitarbeiter fr IT-Sicherheit
werden Grundstze und mgliche Vorgehensweisen zur Erreichung dieses
Ziels vorgestellt.
Schritt 7: Aufrechterhalten des sicheren Betriebs
Um das angestrebte Sicherheitsniveau nicht nur einmalig zu erreichen,
sondern dauerhaft zu gewhrleisten, mssen die implementierten
IT-Sicherheitsmanahmen auch im laufenden Betrieb funktionsfhig bleiben.
In wohl kaum einem anderen Bereich "veraltet" ein einmal etabliertes Sicher-
heitsniveau so schnell wie im dynamischen IT-Umfeld. Insbesondere
Erkenntnisse aus sicherheitsrelevanten Zwischenfllen, Vernderungen im
technisch-organisatorischen Umfeld sowie nderungen von Sicherheits-
anforderungen bzw. neue Bedrohungen erfordern eine Anpassung der beste-
henden IT-Sicherheitsmanahmen.
In der Manahme M 2.199 Aufrechterhaltung der IT-Sicherheit finden sich
detailliertere Empfehlungen darber, wie eine solche Aktualisierung gewhr-
leistet werden kann.
Hufig werden Anpassungen des IT-Sicherheitsprozesses einer Entscheidung
der obersten Leitungsebene bedrfen. Zu diesem Zweck muss die Leitungs-
ebene ber das erreichte IT-Sicherheitsniveau sowie ber bestehende
Probleme und Schwachstellen informiert werden. Hierzu sollte mglichst
regelmig ein Managementreport "IT-Sicherheit" erstellt werden.
In der Manahme M 2.200 Erstellung von Managementreports zur IT-
Sicherheit finden sich Hinweise, wie solche Berichte erstellt und vorgelegt
werden knnen.
Um die Kontinuitt und Konsistenz des gesamten IT-Sicherheitsprozesses
sicherzustellen, ist es unabdingbar, diesen zu dokumentieren. Nur so knnen
grundstzliche Schwchen im Prozess zuverlssig erkannt und Fehlent-
wicklungen rechtzeitig unterbunden werden.
Empfehlungen fr Inhalt und Umfang dieser Dokumentation finden sich in der
Manahme M 2.201 Dokumentation des IT-Sicherheitsprozesses.
Ergnzende Arbeits- und Hilfsmittel innerhalb des IT-Sicherheisprozesses
werden in den Manahmen M 2.202 Erstellung eines Handbuchs zur IT-
Sicherheit und M 2.203 Aufbau einer Informationsbrse zur IT-
Sicherheit vorgestellt.
Fr Leser, die sich intensiver mit der Thematik "IT-Sicherheitsprozess" Weiterfhrende Literatur
beschftigen wollen, bietet sich zur Vertiefung die Lektre des Teils 3 der
ISO/IEC-Norm 13335 "Guidelines on the Management of IT Security" an.
- Ist ein adquater IT-Sicherheitsprozess etabliert?
- Untersttzt die Leitungsebene den IT-Sicherheitsprozess in ausreichendem
Mae?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.192 Erstellung einer IT-Sicherheitsleitlinie

Verantwortlich fr Umsetzung: Behrden-/Unternehmensleitung, IT-
Sicherheitsmanagement-Team
Die IT-Sicherheitsleitlinie definiert das angestrebte IT-Sicherheitsniveau, mit Zweck
dem die Aufgaben durch die Organisation erfllt werden. Die IT-Sicherheits-
leitlinie beinhaltet die von der Organisation angestrebten IT-Sicherheitsziele
sowie die verfolgte IT-Sicherheitsstrategie. Sie ist somit Anspruch und
Aussage zugleich, dass das IT-Sicherheitsniveau auf allen Ebenen der Orga-
nisation erreicht werden soll. Bei der Erstellung der IT-Sicherheitsleitlinie
sind folgende Gesichtspunkte zu beachten:
1. Verantwortung der Behrden- bzw. Unternehmensleitung fr die
IT-Sicherheitsleitlinie
2. Einberufung einer Entwicklungsgruppe fr die IT-Sicherheitsleitlinie
3. Bestimmung der IT-Sicherheitsziele
4. Inhalt der IT-Sicherheitsleitlinie
5. Bekanntgabe der IT-Sicherheitsleitlinie
6. Erstellung zustzlicher IT-System-Sicherheitsleitlinien
Ein Beispiel fr eine IT-Sicherheitsleitlinie (Information Security Policy) ist
als Hilfsmittel der CD-ROM im Verzeichnis word20\hilfsmi\13policy.doc
beigefgt.
Die Erstellung der IT-Sicherheitsleitlinie sollte in folgenden Schritten vollzo- Vorgehensweise
gen werden:
1. Verantwortung der Behrden- bzw. Unternehmensleitung fr die
IT-Sicherheitsleitlinie
Mit der IT-Sicherheitsleitlinie wird dokumentiert, welche strategische
Position die Behrden- bzw. Unternehmensleitung u. a. zur Erstellung und
Umsetzung des Sicherheitskonzeptes, zur Erreichung der IT-Sicherheits-
ziele auf allen Ebenen der Organisation und zur Priorisierung von
Manahmenbereichen einnimmt.
Wichtig ist, dass die Behrden- bzw. Unternehmensleitung in vollem Gesamtverantwortung
der Leitungsebene
Umfang hinter der IT-Sicherheitsleitlinie und den darin festgehaltenen
Zielen steht. Selbst wenn einzelne Aufgaben im Rahmen des
IT-Sicherheitsprozesses an Personen oder Organisationseinheiten delegiert
werden, die dann fr die Umsetzung zustndig sind, bleibt die Gesamt-
verantwortung bei der Behrden- bzw. Unternehmensleitung.
2. Einberufung einer Entwicklungsgruppe fr die IT-Sicherheitsleitlinie
Falls es innerhalb der Behrde oder des Unternehmens bereits ein
IT-Sicherheitsmanagement-Team gibt, so sollte dieses die
IT-Sicherheitsleitlinie entwickeln bzw. berprfen und berarbeiten.
Danach wird dieser Entwurf der Behrden- bzw- Unternehmensleitung zur
Genehmigung vorgelegt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Befindet sich das IT-Sicherheitsmanagement erst im Aufbau, so sollte eine Zusammensetzung der
Entwicklungsgruppe zur Erarbeitung der IT-Sicherheitleitlinie eingerichtet Entwicklungsgruppe
werden. Diese Gruppe kann im Laufe des IT-Sicherheitsprozesses die
Funktion des IT-Sicherheitsmanagement-Teams bernehmen. Sinnvoller-
weise sollte in dieser Entwicklungsgruppe Vertreter der IT-Anwender,
Vertreter des IT-Betriebs und ein oder mehrere in Sachen IT-Sicherheit
ausreichend vorgebildete Mitarbeiter mitwirken. Idealerweise sollte zeit-
weise auch ein Mitglied der Leitungsebene, das die Bedeutung der IT fr
die Behrde oder das Unternehmen einschtzen kann, hinzugezogen
werden.
Weitere Hinweise sind M 2.193 Aufbau einer geeigneten
Organisationsstruktur fr IT-Sicherheit zu entnehmen.
3. Bestimmung der IT-Sicherheitsziele
Zunchst sollte abgeschtzt werden, welche Informationen und Informa- Klassifizierung von
IT-Anwendungen
tionsverarbeitungssysteme zur Aufgabenerfllung beitragen und welcher
Wert diesen beigemessen wird. Hierzu sollten vor allem die Informationen,
die technische Infrastruktur und die IT-Anwendungen der Behrde bzw.
des Unternehmens klassifiziert werden. Im Rahmen der IT-Sicherheit ist
hiermit vordringlich die Bedeutung der IT fr die Organisation und ihre
Aufgaben gemeint. Hier ist insbesondere die strategische und operative
Bedeutung der IT entscheidend. Daher ist es wichtig, sich ber den mate-
riellen Wert der IT selbst hinaus klarzumachen, wie stark die Aufgaben-
erfllung innerhalb der Organisation von der eingesetzten IT und deren
reibungslosem Funktionieren abhngt. Fragen zur Beurteilung der Abhn-
gigkeit sind beispielsweise:
- Welche kritischen Aufgaben der Behrde bzw. des Unternehmens
knnen ohne Untersttzung durch IT nicht, nur unzureichend oder
mit erheblichem Mehraufwand ausgefhrt werden?
- Welche wesentlichen Entscheidungen der Behrde bzw. des Unter-
nehmens beruhen auf Vertraulichkeit, Integritt und Verfgbarkeit
von Informationen und Informationsverarbeitungssystemen?
- Welche Auswirkungen haben absichtliche oder ungewollte
IT-Sicherheitszwischenflle?
- Werden mit der eingesetzten IT Informationen verarbeitet, deren
Vertraulichkeit besonders zu schtzen ist?
- Hngen wesentliche Entscheidungen von der Korrektheit und
Aktualitt von Informationen ab, die mit IT verarbeitet werden?
Mit Hilfe dieser berlegungen kann nun festgelegt werden, welches Ma
an IT-Sicherheit fr die jeweilige Organisation ausreichend und ange-
messen ist.
Nachstehend sind einige Beispielkriterien fr eine solche Einschtzung
aufgefhrt. Hierbei spielt die Bedeutung der IT, die spezifische Gefhr-
dungslage und die relevanten Gesetzesvorgaben eine entscheidende Rolle.
Anhand derjenigen Aussagen, die am ehesten zutreffen, lsst sich das
IT-Sicherheitsniveau (niedrig, mittel, hoch oder maximal) bestimmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Maximal:
- Der Schutz vertraulicher Informationen muss gewhrleistet sein und
in sicherheitskritischen Bereichen strengen Vertraulichkeitsanforde-
rungen gengen.
- Die Informationen mssen im hchsten Mae korrekt sein.
- Die zentralen Aufgaben der Institution sind ohne IT-Einsatz nicht
durchfhrbar. Knappe Reaktionszeiten fr kritische Entscheidungen
fordern stndige Prsenz der aktuellen Informationen, Ausfallzeiten
sind nicht akzeptabel.
Insgesamt gilt: Der Ausfall der IT fhrt zum totalen Zusammenbruch der
Institution oder hat schwerwiegende Folgen fr breite gesellschaftliche
oder wirtschaftliche Bereiche.
Hoch:
- Der Schutz vertraulicher Informationen muss hohen gesetzlichen
Anforderungen gengen und in sicherheitskritischen Bereichen
strker ausgeprgt sein.
- Die verarbeiteten Informationen mssen korrekt sein, auftretende
Fehler mssen erkennbar und vermeidbar sein.
- In zentralen Bereichen der Institution laufen zeitkritische Vorgnge
oder es werden dort Massenaufgaben wahrgenommen, die ohne
IT-Einsatz nicht zu erledigen sind; es knnen nur kurze Ausfall-
zeiten toleriert werden.
Insgesamt gilt: Im Schadensfall tritt Handlungsunfhigkeit zentraler
Bereiche der Institution ein; Schden haben erhebliche Beeintrchtigungen
der Institution selbst oder betroffener Dritter zur Folge.
Mittel:
- Der Schutz von Informationen, die nur fr den internen Gebrauch
bestimmt sind, muss gewhrleistet sein.
- Kleinere Fehler knnen toleriert werden. Fehler, die die Aufgaben-
erfllung erheblich beeintrchtigen, mssen jedoch erkenn- oder
vermeidbar sein.
- Lngere Ausfallzeiten, die zu Terminberschreitungen fhren, sind
nicht zu tolerieren.
Insgesamt gilt: Schden haben Beeintrchtigungen der Institution zur
Folge.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Niedrig:
- Vertraulichkeit von Informationen ist nicht gefordert.
- Fehler knnen toleriert werden, solange sie die Erledigung der
Aufgaben nicht vllig unmglich machen.
- Dauernder Ausfall ist zu vermeiden, lngere Ausfallzeiten sind
jedoch hinnehmbar.
Insgesamt gilt: Schden haben nur eine unwesentliche Beeintrchtigung
der Institution zur Folge.
Ein bestimmtes Ma an IT-Sicherheit ist immer nur mit einem entspre- Wirtschaftlichkeit
chenden Aufwand zu erreichen und aufrechtzuerhalten. Deshalb ist beim
Festlegen des IT-Sicherheitsniveaus fr die jeweilige Organisation darauf
zu achten, das dieses auch unter Kostenaspekten vertretbar bzw. finanzier-
bar ist.
Das nachstehende Diagramm soll verdeutlichen, wie viel Aufwand in Aufwand-Nutzen
Relation zu dem angestrebten IT-Sicherheitsniveau zu betreiben ist. Dieser
Aufwand bietet eine Orientierung fr die personellen, zeitlichen und mone-
tren Ressourcen, die zur Umsetzung des IT-Sicherheitsniveaus auch not-
wendig sind. Eine Orientierung fr den monetren Aufwand kann der in
der Privatwirtschaft betriebene Aufwand von durchschnittlich 5% der
IT-Investitionssumme pro Jahr fr IT-Sicherheit bieten.
Abbildung: Aufwand-Nutzen-Relation fr IT-Sicherheit

Nach der Festlegung des Gesamtsicherheitsniveaus fr die Behrde oder IT-Sicherheitsziele
das Unternehmen anhand der obigen Szenarien mssen die entsprechenden
IT-Sicherheitsziele definiert werden.
Mgliche IT-Sicherheitsziele einer Organisation knnten sein:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Hohe Verlsslichkeit des Handelns, besonders in puncto Rechtzei-

tigkeit (hier ist die Verfgbarkeit der IT gefordert), Korrektheit (das
betrifft die Integritt der IT) und Vertraulichkeit,
- Gewhrleistung des guten Rufs der Institution in der ffentlichkeit,
- Erhaltung der in Technik, Informationen, Arbeitsprozesse und
Wissen investierten Werte,
- Sicherung der hohen, mglicherweise unwiederbringlichen Werte
der verarbeiteten Informationen,
- Sicherung der Qualitt der Informationen, z. B. wenn sie als Basis
fr weitreichende Entscheidungen dienen,
- Gewhrleistung der aus gesetzlichen Vorgaben resultierenden
Anforderungen,
- Reduzierung der im Schadensfall entstehenden Kosten (sowohl
durch Schadensvermeidung wie Schadensverhtung) sowie
- Sicherstellung der Kontinuitt der Arbeitsablufe innerhalb der
Organisation.
Die einzelnen IT-Sicherheitsziele knnen auf unterschiedliche Arten IT-Sicherheitsstrategien
umgesetzt werden. Hierzu sollten generelle IT-Sicherheitsstrategien erar-
beitet werden. Mgliche IT-Sicherheitsstrategien knnen sein:
- Konsequente Datensicherung in allen IT-Bereichen,
- Weitestgehende Verschlsselung aller nach auen gehenden Infor-
mationen,
- Einsatz starker Authentisierungsverfahren fr alle Zugriffe auf
IT-Systeme,
- Isolierung besonders sensitiver IT-Anwendungen auf nicht vernetzte
IT-Systeme.
Diese allgemeinen IT-Sicherheitsziele und -strategien haben Gltigkeit fr Spezifische
Anforderungen
die meisten Organisationen, die mit IT-Untersttzung arbeiten. Um die
spezifischen IT-Sicherheitsziele und IT-Sicherheitsstrategien einer Organi-
sation zu ermitteln, ist es unumgnglich, diese fr die in der Organisation
durchgefhrten Arbeiten und Projekte zu formulieren.
Beispiel: Bei der Verarbeitung von personenbezogenen Daten (z. B. in der
Personalabteilung), die unter das Datenschutzgesetz fallen, mssen die dort
beschriebenen Anforderungen an Vertraulichkeit und Integritt durch
Einhaltung der technisch-organisatorischen Rahmenbedingungen sicher-
gestellt sein.
Die Ergebnisse dieser berlegungen sollten in der IT-Sicherheitsleitlinie
festgehalten werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. Inhalt der IT-Sicherheitsleitlinie

Die IT-Sicherheitsleitlinie sollte mindestens die folgenden Informationen
beinhalten:
- Stellenwert der IT-Sicherheit und Bedeutung der IT fr die Aufga-
benerfllung,
- Sicherheitsziele und die Sicherheitsstrategie fr die eingesetzte IT,
- Zusicherung, dass die IT-Sicherheitsleitlinie von der Behrden- bzw.
Unternehmensleitung durchgesetzt wird,
- Beschreibung der fr die Umsetzung des IT-Sicherheitsprozesses
etablierten Organisationsstruktur (vgl. M 2.193 Aufbau einer
geeigneten Organisationsstruktur fr IT-Sicherheit).
Zustzlich knnen noch folgende Aussagen hinzukommen:
- Klassifizierung der Informationen, Kontrolle von Zutritt, Zugang
und Zugriff auf Informationen sowie Sicherheit der Informations-
verarbeitungssysteme
- Zuweisung von Verantwortlichkeiten im IT-Sicherheitsprozess,
insbesondere fr das IT-Sicherheitsmanagement-Team, den
IT-Sicherheitsbeauftragten, die IT-Anwender und die
IT-Administratoren.
- Darstellung der Durchsetzung der IT-Sicherheitsleitlinie einschlie-
lich der Vorgehensweise bei Versten und damit verbundener
disziplinarischer Konsequenzen
- berblick ber Dokumentation des IT-Sicherheitsprozesses
- Aussagen zur periodischen berprfung der IT-Sicherheits-
manahmen
- Aussagen zu Programmen zur Frderung der IT-Sicherheit durch
Schulungs- und Sensibilisierungsmanahmen
Die IT-Sicherheitsleitlinie sollte kurz und bndig formuliert sein. Sie sollte Aktualisierung
in regelmigen Abstnden auf ihre Aktualitt hin berprft und ggf.
angepasst werden, ggf. sind dies Zyklen in der Leitlinie zu dokumentieren.
5. Bekanntgabe der IT-Sicherheitsleitlinie
Es ist wichtig, dass die Behrden- bzw. Unternehmensleitung ihre Ziel-
setzungen und Erwartungshaltungen durch Bekanntgabe der
IT-Sicherheitsleitlinie unterstreicht und den Stellenwert sowie die Wich-
tigkeit der IT-Sicherheit in der gesamten Organisation unterstreicht.
Da die Verantwortung der Behrden- bzw. Unternehmensleitung in Bezug
auf die IT-Sicherheitsleitlinie entscheidend ist, sollte die Leitlinie schrift-
lich fixiert sein. Die Behrden- bzw. Unternehmensleitung sollte ihr
formell zugestimmt haben.
Schlielich sollten alle Mitarbeiter darauf aufmerksam gemacht werden,
dass nicht nur bei der Aufgabenerfllung allgemein, sondern auch bei der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Erfllung der Aufgabe "IT-Sicherheit" von jedem Mitarbeiter ein engagier-

tes, kooperatives sowie verantwortungsbewusstes Handeln erwartet wird.
6. Erstellung zustzlicher IT-System-Sicherheitsleitlinien
Fr IT-Systeme oder IT-Dienstleistungen, die sich in einem sicherheits-
kritischen Bereich befinden, deren Konfiguration kompliziert ist oder deren
Anwendung eine gewisse Komplexitt aufweist, sollten separate
IT-System-Sicherheitsleitlinien erstellt werden. Beispiele hierfr sind
System-Sicherheitsleitlinien fr Firewalls, fr Virenschutzmanahmen, fr
den Einsatz von E-Mail oder fr die Nutzung des Internets (s. Anhang:
Hilfsmittel. Die IT-System-Sicherheitsleitlinien sollten beinhalten:
- eine Beschreibung der Funktionalitt des Systems, der externen
Schnittstellen und der Anforderungen an die Einsatzumgebung,
- eine Beschreibung der Bedrohungen, gegen die das System
geschtzt werden soll,
- eine Beschreibung der Aktionen, die Personen oder technische
Prozesse auf Daten oder Programmen ausfhren drfen,
- eine Beschreibung der Schutzbedrftigkeit der Systemobjekte,
- eine Beschreibung der Restrisiken, die der Betreiber des Systems
akzeptieren kann,
- alle Manahmen, die den Bedrohungen gegenbergestellt und die
vom System einzuhalten sind,
- alle bekannten Schwachstellen des Systems.
- Ist die IT-Sicherheitsleitlinie smtlichen betroffenen Mitarbeitern bekannt
gegeben worden?
- Werden neue Mitarbeiter auf die IT-Sicherheitsleitlinie hingewiesen?
- Wird die IT-Sicherheitsleitlinie in regelmigen Abstnden aktualisiert?
- Fr welche IT-Systeme existieren besondere IT-System-Sicherheitsleit-
linien?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.193 Aufbau einer geeigneten Organisationsstruktur

fr IT-Sicherheit
IT-Sicherheit ist fr jedes IT-Projekt, jedes IT-System und alle IT-Benutzer Rollen und Aufgaben
innerhalb einer Organisation von besonderer Bedeutung. Das angestrebte IT-
Sicherheitsniveau kann nur erreicht werden, wenn das IT-Sicherheitskonzept
behrden- bzw. unternehmensweit umgesetzt wird. Dieser bergreifende
Charakter des IT-Sicherheitsprozesses macht es notwendig, die Rollen inner-
halb der Behrde bzw. des Unternehmens festzulegen. Den Rollen sind die
entsprechenden Aufgaben zuzuordnen, die wiederum von qualifizierten
Mitarbeitern ausgefhrt werden. Nur so kann gewhrleistet werden, dass alle
wichtigen Aspekte bercksichtigt und smtliche anfallenden Aufgaben effizi-
ent und effektiv erledigt werden.
Das IT-Sicherheitsmanagement hngt von der Gre, Beschaffenheit und Zentrale Rollen
Struktur der jeweiligen Organisation ab. Als zentrale Rollen sind auf jeden
Fall zu definieren:
- der IT-Sicherheitsbeauftragte, der eine eigene Fachkompetenz fr IT-
Sicherheit aufbaut und fr alle IT-Sicherheitsfragen in der Organisation
zustndig ist, sowie
- das IT-Sicherheitsmanagement-Team, welches in greren Organisatio-
nen smtliche bergreifenden Belange der IT-Sicherheit regelt und Plne,
Vorgaben und Richtlinien erarbeitet.
Um den direkten Zugang zur Behrden- bzw. Unternehmensleitung sicherzu-
stellen, sollten beide als Stabsstelle organisiert sein.
Grundregel:
Das Wichtigste bei der Definition von Rollen im IT-Sicherheitsmanagement
ist:
- die Gesamtverantwortung fr die ordnungsgeme und sichere Aufgaben-
erfllung (und damit fr die IT-Sicherheit) verbleibt bei der Leitungsebene,
und
- die Verantwortung fr die IT-Sicherheit am einzelnen Arbeitsplatz ist
genauso in der Linie zu delegieren wie die Verantwortung fr die originre
Aufgabe.
Aufbauorganisation des IT-Sicherheitsmanagements
In Abhngigkeit von der Organisationsgre bieten sich drei Mglichkeiten Anpassung an die
Organisationsgre
fr die Aufbauorganisation des IT-Sicherheitsmanagements an, die in den
nachstehenden Abbildungen aufgezeigt werden. Die erste Abbildung zeigt die
Organisationsstruktur fr das IT-Sicherheitsmanagement in einer groen
Organisation. Die zweite Abbildung zeigt die Aufbauorganisation in einer
mittelgroen Organisation, in der das IT-Sicherheitsmanagement-Team und
der IT-Sicherheitsbeauftragte zusammengefasst wurden. Die dritte Abbildung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zeigt eine Organisationsstruktur fr das IT-Sicherheitsmanagement in einer

kleinen Organisation, wo alle Aufgaben vom IT-Sicherheitsbeauftragten
wahrgenommen werden.
Abb. 1: Aufbauorganisation des IT-Sicherheitsmanagements in einer groen

Organisation
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abb. 2: Aufbauorganisation des IT-Sicherheitsmanagements in einer mittel-

groen Organisation
Abb. 3: Aufbauorganisation des IT-Sicherheitsmanagements in einer kleinen

Organisation
An dieser Stelle sei deutlich darauf hingewiesen, dass diese zentralen Rollen Notwendige Ressourcen
nicht unbedingt von mehreren Personen wahrgenommen werden mssen. Die
personelle Ausgestaltung richtet sich nach der Gre der jeweiligen Organi-
sation, den vorhandenen Ressourcen und dem angestrebten IT-Sicherheits-
niveau. Auf der anderen Seite sei betont, dass IT-Sicherheit leider nicht zum
Nulltarif zu erreichen ist. Den verantwortlichen Personen mssen gengend
Ressourcen zur Verfgung stehen, so dass sie sich der Aufgabe "IT-Sicher-
heit" entsprechend widmen knnen. Das hat sich bereits dann mehr als bezahlt
gemacht, wenn es weniger schdigende Vorkommnisse aufgrund mangelnder
Sicherheitsvorsorge gibt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Aufgaben, Verantwortungen und Kompetenzen im IT-Sicherheits-

management
IT-Sicherheitsbeauftragte und IT-Sicherheitsmanagement-Team mssen klar Einbindung in die
Organisationsstruktur
definierte Aufgaben, Verantwortungen und Kompetenzen haben, die von der
Leitungsebene festzulegen sind. Um ihre Aufgabe wahrnehmen zu knnen,
sollten beide bei allen relevanten Verfahren und Entscheidungen beteiligt
werden. Die Rollen sind dergestalt in die Organisationsstruktur einzubinden,
dass alle Beteiligten untereinander kommunizieren knnen. Mit der Wahr-
nehmung der Aufgaben als IT-Sicherheitsbeauftragte bzw. im IT-Sicherheits-
management-Team sollte qualifiziertes Personal betraut werden. Bei Bedarf
knnen untersttzend Aufgaben an Bereichs-IT-Sicherheitsbeauftragte, IT-
Projekt- sowie IT-System-Sicherheitsbeauftragte delegiert werden.
Der IT-Sicherheitsbeauftragte
Da die Verantwortung fr IT-Sicherheit genauso in der Linie delegiert wird
wie die Verantwortung fr die Aufgabenerfllung selbst, besteht bei unklarer
Zuweisung die Gefahr, dass IT-Sicherheit grundstzlich zu einem "Problem
anderer Leute" wird. Damit wird die Verantwortung fr IT-Sicherheit so lange
hin und her geschoben, bis keiner sie mehr zu haben glaubt. Um dies zu
vermeiden, sollte die Verantwortung fr IT-Sicherheit einer Rolle, dem "IT-
Sicherheitsbeauftragten", bertragen werden. Dieser ist verantwortlich fr die
Wahrnehmung aller Belange der IT-Sicherheit innerhalb der Organisation. Die
Aufgaben des IT-Sicherheitsbeauftragten sind:
- im gesamten IT-Sicherheitsprozess mitzuwirken,
- die IT-System-Sicherheitleitlinie(n) zu erstellen,
- die Erstellung des IT-Sicherheitskonzepts zu koordinieren,
- die Erstellung des Notfallvorsorgekonzepts und anderer Teil-Konzepte zu
koordinieren,
- die Erstellung des Realisierungsplan fr IT-Sicherheitsmanahmen und die
Initiierung und berprfung der Realisierung,
- dem IT-Sicherheitsmanagement-Team und der Leitungsebene zu berichten,
- den Informationsfluss zwischen Bereichs-IT-, IT-Projekt- sowie IT-
System-Sicherheitsbeauftragten sicherzustellen sowie
- evtl. auftretende sicherheitsrelevante Zwischenflle festzustellen und zu
untersuchen.
Zur Erfllung dieser Aufgaben ist es wnschenswert, dass der IT-Sicherheits- Anforderungsprofil
beauftragte ber Wissen und Erfahrung in den Gebieten IT-Sicherheit und IT
verfgt. Da diese Aufgabe eine Vielzahl von Fhigkeiten erfordert, sollte bei
der Auswahl auerdem darauf geachtet werden, dass die folgenden Qualifi-
kationen vorhanden sind:
- Identifikation mit den Zielsetzungen der IT-Sicherheit und Einsicht in die
Notwendigkeit von IT-Sicherheit,
- Kooperations- und Teamfhigkeit (wenige andere Projekte erfordern so
viel Fhigkeit und Geschick im Umgang mit anderen Personen: Die Lei-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
tungsebene muss in zentralen Fragen des IT-Sicherheitsprozesses immer

wieder eingebunden werden, Entscheidungen mssen eingefordert werden
und die IT-Benutzer mssen - evtl. mit Hilfe des Bereichs-IT-
Sicherheitsbeauftragten - in den IT-Sicherheitsprozess mit eingebunden
werden),
- Erfahrungen im Projektmanagement, idealerweise im Bereich der System-
analyse (das sind die Schwerpunkte, die auch bei dem Projekt "IT-Sicher-
heit" und besonders in der Risikoanalyse verstrkt eine Rolle spielen).
Die Zusammenarbeit mit den IT-Benutzern verlangt viel Geschick, da diese Kooperation
zunchst von der Notwendigkeit der (fr sie manchmal etwas lstigen) IT-
Sicherheitsmanahmen berzeugt werden mssen. Mindestens genauso heikel
ist die Befragung der IT-Benutzer nach sicherheitskritischen Vorkommnissen
und Schwachstellen. Um den Erfolg dieser Befragungen zu garantieren,
mssen die IT-Benutzer davon berzeugt werden, dass ehrliche Antworten
nicht zu Problemen fr sie selbst fhren.
Das IT-Sicherheitsmanagement-Team
Das IT-Sicherheitsmanagement-Team untersttzt den IT-Sicherheitsbeauf-
tragten bei der Wahrnehmung seiner Aufgaben, indem es bergreifende
Manahmen in der Gesamtorganisation koordiniert, Informationen
zusammentrgt und Kontrollaufgaben durchfhrt. Die genaue Ausprgung
hngt von der Gre der jeweiligen Organisation, dem angestrebten
IT-Sicherheitsniveau und den vorhandenen Ressourcen ab. Im Extremfall
besteht das IT-Sicherheitsmanagement-Team nur aus einer einzigen Person,
dem IT-Sicherheitsbeauftragten, dem in diesem Fall smtliche Aufgaben im
IT-Sicherheitsprozess obliegen.
Aufgaben des IT-Sicherheitsmanagement-Teams sind insbesondere:
- IT-Sicherheitsziele und -strategien zu bestimmen sowie die IT-Sicherheits-
leitlinie zu entwickeln,
- die Umsetzung der IT-Sicherheitsleitlinie zu berprfen,
- den IT-Sicherheitsprozess zu initiieren, zu steuern und zu kontrollieren,
- bei der Erstellung des IT-Sicherheitskonzepts mitzuwirken,
- zu berprfen, ob die im IT-Sicherheitskonzept geplanten IT-Sicherheits-
manahmen wie beabsichtigt funktionieren und geeignet und wirksam
sind,
- den Realisierungsplan fr die IT-Sicherheitsmanahmen zu genehmigen
und die erforderlichen Ressourcen zur Verfgung zu stellen
- die Schulungs- und Sensibilisierungsprogramme fr IT-Sicherheit zu
erstellen sowie
- den IT-Koordinierungsausschuss und die Leitungsebene in IT-Sicherheits-
fragen zu beraten.
Um seine Aufgaben erfllen zu knnen, sollte das IT-Sicherheitsmanagement- Zusammensetzung des
Teams
Team sich aus Personen zusammensetzen, die Kenntnisse in IT-Sicherheit,
technische Kenntnisse ber IT-Systeme, sowie Erfahrung mit Organisation
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
und Verwaltung haben. Darber hinaus sollte das IT-Sicherheitsmanagement-

Team die unterschiedlichen Aufgabenbereiche einer Organisation wider-
spiegeln. Mitglieder im IT-Sicherheitsmanagement-Team sollten mindestens
sein: ein IT-Verantwortlicher, der IT-Sicherheitsbeauftragte und ein Vertreter
der IT-Anwender. Gibt es in der Organisation bereits ein hnliches Gremium,
knnten dessen Aufgaben entsprechend erweitert werden. Um die Bedeutung
der IT-Sicherheit zu unterstreichen, ist es jedoch ratsam, ein IT-Sicherheits-
management-Team einzurichten und dieses mit Ressourcen entsprechend
auszustatten.
Nur wenige, entweder sehr groe Organisationen oder solche mit einem hohen Angemessene
Freistellung der Team-
Bedarf an IT-Sicherheit, werden die Mglichkeit haben, hauptamtliche Stellen Mitglieder
fr das IT-Sicherheitsmanagement-Team bereitstellen zu knnen. Im
allgemeinen werden diese Aufgaben neben den originren Aufgaben wahrzu-
nehmen sein. Eine Ausnahme stellt hier jedoch die erstmalige Einrichtung des
IT-Sicherheitsprozesses dar. Wenn mglich sollten die Mitglieder des IT-
Sicherheitsmanagement-Teams whrend dieser Phase weitgehend von ihren
sonstigen Aufgaben freigestellt werden. Die Entscheidung, ob und inwieweit
diese Freistellung auch danach noch sinnvoll ist, hngt von der Aufgaben-
verteilung zwischen IT-Sicherheitsmanagement-Team und IT-Sicherheits-
beauftragten ab. Die letztendliche Entscheidung hierfr liegt bei der
Behrden- bzw. Unternehmensleitung. In jedem Fall sollte das IT-Sicher-
heitsmanagement regelmig tagen, um eine kontinuierliche Steuerung des
IT-Sicherheitsprozesses zu gewhrleisten.
Bereichs-IT-Sicherheitsbeauftragte, IT-Projekt- bzw. IT-System-Sicher-
heitsbeauftragte
Bei groen Organisationen kann es erforderlich sein, in den verschiedenen
Bereichen eigene IT-Sicherheitsbeauftragte einzusetzen. Der Bereichs-IT-
Sicherheitsbeauftragte ist fr alle Sicherheitsbelange der IT-Systeme und -
Anwendungen in seinem Bereich (z. B. Abteilung, Auenstelle, o. .)
verantwortlich. Je nach Gre des zu betreuenden Bereiches kann die Aufgabe
des Bereichs-IT-Sicherheitsbeauftragten von einer Person bernommen
werden, die bereits mit hnlichen Aufgaben betraut ist, z. B. dem Bereichs-IT-
Beauftragten (falls vorhanden). Auf jeden Fall ist bei der Auswahl des
Bereichs-IT-Sicherheitsbeauftragten darauf zu achten, dass er die Aufgaben,
Gegebenheiten und Arbeitsablufe in dem zu betreuenden Bereich gut kennt.
Die verschiedenen IT-Systeme und -Anwendungen einer Organisation haben
oft verschiedene IT-Sicherheitsanforderungen, die u. U. in einer IT-System-
Sicherheitsleitlinie zusammengefasst sind und unterschiedlicher IT-Sicher-
heitsmanahmen bedrfen. Analoges trifft fr den IT-Projekt-Sicherheits-
beauftragten zu, mit dem Unterschied, dass es sich bei den Aufgaben um IT-
projektspezifische statt IT-systemspezifische handelt.
Als Aufgaben der IT-Projekt-, IT-System- bzw. Bereichs-Sicherheitsbeauf-
tragten sind festzuhalten:
- die Vorgaben des IT-Sicherheitsbeauftragten umsetzen,
- die IT-Sicherheitsmanahmen gem IT-System-Sicherheitsleitlinie
umsetzen,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- IT-systemspezifische Informationen zusammenfassen und an den

IT-Sicherheitsbeauftragten weiterleiten,
- als Ansprechpartner der IT-Benutzer vor Ort dienen,
- bei der Auswahl der IT-Sicherheitsmanahmen zur Umsetzung der
IT-System-Sicherheitsleitlinie mitwirken,
- Information ber Schulungs- und/oder Sensibilisierungsbedarf von
IT-Benutzern an den IT-Sicherheitsbeauftragten ermitteln,
- Protokolldateien regelmig kontrollieren und auswerten, sowie
- evtl. auftretende sicherheitsrelevante Zwischenflle an den IT-Sicherheits-
beauftragten melden.
Folgende Qualifikationen sollten vorhanden sein:
- detaillierte IT-Kenntnisse, da diese die Gesprche mit IT-Benutzern vor
Ort erleichtern und bei der Suche nach IT-Sicherheitsmanahmen fr die
speziellen IT-Systeme von Nutzen sind, sowie
- Kenntnisse im Projektmanagement, die bei der Organisation von IT-
Benutzerbefragungen und der Erstellung von Plnen zur Umsetzung und
der Kontrolle von IT-Sicherheitsmanahmen hilfreich sind.
- Ist ein IT-Sicherheitsbeauftragter benannt worden?
- Besteht die Notwendigkeit, den IT-Sicherheitsbeauftragte durch ein IT-
Sicherheitsmanagement-Team zu untersttzen?
- Sind die Aufgaben und Kompetenzen innerhalb des IT-Sicherheitspro-
zesses klar definiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.194 Erstellung einer bersicht ber vorhandene IT-

Systeme
Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsmanagement-Team
Nicht nur fr die Erstellung eines IT-Sicherheitskonzepts, sondern auch fr
die berprfung, Wartung, Fehlersuche und Instandsetzung von IT-Systemen
ist eine vollstndige und korrekte Erfassung der vorhandenen und geplanten
IT-Systeme notwendig. Besonderer Wert ist auf die Vollstndigkeit und
Aktualitt einer solchen bersicht zu legen. Sie sollte insbesondere auch einen
detaillierten Vernetzungsplan beinhalten.
Ist bereits ein vollstndiges IT-Gerteverzeichnis sowie ein Netzplan vorhan- IT-Gerteverzeichnis
Netzplan
den, so sind diesem die bentigten Informationen zu entnehmen. Existiert ein
solches Verzeichnis nicht oder sind die Informationen dort nicht enthalten, so
mssen sie zustzlich erfasst werden.
Die bersichtsliste muss fr alle IT-Systeme mindestens die folgenden Infor-
mationen enthalten:
- Vergabe einer laufenden Nummer,
- Bezeichnung und Art des IT-Systems,
- Installationsort des IT-Systems,
- Vernetzung des IT-Systems,
- Typ des IT-Systems (stand-alone, Client, Server, ...),
- Status des IT-Systems (in Betrieb, im Test, in Planung) und
- Benutzer des IT-Systems,
- Anwendungen auf IT-Systemen,
- Weitere Komponenten des Systems (z. B. Drucker, Diskettenlaufwerk,
Monitor,...).
Darber hinaus sollte ein Netzplan verfgbar sein, aus dem die Vernetzungs-
strukturen einschlielich der Verbindung nach auen ersichtlich sind.
Sollte eine so groe Anzahl von IT-Systemen vorhanden sein, dass eine Gruppenbildung
vollstndige Erfassung nicht angemessen erscheint, so kann man gleiche IT-
Systeme zu Gruppen zusammenfassen, wenn von Anwendungsstruktur und -
ablauf vergleichbare IT-Anwendungen auf diesen IT-Systemen laufen. Dies
gilt insbesondere fr PCs, die oft in groer Anzahl in hnlicher Konfiguration
vorhanden sind.
Wichtig ist die regelmige berprfung der Aktualitt und Vollstndigkeit Aktualisierung
einer solchen bersicht. Um dies gewhrleisten zu knnen, ist sicherzustellen,
dass das IT-Sicherheitsmanagement-Team ber jede Vernderung im einge-
setzten IT-Verbund informiert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Liegt eine Liste vorhandener und geplanter IT-Systeme vor? Enthlt sie
alle notwendigen Informationen?
- Liegt ein aktueller Vernetzungsplan vor?
- Wird die Bestandsliste und der Vernetzungsplan regelmig auf Vollstn-
digkeit und Aktualitt hin berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.195 Erstellung eines IT-Sicherheitskonzepts

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement-Team
Das IT-Sicherheitskonzept ist das "zentrale" Dokument im IT-Sicherheits-
prozess eines Unternehmens bzw. einer Behrde. Jede konkrete Manahme
muss sich letztlich darauf zurckfhren lassen.
Ein IT-Sicherheitskonzept enthlt zunchst die Beschreibung des aktuellen Zustandsbeschreibung
Zustandes eines IT-Verbundes und der auf ihr zu verarbeitenden Informatio-
nen. Unter einem IT-Verbund ist die Gesamtheit der technischen Kompo-
nenten zu verstehen, die der Aufgabenerfllung dienen. Dies beinhaltet die IT-
Systeme und die IT-Anwendungen. Der aktuelle Zustand eines IT-Verbunds
umfasst neben der Beschreibung der technischen Komponenten, der dort
betriebenen IT-Anwendungen und dabei zu verarbeitenden Informationen
auch eine Auflistung der vorhandenen Schwachstellen, mglicher Bedrohun-
gen und bereits umgesetzter Manahmen.
Je nach Schutzbedrftigkeit des vorhandenen IT-Verbunds - diese ist vorab Schutzbedarf
festzulegen und zu begrnden - und der zu verarbeitenden Informationen muss
im weiteren Vorgehen ein unterschiedlicher Untersuchungsaufwand betrieben
werden. Seitens des BSI wird dabei empfohlenen, die Manahmen dieses
Handbuchs fr smtliche IT-Systeme umzusetzen und parallel fr Komponen-
ten mit hohen oder sehr hohem Schutzbedarf eine ergnzende IT-Sicherheits-
analyse durchzufhren.
Bei der Erstellung eines IT-Sicherheitskonzepts sind die Mitarbeiter, die mit Kooperation
dem zu untersuchenden IT-Verbund und der darauf verarbeiteten Informatio-
nen befasst sind, in jeweils angemessener Art und Weise einzubeziehen.
Ebenso ist die Erfassung aller vorhandenen IT-Systeme (siehe M 2.194
Erstellung einer bersicht ber vorhandene IT-Systeme) eine Grund-
voraussetzung fr die Erstellung eines umfassenden IT-Sicherheitskonzepts.
Fr die Erstellung eines IT-Sicherheitskonzepts bietet sich folgende Vorge-
hensweise an: (Eine ausfhrliche Beschreibung der Vorgehensweise zur
Erstellung eines IT-Sicherheitskonzepts nach IT-Grundschutz befindet sich in
Kapitel 2 dieses Handbuchs)
1. Schutzbedarfsfeststellung
Bei der Schutzbedarfsfeststellung ist die Fragestellung, wie gro der maximale
Schaden ist, wenn die Verfgbarkeit, die Integritt und die Vertraulichkeit der
zu untersuchenden IT-Systeme und der Informationen beeintrchtigt wird, zu
beantworten. Um eine solche Aussage treffen zu knnen, sollten folgende
Schritte durchgefhrt werden:
1.1 Abgrenzung und Erfassung aller Bestandteile des Unter-
suchungsbereiches
In diesem Schritt werden ausgehend von der Aufgabenstellung alle
zu untersuchenden IT-Systeme und Informationen erfasst und mit
Bezug auf die Fachaufgabe beschrieben. Es ist sinnvoll, diese
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beschreibung um die Aussage zu ergnzen, ob diese IT-Systeme und

Informationen fr die Erfllung der Fachaufgabe sehr wichtig,
wichtig oder weniger wichtig sind.
1.2 Bewertung der erfassten IT-Systeme und der zu verarbeitenden
Informationen
In diesem Schritt werden fr jedes IT-System und fr die darauf
verarbeiteten Informationen die Maximalschden bestimmt, die bei
dem Verlust der drei Grundwerte Verfgbarkeit, Integritt und
Vertraulichkeit auftreten knnen. Die potentiellen Schden knnen
in Schadensszenarien eingeteilt werden:
Diese knnen sein:
- Versto gegen Gesetze, Vorschriften oder Vertrge,
- Beeintrchtigung des informationellen Selbstbestimmungs-
rechts,
- Beeintrchtigung der persnlichen Unversehrtheit,
- Beeintrchtigung der Aufgabenerfllung,
- Negative Auenwirkung sowie
- Finanzielle Auswirkungen.
Anhand der Hhe der potentiellen Schden und ihrer Folgen wird
zwischen zwei Schutzbedarfskategorien unterschieden:
- niedrig bis mittel
- hoch bis sehr hoch
2. Erfassung des Sicherheits-Ist
Zur Feststellung des Sicherheits-Ist ist eine genaue Untersuchung der IT-
Systeme ntig. Dabei sollen vorhandenen Sicherheitsmanahmen erfasst,
aber auch Defizite aufzeigt werden (Soll-Ist-Vergleich).
3. Auswahl der IT-Grundschutzmanahmen
Fr alle untersuchten IT-Systeme und Informationen sollten nun, unab-
hngig davon in welche Schutzbedarfskategorie sie eingeordnet worden
sind, die jeweiligen Manahmenempfehlungen des vorliegenden Hand-
buchs umgesetzt werden.
4. Ergnzende Sicherheitsanalyse
Es gibt verschiedene Grnde fr die Durchfhrung von IT-Sicherheits-
analysen. Sie kann z. B. dann sinnvoll sein, wenn der Schutzbedarf fr eine
IT-Anlage und die dort verarbeiteten Informationen "hoch" bzw. "sehr
hoch" ist oder wenn es sich um IT-Systeme handelt, die noch nicht im IT-
Grundschutzhandbuch behandelt worden sind, fr die also noch keine IT-
Grundschutzmanahmen existieren.
Neben Penetrationstest und Schwachstellenanalysen fr ausgewhlte
Bereiche ist die Risikoanalyse eine mgliche Vorgehensweise fr eine
solche IT-Sicherheitsanalyse. Die Durchfhrung von Risikoanalysen ist im
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
IT-Sicherheitshandbuch des BSI beschrieben. Sie kann wie folgt durchge-

fhrt werden:
4.1 Analyse der Schwachstellen und Bedrohungen
Ziel der Analyse der Schwachstellen und Bedrohungen ist das
Entdecken mglichst aller vorhandener Schwachstellen und das
Erkennen aller "wesentlichen" Bedrohungen.
4.2 Bewertung der dadurch erkannten Risiken
In diesem Schritt geht es um das Bewerten der aktuellen Risiken
durch Bedrohungen hinsichtlich Schadenswirkung und Schadens-
hufigkeit.
4.3 Festlegung geeigneter Sicherheitsmanahmen
Unter Bercksichtigung des Sicherheits-Ists sowie der gefundenen
Schwachstellen und Bedrohungen sind fr die in der vorhergehenden
Analyse als untragbar hoch erkannten Risiken zustzliche Manah-
men auszuwhlen.
5. Konsolidierung aller Manahmen
Fr die in Schritt 3 und 4 ermittelten notwendigen IT-Sicherheitsmanahmen
ist zu berprfen, ob sie sich ergnzen oder in ihrer Wirkung beeintrchtigen.
Ggf. knnen IT-Grundschutzmanahmen durch hherwertige Manahmen
ersetzt werden. Bei der Konsolidierung werden diese berschneidungen
bereinigt.
6. Kosten-Nutzen-/Gesamtkosten-Betrachtung
Bei den im IT-Grundschutzhandbuch enthaltenen Manahmen handelt es
sich um Standard-Sicherheitsmanahmen. Sie entsprechen also dem, was
umzusetzen ist, um die betrachteten IT-Systeme entsprechend dem Stand
der Technik zu schtzen. Diese Manahmen sind somit generell als ange-
messen zu betrachten. Fr sie sind in den meisten Fllen keine finanziellen
Investitionen erforderlich. Einige, insbesondere optionale Manahmen
bedrfen jedoch finanzieller Mittel.
Wichtig ist die Erstellung eines Kostenplans. Dadurch erhlt der Verant-
wortliche eine bersicht ber die anfallenden Kosten. Fr die erforder-
lichen Ressourcen an Personal und finanziellen Mitteln muss eine
Genehmigung der Leitungsebene eingeholt werden.
7. Restrisikobetrachtung
Reicht das fr IT-Sicherheit vorgesehenen Ressourcen an Personal und
Finanzmittel nicht aus, um smtliche fehlenden IT-Sicherheitsmanahmen
umzusetzen, sind die Manahmen fr die Umsetzung mit Prioritten zu
versehen. Aus der unvollstndigen Umsetzung der Manahmen resultiert
jedoch, dass Sicherheitslcken zunchst bestehen bleiben. Dies daraus
resultierenden Restrisiken, die durch die mgliche Schadenshhe und der
Einschtzung der quantitativen oder qualitativen Eintrittswahrscheinlich-
keit charakterisiert sind, sollten der Leitungsebene zur Genehmigung
vorgelegt werden. Ggf. knnen durch ein Aufstocken des Budgets weitere
Restrisiken reduziert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Sicherheitskonzept ist ein Dokument, das in der Praxis hufiger herange- Strukturierung
zogen wird, um konkrete Sicherheitsmanahmen bezglich ihrer Umsetzung
oder ihrer Aktualitt zu berprfen. Daher sollte es so strukturiert sein, dass
- spezifische Bereiche schnell gefunden werden knnen,
- es mit minimalem Aufwand aktualisiert werden kann und
- ausreichend dokumentiert sein, damit im Vertretungsfall ein Dritter sicher-
heitsspezifische Aufgaben bernehmen kann.
Hier bietet es sich an, ein Sicherheitskonzept nach Zustndigkeiten oder im
thematischem Zusammenhang zu gliedern. So sollte ein auf IT-Grundschutz
basierendes Sicherheitskonzept nach der untersuchten Organisations- bzw.
nach der Netzstruktur gegliedert sein.
Ein Sicherheitskonzept kann Informationen beinhalten, die nicht beliebig Vertraulichkeit
weitergegeben werden sollten, so zum Beispiel ber noch nicht beseitigte
Schwachstellen. Die Vertraulichkeit dieser Informationen ist sicherzustellen,
indem ausschlielich den Betroffenen die fr sie relevanten Teile zugnglich
gemacht werden. Eine entsprechende Gliederung des Sicherheitskonzeptes
kann dies untersttzen.
- Existiert ein IT-Sicherheitskonzept?
- Wann wurde es zuletzt aktualisiert?
- Wo befindet sich das Konzept?
- Wer darf darauf zugreifen?
- Ist jeder zumindest ber die ihn unmittelbar betreffenden Teile des
Sicherheitskonzeptes informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.196 Umsetzung des IT-Sicherheitskonzepts nach

einem Realisierungsplan
Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsmanagement-Team
Nach der Erstellung des IT-Sicherheitskonzepts ist dieses in die Praxis umzu-
setzen. Hierbei ist zwischen einer Konzeptionsphase und der eigentlichen
Realisierung zu unterscheiden.
In der Konzeptionsphase ist die grundstzliche Eignung jeder empfohlenen Konzeptionsphase
Manahme innerhalb des vorliegenden IT-Verbunds zu prfen und die
Manahmeempfehlungen derart zu konkretisieren, dass sie in organisations-
spezifischen Regelungen mnden. Im IT-Sicherheitskonzept erfolgt daher
neben der Festlegung der Verantwortlichkeit fr die Initiierung insbesondere
die Festlegung der Verantwortung fr die Umsetzung der Manahmen.
Die Verantwortung fr die Initiierung umfasst das Schaffen der Voraus- Initiierung
setzungen fr die wirksame Umsetzung sowie die Festlegung der Ziele. Diese
Verantwortung setzt das Verfgungsrecht ber die erforderlichen Ressourcen
voraus.
Zur Initiierung gehren im Allgemeinen:
- die Zielvorgabe mit der Beschreibung des erwarteten Soll-Zustandes oder
des erwarteten Verhaltens,
- die Freigabe von Ressourcen (Arbeitszeit, Finanzmittel) und
- eine realistische Zeitvorgabe.
Die Verantwortung fr die Umsetzung gliedert sich in Ausgestaltung der Umsetzung
Regelungen, Beschaffung der Hilfsmittel, Gestaltung von Ablufen und
Information der betroffenen Mitarbeiter. Mit der Anwendung einer Manahme
im engeren Sinne ist die Umsetzung abgeschlossen. Die Verantwortung fr
Umsetzung und Anwendung kann in verschiedenen Hnden liegen. Zur
Umsetzung gehren:
- die Gestaltung von technischen oder organisatorischen Ablufen an den
Arbeitspltzen,
- die Anpassung von Aufgabenbeschreibungen,
- die Bereitstellung von Anleitungen und Informationen fr Sensibilisie-
rungs- und Schulungsmanahmen und
- die Bereitstellung der Hilfsmittel und Umsetzung der Manahme am
Arbeitsplatz.
Eine Grenze zwischen Initiierung und Umsetzung lsst sich nicht immer Kooperation
eindeutig ziehen, sie ist abhngig von der Reichweite und Art der Manahme
(technisch/organisatorisch). Vielfach ist fr die Umsetzung von Manahmen
die Kooperation zwischen verschiedenen Stellen erforderlich. So sind einer-
seits Systemverantwortliche gefordert, technische Einrichtungen zu beschaf-
fen, zu installieren und zu pflegen - etwa bei der Einrichtung von Sicherheits-
oberflchen - andererseits sind Organisationsverantwortliche in der Pflicht, die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
entsprechenden Regelungen fr den Einsatz zu schaffen und zu dokumen-

tieren.
Ein strukturierter Realisierungsplan ist Voraussetzung fr die korrekte Umset- Realsierungsphase
zung der identifizierten IT-Sicherheitsmanahmen. Das IT-Sicherheits-
management-Team ist verantwortlich fr die Erstellung des Umsetzungsplans.
Die konkrete Umsetzung der einzelnen Manahmen obliegt je nach Art und
Umfang dem Benutzer des betroffenen IT-Systems oder einem zustndigen
IT-Betreuer. Diese sind bei der Umsetzung vom IT-Sicherheitsmanagement-
Team zu untersttzen. Insbesondere muss jeder Mitarbeiter vorab wissen, an
wen er sich bei auftretenden Problemen wenden kann.
In einem Realisierungsplan sollte Folgendes dokumentiert werden:
- Name der Person, die fr die Umsetzung einer Manahme verantwortlich
ist,
- Prioritt der umzusetzenden Manahme,
- Festlegung des Zeitpunktes, bis wann die Manahme umzusetzen ist,
- Stelle, der die vollzogene Umsetzung der Manahme zu melden ist,
- Bereitstellung von Ressourcen (Mitarbeiterkapazitten, Raumbedarf,
Kosten).
Es ist sinnvoll die Umsetzung der Manahmen durch entsprechende Schulung
und Sensibilisierung der IT-Benutzer vorzubereiten bzw. zu begleiten (siehe
die Manahmen M 2.197 Erstellung eines Schulungskonzepts fr IT-
Sicherheit und M 2.198 Sensibilisierung der Mitarbeiter fr IT-Sicherheit)
- Wird bei Manahmenempfehlungen im IT-Sicherheitskonzept die Verant-
wortung fr Initiierung und Umsetzung eindeutig festgelegt?
- Existiert ein Umsetzungsplan?
- Werden berprfungen durchgefhrt und dokumentiert?
- Wird das Management ber die Ergebnisse informiert?
- Werden die Regelungen zur Umsetzung von IT-Sicherheitsmanahmen
dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.197 Erstellung eines Schulungskonzepts fr IT-

Sicherheit
Verantwortlich fr Umsetzung: Vorgesetzte, IT-Sicherheitsmanagement-
Team
Die sachgerechte Erfllung der Gemeinschaftsaufgabe "IT-Sicherheit" kann Angemessener
Kenntnisstand
nur dann gelingen, wenn alle am IT-Sicherheitsprozess beteiligten Personen
einen angemessenen Kenntnisstand ber IT-Sicherheit allgemein und insbe-
sondere ber die Gefahren und Gegenmanahmen in ihrem eigenen Arbeits-
gebiet haben. Obwohl letztlich jeder Benutzer dazu motiviert werden sollte,
sich auch in Eigeninitiative auf dem notwendigen Kenntnisstand zu halten,
bleibt es in der Verantwortung der Organisationsleitung durch geeignete
Schulungsmanahmen hierfr die ntigen Voraussetzungen zu schaffen.
Angesichts des Umfangs der mglichen Schulungsthemen und der Bedeutung
der IT-Sicherheit ist bei der Auswahl der Schulungsinhalte ein koordiniertes
Vorgehen erforderlich. Dieses ist in Schulungskonzepten darzulegen und zu
dokumentieren.
Bei greren Organisationen mit heterogenen Arbeitspltzen wird ein Konzept Zielgruppen
in der Regel nicht ausreichen. Vielmehr sind Schulungskonzepte nach Umfang
und Inhalt auf die Bedeutung und Komplexitt des IT-Einsatzes bei den
jeweiligen Zielgruppen abzustimmen. So muss der IT-Sicherheitskenntnis-
stand eines IT-Administrators oder Softwareentwicklers deutlich hher sein,
als der etwa eines kaufmnnischen Mitarbeiters oder einer Schreibkraft. Erster
Schritt bei der Abfassung von Schulungskonzepten zur IT-Sicherheit ist daher
die Einteilung der Mitarbeiter einer Organisation in Zielgruppen, fr die
jeweils ein eigenes Konzept erstellt wird. Hierbei ist zu gewhrleisten, dass
sich jeder Mitarbeiter, dessen Arbeitsbereich mittelbar oder unmittelbar mit
der IT zusammenhngt, in einer solchen Gruppe wiederfindet, dass dieses
Konzept nachprfbar umgesetzt wird und dass die Schulungsnachweise
aufbewahrt werden. Somit wird sichergestellt, dass eine umfassende Schulung
in jeweils angemessener Tiefe stattfindet.
Die Schulungskonzepte zur IT-Sicherheit mssen in enger Abstimmung mit Einbindung in
bestehende
den sonstigen Schulungskonzepten eines Unternehmens bzw. einer Behrde, Schulungskonzepte
insbesondere mit der IT-Anwenderschulung erstellt werden. Dabei sollte
berlegt werden, inwieweit es mglich ist, Schulungsthemen zur IT-Sicherheit
in Letztere zu integrieren. Eine solche Einbindung hat den Vorteil, dass IT-
Sicherheit unmittelbar als Bestandteil des IT-Einsatzes wahrgenommen wird.
Voraussetzung hierfr ist zunchst eine ausreichende, nachgewiesene Qualifi-
kation der Dozenten. Entscheidend bei der Gestaltung der Schulung selbst ist
ein hinreichender Umfang des Teils "IT-Sicherheit" innerhalb des Gesamt-
plans. Eine "Kurz-Abhandlung" des Themas etwa am Freitag zwischen 13 und
14 Uhr gengt sicherlich nicht.
Ein Schulungskonzept zur IT-Sicherheit sollte fr alle IT-Nutzer mindestens Mindestinhalte
die folgenden Punkte enthalten:
- Risiken und Bedrohungen bei der IT-Nutzung
- Grundbegriffe und Grundwerte der IT-Sicherheit
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die organisationsweite IT-Sicherheitsleitlinie - Was bedeutet sie in

meinem Arbeitsalltag?
- Verantwortlichkeiten und Meldewege in unserer Organisation (mit persn-
licher Vorstellung der IT-Sicherheitsbeauftragten)
- Wie kann ich zur IT-Sicherheit beitragen?
- Wie erkenne ich sicherheitsrelevante Vorflle und was ist zu tun?
- Wie kann ich mich selbst in Fragen der IT-Sicherheit fortbilden und
informieren?
Je nach Art und Tiefe des IT-Einsatzes sollte es fr bestimmte Zielgruppen Spezifische Inhalte
auch weiterfhrende Gesichtspunkte enthalten wie z. B.:
- Sichere elektronische Kommunikation,
- Sicherheitsaspekte bestimmter IT-Systeme und Anwendungen,
- sichere Softwareentwicklung und
- Erstellung und Revision von IT-Sicherheitskonzepten.
In jedem Fall ist zu prfen, bei welchen der zu behandelnden Themen eigene Auswahl geeigneter
Dozenten
Mitarbeiter als Dozenten in Frage kommen und wo externe Schulungen sinn-
voll sind. Letzteres wird insbesondere bei Arbeitsbereichen mit hoher IT-
Durchdringung und hohem Komplexittsgrad erforderlich sein; insbesondere
bei der Fortbildung von IT-Sicherheits-Verantwortlichen, der selbstverstnd-
lich eine besonders groe Bedeutung zukommt.
In dem sich dynamisch entwickelnden IT-Bereich verliert einmal erworbenes Aktualisierung des
Wissens
Wissens rasch an Wert. Neue IT-Systeme, aber auch neue Bedrohungen und
Schwachstellen und mgliche Abwehrmanahmen machen eine stndige
Auffrischung und Erweiterung des Wissen ber IT-Sicherheit dringend erfor-
derlich. Das diesbezgliche Schulungsangebot sollte sich daher nicht
ausschlielich an neue Mitarbeiter richten, sondern auch fr erfahrenere IT-
Benutzer in regelmigen Abstnden Auffrischungs- und Ergnzungskurse
vorsehen. Weiter ist es vor diesem Hintergrund wichtig, die Schulungskon-
zepte einer regelmigen Aktualisierung zu unterziehen und sie ntigenfalls
an neue Gegebenheiten anzupassen.
Eine weitere Voraussetzung fr die laufende Auffrischung des Schulungs- Schulung und
Sensibilisierung
wissens ist eine enge Verzahnung von Schulungs- und Sensibilisierungs-
manahmen (siehe M 2.198 Sensibilisierung der Mitarbeiter fr IT-
Sicherheit). So sollte bereits in den Schulungen auf vorhandene
Informationsquellen und insbesondere auf Mglichkeiten zum vertiefenden
Selbststudium (Selbstlernkurse, Bcher etc.) hingewiesen werden.
- Liegen schriftlich festgelegte IT- und IT-Sicherheits-Schulungskonzepte
fr alle IT-Benutzer-Gruppen einer Organisation vor?
- Wird das IT-Sicherheitsmanagement-Team bei der Planung und Durch-
fhrung von IT-Schulungen eingebunden?
- Existieren Aktualisierungsplne fr Schulungskonzepte und werden diese
eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.198 Sensibilisierung der Mitarbeiter fr IT-Sicherheit

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement-Team, IT-Betreuer
In der Praxis besttigt sich immer wieder, dass ein Groteil der Sicherheits-
vorflle bei der IT-Nutzung nicht durch organisationsfremde Auentter,
sondern durch unsachgemes Verhalten eigener Mitarbeiter hervorgerufen
wird. Daher kann die Verbesserung der IT-Sicherheitskenntnisse der eigenen
Mitarbeiter und die Erhhung der Eigenverantwortung jedes IT-Benutzers als
eine besonders wirksame und berdies relativ kostengnstige Manahme zur
Erhhung der IT-Sicherheit gelten. Ebenso sind gute IT-Sicherheitskenntnisse
Voraussetzung dafr, dass sicherheitsrelevante Zwischenflle frhzeitig als
solche erkannt werden. Es sollte bei allen Mitarbeitern ein hinreichender
Kenntnisstand ber die Belange der IT-Sicherheit und das Bewusstsein fr die
Risiken im alltglichen Umgang mit der IT vorhanden sein. Zur Erreichung
dieses Ziels trgt neben einem Schulungskonzept fr IT-Sicherheit (siehe
M 2.197 Erstellung eines Schulungskonzepts fr IT-Sicherheit) insbesondere
die wiederholte Sensibilisierung aller Mitarbeiter durch IT-Sicherheits-
Verantwortliche, Vorgesetzte oder Kollegen wesentlich bei.
Im Mittelpunkt der Sensibilisierungsmanahmen sollten stets die Zielsetzun- Leitidee der
Sensibilisierung
gen der IT-Sicherheitsleitlinie stehen. Jedem Mitarbeiter muss im tglichen
Umgang mit der IT bewusst sein und gemacht werden, dass die Einhaltung der
Sicherheitsziele, die gewissenhafte Umsetzung der Sicherheitsmanahmen
sowie die Erhaltung und Steigerung des erlangten Sicherheitsniveaus zu
seinen selbstverstndlichen Pflichten innerhalb des Unternehmens oder der
Behrde gehrt.
Wirksame Mglichkeiten zur Sensibilisierung fr Belange der IT-Sicherheit
sind z. B.:
- Mitarbeiter-Workshops zum Thema "Wie trgt die IT-Sicherheit zu unserer
Arbeitsaufgabe bei?",
- Sprechstunden des IT-Sicherheitsbeauftragten,
- Einrichtung eines "Sicherheitsforums" im Intranet,
- Verffentlichung von "IT-Sicherheitsreports" im Intranet,
- Sichtbare Frderung des IT-Sicherheits-Gedankens durch die Leitungs-
ebene,
- Aushang von (Presse-) Informationen ber IT-Sicherheitsvorflle und
Lsungsanstze am Schwarzen Brett o. .,
- Auslegen von Fachzeitschriften zur IT-Sicherheit und
- Gesprche am Arbeitsplatz und in Arbeitspausen zu Themen der IT-
Sicherheit.
Fr die Akzeptanz des IT-Sicherheitsprozesses insgesamt ist es frderlich, Kollegial aber
konsequent
wenn die Sensibilisierungsmanahmen nicht in belehrender, autoritrer Form
erfolgen, sondern eher den Charakter eines informativen, kollegialen
Gesprchs tragen. Dazu ist es entscheidend, dass fr jeden Mitarbeiter arbeits-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
platznahe Ansprechpartner zur Verfgung stehen, die er ohne

"Schwellenangst" kontaktieren kann. Dies ist insbesondere in Bezug auf das
Melden erkannter sicherheitsrelevanter Zwischenflle wichtig. Dies bedeutet
auch, dass festgestellte Mngel beim Sicherheitsbewusstsein einzelner Mitar-
beiter nicht sofort zu unangenehmen Sanktionen fhren drfen, sondern
gemeinsam und mglichst "geruschlos" geschlossen werden sollten. Erst
wenn diese Vorgehensweise wiederholt keinen Erfolg zeigt, sollten weiter-
gehende (notfalls auch personelle) Manahmen - dann allerdings konsequent -
ergriffen werden.
Unabdingbar fr die Akzeptanz und Glaubwrdigkeit von Sensibilisierungs- Das gute Beispiel
manahmen ist natrlich, dass alle IT-Sicherheitsverantwortlichen und die
Leitungsebene hinsichtlich ihrer eigenen Sensibilisierung und vor allem der
konsequenten Umsetzung der Sicherheitsmanahmen mit gutem Beispiel
vorangehen.
- Stehen den IT-Sicherheitsverantwortlichen und ggf. allen Mitarbeitern
Fachzeitschriften zur IT-Sicherheit zur Verfgung?
- Wird in geeigneter Form auf organisationsinterne oder ffentlich bekannt
gewordene IT-Sicherheitsvorkommnisse hingewiesen und werden ggf.
Wege zu deren Vermeidung aufgezeigt?
- Existieren allgemein akzeptierte und genutzte Foren zur organisations-
internen Kommunikation ber Belange der IT-Sicherheit?
- Verfgen die Sicherheitsverantwortlichen ber ausreichend fundierte
psychologische Kenntnisse zur motivierenden Gesprchsfhrung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.199 Aufrechterhaltung der IT-Sicherheit

Verantwortlich fr Umsetzung: IT-Sicherheitsbeauftragter
Im IT-Sicherheitsprozess geht es nicht nur darum, das angestrebte IT-Sicher-
heitsniveau zu erreichen, sondern dieses auch dauerhaft zu gewhrleisten. Um
das bestehende IT-Sicherheitsniveau aufrechtzuerhalten und fortlaufend zu
verbessern, sollten alle IT-Sicherheitsmanahmen regelmig berprft
werden.
Diese berprfungen sollten zu festgelegten Zeitpunkten (mindestens alle Regelmige und
anlassbezogene
zwei Jahre) durchgefhrt werden und knnen bei gegebenem Anlass auch Prfungen
zwischenzeitlich erfolgen. Insbesondere Erkenntnisse aus sicherheitsrele-
vanten Zwischenfllen, Vernderungen im technischen oder technisch-organi-
satorischen Umfeld sowie nderungen von Sicherheitsanforderungen bzw.
Bedrohungen erfordern eine Anpassung der bestehenden IT-Sicherheits-
manahmen. Die in den einzelnen berprfungen erlangten Ergebnisse sollten
dokumentiert werden und es muss festgelegt sein, wie mit den ber-
prfungsergebnissen zu verfahren ist. Hervorzuheben ist hierbei, dass
berprfungen nur dann wirksam die IT-Sicherheit aufrechterhalten knnen,
wenn aufgrund der berprfungsergebnisse auch die erforderlichen Korrek-
turmanahmen ergriffen werden.
Es sollte in der Behrde bzw. im Unternehmen festgelegt werden, wie die Koordinierte
Vorgehensweise
Ttigkeiten im Zusammenhang mit diesen berprfungen zu koordinieren
sind. Dazu ist zu regeln, welche IT-Sicherheitsmanahmen wann und von
wem zu berprfen sind. Somit wird zum einen Doppelarbeit vermieden und
zum anderen verhindert, dass bestimmte Bereiche innerhalb einer Organi-
sation unbercksichtigt bleiben.
Einerseits kann mit einer berprfung festgestellt werden, ob die IT-Sicher- Revision und Aktualisie-
rung
heitsmanahmen auch auf allen Ebenen im laufenden Betrieb funktionsfhig
sind. Andererseits kann mit einer berprfung ermittelt werden, inwieweit die
IT-Sicherheitsmanahmen bezogen auf die Sicherheitsanforderungen geeignet
und hinsichtlich der Abwehr von Bedrohungen wirksam sind. Man unter-
scheidet demnach zwei Arten der berprfung: IT-Sicherheitsrevision und
Aktualisierungsprfung.
Durch eine IT-Sicherheitsrevison wird festgestellt,
- ob die umgesetzten IT-Sicherheitsmanahmen mit den dokumentierten
bereinstimmen und
- ob die IT-Sicherheitsmanahmen auch so funktionieren, wie es beabsich-
tigt war.
Als Ergebnis dieses Soll-Ist-Abgleichs kann sich herausstellen, dass
beispielsweise IT-Sicherheitsmanahmen nicht umgesetzt worden sind oder
dass sie in der Praxis nicht greifen. In beiden Fllen sollten die Ursachen fr
die Abweichungen ermittelt werden. Als mgliche Korrekturmanahmen
kommen - je nach Ursache - in Frage:
- organisatorische Manahmen sind anzupassen,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- personelle Manahmen, z. B. Schulungs- und Sensibilierungsmanahmen

sind zu ergreifen oder disziplinarische Manahmen einzuleiten,
- infrastrukturelle Manahmen, z. B. bauliche Vernderungen sind zu initiie-
ren,
- technische Manahmen, z. B. nderungen an Hardware und Software oder
Kommunikationsverbindungen und Netzwerken sind vorzunehmen,
- Entscheidungen des verantwortlichen Vorgesetzten (bis hin zur Leitungs-
ebene) sind einzuholen.
Auf jeden Fall sollte fr jede Abweichung eine Korrekturmanahme vorge-
schlagen werden. Auerdem sollte festgelegt werden, wer fr die Umsetzung
der Kontrollmanahme zustndig und bis wann die Umsetzung durchzufhren
ist.
Die IT-Sicherheitsrevision beinhaltet auch die berprfung, ob eine Auswer-
tung und Kontrolle von Log- bzw. Protokolldateien und Filtereinstellungen
- wo erforderlich - stattgefunden hat.
Durch eine Aktualisierungsprfung wird festgestellt,
- ob die IT-Sicherheitsmanahmen weiterhin angemessen sind, die
IT-Sicherheitsziele zu erreichen,
- ob die IT-Sicherheitsmanahmen weiterhin ausreichend sind, das Risiko zu
reduzieren,
- ob die IT-Sicherheitsziele noch aktuell sind.
Als Ergebnis dieser Aktualisierungsprfung kann sich herausstellen, dass
beispielsweise aufgrund von nderungen jedweder Art die IT-Sicherheits-
manahmen nicht mehr den aktuellen Risiken entgegenwirken, der IT-Sicher-
heitsprozess nicht optimal abluft oder im IT-Sicherheitsmanagement Fehler
liegen. In allen drei Fllen sollten die Ursachen fr die Sicherheitslcken
ermittelt werden. Als mgliche Korrekturmanahmen kommen - je nach
Ursache - in Frage:
- Vernderung im IT-Sicherheitsmanagement,
- Anpassung des IT-Sicherheitsprozesses,
- Ermittlung neuer Gefhrdungen,
- Einsatz neuer Technik (IT-Systeme und Anwendungen),
- Nutzung neuer IT-Sicherheitstechniken,
- nderung der IT-Sicherheitsmanahmen,
- Bercksichtigung von neuen oder genderten Gesetzen und Verordnungen
und
- Bercksichtigung des aktualisierten IT-Grundschutzhandbuchs.
Auf jeden Fall sollte fr jede Sicherheitslcke eine Korrekturmanahme
vorgeschlagen werden. Auerdem sollte festgelegt werden, wer fr die
Steuerung und Kontrolle der Korrekturmanahmen verantwortlich ist oder ob
gegebenenfalls das zustzliche Risiko tragbar ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Aktualisierungsprfung beinhaltet auch die berprfung, ob auf nde-

rungen jedweder Art - soweit erforderlich - adquat reagiert wurde.
Bei beiden berprfungen, sowohl der IT-Sicherheitsrevision als auch der Vorgehensweise
Aktualisierungsprfung, ist bezglich der Durchfhrung Folgendes zu beach-
ten:
Entsprechend dem berprfungszweck sind Umfang und Tiefe der ber- Planung
prfung festzulegen. Als Grundlage fr die berprfung dient das IT-Sicher-
heitskonzept und die vorhandene Dokumentation des IT-Sicherheitsprozesses.
Die berprfung, die von internen oder externen Personen durchgefhrt
werden kann, ist sorgfltig zu planen. Whrend der Durchfhrung sind alle
relevanten Feststellungen von den Prfenden zu dokumentieren und auszu-
werten.
Die Ergebnisse sind in einem IT-Sicherheitsreport festzuhalten. Dieser sollte IT-Sicherheitsreport
auch die vorgeschlagenen Korrekturmanahmen aus fachlicher Sicht enthal-
ten. Der IT-Sicherheitsreport, der gegebenenfalls vertrauliche und somit
schtzenswerte Informationen enthlt, sollte dem IT-Sicherheitsbeauftragten
(falls er die berprfung nicht selbst durchgefhrt hat) vorgelegt werden und
dem Leiter des berprften Bereiches sowie dem IT-Sicherheitsmanagement-
Team zur Kenntnis gegeben werden. Bei schwerwiegenden Problemen sollte
die Leitungsebene mit einbezogen werden, damit auch weitreichende
Entscheidungen zeitnah getroffen werden knnen. Hierzu dient ein Manage-
mentreport zur IT-Sicherheit, dessen Bedeutung in der Manahme M 2.200
Erstellung von Managementreports zur IT-Sicherheit dargelegt ist.
Aufgrund des berprfungsergebnisses sind Entscheidungen ber das weitere Korrekturmanahmen
Vorgehen zu treffen; insbesondere sind alle erforderlichen Korrekturmanah-
men zu beschlieen und in Form eines Umsetzungsplans festzuhalten. Die
Verantwortlichen fr die Umsetzung der Korrekturmanahmen, die analog zur
Vorgehensweise in M 2.196 Umsetzung des IT-Sicherheitskonzepts nach
einem Realisierungsplan ausgefhrt wird, sind zu benennen und mit den
notwendigen Ressourcen auszustatten.
Zusammenfassend ist festzuhalten, dass das erreichte IT-Sicherheitsniveau
sich nur aufrechterhalten lsst, wenn
- die Aufrechterhaltung der IT-Sicherheit im Betrieb durch organisatorische
Regelungen ermglicht wird,
- die Verantwortungen fr diese Aufrechterhaltung klar zugewiesen werden,
- die Manahmen vollstndig wie beschrieben umgesetzt sind,
- die Manahmen regelmig daraufhin geprft werden, ob sie wie
beabsichtigt funktionieren,
- die Manahmen korrekt eingesetzt bzw. eingehalten sind und sie akzeptiert
werden,
- Manahmen angepasst werden, falls sich neue Schwachstellen zeigen,
- die Manahmen angepasst werden, falls es personelle oder organisato-
rische nderungen bzw. nderungen im Hardware- oder Softwarebereich
gibt,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- nderungen in der Aufgabenstellung oder in der Wichtigkeit der Aufgabe

fr die Institution bercksichtigt werden
- rumliche nderungen, wie z. B. nach einem Umzug bercksichtigt
werden,
- bei nderungen von Bedrohungen und/oder Schwachstellen Anpassungen
erfolgen.
Alle diese nderungen haben einen signifikanten Einfluss auf die Sicher- Neue Sicherheitsrisiken
heitsrisiken. Die neuen Sicherheitsrisiken sollten so frh wie mglich erkannt
werden, um rechtzeitige Reaktionen zu erlauben. Falls sich herausstellt, dass
das tatschliche Risiko von dem im IT-Sicherheitskonzept akzeptierten Rest-
risiko abweicht, so sollten Ressourcen bereitgestellt werden, um diesen
Zustand zu ndern.
- Wird eine regelmige IT-Sicherheitsrevision durchgefhrt?
- Wann wird die nchste Aktualisierungsprfung durchgefhrt?
- Werden IT-Sicherheitsrevisionen gegebenenfalls auch von einer
Revisionsabteilung (sofern vorhanden) durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.200 Erstellung von Managementreports zur IT-

Sicherheit
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement-Team
Zu den Aufgaben des IT-Sicherheitsmanagement-Teams gehrt es, die
Leitungsebene eines Unternehmens oder einer Behrde bei der Wahrnehmung
ihrer Gesamtverantwortung fr die IT-Sicherheit zu untersttzen. Ein wichti-
ges Instrument zur Erfllung dieser Aufgabe ist ein Bericht zur aktuellen Lage
der IT-Sicherheit. Durch ein solches Papier soll die Unternehmens- bzw.
Behrdenleitung mit ntigen Informationen fr die zu treffenden Entschei-
dungen versorgt werden.
Grundstzlich ist zwischen zwei verschiedenen Formen von Management-
reports zu unterscheiden:
1. Regelmige Managementreports
Durch die mglichst regelmige Vorlage eines Managementreports "IT-
Sicherheit" wird verhindert, dass das Thema bei der Leitungsebene "in
Vergessenheit" gert. Er ist also gewissermaen ein
"Sensibilisierungsinstrument" fr die Gesamtverantwortlichen. Aus diesem
Grund sollte ein solcher Bericht mindestens einmal im Jahr erstellt werden.
Der Managementreport "IT-Sicherheit" sollte aufzeigen:
- inwieweit die Vorgaben des IT-Sicherheitskonzepts im Unternehmen oder
in der Behrde bereits abgedeckt sind,
- an welchen Stellen noch Lcken - und damit Restrisiken - bestehen,
- inwieweit das IT-Sicherheitsniveau den Sicherheitsanforderungen und der
Bedrohungslage der Organisation gengt,
- ob die Aktivitten im Rahmen IT-Sicherheit Erfolg hatten,
- ob sich die IT-Sicherheitsmanahmen zur Erreichung der IT-Sicherheits-
ziele als geeignet erwiesen haben,
Daneben sollte auch ein Ausblick auf die zu erwartende Weiterentwicklung
der organisationsweiten IT-Sicherheit gegeben werden.
2. Anlassbezogene Managementreports
Neben den regelmigen Managementreports zur IT-Sicherheit kann es auch
notwendig sein, bei berraschend auftretenden IT-Sicheitsproblemen oder
aufgrund von mit neuen technischen Entwicklungen verbundenen Risiken
anlassbezogene Managementreports zu erstellen. Dies ist vor allem dann der
Fall, wenn sich herausstellt, dass diese Probleme nicht "auf Arbeitsebene"
beseitigt werden knnen, weil z. B. materielle Ressourcen auerhalb des
bewilligten Rahmens bentigt werden oder weitergehende personelle Rege-
lungen getroffen werden mssen. Immer wieder erregen IT-Sicherheitsvorflle
wie globale Computer-Virenattacken (z. B. Melissa, Loveletter) die Aufmerk-
samkeit der Massenmedien. Es hat sich als sinnvoll erwiesen, auch in diesen
Fllen Managementreports zu erstellen, um aufzuzeigen, in wie weit die
eigene Organisation von diesen Sicherheitsvorfllen betroffen wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei der Abfassung der Managementreports sollte bercksichtigt werden, dass kurz und verstndlich
der Leserkreis sich in der Regel nicht aus technischen Experten zusammen-
setzt. Entsprechend sollte sich der Text durch grtmgliche Verstndlichkeit
und Knappheit auszeichnen. Die Verfasser sollten gezielt die wesentlichen
Punkte - insbesondere also bestehende Schwachstellen, aber auch erreichte
Erfolge - herausarbeiten und nicht versuchen, ein "vollstndiges" Bild zu
vermitteln.
Zum Abschluss des Managmentreports - insbesondere bei anlassbezogenen Entscheidungsvorlage
Berichten - sollten immer klar priorisierte und mit realistischen Abschtzun-
gen des zu erwartenden Umsetzungsaufwands versehene Manahmenvor-
schlge stehen. Hierdurch wird sichergestellt, dass eine notwendige Entschei-
dung der Leitungsebene ohne unntige Verzgerungen herbeigefhrt werden
kann.
Wenn irgend mglich, sollte der Managementreport "IT-Sicherheit" der Zusammenarbeit mit der
Leitungsebene
Leitungsebene nicht nur schriftlich unterbreitet, sondern auch durch ein
Mitglied des IT-Sicherheitsmangement-Teams prsentiert werden. Eine solche
persnliche bergabe erffnet zum einen die Mglichkeit, auf wesentliche
Schwerpunkte, insbesondere auf bestehende oder drohende Sicherheitsmngel
mit besonderem Nachdruck hinzuweisen. Zum anderen steht der anwesende
IT-Sicherheitsverantwortliche auch direkt fr Nachfragen oder weitergehende
Erluterungen zur Verfgung, was wiederum erfahrungsgem zu einer
Beschleunigung des Entscheidungsvorgangs fhrt. Nicht zuletzt bietet ein
solcher persnlicher Kontakt die Mglichkeit, einen "kleinen Dienstweg" zu
etablieren, dessen Existenz sich in dringenden Notfllen als sehr hilfreich
erweisen kann. Alternativ bzw. ergnzend zur persnlichen Prsentation des
Managementreports sollte berlegt werden, ob ein Mitglied der Leitungsebene
des Unternehmens oder der Behrde mit entsprechendem fachlichen Hinter-
grund und Interesse vorab als Ansprechpartner zur Verfgung steht. Auch so
knnen Leitungsentscheidungen besser vorbereitet und Probleme schon im
Voraus entschrft werden.
Zur kontinuierlichen Verfolgung des IT-Sicherheitsprozesses sollten smtliche Dokumentation
Managementreports zur IT-Sicherheit ggf. mit Vermerken ber die getroffe-
nen Entscheidungen in geordneter Weise zusammen mit den sonstigen IT-
sicherheitsrelevanten Dokumenten archiviert werden und allen Sicherheits-
verantwortlichen bei Bedarf kurzfristig zugnglich sein (siehe M 2.201
Dokumentation des IT-Sicherheitsprozesses).
Da die Managmentreports zur IT-Sicherheit im Allgemeinen sensitiven Infor- Vertraulichkeit
mationen ber bestehende Sicherheitslcken und Restrisiken enthalten, ist
deren Vertraulichkeit sicherzustellen. Eine Weitergabe an unbefugte Personen
ist zuverlssig auszuschlieen.
- Werden die Managementreports "IT-Sicherheit" zusammen mit sonstigen
relevanten Dokumenten zum IT-Sicherheitsprozess archiviert?
- Gibt es innerhalb des Unternehmens oder der Behrde "geeignete" Mit-
glieder der Leitungsebene, mit denen der Managementreport vorab abge-
stimmt und seine Vorlage vorbereitet werden kann?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.201 Dokumentation des IT-Sicherheitsprozesses

Verantwortlich fr Umsetzung: IT-Sicherheitsbeauftragter
Der Ablauf des IT-Sicherheitsprozesses und die Arbeitsergebnisse in seinen
einzelnen Phasen sollten dokumentiert werden. Eine solche Dokumentation ist
eine wesentliche Grundlage fr die Aufrechterhaltung der IT-Sicherheit und
damit entscheidende Voraussetzung fr die effiziente Weiterentwicklung des
Prozesses. Sie hilft dabei, die Ursachen von Strungen und fehlgeleiteten
Ablufen zu finden und zu beseitigen. Wichtig ist dabei, dass nicht nur die
jeweils aktuelle Version der betreffenden Unterlagen griffbereit gehalten wird,
sondern auch eine zentrale Archivierung der Vorgngerversionen vorgenom-
men wird. Erst hierdurch ist eine kontinuierliche Rckverfolgung der Ent-
wicklung im Bereich IT-Sicherheit, bei der die getroffenen Entscheidungen
nachvollziehbar werden, gewhrleistet.
Die Dokumentation des IT-Sicherheitsprozesses sollte sich mindestens auf die
folgenden Dokumente erstrecken:
- IT-Sicherheitsleitlinie,
- IT-Systembersichten (inklusive Netzplne etc.),
- IT-Sicherheitskonzept(e),
- Umsetzungsplne fr IT-Sicherheitsmanahmen,
- Regelungen fr den ordnungsgemen und sicheren IT-Einsatz,
- Dokumentationen von berprfungen (Prflisten, Befragungsproto-
kolle,...),
- Sitzungsprotokolle und Beschlsse des IT-Sicherheitsmanagement-Teams,
- Managementreports zur IT-Sicherheit,
- IT-Sicherheits-Schulungsplne und
- Meldungen ber sicherheitsrelevante Vorflle.
Es ist Aufgabe des IT-Sicherheitsbeauftragten, stets eine aktuelle Dokumen- Geregelter Zugriff
tation vorzuhalten. Auerdem sollte er fr einen geregelten Zugriff auf die
Dokumentation sorgen. Hierbei ist einerseits eine schnelle Informations-
weitergabe an Berechtigte sowie andererseits die Vertraulichkeit von organi-
sationsinternen Details sicherzustellen.
- Existieren Regelungen zur Wahrung der Vertraulichkeit der Dokumen-
tation?
- Wie aktuell sind die vorhandenen Dokumente?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.202 Erstellung eines Handbuchs zur IT-Sicherheit

Verantwortlich fr Umsetzung: Leiter Organisation
Im Laufe des IT-Sicherheitsprozesses werden nicht nur die in den vorstehen-
den Manahmen erwhnten Dokumente produziert, sondern in der
Umsetzungsphase entstehen weitere Regelungen fr smtliche oder fr
spezielle Arbeitspltze. Es werden Verhaltensregen oder Handlungsanlei-
tungen formuliert, die jedem Mitarbeiter als Basis fr seine Handlungen oder
Unterlassungen am Arbeitsplatz zur Verfgung stehen mssen. Es ist daher
Aufgabe der Organisation, diese Regelungen zusammenzutragen und in
geeigneter Form der jeweiligen Zielgruppe an die Hand zu geben. Whrend
die Dokumentation des IT-Sicherheitsprozesses ein wesentliches Arbeitsmittel
fr das IT-Sicherheitsmangement-Team ist, dient das Handbuch der IT-
Sicherheitsorganisation als Leitfaden fr alle vom IT-Sicherheitsprozess
betroffenen Mitarbeiter. In der Praxis werden Teile dieser Handreichung unter
Bezeichnungen wie "PC-Richtlinie" oder "IT-Benutzerrichtlinie" verwendet.
Es gilt, fr die verschiedenen Zielgruppen innerhalb der Organisiation zu
unterschiedlichen Regelungen zu kommen, die sich an den gleichen Leitaus-
sagen orientieren, daneben aber auch speziell auf Rechte und Pflichten aus der
jeweiligen Funktion eingehen. So entstehen Regelwerke, in denen Aufgaben
und Verantwortlichkeiten fr unterschiedliche Zielgruppen zu beschreiben
sind. Solche Regelwerke knnten zusammen mit bergeordneten Kapiteln in
einem Handbuch der IT-Sicherheitsorganisation wie nachstehend gegeliedert
werden:
Handbuch der IT-Sicherheitsorganisation

Kapitel 1 IT-Sicherheitsleitlinie der Organisation
Kapitel 2 Abgeleitete IT-Sicherheitsleitlinien
2.1 IT-Systeme
2.2 IT-Anwendungen
Kapitel 3 IT-Sicherheitsmanagement
3.1 Aufbauorganisation
3.2 IT-Sicherheitsspezifische Aufgaben
3.3 Zustndigkeiten fr die Erfllung von
Sicherheitsanforderungen
3.4 Ablauforganisation fr den ordnungsgemen und
sicheren IT-Einsatz
3.5 Strategische Elemente des IT-Sicherheitsmanagements
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kapitel 4 Richtlinien zur IT-Sicherheit

4.1 Richtlinien fr IT-Nutzer
4.2 Richtlinien fr IT-Administratoren
4.3 Richtlinien fr Fachverantwortliche
4.n Regelungen fr sonstige Verantwortlichkeiten

Anhnge
IT-Arbeits- A.1 Dienstanweisung fr den sicheren IT-Einsatz
platz A.2 Handhabung von Sicherheitseinrichtungen
Betreiber B.1 Dienstanweisungen fr

Systembetreiber/Administratoren
B.2 Handhabung von Sicherheitseinrichtungen
- Sind die Leitaussagen und Regelungen zur IT-Sicherheit dokumentiert?
- Stehen diese Dokumente allen betroffenen Mitarbeitern zur Verfgung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.203 Aufbau einer Informationsbrse zur IT-

Sicherheit
Verantwortlich fr Umsetzung: Leiter Organisation, IT-
Verfahrensverantwortlicher
Mit dem breiten IT-Einsatz unterliegen traditionelle Arbeitsablufe einem
Wandel, der neben einer Anpassung von Organisationsstrukturen auch eine
Vernderung von Qualifikationen und Kompetenzen der Mitarbeiter erfordert.
Es reicht daher nicht aus, alleine unter sachlichen Gesichtspunkten die
notwendigen Regelungen zusammenzutragen, sondern es muss mit
didaktischen Methoden zustzlich auf eine Vernderung von Qualifikationen
und Kompetenzen abgezielt werden. Dazu dienen einerseits Sensibilisierungs-
und Schulungsprogramme, andererseits sollten die Mglichkeiten der neuen
Technologien auch dazu genutzt werden, die notwendigen Informationen
kontextbezogen am Arbeitsplatz zur Verfgung zu stellen. Das BSI hat mit
dieser Zielsetzung einen "Info-Desk IT-Sicherheit" entwickelt, der allgemeine
Informationen, sicherheitspolitische Leitaussagen und spezifische Reglungen
unter einer graphischen Benutzeroberflche online fr das Intranet einer
Organisation bereitstellt.
Eine Demo-Version dieses "Info-Desks" finden Sie auf der CD-ROM zum
Handbuch (siehe Anhang: Hilfsmittel). Die Anwendung ist so ausgelegt, dass
sie an die Spezifika der Behrde oder des Unternehmens angepasst werden
kann. Das BSI bietet ber eine Lehrbriefreihe die Untersttzung bei der
Einrichtung an. Beginnend mit der Anpassung der Benutzeroberflche an das
organisationstypische Erscheinungsbild erfolgt ber einen Zyklus von 18
Monaten die Integration der organisationseigenen IT-Sicherheitsleitlinie und
der spezifischen IT-Sicherheitskonzepte in den Info-Desk. Der Versand der
Lehrbriefe sowie ein Erfahrungsaustausch finden per E-Mail statt.
Interessenten knnen ber schulung@bsi.de weitere Informationen erhalten.
- Ist eine Informationsbrse zur IT-Sicherheit im Intranet eingerichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.204 Verhinderung ungesicherter Netzzugnge

Jeder ungesicherte Zugang zu einem Netz stellt eine enorme Sicherheitslcke
dar. Daher muss jede Kommunikation in das interne Netz ausnahmslos ber
einen gesicherten Zugang gefhrt werden. Dies kann beispielsweise eine
Firewall sein (siehe Kapitel 7.3).
Es mssen Regelungen getroffen werden, dass keine weiteren externen
Verbindungen unter Umgehung der Firewall geschaffen werden drfen. Alle
Benutzer mssen darauf hingewiesen werden, welche Gefahren mit der
Schaffung "wilder" Zugnge, z. B. ber mitgebrachte Modems, verbunden
sind.
Smtliche externen Netzzugnge sollten zentral erfasst werden (siehe Dokumentation der
Netztzugnge
Kapitel 2.1). Weiterhin sollte durch Stichproben berprft werden, ob ber
Modems oder anderweitig zustzliche Netzzugnge geschaffen wurden. Dafr
knnen z. B. automatisiert vorgegebene Rufnummerbereiche getestet werden,
ob sich dort Datenbertragungseinrichtungen melden.
Die Datenbertragung sollte in allen Organisationen klar geregelt sein. Alle
Datenbertragungseinrichtungen sollten genehmigt sein und deren Nutzung
klaren Regelungen unterliegen. Dies betrifft nicht nur Router, Modems und
ISDN-Karten, sondern auch Infrarot- oder Funk-Schnittstellen.
Die Datenbertragung sollte in allen Organisationen klar geregelt sein. Insbe-
sondere sollten die folgenden Punkte festgelegt sein:
- Zustndigkeiten fr Installation, Wartung und Betreuung
- Festlegung des Benutzerkreises und der Nutzungsberechtigungen
- Vorgaben und Sicherheitsmanahmen fr die Benutzung
- Festlegung der mglichen Kommunikationspartner
- Nutzungszeiten
- Vertretungsregelung
- Protokollierung
- Sichere Konfiguration der Datenbertragungseinrichtungen
Beispiele hierfr finden sich in M 2.61 Regelung des Modem-Einsatzes oder
M 2.179 Regelungen fr den Faxserver-Einsatz.
- Sind alle externen Netzzugnge dokumentiert?
- Sind Regelungen fr die Nutzung von Datenbertragungseinrichtungen
festgelegt worden?
- Werden die Regelungen fr die Nutzung von Datenbertragungseinrich-
tungen regelmig an das Einsatzumfeld und die technische Entwicklung
angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.205 bertragung und Abruf personenbezogener

Daten
Verantwortlich fr Umsetzung: Leiter IT, Datenschutzbeauftragter
Erfolgt eine bertragung personenbezogener Daten vom Standort des Arbeit-
bzw. Auftraggebers zu einem "entfernten" Arbeitsplatz (z. B. eines
Telearbeiters), so mssen die datenschutzrechtlichen Bestimmungen
Beachtung finden. Gem 9 BDSG muss in solchen Fllen insbesondere
verhindert werden, dass Unbefugte mit Hilfe von Einrichtungen zur
Datenbertragung IT-Systeme nutzen (Benutzerkontrolle). Weiterhin ist zu
gewhrleisten, dass berprft und festgestellt werden kann, an welche Stellen
personenbezogene Daten durch Einrichtungen zur Datenbertragung
bermittelt werden knnen (bermittlungskontrolle).
Der Transportweg bzw. die bertragungsmethode sollten so gewhlt sein,
dass sowohl die Vertraulichkeit und Integritt als auch die Authentizitt
(Herkunftsnachweis) der personenbezogenen Daten gewhrleistet werden
kann.
Erfolgt die bertragung personenbezogener Daten im Rahmen eines
automatisierten Abrufverfahrens, sind die besonderen Zulssigkeits-
voraussetzungen in den einschlgigen Gesetzen zu beachten:
Allgemeine Aspekte
- Anlass und Zweck sowie beteiligte Stellen am Abrufverfahren sind
festzulegen.
- Abrufberechtigungen sind festzulegen und zu kontrollieren.
- Art und Umfang der bereitgehaltenen Daten sind festzulegen.
- Sperr- und Lschfristen fr Daten sind zu definieren.
- Es ist festzulegen, in welchen Fllen die speichernde Stelle von der
abrufenden Stelle zu informieren ist.
- Der Transportweg ist festzulegen, z. B. Zugriff ber ISDN-Whlleitung,
gesichert ber Callback basierend auf CLIP bzw. COLP (siehe M 5.49).
- Es sollten geeignete kryptographische Verfahren (z. B. symmetrische und
asymmetrische Verschlsselung, digitale Signatur) eingesetzt werden, um
Verletzungen des Datenschutzes beim Transport schutzwrdiger Daten zu
verhindern. Wie entsprechende Verfahren und Produkte ausgewhlt
werden knnen, ist in Kapitel 3.7 Kryptokonzept beschrieben.
- Werden ber einen Transportweg regelmig oder dauerhaft
personenbezogene Daten ausgetauscht, sollte die bertragung mit Hilfe eines
virtuellen privaten Netzes (VPN) gesichert werden (siehe M 5.76 Einsatz
geeigneter Tunnel-Protokolle fr die RAS-Kommunikation und M 5.83 Sichere
Anbindung eines externen Netzes mit Linux FreeS/WAN
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Manahmen gegen unbefugten Abruf

Der Abruf von Daten durch nicht Abrufberechtigte ist durch geeignete
Vorkehrungen zu verhindern:
- Jeder Benutzer muss sich gegenber den IT-Systemen, von denen die
personenbezogenen Daten abgerufen werden, eindeutig identifizieren und
authentisieren.
- Nach einer festgelegten Anzahl von Fehlversuchen ist die Berechtigung zu
sperren.
- Passwrter mssen in regelmigen Abstnden gewechselt werden. Soweit
mglich, ist dies durch die entsprechenden Programme zu erzwingen.
- Zur berprfung der Protokolldateien sollten programmgesteuerte
Prfungsverfahren eingesetzt werden.
- Art und Umfang der Protokollierung mssen festgelegt werden (siehe auch
M 2.110 Datenschutzaspekte bei der Protokollierung).
- Es sollten zufallsgesteuerte Stichprobenkontrollen oder eine
Dauerprotokollierung durchgefhrt werden.
- Es ist festzulegen, an welcher Stelle die Protokollierungen durchgefhrt
werden (abrufende und/oder speichernde Stelle).
- Die Protokollierung muss so konzipiert sein, dass nachtrglich festgestellt
werden kann, aufgrund wessen Abrufberechtigung Daten abgerufen
wurden.
- Die Grnde des Abrufs mssen protokolliert werden.
- Beim Abruf von Daten sollte protokolliert werden, ber welchen Anschluss
und welche Endgerte die bertragung stattfindet.
Manahmen zur Organisationskontrolle
- Alle Mitarbeiter, insbesondere die der abrufenden Stelle, sind auf das
Datengeheimnis zu verpflichten. Eine Weitergabe von Daten an Dritte ist
vertraglich zu untersagen.
- Wurden die umgesetzten technischen und organisatorischen Manahmen
dokumentiert?
- Liegt ein Konzept zur berprfung und Feststellung der Zulssigkeit der
im Rahmen automatisierter Abrufe erfolgten Datenbertragungen vor?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.206 Planung des Einsatzes von Lotus Notes

Vor der Einfhrung von Lotus Notes muss entschieden werden, fr welche
Einsatzzwecke Lotus Notes genutzt werden soll. Die Nutzungsart hat zum
einen Einfluss auf die zu beschaffende Software (z. B. Domino Application
Server oder Domino Mail Server), die festzulegenden Sicherheitsrichtlinien
und auch auf die Art und den Umfang der Planungen fr die Einsatzszenarien.
Generell kann grob zwischen drei verschiedenen Varianten unterschieden
werden:
1. Einsatz als Intranetserver und Zugriff ber Notes-Clients
In diesem Szenario liegt der Hauptaugenmerk auf dem Einsatz als internes
System zur Brokommunikation (Datenverwaltung, E-Mail, Termin-
vereinbarung, Koordination von Gruppenarbeit).
2. Einsatz als Intranetserver und Zugriff ber Browser
In diesem Szenario liegt der Hauptaugenmerk auf dem Web-Zugriff auf
einen Notes-Server. Da an der Web-Schnittstelle des Notes-Servers gnz-
lich andere Sicherheitsmechanismen als in Variante 1 genutzt werden, wird
die sichere Konfiguration dieser Schnittstelle als eigenes Szenario
betrachtet.
3. Einsatz als Internet-Server und Zugriff ber Browser
Neben dem primren Einsatz eines Notes-Servers als Intranet-Server kann
auch die Nutzung als ffentlich zugreifbarer Informations-Server ber das
Internet gewnscht sein. Diese Nutzungsart erfordert aufgrund der expo-
nierten Stellung eines solchen Servers besondere Aufmerksamkeit bei der
Systemkonfiguration. Insbesondere muss hierbei der Notes-Server in einer
DeMilitarisierten Zone (DMZ) aufgestellt sein, also in einem durch Fire-
walls gegen unbefugte Zugriffe von innen und auen geschtztem Bereich
(siehe auch M 2.211 Planung des Einsatzes von Lotus Notes in einer
DMZ).
Innerhalb der Einzelszenarien kann weiter dahingehend unterschieden werden, Welche Funktionen
sollen genutzt werden
welche Notes-Funktionen genutzt werden sollen (z. B. Datenbankzugriff,
Notes-Mail, Internet-Mail, LDAP-Server, HTML-Server). Eine
Unterscheidung auf dieser Ebene soll hier nicht erfolgen. Grundstzlich gilt
jedoch, dass fr die Nutzung jeder Funktionalitt eine eigene Planung erfor-
derlich ist, bei der auch Sicherheitsgesichtspunkte zu bercksichtigen sind.
Fr einige der genannten Funktionen existieren auch eigene Bausteine im IT-
Grundschutzhandbuch, die bei deren Nutzung beachtet werden sollten, z. B.
Kapitel 7.4 E-Mail und 7.5 WWW-Server.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Grundstzlich mssen bei der Einsatzplanung folgende Aspekte betrachtet

werden:
- Lotus Notes baut einen eigenen Namensraum auf, der die Aufteilung in Domnen- und
Zertifikatsstruktur
sogenannte Notes-Domnen ermglicht. Damit dieser effizient genutzt planen
werden kann, muss eine Planung der Domnen erfolgen. Daneben wird
durch die Notes-Zertifikate eine hierarchische Zertifikatsstruktur aufge-
baut, die unabhngig von der Domnenaufteilung ist und daher eine eigene
Planung erfordert. Die dabei zu bercksichtigenden Aspekte sind in der
Manahme M 2.208 Planung der Domnen und der Zertifikatshierarchie
von Lotus Notes beschrieben.
- Begleitend zur Planung des Namensraumes von Lotus Notes und des Sicherheitsrichtlinien
festlegen
gewnschten Einsatzszenarios ist eine Notes-spezifische Sicherheits-
richtlinie zu entwerfen. Die dabei zu bercksichtigenden Aspekte sind in
der Manahme M 2.207 Festlegen einer Sicherheitsrichtlinie fr Lotus
Notes zusammengefasst.
- Die Detailplanung fr das gewnschte Einsatzszenario ist durchzufhren.
Fr jedes Szenario sind die relevanten Empfehlungen in den folgenden
Manahmen erfasst:
- M 2.209 Planung des Einsatzes von Lotus Notes im Intranet
- M 2.210 Planung des Einsatzes von Lotus Notes im Intranet mit
Browser-Zugriff
- M 2.211 Planung des Einsatzes von Lotus Notes in einer DMZ
Die Planung des Notes Systems darf nur dann als abgeschlossen betrachtet Roll-out planen
werden, wenn auch das sogenannte "Roll-out" im Detail geplant worden
ist. Durch die Roll-out-Planung wird die Installationsreihenfolge der
einzelnen Notes-Server und aller Notes-Clients festgelegt. Insbesondere
das Roll-out der Zertifizierungsstellen muss genau geplant werden, um die
Zertifizierungshierarchie korrekt nutzen zu knnen.
Die bei der Planung getroffenen richtungsweisenden Entscheidungen sollten Entscheidungen
dokumentieren
dokumentiert werden, damit spter berprft werden kann, ob diese vollstn-
dig umgesetzt worden sind. Insbesondere sollten sie so aufgeschrieben
werden, dass die Grnde fr diese Entscheidungen nachvollziehbar sind.
- Wurde eine Anforderungsanalyse fr den Einsatz von Lotus Notes durch-
gefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.207 Festlegen einer Sicherheitsrichtlinie fr Lotus

Notes
Wie fr jedes in einem Unternehmen eingesetzte Software-Produkt muss auch
fr den Einsatz von Lotus Domino Servern eine geeignete Sicherheitsrichtlinie
festgelegt werden. Lotus Domino kann als eigenes Netzkommuni-
kationssystem angesehen werden, welches das darunter liegende Betriebs-
system lediglich als Ablaufumgebung nutzt und auf administrativer Ebene
ber eigenstndige Mechanismen verfgt. Daher ist fr das Festlegen einer
Sicherheitsrichtlinie ein hnlich umfangreiches Themenspektrum zu beden-
ken, wie fr ein Netzbetriebssystem.
Im Rahmen der Sicherheitsrichtlinie sind folgende Aspekte zu bercksich-
tigen:
- Die Sicherheitsrichtlinie fr Lotus Notes muss konform zu den geltenden
generellen Sicherheitsrichtlinien der Behrde bzw. des Unternehmens sein
(siehe M 2.192 Erstellung einer IT-Sicherheitsleitlinie).
- Es mssen Zugriffsregeln festgelegt werden, Zugriffsregeln
- welcher Benutzer auf welchen Server zugreifen darf und welche

Benutzer auf welche Server nicht zugreifen sollen (Ausschlussliste),
- welcher Benutzer mit welchen Rechten auf welche Datenbank
zugreifen darf,
- welche Datenbank von welchem Server aus administriert wird,
- welche anderen Server auf einen Server zugreifen drfen,
- wie Datenbanken repliziert werden,
- welche Datenbankbestandteile (Datenstze, Ansichten, Scripten
usw.) repliziert werden,
- von wo aus auf einen Notes-Server zugegriffen werden darf.
- Auerdem muss festgelegt werden,
- wie Notes-ID-Dateien zu behandeln sind, beispielsweise in Bezug Notes-ID-Dateien
auf Erzeugung, Verteilung, Speicherung und Vier-Augen-Prinzip
(siehe dazu auch Manahme M 4.129 Sicherer Umgang mit Notes-
ID-Dateien),
- ob und unter welchen Bedingungen das Wiederherstellen von Pass-
wrtern fr Notes-ID-Dateien bzw. ganzer Notes-ID-Dateien erfolgt,
- ob eine Kommunikationsabsicherung (z. B. fr Netzkommunikation, Verschlsselung und
Signatur
E-Mail-Kommunikation) eingesetzt werden soll, welcher Mecha-
nismus genutzt wird und welche Kommunikationsverbindungen
geschtzt werden sollen.
- Es muss ein Auditing- und Protokollierungskonzept entworfen werden. Es Audit und
Protokollierung
ist darauf zu achten, dass der Datenschutzbeauftragte in die Planung mit
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
einbezogen wird, da im Rahmen der berwachung auch personenbezogene

Daten anfallen knnen.
- Die Planung der Notes Domnen muss erfolgen, die Zugriffsberech-
tigungen zwischen den Domnen mssen festgelegt werden
(benutzerorientiert und serverorientiert) und es muss eine Planung der
Replikation von Datenbanken erfolgen.
- Fr jedes aktivierte Funktionsmodul des Domino Applikation Servers ist
eine Sicherheitsplanung erforderlich. Es mssen u. a. Zugriffsbe-
schrnkungen, Zugriffsarten, zu benutzende Authentisierungsmechanismen
und Reaktionen auf Sicherheitsverste festgelegt werden.
Die Sicherheitsrichtlinie fr die Nutzung von Lotus Notes muss organi- Alle Benutzer mssen
die Vorgaben kennen.
sationsweit abgestimmt sein und allen Benutzern bekannt gegeben worden
sein. Hierbei empfiehlt es sich, fr die Endbenutzern die wichtigsten Inhalte in
einer kurzen und prgnanten Form aufzubereiten, z. B. in Form eines Falt-
blattes oder einer Webseite. Wenn sich Sicherheitsvorgaben verndern,
mssen alle Benutzer hierber informiert werden.
Im Rahmen von bestehenden Sicherheitsrichtlinien kann die Situation ent-
stehen, dass bestimmte Sicherheitsanforderungen mit den Mechanismen von
Lotus Notes nicht realisiert werden knnen. In diesem Fall muss entschieden
werden, ob die bestehenden Sicherheitsrichtlinien angepasst werden oder ob
das Einsatzszenario von Lotus Notes so stark eingeschrnkt wird, dass die
Richtlinien umgesetzt werden knnen.
- Existiert eine aktuelle Sicherheitsrichtlinie fr die Nutzung von Lotus
Notes?
- Knnen alle relevanten Sicherheitsvorschriften der organisationsweiten
Sicherheitsrichtlinie auf Lotus Notes abgebildet werden?
- Werden alle Benutzer ber neue oder vernderte Sicherheitsvorschriften
informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.208 Planung der Domnen und der Zertifikats-

hierarchie von Lotus Notes
Ein Notes-System besteht aus einem oder mehreren Lotus Notes Servern und
vielen Notes- und/oder Web-Clients. Die einzelnen Server eines Notes-
Systems knnen einzelnen Notes-Domnen zugeordnet werden. Domnen
legen - hnlich wie in anderen Netz-Betriebssystemen - die administrativen
Grenzen und die Gltigkeit von Sicherheitseinstellungen (z. B. Zugriffskon-
trollen) fest. Zustzlich wird durch jede Domne ein eigener Namensraum
aufgespannt. Der Planung der Notes-Domnen und dem durch sie definierten
Namensraum kommt daher eine wichtige Bedeutung zu.
Eine Domne korrespondiert mit einem Notes-Verzeichnis und kann in grober Domnen an
Organisationsstruktur
Vereinfachung als Mittel zur E-Mail-Verteilung angesehen werden. Der anpassen
Namensraum einer Domne kann hierarchisch in sogenannten Organisations-
einheiten strukturiert sein, so dass Benutzer, Gruppen und Server, die in einer
Domne zusammengefasst sind, weiter unterteilt werden knnen. Die Auftei-
lung einer Domne muss an die Anforderungen der Behrde bzw. des Unter-
nehmens angepasst werden. Es empfiehlt sich jedoch eine Aufteilung, die die
Organisationsstruktur widerspiegelt.
Die E-Mail-Kommunikation kann unter Lotus Notes durch den Einsatz von
Verschlsselung und digitalen Signaturen abgesichert werden (siehe M 5.85
Einsatz von Verschlsselungsverfahren fr Lotus Notes E-Mail). Fr die
Verteilung der kryptographischen Schlssel sollte eine Zertifikatshierarchie
(Public Key Infrastruktur - PKI) aufgebaut werden, die unabhngig von der
Domnenplanung sein kann. Dies hat zur Folge, dass in einer Notes-Domne
mehrere unabhngige Zertifikatshierarchien existieren knnen oder eine
Zertifikatshierarchie mehrere Domnen umfasst.
Bei der Planung von Domnen ist zu berlegen, ob ein Ein- oder Mehr-
Domnen-Konzept konzipiert werden soll.
Ein Ein-Domnen-Konzept besitzt folgende Vorteile: Ein-Domnen-Konzept
- Die E-Mail-Adressen aller Benutzer besitzen die gleiche Domnenkennung

(Benutzer@Domne). Eine Kenntnis der Notes-Domnenzugehrigkeit bei
der Nutzung mehrerer Domnen in einem Unternehmen ist fr den Sender
nicht notwendig.
- Die Administration vereinfacht sich wesentlich, da nur ein Namens- und
Adressbuch (NAB) gepflegt werden muss. Werden mehrere Domnen
benutzt, so sind im NAB zustzlich z. B. die Verbindungs-Eintrge und
Domnen-Definitionen enthalten, die die Schnittstellen der jeweiligen
Domne mit den anderen Domnen festlegen. Diese mssen fr jede
Domne einzeln gepflegt werden. Beim Ein-Domnen-Konzept fllt diese
Arbeit nicht an.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ein Mehr-Domnen-Konzept besitzt folgende Vorteile: Mehr-Domnen-Konzept

- Groe Benutzermengen lassen sich besser in mehreren Domnen verwal-
ten, da mit zunehmender Gre des NAB die Performance sinkt und auch
die Verwaltung unbersichtlicher wird. Wird das NAB zustzlich auf
Clients repliziert (z. B. fr mobile Benutzer) kann dies bei entsprechender
Gre durch den zunehmenden Bedarf an Speicherplatz bzw. der
wachsenden Replikationszeit, insbesondere bei langsamen Verbindungen,
problematisch werden. Das Aufbrechen in mehrere Domnen und damit
mehrere NABs besitzt daher Vorteile und bietet auch einen gewissen
Ausfallschutz.
- Vielfach sind Organisationsstrukturen nicht homogen und lassen sich daher
schlecht auf genau eine Notes-Domne abbilden. Insbesondere ist vielfach
auch die administrative Trennung einzelner Bereiche sinnvoll oder
zwingend erforderlich, z. B. wenn unterschiedliche Sicherheitsvorschriften
umzusetzen sind oder lnderspezifische Eigenschaften, wie Sprache oder
Zeichenstze, bercksichtigt werden mssen. Diese Trennung lsst sich nur
durch ein Mehr-Domnen-Konzept erreichen.
- Durch Zusammenlegung von Organisationseinheiten werden vorher
eigenstndige Notes-Domnen weitergefhrt, da eine Integration einen
hohen administrativen Aufwand bedeutet oder der etablierte Namensraum
weiter verwendet werden soll.
- Es knnen spezielle Domnen angelegt werden, die zur Isolation oder
Abgrenzung gegen andere Domnen genutzt werden knnen, beispiels-
weise Test-Domnen, Domnen fr Software-Entwicklung oder Domnen
mit Einwahl-Zugngen.
Bei der Planung des Domnenkonzeptes ist zu bedenken, dass eine nachtrg- Nachtrgliche
nderungen sind
liche Vernderung im Domnenmodell zwar generell mglich, jedoch in der aufwndig.
Regel mit hohem administrativen Aufwand verbunden ist, da u. a. alle von
einem Domnenwechsel betroffenen Server und Benutzer innerhalb der
Notes-Domnen umgesiedelt werden mssen. Dabei sind auch Rezertifizie-
rungen notwendig, sowie das Umstellen von Datenbank-ACLs.
Bei der Planung von Zertifikatshierarchien ist generell folgendes zu beachten: Zertifikatshierarchien
- Es muss zwischen Notes-Zertifikaten und den von Notes benutzten Inter-

net-Zertifikaten (X.509-Zertifikate) unterschieden werden. Es sind daher
u. U. zwei Zertifikatshierarchien parallel zu verwalten.
- Zur Zertifizierung von Notes-Benutzern (Notes-ID) knnen nur Notes-
Zertifikate und keine Internet-Zertifikate genutzt werden.
- Die Vergabe und Kontrolle von Zugriffsberechtigungen (auch zwischen
verschiedenen Domnen) bei Lotus Notes basiert auf den Notes-Zertifi-
katen.
- Zwischen verschiedenen Zertifikatshierarchien (ohne gemeinsame Zertifi-
zierungsinstanz) knnen Vertrauensstellungen eingetragen werden, indem
eine sogenannte Cross-Zertifizierung erfolgt (Anerkennen fremder Zertifi-
kate). Die leichtfertige Vergabe von Cross-Zertifikaten (meist knnen diese
automatisch erzeugt werden, wenn ein unbekanntes Zertifikat
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
"entdeckt" wird) vermindert die Systemsicherheit. Dies gilt sowohl fr

Notes-Zertifikate, als auch fr X.509-Zertifikate. Dabei knnen Cross-
Zertifikate auch von Benutzern einfach im persnlichen lokalen
Adressbuch erzeugt werden. Das Anlegen von Cross-Zertifikaten im NAB
kann dagegen nur durch einen berechtigten Administrator erfolgen.
- Zur Identifizierung von Benutzern bei Zugriffen ber die Web-Schnittstelle
von Lotus Notes knnen nur Internet-Zertifikate benutzt werden.
- Notes Zertifikatsstrukturen knnen flach oder hierarchisch sein. In einer
flachen Zertifikatsstruktur gibt es eine Zertifizierungsstelle, die die Zertifi-
kate fr alle Benutzer ausstellt. In einer hierarchischen Zertifikatsstruktur
gibt es verschiedene Zertifizierungsstellen, wobei die Zertifikate der
einzelnen Zertifizierungsstellen von einer bergeordneten Zertifizierungs-
instanz signiert werden.
Flache Zertifikatsstrukturen sind einfacher zu administrieren, hierarchische
Strukturen besitzen allerdings den Vorteil, dass eine Delegation der
Administration mglich ist (so knnen z. B. Abteilungen neue Benutzer
selbst zertifizieren). Dies ermglicht es auch einzelnen Organisations-
einheiten, eigene Zertifikate auszustellen und zu verwalten.
- Die Zertifikatshierarchie ist zu planen. Es muss u. a. festgelegt werden,
welche Zertifikate ausgestellt werden, wer zertifizieren darf und was zerti-
fiziert werden darf. Die Zustndigkeiten und Verantwortlichkeiten mssen
geplant werden.
Das Aufsetzen einer Zertifikatshierarchie stellt in der Regel weniger ein grndliche Abstimmung
mit allen beteiligten
technisches als ein organisatorisches und politisches Problem dar. Eine Stellen
entsprechend lange Planungsphase, in die alle beteiligten Stellen (technisch
und organisatorisch) eingebunden sind und an deren Ende ein von allen
Beteiligten verabschiedetes Konzept vorliegt, sollte daher vorgesehen werden.
- Ist die Domnenplanung dokumentiert?
- Wird bereits eine Zertifikatsinfrastruktur (PKI) betrieben?
- Kann oder muss die PKI zur Ausstellung von X.509-Zertifikaten benutzt
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.209 Planung des Einsatzes von Lotus Notes im

Intranet
Lotus Domino ist hauptschlich fr den Einsatz im Intranet konzipiert, was
durch die Integration von Internet-Technologien weiter untersttzt wird. Soll
ein Notes-System eingesetzt werden, so ist ein Betriebskonzept zu entwerfen.
Ohne festgelegtes Konzept kann in der Regel keine IT-Sicherheit gewhr-
leistet werden. Bei der Planung eines Notes-Systems ist folgendes aus Sicher-
heitssicht zu beachten:
- Die umzusetzenden Sicherheitsvorschriften mssen geplant werden (siehe
M 2.207 Festlegen einer Sicherheitsrichtlinie fr Lotus Notes).
- Die Domnenplanung und die Planung der Zertifikatshierarchie ist durch-
zufhren (siehe M 2.208 Planung der Domnen und der Zertifikats-
hierarchie von Lotus Notes).
- Die Standorte der Notes-Server ist festzulegen. Alle Notes-Server sollten in sichere Aufstellung der
Server
Serverrumen aufgestellt werden. Hierbei zu realisierende Manahmen
sind in Kapitel 4.3.2 beschrieben. Wenn kein Serverraum zur Verfgung
steht, kann ein Notes-Server alternativ in einem Serverschrank aufgestellt
werden (vgl. Kapitel 4.4 Schutzschrnke).
- Neben den Notes-spezifischen Sicherheitsmanahmen sind sind fr die
Server die relevanten Bausteine aus dem Kapitel 6 umzusetzen.
- Die Verteilung von Datenbanken auf Server ist zu planen. Dabei muss auch
die Lastverteilung bercksichtigt werden. Ausgangspunkt ist dabei die
Frage, welche Clients auf welchen Server zugreifen.
- Fr die Server sind die Zugangs- und Zugriffsbeschrnkungen zu planen. Rechtekonzept fr
Server
Dabei sollten nur die Rechte vergeben werden, die auch wirklich bentigt
werden.
- Fr die Datenbanken eines Servers ist die Zugriffskontrolle zu planen:
Welche Benutzer (oder Benutzergruppen) sollen mit welchen Rechten auf
Datenbanken zugreifen?
- Es sollte ein Notes-spezifisches Gruppenkonzept entworfen werden, so
dass die Zugriffskontrolle gruppenbasiert konzipiert werden kann.
- Ein einzelner Notes-Server integriert sich durch die zur Verfgung stehen-
den Funktionsmodule in viele Anwendungen (z. B. E-Mail, News, Web)
und kann dadurch eine zentrale Rolle in jedem System spielen. Dies macht
einen Notes-Server jedoch auch zu einer kritischen Ressource. Fllt ein
solcher Server aus, so sind u. U. alle diese Anwendungen teilweise oder
ganz funktionsunfhig. Es sollte daher berlegt werden, verschiedenen
Notes-Servern dedizierte Rollen zuzuweisen.
- Fr jeden Server ist festzulegen, welche Funktionsmodule aktiviert werden. nicht bentigte Module
deaktivieren
Nicht bentigte Module sind zu deaktivieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Jedes Funktionsmodul erfordert eine eigene Planung, die die Einbindung in

das lokale Netz bercksichtigt (z. B. E-Mail-System mit Domino Mail
Servern, Notes-Server als LDAP-Server oder LDAP-Client, gemischtes
News-System mit Notes-NNTP-Servern und Unix-NNTP-Servern).
Die Sicherheit des Notes-Systems hngt von vielen Faktoren ab, die wich-
tigsten sind jedoch:
- Die Sicherheit jedes Notes-Servers.
- Die Sicherheit jedes Notes-Clients.
- Die Sicherheit jeder Kommunikationsverbindung zwischen Notes-Servern
und Clients.
Detaillierte Manahmen zu Absicherung dieser Hauptkomponenten finden
sich in den Notes-spezifischen Manahmen der Manahmenkataloge 4
"Hardware/Software" und 5 "Kommunikation".
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.210 Planung des Einsatzes von Lotus Notes im

Intranet mit Browser-Zugriff
Soll auf einen Notes-Server im Intranet auch ber einen Browser zugegriffen
werden, so ist eine Planung insbesondere unter Sicherheitsgesichtspunkten
notwendig.
Die Web-Schnittstelle bietet im Vergleich zum Zugriff mittels Notes-Client in
der Regel weniger Funktionalitten. Insbesondere ist zu beachten, dass an der
Web-Schnittstelle im Vergleich zum Zugriff mittels Notes-Client gnzlich
andere Sicherheitsmechanismen fr die Authentisierung zum Einsatz
kommen. Auch die Datensicherheit auf Datenbankebene wird hier nur einge-
schrnkt untersttzt. Die Ent- bzw. Verschlsselung von Dokumentenfeldern
an der Web-Schnittstelle wird zur Zeit nicht angeboten. Eine weitere Ein-
schrnkung ist die fehlende Mglichkeit, Datenbanken lokal auf Clients zu
replizieren, um eine Offline-Verarbeitung zu ermglichen.
Da der Browser-Zugriff verschiedene Einschrnkungen der IT-Sicherheit mit
sich bringt, ist dieser nicht zu empfehlen. Daher sollte er mglichst restriktiv
gehandhabt werden, also nur ermglicht werden, wenn dies unbedingt
erforderlich ist.
Soll trotz der zustzlichen Sicherheitsprobleme der Browser-Zugriff
ermglicht werden, mssen fr die Planung die nachstehend aufgefhrten
Fragestellungen bercksichtigt werden:
- Welche Benutzer sollen ber die Web-Schnittstelle auf welche Server
zugreifen drfen? Diese Entscheidung hat Einfluss auf die Konfiguration
des Datenbankzugriffs, die dann entsprechend angepasst werden muss
(siehe M 4.120 Konfiguration von Zugriffslisten auf Lotus Notes Daten-
banken und M 4.125 Einrichten von Zugriffsbeschrnkungen beim
Browser-Zugriff auf Lotus Notes Datenbanken).
- Soll ausschlielich ber die Web-Schnittstelle auf Lotus Notes zugegriffen
werden? Ist dies der Fall, mssen gewisse Einschrnkungen, z. B. in Bezug
auf Verschlsselungsmechanismen, in Kauf genommen werden, da nicht
alle Funktionen und Sicherheitsmechanismen an der Webschnittstelle
verfgbar sind. Es ist daher zu entscheiden, ob diese Einschrnkungen in
Kauf genommen werden knnen.
- Knnen alle notwendigen Datenbanken ber die Web-Schnittstelle genutzt
werden? Datenbanken, die Funktionen ber clientseitiges LotusScript und
Agenten anbieten, verlieren diese Funktionalitt beim Web-Zugriff, da
LotusScript nicht durch Browser untersttzt wird. Aus diesem Grund muss
berprft werden, ob solche Datenbanken genutzt werden.
- Auf welche Daten soll ber die Web-Schnittstelle zugegriffen werden? Es
kann grob zwischen ffentlichen Daten, internen Daten, z. B. Kunden-
daten, Projektdaten, Personaldaten, und den Brodaten der Mitarbeiter,
z. B. Terminkalender, E-Mail, Todo-Listen, unterschieden werden. Eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
weitere Unterteilung, z. B. nach einer Schutzbedarfsfeststellung gem

Kapitel 2.2, ist sinnvoll. Nur Daten ohne besonderen Schutzbedarf sollten
fr den Zugriff ber die Web-Schnittstelle freigegeben werden.
- Knnen die Daten, auf die ber die Web-Schnittstelle zugegriffen werden
soll, auf dedizierten Servern gehalten werden? Dies erleichtert die Konfi-
guration von Servern, da kein Mischzugriff (Notes-Client und Browser)
erfolgt. Die Daten sollten daher mglichst getrennt gehalten werden.
- Welche Datenbanken sollen ber die Web-Schnittstelle zugreifbar sein?
Fr solche Datenbanken mssen spezielle Sicherheitseinstellungen vorge-
nommen werden (siehe M 4.120 Konfiguration von Zugriffslisten auf Lotus
Notes Datenbanken, M 4.125 Einrichten von Zugriffsbeschrnkungen beim
- Mssen die Daten beim Transport ber die Web-Schnittstelle geschtzt
werden? In diesem Fall muss die Kommunikation abgesichert werden
(siehe M 5.86 Einsatz von Verschlsselungsverfahren beim Browser-
Zugriff auf Lotus Notes). Der ungeschtzte Transport von Daten sollte
grundstzlich vermieden werden. Nur bei Daten, auf die anonym zuge-
griffen werden darf, kann auf Verschlsselung verzichtet werden.
- Ist der anonyme Zugriff ber die Web-Schnittstelle notwendig? In diesem
Fall muss der jeweilige Server und die betroffenen Datenbanken entspre-
chend angepasst werden (siehe M 4.119 Einrichten von Zugangsbe-
schrnkungen auf Lotus Notes Server, M 4.120 Konfiguration von
Zugriffslisten auf Lotus Notes Datenbanken, M 4.124 Konfiguration der
Authentisierungsmechanismen beim Browser-Zugriff auf Lotus Notes).
ffentliche Daten, auf die anonym zugegriffen werden soll, sollten
mglichst auf einem speziellen Server vorgehalten werden. Anonyme
Zugriffe auf alle anderen Server sind dann zu deaktivieren.
- Soll der Zugriff auf Datenbanken ber die Web-Schnittstelle mit einge-
schrnkten Rechten erfolgen? Dies ist auf Grund der eingeschrnkten
Sicherheitsfunktionalitt dringend zu empfehlen. In diesem Fall ist aller-
dings auf Grund der damit einhergehenden Funktionseinbue in der Regel
keine ausschlieliche Nutzung der Web-Schnittstelle mglich. Die Daten-
banken mssen entsprechend konfiguriert werden (siehe M 4.125 Einrich-
ten von Zugriffsbeschrnkungen beim Browser-Zugriff auf Lotus Notes
Datenbanken).
- Soll eine eigene Zertifizierungsstelle (CA) zum Ausstellen von Internet-
zertifikaten betrieben werden? Hierzu mssen das Aufsetzen einer eigenen
Zertifizierungsstelle (z. B. einer Notes-CA) und die Zertifikatshierarchien
geplant werden. Zustzlich muss fr die Verteilung der Zertifikate an
Server und Benutzer gesorgt werden.
- Kann die Sicherheit der Computer, die als Client fungieren, gewhrleistet
werden? Das Sicherheitsniveau dieser Computer hat Einfluss auf die
benutzten Authentisierungsverfahren an der Web-Schnittstelle (siehe
M 4.124 Konfiguration der Authentisierungsmechanismen beim Browser-
Zugriff auf Lotus Notes).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welcher Browser wird fr den Web-Zugriff genutzt? Auch die Sicher-

heitsmechanismen des Browsers haben Einfluss auf die benutzten Authen-
tisierungsverfahren an der Web-Schnittstelle (siehe M 4.124 Konfiguration
der Authentisierungsmechanismen beim Browser-Zugriff auf Lotus Notes,
M 4.127 Sichere Browser-Konfiguration fr den Zugriff auf Lotus Notes).
- Sollen Server ber die Web-Schnittstelle administriert werden? Die
Administration ber die Web-Schnittstelle sollte nur nach einer gewissen-
haften Risikoabwgung erfolgen. Der administrative Zugriff muss alle
Sicherheitsmechanismen nutzen (siehe M 4.123 Einrichten des SSL-
geschtzten Browser-Zugriffs auf Lotus Notes, M 4.125 Einrichten von
Zugriffsbeschrnkungen beim Browser-Zugriff auf Lotus Notes Daten-
banken).
- Sollen Benutzer auf ihre E-Mail-Datenbanken ber die Web-Schnittstelle
zugreifen drfen? Dies erfordert eine entsprechende Konfiguration der
Zugriffsmechanismen der einzelnen E-Mail-Datenbanken (siehe M 4.123
Einrichten des SSL-geschtzten Browser-Zugriffs auf Lotus Notes, M 4.125
Einrichten von Zugriffsbeschrnkungen beim Browser-Zugriff auf Lotus
Notes Datenbanken).
- Mssen E-Mails verschlsselt werden? In diesem Fall kann die Web-
Schnittstelle nicht als alleiniger Zugang zum Notes-Server verwendet
werden, wenn auch Notes-Verschlsselung benutzt werden muss. Auch die
S/MIME-Verschlsselung ist an der Web-Schnittstelle nicht verfgbar.
Daher mssen alle Benutzer einen S/MIME-fhigen E-Mail-Client
verwenden und mit einem "Internet-Zertifikat" ausgestattet sein, das mit
S/MIME benutzt werden kann (siehe M 5.85 Einsatz von Verschlsse-
lungsverfahren fr Lotus Notes E-Mail).
Je nach konkretem Einsatzszenario, sind weitere Fragestellungen beim Einsatz
von Lotus Notes im Intranet mit Browser-Zugriff zu beachten.
- Gibt es zwingende Grnde Browser-Zugriffe auf Notes-Server zuzulassen?
- Existiert eine Konzeption fr den Einsatz von Lotus Notes mit Browser-
Zugriffen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.211 Planung des Einsatzes von Lotus Notes in einer

DMZ
Die in den Datenbanken eines Notes-Servers gespeicherten Daten knnen
auch fr den ffentlichen Zugriff aus dem Internet bereitgestellt werden. Dies
stellt besondere Anforderungen an die Sicherheit des dazu benutzten Notes-
Servers.
Fr den direkten Zugriff auf einen Notes-Server aus dem Internet ist generell
folgendes zu beachten:
- Direkte Zugriffe aus dem Internet auf einen Notes-Server im lokalen Netz keine direkten Zugriffe
aus dem Internet ins
drfen nicht erfolgen. Alle internen Notes-Server sind vor direkten Zugrif- LAN zulassen
fen aus dem Internet mit einer Firewall zu schtzen (siehe auch
Baustein 7.4 Firewall).
- Notes-Server, auf die direkt aus dem Internet zugegriffen wird, mssen in aus dem Internet
erreichbare Notes-Server
einem separaten Netz (einer sogenannten DeMilitarisierten Zone, DMZ) in DMZ platzieren
angesiedelt sein. Der Zugriff auf den Server muss durch eine Firewall
abgesichert werden (siehe auch M 2.77 Sichere Anordnung weiterer
Komponenten).
Bei einer Anbindung an das Internet knnen auftretende Sicherheitsprobleme
gravierende Folgen haben (siehe G 5.100 "Hacking Lotus Notes"). Daher
sollte darauf verzichtet werden, Notes-Server fr Zugriff aus dem Internet zu
ffnen. Kommt trotzdem ein Notes-Server in der DMZ zum Einsatz, so muss
die Konfiguration der Sicherheitseinstellungen besonders sorgfltig erfolgen.
Dabei sind insbesondere die folgenden Punkte zu beachten:
- Es muss eine Sicherheitskonzeption fr die Anbindung von Notes-Servern Regelungen fr Internet-
Anbindung von Notes-
an das Internet erarbeitet werden, in dem u. a. die Sicherheitsziele und die Servern
grundlegenden Voraussetzungen festgelegt sind, die erforderliche Netz-
struktur beschrieben ist und alle organisatorischen Regelungen festgehalten
sind.
- Der Notes-Server sollte in einer separaten Notes-Domne angesiedelt
werden.
- Es sollte eine eigene Zertifizierung des Servers erfolgen, die keine
Berechtigungen im Intranet der Behrde bzw. des Unternehmens besitzt.
- Der Notes-Server in der DMZ darf nicht mit internen Notes-Servern repli-
zieren. Fr den Datentransfer knnen dateibasierte Mechanismen, z. B. ftp,
zum Einsatz kommen.
- Die Firewall-Konfiguration muss das Initiieren von Verbindungen vom
Notes-Server in das interne Netz unterbinden. Ist ein Datenaustausch
zwischen internen Systemen und dem Notes-Server in der DMZ notwen-
dig, so drfen Verbindungen nur von den internen Systemen initiiert
werden knnen. Auch hier sollte auf die Verwendung von Notes-Mecha-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nismen zum Datenaustausch verzichtet werden, um einen bewussten

Protokollbruch zu erzeugen.
- Datenbanken enthalten auch ausfhrbaren Programmcode, wie Agenten
und Skripten, die zur Kompromittierung des internen Netzes genutzt
werden knnen. Datenbanken, die vom Notes-Server in der DMZ in das
interne Netz zur Weiterverarbeitung transferiert werden, sollten daher einer
Sicherheitsberprfung unterzogen werden.
- Sollen nur HTML-Seiten (und keine Notes-Datenbanken) durch den Server Notes nicht als Ersatz fr
einen reinen WWW-
angeboten werden, so ist ein reines WWW-Server-Produkt zu verwenden. Server verwenden
Durch einen Notes-Server werden komplexe Funktionen und Mechanismen
angeboten, die sich nicht alle deaktivieren lassen und damit als mgliche
Angriffspunkte genutzt werden knnen. Beispielsweise ist immer eine
Verbindung ber das Notes-Protokoll mglich.
- Das Notes-System sollte ebenso wie andere existierende Systeme in der
DMZ berwacht werden.
Neben den hier aufgefhrten Aspekten knnen sich durch die Nutzung eines
Notes-Systems in exponierter Stellung weitere Probleme ergeben. Es wird
empfohlen, eine individuelle Risikoabwgung durchzufhren, die den Schutz-
bedarf der IT-Anwendungen und Informationen bercksichtigt.
- Gibt es zwingende Grnde Internet-Zugriffe auf Notes-Server zuzulassen?
- Ist das IT-Sicherheitsmanagement in diese Entscheidung einbezogen
worden?
- Existiert ein Sicherheitskonzept fr den Einsatz von Lotus Notes in der
DMZ?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.212 Organisatorische Vorgaben fr die

Gebudereinigung
Die Gebudereinigung erfordert im Normalfall den Zutritt von Betriebs-
fremden. Dies kann insbesondere in Bereichen mit hheren Sicherheitsan-
forderungen wie Rechenzentren, Serverrumen, Technikrumen oder
Kommunikationszentralen problematisch sein und daher zustzliche Sicher-
heitsmanahmen erfordern.
Bereits in der Ausschreibung und der Vertragsformulierung ist die Sonderbe-
handlung sensitiver Bereiche einzubeziehen. Zum Beispiel sind bei Rechen-
zentren stichprobenartige Kontrollen von Taschen oder Transportgut im Zu-
gangs- oder Zufahrtsbereich fr betriebsfremdes Personal in den Vertrgen
festzuschreiben.
Da bei Reinigungskrften IT-Kenntnisse nicht vorausgesetzt werden knnen, Reinigungspersonal
einweisen
sollten diese daher in allen Bereichen mit geschftskritischen IT-Systemen
dahingehend eingewiesen werden, welche Ttigkeiten zu Schden an IT-Ein-
richtungen oder Problemen beim IT-Betrieb fhren knnen. Beispiele fr
solche Problemfelder sind:
- Bei der Reinigung von Tastaturen knnen unbeabsichtigt Eingaben an
Servern oder anderen zentralen Komponenten erfolgen, die den IT-Betrieb
beeintrchtigen.
- IT-Systeme knnen versehentlich ausgeschaltet werden.
- Stromversorgungs- oder Kommunikationskabel knnen durch Staubsauger
beschdigt oder aus den Endpunkten gerissen werden.
- Durch Wasser oder Reinigungsflssigkeit knnen Kurzschlsse in Hard-
ware-Komponenten verursacht werden.
Wenn Vertrauen in die Reinigungsfirma besteht, sollte der Zutritt der Reini- Zutritt der Reinigungs-
krfte regeln
gungskrfte ber die vorhandene Zutrittskontrolle bzw. das Schliesystem
geregelt werden. Jedoch knnen dies nur wirksame Sicherungsmanahmen
sein, wenn z. B. Ausweis oder Schlssel gegen Unterschrift und nur zeitlich
begrenzt benannten bzw. bekannten Mitarbeitern der Reinigungsfirma ausge-
geben werden. Bei der Vereinbarung ber die Verwendung von Stamm-
personal kann ber das Ausweissystem eine wirksame Kontrolle der Ver-
tragseinhaltung erreicht werden.
Fr die Koordination, aber auch bei auftretenden Problemen ist vom Auftrag- Ansprechpartner der
Reinigungsfirma
nehmer ein Objektverantwortlicher zu benennen, der jederzeit ansprechbar ist.
Er muss Entscheidungsbefugnis ber das einzusetzende (vor allem auch ber
nicht mehr einzusetzendes, weil unerwnschtes) Personal haben.
Bereiche mit einem erhhten Sicherungsbedarf wie Maschinensaal oder
Datentrgerarchiv sind nur unter Anwesenheit von Verantwortlichen des
Auftraggebers oder in einigen Fllen auch unter Anwesenheit einer Ver-
trauensperson des Auftragnehmers, z. B. im Vier-Augen-Prinzip, zu reinigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wird kontrolliert, ob die Mitarbeiter der beauftragten Reinigungsfirma die
ausgegebenen Schlssel bzw. Ausweise vertragsgem verwenden?
- Sind die Reinigungskrfte ber den Umgang mit der IT ausreichend
informiert?
- Werden die Reinigungskrfte in besonders sensitiven Bereichen bei der
Arbeit beaufsichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.213 Wartung der technischen Infrastruktur

Die von den Herstellern empfohlenen Wartungsintervalle und -vorschriften
sollten unbedingt eingehalten werden. Neben der normalen Wartung sollten
ltere Anlagen einer greren Inspektion unterzogen werden, bei denen insbe-
sondere verschlissene Teile erkannt und rechtzeitig ausgetauscht werden. Dies
betrifft insbesondere grere Aggregate der Gebudetechnik, beispielsweise
zentrale Heizungs- und Klimatisierungsanlagen, sowie mechanisch stark bean-
spruchte Anlagen, z. B. Lastenaufzge fr Rechenzentren. Gegebenenfalls
sollte die Untersttzung durch technische Sachverstndige in Anspruch
genommen werden.
Besondere Beanspruchung oder auergewhnliche Betriebsbedingungen
knnen zu zustzlichem Wartungsaufwand fhren. Zum Beispiel mssen
Luftfilter whrend und nach Bauarbeiten in erheblich krzeren Intervallen
geprft werden.
- Werden die Wartungsvorschriften eingehalten?
- Werden die Wartungsintervalle bei besonderen Beanspruchungen diesen
angepasst?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.214 Konzeption des IT-Betriebs

Um einen ordnungsgemen und sicheren IT-Betrieb gewhrleisten zu
knnen, ist eine bergreifende Konzeption unabdingbar. Es sollten Regelun-
gen bzw. Vorgaben fr den Einsatz von IT-Systemen und IT-Produkten in den
verschiedenen Bereichen existieren, die gut aufeinander abgestimmt sind und
die Sicherheitsziele der Behrde bzw. des Unternehmens widerspiegeln.
Richtlinien fr IT-Verfahrensablufe und IT-Sicherheitsprinzipien
Alle an der IT-Planung und am IT-Betrieb beteiligten Organisationseinheiten grundlegende
IT-Sicherheitsprinzipien
mssen sich auf grundlegende IT-Sicherheitsprinzipien verstndigen, die auf abstimmen
alle Bereiche anzuwenden sind (z. B. Anforderungen an Passwrter). Es muss
eine bergreifende Regelung der Authentisierung und Rechtevergabe (siehe
M 2.220 Richtlinien fr die Zugriffs- bzw. Zugangskontrolle) erfolgen.
Die Verantwortlichkeiten fr den Betrieb aller IT-Komponenten mssen klar Verantwortlichkeiten
festlegen
festgelegt werden. Dazu gehrt die Benennung von Administratoren und
Ansprechpartnern fr die Benutzer (siehe auch M 2.79 Festlegung der
Verantwortlichkeiten im Bereich Standardsoftware).
Jeder Beschaffung von neuen IT-Komponenten sollte eine Konzeption fr Integration neuer
Komponenten
deren Einsatz zugrunde liegen. Dabei sollte auch deren Integration in den
vorhandenen IT-Verbund betrachtet werden und welche Auswirkungen dies
auf vorhandene IT-Sicherheitsmechanismen hat, die evtl. angepasst werden
mssen (siehe M 2.216 Genehmigungsverfahren fr IT-Komponenten).
Ebenso wie der Ablauf bei der Bestellung von IT muss auch der Umgang mit Test neuer Hard- und
Software
den gelieferten IT-Komponenten geregelt sein (siehe M 2.90 berprfung der
Lieferung). Bevor neue Hardware-Komponenten oder neue Software zum
Einsatz kommen, mssen diese getestet werden (siehe M 4.65 Test neuer
Hard- und Software).
Jede Installation von IT-Komponenten sollte den grundlegenden IT-Sicher- geregelte Installation
und Konfiguration
heitszielen der Behrde bzw. des Unternehmens folgen und auf geregelten
Verfahren basieren. Abhngig von der jeweiligen IT-Komponente und deren
Sicherheitsanforderungen mssen hierbei Zugriffsregelungen, Benutzerrechte
und andere sicherheitsrelevante Konfigurationen eingerichtet werden. Grund-
stzlich sollte jede Installation nachvollziehbar dokumentiert werden (siehe
M 2.87 Installation und Konfiguration von Standardsoftware).
Richtlinien fr den sicheren IT-Betrieb
Um auch im laufenden Betrieb die Sicherheit aller IT-Systeme aufrecht-
erhalten zu knnen, mssen eine Vielzahl von Faktoren bercksichtigt
werden. Daher sollten alle zur Aufrechterhaltung eines ordnungsgemen und
sicheren Betriebs notwendigen Aufgaben beschrieben und klar zugeordnet
werden. Dies betrifft u. a. die folgenden Aspekte:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Informationsverarbeitung muss kontinuierlich in allen ihren Phasen,

allen Anwendungen und allen Systemen dokumentiert werden (siehe
M 2.219 Kontinuierliche Dokumentation der Informationsverarbeitung).
- Der Zugang zu allen IT-Systemen sollte geschtzt sein, z. B. durch
Passwrter.
- Die Funktionen derjenigen IT-Komponenten, die nicht zum Einsatz
kommen sollen oder drfen, sind - wenn mglich - zu sperren (siehe auch
M 4.95 Minimales Betriebssystem).
- Die Protokollierungsdateien sind in regelmigen Abstnden auf Anoma-
lien (z. B. Ausfhrung von Funktionen, die nicht zum Einsatz kommen
sollen) zu untersuchen.
- Nach Mglichkeit sollten die IT-Systeme in Abstnden einem Integritts-
test unterzogen werden, so dass unberechtigte nderungen so frh wie
mglich entdeckt werden knnen. Dies gilt insbesondere fr Konfigu-
rationsdaten.
- Fr alle IT-Systeme sollten geeignete Verfahren zur Datensicherung
eingesetzt werden.
- Die Einhaltung der IT-Sicherheitsmanahmen muss regelmig kontrolliert
werden (siehe M 2.222 Regelmige Kontrollen der technischen IT-
Sicherheitsmanahmen).
Standardlsungen fr verwendete Hard- oder Software-Komponenten
Je grer eine Institution ist, desto wichtiger ist es, fr die IT-Ausstattung und mglichst einheitliche
Komponenten verwen-
den IT-Betrieb mglichst einheitliche Komponenten zu verwenden. Dies den
betrifft sowohl Hardware-Komponenten, wie z. B. Router, Drucker und
Grafikkarten, als auch Software-Produkte, wie Betriebssysteme, Textver-
arbeitungsprogramme und Tools. Anderenfalls besteht die Gefahr, dass das
Gesamtsystem aufgrund von Interoperabilittsproblemen und ausufernder
Komplexitt nicht mehr administriert werden kann.
Es sollten daher Hausstandards fr Hardware- und Software-Komponenten Hausstandards
definieren
festgelegt und dokumentiert werden, die bei der Beschaffung zu bercksich-
tigen sind. Dies erlaubt es, auf bewhrte Lsungen zurckzugreifen und
Interoperabilitts- und Kompatibilittsprobleme mglichst zu vermeiden.
Weiterhin wird hierdurch der administrative Aufwand und das erforderliche
Fachwissen verringert. In vielen Fllen knnen auch die Lagerkosten fr
Verbrauchsmaterial gesenkt werden. In Verbindung mit Rahmenvertrgen
oder Mengenrabatt knnen oft auch weitere finanzielle Einsparungen erreicht
werden.
Aufgrund der schnellen technischen Fortentwicklung im Bereich der Kompatibilitt sicher-
stellen
Informationsverarbeitung mssen Hausstandards fr IT-Komponenten regel-
mig aktualisiert werden. Dies fhrt in der Regel dazu, dass ein Mischbetrieb
zwischen verschiedenen "Generationen" von Hausstandards erforderlich ist.
Daher ist bei der berarbeitung der Hausstandards zu bercksichtigen, dass
neue und alte IT-Komponenten bzw. Produkte kompatibel sind und
gemeinsam verwendet werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ein besonders wichtiger Anwendungsfall fr Hausstandards sind Arbeitsplatz- Hausstandards fr

PCs. Hier sollte sowohl fr die Hardware-Komponenten in den PCs, wie Arbeitsplatz-PCs
Prozessor, Arbeitsspeicher, Grafikkarte, usw., als auch fr die installierte
Software und deren Konfigurationen Hausstandards festgelegt werden.
Anderenfalls besteht aufgrund der Vielzahl von Konfigurationsmglichkeiten,
die PCs bieten, die Gefahr, dass die eingesetzten Arbeitsplatz-PCs
unberschaubar und somit nicht mehr administrierbar werden. Allein die
Pflege der notwendigen Hardware-Treiber fr die Betriebssysteme ist in
mittelgroen Behrden und Unternehmen ohne verbindliche Festlegung von
Hausstandards nicht mehr leistbar. Durch Hausstandards fr Arbeitsplatz-PCs
wird auch der Einsatz von Systemmanagement-Produkten erleichtert.
Hinweis: Bei der Definition von Hausstandards fr Hardware- oder Software-
Komponenten sollte keinesfalls nur das marktgngigste Produkt in Betracht
gezogen werden. Vielmehr sollte sich die Auswahl nach den funktionalen
Anforderungen und den (IT-)Sicherheitsanforderungen richten. Eine
"Monokultur", d. h. die weitgehende Dominanz eines einzelnen Produktes am
Markt, kann u. U. sogar zu Sicherheitsproblemen fhren. In diesem Fall sind
nmlich auch die in dem Produkt evtl. vorhandenen Software-Schwachstellen
besonders weit verbreitet und knnen daher, wenn sie ausgenutzt werden, zu
hohen Gesamtschden fhren. Computer-Viren, Trojanische Pferde und
andere Gefhrdungen durch vorstzliche Handlungen richten sich in vielen
Fllen auf weit verbreitete Produkte.
Konventionen fr Namens-, Adress- und Nummernrume
Innerhalb einer Institution existieren meist eine ganze Reihe unterschiedlicher
Namens- und Nummernrume nebeneinander. Besonders populr sind die-
jenigen, die auch auerhalb der Behrde bzw. des Unternehmens verwendet
werden, beispielsweise E-Mail-Adressen, DNS-Namen, Telefonnummern und
Bezeichnungen von Organisationseinheiten. Aber auch rein interne Bezeich-
nungskonventionen, wie Inventarnummern, IP-Adressen und Ausweis-
nummern, spielen oft eine wichtige Rolle fr die Organisation und das IT-
Management.
Fr einen reibungslosen Ablauf der Informationsverarbeitung und fr die bergreifendes Konzept
fr Namens- und
Administrierbarkeit der eingesetzten IT ist es erforderlich, dass ein ber- Nummernrume
greifendes Konzept fr die verwendeten Namens- und Nummernrume erstellt
wird. Bei der Konzeption sollten folgende Aspekte bercksichtigt werden:
- Mglichst wenig unterschiedliche Namens- und Nummernrume sollten
parallel verwendet und gepflegt werden.
- Das Konzept muss Vergabe, Entzug, ggf. Sperrung von Namen und
Nummern sowie das Zusammenspiel der einzelnen Namens- und
Nummernrume regeln.
- Namen und Nummern, die nur fr Teilbereiche (Organisationseinheiten,
Teilnetze, Liegenschaften, usw.) bentigt werden, sollten mglichst aus
allgemeinen, behrden- bzw. unternehmensweiten Namens- bzw.
Nummernrumen abgeleitet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Struktur der verwendeten Namens- und Nummernrume sollte mg- unntige Ausnahmen
lichst einfach, allgemein und ohne unntige Ausnahmen sein, auch wenn vermeiden
dies bedeutet, dass die Bezeichnungen lnger werden (z. B. mehr Ziffern
enthalten). Anderenfalls besteht die Gefahr, dass die Bezeichnungen fehl-
interpretiert oder von gngigen Produkten nicht verarbeitet werden knnen.
- Bei der Konzeption ist das absehbare mittelfristige Wachstum zu berck- Reserven einplanen
sichtigen, das durch den Namens- bzw. Nummernraum versorgt werden
muss. In jedem Fall sind grozgige Reserven einzuplanen. Nachtrgliche
Erweiterungen oder Migrationen auf grere Namens- oder Nummern-
rume sind oft zeit- und kostenintensiv.
- Wenn Kollisionen, d. h. mehrfache Vergabe des gleichen Bezeichners oder Kollisionen auflsen
der gleichen Nummer, durch das generelle Vergabesystem mglich sind, so
ist im Konzept festzulegen, wie diese aufgelst werden. Ein wichtiges
Beispiel ist die Konvention Vorname.Nachname fr E-Mail-Adressen. Hier
muss im Konzept definiert werden, welche Adressen ersatzweise vergeben
werden, wenn in der Behrde bzw. im Unternehmen zwei oder mehr
Mitarbeiter mit gleichen Vor- und Nachnamen beschftigt werden.
Schnittstellendefinitionen fr das Zusammenspiel der Komponenten
Die Informationsverarbeitung geschieht in der Regel durch eine Vielzahl
kleiner Verarbeitungsschritte, die durch geeignete Hardware- oder Software-
Komponenten untersttzt werden. Der Datentransfer zwischen diesen
Komponenten erfolgt in der Regel ber Dateien, Datenbanken oder Netze.
Um einen reibungslosen IT-Betrieb gewhrleisten zu knnen ist es daher Schnittstellen definieren
und dokumentieren
erforderlich, die Schnittstellen fr das Zusammenspiel der einzelnen Kompo-
nenten klar zu definieren. Alle Schnittstellendefinitionen sollten dokumentiert
werden, sofern sie nicht von den verwendeten Komponenten her selbstver-
stndlich sind.
Wichtige Aspekte von Schnittstellendefinitionen zwischen IT-Komponenten Standardformate und
Standardprotokolle
sind beispielsweise Datei- und Datenformate sowie Netzprotokolle. Um bei verwenden
Bedarf einzelne Komponenten mglichst problemlos austauschen zu knnen
(Investitionsschutz) und um auf praxisbewhrte Lsungen zurckgreifen zu
knnen, sollten so weit wie mglich Standardformate und Standardprotokolle
verwendet werden, beispielsweise EDI, XML und HTTP.
Alle nderungen an Schnittstellendefinitionen zwischen den verwendeten IT- Auswirkungen auf die IT-
Sicherheit prfen
Komponenten mssen dokumentiert und in Bezug auf Auswirkungen auf die
Sicherheit des IT-Verbunds geprft werden. Falls erforderlich ist das IT-
Sicherheitskonzept entsprechend zu ergnzen bzw. anzupassen.
- Gibt es Richtlinien fr IT-Verfahrensablufe und den sicheren IT-Betrieb?
- Wurden Hausstandards fr verwendete Hardware- und Software-Kompo-
nenten festgelegt?
- Existiert ein bergreifendes Konzept fr den Einsatz von Namens-, Adress-
und Nummernrumen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.215 Fehlerbehandlung
Verantwortlich fr Umsetzung: Benutzer, Administrator
Alle Fehler, die IT-Systeme oder Kommunikationsverbindungen betreffen,
mssen gemeldet und protokolliert werden. Hiervon sind natrlich alle
Fehlermeldungen ausgenommen, die aufgrund von Plausibilittsprfungen
angezeigt werden, also z. B. durch fehlerhafte Benutzereingaben
hervorgerufen werden. Es muss gewhrleistet sein, dass die gemeldeten Fehler
schnellstmglich behoben werden.
Die Untersuchung und Beseitigung von Fehlern sollte nur von entsprechend Information der Benutzer
geschultem Personal durchgefhrt werden. Alle Benutzer sollten darber
informiert sein, wer beim Auftreten von Fehlern oder Problemen mit IT-
Systemen zu benachrichtigen ist. Auerdem sollten die Benutzer ber Fehler,
die das Arbeiten mit IT-Systemen beeintrchtigen knnen, informiert werden,
ebenso ber deren Behebung.
Die Protokolle ber gemeldete Fehler sollten folgende Angaben enthalten: Protokollierung
- Bezeichnung und Versionsnummer der betroffenen IT-Systeme und

Software,
- den Zeitpunkt der Meldung,
- eine Beschreibung, ob bzw. inwiefern die Nutzung der betroffenen IT-
Systeme eingeschrnkt ist,
- den Namen des fr die Behebung Verantwortlichen sowie
- den Zeitpunkt der Fehlerbehebung.
In einigen Fllen kann es sinnvoll oder notwendig sein, aufgetretene Fehler
nicht zu beheben, z. B. wenn kein zuverlssiger Patch vorhanden ist oder ein
Ersatzteil nicht beschafft werden kann. Dann sollte im Protokoll vermerkt
werden, ob die betroffene IT-Komponente mit Funktionseinschrnkungen
weiter betrieben werden kann.
Diese Protokolle sollten regelmig daraufhin berprft werden, ob sie aktuell
sind und ob alle gemeldeten Fehler behoben wurden.
Fehler sollten nur von den dafr benannten Verantwortlichen korrigiert sorgfltige Bereinigung
der Fehler
werden. Die Fehlerbeseitigung muss im Rahmen der IT-Sicherheitsrichtlinien
der jeweiligen Institution erfolgen. Wenn fr die Fehlerbehebung Patches oder
Updates bentigt werden, sollten diese direkt vom Hersteller oder von
vertrauenswrdigen Stellen bezogen werden (siehe auch M 4.107 Nutzung von
Hersteller-Ressourcen). Grere Korrekturmanahmen mssen zunchst auf
vom Wirknetz getrennten Systemen getestet werden, da diese auch
unerwnschte Nebeneffekte haben knnen. Nach der Fehlerbeseitigung
mssen eventuell die genderten IT-Systeme bzw. Komponenten erneut
abgenommen und freigegeben werden (siehe M 2.62 Software-Abnahme- und
Freigabe-Verfahren).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gibt es ein festgelegtes Verfahren fr die Fehlerbehandlung?
- Werden Fehler ausschlielich von der fachlich zustndigen Stelle beseitigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.216 Genehmigungsverfahren fr IT-Komponenten

Die Beschaffung, die Installation und der Betrieb von IT-Komponenten aller
Art muss koordiniert und genehmigt sein. Es muss geregelt sein, wie
IT-Komponenten abgenommen, freigegeben, installiert bzw. benutzt werden.
Dies betrifft beispielsweise den Einsatz von Modems, Diskettenlaufwerken,
Software und Mobiltelefonen. Eine entsprechende Vorgehensweise fr den
Bereich Standardsoftware ist in Kapitel 9.1 beschrieben. Dabei wird der
gesamte Lebenszyklus von Standardsoftware betrachtet: Erstellung eines
Anforderungskataloges, Vorauswahl eines geeigneten Produktes, Test, Frei-
gabe, Installation, Lizenzverwaltung und Deinstallation. Um eine analoge
Vorgehensweise fr andere IT-Komponenten zu entwickeln, kann sich eben-
falls an diesem Kapitel orientiert werden.
Im Rahmen des Genehmigungsverfahrens von neuen IT-Komponenten
mssen
- die generelle Funktionstchtigkeit untersucht werden (siehe auch M 4.65
Test neuer Hard- und Software),
- deren Sicherheitseigenschaften bewertet werden,
- mgliche Sicherheitsrisiken, die durch diese IT-Komponenten entstehen
knnten, untersucht und bewertet sowie weitestgehend behoben werden,
- alle ihre Sicherheitseigenschaften (sowohl die positiven als auch die nega-
tiven) sorgfltig dokumentiert werden,
- auf dieser Basis Installationsanweisungen erarbeitet werden.
Whrend des Genehmigungsverfahrens sollten auerdem Installations- bzw. Dokumentation aller
sicherheitsrelevanten
Konfigurationsanleitungen erarbeitet werden, in denen auch alle sicherheits- Einstellungen
relevanten Einstellungen dokumentiert sind. Auch nach der Erstinstallation
von IT-Komponenten mssen diese weitergepflegt werden (siehe auch M 4.78
Sorgfltige Durchfhrung von Konfigurationsnderungen). Vor der Inbe-
triebnahme neuer IT-Komponenten sind (sofern erforderlich) die Administra-
toren bzw. die Benutzer in deren Anwendung zu schulen.
Die Installation und Benutzung nicht freigegebener IT-Komponenten muss
verboten und die Einhaltung dieses Verbotes regelmig kontrolliert werden.
- Gibt es Genehmigungs- und Registrierverfahren fr IT-Komponenten aller
Art?
- Werden alle Schritte bei der Abnahme und Freigabe von IT-Komponenten
sorgfltig dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.217 Sorgfltige Einstufung und Umgang mit

Informationen, Anwendungen und Systemen
Grundstzlich sollten Mitarbeiter natrlich sorgfltig mit allen Informationen
umgehen. Darber hinaus gibt es aber in vielen Bereichen Daten, die einen
hheren Schutzbedarf haben oder besonderen Restriktionen unterliegen, z. B.
personenbezogene, finanzrelevante, vertrauliche oder Copyright-geschtzte
Daten. Fr diese gelten je nach ihrer Kategorisierung unterschiedliche
Beschrnkungen im Umgang mit ihnen. Daher ist es wichtig, alle Mitarbeiter
auf die fr diese Daten geltenden Restriktionen hinzuweisen (siehe auch M 3.2
Verpflichtung der Mitarbeiter auf Einhaltung einschlgiger Gesetze,
Vorschriften und Regelungen).
Der Schutzbedarf von Daten wirkt sich natrlich unmittelbar auf alle Medien
aus, auf denen diese gespeichert oder verarbeitet werden. Daten mit beson-
derem Schutzbedarf knnen in den unterschiedlichsten Bereichen anfallen,
z. B. bei Fax oder E-Mail. Es sollte also in allen Bereichen Regelungen geben,
in denen beispielsweise auch festgelegt ist, wer solche Daten lesen, bearbeiten
bzw. weitergeben darf (siehe z. B. M 2.42 Festlegung der mglichen
Kommunikationspartner). Dazu gehrt auch die regelmige berprfung auf
Korrektheit und Vollstndigkeit der Daten (siehe auch M 4.64 Verifizieren der
zu bertragenden Daten vor Weitergabe / Beseitigung von Restinfor-
mationen).
Viele Informationen, aber auch IT-Anwendungen, unterliegen Copyright- Einschrnkung der
Weitergabe
Vermerken oder Weitergaberestriktionen ("Nur fr den internen Gebrauch").
Alle Mitarbeiter mssen darauf hingewiesen werden, dass weder Dokumente,
noch Dateien oder Software ohne Bercksichtigung evtl. Copyright-Vermerke
oder Lizenzbedingungen kopiert werden drfen.
Ein besonderes Augenmerk muss auch auf alle Informationen gelegt werden, Schutz geschfts-
kritischer Informationen
die die Grundlage fr die Aufgabenerfllung bilden. Dazu gehren alle
geschftsrelevanten Daten, also z. B. diejenigen Daten, bei deren Verlust die
Institution handlungsunfhig wird, die die wirtschaftlichen Beziehungen
zusammenarbeitender Unternehmen beeintrchtigen knnen oder aus deren
Kenntnis ein Dritter (z. B. Konkurrenzunternehmen) finanzielle Vorteile
ziehen kann. Jede Behrde und jedes Unternehmen sollte eine bersicht
darber haben, welche Daten als geschftskritisch einzustufen sind (siehe dazu
auch Kapitel 2.2 Schutzbedarfsfeststellung). Neben den allgemeinen
Sorgfaltspflichten knnen auch hier fr diese Daten bei der Speicherung,
Verarbeitung, Weitergabe und Vernichtung besondere Vorschriften und Rege-
lungen gelten. Geschftskritische Informationen mssen vor Verlust, Mani-
pulation und Verflschung geschtzt werden. Lngerfristig gespeicherte oder
archivierte Daten mssen regelmig auf ihre Lesbarkeit getestet werden.
Nicht mehr bentigte Informationen mssen zuverlssig gelscht werden
(siehe auch M 2.167 Sicheres Lschen von Datentrgern).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die Mitarbeiter regelmig auf den sorgfltigen Umgang mit
Informationen hingewiesen?
- Sind alle Informationen entsprechend ihrem Schutzbedarf eingestuft
worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.218 Regelung der Mitnahme von Datentrgern und

IT-Komponenten
Die IT-Komponenten, die innerhalb einer hauseigenen Liegenschaft eingesetzt
werden, sind im Allgemeinen durch infrastrukturelle Sicherheitsmanahmen
ausreichend vor Missbrauch und Diebstahl geschtzt. Hufig sollen aber IT-
Systeme oder Datentrger auch auer Haus eingesetzt werden, z. B. bei
Dienstreisen oder Telearbeit. Um auch diese ausreichend schtzen zu knnen,
muss die Mitnahme von Datentrgern und IT-Komponenten klar geregelt
werden.
Dabei muss festgelegt werden, Regelung
- welche IT-Komponenten bzw. Datentrger auer Haus mitgenommen Welche Komponenten?

werden drfen,
- wer IT-Komponenten bzw. Datentrger auer Haus mitnehmen darf, Wer darf?
- welche grundlegenden IT-Sicherheitsmanahmen dabei beachtet werden Was ist zu beachten?

mssen (Virenschutz, Verschlsselung sensitiver Daten, Aufbewahrung,
etc.).
Die Art und der Umfang der anzuwendenden IT-Sicherheitsmanahmen fr
extern eingesetzte IT-Komponenten hngt einerseits vom Schutzbedarf der
darauf gespeicherten IT-Anwendungen und Daten und andererseits von der
Sicherheit der Einsatz- bzw. Aufbewahrungsorte ab.
Grundstzlich sollte fr alle IT-Komponenten, die extern eingesetzt werden
sollen, eine entsprechende Genehmigung eingeholt werden.
Bei greren Institutionen, bei denen der Zutritt zu den Liegenschaften durch ggf. Stichprobe
veranlassen
Pfrtner bzw. Wachdienste kontrolliert wird, sollte berlegt werden, ob diese
angewiesen werden sollten, in Stichproben zu berprfen, inwieweit die
Regelungen fr die Mitnahme von Datentrgern und IT-Komponenten einge-
halten werden.
Auerhalb der organisationseigenen Liegenschaften sind die Benutzer fr den
Schutz der ihnen anvertrauten IT verantwortlich. Darauf und auf die zu ergrei-
fenden Vorsichtsmanahmen sind sie hinzuweisen. Dazu gehren folgende
Regeln:
- IT-Systeme mssen stets sicher aufbewahrt werden. Bei Dienstreisen Aufbewahrung
sollten sie nicht unbeaufsichtigt gelassen werden. Insbesondere sollten sie
nicht in Fahrzeugen zurckgelassen werden (siehe auch M 1.33 Geeignete
Aufbewahrung tragbarer IT-Systeme bei mobilem Einsatz).
- IT-Systeme wie Laptops oder Mobiltelefone und deren Anwendungen Zugriffsschutz
knnen im Allgemeinen durch PINs oder Passwrter abgesichert werden.
Diese Mechanismen sollten auch genutzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- IT-Systeme oder Datentrger, die sensitive Daten enthalten, sollten Verschlsselung

mglichst komplett verschlsselt werden (siehe auch M 4.29 Einsatz eines
Verschlsselungsproduktes fr tragbare PCs).
- Die Verwaltung, Wartung und Weitergabe von extern eingesetzten IT- Verwaltung
Systemen sollte geregelt werden. Hierzu knnen beispielsweise Pools
eingerichtet werden (siehe auch M 1.35 Sammelaufbewahrung mehrerer
tragbarer PCs bzw. M 2.190 Einrichtung eines Mobiltelefon-Pools).
- Es sollte protokolliert werden, wann und von wem welche IT-Kompo- Protokollierung
nenten auer Haus eingesetzt wurden.
- Gibt es Regelungen fr die Mitnahme von IT-Komponenten aller Art?
- Werden die Benutzer von extern eingesetzten IT-Komponenten auf die
Regelungen hingewiesen, die von ihnen einzuhalten sind?
- Werden die Benutzer von extern eingesetzten IT-Komponenten auf deren
geeignete Aufbewahrung hingewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.219 Kontinuierliche Dokumentation der

Informationsverarbeitung
Die Informationsverarbeitung muss kontinuierlich in allen Phasen, allen
Anwendungen und allen Systemen dokumentiert werden, um einen ordnungs-
gemen IT-Betrieb gewhrleisten zu knnen. Dazu gehren:
- eine aktuelle Dokumentation aller vorhandenen IT-Systeme und deren Konfiguration
Konfiguration (siehe M 2.25 Dokumentation der Systemkonfiguration),
- die Dokumentation der auf den jeweiligen IT-Systemen eingerichteten Rechteprofile
Benutzer und deren Rechteprofile (siehe M 2.31 Dokumentation der zuge-
lassenen Benutzer und Rechteprofile), dies umfasst auch eine Beschreibung
und Begrndung aller Einschrnkungen bei der Nutzung von IT-Systemen
(Rechte und Ressourcen),
- die neu hinzugekommenen Hard- und Softwarekomponenten mssen in der Vernderungen
Systemdokumentation aufgefhrt werden (siehe M 2.34 Dokumentation
der Vernderungen an einem bestehenden System),
- die Dokumentation aller sicherheitsrelevanten Ablufe wie der Daten- sicherheitsrelevante
Ablufe
sicherung (siehe M 6.37 Dokumentation der Datensicherung) oder der
Vernichtung von Datentrgern,
- die Dokumentation der Wartungsmanahmen (siehe M 2.4 Regelungen fr Wartung
Wartungs- und Reparaturarbeiten),
- eine Beschreibung aller gefundenen und behobenen Fehler (siehe M 2.215 Fehlerbehandlung
Fehlerbehandlung).
Die Benennung der Systemverantwortlichen (siehe M 2.26 Ernennung eines
Administrators und eines Vertreters) sollte ebenfalls schriftlich erfolgen und
den Benutzern bekannt gegeben werden.
Fr Problemflle sollte dokumentiert sein, wer helfen kann und wo Informa- Ansprechpartner
tionen zu finden sind (M 6.59 Festlegung von Verantwortlichkeiten bei
Sicherheitsvorfllen).
- Wird die Informationsverarbeitung in allen Phasen, allen Anwendungen
und allen Systemen dokumentiert?
- Gibt es Regelungen fr die Dokumentation der Informationsverarbeitung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.220 Richtlinien fr die Zugriffs- bzw.

Zugangskontrolle
Verantwortlich fr Umsetzung: Administratoren, Fachverantwortliche
Um IT-Systeme bzw. System-Komponenten und Netze nutzen zu knnen
bzw. um dort gespeicherte Informationen abrufen zu knnen, muss die
Zugriffs- bzw. Zugangskontrolle geregelt sein. Neben den an den einzelnen
IT-Komponenten einzurichtenden Zugriffs- bzw. Zugangskontrollen sollte
eine bergreifende Richtlinie hierzu existieren, in der die Grundsatzfragen
geregelt sind. Die Regelungen zur Zugriffs- bzw. Zugangskontrolle mssen
den Schutzbedarf der Behrde bzw. des Unternehmens widerspiegeln. Insbe-
sondere ist hier auf die Einhaltung einschlgiger Gesetze, Vorschriften und
Regelungen, also z. B. Datenschutz- und Urheberrechtsgesetze bzw. Lizenz-
regelungen, zu verweisen.
Es empfiehlt sich, dabei Standard-Rechteprofile fr nutzungsberechtigte Standard-Rechteprofile
Personen aufgrund ihrer Funktionen und Aufgaben festzulegen (siehe auch
M 2.8 Vergabe von Zugriffsrechten). Die Benutzerrechte fr Zugriffe auf
Dateien und Programme mssen abhngig von der jeweiligen Rolle, dem
Need-to-Know und der Sensitivitt der Daten definiert sein. Falls Rechte
vergeben werden, die ber den Standard hinausgehen, sollte dies begrndet
werden.
Die Richtlinien fr die Zugriffs- bzw. Zugangskontrolle sollte allen Verant-
wortlichen fr IT-Anwendungen vorliegen. Darauf aufbauend knnen dann
Zugriffsregelungen fr die einzelnen IT-Systeme abgeleitet und eingerichtet
werden.
Fr jedes einzelne IT-Systeme und jede IT-Anwendung sollten schriftliche Regelungen auf IT-
Systeme anpassen
Zugriffsregelungen und die Dokumentation der Einrichtung von Benutzern
und der Rechtevergabe vorhanden sein (siehe M 2.30 Regelung fr die
Einrichtung von Benutzern / Benutzergruppen). Hierbei mssen die system-
bzw. anwendungsspezifischen Besonderheiten und Sicherheitsanforderungen
bercksichtigt werden. Verantwortlich fr die Erstellung und Aktualisierung
der system- bzw. anwendungsspezifischen Vorgaben sind die
IT-Verantwortlichen.
Werden an Mitarbeiter besonders weitgehende Rechte vergeben (z. B. an Restriktive Rechte-
vergabe
Administratoren), so sollte dies mglichst restriktiv erfolgen. Hierbei sollte
zum einem der Kreis der privilegierten Benutzer mglichst eingeschrnkt
werden und zum anderen nur die fr die Durchfhrung der Arbeit bentigten
Rechte vergeben werden (siehe auch M 2.38 Aufteilung der Administrations-
ttigkeiten). Fr alle Aufgaben, die ohne erweiterte Rechte durchgefhrt
werden knnen, sollten auch privilegierte Benutzer unter Accounts mit
Standard-Rechten arbeiten.
Der Zugriff auf alle IT-Systeme oder Dienste muss durch Identifikation und kein Zugriff ohne
Authentikation
Authentikation des zugreifenden Benutzers oder IT-Systems abgesichert
werden. Beim Zugriff aus externen Netzen sollten starke Authentisierungs-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
verfahren eingesetzt werden, also solche die z. B. auf dem Einsatz von
Einmalpasswrtern oder dem Besitz von Chipkarten basieren.
Beim Anmeldevorgang sollten keine Informationen ber das IT-System oder
den Fortschritt der Anmeldeprozedur angezeigt werden, bis dieser erfolgreich
abgeschlossen ist. Es sollte dabei darauf hingewiesen werden, dass der Zugriff
nur autorisierten Benutzern gestattet ist. Die Authentikationsdaten drfen erst
dann berprft werden, wenn sie vollstndig eingegeben wurden. Weitere
Anforderungen an die Authentikationsmechanismen finden sich in M 4.133
Geeignete Auswahl von Authentikations-Mechanismen.
- Gibt es Richtlinien fr die Zugriffs- bzw. Zugangskontrolle?
- Gibt es Standard-Rechteprofile fr verschiedene Funktionen bzw.
Aufgaben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.221 nderungsmanagement
Verantwortlich fr Umsetzung: Administratoren, Fachverantwortliche
Bei der Komplexitt heutiger IT-Systeme knnen bereits kleine nderungen
an laufenden Systemen zu Sicherheitsproblemen fhren, z. B. durch uner-
wartetes Systemverhalten oder Systemausflle.
In Bezug auf IT-Sicherheit ist es Aufgabe des nderungsmanagements, neue
Sicherheitsanforderungen zu erkennen, die sich aus nderungen an IT-Syste-
men ergeben. Sind signifikante Hardware- oder Software-nderungen an
einem IT-System geplant, so sind die Auswirkungen auf die Sicherheit des
Gesamtsystems zu untersuchen. nderungen an einem IT-System drfen nicht
zu einer Verringerung der Effizienz von einzelnen Sicherheitsmanahmen und
damit einer Gefhrdung der Gesamtsicherheit fhren.
Daher sollte es Richtlinien fr die Durchfhrung von nderungen an IT- Richtlinien fr nde-
rungen
Komponenten, Software oder Konfigurationsdaten geben (siehe M 4.78
Sorgfltige Durchfhrung von Konfigurationsnderungen). Alle nderungen
an IT-Komponenten, Software oder Konfigurationsdaten sollten geplant,
getestet, genehmigt und dokumentiert werden. Es ist dafr Sorge zu tragen,
dass auf alle sicherheitsrelevanten nderungen angemessen reagiert wird.
Dazu gehren zum Beispiel:
- nderungen an IT-Systemen (neue Applikationen, neue Hardware, neue
Netzwerkverbindungen, Modifikationen an der eingesetzten Software,
Einspielen von Sicherheitspatches, Aufrstung der Hardware, ...),
- nderungen in der Aufgabenstellung oder in der Wichtigkeit der Aufgabe
fr die Institution,
- nderungen in der Benutzerstruktur (neue, etwa externe oder anonyme,
Benutzergruppen),
- rumliche nderungen, z. B. nach einem Umzug.
Bevor nderungen genehmigt und durchgefhrt werden, muss durch Prfung Rckfalllsung
und Test der geplanten Aktionen sichergestellt werden, dass das Sicherheits-
niveau whrend und nach der nderung erhalten bleibt. Wenn Risiken, insbe-
sondere fr die Verfgbarkeit, nicht ausgeschlossen werden knnen, muss die
Planung auch eine Rckfalllsung vorsehen und Kriterien vorgeben, wann
diese zum Tragen kommen soll.
Alle nderungen und die dazugehrigen Entscheidungsgrundlagen sind zu Dokumentation der
nderungen
dokumentieren. Dies gilt sowohl in der Betriebs- als auch in einer Testum-
gebung.
Beim nderungsmanagement ist das Berechtigungskonzept zur Durchfhrung
von nderungen ein wichtiger Punkt:
- Nur diejenigen, die nderungen durchfhren drfen, sollten Zugriffs-
berechtigungen auf die dafr relevanten Systembereiche haben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Es sollte Mechanismen geben, die sicherstellen, dass alle wesentlichen

nderungen vorher abgestimmt wurden.
Hinweis: Bei der Durchfhrung von nderungen sollte immer beachtet
werden, dass nderungen eines IT-Systems oder seiner Einsatzbedingungen
- nderungen in der Umsetzung des IT-Sicherheitsplanes,
- die Erstellung eines neuen IT-Sicherheitskonzepts oder sogar
- die berarbeitung der organisationsweiten IT-Sicherheitspolitik
erforderlich machen knnen. Bei greren nderungen sollte daher das IT-
Sicherheitsmanagement involviert werden.
- Gibt es Richtlinien fr die Durchfhrung von nderungen an IT-Kompo-
nenten, Software oder Konfigurationsdaten?
- Werden alle nderungen getestet und dokumentiert?
- Wird bei greren nderungen das IT-Sicherheitsmanagement beteiligt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.222 Regelmige Kontrollen der technischen

IT-Sicherheitsmanahmen
Im IT-Grundschutzhandbuch werden eine Vielzahl von technischen Sicher- unangekndigte
Kontrollen
heitsmanahmen und Konfigurationshinweisen vorgestellt, die fr die Errei-
chung der angestrebten IT-Sicherheit notwendig sind. Deren Einhaltung muss
Kontrollen sollten vor allen Dingen darauf ausgerichtet sein, Mngel abzu-
stellen. Fr die Akzeptanz von Kontrollen ist es wichtig, dass dies allen
Beteiligten als Ziel der Kontrollen erkennbar ist und dass die Kontrollen nicht
den Charakter von Schulmeisterei haben. Es ist daher sinnvoll, whrend einer
Kontrolle mit den Beteiligten ber mgliche Problemlsungen zu sprechen
und entsprechende Abhilfen vorzubereiten.
Wenn Mitarbeiter eine Regelung ignorieren oder umgehen, ist das meist ein Regelungen auf Arbeits-
ablufe abstimmen
Zeichen dafr, dass diese nicht mit den Arbeitsablufen vereinbar ist oder
durch die Mitarbeiter nicht umgesetzt werden kann. Beispielsweise ist eine
Anweisung, vertrauliche Schreiben nicht unbeaufsichtigt am Drucker liegen
zu lassen, unsinnig, wenn zum Drucken nur ein weit entfernter Netzdrucker
zur Verfgung steht.
Wenn bei Kontrollen Mngel festgestellt werden, kommt es nicht darauf an, Ursachen der Sicher-
heitsdefizite beseitigen
nur die Symptome zu beseitigen. Vielmehr ist es wichtig, die Ursachen fr
diese Probleme festzustellen und Lsungen aufzuzeigen. Diese knnen
beispielsweise in der nderung bestehender Regelungen oder in der Hinzu-
nahme technischer Manahmen bestehen.
Kontrollen sollen helfen, Fehlerquellen abzustellen. Es ist fr die Akzeptanz Schuldzuweisungen
vermeiden
von Kontrollen extrem wichtig, dass dabei keine Personen blogestellt oder
als "Schuldige" identifiziert werden. Wenn die Mitarbeiter dies befrchten
mssen, besteht die Gefahr, dass sie nicht offen ber ihnen bekannte
Schwachstellen und Sicherheitslcken berichten, sondern versuchen, beste-
hende Probleme zu vertuschen.
Kontrollen sollten sorgfltig vorbereitet werden, damit sie zum einen ihr Ziel gute Vorbereitung
mglichst effizient erreichen und zum anderen die Arbeitsablufe mglichst
wenig gestrt werden. Die generelle Durchfhrung von Kontrollen sollte
vorab mit der Leitungsebene bzw. den Verantwortlichen der betroffenen
Bereiche sowie dem Personal- bzw. Betriebsrat abgestimmt sein.
- Werden alle Regelungen und IT-Sicherheitsmanahmen auf ihre Umsetz-
barkeit untersucht?
- Wie hufig werden die bestehenden Regelungen und IT-Sicherheits-
manahmen auf ihre Einhaltung kontrolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.223 Sicherheitsvorgaben fr die Nutzung von

Standardsoftware
Verantwortlich fr Umsetzung: Administratoren, Mitarbeiter
In den meisten Broumgebungen wird fr die typischen Broaufgaben
Standardsoftware eingesetzt. Dazu gehren z. B. Textverarbeitungsprogramme
(Word, WordPerfect, StarOffice), Tabellenkalkulation, Bro-
Kommunikationssysteme, E-Mail-Programme und Datenbanken. Da diese
hufig komplett von einem Anbieter gekauft werden, wird hier auch von
Office-Paketen gesprochen. Durch die hohe Verbreitung gleichartiger Soft-
ware knnen Sicherheitslcken in diesen Programmen groe Auswirkungen
haben, da sie an vielen IT-Systemen ausgenutzt werden knnen und sich
Schadprogramme sehr schnell weiterverbreiten. Ein typisches Beispiel hierfr
sind Makro-Viren (siehe G 5.43 Makro-Viren).
Um solche Probleme vermeiden bzw. reduzieren zu knnen, sollten daher
Sicherheitsrichtlinien bei der Nutzung von Standardsoftware festgelegt
werden.
Standardsoftware ist im Allgemeinen nicht auf ein hohes IT-Sicherheitsniveau Benutzer ber Eignung
und Sicherheits-
ausgelegt. Alle Mitarbeiter sollten daher darauf hingewiesen werden, dass funktionen informieren
besonders schutzbedrftige Informationen nicht ohne weitere IT-Sicherheits-
manahmen auf einem Standard-Broarbeitsplatz verarbeitet werden sollten.
Einige der Standardprodukte bieten aber trotzdem eine Reihe von IT-Sicher-
heitsfunktionen an, die aber meist deutlich weniger Sicherheit bieten als
spezielle Sicherheitsprodukte. Die Benutzer sollten ber diese Sicherheits-
funktionen und deren Wirksamkeit informiert werden (siehe auch M 4.30
Nutzung der in Anwendungsprogrammen angebotenen Sicherheitsfunktionen).
Dabei ist vor allen Dingen sicherzustellen, dass die Benutzer sich nicht in
einer falschen, trgerischen Sicherheit wiegen und dass die Nutzung dieser
Sicherheitsfunktionen keine Sicherheitslcken ffnet. Benutzer sollten darber
informiert werden, dass Office-Produkte nicht fr jeden beliebigen
Einsatzzweck geeignet sind.
Daneben bieten Office-Pakete hufig Funktionen, die den Austausch von
Informationen erleichtern sollen, die aber hufig bereits in der Konzeption
groe Sicherheitsprobleme mit sich bringen.
Beispiele:
- Nutzung gemeinsamer Terminkalender
Um die Koordination innerhalb von Arbeitsgruppen zu erleichtern, lassen
sich die meisten elektronischen Terminkalender untereinander vernetzen.
Neben vielen Vorteilen bringt dies aber auch einige Probleme mit sich. So
will nicht jeder Mitarbeiter alle seine Termine den Kollegen offen legen.
Darauf haben die Hersteller reagiert, in dem sie hier die Mglichkeit
bieten, anderen nur die freien bzw. belegten Zeiten anzuzeigen. Viele Mit-
arbeiter glauben aber zum einen, dass es einen schlechten Eindruck macht,
wenn hier viel freie Zeit angezeigt wird, und befrchten zum anderen, dass
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
jede freie Minute von Kollegen mit Terminen besetzt wird. Dies fhrt dann
dazu, dass groe Zeitrume auf Vorrat blockiert werden.
Daneben kann es auch zu anderen Problemen kommen, z. B. durch zu
grozgige Rechtevergabe (siehe auch G 3.20 Ungewollte Freigabe des
Leserechtes bei Schedule+).
Es sollte daher Richtlinien fr die Verwendung vernetzter Terminkalender
und die hierbei zu beachtenden Zugriffsrechte geben. Diese sollten frh-
zeitig mit dem Personal- bzw. Betriebsrat abgestimmt werden. Bei der
Einfhrung von vernetzten Terminkalendern sollten auerdem alle Mitar-
beiter in den richtigen Umgang damit eingewiesen werden.
- automatischer Start von CD-ROMs
Unter allen neueren Windows-Betriebssystemen knnen CD-ROMs auto-
matisch erkannt und gestartet werden. Dadurch knnen auch Schad-
programme wie Viren oder Trojanische Pferde auf den Rechner gelangen
werden. Die automatische CD-ROM-Erkennung sollte daher ausgeschaltet
werden (siehe M 4.57 Deaktivieren der automatischen CD-ROM-Erken-
nung).
- OLE (Object Linking And Embedding, Dienst zum Verknpfen und
Einbetten von Objekten)
ber OLE-Funktionen knnen Objekte in Dateien eingebettet werden.
Diese werden in vielen Office-Produkten benutzt, um Informationen
anderen Programmen zur Verfgung zu stellen. Hierber kann beispiels-
weise eine in Excel erstellte Tabelle in einem Word-Dokument eingebettet
werden. Damit werden aber nicht nur die in dem Tabellenausschnitt
dargestellte Informationen, sondern u. U. alle in der Excel-Datei enthal-
tenen Informationen in die Word-Datei bertragen. Wenn die Word-Datei
dann weitergegeben wird, kann der Empfnger dann auch die Excel-Datei
einsehen und sogar verndern, auch wenn diese durch ein Passwort lese-
oder schreibgeschtzt war.
Um dies zu verhindern, sollte in diesem Beispiel die Tabelle als Text in die
Word-Datei kopiert werden. Nur wenn die Ursprungs-Excel-Datei keine
anderen Informationen enthlt, als solche, die weitergegeben werden
sollen, sollte sie in einer andere Datei eingebettet werden. Dies kann z. B.
durch Anlegen einer neuen Excel-Datei erreicht werden (siehe auch M 4.64
Verifizieren der zu bertragenden Daten vor Weitergabe / Beseitigung von
Restinformationen).
- PostScript /ghostscript
In PostScript-Dateien kann es zu Problemen hnlich wie bei Makro-Viren
kommen. Bei Anzeige-Programmen fr PostScript handelt es sich um
Interpreter, die die PostScript-Sprache abarbeiten. Ab Level 2.0 der
PostScript-Spezifikation gibt es auch PostScript-Befehle, um Dateien zu
schreiben. Dadurch ist es mglich, PostScript-Dateien zu erzeugen, die
whrend der Bearbeitung durch einen Interpreter, auch bereits bei der
Anzeige am Bildschirm, andere Dateien modifizieren, lschen oder umbe-
nennen knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Konkrete Probleme existieren bei dem Programm ghostscript (gs). In den

Unix-Versionen knnen die Schreibmglichkeiten auf Dateien mit der
Option -dSAFER abgeschaltet werden. Allerdings ist dies nicht die
Voreinstellung. In Versionen fr andere Betriebssysteme heit diese
Option hnlich.
Die Verwendung der Option -dSAFER wird dem Benutzer berlassen. Dies
hat auch zur Folge, dass zahlreiche andere Programme, die intern
ghostscript (gs) aufrufen (z. B. netscape, xdvi, xfig, xv etc.), dies unter-
schiedlich realisieren. Die Option sollte daher als Default eingestellt
werden. Beschreibungen, wie dies zu realisieren ist, finden sich in den
Sicherheitsbulletins des DFN-CERT DSB-95:02 und DSB-95:03 vom 24.
August 1995 (siehe auch M 2.35 Informationsbeschaffung ber Sicher-
heitslcken des Systems).
Bei lteren ghostscript-Versionen kann es daneben weitere PostScript-
Befehle geben, mit denen Dateien modifiziert werden knnen. Es sollten
nur ghostscript-Versionen eingesetzt werden, bei denen diese Probleme
beseitigt wurden.
Das Programm ghostview, mit dem sich PostScript-Dateien anzeigen
lassen, bietet ab der Version 1.5 eine Option -safer an, die die Sicherheits-
funktionen von ghostscript aktiviert. Versionen vor 1.5 bieten diesen
Schutz nicht und sollten durch die aktuelle Version ersetzt werden. Ein
hnliches Programm zur Anzeige von PostScript-Dateien ist gv. Hier sollte
im Dialogfeld "Ghostscript Options" die Schaltflche "Safer" aktiviert sein.
Beim PostScript-Viewer GSview, der fr Windows und OS/2 zur
Verfgung steht, sollte die Option "Schreibschutz fr Dateien" eingeschal-
tet sein.
- PDF (Portable Document Format)
Auch bei PDF-Dateien kann es zu hnlichen Problemen kommen, wenn
zum Anzeigen dieser Dateien ltere Versionen des Acrobat Readers
eingesetzt werden. In PDF-Dateien lassen sich Funktionen wie
Programmaufrufe einbetten, die ein Sicherheitsrisiko fr die Dateien des
lokalen IT-Systems darstellen. Daher sollte zur Anzeige von PDF-Dateien
ein Viewer verwendet werden, der
- diese Funktionalitt nicht untersttzt oder
- geeignete Sicherheitsmechanismen fr die Ausfhrung von Makros
bereitstellt (beispielsweise aktuelle Versionen des Acrobat Readers).
Anderenfalls besteht die Gefahr, dass die eingebetteten Funktionen bereits
beim ffnen des Dokuments oder durch das Bewegen im Dokument ber
so genannte Action Trigger gestartet werden, ohne dass sich der Leser
dessen bewusst ist.
- Schnellspeicherung unter Word
Word besitzt die Mglichkeit der Schnellspeicherung von erstellten
Texten. Dies fhrt dazu, dass nur die aktuell vorgenommenen nderungen
an einem Dokument gespeichert werden. Dieser Vorgang nimmt nicht so
viel Zeit in Anspruch wie ein vollstndiger Speichervorgang, bei dem
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Word das vollstndige berarbeitete Dokument speichert. Ein vollstndiger

Speichervorgang erfordert jedoch weniger Festplattenspeicher als eine
Schnellspeicherung. Der entscheidende Nachteil der Schnellspeicherung ist
aber, dass die Datei unter Umstnden Textfragmente enthalten kann, die
der Verfasser nicht weitergeben mchte.
Grundstzlich sollte daher die Option "Schnellspeicherung zulassen" abge-
schaltet werden. Des weiteren sollte die Option "Erstellung einer Siche-
rungskopie" aktiviert sein. Das System sollte regelmig durch Lschen
der nicht mehr bentigten Sicherungskopien gesubert werden.
Entscheidet sich der Benutzer trotzdem fr die Schnellspeicheroption,
sollte er bei folgenden Situationen immer einen vollstndigen Speicher-
vorgang durchfhren:
- Sobald die Bearbeitung eines Dokuments abgeschlossen worden ist.
- Bevor eine Aufgabe ausgefhrt wird, die viel Speicherplatz in
Anspruch nimmt, z. B. die Suche nach Text oder das Kompilieren
eines Indexes.
- Bevor der Dokumenttext in eine andere Anwendung bertragen
wird.
- Bevor das Dokument in ein anderes Dateiformat konvertiert wird.
Um gegen Konzeptionsschwchen und bekannt gewordene Sicherheitslcken Informationen ber
Sicherheitslcken
rechtzeitig Manahmen ergreifen zu knnen, sollte sich der Administrator einholen
bzw. das IT-Sicherheitsmanagement regelmig ber solche Probleme infor-
mieren (siehe auch M 2.35 Informationsbeschaffung ber Sicherheitslcken
des Systems).
- Wurden die Benutzer ber die Sicherheitsfunktionen in Anwendungs-
programmen und deren Wirksamkeit informiert?
- Wurde berprft, dass die Option -dSAFER bei den eingesetzten
PostScript-Interpretern aktiviert ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.224 Vorbeugung gegen Trojanische Pferde

Verantwortlich fr Umsetzung: Administratoren, Mitarbeiter
Ein Trojanisches Pferd ist ein Programm mit einer Schadensfunktion, das in
ein anderes Programm verdeckt eingebettet ist. Trojanische Pferde werden
verbreitet, indem sie in mglichst "attraktive" Wirtsprogramme integriert
werden, die dann beispielsweise zum Download angeboten oder als Anhang
an E-Mails verschickt werden. Neben unmittelbaren Schden knnen ber
Trojanische Pferde Informationen nicht nur ber den einzelnen Rechner,
sondern auch ber das lokale Netzwerk ausspht werden.
Es ist schwierig, sich gegen Trojanische Pferde zu schtzen, da diese in Benutzer immer wieder
informieren!
vielerlei Dateien versteckt sein knnen. Daher ist es wichtig, alle Benutzer
immer wieder ber die Problematik Trojanischer Pferde aufzuklren. Wichtige
Verhaltensregeln sind aus diesem Grunde:
- Daten und Programme, die aus dem Internet abgerufen werden, stellen
einen Hauptverbreitungsweg fr Computer-Viren und Trojanische Pferde
dar, um Benutzerdaten auszusphen, weiterzuleiten, zu verndern oder zu
lschen. Aber nicht nur Programme im eigentlichen Sinn, sondern auch
Office-Dokumente (Text-, Tabellen- und Prsentations-Dateien) knnen
ber Makros Viren und Trojanische Pferde enthalten.
Es sollten keine Programme aus unbekannter Quelle installiert werden Software aus
vertrauenswrdigen
(siehe auch M 2.9 Nutzungsverbot nicht freigegebener Software). Quellen beziehen
Viele Daten und Programme sind ber verschiedene Quellen verfgbar,
z. B. ber Mirror-Server im Internet oder ber CD-ROMs von Zeitschrif-
ten. Daten und Programme sollten nur von vertrauenswrdigen Seiten
geladen werden, also insbesondere von den Originalseiten des Erstellers.
- Es sollten keine E-Mail-Anhnge oder andere Dateien von Kommunikati- ggf. beim Absender
nachfragen
onspartnern geffnet werden, wenn diese nicht erwartet wurden oder
merkwrdige Namen tragen. Im Zweifelsfall sollte bei diesen nachgefragt
werden, ob sie die Nachrichten wirklich geschickt haben.
Hinweis: Eingehende E-Mail ist das grte Einfalltor fr Computer-Viren
und Trojanische Pferde. Bei E-Mail auch von vermeintlich bekannten bzw.
vertrauenswrdigen Absendern ist zu prfen, ob der Text der Nachricht
auch zum Absender passt (englischer Text von deutschem Partner, zwei-
felhafter Text oder fehlender Bezug zu konkreten Vorgngen etc.) und ob
die Anlage (Attachment) auch erwartet wurde.
- Die Angabe der Gre von Dateien, sowie einer evtl. auch angegebenen mglichst Gre und
Prfsumme berprfen
Prfsumme, sollte nach einem Download immer berprft werden. Bei
Abweichungen von der vorgegebenen Gre oder Prfsumme ist zu ver-
muten, dass unzulssige Vernderungen vorgenommen worden sind. Daher
sollten solche Dateien sofort gelscht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Beim Austausch von E-Mails sollten mglichst Digitale Signaturen einge-

setzt werden, um die Echtheit und Korrektheit der E-Mail-Inhalte
berprfen zu knnen (M 4.34 Einsatz von Verschlsselung, Checksummen
oder Digitalen Signaturen).
- Alle von Dritten erhaltenen Dateien und Programme sollten vor der Akti- aktuellen Virenscanner
verwenden
vierung mit aktuellem Virenscanner berprft werden. Diese berprfen
auch, ob (bekannte) Trojanische Pferde vorhanden sind (siehe dazu auch
Kapitel 3.6 Computer-Virenschutzkonzept).
- Grundstzlich sollten alle Programme vor Installation und Freigabe auf
Testsystemen berprft werden (M 4.65 Test neuer Hard- und Software).
- Bei CERTs bzw. anderen sicherheitsbezogenen Informationsdiensten sollte
regelmig recherchiert werden, ob eingesetzte Programme dahingehend
aufgefallen sind, dass sie Daten vom IT-System des Benutzers ohne dessen
Wissen bertragen (siehe auch M 2.35 Informationsbeschaffung ber
Sicherheitslcken des Systems). Neben einigen Office-Programmen und
freier Zusatzsoftware sind hier auch Programmbibliotheken aufgefallen,
die Nutzerinformationen an Dritte weitergegeben haben, ohne das dies den
Programmierern, die sie eingesetzt hatten, bekannt gewesen wre.
- Bei der Installation von Programmen sollten die Programmhinweise und
Nutzungsbedingungen sorgfltig durchgelesen werden. Oftmals wird in
diesen sogar (mehr oder weniger deutlich) darauf hingewiesen, dass bei
deren Nutzung Benutzer- oder Systemdaten erhoben und weitergegeben
werden.
- Trojanische Pferde knnen auch in aktive Inhalte von WWW-Seiten (Java, Vorsicht bei aktiven
Inhalten
JavaScript und besonders ActiveX) eingebettet sein, da sie zusammen mit
WWW-Seiten geladen werden, hufig ohne das es der Benutzer bemerkt.
Ein gewisser Schutz kann aber schon dadurch erreicht werden, dass
sichergestellt wird, dass - besonders zu den Zeiten, zu denen man online
arbeitet - nur Prozesse und Programme laufen, die wirklich notwendig sind
und so die zustzlichen Aktivitten des Rechners oder der Festplatte
bemerkt werden. Weiterhin knnen die Einstellmglichkeiten des verwen-
deten Internet Browsers konsequent ausgenutzt werden, so dass beispiels-
weise aktive Inhalte gar nicht erst auf den eigenen Rechner geladen werden
knnen.
- Trojanische Pferde verfolgen hufig den Zweck, Passwrter oder andere Passwrter nicht
abspeichern
Zugangsdaten auszusphen. Daher sollten Passwrter nie auf den IT-
Systemen abgespeichert werden.
Darber hinaus bietet es sich an, die genutzten Speichermedien regelmige
auf unerwartete Vernderungen (neue oder vernderte Dateien, ungewhn-
liches Verhalten) zu kontrollieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.225 Zuweisung der Verantwortung fr

Informationen, Anwendungen und IT-
Komponenten
Verantwortlich fr Umsetzung: Fachverantwortliche, Administrator,
Mitarbeiter
Um zu einer umfassenden Gesamtsicherheit zu gelangen, ist die Beteiligung
aller Mitarbeiter einer Organisation an der Umsetzung der erforderlichen IT-
Sicherheitsmanahmen erforderlich. Fr alle Informationen, Anwendungen
und IT-Komponenten sollte daher festgelegt werden, wer fr diese und deren
Sicherheit verantwortlich ist. Hierfr sollte immer eine konkrete Person und
keine abstrakte Gruppe benannt werden, damit die Zustndigkeit jederzeit
deutlich erkennbar ist. Bei komplexeren Informationen, Anwendungen und
IT-Komponenten sollten alle Verantwortlichen namentlich genannt sein.
Umgekehrt sollten natrlich alle Mitarbeiter wissen, fr welche Infor-
mationen, Anwendungen und IT-Komponenten sie in welcher Weise verant-
wortlich sind.
Jeder Mitarbeiter ist dabei fr das verantwortlich, was in seinem Einfluss-
bereich liegt, es sei denn, es ist explizit anders geregelt. Beispielsweise ist die
Leitungsebene der Organisation verantwortlich fr alle grundstzlichen Ent-
scheidungen bei der Einfhrung einer neuen Anwendung, der Leiter IT
zusammen mit dem IT-Sicherheitsmanagement fr die Ausarbeitung von
Sicherheitsvorgaben, die Administratoren fr deren korrekte Umsetzung und
die Benutzer fr den sorgfltigen Umgang mit den zugehrigen Infor-
mationen, Anwendungen und Systemen.
Die Fachverantwortlichen als die "Eigentmer" von Informationen und
Anwendungen mssen sicherstellen, dass
- der Schutzbedarf der Informationen, Anwendungen und IT-Komponenten
korrekt festgestellt wurde,
- die erforderlichen Sicherheitsmanahmen umgesetzt werden,
- dies regelmig berprft wird,
- die Aufgaben fr die Umsetzung der Sicherheitsmanahmen klar definiert
und zugewiesen werden,
- der Zugang bzw. Zugriff zu den Informationen, Anwendungen und IT-
Komponenten geregelt ist.
Die Fachverantwortlichen mssen zusammen mit dem IT-Sicherheits-
management entscheiden, wie mit eventuellen Restrisiken umgegangen wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.226 Regelungen fr den Einsatz von Fremdpersonal

Verantwortlich fr Umsetzung: Leiter IT, Leiter Personal
Hufig wird in Behrden oder Unternehmen auf externe Untersttzung
zurckgegriffen, falls die entsprechenden personellen Ressourcen nicht im
eigenen Haus vorhanden sind. Dies kann im Extremfall dazu fhren, dass
Fremdpersonal ber so lange Zeitrume im eigenen Haus eingesetzt wird, dass
viele Mitarbeiter schon nicht mehr genau wissen, ob es sich um eigene oder
externe Mitarbeiter handelt.
Externe Mitarbeiter, die ber einen lngeren Zeitraum in einer oder fr eine Einhaltung von Gesetzen
und Vorschriften
Organisation ttig sind und eventuell Zugang zu vertraulichen Unterlagen und
Daten bekommen knnten, sind schriftlich auf die Einhaltung der geltenden
einschlgigen Gesetze, Vorschriften und internen Regelungen zu verpflichten
(siehe auch M 3.2 Verpflichtung der Mitarbeiter auf Einhaltung einschlgiger
Gesetze, Vorschriften und Regelungen).
Beim Einsatz von externen Mitarbeiter muss auerdem auf jeden Fall sicher- Einarbeitung und Ein-
weisung
gestellt sein, dass sie bei Beginn ihrer Ttigkeit - hnlich wie eigene Mit-
arbeiter - in ihre Aufgaben eingewiesen werden (siehe M 3.1 Geregelte Ein-
arbeitung/Einweisung neuer Mitarbeiter). Sie sind - so weit es zur Erfllung
ihrer Aufgaben und Verpflichtungen erforderlich ist - ber hausinterne
Regelungen und Vorschriften zur IT-Sicherheit sowie die organisationsweite
IT-Sicherheitspolitik zu unterrichten. Dies gilt in besonderem Ma, wenn sie
innerhalb der Liegenschaften des Auftraggebers arbeiten.
Daneben sollte sichergestellt sein, dass auch fr externe Mitarbeiter Ver- Vertretungsregelungen
tretungsregelungen existieren (siehe M 3.3 Vertretungsregelungen). Ebenso
sollte gewhrleistet sein, dass sich diese mit den von ihnen eingesetzten IT-
Anwendungen auskennen und auch die erforderlichen IT-Sicherheitsma-
nahmen beherrschen.
Bei Beendigung des Auftragsverhltnisses muss eine geregelte bergabe der geregeltes Verfahren
bei Ende des Auftrags
Arbeitsergebnisse und der erhaltenen Unterlagen und Betriebsmittel erfolgen.
Es sind auerdem smtliche eingerichteten Zugangsberechtigungen und Zu-
griffsrechte zu entziehen bzw. zu lschen. Auerdem sollte der Ausscheidende
explizit darauf hingewiesen werden, dass die Verschwiegenheitsverpflichtung
auch nach Beendigung der Ttigkeit bestehen bleibt (siehe auch M 3.6
Geregelte Verfahrensweise beim Ausscheiden von Mitarbeitern).
Kurzfristig oder einmalig zum Einsatz kommendes Fremdpersonal ist wie
Besucher zu behandeln, d. h. beispielsweise dass der Aufenthalt in sicher-
heitsrelevanten Bereichen nur in Begleitung von Mitarbeitern der Behrde
bzw. des Unternehmens erlaubt ist (siehe auch M 2.16 Beaufsichtigung oder
Begleitung von Fremdpersonen).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden externe Mitarbeiter mit lngerfristigen Aufgaben auf die Ein-
haltung der einschlgigen Gesetze und Vorschriften verpflichtet?
- Werden externe Mitarbeiter geregelt in ihre Aufgaben eingearbeitet und
ber bestehende Regelungen zur IT-Sicherheit unterrichtet?
- Werden bei smtlichen eingerichteten Zugangsberechtigungen die
Zugriffsrechte bei Auftragsende entzogen bzw. gelscht?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.227 Planung des Windows 2000 Einsatzes

Vor der Einfhrung eines Windows 2000 Systems, welches aus vernetzten,
einzelnen Windows-Rechnern aufgebaut ist, sind umfangreiche Planungen
durchzufhren, damit eine geregelte und auch sichere Einfhrung sowie in
Folge ein sicherer Betrieb ermglicht wird. Im Rahmen der Windows 2000
Planung sind abhngig von den geplanten Einsatzszenarien fr Windows 2000
Systeme verschiedene Gesamt- und Einzelkonzepte zu erstellen. Dabei ist aus
Sicherheitssicht jeweils zu gewhrleisten, dass die festgelegten Sicherheits-
richtlinien (siehe M 2.228 Festlegen einer Windows 2000 Sicherheitsricht-
linie) eingehalten und in der Planung bercksichtigt werden, so dass eine
richtlinienkonforme Umsetzung erfolgen kann.
Die Planung eines Windows 2000 Systems erfolgt in mehreren Schritten nach Planung vom
Grobkonzept zu
dem Prinzip des Top-Down-Entwurfes: Ausgehend von einem Grobkonzept Teilkonzepten
fr das Gesamtsystem werden konkrete Planungen fr Teilkomponenten in
spezifischen Teilkonzepten festgelegt.
Im Grobkonzept werden beispielsweise folgende typische Fragestellungen
behandelt:
- Wird ein neues Netz aufgebaut oder wird ein bestehendes Netz migriert?
- Soll ein existierendes Windows Netz (z. B. Windows NT basiert) vollstn-
dig oder nur teilweise nach Windows 2000 migriert werden?
- Welche Komponenten, z. B. Server, Druckserver, Arbeitsplatzrechner,
werden ersetzt, welche bleiben erhalten?
- Mssen existierende Verfahren oder Komponenten, wie z. B. ein beste- Integration in
bestehende Umgebung
hendes Kerberos-System oder auch eine bestehende PKI, in Windows 2000
integriert werden? Hier ist u. a. die Interoperabilitt sowie der angebotene
Funktionsumfang zu bercksichtigen.
- Ist ein Mischbetrieb von Windows 2000 und anderen Betriebssystemen, Mischbetrieb mit
anderen Systemen
wie Windows 9x/ME/NT/WfW, OS/2, Novell oder Unix, notwendig? Ist
dies der Fall, so hat dies u. a. Einfluss auf die im System verwendeten
Authentisierungsverfahren, die je nach den anderen eingesetzten Betriebs-
systemen auch Schwachstellen aufweisen und damit die Sicherheit des
gesamten Windows 2000 Systems schwchen knnen.
- Muss Windows 2000 mit existierenden Windows NT Domnen, z. B. mit mixed mode oder native
mode
Backup-Domnen-Controllern, zusammenarbeiten? Dies hat Einfluss auf
den Modus (Mixed-Mode, Native-Mode), in dem eine Domne betrieben
werden muss. Je nach Modus sind dann einige Sicherheitsmechanismen
nicht verfgbar.
Die folgenden typischen Teilkonzepte sind fr Windows 2000 zu bercksich-
tigen, wobei sich die jeweiligen Empfehlungen zu den Teilkonzepten in spezi-
fischen Manahmen befinden:
- Das Active Directory Konzept: Mit Windows 2000 wurde das Active
Directory (AD) als zentraler Datenspeicher zur Systemverwaltung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
eingefhrt. Technisch gesehen ist die AD-Installation einfach und

problemlos durchzufhren. Durch die zentrale Stellung des AD innerhalb
von Windows 2000 und insbesondere dadurch, dass Domnen unter
Windows 2000 nun global verwaltet, sowie hierarchisch und baumartig
angeordnet werden knnen, ergeben sich allerdings eine Vielzahl
organisatorischer und unternehmenspolitischer Problemstellungen. Diese
erfordern eine ausgedehnte Planungsphase fr das AD-Konzept. Dabei ist
ein Zeitrahmen von ein bis zwei Jahren fr global operierende
Unternehmen und Behrden durchaus als minimaler Planungszeitraum
einzukalkulieren.
Aus Sicherheitssicht stellt das AD eine wichtige Schaltzentrale fr ein Active Directory als
Schaltzentrale
Windows 2000 System dar, da durch die Berechtigungen im AD
administrative Delegationen erreicht werden knnen. Zudem erlaubt der
Mechanismus der Gruppenrichtlinien (vergleichbar mit den Windows NT
Systemrichtlinien) eine feingranulare Konfiguration auch der
Sicherheitseinstellungen eines Windows 2000 Systems. Auch hier ist eine
zentrale Verwaltung der Sicherheitseinstellungen mglich.
Das AD erfordert neben der eigentlichen Planung der AD-Struktur (siehe
M 2.229 Planung des Active Directory) noch die Planung weiterer
Teilkonzepte fr die im AD verwendeten Sicherheitsmechanismen. Es sind
dies das Konzept fr die AD-Administration (siehe M 2.230 Planung der
Active Directory-Administration), in dem u. a. auch die Rechtevergabe auf
AD-Objekten geregelt wird, sowie das Konzept fr die Gruppenrichtlinien
(siehe M 2.231 Planung der Gruppenrichtlinien unter Windows 2000), in
denen u. a. die Sicherheitseinstellungen fr alle Windows 2000 Systeme
und deren Verteilung geregelt werden. Des Weiteren mssen im Rahmen
des AD-Administrationskonzeptes insbesondere auch Regeln fr die
Zugehrigkeit zu den verschiedenen administrativen Gruppen erstellt
werden. Hier ist u. a. festzugelegen, wer Mitglied in den von Windows
2000 vordefinierten Gruppen, wie z. B. Organisations-Admins, und den
selbst definierten Gruppen sein soll.
- Das PKI-Konzept: Windows 2000 bietet PKI-Komponenten im PKI-Konzept
Standardlieferumfang an, die zum Aufbau einer unternehmensweiten PKI
(Public Key Infrastruktur) genutzt werden knnen. Die dabei verwendeten
Zertifikatsausgabestellen (Certificate Authority, CA) knnen sowohl von
Windows 2000 Systemkomponenten, z. B. von den EFS-Komponenten, als
auch von externen Komponenten, also z. B. bei Kunden oder
Geschftspartnern, und von Komponenten von Drittherstellern, wie z. B.
E-Mail-Programmen, verwendet werden. Im Rahmen des PKI-Konzeptes
(siehe M 2.232 Planung der Windows CA-Struktur) ist dabei die
hierarchische Struktur von CAs, deren Vertrauensstellungen zueinander,
sowie der Einsatzzweck und die Verteilung von Zertifikaten an Benutzer
und innerhalb des Systems zu regeln.
- Das DNS/WINS/DHCP-Konzept: Neben dem AD ist eine weitere DNS, WINS und DHCP
grundstzliche Neuerung innerhalb von Windows 2000, dass als primrer
Namensdienst zur Zuordnung von Rechnernamen zu IP-Adressen DNS
(Domain Name Service) genutzt wird. Insbesondere gilt, dass ohne DNS
kein Windows 2000 AD aufgebaut werden kann. Dabei muss jedoch nicht
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zwingend die Windows 2000 DNS-Komponente eingesetzt werden,

sondern es kann auch eine externe DNS-Implementierung (z. B. Unix-
basiert) zum Einsatz kommen. Allerdings muss die Fremdimplementierung
gewissen Anforderungen gengen. So mssen z. B. so genannte SRV-
Records und dynamische Updates von DNS-Eintrgen untersttzt werden.
Da die Domnennamen einer Windows 2000 Domnenhierarchie mit dem
hierarchischen DNS-Namensraum bereinstimmen, beeinflussen sich AD-
Konzept und DNS-Konzept mageblich. Zustzlich muss im DNS-Konzept
bercksichtigt werden, ob der bisherige Namensdienst WINS (Windows
Internet Naming Service) - der fr den Betrieb von Windows 2000
Systemen nicht mehr notwendig ist - aus Grnden der
Rckwrtskompatibilitt weiter betrieben werden muss. Grnde hierfr
knnen z. B. Applikationen sein, die zwingend WINS bentigen.
Auerdem ist die Integration des DNS mit dem DHCP (Dynamic Host
Configuration Protocol) zu planen, mit dem der Rechner automatisch nach
dem Einschalten fr den Netzzugriff konfiguriert wird. Unter dem
Gesichtspunkt der Sicherheit sind jeweils die berechtigten Administratoren
und die Verwendung der einzelnen komponentenspezifischen
Sicherheitsmechanismen festzulegen. Hinweise zu den Einzelkonzepten
werden genauer in M 4.140 Sichere Konfiguration wichtiger Windows
2000 Dienste und den darin referenzierten Manahmen gegeben.
- Das RAS-Konzept: Auch Windows 2000 bietet Komponenten, um den RAS-Konzept
entfernten Zugang zu einem lokalen Netz zu realisieren. Im Vergleich zu
der aus Windows NT bekannten Lsung sind keine gravierenden
nderungen zu verzeichnen. Insbesondere aus Sicherheitssicht ergeben
sich kaum Unterschiede. Als wesentliche Neuerung ist lediglich die
Verfgbarkeit starker Verschlsselung zu nennen, die nach Einspielen des
so genannten "High-Encryption-Pack" und des "Service Pack 1" zur
Verfgung steht. Alternativ kann auch das mittlerweile verfgbare Service
Pack 2 genutzt werden, das die strkere Verschlsselung integriert enthlt.
Fr die Konfiguration der Zugangskontrolle steht eine neue regelgesteuerte
Mglichkeit zur Verfgung, die in Manahme M 4.145 Sichere
Konfiguration von RRAS unter Windows 2000 erlutert wird. Fr generelle
Empfehlungen und Manahmen zum Themenkomplex Remote Access
existiert ein entsprechender Baustein in Kapitel 7.6.
- Das NTFS-Konzept: Auch unter Windows 2000 wird das Windows NT- NTFS-Konzept
File System (NTFS) eingesetzt, das im Vergleich zu der unter Windows
NT eingesetzten Vorgngerversion einige Neuerungen auch
sicherheitstechnischer Art bietet. Einerseits knnen Dateiberechtigungen
und berwachungseinstellungen unter Windows 2000 nun wesentlich
detaillierter erfolgen, andererseits besteht mit dem Dateisystem EFS die
Mglichkeit der Dateiverschlsselung. Daneben steht das verteilte
Dateisystem DFS, das auch schon unter Windows NT verwendet werden
konnte, unter Windows 2000 integriert zur Verfgung. Entsprechende
Manahmen fr die sicherheitsrelevanten Neuerungen finden sich unter
M 3.28 Schulung zu Windows 2000 Sicherheitsmechanismen fr Benutzer,
M 4.140 Sichere Konfiguration wichtiger Windows 2000 Dienste,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.147 Sichere Nutzung von EFS unter Windows 2000, sowie unter
M 4.148 berwachung eines Windows 2000 Systems.
- Das Migrations-Konzept: Der vllige Neuaufbau eines Windows 2000 Migrations-Konzept
Systems stellt normalerweise nicht den Regelfall dar. Vielmehr besteht
regelmig der Wunsch oder die Notwendigkeit, existierende, meist
Windows NT-basierte Netze auf Windows 2000 umzustellen. Dabei muss
die so genannte Migration sorgfltig geplant, vorbereitet und durchgefhrt
werden. Eine allgemeine Empfehlung, welche der verschiedenen Migrati-
onskonzepte zur Anwendung kommen sollen, kann nicht gegeben werden,
da dies vom zu migrierenden Netz abhngt. Generell muss jedoch schon
bei der Planung des Windows 2000 Netzes bedacht werden, dass das Netz
ber einen lngeren Zeitraum als heterogenes Netz betrieben werden muss,
das migrierte und auch nicht migrierte Komponenten enthalten wird.
Insbesondere ist zu beachten, dass whrend der Migration die Sicherheit
des Systems - im Vergleich zu einem reinen Windows 2000 System -
gefhrdet sein kann. Dies geschieht u. U. durch Fehler bei der Migration,
durch nicht kompatible Konfigurationsparameter oder aber durch die
Notwendigkeit der Rckwrtskompatibilitt fr Sicherheitseinstellungen.
Hinweise zu typischen Sicherheitsproblemen bei der Migration sind in
M 2.233 Planung der Migration von Windows NT auf Windows 2000 zu
finden.
- Das Auditing/Protokollierungs-Konzept: Um die Sicherheit in einem Auditing und
Protokollierung
Windows 2000 System gewhrleisten zu knnen, muss das Einhalten der
festgelegten Sicherheitsrichtlinien (siehe M 2.228 Festlegen einer Windows
2000 Sicherheitsrichtlinie) berwacht werden. Dazu stellt Windows 2000,
wie auch schon Windows NT, einen ereignisbasierten Protokollierungs-
Mechanismus zur Verfgung. Die im Rahmen eines Auditing-Konzeptes
zu beachtenden Sicherheitsaspekte sind in der Manahme
M 4.148 berwachung eines Windows 2000 Systems zusammengefasst.
- Das IPSec-Konzept: Fr die Kommunikationsabsicherung auf Transport- IPSec-Konzept
ebene stellt Windows 2000 eine IPSec-konforme Implementierung zur
Verfgung. Durch IPSec knnen alle IP-basierten Kommunikationsver-
bindungen von und zu einem Rechner abgesichert werden. Dabei ist es
mglich, die Endpunkte der Kommunikation zu authentisieren und die
Datenpakete signiert und verschlsselt zu bertragen, so dass die Integritt
und Vertraulichkeit der Daten gewhrleistet werden kann. Empfehlungen
fr die Konfiguration der IPSec-Komponenten sind in Manahme
M 5.90 Einsatz von IPSec unter Windows 2000 zusammengefasst.
Neben diesen Teilkonzepten knnen je nach Einsatzszenario auch weitere
Konzepte notwendig werden, wie z. B. Internet-Konzept oder Software-
verteilungs-Konzept, die dann in der Planungsphase bercksichtigt werden
mssen. So basiert beispielsweise die Windows 2000 Authentisierung auf dem
Kerberos-Protokoll. Hierbei werden Zeitstempel benutzt, um u. a. die Gltig-
keit von Authentisierungsdaten zu beschrnken. Daher mssen die System-
uhren aller Rechner, die mit Kerberos arbeiten, innerhalb eines Toleranz-
intervalls synchronisiert sein. Standardmig erfolgt der regelmige Uhren-
abgleich automatisch durch Windows 2000 selbst. Sofern jedoch auf eine
externe Zeitquelle synchronisiert werden soll, ist dazu ein Konzept zu
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
entwerfen, das alle notwendigen Randbedingungen umfasst. Dies sind

beispielsweise Zeitserver, Verfahren beim Ausfall des Zeitservers und
Toleranzintervalle.
- Wurde die Windows 2000 Planung bedarfsgerecht durchgefhrt?
- Sind alle fr den konkreten Einsatz notwendigen Teilkonzepte entworfen?
- Wurde die AD-Struktur mit allen Betroffenen abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.228 Festlegen einer Windows 2000 Sicherheits-

richtlinie
Das Festlegen einer Sicherheitsrichtlinie fr Windows 2000 ist eine der
organisatorischen Hauptaufgaben bei der Windows 2000 Planung. Durch die
Sicherheitsrichtlinie wird festgelegt, welche Sicherheitsbestimmungen in
einem Windows 2000 System gelten sollen und bei der Windows 2000
Installation umgesetzt werden mssen.
Durch die Windows 2000 Sicherheitsrichtlinie werden smtliche sicherheits-
bezogenen Themenbereiche eines Windows 2000 Systems geregelt. Die
folgende Liste gibt einen groben berblick ber die abzudeckenden Bereiche.
Die Liste muss je nach Unternehmen und Windows 2000 Einsatzszenarien
entsprechend angepasst, ausgestaltet und erweitert werden.
Eine Windows 2000 Sicherheitsrichtlinie sollte fr folgende Windows 2000
spezifischen Bereiche Regelungen treffen:
Allgemein:
- Wie sollen Windows 2000 Rechner physikalisch abgesichert werden?
- Welche Windows 2000 Komponenten, z. B. RAS, IIS, sollen genutzt
werden?
- Welcher Benutzer darf welche Rechte ausben?
- Welcher Administrator darf welche Rechte ausben?
- Welche Datenkommunikation ist abgesichert abzuwickeln, also wo muss
Vertraulichkeit und Integritt sichergestellt sein?
- Wo ist Authentikation erforderlich? Welche Authentisierungsverfahren
sollen gewhlt werden?
Active Directory (AD):
- Welche Rechner sind Domnen-Controller und halten eine AD Kopie?
- Wer hat welchen Zugriff auf das AD?
- Wer darf welche administrativen Aufgaben auf Objekten im AD
ausfhren?
- Welche Domnenstruktur (Domne, Baum, Wald) soll gewhlt werden?
- Welche Vertrauensstellungen zwischen Domnen drfen bzw. mssen
existieren?
- Sollen Berechtigungen domnenbergreifend vergeben werden?
DNS/DHCP/WINS:
- Welche DNS-Server sollen Daten miteinander austauschen?
- Welcher Server ist fr welche DNS-Zone verantwortlich?
- Welche Rechner sollen DHCP verwenden drfen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Drfen DHCP-Clients eigenstndig DNS-Updates machen?

- Soll neben DNS auch WINS weiter betrieben werden?
- Wer verwaltet DNS, DHCP und WINS?
Kerberos:
- Welche Kerberos-Parameter sind zu verwenden?
- Wer darf Kerberos-Einstellungen ndern?
Dateisystem:
- Welche Berechtigungen auf Systemdateien gelten fr die verschiedenen
Administratoren und Benutzer?
- Soll das verschlsselnde Dateisystem (EFS) eingesetzt werden?
- Fr welche Daten soll EFS eingesetzt werden?
RAS:
- Welche Rechner sollen als RAS-Einwahlrechner fungieren?
- Welche Benutzer drfen sich unter welchen Bedingungen ber RAS
einwhlen?
- Welche RAS-Sicherheitsmechanismen sollen benutzt werden, um die
RAS-Kommunikation abzusichern?
- Welches Authentisierungsverfahren (z. B. MS-CHAP, PAP, RADIUS) soll
fr RAS eingesetzt werden?
Netz-Zugriff:
- Auf welche Rechner darf vom Netz aus zugegriffen werden?
- Welche Ressourcen sind aus dem Netz von welchen Benutzern zugreifbar?
- Welchen Rechnern wird fr die Delegation, d. h. das stellvertretende
Handeln unter einer Benutzeridentitt, vertraut?
- Welche Authentisierungsverfahren sollen eingesetzt oder erlaubt werden
(Kerberos, NTLM Version 1 oder 2, LanMan)?
- Welche Benutzer drfen welche externen Dienste, z. B. den Internetzugriff,
nutzen?
Diese fr Windows 2000 Komponenten spezifische Auflistung von
Themengebieten kann in folgende zeitliche Abfolge gebracht werden:
1. Definition der Client-Server-Netzstruktur
Im ersten Schritt ist die logische Struktur des Client-Server-Netzes, insbeson-
dere die Zuordnung der Server und der Netz-Domnen festzulegen (siehe
M 2.227 Planung des Windows 2000 Einsatzes). Nach Mglichkeit sollte auf
die Verwendung von Peer-to-Peer-Funktionalitten verzichtet werden, da
diese die Sicherheit des Client-Server-Netzes beeintrchtigen knnen. Sofern
sich dies jedoch nicht vermeiden lsst, sind verbindliche Regelungen fr die
Nutzung von Peer-to-Peer-Funktionalitten zu treffen (siehe M 2.67 Fest-
legung einer Sicherheitsstrategie fr Peer-to-Peer-Dienste).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Ein Client-Server-Netz sollte von geschulten Netzadministratoren sicher
betrieben werden. Dabei ist im Rahmen der Notfallvorsorge fr eine geeignete
Stellvertreterregelung zu sorgen. Nur die berechtigten Administratoren drfen
Windows 2000 Sicherheitsparameter verndern. Sie sind z. B. dafr zustndig,
auf den Servern den entsprechenden Verantwortlichen Administrationsrechte
und -werkzeuge zur Verfgung zu stellen, damit diese die Vergabe von Datei-
und Verzeichnisberechtigungen, die Freigabe der von anderen bentigten
Verzeichnissen bzw. Anwendungen, den Aufbau von Benutzergruppen und
-konten sowie die Einstellung der Systemrichtlinien fr Benutzer, Zugriffs-
kontrolle und berwachung vornehmen knnen.
Die Verantwortlichkeiten der einzelnen Administratoren und Benutzer im
Client-Server-Netz sind unter Schritt 11 dargestellt.
Um die Verwaltung des Client-Server-Netzes zu erleichtern, sollten eindeutige
Namen fr die Rechner, Benutzergruppen und die Benutzer verwendet
werden.
Zustzlich sollten Namenskonventionen fr die Freigabenamen von Verzeich-
nissen oder Druckern eingefhrt werden. Sollen keine Rckschlsse auf den
Inhalt eines freigegebenen Verzeichnisses mglich sein, sind entsprechende
Pseudonyme zu verwenden. Soll eine freigegebene Ressource nicht als solche
erkennbar sein, ist dem Freigabenamen das Zeichen "$" anzuhngen. Letzteres
empfiehlt sich immer dann, wenn Verzeichnisse nur zum bilateralen
Austausch von Informationen zwischen zwei Anwendern oder zum Zugriff
auf Ressourcen, die nur einzelnen Benutzern bekannt sein sollen, freigegeben
werden. Es wird explizit darauf hingewiesen, dass das "Verstecken" von Netz-
freigaben nicht als Sicherheitsmechanismus angesehen oder benutzt werden
kann. Die Sicherheit der ber eine Netzfreigabe verfgbar gemachten Daten
muss durch entsprechende Zugriffsrechte gewhrleistet werden.
bzw. fr bestimmte Konten gelten sollen, festgelegt werden. Dies betrifft
insbesondere die Regelungen fr Passwrter und fr die Reaktion des Systems
auf fehlerhafte Login-Vorgnge. Unter Windows 2000 erfolgen diese
Einstellungen bevorzugt ber Gruppenrichtlinien im Active Directory (siehe
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000) oder fr nicht
vernetzte Systeme ber die Konfiguration der lokalen Sicherheitsrichtlinien in
der Programmgruppe Verwaltung.
Zur Vereinfachung der Administration sollten Benutzerkonten, fr die die
gleichen Anforderungen gelten, zu Gruppen zusammengefasst werden.
Benutzerrechte sowie Datei-, Verzeichnis- und Freigabeberechtigungen und
ggf. weitere vordefinierte Funktionen werden dann den Gruppen und nicht
einzelnen Benutzerkonten zugeordnet. Die Benutzerkonten erben die Rechte
und Berechtigungen der Gruppen, denen sie angehren. So ist es z. B. denk-
bar, alle Mitarbeiter einer Abteilung in einer Gruppe zusammenzufassen. Eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Zuweisung von Benutzerrechten und -berechtigungen an einzelne Benutzer

sollte nur erfolgen, wenn dies ausnahmsweise unumgnglich ist.
Die Verwaltung von Gruppen von Benutzern oder Rechnern erfolgt unter
Windows 2000 ber das Active Directory (siehe M 2.229 Planung des Active
Directory).
6. Festlegung der Benutzerrechte
Rechte gestatten einem Benutzer die Ausfhrung bestimmter Aktionen auf
dem System. Sie beziehen sich auf das gesamte System, sind keinem speziel-
len Objekt zugeordnet und knnen die Berechtigungen fr ein Objekt auer
Kraft setzen, da ein Recht Vorrang vor allen Datei- und Verzeichnisberechti-
gungen hat. Wenn sich ein Benutzer bei einem Konto anmeldet, dem die
gewnschten Rechte entweder direkt oder ber die Gruppenmitgliedschaft
erteilt wurden, kann er die entsprechenden Aktionen ausfhren. Besitzt ein
Benutzer nicht die geeigneten Rechte, so verhindert Windows 2000 jeden Ver-
such, die betreffenden Aktionen auszufhren.
Die Konfiguration der Benutzerrechte erfolgt unter Windows 2000
vorzugsweise ber Gruppenrichtlinien im Active Directory (siehe
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000) oder bei nicht
vernetzten Rechnern ber die Konfiguration der lokalen Sicherheitsrichtlinie.
Windows 2000 stellt sehr ausfhrliche Mglichkeiten der Protokollierung
sicherheitsrelevanter Ereignisse zur Verfgung. Diese sind bei vollstndiger
Nutzung in der Lage, das System weitgehend mit der Protokollierung
auszulasten und dabei groe Mengen an Plattenplatz zu verbrauchen. Dabei
kann ein Spektrum von Ereignisarten aufgezeichnet werden, das sich von
systemweiten Ereignissen, wie zum Beispiel dem Anmelden eines Benutzers
bis hin zum Versuch eines Benutzers, eine bestimmte Datei zu lesen, erstreckt.
Sowohl die erfolgreichen als auch die fehlgeschlagenen Versuche, eine Aktion
durchzufhren, lassen sich aufzeichnen. Bei der Festlegung der jeweils
rechnerlokalen Protokolleinstellungen ist auf die Vertrglichkeit mit dem
Gesamtkonzept der Systemberwachung (siehe M 4.148 berwachung eines
Windows 2000 Systems) zu achten.
Die Konfiguration der Protokolleinstellungen (z. B. Aktivierung der
Protokollmglichkeit, Gre der Protokolldateien, Protokolleinstellungen pro
Datei) erfolgt unter Windows 2000 vorzugsweise ber Gruppenrichtlinien im
Active Directory (siehe M 2.231 Planung der Gruppenrichtlinien unter
Windows 2000) oder bei nicht vernetzten Rechnern ber die Konfiguration der
lokalen Sicherheitsrichtlinie.
Strukturierte Datenhaltung). So ist es denkbar, dass Benutzerdaten nur auf
einem Server abgelegt werden. Eine Datenspeicherung auf der lokalen
Festplatte ist bei diesem Modell nicht erlaubt. Mglich ist aber auch,
bestimmte Benutzerdaten nur auf der lokalen Festplatte abzulegen. Nach
welcher Strategie verfahren werden soll, muss an den konkreten Umstnden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
des Einzelfalles festgelegt werden. Eine generelle Empfehlung auszusprechen,

ist nicht mglich.
Um eine saubere Trennung von Benutzer- und projektspezifischen Daten
untereinander sowie von den Programmen und Daten des Betriebssystems
durchzusetzen, sollte eine geeignete Verzeichnisstruktur festgelegt werden,
mit der eine projekt- und benutzerbezogene Dateiablage untersttzt wird. So
knnen beispielsweise zwei Hauptverzeichnisse \Projekte und \Benutzer ange-
legt werden, unter denen dann die Dateien und Verzeichnisse der Projekte
bzw. Benutzer in jeweils eigenen Unterverzeichnissen abgelegt werden.
Fr die Server ist festzulegen, welche Verzeichnisse - und bei Nutzung von
NTFS-Partitionen - welche Dateien fr den Betrieb freizugeben und welche
Zugriffsrechte ihnen zuzuweisen sind (siehe M 4.145 Sichere Konfiguration
von RRAS unter Windows 2000). Zustzlich ist bei Nutzung von Peer-to-Peer-
Funktionalitten auf der Ebene der Clients zu entscheiden, welche Verzeich-
nisse fr Netzzugriffe freizugeben sind. Gleiches gilt fr die Freigabe von
Druckern.
11. Verantwortlichkeiten fr Administratoren und Benutzer im Client-
Server-Netz
welche Verantwortung die einzelnen Administratoren im Client-Server-Netz
- die Verwaltung des Active Directory oder einzelner Active Directory Teil-
komponenten,
Clients,
Auch die Endbenutzer mssen in einem Client-Server-Netz bestimmte Verant-
wortlichkeiten bernehmen, sofern ihnen Rechte zur Ausfhrung administrati-
ver Funktionen gegeben werden. In der Regel beschrnken sich diese Verant-
wortlichkeiten jedoch auf die Vergabe von Zugriffsrechten auf die eigenen
Dateien, sofern diese explizit festgelegt und nicht von Voreinstellungen des
bergeordneten Verzeichnisses bernommen werden.
12. Schulung
Abschlieend muss festgelegt werden, welche Benutzer zu welchen Punkten
geschult werden mssen. Erst nach ausreichender Schulung kann der Wirkbe-
trieb aufgenommen werden. Insbesondere die Administratoren sind hinsicht-
lich der Verwaltung und der Sicherheit von Windows 2000 grndlich zu
schulen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die daraus entwickelten Sicherheitsrichtlinien sind zu dokumentieren und im

erforderlichen Umfang den Benutzern des Client-Server-Netzes mitzuteilen.
Bei der Definition der Sicherheitsrichtlinie ist zu beachten, dass sich die fr
Windows 2000 festgelegten Richtlinien an den bisher geltenden Sicherheits-
richtlinien der Organisation orientieren, diesen nicht widersprechen (Konsis-
tenz) und auch nicht im Widerspruch zu geltendem Recht stehen. In der Regel
wird eine Windows 2000 Sicherheitsrichtlinie existierende Regelungen
Windows 2000-spezifisch anpassen oder aber sinngem erweitern. Dabei
sind unter Umstnden neue Regelungen fr neue Windows 2000 spezifische
Funktionalitten, z. B. fr das Active Directory, zu treffen. Generell gilt, dass
sich die Planung der Windows 2000 Infrastruktur an den jeweiligen Sicher-
heitsrichtlinien orientiert, dabei jedoch auch Einfluss auf die Sicherheitsricht-
linien besitzt (Feedback-Prozess).
- Sind alle fr den geplanten Einsatz von Windows 2000 relevanten Bereiche
durch die Sicherheitsrichtlinien abgedeckt?
- Wurden zeitliche Abhngigkeiten fr die Umsetzung der Sicherheitsricht-
linien bercksichtigt?
- Sind alle Benutzer auf die Windows 2000 Sicherheitsrichtlinien vorbereitet
worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.229 Planung des Active Directory

Das Active Directory (AD) ist der zentrale Datenspeicher fr smtliche
Verwaltungsdaten einer Windows 2000 Domne. Abstrakt gesehen, bildet das
AD eine hierarchisch und baumartig organisierte, Objekt-basierte Datenbank.
Es ist an den Verzeichnisdienst-Standard X.500 angelehnt, von dem es die
interne Struktur und den internen Aufbau entliehen hat. Es ist jedoch kein
X.500 kompatibler Verzeichnisdienst.
Das Windows 2000 Domnenkonzept gleicht auf Domnenebene prinzipiell Domnen
dem Windows NT Domnenkonzept: in einer Domne werden Rechner und
Benutzer zusammengefasst und knnen durch den Domnenadministrator
verwaltet werden. Eine Domnengrenze bildet grundstzlich eine administra-
tive Grenze und begrenzt auch den Wirkungsbereich von Berechtigungen.
Zustzlich zu diesem Konzept bietet Windows 2000 an, Domnen baumartig
miteinander in Beziehung zu setzen, so dass Vater-Kind-Beziehungen
zwischen Domnen bestehen knnen. Eine Kind-Domne wird dabei auch als
Sub-Domne bezeichnet, da sich der Name der Kind-Domne aus dem Namen
der bergeordneten Domne ableitet, indem diesem Namen der Name der
Domne durch einen Punkt getrennt angehngt wird.
Beispiel:
Name der Vater-Domne: unternehmen.de
Name der Sub-Domne: verwaltung.unternehmen.de
Der so aufgespannte Namensraum ist mit dem zugehrigen DNS Namensraum Tree
identisch und kann auch nicht verschieden von diesem gebildet werden.
Domnen, die einen gemeinsamen Namensstamm besitzen, bilden einen
Windows 2000 Baum (englisch Tree).
Domnen, die in mehreren Bumen angesiedelt sind - also unterschiedliche Forest

Namensrume aufspannen - knnen dennoch gemeinsam verwaltet werden.
Derart zusammengeschlossene Domnenbume bilden einen Wald (englisch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Forest). Insbesondere bildet eine einzige alleinstehende Domne auch einen

Baum und gleichzeitig auch einen Wald.
In einem Wald gibt es immer eine ausgezeichnete Domne, die eine gewisse Forest-Root-Domne
Sonderstellung besitzt. Es ist die als erstes erzeugte Domne, die auch als
Forest-Root-Domne (FRD, Wurzel-Domne des Waldes) bezeichnet wird.
Die Sonderstellung besteht darin, dass Administratoren der FRD im gesamten
Forest weitreichende Berechtigungen besitzen. Fr die Mitglieder der Gruppe
Organisations-Admins stellen die Domnengrenzen keine administrativen
Grenzen dar, da sie in allen Domnen Zugriffsrechte besitzen. Beim Aufbau
eines Windows 2000 Domnenverbundes ist zu bedenken, dass die zuerst
erzeugte Domne immer die FRD ist. Insbesondere kann die "Rolle" der FRD
nachtrglich nicht auf eine andere Domne "bertragen" werden, so dass die
Domnenstruktur ggf. vollstndig in der gewnschten Form neu erzeugt
werden muss.
Das AD besteht aus verschiedenen Objekten, den Active Directory Objekten Active Directory Objekte
(ADOs). Jedes Objekt besitzt einen ausgezeichneten Typ, wie z. B. Benutzer-
objekt oder Rechnerobjekt, und ist gem dieses Typs aus verschiedenen
Attributen zusammengesetzt. Die verschiedenen Objektattribute knnen
verschiedene Werte aufnehmen, wie z. B. Telefonnummer oder IP-Adresse.
Das AD kennt verschiedene vordefinierte Objekttypen:
- Domnen-Objekt: Dieses Objekt ist die Wurzel aller AD-Objekte einer
Domne und enthlt Informationen ber die Domne, wie z. B. den
Namen. Unterhalb eines Domnen-Objektes knnen andere Objekte ange-
ordnet sein.
- Gruppierungs-Objekte: Diese Objekte dienen dazu, andere Objekte zu
gruppieren. Standardmig steht das Objekt Organisations-Einheit
(Organizational Unit, OU) zur Verfgung. Unterhalb eines OU-Objektes
knnen weitere OU-Objekte enthalten sein, sowie Rechner-, Benutzer- und
Benutzer-Gruppen-Objekte.
- Rechner-Objekt: Durch dieses Objekt werden Windows 2000 Rechner
reprsentiert. Unterhalb eines Rechner-Objektes knnen keine weiteren
Objekte mehr angeordnet sein. Das Windows 2000 Active Directory ist nur
auf die Verwaltung von Windows Rechnern ausgelegt, so dass Rechner-
Objekte ausschlielich Windows Rechner reprsentieren knnen, die mit
dem Active Directory zusammenarbeiten. Dies sind standardmig
Rechner mit den Betriebssystemen Windows 2000 und Windows NT. Fr
andere Versionen von Windows, wie z. B. Windows 98, stehen Active
Directory Anmeldekomponenten zur Verfgung.
- Benutzer-Objekt: Durch dieses Objekt werden Windows 2000 Benutzer
reprsentiert. Unterhalb eines Benutzer-Objektes knnen keine weiteren
Objekte mehr angeordnet sein.
- Benutzer-Gruppen-Objekte: Durch diese so genannten Sicherheits-Grup-
pen werden Windows 2000 Gruppen reprsentiert. Es gibt verschiedene
Gruppentypen, die sich im Geltungsbereich (domnen-, forestweit) und in
den mglichen Gruppenmitgliedern (Domnen-, Forest-Objekte) unter-
scheiden. Es wird unterschieden zwischen lokalen, domnen-lokalen,
globalen und universalen Gruppen. Sicherheits-Gruppen werden dazu
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
benutzt, Berechtigungen zu vergeben. Im Vergleich zu Windows NT ist in

einem Windows 2000 System mit einer deutlich hheren Anzahl von
Gruppen zu rechnen (mehrere zehntausend fr grere Unternehmen), so
dass u. U. ber eine werkzeuggesttzte Verwaltung nachgedacht werden
muss. Diese kann sowohl ber selbst geschriebene Skripte, als auch ber
Produkte von Drittherstellern erfolgen. Ob und welche Werkzeuge hier
sinnvoll sind, muss jedoch im Einzelfall entschieden werden.
Der generelle AD-Aufbau lsst sich wie folgt darstellen:
- Das Domnen-Objekt ist die Wurzel des AD-Baumes einer Domne.
- Unter dem Domnen-Objekt werden OU-Objekte erzeugt, um Rechner-,
Benutzer- und Benutzer-Gruppen-Objekte strukturiert zusammenzufassen.
Da OU-Objekte geschachtelt werden knnen, ergibt sich eine organi-
sationsspezifische Baumstruktur.
Nach einer Standardinstallation existiert eine einfache und flache AD- Anpassung an
administrative
Struktur, die von Windows 2000 angelegt wird und dann entsprechend der Gegebenheiten
AD-Planung verndert werden muss. Da das AD primr der Verwaltung eines
Windows 2000 Systems dient, sollte beim Aufbau der AD-Struktur darauf
geachtet werden, dass die Struktur vornehmlich auf administrative Gegeben-
heiten abgestimmt wird. Wenn stattdessen zwanghaft die organisatorische
Behrden- bzw. Unternehmensstruktur bis ins Kleinste nachgebildet wird,
kann dies zu Problemen in der Administration fhren.
Die mglichen Anordnungen von AD-Objekten, d. h. die Festlegung welches AD-Schema
Objekt welche anderen Objekte enthalten darf, welche Attribute existieren und
aus welchen Attributen Objekte zusammengesetzt werden, wird durch das so
genannte AD-Schema definiert. Das von Microsoft vorgegebene AD-Schema
kann auch verndert werden. Dies stellt jedoch einen gravierenden Eingriff in
das AD dar, der nur nach sorgfltiger Planung durchgefhrt werden darf. Eine
Schema-nderung wirkt sich in allen gemeinsam verwalteten Domnen, d. h.
im Wald bzw. Forest, aus. Da die Schemanderung eine kritische Operation
ist, kann diese nur an genau einem Rechner, dem so genannten Schema-
Master, durch Mitglieder der Gruppe Schema-Admins durchgefhrt werden.
Schemanderungen knnen zudem u. U. nicht mehr rckgngig gemacht
werden. Die Mitgliedschaft in dieser Gruppe ist daher unbedingt restriktiv zu
vergeben und streng zu kontrollieren.
Das AD wird auf Domnen Controllern gehalten und innerhalb einer Domne Global Catalog
zwischen diesen durch Replikation synchronisiert. Das AD einer Domne
enthlt nur domnenbezogene Informationen. Um in einem Forest schnell auf
Informationen aus dem gesamten Forest zugreifen zu knnen, wird der so
genannte Global Catalog (GC) aufgebaut. Er besteht aus Teilinformationen
von AD-Objekten und wird im gesamten Forest repliziert, so dass ber den
GC in einer Domne auch direkt auf Informationen aus anderen Domnen
zugegriffen werden kann.
Neben der beschriebenen baumartigen und hierarchischen Struktur baut Sites
Windows 2000 automatisch eine zustzliche und orthogonale Struktur auf.
Rumlich nahe Rechner - dies bestimmt Windows 2000 ber Netzlaufzeiten -
werden zu so genannten Standorten (englisch Sites) zusammengefasst. ber
Sites wird u. a. auch die Replikationsstruktur von Domnen Controllern
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
gesteuert. Pro Site muss mindestens ein Rechner existieren, der eine Kopie des
Global Catalogs hlt. Der Global Catalog muss im Rahmen des Anmelde-
prozesses eines Benutzers angefragt werden, so dass bei der Anmeldung
immer ein Global Catalog-Server zugreifbar sein muss. Die von Windows
2000 automatisch aufgebaute Standortstruktur sollte an die behrden- oder
unternehmensinternen Gegebenheiten, wie z. B. Standorte in verschiedenen
Stdten oder Lndern, individuell angepasst werden. Da dies Einfluss auf die
AD-Replikationsbeziehungen hat, ist dazu jedoch ein Konzept zu erstellen.
Im Rahmen der AD Planung sind folgende Aspekte zu bercksichtigen:
- Welche AD-Struktur im Sinne der Aufteilung in Domnen und welche
Anordnung der Domnen in Bume und Wlder soll gewhlt werden?
- Welche Benutzer und Rechner sollen in welchen Domnen zusammen-
gefasst werden?
Fr jede Domne muss entschieden werden,
- welche OU-Objekte existieren sollen, wie diese hierarchisch angeordnet
werden und welche Objekte diese jeweils aufnehmen sollen,
- welche Sicherheitsgruppen bentigt werden und wie diese in OUs zusam-
mengefasst werden,
- welches administrative Modell umgesetzt wird (zentrale/dezentrale
Verwaltung),
- ob und an wen administrative Aufgaben delegiert werden sollen,
- welche Sicherheitseinstellungen fr verschiedene Typen von Rechnern und
Benutzergruppen gelten sollen,
- welche Einstellungen bei den Gruppenrichtlinien bentigt werden und nach
welchem Konzept die Gruppenrichtlinien verteilt werden (siehe
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000),
- welche Vertrauensstellungen von Windows 2000 automatisch generiert
werden und welche zustzlichen Vertrauensstellungen (z. B. zu NT-
Domnen oder externen Kerberos-Realms) eingerichtet werden mssen,
- auf welche AD-Informationen ber die verschiedenen AD-Schnittstellen
(z. B. ADSI, LDAP) von wem zugegriffen werden drfen,
- welche AD-Objekte in den so genannten Global Catalog bernommen
werden sollen, auf den in einem Forest global zugegriffen werden kann,
- in welchem Modus die Domne betrieben werden muss: mssen in einer
Domne noch Windows NT Backup-Domnen-Controller (BDCs) betrie-
ben werden, so muss die Domne im "Mixed-Mode" betrieben werden.
Sind keine BDCs vorhanden, kann die Domne im "Native-Mode" betrie-
ben werden.
Generell muss die geplante AD-Struktur dokumentiert werden, dies trgt
mageblich zur Stabilitt, konsistenten Administration und damit zur System-
sicherheit bei. Es empfiehlt sich insbesondere festzuhalten, welche Schema-
nderungen durchgefhrt werden. Dabei sollten auch die Grnde fr die
nderung dokumentiert sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr jedes AD-Objekt sollte dokumentiert sein:

- Name und Position im AD-Baum (z. B. "StandortBerlin", Vater-Objekt:
OU "Filialen-Deutschland")
- welchem Zweck das Objekt dient (z. B. Gruppe der Benutzer mit RAS-
Zugang auf RAS-Server 1)
- welche administrativen Zugriffsrechte fr das Objekt und dessen Attribute
vergeben werden sollen (z. B. vollstndig verwaltet von "Admin1")
- wie die Vererbung von AD-Rechten konfiguriert werden soll, z. B.
Blockieren der Rechtevererbung (siehe auch M 2.230 Planung der Active
Directory-Administration, M 3.27 Schulung zur Active Directory-
Verwaltung)
- welche Gruppenrichtlinienobjekte auf dieses Objekt wirken (siehe
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000)
Der Planung der AD-Administration und des benutzten administrativen
Modells kommt eine wichtige Aufgabe zu. Empfehlungen dazu finden sich
zusammengefasst in Manahme M 2.230 Planung der Active Directory-
Administration.
Die sicherheitsrelevanten Kernaspekte der AD-Planung sind zusammen-
gefasst:
- Domnen begrenzen die administrative Macht von Administratoren. Domnen sind
administrative Grenzen
Administratoren knnen daher nur innerhalb einer Domne verwaltend
ttig werden, so dass ihre Verwaltungsbefugnis standardmig nicht ber
die Domnengrenze reicht. Dies gilt insbesondere im Verbund mit
mehreren Domnen (Baum, Wald), so dass die oft geuerten Bedenken,
dass unter Windows 2000 durch das standardmig transitive Vertrauens-
modell auch administrative Berechtigungen ber Domnengrenzen hinweg
mglich sind, fr normale Administratorenkonten ausgerumt werden
knnen (siehe jedoch Organisations-Admins unten).
- Domnenbergreifende Zugriffe setzen voraus, dass in der Ziel-Domne domnenbergreifende
Zugriffe
explizit Zugriffsberechtigungen fr den Zugreifer aus einer anderen
Domne eingerichtet werden. Standardmig sind daher keine domnen-
bergreifenden Zugriffe mglich. Dies bedeutet, dass in einem Baum oder
Wald ein Administrator einer Domne "A" nur dann administrativ auf eine
beliebige andere Domne "B" zugreifen kann, falls der Domnen-
administrator von "B" dem Administrator der Domne "A" explizit
Berechtigungen dazu einrumt (siehe jedoch Organisations-Admins).
- Die Mitglieder der Gruppe Organisations-Admins genieen einen Sonder- Organisations-Admins
status, da sie im gesamten Forest Administratorrechte auf dem AD
besitzen. Insbesondere werden gesetzte Zugriffsrechte auf AD-Objekte bei
Zugriffen von Organisations-Admins ignoriert. Die Mitgliedschaft in der
Gruppe der Organisations-Admins muss daher restriktiv vergeben und
strikt kontrolliert werden. Es ist zu beachten, dass ein Organisations-
Admin bentigt wird, um beispielsweise eine Subdomne anzulegen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Administrative Delegation wird durch die Vergabe von Zugriffsrechten auf Administrative
AD-Objekte und deren Attribute erreicht. Die Verteilung der Zugriffs- Delegation
rechte muss gem dem administrativen Modell erfolgen. Durch die
Mechanismen fr Zugriffsrechte im AD (Vererbung, Kontrolle der
Vererbung, Wirkungsbereich von Zugriffseinstellungen) knnen sehr
komplexe Berechtigungsstrukturen aufgebaut werden. Diese knnen sehr
schnell unbersichtlich und nicht mehr administrierbar werden, so dass
sich durch Fehlkonfigurationen im AD Sicherheitslcken ergeben knnen.
Eine mglichst einfache Berechtigungsstruktur ist daher vorzuziehen.
- Schemanderungen sind kritische Operationen und drfen nur von autori- Schemanderungen
sorgfltig planen
sierten Administratoren nach sorgfltiger Planung durchgefhrt werden.
Abschlieend sei darauf hingewiesen, dass Fehler in der AD-Planung und den
zugrunde liegenden Konzepten nach erfolgter Installation nur mit betrcht-
lichem Aufwand zu berichtigen sind. Nachtrgliche Vernderungen in der
AD-Struktur, wie z. B. die Anordnung von Domnen in Bume und Forests,
ziehen u. U. das komplette Neuaufsetzen von Domnen nach sich.
- Wurde eine AD-Planung durchgefhrt?
- Sind alle Beteiligten in die Planung einbezogen worden?
- Ist ein bedarfsgerechtes AD-Berechtigungskonzept entworfen worden?
- Sind administrative Delegationen mit restriktiven und bedarfsgerechten
Berechtigungen ausgestattet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.230 Planung der Active Directory-Administration

Das Active Directory (AD) besteht aus verschiedenen Objekten, die baumartig
organisiert sind. Jedes Objekt besteht aus bestimmten Attributen, die die
Objektinformationen speichern. Durch Objekte geschieht die Verwaltung
eines Windows 2000 Systems, die durch einen berechtigten Administrator
erfolgen muss. Fr alle AD-Objekte knnen Berechtigungen vergeben werden,
die den Zugriff auf die Objekte steuern. Damit kann festgelegt werden, welche
Objekte von welchen Benutzern in einer bestimmten Art und Weise verndert
werden knnen, wie beispielsweise das Anlegen von Benutzern oder das
Zurcksetzen von Benutzerpasswrtern.
Bei einer Standardinstallation von Windows 2000 besitzen nur Administra-
toren das Recht, Vernderungen an Objekten vorzunehmen und damit eine
Domne zu verwalten. Benutzer besitzen in der Regel maximal Leserecht.
Generell gilt auch unter Windows 2000, dass an der Domnengrenze auch die
administrative Macht der Administratoren der Domne endet. Lediglich die
Mitglieder der Gruppe Organisations-Admins besitzen in jeder Domne eines
Forests Vollzugriff auf alle AD-Objekte, und zwar unabhngig von den fr
diese Objekte eingestellten Zugriffsrechten. Standardmig sind dies die
Mitglieder der Administratorengruppe der Forest-Root-Domain (FRD).
In groen Domnen empfiehlt sich die Delegation administrativer Aufgaben, Delegation
administrativer
so dass die administrative Last auf mehrere Administratoren verteilt ist oder Aufgaben
auch, u. U. zustzlich, eine Rollentrennung umgesetzt werden kann. Die Dele-
gation administrativer Aufgaben erfolgt im AD durch die Vergabe von ent-
sprechenden Zugriffsrechten auf AD-Objekte fr die jeweiligen Adminstra-
torengruppen. Dabei erlaubt die AD-Rechtestruktur eine feingranulare
Vergabe von Rechten. Auf diese Weise kann z. B. einem Administrator
erlaubt werden, Benutzerkonten anzulegen und Benutzerpasswrter zurck-
zusetzen, jedoch nicht Benutzerkonten zu lschen oder in andere Organi-
zational Units (OU, Organisationseinheiten) zu verschieben. Um die Vergabe
gleichfrmiger Rechte innerhalb eines kompletten Teilbaums zu vereinfachen,
besteht zustzlich die Mglichkeit, Rechte eines Objektes an Objekte im
Unterbaum zu vererben. Da die bernahme von vererbten Rechten durch
bestimmte Objekte im Unterbaum u. U. nicht gewnscht ist, lsst sich die
bernahme fr Objekte auch blockieren, so dass sich hier durchaus komplexe
Szenarien fr die Verteilung von Berechtigungen ergeben knnen (siehe auch
M 3.27 Schulung zur Active Directory-Verwaltung).
Aus Sicherheitssicht ergeben sich folgende Aspekte, die bei der Planung der
AD-Administration zu bercksichtigen sind:
- Wird Delegation eingesetzt, so sollten nur die unbedingt notwendigen restriktive
Rechtevergabe
Rechte vergeben werden, die zur Ausbung der delegierten administrativen
Ttigkeiten erforderlich sind.
- Das Delegationsmodell und die daraus resultierenden Rechtezuordnungen Delegationsmodell
dokumentieren
mssen dokumentiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die administrativen Ttigkeiten sollten so delegiert werden, dass sich berschneidungen

mglichst keine berschneidungen ergeben. Ansonsten knnen durch zwei vermeiden
Administratoren sich widersprechende Vernderungen durchgefhrt
werden. Dies fhrt dann zu Replikationskonflikten, die von Windows 2000
automatisch aufgelst werden, so dass sich eine der nderungen auf jeden
Fall durchsetzt. Es gibt jedoch fr diesen Fall keine Warnungen. Es
empfiehlt sich daher, das Administrationsmodell so zu entwerfen, dass
mglichst berschneidungsfreie Zustndigkeiten existieren. Auf diese
Weise kann die Gefahr von Replikationskonflikten verringert werden. Sind
Replikationskonflikte zu erwarten oder bereits aufgetreten, so sollte in
regelmigen Abstnden oder nach wichtigen nderungen eine manuelle
berprfung erfolgen, ob sich immer die korrekten Werte durchgesetzt
haben. Ob das Fhren einer Evidenzdatenbank mit den Active Directory
Soll-Daten u. U. organisatorisch sinnvoll ist, muss im Einzelfall entschie-
den werden.
- Wird fr die Verwaltung des AD Delegation eingesetzt, so wird dies durch Komplexitt reduzieren
die Vergabe von entsprechenden Zugriffsrechten innerhalb des AD
erreicht. Dabei wird in der Regel der Vererbungsmechanismus eingesetzt,
um Berechtigungen auf Objekte in Teilbumen zu verwalten. Komplexe
Szenarien mit Delegation und damit Rechtevererbung sollten jedoch unbe-
dingt vermieden werden, da sonst leicht Sicherheitslcken entstehen
knnen. Beispielsweise kann der Fall eintreten, dass ein Benutzer zu
wenige oder zu viele Rechte hat.
- Es muss ein Konzept fr die Mitgliedschaft in den verschiedenen Konzept fr
Gruppenmitgliedschaft
administrativen Gruppen entworfen werden. Dabei sind vor allem die schaffen
Bedingungen und Verfahren zu definieren, die festlegen, ob, wann und wie
lange ein Benutzer oder eine Benutzergruppe in eine administrative Gruppe
aufgenommen wird. Es muss insbesondere dafr Sorge getragen werden,
die Mitgliedschaft in der Gruppe der Organisations-Admins restriktiv zu
handhaben und zu kontrollieren. Falls es der organisatorische Ablauf
zulsst, kann erwogen werden, alle Mitglieder in dieser Gruppe nach
Aufbau der Domnenstruktur zu entfernen und nur bei Bedarf und unter
Einhaltung des Vier-Augen-Prinzips entsprechende Mitglieder hinzu-
zufgen. Es muss jedoch bercksichtigt werden, dass ein Mitglied der
Gruppe der Organisations-Admins immer dann bentigt wird, wenn eine
neue Domne im Forest angelegt werden soll.
- Die Administratoren sind ber die AD-Struktur und die organisatorischen Administratoren
informieren und schulen
Ablufe im Rahmen ihrer administrativen Ttigkeit zu informieren und
entsprechend zu schulen, um zu verhindern, dass nicht-konforme nderun-
gen zu Sicherheitslcken fhren. Beispielsweise kann es erforderlich sein,
beim Anlegen eines neuen Benutzers diesen in entsprechende Sicherheits-
gruppen aufzunehmen oder sogar zustzlich eine neue Sicherheitsgruppe
mit einem speziellen Namen anzulegen. Wird dies vergessen, so erhalten
Benutzer u. U. fehlerhafte Berechtigungen.
- Fr groe Domnen sollte ber die Mglichkeit der werkzeuggesttzten Tools verwenden
Verwaltung nachgedacht werden. Es gibt verschiedene kommerzielle und
auch frei verfgbare Werkzeuge, die die AD-Verwaltung erleichtern. Es
sollte berlegt werden, diese einzusetzen. Werden solche Werkzeuge ver-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wendet, so muss sichergestellt werden, dass die AD-Verwaltung

ausschliesslich durch diese Werkzeuge erfolgt.
- Wurde eine Planung der administrativen Gruppen zur AD-Verwaltung
durchgefhrt?
- Ist das Delegationsmodell berschneidungsfrei?
- Sind alle administrativen Aufgabenbereiche und Berechtigungen dokumen-
tiert?
- Wurden die Administratoren durch Schulungen auf die AD-Verwaltung
vorbereitet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.231 Planung der Gruppenrichtlinien unter Windows

2000
Zur Konfiguration von Windows 2000 Rechnern steht der Mechanismus der
so genannten Gruppenrichtlinien zur Verfgung. Schon unter Windows NT
gab es mit den Gruppenrichtlinien ein hnliches, aber deutlich weniger
leistungsfhiges Instrument. Gruppenrichtlinien dienen im Active Directory
dazu, einen Satz von Konfigurationseinstellungen, zu denen insbesondere
auch Sicherheitseinstellungen gehren, auf eine Gruppe von Objekten anzu-
wenden. Durch ein so genanntes Gruppenrichtlinienobjekt (englisch Group
Policy Object, GPO) wird ein vorgegebener Satz von Konfigurationspara-
metern (standardmig ber 700) zusammengefasst. Fr jeden Parameter kann
ein konkreter Wert angegeben werden, der u. U. nur aus einem beschrnkten
Wertebereich stammt. Generell kann auch immer der Wert nicht definiert
gewhlt werden, so dass dann automatisch die Windows Standardeinstellun-
gen fr diese Parameter gelten. Die Standardeinstellungen sind in der Hilfe-
datei zu Gruppenrichtlinien, u. a. im Windows 2000 Server Resource Kit,
dokumentiert.
Die Parameter innerhalb eines Gruppenrichtlinienobjektes sind baumartig oder Rechner- und
Benutzereinstellungen
dateisystemartig thematisch zusammengefasst. Dabei ergibt sich eine gene-
relle Zweiteilung auf oberster Ebene in Einstellungen fr Rechner sowie fr
Benutzer. Aus Sicherheitssicht sind insbesondere die Einstellungen interes-
sant, die sich unterhalb der folgenden "Pfade" finden:
- Rechnereinstellungen\WindowsEinstellungen\Sicherheitseinstellungen
- Rechnereinstellungen\Administrative Einstellungen\
Windows Komponenten\Windows Installer
- Rechnereinstellungen\Administrative Vorlagen\System\Gruppenrichtlinien
- Benutzereinstellungen\Administrative Vorlagen\
Windows Komponenten\Microsoft Management Konsole
- Benutzereinstellungen\Administrative Einstellungen\
Windows Komponenten\Windows Installer
Windows 2000 berechnet generell fr jeden an einer Domne angemeldeten Berechnung der jeweils
gltigen Einstellungen
Rechner und fr jeden angemeldeten Benutzer die jeweils gltigen Einstel-
lungen fr jeden Gruppenrichtlinienparameter. Diese Berechung ist ntig, da
die Vorgaben fr die Parametereinstellungen durch unterschiedliche Gruppen-
richtlinienobjekte definiert sein knnen, die sich gegenseitig berlagern
knnen. Folgende Gruppenrichtlinienobjekte knnen definiert werden:
1. Jeder Rechner besitzt ein lokal definiertes Gruppenrichtlinienobjekt. Dies
erlaubt die Definition von Parametereinstellungen lokal auf dem Rechner,
z. B. wenn keine Netzverbindung besteht.
2. Gruppenrichtlinienobjekte knnen ber Windows 2000 Standorte (Sites)
definiert werden. Damit knnen Einstellungen standortspezifisch adaptiert
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Innerhalb der Active Directory Struktur knnen Gruppenrichtlinienobjekte

fr das Domnenobjekt definiert werden, so dass damit Parametereinstel-
lungen fr Rechner und Benutzer innerhalb der gesamten Domne gesteu-
ert werden knnen.
4. Auf jedem OU-Objekt knnen Gruppenrichtlinien definiert werden, deren
Einstellungen dann auf alle Rechner und Benutzer unterhalb dieses OU-
Objektes wirken.
Fr die Berechnung der jeweils fr einen konkreten Rechner oder Benutzer Reihenfolge LSDO
geltenden Parametereinstellungen wird folgendes Berechnungs- bzw. ber-
deckungsschema (Lokal <- Standort <- Domne <- Organisationseinheit,
LSDO) angewandt: Zunchst werden die lokalen Einstellungen bercksichtigt
(L, Lokal). Dann werden diese Einstellungen durch die Einstellungen des
Gruppenrichtlinienobjektes, das auf dem zugehrigen Standort definiert ist,
berdeckt (S, Standort). Danach erfolgt die berdeckung durch die auf dem
relevanten Domnenobjekt definierten Gruppenrichtlinienobjekte (D,
Domne). Schlielich werden die Gruppenrichtlinienobjekte der OU-Objekte
in der Reihenfolge angewandt, wie sie auf dem Weg vom Domnenobjekt zu
dem OU-Objekt, das den jeweiligen Rechner oder Benutzer enthlt, definiert
sind (O, Organisationseinheit).
Die berdeckung kann durch die Optionen blockieren bzw. erzwingen beein- Blockieren und
Erzwingen der
flusst werden. Stehen die Einstellungen blockieren und erzwingen im Kon- berdeckung
flikt, so wird die Einstellung erzwingen durchgesetzt. Zustzlich ist es auf
OU-Ebene mglich, mehrere Gruppenrichtlinienobjekte fr ein OU-Objekt zu
definieren. Dabei erfolgt die berdeckung gem der angegebenen Reihen-
folge. Es ist dabei auerdem mglich, jedes einzelne Gruppenrichtlinienobjekt
fr ein OU-Objekt zu aktivieren oder zu deaktivieren.
Gruppenrichtlinienobjekte knnen im Active Directory nur auf OU-Objekten
definiert werden, nicht jedoch auf einzelnen Rechnern oder Benutzerobjekten.
Das lokal definierte Gruppenrichtlinienobjekt wird nicht im Active Directory
gespeichert. Soll ein Gruppenrichtlinienobjekt, das auf einem OU-Objekt
definiert ist, das Rechnerobjekte zusammenfasst, nicht auf alle enthaltenen
Rechnerobjekte wirken, so besteht die Mglichkeit, durch die Vergabe von
Zugriffsrechten auf das Gruppenrichtlinienobjekt die Anwendung auf ein
konkretes Rechnerobjekt zu unterbinden. Hierzu ist diesem Rechnerobjekt das
Zugriffsrecht Anwenden auf das Gruppenrichtlinienobjekt zu entziehen.
Die bisher benutzte Darstellung der Definition von Gruppenrichtlinien- Links zwischen GPOs
und OUs
objekten auf OU-Objekten war jedoch vereinfacht: Gruppenrichtlinienobjekte
werden separat im Active Directory gespeichert und bilden einen Pool von
Objekten. Jedes definierte Gruppenrichtlinienobjekt kann nun einem oder
auch mehreren OU-Objekten assoziiert werden. Man spricht dann von einem
Link. Durch das Kennzeichnen eines Links als aktiviert oder deaktiviert wird
das jeweilige Gruppenrichtlinienobjekt bei der Berechnung fr das OU-Objekt
herangezogen oder nicht (siehe oben). Fr jedes Gruppenrichtlinienobjekt
kann ber den Eigenschaftsdialog festgestellt werden, mit welchen OU-
Objekten ein Link besteht, d. h. auf welche Objekte sie potentiell wirken.
Aus Sicherheitssicht sind bei der Planung und im Umgang mit Gruppenricht-
linienobjekten folgende Aspekte zu bercksichtigen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Das Gruppenrichtlinienkonzept muss so einfach wie mglich gehalten GPO-Konzept mglichst

werden. Komplexe Strukturen aus Mehrfachberdeckungen sind zu ver- einfach halten
meiden. Insbesondere sollte auf die Mglichkeit der Vergabe von Zugriffs-
rechten auf Gruppenrichtlinienobjekte nur in Ausnahmefllen zurck-
gegriffen werden. Generell muss das Gruppenrichtlinienkonzept so
dokumentiert sein, dass Ausnahmeregelungen einfach zu erkennen sind.
- Das Gruppenrichtlinienkonzept und die OU-Objektstruktur beeinflussen GPO-Konzept bei OU-
Gruppierung beachten
sich gegenseitig wesentlich, da Gruppenrichtlinienobjekte im Active
Directory nur auf OU-Objekte angewandt werden knnen und nicht auf
Rechner- oder Benutzerobjekte. Beim Aufbau der OU-Gruppierungen ist
daher darauf zu achten, dass nur Objekte, die mit gleichen GPO-Einstel-
lungen versehen werden sollen, in einem OU-Objekt oder untergeordneten
OU-Objekten zusammengefasst werden.
- Durch die Rechteberechnung ist es mglich, die Verwaltung der Wo wird welcher
Parameter definiert?
Parametereinstellungen auf unterschiedliche "Orte" (Lokal, Standort,
Domnen-Objekt, OU-Objekte) zu verteilen. Es muss daher fr jeden
Parameter entschieden werden, wo er definiert wird. Es ist dabei zu
beachten, dass einige Parameter nur dann wirksam werden, wenn sie an
bestimmten "Orten" definiert werden. So knnen z. B. die Passwort-
einstellungen nur auf Domnen-Objekten definiert werden.
- Gruppenrichtlinienobjekte mssen vor unberechtigter Vernderung GPOs schtzen
geschtzt werden. Dazu mssen einerseits entsprechende Berechtigungen
im Active Directory vergeben werden (siehe auch M 2.230 Planung der
Active Directory-Administration, M 3.27 Schulung zur Active Directory-
Verwaltung) und andererseits kann der Gebrauch von entsprechenden
Verwaltungswerkzeugen, wie z. B. MMC-Gruppenrichtlinien-Snap-In oder
Registrierungseditoren, fr Benutzer unterbunden werden.
- Insbesondere fr die sicherheitsrelevanten Parameter innerhalb eines sicherheitsrelevante
Parameter festlegen
Gruppenrichtlinienobjektes sind die Einstellungen festzulegen. Neben den
oben angegebenen Einstellungen knnen je nach Anwendungsszenario
auch weitere Parameter sicherheitsrelevant sein. Dazu zhlen z. B. Internet-
Explorer-Einstellungen.
Die Einstellungen der verschiedenen Gruppenrichtlinienobjekte mssen sich
dabei generell an den Sicherheitsrichtlinien des Unternehmens bzw. der
Behrde orientieren und diese umsetzen.
Im Folgenden werden Vorgaben fr die Sicherheitseinstellungen aufgezeigt,
die als Ausgangsbasis fr die Sicherheitseinstellungen innerhalb einer
Gruppenrichtlinie dienen knnen. Die angegebenen Werte mssen auf jeden
Fall an die lokalen Bedingungen angepasst werden. Im Rahmen des Gruppen-
richtlinienkonzeptes sind die einzelnen Werte zudem auf unterschiedliche
Gruppenrichtlinienobjekte zu verteilen und jeweils an den Verwendungszweck
anzupassen (z. B. GPO fr Server, GPO fr Arbeitsplatzrechner). Dadurch
knnen fr einzelne Eintrge auch jeweils unterschiedliche Werte zustande
kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kennwortrichtlinie
Richtlinie Computereinstellung
Kennwortchronik erzwingen 6 Gespeicherte Kennwrter
Kennwrter mssen den Komplexittsanforderungen Aktiviert
entsprechen.
Kennwrtern fr alle Domnenbenutzer mit umkehr- Deaktiviert
barer Verschlsselung speichern
Maximales Kennwortalter 90 Tage
Minimale Kennwortlnge 6 Zeichen
Minimales Kennwortalter 1 Tag
Kontosperrungsrichtlinien
Kontensperrungsschwelle 3 Ungltige Anmeldeversuche
Kontosperrdauer 0 (Hinweis: Konto ist gesperrt, bis Administrator
Sperrung aufhebt)
Kontosperrungszhler zurcksetzen nach 30 Minuten
Kerberos-Richtlinie
Benutzeranmeldeeinschrnkungen erzwingen Aktiviert
Max. Gltigkeitsdauer des Benutzertickets 8 Stunden
Max. Gltigkeitsdauer des Diensttickets 60 Minuten
Max. Toleranz fr die Synchronisation des 5 Minuten
Computertakts
Max. Zeitraum, in dem ein Benutzerticket erneuert 1 Tag
werden kann
berwachungsrichtlinie
Active Directory-Zugriff berwachen Erfolgreich, Fehlgeschlagen
Anmeldeereignisse berwachen Erfolgreich, Fehlgeschlagen
Anmeldeversuche berwachen Erfolgreich, Fehlgeschlagen
Kontenverwaltung berwachen Erfolgreich, Fehlgeschlagen
Objektzugriffsversuche berwachen Fehlgeschlagen
Prozessverfolgung berwachen Keine berwachung
Rechteverwendung berwachen Fehlgeschlagen
Richtliniennderungen berwachen Erfolgreich, Fehlgeschlagen
Systemereignisse berwachen Erfolgreich, Fehlgeschlagen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Zuweisen von Benutzerrechten

Als Dienst anmelden Definiert, aber leer
ndern der Systemzeit Administratoren
Anheben der Zeitplanungsprioritt Administratoren
Anheben von Quoten Administratoren
Anmelden als Stapelverarbeitungsauftrag Definiert, aber leer
Anmeldung als Batchauftrag verweigern Nicht definiert
Anmeldung als Dienst verweigern Nicht definiert
Auf diesen Computer vom Netzwerk aus zugreifen Jeder,
Administratoren,
Authentifizierte Benutzer,
Sicherungs-Operatoren
Auslassen der durchsuchenden berprfung Jeder
Debuggen von Programmen Nicht definiert
Einsetzen als Teil des Betriebssystems Definiert, aber leer
Entfernen des Computers von der Dockingstation Administratoren
Ermglichen, dass Computer- und Benutzerkonten Administratoren
fr Delegierungszwecke vertraut wird
Ersetzen eines Tokens auf Prozessebene Definiert, aber leer
Erstellen einer Auslagerungsdatei Administratoren
Erstellen eines Profils der Systemleistung Administratoren
Erstellen eines Profils fr einen Einzelprozess Administratoren
Erstellen eines Tokenobjekts Definiert, aber leer
Erstellen von dauerhaft freigegebenen Objekten Definiert, aber leer
Erzwingen des Herunterfahrens von einem Remote- Administratoren
system aus
Generieren von Sicherheitsberwachungen Definiert, aber leer
Herunterfahren des Systems Administratoren
Hinzufgen von Arbeitsstationen zur Domne Definiert, aber leer
Laden und Entfernen von Gertetreibern Administratoren
Lokal anmelden Administratoren,
Sicherungs-Operatoren
Lokale Anmeldung verweigern Nicht definiert
Sichern von Dateien und Verzeichnissen Sicherungs-Operatoren
Sperren von Seiten im Speicher Definiert aber leer
Synchronisieren von Verzeichnisdienstdaten Definiert, aber leer
Hinweis: Gem der Dokumentation zum Ressorce-
Kit findet diese Einstellung in der gegenwrtigen
Version von Windows 2000 keine Anwendung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
bernehmen des Besitzes von Dateien und Objekten Administratoren

Verndern der Firmwareumgebungsvariablen Administratoren
Verwalten von berwachungs- und Sicherheits- Administratoren
protokollen
Wiederherstellen von Dateien und Verzeichnissen Administratoren
Zugriff vom Netzwerk auf diesen Computer verwei- Nicht definiert
gern
Sicherheitsoptionen
Administrator umbenennen Nicht definiert
Anwender vor Ablauf des Kennworts zum ndern 7 Tage
des Kennworts auffordern
Anwendern das Installieren von Druckertreibern nicht Aktiviert
erlauben
Anzahl zwischenzuspeichernder vorheriger Anmel- 0 Anmeldungen
dungen (fr den Fall, dass der Domnencontroller
nicht verfgbar ist)
Auslagerungsdatei des virtuellen Arbeitspeichers Aktiviert
beim Herunterfahren des Systems lschen
Auswerfen von NTFS-Wechselmedien zulassen Administratoren
Benutzer automatisch abmelden, wenn die Anmelde- Aktiviert
zeit berschritten wird (lokal)
Benutzer nach Ablauf der Anmeldezeit automatisch Aktiviert
abmelden
Clientkommunikation digital signieren (immer) Deaktiviert
Clientkommunikation digital signieren (wenn Aktiviert
mglich)
Die Verwendung des Sicherungs- und Wieder- Deaktiviert
herstellungsrechts berprfen
Gastkonto umbenennen Nicht definiert
Herunterfahren des Systems ohne Anmeldung Deaktiviert
zulassen
LAN Manager-Authentifizierungsebene Nur NTLMv2-Antworten senden\LM verweigern
Leerlaufzeitspanne bis zur Trennung der Sitzung 15 Minuten
Letzten Benutzernamen nicht im Anmeldedialog Aktiviert
anzeigen
Nachricht fr Benutzer, die sich anmelden wollen Nicht definiert
Nachrichtentitel fr Benutzer, die sich anmelden Nicht definiert
wollen
Serverkommunikation digital signieren (immer) Deaktiviert
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sicherheitsoptionen (Fortsetzung)
Serverkommunikation digital signieren (wenn mg- Aktiviert
lich)
Serveroperatoren das Einrichten von geplanten Tasks Nicht definiert
erlauben (Nur fr Domnencontroller)
Sicherer Kanal: Daten des sicheren Kanals digital Aktiviert
signieren (wenn mglich)
Sicherer Kanal: Daten des sicheren Kanals digital Aktiviert
verschlsseln (wenn mglich)
Sicherer Kanal: Daten des sicheren Kanals digital Deaktiviert
verschlsseln oder signieren (immer)
Sicherer Kanal: Starker Sitzungsschlssel erforderlich Deaktiviert (Hinweis: In reinen Windows 2000
(Windows 2000 oder hher) Umgebungen aktivieren)
Standardberechtigungen globaler Systemobjekte (z. Aktiviert
B. symbolischer Verknpfungen) verstrken
STRG+ALT+ENTF-Anforderung zur Anmeldung Deaktiviert (Hinweis: D. h. STRG+ALT+ENTF ist
deaktivieren erforderlich)
System sofort herunterfahren, wenn Sicherheitsber- Deaktiviert
prfungen nicht protokolliert werden knnen
Systemwartung des Computerkontokennworts nicht Deaktiviert
gestatten
Unverschlsseltes Kennwort senden, um Verbindung Deaktiviert
mit SMB-Servern von Drittanbietern herzustellen
Verhalten bei der Installation von nichtsignierten Warnen, aber Installation zulassen
Dateien (auer Treibern)
Verhalten bei der Installation von nichtsignierten Warnen, aber Installation zulassen
Treibern
Verhalten beim Entfernen von Smartcards Computer sperren
Weitere Einschrnkungen fr anonyme Verbindungen Kein Zugriff ohne explizite anonyme Berechtigung
Wiederherstellungskonsole: Automatische Deaktiviert
administrative Anmeldungen zulassen
Wiederherstellungskonsole: Kopieren von Disketten Deaktiviert
und Zugriff auf alle Laufwerke und alle Ordner
zulassen
Zugriff auf CD-ROM-Laufwerke auf lokal ange- Aktiviert
meldete Benutzer beschrnken
Zugriff auf Diskettenlaufwerke auf lokal angemeldete Aktiviert
Benutzer beschrnken
Zugriff auf globale Systemobjekte prfen Deaktiviert
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ereignisprotokoll
Anwendungsprotokoll aufbewahren fr Nicht definiert
Aufbewahrungsmethode des Anwendungsprotokolls Ereignisse bei Bedarf berschreiben
Aufbewahrungsmethode des Sicherheitsprotokolls Ereignisse bei Bedarf berschreiben Hinweis: Im
Hochsicherheitsbereich ist folgende Einstellung zu
whlen: Ereignisse nicht berschreiben (Protokoll
manuell aufrumen)
Aufbewahrungsmethode des Systemprotokolls Ereignisse bei Bedarf berschreiben
Gastkontozugriff auf Anwendungsprotokoll Aktiviert
einschrnken
Gastkontozugriff auf Sicherheitsprotokoll Aktiviert
einschrnken
Gastkontozugriff auf Systemprotokoll einschrnken Aktiviert
Maximale Gre des Anwendungsprotokolls 30080 Kilobytes
Maximale Gre des Sicherheitsprotokolls 100992 Kilobytes
Maximale Gre des Systemprotokolls 30080 Kilobytes
Sicherheitsprotokoll aufbewahren fr Nicht definiert
System bei Erreichen der max. Sicherheitsprotokoll- Deaktiviert (Hinweis: Fr Hochsicherheitssysteme
gre herunterfahren aktivieren)
Systemprotokoll aufbewahren fr Nicht definiert
- Wurde das GPO-Konzept bedarfsgerecht entworfen?
- Sind alle GPOs durch restriktive Zugriffsrechte geschtzt?
- Sind fr alle GPO-Parameter in allen GPOs Vorgaben festgelegt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.232 Planung der Windows 2000 CA-Struktur

Windows 2000 wird mit eigenen PKI-Komponenten ausgeliefert, die den
Aufbau einer unternehmensweiten Zertifikatshierarchie ermglichen. Kern-
stck einer PKI (Public Key Infrastruktur) ist die so genannte Zertifizierungs-
stelle (Certificate Authority, CA), die Zertifikate ausstellen kann. Fr den
Betrieb von Windows 2000 ist der Betrieb einer CA zwar generell nicht not-
wendig, jedoch immer dann zwingend, wenn bestimmte Eigenschaften oder
Funktionen genutzt werden sollen, wie z. B. Smart-Card Login oder abge-
sicherte Kommunikation zwischen Windows Systemkomponenten ber SSL.
Windows 2000 bietet zwei Ausprgungen einer CA an:
1. die Windows 2000 Stand-alone-CA und
2. die Windows 2000 Enterprise-CA.
Der Hauptunterschied zwischen den beiden CA-Versionen ist, dass die Enter-
prise-CA im Active Directory integriert ist und Zertifikate nach einer Zertifi-
katsanforderung automatisch nach Prfung der Zulssigkeit der Anforderung
ausstellt und verteilt. Bei der Stand-alone-CA wird die Zertifikatsanforderung
immer vom Administrator der CA geprft. Die Zertifikatserzeugung muss
durch den Administrator von Hand angestoen werden. Die Stand-alone-CA
kann auch auf einem nicht vernetzten Rechner installiert und betrieben
werden, wohingegen die Enterprise-CA sinnvoll nur auf einem vernetzten
Rechner ablaufen kann.
Beide CA-Versionen eignen sich fr den Aufbau von Zertifikatshierarchien.
Eine spezielle CA kann daher auch als untergeordnete CA fungieren.
Bei der Planung der CA-Struktur ist Folgendes zu bercksichtigen:
- Die Planung der PKI erfordert Zeit. In der Regel mssen insbesondere Zustndigkeiten regeln
innerorganisatorische Zustndigkeiten geregelt und festgeschrieben
werden.
- Der Verwendungszweck von Zertifikaten spielt bei der Planung der CA-
Struktur eine wichtige Rolle. So bereitet der Aufbau einer generellen,
organisationsweiten Zertifikatsinfrastruktur meist mehr Schwierigkeiten,
als der Aufbau einer applikationsbezogenen PKI. Eine applikations-
bezogene PKI kann beispielsweise eingesetzt werden, wenn im Rahmen
einer netzbasierten Anwendung nur die betroffenen Mitarbeiter zuverlssig
identifiziert werden mssen. Ein Beispiel hierfr ist das elektronische
Einreichen und Bearbeiten von Urlaubsantrgen, wobei die Antrge nach-
einander von verschiedenen Personen digital abgezeichnet, also signiert,
werden mssen.
Es ist weiterhin zu beachten, dass Zertifikate trotz (oder vielleicht wegen) mangelnde Interope-
rabilitt
einer Vielzahl von Normen in der Regel nicht automatisch universell mit
allen Applikationen eingesetzt werden knnen. Die fehlende Interope-
rabilitt resultiert aus mehreren Ursachen. Dazu gehren neben tatsch-
lichen Normverletzungen bei der Implementierung auerdem die Interpre-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
tationsspielrume, die in den Spezifikationen der verschiedenen Normen

existieren.
- Der Einsatz der Microsoft Enterprise-CA ist notwendig, wenn Smartcard-
basiertes Logon eingesetzt werden soll oder wenn SSL zur Absicherung
der Kommunikation zwischen Windows-Systemkomponenten, z. B. beim
LDAP-Zugriff, genutzt werden soll. Dies ist notwendig, da in beiden
Fllen Rechnerzertifikate erforderlich sind, die automatisch nur von der
Enterprise-CA vergeben werden knnen.
- Das Vertrauen in Zertifikate einer CA hngt wesentlich von deren Sicher- Cas besonders schtzen
heitsgrad ab. Daher ist fr CAs, die sicherheitskritische Zertifikate erzeu-
gen, besonders auf die physikalische und softwaretechnische Sicherheit zu
achten. Sicherheitskritisch sind insbesondere solche Zertifikate, die einen
groen Anwenderkreis haben oder von deren Korrektheit weitere sicher-
heitskritische Anwendungen abhngen.
- Fr Zertifikate mit unterschiedlichem Sicherheitsbedarf sollten
unterschiedliche CAs eingesetzt werden.
- In vielen Lndern unterliegen elektronische Zertifikate einer gesetzlichen rechtliche Aspekte
beachten
Regelung. Die geltenden Gesetze sind daher bei der Planung zu berck-
sichtigen. Dabei muss beachtet werden, dass bei weltweit agierenden
Organisationen auch mehrere Gesetzesvorschriften gelten knnen, die
durchaus auch im Widerspruch zueinander stehen knnen (siehe auch
M 2.163 Erhebung der Einflussfaktoren fr kryptographische Verfahren
und Produkte).
- Werden Zertifikate nur innerhalb einer Behrde bzw. eines Unternehmens
genutzt, so sollten diese nur von CAs vergeben werden, die ausschlielich
intern genutzte Zertifikate ausstellen. Solche internen CAs drfen keine
Zertifikate nach "auen" geben.
- Werden Zertifikate auch extern genutzt, z. B. zum Signieren von E-Mails
an organisationsfremde Kommunikationspartner, so sollten diese von einer
eigenen CA oder CA-Hierarchie ausgestellt werden. Dies verhindert, dass
bei Kompromittierung extern genutzter Zertifikate auch interne Zertifikate
betroffen werden knnen.
- Fr extern genutzte Zertifikate und die ausstellenden CAs sind die Nutzungsrichtlinien
dokumentieren
Nutzungsrichtlinien zu definieren und zu dokumentieren. Es ist dabei
insbesondere darauf zu achten, dass entsprechende Anforderungen an die
Qualitt der Identittsprfung gestellt und umgesetzt werden.
- Es muss geplant werden, welche kryptographischen Verfahren und
Algorithmen und welche Schlssellngen zum Einsatz kommen sollen
(siehe auch M 2.162 Bedarfserhebung fr den Einsatz kryptographischer
Verfahren und Produkte).
- Beim Einsatz von CA-Hierarchien muss das Gltigkeitsmodell festgelegt Gltigkeitsmodell
festlegen
werden. Dabei ist es wichtig festzulegen, wie nachgeordnete Zertifikate zu
behandeln sind, wenn z. B. das Root-CA-Zertifikat - aus welchen Grnden
auch immer - gesperrt werden muss.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Fr die verschiedenen Zertifikatstypen (z. B. Root-CA-Zertifikat, Benut- Gltigkeitsdauer

zer-E-Mail-Zertifikat) muss jeweils die maximale Gltigkeitsdauer fest- festlegen
gelegt werden. Im Allgemeinen ist es sinnvoll, dass die Gltigkeitsdauer
der Zertifikate nicht die Gltigkeitsdauer des Zertifikates der ausstellenden
CA berschreitet. Es gibt hier allerdings verschiedene Gltigkeitsmodelle.
Beispielsweise kann bei Signaturen nach dem deutschen Signaturgesetz die
Gltigkeit der einzelnen Zertifikate lnger sein als die Gltigkeit des CA-
Zertifikates.
- Die Mglichkeiten und Verfahren nach Ablauf der Gltigkeit eines Zertifi- Sind Verlngerungen
mglich?
kates sind festzulegen. Sind z. B. Verlngerungen mglich oder mssen
neue Zertifikate ausgestellt werden?
Im Rahmen der PKI-Planung muss festgelegt werden:
- Soll eine eigene Wurzel-CA (Root-CA) betrieben werden? Wird keine
eigene Wurzel-CA betrieben, muss entschieden werden, welche externe
CA als Wurzel-CA akzeptiert wird. Generell knnen zwar auch mehrere
externe CAs als Wurzel-CA akzeptiert werden, dies sollte jedoch aus
Grnden der Konsistenz in den intern verwendeten Zertifikaten vermieden
werden.
- Welche CA ist welcher anderen CA untergeordnet?
- Welche CA stellt welche Zertifikatstypen in Abhngigkeit vom Verwen-
dungszweck aus?
- Nach welchen Kriterien wird bei einer Zertifikatsanfrage positiv entschie-
den? Ist z. B. eine berprfung von Personalien notwendig?
- Welche Benutzer und Rechner drfen auf eine CA zugreifen?
- Werden Zertifikatsrckruflisten bentigt, und wo und wie werden diese
verffentlicht?
- Auf welchen Rechnern werden welche PKI-Komponenten installiert? Wo
laufen die CA-Komponenten ab?
Insbesondere bei der Planung einer unternehmensweiten PKI sollte darauf Interoperabilitt
frhzeitig prfen
geachtet werden, dass alle Einsatzszenarien und die dadurch betroffenen
Applikationen bekannt sind. Um die technische Machbarkeit abschtzen zu
knnen, empfiehlt es sich, alle Komponenten, die eingesetzt werden sollen, im
Vorfeld auf ihre Interoperabilitt zu berprfen.
Generell gilt, dass alle fr den Betrieb einer CA relevanten organisatorischen,
technischen und auch sicherheitstechnischen Rahmenbedingungen in einem
entsprechenden Konzept dokumentiert werden mssen.
Neben der Planung einer PKI spielt insbesondere die Sicherheit im laufenden
Betrieb der einzelnen PKI-Komponenten eine groe Rolle. Hinweise dazu
finden sich in M 4.144 Nutzung der Windows 2000 CA.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wurde eine bedarfsgerechte PKI-Planung durchgefhrt?
- Ist die CA-Hierarchie mit allen Verantwortlichkeiten und Nutzungsbe-
stimmungen dokumentiert?
- Wurde eine Root-CA bestimmt?
- Sind alle CA-Rechner abgesichert?
- Wurde festgelegt, welcher Benutzer welche Zertifikate erhlt?
- Wurden alle Parameter - wie etwa die Gltigkeit - fr alle Zertifikatstypen
definiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.233 Planung der Migration von Windows NT auf

Windows 2000
In der Regel wird ein auf Windows 2000 basierendes Netz nicht vollstndig
neu aufgebaut, sondern es existiert bereits ein Behrden- oder Unternehmens-
netz, welches meist auf Vorgngerversionen wie Windows NT beruht. Auch
eine Umstellung von einer alten Windows-Version auf Windows 2000 ist in
der Regel schon fr Netze mittlerer Gre nur in mehreren Schritten und ber
einen lngeren Zeitraum hin mglich. Diese Migration erfordert sorgfltige
Planung, da sich in der Zeit der Umstellung leicht Sicherheitslcken ergeben
knnen.
Fr die Migration stehen verschiedene Migrationsverfahren zur Verfgung.
Eine generelle Empfehlung fr eines der Verfahren kann jedoch nicht gegeben
werden, da das gnstigste Verfahren sehr von den lokalen Gegebenheiten
abhngt und zustzlich darauf zugeschnitten werden muss.
Fr die Migration auf Windows 2000 kann unterschieden werden zwischen
- Migration einer Domne,
- Migration von Servern und
- Migration von Clients.
Die Umstellung einer Domne von Windows NT auf Windows 2000 erfolgt
dabei durch die Umstellung von Domnen-Controllern auf Windows 2000.
Generell kann bei der Migration von Domnen zwischen zwei Varianten
unterschieden werden:
1. Dem so genannten Domain Upgrade oder In-place Upgrade, bei dem die Domain Upgrade
existierenden Domnenstrukturen eins-zu-eins nach Windows 2000 ber-
nommen werden. Dies hat den Vorteil, dass die Umstellung keine groen
Restrukturierungen mit sich bringt, und aus Benutzersicht lediglich ein
Betriebssystem-Update erfolgt. Nachteilig kann jedoch sein, dass dadurch
auch existierende Unzulnglichkeiten automatisch in das Windows 2000
System bernommen werden.
2. Der so genannten Domnen Restrukturierung, Domain Restructure oder Domain Restructure
Domain Consolidation, bei der eine neue Windows 2000 Domnenstruktur
aufgebaut wird. Hier wird die Umstellung auf Windows 2000 genutzt, um
existierende Unzulnglichkeiten in der zurzeit benutzten Domnenstruktur
durch Reorganisation zu verbessern. Dieses Vorgehen entspricht meist
einem vlligen Neuaufbau. Es bietet den Vorteil, dass hierbei alte und
schwer administrierbare Strukturen durch neue ersetzt werden knnen. So
sind einige unter Windows NT geltende Limitierungen aufgehoben
worden. Auerdem ist es mglich, u. U. vernderten Geschftsanforde-
rungen und lokalen Gegebenheiten besser zu entsprechen. Es ist dabei
jedoch zu beachten, dass die Planung und Umsetzung der neuen Struktur
meist mit groem Aufwand verbunden ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Im Rahmen der Migration einer Domne ist zustzlich von Bedeutung, ob native mode oder mixed
nach Abschluss der Migration weiterhin Windows NT Backup-Domnen- mode
Controller (BDC) innerhalb der Domne betrieben werden oder nicht. Davon
hngt ab, ob die Windows 2000 Domne im so genannten "nativen Modus"
(native mode) oder im so genannten "gemischten Modus" (mixed mode)
betrieben werden kann. Im gemischten Modus untersttzen die Windows 2000
Domnen-Controller weiterhin alle Mechanismen und Protokolle, um mit den
BDCs wie ein Windows NT Primrer Domnen-Controller (PDC) zu kommu-
nizieren. Dies hat jedoch den Nachteil, dass auch unter Windows 2000
bestimmte Funktionen, die von Windows NT nicht untersttzt werden, nicht
genutzt werden knnen. Existieren nach der Migration keine Windows NT
BDCs im Netz, so kann die Windows 2000 Domne in den nativen Modus
geschaltet werden. Es sei an dieser Stelle darauf hingewiesen, dass auch
Client- oder Server-Rechner mit lteren Windows Versionen durchaus
Mitglied in einer Windows 2000 Domne sein knnen, die im nativen Modus
betrieben wird. Vor der Umstellung einer Domne auf den nativen Modus ist
zu beachten, dass diese Umstellung nicht wieder rckgngig gemacht werden
kann. Eine Rckkehr zu einer Windows NT-Domne ist dann nicht mehr
mglich.
Die wesentlichen Einschrnkungen des gemischten Modus sind:
- Es existiert eine Greneinschrnkung der Windows NT SAM.
- Folgende, unter Windows 2000 neu eingefhrte Gruppentypen und Funkti-
onen stehen nicht zur Verfgung:
- Universelle Sicherheitsgruppen
- Domnen-lokale Gruppen
- Verschachtelte Gruppen
- Transitive Kerberos-Vertrauensstellungen
Vorteilhaft am gemischten Modus ist, dass jederzeit wieder auf Windows NT
umgestellt werden kann, indem ein vorhandener Windows NT BDC zum PDC
heraufgestuft wird, nachdem alle Windows 2000 Domnen-Controller vom
Netz genommen worden sind.
Fr die eigentliche Rechnerumstellung auf Windows 2000 kann grob
zwischen folgenden Verfahren unterschieden werden, die sich im wesent-
lichen im zustzlichen Hardware-Bedarf unterscheiden:
1. In-place-Umstellung: Bei dieser Umstellungsart kommt die jeweilige In-place-Umstellung
Update-Version von Windows 2000 zum Einsatz. Auf die Rechner wird -
nach vorheriger Datensicherung - Windows 2000 aufgespielt. Dabei wird
das Vorgngersystem durch Windows 2000 ersetzt und analog zur existie-
renden Version konfiguriert. Bei dieser Variante ist keine zustzliche
Hardware notwendig. Nachteilig ist jedoch, dass der umzustellende
Rechner whrend der Umstellung nicht zur Verfgung steht.
2. Migration durch parallelen Aufbau eines separaten Windows 2000 Netzes: separates Netz
Bei dieser Migrationsart wird parallel zum existierenden Netz ein quiva-
lentes Windows 2000 Netz aufgebaut. Nach erfolgreichem Aufbau des
Parallelnetzes wird dieses genutzt. Vorteilhaft ist hierbei, dass das existie-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
rende System nicht beeinflusst wird. Nachteilig ist hier jedoch der hohe
Bedarf an zustzlicher Hardware.
3. Rollende Migration: Bei dieser Variante der parallelen Migration wird das rollende Migration
existierende Netz in Teilbereiche aufgeteilt. Die Teilbereiche werden dann
nacheinander auf Windows 2000 umgestellt. Dabei wird zunchst jeweils
fr das Teilnetz eine parallele Struktur aufgebaut, die dann nach erfolgtem
Aufbau genutzt wird. Die so freigesetzte Hardware des Altsystems kann
dann fr den Aufbau des parallelen Systems des nchsten Teilsystems
genutzt werden.
Fr die Migrationsreihenfolge von Rechnern kann unterschieden werden
zwischen:
1. Client-Update-first: Hierbei werden zunchst die Arbeitsplatzrechner auf
Windows 2000 umgestellt und innerhalb der existierenden NT Domne
betrieben. Danach werden die Server und die Domne nach Windows 2000
migriert. Vorteil dieser Umstellungsart ist, dass Benutzer bereits mit der
neuen Bedienoberflche arbeiten knnen, ohne dass serverseitig wichtige
Systemdienste umgestellt werden mssen.
2. Server-Update-first: Hierbei werden zunchst die Server auf Windows
2000 umgestellt. In der Regel erfolgt dabei zunchst eine Domnen-
Umstellung und die Server werden in die Windows 2000 Domne integ-
riert. Danach erfolgt die Umstellung der Clients. Vorteil dieser Umstel-
lungsart ist, dass Benutzer mit dem gewohnten Client-Betriebssystem
arbeiten knnen und die Umstellung der wichtigen Systemdienste im
Hintergrund vollzogen werden kann.
Wie bereits erwhnt, kann an dieser Stelle keine Empfehlung fr eine der
Migrationsvarianten gegeben werden. Generell sind fr die Planung der
Migration jedoch folgende Aspekte zu bedenken:
- Es muss ein realistischer Zeitplan fr die Migration erstellt werden. Im Zeitplan erstellen
Laufe der Migrationsplanung muss mit Angleichungen des Zeitplanes
gerechnet werden.
- Es muss sichergestellt sein, dass die existierenden Betriebssysteme auf
Windows 2000 umgestellt werden knnen: So ist es z. B. nicht mglich,
Windows NT 3.51 direkt auf Windows 2000 umzustellen. Hier muss eine
Zwischenumstellung, z. B. auf Windows 95/98 oder NT 4.0, eingeplant
werden.
- Die existierende Domnenstruktur muss erfasst werden. Nur so kann eine
korrekte Planung der Windows 2000 Domnenstruktur erfolgen.
- Es muss ein Notfallplan erstellt werden, der sicherstellt, dass bei einem Notfallplan erstellen
fehlgeschlagenen Migrationsversuch ein operatives System schnell wieder-
hergestellt werden kann.
- Der Migrationsplan muss eine Strategie zur Umstellung der Domain
Controller festlegen (In-place-Upgrade, Parallel-Upgrade, Reihenfolge).
- Die Reihenfolge, in der die existierenden Domnen umgestellt werden
sollen, muss festgelegt werden. Da die erste umgestellte Domne die Rolle
der so genannten Forest-Root-Domne (FRD) erhlt, ist die Wahl der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Domne, die als erste umgestellt werden soll, besonders wichtig. Es kann
u. U. sinnvoll sein, keine der existierenden Domnen mit der Rolle der
FRD zu betrauen und die FRD vllig neu zu erzeugen.
- Fr jede Domne muss entschieden werden, ob und wann diese in den
nativen Modus umgeschaltet wird. Ziel einer Migration sollte immer die
vollstndige Umschaltung aller Domnen in den nativen Modus sein.
- Im Rahmen der Migrationsplanung sollte entschieden werden, ob eine Sollen Domnen
restrukturiert werden?
Restrukturierung der Domnen notwendig oder gewnscht ist. Ist dies der
Fall, muss der Restrukturierungsprozess geplant werden.
- Fr jede Domne muss die Migration von Benutzern und Benutzergruppen Wie und wann werden
Benutzer und Gruppen
geplant werden. Es ist dabei darauf zu achten, dass die Migration Einfluss migriert?
auf die Zugriffsberechtigungen hat, da sich die SID eines Benutzerkontos
bei der Migration ndert. Windows 2000 bietet hier den Mechanismus der
so genannten SID-History an, der es einem nach Windows 2000 migrierten
Benutzerkonto erlaubt, unter der Pr-Windows 2000 Identitt (SID) auf
Ressourcen zuzugreifen. Es ist hierbei darauf zu achten, dass einerseits die
SID-History nach der vollstndigen Migration fr alle Benutzerkonten
gelscht wird und andererseits nicht alle Windows 2000 Vorgngerver-
sionen SID-Histories untersttzen, z. B. Windows NT 3.51.
- Fr jede Domne muss die Migration von Rechnern, also Clients und Wie und wann werden
Clients und Server
Servern, geplant werden. Es ist dabei darauf zu achten, ob insbesondere die migriert?
Migration von Applikationsservern problemlos mglich ist, oder ob
bestimmte Applikationen eine Migration verhindern, weil diese beispiels-
weise auf einem BDC installiert sein mssen. Werden Clients vor Servern
auf Windows 2000 umgestellt und ohne Windows 2000 Active Directory
Untersttzung betrieben, so muss bercksichtigt werden, dass nach
Umstellung der Server auf Windows 2000 und Einfhrung des Active
Directory u. U. eine nochmalige Neuinstallation der Clients notwendig ist,
um deren gewnschte Systemkonfiguration sicherzustellen.
- Whrend der Migration existieren Windows 2000 Domnen und (meist) Vertrauensstellung
zwischen alten und
Windows NT Domnen nebeneinander. Der Zugriff auf Ressourcen der NT neuen Domnen
Domne kann dabei auch ber schon nach Windows 2000 migrierte Benut-
zerkonten erfolgen. Zwischen Windows 2000 Domnen und Windows NT
Domnen muss jedoch eine explizite Vertrauensstellung definiert werden,
damit der Zugriff erfolgen kann. Es sollten hierbei nur die notwendigen
Vertrauensstellungen erzeugt werden. Es empfiehlt sich auerdem, NT-
Kontendomnen vor NT-Ressourcendomnen auf Windows 2000 umzu-
stellen. Dadurch muss die Vertrauensstellung nur einseitig von den NT-
Ressourcendomnen fr eine Windows 2000 Domne erfolgen.
- Bei der Durchfhrung der Migration werden in der Regel diverse Migrati- Welche Tools werden
eingesetzt?
onswerkzeuge eingesetzt. In der Migrationsplanung muss auch der Werk-
zeugeinsatz geplant werden. Es ist festzulegen, welche Werkzeuge fr
welche Migrationsschritte zum Einsatz kommen sollen.
- Whrend der technischen Migrationsvorbereitung findet in der Regel eine
Informationssammelphase statt, bei der - meist werkzeuggesttzt -
Systeminformationen, wie Benutzerkonten, Zugriffsrechte usw., zusam-
mengetragen werden. Damit die benutzten Werkzeuge auf diese Infor-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
mationen zugreifen knnen, ist es je nach Vorgehensweise notwendig,

zustzliche Vertrauensstellungen zwischen den existierenden NT-Domnen
einzurichten. Es ist dabei zu beachten, dass dadurch potentielle Sicher-
heitslcken erzeugt werden knnen.
- Oft wird ein spezielles Migrationsteam mit der Aufgabe der Migration Migrationsteam
benennen
betraut. Die Mitglieder dieses Teams mssen dafr jedoch mit weit-
reichenden Berechtigungen sowohl innerhalb des existierenden Systems als
auch innerhalb des Windows 2000 Systems ausgestattet werden. Es ist
daher in solchen Fllen darauf zu achten, dass nur vertrauenswrdige
Personen mit diesen Aufgaben betraut werden. Im Migrationskonzept
sollte auerdem festgelegt sein, welche Aufgaben nur im Vier-Augen-Prin-
zip erfolgen drfen.
- Nach Abschluss der Migration empfiehlt sich ein Soll-Ist-Vergleich aller abschlieender Soll-Ist-
Vergleich
Sicherheitseinstellungen, wie z. B. der Zugriffsberechtigungen und der
Gruppenmitgliedschaften. Dies ist in der Regel jedoch nur werkzeug-
gesttzt mglich.
Die hier aufgefhrten Aspekte dienen als Leitfaden fr hnliche und weiter-
gehende Fragestellungen, die im Rahmen des Migrationskonzeptes adressiert
werden mssen. Es ist zu beachten, dass ein Migrationsplan immer auf ein
konkretes System zugeschnitten sein muss und die jeweiligen lokalen Anfor-
derungen an die Migration reflektiert.
- Wurde eine bedarfsgerechte Migrationsplanung durchgefhrt?
- Sind alle Werkzeuge, die im Rahmen der Migration bentigt werden,
bekannt und getestet?
- Wurde ein zeitliche Migrationsreihenfolge entworfen?
- Ist sichergestellt, dass die weitreichenden Berechtigungen des Migra-
tionsteams nach Abschluss der Migration wieder zurckgesetzt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.234 Konzeption von Internet-PCs

Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsbeauftragter
Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsbeauftragter
Nach der Entscheidung, einen oder mehrere Internet-PCs fr die Nutzung von
Internet-Angeboten und -Diensten zur Verfgung zu stellen, sollte ein
Konzept fr die konkrete Realisierung erstellt werden. In diesem Konzept
sollten die funktionale Anforderungen, IT-Sicherheitsanforderungen, erfor-
derliche Regelungen, Zustndigkeiten sowie Vorgaben fr die technische
Realisierung und Nutzung festgelegt werden.
Es wird empfohlen, bei der Konzeption mindestens die folgenden Teilaspekte
zu bercksichtigen. Je nach den vorliegenden organisatorischen Randbe-
dingungen mssen unter Umstnden weitere Punkte in das Konzept aufge-
nommen werden. Hinweise hierzu knnen den Bausteinen 7.3 Firewall und
7.5 WWW Server entnommen werden.
Funktionale Anforderungen
Als Erstes sollte festgelegt werden, welche im Internet angebotenen Dienste, Welche Dienste sollen
genutzt werden?
z. B. World Wide Web (WWW), E-Mail, News oder Instant Messaging,
genutzt werden sollen. Dies hat weitgehende Auswirkungen auf die zu instal-
lierende Software und die erforderlichen Sicherheitsmanahmen.
Um einen geeigneten Internet Service Provider (ISP) und eine zweckmige
Anschlusstechnik auswhlen zu knnen, sollten weiterhin die bentigten
Bandbreiten und Antwortzeiten fr die einzelnen Internet-Dienste dokumen-
tiert werden.
Um Kriterien fr die Aufstellungsorte der Internet-PCs zu erhalten, sollte
anschlieend im Konzept dokumentiert werden, wie hoch das voraussichtliche
Nutzeraufkommen ist und welche Anforderungen hinsichtlich der rumlichen
Nhe des Internet-PCs zum Mitarbeiter bestehen.
Weiterhin sollte festgelegt werden, wie mit Daten aus dem Internet, z. B.
heruntergeladenen Dateien, umgegangen wird, ob diese z. B. auf anderen
Systemen weiterverarbeitet werden drfen oder archiviert werden mssen. Ein
Datenaustausch zwischen Internet-PC und Hausnetz erfordert zustzliche IT-
Sicherheitsmanahmen und Regelungen.
IT-Sicherheitsanforderungen
Hinsichtlich der IT-Sicherheitsanforderungen sollte im Konzept festgelegt
werden, ob die Informationen, die aus dem Internet abgerufen oder an andere
Computer im Internet gesendet werden, gegen unbefugtes Mitlesen oder
unerlaubte Vernderung geschtzt werden mssen.
Weiterhin ist im Konzept zu dokumentieren, ob auf dem Internet-PC
schtzenswerte Daten abgespeichert und lngere Zeit vorgehalten werden
mssen. Dies ist besonders dann relevant, wenn der Internet-PC auch fr
E-Mail verwendet wird.
Im Hinblick auf Zurechenbarkeit und Schutz vor unerlaubter Nutzung sollte
festgelegt werden, ob sich Benutzer am Internet-PC authentisieren mssen,
bevor sie den Internet-Zugang verwenden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Einsatzkonzept sollte auch Aussagen zu Anforderungen an die Verfg-

barkeit enthalten. Es ist daher festzulegen, ob ein Ausfall des Internet-PCs fr
lngere Zeit tolerabel ist oder ob fr diesen Fall Ausweichlsungen geschaffen
werden mssen.
Erforderliche Regelungen
Im Hinblick auf die Nutzung eines Internet-PCs mssen bestehende Regelun-
gen angepasst oder neu festgelegt werden. Dazu gehren insbesondere das IT-
Sicherheitskonzept und die Benutzerrichtlinie (siehe auch M 2.235 Richtlinien
fr die Nutzung von Internet-PCs). Je nach Standort kann der Einsatz eines
Internet-PCs aber beispielsweise auch Auswirkungen auf bestehende Zutritts-
regelungen haben.
Zustndigkeiten
Auch Internet-PCs mssen durch fachkundiges Personal administriert und Ansprechpartner fr
Benutzer
gewartet werden. Im Einsatzkonzept sollte daher festgelegt werden, welche
Mitarbeiter bzw. Rollen fr Administration und Betrieb des Internet-PCs
zustndig sind und wer zu benachrichtigen ist, wenn der Internet-PC ausfllt
oder wenn Anzeichen fr einen Sicherheitsvorfall entdeckt werden.
Da sich das Nutzungsprofil und die Einsatzumgebung von Internet-PCs
schnell ndern knnen, muss das Konzept fortgeschrieben werden. Es sollte
dokumentiert werden, wer hierfr zustndig ist.
Vorgaben fr die technische Realisierung (Hardware)
Im Konzept sollte vorgegeben werden, wie viele Internet-PCs zum Einsatz
kommen und ob diese untereinander vernetzt und mit einer gemeinsamen
Internet-Anbindung ausgestattet werden sollen. In diesem Fall sollte auch
festgelegt werden, was fr Komponenten zur Vernetzung verwendet werden.
Weiterhin sollte die Hardware-Ausstattung der Internet-PCs definiert werden.
Dazu gehren z. B. die Hardware-Plattform, Laufwerke, Schnittstellen und
Peripheriegerte.
Falls eine Datensicherung des Internet-PCs erforderlich ist, sollte im Konzept
festgelegt werden, ber welche Medien oder Schnittstellen diese erfolgt.
Vorgaben fr die technische Realisierung (Software)
Um die Administration zu vereinfachen, sollten alle Internet-PCs mglichst Standardisierung redu-
ziert Betreuungsaufwand
gleich ausgestattet sein. Die Software-Ausstattung sollte daher im Konzept
weitgehend vorgegeben werden.
Das verwendete Betriebssystem sollte auf jeden Fall im Einsatzkonzept fest-
gelegt werden. Falls eine Authentisierung der Benutzer erforderlich ist, sollten
nur Betriebssysteme mit einer wirksamen Benutzertrennung, z. B.
Windows NT/2000 oder Linux, eingesetzt werden. Windows 9x/ME sind in
diesem Fall ungeeignet.
Weiterhin sollte dokumentiert werden, welche Client-Programme fr Internet-
Dienste zum Einsatz kommen sollen. In vielen Fllen wird zumindest ein
WWW-Browser und ein E-Mail-Client bentigt. Weitere Beispiele sind
News-Clients und Instant Messaging-Programme.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Um die IT-Sicherheitsanforderungen erfllen zu knnen, mssen meist Sicherheitstools

zustzliche Sicherheitstools installiert werden, z. B. fr den Schutz vor installieren
Computer-Viren, zur Datensicherung oder zur Verschlsselung. Im Konzept
sollte festgelegt werden, welche Produkte hierfr ggf. verwendet werden.
Vorgaben fr die technische Realisierung (Internet-Anbindung)
Das Einsatzkonzept sollte detaillierte Vorgaben zur technischen Realisierung
der Internet-Anbindung machen, um die Anforderungen an Bandbreite,
Antwortzeiten und Verfgbarkeit erfllen zu knnen (siehe auch M 5.92
Sichere Internet-Anbindung von Internet-PCs). Hierzu gehrt einerseits die
Frage, ber welchen oder welche Internet Service Provider (ISP) der Zugang
zum Internet erfolgen soll (siehe auch M 2.176 Geeignete Auswahl eines
Internet Service Providers).
Andererseits muss auch festgelegt werden, ber welche Zugangstechnik, z. B.
ISDN oder DSL, die Internet-Anbindung erfolgen soll und welche Schnitt-
stelle des Internet-PCs, z. B. ISDN-Karte oder Netzwerkkarte, hierfr
verwendet wird. Je nach verwendeter Zugangstechnik werden unter Umstn-
den spezielle Programme oder Hardware-Komponenten, z. B. DSL-Modem
bzw. Router, bentigt.
- Wurde ein Nutzungskonzept fr den Einsatz von Internet-PCs erstellt?
- Enthlt das Nutzungskonzept auch die IT-Sicherheitsanforderungen an den
Internet-Zugang?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.235 Richtlinien fr die Nutzung von Internet-PCs

Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsbeauftragter
Fr die sichere Nutzung von Internet-PCs ist es erforderlich, dass hierfr
verbindliche Richtlinien festgelegt werden. Diese Richtlinien mssen allen
beteiligten Mitarbeitern der Institution, d. h. mindestens den Benutzern des
Internet-PCs und den zustndigen Administratoren, bekannt gemacht werden.
Es wird empfohlen, die Richtlinien fr die Nutzung des Internet-PCs in einem
Dokument zusammenzufassen und als Datei auf dem Internet-PC zur Verf-
gung zu stellen, z. B. auf dem Desktop. Dabei sollten mindestens folgende
Teilaspekte bercksichtigt werden:
Die Benutzer sollten in kurzer, verstndlicher Form ber die Risiken infor- Benutzer ber Risiken
informieren
miert werden, die mit der Nutzung des Internet-PCs verbunden sind. Diese
Information dient gleichzeitig als Motivation fr die nachfolgenden Richt-
linien.
Auch der Internet-PC muss durch fachkundiges Personal administriert und fachkundige
Administration
gewartet werden. Dies kann entweder durch die vorhandene Administration,
z. B. fr IT-Systeme im Hausnetz, oder durch andere Mitarbeiter erfolgen, die
dann entsprechend geschult werden mssen. Die Zustndigkeit sollte in den
Richtlinien dokumentiert werden.
In einigen Fllen kann es zweckmig sein, dass Benutzer bestimmte Konfi-
gurationseinstellungen selbst vornehmen drfen. Dies sollte in den Richtlinien
vermerkt, anderenfalls sollte es untersagt werden.
In den Richtlinien sollte festgelegt werden, welche Personen den Internet-PC Wer, wann, wofr
zu welchen Zeiten und fr welche Zwecke benutzen drfen. In diesem
Zusammenhang ist insbesondere festzulegen, ob nur dienstliche oder auch
private Nutzung - z. B. in der Mittagspause - zugelassen ist.
Weiterhin sollte dokumentiert werden, welche Programme fr die Nutzung
von Internet-Diensten verwendet werden drfen und ob aktive Inhalte, wie
z. B. Javascript, Java oder ActiveX, auf dem Internet-PC ausgefhrt werden
drfen. Wichtig ist in diesem Zusammenhang auch, ob Benutzer selbstndig
Browser-Erweiterungen ("Plug-Ins") installieren und nutzen drfen.
Falls das verwendete Betriebssystem eine Benutzertrennung untersttzt, soll-
ten Client-Programme fr die Nutzung von Internet-Diensten nicht unter dem
Administrator-Benutzerkonto, z. B. root oder Administrator, gestartet werden.
Auch von Administratoren sollten hierfr normale Benutzerkonten verwendet
werden.
Es mssen Regelungen dafr festgelegt werden, welche persnlichen Daten Weitergabe von
Informationen
und welche Informationen ber die Behrde bzw. das Unternehmen, z. B.
Postadressen, ber den Internet-Zugang weitergegeben werden drfen. Dazu
gehrt auch die Frage, ob Nachrichten mit einer dienstlichen Absenderadresse
gesendet werden drfen, falls der Internet-PC fr E-Mail oder News genutzt
wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Auerdem sollte in den Richtlinien vorgegeben werden, welche Daten auf Umgang mit Daten aus
dem Internet-PC abgespeichert werden drfen und welche Verzeichnisse hier- dem Internet
fr vorgesehen sind. Es muss auch geregelt werden, unter welchen Bedingun-
gen Daten vom Internet-PC in das Hausnetz oder umgekehrt transportiert
werden drfen.
In beiden Fllen ist mindestens eine Prfung auf Computer-Viren durchzu-
fhren. Fr den Import von Daten und Programmen ins Hausnetz wird der
Einsatz eines Schleusen-PCs empfohlen.
Falls eine lokale Datenhaltung auf dem Internet-PC vorgesehen ist, muss
geregelt werden, ob die Benutzer fr eine evtl. erforderliche Datensicherung
selbst verantwortlich sind oder ob dies automatisch bzw. durch die Administ-
ration geschieht. Dies ist besonders wichtig, wenn der Internet-PC fr E-Mail,
Banking, elektronische Beschaffung oder hnliche Aufgaben eingesetzt wird.
Die Benutzer mssen darber belehrt werden, welche Angebote, z. B. illegale unerlaubte Inhalte
Inhalte, Pornographie oder Extremismus, auf keinen Fall genutzt werden
drfen. Auerdem mssen die Benutzer darber belehrt werden, dass sie sich
bei der Nutzung des Internets an geltende Rechtsvorschriften und die
"Netiquette" halten mssen, da sie ja im Namen der Behrde bzw. des Unter-
nehmens agieren.
Fr die Einwahl beim Internet Service Provider oder fr die lokale Anmel- Umgang mit
Authentisierungsdaten
dung am Internet-PC werden meist Passwrter bentigt. In den Richtlinien
sollte vorgegeben werden, welches Format und welche (Mindest-)lnge diese
Passwrter haben und wie oft sie gendert werden mssen.
Falls eine Benutzer-Authentisierung im Einsatzkonzept vorgesehen ist, sind
die Benutzer darber zu belehren, dass sie mit den Authentisierungs-
geheimnissen sorgfltig umgehen und sich vom System abmelden mssen,
wenn sie den Internet-PC verlassen.
Schlielich sollte festgelegt werden, ob das fr die Einwahl beim Internet
Service Provider bentigte Passwort abgespeichert werden darf oder ob es bei
jeder Einwahl erneut eingegeben werden muss. Diese Entscheidung sollte auf
einer Einschtzung beruhen, wie gro die Gefahr einer missbruchlichen
Nutzung der Internet-Anbindung im vorliegenden Einsatzumfeld ist. Ein dop-
pelter Zugangsschutz (erst Benutzeranmeldung, dann Eingabe des Einwahl-
passwortes) wird von Benutzern oft nicht akzeptiert.
Je nach Anwendungsfall und Einsatzumgebung mssen unter Umstnden
weitere Richtlinien oder Regelungen fr den Internet-PC getroffen werden.
- Wurden fr die Nutzung des Internet-PCs alle erforderlichen Richtlinien
festgelegt?
- Sind die Richtlinien allen Benutzern des Internet-PCs bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.236 Planung des Einsatzes von Novell eDirectory

Grundstzlich gibt es zwei Einsatzszenarien fr eDirectory:
- der Einsatz als Managementprodukt fr Ressourcen in einem gegebenen
Netz oder
- die Verwendung als (Meta-)Verzeichnisdienst (LDAP-Server).
Abstrakt gesehen bildet das eDirectory eine hierarchisch und baumartig orga-
nisierte, Objekt-basierte Datenbank. Es ist an den Verzeichnisdienst-Standard
X.500 angelehnt, von dem es die interne Struktur und den internen Aufbau
entliehen hat. Es ist jedoch kein X.500-kompatibler Verzeichnisdienst, da das
Zugriffsprotokoll auf dem proprietren NDAP (Novell Directory Access
Protocol) basiert.
Das Baum-Konzept von eDirectory stellt sich auf folgende Weise dar: in Baum-Konzept
einem Baum (Tree) werden Server, Benutzer und weitere Ressourcen abgebil-
det und knnen durch den Baum-Administrator verwaltet werden. Ein Baum
bildet grundstzlich eine administrative Grenze und limitiert auch den
Wirkungsbereich von Berechtigungen.
Ein eDirectory-Verzeichnisbaum besteht aus verschiedenen Objekten. Jedes Schema
Objekt gehrt einer ausgezeichneten Klasse an, z. B. Benutzerobjekt oder
Serverobjekt, und ist gem dieser Klasse aus verschiedenen Attributen bzw.
Eigenschaften zusammengesetzt. Die verschiedenen Objektattribute knnen
unterschiedliche Werte aufnehmen, z. B. Telefonnummer oder IP-Adresse.
Die Informationen ber die bestehenden Objektklassen inklusive der darin
vorkommenden Attribute werden im Directory-Schema gehalten. Durch
nderungen der Schemadefinition knnen neue Objektklassen erzeugt oder
bestehende Objektklassen mit vernderten Attributstzen versehen werden.
Bei Vernderung des Schemas spricht man dann vom Extended Schema.
eDirectory kennt verschiedene vordefinierte Objekttypen:
- Tree-Objekt: Dieses Objekt ist die Wurzel aller eDirectory-Objekte eines
Verzeichnisbaums und enthlt Informationen ber diesen, z. B. Name des
Baums. Unterhalb des Tree-Objekts knnen weitere Objekte angeordnet
sein.
- Container-Objekte: Diese Objekte dienen dazu, andere Objekte zu gruppie-
ren. Standardmig stehen die Objekte Land (Country, C), Organisation
(Organization, O) und Organisations-Einheit (Organizational Unit, OU) zur
Verfgung. Unterhalb eines OU-Objektes knnen weitere OU-Objekte ent-
halten sein, sowie so genannte Leaf-Objekte (siehe unten).
- Leaf-Objekte: Dies sind Server-, Benutzer-, Benutzer-Gruppen-, Rollen-,
Drucker-, Druckerwarteschlangen-, Profil- sowie Applikations-Objekte.
Weiterhin knnen auch Alias-Objekte zum Verweis auf bestehende
Objekte in anderen Teilbumen definiert werden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
In einem eDirectory-Baum gibt es immer eine ausgezeichnete Wurzel, die eine Wurzel- und
Zertifizierungsstelle
gewisse Sonderstellung besitzt: sie wird bestimmt durch den ersten Server, der
in einem Baum installiert wird. Auf diesem Server luft die Zerti-
fizierungsstelle (CA) des Baums, der Voraussetzung fr die Einbindung
weiterer eDirectory-Server in den Baum ist. Die CA kann spter auch auf
einen anderen eDirectory-Server verschoben werden. Smtliche weiteren
eDirectory-Installationen mssen sich bei dem gegebenen eDirectory-Baum
anmelden. Dabei muss der genaue Kontext, in dem der eDirectory-Server in
einen bestehenden Baum eingebunden wird, angegeben werden. Ein spteres
Verschieben der eDirectory-Server ist nur sehr schwer mglich, so dass der
Server-Kontext im Voraus geplant werden muss.
Die ersten drei eDirectory-Server eines Baums erhalten automatisch eine vollautomatische
Replizierung
stndige Replica der Verzeichnisdaten, die weiteren nicht mehr - sofern dies
nicht explizit so konfiguriert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Nach einer Standardinstallation existiert eine zunchst einfache eDirectory- Baumstruktur sorgfltig
Struktur, die von eDirectory angelegt wird und dann entsprechend der Planung planen
verndert werden kann. Da eDirectory primr der Verwaltung von IT-Res-
sourcen dient, sollte beim Aufbau der eDirectory-Baumstruktur darauf geach-
tet werden, dass die Struktur vornehmlich auf administrative Gegebenheiten
abgestimmt wird. Wenn stattdessen zwanghaft die organisatorische Unter-
nehmensstruktur bis ins Kleinste nachgebildet wird, kann dies zu Problemen
in der Administration fhren.
Es ist weiterhin darauf zu achten, dass die gewhlte Baumstruktur nicht zu Baumstruktur nicht zu
flach whlen
flach ist, damit sich die Replizierung zwischen den eDirectory-Servern nicht
auf den gesamten Baum auswirkt. Der Ausfall eines einzelnen eDirectory-
Servers oder der Verbindung dieses Servers zum Restsystem fhrt anderen-
falls zu Fehlermeldungen smtlicher in den Replizierungsring eingebundener
Server.
Die mglichen Anordnungen von eDirectory-Objekten, d. h. welches Objekt Vorsicht bei
Schemanderungen
welche anderen Objekte enthalten darf, welche Attribute existieren und aus
welchen Attributen Objekte zusammengesetzt werden, wird durch das so
genannte eDirectory-Schema definiert. Das von eDirectory vorgegebene
Schema kann verndert werden, dies stellt jedoch einen gravierenden Eingriff
in die Verzeichnisstruktur dar, der nur nach sorgfltiger Planung durchgefhrt
werden darf.
Der eDirectory-Verzeichnisdienst bietet die Mglichkeit, mit anderen DirXML-Schnittstelle
Verzeichnisdiensten ber einen Synchronisationsmechanismus Daten im
XML-Format abzugleichen. Als XML-Schnittstelle steht dazu das Produkt
DirXML zur Verfgung. Diese besteht aus einem Kern (engine) und verschie-
denen Treibern fr diverse untersttzte Zielsysteme, z. B. Lotus Notes, SAP
R/3, Windows 2000 Active Directory, Netscape (iPlanet), etc. Es gibt dabei
zwei Kommunikationskanle: Zum einen den so genannten Publisher
Channel, unter dem fremde Verzeichnisdienste nderungen ihres Daten-
bestandes dem eDirectory mitteilen knnen. Zum anderen gibt es den Subscri-
ber Channel, mit dessen Hilfe eingeschriebene fremde Verzeichnisdienste von
nderungen im eDirectory erfahren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Der Einsatz der DirXML-Schnittstelle bedarf auf jeden Fall einer genauen
Planung, um spter unerwnschte Seiteneffekte zu vermeiden, z. B. Endlos-
schleifen.
Im Rahmen der eDirectory-Planung sind folgende Aspekte zu bercksich-
tigen:
- Welche Gliederung in Organisations-, Organisationseinheit- und weitere
Container-Objekte soll gewhlt werden?
- Welche Objektklassen werden bentigt und welche Attribute sollen diese
haben?
- Welche Benutzer und Server sollen in welchen Organisationseinheiten
zusammengefasst werden?
Fr jede Organisation muss entschieden werden,
- welche Administratorgruppen bentigt werden,
- welches administrative Modell umgesetzt wird (zentrale oder dezentrale
Verwaltung),
- welche administrativen Rollen innerhalb der Baumstruktur existieren
sollen,
- ob und an wen administrative Aufgaben delegiert werden sollen,
- welche Sicherheitseinstellungen fr verschiedene Typen von Servern und
Benutzergruppen gelten sollen,
- auf welche Informationen ber die verschiedenen eDirectory-Schnittstellen
(z. B. eDirectory-Clients, LDAP) von wem zugegriffen werden darf.
Generell muss die geplante eDirectory-Struktur dokumentiert werden. Dies Dokumentation der
eDirectory-Struktur
trgt mageblich zur Stabilitt, konsistenten Administration und damit zur
Systemsicherheit bei. Es empfiehlt sich insbesondere festzuhalten:
- Welche Schemanderungen werden durchgefhrt? Dabei sollen auch die
Grnde fr die nderung dokumentiert sein.
- Welche Objektklassen werden in welcher Weise verwendet, speziell
welche Attribute werden fr welche Inhalte genutzt?
Fr jedes eDirectory-Objekt sollte dokumentiert sein: Dokumentation der
eDirectory-Objekte
- Name und Position im eDirectory-Baum (z. B. "StandortBerlin", Vater-
Objekt: OU "Filialen-Deutschland"),
- welchem Zweck das Objekt dient,
- welche administrativen Zugriffsrechte fr das Objekt und dessen Attribute
vergeben werden sollen (z. B. vollstndig verwaltet von "Admin1"),
- wie die Vererbung von eDirectory-Rechten konfiguriert werden soll, z. B.
blockieren oder filtern der Rechtevererbung,
- welche Sicherheitsquivalenzen zwischen Objekten bestehen sollen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die eDirectory-Administration und das benutzte administrative Modell muss Rollen-basierte

auf jeden Fall geplant werden. Besonders auch die Einrichtung einer Rollen- Administration und
basierten Administration und die Mglichkeit der Delegation von Administra- Delegation
tionsaufgaben sind sicherheitskritisch. Bei sinnvoller, bersichtlicher und
konsistenter Planung kann die Sicherheitsadministration durch diese Funktio-
nalitten transparenter und effizienter gestaltet werden.
Die Nutzung von eDirectory beinhaltet den Betrieb einer eigenen, eingebun-
denen Zertifizierungsstelle (CA). Auch hier muss sich die Planung nach den
Anforderungen und besonders nach der zuvor aufgestellten Sicherheitsleitlinie
richten.
Zusammengefasst ergeben sich folgende sicherheitsrelevante Kernaspekte bei
der eDirectory-Planung:
- Bume begrenzen die administrative Macht von Administratoren und den
Verzeichnisdienst an sich.
- Standardmig ist bei der Erstinstallation von eDirectory der Benutzer
Admin innerhalb des Organisationscontainers des eDirectory-Baums ange-
legt. Dieser besitzt das so genannte Supervisor-Recht auf den gesamten
Baum.
- Administrative Delegation wird durch die Vergabe von Zugriffsrechten auf mglichst einfache
eDirectory-Objekte und deren Attribute erreicht. Die Verteilung der Berechtigungsstruktur
Zugriffsrechte muss gem dem administrativen Modell erfolgen. Die whlen
Mechanismen fr Zugriffsrechte im eDirectory sind unter anderem Ver-
erbung, Kontrolle der Vererbung, Wirkungsbereich von Zugriffseinstellun-
gen und Sicherheits-quivalenz zwischen Objekten. Damit knnen sehr
komplexe Berechtigungsstrukturen aufgebaut werden, die sehr schnell
unbersichtlich und nicht mehr administrierbar werden, so dass sich durch
Fehlkonfigurationen im eDirectory Sicherheitslcken ergeben knnen.
Eine mglichst einfache Berechtigungsstruktur ist daher vorzuziehen.
- Schemanderungen sind kritische Operationen und drfen nur von autori-
sierten Administratoren nach sorgfltiger Planung durchgefhrt werden.
Abschlieend sei darauf hingewiesen, dass Fehler in der eDirectory-Planung
und den zugrunde liegenden Konzepten nach erfolgter Installation nur mit
betrchtlichem Aufwand zu berichtigen sind.
- Wurde eine eDirectory-Planung durchgefhrt?
- Wurde fr jeden geplanten eDirectory-Server sein genauer Kontext inner-
halb des Verzeichnisbaums festgelegt?
- Sind alle Beteiligten in die Planung einbezogen worden?
- Ist ein bedarfsgerechtes eDirectory-Berechtigungskonzept entworfen
worden?
- Wurde die Synchronisation der Verzeichnisdaten mit weiteren Verzeich-
nisdiensten geplant?
- Wurde das Konzept der Rollen-basierten Administration konsistent
geplant?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.237 Planung der Partitionierung und Replikation im

Novell eDirectory
Als skalierbarer Verzeichnisdienst bietet eDirectory die Mglichkeit, Teile der Partitionierung
Verzeichnisdatenbank in Partitionen zu zerlegen und auf verschiedene
eDirectory-Server zu verteilen. Dies verkrzt die mittleren Zugriffszeiten, da
die Suche sich unter Umstnden nur auf eine spezielle Partition und nicht den
gesamten Verzeichnisbaum erstrecken muss. Auerdem erhht es die Ausfall-
sicherheit, da bei einem Serverausfall nur die dort befindliche Partition und
nicht die gesamte Verzeichnisdatenbank betroffen ist. Weiterhin erlaubt es die
Partitionierung, die Daten gem einer zuvor vorgenommenen Klassifizierung
auf entsprechend gesicherte Server zu verteilen.
Bei der Planung der Partitionierung sind die vom eDirectory definierten
Regeln fr Partitionen zu bercksichtigen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Partitionen knnen wiederum Unterpartitionen enthalten, welche gem den

festgelegten Regeln gebildet wurden. Auf Partitionen knnen verschiedene
Operationen ausgefhrt werden, z. B. Erzeugen, Zusammenfhren, Bewegen
oder Annullieren einer der genannten Operationen.
Neben dem Mechanismus der Partitionierung des Verzeichnisbaums bietet Replikation
eDirectory die Mglichkeit, Teile des Verzeichnisbaums auf andere eDirec-
tory-Server zu replizieren. In der Terminologie von eDirectory wird dabei von
Replicas gesprochen. In jeder Partition gibt es eine so genannte Master-
Replica. Diese bildet den Mittelpunkt der jeweiligen Partition. Das Anlegen
neuer Unterpartitionen oder neuer Replicas der aktuellen Partition ist von der
Verfgbarkeit des Master-Replica-Servers abhngig. Es gibt verschiedene
Mglichkeiten, die Verzeichnisdaten auf andere Server zu replizieren:
- Read/Write Replica: Auf Read/Write Replicas einer Partition kann genauso
zugegriffen werden, wie auf die Master-Replica selbst. Insbesondere ist es
in einer Read/Write Replica mglich, Modifikationen der Daten vorzu-
nehmen. Die Informationen werden automatisch zwischen den einzelnen
Replicas ausgetauscht. Sofern der Server, auf dem die Master-Replica ge-
halten wird, dauerhaft ausfllt, kann eine Read/Write Replica zur Master-
Replica umkonfiguriert werden.
- Read-Only Replica: Diese Replicas empfangen lediglich Synchronisations-
Updates von anderen Replicas. Clients knnen den Inhalt einer Read-Only
Replica nicht ndern.
- Filtered Read/Write Replica: Auf diese Server wird lediglich ein Teil einer
eDirectory-Partition repliziert. Die Auswahl des replizierten Inhaltes ist
dabei sowohl auf der Ebene der Objektklassen als auch auf der Ebene ein-
zelner Attribute mglich. Der Inhalt dieser Replica kann von Clients ver-
ndert werden. Bei einer nderung des Informationsstandes wird der Inhalt
automatisch mit den weiteren Replicas synchronisiert.
- Filtered Read-Only Replica: Dieser Typ einer Replica enthlt nur eine
Auswahl der gesamten Partition, die zudem nicht durch Clients verndert
werden kann. Fr die Auswahl des zu replizierenden Inhaltes bestehen die
gleichen Mglichkeiten wie bei Filtered Read/Write Replicas.
Die oben beschriebenen Arten von Replicas werden manuell eingerichtet und
konfiguriert. Die Replizierung selbst luft automatisch ab. Ein weiterer Repli-
kationstyp sind die Subordinate-Reference-Replicas. Diese werden vom
eDirectory-System jedoch selbst angelegt und verwaltet. Sie enthalten ledig-
lich Sprungadressen, um effizient Objektnamen ber Partitionsgrenzen hinweg
auflsen zu knnen (so genanntes tree walking).
Bei der Planung der Partitionen sollten folgende Punkte beachtet werden:
- Bercksichtigung des Schutzbedarfs: Die Informationen, die im Verzeich- Schutzbedarf
nis gehalten werden, sollten gem ihrem Schutzbedarf klassifiziert wer-
den. Anhand dieser Klassifizierung sollte die Verteilung der Objekte auf
entsprechend geschtzte Server erfolgen. Dabei ist darauf zu achten, dass
besonders der Inhalt des Security-Containers auf einem ausreichend abge-
sicherten Server gelagert wird, da es sich hierbei um sensitive Informatio-
nen handelt. Im
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Security-Container werden beispielsweise die Key Management Objects

sowie die Security Policies gespeichert.
- geforderte Verfgbarkeit des Verzeichnisdienstes: Zur Verbesserung der
Lastverteilung mssen hinreichend viele Repliken der Verzeichnisdaten
auf eDirectory-Servern angelegt werden.
- Verteilung der Administrationsaufgaben: Damit eine Rollentrennung der
Administrationsaufgaben mit der Trennung der Datenhaltung einhergeht,
sollten die Administrationsaufgaben auf einzelne Partitionen verteilt
werden.
- Einhaltung der eDirectory-Regeln zur Partitionierung. Die wesentlichen
Regeln dabei sind:
- Jede Partition beginnt hierarchisch mit einem einzelnen Container-
Objekt.
- Die Partition muss ein zusammenhngender Sub-Tree des
eDirectory-Baums sein.
- Verschiedene Partitionen drfen sich nicht berschneiden.
- Der Name der Partition muss der Fully Qualified Distinguished
Name (FQDN) des Wurzelobjekts der Partition sein.
- Die genauen Kontexte der Server, welche Partitionen/Replicas halten. Ist
die Struktur zu flach, so entsteht ein hoher interner Replizierungsaufwand.
Darber hinaus fhren einzelne - momentan nicht verfgbare - Server zu
entsprechenden Statusmeldungen bei smtlichen weiteren in den Replizie-
rungsring eingebundenen eDirectory-Servern.
Bei der Planung der Replicas sind folgende Punkte zu bercksichtigen:
- Aus den Anforderungen an Verfgbarkeit und Ausfallsicherheit des
Verzeichnisdienstes mssen die Vorgaben fr die Anzahl der anzulegenden
Replicas abgeleitet werden.
- Die geforderte Systemperformance fhrt zur Planung der Lastverteilung.
- Es muss entschieden werden, ob durch die Definition von Filtern fr
Replicas ein Sicherheitsgewinn erzielt werden kann.
Dieser liegt vor allem in der Mglichkeit einer getrennten Datenhaltung
entsprechend einer zuvor vorgenommenen Klassifizierung der Daten. Es
kann damit das Grundprinzip realisiert werden, dass jeder eDirectory-
Server nur diejenigen Daten hlt, welche er "bentigt" (bzw. welche die
zugreifenden Nutzer oder Applikationen bentigen).
Bei unbedachter Konfiguration kann dieser Sicherheitsgewinn allerdings
wirkungslos bleiben. Ein mglicher Nachteil kann die Systemperformance
sein. Sind gesuchte Daten auf einem eDirectory-Server nicht vorhanden
bzw. nicht sichtbar, weil sie durch entsprechende Filterregeln ausgeblendet
sind, so wird im Hintergrund weitergesucht (sofern dies zugelassen ist).
Eine nicht bedarfsgerechte Konfiguration der Filterregeln kann also die
Systemperformance negativ beeinflussen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel: Ein eDirectory-Server steht im Intranet einer Organisation und

eine Teilmenge der dort gehaltenen Verzeichnisdaten soll auch im Internet
verfgbar sein. Eine mgliche Lsung ist, einen weiteren eDirectory-
Server in der demilitarisierten Zone (DMZ) zwischen Intranet und Internet
mit einer gefilterten Replica aufzustellen, welche nur die im Internet tat-
schlich bentigten Verzeichnisdaten hlt.
- Die Datenhaltung muss geplant werden. Hier geht es um eine mglichst Planung der
Datenhaltung
detaillierte Planung, welche Daten von wem und von wo aus zugreifbar
sein sollen. Fr die Durchsetzung der Vorgaben knnen beispielsweise
gefilterte Replicas eingesetzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.238 Festlegung einer Sicherheitsrichtlinie fr Novell

eDirectory
Als eine der organisatorischen Hauptaufgaben bei der Planung des eDirectory-
Einsatzes muss zunchst eine Sicherheitsrichtlinie fixiert werden. Durch die
Sicherheitsrichtlinie wird festgelegt, welche Sicherheitsbestimmungen in
einem eDirectory-System gelten sollen und wie diese bei der Installation
umgesetzt werden mssen.
Durch die eDirectory-Sicherheitsrichtlinie sollten smtliche sicherheits-
bezogenen Themenbereiche eines eDirectory-Verzeichnisdienstes geregelt
werden. Die folgende Liste gibt einen groben berblick ber die Bereiche, die
durch eine solche Richtlinie geregelt werden sollten. Die Liste muss je nach
Einsatzszenarien in der Behrde bzw. im Unternehmen entsprechend ange-
passt, ausgestaltet und erweitert werden.
Allgemeines:
- Wie sollen eDirectory-Server physikalisch abgesichert werden?
- Welche eDirectory-Komponenten, z. B. ConsoleOne und iMonitor, sollen
genutzt werden?
- Welche Baumstruktur soll gewhlt werden?
- Wie wird diese Baumstruktur partitioniert?
- Werden Schemanderungen vorgenommen?
- Welche Objektklassen mit welchen Attributstzen werden eingesetzt?
- Welche Repliken welchen Typs sollen angelegt werden?
- Welche Rechner sind eDirectory-Server und welche Rechner halten eine
Replica?
Rechtevergabe:
- Welcher Benutzer darf welche Rechte ausben?
- Welcher Administrator darf welche Rechte ausben?
- Welche Authentisierungsverfahren sollen gewhlt werden?
- Wie wird die Vererbung von Rechten innerhalb der Baumstruktur defi-
niert?
- Welche Sicherheitsquivalenzen zwischen Objekten oder Objektklassen
werden definiert?
Administration:
- Welche Administratorrollen werden definiert?
- Wer darf Schemanderungen vornehmen?
- Welche Administrationsaufgaben drfen bzw. sollen delegiert werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Datenkommunikation:
- Welche Datenkommunikation ist abgesichert abzuwickeln?
- Mit welchen Mechanismen werden ggf. Vertraulichkeit, Integritt und
Authentizitt der Daten geschtzt?
Zertifikatsautoritt:
- Welche Parameter fr die CA sind zu verwenden?
- Wer darf Einstellungen der CA ndern?
- Welche Objekte sind mit Zertifikaten zu versehen?
- Welche Zertifikate sind fr SSL-Verbindungen einzusetzen?
Dateisystem des unterliegenden Betriebssystems:
- Welche Berechtigungen auf Systemdateien gelten fr die verschiedenen
Administratoren und Benutzer?
- Soll Verschlsselung auf Dateisystemebene eingesetzt werden?
LDAP:
- Welche Benutzer drfen unter welchen Bedingungen ber LDAP auf das
eDirectory zugreifen?
- Soll anonymer Login untersttzt werden?
- Welche Netzapplikationen drfen via LDAP auf das eDirectory zugreifen?
- Soll die LDAP-Kommunikation generell ber SSL laufen?
- Drfen die Benutzerpasswrter im Klartext bertragen werden?
Client-Zugriff auf den eDirectory-Verzeichnisdienst:
- Welche Authentisierungsverfahren sollen eingesetzt oder erlaubt werden?
- Auf welchen Verzeichnisbaum darf vom Netz aus zugegriffen werden?
- Welche Ressourcen sind aus dem Netz von welchen Benutzern zugreifbar?
Verschlsselung von Attributen
- Soll der Secret Store Mechanismus (verfgbar ber das Zusatzmodul
Secure Login) zur Verschlsselung von Attributen genutzt werden?
Fernzugriff zur Systemberwachung und Administration:
- Darf das Tool iMonitor genutzt werden?
- Wer darf das Tool iMonitor nutzen?
- Wie wird das Protokoll HTTPS zu diesem Zweck konfiguriert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese komponentenspezifische Auflistung von Themengebieten kann in fol-

gende zeitliche Abfolge gebracht werden:
1. Definition der eDirectory-Baumstruktur
Im ersten Schritt ist die logische Struktur des eDirectory-Baumes, die Auf-
teilung in Organisation und Organisationseinheiten sowie insbesondere auch
die Zuordnung der Server und der zu verwaltenden Netz-Ressourcen festzu-
legen (siehe M 2.236 Planung des Einsatzes von Novell eDirectory).
Anschlieend muss ber die im Verzeichnisdienst gehaltenen Objekte und
deren Attribute entschieden werden. Bei Bedarf sind hierzu Schemanderun-
gen am eDirectory vorzunehmen. Weiterhin sollte an dieser Stelle ber die
Partitionierung der Verzeichnisdaten und ber die Einrichtung von Repliken
entschieden werden (siehe M 2.237 Planung der Partitionierung und Replika-
tion im Novell eDirectory).
Ein eDirectory-Verzeichnisdienst sollte von geschulten Netzadministratoren
sicher betrieben werden. Dabei ist im Rahmen der Notfallvorsorge eine geeig-
nete Stellvertreterregelung zu treffen. Generell sollte ein Konzept zur rollen-
basierten Administration erstellt werden. Nur die berechtigten Sicherheits-
Administratoren drfen eDirectory-Sicherheitsparameter verndern.
Die Verantwortlichkeiten der einzelnen Benutzer des eDirectory-Verzeich-
nisses sind unter Schritt 10 dargestellt.
Um die Verwaltung des eDirectory-Verzeichnisbaums zu erleichtern, sollten
eindeutige Namen fr die Server, Applikationen, Drucker, Benutzer, Benut-
zergruppen und die weiteren eDirectory-Objekte verwendet werden.
oder nur fr bestimmte Konten gelten sollen, festgelegt werden. Dies betrifft
insbesondere die Regelungen fr Passwrter und fr die Reaktion des Systems
auf fehlerhafte Login-Vorgnge. Auerdem sollte das Erstellen der Login-
Skripts geregelt werden.
5. Einrichtung von Gruppen (Organizational Roles)
Zur Vereinfachung der Administration sollten Benutzer-Objekte, fr die die
gleichen Anforderungen gelten, zu Gruppen zusammengefasst werden. Die
korrespondierenden eDirectory-Objekte heien Organizational Roles. Benut-
zerrechte sowie Zugriffsrechte auf Verzeichnisobjekte und gegebenenfalls
weitere vordefinierte Funktionen werden dann den Gruppen (Organizational
Roles) und nicht einzelnen Benutzer-Objekten zugeordnet. Die Benutzer-
Objekte erben die Rechte und Berechtigungen der Gruppen (Organizational
Roles), denen sie angehren. So ist es z. B. denkbar, alle Mitarbeiter einer
Abteilung in einer Gruppe (Organizational Role) zusammenzufassen. Benut-
zerberechtigungen sollten nur dann einzelnen Benutzern zugewiesen werden,
wenn dies ausnahmsweise unumgnglich ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Hierbei ist festzulegen, welche vom eDirectory generierten Ereignisse zu
protokollieren sind und bei welcher Ereigniskombination eine Benachrichti-
gung an den Sicherheits- bzw. Systemadministrator zu erfolgen hat. Weiterhin
muss entschieden werden, wie lange die gesammelten Ereignisdaten aufzu-
bewahren sind.
Strukturierte Datenhaltung). Bei eDirectory werden Benutzerdaten nur auf
eDirectory-Servern abgelegt. Eine Datenspeicherung auf den lokalen Fest-
platten der einzelnen Clients findet nicht statt. Die Frage nach der Datenspei-
cherung ist jedoch auf der Ebene einzelner Partitionen zu klren. Daten-
bestnde sollten in Bezug auf ihren Schutzbedarf klassifiziert werden, und
entsprechend sollte die Partitionierung des Verzeichnisses auf vertrauenswr-
dige und gesicherte Hosts vorgenommen werden. Dabei sind besonders die
hochsensiblen Daten des Security-Containers zu bercksichtigen.
Um eine saubere Trennung von benutzer- und projektspezifischen Daten
(Objekten) untereinander durchzusetzen, sollte eine geeignete Verzeichnis-
struktur festgelegt werden, die eine solche Objekthaltung untersttzt.
Fr die Objekte des Verzeichnisdienstes ist festzulegen, welche Attribute fr
den Betrieb freizugeben und welche Zugriffsrechte ihnen zuzuweisen sind.
10. Verantwortlichkeiten der Administratoren und Benutzer im Client-
Server Netz
welche Verantwortung die einzelnen Administratoren im eDirectory-
Verzeichnissystem bernehmen mssen. Dies knnen zum Beispiel Verant-
wortlichkeiten sein fr
- die Verwaltung des eDirectory-Baums oder einzelner Partitionen,
- die Verwaltung der Schemadefinition,
- die Verwaltung der CA und der Key Management Objekte (KMO),
Clients,
- das Hinterlegen und den Wechsel von Passwrtern und die Durchfhrung
von Datensicherungen.
Auch die Benutzer mssen in einem eDirectory-Verzeichnisdienst mit Client-
Zugriff bestimmte Verantwortlichkeiten bernehmen, insbesondere wenn
ihnen Rechte zur Ausfhrung administrativer Funktionen gegeben werden. In
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
der Regel beschrnkt sich dies jedoch auf die Vergabe der eigenen Passwrter
fr das Login.
11. Schulung
Abschlieend muss festgelegt werden, welche Benutzer zu welchen Teil-
aspekten geschult werden mssen. Erst nach ausreichender Schulung kann der
Produktivbetrieb aufgenommen werden. Besonders die Administratoren sind
hinsichtlich der Verwaltung und der Sicherheit von eDirectory grndlich zu
schulen.
Die so entwickelten Sicherheitsrichtlinien sind zu dokumentieren und im
erforderlichen Umfang den Benutzern des eDirectory-Verzeichnisdienstes
mitzuteilen. Bei der Definition der Sicherheitsrichtlinie fr eDirectory ist zu
beachten, dass sie sich an den bisher geltenden Sicherheitsrichtlinien der
Behrde bzw. des Unternehmens orientieren muss, diesen nicht widersprechen
(Konsistenz) und auch nicht im Widerspruch zu geltendem Recht stehen darf.
In der Regel wird eine eDirectory-Sicherheitsrichtlinie existierende Regelun-
gen spezifisch anpassen oder aber sinngem erweitern, z. B. durch zustz-
liche Anforderungen fr Komponenten. Dabei sind unter Umstnden neue
Regelungen fr eDirectory-spezifische Funktionalitten, z. B. iMonitor, zu
treffen. Generell gilt, dass sich die Planung des eDirectory-Verzeichnis-
dienstes an den jeweiligen Sicherheitsrichtlinien orientiert, dabei jedoch auch
Einfluss auf die Sicherheitsrichtlinien besitzt (Feedback-Prozess).
- Sind alle fr den geplanten Einsatz von eDirectory relevanten Bereiche
durch die Sicherheitsrichtlinien abgedeckt?
- Wurden zeitliche Abhngigkeiten fr die Umsetzung der Sicherheitsricht-
linien bercksichtigt?
- Sind alle Benutzer ber die eDirectory-Sicherheitsrichtlinien informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Intranet
eDirectory ist als Management-Produkt fr IT-Ressourcen einer Organisation
geeignet. Dazu wird die Organisationshierarchie auf einen eDirectory-Baum
abgebildet und der Zugriff auf die im Verzeichnis gehaltenen Objekte entspre-
chend vergeben. Dabei knnen Automatismen, wie die Vererbung von
Zugriffsberechtigungen auf Teilbume und das Einrichten von Benutzer-
gruppen (Organizational Roles), die Administration des Verzeichnissystems
erleichtern.
eDirectory kann auf verschiedenen Serverplattformen betrieben werden:
Netware, Windows NT/2000, Linux sowie Sun Solaris.
Neben dem prinzipiell fr alle Applikationen mglichen LDAP-Zugang zum
eDirectory bietet Novell spezielle Client-Software an, die fr bestimmte
Systeme das Ressourcen- und Benutzermanagement im eDirectory erlaubt.
Dabei handelt es sich um
- den Novell Client fr Windows (derzeit - Februar 2002 - in der Version
4.83 fr Windows NT/2000/XP und Version 3.31 fr Windows 95/98/ME),
- die Novell User Account Management Software fr Solaris sowie Linux auf
Intel-Plattform.
Dabei kann eDirectory auch zur Authentisierung von Netware-Servern und zur
Zugriffskontrolle auf dort gehaltene Volumes genutzt werden.
Folgende Aspekte sind bei der Einrichtung eines eDirectory-Verzeichnis-
dienstes im Intranet zu planen:
- der Verzeichnisbaum und Abbildung der IT-Ressourcen darin,
- die einzusetzenden Objektklassen sowie deren Attributstze,
- gegebenenfalls Planung einer Schemanderung,
- die Einrichtung von Benutzern und Benutzergruppen (siehe M 2.30
Regelung fr die Einrichtung von Benutzern/Benutzergruppen),
- die Anbindung von Benutzern an das eDirectory (siehe M 4.157 Einrichten
von Zugriffsberechtigungen auf Novell eDirectory),
- die Zugriffsrechte von Benutzern auf das eDirectory (siehe M 4.157
Einrichten von Zugriffsberechtigungen auf Novell eDirectory),
- das Administrationskonzept fr das eDirectory (siehe M 3.29 Schulung zur
Administration von Novell eDirectory),
- die Partitionierung und die Replizierung (siehe M 2.237 Planung der
Partitionierung und Replikation im Novell eDirectory),
- der Zertifikatsdienst (siehe M 4.155 Sichere Konfiguration von Novell
eDirectory),
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- die Client-Anbindung an das eDirectory (siehe M 4.156 Sichere

Konfiguration der Novell eDirectory Clientsoftware),
- der LDAP-Zugriff auf das eDirectory durch Netzapplikationen (siehe
M 4.158 Einrichten des LDAP-Zugriffs auf Novell eDirectory),
- die Verschlsselung des Netzverkehrs,
- die Datensynchronisation mit fremden Verzeichnisdiensten mittels
DirXML,
- der Einsatzes des Service Location Protocols (SLP),
- Audits (siehe M 4.160 berwachen von Novell eDirectory),
- ein automatisiertes und protokolliertes periodisches Backup (siehe auch
M 6.81 Erstellen von Datensicherungen fr Novell eDirectory),
- die Notfallvorsorge fr den Systemausfall (siehe auch M 6.80 Erstellen
eines Notfallplans fr den Ausfall eines Novell eDirectory Verzeichnis-
dienstes).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Extranet
eDirectory lsst sich auch als E-Business-Plattform im Internet betreiben. In
diesem Zusammenhang fungiert das eDirectory oft als LDAP-Server, der
Daten fr seine Benutzer in seinem Verzeichnisdienst bereithlt. Die Benut-
zeranbindung erfolgt dabei ber das LDAP-Protokoll, welches auf TCP/IP
aufsetzt.
Prinzipiell knnen sich Benutzer auf drei verschiedene Arten via LDAP mit
eDirectory verbinden:
- als [Public] Objekt (Anonymous Bind),
- als Proxy User (Proxy User Anonymous Bind),
- als NDS User (NDS User Bind).
Hier ist bei der Planung speziell zu bercksichtigen, ob ein Anonymous Bind
zugelassen wird oder nicht. Standardmig hat das [Public] Objekt uneinge-
schrnktes Browse-Recht auf den eDirectory-Baum.
Die Planung sollte eine Aufteilung der Verzeichnisdaten in drei Kategorien Strukturierung der
Verzeichnisdaten
vorsehen:
- Daten, auf die ber anonymen Login zugegriffen werden kann,
- Daten, auf die nach erfolgreicher Authentisierung zugegriffen werden darf,
sowie
- Daten, auf die von auen prinzipiell nicht zugegriffen werden darf.
Die Verzeichnisdaten sollten entsprechend dieser Aufteilung in getrennten getrennte Speicherung
Bereichen gespeichert werden. Dies erleichtert unter anderem die Durch-
fhrung von Datensicherungen und die Sicherstellung des korrekten Zugriffs-
schutzes. Ein eDirectory-Server mit direkter Internet-Anbindung sollte
mglichst keine Daten halten, auf die von auen nicht zugegriffen werden
braucht.
Weiterhin ist bei Bedarf der Einsatz von SSL fr den LDAP-Zugriff auf das
eDirectory zu planen. Es ist dann zu entscheiden, ob die Authentisierung ber
Passwrter oder Zertifikate erfolgen soll. Wird SSL nicht eingesetzt, so muss
entschieden werden, ob Passwrter im Klartext bertragen werden knnen
oder ob die Option allowing cleartext passwords ausgeschaltet wird.
Da der eDirectory-Server in diesem Einsatzszenario ber eine direkte Internet- eDirectory-Server durch
Firewall absichern
Anbindung verfgt, ist der Einsatz einer Firewall zu planen. Eine geeignete
Vorgehensweise hierzu findet sich in Baustein 7.3 Firewall.
- Welche Daten sollen von auen anonym erreichbar sein?
- Welche Daten sollen nach erfolgter Authentisierung erreichbar sein?
- Ist der Einsatz von SSL erforderlich, um die Vertraulichkeit bzw. Integritt
der bertragenen Daten sicherzustellen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.241 Durchfhrung einer Anforderungsanalyse fr

den Telearbeitsplatz
Bevor ein Telearbeitsplatz eingerichtet wird, ist es sinnvoll, eine Anforde-
rungsanalyse durchzufhren. Sinn dieser Anforderungsanalyse ist es, alle in
Frage kommenden Einsatzszenarien zu bestimmen, um daraus die bentigten
Hard- und Software-Komponenten fr die Anbindung des huslichen Arbeits-
platzes abzuleiten. Hierdurch knnen spezielle Anforderungen identifiziert
werden, die den Einsatz bestimmter Systeme und/oder Software erforderlich
machen (siehe hierzu z. B. Kapitel 7.6 Remote Access oder Kapitel 8.4 LAN-
Anbindung eines IT-Systems ber ISDN).
Die Ergebnisse einer solchen Anforderungsanalyse mssen dokumentiert und Dokumentation und
Abstimmung
mit den IT-Verantwortlichen abgestimmt werden.
Im Rahmen dieser Anforderungsanalyse sind u. a. folgende Fragen zu klren:
- Bis zu welchem Vertraulichkeitsanspruch drfen Daten im Rahmen der
Telearbeit am Telearbeitsplatz, also auerhalb der "schtzenden Mauern"
der Behrde bzw. des Unternehmens, bearbeitet werden?
- Zu welchem Zweck wird der Zugang zur Institution genutzt (Abfragen von
Informationen, Einstellen von Informationen, Programmnutzung)?
- Wie hoch ist der Datenverkehr zwischen dem huslichen Arbeitsplatz und
der Institution?
- Bentigt der Telearbeiter Zugriff auf das Intranet der Institution? Wenn ja,
muss der Zugriff auf das gesamte Intranet, d. h. auf alle dort verfgbaren
Daten und Dienste erfolgen oder nur auf Teilbereiche des Intranets?
- Ist fr die Telearbeiter die Nutzung des Internets vorgesehen? Wenn ja,
bekommt der Telearbeiter einen eigenen Internet-Zugang oder wird dieser
Zugang ber das Intranet der Institution realisiert?
Je nach dem Vertraulichkeitsanspruch der Daten kann es erforderlich sein, bertragungswege
festlegen
bestimmte bertragungswege von der Organisation zum Telearbeitsplatz fest-
zulegen. Dabei kann es sinnvoll sein, bestimmte bertragungswege auszu-
schlieen oder Mindestanforderungen dafr festzulegen. Beispielsweise
knnte es vorgeschrieben sein, Papierdokumente mit vertraulichen Infor-
mationen nur auf direktem Weg von der Organisation zum Telearbeitsplatz in
verschlossenen Transportbehltern zu transportieren. Ebenso knnten fr
verschiedene Vertraulichkeitsgrade unterschiedliche Verschlsselungsver-
fahren fr die Datenbertragung vorgesehen sein.
hnliche berlegungen sollten angestellt werden, wenn die im Rahmen der
Telearbeit zu verarbeitenden Informationen besonders vor Manipulation
geschtzt werden mssen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wurde eine Anforderungsanalyse fr den Telearbeitsplatz durchgefhrt?
- Wurden die Anforderungen an den Telearbeitsplatz mit den IT-Verantwort-
lichen (Administratoren und anderem technischem Personal) abgestimmt?
- Ist der Schutzbedarf der Informationen, die im Rahmen der Telearbeit
verarbeitet werden, festgestellt und dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.242 Zielsetzung der elektronischen Archivierung

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Behrden-
/Unternehmensleitung
Um eine elektronische Archivierung in einer Institution einzufhren, sind die
Ziele festzulegen, die damit erreicht werden sollen. Dabei muss das Manage-
ment der betreffenden Organisation einbezogen werden. Gegebenenfalls ist
eine Koordinierung mit bergeordneten Organisationseinheiten notwendig.
Insbesondere ist festzulegen,
- in welchen Bereichen welche Daten archiviert werden sollen,
- welches Sicherheitsniveau es zu erreichen gilt,
- welcher Funktions- und Leistungsumfang angestrebt ist und
- wer die Verantwortung hierfr trgt.
Die Ergebnisse sind im Archivierungskonzept (siehe Manahme M 2.243 Ziele im Archivierungs-
konzept dokumentieren
Entwicklung des Archivierungskonzepts) zu fixieren.
Welche Daten sind zu archivieren?
Die Bestimmung der zu archivierenden Daten dient der Eingrenzung der tech-
nischen Anforderungen an das auszuwhlende Archivsystem. Die Eingren-
zung sollte aber so allgemein erfolgen, dass ausreichend Spielraum fr die
technische Ausgestaltung bleibt, wobei zu beachten ist, dass sich Anforderun-
gen auch im Laufe der Zeit ndern knnen. Besonders auf Managementebene
sind allgemeine Charakterisierungen sinnvoll wie:
- alle Daten/Dokumente der Abteilung ...
- alle Daten/Dokumente der Geschftsprozesse ...
- alle Geschftsdaten
- alle Buchhaltungsdaten
- alle Kundendaten
- alle Daten der Klassifikationsstufe ...
Wenn Daten mit unterschiedlichem Schutzbedarf archiviert werden sollen, Schutzbedarf berck-
sichtigen
wird empfohlen, die Ziele und Anforderungen an die Archivierung anhand der
jeweiligen Schutzbedarfskategorie zu definieren. Ein Beispiel hierfr ist die
Archivierung von Dokumenten, die als offen, intern, geheim o. . klassifiziert
worden sind.
Welches Sicherheitsniveau soll erreicht werden?
Das zu erreichende Sicherheitsniveau bei der Archivierung lsst sich auf
Managementebene typischerweise wie folgt charakterisieren:
- Erfllung gesetzlicher sowie organisationsinterner Anforderungen an den
Schutz der Daten bei der Archivierung sowie darber hinaus (z. B. nach
Entsorgung der Datentrger),
- Widerstandsfhigkeit des Archivierungsprozesses gegen Manipulation,
- Widerstandsfhigkeit des verwendeten Archivsystems gegen interne und
externe Angriffe auf die gespeicherten Daten sowie das IT-System selbst.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wenn Daten und Dokumente klassifiziert werden, kann das Sicherheitsniveau

auch anhand dieser Klassifikation detaillierter differenziert werden.
Welcher Funktions- und Leistungsumfang soll erreicht werden?
Der angestrebte Funktions- und Leistungsumfang elektronischer Archivierung
kann je nach Organisation unterschiedlich ausfallen. blicherweise werden
auf Managementebene die folgenden Anforderungen definiert:
- Integrationsfhigkeit in die bestehende IT-Systemlandschaft, Integrationsfhigkeit
- Integrationsfhigkeit in bestehende IT- und Dokumentenmanagement-Pro-

zesse,
- Einhaltung (gesetzlich sowie intern) vorgeschriebener Speicher- und
Lschfristen fr Daten,
- Aussonderungsmodalitten und Beachtung der Anbietungspflicht
Dies betrifft vor allem die ffentliche Verwaltung, da ffentliche Stellen unter
Umstnden dazu verpflichtet sind, Daten, die von besonderer Bedeutung sind,
z. B. gesellschaftlicher, politischer oder historischer Art, einem dafr zustn-
digen Archiv nach Ablauf der Aufbewahrungsfrist anzubieten. Erst wenn
dieses entscheidet, dass die entsprechenden Daten nicht archivwrdig sind,
drfen diese endgltig gelscht werden. ber die Archivwrdigkeit von Daten
kann in vielen Fllen erst nach Ablauf der Aufbewahrungsfrist entschieden
werden, so dass die Daten am Ende der Aufbewahrungsfrist nicht immer
automatisch bearbeitet werden knnen.
- Einhaltung des angestrebten Sicherheitsniveaus der Daten sowie
- Migrationsfhigkeit des Archivsystems, wenn sich Anforderungen und Migrationsfhigkeit
Einflussfaktoren ndern.
Wer trgt die Verantwortung?
Mit dem Aufbau bzw. dem Betrieb der elektronischen Archivierung mssen
Verantwortliche benannt werden. blicherweise wird von Seiten des Mana-
gements eine Fachabteilung bzw. deren Leiter mit der Umsetzung der Archi-
vierung beauftragt. Hiermit mssen auch Zielvorgaben, Befugnisse, personelle
und finanzielle Ressourcen verknpft werden. Die Delegation der Umsetzung
ist entsprechend den organisationsinternen Richtlinien durchzufhren und im
Archivierungskonzept zu fixieren.
- Sind smtliche zu archivierende Daten im Archivierungskonzept aufge-
fhrt?
- Ist das angestrebte Sicherheitsniveau der zu archivierenden Daten festge-
legt?
- Ist der angestrebte Funktions- und Leistungsumfang der elektronischen
Archivierung festgelegt?
- Sind die Verantwortlichkeiten fr die Archivierung festgelegt und doku-
mentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.243 Entwicklung des Archivierungskonzepts

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Archivverwalter
Der Aufbau eines Archivsystems sollte sorgfltig konzipiert werden. Dabei
sind einerseits zahlreiche Einflussfaktoren (z. B. organisationsinterne oder
rechtliche Vorgaben, technische und organisatorische Umgebungsbedingun-
gen) zu beachten, andererseits bestehen vielfltige technische Mglichkeiten,
um ein elektronisches Archiv aufzubauen. Daher sollte zunchst ein Konzept
entwickelt werden, in dem alle Einflussgren und Entscheidungskriterien fr
die Wahl eines konkreten Archivierungssystems und der entsprechenden Pro-
dukte bercksichtigt werden und das gleichzeitig unter Kostengesichtspunkten
wirtschaftlich vertretbar ist.
Grundlage fr das Archivierungskonzept ist die in M 2.242 Zielsetzung der
elektronischen Archivierung festgelegte Zielsetzung.
Im Archivierungskonzept ist der technische bzw. organisatorische Einsatz des
Archivsystems festzulegen, also z. B.
- die Zustndigkeiten und Verantwortlichkeiten,
- die Definition von Benutzerrollen (z. B. Archivverwalter, Administratoren,
Benutzer, technische Benutzer),
- Definition von Zugriffsrechten und Modalitten zur Rechtevergabe,
- Abgrenzung der zu archivierenden Daten,
- Schutz der archivierten Daten, z. B. durch Verschlsseln und Signieren,
- die angestrebte Systemanbindung bzw. die Einsatzbedingungen fr Archi-
vierungskomponenten,
- die technische Ausgestaltung des Archivsystems,
- der Betrieb des Archivsystems (z. B. Beschreibung von Service Level
Agreements).
Die Ergebnisse sollten aktualisierbar und erweiterbar schriftlich dokumentiert Konzept schriftlich do-
kumentieren
werden. Das Archivierungskonzept selbst sollte in allen umgesetzten Fassun-
gen aufbewahrt werden. Die Mitarbeiter sind ber den sie betreffenden Teil
des Konzepts zu unterrichten. Die Unterrichtung sollte nachprfbar doku-
mentiert werden. Ein mglicher Aufbau eines Archivierungskonzepts ist im
nachfolgenden Inhaltsverzeichnis beispielhaft aufgezeigt:
Inhaltsverzeichnis Archivierungskonzept
1. Dokumentkontext
- Regelungsgegenstand
- Regelmige Anpassung
- Anordnung der Umsetzung
2. Definitionen
- Archivierung, Dokumentenbegriff
- Langzeitarchivierung, Archivierung zu Revisionszwecken
- Beschreibung der Einsatzart und des Archivsystems
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Gefhrdungslage zur Motivation

- Abhngigkeit der Institution vom Datenbestand
- Typische Gefhrdungen wie Datenverlust, Rekonstruktionsfehler, ...
- Institutionsrelevante Schadensursachen
- Beispiele zu Schadensfllen im eigenen Haus
4. Festlegung einer organisationsinternen Sicherheitsleitlinie
- Festlegung von Verantwortlichkeiten
- Zielsetzung, Sicherheitsniveau
5. Beschreibung der Einflussfaktoren
- Identifikation der zu archivierenden Daten
- Vertraulichkeitsbedarf der Daten
- Integrittsbedarf der Daten
- Authentizittsbedarf der Daten
- Verfgbarkeitsanforderungen an die Daten
- Rechtliche Rahmenbedingungen
- Archivierungsfristen (minimale, bei Bedarf auch maximale
Speicherdauer)
- Anforderungen an die Performance beim Einlesen bzw. Auslesen von
Daten, Rekonstruktionsaufwand
- Datenvolumen sowie nderungsvolumen
- Art der Daten (Formate)
- Art der Zugriffe auf die archivierten Daten (lokal oder verteilt im LAN
bzw. WAN)
- Zu beachtende Normen und Standards
- Erforderliche Funktionalitt
- Personalaufwand
- Kosten inklusive Folgekosten (Wartung, Administration, Updates, etc.)
- Kenntnisse und IT-spezifische Qualifikationen der Benutzer
6. Festlegung des Einsatzes
- Art des Archivsystems
- Einsatzbedingungen an das Archivsystem
- Zeitraum des Einsatzes
- Benennung der Verantwortlichen
- Festlegung von Service Level Agreements
- Durchfhrung der personellen Manahmen (Schulung,
Vertretungsregelungen, Verpflichtungen, Rollenzuteilung)
- Dokumentation der Einsatzbedingungen und der Konfiguration
- Interoperabilitt, Standardkonformitt, Investitionsschutz
- Regelmige Datensicherung
- Virenschutz
- Einsatz kryptographischer Verfahren
7. Randbedingungen fr die Archivierung
- Vertragsgestaltung
- Refresh-Zyklen fr die Speichermedien
- Bestandsverzeichnis
- Lschen von Daten
- Vernichtung von unbrauchbaren Datentrgern
- Vorhalten von arbeitsfhigen Lesegerten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
8. Sporadische Restaurierungsbungen
Einzelne Punkte dieses Konzepts werden in den Manahmen
- M 2.242 Zielsetzung der elektronischen Archivierung,
- M 2.244 Ermittlung der technischen Einflussfaktoren fr die elekronische
Archivierung,
- M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr die elektronische
Archivierung,
- M 2.246 Ermittlung der organisatorischen Einflussfaktoren fr die
elektronische Archivierung,
nher adressiert.
Bei der elektronischen Archivierung handelt es sich nicht um eine einmalige Archivierungskonzept
regelmig anpassen
Aufgabe, sondern um einen dynamischen Prozess. Ein Archivierungskonzept
muss daher regelmig den aktuellen Gegebenheiten angepasst werden.
- Ist das Archivierungskonzept verbindlich festgelegt?
- Ist das vorliegende Archivierungskonzept aktuell?
- Sind die Mitarbeiter ber den sie betreffenden Teil des Konzepts nach-
weislich unterrichtet worden?
- Wird die Aktualitt des Konzepts regelmig berprft?
- Werden nderungen der Einflussfaktoren zeitnah bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.244 Ermittlung der technischen Einflussfaktoren fr

die elektronische Archivierung
Bevor eine Entscheidung getroffen werden kann, welche Verfahren und Pro-
dukte fr die elektronische Archivierung eingesetzt werden sollen, mssen
eine Reihe von technischen Einflussfaktoren ermittelt werden. Dazu sollten
auch die Eigentmer der zu archivierenden Daten befragt werden, also bei-
spielsweise die Verantwortlichen der einzelnen IT-Systeme bzw. IT-Anwen-
dungen und die Systemadministratoren. Die Ergebnisse sind nachvollziehbar
im Archivierungskonzept (siehe M 2.243 Entwicklung des Archivierungs-
konzepts) zu dokumentieren. Die fr die elektronische Archivierung mageb-
lichen technischen Einflussfaktoren sind unter anderem
- das zu erwartende Datenaufkommen,
- die Dateiformate der zu archivierenden Dokumente,
- das nderungsvolumen und Versionierung,
- die Aufbewahrungsdauer der Dokumente,
- die Zahl und Art der Zugriffe,
- die vorhandene IT-Einsatzumgebung sowie
- zu beachtende Normen und Standards.
Die angegebenen Einflussfaktoren sind nachfolgend detaillierter dargestellt:
Zu erwartendes Datenaufkommen
Ein wesentliches Kriterium fr die Auswahl elektronischer Archivsysteme ist Datenaufkommen ab-
schtzen
die Gre der zu archivierenden Dateien und das in Zukunft zu erwartende
Datenaufkommen. Dies kann typischerweise nur grozgig abgeschtzt
werden.
Die Dateigre von Dokumenten hngt dabei auch sehr stark von der Wahl
des Dateiformates und dem Umfang der Rendition (siehe weiter unten) ab.
Dateiformate der zu speichernden Dokumente
Je nach Wahl des Archivsystems knnen in diesem grundstzlich alle ver-
wendeten Dateiformate abgelegt werden, z. B. die in Broumgebungen bli-
chen Formate (DOC, PDF, RTF, ASCII, ZIP, etc.) oder auch Bild- und Ton-
dateien (JPG, GIF, WAV, MPEG, etc). Besondere Bedeutung erhalten bei der
Archivierung jedoch Dateiformate, die eine langfristige Stabilitt hinsichtlich
der Syntax und Semantik der Daten bieten (wie z. B. SGML, XML oder auch
HTML) oder Bilddateien, die ein exaktes Abbild des ehemals vorhandenen
Papierdokuments darstellen knnen (z. B. TIFF). Die einzelnen Datenformate
sind in Manahme M 4.170 Auswahl geeigneter Datenformate fr die Archi-
vierung von Dokumenten detailliert beschrieben.
Bei der elektronischen Archivierung haben sich in der Vergangenheit mehrere Dokumente in mehreren
Formaten archivieren
Dateiformate etabliert, die eine unterschiedliche Eignung fr knftige Ver-
wendungszwecke der Daten aufweisen. Hufig kann oder soll jedoch der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sptere Verwendungszweck nicht festgelegt werden. In so einem Fall ist aber

nicht vorhersagbar, welches das beste Datenformat fr die sptere Verwen-
dung ist. Ebenso hufig bestehen bereits zum Zeitpunkt der Datenspeicherung
konkurrierende Anforderungen an die Wahl des Dateiformates, die sich aus
den unterschiedlichen Verwendungszwecken ergeben. Deshalb hat es sich, vor
allem bei der Langzeitarchivierung, als vorteilhaft erwiesen, Dokumente in
mehreren Dateiformaten gleichzeitig zu archivieren. Die Dokumente mssen
dazu vorher konvertiert werden. Dieser Vorgang wird als Rendition be-
zeichnet. Bei der Rendition ist jedoch auf eine genaue Dokumentation der
Verfahrensweise zu achten. Informationen ber das Originalformat mssen
mit archiviert werden.
Die Rendition von Dokumenten und anschlieende Speicherung in mehreren
Dateiformaten wirkt sich unmittelbar auf die fr die Archivierung notwendige
Speicherkapazitt aus.
nderungsvolumen und Versionstiefe
Bei der Archivierung von Dokumenten ist zu berlegen, welche nderungen
an den Dokumenten im Lauf der Zeit auftreten werden, wie hufig dies zu
erwarten ist und wie damit zu verfahren ist. Wenn archivierte Dokumente
gendert werden sollen, bestehen folgende Mglichkeiten:
- Das ursprngliche Dokument wird durch die genderte Version ersetzt.
- Die neue Version des Dokuments wird zustzlich zur ursprnglichen Ver- Versionierung
sion archiviert (Versionierung), wobei unter Umstnden nur eine maximale
Anzahl von Versionen desselben Dokuments archiviert bleibt (Versions-
tiefe).
Durch organisationsinterne oder rechtliche Anforderungen kann eine Versio-
nierung der Dokumente gefordert werden. Hier wird insbesondere auf die
Manahmen M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr die
elektronische Archivierung und M 2.246 Ermittlung der organisatorischen
Einflussfaktoren fr die elektronische Archivierung verwiesen.
Eine Versionierung kann auch durch die Wahl des Speichermediums (z. B.
WORM - Write Once Read Multiple) erzwungen werden.
Sofern eine Versionierung von Dokumenten vorgenommen wird, muss dies
bei der Berechnung der notwendigen Speicherkapazitt des Archivsystems
Aufbewahrungsdauer der Dokumente
Fr die Kalkulation der notwendigen Speicherkapazitt des Archivsystems ist
eine Abschtzung der Aufbewahrungsdauer der archivierten Dokumente un-
erlsslich. Fr die Aufbewahrungsdauer ergeben sich aufgrund rechtlicher
oder organisationsinterner Vorgaben minimale, jedoch teilweise auch maxi-
male Speicherfristen, die zu beachten sind.
Die Aufbewahrungsdauer hat jedoch nicht nur Einfluss auf die Speicherkapa-
zitt des Archivsystems, sondern auch auf die Auswahl des Speichermediums
sowie dessen Entsorgung nach Ablauf der Aufbewahrungsdauer.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Zahl und Art der Zugriffe

Zugriffszahlen sowie die Art der Zugriffe auf das Archivsystem haben Aus-
wirkungen auf die Konfiguration des Archivservers und die Auswahl der
Speicherkomponenten.
Als Einflussfaktoren sind daher zu ermitteln:
- Wie viele Zugriffe werden innerhalb eines vorgegebenen Zeitraums auf das
Archivsystem erfolgen?
- Wie hoch ist der Anteil von Schreibzugriffen gegenber Lesezugriffen?
- Welche Antwortzeiten werden verlangt?
- Erfolgen die Zugriffe direkt von Benutzer- bzw. Clientsystemen auf das
Archivsystem oder durch ein bergeordnetes Dokumentenmanagementsy-
stem?
- Muss das Archivsystem zwischen Zugriffen verschiedener Benutzer unter-
scheiden oder erfolgt dies durch bergeordnete Komponenten?
- Muss das Archivsystem mehrere, voneinander getrennte Archive verwalten Mandantenfhigkeit
(Mandantenfhigkeit)?
IT-Einsatzumgebung
Archivsysteme sind typischerweise in komplexere IT-Landschaften einge-
bettet. Hierdurch ergeben sich technische Anforderungen, z. B. hinsichtlich
- der Netzanbindung,
- der verwendbaren Netzprotokolle (deren Definition z. B. bekannt sein
muss, wenn die Kommunikationsverbindung ber Firewalls gefhrt wird),
- Kompatibilitt zu anderen Programmen oder IT-Systemen,
- der Einbindung in Systemmanagement-Umgebungen sowohl zur Administ-
ration als auch zur berwachung des Archivsystems,
- der Administrations- und Nutzungsschnittstellen sowie
- der Antwortzeiten des Archivsystems.
Zu beachtende Normen und Standards
Die im Bereich der Archivierung bestehenden Standards konzentrieren sich
auf die Bereiche
- Dateiformate und Kompressionsverfahren,
- Speichermedien und deren Aufzeichnungsverfahren sowie
- Dokumentenmanagement-Software.
Systemhersteller erhalten durch die Offenlegung von Schnittstellen, die im Planungs- und Investiti-
onssicherheit
Rahmen der Standardisierung erfolgt, die Mglichkeit, eine Kompatibilitt
von Systemkomponenten, Schnittstellen und Datenformaten herzustellen.
Deshalb kann durch die Bercksichtigung von Standards bei der Auswahl von
Archivsystemen eine lngerfristige Planungs- und Investitionssicherheit ge-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
whrleistet werden. Bei den in diesem Baustein empfohlenen Manahmen

wird auf die derzeit gltigen Standards Bezug genommen.
Fr den Anwender bedeutet die Orientierung an Standards eine Verringerung
der Abhngigkeit von einzelnen Herstellern, Systemlieferanten und Dienstlei-
stern. Bei den langen Zeitrumen, ber die Archivsysteme typischerweise
eingesetzt werden, ist dies besonders wichtig, da nicht absehbar ist, wie sich
Produktlinien langfristig entwickeln. So knnte sich z. B. bei Insolvenz eines
Herstellers proprietrer Speicherkomponenten das Problem ergeben, dass das
Archivierungssystem nicht mehr in der bisherigen Art durch Zukauf neuer
Speichermedien und -komponenten erweitert werden kann. In Behrden und
Unternehmen mit hohem Archivierungsbedarf fhrt dies typischerweise kurz-
fristig den Eintritt in die Migrationsphase herbei. Bei Einsatz standardisierter
Komponenten kann dagegen einfach ein anderer Lieferant fr die betroffene
Teilkomponente gewhlt werden.
Hinsichtlich Standards ist allerdings zu beachten, dass auch diese mit der Zeit
aufgrund neuer technologischer Entwicklungen an Relevanz verlieren und bei
Bedarf durch neue Standards ersetzt werden. Diese unterscheiden sich gele-
gentlich inhaltlich grundlegend, uerlich aber nur in der Versionsnummer.
Zudem besteht auch ein Wettbewerb zwischen unterschiedlichen Standardi-
sierungsgremien und Herstellern, die naturgem auf der Suche nach wirt-
schaftlichem Einfluss am Markt sind, wodurch es auch konkurrierende Stan-
dards gibt.
Prinzipiell ist die Archivierung jedoch auch ohne Beachtung von Standards Wartung und Systembe-
treuung sicherstellen
unter Nutzung proprietrer Datei- und Speicherformate mglich, sofern ber
den Archivierungszeitraum eine ausreichende Wartung und Systembetreuung
durch Hersteller und eine Anpassung der Schnittstellen an sich verndernde
Anforderungen sichergestellt wird. Es wird jedoch aus obigen Grnden emp-
fohlen, sich bei der Planung von Archivsystemen eng an geltenden Standards
fr Dateiformate und Schnittstellen zu orientieren.
Bereits bei der Planung eines Archivsystems sollte eine sptere Migration
bercksichtigt werden, da sich bei der langfristigen Speicherung von Daten
typischerweise zwischendurch die Technik oder die Anforderungen ndern.
Besondere Sorgfalt sollte daher auf die Planung und Auswahl von Schnitt-
stellen, Dateiformaten und Index-Datenbank verwendet und alle Entscheidun-
gen nachvollziehbar dokumentiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr

die elektronische Archivierung
Fr die Aufbewahrung bestimmter Informationen bestehen verschiedene
rechtliche Vorgaben, deren Nichteinhaltung zivil- oder strafrechtliche Konse-
quenzen haben kann. Daher sollten sich die Verantwortlichen informieren,
welche rechtlichen Vorgaben in ihrem Fall anzuwenden sind. Hieraus ergeben
sich Anforderungen fr die Gestaltung des Archivierungskonzepts, die bei der
Planung elektronischer Archivierung bercksichtigt werden mssen. Dies
betrifft unter anderem
- die Mindestaufbewahrung aus steuerlichen, haushaltsrechtlichen oder
sonstigen Grnden,
- Hchstaufbewahrungsdauer aus Datenschutzgrnden,
- Zugriffsrechte fr Externe, wie z. B. Steuerbehrden, sowie
- Qualitt von digitalen Signaturen.
Die anzuwendenden rechlichen Grundlagen sind im Einzelfall zu klren.
Im Folgenden werden einige Quellen genannte, die in Deutschland typischer-
weise zu bercksichtigen sind:
- Brgerliches Gesetzbuch (BGB)
Hier werden insbesondere Anforderungen an die Rechtsgltigkeit von
Dokumenten im Zivilrecht gestellt. Das BGB definiert auch
Verjhrungsfristen, z. B. fr Schadenersatz aus unerlaubter Handlung.
- Zivilprozessordnung (ZPO)
Analog zum BGB wird durch die ZPO geregelt, welche Dokumente als Ur-
kunde anerkannt werden mssen, beispielsweise aufgrund einer eigenhn-
digen Unterschrift oder einer qualifizierten digitalen Signatur.
- Handelsgesetzbuch (HGB)
Hier werden Anforderungen an die Ordnungsmigkeit und Revisions-
fhigkeit der Geschftsttigkeit gestellt. Dies umfasst auch bestimmte
Aufbewahrungsfristen fr Geschftsdokumente.
- Grundstze ordnungsmiger Datenverarbeitung (GoDV)
Die GoDV sind selbst keine gesetzliche Vorschrift, sondern hergeleitet aus
den im HGB definierten Grundstzen ordnungsmiger Buchfhrung. Sie
sind als de facto-Standard fr die DV-Revision in Unternehmen zu
verstehen.
- Grundstze zum Datenzugriff und zur Prfbarkeit digitaler Unterlagen
(GDPdU)
Das Bundesministerium der Finanzen hat die in den GoDV vorgesehenen
Revisionsanforderungen im Rahmen der GDPdU przisiert. Dies betrifft
hauptschlich alle steuerlich relevanten digital vorliegenden Dokumente.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hierbei wird u. a. gefordert, dass alle zur Auswertung der Daten notwen-
digen Informationen wie Dateistruktur, Datenfelder, interne und externe
Verknpfungen in maschinell auswertbarer Form zur Verfgung stehen
mssen.
- Gesetze und Vorschriften zum Schutz personenbezogener Daten
Sofern personenbezogene Daten archiviert werden, mssen die hierfr
geltenden Gesetze und Vorschriften eingehalten werden. Dazu gehren vor
allem das Bundesdatenschutzgesetz (BDSG) und die entsprechenden Ge-
setze der Lnder.
Weiterhin gibt es Gesetze und Vorschriften, die speziell fr Behrden und in
der Verwaltung zu beachten sind, beispielsweise:
- Bundesarchivgesetz und die entsprechen Landesarchivgesetze,
- Registraturrichtlinie fr das Bearbeiten und Verwalten von Schriftgut in
Bundesministerien (RegR),
- Empfehlungen des Bundesarchivs zur Aussonderung elektronischer Akten
im Konzept zur Aussonderung elektronischer Akten der Koordinierungs-
und Beratungsstelle der Bundesregierung fr Information in der Bundes-
verwaltung (Schriftenreihe der KBSt, Band 40)
Organisationsspezifisch gelten darber hinaus zahlreiche weitere gesetzliche
und organisationsinterne Regelungen (z. B. Vorschriften fr Sozialversiche-
rungstrger, Krankenhuser, Pharmaindustrie, Militr oder Kreditwesen), die
im Einzelfall ermittelt werden mssen. Wesentliche Regelungskriterien sind
blicherweise die Aufbewahrungsdauer sowie der Vertraulichkeits- und Inte-
grittsbedarf, wobei bei letzteren neben der Strke auch die Zeitdauer des
Schutzbedarfs eingeht.
Fr die ffentliche Verwaltung besteht darber hinaus die gesetzliche Ver-
pflichtung, auch in digitaler Form vorliegende Dokumente den zustndigen
Archiven anzubieten (Anbietungspflicht).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.246 Ermittlung der organisatorischen

Einflussfaktoren fr die elektronische
Archivierung
Fr die elektronische Archivierung gibt es eine Reihe von organisatorischen
Einflussfaktoren, die bei der Konzeption des Archivsystems bercksichtigt
werden mssen. Dazu gehren unter anderem
- der Zeitraum des Einsatzes des Archivsystems,
- die Archivierungsfristen,
- der Vertraulichkeitsbedarf der Daten,
- der Verfgbarkeitsbedarf der Daten,
- der Integrittsbedarf der Daten,
- der Authentizittsbedarf der Daten,
- die Festlegung akzeptabler Antwortzeiten,
- der Rekonstruktionsaufwand,
- der Personalaufwand,
- die Kenntnisse und IT-spezifischen Qualifikationen der Benutzer,
- die Ergonomie und Bedienfreundlichkeit des Archivsystems,
- die Einhaltung von Standards und
- die finanziellen Randbedingungen.
Die angegebenen Einflussfaktoren sind nachfolgend detaillierter dargestellt.
Einsatzzeitraum des Archivsystems
Die Einsatzdauer eines Archivsystems ist getrennt von der Zeitdauer der Lebensdauer der
Komponenten
Archivierung zu kalkulieren. Es ist eine Abschtzung vorzunehmen, ber
welchen Zeitraum das konkret auszuwhlende System betriebsbereit sein soll.
Dies wirkt sich auf die Auswahl der Komponenten, speziell auf die geforderte
Lebensdauer der Komponenten, aus.
Ein langer Zeitraum impliziert die Auswahl langlebiger IT-Komponenten
sowie die Gestaltung entsprechender Service- und Liefervertrge, die
typischerweise mit hheren Kosten verbunden sind.
Ein kurzer Zeitraum impliziert eine frhere Migration des Archivs auf ein
neues Archivsystem.
Archivierungsfristen
Fr die Kalkulation der notwendigen Speicherkapazitt des Archivsystems ist
eine Abschtzung der Aufbewahrungsdauer der archivierten Dokumente
unerlsslich. Fr die Aufbewahrungsdauer ergeben sich aufgrund rechtlicher
oder organisationsinterner Vorgaben minimale, jedoch teilweise auch maxi-
male Speicherfristen, die zu beachten sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Aufbewahrungsdauer hat jedoch nicht nur Einfluss auf die

Speicherkapazitt des Archivsystems, sondern auch auf die Auswahl des
Speichermediums sowie dessen Entsorgung nach Ablauf der Aufbewahrungs-
dauer.
Vertraulichkeitsbedarf der Daten
Bei der Bestimmung des Vertraulichkeitsbedarfs ist vor allem zu beachten,
dass sich dieser Bedarf whrend der Archivierungsfrist ndern kann. Hierbei
knnen wirtschaftliche und juristische Einflussfaktoren Geltung erlangen.
Typischerweise ist davon auszugehen, dass der Vertraulichkeitsbedarf im
Lauf der Zeit abnimmt.
Wenn ein langfristiger Schutz der Vertraulichkeit gefordert wird, so hat dies
Einfluss auf die organisatorische Gestaltung des Archivierungskonzepts (siehe
M 2.264 Regelmige Aufbereitung von verschlsselten Daten bei der
Archivierung) und die Auswahl technischer Komponenten.
Verfgbarkeitsbedarf der Daten
Die elektronische Archivierung wird typischerweise zur langfristigen
Aufbewahrung von Daten und Dokumenten eingesetzt. Hierbei ist als
wesentliche Anforderung in einem der vorigen Punkte bereits festgelegt
worden, fr welchen Zeitraum die betreffenden Dokumente zu archivieren
sind.
Daneben ist festzulegen, welche weitergehenden Anforderungen an die
Verfgbarkeit zu stellen sind, z. B. die Ausfallsicherheit des Archivsystems
und die Stabilitt der verwendeten Speichermedien.
Integrittsbedarf der Daten
Die Integritt elektronisch archivierter Dokumente muss typischerweise auch
nach einer langen Aufbewahrungsdauer noch sichergestellt und prfbar sein.
Hierbei ist insbesondere davon auszugehen, dass Ursprungsdokumente und
weitere Kontextinformationen zwischenzeitlich nicht mehr existieren, die
Integrittsprfung also unmittelbar vom Archivsystem bereitgestellt werden
muss.
Es muss neben der Klassifizierung des Integrittsbedarfs (z. B. niedrig bis
mittel, hoch oder sehr hoch) festgelegt werden, ber welchen Zeitraum dies
prfbar sein soll.
Authentizittsbedarf der Daten
Analog zur Integritt muss auch der Authentizittsbedarf und der Zeitraum
festgelegt werden, innerhalb dessen die Authentizitt von Dokumenten
prfbar sein muss. Auch hier ist davon auszugehen, dass typischerweise nach
einer lngeren Archivierungsdauer die Ursprungsdokumente und
Kontextinformationen nicht mehr beigebracht werden knnen. Die
Authentizittsprfung muss also vom Archivierungsprozess bereitgestellt
werden.
Weitere allgemeine Hinweise zur Schutzbedarfsfeststellung in Bezug auf
Vertraulichkeit, Integritt und Verfgbarkeit finden sich in Kapitel 2.2.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bestimmung akzeptabler Antwortzeiten

Zwischen der Anfrage an ein Archivsystem und der Antwort ergibt sich eine
Verzgerung (Antwortzeit). Die Anforderungen an diese Verzgerung werden
typischerweise durch eine zu erzielende mittlere und eine maximal akzeptable
Antwortzeit definiert.
Die Antwortzeit ist nach unterschiedlichen Faktoren zu charakterisieren, u. a.
- die Zeitdauer bis zur Reaktion des Archivsystems bei einer Anfrage,
- die Zeitdauer bis zur Speicherbesttigung des Archivsystems und
- die Zeitdauer bis zur vollstndigen bertragung des gewnschten
Dokuments an das Clientsystem.
Die geforderte Antwortzeit hngt dabei sehr stark vom Einsatzszenario ab. So
kann z. B. bei der Abfertigung von Passagieren auf Flughfen eine
Abfragezeit von wenigen Minuten eine sinnvolle Anforderung sein. Bei einer
Recherche in Altdatenbestnden eines Grundbuchamtes knnen dagegen
durchaus Reaktionszeiten im Stundenbereich innerhalb der Regelarbeitszeit
akzeptabel sein.
Typischerweise ergeben sich auch subjektive Anforderungen an die subjektive
Anforderungen
Antwortzeiten. So kann z. B. eine hohe Reaktionszeit auf Suchanfragen oder
beim ffnen archivierter Dokumente als strender empfunden werden als eine
gleich lange Zeitdauer bis zur Speicherbesttigung bei der Ablage von
Dokumenten im Archiv.
Die Anforderungen an die Antwortzeit sind zu ermitteln und zu dokumen-
tieren.
Rekonstruktionsaufwand
Es ist zu bestimmen, welcher zeitliche und technische Aufwand fr das
Wiederfinden und Bereitstellen archivierter Dokumente akzeptabel ist. Dies ist
abhngig von der Art und Struktur der archivierten Daten und daher vom
konkreten Einsatzszenario.
Personalaufwand
Der Personalaufwand fr den Betrieb des Archivsystems stellt einen
wesentlichen Einflussfaktor bei der Auswahl des Systems dar.
Organisationsspezifisch ist zu ermitteln, welcher zustzliche Personalaufwand
und welche zustzliche individuelle Belastung des Personals durch die
Archivierung als tragbar angesehen werden.
Dies hat Auswirkungen auf die knftige Personalplanung, da gegebenenfalls
zustzliches Personal erforderlich ist. Die Rollen Archivverwalter,
Archivadministrator und (technischer) Benutzer sind mindestens zu besetzen.
Wenn im laufenden Betrieb zu wenig Personal verfgbar ist, muss die
fehlende Personalkapazitt durch externe Wartungs- und Servicevertrge
kompensiert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kenntnisse und IT-spezifische Qualifikationen der Benutzer

Die Auswahl geeigneter Bedienschnittstellen des Archivsystems wird unter
anderem von den Vorkenntnissen der vorgesehenen Benutzer beeinflusst. Hier
sollte ermittelt werden, welche IT-spezifischen Fachkenntnisse vorliegen.
Dies hat auch Einfluss auf die Gestaltung von Dienstleistungen im Umfeld der
Archivierung, etwa die Organisation einer Benutzeruntersttzung (Helpdesk).
Alle Benutzer mssen in jedem Fall im Umgang mit dem Archivsystem Schulung der Benutzer
geschult werden, damit Schden durch Fehlbedienung mglichst vermieden
werden. Die erforderliche Schulung muss in der Kalkulation der
Gesamtkosten bercksichtigt werden.
Ergonomie und Bedienfreundlichkeit des Archivsystems
Die Bedienfreundlichkeit hat mageblichen Einfluss auf die Akzeptanz durch
die Benutzer und dadurch auch auf die ordnungsgeme Nutzung des
Archivsystems.
Neben gesetzlichen Anforderungen zur Ergonomie an Arbeitspltzen ist Pilot- und
Testinstallationen
hierbei auch der subjektive Eindruck von Benutzern zu bercksichtigen. Die
Ermittlung entsprechender Anforderungen kann z. B. ber eine Befragung der
knftigen Benutzer erfolgen, es sollten jedoch auch Erfahrungen aus Pilot-
und Testinstallationen der vorgesehenen Archivsystem-Komponenten
einflieen.
Einhaltung von Standards
Fr die Interoperabilitt mit anderen Produkten und Organisationsprozessen Investitionsschutz
sollte darauf geachtet werden, dass Archivsystem-Komponenten gewhlt
werden, die konform zu bestehenden Standards sind. Obwohl auch Standards
nicht dauerhaft bestehen, sondern im Lauf der Zeit ebenfalls vom technischen
Fortschritt berholt werden, wird die Einhaltung der mageblichen Standards
typischerweise als Investitionsschutz angesehen.
Dies ist jedoch abhngig vom konkreten Einsatzzweck und der
Einsatzumgebung. Es sollte daher individuell ermittelt werden, welche
Standards mageblich sind. Einige relevante technische Standards sind in den
Manahmen M 4.169 Verwendung geeigneter Archivmedien und M 4.170
Auswahl geeigneter Datenformate fr die Archivierung von Dokumenten
beschrieben.
Finanzielle Randbedingungen
Die Einfhrung von Archivsystemen und die Gestaltung eines entsprechenden
organisatorischen Rahmens werden typischerweise von den anfallenden
Kosten beeinflusst:
- einmalige Investitionen,
- laufenden Kosten, inklusive Personalkosten,
- Lizenzgebhren.
Die technische Planung des Betriebs von Archivsystemen wird daher
typischerweise von einer Finanzplanung begleitet. Hierbei sind die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
organisationsinternen Regelungen (Budgetplanung, Verteilung von

Kostenstellen, etc.) zu bercksichtigen.
Die notwendigen Schulungen der Benutzer und Administratoren mssen in die
Kalkulation der Gesamtkosten der Archivierung einbezogen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.247 Planung des Einsatzes von Exchange/Outlook

2000
Bevor Exchange/Outlook 2000 eingefhrt wird, muss entschieden werden, fr
welche Einsatzzwecke das System genutzt werden soll. Von der Nutzungsart
hngt ab, welche Server-Variante beschafft werden muss, z. B. Exchange
2000 Enterprise Server oder Exchange 2000 Conferencing Server, und sie
bestimmt Art und den Umfang der notwendigen Planungen. Insbesondere
hngen auch die festzulegenden Sicherheitsrichtlinien stark vom geplanten
Einsatzszenario ab.
Generell kann grob zwischen drei verschiedenen Einsatzvarianten von Ex-
change-Servern unterschieden werden:
- Einsatz als Intranet-Server und Zugriff ber Outlook 2000 Clients. In die-
sem Szenario liegt das Hauptaugenmerk auf dem Einsatz als internes Sy-
stem zur Brokommunikation (E-Mail, Terminvereinbarung, Koordination
von Gruppenarbeit).
- Einsatz als Intranet-Server und Zugriff ber Web-Clients. In diesem Szena-
rio liegt der Schwerpunkt auf der Nutzung von Browsern zum Zugriff auf
einen Exchange-Server. Da an der Web-Schnittstelle des Exchange-Servers
gnzlich andere Sicherheitsmechanismen genutzt werden, wird die sichere
Konfiguration der Web-Schnittstelle als eigenes Szenario betrachtet.
- Einsatz in der DMZ (Demilitarisierte Zone). Ein Exchange-Server kann
auch als ffentlich zugnglicher Informations-Server in einer DMZ einge-
setzt werden. Diese Nutzungsart erfordert aufgrund der exponierten Stel-
lung des Servers besondere Aufmerksamkeit bei der Systemkonfiguration.
Innerhalb dieser Einzelszenarien kann weiter dahingehend unterschieden wer-
den, welche Funktionen von Exchange genutzt werden sollen, z. B. interne E-
Mail, Internet-Mail, Konferenz-Funktionen, Instant Messaging, LDAP-Server
oder HTML-Server. Eine Unterscheidung auf dieser Ebene soll hier nicht er-
folgen. Grundstzlich gilt jedoch, dass fr die Nutzung jeder Funktionalitt
eine eigene Planung erforderlich ist, bei der auch Sicherheitsaspekte zu be-
rcksichtigen sind. Fr einige Funktionen existieren passende, allgemeine
Bausteine im IT-Grundschutzhandbuch, siehe beispielsweise Baustein 7.4
E-Mail, die dann zur Anwendung kommen.
Grundstzlich mssen bei der Einsatzplanung folgende Aspekte bercksichtigt
werden:
- Exchange 2000 integriert sich in das Active Directory (AD) von Windows Integration in das Active
Directory
2000. Daher sollte die Exchange 2000 Planung mit der Planung des Active
Directory (siehe M 2.229 Planung des Active Directory) abgestimmt sein.
Bei der Installation von Exchange 2000 wird eine Schema-Erweiterung des
Active Directories durchgefhrt. Damit beeinflusst eine Exchange-Instal-
lation das Active Directory nachhaltig, so dass der Schema-Administrator
des Windows 2000 Systems unbedingt beteiligt werden muss. Auerdem
mssen die an der Planung beteiligten Personen ausreichende Kenntnisse
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ber den generellen Aufbau des Windows 2000 Systems haben, insbeson-
dere ber die Verteilung der Domnen-Controller und die Erreichbarkeit
des sogenannten Global Catalog Servers.
- Bei der Planung des Einsatzes von Exchange 2000 und Outlook 2000 ist Aufteilung in Routing
Groups
ber die Aufteilung in sogenannte Routing Groups zu entscheiden. Dies
sind Verbnde von Exchange-Servern, die ber eine spezielle Hochge-
schwindigkeitsverbindung miteinander kommunizieren. Dies lst das Site-
Konzept (Standort-Konzept) von Exchange 5.5 ab. Weiterhin ist ber die
Aufteilung der Exchange-Server in administrative Gruppen zu entscheiden.
- Die E-Mail-Datenbanken knnen partitioniert und auf verschiedene Ex- Partitionierung
change-Server verteilt werden. Damit lassen sich E-Mail-Daten mit unter-
schiedlichem Schutzbedarf auf entsprechend physikalisch gesicherte Server
aufteilen. Bei bedarfsgerechter Planung kann dies gleichzeitig die Perfor-
mance und die Ausfallsicherheit erhhen. Dies gilt auch fr den Einsatz der
Replikation der E-Mail-Datenbanken, die genutzt werden kann, um die
Ausfallsicherheit zu erhhen.
- Begleitend zur Planung des gewnschten Einsatzszenarios und der Vertei- Sicherheitsrichtlinie
erstellen
lung der Exchange-Server ist eine Sicherheitsrichtlinie zu entwerfen, in der
die fr Exchange spezifischen Aspekte behandelt werden. Die dabei zu be-
rcksichtigenden Gesichtspunkte sind in der Manahme M 2.248
Festlegung einer Sicherheitsrichtlinie fr Exchange/ Outlook 2000
zusammengefasst.
- Die Konfiguration des Exchange-Systems erfolgt ber die Mechanismen
der System- und Gruppenrichtlinien von Windows 2000. Diese Einstellun-
gen mssen mit den allgemeinen Richtlinieneinstellungen von Windows
2000 abgestimmt sein (siehe auch M 2.231 Planung der
Gruppenrichtlinien unter Windows 2000).
- Fr die Anbindung eines Exchange-Systems an fremde E-Mail/Messaging- Connectoren planen
Systeme, z. B. X.400 oder ccMail, stehen sogenannte Connectoren zur
Verfgung, welche die Verbindung zwischen den verschiedenen E-Mail-
Systemen herstellen. Der Einsatz dieser Connectoren ist sorgfltig zu
planen, um einen reibungslosen Ablauf des E-Mail-Verkehrs zu gewhr-
leisten.
- Um die Weiterleitung von E-Mails ber die eingerichteten Routing Groups Bridgehead Server
sicher betreiben
hinweg zu ermglichen, muss der Einsatz sogenannter Bridgehead Server
geplant werden. Da diese Server in der Regel mit fremden Netzen kommu-
nizieren mssen, sollten sie in einer demilitarisierten Zone (DMZ) oder
zumindest hinter einer Firewall (siehe Baustein 7.3 Firewall) platziert
werden.
- Der Einsatz der Outlook 2000 Clients, deren Zugriffsmglichkeiten auf das Zugriffsmglichkeiten
der Clients festlegen
Exchange-System und die Absicherung dieser Zugriffe mssen geplant
werden. Es ist ferner die Frage zu beantworten, ob eine Anbindung als
MAPI-Client gewnscht ist oder nicht. In der Vergangenheit wurde die
MAPI-Schnittstelle hufig zur Verbreitung von Programmen mit Schad-
funktionen (z. B. Viren, Wrmer, usw.) missbraucht.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Administration des Exchange/Outlook 2000 Systems muss geplant

werden. Die Aufgaben reichen dabei von der Festlegung der Verantwort-
lichkeiten inklusive Stellvertreterregelung in der Organisation bis zur Defi-
nition geeigneter Administrationsrollen. In den entsprechenden Domnen
mssen dann Benutzergruppen mit passenden Rechten eingerichtet werden.
- Die E-Mail-Konten und die verwendeten Newsgroups der Organisation
mssen geplant werden.
- Der Einsatz eines integrierten Viren-Schutzprogramms im Ex- Virenschutz
change/Outlook 2000 System muss geplant werden. Dabei ist zu entschei-
den, ob ein solches Programm Server- und/oder Client-seitig eingesetzt
wird.
- Die Behandlung aktiver Inhalte muss konsistent geplant werden. Dabei Behandlung aktiver
Inhalte
muss eine organisationsweit einheitliche Vorgehensweise festgelegt wer-
den, nachdem die jeweiligen Vor- und Nachteile gegeneinander abgewo-
gen wurden.
- Die organisationsweite Verwendung von "Out-of-Office"-Nachrichten Umgang mit
Abwesenheiten
muss entschieden werden, da bei der Verwendung dieser Funktionalitt
interne, personenbezogene Information, wie z. B. die Abwesenheit einer
konkreten Person, auch nach auen gelangen knnen.
- Die Verwendung von E-Mail-Filtern zur Abwehr von Spam-Mail (uner-
wnschte Werbe-E-Mail) muss geplant werden.
- Fr die Benutzung der Kalenderfunktion und der Aufgabenliste mssen
ggf. die Zugriffsmglichkeiten fremder Benutzer auf diese Funktionen
festgelegt werden.
- In der Planung ist zu bercksichtigen, welche Outlook-Benutzer einen ge-
meinsamen Rechner verwenden. Entsprechend sind Profile auf diesen
Rechnern anzulegen und gegenseitig abzusichern.
- Sollen Chat-, Instant Messaging-, Audio- oder Videokonferenz-Dienste in
der Organisation genutzt werden, so muss deren Einsatz konzipiert werden.
- Es muss ein Konzept fr Audit und Protokollierung entworfen werden. Audit und
Protokollierung
Dazu ist festzulegen, wie die Audit- und Protokollierungsfunktion des Ex-
change-Systems genutzt wird. Wird bereits ein unternehmensweites Audit-
oder Protokollierungssystem eingesetzt, so ist zu entscheiden, ob und wie
die Exchange-Integration erfolgt. Es ist darauf zu achten, den Datenschutz-
beauftragten und den Personal- bzw. Betriebsrat frhzeitig in die Planung
einzubeziehen, da im Rahmen der berwachung auch personenbezogene
Daten anfallen knnen.
- Fr das Exchange-System muss ein Backup-Konzept und ein Notfallvor-
sorge-Konzept erstellt werden. Dabei ist auf die Integration in existierende
Konzepte zu achten.
- Erfolgt der Zugriff auf ein Exchange-System ber HTTP (HyperText
Transfer Protocol) so ergeben sich besondere Sicherheitsaspekte. Diese so-
genannte OWA-Funktionalitt (Outlook Web Access) war in der Vergan-
genheit (speziell bei Exchange 5.5) oftmals das Ziel von Angriffen. Die
Absicherung und die Konfiguration muss deshalb besonders sorgfltig ge-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
plant und umgesetzt werden. In Anbetracht der Sicherheitsrisiken beim

Einsatz der OWA-Funktionalitt muss im Unternehmen bzw. in der Be-
hrde zunchst prinzipiell die Frage geklrt werden, ob der Browser-Zu-
griff berhaupt genutzt werden soll. Wird die OWA-Funktionalitt genutzt,
so ist allgemein folgendes zu beachten:
- Es ist zu entscheiden, auf welche Inhalte zugegriffen werden darf, z. B.
ffentliche Verzeichnisse (public folders), Newsgroups oder auch auf die
eigene Inbox.
- Die Aufstellung des Exchange-Servers, auf den ber das Internet zugegrif- Aufstellung des
Exchange-Servers
fen werden kann, ist sorgfltig zu planen. Hierbei geht es sowohl um die
geeignete Abschottung nach auen als auch nach innen. In den meisten
Fllen sollte der von auen erreichbare Exchange-Server in einer soge-
nannten Demilitarisierten Zone (DMZ) aufgestellt werden. Weitere Hin-
weise hierzu finden sich im Baustein 7.3 Firewall.
- Es ist zu beachten, dass ohne den Einsatz von Verschlsselung, z. B. mit
Hilfe von SSL, die zwischen Client und Server ausgetauschten Nachrichten
unter Umstnden von unberechtigten Dritten mitgelesen werden knnen.
Der Einsatz von SSL muss genau geplant werden, damit eine sichere beid-
seitige Authentisierung von Client und Server erreicht werden kann.
Die Planung des Exchange/Outlook-Systems darf nur dann als abgeschlossen
betrachtet werden, wenn auch das sogenannte Roll-out im Detail geplant wor-
den ist. Dabei wird u. a. die Installationsreihenfolge der einzelnen Exchange-
Server und aller Outlook-Clients festgelegt.
- Wurde das unterliegende Windows 2000 System bedarfsgerecht geplant?
- Wurde der Schema-Administrator in die Planung des Exchange-Systems
einbezogen?
- Existiert ein Plan zur Verteilung der Exchange/Outlook-Software?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.248 Festlegung einer Sicherheitsrichtlinie fr

Exchange/ Outlook 2000
Wie fr jedes in einer Behrde oder einem Unternehmen eingesetzte Client-
Server-System muss auch fr den Einsatz von Exchange 2000 Servern und
Outlook 2000 Clients eine geeignete Sicherheitsrichtlinie festgelegt werden.
Da sich Exchange 2000 sehr stark in die Windows 2000 Umgebung integriert,
speziell in das Windows 2000 Active Directory, muss die Windows 2000 Si-
cherheitsrichtlinie bercksichtigt werden (siehe hierzu M 2.228 Festlegen
einer Windows 2000 Sicherheitsrichtlinie sowie M 2.229 Planung des Active
Directory).
In der Sicherheitsrichtlinie fr Exchange/Outlook 2000 ist festzulegen,
- welche Benutzer auf welche Server zugreifen drfen und welche Benutzer
auf welche Server nicht zugreifen sollen (Ausschlussliste),
- welche Benutzer mit welchen Rechten auf welche E-Mail-Datenbanken
(Mail Store) zugreifen drfen,
- welche anderen Server auf einen Exchange-Server zugreifen drfen,
- wie E-Mail-Datenbanken repliziert werden,
- welche Bestandteile von E-Mail-Datenbanken repliziert werden und
- von wo aus auf einen Exchange-Server zugegriffen werden darf.
Wird die Sicherheitsrichtlinie festgelegt, so sind auerdem auch folgende
Aspekte zu bercksichtigen:
- Die Sicherheitsrichtlinie fr Exchange/Outlook muss konform zu den
geltenden generellen Sicherheitsrichtlinien des Unternehmens bzw. der
Behrde sein.
- Es muss festgelegt werden, wann eine Kommunikationsabsicherung, z. B.
fr Netz- oder E-Mail-Kommunikation, vorgenommen werden muss (z. B.
beim Zugriff mittels Browser oder generell beim Zugriff ber das Internet).
Dabei ist auch festzulegen, welche Mechanismen dafr genutzt werden
sollen.
- Die Gruppen fr die Exchange-Administration, die Routing Groups, die
Zugriffsberechtigungen zwischen diesen Gruppen (Benutzer- und Server-
orientiert) und die Replikation von E-Mail-Datenbanken mssen geplant
werden.
- Fr die Kommunikationsbeziehungen nach auen mssen jeweils dedi-
zierte Sicherheitsricht-linien festgelegt werden. Dabei ist auf Konsistenz
mit anderen Richtlinien zu achten, die dem Schutz der physischen und
logischen Grenzen der Organisation dienen.
Die Sicherheitsrichtlinie muss an alle mittel- und unmittelbar betroffenen Per-
sonen der Organisation verteilt und am besten in Form einer internen Schu-
lung dargestellt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Knnen alle relevanten Sicherheitsvorschriften auf Exchange/Outlook
2000 abgebildet werden?
- Mssen existierende Sicherheitsvorschriften gendert werden?
- Werden alle Benutzer ber neue oder vernderte Sicherheitsvorschriften
informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.249 Planung der Migration von "Exchange 5.5-

Servern" nach "Exchange 2000"
In der Praxis wird ein bereits bestehendes E-Mail-System hufig migriert,
anstatt eine vollstndige Neuinstallation durchzufhren. Exchange 5.5 ist ein
weit verbreitetes E-Mail- und Messaging-System, so dass die Migration von
Exchange 5.5 nach Exchange 2000 ein wichtiges Szenario darstellt.
Der Wechsel von Exchange 5.5 zu Exchange 2000 bedeutet einen gravieren- weitreichender Design-
Wechsel
den Sprung in nahezu smtlichen Teilaspekten. Es handelt sich deshalb nicht
um ein Software-Update, sondern um einen weitreichenden Designwechsel.
Bei diesem Wechsel ist nicht nur die Exchange-Software betroffen, sondern
auch das zugrundeliegende Betriebssystem Windows 2000. Ein installierter
Windows 2000 Server ist Systemvoraussetzung fr den Betrieb von Ex-
change 2000. Hufig fllt deshalb die Migration von Exchange 5.5 nach Ex-
change 2000 mit dem Wechsel des Betriebssystems von Windows NT 4 nach
Windows 2000 und der Einfhrung des Active Directory zusammen.
Exchange 2000 ist so konzipiert, dass es sich in das Windows 2000 Active Integration ins Active
Directory
Directory integriert. Bei der Installation von Exchange 2000 wird eine soge-
nannte Schema-Erweiterung des Active Directories vorgenommen. Eine
Schema-Vernderung ist ein grundlegender Eingriff in das Active Directory,
die nicht rckgngig gemacht werden kann. Es ist deshalb unerlsslich, den
Windows-Systemadministrator und speziell den Active Directory-Schema-
Administrator in die Migrationsplanung einzubeziehen.
Dass das Active Directory durch Exchange 2000 genutzt wird, hat folgende
Auswirkungen:
- Access Control Lists (ACLs) sind auf jede einzelne Ressource anwendbar, Access Control Lists
so z. B. auf einzelne Items von ffentlichen Verzeichnissen sowie auch auf
deren Eigenschaften (Properties).
- Anders als Exchange 5.5 verwendet Exchange 2000 keine Rollen mehr, da
sich die Sicherheit nicht mehr aus dem Information Store selbst ableitet.
Stattdessen wird die Berechtigung zur Administration des Exchange-
Servers im Active Directory vergeben.
- Die Security Identifiers (SIDs) fr Benutzer- und Gruppenobjekte werden Security Identifiers
in der ACL der jeweiligen Exchange-Objekte verwendet. Anonyme
Zugriffsberechtigungen werden einem speziellen anonymen Logon-Konto
zugewiesen. Jede Gruppe erhlt Standardeinstellungen fr die Zugriffsbe-
rechtigungen.
- Berechtigungen auf Benutzer-, Objekt- und Property-Basis knnen explizit
verboten werden. Verbotseinstellungen haben dabei Vorrang vor Erlaub-
niseinstellungen.
- Als Authentisierungsprotokoll im Netz wird Kerberos 5 verwendet. Details Kerberos
dazu finden sich beispielsweise in der Beschreibung des Bausteins 6.9
Windows 2000 Server.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die bei Exchange 5.5 noch bliche Site-Gruppierung von Exchange-Servern Routing Groups
werden unter Exchange 2000 durch die sogenannten Routing Groups abgelst.
Die so im Verbund organisierten Exchange-Server erlauben den Datenaus-
tausch mit hoher Bandbreite. Bei Exchange 2000 wird nun standardmig das
Simple Mail Transfer Protocol (SMTP) eingesetzt, anstelle der vormals ver-
wendeten Remote Procedure Calls (RPCs).
Auch hinsichtlich der Administration der Exchange-Server ergibt sich ein
Unterschied: Sie beschrnkte sich vormals auf eine NT-Domne, nun ist die
bergreifende Verwaltung ber Domnen hinweg innerhalb eines Forests
durch entsprechend autorisierte Administratoren mglich.
Die Aufgaben der Partitionierung und der Replizierung von Inhalten der E- Partitionierung und
Replizierung
Mail-Datenbank bernimmt in vollem Umfang das Active Directory. Hier ist
jedoch eine bedarfsgerechte Planung wesentlich, wenn eine Steigerung der
Performance erreicht werden soll.
Fremde E-Mail-Systeme, z. B. X.400 oder ccMail, werden mittels sogenannter
Connectoren an das Exchange-System angebunden. Speziell fr die hier be-
trachtete Migration wird auch ein Connector zur Anbindung eines Ex-
change 5.5 Systems an das Active Directory angeboten.
Die Migration muss in ihren einzelnen Schritten mglichst detailliert geplant, Migration planen und
dokumentieren
der angestrebte Migrationsprozess dokumentiert und allen Beteiligten zu-
gnglich gemacht werden. Im berblick sind folgende Schritte im Rahmen
des Migrationprozesses durchzufhren:
- Backup des Exchange 5.5-Systems
- Probelauf der Exchange 2000 Software in einem Testszenario
- Windows 2000 Active Directory auf Domnen-Controller
installieren
- Einrichten des Windows 2000 Netzes und der gewnschten Dienste
(DNS, DHCP, etc.)
- Neue Rechner (fr Exchange 2000 Server) mit Windows 2000
Server installieren
- Neue Rechner (fr Exchange 2000 Server) Mitglied der
gewnschten Domnen werden lassen
- Installation der Exchange 2000 Software auf den dafr vorgesehenen
Windows 2000 Servern
- Verteilung der Outlook 2000 Clients
- Einrichten der Benutzerkonten inklusive der E-Mail-Funktionalitt
- Einspielen der alten E-Mail-Daten. Dies kann dadurch geschehen,
dass ein Connector zu einem Exchange 5.5 Server eingerichtet wird.
Folgende Aspekte sind aus Sicherheitssicht bei der Planung der Migration zu
bercksichtigen:
- Welche E-Mail-Konten und ffentliche Verzeichnisse (public
folders) sind zu migrieren?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wird die bestehende Sicherheitsrichtlinie bernommen oder

gendert bzw. ergnzt?
- Ist das Active Directory-Konzept bercksichtigt und ggf. ergnzt
worden?
- Welche fremden E-Mail-Systeme mssen angebunden werden?
- Welche Routing- und Administrations-Gruppen werden definiert?
- Die bestehende Installation von Exchange 5.5 sollte gesichert und
zumindest so lange vorgehalten werden, bis das Exchange 2000 Sy-
stem zuverlssig in Betrieb genommen ist.
- Die neue Software sollte in einem separaten Testnetz getestet
werden.
Allgemein ist zu beachten, dass sich die Terminologie der Objekte von Ex- genderte Terminologie
change 5.5 nach Exchange 2000 teilweise gendert hat. So wechseln bei-
spielsweise die Begriffe Mailbox zu Mail-Enabled User, Distribution List zu
Distribution or Security Group, Custom Recipient zu Contact und einiges
weitere mehr.
- Wurde der Windows 2000 Systemadministrator an der Planung der Migra-
tion beteiligt?
- Wurden die vorzunehmenden Schema-nderungen am Active Directory
dokumentiert?
- Wurden fr die Migration Backups des Systems und der Daten eingeplant?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.250 Festlegung einer Outsourcing-Strategie

Verfahrensverantwortlicher
Die Bindung an einen Outsourcing-Dienstleister erfolgt auf lange Sicht, ist
zunchst kostenintensiv und mit Risiken verbunden. Eine gute Planung des
Outsourcing-Vorhabens ist daher wichtig. Dabei mssen neben den wirt-
schaftlichen, technischen und organisatorischen Randbedingungen auch die
sicherheitsrelevanten Aspekte bedacht werden. Folgende Gesichtspunkte
sollten betrachtet werden:
- Unternehmensstrategie (Flexibilitt, Abhngigkeiten, zuknftige Planun-
gen),
- Machbarkeitsstudie mit Zusammenstellung der Rahmenbedingungen,
- betriebswirtschaftliche Aspekte mit Kosten-Nutzen-Abschtzung.
Nach ersten strategischen berlegungen muss zunchst geklrt werden, wel-
che Aufgaben oder IT-Anwendungen generell fr Outsourcing in Frage kom-
men.
Dabei darf die Bedeutung der rechtlichen Rahmenbedingungen nicht unter- rechtliche Rahmenbe-
dingungen
schtzt werden. Gesetze knnten beispielsweise das Auslagern bestimmter
Kernaufgaben einer Institution generell verbieten oder zumindest weitrei-
chende Auflagen enthalten und die Beteiligung von Aufsichtsbehrden vor-
schreiben. In der Regel bleibt der Auftraggeber weiterhin gegenber seinen
Kunden oder staatlichen Stellen voll verantwortlich fr Dienstleistungen oder
Produkte, unabhngig davon, ob einzelne Aufgabenbereiche ausgelagert wur-
den.
Die IT-Sicherheit wird leider hufig zu Beginn der Planung vernachlssigt, generelle Sicherheits-
aspekte
obwohl ihr eine zentrale Bedeutung zukommt. Dies gilt sowohl fr technische
als auch organisatorische Sicherheitsaspekte, denen im Outsourcing-Szenario
eine entscheidende Rolle zukommt. Generell ist nmlich zu bedenken:
- Die Entscheidung zum Outsourcing ist in der Regel nicht einfach zu revi-
dieren. Die Bindung an den Dienstleister erfolgt unter Umstnden sehr
langfristig.
- Der Dienstleister hat Zugriff auf Daten und IT-Ressourcen des Auftragge-
bers. Der Outsourcing-Auftraggeber verliert dadurch die alleinige und voll-
stndige Kontrolle ber Daten und Ressourcen. Je nach Outsourcing-Vor-
haben betrifft dies dann auch Daten mit hohem Schutzbedarf.
- Fr die technische Umsetzung des Outsourcing-Vorhabens ist es notwen- Datenbertragung
dig, dass zwischen Auftraggeber und Dienstleister Daten bertragen wer-
den. Dadurch ergibt sich automatisch ein erhhtes Gefahrenpotential.
- In der Regel ist es erforderlich, dass Mitarbeiter oder Subunternehmer des
Outsourcing-Dienstleisters (und damit Betriebsfremde) zeitweise in den
Rumlichkeiten des Auftraggebers arbeiten mssen. Auch dadurch ergibt
sich ein erhhtes Gefahrenpotential.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Im Rahmen eines Outsourcing-Vorhabens mssen neue Prozesse und Ar-

beitsablufe entworfen, eingefhrt und durchgefhrt werden. Die Folgen
der notwendigen Umstellungen mssen geklrt und abgeschtzt werden.
- Fr jeden Outsourcing-Dienstleister besteht ein nicht zu unterschtzender Jeder Dienstleister muss
Geld verdienen!
Interessenskonflikt: Einerseits muss er die Dienstleistung mglichst
kostengnstig erbringen, um seinen Gewinn zu maximieren, andererseits
erwartet der Auftraggeber hohe Dienstleistungsqualitt, Flexibilitt und
kundenfreundliches Verhalten. Dieser Punkt ist erfahrungsgem der am
hufigsten unterschtzte. Whrend IT-Manager in der Regel sehr kritisch
und kostenbewusst sind und Versprechungen von Herstellern und Beratern
mit groer Skepsis begegnen, ist beim Outsourcing leider oft das Gegenteil
zu beobachten. Allzu leicht verfllt hier der Auftraggeber den Werbeaus-
sagen der Dienstleister in der frohen Erwartung, seine IT-Kosten signifi-
kant senken zu knnen. Die Praxis lehrt jedoch, dass hchstens die
Dienstleistungen in der Zukunft erbracht werden, die von Anfang an ver-
traglich fixiert worden sind. Stellt sich heraus, dass die Dienstleistungs-
qualitt unzureichend ist, weil der Auftraggeber Leistungen erwartet, die er
- im Gegensatz zum Outsourcing-Dienstleister - als selbstverstndlich er-
achtet, sind Nachbesserungen in der Regel ohne hohe zustzliche Kosten
nicht zu erwarten. Jeder IT-Manager, der ber Outsourcing nachdenkt,
sollte sich die Mhe machen nachzurechnen, zu welchen Kosten ein
Dienstleister die vereinbarte Leistung erbringen muss, damit Auftraggeber
und Auftragnehmer beide von dem Vertragsverhltnis profitieren. Bei die-
ser Rechnung stellt sich vielleicht heraus, dass eine serise Leistungs-
erbringung zu den versprochenen niedrigen Kosten hchst unwahrschein-
lich ist.
Um die Outsourcing-Strategie festzulegen, muss daher immer eine indivi- individuelle Sicherheits-
analyse
duelle Sicherheitsanalyse durchgefhrt werden. Nur so kann letztendlich fest-
gestellt werden, wie bestehende IT-Systeme oder IT-Verbnde abgegrenzt und
getrennt werden knnen, damit Teile davon ausgelagert werden knnen. In
dieser frhen Projektphase wird das Sicherheitskonzept naturgem nur Rah-
menbedingungen beschreiben und keine detaillierten Manahmen enthalten.
Die IT-Sicherheitsanalyse sollte nach der im IT-Grundschutzhandbuch be-
schriebenen Methodik durchgefhrt werden:
- Es sollte eine IT-Strukturanalyse durchgefhrt werden, sofern IT-Outsour-
cing geplant ist.
- Danach erfolgt eine Schutzbedarfsfeststellung.
- Im Einzelfall kann auch jetzt schon eine IT-Grundschutz-Analyse erfolgen,
um den Handlungsbedarf sowie die Kosten fr umzusetzende Manahmen
zu identifizieren. Die Ergebnisse knnen dann insbesondere in die Be-
trachtung der Wirtschaftlichkeit des Outsourcing-Vorhabens mit einbezo-
gen werden.
Wenn der Schutzbedarf wichtiger Systeme oder Anwendungen hoch ist oder
die Modellierung des IT-Verbunds nach IT-Grundschutzhandbuch nicht mg-
lich ist, muss eine ergnzende Sicherheitsanalyse (z. B. Risikoanalyse) durch-
gefhrt werden. Sind die sicherheitsrelevanten Gefhrdungen analysiert wor-
den, kann festgelegt werden, ob und wie diesen begegnet werden soll.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schlussendlich wird dennoch ein gewisses Restrisiko durch den Outsourcing-

Auftraggeber zu tragen sein. Die Ergebnisse der Sicherheitsanalyse gehen
unmittelbar in die Kosten-Nutzen-Abschtzung ein.
Das Management darf bei der Entwicklung einer erfolgversprechenden, lang- strategische ber-
legungen
fristigen Outsourcing-Strategie den Blick nicht nur auf die Einsparung von
Kosten richten. Die Auswirkungen eines Outsourcing-Vorhabens auf die Auf-
gabenerfllung, das Geschftsmodell und das Dienstleistungs- oder Produkt-
portfolio mssen ebenfalls bercksichtigt werden. Sollen Standardablufe oder
Kerngeschftsprozesse ausgelagert werden? Wichtig ist in diesem Zusam-
menhang, dass die Fhigkeit, Anforderungen an die IT selbst zu bestimmen
und zu kontrollieren in ausreichendem Mae erhalten werden. Insbesondere an
die Weiterentwicklung und Pflege selbstentwickelter IT-Systeme und Anwen-
dungen sollte gedacht werden.
Die nachfolgenden Hinweise beleuchten Vor- und Nachteile von Outsourcing
mit Bezug zur IT-Sicherheit.
- Vorteil: Es besteht die Mglichkeit, neue Dienstleistungen (z. B. durch
Diversifikation oder Ausweitung der Produktpalette) zu etablieren. In der
Folge muss das festgelegte Sicherheitsniveau jedoch auch fr das ausge-
weitete Angebot sichergestellt werden.
- Vorteil: Es besteht mehr Flexibilitt, beispielsweise knnen Systeme, Res- hhere Flexibilitt
sourcen oder der Personalbedarf schneller angepasst bzw. erweitert
werden, da dies vom Outsourcing-Dienstleister unter Umstnden auch
kurzfristig eingekauft werden kann. Fixe Kosten knnen so in variable um-
gewandelt werden. In Folge knnen sich jedoch durch die Erweiterungen
(z. B. von IT-Systemen) auch neue Sicherheitsprobleme ergeben.
- Vorteil: Im Idealfall kann durch das Outsourcing-Vorhaben ein besseres hheres IT-Sicherheits-
niveau durch externe
IT-Sicherheitsniveau erreicht werden, da der Dienstleister Spezialisten be- Experten
schftigt, so dass dadurch auch neue, sicherheitskritische Anwendungen
betrieben werden knnen. Gerade in der IT-Sicherheit ist es sehr zeitauf-
wndig und bentigt viel technisches Wissen, regelmig die Flut an Si-
cherheitshinweisen, Security-Bulletins, Updatemeldungen und Bug-Re-
ports auszuwerten, ihre Relevanz zu erkennen und bei Bedarf rasch die
richtigen Schritte einzuleiten. Zunehmende Komplexitt der angebotenen
Hard- und Softwarelsungen, immer krzere Produktzyklen, steigende
Vernetzung und steigende Anforderungen der Nutzer machen es zudem
auerordentlich schwierig, immer wieder die richtige Balance zwischen
Sicherheit und "mehr Funktionalitt" zu finden.
- Vorteil: Gerade in Unternehmen oder Behrden mit kleiner IT-Abteilung
haben einzelne Mitarbeiter oft einen hohen Stellenwert. Stehen sie einmal
nicht zur Verfgung (Krankheit, Urlaub) oder verlassen die Institution,
knnen sich gravierende Sicherheitsprobleme ergeben, weil es keinen
gleichwertigen Vertreter gibt. Dienstleister hingegen knnen in der Regel
auf mehrere gleich qualifizierte Experten zurckgreifen, die sich gegensei-
tig vertreten knnen.
- Vorteil: Von einigen Institutionen wird Outsourcing hufig als vielleicht
einzige Mglichkeit gesehen, eine Neugestaltung ihrer IT-Systeme und
Anwendungen gegen interne Widerstnde durchzusetzen. Im Zuge des
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Outsourcings soll eine heterogene Systemlandschaft aufgerumt und stan-

dardisiert werden.
- Nachteil: Wenn das Know-how der vom Outsourcing-Dienstleister einge-
setzten Spezialisten nicht angemessen ist, so knnen dadurch gravierende
IT-Sicherheitslcken entstehen. Ist zustzlich intern nicht mehr das Fach-
wissen vorhanden, um das Sicherheitsniveau beim Outsourcing-
Dienstleister zu kontrollieren, werden Sicherheitslcken womglich nicht
einmal entdeckt.
- Nachteil: Eine Ausweitung des Dienstleistungsangebots oder die Erweite-
rung von IT-Systemen ist nicht mehr allein eine Entscheidung des eigenen
Managements. Der Outsourcing-Dienstleister muss immer an der Diskus-
sion beteiligt werden. Dienstleister kompensieren nicht selten gnstige
Konditionen bei Vertragsabschluss durch hohe Forderungen bei spteren
Sonderwnschen oder neuen Anforderungen des Auftraggebers. Der dann
entstehende Kostendruck fhrt oftmals zu Einsparungen bei der IT-Sicher-
heit.
- Nachteil: Der Aufwand fr die Kontrolle der Dienstleistungsqualitt darf
nicht unterschtzt werden. Sollten hierbei Defizite festgestellt werden,
knnen diese schwierig und zeitaufwendig zu beheben sein, vor allem
wenn es zu Meinungsverschiedenheiten zwischen Auftraggeber und
Dienstleister kommt. Wenn Fragen der IT-Sicherheit dann nicht zeitnah
gelst werden, knnen sich Sicherheitslcken ergeben.
Eine umfassende Kosten-Nutzen-Analyse jedes Outsourcing-Vorhabens ist Kosten-Nutzen-Analyse
essentiell fr den strategischen und wirtschaftlichen Erfolg. Es ist daher wich-
tig, alle Parameter zu kennen und auch richtig einzuschtzen.
Der strategische Wert der folgenden Ressourcen muss unter den Rahmenbe-
dingungen des Outsourcing-Vorhabens eingeschtzt werden:
- Know-how
- Mitarbeiter
- IT-Systeme und Anwendungen
Bei der Kosten-Nutzen-Analyse knnen Studien und Erfahrungsberichte
anderer Institutionen wertvolle Informationen liefern.
Abschlieend ist die Outsourcing-Strategie zu dokumentieren. Die Ziele, Dokumentation der
gewhlten Strategie
Chancen und Risiken des Outsourcing-Vorhabens sollten eindeutig beschrie-
ben werden. Es empfiehlt sich unter diesem Gesichtspunkt auerdem, die im
Rahmen eines laufenden Outsourcing-Vorhabens gemachten Erfahrungen in
die Dokumentation der Outsourcing-Strategie zu integrieren. Es sollte dabei
auch auf Fehlentscheidungen und daraus abgeleitete Empfehlungen fr die
Zukunft hingewiesen werden.
- Sind alle betrieblichen und rechtlichen Rahmenbedingungen abgeklrt?
- Wurden IT-Sicherheitsgesichtspunkte ausreichend bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.251 Festlegung der Sicherheitsanforderungen fr

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Leiter IT ,
Administrator,
Wenn eine Outsourcing-Strategie festgelegt wurde, mssen die IT-Sicher-
heitsanforderungen so konkret ausgearbeitet werden, dass auf ihrer Basis der
geeignete Dienstleister ausgesucht werden kann. Dabei sind Sicherheitsanfor-
derungen an den Outsourcing-Dienstleister selbst, die benutzte Technik (in-
klusive Kommunikationswege und -dienste), aber auch an die eigene Organi-
sation zu stellen. Die Erstellung eines detaillierten Sicherheitskonzeptes, das
auf den hier formulierten Anforderungen aufbaut und nach Auswahl des
Dienstleisters ausgearbeitet wird, wird in M 2.254 Erstellung eines IT-
Sicherheitskonzepts fr das Outsourcing-Vorhaben beschrieben.
Es ist zu bedenken, dass das Festlegen von IT-Sicherheitsanforderungen ein
iterativer Prozess ist:
- Zunchst werden die gewnschten IT-Sicherheitsanforderungen durch den
Auftraggeber spezifiziert.
- Danach wird in der Angebotsphase abgeglichen, wie und ob die gewnsch-
ten IT-Sicherheitsanforderungen durch die anbietenden Dienstleister ge-
leistet werden knnen (siehe auch M 2.252 Wahl eines geeigneten
Outsourcing-Dienstleisters).
- Ist ein Dienstleister ausgewhlt, so muss mit diesem die weitere Verfeine-
rung der IT-Sicherheitsanforderungen (z. B. basierend auf den eingesetzten
Betriebssystemen oder Sicherheitsmechanismen) erarbeitet werden. In der
Endphase dieses Abstimmungsprozesses mssen dann auch die Sicher-
heitsanforderungen fr die konkrete Umsetzung definiert werden.
Generell ergeben sich fr Outsourcing-Szenarien folgende Mindestsicherheits-
anforderungen:
- Die Umsetzung des IT-Grundschutzes ist eine Minimalforderung an beide Umsetzung von IT-
Grundschutz
Outsourcing-Parteien. Zustzlich mssen sowohl Outsourcing-Dienstleister
als auch der Auftraggeber selbst ein IT-Sicherheitskonzept besitzen und
dieses umgesetzt haben.
- Es ist wichtig, die relevanten IT-Verbnde genau abzugrenzen (z. B. nach
Fachaufgabe, Geschftsprozess, IT-Systemen), so dass alle Schnittstellen
identifiziert werden knnen. An die Schnittstellen knnen dann entspre-
chende technische Sicherheitsanforderungen gestellt werden.
- Es muss eine Ist-Strukturanalyse von IT-Systemen und Anwendungen
(siehe auch M 2.250 Festlegung einer Outsourcing-Strategie) erfolgen.
- Es muss eine Schutzbedarfsfeststellung (z. B. von Anwendungen, Syste-
men, Kommunikationsverbindungen, Rumen) bezglich Vertraulichkeit,
Integritt und Verfgbarkeit erfolgen (siehe auch M 2.250 Festlegung einer
Outsourcing-Strategie).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Natrlich sind auch relevante Gesetze und Vorschriften zu beachten. Dies

kann besonders in Fllen, in denen Auftraggeber oder Dienstleister ln-
derbergreifend oder weltweit operieren, aufwendig sein.
Im Rahmen der IT-Sicherheitsanforderungen ist festzulegen, welche Rechte
(z. B. Zutrittsrechte, Zugriffsrechte auf Daten und Systeme) dem Outsourcing-
Dienstleister vom Auftraggeber eingerumt werden.
Die Anforderungen an Infrastruktur, Organisation, Personal und Technik ms-
sen beschrieben werden. Es gengt hier oftmals die Verpflichtung auf ein
Sicherheitsniveau, das IT-Grundschutz entspricht. Sollten darber hinausge-
hende Anforderungen bestehen, mssen diese detailliert beschrieben werden.
Dies hngt entscheidend von der Sicherheitsstrategie und bereits vorhandenen
Systemen und Anwendungen ab. Beispielsweise knnten folgende Punkte in
Abhngigkeit vom Outsourcing-Vorhaben detailliert werden:
Organisatorische Regelungen und Prozesse
- Anforderungen an sicherheitskritische organisatorische Prozesse (z. B.
Zeitrestriktionen fr den Alarmierungsplan) knnen spezifiziert werden.
- Spezielle Anforderungen an bestimmte Rollen knnen festgelegt werden.
Es kann beispielsweise gefordert werden, dass ein IT-Sicherheitsbeauf-
tragter mit speziellen Kenntnissen (z. B. Host-Kenntnissen) beim Outsour-
cing-Dienstleister benannt werden muss.
Hard-/Software
- Der Einsatz zertifizierter Produkte (z. B. gem Common Criteria oder
ITSEC) beim Outsourcing-Dienstleister kann gefordert werden.
- Anforderungen an die Verfgbarkeit von Diensten und IT-Systemen kn-
nen gestellt werden. Beispielsweise kann in diesem Zusammenhang der
Grad und die Methode der Lastverteilung (z. B. fr Web-Server mit Kun-
denzugriff bei sehr vielen Kunden) vorgegeben werden.
- Vorgaben an die Mandantenfhigkeit sowie die diesbezgliche Trennung
von Hard- und Software knnen formuliert werden. Beispielsweise kann
festgelegt werden, dass keine IT-Systeme des Auftraggebers in Rumen
untergebracht werden drfen, in denen bereits Systeme anderer Mandanten
des Dienstleisters stehen.
Kommunikation
- Spezielle Verfahren zur Absicherung der Kommunikation zwischen
Dienstleister und Auftraggeber wie Einsatz von Verschlsselungs- und
Signaturverfahren (siehe auch Bausteine 7.6 Remote Access und 3.7
Kryptokonzept) knnen fest vorgegeben werden.
Kontrollen und QS
- Allgemeine Anforderungen bezglich Kontrolle und Messung von Sicher-
heit, Qualitt oder auch Ablufen und organisatorischen Regelungen kn-
nen festgelegt werden, z. B. Zeitintervalle, Zustndigkeiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gewnschte Verfahren oder Mechanismen fr die Kontrolle und berwa-

chung, wie unangekndigte Kontrollen vor Ort, Audits (unter Umstnden
durch unabhngige Dritte) knnen spezifiziert werden.
- Anforderungen an die Protokollierung und Auswertung von Protokollda-
teien knnen festgelegt werden.
Generell bilden die festgelegten IT-Sicherheitsanforderungen eine der Grund-
lagen fr die Wahl eines geeigneten Outsourcing-Dienstleisters. Spezielle IT-
Sicherheitsanforderungen mssen jedoch eventuell an das von Dienstleistern
umsetzbare IT-Sicherheitsniveau angepasst werden.
- Ist IT-Grundschutz als Minimalanforderung in die Anforderungsliste
aufgenommen worden?
- Sind alle IT-Sicherheitsanforderungen fr das Outsourcing-Vorhaben
ausreichend detailliert beschrieben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.252 Wahl eines geeigneten Outsourcing-

Dienstleisters
Verantwortlich fr Umsetzung: Behrden-/Unternehmensleitung, Leiter IT,
Bei der Wahl eines geeigneten Outsourcing-Dienstleisters sind ein mglichst
detailliertes Anforderungsprofil und ein darauf basierendes Pflichtenheft ent-
scheidende Erfolgsfaktoren. Nur so kann eine bedarfsgerechte Ausschreibung
erfolgen, auf die sich auch geeignete Dienstleister bewerben.
Die Ausschreibung sollte die
- Beschreibung des Outsourcing-Vorhabens (Aufgabenbeschreibung und allgemeine Beschrei-
bung
Aufgabenteilung) sowie
- Beschreibungen zum geforderten Qualittsniveau, welches nicht
zwangslufig dem Niveau des Auftraggebers entsprechen muss, enthalten.
Weiterhin mssen den potenziellen Dienstleistern auch mglichst detailliert Sicherheits-
anforderungen
die
- IT-Sicherheitsanforderungen und die
- Kriterien zur Messung von Servicequalitt und Sicherheit
mitgeteilt werden (siehe M 2.251 Festlegung der Sicherheitsanforderungen
fr Outsourcing-Vorhaben). In Einzelfllen kann es notwendig sein, die
Detailanforderungen bezglich Sicherheit nur gegen eine Geheimhaltungsver-
einbarung an Dienstleister herauszugeben, da sich daraus Hinweise auf exis-
tierende oder geplante Sicherheitsmechanismen ableiten lassen.
Das Anforderungsprofil hngt stark von der Art des Outsourcing-Vorhabens
ab. Als wichtige grundstzliche Bewertungskriterien fr Dienstleister und
dessen Personal knnen gelten:
Anforderungen an Outsourcing-Dienstleister
- Bei auslndischen Dienstleistern mssen besondere Aspekte bedacht wer- Herkunft des Outsour-
cing-Dienstleisters
den. Dazu gehren beispielsweise: fremde Gesetzgebung, andere Haftungs-
regelungen, Spionagerisiko, andere Sicherheitskultur, im Partnerunterneh-
men bzw. durch die landesspezifische Gesetzgebung zugelassene und ver-
wendbare Sicherheitsmechanismen.
- Die Gre des Dienstleisters kann bei der Auswahl ein Argument sein. Bei Gre des Dienstleisters
kleinen Unternehmen knnte das Insolvenzrisiko hher sein. Bei groen
Unternehmen ist zu bedenken, dass diese sehr viele Auftraggeber und Pro-
jekte haben, so dass ein einzelner Auftraggeber nur einer unter vielen ist
und keine bevorzugte Stellung einnimmt.
- Der Dienstleister sollte Referenzen fr hnliche Outsourcing-Vorhaben Referenzen
aufweisen knnen. Dabei ist auf Interessenskonflikte durch Geschftsbe-
ziehungen zu Konkurrenten des Auftraggebers und auf die Unabhngigkeit
von bestimmten Herstellern (z. B. Zulieferer, die Konkurrenten des Auf-
traggebers sind) zu achten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Organisationsform eines Dienstleisters kann in Betracht gezogen wer- Eigentmerstruktur und
den, da dies z. B. die Haftungsgrenzen beeinflussen kann. Die Eigentmer- Organisationsform
struktur sollte recherchiert werden, um mgliche Einflussfaktoren im Vor-
feld abzuklren.
- Die Kundenstruktur sollte beachtet werden, da dies darauf hinweist, in Kundenstruktur
welchem Wirtschaftssektor der Anbieter seine Strken hat.
- Ein Qualittsnachweis bzw. eine Zertifizierung, z. B. nach IT-Grundschutz Zertifizierung
oder ISO 9000, ist eine sinnvolle Forderung.
- Ausknfte ber die aktuelle wirtschaftliche Lage sowie Erwartungen an die Solvenz
zuknftige Geschftsentwicklung der Dienstleister sollten eingeholt wer-
den.
Anforderungen an Mitarbeiter
Auch an die Mitarbeiter eines Dienstleisters sind diverse Anforderungen zu
stellen (siehe auch M 2.226 Regelungen fr den Einsatz von Fremdpersonal
und M 3.33 Sicherheitsberprfung von Mitarbeitern).
- Die Qualifikation der Mitarbeiter muss in die Bewertung der Angebote Qualifikationsprofil
einflieen. Es ist nach der Projektvergabe darauf zu achten, dass die im
Angebot genannten Mitarbeiter auch spter tatschlich eingesetzt werden.
- Die Anzahl der verfgbaren Mitarbeiter muss bewertet werden. Dabei soll- Ressourcenplanung
ten auch die Vertretungsregelungen und die Arbeitszeiten hinterfragt wer-
den.
- Bei der Wahl auslndischer Partner muss eine gemeinsame Sprache fr die Kommunikationssprache
Kommunikation zwischen den eigenen Mitarbeiter und denen des
Dienstleisters festgelegt werden. Hierbei sollte auch hinterfragt werden, ob
die vorhandenen Sprachkenntnisse fr die Klrung von Detailproblemen
ausreichen. Die Erfahrungen zeigen, dass viele Personen aus Angst, sich zu
blamieren, lieber zu wichtigen Fragen schweigen, wenn sie ihre Sprachf-
higkeiten als nicht perfekt einschtzen.
- Entsprechend dem erforderlichen Sicherheitsniveau fr das Outsourcing- Sicherheitsberprfung
Vorhaben sollte in die Bewertung der Angebote mit aufgenommen werden,
ob eine Sicherheitsberprfung der Mitarbeiter vorliegt bzw. eine solche
durchgefhrt werden kann.
- Ist ein Bewertungsmastab mit Bewertungskriterien fr die Anbieteraus-
wahl festgelegt worden?
- Sind die Sicherheitsanforderungen im Bewertungsmastab bercksichtigt?
- Ist der Bewertungsmastab auf das konkrete Outsourcing-Vorhaben zuge-
schnitten worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.253 Vertragsgestaltung mit dem Outsourcing-

Dienstleister
Verantwortlich fr Umsetzung: Behrden-/Unternehmensleitung, IT-Sicher-
Nachdem ein Outsourcing-Dienstleister ausgewhlt wurde, mssen alle As-
pekte des Outsourcing-Vorhabens vertraglich in sogenannten Service Level
Agreements (SLAs) festgehalten und geregelt werden. Die Aspekte, die im
Folgenden beschrieben werden, sind als Hilfsmittel und Checkliste bei der
Vertragsgestaltung zu sehen. Art, Umfang und Detaillierungsgrad der vertrag-
lichen Regelungen hngen immer vom speziellen Outsourcing-Projekt ab. Je
hher der Schutzbedarf der ausgelagerten IT-Systeme und Anwendungen ist,
desto sorgfltiger und detaillierter muss der Vertrag zwischen Auftraggeber
und Dienstleister ausgehandelt werden. Der Dienstleister sollte auf Einhaltung
des IT-Grundschutzes und auf die vom Auftraggeber vorgegebenen Sicher-
heitsanforderungen verpflichtet werden (siehe M 2.251 Festlegung der Si-
cherheitsanforderungen fr Outsourcing-Vorhaben). Dazu gehrt natrlich,
dass der Outsourcing-Dienstleister sich verpflichtet, ein IT-Sicherheitskonzept
inklusive eines Notfallvorsorgekonzepts zu erstellen und Sicherheitsmanah-
men sowie Systeme und Anwendungen zu dokumentieren.
Zustzlich zur allgemeinen Leistungsbeschreibung empfiehlt es sich jedoch
immer, auch eine genaue quantitative Leistungsbeschreibung vertraglich zu
fixieren, z. B. zu Verfgbarkeitsanforderungen, Reaktionszeiten, Rechenleis-
tung, zur Verfgung stehendem Speicherplatz, Anzahl der Mitarbeiter, Sup-
portzeiten.
Generell wre eine allgemeine Verpflichtung auf die Einhaltung des IT-
Grundschutzes zwar zufriedenstellend, es empfiehlt sich jedoch immer, alle
vereinbarten Leistungen so genau und eindeutig wie mglich vertraglich fest-
zuhalten. Dadurch lassen sich spter Streitigkeiten zwischen den Parteien
vermeiden. Nachtrgliche Konkretisierungen und Ergnzungen des Vertrages,
die aufgrund unterschiedlicher Interpretationen der beschriebenen Leistungen
notwendig werden, sind oftmals mit deutlichen Kostenerhhungen fr den
Auftraggeber verbunden. Auch die Erstellung des IT-Sicherheitskonzeptes
selbst sollte Vertragsbestandteil sein. Insbesondere ist zu klren, wer fr die
fachlichen Inhalte verantwortlich ist und welche Mitwirkungspflichten dem
Auftraggeber obliegen.
Im Folgenden findet sich eine Themenliste von Aspekten, die aus Sicherheits-
sicht geregelt werden sollten. Weitere Hinweise zu Details knnen den jewei-
ligen Manahmen des IT-Grundschutzhandbuches entnommen werden:
Infrastruktur
- Absicherung der Infrastruktur des Dienstleisters (z. B. Zutrittskontrolle,
Brandschutz, ...)
Organisatorische Regelungen/ Prozesse
- Festlegung von Kommunikationswegen und Ansprechpartnern
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Festlegung von Prozessen, Arbeitsablufen und Zustndigkeiten

- Verfahren zur Behebung von Problemen, Benennung von
Ansprechpartnern mit den ntigen Befugnissen
- regelmige Abstimmungsrunden
- Archivierung und Lschung von Datenbestnden (insbesondere bei
Beendigung des Vertragsverhltnisses)
- Zugriffsmglichkeiten des Dienstleisters auf IT-Ressourcen des Auftragge-
bers: Wer greift wie auf welches System zu? Wie sind die Zustndigkeiten
und Rechte?
- Zutritts- und Zugriffsberechtigungen fr Mitarbeiter des Dienstleisters zu
den Rumlichkeiten und IT-Systemen des Auftraggebers
- Zutritts- und Zugriffsberechtigungen fr Mitarbeiter des Auftraggebers zu
den Rumlichkeiten und IT-Systemen des Dienstleisters
Personal
- Gestaltung der Arbeitspltze von externen Mitarbeitern (Einhalten von
Computerarbeitsplatzrichtlinien)
- Festlegung und Abstimmung von Vertretungsregelungen
- Verpflichtung zu Fortbildungsmanahmen
Notfallvorsorge
- Kategorien zur Einteilung von Fehlern und Strfllen nach Art, Schwere
und Dringlichkeit.
- erforderliche Handlungen beim Eintreten eines Strfalls
- Reaktionszeiten und Eskalationsstufen.
- Mitwirkungspflicht des Auftraggebers bei der Behebung von Notfllen
- Art und zeitliche Abfolge von regelmigen und adquaten Notfallbungen
- Art und Umfang der Datensicherung
- Vereinbarung, ob bzw. welche Systeme redundant ausgelegt sein mssen
- Von besonderer Bedeutung knnen Regelungen im Fall hherer Gewalt
sein. Es sollte beispielsweise geklrt sein, wie bei einem Streik des Perso-
nals des Dienstleisters die Verfgbarkeit von Daten und Systemen sicher-
gestellt werden kann. Besonders wenn Dienstleister und Auftraggeber un-
terschiedlichen Branchen angehren oder ihren Sitz in verschiedenen Ln-
dern haben, kann der Auftraggeber von derartigen Vorkommnissen gnz-
lich berrascht werden.
Haftung, juristische Rahmenbedingungen
- Eine Verpflichtung auf die Einhaltung von geltenden Normen und Geset-
zen sowie der vereinbarten Sicherheitsmanahmen und sonstigen Rahmen-
bedingungen ist vertraglich zu regeln. Ebenso sind Geheimhaltungsverein-
barungen vertraglich zu fixieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Einbindung Dritter, Subunternehmer und Unterauftragnehmer des

Dienstleisters ist zu regeln. In der Regel empfiehlt es sicht nicht, diese
grundstzlich auszuschlieen, sondern sinnvolle Regelungen festzulegen.
- Die Eigentums- und Urheberrechte an Systemen, Software und Schnittstel-
len sind festzulegen. Es ist auch zu klren, ob der Dienstleister bereits be-
stehende Vertrge mit Dritten (Hardwareausstattung, Servicevertrge,
Softwarelizenzen etc.) bernimmt.
- Die Weiterverwendung der vom Dienstleister eingesetzten Tools, Prozedu-
ren, Skripte, Batchprogramme ist fr den Fall der Beendigung des Dienst-
leistungsverhltnisses zu regeln.
- Regelungen fr das Ende des Outsourcing-Vorhabens, z. B. fr einen
Wechsel oder bei Insolvenz des Dienstleisters, knnen spezifiziert werden.
Auf ein ausreichend flexibles Kndigungsrecht ist zu achten.
- Der Auftragnehmer ist zu verpflichten, nach Beendigung des Auftrags alle
Hard- und Software inklusive gespeicherter Daten, die dem Auftraggeber
gehren, zurckzugeben. Alle vorhandenen Daten inklusive Datensiche-
rungen sind ebenfalls zurckzugeben oder (je nach Vereinbarung) zu ver-
nichten.
- Die Aufteilung von Risiken zwischen Auftraggeber und Dienstleister muss
bedacht werden.
- Haftungsfragen im Schadensfall sind zu klren.
- Sanktionen oder Schadensersatz bei Nichteinhaltung der Dienstleistungs-
qualitt mssen festgelegt werden. Die Bedeutung von Schadensersatz-
zahlungen und juristischen Konsequenzen sollte dabei nicht berschtzt
werden. Zu bedenken sind nmlich die folgenden Punkte:
1. Quantifizierbarkeit des Schadens
- Wie wird beispielsweise ein Imageschaden gemessen?
- Wie ist es zu bewerten, wenn gravierende Pflichtverletzungen aufge-
deckt werden, die nur zufllig nicht zu einem greren Schaden ge-
fhrt haben?
2. Insolvenz des Dienstleisters
- Das Recht auf Schadensersatzzahlungen ist wertlos, wenn diese die
Zahlungsfhigkeit des Dienstleisters bersteigen und dieser Insol-
venz anmeldet. Nachfolgend fallen dann mindestens Kosten fr den
Umzug zu einem neuen Dienstleister an.
3. Katastrophale Schden
- Eine Konventionalstrafe kommt zu spt, wenn der Auftraggeber
durch das Ausma des Schadensereignisses seiner Geschftsgrund-
lage beraubt wird und im schlimmsten Fall durch die Schadens-
folgen die Zahlungsunfhigkeit eintritt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. Beweisbarkeit
- Kann ein Schaden nachgewiesen bzw. der Verursacher berfhrt
werden (z. B. Nachweis von Spionage oder Manipulationen)?
Es ist immer zu bedenken, dass Schadensersatzzahlungen nur das aller-
letzte Mittel sind und nicht dazu fhren drfen, dass aus Kostengrnden
andere Sicherheitsmanahmen vernachlssigt werden. Sicherheit lsst sich
nicht mit juristischen Mitteln erzielen.
Mandantenfhigkeit
- Die notwendige Trennung von IT-Systemen und Anwendungen ver-
schiedener Kunden muss vereinbart werden.
- Es ist sicherzustellen, dass Probleme bei anderen Kunden nicht die
Ablufe und Systeme des Auftraggebers beeintrchtigen.
- Es ist sicherzustellen, dass Daten des Auftraggebers unter keinen
Umstnden anderen Kunden des Outsourcing-Dienstleisters zugng-
lich werden.
- Falls notwendig, muss die physikalische Trennung (d. h. dezidierte Hard-
ware) vereinbart werden.
- Falls notwendig, muss vereinbart werden, dass die vom Dienstleister einge-
setzten Mitarbeiter nicht fr andere Auftraggeber eingesetzt werden. Es
kann auch sinnvoll sein, diese auf Verschwiegenheit zu verpflichten, so
dass die eingesetzten Mitarbeiter nicht mit anderen Mitarbeitern des
Dienstleisters auftraggeberbezogene Informationen austauschen drfen.
nderungsmanagement und Testverfahren
- Es mssen Regelungen gefunden werden, die es ermglichen, dass der
Auftraggeber immer in der Lage ist, sich neuen Anforderungen anzupas-
sen. Dies gilt insbesondere, wenn beispielsweise gesetzliche Vorgaben ge-
ndert wurden. Es ist festzulegen, wie auf Systemerweiterungen, gestie-
gene Anforderungen oder knapp werdende Ressourcen reagiert wird.
- In diesem Zusammenhang ist auch die Betreuung und Weiterentwicklung
bereits vorhandener Systeme zu regeln. Nicht selten bernimmt der
Dienstleister selbstentwickelte Systeme oder Software vom Auftraggeber,
der damit die Fhigkeit verliert, diese in seinem Sinne weiterzuentwickeln.
Der Evolutionspfad von Systemen muss daher geregelt werden.
- Eine kontinuierliche Verbesserung der Dienstleistungsqualitt und des IT-
Sicherheitsniveaus sollte bereits in den SLAs festgeschrieben werden.
- Der Zeitrahmen fr die Behebung von Fehlern ist festzulegen.
- Testverfahren fr neue Soft- und Hardware sind zu vereinbaren. Dabei sind
folgende Punkte einzubeziehen:
- Regelungen fr Updates und Systemanpassungen
- Trennung von Test- und Produktionssystemen
- Zustndigkeiten bei der Erstellung von Testkonzepten
- Festlegen von zu benutzenden Testmodellen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zustndigkeiten bei Auftraggeber und Dienstleister bei der

Durchfhrung von Tests (z. B. Mitarbeit oder Hilfestellung des Auf-
traggebers, Abnahme- und Freigabeprozeduren)
- Informationspflicht und Absprache vor wichtigen Eingriffen ins
System (Negativbeispiel: Der Dienstleister spielt ein neues Betriebs-
system auf dem Server ein. Durch unerwartete Fehler dabei werden
wichtige Anwendungen gestrt, ohne dass der Auftraggeber sich
vorbereiten konnte.)
- Genehmigungsverfahren fr die Durchfhrung von Tests
- Festlegung zumutbarer Qualittseinbuen whrend der Testphase
(z. B. Verfgbarkeit)
Kontrollen
- Dienstleistungsqualitt und IT-Sicherheit mssen regelmig kontrolliert
werden. Der Auftraggeber muss die dazu notwendigen Auskunfts-, Ein-
sichts-, Zutritts- und Zugangsrechte besitzen. Wenn unabhngige Dritte
Audits oder Benchmark-Tests durchfhren sollen, muss dies bereits im
Vertrag geregelt sein.
- Allen Institutionen, die beim Auftraggeber Prfungen durchfhren mssen
(z. B. Aufsichtsbehrden) mssen auch beim Outsourcing-Dienstleister die
entsprechenden Kontrollmglichkeiten (z. B. Zutrittsrechte, Dateneinsicht)
eingerumt werden.
- Sind alle Vereinbarungen schriftlich fixiert?
- Enthlt der Vertrag eindeutige und quantifizierbare Leistungsbe-
schreibungen?
- Sind genaue Regelungen fr das Laufzeitende des Vertrages getroffen
worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.254 Erstellung eines IT-Sicherheitskonzepts fr das

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Administrator,
Leiter IT
Fr jedes Outsourcing-Vorhaben muss ein IT-Sicherheitskonzept existieren.
Dieses kann unter anderem auf Grundlage des IT-Grundschutzhandbuchs er-
stellt sein. Outsourcing-Projekte sind dadurch gekennzeichnet, dass sich viele
technische und organisatorische Details erst im Laufe der Planung und bei
Migration der Systeme ergeben. Das IT-Sicherheitskonzept, das nach Beauf-
tragung eines Dienstleisters erarbeitet wird, wird daher in den wenigsten
Fllen gleich vollstndig und endgltig sein und muss whrend der Migrati-
onsphase von allen Beteiligten stetig weiterentwickelt und konkretisiert
werden. Die Migrationsphase ist daher von entscheidender Bedeutung fr den
Erfolg des Gesamtprojektes und wird in Manahme M 2.255 Sichere
Migration bei Outsourcing-Vorhaben ausfhrlich beschrieben.
Generell unterscheiden sich IT-Sicherheitskonzepte fr Outsourcing-Vorhaben
nur wenig von IT-Sicherheitskonzepten fr selbstbetriebene IT-Systeme. Es
ergeben sich jedoch folgende Besonderheiten, die bercksichtigt werden
mssen:
- Am Outsourcing-Vorhaben sind aus technischer Sicht in der Regel drei
Parteien beteiligt:
1. Outsourcing-Auftraggeber
2. Outsourcing-Dienstleister
3. Netzprovider
Der Netzprovider stellt die Anbindung zwischen den Outsourcing-Parteien
bereit. Die Zustndigkeit fr die Netzanbindung fllt dabei in der Regel
dem Outsourcing-Dienstleister zu.
- Jeder Beteiligte muss ein eigenes IT-Sicherheitskonzept erstellen und um-
setzen, welches auch das spezielle Outsourcing-Vorhaben umfasst. Damit
sind IT-Sicherheitskonzepte erforderlich:
- fr den Einflussbereich des Outsourcing-Dienstleisters,
- fr den Einflussbereich des Auftraggebers sowie
- fr die Schnittstellen und die Kommunikation zwischen diesen Be-
reichen.
- Zustzlich zu den Einzelkonzepten ist ein IT-Sicherheitskonzept fr das
Gesamtsystem zu erstellen, welches die Sicherheit im Zusammenspiel der
Einzelsysteme betrachtet.
- Die verschiedenen Teil-Konzepte mssen zwischen Auftraggeber und
Dienstleistern abgestimmt werden. Dabei ist der Auftraggeber am IT-Si-
cherheitskonzept des Outsourcing-Dienstleisters nicht direkt beteiligt,
sollte aber in einem Audit prfen, ob es vorhanden und ausreichend ist. Fr
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
das Audit kann der Auftraggeber dabei auch auf externe Dritte zurckgrei-
fen.
Die in M 2.251 Festlegung der Sicherheitsanforderungen fr Outsourcing-
Vorhaben und M 2.253 Vertragsgestaltung mit dem Outsourcing-Dienstleister
genannten Sicherheitsanforderungen bilden dabei die Basis fr das IT-
Sicherheitskonzept. Aufbauend auf den dort beschriebenen grundlegenden
Anforderungen muss im IT-Sicherheitskonzept die detaillierte Ausgestaltung
erfolgen, wobei beispielsweise die Manahmen konkretisiert und
Ansprechpartner namentlich festgelegt werden.
Erfahrungsgem ist der bergang (Migration) von Aufgaben und IT-Syste- Sicherheitskonzept fr
Testphase
men vom Auftraggeber zum Outsourcing-Dienstleister eine Projektphase, in
der verstrkt mit Sicherheitsvorfllen zu rechnen ist. Aus diesem Grund ms-
sen im Sicherheitskonzept Regelungen und Manahmen zur Migration behan-
delt werden, die in M 2.255 Sichere Migration bei Outsourcing-Vorhaben
genauer behandelt werden.
Im Folgenden sind einige Aspekte und Themen aufgelistet, die im IT-Sicher-
heitskonzept im Detail beschrieben werden sollten. Da die Details eines IT-
Sicherheitskonzeptes direkt vom Outsourcing-Vorhaben abhngen, ist die
Liste als Anregung zu verstehen und erhebt keinen Anspruch auf Vollstndig-
keit. Neben einem berblick ber die Gefhrdungslage, die der Motivation
der Sicherheitsmanahmen dient, und den organisatorischen, infrastrukturellen
und personellen Sicherheitsmanahmen knnen Manahmen aus folgenden
Bereichen sinnvoll sein:
Organisation
- Umgang mit Daten und schtzenswerten Betriebsmitteln wie Druckerpa-
pier und Speichermedien, insbesondere Regelungen zum Anfertigen von
Kopien und Lschen/Vernichten
- Festlegung von Aktionen, fr die das "Vier-Augen-Prinzip" anzuwenden
ist
Hard-/Software
- Einsatz gehrteter Betriebssysteme, um Angriffe mglichst zu erschweren
- Einsatz von Intrusion-Detection-Systemen (IDS), um Angriffe frhzeitig
zu erkennen
- Einsatz von Datei-Integritt-Prfungssystemen, um Vernderungen z. B.
nach erfolgreichen Angriffen, zu erkennen
- Einsatz von Syslog- und Timeservern, um eine mglichst umfassende
Protokollierung zu ermglichen
- Einsatz kaskadierter Firewallsysteme zur Erhhung des Perimeterschutzes
auf Seiten des Dienstleisters
- sorgfltige Vergabe von Benutzer-Kennungen, Verbot von Gruppen-IDs
fr Personal des Dienstleisters
Kommunikation
- Absicherung der Kommunikation (z. B. durch Verschlsselung, elektroni-
sche Signatur) zwischen Dienstleister und Auftraggeber, um sensitive Da-
ten zu schtzen
- Authentisierungsmechanismen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Detailregelungen fr weitere Netzanbindungen (siehe M 5.87

Vereinbarung ber die Anbindung an Netze Dritter)
- Detailregelungen fr den Datenaustausch (siehe M 5.88 Vereinbarung ber
Datenaustausch mit Dritten).
Kontrollen und QS
- Detailregelungen (z. B. unangekndigte Kontrollen vor Ort, Zeitintervalle,
Zustndigkeiten, Detailgrad) fr Kontrollen und Messung von Sicherheit,
Dienstqualitt, Ablufen und organisatorische Regelungen
Notfallvorsorge
- Das Notfallvorsorgekonzept ist in M 6.83 Notfallvorsorge beim
Outsourcing beschrieben.
- Sind alle Teil-Sicherheitskonzepte (Auftraggeber, Dienstleister, Schnitt-
stelle) erstellt worden?
- Wurde die IT-Sicherheitskonzeption des Dienstleisters durch den
Auftraggeber oder unabhngige Dritte verifiziert?
- Sind alle IT-Sicherheitskonzepte gegeneinander abgestimmt und harmonie-
ren miteinander?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.255 Sichere Migration bei Outsourcing-Vorhaben

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Leiter IT,
Administrator
Nach Beauftragung des Outsourcing-Dienstleisters muss zunchst ein vorlu- Gefhrdungslage
figes IT-Sicherheitskonzept entwickelt werden, in dem auch die Test- und
Einfhrungsphase als Teilaspekt des Outsourcing-Vorhabens betrachtet wird.
Zum einen sind in dieser Phase zahlreiche Betriebsfremde involviert, zum
anderen mssen Ablufe etabliert, Aufgaben bertragen und Systeme neu
eingerichtet bzw. angepasst werden. Einem sorgfltigen Testbetrieb kommt
daher eine hohe Bedeutung zu. Besonders zu Testzwecken und in Phasen gro-
er Arbeitsbelastung werden gerne "flexible" und "unkomplizierte" Lsungen
gewhlt, die selten sehr sicher sind. Es ist daher beispielsweise sicherzustel-
len, dass produktive Daten nicht ohne besonderen Schutz als Testdaten ver-
wendet werden. Dies muss durch das IT-Sicherheitskonzept ausgeschlossen
werden.
Vor der Erstellung eines Migrationskonzepts als Teil des Sicherheitskonzeptes
fr ein Outsourcing-Vorhaben muss ein IT-Sicherheitsmanagement-Team
speziell fr die Migrationsphase beim Auftraggeber eingerichtet worden sein.
Dieses muss whrend der Migrationsphase auf Sicherheitsbelange achten und
durch geeignete Manahmen auch schon im Vorfeld der Migration dafr sor-
gen, dass ein sicherer IT-Betrieb whrend der Migration gewhrleistet ist. Die
Gre des IT-Sicherheitsmanagement-Teams hngt dabei von Art und Gre
des Outsourcing-Vorhabens ab, als Minimum kann es aus einem Sicherheits-
experten bestehen.
Dem IT-Sicherheitsmanagement-Team kommen dabei folgende Aufgaben zu, Aufgaben des IT-Sicher-
heitsmanagement-Teams
aus denen sich Regelungen und Vorgaben ableiten, die im Migrationskonzept
zu erfassen sind:
- Es ist ein gemischtes Team aus Mitarbeitern des Auftraggebers und des
Outsourcing-Dienstleisters zu bilden. Dieses kann auch durch externe Ex-
perten verstrkt werden, um spezielles Know-how verfgbar zu machen.
- Fr die Migrationsphase muss eine IT-Sicherheitskonzeption erstellt wer-
den.
- Die Verantwortlichkeiten und Hierarchien fr die Migrationsphase sind
festzulegen. Dabei ist es wichtig, dass klare Fhrungsstrukturen geschaffen
und auf beiden Seiten eindeutige Ansprechpartner definiert werden. Zu-
stzlich ist darauf zu achten, dass auf beiden Seiten Verantwortlichkeiten
auch auf hohen Ebenen definiert werden. Nur so kann sichergestellt wer-
den, dass im Zweifelsfall mit entsprechendem Nachdruck gehandelt wer-
den kann.
- Die erforderlichen Tests mssen geplant und durchgefhrt werden, Abnah-
meprozeduren erarbeitet und die Produktionseinfhrung geplant werden.
- Es sind geeignete interne Mitarbeiter fr die Test-, Einfhrungsphase und
den spteren Betrieb auszuwhlen. Vertraglich kann sich ein Auftraggeber
natrlich auch ein Mitspracherecht bei der Personalauswahl des Outsour-
cing-Dienstleisters einrumen lassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Mitarbeiter des Auftraggebers sind zum Verhalten whrend und nach
der Migrationsphase zu schulen. In der Regel sind die Mitarbeiter dabei mit
neuen und unbekannten Ansprechpartnern konfrontiert. Dies birgt die Ge-
fahr des Social Engineering (z. B. Anruf eines vermeintlichen Mitarbeiters
des Sicherheitsteams des Dienstleisters).
- Der Dienstleister muss die relevanten Ablufe, Applikationen und IT-Sys-
teme des Auftraggebers genau kennen lernen und dahingehend eingewie-
sen werden.
- Der strungsfreie Betrieb ist durch genaue Ressourcenplanung und Tests
sicherzustellen. Die produktiven Systeme drfen dabei nicht vernachlssigt
werden. Dazu ist im Vorfeld zu berprfen, ob die vorgesehenen Mitar-
beiter zur Verfgung stehen. Zustzlich mssen Strungen durch notwen-
dige Tests einkalkuliert werden.
- Anwendungen und IT-Systeme, die der Dienstleister bernehmen soll,
mssen ausreichend dokumentiert sein. Die Prfung der Dokumentation
auf Vollstndigkeit muss dabei ebenso bedacht werden wie das Anpassen
der vorhandenen Dokumentation auf die vernderten Randbedingungen
durch das Outsourcing-Vorhaben. Die Dokumentation neuer Systeme oder
Teilsysteme muss dabei ebenfalls sichergestellt sein.
- Whrend der Migration muss stndig berprft werden, ob die SLAs oder
die vorgesehenen IT-Sicherheitsmanahmen angepasst werden mssen.
In der Einfhrungsphase des Outsourcing-Vorhabens und der ersten Zeit des Notfallvorsorgekonzept
Betriebs muss dem Notfallkonzept besondere Aufmerksamkeit geschenkt
werden. Bis sich bei allen Beteiligten die notwendige Routine, beispielsweise
in der Behandlung von Fehlfunktionen und sicherheitsrelevanten Vorkomm-
nissen eingestellt hat, sind verstrkt Mitarbeiter zu Bereitschaftsdiensten zu
verpflichten.
Nach Abschluss der Migration muss sichergestellt werden, dass das IT-Si- Aktualisierung und Kon-
kretisierung des Sicher-
cherheitskonzept aktualisiert wird, da sich erfahrungsgem whrend der heitskonzepts
Migrationsphase immer nderungen ergeben. Dies bedeutet insbesondere:
- Alle Sicherheitsmanahmen mssen konkretisiert werden.
- Ansprechpartner und Zustndigkeiten werden mit Namen und notwendigen
Kontaktdaten (Telefon, Zeiten der Erreichbarkeit, Kodeworte) dokumen-
tiert.
- Die Systemkonfigurationen ist zu dokumentieren, wobei auch die
eingestellten sicherheitsrelevanten Parameter zu erfassen sind.
Schulung
- Das Personal ist durch Schulungsmanahmen auf den Regelbetrieb
vorzubereiten.
Als letzte Aufgabe muss das Outsourcing-Vorhaben nach der Migrationsphase
in den sicheren Regelbetrieb (siehe M 2.256 Planung und Aufrechterhaltung
der IT-Sicherheit im laufenden Outsourcing-Betrieb) berfhrt werden. Dabei
ist vor allem darauf zu achten, dass alle Ausnahmeregelungen, die whrend
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
der Migrationsphase notwendig waren, wie z. B. erweiterte Zugriffsrechte,

aufgehoben werden.
- Ist eine IT-Sicherheitskonzeption fr die Migrationsphase erarbeitet
worden?
- Enthlt das Migrationskonzept alle notwendigen sicherheitsrelevanten
Manahmen?
- Ist sichergestellt, dass alle Ausnahmeregelungen, die whrend der Migra-
tion notwendig sind, nach der Migration aufgehoben werden?
- Sind sowohl die Mitarbeiter des Auftraggebers als auch des Outsourcing-
Dienstleisters ausreichend auf die Migration vorbereitet worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.256 Planung und Aufrechterhaltung der IT-

Sicherheit im laufenden Outsourcing-Betrieb
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Leiter IT,
Administrator
Nachdem ein Outsourcing-Vorhaben umgesetzt wurde, muss die IT-Sicherheit
auch im laufenden Betrieb gewhrleistet werden. Dazu ist fr das Outsour-
cing-Vorhaben ein Betriebskonzept zu planen, in dem auch die Sicherheitsas-
pekte bercksichtigt werden. Dabei unterscheiden sich die IT-bezogenen Ein-
zelaufgaben generell nicht von denen, die zu planen und durchzufhren sind,
wenn kein Outsourcing betrieben wird (siehe M 2.199 Aufrechterhaltung der
IT-Sicherheit).
Besonderheiten ergeben sich jedoch dadurch, dass die Aufgaben auf mehrere
Parteien verteilt sind und daher zustzliche Aufgaben (z. B. Abstimmungen
und Kontrollen) anfallen. Diese sind unter anderem:
- Dokumentationen und Richtlinien mssen regelmig aktualisiert werden.
- Die geltenden Sicherheitskonzepte aller Beteiligten mssen daraufhin ge- Aktualitt der Sicher-
heitskonzepte
prft werden, ob sie noch aufeinander abgestimmt sind und das ge-
wnschte Sicherheitsniveau gewhrleisten. Insbesondere sollte der Out-
sourcing-Dienstleister den Auftraggeber ber wichtige nderungen in sei-
nem Einflussbereich informieren.
- Regelmige Kontrollen zu folgenden Aspekten sind durchzufhren: Kontrollen
- Durchfhrung der vereinbarten Audits

- Umsetzungsstand der vereinbarten IT-Sicherheitsmanahmen
- Wartungszustand von Systemen und Anwendungen
- Rechtezuweisung durch den Dienstleister (Missbrauch von Rechten)
- Einsatz von Mitarbeitern, die dem Auftraggeber nicht gemeldet wur-
den, z. B. bei Vertretungen
- Performance, Verfgbarkeit, Qualittsniveau
- Datensicherung
- Regelmige Abstimmungsrunden zu folgenden Punkten sind abzuhalten: Kommunikation
- Informationen mssen zwischen den Partnern ausgetauscht werden

(z. B. Personalnachrichten, organisatorische Regelungen, Gesetzes-
nderungen, geplante Projekte, vorgesehene Tests und Systemnde-
rungen, die zu Beeintrchtigungen der Dienstleistungsqualitt fhren
knnen).
- Probleme mssen identifiziert und analysiert werden.
- Wichtig sind gegenseitiges Feedback und das Aufspren von
Verbesserungspotentialen. Zur Motivation der Mitarbeiter knnen
besonders positive Beispiele einer gelungenen Kooperation darge-
stellt werden.
- nderungsmanagement: nderungswnsche (Hardware, Software,
Ausweitung des Dienstleistungsportfolios, gestiegener Ressourcen-
bedarf etc.) sollten frhzeitig besprochen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Es mssen regelmige bungen und Tests zu folgenden Themen durchge- Tests und bungen
fhrt werden:
- Reaktion auf Systemausflle (Teilausfall, Totalausfall)
- Wiedereinspielen von Datensicherungen
- Beherrschung von Sicherheitsvorfllen
- Wurde ein Betriebskonzept fr das Outsourcing-Vorhaben festgelegt?
- Enthlt das Betriebskonzept Verfahren und Manahmen, die das ge-
wnschte Sicherheitsniveau im laufenden Betrieb sicher stellen?
- Werden regelmig die notwendigen Kontrollen durchgefhrt?
- Sind alle Sicherheitskonzepte noch aktuell?
- Gibt es eine regelmige Kommunikation zwischen den Vertragspartnern?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.257 berwachung der Speicherressourcen von

Archivmedien
Verantwortlich fr Initiierung: Leiter IT, Archivverwalter
Verantwortlich fr Umsetzung: Leiter IT, Archivverwalter, Administrator
Die auf den Archivmedien vorhandene, freie Speicherkapazitt ist kontinuier- Benachrichtigung und
Alarmierung
lich zu berwachen. Wenn die freie Speicherkapazitt unter einen festzu-
legenden Schwellwert sinkt, sollte eine Benachrichtigung des Administrators
sowie gegebenenfalls eine Signalisierung an eine Systemmanagement-Um-
gebung erfolgen. Sinkt die freie Speicherkapazitt weiter unter einen
kritischen Grenzwert, sollte eine Alarmierung ausgelst werden.
Bei der Alarmierung ist besonders darauf zu achten, dass sie rollenbezogen
erfolgt, das heit unabhngig von konkreten Personen. Damit ist sichergestellt,
dass auch im Krankheitsfall oder bei Urlaub Alarmierungen wahrgenommen
werden.
Der Schwellwert, der kritische Grenzwert sowie die Eskalationsprozeduren Schwellwert und Grenz-
wert festlegen
und -wege sind organisationsspezifisch festzulegen.
Fr die Festlegung der Grenzwerte mssen die verwendeten Archivmedien
und das durchschnittliche Volumen der zu archivierenden Daten zugrunde
gelegt werden. Nach Auslsen des kritischen Alarms muss gewhrleistet sein,
dass fr eine hinreichende Zeit weiterhin das durchschnittliche Datenauf-
kommen archiviert werden kann. Typischerweise wird fr den Schwellwert
eine Restkapazitt von 15% der Gesamtkapazitt des Speichermediums und
fr den kritischen Grenzwert eine Restkapazitt von 10% zugrunde gelegt.
Um etwaige Lieferengpsse bei Speichermedien zu berbrcken, sollte eine leere Archivmedien
vorhalten
ausreichende Zahl leerer Archivmedien an einem bekannten Ort gelagert
werden. Dabei mssen die klimatischen und physikalischen Lagerbe-
dingungen eingehalten werden (siehe M 1.60 Geeignete Lagerung von
Archivmedien).
Fr den Fall der Alarmierung ist zu dokumentieren, in welcher Weise und in
welchem Zeitraum eine Reaktion auf die Alarme erfolgen soll. Dies ist z. B. in
Service Level Agreements (SLAs) festzulegen, falls der Betrieb des Archiv-
systems durch Dritte erfolgt.
Neben dem Speicherplatz mssen ggf. noch betriebssystem- oder anwen-
dungsspezifische Restriktionen berwacht werden. Die entsprechenden Pro-
grammdokumentationen mssen daraufhin geprft werden. In Zweifelsfllen
oder bei fehlenden Angaben in der Dokumentation sollte der jeweilige Her-
steller zu Rate gezogen werden. Beispielsweise knnen die Anzahl der maxi-
mal zugelassenen Dateien pro Verzeichnis oder die maximal erlaubten Daten-
bankeintrge berschritten werden, so dass keine weiteren Daten auf dem
Speichermedium angelegt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist eine kontinuierliche berwachung des verbleibenden Speicherplatzes
gewhrleistet?
- Sind die Grenzwerte fr eine Alarmierung festgelegt und dokumentiert?
- Sind leere Archivmedien in gengender Stckzahl an einem bekannten Ort
gelagert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.258 Konsistente Indizierung von Dokumenten bei

der Archivierung
Beim Betrieb eines Archivs ist es wichtig, alle abgelegten Dokumente und
Datenstze eindeutig zu referenzieren, um sie bei spteren Archivanfragen
korrekt wiederfinden zu knnen. Zustzlich bieten Archivsysteme die Mg-
lichkeit von Suchanfragen. Da eine Volltextsuche abhngig von Art und Um-
fang der archivierten Daten sehr lange dauern kann, speichern Archivsysteme
zu jedem Dokument einen separaten Datensatz mit Indexangaben in einer
eigenen Suchdatenbank. Struktur und Umfang der Indexangaben sind in der
Regel konfigurierbar und sollten die folgenden Eigenschaften aufweisen:
- Eindeutigkeit: Die Dokumentenbezeichner mssen eindeutig sein.
- Untersttzung zu erwartender Suchanfragen: Durch die Kontextangaben
sollen sptere Suchanfragen beschleunigt werden. Da der sptere Such-
kontext nicht feststeht, kann im Vorfeld nur eine Abschtzung spterer
Suchanfragen vorgenommen und versucht werden, die Kontextangaben so
aussagekrftig wie mglich zu gestalten.
- Geringer Umfang: Ein geringer Umfang an Indexdaten beschleunigt
sptere Suchanfragen, jedoch kann ein zu geringer Umfang der Indexdaten
Suchanfragen behindern bzw. das Auffinden von Dokumenten erschweren.
Der Umfang der Kontextangaben ist letztlich in Abhngigkeit vom er-
warteten Datenvolumen festzulegen.
Diese Parameter mssen grundstzlich vor der Inbetriebnahme des Archivs
festgelegt werden. Trotzdem kann es im Laufe der Zeit notwendig werden, die
Eigenschaften zu ndern. Je nach Umfang und Art der nderung der Index-
daten kann dies eine sehr aufwndige Neuindizierung der Archivdatenbe-
stnde erforderlich machen.
Der konkrete Kontext fr einzelne zu archivierende Dokumente kann auf
unterschiedliche Art und Weise erzeugt werden. Drei Verfahren werden dabei
unterschieden:
- manuelle Erstellung:
Auf der Ebene des Dokumentenmanagementsystems werden Indexangaben
zu jedem Dokument ber eine Eingabemaske manuell erzeugt. Hierdurch
besteht besonders bei groen Datenmengen die Gefahr, dass inkonsistente
Indexangaben erfasst werden.
- halbautomatische Erzeugung:
Diese Verfahren automatisieren die Vergabe von Indexdaten, gestatten je-
doch eine manuelle Kontrolle und Korrektur.
- vollautomatische Erzeugung:
Hierbei werden Dokumentindizes vollautomatisch ohne manuelle Ein-
griffsmglichkeit vergeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Wahl des Verfahrens ist abhngig vom erwarteten Datenvolumen. Werden
in unregelmigen Abstnden einzelne Dokumente archiviert, ist ein manu-
elles Verfahren auf der Grundlage konkreter Vorgaben zur Erstellung eines
Kontextes ausreichend.
Werden regelmig groe Datenvolumen archiviert, sollte ein halbautoma-
tisches Verfahren zur Erzeugung der Indexdaten gewhlt werden. Hier besteht
die Mglichkeit, diese Informationen manuell zu kontrollieren und zu korri-
gieren, bevor Dokument und Dokumentindex archiviert werden und dann ge-
gebenenfalls nicht mehr nachtrglich gendert werden knnen.
Bei der vollautomatischen Erzeugung der Indexdaten knnen Fehler nicht
erkannt bzw. korrigiert werden. Eine eventuelle Fehlzuordnung von zu archi-
vierenden Dokumenten, z. B. zu Geschftsprozessen, kann dann nicht erkannt
oder ausgeschlossen werden. Dieses Verfahren sollte deshalb nur dann ange-
wandt werden, wenn alle Dokumente so strukturiert sind, dass alle Indexdaten
in jedem Fall zweifelsfrei und zuverlssig extrahiert werden knnen.
- Wie gro ist der Benutzerkreis und wie hoch ist das Datenaufkommen, so
dass eine manuelle Indizierung vertretbar ist?
- Sind Kontrollen der vergebenen Indizes mglich?
- Ist die Struktur der Indizierung dokumentiert und kommuniziert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.259 Einfhrung eines bergeordneten

Dokumentenmanagements
Bei der elektronischen Archivierung mssen alle archivierten Dokumente
eindeutig identifiziert und reproduziert werden knnen. Da dabei in der Regel
groe Datenbestnde zu verwalten sind, wird der Einsatz eines bergeordneten
Dokumentenmanagement-Systems (DMS), auch fr kleine und mittlere Be-
hrden bzw. Unternehmen, empfohlen.
Dokumentenmanagement-System
Ein Dokumentenmanagement-System (DMS) bildet die Schnittstelle zwischen
Benutzer (-programmen) und Archivsystem und sorgt fr eine konsistente
Verwaltung, Versionierung und Zuordnung von elektronischen Dokumenten.
Das DMS bernimmt regelmig auch die Pflege der Index-Datenbank, in der Pflege der Index-
Datenbank
die zu den elektronischen Dokumenten archivierte Kontextinformation ver-
waltet und eventuell um DMS-Bestandteile ergnzt wird.
Unterschieden werden dabei zum einen Systeme, die neben den Indizes auch
die Dokumente selbst in einer Datenbank ablegen, und zum anderen Systeme,
die in ihrer Datenbank ausschlielich Referenzdaten auf die eigentlichen
Dokumente im jeweiligen Speichersystem ablegen. Die erstgenannten
Systeme sind allerdings durch die Kapazitt der Datenbank eingeschrnkt und
eignen sich damit nicht fr die Archivierung groer Datenmengen.
Darber hinaus muss ein Dokumentenmanagement-System die Festlegung Zugriffsrechte und
Klassifikation
von Zugriffsberechtigungen zu den archivierten Dokumenten sowie zur Index-
Datenbank ermglichen. Das DMS sollte auch eine Klassifikation von Doku-
menten untersttzen. Es sollten Profile und Referenztabellen angelegt werden
knnen, anhand derer Dokumente klassifiziert und verschlagwortet werden.
Die Eigenschaften des DMS mssen langfristig gewhrleisten, dass die archi-
vierten Dokumente eindeutig identifiziert, geschtzt und reproduziert werden
knnen.
Organisatorische Einbettung
Dokumentenmanagement-Systeme mssen in geeigneter Weise eingesetzt und
in die Organisation eingebettet werden. Hierzu sind entsprechende Organisa-
tionsprozesse zu definieren, zu dokumentieren und in der Behrde bzw. im
Unternehmen umzusetzen.
Regelungsbedarf besteht unter anderem hinsichtlich
- des Einstellens von Dokumenten ins DMS,
- der Nutzung des DMS beim Umgang mit Dokumenten,
- der Verantwortlichkeiten fr Nutzung und Betrieb des DMS,
- der Rechtevergabe und der Zustndigkeit hierfr sowie
- der Anforderungen an den Betrieb des DMS (Service Level Agreements).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Letztlich soll durch die Organisationsprozesse sichergestellt werden, dass das

Dokumentenmanagement auch in der vorgesehenen Weise benutzt und nicht
etwa umgangen wird. Nur so ist eine vollstndige und konsistente Archi-
vierung der in der Organisation genutzten elektronischen Dokumente und
Informationen mglich.
Standardisierung
Die am Markt angebotenen Dokumentenmanagement- und Archivsysteme
sind nicht alle miteinander kompatibel. Dies ist sowohl durch die verwendete
Technologie als auch durch die verwendeten Medien- und Speicherformate
verursacht.
Um diese Probleme zu beheben, arbeiten die am Markt operierenden DMS-
Hersteller in verschiedenen Gremien an der Vereinheitlichung der dem
Dokumentenmanagement zugrundeliegenden Technologien zum Speichern
und Wiedergewinnen von Dokumenten. Bei der Auswahl des DMS sollten die
betreffenden Standards bercksichtigt werden, damit DMS- und Archivkom-
ponenten langfristig vertrglich sind.
Die wichtigsten Gruppen bzw. Standards sind:
- ODMA
Innerhalb der AIIM (Association for Information and Image Management) Schnittstelle zu
Anwendungen
ist die ODMA-Gruppe (Open Document Management API) als Standardi-
sierungsgremium ttig. ODMA bezeichnet eine standardisierte Schnittstelle
zwischen dem Dokumentenmanagement-System und den Benutzeran-
wendungen. Es vereinfacht an dieser Stelle die Einbindung der Anwen-
dungen.
Die meisten Anbieter untersttzen diesen Standard.
- DMA
Die DMA (Document Management Alliance) ist als Projektgruppe inner- Integration
verschiedener DMS
halb der AIIM gegrndet worden. Sie ist aus einem Zusammenschluss von
drei anderen Standardisierungsgremien, die ebenfalls im Umkreis der DMS
gearbeitet haben, hervor gegangen:
- ISO-Gruppe Document Filing and Retrieval - ISO 10166
- Document Enabled Networking
- Shamrock Document Management Coalition
Die DMA etabliert einen Standard, mit dessen Hilfe Dokumentensamm-
lungen und Dokumentenmanagement-Software ber verschiedene Platt-
formen und Systeme hinweg einfach integriert werden knnen.
Fr den Benutzer ergibt sich so eine einheitliche Sicht auf alle Dokument-
typen, unabhngig vom Ort der Ablage oder der Erstellung.
Nahezu alle fhrenden Hersteller halten diesen Standard ein. Im konkreten
Einzelfall ist die Einhaltung der Standards allerdings zu prfen.
- WfMC
Die WfMC (Workflow Management Coalition, Belgien) arbeitet als Stan-
dardisierungsorgan im Bereich der Workflows.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Ziel ist, Software-Spezifikationen zu erstellen, mit deren Hilfe ein- Zusammenwirken von
heitliche Voraussetzungen fr das Zusammenwirken unterschiedlichster Workflow-Produkten
Workflow-Produkte und -Komponenten in unterschiedlichsten Umge-
bungen geschaffen werden.
Fast alle namhaften Hersteller arbeiten in diesem Gremium mit.
- Ist berprft worden, ob der Einsatz eines Dokumentenmanagement-
Systems sinnvoll ist?
- Ist die Verantwortung fr Betrieb und Nutzung des DMS dokumentiert und
bekannt?
- Ist die Nutzung des DMS in der Organisation verpflichtend geregelt und
dokumentiert?
- Untersttzt das DMS die Vergabe und Kontrolle von Rollen und
Zugriffsberechtigungen?
- Untersttzt das eingesetzte DMS die einschlgigen Standards?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.260 Regelmige Revision des

Archivierungsprozesses
Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Revisor
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Revisor, Archiv-
verwalter
Der Prozess der Archivierung ist regelmig einer Revision zu unterziehen,
um seine Korrektheit und Ordnungsmigkeit zu prfen und daraus die Kor-
rektheit und Authentizitt der im Archivsystem abgelegten Dokumente abzu-
leiten.
Hierzu ist eine geeignete Vorgehensweise fr die Revision entsprechend des
in M 2.243 Entwicklung des Archivierungskonzepts beschriebenen Konzeptes
zu entwickeln und in Form einer Checkliste zu dokumentieren.
Diese Checkliste sollte mindestens die folgenden Punkte umfassen:
Fragen zu Verantwortlichkeiten
- Sind die verantwortlichen Personen benannt und in ihre Aufgaben einge-
wiesen worden? Ist dies dokumentiert?
- Bestehen Vertretungsregelungen fr alle verantwortlichen Personen?
Fragen zum Organisationsprozess
- Bestehen organisationsweite Regelungen zum Einsatz elektronischer
Archivierung?
- Ist organisationsweit geregelt und dokumentiert, welche Dokumente zu
archivieren sind? Ist diese Regelung umfassend und vollstndig?
- Sind die Sicherheitsanforderungen an die Dokumente dokumentiert?
- Werden die organisationsweiten Regelungen regelmig an aktuelle Ent-
wicklungen angepasst?
- Werden alle Anpassungen der Regelungen ordnungsgem dokumentiert
und archiviert?
Fragen zum Einsatz der Archivierung
- Bestehen eindeutige Regelungen, welche Dokumente zu archivieren sind?
- Bestehen dokumentierte Regelungen, welche Kontextangaben zu archi-
vierten Dokumenten vergeben werden, etwa die Angabe von Dokument-
kategorien?
- Werden die zu archivierenden Dokumente vollstndig und reproduzierbar
archiviert?
- Werden die Anforderungen an die Vertraulichkeit der zu archivierenden
Dokumente eingehalten?
- Werden die Anforderungen an die Authentizitt der zu archivierenden Do-
kumente eingehalten?
- Werden die Anforderungen an die Integritt der zu archivierenden Doku-
mente eingehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die Anforderungen an die Verfgbarkeit der zu archivierenden

Dokumente eingehalten?
- Werden die rechtlichen Vorgaben an die Archivierung eingehalten?
- Sind alle Benutzer und Administratoren entsprechend ihrer Rollen und
Aufgaben geschult und eingewiesen? Ist dies dokumentiert?
Fragen zur Redundanz der Archivdaten
- Werden Archivdaten ausreichend redundant gespeichert und aufbewahrt,
z. B. durch den Einsatz redundanter Archivsysteme oder alternativer
Backup-Medien?
- Erfolgt eine regelmige Datensicherung der Archivsysteme sowie gegebe-
nenfalls der Archivdaten?
- Sind die Datensicherungen den Vorgaben entsprechend durchgefhrt
worden?
- Sind die Datensicherungen der Archivdaten vollstndig und lesbar?
- Gab es seit der letzten Revision Datenverluste?
Wenn ja, wie hufig und wie schwer waren diese Vorflle?
- Traten Fehler bei der Rekonstruktion archivierter Dokumente auf?
Wenn ja, wie hufig waren diese Vorflle und waren die Fehler behebbar?
Fragen zur Administration
- Wird der geforderte Refresh-Zyklus der Archivmedien eingehalten?
- Werden nicht mehr bentigte, beschriebene Archivmedien ordnungsgem
vernichtet und entsorgt?
- Werden Lesegerte und Speichermedien im geforderten Mae vor-
gehalten?
Technische Beurteilung des Archivsystems
Die Revision sollte auch eine technische Neubewertung der Archivsystem-
Komponenten und der verwendeten Datenformate beinhalten. Hierdurch soll
gewhrleistet werden, dass technische Weiterentwicklungen frhzeitig erkannt
werden und technische nderungen am Archivsystem selbst durch den Her-
steller im Vorfeld bekannt sind.
Bei dieser Prfung kann sich herausstellen, dass technische Komponenten des
Archivsystems gendert werden mssen. Dann muss sichergestellt werden,
dass ausgetauschte Komponenten, z. B. Laufwerke, Speichermedien, Betriebs-
software, einwandfrei mit allen anderen Komponenten unter Beibehaltung der
fr den Betrieb notwendigen Funktionalitt zusammenarbeiten.
Die Prfergebnisse der Revisionen sind ebenfalls gem den Anforderungen
an den Archivierungsprozess selbst zu archivieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Findet eine regelmige Revision des Archivierungsprozesses statt?
- Ist die Vorgehensweise fr Revisionen dokumentiert?
- Werden die Ergebnisse der Revision ebenfalls archiviert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.261 Regelmige Marktbeobachtung von

Archivsystemen
Verantwortlich fr Umsetzung: Leiter IT, Archivverwalter
Die geforderten Aufbewahrungszeiten fr Archivdaten liegen normalerweise
um ein Vielfaches hher als die durchschnittliche Lebenserwartung einzelner
Bestandteile eines elektronischen Archivs. Dies betrifft sowohl Hardware- als
auch Software-Komponenten.
Um den vollen Funktionsumfang ber den gesamten Zeitraum der Archi-
vierung dennoch sicher zu stellen, ist davon auszugehen, dass einzelne Hard-
ware-Komponenten, ganze Baugruppen oder auch Software-Komponenten
unter Umstnden mehrfach ausgetauscht werden mssen.
Eine wichtige Voraussetzung dazu ist eine regelmige Marktbeobachtung.
Diese dient dazu, sich abzeichnende Vernderungen rechtzeitig zu regist-
rieren. Solche Vernderungen knnen z. B. sein:
- nderung eines alten Standards oder Verabschiedung eines neuen
Standards bei Speicherformaten,
- Vernderungen beim Hersteller des genutzten Archivsystems oder seiner
Speicherkomponenten (Wechsel auf neue Systemplattformen, Beendigung
einer Produktreihe und Einstellung des Supports, Einstellung der Produk-
tion von Speichermedien, Insolvenz eines Herstellers),
- Bekanntwerden von Sicherheitslcken oder Schwachstellen, z. B. bei
eingesetzten Verschlsselungsalgorithmen.
Es wird empfohlen, einen regelmigen Kontakt zu allen beteiligten Her- Kontakt zu Herstellern
aufbauen
stellern aufzubauen, beispielsweise durch die Teilnahme an Informationsforen,
z. B. Newsgroups und Mailinglisten, in denen aktuelle Informationen ber das
eingesetzte Archivsystem regelmig versandt werden.
Es sollte mindestens eine Person dafr verantwortlich sein, die oben beschrie- Informationen sammeln
und auswerten
benen Informationen regelmig aufzunehmen, nach ihrer Bedeutung fr das
verwendete Archivsystem auszuwerten und gegebenenfalls notwendige Akti-
vitten zu empfehlen. Hierzu muss festgelegt werden, wie eine eventuell er-
forderliche Migration des Systems eingeleitet wird. Die hier gewonnenen
Informationen flieen in die regelmige Revision des Archivierungspro-
zesses (siehe M 2.260 Regelmige Revision des Archivierungsprozesses) ein.
- Ist eine verantwortliche Person fr die Informationsbeschaffung benannt?
- Ist die regelmige Teilnahme an entsprechenden Informationsforen ge-
sichert?
- Ist festgelegt, wie eine Migration des Archivsystems eingeleitet wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.262 Regelung der Nutzung von Archivsystemen

Verantwortlich fr Initiierung: Leiter IT, Archivver
Durch entsprechende Regelungen ist sicherzustellen, dass das Archivsystem in
der im Archivierungskonzept (siehe Manahme M 2.243 Entwicklung des
Archivierungskonzepts) vorgesehenen Weise genutzt wird. Hierzu sollten
Richtlinien fr die Benutzung und die Administration des Archivsystems er-
stellt werden. Die Richtlinien sind entsprechend den organisatorischen Ge-
pflogenheiten in der jeweiligen Institution zu verankern und bekanntzugeben.
Beim Einsatz externer Personen sind diese auf die Beachtung dieser Richt-
linien zu verpflichten.
Die Administrationsrichtlinien sollten mindestens die folgenden Punkte Richtlinien fr die
Administration
umfassen:
- Festlegung der Verantwortung fr Betrieb und Administration des Archiv-
systems,
- Vereinbarungen ber Leistungsparameter (Service Level Agreements)
beim Betrieb des Archivsystems, insbesondere wenn die Administration
oder der Betrieb durch Externe erfolgen soll,
- Modalitten der Vergabe von Zutritts- und Zugriffsrechten zu den Kompo-
nenten des Archivsystems und den Archivmedien,
- Modalitten der Vergabe von Zugangsrechten zu den vom Archiv bereitge-
stellten Diensten,
- Regelungen zum Umgang mit archivierten Daten und Archivmedien,
- berwachung des Archivsystems und der Umgebungsbedingungen fr das
Archivsystem und die verwendeten Archivmedien,
- Regelung zur Datensicherung der Software-Komponenten des Archiv-
systems selbst,
- Protokollierung der Aktivitten am Archivsystem.
Die Benutzerrichtlinien sollten mindestens umfassen: Richtlinien fr Benutzer
- Erluterung der Zielsetzung der elektronischen Archivierung und der

Archivierungsfristen fr Dokumente,
- Festlegung der Verantwortung fr Arbeiten mit dem Archivsystem,
- Festlegung, in welchem Umfang die Nutzung des Archivsystems ver-
pflichtend ist,
- Modalitten der Vergabe von Zugangsrechten zu den vom Archiv bereitge-
stellten Diensten,
- Schulungsanforderungen an Benutzer, damit sie zur Nutzung des Archiv-
systems freigeschaltet werden drfen,
- Regelung der Vergabe von Kontextinformationen zu den archivierten
Dokumenten, siehe auch M 2.258 Konsistente Indizierung von Dokumenten
bei der Archivierung,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Verpflichtung zum sorgfltigen Umgang mit recherchierten Dokumenten

unter Beachtung der eventuellen Zweckbindung der Informationen,
- Regelung zum Umgang mit Dokumenten nach Ablauf der festgelegten
Archivierungsdauer,
- Regelung, dass Daten, deren Lschung nach einem festgelegten Zeitraum
vorgesehen ist, nicht mehr verwendet werden drfen, obwohl sie unter
Umstnden aus technischen Grnden noch vorhanden sind,
- Regelung zum Umgang mit personenbezogenen Daten,
- Nutzung der vom Archivsystem bereitgestellten Schutzmechanismen, um
eine sptere Prfung der Integritt und Authentizitt der archivierten
Dokumente zu ermglichen, sowie zur Gewhrleistung der erforderlichen
Vertraulichkeit,
- Verpflichtung zur berprfung der Integritt und Authentizitt recher-
chierter Dokumente vor der Weiterverwendung,
- Umgang mit Daten, deren Integritt sich nicht nachweisen lsst, z. B. bei
fehlgeschlagener Signaturprfung,
- Protokollierung der Benutzeraktivitten am Archivsystem,
- Abrechnungsmodalitten bei Nutzung des Archivsystems durch mehrere
Organisationseinheiten.
Die Regelungen sowie deren Kenntnisnahme durch die Administratoren und
Benutzer des Archivsystems sind zu dokumentieren.
- Sind Regelungen zur Nutzung des Archivsystems dokumentiert und in der
Behrde bzw. im Unternehmen verpflichtend umgesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.263 Regelmige Aufbereitung von archivierten

Datenbestnden
Fr eine ordnungsgeme Archivierung muss ber den gesamten
Archivierungszeitraum hinweg sichergestellt werden, dass
- das benutzte Datenformat dem Stand der Technik entspricht und von den
verwendeten Anwendungen derzeit und zuknftig verarbeitet werden kann,
- die gespeicherten Daten auch zuknftig lesbar sind und unter Beibehaltung
der Semantik und der Nachweiskraft reproduziert werden knnen,
- das benutzte Dateisystem auf dem Speichermedium von allen beteiligten
Komponenten verarbeitet werden kann,
- die Speichermedien jederzeit physikalisch einwandfrei gelesen werden
knnen,
- die verwendeten kryptographischen Verfahren zur Verschlsselung und zur
digitalen Signatur dem Stand der Technik entsprechen und
- fr alle Komponenten der Speichereinheit (Speichermedien, Laufwerke,
Jukeboxen sowie die Steuersoftware) Ersatz- und Wartungsmglichkeiten
bestehen.
Ist abzusehen, dass eine der geforderten Eigenschaften in naher Zukunft nicht
mehr gegeben ist, mssen die betroffenen Systeme ausgetauscht werden.
Dabei ist zu bercksichtigen, dass unter Umstnden eine erhebliche Menge an
archivierten Daten auf neue Datentrger kopiert werden muss.
Fr die Aufbereitung verschlsselter oder signierter Dokumente wird auf die Kompatibilitt testen
Manahmen M 2.264 Regelmige Aufbereitung von verschlsselten Daten
bei der Archivierung und M 2.265 Geeigneter Einsatz digitaler Signaturen bei
der Archivierung verwiesen.
- Gibt es Dokumentationen ber die Haltbarkeit der Datentrger und daraus
resultierende Arbeitsanweisen, wann Daten auf neue Datentrger
umkopiert werden mssen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.264 Regelmige Aufbereitung von verschlsselten

Daten bei der Archivierung
Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsmanagement,
Administrator
Kryptographische Verfahren unterliegen einem technologischen Alterungs-
prozess, da im Laufe der Zeit durch mathematische oder technische Weiter-
entwicklungen Schwchen aufgezeigt werden knnen, die bei deren Auswahl
noch nicht bekannt oder relevant waren.
Bei Aufbewahrungsfristen von 10 Jahren und lnger ist davon auszugehen,
dass verschlsselte oder signierte Daten wiederholt mit neuen Schlsseln und
gegebenenfalls auf Basis neuer Algorithmen umgeschlsselt werden mssen,
um die Vertraulichkeit bzw. Integritt der Daten weiterhin zu schtzen.
Um beurteilen zu knnen, ob ein Algorithmus weiterhin zuverlssig und aus- kryptographische Ent-
wicklung beobachten
reichend sicher ist, sollten die Entwicklungen auf dem Gebiet der Krypto-
graphie kontinuierlich beobachtet werden. Darber hinaus sind einschlgige
Informationsquellen laufend dahingehend auszuwerten, ob Mglichkeiten
bekannt werden, bestehende Verfahren zu kompromittieren.
Wenn die verwendeten Kryptoverfahren nicht mehr zeitgem sind und daher rechtzeitig neu ver-
schlsseln bzw.
die Vertraulichkeit oder Integritt der verschlsselten Daten nicht mehr signieren
sichergestellt werden kann, mssen die Daten neu verschlsselt bzw. signiert
werden.
Folgende Aspekte sind bei der Neuverschlsselung zu beachten (siehe auch
Kapitel 3.7 Kryptokonzept):
- Es muss ein nach aktuellen Mastben sicherer Kryptoalgorithmus ver-
wendet werden, von dem angenommen werden kann, dass er fr einen
langen Zeitraum sicher ist.
- Es muss ein Verfahren zur Verschlsselung und Schlsselverteilung ge-
whlt werden, das den Anforderungen der Archivierungsanwendung ge-
recht wird.
- Die neu erzeugten Schlssel mssen auf sicherem Weg an die Benutzer des
Kryptoverfahrens verteilt werden.
- Eine Authentisierung der Kryptoschlssel (z. B. durch ein elektronisches
Zertifikat) ist vorzusehen.
- Die Ursprungsdatei muss nach erfolgreicher Verschlsselung vernichtet
werden, bei WORM-Medien der gesamte Datentrger.
- Wenn Datentrger im Rahmen der Neuverschlsselung ausgesondert
werden, sind auch diese sicher zu entsorgen.
- Neben den Haupt-Datentrgern sind auch Backup-Datentrger sicher zu
entsorgen bzw. alte Dateien sicher zu lschen.
Die Verteilung der Schlssel kann auf zwei unterschiedlichen Wegen er-
folgen: Falls die Schlsselerzeugung durch eine unabhngige, vertrauens-
wrdige Instanz erfolgen soll, ist sicherzustellen, dass die neuen Schlssel ver-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
traulich und unverflscht an den ursprnglichen Eigentmer des Dokuments

bertragen werden.
Bei der Nutzung asymmetrischer Verfahren zur Verschlsselung kann der
Dokumenteneigentmer alternativ auf Verlangen selbst ein neues Schlssel-
paar erzeugen und den ffentlichen Schlssel der archivierenden Instanz mit-
teilen.
In jedem Fall ist zu bercksichtigen, dass eine derartige Neuverschlsselung zeitlicher Vorlauf und
Aufwand
einen gewissen Vorlauf braucht: Die Eigentmer der Daten bzw. der Schlssel
mssen benachrichtigt, die notwendigen Schlssel generiert und verteilt
werden. Bei einer groen Anzahl verschiedener Eigentmer und groen
Datenmengen ist ein entsprechender Aufwand einzukalkulieren.
Bei der Auswahl eines mglichst langfristig zuverlssigen neuen Kryptover-
fahrens sollte ein aktueller und anerkannter sicherer Algorithmus ausgewhlt
werden. Ist zum derzeit verwendeten Algorithmus keine wirklich gute Alter-
native verfgbar, sollte geprft werden, ob eine Erhhung der Schlssellnge
als bergangslsung infrage kommt.
Nach der Neuverschlsselung und erneuter Archivierung sind die alten Daten- Backup-Medien nicht
vergessen!
bestnde zuverlssig zu vernichten. Falls die Ursprungsdaten auf WORM-
Medien archiviert wurden, sind die Datentrger, auf denen die Daten in der
bisherigen Verschlsselung gespeichert wurden, sicher zu entsorgen. Auf
wiederbeschreibbaren Medien mssen die Daten zuverlssig gelscht werden
(vergleiche dazu M 2.167 Sicheres Lschen von Datentrgern). Es ist zu be-
achten, dass auch die auf Backup-Medien vorgehaltenen Daten neuver-
schlsselt und alte Backup-Medien selektiv gelscht oder vernichtet werden
mssen (siehe hierzu M 6.84 Regelmige Datensicherung der System- und
Archivdaten).
- Werden die Entwicklungen auf dem Gebiet der Kryptographie beobachtet?
- Sind die Zustndigkeiten fr die Neuverschlsselung klar definiert?
- Werden alte Datentrger sicher vernichtet?
- Werden in die Neuverschlsselung auch die Backup-Daten einbezogen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.265 Geeigneter Einsatz digitaler Signaturen bei der

Archivierung
Verantwortlich fr Umsetzung: Leiter IT, IT-Sicherheitsmanagement,
Archivverwalter, Administrator
Digitale Signaturen sind fr die elektronische Archivierung eine Heraus-
forderung, da sie technisch bedingt eine begrenzte Lebensdauer haben, die
vorher nicht immer bekannt ist. Andererseits sind sie aber auch erforderlich,
wenn elektronische Dokumente wirklich beweissicher archiviert werden
mssen. Die Aussagekraft digitaler Signaturen hngt sehr stark von deren
Interpretation zum Zeitpunkt der Prfung und damit vom so genannten
Gltigkeitsmodell ab. Es bestehen derzeit auch noch keine langfristigen prak-
tischen Erfahrungen mit der Archivierung digital signierter Dokumente, da
digitale Signaturen erst seit wenigen Jahren praktisch eingesetzt werden.
Gltigkeit und Beweiskraft
Diese beiden Eigenschaften einer digitalen Signatur werden blicherweise wie
folgt definiert: Eine digitale Signatur ist genau dann gltig,
- wenn sie mathematisch richtig ist und
- wenn zum Zeitpunkt der Signaturausbung der zugehrige Signatur-
schlssel gltig war.
Eine digitale Signatur ist genau dann beweiskrftig,
- wenn sie zum Zeitpunkt der Prfung entsprechend dem verwendeten
Gltigkeitsmodell als gltig anerkannt wird und
- wenn der zugehrige Signaturschlssel nicht kompromittiert ist.
Aussagekraft digitaler Signaturen
Digitale Signaturen knnen zu unterschiedlichen Zwecken eingesetzt werden,
unter anderem
- zum Nachweis der Integritt von Dateien,
- zur Beglaubigung der Authentizitt von kryptographischen Schlsseln oder
elektronischen Dokumenten sowie
- zur Authentisierung.
Der Einsatz und die Aussagekraft digitaler Signaturen sind anwendungs-
spezifisch im Rahmen einer Sicherheitsrichtlinie (Policy) vorzugeben. In
dieser Policy sollte unter anderem festgelegt werden,
- unter welchen Voraussetzungen digitale Signaturen erzeugt werden,
- von welcher Stelle digitale Signaturen erzeugt werden (bei Zertifikats-
Signaturen z. B. in einem neutralen Trust Center),
- welches Gltigkeitsmodell fr die Anwendung herangezogen wird,
- ob und wie digitale Signaturen gegebenenfalls widerrufen werden knnen
sowie
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- welche Aussage damit verbunden sein soll, d. h. was damit beglaubigt wird
(bei einem Zeitstempel beispielsweise das Vorliegen eines Dokuments zu
einem bestimmten Zeitpunkt).
Die Policy muss schriftlich dokumentiert und archiviert werden, damit bei
einer spteren Prfung der digitalen Signatur klar ist, was die Signatur aussagt
(d. h. beweisen soll) und was nicht. Auerdem sollte sie auch in geeigneter
Form verffentlicht werden, damit alle, die auf die Signaturen vertrauen
mssen bzw. wollen, sich darauf beziehen knnen.
Lebensdauer digitaler Signaturen
Die Lebensdauer digitaler Signaturen wird durch die technische Entwicklung
von Hard- und Software sowie Fortschritte der Kryptographie beschrnkt
(siehe G 2.79 Unzulngliche Erneuerung von digitalen Signaturen bei der
Archivierung und G 4.47 Veralten von Kryptoverfahren). Es muss davon
ausgegangen werden, dass digitale Signaturen nach einem Zeitablauf von ca.
5 Jahren als veraltet gelten, da ihre Aussagekraft nachlsst.
Schlsselzertifikate und Zeitstempel sollten von einem Trust Center daher in
der Regel fr maximal 5 Jahre ausgestellt werden. Sie knnen aber auch
kurzfristig fr ungltig erklrt werden, wenn dies notwendig sein sollte. Dies
wird als Sperrung bezeichnet.
Sperrung von Schlsselzertifikaten
Wenn Schlsselzertifikate durch die Zertifizierungsinstanz gesperrt werden,
weil z. B. die Signaturschlssel kompromittiert sind, muss schnell gehandelt
werden. Alle ab diesem Zeitpunkt mit dem betreffenden Schlssel erfolgten
Signaturen haben ihre faktische Aussagekraft (z. B. Beweiskraft) verloren. Die
Gltigkeit der Signaturen hngt jedoch auch vom Gltigkeitsmodell ab. Im
Gegensatz zum Schalenmodell sind beim Kettenmodell im Grunde zunchst
keine weiteren Aktionen bei der Kompromittierung von Schlsseln
erforderlich.
Dies kann unmittelbare Folgen fr die Aussagekraft archivierter Dokumente
haben. Wenn die betroffenen archivierten Dokumente nur mit dem nun
ungltigen Schlssel signiert sind, so ist diese Signatur je nach verwendetem
Gltigkeitsmodell nicht mehr beweiskrftig.
Empfehlung
Fr die Archivierung digital signierter Dokumente gibt es derzeit keine
erprobten Standards, durch deren Anwendung eine langfristige Gltigkeit und
Beweiskraft der Signaturen sichergestellt werden kann. Bis sich entsprechende
Standards etablieren, sollten daher unter Bercksichtigung der bei der
Langfristarchivierung auftretenden Gefhrdungen folgende Empfehlungen
beachtet werden:
- Die Aussagekraft der Signaturen und Zertifikate ist in einer Policy zu
dokumentieren. Die Policy muss ebenfalls archiviert werden.
- Es sollte ein unabhngiges Trust Center zur Generierung von
Schlsselzertifikaten und Zeitstempeln eingebunden werden.
- Alle zu einem Dokument gehrenden Signaturen, Zeitstempel, Zertifikate
und die fr die Signatur- bzw. Zertifikatsprfung bentigten Schlssel
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
mssen ebenfalls archiviert werden. Dies kann entweder lokal oder zentral
durch das Trust Center erfolgen.
- Je nach Anforderungen an die Aussagekraft der Signaturen mssen u. U.
weitere Kontextinformationen archiviert werden. Bei qualifizierten
Signaturen gem Signaturgesetz gehren hierzu z. B. Verzeichnisdienst-
ausknfte des Zertifizierungsdiensteanbieters.
- Nach sptestens 5 Jahren, mindestens vor Ablauf der regulren Gltigkeit
der Schlsselzertifikate sollten die digitalen Signaturen und Zertifikate
erneuert werden. Solange der Verzeichnisdienst integer verfgbar bleibt, ist
dies eigentlich nur dann erforderlich, wenn die Eignung der Algorithmen
nicht mehr gegeben ist. Da bei der Archivierung die Daten fr einen
lngeren Zeitraum unbearbeitet vorgehalten werden, ist es sinnvoll, diese
trotzdem vorsichtshalber alle 5 Jahre erneut zu signieren.
- Die berprfung einer digitalen Signatur schlgt fehl, sobald auch nur ein
Bit im Dokument oder dessen Signatur gendert wird. Eine bitgenaue
Archivierung ist deshalb unbedingt erforderlich, um die Gltigkeit der
Signatur zu erhalten. Aus diesem Grund sollten entsprechende Fehler-
korrekturmanahmen bei der Speicherung der signierten Dokumente
getroffen werden.
- Die Verantwortlichen fr die elektronische Archivierung sollten sich
regelmig ber die Entwicklungen auf dem Gebiet der digitalen
Signaturen informieren.
Archivierungsmodelle
Im Folgenden werden verschiedene Modelle fr die Archivierung digital
signierter Dokumente beschrieben. Dabei bleibt zunchst die Archivierung
von Schlsselverwaltungsinformationen, wie Zertifikaten oder Sperrlisten,
unbercksichtigt.
Solange es bei den beschriebenen Modellen unwesentlich ist, ob das
Originaldokument nur eine oder mehrere Signaturen enthlt, wird von einer
Originalsignatur gesprochen. Mehrere Originalsignaturen werden nur dann
erwhnt, wenn die Funktionsweise der Archivierung sich dadurch ndert.
Die Beschreibungen der Modelle sind nach folgenden Punkten strukturiert:
- Notwendige Infrastruktur
- Ablauf der Archivierung eines signierten Dokuments
- Ablauf der Abfrage eines Dokuments aus dem Archiv
- Semantik der durch die Archivierung erfolgten zustzlichen Signaturen,
d. h. was wird durch diese Signaturen besttigt?
- Vorgehensweise bei der Prfung der Beweiskraft der Originalsignatur
- Notwendiges Vertrauen in die Instanzen, die an der Archivierung beteiligt
sind
An die Beschreibung schliet sich eine kurze Diskussion der unterschied-
lichen Modelle an.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Modell 1: Archivierungsstelle mit Eingangsstempelung

- Infrastruktur
Vertrauenswrdige Archivierungsstelle, die auch Zertifizierungsdienste
anbietet (Trust Center)
- Ablauf der Archivierung
Das Dokument wird zusammen mit der Angabe des Zeitpunktes seines
Eingangs bei der Archivierungsstelle archiviert.
- Ablauf der Abfrage
Das Dokument zusammen mit der Zeitangabe seines Eingangs in die
Archivierungsstelle wird durch die Archivierungsstelle zum Zeitpunkt der
Abfrage digital signiert. Durch die Signatur der Archivierungsstelle wird
die Authentizitt des Dokuments nachgewiesen und dessen Integritt
geschtzt.
- Semantik der Signatur der Archivierungsstelle
Durch die Signatur bei der Dokumentenabfrage besttigt die
Archivierungsstelle, dass das betreffende Dokument bei ihr zum
angegebenen Zeitpunkt eingegangen und archiviert worden ist.
- Prfung der Beweiskraft der Originalsignatur
Um die Authentizitt und Integritt des Dokuments zu verifizieren, wird
zunchst die Signatur der Archivierungsstelle geprft. Die Originalsignatur
gilt genau dann als beweiskrftig, wenn sie zum angegebenen Zeitpunkt
des Dokumenteneingangs bei der Archivierungsstelle beweiskrftig war.
Diese Prfung bleibt dem Benutzer berlassen. Die hierzu erforderlichen
Zertifikate knnen ihm entweder von derselben Archivierungsstelle
zusammen mit dem Dokument bereitgestellt werden oder mssen von ihm
bei einer anderen geeigneten Stelle angefordert werden.
- Vertrauensmodell
Der Archivierungsstelle wird Vertrauen fr die integere Speicherung der
signierten Dokumente und fr die Korrektheit des Zeitpunkts des
Dokumenteneingangs entgegengebracht.
Gelingt es einem Angreifer, den Zeitpunkt des Dokumenteneingangs zu
manipulieren, so kann er die Beweiskraft der Dokumente ndern. Durch
Angabe eines spteren Zeitpunkts lsst sich die Beweiskraft eines
Dokuments ausschalten. Andererseits kann bei einem archivierten
Dokument mit gltiger, aber nicht beweiskrftiger Signatur die
Beweiskraft durch Angabe eines frheren Eingangszeitpunkts vorgetuscht
werden.
Die Korrektheit des gespeicherten Zeitpunkts des Dokumenteneingangs ist
durch geeignete Schutzmanahmen sicherzustellen. Hierzu knnen digitale
Signaturen verwendet werden, wie bei den Modellen 3 und 4.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Modell 2: Archivierungsstelle mit Besttigungsstempelung

- Infrastruktur
Vertrauenswrdige Archivierungsstelle, die auch Zertifizierungsdienste
anbietet (Trust Center)
Beim Eingang des Dokuments bei der Archivierungsstelle wird die
Beweiskraft der Originalsignatur des Dokuments geprft. Das Dokument
wird nur dann archiviert, falls die Beweiskraft zum aktuellen Zeitpunkt
verifiziert werden kann. Bei mehreren Originalsignaturen wird deren
Beweiskraft einzeln festgestellt. Das Dokument wird zusammen mit den
Angaben ber die Beweiskraft der einzelnen Signaturen archiviert, falls
mindestens eine der Originalsignaturen beweiskrftig ist.
Zum Zeitpunkt der Abfrage wird das Dokument durch die
Archivierungsstelle digital signiert, gegebenenfalls zusammen mit den
Angaben ber die Beweiskraft der Originalsignaturen. Durch die Signatur
der Archivierungsstelle wird die Authentizitt des Dokuments nachge-
wiesen und dessen Integritt geschtzt.
- Semantik der Signatur der Archivierungsstelle
Durch die Signatur der Archivierungsstelle wird die Beweiskraft der
Originalsignatur besttigt. Bei mehreren Originalsignaturen werden die
mitgelieferten Angaben ber deren Beweiskraft einzeln besttigt.
Um die Authentizitt und Integritt der Archivantwort zu verifizieren, wird
die Signatur der Archivierungsstelle geprft. Die Beweiskraft der
Originalsignatur ergibt sich aus den mitgelieferten Angaben bzw. aus der
Archivierung an sich.
- Vertrauensmodell
signierten Dokumente und fr die Prfung der Beweiskraft der Dokumente
vor der Archivierung entgegengebracht.
Wenn es einem Angreifer unbemerkt gelingt, einen ehemals gltigen
Signaturschlssel zu brechen und Dokumente mit geflschten Signaturen
ins Archiv einzubringen, gelten diese als beweiskrftig. Durch geeignete
Manahmen ist daher sicherzustellen, dass die Beweiskraft signierter
Dokumente vor der Aufnahme ins Archiv geprft und der Datenbestand
vor unberechtigtem Hinzufgen von Daten geschtzt wird.
Modell 3: Trust Center mit Zeitstempeldienst
- Infrastruktur
Rollentrennung zwischen einer Archivierungsstelle und einem vertrauens-
wrdigen Zeitstempeldienst (Trust Center), die miteinander kommuni-
zieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Beweiskraft der Originalsignatur durch einen Zeitstempel des Trust
Centers fr die Dauer der Beweiskraft dieses Stempels besttigt.
Regelmig vor dem Ablauf der Beweiskraft des letzten Zeitstempels wird
das Gesamtdokument, d. h. das Dokument inklusive aller Signaturen, mit
einem neuen Zeitstempel des Trust Centers versehen.
- Struktur eines archivierten Dokuments
Ein archiviertes Dokument enthlt mindestens das signierte Original-
dokument und einen Zeitstempel ber dieses Dokument. Im Laufe der Zeit
verlngert es sich durch zustzliche Zeitstempel, die jeweils ber das
signierte Originaldokument inklusive aller bisherigen Zeitstempel
ausgefhrt werden.
Das Dokument inklusive aller Zeitstempel wird im aktuellen Zustand
ausgeliefert.
- Semantik eines Zeitstempels
Bei einer Zeitstempelung wird durch eine speziell fr diesen Zweck
vorgesehene Signatur des Trust Centers besttigt, dass das Dokument zu
dem im Zeitstempel angegebenen Zeitpunkt vorlag.
Die Beweiskraft des letzten Zeitstempels wird direkt verifiziert. Jeder
andere Zeitstempel wird geprft, indem seine Beweiskraft zum Zeitpunkt
des jeweils nachfolgenden Zeitstempels verifiziert wird (rekursive
Verifikation). Die Prfung der Beweiskraft der Originalsignatur erfolgt zu
dem Zeitpunkt, der im ersten Zeitstempel angegeben ist.
- Vertrauensmodell
Dokumente entgegengebracht. Beim Trust Center wird dem Zeitstempel-
dienst vertraut.
Anhand der Kette von Zeitstempeln ist die Beweiskraft der Original-
signatur lckenlos nachweisbar.
Modell 4: Trust Center mit Archivstempeldienst
- Infrastruktur
Rollentrennung zwischen einer Archivierungsstelle und einem vertrauens-
wrdigen Archivstempeldienst (Trust Center), die miteinander kommuni-
zieren.
- Funktionsweise einer Archivstempelung
Wird ein Dokument zum ersten Mal einer Archivstempelung unterzogen,
entspricht dieser Vorgang der Zeitstempelung: Das Dokument wird mit
einem Zeitstempel versehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Falls ein Dokument bereits genau einmal den Archivstempeldienst

durchlief und somit schon einen Zeitstempel enthlt, wird bei der erneuten
Archivstempelung zunchst dieser Zeitstempel geprft. Nur falls der
Zeitstempel beweiskrftig ist, wird das Dokument inklusive Zeitstempel
mit einer speziellen Archivsignatur signiert.
Enthlt ein Dokument bereits eine Archivsignatur, wird bei einer erneuten
Archivstempelung zunchst die Archivsignatur geprft. Nur falls die
bisherige Archivsignatur beweiskrftig ist, wird sie durch eine aktuelle
Archivsignatur ersetzt.
Beweiskraft der Originalsignatur durch die Archivstempelung des Trust
Centers fr die Dauer der Beweiskraft des hinzugefgten Zeitstempels
besttigt.
Regelmig vor dem Ablauf der Beweiskraft des Zeitstempels oder der
letzten Archivsignatur muss eine Archivstempelung durch das Trust Center
erfolgen.
- Struktur eines archivierten Dokuments
Ein archiviertes Dokument besteht mindestens aus dem signierten
Originaldokument und einem Zeitstempel darber. Nach Ablauf der
Beweiskraft des Zeitstempels enthlt es zustzlich genau eine
Archivsignatur. Diese Signatur ist ber das signierte Originaldokument und
den Zeitstempel gebildet.
Das Dokument inklusive aller Signaturen wird im aktuellen Zustand
ausgeliefert.
- Semantik der Archivsignatur
Die Archivsignatur besttigt die Beweiskraft des Zeitstempels. Der
Zeitstempel wiederum besttigt das Vorliegen des Originaldokuments zum
angegebenen Zeitpunkt.
Zunchst wird die Beweiskraft der Archivsignatur und anschlieend die
Beweiskraft der Originalsignatur zum im Zeitstempel angegebenen
Zeitpunkt verifiziert.
- Vertrauensmodell
Dokumente entgegengebracht. Beim Trust Center ist ein vertrauens-
wrdiger Archivstempeldienst notwendig.
- Der Archivstempeldienst muss die Beweiskraft einer vorhergehenden
Signatur prfen. Gelingt es einem Angreifer, diese Prfung zu unter-
drcken und geflschte, signierte Dokumente mit einer Archivsignatur zu
versehen, gelten diese als beweiskrftig. Durch geeignete Manahmen
muss daher sichergestellt werden, dass die Beweiskraft der bisherigen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Signatur vor der Erneuerung oder dem Hinzufgen einer Archivsignatur

geprft wird.
Diskussion der Modelle
Je geringer das Vertrauen der Benutzer in die Archivierungsstelle ist, desto
hher ist der Aufwand fr die beweiskrftige Archivierung digital signierter
Dokumente.
Bei vollem Vertrauen in die Archivierungsstelle ist Modell 2 anwendbar. Es
ist fr einen Benutzer das "bequemste" Modell, da dieser bei der Abfrage des
archivierten Dokuments ber die Beweiskraft der Originalsignatur informiert
wird. Der Benutzer vertraut darauf, dass die Angaben der Archivierungsstelle
stimmen. ber diese hinaus hat er keine Kontrollmglichkeit. Will er einen
Dritten von der Beweiskraft der Originalsignatur berzeugen, kann er
lediglich auf die Antwort der Archivierungsstelle verweisen und auf deren
durch Archivierungsrichtlinien belegte Vertrauenswrdigkeit.
In Modell 1 muss der Benutzer selbst die Beweiskraft der Originalsignatur des
abgefragten Dokuments prfen. Die Archivierungsstelle liefert ihm lediglich
den Zeitpunkt, an dem das Dokument bei ihr einging. Ein Dritter kann ebenso
wie der Benutzer die Prfung der Beweiskraft durchfhren, muss allerdings
der Zeitangabe der Archivierungsstelle vertrauen.
Beide Modelle haben den Vorteil, dass der organisatorische Aufwand der
Archivierungsstelle minimal ist: Nach der Archivierung ist keine weitere
Behandlung des Dokuments erforderlich. Die Archivierung selbst dient als
Versiegelung der Originalsignatur fr die gesamte Archivierungsdauer.
Entsprechend kritisch ist die Integritt des Datenbestandes des Archivs.
Unberechtigtes Hinzufgen von Daten kann dazu fhren, dass geflschte
Signaturen als beweiskrftig anerkannt werden.
In den Modellen 3 und 4 sind archivierte Daten selbst wiederum durch digitale
Signaturen integrittsgeschtzt. Dadurch wird verhindert, dass geflschte
signierte Dokumente als beweiskrftig anerkannt werden, wenn sie
unberechtigt in das Archiv eingebracht werden.
Eine weitere vertrauensfrdernde Manahme in den Modellen 3 und 4 ist die
Mglichkeit, die Zustndigkeiten fr die Dokumentenspeicherung einerseits
und die Signaturversiegelung andererseits auf unterschiedliche Stellen zu
verteilen: Archivierungsstelle und Trust Center.
Das notwendige Vertrauen in die Archivierungsstelle beschrnkt sich dabei,
wie es blicherweise bei der Archivierung der Fall ist, auf die Speicherung
von Dokumenten. Darber hinaus erfordert die erfolgreiche Archivierung
digital signierter Dokumente die regelmige Kommunikation mit dem Trust
Center. Zunchst muss jedes eingehende Dokument durch das Trust Center
zeitgestempelt werden, da der Zeitpunkt des Dokumenteneingangs bei der
Archivierungsstelle fr die nachtrgliche Prfung der Beweiskraft
entscheidend ist.
In Modell 4 besttigt das Trust Center regelmig die ordnungsgeme
Archivierung bis zum aktuellen Zeitpunkt, indem es die Beweiskraft der
bisherigen Archivsignatur des Dokuments verifiziert und diese Signatur durch
eine neue Archivsignatur ersetzt. Der zeitliche Abstand zwischen dem Ende
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
der Beweiskraft des Zeitstempels und dem Zeitpunkt der letzten

Archivstempelung vergrert sich dadurch laufend. Die Archivsignatur
besttigt daher die Beweiskraft des Zeitstempels nur, solange die
Archivstempelung im Trust Center ordnungsgem verluft. Insbesondere
betrifft dies die berprfung der Beweiskraft der bisherigen Archivsignatur.
Ohne diese Prfung kann die Archivierungsstelle geflschte signierte
Dokumente zur Archivstempelung vorlegen, die dann Beweiskraft erhalten.
Der Benutzer muss also der ordnungsgemen Ausfhrung der
Archivstempelung durch das Trust Center vertrauen.
Bei Modell 3 kann der Benutzer den zeitlich lckenlosen Ablauf der regel-
migen Signaturversiegelung kontrollieren. Als Dienstleistung des Trust
Centers ist lediglich eine Zeitstempelung erforderlich. Diese Zeitstempelung
ist nicht spezifisch fr die Archivierung und umfasst keine berprfungen.
Ein vorliegendes Dokument wird ohne vorhergehende Betrachtung, sozusagen
"blind" mit der aktuellen Zeit versehen und signiert. Eine vertrauenswrdige
Realisierung einer Zeitstempelung ist daher im Allgemeinen einfacher als eine
vergleichbar vertrauenswrdige Realisierung einer Archivstempelung.
Die Modelle 3 und 4 bieten zwar im Vergleich zu den Modellen 1 und 2 eine
hhere Vertrauenswrdigkeit, hierbei ist es jedoch fr die Benutzer
komplizierter, die Beweiskraft der Originalsignatur zu berprfen. Zustzlich
zur Beweiskraft der Originalsignatur zum Zeitpunkt des ersten Zeitstempels
ist in Modell 3 eine ganze Kette von Zeitstempeln auf Beweiskraft zu prfen,
in Modell 4 hingegen nur die Beweiskraft der Archivsignatur.
Fr die Langzeitarchivierung digitaler Signaturen gibt es noch keine erprobten
Standards. Hier mssen sich noch einheitliche Konzepte und Standards
durchsetzen, daher sollten sich die Verantwortlichen fr die elektronische
Archivierung regelmig ber die Entwicklungen auf diesem Bereich
informieren. Die zuvor beschriebenen Modelle sind somit als Beispiele zu
verstehen, zur Archivierung digital signierter Dokumente sind durchaus auch
andere Verfahren denkbar.
- Gibt es ein Konzept sowie eine Sicherheitsrichtlinie fr den Einsatz
digitaler Signaturen bei der Archivierung?
- Sind das vorliegende Konzept sowie die Sicherheitsrichtlinie aktuell?
- Sind die Mitarbeiter ber den sie betreffenden Teil des Konzepts nach-
weislich unterrichtet worden?
- Wird die Aktualitt des Konzepts regelmig berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.266 Regelmige Erneuerung technischer

Archivsystem-Komponenten
Archivsysteme mssen ber lange Zeitrume auf aktuellem technologischen technischer Fortschritt
Stand gehalten werden. In der Informationstechnik haben Standards fr Hard-
und Software sowie Datenformate zur digitalen Speicherung in der Ver-
gangenheit im Vergleich zu den avisierten Zeitrumen einer Archivierung nur
kurzzeitigen Bestand gehabt. Es ist davon auszugehen, dass dies auch knftig
so bleibt, da die Standards in hohem Mae vom technischen Fortschritt ge-
prgt werden.
Hardware-Komponenten unterliegen zudem Verschleierscheinungen und Verschlei-
erscheinungen
mssen daher regelmig gewartet sowie gegebenenfalls ausgetauscht werden.
Zustzlich ist damit zu rechnen, dass Hersteller unvorhergesehen die Unter-
sttzung bestehender Systeme einstellen oder, z. B. aufgrund von Insolvenz,
nicht mehr in der Lage sind, langfristige Untersttzung zu gewhrleisten.
Es ist daher damit zu rechnen, dass die Komponenten des Archivs regelmig
erneuert werden mssen und unter Umstnden eine Migration des kompletten
Datenbestands auf ein neues Archivsystem notwendig ist.
Dieser Prozess ist eng mit der Manahme M 2.261 Regelmige Markt-
beobachtung von Archivsystemen verknpft.
Neue Hard- und Software ist vor der Installation in ein laufendes Archiv- Kompatibilitt testen
system grundstzlich ausfhrlich zu testen, um die Stabilitt des bestehenden
Systems nicht zu gefhrden (siehe auch M 4.65 Test neuer Hard- und Soft-
ware). Bei der Installation neuer Datentrger und Laufwerke muss auf Kom-
patibilitt mit bestehenden Systemen und Datentrgern geachtet werden. Vor
der Inbetriebnahme neuer Komponenten oder der Einfhrung neuer Daten-
formate ist ein Migrationskonzept zu erstellen, in dem alle nderungen und
Tests beschrieben werden. Das Archivierungskonzept (siehe M 2.243 Ent-
wicklung des Archivierungskonzepts) ist unter Umstnden anzupassen. Bei
greren nderungen muss die in der Bausteinbeschreibung beschriebene
Planungsphase erneut durchlaufen werden.
Bei der nderung von Formaten muss geprft werden, ob bei der Konver-
tierung von Altdaten in die neuen Formate aufgrund rechtlicher An-
forderungen zustzlich die Daten in ihren ursprnglichen Formaten archiviert
werden mssen.
- Besteht fr alle Komponenten (Software, Hardware und Speichermedien)
des Archivs Untersttzung durch den Hersteller oder vergleichbare Unter-
sttzung?
- Sind Kompatibilittstests vor Installation neuer Komponenten verbindlich
vorgeschrieben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.267 Planen des IIS-Einsatzes

Verantwortlich fr Umsetzung: Leiter IT Administrator
Ein IIS bietet vielfltige Einsatzmglichkeiten im Intranet und Internet. Er

kann als einfacher Informations-Server oder auch als Basis fr komplexe
Web-Anwendungen genutzt werden. Soll ein IIS eingesetzt werden, so ist ein
Betriebskonzept zu entwerfen. Bei der Planung eines IIS ist Folgendes aus
Sicherheitssicht zu beachten:
- Die umzusetzenden Sicherheitsvorschriften mssen ausgearbeitet werden
(siehe M 2.268 Festlegung einer IIS-Sicherheitsrichtlinie).
- Der Standort der IT-Systeme, auf denen der IIS betrieben wird, ist sichere Aufstellung der
Server
festzulegen. Alle Systeme mit IIS sollten in Serverrumen oder in einem
Rechenzentrum aufgestellt werden. Hierbei zu realisierende Manahmen
sind in Kapitel 4.3.2 Serverraum bzw. 4.6 Rechenzentrum beschrieben.
Wenn kein Serverraum zur Verfgung steht, kann ein IIS alternativ in
einem Serverschrank aufgestellt werden (vgl. Kapitel 4.4 Schutzschrnke).
- Ein Webserver, auf den aus dem Internet zugegriffen wird, muss in einem sichere Anbindung an
das Internet
separaten Netz (einer so genannten Demilitarisierten Zone, DMZ)
angesiedelt sein. Der Zugriff auf den Server muss durch eine Firewall
abgesichert werden (siehe auch M 2.77 Sichere Anordnung weiterer
Komponenten).
- Bei Installation in der DMZ sollte der IIS ebenso wie andere existierende
Systeme in der DMZ berwacht werden (siehe auch . M 4.182
berwachen des IIS-Systems)
- Der Webserver ist als Standalone-Server (nicht Mitglied einer Domne) zu
installieren.
- Ggf. ist die Installation von Systemen zur Erhhung der Verfgbarkeit und Performance und
Lastverteilung
Performance (Standby-Systeme, Lastverteilung) zu planen (siehe auch
M 4.183 Sicherstellen der Verfgbarkeit und Performance des IIS).
- Ggf. ist die Anbindung an Datenbanken fr komplexe Web-Anwendungen
zu planen.
- Fr die Server und die Verzeichnisse sind die Zugangs- und Rechtekonzept fr
Server
Zugriffsbeschrnkungen zu planen. Dabei sollten nur die Berechtigungen
vergeben werden, die auch wirklich bentigt werden (siehe auch M 4.185
Absichern von virtuellen Verzeichnissen und Web-Anwendungen beim IIS-
Einsatz).
- Fr die Web-Sites sind Zugriffsberechtigungen und die Authentisierungs-
methode zu planen (siehe auch M 4.180 Konfiguration der
Authentisierungsmechanismen fr den Zugriff auf den IIS).
- Fr jeden Server ist festzulegen, welche Komponenten und Dienste nicht bentigte
Komponenten und
aktiviert werden. Nicht bentigte Komponenten und Dienste sind zu Dienste deaktivieren
deaktivieren (siehe auch M 4.184 Deaktivieren nicht bentigter Dienste
beim IIS-Einsatz). Bei der Planung sollte eine Funktionstrennung von
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
unterschiedlichen Servertypen bercksichtigt werden, beispielsweise FTP-

Server und WWW-Server.
Die Sicherheit des Webservers hngt von vielen Faktoren ab, die wichtigsten
sind jedoch
- die sichere Konfiguration des Betriebssystems,
- die sichere Konfiguration des IIS und
- die sichere Einbindung in die Systemumgebung.
Detaillierte Manahmen zur Absicherung dieser Hauptkomponenten finden
sich in den IIS-spezifischen Manahmen der Manahmenkataloge 4
Hardware/Software und 5 Kommunikation.
- Ist der Server vom Internet aus erreichbar?
- Erfolgt der Zugriff durch anonyme oder authentisierte Benutzer?
- Ist der Server durch einen Proxy, eine Firewall oder hnliches geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.268 Festlegung einer IIS-Sicherheitsrichtlinie

Die Vorbereitungen des Betriebssystems sind die grundlegenden Manahmen
fr die Installation des IIS. Diese Manahmen sind als erstes technisch
umzusetzen und lassen sich nicht oder nur schwer nachtrglich realisieren.
Version des Betriebssystems
Die englische Version von Windows NT/2000 ist weiter verbreitet als die Englische Version
deutsche Version. Dies fhrt dazu, dass Tools, Service Packs und Hotfixes fr
die englische Version schneller verfgbar sind. Es gibt auch Tools, die nur mit
der englischen Version von Windows NT/2000 einsetzbar sind. Es ist auch
mglich, die englische Version von Windows NT/2000 so zu konfigurieren,
dass Fehlermeldungen in deutscher Sprache ausgegeben werden. Es sollte
demnach die englische Version von Windows NT/2000 eingesetzt werden.
Installation des Servers
Bei der Installation eines Rechners als Internet-Server sollte auch das
Betriebssystem neu installiert werden, da die Gefahr bestehender
Sicherheitslcken bei einem historisch gewachsenen System sehr gro ist.
Die Installation von Windows NT/2000 sollte als Stand-Alone-Server Stand-Alone-Server
erfolgen. Wenn mglich sollte der Server nicht als Domnen-Controller oder
Mitglied einer Domne konfiguriert werden, da die Gefahr besteht, dass ein
Angreifer Informationen ber vorhandene Benutzer und Systeme gewinnen
kann. Ebenfalls sollte der Server nicht in das Active Directory (Windows
2000) der Organisation eingebunden werden.
Fr die sptere Installation des Web-Servers bietet es sich an, zwei getrennte Partitionierung
Partitionen zu erstellen. Dadurch besteht die Mglichkeit, das Webroot-
Verzeichnis, auf das von extern zugegriffen wird, von den Systemverzeich-
nissen zu trennen.
Um auf der Verzeichnisebene eine grere Sicherheit zu gewhrleisten, ist als Dateisystem
Dateisystem NTFS zu whlen. Die Zugriffe und Berechtigungen, z. B. Lesen,
Schreiben, Ausfhren, auf Dateien und Verzeichnisse werden dabei ber
Access Control Lists (ACLs) festgelegt und knnen auf bestimmte Benutzer
beschrnkt werden.
Bei Windows NT bietet der Installations-Wizard whrend der Installation von Windows NT mit IIS 2.0
Windows NT 4.0 Server die Mglichkeit, den IIS 2.0 mit zu installieren.
Dieser Installationsschritt ist zu berspringen, um den IIS 4.0 zu installieren.
Voraussetzung fr die Installation des IIS ist bei Windows NT der Internet Internet Explorer
Explorer 4.0.1. Microsoft empfiehlt, die Version 4.01 mit dem Service Pack 2
zu installieren, da auf die erweiterten Mglichkeiten des Internet Explorer 5
verzichtet werden kann.
Der "Active Desktop" sollte auf keinem IIS-System aktiviert sein. Er ist in den
Eigenschaften des Desktops zu deaktivieren.
Bei einer Neuinstallation eines Windows 2000 Servers wird der IIS 5.0 Windows 2000
standardmig mit installiert. Auch beim Update eines Systems, z. B.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Windows NT 4.0 Server, wird ein vorhandener IIS 4.0 automatisch

aktualisiert. Bei einem historisch gewachsenen System besteht die Gefahr,
dass bestehende Sicherheitslcken auf das neue System bertragen werden.
Deshalb ist bei einem Internet-Web-Server so weit wie mglich eine
Neuinstallation zu empfehlen. Ansonsten muss der IIS ber die
Systemsteuerung Software | Windows-Komponenten hinzufgen/entfernen
hinzugefgt werden.
Updates und Patches
Bei der Installation von Windows NT/2000 sind eine Reihe von Updates und Updates und Patches
Patches zu bercksichtigen. Eine aktuelle bersicht ist auf den Web-Seiten
von Microsoft (http://www.microsoft.com/ntserver/downloads/default.asp und
http://www.microsoft.com/windows2000/server/default.asp) oder auf den
Web-Seiten des RUS CERT (http://cert.uni-stuttgart.de/ms.php) zu finden.
Der Administrator eines Web-Servers sollte das System aktuell halten.
Microsoft stellt ein Tool zur Verfgung (HFCHECK.WSF), das den aktuellen
Patch-Status fr Windows NT und Windows 2000 sowie die aktuellen
Hotfixes fr den IIS 4.0 und IIS 5.0 untersucht. Das Tool kann unter
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24168
herunter geladen werden. Eine Anleitung ist unter
http://www.aspheute.com/artikel/20000914.htm
erhltlich.
- Wird die englische Version des Betriebssystems eingesetzt?
- Wurde der Server als Stand-Alone-Server installiert?
- Wurden bei der Installation mindestens zwei Partitionen eingerichtet?
- Wird als Dateisystem NTFS verwendet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.269 Planung des Einsatzes eines Apache

Webservers
Die Detailplanung fr den Einsatz eines Apache-Webservers baut auf der all-
gemeinen Planung fr den Aufbau eines Webangebots (siehe M 2.172 Ent-
wicklung eines Konzeptes fr die WWW-Nutzung) auf. Aus den festgelegten
Zielen des Webangebots und weiteren Rahmenbedingungen (beispielsweise
Zugriff auf Datenbanken) ergeben sich Anforderungen, die in der konkreten
Planung fr den Apache-Webserver bercksichtigt werden mssen. Die fol-
genden Themen, die auch untereinander Abhngigkeiten aufweisen, sollten
bei der Planung bercksichtigt werden:
Auswahl der Hardware- und Betriebssystemplattform und der Apache-
Version
Die Hardware, auf der der Apache-Webserver eingesetzt wird, kann einen Hardware auswhlen
entscheidenden Einfluss auf die Gesamtleistung des entstehenden Systems
haben. Dabei spielen bei einem Webserver, der vor allem statische Seiten aus-
liefert, Anzahl und Takt der eingesetzten Prozessoren praktisch keine Rolle
mehr. Wichtiger ist in diesem Fall die Geschwindigkeit der eingesetzten Fest-
platten und des Speicherzugriffs.
Je mehr dynamische Seiten in einem Webangebot enthalten sind, desto wich-
tiger werden Prozessorgeschwindigkeit und Hauptspeicherausbau. Bei der
Auswahl des Plattensubsystems sollte darauf geachtet werden, dass das Sys-
tem hohe Datenbertragungsraten beim "zuflligen" Lesen verschiedener Da-
teien bietet. Es sollte berlegt werden, die Partition, auf der die WWW-Daten
abgelegt werden sollen, auf einem externen RAID-System zu installieren. Das
RAID-System sollte das Austauschen von Festplatten im laufenden Betrieb
(hot-swap) untersttzen und als RAID 5 organisiert werden. Dies erlaubt es,
defekte Platten ohne Betriebsunterbrechung des Servers auszutauschen.
Der Apache-Webserver kann unter sehr vielen Betriebssystemen eingesetzt Betriebssystem aus-
whlen
werden. Bei der Auswahl der Apache Version und des Betriebssystems, unter
welchem der Apache-Webserver eingesetzt werden soll, sollten die folgenden
Punkte bercksichtigt werden:
- Erst seit der Version 2 wird Windows als Betriebssystem "voll" untersttzt.
Zwar existiert auch eine Portierung der Version 1.3 auf Windows, diese
wird jedoch nicht als so stabil angesehen, wie die Unix-Versionen.
- Nicht alle Erweiterungsmodule, die es fr den Apache-Webserver gibt,
sind fr alle Betriebssysteme verfgbar. Daher muss geprft werden, wel-
che Erweiterungsmodule fr den geplanten Einsatz bentigt werden und
fr welche Plattformen diese verfgbar sind.
- Fr die gewhlte Plattform muss entsprechender interner oder externer
Support zur Verfgung stehen. Die Administratoren mssen ber die not-
wendigen Kenntnisse in dem Betriebssystem verfgen oder entsprechend
geschult werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Binrversion oder eigenes Kompilieren

Der Apache-Webserver kann entweder aus dem Quellcode selbst kompiliert
werden, oder es kann eine Binrversion installiert werden. Der Quellcode
kann vom Server der Apache Foundation (http://www.apache.org) herunter-
geladen werden. Binrversionen werden von verschiedenen Betriebssystem-
herstellern und Distributoren angeboten. Auch die Apache Foundation bietet
vorkompilierte Versionen fr verschiedene Betriebssysteme an.
Bei der Entscheidung, ob eine Binrversion eingesetzt oder der Apache-Web-
server selbst kompiliert wird, sollten die folgenden Punkte bercksichtigt
werden:
- Binrversionen sind meist auf eine bestimmte Standardkonfiguration zuge-
schnitten. Dies bedeutet, dass weniger Einfluss auf Installationspfade und
die Zusammenstellung von Erweiterungsmodulen mglich ist.
- Binrversionen von Betriebssystemherstellern oder Distributoren sind oft Binrversionen sind
bequem, aber nicht so
nicht auf dem neuesten Versionsstand bzw. es vergeht einige Zeit, bevor flexibel
eine neue Version verfgbar ist. Dies kann zu Problemen fhren, wenn bei-
spielsweise beim Auftauchen von Sicherheitslcken schnell eine neue Ver-
sion bentigt wird. Andererseits bieten Binrversionen den Vorteil, dass sie
vom Hersteller bzw. Distributor getestet sind, mit den vorhandenen Instal-
lationsmechanismen (Paketverwaltung oder hnliches) installiert werden
knnen und meist auch auf dem "Standard-Support-Weg" untersttzt wer-
den. Die Binrversionen von der Apache Foundation sind meist relativ
schnell verfgbar, es gibt jedoch keinen Standard-Support.
- Das Kompilieren des Apache-Webservers aus dem Quellcode bietet die Kompilieren ist flexibel,
aber aufwendiger
grtmgliche Flexibilitt bei der Auswahl von Modulen und anderen Op-
tionen. Zustzlich sind Patches und neue Versionen immer zuerst als
Quellcode verfgbar. Der Nachteil ist, dass ein Administrator mit entspre-
chenden Kenntnissen sowie ein entsprechend ausgersteter Entwicklungs-
rechner vorhanden sein mssen. Aus Sicherheitsgrnden sollte auf dem
Webserver-Rechner selbst kein Compiler installiert sein.
- Manche Module knnen nur verwendet werden, wenn der Apache-Webser-
ver selbst bersetzt wird.
Festlegen bentigter Funktionalitt
Die weiteren Anforderungen, die bei der allgemeinen Planung fr das Weban-
gebot aufgestellt wurden, mssen in konkrete Anforderungen an den Apache-
Webserver bertragen werden.
Falls das Webangebot dynamische Seiten enthalten soll, sollte sptestens an
dieser Stelle entscheiden werden, mit welcher Technik diese realisiert werden
sollen. Ist der Zugriff auf Datenbanken, Verzeichnisdienste oder sonstige ex-
terne Resourcen erforderlich, so muss auch dafr festgelegt werden, wie der
Zugriff realisiert werden soll.
Es sollte eine Liste der Module erstellt werden, die im Apache-Webserver
eingesetzt werden mssen, um die Anforderungen zu erfllen. Module, die in
der Standardkonfiguration aktiv sind, fr die jedoch kein konkreter Bedarf
besteht, sollten nach Mglichkeit entfernt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.270 Planung des SSL-Einsatzes beim Apache

Webserver (zustzlich)
Verantwortlich fr Initiierung: Leiter IT IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement Administrator
SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) ist ein
Transportprotokoll, das kryptographische Mechanismen zur Gewhrleistung
von Integritt, Vertraulichkeit und Authentizitt bertragener Daten nutzt
(siehe M 5.66 Verwendung von SSL).
Einsatzmglichkeiten von SSL beim Apache-Webserver
Es gibt zwei Szenarien, in denen SSL zum Einsatz kommen kann:
Im ersten Szenario verfgt nur der WWW-Server ber ein Zertifikat. Der Serverzertifikat und
Verbindungsverschlsse
WWW-Client kann dann aufgrund dieses Zertifikates den WWW-Server lung
authentisieren. Im Rahmen des SSL-Protokolles wird dann ein verschlsselter
und integrittsgeschtzter Kanal etabliert, ber den im folgenden die Daten
zwischen WWW-Server und WWW-Client ausgetauscht werden knnen.
Im zweiten Szenario verfgt auch der Benutzer des WWW-Servers ber ein Client-Authentisierung
eigenes Zertifikat, so dass im Rahmen des SSL-Protokolles eine gegenseitige
Authentisierung erfolgen kann.
Der Einsatz von SSL in Verbindung mit einem WWW-Server erfordert eine
sorgfltige Planung, bei der eine ganze Reihe von Aspekten bercksichtigt
werden mssen. Beim Einsatz von SSL im ersten Szenario etwa kommen die
folgenden Aspekte zum Tragen:
- Der WWW-Server bentigt ein SSL-Zertifikat, das fr ihn von einer
Zertifizierungsstelle ausgestellt wurde.
- Bei der Auswahl dieser Zertifizierungsstelle muss bercksichtigt werden,
dass die WWW-Clients, die auf den WWW-Server zugreifen sollen, ber
das entsprechende Wurzelzertifikat dieser Zertifizierungsstelle verfgen
mssen.
- Das SSL-Zertifikat eines Servers muss regelmig erneuert werden. Neben
der Laufzeit des Zertifikates selbst muss hier auch die Laufzeit des
Wurzelzertifikates bercksichtigt werden.
- Ein SSL-Zertifikat kann auch selbst erzeugt werden, beispielsweise mit
dem OpenSSL Paket. Da solche Eigen-Zertifikate nicht von einer der
Zertifizierungsstellen stammen, die normalerweise den Browsern bekannt
sind, bekommen die Besucher in diesem Fall jedoch meist beim Zugriff
eine Warnung angezeigt. Dies kann dadurch behoben werden, dass das
zum Ausstellen des Server-Zertifikats benutzte Zertifikat manuell auf den
Browsern installiert wird. Bei einer Nutzung eines SSL-gesicherten
Webservers im Intranet kann dies eine bercksichtigenswerte Option sein.
Wird SSL im zweiten Szenario auch zur Client-Authentisierung genutzt, so SSL-Benutzerzertifikate
mssen verwaltet
muss im Prinzip eine vollstndige Public-Key-Infrastruktur geplant werden. werden
Folgende Aspekte mssen dabei bercksichtigt werden:
- Fr die einzelnen Benutzer mssen SSL-Zertifikate erstellt und verteilt
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Gltigkeitsdauer der Benutzer-Zertifikate muss ebenso bercksichtigt

werden, wie das Szenario eines Schlsselwechsels der eingesetzten
Zertifizierungsstelle.
- Die Richtlinien der fr die Benutzer-Zertifikate genutzten
Zertifizierungsstelle mssen konform zu den Anforderungen an die
Authentisierung der Benutzer sein.
- Es muss in Betracht gezogen werden, dass der private SSL-Schlssels
eines Benutzers kompromittiert sein knnte. Daher sollte es auch
Mglichkeiten geben, diese zu sperren. Dies kann durch Prfen gegen eine
Positivliste (noch gltige Zertifikate) oder durch Verwendung einer
Negativliste (gesperrte Zertifikate) geschehen.
Prinzipiell besteht die Mglichkeit, SSL-Benutzerzertifikate nicht nur zur
Authentisierung zu nutzen, sondern darber hinaus auch Zugriffsrechte in
Abhngigkeit von einzelnen Eintrgen des Zertifikates zu vergeben (z. B. der
Zugehrigkeit zu einer bestimmten Abteilung). Soll diese Mglichkeit genutzt
werden, so muss darauf geachtet werden, dass
- die relevanten Eintrge bei der Zertifizierung von Benutzern korrekt
vorgenommen werden und
- die Zertifikate gesperrt werden, sobald die relevanten Eintrge ungltig
werden (z. B. wenn Mitarbeiter die Institution verlassen oder die Abteilung
wechseln).
Knnen diese Voraussetzungen nicht gewhrleistet werden, so ist im Rahmen
der Definition einer Sicherheitsrichtlinie fr den Webserver festzuhalten, dass
Zugriffsrechte nicht auf der Basis von Zertifikatsfeldern eingerichtet werden
drfen.
Im Rahmen der Planung mssen schlielich die notwendigen Ablufe und
Zustndigkeiten definiert werden. Die Planung ist zu dokumentieren. Die
Dokumentation der Planung sollte getroffene Entscheidungen und die
Beweggrnde, die fr diese Entscheidungen ausschlaggebend waren, klar
herausstellen.
Verfgbare Implementierungen von SSL beim Apache-Webserver
Ab der Version 2.0 des Apache-Webservers wird SSL mit dem Modul
mod_ssl vom Apache-Webserver direkt untersttzt. In der Version 1.3 ist
keine Implementierung von SSL enthalten, sondern es ist eine Erweiterung
des Apache-Webservers notwendig. Es existieren gibt zwei verschiedene
Open-Source-Implementierungen von SSL: Apache-SSL (http://www.apache-
ssl.org) und mod_ssl (http://www.modssl.org). Beide verwenden fr die
kryptographischen Algorithmen und die Realisierung des SSL-Protokolles
selbst das Open-Source Paket OpenSSL (http://www.openssl.org). Die
prinzipiellen Unterschiede zwischen den beiden Implementierungen bestehen
in der Art der Integration von OpenSSL in den Apache-Webserver sowie in
den verfgbaren Konfigurationsmglichkeiten.
Vor der Verwendung von SSL muss daher im Rahmen der Planung (siehe M
2.269 Planung des Einsatzes eines Apache-Webservers ) entschieden werden,
welche Implementierung genutzt werden soll. Diese Entscheidung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
kann unter Bercksichtigung funktionaler Gesichtspunkte getroffen werden.

Bei der Planung des Einsatzes von SSL muss auch bercksichtigt werden, dass
es in diesem Fall in der Regel notwendig sein wird, den Apache-Webserver
aus den Quelltexten selbst zu kompilieren, da SSL in den meisten
Binrdistributionen nicht enthalten ist.
Serverzertifikat
Der private Schlssel des Server-Zertifikats sollte aus Sicherheitsgrnden
durch eine Passphrase geschtzt sein. Dies bedeutet, dass die Passphrase beim
Neustart des Servers eingegeben werden muss. Ein automatischer
unbeaufsichtigter Neustart des Servers ist somit nicht mglich. Dieser Aspekt
muss bei der Planung des Betriebs bercksichtigt werden.
- Ist geklrt, welche Art von Zertifikat fr den WWW-Server bentigt wird?
- Wird SSL auch zur Benutzer-Authentisierung verwendet? Falls ja, sind die
entsprechenden Rahmenbedingungen erfllt?
- Ist festgelegt, welche Implementierung von SSL eingesetzt werden soll?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.271 Festlegung einer Sicherheitsstrategie fr den

WWW-Zugang
heitsmanagement
Wird der Zugang zum WWW nicht ber eigenstndige Internet-PCs
(siehe Kapitel 5.8 Internet-PC) abgewickelt, sondern direkt ber die
Arbeitsplatz-Rechner, so muss fr diesen Bereich eine eigene
Sicherheitsstrategie festgelegt werden.
In der Sicherheitsstrategie fr die WWW-Nutzung sollten die folgenden Fra-
gen beantwortet werden:
- Wer erhlt WWW-Zugang?
- Unter welchen Bedingungen bzw. zu welchem Zweck darf auf das WWW
zugegriffen werden?
- Ist eine Benutzerschulung erforderlich und falls ja, wie wird sie durchge-
fhrt?
- Wie wird technische Hilfestellung fr die Benutzer gewhrleistet?
Durch organisatorische Regelungen oder durch die technische Umsetzung sind
dabei insbesondere die folgenden Punkte zu gewhrleisten:
- Die Browser der Benutzer mssen durch den Administrator so vorkonfi-
guriert sein, dass ohne weiteres Zutun der Benutzer maximale Sicherheit
erreicht werden kann (siehe auch M 5.45 Sicherheit von WWW-Browsern).
- Dateien, deren Inhalt Ansto erregen knnte, drfen weder auf WWW-
Servern eingestellt noch nachgefragt werden. Es muss festgelegt werden,
welche Inhalte als anstig gelten.
- Nach dem Download von Dateien sind diese explizit auf Computer-Viren
zu berprfen.
Alle Regelungen und Bedienungshinweise zur WWW-Nutzung sind schrift-
lich zu fixieren und sollten den Mitarbeitern jederzeit zur Verfgung stehen.
Ein entsprechendes Muster findet sich auf der CD-ROM zum
IT-Grundschutzhandbuch im Verzeichnis Hilfsmittel
Die Benutzer mssen vor der WWW-Nutzung geschult werden, sowohl in der
Nutzung ihrer WWW-Browser als auch des Internets, um Fehlbedienungen zu
vermeiden und die Einhaltung der organisationsinternen Richtlinien zu ge-
whrleisten. Insbesondere mssen sie hinsichtlich mglicher Gefhrdungen
und einzuhaltender Sicherheitsmanahmen sensibilisiert werden.
- Existiert eine Sicherheitsstrategie fr den Betrieb eines WWW-Servers?
- Existiert eine Sicherheitsstrategie fr die Nutzung von WWW-Diensten?
- Sind die getroffenen Regelungen ausreichend?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.272 Einrichtung eines WWW-Redaktionsteams

Verantwortlich fr Umsetzung: Leiter IT, Fachverantwortliche
Ein Webangebot bentigt regelmige Pflege. Vor allem dann, wenn Inhalte
oder Dienste angeboten werden, die sich hufiger ndern, wird der Pflegeauf-
wand relativ schnell anwachsen.
Im Konzept fr das Webangebot (siehe M 2.172 Entwicklung eines Konzeptes
fr die WWW-Nutzung) werden Verantwortliche fr verschiedene Aspekte der
Pflege des Webangebots benannt. berschreitet der Umfang des Angebots
und der damit verbundene Pflegeaufwand ein bestimmtes Ma, so kann es
sinnvoll sein, zur besseren Koordination eine eigenstndige WWW-Redaktion
einzurichten. Auf diese Weise werden die Verantwortlichkeiten noch einmal
betont und sichtbar in der Organisationsstruktur abgebildet.
Die Einrichtung einer WWW-Redaktion bietet den Vorteil, dass ein zentraler zentraler Anlaufpunkt
Kontakt fr alle Fragen, die das Webangebot betreffen, zur Verfgung steht.
Innerhalb einer solchen Redaktion knnen meist einfacher effiziente Prozesse
zur Sicherstellung der Aktualitt und Korrektheit der Informationen im Web-
angebot (beispielsweise bestimmte Freigabeprozesse oder ein Vieraugen-
prinzip) etabliert werden, als wenn dies ber verschiedene Organisationsein-
heiten hinweg geschehen msste.
Die Redaktion sollte mindestens diejenigen Personen umfassen, die im
WWW-Konzept als Verantwortliche genannt wurden. Oft ist es sinnvoll,
weitere Personen in die Redaktion einzubinden. Eine WWW-Redaktion sollte
folgende Mitglieder umfassen:
- einen Chefredakteur, der die Gesamtverantwortung fr die Inhalte und
Dienste im Webangebot bernimmt,
- fr die verschiedenen inhaltlichen Bereiche jeweils einen Fachredakteur,
- einen Verantwortlichen fr das optische Erscheinungsbild (Webdesign) des
Webangebots,
- einen "technischen Webmaster", der fr die technischen Aspekte des Be-
triebs des Webservers zustndig ist.
Falls auf dem Webserver umfangreichere Webanwendungen eingesetzt
werden, so sollte auch fr diese Anwendungen ein Ansprechpartner in der
WWW-Redaktion vertreten sein. Die Fachredakteure, der Webdesigner und
der technische Webmaster dienen jeweils als Ansprechpartner (Schnittstelle)
zu den jeweiligen Fachbereichen.
Innerhalb der WWW-Redaktion mssen neben den normalen Redaktionspro-
zessen auch Vorgehensweisen und Zustndigkeiten fr den Fall von Prob-
lemen festgelegt werden, damit eine schnelle und effiziente Reaktion auf
Sicherheitsvorflle gewhrleistet ist (siehe auch M 2.173 Festlegung einer
WWW-Sicherheitsstrategie).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.273 Zeitnahes Einspielen sicherheitsrelevanter

Patches und Updates
Hufig werden Fehler in Software-Produkten bekannt, die dazu fhren
knnen, dass die Sicherheit der IT-Systeme, auf denen diese Produkte
installiert sind, beeintrchtigt wird. Diese Schwachstellen mssen so schnell
wie mglich behoben werden, damit sie nicht durch interne oder externe
Angreifer ausgenutzt werden knnen. Dies ist ganz besonders wichtig, wenn
die betreffenden Systeme mit dem Internet verbunden sind. Die Hersteller von
Betriebssystem- oder Software-Komponenten verffentlichen in der Regel
Patches oder Updates, die auf dem jeweiligen IT-System installiert werden
mssen, um den oder die Fehler zu beheben.
Die Systemadministratoren sollten sich daher regelmig ber bekannt Auf dem Laufenden
bleiben
gewordene Software-Schwachstellen informieren (siehe auch M 2.35
Informationsbeschaffung ber Sicherheitslcken des Systems).
Wichtig ist, dass Patches und Updates, wie jede andere Software, nur aus Bezugsquellen kennen,
Integritt und
vertrauenswrdigen Quellen bezogen werden drfen. Fr jedes eingesetzte Authentizitt berprfen
System oder Softwareprodukt muss bekannt sein, wo Sicherheitsupdates und
Patches erhltlich sind. Auerdem ist es wichtig, dass Integritt und
Authentizitt der bereits installierten Produkte oder der einzuspielenden
Sicherheitsupdates und Patches berprft werden (siehe M 4.177
Sicherstellung der Integritt und Authentizitt von Softwarepaketen), bevor
ein Update oder Patch installiert wird. Vor der Installation sollten sie
auerdem mit Hilfe eines Computer-Virenschutzprogramms geprft werden.
Dies sollte auch bei solchen Paketen gemacht werden, deren Integritt und
Authentizitt verifiziert wurde.
Sicherheitsupdates oder Patches drfen jedoch nicht voreilig eingespielt Auch Updates und
Patches Testen
werden, sondern mssen vor dem Einspielen getestet werden. Falls sich ein
Konflikt mit anderen kritischen Komponenten oder Programmen herausstellt,
kann ein solches Update sonst zu einem Ausfall des Systems fhren.
Ntigenfalls muss ein betroffenes System so lange durch andere Manahmen
geschtzt werden, bis die Tests abgeschlossen sind.
Vor der Installation eines Updates oder Patches sollte stets eine Backup
Datensicherung des Systems erstellt werden, das es ermglicht, den
Originalzustand wieder herzustellen, falls Probleme auftreten. Dies gilt
insbesondere dann, wenn ausfhrliche Tests aus Zeitgrnden oder mangels
eines geeigneten Testsystems nicht durchgefhrt werden knnen.
In jedem Fall muss dokumentiert werden, wann, von wem und aus welchem Dokumentation
Anlass Patches und Updates eingespielt wurden (siehe auch M 2.34
Dokumentation der Vernderungen an einem bestehenden System). Aus der
Dokumentation muss sich der aktuelle Patchlevel des Systems jederzeit
schnell ermitteln lassen, um beim Bekanntwerden von Schwachstellen schnell
Klarheit darber zu erhalten, ob das System dadurch gefhrdet ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Falls festgestellt wird, dass ein Sicherheitsupdate oder Patch mit einer anderen
wichtigen Komponente oder einem Programm inkompatibel ist oder Probleme
verursacht, so muss sorgfltig berlegt werden, wie weiter vorgegangen wird.
Wird entschieden, dass auf Grund der aufgetretenen Probleme ein Patch nicht
installiert wird, so ist diese Entscheidung auf jeden Fall zu dokumentieren.
Auerdem muss in diesem Fall klar beschrieben sein, welche Manahmen
ersatzweise ergriffen wurden, um ein Ausnutzen der Schwachstelle zu
verhindern. Eine solche Entscheidung darf nicht von den Administratoren
alleine getroffen werden, sondern sie muss mit den Vorgesetzten und dem IT-
Sicherheitsbeauftragten abgestimmt sein.
- Wissen die Administratoren, von wo sie sicherheitsrelevante Patches und
Updates beziehen knnen?
- Werden Sicherheitsupdates und Patches vor dem Einspielen berprft und
getestet?
- Wie werden die Vernderungen durch Updates und Patches dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.274 Vertretungsregelungen bei E-Mail-Nutzung

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Administrator
Fr die Bearbeitung von E-Mail ist - ebenso wie bei jeder anderen Aufgabe -
fr jeden Mitarbeiter ein Vertreter zu benennen. Bei geplanter Abwesenheit
sollten die Benutzer dann fr den Vertreter eine E-Mail-Weiterleitung ein-
richten oder den Zugriff auf ihr Postfach freigeben. Bei spontaner Abwesen-
heit, z. B. wegen Krankheit, knnen andere Regelungen die zeitnahe E-Mail-
Bearbeitung sicherstellen. Beispielsweise kann das Vorzimmer der betroffe-
nen Abteilung die IT-Verantwortlichen informieren, die dann wiederum am E-
Mail-Server eine Weiterleitung schalten. Dies ist allerdings nur dann zulssig,
wenn klar geregelt ist, dass E-Mail nur dienstlich genutzt werden darf. Die
Benutzer sollten auerdem per E-Mail ber die Weiterleitung informiert wer-
den. Sobald sie wieder im Haus sind, sollten sie den IT-Verantwortlichen
mitteilen, dass die Weiterleitung aufgehoben werden kann.
Alternativ knnen grundstzlich auch aufgabenbezogene E-Mail-Adressen
eingerichtet werden. Auch hier muss natrlich sichergestellt sein, dass einge-
hende E-Mail jederzeit zeitnah bearbeitet wird.
Viele E-Mail-Clients bieten die Mglichkeit, vor einer lngeren Abwesenheit Autoreply / Abwesen-
heitsassistent
einen Dienst zu aktivieren (Autoreply, unter Outlook Abwesenheitsassistent),
der dafr sorgt, dass jeder Absender einer E-Mail whrend der vorgegebenen
Abwesenheitszeiten eine Nachricht erhlt, dass dieser Empfnger vorberge-
hend nicht zu erreichen ist. Dies hat oft Vorteile, fhrt aber hufig dazu, dass
zu viele Informationen ber den Benutzer und die Organisation breit gestreut
nach auen gegeben werden.
Andererseits wird der Absender trotz einer solchen Benachrichtigung ber die
Abwesenheit meistens im unklaren darber gelassen, wie mit seiner E-Mail
weiter umgegangen wird. Es stellt sich dann die Frage, ob die E-Mail also bis
auf weiteres unbearbeitet bleibt oder an einen Vertreter weitergeleitet wurde.
Daher sollten alle Benutzer darauf achten, dass weder die genaue Zeit der
Abwesenheit noch Informationen ber Interna weitergegeben werden, wie
Telefonnummern oder Organisationseinheiten. Diese lassen sich fr Angriffe
ber Social Engineering weiterbenutzen (siehe G 5.42 Social Engineering).
Auf jeden Fall sollten aber Vertreter fr alle lngeren Abwesenheitsphasen
benannt werden. Dies kann auch Externen ber solche Mechanismen wie den
Abwesenheitsassistent mitgeteilt werden, so dass sie wissen, dass die E-Mail
angekommen ist und bearbeitet wird.
Hinweis: Die meisten E-Mail-Programme mit Autoreply-Funktion bieten
auch die Mglichkeit, die Benachrichtigung nach Kriterien, die die Benutzer
selbst festlegen knnen, zu steuern. Damit kann dann beispielsweise voreinge-
stellt werden, dass interne E-Mail-Absender andere Antworten erhalten als
externe. Hierfr werden in der Regel aber tiefere Kenntnisse des E-Mail-
Clients bentigt. Wenn daher Regeln zur Steuerung von Autoreply-Funktio-
nen eingesetzt werden sollen, sollten die Administratoren dies entsprechend
fr die Benutzer vorbereiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist geregelt, wie Vertretungsregelungen bei E-Mail umgesetzt werden?
- Wissen alle Benutzer, wie sie Vertretungsregelungen bei den E-Mail-
Clients aktivieren knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.275 Einrichtung funktionsbezogener E-Mailadressen

In vielen Organisationen werden Geschftsprozesse inzwischen ganz oder
teilweise per E-Mail abgewickelt. Dabei ist es wichtig, dass Nachrichten
rechtzeitig den richtigen Empfnger erreichen. Durch Urlaub, Dienstreisen,
Krankheit oder personelle Vernderungen knnen zu unterschiedlichen Zeit-
punkten aber ganz verschiedene Personen fr die Bearbeitung einer E-Mail
zustndig sein.
Daher sollten fr bestimmte Funktionen organisations- bzw. funktionsbezo-
gene E-Mail-Adressen eingerichtet werden, um unabhngig von Personen die
Zustellung zur richtigen Organisationseinheit zu garantieren. Dies ist insbe-
sondere bei zentralen Anlaufstellen wichtig. Dieser Ansatz hat u. a. folgende
Vorteile:
- E-Mails an funktionsbezogene Adressen knnen gegebenenfalls direkt an
Stellvertreter verteilt werden. Dadurch kann auch bei Abwesenheit des
Hauptansprechpartners eine zgige Bearbeitung erreicht werden. Werden
E-Mails an funktionsbezogene Adressen nicht direkt an den jeweiligen An-
sprechpartner weitergeleitet, sondern in eigenen Postfchern abgelegt, so
hat dies einen zustzlichen Vorteil im Bezug auf Datenschutz. In diesem
Fall braucht nmlich im Fall einer ungeplanten Abwesenheit (beispiels-
weise Unfall, Krankheit) des eigentlichen Empfngers nicht dessen per-
snliches Postfach "geffnet" zu werden.
- Bei einem Wechsel der Zustndigkeit mssen nicht alle Kommunikations-
partner informiert werden. In diesem Fall mssen lediglich alle E-Mails,
die an die funktionsbezogene E-Mail-Adresse gerichtet sind, an die neuen
Ansprechpartner weitergeleitet werden.
- Funktionsbezogene E-Mail-Adressen knnen aussagekrftig benannt wer-
den, z. B. beratung@..., webmaster@..., vertrieb@..., und lassen sich da-
durch oft leichter merken als personenbezogene Adressen.
- Durch die Adressierung an die funktionsbezogene E-Mail-Adresse knnen
die Empfnger auch unabhngig vom Betreff (Subject) erkennen, um
welches Thema es in der E-Mail wahrscheinlich geht.
Fr verschiedene Funktionen, die direkt mit dem Betrieb einer Internet-Do-
main zusammen hngen, wird darber hinaus die Existenz gewisser funkti-
onsbezogener E-Mailadressen (beispielsweise postmaster) in den relevanten
De-Facto-Standards (IETF RFCs, hier insbesondere die RFC 822 und
RFC 2142) explizit gefordert (siehe auch M 2.120 Einrichtung einer
Poststelle).
Werden organisations- oder funktionsbezogene E-Mailadressen eingefhrt, so Schema fr E-Mailadres-
sen festlegen
sollte ein geeignetes, nachvollziehbares Schema festgelegt werden, nach dem
diese Adressen gebildet werden. Dies ist vor allem bei organisationsbezoge-
nen Adressen wichtig, da solche Adressen eventuell nicht so "intuitiv" sind,
wie funktionsbezogene Adressen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Je nachdem, welche Softwareprodukte (Mailserver und -clients, eventuell Konfiguration dokumen-

Verzeichnisserver etc.) verwendet werden, wird die Einrichtung organisations- tieren
und funktionsbezogener E-Mailadressen auf unterschiedliche Art und Weise
erfolgen mssen. Dabei sollte die Konfiguration so dokumentiert werden, dass
es im Falle eines Totalausfalls des Mailsystems mglich ist, die Konfiguration
auf einem Ersatzsystem so "nachzubauen", dass keine Nachrichten verloren
gehen. Zumindest muss dokumentiert sein, welche organisations- und funkti-
onsbezogenen Adressen existieren und zu welchem Zweck sie dienen.
- Existieren die in RFC 822 geforderten technischen Funktionsadressen?
- Existieren Vertretungsregelungen fr alle funktions- und organisationsbe-
zogenen E-Mailadressen?
- Ist ein Schema festgelegt, nach dem funktions- und organisationsbezogene
E-Mailadressen gebildet werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.276 Funktionsweise eines Routers

In groen Netzen kann kaum auf den Einsatz von Routern verzichtet werden.
Router werden sowohl in lokalen Netzen als auch in Weitverkehrsnetzen
eingesetzt (siehe auch Kapitel 7.6 Remote Access). Ohne den Einsatz von
Routern wre das Internet nicht funktionsfhig.
Router knnen gleichzeitig unterschiedliche Protokolle (z. B. IP, IPX) und
Topologien (z. B. Ethernet, Token Ring, FDDI, ATM, Frame Relay, ISDN)
untersttzen. Dadurch sind Router in der Lage, lokale Netze nahtlos mit
Weitverkehrsnetzen zu verbinden. Nicht zuletzt diese Funktion von Routern
hat mit dazu beigetragen, dass sich das Internet in der Vergangenheit so rasch
entwickeln konnte.
Ein Router bernimmt im wesentlichen zwei Aufgaben. Zum einen wird eine
geeignete Verbindung zwischen dem Quellsystem beziehungsweise Quellnetz
und dem Zielsystem beziehungsweise Zielnetz ermittelt und zum anderen
werden Datenpakete entlang dieser Verbindung transportiert. Wenn das
Zielsystem (Zielnetz) direkt an dem Router angeschlossen ist - d. h. Router
und Zielsystem befinden sich im selben Subnetz - wird das vom Quellsystem
gesendete Datenpaket direkt an das Zielsystem gesendet.
Abbildung 1: Routing
Wenn das Zielsystem (Zielnetz) nicht direkt am Router angeschlossen ist, Next Hop
sendet der Router das Datenpaket an einen benachbarten Router, der nher am
Zielsystem (Zielnetz) angeschlossen ist, den sogenannten Next Hop. Der letzte
Router in dieser Verbindungskette ist immer direkt am Zielnetz angeschlossen
und sendet das Datenpaket zum Zielsystem.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 2: Routing
Die Aufgabe eines Routers ist es, eintreffende Datenpakete entweder direkt an
den adressierten Empfnger zu bergeben, oder in das nchste Netz
weiterzuleiten. In welches Netz das Datenpaket weitergeleitet wird, wenn es
nicht direkt zugestellt werden kann, entscheidet die sogenannte Routing-
Metrik. Die Metrik ist ein Ma fr die Qualitt der Verbindung zwischen dem
Sender bzw. dem Router und dem Ziel des Paketes. Mit ihrer Hilfe entscheidet
der Router, an welchen Next Hop er das Paket weitergibt. Routing-Metriken
beziehen sich nicht ausschlielich auf die Lnge des Weges zwischen Sender
und Empfnger, sondern knnen auch andere Merkmale, wie beispielsweise
die Qualitt der Leitungen, die Bandbreite oder die Auslastung in die
Entscheidung mit einbeziehen. Welche Kriterien verwendet werden, ist von
dem verwendeten Routing-Protokoll abhngig.
Die Routing-Informationen werden in sogenannten Routing-Tabellen Routing-Tabellen
verwaltet. Routing-Tabellen enthalten Informationen darber, ber welche
benachbarten Router als Next Hop fr bestimmte Zielnetze dienen knnen.
Router treffen die Entscheidung, an welchen Next Hop ein empfangenes
Datenpaket weitergegeben wird, ausschlielich auf Basis dieser Routing-
Tabellen. Deswegen ist es besonders wichtig, diese Tabellen vor
Manipulationen zu schtzen. Es sind eine Reihe von Angriffen bekannt,
welche die Manipulierbarkeit von Routing-Tabellen ausnutzen. In der
folgenden Abbildung ist der Inhalt einer Routing-Tabelle beispielhaft
dargestellt.
Abbildung 3: Beispielhafter Ausschnitt aus einer Routing-Tabelle

In diesem Beispiel wrde der Router ein Paket mit der Zieladresse
210.23.125.98 an den Next Hop 210.23.122.4 weiterleiten. Der sogenannte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hop Count gibt an, wie viele Zwischenstationen das Paket noch passieren
muss, um sein Ziel ber den betreffenden Next Hop zu erreichen. Sind fr ein
bestimmtes Ziel mehrere benachbarte Router als Next Hops verfgbar, so
kann der Hop Count als eine Routing-Metrik verwendet werden, um den
"gnstigsten" Next Hop zu bestimmen. Auch beim Routing Protokoll RIP
wird der Hop Count als Routing-Metrik verwendet.
Statisches und dynamisches Routing
Es wird in bezug auf das Routing zwischen statischem und dynamischem
Routing unterschieden. Diese beiden Methoden unterscheiden sich
hinsichtlich der Verwaltung der Routing-Tabellen.
Beim statischen Routing werden diese Tabellen manuell mit Hilfe von
Systembefehlen gepflegt.
Beim dynamischen Routing erfolgt die Pflege der Routing-Tabellen
automatisiert. Dies geschieht mit Hilfe von Routing-Protokollen. Hier wird
noch einmal zwischen den Interior Gateway Protokollen (IGP) und den
Exterior Gateway Protokollen (EGP) unterschieden. IGP wird innerhalb von
Netzen verwendet, die unter eigener Administrationsverantwortung stehen.
Die Zusammenfassung der unter eigener Verantwortung betriebenen Netze
wird auch als Routing-Domne bezeichnet. Mit Hilfe von EGP werden
Routing-Informationen zwischen unterschiedlichen Routing-Domnen
ausgetauscht.
Die folgende Abbildung stellt diesen Zusammenhang dar.
Abbildung 4: Austausch von Routing-Informationen

Die bekanntesten und standardisierten Routing-Protokolle sind das Routing Routing-Protokolle
Information Protocol (RIP), Open Shortest Path First (OSPF) und das Border
Gateway Protocol (BGP), wobei es sich beim Border Gateway Protocol um
ein Exterior Gateway Protokoll handelt. Erweitert werden diese Protokolle
durch proprietre Routing-Protokolle von unterschiedlichen Herstellern. Die
bekanntesten Protokolle sind das Interior Gateway Routing Protocol (IGRP)
und das Enhanced Interior Gateway Routing Protocol (EIGRP) des Herstellers
Cisco.
Da Routing-Protokolle die Verwaltung von Routing-Tabellen automatisieren,
haben Angreifer lngst erkannt, Sicherheitslcken dieser Protokolle
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
auszunutzen, um die Routing-Tabellen zu modifizieren und so Datenpakete

umzuleiten oder ganze Netze auer Betrieb zu setzen (siehe G 5.51
Missbrauch von Routing-Protokollen).
Bei der Implementierung eines dynamischen Routings zwischen Netzen ist in
erster Linie auf die Sicherheitsfunktionen der verwendeten Routing-Protokolle
zu achten (siehe M 5.112 Sicherheitsaspekte von Routing-Protokollen). Der
Administrator muss besonderen Wert auf die sichere Authentisierung der
benachbarten Router beim Austausch von Routing-Tabellen legen. Es sollten
nur Routing-Protokolle verwendet werden, die eine verschlsselte
Authentisierung beim Austausch von Routing-Tabellen untersttzen.
Der Aufwand der manuellen Pflege von Routing-Tabellen ist zu gro, um in
komplexen Netzen auf dynamisches Routing verzichten zu knnen. Der
Einsatz von dynamischem Routing ist vor der Inbetriebnahme unter dem
Gesichtspunkt der Sicherheit zu bewerten.
Allgemein sollte in Netzen mit hohem Schutzbedarf nach Mglichkeit kein Kein dynamisches
Routing bei hohem
dynamisches Routing verwendet werden. Kann auf dynamisches Routing aus Schutzbedarf
wichtigen Grnden nicht verzichtet werden, so sollten zumindest nur solche
Routing-Protokolle verwendet werden, die eine sichere Authentisierung der
beteiligten Gerte und eine gesicherte bertragung der Routing-Informationen
bieten.
In M 2.278 Typische Einsatzszenarien von Routern und Switches ist ein
weiteres Szenario beschrieben, in dem vom Einsatz von Routing-Protokollen
abgeraten wird.
Router als Paketfilter
Viele Router knnen auch fr die Filterung von Datenpaketen verwendet
werden, d. h. der Router wird als Paketfilter eingesetzt (siehe Kapitel 7.3
Sicherheitsgateway (Firewall) ).
Broadcast-Pakete werden von einem Router normalerweise nicht zwischen
verschiedenen angeschlossenen Netzen transportiert. Hierdurch teilt der
Router die angeschlossenen Netze in unterschiedliche Broadcast-Domnen
auf.
Router verfgen allerdings meist noch ber weitergehende Filterfunktionen.
Beispielsweise knnen sogenannte Access Control Lists (ACL) konfiguriert
werden. Der Router regelt anhand dieser Listen den Datenverkehr zwischen
den beteiligten Netzen. Weitergehende Sicherheitsaspekte bei Access Control
Lists sind in M 5.111 Einrichtung von Access Control Lists auf Routern zu
finden.
Der Einsatz von Paketfiltern ist als alleinige Methode zur Kontrolle des
Datenverkehrs zwischen Netzen mit einem unterschiedlichen Schutzbedarf
meist nicht ausreichend. Mehr Informationen finden sich im Kapitel 7.3
Sicherheitsgateway (Firewall) beispielsweise in M 2.73 Auswahl eines
geeigneten Firewall-Typs und M 2.74 Geeignete Auswahl eines Paketfilters.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Router als VPN-Gateway

Einige am Markt verfgbare Router untersttzen die Funktion Virtual Private
Network (VPN). Diese Router werden insbesondere dann eingesetzt, wenn
sensitive Daten ber ein Netz bertragen werden. Der Einsatz von Routern mit
VPN-Funktionalitt hat den Vorteil, dass anwendungsseitig keine
Verschlsselungsmechanismen vorhanden sein mssen. Die Verschlsselung
ist transparent fr die Kommunikationspartner. Allerdings findet die
Kommunikation auf der Strecke bis zum ersten verschlsselnden
Netzkoppelelement unverschlsselt statt und birgt damit ein Restrisiko.
Authentisierung ist hier nur zwischen den Koppelelementen mglich. Die
eigentlichen Kommunikationspartner werden nicht authentisiert (M 5.68
Einsatz von Verschlsselungsverfahren zur Netzkommunikation).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.277 Funktionsweise eines Switches

Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Leiter IT,
Einfhrung
Ursprnglich arbeiteten Switches auf der OSI-Schicht 2, mittlerweile sind
Switches mit unterschiedlichen Funktionen erhltlich. Hersteller kennzeichnen
Switches meist mit dem OSI-Layer, der untersttzt wird. Dadurch entstanden
die Begriffe Layer-2-, Layer-3- und Layer-4-Switch, wobei es sich bei Layer-
3- und Layer-4-Switches eigentlich funktional bereits um Router handelt. Die
ursprnglich unterschiedlichen Funktionen von Switches und Routern werden
auf einem Gert vereint. Dadurch wird die Abgrenzung der Gertetypen
(Switch oder Router) erschwert. Die wesentlichen Unterschiede dieser Gerte
sind in der Einleitung zum Kapitel 7.11 Router und Switches aufgefhrt.
Die ersten Switches entstanden aus den Bridges, die wie die modernen
Switches heutzutage zur Auftrennung groer LAN-Segmente in mehrere
kleine Segmente (Kollisionsdomnen) dienten. Bridges arbeiten in der Regel
mit der Store-and-Forward-Technologie. Dabei wird jeder empfangene
Ethernet-Frame eingelesen und dann anhand der Zieladresse entschieden, ob
er an ein anderes LAN-Segment weitergegeben wird. Handelt es sich um
lokalen Datenverkehr, erfolgt keine Weitergabe und der Frame gelangt nur zu
den Stationen im lokalen Netz. Damit wird der lokale Verkehr auf einzelne
Segmente begrenzt, was bei geeigneter Auslegung die Netzlast deutlich
reduzieren kann. Bei kleineren Segmenten sinkt zudem der Anteil an
Kollisionen und die Performance verbessert sich. Ist ein Frame an ein anderes
Segment weiterzuleiten, wird er im Zwischenspeicher der Bridge abgelegt und
anschlieend an den Zielport bergeben. Zustzlich kann beim Store-And-
Forward die Integritt eines empfangenen Frames mit Hilfe von CRC-
Prfsummen berprft werden. Korrupte Frames werden verworfen, was zu
einer weiteren Verringerung der Netzlast beitragen kann.
Switches verfgen neben dem Store-and-Forward-Switching auch ber den
Mechanismus des Cut-Through-Forward-Switching, bei dem nur die
Zieladresse - die ersten sechs Bytes eines Frames - gelesen wird. Hierdurch
reduziert sich die Verzgerung zwischen dem Empfnger- und Sendeport
erheblich. Allerdings ist es dabei nicht mglich, korrupte Frames auszufiltern.
Durch das unntige Weiterleiten fehlerhafter Frames kann eventuell ein
Engpass entstehen. Abhilfe schafft ein adaptives Verhalten des Switches, bei
dem der Frame whrend des Weiterreichens geprft wird. Damit werden zwar
korrupte Frames nicht ausgefiltert, aber der Switch kann die Qualitt der
Frames berwachen. bersteigt der Prozentsatz der korrupten Frames einen
vorher festgelegten Wert, so schaltet der Switch fr diesen Port auf Store-and-
Forward um, um in Zukunft zu filtern.
In der folgenden Abbildung ist beispielhaft eine sogenannte Switching-Tabelle Switching-Tabellen
dargestellt. In dieser Tabelle wird gespeichert, an welchem Port die Station
mit der entsprechenden MAC-Adresse angeschlossen ist. Der Switch lernt
diese Zuordnung dynamisch. Im Gegensatz zu einem Hub sendet der Switch
einen Ethernet-Frame immer nur an den Port, an dem der Zielrechner
angeschlossen ist. Dadurch wird die Bandbreite, die einem Gert zur
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verfgung steht, nicht von der Kommunikation zwischen anderen

angeschlossenen Stationen beeinflusst. Ein weiterer Effekt ist, dass die
Kommunikation zwischen zwei Stationen von keiner der anderen Stationen
mitgelesen werden kann. Davon ausgenommen sind Broadcasts und
Multicasts, die an alle angeschlossenen Stationen gesandt werden. Ebenso
werden Frames, deren Ziel-MAC-Adresse noch unbekannt ist, an alle Ports
weitergeleitet.
Abbildung 1: Switching-Tabelle
Ein Frame, der an die Station mit der MAC-Adresse 0001.02c4.fdca gerichtet
ist, wird vom Switch nur an den Port 01 weitergeleitet.
Da die Switching-Tabelle zur Steuerung des Datenflusses verwendet wird,
muss sie vor Manipulationen geschtzt werden. Es sind einige
Angriffsmethoden bekannt, die die Integritt und Verfgbarkeit dieser
Tabellen bedrohen (siehe G 5.112 Manipulation von ARP-Tabellen).
Layer-3- und Layer-4-Switches arbeiten analog auf einer entsprechend
hheren OSI-Schicht.
Sind in einem lokalen Netz mit einer komplizierten Topographie mehrere Spanning Tree
Switches vorhanden, so kann es vorkommen, dass fr die Verbindung
zwischen zwei Gerten mehrere mgliche Wege existieren. Switching
funktioniert aber nur dann, wenn zu jedem Zeitpunkt klar ist, an welchen Port
ein Paket weitergeleitet werden muss. Andernfalls besteht die Gefahr, dass im
Netz Schleifen (Loops) entstehen, auf denen Pakete immer im Kreis geschickt
werden und niemals ihr eigentliches Ziel erreichen. Deswegen bieten Switches
die Mglichkeit, automatisch untereinander eine logische Netzstruktur (einen
sogenannten Spanning Tree des Netzes) "auszuhandeln", die eine reibungslose
Funktion erlaubt. Zu diesem Zweck wird das sogenannte Spanning Tree
Protocol (STP, IEEE 802.1d) verwendet. berflssige Verbindungen im Netz
werden automatisch deaktiviert und nur dann wieder aktiviert, wenn die per
STP ermittelte primre Verbindung nicht verfgbar ist.
Hierzu muss jedem Switch eine Priorittsinformation und eine eindeutige
MAC-Adresse zugewiesen sein, es muss eine Multicast-Adresse fr alle
Switches existieren und jeder Port ber eine ID eindeutig identifizierbar sein.
Um den Broadcast-Verkehr in einem "geswitchten" Netz einzuschrnken, VLAN
lassen sich virtuelle Netze (VLANs) bilden. Hierbei wird innerhalb eines
physikalischen Netzes eine logische Netzstruktur abgebildet, in dem
funktionell zusammengehrende Arbeitsstationen und Server zu einem
virtuellen Netz verbunden werden. Die Grnde fr den Zusammenschluss zu
einem VLAN knnen organisatorischer oder technischer Art sein. Unter dem
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Aspekt der Unternehmensorganisation ist es beispielsweise mglich, alle

Mitarbeiter einer Abteilung in eine Netzgruppe zusammenzufassen, auch
wenn sie auf verschiedenen Etagen verteilt sind. Unter dem Aspekt der
Arbeitsorganisation knnen Mitarbeiter, die gemeinsam an einem Projekt
arbeiten, zu einer Netzgruppe zusammengefasst werden, auch wenn sie zu
verschiedenen Abteilungen gehren.
Jedes VLAN bildet eine separate Broadcast-Domne. Ein VLAN braucht nicht
auf einen einzelnen Switch beschrnkt zu sein, sondern es kann sich ber ein
ganzes geswitchtes Netz erstrecken. Die Netzbenutzer bilden dann nicht mehr
aufgrund ihres Standortes ein Netzsegment, sondern sie knnen innerhalb des
Intranets standortunabhngig mit anderen Nutzern zu einer Gruppe
zusammengefasst werden.
Es wird zwischen port- und hostbasierten VLANs unterschieden. Bei
portbasierten VLANs werden einzelne Anschlsse (Ports) an einem Switch
direkt einem VLAN zugeordnet. Das bedeutet, dass der zugeordnete
Anschluss unabhngig von der angeschlossenen Station fest einem
bestimmtem VLAN zugeordnet ist. Bei hostbasierten VLANs wird die
Zugehrigkeit eines VLANs beispielsweise ber die MAC-Adresse oder IP-
Adresse der angeschlossenen Station gesteuert. Bei hostbasierten VLANs hat
der Anwender die Mglichkeit, sein Endgert an jedem beliebigen Ort
innerhalb des Netzes anzuschlieen, ohne dass er die Zugehrigkeit zu seinem
VLAN verliert.
Die Mglichkeit, VLANs ber mehrere Switches auszudehnen, wird als Trunking
Trunking bezeichnet. Hierbei wird pro Switch ein physischer Port fr die
Inter-Switch-Kommunikation reserviert, die logische Verbindung zwischen
den Switches wird als Trunk bezeichnet. Trunking wird durch
unterschiedliche, teils proprietre Trunking-Protokolle realisiert. Der Ethernet-
Rahmen wird beim Informationsaustausch zwischen den Switches in das
Trunking-Protokoll gekapselt. Dadurch ist der Ziel-Switch in der Lage, die
Information dem entsprechenden VLAN zuzuordnen. Als Standards werden
IEEE 802.1q und beispielsweise die proprietren Protokolle ISL (Inter Switch
Link) und VTP (VLAN Trunking Protokoll) des Herstellers Cisco verwendet.
Manchmal wird auch die Bndelung (Zusammenfassung) mehrerer Vorsicht
Begriffsverwirrung
physikalischer Verbindungen zwischen Switches zur Erzielung entsprechend
hherer Durchsatzraten als Trunking bezeichnet. Diese Funktionalitt wird
andererseits auch als "Channel Bonding" oder "Channeling" bezeichnet. Wenn
in einem Dokument der Begriff Trunking auftaucht, so muss deswegen stets
darauf geachtet werden, in welcher Bedeutung der Begriff gerade verwendet
wird. In diesem Kapitel wird unter Trunking stets die Mglichkeit verstanden,
VLANs ber mehrere Switches zu verteilen.
Die folgende Abbildung zeigt eine Konfiguration mit zwei Switches, die ber
einen Trunk-Port verbunden sind. Der Rechner, der am linken Switch
ebenfalls an einem Trunk-Port angeschlossen ist, stellt ein potentielles
Sicherheitsrisiko dar, da er Zugriff auf die Daten aus allen VLANs hat, die auf
dem Switch konfiguriert sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 2: Trunking
Erstreckt sich ein VLAN ber mehrere Switches, so steigt in der Praxis der
Datenverkehr zwischen diesen Komponenten um den Anteil der mit Hilfe des
Trunking- Protokolls bertragenen Informationen. Die Kommunikation
zwischen Teilnehmern unterschiedlicher VLANs erfolgt ber OSI-Schicht 3,
das heit die Pakete werden VLAN bergreifend geroutet. Das Routing kann
auf einem Switch durchgefhrt werden, der Routing-Funktionen untersttzt
(siehe auch den Abschnitt zu Layer-3-Switches in der Einleitung zum Kapitel
7.11 Router und Switches), oder auf einem angeschlossenen Router erfolgen,
der die VLANs auf der OSI-Schicht 3 verbindet.
Die folgenden Abbildungen zeigen Beispiele fr ein (port-basiertes) VLAN,
das sich ber drei verschiedene Etagen eines Gebudes erstreckt und fr eine
Konfiguration mit zwei verschiedenen VLANs auf einem Switch.
Abbildung 3: Beispiel fr ein VLAN

Entgegen den Aussagen einiger Hersteller muss bercksichtigt werden, dass
VLANs nicht entwickelt wurden, um Sicherheitsanforderungen bei der
Trennung von Netzen zu erfllen. VLANs bieten eine Vielzahl von
Angriffspunkten, so dass insbesondere fr die Trennung von
schutzbedrftigen Netzen immer zustzliche Manahmen umzusetzen sind. In
der folgenden Beispiel-Abbildung kann nicht von einer sicheren Trennung
zwischen dem VLAN 1 und VLAN 2 ausgegangen werden, da die beiden
VLANs auf dem selben Switch realisiert sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 4: Zwei VLANs auf einem Switch

Auf einem Switch sollten keine VLANs mit unterschiedlichem Schutzbedarf
konfiguriert sein. Soll dies aus wichtigen Grnden trotzdem geschehen, so
mssen in jedem Fall zustzliche Sicherungsmanahmen ergriffen werden, um
ein angemessenes Sicherheitsniveau zu gewhrleisten. Keinesfalls darf das
Netz einer DMZ, die zwischen dem internen Netz und dem Internet steht, als
VLAN auf dem selben Switch wie das interne Netz konfiguriert sein.
In der folgenden Abbildung wurde eine sichere Trennung von zwei VLANs
mit unterscheidlichem Schutzbedarf realisiert, indem pro Switch lediglich ein
VLAN konfiguriert wurde. Die Kopplung der Netze wird von einem Router
bernommen, der als Paketfilter fungiert.
Abbildung 5: Sichere Trennung von VLANs

- Existieren VLANs mit unterschiedlichem Schutzbedarf? Falls ja: Wie ist
die Trennung der VLANs realisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.278 Typische Einsatzszenarien von Routern und

Switches
Der Einsatzzweck von Routern bestimmt mageblich die Konfiguration der
Systeme. Zudem bestimmt die Verwendung auch die zustzlichen Funktionen,
die von einem Router bereit gestellt werden mssen.
Router im internen Netz
Router sind in vielen Installationen als reine LAN-to-LAN-Router im Einsatz,
um Subnetze zu verbinden und die Nebeneffekte von rein "geswitchten"
Netzen, beispielsweise sogenannte Broadcast-Strme, zu verhindern. In
dieser Funktion werden heute allerdings vermehrt Switches mit integrierter
Routing-Funktion (Layer-3- oder Layer-4-Switches, siehe auch M 2.277
Funktionsweise eines Switches) eingesetzt. Bei diesem Einsatzszenario hngen
die Sicherheitsanforderungen an den Router stark vom Schutzbedarf der
Teilnetze ab, die ber den Router verbunden sind.
Router zur Anbindung an externe Netze
Wird ein Router zur Anbindung des eigenen Netzes einer Organisation an
externe Netze eingesetzt, so spricht man von einem Border-Router. Oft sind
Border-Router auch in ein Sicherheits-Gateway integriert und bernehmen in
diesem die Funktion des externen Paketfilters (siehe unten). Bei Routern, die
an fremde Netze angeschlossen sind, spielt die Sicherheit des Gertes eine
besonders wichtige Rolle, da sie Angriffen von auen direkt ausgesetzt sind.
Router als Paketfilter
Router werden oft als Bestandteil von Sicherheits-Gateways zum Anschluss
an ffentliche Netze (beispielsweise das Internet) verwendet. Im folgenden
Beispiel besteht das Sicherheits-Gateway aus einem internen Paketfilter,
einem externen Paketfilter und einem Applikations-Gateway. Statt
Applikations-Gateways werden oft auch Stateful-Inspection-Systeme als
zentrale Teile von Sicherheits-Gateways eingesetzt. Die festgelegten
Filterregeln werden sowohl auf dem zentralen System als auch auf den
Routern (intern und extern) konfiguriert. Auf den Routern wird das Regelwerk
durch die Einrichtung von Access Control Lists (ACLs) etabliert.
Abbildung 1: Router als Paketfilter
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Funktion der Paketfilterung ist bei den meisten Routern bereits im
Betriebssystem integriert. Es gibt auch Router, die bereits eine integrierte
Stateful-Inspection-Firewall bereitstellen.
Es ist empfehlenswert, das Management der beteiligten Systeme (speziell die
Einrichtung von Filterregeln) mit Hilfe einer einheitlichen Benutzeroberflche
durchzufhren. Dies hilft Konfigurationsfehler vermeiden, die beispielsweise
Sicherheitslcher im Sicherheits-Gateway ffnen oder zu Strungen des
Netzbetriebs fhren knnen.
Anforderungen an einen Router fr diesen Einsatzzweck sind in M 2.73
Auswahl eines geeigneten Firewall-Typs zu finden.
Weiterhin sind bei der Konfiguration Vorgaben aus M 4.203 Konfigurations-
Checkliste fr Router und Switches als Mindestvoraussetzung zu
bercksichtigen. Der uere Paketfilter im aufgefhrten Beispiel ist direkt an
ein ffentliches Netz angeschlossen und damit einem erhhten Risiko
ausgesetzt. Deshalb muss dieser Router besonders restriktiv konfiguriert sein.
Anbindung von Auenstellen
Router knnen zur Anbindung von Auenstellen genutzt werden. In der
nachfolgenden Abbildung dienen die dargestellten Router zur Kopplung von
lokalen Netzen (LAN), die einen einheitlichen Schutzbedarf haben und unter
einer einheitlichen Administrationsverantwortung stehen. In diesen Fllen
werden zumeist keine oder nur schwache Filterregeln auf den Routern
konfiguriert. In kleinen Netzen knnen statische Routen verwendet werden,
whrend in mittleren oder groen Umgebungen Interior Gateway Protokolle
als Routing-Protokolle eingesetzt werden. Die beteiligten Router sind somit
Bestandteil einer abgeschlossenen Routing-Domne. Als
Verbindungstechnologien knnen ATM, Frame Relay, ISDN, DSL oder
Standardfestverbindungen genutzt werden.
Abbildung 2: Anbindung von Auenstellen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Remote Access
In kleinen und mittleren Netzen werden Router oftmals auch zur Einwahl in
lokale Netze (LAN) verwendet. Einwahlmglichkeiten sollten jedoch nicht
direkt in ein LAN integriert werden, sondern es sollte zumindest ein Einwahl-
Router eingesetzt werden, der entsprechende Sicherheitsfunktionalitt bietet,
um das LAN vor Angriffen ber die Einwahlzugnge zu schtzen.
Ein mglicher Weg zur Absicherung einer Einwahl mit Hilfe eines Routers ist
in der folgenden Abbildung dargestellt. Der Router wird in der DMZ eines
Sicherheits-Gateways betrieben. Zustzliche Sicherheit wird durch die
Authentisierung mit Hilfe eines RADIUS-Servers erreicht. Der Router
fungiert in diesem Fall als RADIUS-Client. Remote-User authentisieren sich
nicht direkt am Router, sondern am RADIUS-Server. Dadurch knnen
Benutzer zentral am RADIUS-Server verwaltet werden.
Durch die Verwendung eines One-Time-Passwort-Verfahrens (OTP) in
Kombination mit einem Hardware-Token oder einer Smart-Card, wird eine
starke Authentisierung erreicht. RADIUS-Server untersttzen in der Regel die
Erweiterung von OTP-basierenden Verfahren durch die Installation von Plug-
Ins oder durch die Kommunikation mit einem OTP-Server. Eine weitere
Mglichkeit zur Erreichung einer starken Authentisierung ist die Einbindung
der Remote-Access-Lsung in eine bestehende Public Key Infrastructure
(PKI). Der RADIUS-Server muss in diesem Fall fr den Zugriff auf einen
Verzeichnisdienst konfiguriert sein. Dadurch lsst sich in Kombination mit
einer Smart-Card eine zertifikatsbasierende starke Verschlsselung erreichen.
Weiterfhrende Manahmen sind im Baustein 7.6 Remote Access und 8.4
LAN-Anbindung eines IT-Systems ber ISDN beschrieben.
Abbildung 3: Remote Access

VPN
Eine weitere Mglichkeit Standorte sicher miteinander zu verbinden, ist die
Nutzung von virtuellen privaten Netzen (VPN). Ein VPN ist ein gesicherter
Tunnel, der ber bestehende Netzinfrastrukturen gefhrt wird. Somit
ermglicht der Einsatz von VPNs eine sichere bertragung von vertraulichen
Informationen ber unsichere Netze (z.B. das Internet). Der Datenverkehr
zwischen zwei Endpunkten innerhalb eines VPN wird verschlsselt. VPN-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
fhige Router sollten eine starke Verschlsselung (z.B. 3DES, AES)

untersttzen. Viele am Markt verfgbare Router untersttzen die VPN-
Funktionalitt.
IPSec ist ein Standard, der ber eine Reihen von RFCs und Internet-Drafts der
IEEE definiert wird. Auf der Basis von IPSec lassen sich VPNs zwischen
Gerten unterschiedlicher Hersteller konfigurieren. IPSec stellt die
Datenvertraulichkeit, Datenintegritt und die Authentisierung zwischen den
Endpunkten des VPN sicher. IPSec basiert auf der Netzschicht des OSI-
Referenzmodells. Es nutzt das Internet Key Exchange (IKE) zur Ausfhrung
der Protokoll-Algorithmusvereinbarung entsprechend der lokalen
Konfiguration und zur Erzeugung der Verschlsselungs- und
Authentisierungsschlssel. Eine weitere VPN-Technologie, die auf einem
Standard beruht, ist das sogenannte "SSL-VPN", bei dem der Datenverkehr
ber eine mit SSL/TLS gesicherte Verbindung geleitet wird.
Neben VPNs auf der Basis von IPSec und SSL existieren verschiedene andere,
sowohl proprietre, als auch Open Source Technologien. Dabei muss beachtet
werden, dass diese meist untereinander nicht kompatibel und teilweise nur fr
bestimmte Plattformen verfgbar sind.
Falls die beteiligten Komponenten die Einbindung in eine bestehende PKI
ermglichen, kann dadurch die Verwaltung von VPNs (speziell das
Schlsselmanagement) wesentlich erleichtert und die Skalierbarkeit verbessert
werden.
Es wird zwischen einem Site-to-Site-VPN und einem Client-to-Site-VPN Site-to-Site und Client-
to-Site VPN
unterschieden. Ein Site-to-Site-VPN dient zur Verbindung von Netzen. Dabei
wird das VPN auf beiden Seiten durch entsprechend konfigurierte, VPN-
fhige Router begrenzt. Diese Art von VPNs ist eine Alternative zur
Verbindung von lokalen Netzen ber Weitverkehrsstrecken.
Bei einem Client-to-Site-VPN wird ein VPN zwischen einem Client und
einem VPN-fhigen Router aufgebaut. Dazu muss auf dem Client meist eine
herstellerspezifische VPN-Client-Software installiert werden. Ein Client-to-
Site-VPN ist als eine weitere Alternative des Remote-Zugangs zu lokalen
Netzen anzusehen.
In der folgenden Abbildung ist beispielhaft eine VPN-Architektur dargestellt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 4: Beispiel fr eine VPN-Architektur

Es wird zwischen einem Site-to-Site-VPN und einem Client-to-Site-VPN
unterschieden. Bei einem Site-to-Site-VPN terminieren auf beiden Seiten
VPN-fhige Router das VPN. Netze werden mit Hilfe der VPN-Technik
verbunden. Diese Art von VPNs ist eine Alternative zur Verbindung von
lokalen Netzen ber Weitverkehrsstrecken.
Bei einem Client-to-Site-VPN wird ein VPN zwischen einem Client und
einem VPN-fhigen Router aufgebaut. Dazu wird auf dem Client eine meist
herstellerspezifische VPN-Client-Software installiert. Ein Client-to-Site-VPN
ist als eine weitere Alternative des Remote-Zugangs zu lokalen Netzen
anzusehen.
Switches
Der Einsatzzweck eines Switches zur Bildung von VLANs ist in der
Manahme M 2.277 Funktionsweise eines Switches beschrieben. Die folgende
Abbildung zeigt ein typisches geswitchtes Netz.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abbildung 5: Geswitchtes Netz mit Backbone- und Access-Switches

In der Abbildung sind zwei Arten von Switches zu unterscheiden. Die Access-
Switches, die sich durch eine hohe Anzahl von Anschlssen (Ports)
auszeichnen, stellen den unmittelbaren Anschluss der Endgerte sicher. Die
Access-Switches sind wiederum an zentrale Backbone-Switches
angeschlossen.
Die Backbone-Switches bilden das so genannte Switched-Backbone. Ein
Switched-Backbone bndelt die Bandbreite der angeschlossenen Switches, um
eine hohe Durchsatzrate zwischen den Endgerten sicherzustellen. Ein
Switched-Backbone zeichnet sich also durch eine hohe Durchsatzrate aus. Der
Durchsatz eines Switched-Backbones hngt von einigen Faktoren ab, die bei
der Anschaffung von Gerten zu bercksichtigen sind. Die wichtigsten
Faktoren sind der maximale Adresscache zur Vorhaltung der dynamisch
erlernten MAC-Adressen, der Durchsatz der Backplane eines Backbone-
Switches sowie die Leitungsgeschwindigkeit des Switched-Backbone.
Die beteiligten Switches mssen in einer Architektur hnlich der Abbildung
dynamisch erlernte Switching-Tabellen austauschen, um die Verbindung
zwischen Endgerten, die an unterschiedlichen Switches angeschlossen sind,
effizient herstellen zu knnen. Dies geschieht mit zumeist
herstellerabhngigen (proprietren) Protokollen (z. B. Cisco Discovery
Protocol CDP).
In groen geswitchten Netzen werden Switches typischerweise kaskadiert.
Dies wird in der Praxis mit Hilfe des sogenannten Uplink-Ports erreicht.
- Ist der Einsatzzweck der zu beschaffenden Netzkomponente definiert?
- Wo soll der Router eingesetzt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welche Funktionen (VPN, Remote Access, Paketfilterung) soll der Router

untersttzen?
- Wurden Anforderungen fr den Einsatz der Router definiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.279 Erstellung einer Sicherheitsrichtlinie fr Router

und Switches
heitsmanagement
Da Router und Switches zentrale Elemente eines Netzes sind, ist der sichere
und ordnungsgeme Betrieb besonders wichtig. Dieser kann nur sicherge-
stellt werden, wenn das Vorgehen in die bestehenden sicherheitstechnischen
Vorgaben integriert ist.
Die zentralen sicherheitstechnischen Anforderungen (das zu erreichende
Sicherheitsniveau) ergeben sich aus der organisationsweiten
Sicherheitsleitlinie und sollten in einer spezifischen Sicherheitsrichtlinie fr
Router und Switches formuliert werden, um die bergeordnet und allgemein
formulierte Sicherheitsleitlinie im gegebenen Kontext zu konkretisieren und
umzusetzen.
In diesem Zusammenhang ist zu prfen, ob neben der organisationsweiten
Sicherheitsleitlinie weitere bergeordnete Vorgaben wie bspw. IT-Richtlinien,
Passwortrichtlinien oder Vorgaben zur Internetnutzung zu bercksichtigen
sind.
Die Sicherheitsrichtlinie muss allen Personen und Gruppen, die an der Be-
schaffung und dem Betrieb von Routern und Switches beteiligt sind, bekannt
sein und Grundlage fr deren Arbeit sein. Wie bei allen Richtlinien sind ihre
Inhalte und ihre Umsetzung im Rahmen einer bergeordneten Revision re-
gelmig zu prfen.
Die Sicherheitsrichtlinie sollte zunchst das generell zu erreichende Sicher-
heitsniveau spezifizieren und grundlegende Aussagen zum Betrieb von Rou-
tern und Switches treffen. Nachfolgend sind einige Punkte aufgefhrt, die
bercksichtigt werden sollten:
- Allgemeine Konfigurationsstrategie ("Liberal" oder "Restriktiv")
- Regelungen fr die Arbeit der Administratoren und Revisoren:
- ber welche Zugangswege drfen Administratoren und Revisoren
auf die Syteme zugreifen (beispielsweise nur lokal an der Konsole,
ber ein eigenes Administrationsnetz oder ber verschlsselte
Verbindungen)?
- Welche Vorgnge werden mssen dokumentiert werden? In welcher
Form wird die Dokumentation erstellt und gepflegt?
- Gilt fr bestimmte nderungen ein Vieraugenprinzip?
- Nach welchem Schema werden Administrationsrechte vergeben?
- Vorgaben fr Beschaffung von Gerten anhand eines Anforderungsprofils
- Vorgaben fr die Installation und Konfiguration
- Vorgehen bei der Erstinstallation
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- berprfung der Default-Einstellungen hinsichtlich

Sicherheitsgefhrdungen
- Regelungen zur physikalischen Zugriffskontrolle
- Verwendung und Konfiguration von Konsole und sonstigen
Zugriffsarten
- Regelungen zur Benutzer- und Rollenverwaltung,
Berechtigungsstrukturen (Ablauf und Methoden der Authentisierung
und Autorisierung, Berechtigung zu Installation, Update,
Konfigurationsnderungen etc.). Nach Mglichkeit sollte ein
Rollenkonzept fr die Administration erarbeitet werden.
- Regelungen zur Einrichtung und Nutzung von VLANs und VPNs
(beispielsweise: keine VLANs mit unterschiedlichem Schutzbedarf
auf einem Switch)
- Regelungen zu Erstellung und Pflege von Dokumentation, Form der
Dokumentation: Verfahrensanweisungen, Betriebshandbcher
- Falls allgemeine Vorgaben existieren: Zugelassene und nicht
zugelassene Dienste, Protokolle und Netze
- Vorgaben fr den sicheren Betrieb
- Absicherung der Administration (beispielsweise: Zugriff nur ber
abgesicherte Verbindungen)
- Einsatz von Verschlsselung (Standards, Schlsselstrken,
Einsatzbereiche)
- Vorgaben zu Passwortnutzung (Passwortregeln, durch Passwrter zu
schtzende Bereiche, Regeln und Situationen fr
Passwortnderungen, gegebenenfalls Hinterlegung von Passwrtern)
- Werkzeuge fr Betrieb und Wartung, Integration in ein bestehendes
Netzmanagement
- Berechtigungen und Vorgehensweisen bei Softwareupdates und
Konfigurationsnderungen
- Protokollierung
- Welche Ereignisse werden protokolliert?
- Wo werden die Protokolldateien gespeichert?
- Wie und in welchen Abstnden werden die Protokolle ausgewertet?
- Datensicherung und Recovery (siehe auch, M 6.91 Datensicherung und
Recovery bei Routern und Switches)
- Einbindung in das organisationsweite Datensicherungskonzept
- Strungs- und Fehlerbehandlung, Incident Handling
- Regelungen fr die Reaktion auf Betriebsstrungen und technische
Fehler (lokaler Support, Fernwartung)
- Regelungen fr Sicherheitsvorflle
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Notfallvorsorge (siehe auch M 6.92 Notfallvorsorge bei Routern und

Switches)
- Einbindung in das organisationsweite Notfallvorsorgekonzept
- Revision und Audit (Verantwortlichkeiten, Vorgehen, Integration in ein
bergreifendes Revisionskonzept)
Die Verantwortung fr die Sicherheitsrichtlinie liegt beim IT-Sicherheitsma-
nagement, nderungen und Abweichungen hiervon drfen nur in Abstim-
mung mit dem IT-Sicherheitsmanagement erfolgen.
Bei der Erstellung einer Sicherheitsrichtlinie ist es empfehlenswert, so vorzu-
gehen, dass zunchst ein Maximum an Forderungen und Vorgaben fr die
Sicherheit der Systeme aufgestellt wird. Diese knnen anschlieend den tat-
schlichen Gegebenheiten angepasst werden. Idealerweise wird so erreicht,
dass alle notwendigen Aspekte bercksichtigt werden. Fr jede im zweiten
Schritt verworfene oder abgeschwchte Vorgabe sollte der Grund fr die
Nicht-Bercksichtigung dokumentiert werden.
- Wurde eine Sicherheitsrichtlinie fr den Betrieb von Routern und Switches
erstellt?
- Wann wurde die Sicherheitsrichtlinie zum letzten Mal aktualisiert?
- Wurde ein Sicherheitsniveau in der Sicherheitsrichtlinie definiert?
- Wurden in der Sicherheitsrichtlinie Vorgaben zur Einrichtung, zum Betrieb
und zur Strungsbehandlung von Routern und Switches beschrieben?
- Wurden in der Sicherheitsrichtlinie unterschiedliche Einsatzzwecke der
Komponenten bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.280 Kriterien fr die Beschaffung und geeignete

Auswahl von Routern und Switches
Aktive Netzkomponenten unterscheiden sich in ihrem Leistungsumfang, den
angebotenen Sicherheitsmechanismen, Bedienkomfort und Wirtschaftlichkeit.
Werden bei der Beschaffung Fehler gemacht, so kann dies schwerwiegende
Folgen auf den sicheren Betrieb eines Netzes haben, da mit ungeeigneten
Gerten das angestrebte Sicherheitsniveau unter Umstnden nur schwer
erreichbar ist.
Bevor Router und Switches beschafft werden, muss daher eine
Anforderungsliste erstellt werden, anhand derer die am Markt erhltlichen
Produkte bewertet werden. Aufgrund der Bewertung kann dann eine fundierte
Kaufentscheidung erfolgen, die sicherstellt, dass das zu beschaffende Produkt
im praktischen Betrieb den Anforderungen gengt.
Aus dem Blickwinkel der IT-Sicherheit sind zentrale Anforderungen an aktive Zentrale Sicherheits-
anforderungen
Netzkomponenten, dass diese die Administration ber sichere Protokolle
erlauben und dass die Benutzerverwaltung des Gerts es erlaubt, das
organisationsweite Rollenkonzept entsprechend umzusetzen. Die
Anforderung, dass Passwrter nur verschlsselt im Gert gespeichert werden
drfen, sollte eigentlich eine Selbstverstndlichkeit sein, jedoch gibt es immer
noch Gerte, bei denen Passwrter im Klartext in Konfigurationsdateien
gespeichert werden mssen. Bei Neubeschaffungen sollten keine Gerte mehr
bercksichtigt werden, die keine sichere Administrationsmglichkeit bieten
und bei denen es nicht mglich ist, Passwrter verschlsselt abzuspeichern.
Auch rein funktionale Merkmale aktiver Netzkomponenten knnen
Auswirkungen auf die IT-Sicherheit haben. Meist ist dann der Grundwert
Verfgbarkeit betroffen, beispielsweise wenn ein Gert wegen unzureichender
Speicherausstattung nicht die erforderlichen Durchsatzraten erreicht.
Auerdem spielt die Untersttzung durch den Hersteller eine nicht zu
vernachlssigende Rolle, wenn es beispielsweise darum geht, dass zeitnah
Patches fr Sicherheitslcken zur Verfgung gestellt werden.
Nachfolgend werden einige grundstzliche Anforderungen bei der
Beschaffung von Routern und Switches aufgelistet. Anschlieend werden
noch einige spezielle Anforderungen getrennt fr Router und Switches
beschrieben.
Allgemeine Kriterien fr Router und Switches
1. Grundlegende funktionale Anforderungen
- Untersttzt das Gert alle bentigten Protokolle und Verkabelungstypen?
2. Sicherheit
- Untersttzt das System sichere Protokolle zur Administration?
Wenn Router und Switches nicht ber ein eigenes Administrationsnetz
administriert werden, mssen diese Gerte mit Hilfe von sicheren
Netzprotokollen (beispielsweise SSH2) konfigurierbar sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Untersttzt das System die verschlsselte Speicherung von Passwrtern?

Gerte, bei denen Passwrter unverschlsselt gespeichert werden, sollten
nicht mehr beschafft werden.
3. Wartbarkeit
- Bietet der Hersteller regelmige Updates und schnell verfgbare
Sicherheitspatches an?
Es ist insbesondere wichtig, dass der Hersteller zeitnah auf bekannt
gewordene Sicherheitsmngel reagiert.
Oft ist der Zugriff auf Updates und Untersttzungsleistungen vom
Hersteller nur in Verbindung mit einem gltigen Wartungsvertrag mglich.
- Knnen im Rahmen der Wartungsvertrge maximale Reaktionszeiten fr
die Problembehebung festgelegt werden?
Ein Wartungsvertrag ist nur dann geeignet, wenn mit den garantierten
Reaktions- und Wiederinbetriebnahmezeiten die festgelegten Ansprche an
die Verfgbarkeit der Gerte abgedeckt werden knnen.
- Bietet der Hersteller einen technischen Kundendienst (Hotline) an, der in
der Lage ist, sofort bei Problemen zu helfen?
Dieser Punkt sollte Bestandteil des abgeschlossenen Wartungsvertrags
sein. Beim Abschluss des Vertrags ist auf die Sprache der zur Verfgung
gestellten Hotline des Herstellers zu achten.
4. Zuverlssigkeit/Ausfallsicherheit
Der Hersteller sollte Erfahrungswerte bezglich der Zuverlssigkeit liefern
knnen, beispielsweise Mean Time Between Failures (MTBF), Mean Time
To Repair (MTTR).
- Bietet der Hersteller Hochverfgbarkeitslsungen an?
Wenn durch den Abschluss von Wartungsvertrgen die
Verfgbarkeitsanforderungen nicht abgedeckt werden knnen, muss das
System Hochverfgbarkeitslsungen untersttzen.
5. Benutzerfreundlichkeit
- Lsst sich das Produkt einfach installieren, konfigurieren, und
administrieren?
Es sollten darber hinaus Schulungen fr das Produkt angeboten werden.
6. Kosten
- Wie hoch sind die Anschaffungskosten der Gerte?
- Wie hoch sind die voraussichtlichen laufenden Kosten (Wartung, Betrieb,
Support)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese Kosten sollten bereits in der Beschaffungsphase mit bercksichtigt

werden. Der Inhalt der Wartungs- und Supportvertrge sollte geprft
werden (Reaktionszeiten, Hotline, Qualifikation des Personals, etc.).
- Wie hoch sind die voraussichtlichen laufenden Kosten fr das Personal?
- Mssen zustzliche Soft- oder Hardware-Komponenten angeschafft
werden (z. B. RADIUS-Server, Netz-Management-System)?
Diese Frage sollte bereits in der Planungsphase beantwortet werden. Wenn
beispielsweise bereits ein Netz-Management-System im Einsatz ist, sollte
die Kompatibilitt mit den zu beschaffenden Gerten geprft werden.
Zudem sollte der Aufwand zur Integration der Gerte in eine bestehende
Infrastruktur beachtet werden.
- Wie hoch sind die Kosten fr die Schulung von Administratoren?
7. Funktionalitt
- Kann das System sicher in die bestehende Netz-Management-Architektur
eingefgt werden?
Der Aufwand zur Integration sollte bercksichtigt werden. Der Hersteller
sollte MIB-Tables und Angaben zu den untersttzten NMS-Protokollen
liefern.
- Untersttzt das System NTP?
NTP ist besonders im Hinblick auf die Protokollierung von Bedeutung,
siehe auch M4.sgX/RSx Einsatz eines lokalen NTP-Servers zur
Zeitsynchronisation
- Untersttzt das System die Einbindung von Authentisierungsservern
(beispielsweise RADIUS oder TACACS+)?
Ist bereits ein Authentisierungsserver im Einsatz, so sollte das System
diesen nutzen knnen.
8. Protokollierung
- Welche Mglichkeiten der Protokollierung sind vorhanden?
Die angebotenen Mglichkeiten zur Protokollierung mssen mindestens
die in der Sicherheitsrichtlinie festgelegten Anforderungen erfllen.
Insbesondere sind die folgenden Punkte relevant:
- Ist der Detailgrad der Protokollierung konfigurierbar?
- Werden durch die Protokollierung alle relevanten Daten erfasst?
- Untersttzt das System zentrale Protokollierung (z. B. syslog)?
Router und Switches sollten eine zentrale Protokollierung
untersttzen, um eine gezielte Auswertung der Log-Dateien
sicherstellen zu knnen.
- Kann die Protokollierung so erfolgen, dass die Bestimmungen des
Datenschutzes erfllt werden knnen?
- Werden Alarmierungsfunktionen untersttzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Angriffe auf Router und Switches sollten durch Alarmierungsfunktionen

der Gerte zentral und zeitnah gemeldet werden. Dies kann beispielsweise
auf Basis eines Netz-Management-Systems geschehen.
9. Infrastruktur
- Abmessungen und Kompatibilitt mit Schutzschrnken
Auch der Platzbedarf von Routern und Switches ist bei der Beschaffung zu
bercksichtigen. Kann das Gert in die vorgesehenen Schutzschrnke
eingebaut werden (Formfaktor, Gewicht, Befestigungselemente)?
- Stromversorgung und Abwrme
Vom Hersteller sollten Angaben zum Stromverbrauch und zu den
Anforderungen an die Umgebungstemperatur verfgbar sein. Reicht die
vorhandene Kapazitt der Stromversorgung und der USV aus? Reicht die
vorhandene Khlleistung zur Abfuhr der Abwrme des Gerts aus?
Besondere Kriterien fr Switches
1. Performance und Skalierbarkeit
- Kann das System den Ansprchen an die Performance gerecht werden?
Vom Hersteller sollten Angaben zum Datendurchsatz verfgbar sein,
insbesondere sollte der Maximal-Durchsatz der Switch-Backplane beachtet
werden. Weitere Gren, die Einfluss auf die Performance haben knnen,
sind die Gre des Adress-Cache und des Speichers.
- Wie gro ist die Anzahl der bereitgestellten Ports?
Ein Access-Switch sollte ber eine ausreichende Anzahl von Ports zum
Anschluss von Endgerten verfgen. Oft lassen sich die
Anschaffungskosten von unterschiedlichen Switches anhand der Kosten
pro Port vergleichen.
- Ist das System "stackable" oder (beispielsweise durch zustzliche
Einschubkarten) modular erweiterbar?
Zustzlich erforderliche Funktionen oder der Bedarf an einer hheren
Portdichte sollten nicht dazu fhren, dass Gerte vorzeitig ausgetauscht
werden mssen.
2. Funktionalitt
- Untersttzt der Switch Layer-3-Switching (Routing)?
In lokalen Netzen kann diese Funktion im Hinblick auf die Performance
(Datendurchsatz) vorteilhaft sein.
- Untersttzt der Switch VLANs?
Bei der Nutzung von VLANs sollte der Hersteller Angaben zum
verwendeten Standard machen.
- Untersttzt der Switch Cut Through oder/und Store and Forward?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Besondere Kriterien fr Router

1. Performance und Skalierbarkeit
- Kann das System den Ansprchen an die Performance gerecht werden?
Vom Hersteller sollten Angaben zum Datendurchsatz verfgbar sein. Falls
der Router als VPN-Endpunkt eingesetzt werden soll, sind auch die
untersttzten Verschlsselungsverfahren und die Performance beim Ver-
und Entschlsseln der Daten wichtige Performance-Kriterien.
- Ist das Gert modular erweiterbar?
Die Anzahl der im Standardumfang bereitgestellten Interfaces,
insbesondere die maximale Anzahl von untersttzten Interfaces sollte
2. Funktionalitt
- Untersttzt der Router VPN-Funktionalitt?
Ein Router mit VPN-Funktionalitt sollte den IPSec-Standard und starke
Verschlsselungsalgorithmen (3DES, AES) untersttzen.
- Untersttzt der Router die Nutzung von ACLs?
Die Filterfunktionen der zu beschaffenden Router sind zu bercksichtigen
(siehe auch M 5.111 Einrichtung von Access Control Lists auf Routern,).
- Welche Routing-Protokolle werden untersttzt?
Der Router sollte sichere Routing-Protokolle untersttzen (siehe auch
M 5.112 Sicherheitsaspekte von Routing-Protokollen).
- Wurden Anforderungen zur Beschaffung von Routern und Switches
definiert?
- Wurde dabei auf unterschiedliche Einsatzzwecke der Gerte geachtet?
- Wurden die Anforderungen schriftlich hinterlegt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.281 Dokumentation der Systemkonfiguration von

Routern und Switches
Die Konfiguration von Routern und Switches wird meist mittels
Konfigurationsdateien vorgenommen, die auf dem Gert gespeichert sind.
Router und Switches besitzen eine Reihe von Konfigurationsoptionen, die fr
den sicheren Betrieb wichtig sind. Bei der Erstinstallation beziehungsweise im
Auslieferungszustand sind diese Einstellungen mit Default-Werten belegt.
Die Konfiguration, die bei der Inbetriebnahme des Gerts vorgenommen wird, Grundkonfiguration
dokumentieren
muss so dokumentiert werden, dass sie jederzeit vom Administrator oder
seinem Vertreter nachvollzogen werden kann. Insbesondere dann, wenn eine
Konfiguration von einem Default-Wert abweicht, sollte in einem Kommentar
in der Konfigurationsdatei festgehalten werden, warum die Einstellung so
gewhlt wurde.
Jede nderung der Konfiguration sollte vom Administrator nachvollzogen nderungen
dokumentieren
werden knnen. Es wird empfohlen, mindestens folgende Punkte zu
dokumentieren:
- Welche nderung wurde durchgefhrt?
- Warum wurde die nderung durchgefhrt (Anlass)?
- Wann wurde diese nderung durchgefhrt (Uhrzeit, Datum)?
- Wer hat die nderung durchgefhrt?
Die Dokumentation der nderungen kann ebenfalls durch Kommentare in der
Konfigurationsdatei erfolgen. Dabei ist es jedoch in der Regel sinnvoll, zu
jeder Option nur die jeweils letzte nderung in der Datei selbst zu speichern.
Zustzlich dazu sollten zumindest alle sicherheitsrelevanten Vollstndiges Protokoll
der sicherheitsrelevan-
Konfigurationsnderungen in einem Protokoll gespeichert werden, anhand ten nderungen
dessen sich jederzeit nachvollziehen lsst, wie das Gert zu einem bestimmten
Zeitpunkt konfiguriert war. Dieses Protokoll sollte nicht auf dem Gert selbst
gespeichert werden.
Zur Erleichterung der Dokumentation und Protokollierung kann ein
Revisions- und Versionskontrollsystem wie beispielsweise CVS eingesetzt
werden. Ein solches System bietet den zustzlichen Vorteil, dass notfalls eine
frhere Konfiguration einfach wieder hergestellt werden kann.
Netzmanagement-Systeme zur zentralen Administration bieten in der Regel
ebenfalls eine integrierte Dokumentations- und Protokollfunktion.
Es ist empfehlenswert, die Dokumentation so zu gestalten, dass sie auch von
einem Fachmann, der mit den konkreten Gegebenheiten der Systemlandschaft
nicht vertraut ist, nachvollzogen werden kann.
Die Konfigurationsdateien sollten zur der Notfallvorsorge zustzlich zentral
auf einem dafr vorgesehenen Server gespeichert werden. Fr die zentrale
Verwaltung von Konfigurationsdateien werden oft TFTP-Server verwendet.
TFTP-Server sollten jedoch nur in einem abgesicherten Administrationsnetz
betrieben werden, weil der Dienst TFTP eine Reihe von Schwachstellen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
beinhaltet (siehe auch G 2.87 Verwendung unsicherer Protokolle in

ffentlichen Netzen). Eine Alternative dazu ist die bertragung per SCP (siehe
auch M 5.64 Secure Shell).
- Werden Konfigurationsdateien zentral verwaltet?
- Werden Konfigurationsdateien hinsichtlich der o. a. Punkte dokumentiert?
- Wird ein Versionskontrollsystem eingesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.282 Regelmige Kontrolle von Routern und

Switches
Zur Sicherstellung des ordnungsgemen Betriebs der aktiven
Netzkomponenten und der Korrektheit aller Konfigurationsparameter ist ein
regelmiger, mglichst automatisierter, Kontrollprozess zu etablieren. Hierzu
gehren beispielsweiseregelmige Funktionstests, Veranlassen von
nderungen und Prfung der Umsetzung sowie die berprfung der Logfiles
und Alarme.
Um die im laufenden Betrieb entstehende groe Menge an relevanten Daten
effektiv verarbeiten zu knnen, ist meist der Einsatz geeigneter Werkzeuge fr
eine mglichst weit automatisierte Kontrolle erforderlich. Dies kann
beispielsweise durch die Einbindung in ein Netzmanagementsystem (NMS)
geschehen.
Checkliste fr die Kontrolle
Fr die Kontrolle kann die Checkliste in M 4.203 Konfigurations-Checkliste
fr Router und Switches verwendet werden. Als Basis sollte die erstellte
Sicherheitsrichtlinie fr Router und Switches dienen (siehe M 2.279
Erstellung einer Sicherheitsrichtlinie fr Router und Switches). Zustzlich
sollten folgende Punkte im Rahmen des Kontrollprozesses bercksichtigt
werden:
Was wird getestet bzw. kontrolliert?
- Die generelle Funktionsfhigkeit von Gerten wird im Normalfall
regelmig durch den Administrator im laufenden Betrieb geprft.
- Die Integritt von Konfigurationsdateien sollte in regelmigen Abstnden
geprft werden. Die Sicherheitsrichtlinie fr Router und Switches sollte
eine regelmige berprfung mit Festlegung von Verantwortlichkeiten
vorschreiben.
- Der Stand der Datensicherung (zentral gespeicherte Konfigurationsdateien)
sollte regelmig vom Administrator geprft werden.
- Die Systemdokumentation sollte laufend vom Administrator aktualisiert
werden. Die Aktualitt kann im Rahmen von Audits geprft werden.
Hierzu sind auch M 2.31 Dokumentation der zugelassenen Benutzer und
Rechteprofile und M 2.64 Kontrolle der Protokolldateien zu bercksichtigen.
Wie wird getestet?
- Durch die Einbindung der Komponenten in ein Netzmanagement-System
kann eine regelmige Kontrolle sichergestellt werden.
Sicherheitsverletzungen, Ausflle und Fehlfunktionen knnen mit Hilfe
von Alarmierungsfunktionen des NMS zeitnah erkannt werden.
- Im Rahmen von Audits erfolgt meist eine stichprobenartige Kontrolle von
Komponenten. Als Basis fr ein Audit dient die erstellte
Sicherheitsrichtlinie fr Router und Switches. Wichtiger Bestandteil einer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
solchen Untersuchung ist die Aktualitt der Systemdokumentation, Stand

der Datensicherung, Passwortwechsel, etc. Unter Zuhilfenahme der
Checkliste aus M 4.203 Konfigurations-Checkliste fr Router und Switches
kann ein Groteil der sicherheitsrelevanten Einstellungen abgefragt
werden.
- Es existiert eine Reihe frei verfgbarer Sicherheits-Tools (z. B. Nessus),
welche die Sicherheitseinstellungen auf Routern und Switches prfen
knnen. Solche Tools knnen auf einem Rechner im Netz installiert sein.
Es sollte nach Mglichkeit die aktuellste Version verwendet werden. Als
Betriebssystem ist oft Unix/Linux notwendig. Von diesem System aus
kann der Administrator entsprechende Router und Switches scannen, um
somit eine Vielzahl von Einstellungen dieser Gerte zu prfen.
Kommerzielle Tools bieten teilweise recht komfortable Auswertungen und
Mglichkeiten zur Historienverfolgung der durchgefhrten Scans.
- Eine Vielzahl von Sicherheitsunternehmen bieten regelmige
berprfungen von Routern und Switches an. Durch turnusmige
Berichte und Auswertungen erhlt der Betreiber einen berblick ber den
Zustand der Komponenten.
Wann wird getestet?
- Der Administrator prft laufend und meist automatisiert die Funktion der
Gerte mit Hilfe eines NMS-Systems. Die Systemdokumentation ist vom
Administrator laufend aktuell zu halten.
- Der Stand der Datensicherung, die Integritt der Konfigurationsdateien und
weitere Daten zur Konfiguration sollten vom Administrator regelmig
(wchentlich) geprft werden.
- Scans mit der Hilfe von Sicherheits-Tools sollten nach Installation
regelmig (monatlich) durch den Administrator vorgenommen werden.
Die Ergebnisse sind zu prfen und zu archivieren.
- Die Prfung der Einhaltung von Sicherheitsrichtlinien muss regelmig
erfolgen (z. B. jhrlich im Rahmen von Sicherheits- oder
Grundschutzaudits).
Wer testet?
- Der Administrator sollte laufend Prfungen durchfhren (Funktion der
Komponenten, Stand der Datensicherung, Integritt der
Konfigurationsdateien, Scans, etc.).
- Die Prfung der Einhaltung von Sicherheitsrichtlinien bzw. von
Sicherheitsmanahmen aus dem Grundschutzhandbuch im Rahmen von
Sicherheits- bzw. Grundschutzaudits darf nicht durch den Administrator
durchgefhrt werden, sondern hat abhngig vom etablierten Sicherheits-
managementprozess durch den Grundschutzauditor, IT-
Sicherheitsbeauftragten oder den Revisor zu erfolgen.
Welche Informationen bilden die Grundlage der Kontrolle?
- Sicherheitsrichtlinie fr Router und Switches
- Protokolldateien von Routern und Switches
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Systemdokumentation (siehe M 2.281 Dokumentation der

Systemkonfiguration von Routern und Switches)
- IT-Sicherheitskonzept
- IT Grundschutzhandbuch
- Ergebnisse von durchgefhrten Scans
berprfung der Konfiguration
Bei der Einrichtung der Router und Switches sind alle Default-Einstellungen
zu prfen und falls notwendig zu modifizieren. Hierbei werden beispielsweise
nicht bentigte Dienste deaktiviert und Voreinstellungen den betrieblichen
und sicherheitstechnischen Anforderungen angepasst. Eine Erluterung der
hierfr notwendigen Schritte findet sich in M 4.201 Sichere lokale
Grundkonfiguration von Routern und Switches und M 4.202 Sichere Netz-
Grundkonfiguration von Routern und Switches.
Die Umsetzung der Vorgaben zum Umgang mit Default-Einstellungen sind im
Rahmen von regelmigen Audits zu berprfen. Hierdurch knnen
versehentliche oder vorstzliche Vernderungen festgestellt und die
Umsetzung von aktuellen Empfehlungen der Hersteller verifiziert werden.
Dies kann ausgehend von der fr jeden Gertetyp beziehungsweise fr jede
Betriebssystemversion zu erstellenden Installationsanleitung erfolgen und
sollte am jeweiligen Gert verifiziert werden. Hierbei ist jedoch zu beachten,
dass Betriebssystem-Kommandos bei manchen Herstellern nicht alle Default-
Einstellungen anzeigen. Aus diesem Grund empfiehlt es sich, separate
Software-Tools einzusetzen, um eine vollstndige Analyse durchzufhren.
Fr einen umfassenden Test aller Gerte knnen Softwareprodukte eingesetzt
werden, die einen automatisierten Test mit konfigurierbaren Parametern
ermglichen.
Mirror Port
Zur Analyse des Datenverkehrs gibt es die Mglichkeit, einen Port des
Routers oder des Switches als "Mirror Port" zu konfigurieren. Dabei wird der
gesamte Datenverkehr eines beliebigen Ports auf den Mirror Port repliziert
und kann mit entsprechenden Analyseprogrammen ausgewertet werden. Im
Gegensatz zu anderen Analysemethoden wird der Datenverkehr dabei nicht
unterbrochen oder beeintrchtigt.
Der Mechanismus bietet zwei Analysemethoden: Spiegelung des gesamten
Datenverkehrs fr einen definierten Port oder Spiegelung des Datenverkehrs
fr eine MAC-Adresse. Im zweiten Fall wird das gesamte Datenvolumen,
welches mit einer definierten Quell- und/oder Ziel-MAC-Adresse ber das
Gert luft, auf den Mirror Port gespiegelt.
Der Mirror Port darf keinem produktiven VLAN und keiner Spanning Tree
Group (STG) angehren. Standardmig muss "Port Mirroring" ausgeschaltet
sein. Der Zugriff auf die Konfiguration des "Port Mirroring" ist zu schtzen.
Nach der Verwendung des Mirror Ports ist dieser wieder zu deaktivieren. Es
ist regelmig zu prfen, ob die Funktion Port Mirroring im Regelbetrieb
deaktiviert ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist die regelmige Kontrolle von Routern und Switches Bestandteil der
Sicherheitsrichtlinie?
- Welches Prfintervall wurde festgelegt?
- Wann und von wem wurden Router und Switches das letzte Mal geprft?
- Wurde die Prfung dokumentiert?
- Wurden entsprechende Aktionen aus der Prfung abgeleitet und
Verantwortlichkeiten festgelegt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.283 Software-Pflege auf Routern und Switches

Jeglicher Betrieb von Software macht es notwendig, Betriebssystem und
Konfiguration regelmig zu berprfen und zu pflegen. Router und Switches
knnen hiervon nicht ausgenommen werden, um beispielsweise funktionale
Erweiterungen zu ermglichen, Softwarefehler zu beheben und Performance
und Sicherheit zu verbessern.
Dabei ist zu beachten, dass in der Praxis zur Pflege des Betriebssystems bei
Router und Switches oftmals ein kompletter Austausch der
Betriebssystemsoftware erforderlich ist. Das Einspielen von Updates oder
Patches ist in vielen Fllen nicht mglich. Wie bei allen
Konfigurationsnderungen ist mit angemessener Sorgfalt vorzugehen, da eine
unsachgeme Durchfhrung Beeintrchtigungen der Funktion und der
Sicherheit der Gerte zur Folge haben kann. Insofern gehrt zur sorgfltigen
Planung einer nderung immer auch eine Fallback-Strategie.
Einspielen neuer Software
Bei der Vorbereitung von Updates sind folgende Punkte zu beachten:
- Es muss ein geeignetes Zeitfenster vorgesehen werden. Der bentigte
Aufwand sollte nicht unterschtzt werden und vorsichtshalber eine
ausreichende Down-Time eingeplant werden.
- Die vom Hersteller beigefgten Hinweistexte (Release Notes) des neuen
Release sind sorgfltig zu lesen.
- Bei neuen Softwareversionen sind eventuell einzelne Features nicht mehr
enthalten oder funktionieren nicht korrekt. Manchmal ndern sich auch
Defaulteinstellungen.
- Neue Versionen eines Programmes und insbesondere eines
Betriebssystems mssen vor der Inbetriebnahme sorgfltig getestet werden,
um die volle Funktionalitt sicher zu stellen.
- Neue Programme oder Betriebssysteme sind unter Umstnden weniger
performant, beispielsweise wegen zustzlicher Features oder hherem
Speicherbedarf. Dies kann zu Problemen fhren, wenn ein Router oder
Switch bereits vor dem Upgrade an der Auslastungsgrenze betrieben
wurde.
Viele Hersteller bieten zur Planung der Erweiterung Konfigurationswerkzeuge
an. Diese ermglichen es, ausgehend vom benutzen Gert eine Konfiguration
zu planen und die bentigten Hardwarebestandteile wie Interfaces und
Speicher auszuwhlen.
Bei der Durchfhrung von Updates sollten folgende Schritte durchgefhrt
werden:
- Beschaffung des Updates aus vertrauenswrdiger Quelle. Normalerweise
sollten Updates nur vom Hersteller bezogen werden. Falls der Hersteller
fr die Updates Prfsummen zur Verfgung stellt oder die Update-Pakete
digital signiert, so sollten die Prfsummen oder Signaturen berprft
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden (siehe auch M 2.273 Zeitnahes Einspielen sicherheitsrelevanter

Patches und Updates und M 4.177 Sicherstellung der Integritt und
Authentizitt von Softwarepaketen).
- berprfung der Integritt und Funktion des Updates
- Trennung des Gertes vom produktiven Netz oder Deaktivierung aller
Schnittstellen
- Nach Mglichkeit Sicherung der bestehenden Konfiguration und des
Betriebssystems
- Einspielen des Updates
- Test
- Re-Aktivierung des Gertes im Netz
nderung der Konfiguration
Konfigurationsnderungen knnen sowohl direkt am Gert an der System-
Konsole (online) als auch auf einem eigenen Management-Rechner mit einem
entsprechenden Konfigurationsprogramm oder einem Texteditor (offline)
vorgenommen werden. Beide Vorgehen haben Vor- und Nachteile, generell ist
jedoch die Offline-Konfiguration zu bevorzugen.
Die Online-Konfiguration kann in der Regel nur wenig komfortabel und ohne
Zuhilfenahme von Tools erfolgen, beispielsweise ist das Einfgen von
Kommentaren nicht immer mglich. Dafr wird die Syntax zeitnah berprft.
Wenn die Erstellung von Konfigurationsdateien offline durchgefhrt wird,
stehen in der Regel komfortablere Werkzeuge zur Verfgung und es knnen
Kommentare eingefgt werden. Nachteil bei dieser Vorgehensweise ist, dass
oftmals Passworte im Klartext in die Konfigurationsdateien eingetragen
werden mssen. Da die Passworte in der Konfigurationsdatei - und damit auch
der bei bertragung ber das Netz auf das Gert, sofern keine verschlsselte
Verbindung verwendet wird - lesbar sind, sollten diese sofort nach dem
Einspielen der Konfigurationsdatei gendert werden. Eine andere Mglichkeit
besteht darin, Passworte online zu setzen und die Konfiguration anschlieend
inklusive der verschlsselten Passworte auszulesen.
Um sicher zu stellen, dass bei einem Boot-Vorgang aus dem Speicher die
aktuelle Konfiguration eingelesen wird, muss die genderte Konfiguration
gespeichert werden, nachdem sie in das Gert geladen wurde.
Bei manchen Gerten knnen Konfigurationsdateien fr eine zentrale
Administration auch auf separaten Servern gehalten und von dort geladen
werden. Dies kann sowohl manuell als auch automatisiert - beispielsweise
beim Bootvorgang - geschehen. nderungen knnen somit automatisiert an
die Gerte verteilt werden. Das Laden beim Bootvorgang ist jedoch wegen der
Mglichkeit zur mutwilligen Strung, seiner Fehleranflligkeit und der
entstehenden Netzlast nicht empfehlenswert und wird nur selten genutzt. Die
Sicherung und Verwaltung der Konfigurationsdateien hingegen sollte ber
einen derartigen zentralen Server erfolgen.
In jedem Fall muss der Administrationsrechner, auf dem die Offline-
Konfiguration vorgenommen wird beziehungsweise auf dem die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Konfigurationsdaten gehalten werden, vor unbefugtem Zugriff besonders

geschtzt werden.
- Sind Sicherheitslcken eingesetzter Betriebssystemversionsstnde
bekannt?
- Werden veraltete Versionen verwendet?
- Wann wurde die letzte Aktualisierung durchgefhrt?
- Wie findet die Informationsbeschaffung ber Sicherheitslcken der
eingesetzten Systeme statt?
- Wird vor der Konfigurationsnderung eine Sicherung durchgefhrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.284 Sichere Auerbetriebnahme von Routern und

Switches
Auf aktiven Netzkomponenten gespeicherte Konfigurations- oder Log-Dateien
enthalten eine Vielzahl von Informationen ber das Netz, die Infrastruktur, die
Organisation und eventuell auch ber Personen im Unternehmen. Wenn ein
Gert an Externe weitergegeben wird (etwa an den Hersteller oder den Service
bei einem Garantieaustausch oder an einen etwaigen Kufer), dann knnen
diese Informationen ausgewertet werden.
Beispielsweise knnen folgende Informationen aus Konfigurationsdateien
gewonnen werden:
- Verwendete Protokolle (insbesondere Routing-Protokolle), IP-Adressen
und Subnetze
- VLAN-Konfiguration
- Access Control Lists
- Passwrter und SNMP Community Strings
- Name und Kontaktdaten des Administrators (Banner)
Wegen der Sensibilitt dieser Informationen ist darauf zu achten, dass die
Dateien vor der Auerbetriebnahme oder dem Austausch defekter oder
veralteter Gerte gelscht beziehungsweise unlesbar gemacht werden. Die
Vorgehensweise hngt dabei stark vom Hersteller des Gertes ab. In der
Sicherheitsrichtlinie fr Router und Switches sollten hierfr entsprechende
Verantwortlichkeiten definiert werden.
Viele Gerte untersttzen die Funktion des "Factory-Resets". Durch einen
Befehl oder durch das Bettigen eines Schalters werden die Komponenten auf
die werksmigen Default-Einstellungen zurck gesetzt. Dabei ist allerdings
zu beachten, dass dieser Reset nicht zwangslufig alle gespeicherten
Einstellungen auf den ursprnglichen Zustand zurcksetzt. Eine anschlieende
Kontrolle ist daher zwingend erforderlich. Auf anderen Gerten knnen
Konfigurationsdateien durch entsprechende Befehle komplett gelscht oder
durch andere Dateien ersetzt werden. Sollten die eingesetzten Gerte ber
keine der erwhnten Funktionen verfgen, ist eine individuelle
Umkonfiguration oder die physikalische Zerstrung des Speichers
erforderlich.
Gespeicherte Protokolldateien knnen auf einigen Gerten ebenfalls mit Hilfe
des "Factory-Resets" gelscht oder berschrieben werden. Dies ist allerdings
als Ausnahme zu betrachten. Hufig kann eine Protokolldatei mit einem
entsprechenden Befehl gelscht werden. Vor der Auerbetriebnahme eines
Gertes sollte daher besonders darauf geachtet werden, dass keine Log-
Dateien mehr vorhanden sind. Sollten die eingesetzten Gerte ber keine der
erwhnten Funktionen verfgen, ist eventuell die physikalische Zerstrung des
Speichers erforderlich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Oft sind Router und Switches von auen mit IP-Adressen, Hostnamen oder
sonstigen technischen Informationen beschriftet. Auch diese Beschriftung
sollte vor der Entsorgung entfernt werden.
- Ist die sichere Entsorgung von Gerten in der Sicherheitsrichtlinie fr
Router und Switches bercksichtigt?
- Werden Konfigurationsdateien und Log-Dateien vor der Entsorgung sicher
gelscht bzw. unlesbar gemacht?
- Wird die Beschriftung von den Gerten vor der Entsorgung entfernt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.285 Festlegung von Standards fr z/OS-

Systemdefinitionen
Die Festlegung von Standards fr die z/OS-Systemdefinitionen ist eine der
Voraussetzungen fr ein funktionierendes System-Management. Standards
untersttzen aber auch die Umsetzung von Sicherheitsregeln und deren
berwachung. Die folgenden Empfehlungen sollten dabei beachtet werden:
Vereinbarte z/OS-System-Standards mssen nachvollziehbar dokumentiert
sein. Die Dokumentation muss fr die Administratoren verfgbar sein.
Die Einhaltung der z/OS-System-Standards sollte regelmig berprft
werden.
Es sollte berlegt werden, eine Standardisierung fr die folgenden Objekte zu
vereinbaren:
- Account-Nummer
- in Jobs und fr USER oder STCs
- ACS-Routinen
- Allokierungs-Regeln
- Application-ID (IMS)
- Assembler-Standards
- Benutzergruppen-Kennzeichen
z. B. Netzadministration, Entwicklung, Test, Produktion und DB-
Administration
- COBOL-Compiler-Optionen
- Command-Character (Console)
- Command-Character (Terminal)
- Coupling-Facility-Namen
- Dateien
anzulegende Dateien sollten katalogisiert sein
- Datei-Namen
evtl. mit Unterscheidungsmerkmalen fr System, Entwicklung und
Produktion. Der letzte Qualifier legt in der Regel die Dateiart fest.
Kennzeichnung von Target- und DLIB-Dateien
- Datenbank-Namen
- DFSMS
DATA-CLASS, STORAGE-CLASS, MANGEMENT-CLASS,
STORAGE-GROUP, LLQ-Zuordnungen
- IMS-ID
- IMS-Start-Prozeduren
- Initiator-Klassen
- ISMF-Schutz-Festlegungen
- JES2
Job-Klassen, Initiator, Parameter
- JOBCAT und STEPCAT sollten nicht verwendet werden (IBM hat im
August 2004 angekndigt, den Support zu JOBCAT und STEPCAT ab
z/OS 1.7 einzustellen.)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Job-Namen
evtl. mit Unterscheidungsmerkmalen fr Entwicklung und Produktion
- Katalog-Namen
- LOGON-Prozeduren-Namen
- Member-Namen
evtl. mit Unterscheidungsmerkmalen fr Entwicklung und Produktion
- Output-Klassen
- PAGE-Datasets
- Parmlib-Member fr JESx
- Prozeduren-Namen
- RACF-Resource-Klassen
- SMF-Belegung (System Management Facility)
- SMP/E-Datei-Namen
- SMP/E-Umgebungen fr verschiedene Subsysteme
- SMP/E-Zonen-Datasets
- SMP/E-Zonen-Namen
- SMS-Datei-Namen
- SSID (Sub-System ID)
- Vermeidung von Standortkennzeichen
Standortkennzeichen haben sich im Rahmen von Umstrukturierungen und
Anwendungsverlagerungen nicht unbedingt als vorteilhaft erwiesen
- STC-Namen (Started Tasks)
- STEPCAT sollte nicht verwendet werden
- SVC-Belegung
- Sysplex-ID
- Systemdateien-Namen
- System-ID (mit Sysplex-Kennung)
- Table-Space-Namen
- TSO-LOGON-Prozeduren
- UNIT-Klassen
- USER-ID
- USERMODs
- Volume-Namen (System-Volumes, Anwendungs-Volumes)
In Abhngigkeit von den eingesetzten Subsystemen, Datenbanksystemen,
Software-Produkten und Anwendungen kann diese Liste noch durch weitere
Objekte ergnzt werden.
- Sind die vereinbarten Standards dokumentiert?
- Haben die Administratoren Zugang zu der Dokumentation der Standards?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.286 Planung und Einsatz von zSeries-Systemen

Verantwortlich fr Umsetzung: Administrator, Leiter IT
Planung
Vor der Anschaffung und Inbetriebnahme von zSeries-Systemen mssen
verschiedene planerische Ttigkeiten durchgefhrt werden. Fr die Planung
des Einsatzes der zSeries-Systeme sind folgende Empfehlungen bezglich der
Sicherheit zu beachten:
Infrastruktur
Der Standort der zSeries-Hardware muss in einem zutrittsgeschtzten
Rechenzentrum geplant werden. Empfehlungen fr die Infrastruktursicherheit
von Rechenzentren finden sich in Baustein 4.6 Rechenzentrum.
Hardware
Die Hardware-Ressourcen, die fr den Betrieb bentigt werden, mssen
geplant und in ihrer Kapazitt entsprechend den Anforderungen dimensioniert
werden. Dies betrifft die gesamte Hardware-Ausstattung, von der Anzahl der
Prozessoren, ber Kanle, Festplatten und Bandstationen bis hin zu Netz-
Komponenten (inklusive Netzanschlsse).
Betriebssysteme
Es ist zu klren, welches der mglichen Betriebssysteme (z/OS, zLinux ohne
Trgersystem, zLinux unter dem Trgersystem z/VM, etc.) fr die
Anforderungen der Anwendung zum Einsatz kommen muss.
Anforderung der Anwendungen
Die Anforderungen der Anwendungen an die Hardware und das
Betriebssystem mssen bei der Planung bercksichtigt werden:
- Wie viele Anwender werden auf die Anwendung gleichzeitig zugreifen?
- Wird ein Single-System oder ein Parallel-Sysplex System bentigt? (u. a.
eine Frage der Verfgbarkeit)
- Welches Datenvolumen wird durch den Betrieb der Anwendung anfallen?
(Festplatten, Magnetbandstationen)
- Welchen Schutzbedarf hinsichtlich Vertraulichkeit, Integritt und
Verfgbarkeit hat die Anwendung bzw. ihre Daten?
- Welche Netzanschlsse werden bentigt bzw. von wo erfolgen Zugriffe
(aus dem Internet, Intranet, eigene Netzumgebung)?
Prozesse
Es ist zu berprfen, wie das neue System in die bestehenden Prozesse
eingebunden werden kann. Dies betrifft z. B. das Change Management,
Eskalations- und Meldeverfahren, Sicherheits-Audits und weitere Manage-
ment-Disziplinen. Die Einhaltung der Sicherheitsvorgaben und -richtlinien der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Behrde oder des Unternehmens muss bei der Planung mit bercksichtigt
werden.
Personal
Es ist zu berprfen, wie viele Mitarbeiter mit welcher Ausbildung fr den
Betrieb des zSeries-Systems bentigt werden. Stehen nicht gengend
ausgebildete Mitarbeiter mit Mainframe-Wissen zur Verfgung, mssen die
Schulungsmanahmen rechtzeitig initiiert werden.
Einsatzszenarien
Im Folgenden werden exemplarisch einige typische Einsatzszenarien von
zSeries-Systemen vorgestellt und Empfehlungen zur Trennung von Systemen
mit unterschiedlichen Sicherheitsanforderungen beschrieben.
Batch-Systeme
Bei Batch-Systemen steht die Stapelverarbeitung im Vordergrund. Stapelver-
arbeitung bedeutet, dass vorgegebene Programme (Batch-Jobs) an Hand von
durch JCL (Job Control Language) definierten Ablufen ohne Interaktion mit
den Benutzern - in der Regel groe - Datenbestnde bearbeiten. Batch-
Systeme knnen sowohl als Einzelsysteme als auch im Rahmen von Parallel-
Sysplex-Clustern betrieben werden. Fr Batch-Systeme ist zu berlegen, ob
eine Scheduling-Funktion zur Kontrolle der Stapelverarbeitung eingesetzt
werden soll (siehe M 2.287 Batch-Job-Planung fr z/OS-Systeme). Die
Verwaltung der Zugriffsrechte sollte durch RACF (Resource Access Control
Facility) abgedeckt werden. Anhand der Anforderungen an die Skalierbarkeit
ist auerdem zu prfen, ob ein Parallel-Sysplex-Cluster eingesetzt werden
sollte.
Online-Systeme
Online-Systeme verarbeiten Transaktionen, die durch interaktive Arbeiten der
Benutzer am Bildschirm ausgelst werden. Hierbei kommen hufig
sogenannte Transaktionsmonitore wie CICS (Customer Information Control
System) oder IMS (Information Management System) zum Einsatz. Wie bei
Batch-Systemen sollte RACF zur Verwaltung und Durchsetzung der
Zugriffsrechte verwendet werden. Bei hohen Anforderungen an die
Verfgbarkeit des Online-Systems sollte geprft werden, ob diesen
Anforderungen durch den Einsatz eines Parallel-Sysplex-Clusters Rechnung
getragen werden kann. Weitere Empfehlungen finden sich in der Manahme
M 2.296 Grundstzliche berlegungen zu z/OS-Transaktionsmonitoren.
Web-Server
zSeries-Systeme werden auch als Web-Server fr Internet- oder Intranet-
Angebote eingesetzt. Als Betriebssystem kommt dabei z/OS oder auch zLinux
(separat oder als Gast unter z/VM) zum Einsatz. Sicherheitsempfehlungen fr
den Betrieb von Linux auf zSeries-Systemen finden sich in der Manahme
M 4.212 Absicherung von Linux fr zSeries.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Datenbank-Server
z/OS-Systeme knnen auch als Datenbank-Server eingesetzt werden. Das
System stellt dazu, hufig mit Hilfe der Datenbank-Software DB2, Services
zur Verfgung, die es erlauben, Datenbankinformationen abzufragen oder
deren Inhalte zu verndern. Datenbank-Server werden oft in Verbindung mit
Transaktionsmonitoren (z. B. CICS) oder mit Webservern eingesetzt und
liefern diesen den notwendigen Datenbank-Zugriff. Die Konzentration auf den
reinen Datenbank-Service reduziert die Komplexitt und verbessert die
Performance des Systems gerade bei sehr groen Datenbanken. Wie bei den
vorher beschriebenen Szenarien sollte RACF auch bei Datenbank-Servern zur
Verwaltung und Durchsetzung der Zugriffsrechte verwendet werden. Weitere
Empfehlungen zum Einsatz von DB2 finden sich in der Manahme M 2.296
Grundstzliche berlegungen zu z/OS-Transaktionsmonitoren.
Universelle Systeme
Universelle Systeme sind Mainframes, die mehrere der oben beschriebenen
Dienste erbringen. Sie verarbeiten sowohl Batch-Jobs als auch Online-
Transaktionen und enthalten einen (oder mehrere) Datenbank-Server.
Gegebenenfalls werden sie zustzlich auch noch als Webserver im Internet
oder Intranet eingesetzt. In allen Bereichen sollte RACF als Sicherheitssystem
eingesetzt werden.
System-Trennung
Da fr Produktions-Systeme unter z/OS in der Regel hhere
Sicherheitsanforderungen gelten als fr Test- und Entwicklungssysteme, muss
zwischen beiden Systemumgebungen eine Trennung erfolgen. Um diese
Trennung zu realisieren, sind folgende Empfehlungen zu bercksichtigen:
Gemeinsame Festplatten-Zugriffe
Die Festplatten sind den Test- und Produktions-Systemen so zuzuordnen, dass
unberechtigte Zugriffe auf Produktions-Daten verhindert werden knnen.
Dabei erfolgt die Definition der Adressen im HCD (Host Configuration
Definition). Es muss durch technische und organisatorische Manahmen
sichergestellt werden, dass Festplatten aus Test-Systemen an Produktions-
Systemen (und umgekehrt) nicht Online gesetzt werden knnen und dass auf
die gleichen Festplatten nicht gleichzeitig von Test- und Produktions-
Systemen aus zugegriffen werden kann (Shared DASD).
Einsatz von FTP
Der Datenaustausch zwischen Produktions- und Test-Systemen sollte ber
FTP (File Transfer Program) erfolgen.
Shared Sysplex
Produktions- und Test-Systeme sollten nicht im selben Parallel Sysplex-
Verbund betrieben werden. Ist eine solche Konstellation notwendig, muss eine
logische Trennung ber entsprechende Standards und RACF-Definitionen
(Resource Access Control Facility) sicherstellen, dass kein Missbrauch von
Dateizugriffen entstehen kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Shared RACF-Datenbanken
Es sollte berlegt werden, fr Produktions- und Test-Systeme keine Shared-
RACF-Datenbanken zu verwenden.
- Sind die Transaktionsmonitore ber RACF gesichert?
- Ist sichergestellt, dass es keine Shared-Dasd-Verbindung zwischen Test-
und Produktions-Systemen unter Produktionsbedingungen gibt?
- Ist sichergestellt, dass Test- und Produktions-Systeme nicht im gleichen
Parallel-Sysplex-Verbund laufen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.287 Batch-Job-Planung fr z/OS-Systeme

Beim Einsatz eines z/OS-Systems als Stapelverarbeitungs-Systems ist es bei
einer greren Anzahl von Batch-Jobs unabdingbar, dass der Ablauf dieser
Jobs geplant, berwacht und bearbeitet werden muss. Da diese Ttigkeit
manuell ohne Fehler kaum noch realisierbar ist, sollte Automations-Software,
sogenannte Job-Scheduler, zur Ablaufsteuerung der Batch-Jobs eingesetzt
werden.
Aufgaben der Job-Scheduler
Die Aufgabe der Job-Scheduler besteht im wesentlichen aus den Funktionen
- Starten der Batch-Jobs
- berwachen des Betriebszustandes der Batch-Jobs (darber hinaus
sicherstellen, dass Ressourcen bereitstehen)
- Prfen der Ergebnisse (ber Returncodes) der Batch-Jobs
- Verfolgen der Abhngigkeiten von Batch-Jobs
- Verwalten des Status der Batch Jobs
- Korrektive Manahmen im Fehlerfall
Die Sicherheitsmechanismen, um den Job-Scheduler vor Missbrauch zu
schtzen, sollten durch ein Sicherheitssystem wie RACF (Resource Access
Control Facility) realisiert werden.
Fr den Einsatz des Job-Schedulers sind mindestens die folgenden Hinweise
zu beachten:
Attribut OPERATIONS
Der Einsatz des RACF-Attributes OPERATIONS fr die Kennung der Started
Task des Job Schedulers sollte vermieden werden. Anderenfalls besteht die
Gefahr, dass Batch-Jobs, die unter dieser Kennung gestartet werden, Zugriff
zu nahezu allen Produktionsdateien haben (siehe M 2.289 Einsatz restriktiver
z/OS-Kennungen und M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
Falls der Hersteller fr den Betrieb des Job-Schedulers das Attribut
OPERATIONS fordert, sollte mit dem Hersteller geklrt werden, ob es hierzu
Alternativen gibt.
Einsatz von RACF-SURROGAT-Kennungen
Um zu verhindern, dass die Batch-Jobs aus dem Job-Scheduler heraus unter
der eventuell hoch autorisierten Kennung des Job-Scheduler laufen, sollte
berlegt werden, ob RACF-SURROGAT-Kennungen als Verfahrensken-
nungen eingesetzt werden knnen. Dabei sind die Nachteile dieser Funktion
zu bercksichtigen (siehe M 2.289 Einsatz restriktiver z/OS-Kennungen).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Prozedurdateien
Die Prozedurdateien des Job-Schedulers mssen so ber RACF geschtzt
werden, dass der Zugriff auf die Prozedurdateien nur Mitarbeitern mglich ist,
die diesen Zugriff fr ihre Ttigkeit auch bentigen. Dabei ist die Anzahl auf
ein Minimum zu beschrnken. Eine Stellvertreter-Regelung muss in jedem
Fall vorgesehen sein.
Die Kennung des Job-Schedulers muss lesenden Zugriff auf alle
Prozedurdateien besitzen, um die Batch-Jobs entsprechend starten zu knnen.
Tool-Zugriff
Der Job-Scheduler wird meist ber einen ISPF-Dialog (Interactive System
Productivity Facility) gesteuert. Der Zugang zum Job-Scheduler sollte nur
Mitarbeitern zur Verfgung stehen, die ihn fr ihre Arbeit bentigen, sowie
deren Vertretern. Der Zugangs- und Zugriffsschutz sollte ber RACF
erfolgen. Falls dies nicht mglich ist, mssen interne Sicherheitsmechanismen
des Schedulers genutzt werden.
Systemadministration
Die Verwaltung der Batch-Jobs im Job-Scheduler sollte, wenn immer
mglich, so ber RACF geschtzt werden, dass jede Anwender-Gruppe, wie
Systembetreuer, Space-Management oder RACF-Administration, nur ihre
Batch-Jobs einsehen und bearbeiten kann.
- Ist sichergestellt, dass die Kennung des Job-Schedulers ohne das RACF-
Attribut OPERATIONS auskommt?
- Ist der Zugang zum Job-Scheduler-Programm ber RACF geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.288 Erstellung von Sicherheitsrichtlinien fr z/OS-

Systeme
Vor dem Einsatz von z/OS-Systemen mssen Sicherheitsrichtlinien fr das
z/OS-System und besonders auch fr das Sicherheitssystem RACF (Resource
Access Control Facility) geplant und festgelegt werden. Es sind folgende
Empfehlungen zu bercksichtigen:
- Die z/OS-Systeme mssen in das unternehmens- bzw. behrdenweite IT- IT-Sicherheits-
management
Sicherheitsmanagement eingebunden werden. Hinweise hierzu finden sich
in Kapitel 2 und 3 des IT-Grundschutzhandbuchs.
- Wie in Manahme M 2.30 Regelung fr die Einrichtung von Benutzern / Benutzerverwaltung
Benutzergruppen beschrieben, ist ein Verfahren zur Verwaltung der Benut-
zer des z/OS-Systems und deren Kennungen zu erstellen.
- Es muss eine Richtlinie zum Gebrauch des Notusers erstellt werden (siehe Notuser-Verfahren
Manahme M 6.93 Notfallvorsorge fr z/OS-Systeme).
- Eine Richtlinie zur Wiederherstellung der RACF-Datenbank unter z/OS RACF-Datenbank-
Wiederherstellung
muss erstellt werden (siehe Manahme M 6.93 Notfallvorsorge fr z/OS-
Systeme).
- Ein Berechtigungsprozess fr den Zugriff auf sicherheitskritische System-
Ressourcen, wie z. B. APF-Dateien (Authorized Programming Facility),
SVCs (SuperVisor Calls) usw., muss beschrieben und eingefhrt sein.
- Ein Audit-Verfahren, wie in Manahme M 2.291 Sicherheits-Berichts- Sicherheits-Audit /
Monitoring
wesen und -Audits unter z/OS beschrieben, bzw. ein Monitoring-Verfahren,
wie in Manahme M 2.292 berwachung von z/OS-Systemen beschrieben,
mssen etabliert sein.
- Ein Eskalations- und Meldeverfahren muss aufgebaut sein. In ihm muss Eskalations-/ Melde-
Verfahren
festgelegt sein, wer Sicherheits-Verste erkennt, weitermeldet und welche
Abwehrmanahmen zu ergreifen sind.
- Eine Dokumentation zu Aufbau und Funktion eines Notsystems, wie in Not-System
Manahme M 6.93 Notfallvorsorge fr z/OS-Systeme beschrieben, muss
erstellt sein (gilt nur fr Einzel-Systeme).
- Es sollte eine Prfliste mit Kontrollfragen erstellt werden, die alle wich- Prfliste fr Sicherheits-
einstellungen
tigen sicherheitsrelevanten Einstellungen des z/OS-Systems erfasst und
deren Soll-Werte festlegt. Anhand dieser Prfliste werden die
Arbeitsanweisungen fr die System- und RACF-Administratoren erstellt.
Die Prfliste dient dem Auditor als Basis fr die berprfung der
Systemsicherheit. In regelmigen Abstnden muss die Prfliste ber-
arbeitet werden. Als Basis fr eine solche Prfliste knnen die Manahmen
M 4.211 Einsatz des z/OS-Sicherheitssystems RACF und M 4.209 Sichere
Grundkonfiguration von z/OS-Systemen dienen.
- Ist eine Prfliste fr Sicherheitseinstellungen vorhanden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist ein Verfahren fr Audit und/oder Monitoring eingefhrt?

- Ist das Eskalations- und Meldeverfahren beschrieben und in die Praxis
umgesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.289 Einsatz restriktiver z/OS-Kennungen

Fr die Verwaltung des Sicherheitssystems RACF (Resource Access Control Kennungen mit hoher
Autorisierung
Facility) werden u. a. Kennungen mit hoher Autorisierung bentigt. Zur
Minimierung des Missbrauchsrisikos sind die folgenden Regeln zu beachten:
SPECIAL, OPERATIONS, AUDITOR
Attribute mit hoher Autorisierung im RACF, wie SPECIAL, OPERATIONS
und AUDITOR, gelten systemweit und drfen nur an Anwender vergeben
werden, die fr ihre Ttigkeit diese Rechte bentigen. Kennungen mit diesen
besonders hohen Rechten sind auf ein Minimum zu begrenzen, und deren
Vergabe ist zu dokumentieren.
GROUP-SPECIAL, GROUP-OPERATIONS, GROUP-AUDITOR
Sind hohe Rechte erforderlich, so ist zu berlegen, ob diese Rechte nicht auf
Gruppenebene (GROUP-SPECIAL, GROUP-OPERATIONS und GROUP-
AUDITOR) fr die jeweilige Kennung eingeschrnkt werden knnen. Auch
die Vergabe der auf Gruppenebene eingeschrnkten Rechte ist auf ein
Minimum zu begrenzen und zu dokumentieren.
Superuser (UID 0)
Im optionalen Unix-Segment der User-Kennung (OMVS Segment) wird eine
fr Unix System Services (USS) gltige Userid (UID) vergeben, unter der die
z/OS-Kennung im USS gefhrt wird. Die UID 0 (Superuser) oder die Berech-
tigung, das su-Kommando ausfhren zu drfen, darf nur an die Anwender
vergeben werden, die diese Berechtigung fr ihre Arbeit bentigen.
SPECIAL und UID 0
Hoch autorisierte Kennungen mit Attribut SPECIAL drfen aus Sicherheits-
grnden nicht gleichzeitig mit UID 0 als Superuser unter USS laufen. Es ist
weiterhin zu berlegen, ob die Attribute SPECIAL und OPERATIONS an die
gleiche Kennung vergeben werden sollten.
Vergabe von UIDs
UIDs sollten nicht doppelt vergeben werden (gleiche UID fr verschiedene
User). Viele Ttigkeiten, fr die in bestimmten Unix-Betriebssystemen unbe-
dingt Superuser-Rechte bentigt werden, knnen im RACF einzeln ber spe-
zielle RACF-Profile der Klasse UNIXPRIV autorisiert werden. Eine solche
Autorisierung ber RACF-Profile ist in jedem Fall sicherer als die Vergabe
der Superuser-Rechte oder su-Kommando-Berechtigung (siehe auch Ma-
nahme M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
Audit-Verfahren
Um die Ttigkeit der Anwender mit hohen Berechtigungen auditieren zu kn-
nen, muss ein entsprechendes Audit-Verfahren etabliert sein (siehe auch Ma-
nahme M 2.288 Erstellung von Sicherheitsrichtlinien fr z/OS-Systeme) .
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
IBMUSER bei Neuinstallationen

Erfolgt eine Neuinstallation, so sind mit dem IBMUSER mindestens zwei
Kennungen mit dem Attribut SPECIAL neu anzulegen. Ist dies erfolgt, so
muss der IBMUSER gesperrt (REVOKED) werden und gesperrt bleiben.
RACF-Definitionen sollten nicht mit der Kennung IBMUSER angelegt werden
(siehe auch Manahme M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
Notuser-Verfahren
Fr den Fall, dass z. B. alle Kennungen mit dem Attribut SPECIAL gesperrt
wurden, oder kein Anwender mit dieser Berechtigung im Notfall verfgbar ist,
ist ein Notuser-Verfahren zu etablieren (siehe auch Manahme M 6.93 Not-
fallvorsorge fr z/OS-Systeme).
- Ist der IBMUSER gesperrt?
- Gibt es ein Notuser-Verfahren?
- Gibt es eine Liste der Kennungen mit den Attributen SPECIAL,
OPERATIONS oder AUDITOR bzw. der entsprechenden Gruppen-Attri-
bute, und ist ihre Zahl auf ein Minimum beschrnkt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.290 Einsatz von RACF-Exits

Neben den Anpassungsmglichkeiten von RACF (Resource Access Control
Facility) durch Kommandos und Parameter ist es darber hinaus mglich,
zustzliche Sicherheitsregeln durch den Einsatz von RACF-Exits zu imple-
mentieren. Exits werden an verschiedenen Stellen der RACF-Funktionen
durchlaufen und erlauben dort individuelle Eingriffe. Ihr Einsatz erfordert ein
hohes Ma an Wissen und Erfahrung in der Assembler-Programmierung.
Die folgenden Empfehlungen sollten beim Einsatz von Exits beachtet werden:
Wartung der Exits
Wenn Exits zur Erweiterung der RACF-Funktionalitt notwendig sind,
mssen diese per SMP/E (System Management Program/Enhanced) als
Usermod eingebaut werden (siehe M 2.293 Wartung von zSeries-Systemen).
DES-Algorithmus zur Authentisierung
RACF verschlsselt die Kennung mit Hilfe des DES-Algorithmus (Data
Encryption Standard), wobei als Schlssel das eingegebene Passwort benutzt
wird (das Passwort selbst wird dabei nicht gespeichert). Um sicherzustellen,
dass der DES-Algorithmus (und nicht der schwchere Masking-Algorithmus)
benutzt wird, darf der in der SYS1.LINKLIB mitgelieferte Exit ICHDEX01
nicht in der Link Pack Area eingesetzt werden. Es wird daher empfohlen,
dieses Lade-Modul zu entfernen und den entsprechenden Eintrag in SMP/E zu
deaktivieren (Usermod), damit zuknftige Wartungsaktivitten dieses Lade-
Modul nicht eventuell wieder installieren. Der DES-Algorithmus ist normaler-
weise die Standardeinstellung bei der Auslieferung von RACF unter z/OS.
nderungen von Exits
Es ist zu beachten, dass bei nderungen von Exits ein IPL (Initial Program
Load) notwendig ist. Eine Ausnahme hiervon stellt IRREVX01 dar; er lsst
sich dynamisch nachladen.
Erweiterte Passwortregeln
Es sollte berlegt werden, ob die ber die SETROPTS-Funktion von RACF
zur Verfgung gestellten Mechanismen der Passwortregeln ausreichen oder ob
ber den New Password Exit ICHPWX01 erweiterte Passwortregeln eingefhrt
werden sollen.
Verwendung von Tools
Beim Einsatz von Tools zur Passwort-Synchronsierung oder von Produkten
zum Tape-Management ist zu berprfen, ob RACF-Exits mit dem Produkt
geliefert werden oder sogar Voraussetzung fr das Funktionieren des jewei-
ligen Produktes sind.
Exit-Kontrolle
Der Einsatz von Exits kann ber die Funktion DSMON kontrolliert werden.
Eine solche Kontrolle sollte regelmig im Rahmen von Audits erfolgen
(siehe auch M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS). Eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ausnahme stellt IRREVX01 dar. Dieser Exit sollte jedoch ebenfalls kontrolliert
werden, wenn er verwendet wird.
- Ist der Exit ICHDEX01 und damit der Masking-Algorithmus ausgeschaltet?
- Wurden alle verwendeten RACF-Exits per SMP/E als Usermod eingebaut?
- Steht die Exit-Auswertung ber DSMON zur Verfgung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.291 Sicherheits-Berichtswesen und -Audits unter

z/OS
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Administrator,
Revisor
Zur berwachung aller sicherheitsrelevanten Ttigkeiten muss ein Prozess
eingerichtet werden. In diesem muss festgelegt sein, welche Sicherheitsreports
regelmig erstellt werden und wie mit Abweichungen von den Vorgaben
umgegangen wird. Diese Sicherheitsreports sollten als Information fr den
Auditor verwendet werden.
Darber hinaus mssen zur Erhhung der Betriebssicherheit eines z/OS-
Systems regelmig IT-Sicherheits-Audits durchgefhrt werden. Durch solche
Audits wird berprft, ob die geforderten Sicherheitseinstellungen und
Ablufe eingehalten werden. Vorgaben hierfr finden sich in M 2.288
Erstellung von Sicherheitsrichtlinien fr z/OS-Systeme.
Sicherheits-Berichtswesen
SMF-Stze (System Management Facility) als Quelle des Berichtswesens
Fr die berwachung der IT-Sicherheit von z/OS-Systemen sind die SMF-
Stze des Typs 80 von Bedeutung. Sie protokollieren alle Zugriffe auf
Ressourcen, die durch RACF-Profile geschtzt werden. In diesen Profilen
kann durch RACF-Definitionen festgelegt werden, ob nur unerlaubte oder
auch erlaubte Zugriffe protokolliert werden. Unerlaubte Zugriffe mssen in
jedem Fall protokolliert werden. Bei systemkritischen Dateien sollten in einem
Produktionssystem auch die erlaubten Zugriffe ber SMF erfasst werden,
wenn die Datei dabei gendert wird. Beim Protokollieren ber SMF-Stze
sollte immer darauf geachtet werden, dass durch das Aktivieren von SMF-
Funktionen nicht zu viele Logdaten entstehen. Die Kapazitt und die Perfor-
mance des Systems darf nicht zu stark beeintrchtigt werden.
Es muss sichergestellt werden, dass der SMF-Satz Typ 80 auch wirklich
geschrieben wird. Dies wird im Member SMFPRM00 in der Parmlib definiert.
Der Schutz der Parmlib ist in Manahme M 4.209 Sichere
Grundkonfiguration von z/OS-Systemen nher beschrieben.
Einsatz von Tools
- Einsatz des RACFICE-Tools
Es ist zu berlegen, IBMs ICE-Tool (RACFICE) basierend auf IBMs
DFSORT einzusetzen und dabei vorgefertigte Reports zu verwenden, vor-
handene anzupassen oder neue zu erstellen.
Bei den SMF-Stzen knnen beispielsweise fehlgeschlagene Zugriffsver-
suche auf Ressourcen, erlaubte Zugriffe infolge besonderer Berechtigungen
(OPERATIONS) und fehlgeschlagene Zugriffsversuche mit falschem
Passwort als Reports erzeugt werden.
Aus der RACF-Datenbank knnen zum Beispiel die Dateiprofile selektiert
nach UACC (Universal Access), gesperrte Benutzerkennungen und Profile,
die in den letzten 90 Tagen verndert wurden, als Reports erzeugt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Einsatz des RACF-Programms DSMON

Es ist zu berlegen, das RACF-Programm DSMON als Basis fr weitere
Berichte zu benutzen. Dies ist in jedem Fall zu empfehlen, wenn kein Real-
Time-Monitor eingesetzt werden soll, um Vernderungen an vitalen z/OS-
Definitionen kontrollieren zu knnen.
- Einsatz von Independent Vendor Tools
Die Auswertung der in den SMF-Stzen protokollierten Informationen
erfordert besondere Systemkenntnisse, wie z. B. der SMF-Programm-
funktion. Es ist deshalb zu berlegen, separate Tools zur Auswertung
dieser Datenstze einzusetzen. Entsprechende Programme sind von ver-
schiedenen ISVs (Independent Software Vendors) erhltlich.
- Einsatz eines Real-Time-Monitors
Bei besonderen Sicherheitsanforderungen ist zu berlegen, ob ein
Berichtswesen auf Stapelverarbeitungsbasis aktuell genug ist oder ob ein
Real-Time-Monitor zur Erkennung bestimmter Sicherheitsverste nicht
sinnvoller ist. Dabei werden die SMF-Stze ber SMF-Exits (IEF083,
IEF084, IEF085) direkt abgefangen und zu einem Monitor-Programm
geleitet, das die Analyse und Darstellung bernehmen kann (siehe auch
Manahme M 4.209 Sichere Grundkonfiguration von z/OS-Systemen).
Wichtige Informationen fr eine Echtzeit-berwachung sind z. B.:
- nderungen an APF-Dateien
- Benutzung von Kennungen mit dem Attribut SPECIAL oder
OPERATIONS
- Erlaubte Zugriffe auf Grund des Attributes OPERATIONS
- Mehrfache Zugriffsversuche mit falschem Passwort
- Benutzung des Notusers
z/OS-Sicherheits-Audits
Unabhngigkeit der Auditoren
Die Durchfhrung der Audits muss durch unabhngige Auditoren erfolgen,
d. h. das durchfhrende Personal darf sich und seine Arbeit nicht selbst audi-
tieren.
Die Auditoren mssen z/OS-System- und RACF-Kenntnisse zur Durch-
fhrung ihrer Ttigkeit haben. Diese Kenntnisse sind durch regelmige
Schulungen zu erwerben bzw. zu aktualisieren.
Autorisierung der Auditoren
Die Auditoren mssen Zugangsberechtigung zum System mit dem RACF-
Attribut AUDITOR haben. Auch fr die Files in HFS-Dateien muss dieses
Attribut im jeweiligen FSP (File Security Packet) aktiviert sein.
Kontrolle ber SMF-Stze
Grundlage fr das Audit sind die SMF-Stze des Recordtyps 80. Die Infor-
mationen in der RACF-Datenbank legen dabei fest, welche Ereignisse in den
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SMF-Stzen protokolliert werden. Es muss deshalb sichergestellt werden, dass

diese SMF-Stze geschrieben werden und fr Auswertungen zur Verfgung
stehen.
berprfung von RACF-Profilen
Die Auditoren sollten berprfen, ob bei Neueinrichtungen und Vernde-
rungen von RACF-Profilen
- Genehmigungen vorliegen,
- die Funktionen bzw. Attribute (SPECIAL, OPERATIONS) in ihrem
Befugnisumfang begrndet sind (gilt auch fr GROUP-SPECIAL
und GROUP-OPERATIONS).
Gegenstand des Sicherheits-Audits
Ein vollstndiges Sicherheits-Audit ist sehr komplex und muss eine groe
Anzahl von sicherheitsrelevanten Funktionen berwachen. Die folgenden
Funktionen sollten mindestens berwacht werden:
- Kritische System-Einstellungen:
- Program Properties Table (PPT)
- Kontrolle der APF-Dateien (Authorized Programming Facility)
- Kontrolle der Dateien aus der Linklist
- SVC-Einsatz (SuperVisor Call)
- Tabelle ICHRIN03 (Started Task Table)
- Kritische RACF-Funktionen:
- RACF Authorized Caller
- Einsatz von RACF Exits
- RACF Started Procedures (hier besonders die Attribute Privileged
und Trusted)
- RACF Global Access Table
- Kritische Aktionen:
- Aktivitten von Kennungen mit SPECIAL, OPERATIONS (gilt auch
fr GROUP-SPECIAL und GROUP-OPERATIONS) oder Notuser,
IBMUSER
- Vernderung von sensitiven RACF-Parametern durch den Einsatz
des SETROPTS-Kommandos
- Alle Aufrufe des RACDEF-SVC (SVC 133) und alle Vernderungen
an RACF-Profilen, die durch diesen RACF-Befehl entstanden sind
- Hinweise auf potentielle Sicherheitsverste:
- Ballung von fehlgeschlagenen Anmelde- oder Zugriffsversuchen
- Vernderung von Audit-Attributen
- Behauptete bzw. identifizierte Benutzeridentitt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Art des versuchten Zugriffs (Erfolg oder Scheitern)

Einsatz von Audit-Tools
Zur Kontrolle der zu berwachenden Definitionen sollte mindestens der
DSMON von RACF und das RACFICE-Paket eingesetzt werden. Es ist zu
prfen, ob ein zustzliches Programm-Paket beschafft werden sollte, das die
Auditoren bei ihrer Arbeit untersttzt.
Wichtig ist, dass ein Audit nur zur Feststellung von Tatsachen und nicht zur
Ermittlung von Schuldigen dient, siehe auch M 2.182 Regelmige Kontrollen
der IT-Sicherheitsmanahmen.
- Werden regelmig Sicherheitsberichte erstellt?
- Werden die RACF-Reporting-Tools RACFICE und DSMON benutzt?
- Ist ein Real-Time-Monitor im Einsatz?
- Werden SMF-Stze des Typs 80 erstellt und knnen diese ausgewertet
werden?
- Findet eine regelmige berprfung statt?
- Haben die Auditoren das Ihnen zugeordnete Attribut?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.292 berwachung von z/OS-Systemen

Um Fehlersituationen und Sicherheitsprobleme zeitnah erkennen und beheben
zu knnen, ist es notwendig, den laufenden Betrieb von z/OS-Systemen zu
berwachen. Dazu stehen verschiedene Datenquellen des Betriebssystems zur
Verfgung. Diese knnen entweder manuell durch das Operating oder auto-
matisiert durch Programme analysiert werden.
Die folgenden Empfehlungen sind bei der berwachung von z/OS-Systemen
zu bercksichtigen:
MCS-Konsole
Die MCS-Konsole (Multiple Console Support) stellt wichtige System-
Meldungen (Fehler, Sicherheitsverste usw.) dar, auf die der Operator auch
sofort reagieren kann. Um aus der Flut der Nachrichten die wichtigen heraus-
zufiltern, ist der Einsatz der MPF-Funktion (Message Processing Facility)
unbedingt erforderlich. Dabei ist es empfehlenswert, die wichtigen Nach-
richten auf eine spezielle Konsole zu leiten, whrend die Kommunikation mit
dem Betriebssystem auf anderen Konsolen stattfinden sollte. Es sollte berlegt
werden, Farben zum Herausheben von kritischen Nachrichten einzusetzen.
SMF-Auswertung
Nahezu alle Aktivitten des Betriebssystems werden ber SMF-Stze (System
Management Facility) protokolliert. Diese Stze sind in jedem Fall zur
Analyse nach Sicherheitsversten heranzuziehen (siehe auch Manahme
M 2.291 Sicherheits-Berichtswesen und -Audits unter z/OS). Um auch Ereig-
nisse der Vergangenheit analysieren zu knnen, muss ein entsprechendes
Archivierungsverfahren fr die SMF-Daten vorhanden sein. Da die SMF-
Daten ebenso fr Abrechnung und Performance-Analysen des z/OS-Systems
herangezogen werden knnen, ist ferner zu berlegen, ob ein entsprechendes
Berichtswesen aufgebaut werden soll.
SYSLOG-Auswertung
Alle wesentlichen Ereignisse werden darber hinaus vom Betriebssystem im
sogenannten SYSLOG (System Log) mitgeschrieben, das ber SDSF (System
Display and Search Facility) fr JES2 oder ber Flasher fr JES3 fr manu-
elle Analysen zur Verfgung steht. Es ist zu berlegen, ob Auswertungs-
programme erstellt und eingesetzt werden sollen, die das SYSLOG nach kriti-
schen Nachrichten durchsuchen und entsprechende Reports erstellen.
Automation
Es ist zu berlegen, ob Automations-Programme eingesetzt werden sollen, die
vordefinierte SYSLOG-Meldungen erkennen und entsprechende Reaktionen
im System auslsen knnen. Hierzu gibt es eine Reihe von Produkten am
Markt, auch MPF inklusive Exit-Programmierung kann benutzt werden.
Anwendungs-Logs
Viele Anwendungen schreiben eigene Protokolldaten, so zum Beispiel auch
das USS-Subsystem (Unix System Services). Diese Protokolle sind ebenfalls
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
auf Sicherheitsverste zu analysieren, wichtige Nachrichten sind den Opera-

toren zur Verfgung zu stellen.
Zentrale Kontrolle
In greren Installationen mit verschiedenen Standorten sollte eine zentrale
Stelle existieren (Focal Point), an die alle fr den Betrieb wichtigen Infor-
mationen gemeldet werden. Der Einsatz von Programmen, die das Geschehen
bersichtlich - eventuell grafisch - darstellen knnen, ist zu berlegen.
- Gibt es eine zentrale Stelle, an die Informationen unterschiedlicher
Systeme gemeldet werden (Focal Point)?
- Werden die SMF-Stze analysiert, um Sicherheitsverste zu entdecken?
- Sind Nachrichten-Filter im Einsatz, um die wesentlichen Nachrichten
herauszufiltern und besser darzustellen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.293 Wartung von zSeries-Systemen

Die Maintenance-Konzeption umfasst die Wartung der zSeries-Hardware, des
z/OS-Betriebssystems, der verschiedenen Programm-Produkte und die War-
tung des zSeries-Microcode (Firmware). Wartung betrifft den kompletten
Lebenszyklus eines Produktes, von der Neuinstallation ber die permanente
Pflege bis hin zum Abbau.
Wartung des zSeries-Hardware
Es ist zu empfehlen, fr die Wartung der zSeries-Hardware einen Wartungs-
vertrag mit dem Hersteller bzw. mit vom Hersteller autorisierten Partnerunter-
nehmen abzuschlieen. Wartung kann entweder auf regelmiger Basis
erfolgen oder wird notwendig, wenn interne Prfprogramme Fehler entdecken
und ber RSF (Remote Support Facility) den Hersteller oder seinen Vertreter
informieren. Zur Sicherstellung der Funktionsfhigkeit der Hardware (und
auch der Basis-Software) ist eine regelmige berprfung der EREP-Reports
(Environmental Record Editing and Printing Program) zu empfehlen. Die im
EREP-Report dargestellten Informationen ber Hard- und Software-Probleme
werden von der Hardware und dem z/OS-Betriebssystem geliefert.
Wartung des z/OS-Betriebssystems
Die Wartung eines z/OS-Systems inklusive aller Subsysteme ist uerst
komplex und bedarf deswegen einer sorgfltigen Planung. Unter den Begriff
Wartung fllt:
- Inbetriebnahme eines neuen Systems
- nderungen als Funktionserweiterung oder Nachrstung von Funktionen
- Behebung von gemeldeten Fehlern durch sogenannte PTFs (Program
Temporary Fixes)
- Einbau von PTFs als prventive Manahme (besonders wichtig sind hier
PTFs gegen gemeldete Sicherheitslcken) auf Grund von Her-
stellerinformationen
- Abbau von Systemen
Die Wartung von z/OS-Betriebssystemen kann normalerweise nicht ohne
Unterbrechung des Betriebs durchgefhrt werden.
Bei der Wartung des z/OS-Betriebssystems sind die folgenden Empfehlungen
zu bercksichtigen:
Wartungsplne
Es mssen Wartungsplne erstellt werden, in denen festgelegt wird, wann
nderungen am System durchgefhrt werden drfen. Es mssen IPL-Termine
(Initial Program Load) festgelegt und Testszenarien erarbeitet werden. Dies
muss mit allen Beteiligten abgesprochen werden. Um fehlgeschlagene nde-
rungen notfalls wieder rckgngig machen zu knnen, muss ein Rckfall-
Konzept erstellt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Change Management
Alle nderungen an Definitionen des z/OS-Betriebssystems (auch dyna-
mische nderungen whrend des produktiven Betriebs) mssen ber das
Change Management geplant und kontrolliert werden. Dies gilt auch fr
Neuinstallationen.
Neuinstallation
Eine Neuinstallation wird notwendig, wenn ein z/OS-Betriebssystem erstmalig CustomPacs
in Betrieb gehen soll oder wenn eine neue Version (bzw. neues Release) die
vorhandene Version ablsen soll. Der Hersteller bietet hier unter dem Begriff
CustomPac verschiedene, weitgehend vorbereitete Produkt- und System-
lieferungen an, die teils kostenlos, teils im Rahmen von Wartungsvertrgen
zur Verfgung stehen.
SystemPac ist ein Teil des CustomPac-Angebotes und erlaubt es, eine weit-
gehend vorbereitete Lieferung des z/OS-Betriebssystems - gegebenenfalls
einschlielich einiger Zusatzprodukte - zu installieren. Zur Neuinstallation ist
eine separate Systemumgebung (siehe unten) erforderlich. Durch die Nutzung
von SystemPac kann der Aufwand und dadurch auch die Wahrscheinlichkeit
von Bedienungsfehlern bei der Neuinstallation erheblich reduziert werden. Es
sollte deshalb berlegt werden, bei Neuinstallationen von z/OS auf den
SystemPac-Mechanismen zurckzugreifen. Dabei sind auch die Zusatzkosten
zu bercksichtigen, die dadurch eventuell anfallen.
Permanente Pflege der Komponenten
Das z/OS-Betriebssystem und seine Programm-Produkte mssen permanent
gepflegt werden. Fast alle Hersteller stellen fr ihre Programme Patches (im
Mainframe-System als PTFs bekannt) zur Verfgung, die Fehler beheben
sollen. IBM stellt diese PTFs fr das z/OS-Betriebssystem ber verschiedene
Kanle zur Verfgung:
- als Einzellieferung auf Anforderung des Kunden (z. B. auf Grund einer
Fehlersituation): hier muss der Anwender die Rahmenbedingungen selbst
berprfen, z. B. die Abhngigkeiten
- als RefreshPac im Rahmen prventiver Wartung, angepasst an das
Kundensystem (von IBM vorgeprft) oder
- als OMIS-Lieferung (Online Maintenance Information System). OMIS
basiert auf den Daten des Kundensystems und ist ebenfalls von IBM
vorgeprft.
Es ist zu berlegen, ob prventive Wartung zur Erhhung der Betriebssicher-
heit notwendig ist, oder ob PTFs nur bei aktuellen Fehlern eingespielt werden
sollen. Sicherheitsrelevante Patches sollten in jedem Fall prventiv und zeit-
nah nach dem Erscheinen eingespielt werden. Dies gilt besonders fr Systeme
mit Internetzugang. Informationen ber sicherheitsrelevante Patches knnen
von IBM angefordert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SMP/E-Wartung
Als zentrales Wartungs-Tool ist SMP/E einzusetzen, das System Modifikation Einsatz von SMP/E
Program/Extended. Durch die Bestandsfhrung der Software-Stnde im CSI
(Consolidated Software Inventory) wird sichergestellt, dass alle Informationen
ber Module, Versionen und Zusammenhnge des z/OS-Betriebssystems zur
Verfgung stehen und damit Fehler bei der Installation der Patches mglichst
vermieden werden.
Independent Software Vendors
Software-Produkte von ISVs (Independent Software Vendors) sollten mg-
lichst ebenfalls ber SMP/E installiert und gepflegt werden. Es ist zu ber-
legen, ob ISV-Produkte separat oder im Rahmen des SystemPac-Mechanismus
installiert werden sollen.
Consolidated Software Inventory
Es sollte ein CSI fr das z/OS-Betriebssystem existieren, bzw. im Falle einer
SystemPac-Installation gem der Lieferung durch IBM sollte das (die)
CSI(s), wie im Ablauf vorgesehen, angelegt werden. Pro Hersteller wird ein
separates CSI empfohlen, um Problemen mit Namensgleichheit bei PTFs vor-
zubeugen.
USERMODS
Eigene nderungen durch Anwender sollten nur mittels SMP/E installiert
werden (als USERMODS). Dies stellt sicher, dass die eigenen nderungen
nicht durch Herstellernderungen berspielt werden, ohne dass eine Informa-
tion darber vorliegt. Sie mssen nach jedem Releasewechsel des Systems
bzw. der Module, auf denen die nderungen aufsetzen, neu installiert und
eventuell auch angepasst werden. USERMODS sollten auf ein Minimum
begrenzt werden, da sie permanenten Pflegeaufwand nach sich ziehen.
ACCEPT-Lufe
Durch einen ACCEPT-Lauf wird ein PTF permanent im System abgelegt, d. h.
es ist nicht mehr entfernbar. Ein ACCEPT-Lauf sollte daher erst stattfinden,
wenn sichergestellt ist, dass die PTFs die festgestellten Probleme beseitigen
und keine neuen erkennbaren Fehler hervorrufen.
APPLY CHECK
Es ist zu empfehlen, dass vor dem Einbau von PTFs ber einen APPLY
CHECK SMP/E-Lauf sichergestellt wird, dass die PTFs auch zur aktuell
installierten Betriebssystem-Umgebung passen und keine zustzlichen PTFs
erforderlich sind (sogenannte Prerequisites oder Corequisites).
Test vor Produktion
Die betriebliche Zuverlssigkeit der gelieferten PTFs sollte erst auf einem
Testsystem berprft werden, bevor die PTFs in ein Produktionssystem
eingebaut werden. Bei greren Wartungsarbeiten (z. B. ein sogenannter
Refresh mit hunderten von PTFs) muss dieser Ablauf in jedem Fall vorge-
sehen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kumulative Betriebssystemdateien
Es sollten keine Betriebssystemdateien an SMP/E vorbei kopiert werden, da
hierdurch die Sicherheit der Wartung beeintrchtigt werden kann. Kumulierte
Dateien sind solche, die aus mehreren Dateien zusammengesetzt worden sind.
Sollen kumulierte Dateien verwendet werden, muss entweder die Bestands-
fhrung in SMP/E angepasst oder ein separates Verfahren eingesetzt werden,
um die Bestandskontrolle gewhrleisten zu knnen. Es ist daher zu berlegen,
ob der Mehraufwand gerechtfertigt ist.
Alternative Systemumgebung
Zum Einbau von PTFs sollte eine zweite (alternative) Systemumgebung
benutzt werden. Hierfr sollten separate Festplatten mit einer Kopie des
Originalsystems verwendet werden. Dies ermglicht ein problemloses Ein-
bauen whrend der Betriebszeiten und erlaubt ein schnelles IPL (Initial
Program Load) von der vernderten System Residence (der Festplatte, von der
der Boot-Vorgang eingeleitet wird). Darber hinaus untersttzt diese Vor-
gehensweise (Flip-Flop-Verfahren) den schnellen Fallback, da die Festplatten
der vorher aktiven Betriebssystemkomponenten noch zur Verfgung stehen.
System-Cloning
Unter System-Cloning versteht man das Kopieren der Betriebssystem-Kompo-
nenten auf einen neuen Festplatten-Satz unter Bercksichtigung der zu
ndernden Definitionen. Es ist zu berlegen, ob ein Verfahren zum System-
Cloning etabliert wird, um alternative System-Umgebungen schnell und sicher
aufbauen zu knnen.
Ein solches Verfahren muss eigenstndig erstellt werden, z. B. in Form eines
Batch-Jobs mit mehreren Schritten. Die Benutzung von System-Variablen
hilft hier wesentlich.
Einsatz symbolischer System-Variablen
Bei den z/OS-Parameter-Dateien sollte, soweit mglich, mit symbolischen
Variablen gearbeitet werden. Dies vereinfacht das System-Cloning erheblich
und vermeidet vielfach auch Fehldefinitionen. Ab dem z/OS-Betriebssystem
V1R4 stehen bis zu 800 Variablen zur Verfgung.
Dokumentation
Es ist zu berlegen, ob ein Berichtswesen, basierend auf SMP/E, aufgebaut
werden sollte, um jederzeit den aktuellen Stand der gesamten Software des
Betriebssystems darstellen zu knnen.
Wartung des zSeries-Microcode (Firmware)
Zur Behebung von Code-Fehlern in der Firmware, zum Firmware-Update auf
neue Versionen und zur Aktivierung oder Deaktivierung von Hardware-
Komponenten (z. B. Prozessoren, Krypto-Hardware) werden von den Her-
stellern Microcode-Updates durchgefhrt. Hierfr mssen folgende Hinweise
beachtet werden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Betreiberkontrolle
Updates durch den Hersteller drfen nur nach Absprache mit dem Betreiber
der zSeries-Systeme und nur unter Kontrolle von Mitarbeitern des Betreibers
durchgefhrt werden.
Hersteller-Erklrung
Der Hersteller der Betriebssystem-Software sollte eine Vertraulichkeits-
Erklrung ausstellen.
Remote Wartung
Der externe Zugang (Remote Access) ist, wie in Baustein 7.6 Remote Access Einsatz des Remote
Support Facilities
und speziell in Manahme M 4.207 Einsatz und Sicherung systemnaher z/OS-
Terminals beschrieben, zu schtzen. Es muss sichergestellt werden, dass
nderungen an Firmware-Komponenten nur nach Abstimmung mit dem
zSeries-Systembetreiber erfolgen.
Abbau des z/OS-Betriebssystems
Weiterfhrende Informationen zu dem Abbau eines z/OS-Betriebssystems
sind unter M 2.297 Deinstallation von z/OS-Systemen zu finden.
- Wird SMP/E zur Installation und zu Wartungsarbeiten eingesetzt?
- Werden alle Anwender-spezifische Modifikationen ber SMP/E installiert?
- Gibt es eine alternative System-Umgebung?
- Werden symbolische Variablen eingesetzt?
- Ist ein Verfahren zum System-Cloning etabliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.294 Synchronisierung von z/OS-Passwrtern und

RACF-Kommandos
In groen Mainframe-Verbnden kommunizieren oft viele z/OS-Betriebs-
systeme und ihre RACF-Datenbanken (Resource Access Control Facility)
miteinander. Es besteht oftmals der Bedarf, Passwortnderungen oder RACF-
Kommandos ber mehrere z/OS-Systeme des Verbundes zu synchronisieren.
Bei der Passwort-Synchronisation werden die Passwrter der Anwender auf
mehreren z/OS-Systemen automatisiert synchronisiert, so dass der Anwender
nur ein Passwort verwenden muss.
Bei der RACF-Kommando-Synchronisation knnen RACF-Kommandos auf
mehreren z/OS-Systemen parallel ausgefhrt werden. Das entsprechende
RACF-Kommando wird an einem System eingegeben und durch die zentrale
RACF-Administration an alle anderen Systeme weitergeleitet. RACF unter-
sttzt dies durch das Feature RRSF (RACF Remote Sharing Facility).
Solche Verbnde werden auch Synchronisierungs-Verbund genannt. Fr einen
Synchronisierungs-Verbund sind die folgenden Empfehlungen zu beachten.
Standardisierung
Es muss sichergestellt werden, dass der Aufbau und die verwendeten Regeln
der RACF-Datenbanken auf allen Systemen des Synchronisierungs-Verbunds
mglichst identisch sind. Vor der Einrichtung eines Synchronisierungs-Ver-
bunds sollte eine mglichst weitgehende Standardisierung durchgefhrt
werden (siehe M 2.285 Festlegung von Standards fr z/OS-Systemdefini-
tionen).
Sperren einer Benutzerkennung
Bei der Passwort-Synchronisation muss verhindert werden, dass das Sperren
(Revoke) einer Benutzerkennung nach mehrmaliger Falscheingabe des Pass-
wortes an alle anderen Systeme des Synchronisations-Verbundes weiterge-
leitet wird. Der Benutzer wre sonst auf allen Systemen ausgesperrt. Ein Ent-
sperren (Resume) kann beliebig oft bertragen werden.
Weiterleiten von RACF-Kommandos
Bei der RACF-Kommando-Synchronisation muss mit uerster Sorgfalt vor-
gegangen werden. Denn fehlerhafte RACF-Kommandos, die zu ungewollten
nderungen fhren, werden sofort auf allen Systemen des Synchronisations-
Verbundes ausgefhrt. Es sollte deshalb berlegt werden, besonders sicher-
heitskritische RACF-Kommandos, welche die Stabilitt der angebundenen
Systeme beeinflussen knnen, von der Synchronisation auszuschlieen.
Absichern der Verwaltungsfunktion
Die Schnittstelle zu der Verwaltungs-Funktion des Synchronisations-Pro-
grammes (oft eine ISPF-Oberflche - Interactive System Productivity Facility)
darf nur autorisierten Mitarbeitern im Rahmen ihrer Ttigkeit zur Verfgung
stehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schadensbegrenzung durch Aufteilen des Verbundes

Zur Schadensbegrenzung bei der RACF-Kommando-Synchronisierung ist zu
berlegen, einen groen Synchronisierungs-Verbund in zwei oder mehrere
kleine Teilverbnde zu zerlegen.
Die Ausfhrung von fehlerhaften, sicherheitskritischen RACF-Kommandos
kann dadurch auf den jeweiligen Teilverbund beschrnkt werden. Ein Total-
ausfall aller Systeme, der auf fehlerhafte RACF-Kommandos zurckzufhren
ist, kann auf diese Weise unter Umstnden vermieden werden.
Die fr den Betrieb notwendigen Festplatten der Systeme eines Teilverbundes
mssen an die Systeme eines anderen Teilverbundes angeschlossen werden
knnen. Dadurch knnen betriebswichtige Daten eines ausgefallenen Teilver-
bundes, wie die RACF-Datenbank, zumindest teilweise wieder hergestellt
werden.
Die Aufteilung eines groen Synchronisierungs-Verbundes in mehrere
kleinere Teilverbnde fhrt zu einem erhhten Administrationsaufwand. Denn
jeder Teilverbund muss separat administriert werden.
- Wird verhindert, dass das Sperren einer Benutzerkennung automatisiert
weitergeleitet wird?
- Haben nur autorisierte Mitarbeiter Zugang zur Verwaltungs-Funktion des
Synchronisations-Programms?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.295 Systemverwaltung von z/OS-Systemen

Die Systemverwaltung eines z/OS-Systems ist in verschiedene Bereiche auf-
geteilt. Fr viele Aufgaben gibt es in den Rechenzentren Spezialisten, die oft
nur ganz bestimmte Ttigkeiten auf den z/OS-Systemen ausfhren. Bei der
Systemverwaltung sind nachfolgende Empfehlungen zu beachten:
Unterteilung in Rollen
Es sollte ein Rollenkonzept eingefhrt werden. Dies ermglicht die Zuord-
nung von System-Berechtigungen zu den Rollen und erleichtert hiermit die
Arbeit der RACF-Administration.
Um die Vergabe von hohen Berechtigungs-Attributen im RACF zu redu-
zieren, sollte berlegt werden, die Administration in mindestens folgende
Rollen zu unterteilen:
- Systemadministration
Die Systemadministration (kein besonderes RACF-Attribut) ist fr die
Installation und Wartung der z/OS-Systeme verantwortlich. Ihre Berech-
tigungen drfen nur die zu dieser Ttigkeit ntigen Arbeiten am System
erlauben. Zugriffe auf Kundendaten sollten nur in Ausnahmefllen
genehmigt werden (z. B. bei der Fehlersuche). Solche Zugriffe mssen mit
dem jeweiligen Informationseigentmer abgestimmt werden.
- RACF-Administration
Die RACF-Administration (RACF-Attribut SPECIAL) hat die folgende
Aufgabe: Administration des Sicherheitsprogramms RACF sowie Anlegen
und Lschen von Kennungen und Autorisierungen. Der RACF-
Administrator vergibt und entzieht die Rechte auf Ressourcen im z/OS-
System. Hieraus ergibt sich eine besondere Vertrauensstellung. Aus
Sicherheitsgrnden sollte die Zahl der Mitarbeiter, die dieser Rolle zuge-
ordnet sind, auf ein Minimum begrenzt sein.
- Space-Management
Das Space-Management (RACF-Attribut OPERATIONS) ist fr die Ver-
waltung der Datentrger in z/OS-Systemen verantwortlich. Das Attribut
OPERATIONS erlaubt den Zugriff auf alle Daten des Systems. Es sollte
berlegt werden, Kennungen mit dem Attribut OPERATIONS in die
ACCESS-Liste eines RACF-Profiles mit NONE aufzunehmen. Hierdurch
wird der Zugriff ber die OPERATIONS-Berechtigung verhindert. Aller-
dings knnen diese Dateien dann auch nur bedingt vom Space-Manage-
ment verwaltet (z. B. Plattenverlagerung) werden.
- Operating
Das Operating (kein besonderes RACF-Attribut) ist fr den Betrieb der
z/OS-Systeme verantwortlich. Da die Operatoren Zugang zu den Konsolen
haben, muss das Operating in zutrittsgeschtzten Rumen durchgefhrt
werden. Aus Grnden der Nachvollziehbarkeit sollten die Schichtplne des
Operating archiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Audits
Der Auditor (RACF Attribut AUDITOR) kann alle sicherheitsrelevanten
Systemeinstellungen einsehen, aber nicht ndern. Der Auditor gleicht die
aktuellen Systemeinstellungen mit den vorgegebenen Systemeinstellungen
ab.
Stellvertreter-Regelungen
Fr alle wichtigen Rollen der Systemverwaltung mssen Stellvertreter-
Regelungen vorhanden sein. Keinesfalls darf eine wichtige Rolle nur mit einer
Person besetzt sein. Weitere Hinweise hierzu sind in M 3.10 Auswahl eines
vertrauenswrdigen Administrators und Vertreters aufgefhrt.
- Gibt es ein Rollenkonzept fr z/OS-Systeme?
- Gibt es Stellvertreter-Regelungen fr die wichtigen Rollen der System-
verwaltung?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.296 Grundstzliche berlegungen zu z/OS-

Transaktionsmonitoren
Der Einsatz von Transaktionsmonitoren muss detailliert geplant und durch
geeignete Mechanismen abgesichert werden. Als Hilfestellung werden in
dieser Manahme einige Empfehlungen im berblick beschrieben, die sich
aus Sicht der IT-Sicherheit beim Betrieb von Transaktionsmonitoren bewhrt
haben. Je nach Einsatzszenario sind in der Regel weitere spezifische
Planungen und Sicherheitsmechanismen erforderlich, die hier nicht dargestellt
werden knnen. Insbesondere wird in dieser Manahme nicht der
Datenbankteil von IMS betrachtet.
Transaktionsmonitore werden auf Mainframe-Systemen fr den Online-
Betrieb eingesetzt. Sie ermglichen den Anwendern, im Dialogbetrieb auf die
gewnschten Daten ber nachgeschaltete Datenbanksysteme zuzugreifen.
Dabei gehrt es zu den Kernaufgaben des Transaktionsmonitors
sicherzustellen, dass die folgenden Bedingungen erfllt werden:
- Eine Transaktion muss immer komplett durchgefhrt werden. Ist das nicht
realisierbar, muss das System auf den vorherigen Stand zurckgesetzt
werden (Roll-Back).
- Das System sollte sich vor und nach der Transaktion in einem konsistenten
Zustand befinden, ansonsten muss das System zurckgesetzt werden.
- Jeder Anwender soll nur Zugriff auf seine Daten erhalten und sollte isoliert
sein von allen anderen Daten.
- Nach Durchfhrung der Transaktion muss sichergestellt werden, dass der
vernderte Zustand gespeichert wird und spter in der gleichen Form zur
Verfgung steht. Im Falle eines Systemausfalls mssen die noch nicht
gespeicherten Transaktionen notfalls automatisch wiederholt werden.
Diese Bedingungen gelten sowohl fr den Online-Betrieb, als auch fr
Transaktionen, die im Batch-Betrieb durchgefhrt werden.
Transaktionsmonitore werden heute blicherweise in einer sogenannten Drei-
Tier-Konfiguration (Tier = Stufen) eingesetzt (Prsentation, Anwendungs-
logik, Datenhaltung) und decken normalerweise die folgenden Kernfunktionen
ab:
- Message Queuing (Verwalten des Nachrichten-Flusses)
- Lock-Verwaltung (Verwaltung der Zugriffe und gegenseitige Absicherung)
- Logging (Verwaltung der Log-Funktionen)
- Roll-Back Funktionen (Zurckspringen auf den vorherigen Zustand)
- Laststeuerung (Load Balancing)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Two-Phase Commit-Synchronisation (stellt sicher, dass eine Transaktion

komplett durchgefhrt wird oder ein Roll-Back erfolgt)
Als Transaktionsmonitor wird u. a. IMS TM (Information Management
System Transaction Monitor) oder CICS (Customer Information Control
System) eingesetzt. Als Datenbanksystem steht fr IMS der IMS-eigene DB-
Teil, VSAM-Datenbanken (Virtual System Access Method) oder DB2
(Database 2) zur Verfgung. Fr CICS knnen VSAM, IMS DB oder DB2 als
Datenbanksysteme eingesetzt werden.
Auch wenn die Transaktionsmonitore und Datenbanksysteme aus historischen
Grnden eigene interne Schutzsysteme zum Teil noch anbieten, wird in der
heutigen Zeit meistens ergnzend ein Sicherheitssystem wie RACF (Resource
Access Control Facility) eingesetzt. Mit RACF knnen die Authentisierung
des Benutzers, der Schutz der Transaktionen und der Zugriffsschutz auf
Datenelemente realisiert werden.
Allgemeine berlegungen
Die Transaktionsmonitore IMS TM und CICS sind von der historischen
Entwicklung her reine VTAM-Applikationen. Sie waren zu Beginn der
Entwicklung fr interne Netze konzipiert. Im Laufe der letzten Jahre sind
jedoch durch die steigende Bedeutung des Internets erweiterte Schnittstellen
bereitgestellt worden. Diese ermglichen es, Zugriffe auf Anwendungen
dieser Transaktionsmonitore auch vom Internet aus zu erlauben.
Die folgenden Empfehlungen gelten fr den gesamten Bereich der
Transaktionsmonitore und schlieen die Datenbanken mit ein:
- Alle Sicherheitsmechanismen sollten mglichst durch RACF gesteuert
werden. Die internen Sicherheitsmechanismen sind nur dort zu benutzen,
wo es keine adquaten RACF-Funktionen gibt.
- Es sollten vor Inbetriebnahme eines Transaktionsmonitors, wie IMS oder Standards
CICS, oder eines Datenbanksystems, wie DB2, Standards fr alle
relevanten Definitionen entwickelt werden. Die Standards sollten
Transaktionsnamen, Tabellennamen, Resource Classes, etc. betreffen.
Solche Standards helfen dabei, Fehler bei RACF-Definitionen zu
vermeiden (siehe M 2.285 Festlegung von Standards fr z/OS-
Systemdefinitionen).
- Es sollte berlegt werden, ob die Einfhrung von Rollen-Konzepten (siehe Rollen einfhren
M 2.30 Regelung fr die Einrichtung von Benutzern / Benutzergruppen)
die Verwaltung der Benutzer erleichtert.
- Sicherheitsmechanismen sollten bei Transaktionsmonitoren immer so Externalisierung der
Sicherheitsmechanis-
aktiviert werden, dass das entsprechende Regelwerk extern definiert men
werden kann. Der Einsatz externer Sicherheitsfunktionen, wie RACF-
Definitionen, sollte immer eventuell vorhandenen internen Funktionen
vorgezogen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
IMS TM (Transaction Monitor, vorher DC genannt)

Die folgenden Empfehlungen gelten fr den IMS Transaktionsmonitor. Je
nach Einsatzszenario sind in der Regel weitere Sicherheitsmechanismen
erforderlich.
- IMS sollte ber die Definition im IMS Security Makro so eingestellt
werden, dass IMS RACF verwendet (Parameter TYPE = RACFAGN /
RACFTERM / RACFCOM). Das IMS System muss durch die RCLASS
Definition so definiert werden, dass dieser Name (die IMS-ID) in RACF
als Resource Class gefhrt werden kann. Ist mehr als ein IMS im z/OS-
System in Betrieb, sollte berlegt werden, ob die standardmig in RACF
vorhandenen Namen benutzt werden sollen (z. B. AIMS, TIMS usw.) oder
ob eigene (unterschiedliche) Namen vergeben werden sollten. Bei der
Benutzung von eigenen Namen mssen diese als Resource Classes in
RACF eingetragen werden.
ber das IMS Security Makro knnen u. a. die folgenden Prfungen
aktiviert werden (Benutzung der Default IMS-ID IMS):
- AGN Prfung ber RACF (ber Klasse AIMS), Ablegen der gltigen
User-IDs fr IMS in RACF (RDEFINE)
- Transaktions-Autorisierung (ber Klasse TIMS oder GIMS und
SECLVL=TRANAUTH im Security Makro)
- Terminal Security (SECLVL=SIGNON / FORCSIGN im Security
Macro und Resource Class TERMINAL in RACF)
- Kommando Autorisierung (ber Klasse CIMS oder DIMS)
Existiert ein Parallel Sysplex mit Datasharing, sollte als RCLASS Wert die
IMS-ID des Master-IMS benutzt werden.
- Es sollte berlegt werden, ob zur Signon Verifizierung ein Exit
(DFSSGNX0) eingesetzt werden sollte (falls die RACF Prfung nicht
ausreichend granular ist).
- Es mssen in RACF Standard Profile fr die einzelnen Resource Classes
eingerichtet werden, zu denen die Applikations-Anwender zugelassen
werden knnen. Es ist empfehlenswert, vor Beginn der Definitionen
Standards zu entwickeln, die die Definitionen erleichtern.
- Es sollte berlegt werden, ob die Sicherheitsanforderungen eine Terminal- RACF Terminal Security
Security ber RACF notwendig machen (Class Terminal). Vorsicht ist
geboten bei Einfhrung eines restriktiven Schutzes gegen nicht definierte
Terminals, z. B. mit dem RACF Kommando SETROPTS
TERMINAL(NONE): Es mssen mindestens einige Terminals fr die
Benutzung von RACF unter TSO freigeschaltet sein, da sich sonst niemand
mehr auf dem System anmelden kann!
- Das Mapping von RACF-Resource Classes auf die internen IMS Security
Regeln erfolgt ber Definitionen, die ber den SMU-Prozess (Security
Management Utility) verarbeitet werden. Aus der Definitionsdatei wird
ber einen Preprocessor und nachfolgendem Assembly und Link ein
Loadmodule erzeugt, das auf dem IMS Matrix Dataset gestellt wird und in
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
dem u. a. die IMS Security Definitionen in Kontrollblockform zur

Verfgung stehen. Die Datei des Quellcodes darf nur von Mitarbeitern
zugreifbar sein, die diese Datei im Rahmen ihrer Ttigkeit bentigen.
- Zugriffe auf IMS aus dem TCP/IP-Netz (z. B. aus dem Internet) erfolgen
ber die OTMA-Schnittstelle (OpenTransaction Manager Access). Zur
Absicherung dieser Verbindung muss ber den Parameter OTMASE=xxx
mindestens CHECK (besser FULL) sichergestellt werden, dass RACF zur
Verifizierung eingesetzt wird. IMS Kommandos werden dabei gegen die
Klasse CIMS, Transaktionen gegen TIMS geprft. Die Gltigkeit der
Verbindung sollte ber Profile in der FACILITY Klasse in RACF
sichergestellt werden.
- Es ist zu berlegen, ob die IMS Programme (Control Region, Message
Processing Region, Utilities) zur Erhhung der Sicherheit ber die RACF
Klasse Program geschtzt werden sollen.
- Die IMS Dateien mssen ber RACF Dataset Profile so geschtzt werden,
dass nur Mitarbeiter Zugriff zu den Dateien haben, die sie im Rahmen ihrer
Ttigkeit auch bentigen. Anwender von IMS bentigen keinen Zugriff auf
die IMS Dateien. Zu schtzende Dateien sind z. B.
- APF-Dateien (Authorized Programming Facility)
- System-Dateien
- Anwender-Dateien wie z. B. PSB-, DBD-, ACB- und PGM-LIB
Der Zugriff auf APF- und System-Dateien darf nur fr die STC-User-IDs
(Started Task Control) und autorisierte Mitarbeiter freigegeben werden.
Normale Anwender bentigen keinen Zugriff auf diese Dateien (siehe auch
M 4.209 Sichere Grundkonfiguration von z/OS-Systemen).
Der Zugriffsschutz von Anwender-Dateien muss durch RACF Definitionen
erfolgen (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
- MVS Kommandos fr IMS sollten ber RACF geschtzt werden
(siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
- Die Started Tasks sollten ber die RACF Klasse STARTED
abgesichert werden (siehe M 4.211 Einsatz des z/OS-
Sicherheitssystems RACF).
- Bei besonders hohen Sicherheitsanforderungen an IMS kann auch der
Zugang zur IMS Kontroll-Region generell durch die RACF Resource Class
APPL auf der Basis des VTAM LU-Namens abgesichert werden. Da jeder
Anwender hierbei entweder als einzelner User oder in Gruppen definiert
werden muss, ist zu beachten, dass dadurch ein erhhter
Administrationsaufwand entsteht. Dies gilt besonders fr Installationen mit
vielen Anwendern.
CICS
Die folgenden Empfehlungen gelten fr den CICS Transaktionsmonitor. Je
nach Einsatzszenario sind in der Regel zustzliche Sicherheitsmechanismen
erforderlich. Weitere Informationen sind in der IBM Dokumentation CICS
RACF Security Guide zu finden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sollen die CICS-Regions im Modus Non-Swappable laufen (PPT-Eintrag

im SCHEDnn Parmlib-Member), muss sichergestellt werden, dass die
Option NOPASS fr das Modul DFHSIP im PPT-Eintrag (Program
Property Table) nicht gesetzt wird. Die Option NOPASS umgeht
Passwort- und RACF-Prfungen.
- Die Started Task User-IDs mssen so definiert werden, wie M 4.211
Einsatz des z/OS-Sicherheitssystems RACF beschrieben ist. Die User-IDs
von CICS Started Tasks drfen nicht das Attribut OPERATIONS besitzen.
- Die CICS Dateien mssen ber RACF Dataset Profile so geschtzt werden,
dass nur Mitarbeiter Zugriff auf die Dateien haben, die sie im Rahmen
ihrer Ttigkeit auch bentigen. Zu schtzende Dateien sind z. B.
- System-Dateien
- Anwender-Dateien wie z. B. PSB-, DBD-, ACB- und PGM-LIB
- Der Zugriff auf APF- und System-Dateien darf nur fr die STC-User-IDs
Normale Anwender bentigen keinen Zugriff auf diese Dateien (siehe auch
in M 4.209 Sichere Grundkonfiguration von z/OS-Systemen).
Der Zugriff auf Anwender-Dateien muss im Rahmen der RACF Regeln
- MVS Kommandos fr CICS sollten ber RACF geschtzt werden (siehe
dies M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
- Die Aktivierung von RACF fr die CICS-Security erfolgt in der SIT
(System Initialization Table) durch Setzen des Parameters SEC=YES. In
der SIT kann auch definiert werden, ob Transaktionsschutz,
Programmschutz oder Feldschutz von Eingabemasken ber RACF aktiviert
werden soll. Es muss sichergestellt werden, dass diese Modifikationen nur
von autorisierten Mitarbeitern durchgefhrt werden knnen. Dabei ist zu
beachten, dass die Auswahl der SIT sowohl ber SYSIN Eingabe als auch
ber einen Parameter im EXEC Statement der Prozedur (in der Job Control
Language) definiert werden kann. Das SIT-Modul muss in eine APF-
Bibliothek eingestellt und ber RACF Profile so geschtzt werden, dass
nur die fr diesen Bereich zustndigen Mitarbeiter Zugriff haben (siehe
M 4.211 Einsatz des z/OS-Sicherheitssystems RACF). Auch die Quell-
Datei der SIT darf nur zugreifbar sein fr die dazu befugten Mitarbeiter
und muss mit entsprechenden RACF Dateiprofilen geschtzt werden.
- Die Kommando Security muss bei der Definition der Transaktionen
eingeschaltet sein (CMDSEC Parameter). Es ist zu berlegen, ob durch
SECPRFX=YES die Systeme voneinander unterschieden werden sollen.
Dies ist empfehlenswert bei verschiedenen CICS-Jobs in einem System.
- Die Prozeduren der CICS Regions stehen auf einer (oder mehreren)
Prozedur-Bibliothek(en). Diese mssen durch RACF so geschtzt werden,
dass nur Mitarbeiter diese Prozeduren verndern knnen, die im Rahmen
ihrer Ttigkeit darauf Zugriff haben mssen. Es ist zu berlegen, ob eine
separate PROCLIB (mit entsprechender Verknpfung zu den anderen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
PROCLIBs) das Sicherheitsniveau erhht und das Missbrauchsrisiko durch

getrennte Zugriffsdefinitionen dadurch verringert werden kann.
- Die Anmeldung an CICS muss ber die Eingabe von RACF User-ID und
Passwort erfolgen. Es ist zu empfehlen, eine Signon-Maske fr die
Anmeldung an CICS vorzusehen. Fr jede CICS Region muss daher ein
Default-User in RACF definiert sein. Die in der Default-User-ID im CICS-
Segment definierten Vorgaben werden von CICS fr alle Terminal
Sessions verwendet, bis ein Signon mit der persnlichen User-ID
durchgefhrt wurde. Es wird empfohlen, die Default-User-ID nur mit sehr
geringen Rechten auszustatten.
- Die General Resource Classes Txxxxxxx (Member Class) und Gxxxxxxx
(Group Class) sollten fr Transaktionssicherheit, die Klassen Cxxxxxxx
(Member Class) und Vxxxxxxx (Group Class) fr Kommando Sicherheit
aktiviert werden (ber das Kommando SETROPTS).
- Sicherheitsmechanismen in der Anwendung (Applikation) sollten nur dort
implementiert werden, wo keine adquaten Sicherheitsfunktionen von
RACF oder anderen Sicherheitssystemen zur Verfgung stehen.
- Es ist zu berlegen, ob ein Terminalschutz auf Basis der VTAM-LU
(Logical Unit) aktiviert werden soll. Diese Manahme erhht den Schutz,
bedeutet jedoch mehr Verwaltungsaufwand.
- Der Zugang zu der CICS Region kann ber den VTAM ACB-Namen
(Access Control Block) ber RACF kontrolliert werden. Sollte diese
Kontrolle eingesetzt werden, empfiehlt es sich, ein Gruppenkonzept
aufzubauen, um den Verwaltungsaufwand mglichst gering zu halten.
- Fr die CICS Transaktionen und System Kommandos sind
unterschiedliche Gruppen zu bilden. Alle CICS Administrations-
Transaktionen und alle kritischen CICS Kommandos sollten so geschtzt
werden, dass nur die Mitarbeiter Zugriff zu diesen Transaktionen haben,
die sie im Rahmen von Administrationsttigkeiten auch bentigen. Eine
Vertretungsregelung sollte vorhanden sein. Es ist zu berlegen, ob es
erforderlich ist, weitere CICS Resource Classes einzusetzen (siehe CICS
RACF Security Guide).
- CICS Systemdefinitionen knnen entweder ber die RCT (Resource CICS System
Definitionen
Control Table) oder ber die CSD (CICS System Definitions)
vorgenommen werden. Whrend die ltere RCT noch als Loadmodule via
Assembly und Link erstellt wird, wird die CSD durch den RDO Dialog
(Resource Definition Online) ber die Transaktionen CEDA, CEDB und
CEDC als VSAM-Datei erstellt und von CICS eingelesen. In beiden Fllen
mssen sowohl die relevanten Dateien als auch die Transaktionen durch
RACF Profile so geschtzt werden, dass nur CICS-Administratoren Zugriff
auf diese Definitionen haben. Hier wird u. a. auch das CICS-DB2
Attachment ber das Makro DB2CONN definiert, in dem z. B. der Name
des DB2 Subsystems, die Berechtigungen auf bestimmte Kennungen oder
Relationen zwischen Transaktion, DB2 Plan und Programm festgelegt
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es ist zu berlegen, ob CEDC (die nur lesende Aktionen durchfhrt) auch

geschtzt werden soll. Dies hngt vom Inhalt der Daten ab.
DB2
Die folgenden Empfehlungen gelten fr das DB2-Datenbanksystem. Je nach
Einsatzszenario sind in der Regel zustzliche Sicherheitsmechanismen
erforderlich. Weitere Informationen sind in der IBM Dokumentation DB2
UDB Administration Guide zu finden:
- Fr jedes DB2-Subsystem muss ein Eintrag in der RACF Router Table
vorgenommen werden, da diese Eintrge standardmig nicht mit
ausgeliefert werden.
- Die General Resource Class DSNR muss ber das Kommando SETROPTS
aktiviert werden. Die Profile mssen gem DB2 Dokumentation definiert
und Zugriffe dazu ber PERMIT Kommandos eingerichtet werden. Vorher
sollte ein Gruppenkonzept entwickelt werden, wie es beispielhaft in der
IBM Dokumentation DB2 UDB Administration Guide beschrieben ist. Ist
eine VTAM LU 6.2 Verbindung (Virtual Telecommunication Access
Management) im Einsatz, sollte berlegt werden, ob ein zustzlicher
Schutz ber die Klasse APPCLU zweckmig ist.
- Die DB2 Dateien mssen ber RACF Dataset Profile so geschtzt werden,
dass nur Mitarbeiter Zugriff auf die Dateien haben, die sie im Rahmen
ihrer Ttigkeit auch bentigen. Zu schtzende Dateien sind z. B.
- System-Dateien
- Anwender-Dateien als Datenbanken
Der Zugriff auf APF- und System-Dateien darf nur fr die STC-User-IDs
Andere Anwender bentigen keinen Zugriff auf diese Dateien (siehe auch
M 4.209 Sichere Grundkonfiguration von z/OS-Systemen).
Der Zugriff auf Anwender-Dateien muss im Rahmen der RACF Regeln
- Der Zugriff auf die Prozedurbibliotheken der DB2 Started Tasks ist durch
RACF Dateiprofile zu schtzen (siehe M 4.209 Sichere
Grundkonfiguration von z/OS-Systemen).
- MVS Kommandos fr DB2 sollten ber RACF geschtzt werden (siehe
M 4.211 Einsatz des z/OS-Sicherheitssystems RACF).
- Die DB2 Started Task User-IDs mssen in der RACF Klasse STARTED als
Protected User definiert werden. Die User-IDs bentigen Zugriffe auf die
Dateien der Started Task Prozeduren.
- Alle DB2 Dateien sollten ber RACF Dataset Profile abgesichert werden,
wobei normale Benutzer keinen direkten Zugriff auf die Datenbank haben
sollten. Direkte Zugriffe sollten auf die Administratoren beschrnkt
bleiben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Es ist zu empfehlen, keine DB2 GRANT PUBLIC Genehmigung auf DB2-

Katalog-Tabellen zu erteilen. Statt dessen sollten Zugriffsrechte auf der
Ebene von Benutzergruppen vergeben werden.
- Es wird empfohlen, die internen System-Tabellen nur ber DB2-Admin
Kommandos (GRANT in DB2) zu schtzen. Zugriffsrechte auf User-
Tabellen sollten ber RACF Gruppen vergeben werden. Dabei muss die
RACF Gruppe in DB2 durch entsprechende GRANTs autorisiert werden.
Die Autorisierung einzelner User-IDs oder (besser) ganzer Gruppen lsst
sich durch das RACF Kommando Permit realisieren. Alle
Sicherheitsdefinitionen sollten mglichst zu RACF verlegt werden.
- Wird zum Schutz der Transaktionen und der Transaktionsmonitore ein
Sicherheitssystem wie RACF eingesetzt?
- Sind die Started Tasks von IMS, CICS oder DB2 ber RACF gesichert?
- Gibt es ein Gruppenkonzept fr den IMS Transaktionsmonitor?
- Werden die CICS General Resource Classes eingesetzt?
- Sind alle DB2 Dateien ber RACF Dataset Profile abgesichert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.297 Deinstallation von z/OS-Systemen

Wird ein z/OS-System nicht mehr bentigt, so reicht es nicht, das System
einfach auszuschalten. Beim Abbau eines z/OS-Systems oder eines Parallel-
Sysplexes sollten die folgenden Empfehlungen beachtet werden:
Festplatten lschen
Alle Festplatten, die sensitive Daten wie Kundendaten enthalten, mssen so
gelscht werden, dass ihr Inhalt nicht mehr reproduziert werden kann. Hierfr
kann ein Programm wie ICKDSF eingesetzt werden. Das Lschen kann u. U.
auch durch die Herstellerfirma durchgefhrt werden. Sind Festplatten, auch
einzelne, defekt und mssen deshalb vom Hersteller ausgetauscht werden, ist
sicherzustellen, dass die ausgetauschte Festplatte durch den Hersteller ver-
nichtet wird. Dies sollte vertraglich vereinbart werden. Entsprechendes gilt
auch fr den Austausch eines kompletten Festplattenschranks. Vor der
Weitergabe von Datentrgern an Dritte muss in jedem Fall geprft werden, ob
der Schutzbedarf der gespeicherten Daten dies zulsst (siehe auch M 2.167
Sicheres Lschen von Datentrgern).
Kennungen lschen
Alle Kennungen des deinstallierten Systems mssen gelscht werden, sofern
dies nicht schon automatisch durch den Abbau erfolgt. Wenn ein System aus
einem Parallel-Sysplex herausgelst wird, so sind die Kennungen und Aliase
auf den anderen Systemen des Parallel-Sysplex zu lschen.
Die betroffenen Kennungen mssen aus den Verwaltungssystemen (z. B.
Benutzerverwaltung) entfernt werden.
System-Namen entfernen
Die System-Namen (SYSIDs) mssen aus den System-Listen entfernt werden.
Falls ein System aus einem Parallel-Sysplex genommen wird, muss der
System-Name aus den Sysplex-Definitionen entfernt werden.
System entfernen
Das System muss aus dem Passwort-Synchronisierungsverfahren entfernt
werden, falls ein solches Verfahren in Betrieb ist (siehe M 2.294 Synchroni-
sierung von z/OS-Passwrtern und RACF-Kommandos).
Das System muss aus allen Terminal-Monitor-Programmen, z. B. TPX Terminal-Monitor-
Programme
(Terminal Productivity Executive) oder NV/AS (NetView/Access), entfernt
werden.
Das System muss aus den NJE-Definitionen (Network Job Entry) des JES2/3 NJE-Definitionen
korrigieren
entfernt werden.
Berichtswesen
Das Berichtswesen ist darauf zu berprfen, ob Definitionen entfernt und
eventuell Tabellen gelscht werden mssen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Automation
Vorhandene Automationsverfahren sind darauf zu untersuchen, ob Defini-
tionen angepasst werden mssen.
Lizenzschlsselverwaltung
Da sich durch den Abbau die Anzahl der Systeme reduziert hat, sollte geprft
werden, ob Software-Lizenzen nicht mehr bentigt werden und daher abbe-
stellt werden knnen.
- Werden sensitive Daten auf frei werdenden Festplatten vollstndig
gelscht?
- Trgt das Lschverfahren dem Schutzbedarf der gespeicherten Informa-
tionen Rechnung?
- Wird das zu deinstallierende System aus allen relevanten Tabellen ent-
fernt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.298 Verwaltung von Internet-Domainnamen

Internet-Domainnamen (Domains) mssen bei Registrierungsstellen
(Registrars) angemeldet werden. Eine Registrierungsstelle kann Namen fr
eine oder mehrere sogenannte Top-Level-Domains (beispielsweise die
"klassischen" Domains .com, .org, .gov und die diversen Lnder-Domains wie
.de fr Deutschland, .at fr sterreich und .ch fr die Schweiz) vergeben.
Domains werden jeweils fr einen bestimmten Zeitraum registriert. Ist dieser
Zeitraum abgelaufen, so muss die Registrierung gegen Zahlung einer Gebhr
verlngert werden. Wird die Verlngerung einer Registrierung vergessen, so
kann dies unangenehme Folgen haben (siehe G 2.100 Fehler bei der
Beantragung und Verwaltung von Internet-Domainnamen). Es muss daher
sichergestellt sein, dass die Registrierungen fr alle Domains, die von einer
Organisation benutzt werden, regelmig und rechtzeitig verlngert werden.
Dazu sollte in jeder Organisation eine Stelle festgelegt werden, die die
Verwaltung der Domainnamen bei den verschiedenen Registrierungsstellen
koordiniert.
Neben der Verwaltung der Domainnamen und der Sicherstellung der
rechtzeitigen Verlngerung der Registrierungen sollten beim Management von
Internet-Domainnamen auch folgende Punkte bercksichtigt werden:
DNS Nameserver
Bei der Registrierung eines Domainnamens mssen mindestens zwei DNS- Primary Nameserver in
verschiedene Subnetze
Nameserver (Primary Nameserver) angegeben werden, die fr die Zuordnung
von Rechnernamen zu IP-Adressen zustndig sind. Ein Nameserver wird oft
vom Internet-Zugangsprovider betrieben, kann aber auch von der Organisation
selbst betrieben werden. Bei der Festlegung der Nameserver sollte zumindest
darauf geachtet werden, dass die Primary Nameserver in verschiedenen
Class-C Netzen liegen. Ist dies nicht der Fall, so kann ein Denial of Service
Angriff auf den Router, mit dem dieses Netz ans Internet angebunden ist, die
komplette Domain lahm legen, da keine Namen aus dieser Domain mehr
aufgelst werden knnen. Bei hohen Anforderungen an die Verfgbarkeit der
Namensauflsung sollten die Primary Nameserver idealerweise in
verschiedenen Netzen mit Anbindung ber unterschiedliche Provider
angesiedelt werden
Domainnamen
Zu Anfang des "Internet-Zeitalters" reichte es meist aus, wenn eine Domains mit Firmen-
und Produktnamen
Organisation eine einzige Internet-Domain betrieb. Mit der wachsenden
Popularitt des World-Wide-Web wurde es blich, nicht nur eine Domain mit
beispielsweise dem eigenen Firmennamen zu betreiben, sondern auch fr
bekannte Produkte Domains einzurichten.
Um zu verhindern, dass Domains mit dem Namen eigener Produkte und Domain-Grabbing
vorbeugen
Dienstleistungen von Anderen registriert werden, die unter dieser Adresse
dann eventuell pornographische oder andere anstige Inhalte verbreiten, die
von Besuchern dann mit der eigenen Organisation in Verbindung gebracht
werden, sollten soweit mglich nicht nur der eigene Firmenname und die
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Namen bekannter eigener Produkte in der korrekten Schreibweise registriert

werden, sondern jeweils auch Varianten davon, etwa mit oder ohne
Bindestrichen bei zusammengesetzten Namen. Diese Namen sollten unter den
verschiedenen "relevanten" Top-Level-Domains (etwa .de, .com, .org, .info)
registriert werden. Auerdem sollte geprft werden, ob nicht auch bestimmte
falsch geschriebene Varianten (etwa bestimmte "Buchstabendreher") von
Produkt- oder Firmennamen registriert werden sollten. Der dadurch
entstehende Mehraufwand ist gering im Vergleich zu dem Aufwand,
gegebenenfalls die "Herausgabe" einer Domain gerichtlich erzwingen zu
mssen.
Fr solche "sicherheitshalber" registrierten Domains sollte zumindest ein
minimales Webangebot eingerichtet werden, das den Domainnamen nennt, auf
dem das eigentliche Angebot eingerichtet ist und eine Weiterleitung dort hin
anbietet. Gegebenenfalls kann auch einfach der Haupt-Webserver der
Organisation ber eine entsprechende Namensauflsung auch als Webserver
fr diese Domain agieren.
Registrierungsstellen und Registrierungszeitrume
Fr mehrere Top-Level Domains (etwa .com und .org) existieren verschiedene
Registrierungsstellen. Ein Wechsel der Registrierungsstelle ist jederzeit
mglich, aber meist mit Kosten verbunden.
Es ist wichtig, fr alle registrierten Domains einen berblick ber die bersicht ber
Laufzeiten, Preise und
jeweilige Laufzeit der Registrierung, den Preis fr die Verlngerung und die Kontakte behalten
Bankverbindung der Registrierungsstelle zu haben, um eine rechtzeitige
Verlngerung der Registrierung sicher zu stellen.
Vertragsgestaltung mit Internetdienstleistern
Wenn die Domains der Organisation nicht in Eigenregie registriert und
verwaltet werden, sondern dies ber einen Internetdienstfeister geschieht, so
muss bei der Vertragsgestaltung darauf geachtet werden, dass die Organisation
selbst die Kontrolle ber die Domains behlt. Dies kann beispielsweise bei
einem eventuellen Wechsel des Registrars oder bei der Auflsung von
Namensstreitigkeiten von Bedeutung sein.
Fr den Fall von Fehlern und Versumnissen des Dienstleisters im Bezug auf
die Verwaltung von Domainnamen sollten entsprechende Regelungen
getroffen werden, da in solchen Fllen erheblicher Schaden entstehen kann
(siehe G 2.100 Fehler bei der Beantragung und Verwaltung von Internet-
Domainnamen).
Falls die Nameserver nicht in der Organisation selbst betrieben, sondern bei
einem Dienstleister gehostet werden, sollten in den Service-Level-Agreements
insbesondere Vereinbarungen ber die Anforderungen an die Verfgbarkeit
der Nameserver und an Bearbeitungszeiten fr nderungen im DNS der
Organisation getroffen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Welche Domainnamen wurden registriert?
- Existiert ein berblick ber Laufzeiten, Preise und Kontakte fr die
Domainregistrierungen?
- Wo werden die Nameserver der Organisation betrieben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.299 Erstellung einer Sicherheitsrichtlinie fr ein

Sicherheitsgateway
Da das Sicherheitsgateway fr die Sicherheit des Netzes eine zentrale Rolle
spielt, ist der sichere und ordnungsgeme Betrieb besonders wichtig. Dieser
kann nur sichergestellt werden, wenn das Vorgehen in die bestehenden
sicherheitstechnischen Vorgaben integriert ist.
Die zentralen sicherheitstechnischen Anforderungen (das zu erreichende
Sicherheitsniveau) ergeben sich aus der organisationsweiten
Sicherheitsleitlinie und sollten in einer spezifischen Sicherheitsrichtlinie fr
den Betrieb des Sicherheitsgateways formuliert werden, um die bergeordnet
und allgemein formulierte Sicherheitsleitlinie im gegebenen Kontext zu
konkretisieren und umzusetzen.
In diesem Zusammenhang ist zu prfen, ob neben der organisationsweiten
Sicherheitsleitlinie weitere bergeordnete Vorgaben wie beispielsweise IT-
Richtlinien, Passwortrichtlinien oder Vorgaben zur Internetnutzung zu
bercksichtigen sind.
Die Sicherheitsrichtlinie muss allen Personen und Gruppen, die an der
Beschaffung und dem Betrieb des Sicherheitsgateways beteiligt sind, bekannt
sein und Grundlage fr deren Arbeit sein. Wie bei allen Richtlinien sind ihre
Inhalte und ihre Umsetzung im Rahmen einer bergeordneten Revision
regelmig zu prfen.
Die Sicherheitsrichtlinie sollte zunchst das generell zu erreichende
Sicherheitsniveau spezifizieren und grundlegende Aussagen zum Betrieb des
Sicherheitsgateways treffen. Nachfolgend sind einige Punkte aufgefhrt, die
bercksichtigt werden sollten:
- Allgemeine Konfigurationsstrategie: Da das Sicherheitsgateway eine
zentrale Rolle bei der Absicherung des Netzes spielt, muss es selbst (bzw.
die einzelnen Komponenten) besonders sicher konfiguriert sein.
- Regelungen fr die Arbeit der Administratoren und Revisoren:
- ber welche Zugangswege drfen Administratoren und Revisoren
auf die Systeme zugreifen (beispielsweise nur lokal an der Konsole,
ber ein eigenes Administrationsnetz oder ber verschlsselte
Verbindungen)?
- Welche Vorgnge werden mssen dokumentiert werden? In welcher
Form wird die Dokumentation erstellt und gepflegt?
- Gilt fr bestimmte nderungen ein Vieraugenprinzip? Fr besonders
sicherheitskritische nderungen an den Einstellungen des
Sicherheitsgateway ist dies dringend empfohlen.
- Nach welchem Schema werden Administrationsrechte vergeben?
- Vorgaben fr Beschaffung von Gerten anhand eines Anforderungsprofils
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Vorgaben fr die Installation und Konfiguration einzelner Komponenten

des Sicherheitsgateways
- Vorgehen bei der Erstinstallation
- berprfung der Default-Einstellungen hinsichtlich
Sicherheitsgefhrdungen
- Regelungen zur physikalischen Zugriffskontrolle
- Verwendung und Konfiguration von Konsole und sonstigen
Zugriffsarten
- Regelungen zur Benutzer- und Rollenverwaltung,
Berechtigungsstrukturen (Ablauf und Methoden der Authentisierung
und Autorisierung, Berechtigung zu Installation, Update,
Konfigurationsnderungen etc.). Nach Mglichkeit sollte ein
Rollenkonzept fr die Administration erarbeitet werden.
- Regelungen zu Erstellung und Pflege von Dokumentation, Form der
Dokumentation: Verfahrensanweisungen, Betriebshandbcher
- Vorgaben fr den sicheren Betrieb
- Absicherung der Administration (beispielsweise: Zugriff nur ber
abgesicherte Verbindungen)
- Einsatz von Verschlsselung (Standards, Schlsselstrken,
Einsatzbereiche)
- Vorgaben zu Passwortnutzung (Passwortregeln, durch Passwrter zu
schtzende Bereiche, Regeln und Situationen fr
Passwortnderungen, gegebenenfalls Hinterlegung von Passwrtern)
- Werkzeuge fr Betrieb und Wartung, Integration in ein bestehendes
Netzmanagement
- Berechtigungen und Vorgehensweisen bei Softwareupdates und
Konfigurationsnderungen
- Protokollierung
- Welche Ereignisse werden protokolliert?
- Wo werden die Protokolldateien gespeichert?
- Wie und in welchen Abstnden werden die Protokolle ausgewertet?
- Datensicherung und Recovery
- Einbindung in das organisationsweite Datensicherungskonzept
- Strungs- und Fehlerbehandlung, Incident Handling
- Regelungen fr die Reaktion auf Betriebsstrungen und technische
Fehler (lokaler Support, Fernwartung)
- Regelungen fr Sicherheitsvorflle
- Notfallvorsorge
- Einbindung in das organisationsweite Notfallvorsorgekonzept
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Revision und Audit (Verantwortlichkeiten, Vorgehen, Integration in ein

bergreifendes Revisionskonzept)
Die Verantwortung fr die Sicherheitsrichtlinie liegt beim IT-
Sicherheitsmanagement, nderungen und Abweichungen hiervon drfen nur
in Abstimmung mit dem IT-Sicherheitsmanagement erfolgen.
Bei der Erstellung einer Sicherheitsrichtlinie ist es empfehlenswert, so
vorzugehen, dass zunchst ein Maximum an Forderungen und Vorgaben fr
die Sicherheit der Systeme aufgestellt wird. Diese knnen anschlieend den
tatschlichen Gegebenheiten angepasst werden. Idealerweise wird so erreicht,
dass alle notwendigen Aspekte bercksichtigt werden. Fr jede im zweiten
Schritt verworfene oder abgeschwchte Vorgabe sollte der Grund fr die
Nicht-Bercksichtigung dokumentiert werden.
- Wurde eine Sicherheitsrichtlinie fr den Betrieb des Sicherheitsgateways
erstellt?
- Wann wurde die Sicherheitsrichtlinie zum letzten Mal aktualisiert?
- Wurde ein Sicherheitsniveau in der Sicherheitsrichtlinie definiert?
- Wurden in der Sicherheitsrichtlinie Vorgaben zur Einrichtung, zum Betrieb
und zur Strungsbehandlung von Routern und Switches beschrieben?
- Wurden in der Sicherheitsrichtlinie unterschiedliche Einsatzzwecke der
Komponenten bercksichtigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.300 Sichere Auerbetriebnahme oder Ersatz von

Komponenten eines Sicherheitsgateways
Sollen Komponenten des Sicherheitsgateway auer Betrieb genommen oder
ersetzt werden, so mssen von den Gerten alle sicherheitsrelevanten Infor-
mationen gelscht werden. Dies gilt besonders dann, wenn die Komponenten
ausgesondert und an Dritte weitergegeben (beispielsweise verkauft) werden
oder wenn ein Gert im Rahmen eines Garantieaustausches oder einer Repa-
ratur an den Hersteller oder eine Service-Firma bergeben wird, aber selbst
dann, wenn die Gerte intern weiter verwendet oder verschrottet werden.
Je nach Einsatzzweck der Komponenten knnen beispielsweise folgende In-
formationen und Daten auf den Gerten gespeichert sein:
- Konfigurationsdateien, aus denen Informationen ber die Netzstruktur der
Organisation (wie IP-Adressen, Routing-Tabellen, SNMP-Community
Strings, Access-Control-Lists oder hnliches) entnommen werden knnen
- Passwortdateien
- Protokolldateien, die sicherheitsrelevante Informationen oder
personenbezogene Daten enthalten
- Benutzerdaten, beispielsweise aus Web-Cache- oder E-Mail-Spool-
Verzeichnissen
- potentiell gefhrliche Dateien (Schadsoftware) aus "Quarantne-
Verzeichnissen"
- Zertifikate und Schlssel (etwa SSL-Zertifikate bei SSL-Proxies oder
Schlssel fr den Zugang per SSH)
Wegen der Sensibilitt dieser Informationen ist darauf zu achten, dass die Daten lschen, Erfolg
berprfen
Dateien vor der Auerbetriebnahme oder dem Austausch defekter oder veral-
teter Gerte gelscht beziehungsweise unlesbar gemacht werden. Nach dem
Lschen der Daten muss berprft werden, ob das Lschen auch erfolgreich
war. Die Vorgehensweise hngt dabei stark von der Art und vom Verwen-
dungszweck des Gertes ab. In der Sicherheitsrichtlinie fr das Sicherheitsga-
teway sollten hierfr entsprechende Verantwortlichkeiten definiert werden.
Die entsprechenden Dateien sind je nach Gert und Einsatzzweck eventuell in
mehreren unterschiedlichen Verzeichnissen gespeichert, beispielsweise befin-
den sich bei ALGs die verschiedenen Konfigurationsdateien meist an anderen
Stellen als die Cache-Dateien, Spool- oder Quarantneverzeichnisse. Vor der
Auerbetriebnahme sollte daher geklrt werden, welche sicherheitsrelevanten
Dateien an welchen Stellen gespeichert sind.
Bei "normalen" Rechnern, die als Komponenten des Sicherheitsgateway ein- Festplatten lschen
gesetzt waren, sollten die Festplatten mit einem geeigneten Tool so gelscht
werden, dass keine Wiederherstellung der Dateien mehr mglich ist. Die kann
beispielsweise dadurch geschehen, dass der Rechner von einem
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
externen Boot-Medium gestartet wird und die Festplatten mit Zufallsdaten

berschrieben werden. Dabei ist es empfehlenswert, den berschreibvorgang
mehrfach zu wiederholen.
Bei Appliances hngt die Vorgehensweise davon ab, ob in dem Gert eine
Festplatte eingebaut ist oder ob die Daten in einem nichtflchtigen Speicher
gespeichert werden. Oft bieten die Gerte eine "Factory-Reset" Option, mit
der smtliche Konfigurationseinstellungen auf die Werte des Auslieferungs-
zustands zurckgesetzt werden knnen. Auch nach dem Ausfhren eines
"Factory-Reset" sollte berprft werden, ob die Daten wirklich gelscht be-
ziehungsweise zurckgesetzt wurden oder ob bestimmte Daten oder Dateien
noch vorhanden sind.
Sind auf dem Gert besonders sicherheitskritische Informationen gespeichert Notfalls Speicher un-
brauchbar machen
und kann nicht mit hinreichender Sicherheit gewhrleistet werden, dass die
Daten wirklich gelscht sind, so kann es erforderlich sein, die Speicherbau-
steine oder Festplatten physisch zu zerstren bzw. unbrauchbar zu machen.
Neben den Informationen, die auf dem Gert selbst gespeichert sind sollte Auch Backup-Medien
bercksichtigen
auch berprft werden, ob auf den Backup-Medien sensitive Informationen
enthalten sind. Falls es nicht aus anderen Grnden (beispielsweise Archivie-
rung, Aufbewahrungspflicht aufgrund gesetzlicher Regelungen) erforderlich
ist, die Backup-Medien aufzubewahren, so sollten die Medien nach der Au-
erbetriebnahme des Gertes ebenfalls gelscht werden.
Oft sind die Komponenten des Sicherheitsgateways von auen mit IP-Adres- Auch Beschriftungen
entfernen
sen, Hostnamen oder sonstigen technischen Informationen beschriftet. Auch
diese Beschriftungen sollten vor der Entsorgung entfernt werden.
- Ist die sichere Entsorgung von Gerten in der Sicherheitsrichtlinie fr das
Sicherheitsgateway bercksichtigt?
- Werden Konfigurationsdateien und Log-Dateien vor der Entsorgung sicher
gelscht bzw. unlesbar gemacht?
- Wird die Beschriftung von den Gerten vor der Entsorgung entfernt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.301 Outsourcing des Sicherheitsgateway

Der Aufbau und Betrieb eines Sicherheitsgateway bedeutet einen nicht
unerheblichen finanziellen und personellen Aufwand. Trotzdem kann auf ein
Sicherheitsgateway nicht verzichtet werden, wenn LANs an nicht
vertrauenswrdige Netze (insbesondere an das Internet) angeschlossen werden
sollen. Oft wird daher berlegt, den Betrieb einer Sicherheitsgateway einem
externen Dienstleister zu berlassen. Dabei sind verschiedene Varianten
denkbar:
- Betrieb vor Ort, Administration durch Externe
Das Sicherheitsgateway wird innerhalb der Rumlichkeiten des
Auftraggebers betrieben und administriert. Damit wird ein externer
Sicherheitsgateway-Administrator beauftragt.
Diese Lsung bringt oft nicht einmal einen Kostenvorteil. Nachteilig ist
hier, wie bei allen anderen Lsungen, dass Externe sicherheitsrelevante
Aufgaben bernehmen und intern kein entsprechendes Wissen aufgebaut
wird, so dass eine wirksame Kontrolle uerst schwierig ist.
- Remote Management
Das Sicherheitsgateway wird innerhalb der Rumlichkeiten des
Auftraggebers aufgestellt und betrieben, aber ber Fernzugriff
administriert.
Dabei ist eine starke Authentisierung sowie die Verschlsselung der
Verbindung unerlsslich. Die Dienstleister sollten nur auf die
Sicherheitsgateway selber zugreifen drfen, nicht auf weitere Daten und
Verzeichnisse im LAN. Wie im Kapitel 7.6 Remote Access beschrieben,
sollten weitere organisatorische Vorkehrungen getroffen werden, um einen
mglichen Missbrauch einzudmmen. Dazu gehren beispielsweise
- das Verhngen einer Zeitsperre bei fehlerhaften Zugangsversuchen,
- das Sperren des Fernwartungszugangs im Normalbetrieb und
explizite Freigabe fr eine genau definierte Zeitspanne,
- Einschrnkung der Rechte der externen Administratoren, so dass
z. B. die Sicherheitsrichtlinien nicht niedriger eingestellt werden
knnen,
- "Zwangslogout" bei Leitungsunterbrechung; wird die Verbindung
zwischen Fernwartungsstelle und PC-Gateway auf irgendeine Weise
unterbrochen, so muss der Zugriff auf das System durch ein
"Zwangslogout" beendet werden.
- Hosting
Bei dieser Lsung wird die Sicherheitsgateway beim Dienstleister
aufgestellt und gepflegt. Vom internen LAN zum Sicherheitsgateway muss
dabei eine feste, geschtzte Verbindung vorhanden sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hierbei muss eine hohe Verfgbarkeit sowohl der Verbindung als auch des
Sicherheitsgateway-Systems gewhrleistet werden, da bei deren Ausfall
keine externen Verbindungen mehr mglich sind.
Im Allgemeinen sollen auch weitere Komponenten, die der
Kommunikation zwischen geschtztem und externem Netz dienen,
eingesetzt werden. Dazu gehren z. B. Informationsserver fr die
Bereitstellung von Informationen an interne oder externe Benutzer,
Mailserver und DNS-Server. Diese werden blicherweise in einer DMZ
des Sicherheitsgateway aufgestellt (siehe auch M 2.77 Integration von
Servern in das Sicherheitsgateway). In diesem Fall mssten sie also beim
externen Dienstleister betrieben werden. Dies kann die Kosten erheblich in
die Hhe treiben.
Sowohl beim Remote Management als auch beim Hosting eines
Sicherheitsgateways sollte eine Ausweich-Verbindung zum Dienstleister
vorhanden sein, um bei einem Ausfall der Hauptanbindung die Administration
bzw. die Internet-Anbindung zu gewhrleisten. Fr die Ausweich-Verbindung
muss sichergestellt sein, dass fr diese Verbindung mindestens das selbe
Sicherheitsniveau gewhrleistet ist, wie fr die Hauptverbindung.
Bei den verschiedenen Dienstleistungsangeboten ist zu hinterfragen,
- wie viel technisches, aber auch wie viel sicherheitsrelevantes Wissen beim
Anbieter vorhanden ist und wie dieses aktuell gehalten wird,
- ob und wie lange das Sicherheitsgateway-System unbeaufsichtigt betrieben
wird,
- wie der Personaleinsatz gesteuert wird, da ja blicherweise mehrere
Kunden betreut werden.
Auch wenn die Betreuung des Sicherheitsgateways einem Dienstleister
berlassen wird, muss trotzdem intern eine Sicherheitsgateway-
Sicherheitspolicy erstellt werden, die mit den Sicherheitszielen der
Organisation abgestimmt ist (siehe auch M 2.71 Festlegung einer Policy fr
ein Sicherheitsgateway). Beim Outsourcing eines Sicherheitsgateways sollte
in den Service-Level Agreements insbesondere schriftlich fixiert werden,
- welche Reaktionszeiten bei Ausfllen oder Angriffen gewhrleistet werden
mssen,
- welche Verfgbarkeit zu gewhrleisten ist (Performance, maximale
Ausfallrate),
- was protokolliert werden darf bzw. muss,
- welche Sicherheitsmanahmen gewhrleistet werden mssen. Dazu
gehren insbesondere alle in Kapitel 7.3 Sicherheitsgateway (Firewall)
aufgefhrten Manahmen.
Fr das Outsourcing einer so sicherheitskritischen Komponente wie dem Kapitel 3.10 Outsourcing
betrachten!
Sicherheitsgateway muss in jedem Fall der Baustein 3.10 Outsourcing
angewandt werden. Beim Dienstleister sollte idealerweise ebenfalls ein
vollstndiges Sicherheitsmanagement-System nach dem IT-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Grundschutzhandbuch existieren. Es wird empfohlen, beim Outsourcing des

Sicherheitsgateways zumindest zu prfen, ob das Sicherheitsmanagement des
Dienstleisters den Anforderungen des Kapitels 3.0 IT-Sicherheitsmanagement
gengt.
- Wurde die Entscheidung ber das Sicherheitsgateway-Outsourcing mit
dem IT-Sicherheitsmanagement abgestimmt?
- Wurde der Baustein 3.10 Outsourcing angewandt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.302 Sicherheitsgateways und Hochverfgbarkeit

Ein Sicherheitsgateway sollte immer die einzige Schnittstelle zwischen dem
externen und dem zu schtzenden Netz darstellen. Damit stellt natrlich das
Sicherheitsgateway einerseits einen potentiellen Flaschenhals und zum
anderen eine mgliche Bruchstelle fr den gesamten Netzverkehr einer
Organisation dar. Somit werden an die Verfgbarkeit von Sicherheitsgateways
hufig hohe Anforderungen gestellt.
Die wichtigsten Komponenten eines Sicherheitsgateways sollten somit
redundant ausgelegt werden. Dies sind vor allem diejenigen Komponenten,
die zum Abruf oder zum Versand von Informationen unbedingt berquert
werden mssen. In diese Kategorie fallen in der Regel Paketfilter,
Application-Level-Gateway und evtl. VPN-Komponenten. Bei anderen
Komponenten (z. B. Virenscanner oder Intrusion-Detection-System) muss die
Bedeutung fr die Sicherheit des zu schtzenden Netzes im Einzelfall
betrachtet werden.
Es gibt verschiedene Mglichkeiten, die Verfgbarkeit von Komponenten
eines Sicherheitsgateways zu steigern:
Cold-Standby:
Beim Cold-Standby wird neben dem eigentlichen Produktivsystem ein zweites
baugleiches Ersatzsystem bereitgehalten, das aber nicht in Betrieb ist. Wenn
das erste System ausfllt, kann das Ersatzsystem manuell hochgefahren und
ins das Sicherheitsgateway integriert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorteile einer Cold-Standby Lsung Nachteile einer Cold-Standby

Lsung
- Der Aufwand zur Neuinstallation - Zum bestehenden System muss ein
bzw. zum Neuaufbau eines zweites System vorgehalten
Sicherheitsgateways ist relativ werden und stndig auf dem
gering. aktuellen Konfigurations- und
Patch-Stand gehalten werden.
- Die geringe Komplexitt des
Sicherheitsgateways erschwert - Das Cold-Standby-System kann
Fehlkonfigurationen. Fehlfunktionen nicht selbstndig
erkennen und muss manuell
aktiviert werden. Es liegt in der
Verantwortung der
Administratoren, die Funktion des
Wirksystems permanent zu
berwachen und im Notfall
einzuschreiten.
- Je nach eingesetztem Produkt
erfordert das Hochfahren einer
Komponente des
Sicherheitsgateways die
Anwesenheit eines Administrators,
da manche Systeme ohne
Benutzerinteraktion ber Tastatur
nicht in den Betriebszustand
starten. Das Einschalten von
Komponenten ber eine
webgesteuerte Steckdose ist in
diesem Fall ausgeschlossen.
Tabelle 1: Vor- und Nachteile einer Cold-Standby Lsung
Hot-Standby:
Bei einem Hot-Standby steht ebenfalls ein Ersatzsystem (meist mit der
gleichen Konfiguration wie das im Regelbetrieb befindliche System) bereit.
Dieses luft aber stndig parallel mit, wobei eine Komponenten die andere
berwacht. Bei einer Fehlfunktion kann dann das Ersatzsystem unmittelbar die
Funktion des Wirksystems bernehmen. Dies kann automatisiert erfolgen oder
auch nach Benutzerinteraktion. Eine Benutzerinteraktion kann verhindern,
dass eine Umschaltung auf das Hot-Standby-System - die zustzliche
Komplikationen mit sich bringen kann - bei extrem kurzen Ausfllen erfolgt.
Um die Ausfallzeiten mglichst gering zu halten, muss der Zustand der
wichtigsten Komponenten beim Hot-Standby-Betrieb des Sicherheitsgateways
in mglichst kurzen Zeitabstnden berprft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorteile einer Hot-Standby Lsung Nachteile einer Hot-Standby

Lsung
- Es ist keine Interaktion durch den - Gegenber Cold-Standby wird das
Administrator an der Konsole Sicherheitsgateway sehr komplex,
notwendig. da alle beteiligten Komponenten
durch zustzliche
- Da die Funktionen des
berwachungskomponenten
ausgefallenen Systems von der
stndig auf korrekte Funktion
Ersatzkomponenten automatisch
berprft werden mssen.
bernommen wird, gibt es keine
oder nur kurze Ausfallzeiten. - Fr jede relevante Komponente des
Sicherheitsgateways muss eine
eigene berwachungskomponente
beschafft und betreut werden.
Tabelle 2: Vor- und Nachteile einer Hot-Standby Lsung
Parallelbetrieb:
Bei einem Parallelbetrieb arbeiten zwei oder mehr Sicherheitsgateways
stndig nebeneinander im Wirkbetrieb. Durch einen Parallelbetrieb wird nicht
nur eine Lastverringerung und Performancesteigerung erreicht, vielmehr
verringern sich auch die Probleme bei Ausfllen. Je nach gewhlter
Lastverteilungsmethode kann ein System im Fehlerfall die Aufgaben des
gerade nicht zur Verfgung stehenden Systems bernehmen. Daraus resultiert
natrlich ein kurzfristiger Performance-Verlust, aber die Funktionalitt bleibt
vollstndig erhalten.
Dabei muss allerdings sichergestellt sein, dass alle Systeme konsistent
gehalten werden. Bei Sicherheitsgateways muss hier vor allem auf korrekte
Zeitsynchronisierung und die Konsistenz der Regelbasis geachtet werden.
Auerdem muss gewhrleistet sein, dass ein- und ausgehende Anfragen immer
von den selben Komponenten bearbeitet werden, da sonst evtl. Verbindungen
abgebrochen werden. Dies betrifft besonders Application-Level-Gateways und
Paketfilter mit Stateful-Inspection-Funktion.
Beim Parallelbetrieb sind zwei Varianten zu unterschieden:
Statischer Parallelbetrieb
Bei dieser Variante ndert sich die Konfiguration (insbesondere die Routing-
Informationen) der Komponenten des Sicherheitsgateways nicht. Eine
Variante des statischen Parallelbetriebs knnte beispielsweise darin bestehen,
dass ber die parallelen Komponenten des Sicherheitsgateways
unterschiedliche Dienste geleitet werden, also z. B. HTTP ber einen
Kommunikationsstrang und SMTP ber einen parallelen
Kommunikationsstrang. Diese Konfiguration erhht zwar die Performance des
Gesamtsystems, ist aber beim Ausfall einzelner Komponenten problematisch,
da die Komponenten unterschiedlich konfiguriert sind und nicht ohne
Weiteres durch die jeweils parallele Komponente ersetzt werden knnen. Aus
diesem Grund ist von einer solchen Struktur und Konfiguration des
Sicherheitsgateways in der Regel abzuraten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Dynamischer Parallelbetrieb/Loadbalancing
Bei dieser Betriebsart wird die Konfiguration der Komponenten des
Sicherheitsgateways den Performanceanforderungen im Betrieb angepasst. Ein
Beispiel hierfr ist das Loadbalancing, bei dem Datenstrme in Abhngigkeit
von der Auslastung der an der Kommunikation beteiligten Komponenten
geroutet werden.
Unbedingt zu beachten ist beim Loadbalancing, dass sich durch die
automatischen Konfigurationsnderungen auf den beteiligten Komponenten
keine nderungen des Sicherheits-Regelwerks fr das gesamte
Sicherheitsgateway ergeben.
Loadbalancing kann Teil einer High-Availibility-Lsung (HA-Lsung) sein.
Bei einer HA-Lsung wird die Verfgbarkeit von Komponenten des
Sicherheitsgateways berwacht und es werden beim Ausfall ggf.
Ersatzsysteme genutzt, die den Ausfall kompensieren sollen. Das oben
angesprochene Loadbalancing dient in diesem Zusammenhang eigentlich nur
der Performancesteigerung und fhrt alleine noch nicht zu Hochverfgbarkeit,
es muss zustzlich dafr gesorgt werden, dass bei einem Systemausfall die
Ersatzsysteme den Ausfall automatisch ohne Zutun des Administrators
auffangen. Eine stndige berwachung der HA-Komponenten ist dabei
ebenso wichtig wie ein automatisches Fail-Over im Bedarfsfall.
Vor- und Nachteile einer HA-Lsung sind mit denen eines Hot-Standby-
Systems zu vergleichen. Vorteilhaft gegenber Hot-Standby ist zustzlich
jedoch, dass smtliche Komponenten des Sicherheitsgateways genutzt werden
und sich somit eine Lastverteilung ergibt, die die Verfgbarkeit des
Sicherheitsgateways sicherstellen kann.
Anforderungen an HA-Lsungen:
An eine HA-Lsung sollten folgende Forderungen gestellt werden:
- Auch nach einem automatischen Fail-Over muss das Sicherheitsgateway Keine
Sicherheitseinbuen bei
die Sicherheitsanforderungen der Sicherheitsleit- bzw. -richtlinie erfllen Fail-Over!
("Fail safe" bzw. "Fail secure").
- Die HA-Realisierung darf den Betrieb des Sicherheitsgateways bzw.
dessen Sicherheitsfunktionen nicht behindern.
- Mindestens Paketfilter und Application-Level-Gateway sollten
hochverfgbar ausgelegt werden, da eine Kommunikation bei einem
Ausfall der Komponenten in der Regel nicht mehr mglich ist. hnliches
gilt fr VPN-Komponenten.
- Es sollten zwei voneinander unabhngige Zugangsmglichkeiten zum
externen Netz bestehen, z. B. zwei Internetzugnge von unterschiedlichen
Providern.
- Interne und externe Router mssen redundant ausgelegt sein, z. B. unter
Verwendung von Protokollen wie "Virtual Router Redundancy Protocol"
(VRRP) oder das proprietre "Hot Standby Routing Protocol" (HSRP).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Funktionsberwachung sollte anhand einer Vielzahl von Parametern

erfolgen und sich nicht auf ein einzelnes Kriterium verlassen (wie z. B.
eine einfache Erreichbarkeitsprfung durch Testen der Verfgbarkeit der
Netzschnittstelle ("ping")). Ist eine Komponente mittels "ping" erreichbar,
knnte beispielsweise berprft werden, ob die konfigurierten Dienste in
der intendierten Art und Weise arbeiten.
- Fehlkonfigurationen bei Inbetriebnahme oder Fehlfunktionen einer
Komponente im Wirkbetrieb werden bei HA-Lsungen evtl. nicht sofort
sichtbar, da Funktionen teilweise von der parallel installierten Komponente
bernommen werden. So z. B. fllt es unter Umstnden nicht sofort auf,
wenn auf einem ALG die Filterung auf aktive Inhalte ausgeschaltet ist und
die Anfragen vom korrekt konfigurierten System bearbeitet werden.
Deshalb ist eine regelmige Kontrolle der Protokolldateien und der
Warnmeldungen der HA-Lsung wichtig.
Besonders einfach ist eine HA-Lsung dann, wenn nur ein einstufiger Aufbau HA bei Paketfiltern ist
meist einfach
bestehend aus einem Paketfilter hochverfgbar ausgelegt werden soll. Viele
kommerzielle Produkte bieten hierfr eine einfache Lsung, die im
Wesentlichen in der Aktivierung einer entsprechenden HA-Option in der
Administrationsoberflche besteht.
Aufwndiger ist eine HA-Lsung bei mehrstufigen Sicherheitsgateways (z. B.
zusammengesetzt aus Paketfiltern und Application-Level-Gateway). Hier
muss jede Komponente hochverfgbar ausgelegt sein, was einen erheblichen
Mehraufwand bedeutet. In der Regel mssen hier neben der
berwachungsfunktion noch dynamische Routingprotokolle (z. B. "Open
Shortest Path First", OSPF) verwendet werden, die den Netzverkehr je nach
Bedarf in die richtige Richtung lenken.
Dynamische Routing-Protokolle sind jedoch aus Sicht der Sicherheit nicht
unproblematisch. Zu den Problemen siehe auch G 5.51 Missbrauch der
Routing-Protokolle und M 5.112 Sicherheitsaspekte von Routing-Protokollen.
Sollen zur Realisierung einer HA-Lsung dynamische Routing-Protokolle
eingesetzt werden, so sollte im Rahmen einer ergnzenden Sicherheitsanalyse
geprft werden, ob das erforderliche Sicherheitsniveau noch erreicht wird.
In der P-A-P-Kette eines mehrstufigen Sicherheitsgateways muss eine
Komponente die berwachungsfunktion bernehmen. Diese Komponente
entscheidet, ob der P-A-P-Strang funktionsfhig ist oder nicht. Fr diese
Aufgabe bietet sich eine eigenstndige berwachungskomponente an, die fr
nichts anderes als die Funktionskontrolle zustndig ist.
Ist die Integration einer eigenstndigen berwachungskomponente nicht
mglich, so bietet es sich an, dem Application-Level-Gateway diese Aufgabe
zu bertragen. Dies bietet zum einen den Vorteil, dass viele Funktionen des
Sicherheitsgateways auf dem ALG implementiert sind, also von der
berwachungssoftware dann lokal ausgewertet werden knnen. Zum anderen
ist das ALG oftmals an zentraler Stelle in das Sicherheitsgateway integriert,
bietet also einen direkten Zugang zu den anderen Komponenten des
Sicherheitsgateways.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Problematisch ist allerdings, dass ALGs oftmals das Aufspielen von

Fremdsoftware zu verhindern versuchen, um eine Kompromittierung des
Systems zu verhindern. Tatschlich ist natrlich nicht auszuschlieen, dass die
eingesetzte berwachungssoftware fehlerbehaftet ist und die Sicherheit des
ALGs stark herabsetzt.
Ergnzende Sicherheitsanalyse
Hochverfgbarkeitslsungen sind immer auf spezielle Anforderungen
zugeschnitten und Mischformen aus den oben beschriebenen Typen sind
durchaus denkbar. Grundstzlich wird fr denn Fall, dass die Anforderungen
an die Verfgbarkeit des Sicherheitsgateways eine Hochverfgbarkeitslsung
notwendig erscheinen lassen, eine ergnzende Sicherheitsanalyse dringend
empfohlen.
- Wird eine HA-Lsung eingesetzt? Falls ja, welche Art?
- Wie wird sichergestellt, dass bei einem automatischen Fail-Over das
Sicherheitsniveau nicht sinkt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.303 Festlegung einer Strategie fr den Einsatz von

PDAs
heitsmanagement
Bevor in einer Organisation PDAs eingesetzt werden, muss festgelegt sein,
welche generelle Strategie die Organisation im Hinblick auf die Nutzung der
Gerte einnimmt. Insbesondere sind dafr die folgenden Fragen zu beantwor-
ten:
- Fr welche Anwendungen sollen die PDAs eingesetzt werden?
- Werden den Mitarbeitern dienstliche PDAs zur Verfgung gestellt?
- Wird die Nutzung privater PDAs der Mitarbeiter erlaubt oder sogar offi-
ziell untersttzt?
Insbesondere die Frage, fr welche Zwecke PDAs eingesetzt werden sollen,
ist fr die spteren Entscheidungen wichtig, denn sie kann einen entschei-
denden Einfluss auf die Auswahl anzuschaffender Gerte haben und muss in
jedem Fall bei der Formulierung der Sicherheitsrichtlinien und Regelungen fr
die PDA-Nutzung bercksichtigt werden.
Klassifikation der Daten
Jeder Benutzer und jede Institution sollte sich Gedanken darber machen,
welche Daten auf einem PDA gespeichert werden drfen und welchen
Schutzbedarf diese haben. In einem Unternehmen oder einer Behrde sollte
dies nicht nur fr Daten auf PDAs, sondern generell geklrt werden. So gibt es
in Anwendungsfeldern und Geschftsprozessen Daten, die einen hheren
Schutzbedarf haben oder die besonderen Restriktionen unterliegen, z. B.
personenbezogene, finanzrelevante, vertrauliche oder Copyright-geschtzte
Daten.
Daher sollten in einer Institution alle Arten von Daten danach kategorisiert
sein, wie schutzbedrftig sie sind und welche Beschrnkungen im Umgang
mit ihnen beachtet werden sollten (siehe hierzu auch M 2.217 Sorgfltige Ein-
stufung und Umgang mit Informationen, Anwendungen und Systemen).
Damit die Mitarbeiter mit diesen Einstufungen auch sinnvoll umgehen
knnen, empfiehlt es sich, diesen hierzu leicht verstndliche Tabellen und
Beispiele an die Hand zu geben, in denen erlutert ist, welche Arten von Daten
auf den verschiedenen IT-Systemen oder Anwendungen gespeichert oder ver-
arbeitet werden drfen und auch, an wen diese weitergegeben werden drfen.
Nutzung von privaten PDAs
Aufgrund einer unzureichenden Ausstattung oder eines hohen Benutzer-
druckes kann es vorkommen, dass private PDAs fr dienstliche Zwecke
benutzt werden. Das IT-Sicherheitsmanagement bzw. die IT-Verantwortlichen
sollten aber auf jeden Fall sicherstellen, dass auch die private Nutzung
innerhalb der Institution nicht "wild" erfolgt, sondern klar geregelt ist. Sollen
PDAs nur fr Anwendungen wie Termin- und Adressverwaltung oder fr
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
E-Mail-Kommunikation eingesetzt werden, so kann die Nutzung privater

PDAs normalerweise erlaubt werden, wenn keine sonstigen Grnde dagegen
sprechen.
Falls die PDAs fr eine Anwendung eingesetzt werden sollen, aus der sich fr Bei hohem Schutzbedarf
mglichst kein privaten
die Gerte ein hoher Schutzbedarf ergibt, so ist es sehr fraglich, ob dafr die PDAs
Nutzung privater PDAs zugelassen werden sollte. Der Grund dafr ist insbe-
sondere, dass private Gerte weitgehend dem Einfluss der zentralen Konfigu-
ration und Administration entzogen sind und es deswegen praktisch keine
Mglichkeit gibt, fr die Gerte ein akzeptables Sicherheitsniveau zu
gewhrleisten. Es wird dringend empfohlen, in diesem Fall keine Nutzung
privater PDAs zuzulassen.
Bei der Entscheidung sollte auch bercksichtigt werden, dass die Entschei-
dung, private PDAs zuzulassen, auch Auswirkungen auf die sptere IT-Strate-
gie einer Organisation haben kann.
Beispiel:
In einem Unternehmen wurden zwar keine PDAs fr die Mitarbeiter ange-
schafft, die Mitarbeiter wurden aber dennoch bei der Beschaffung privater
Gerte und der Anbindung an die Arbeitsplatz-PCs beraten. Als das Unter-
nehmen die PCs von Windows NT nach Windows 2000 migrierte, stellte sich
heraus, dass es unter Windows 2000 keine passenden Treiber fr die vorhan-
denen PDAs existierten. Durch die massiven Benutzerbeschwerden stand das
Unternehmen vor der Wahl, den Benutzern neue PDAs zu finanzieren oder
diesen weiter NT-basierte PCs zur Verfgung zu stellen.
Wenn ein Verbot ausgesprochen wird, private PDAs fr Dienstzwecke zu
benutzen oder sie in das Bro mitzubringen, sollte immer bedacht werden,
dass solche Verbote berwacht werden mssen und dass sie auch ineffektiv
sein knnen.
Die Entscheidung sollte zusammen mit den Entscheidungsgrnden dokumen-
tiert und den Mitarbeitern auf geeignete Art und Weise kommuniziert werden.
- Werden dienstliche PDAs angeschafft?
- Ist die Nutzung privater PDAs erlaubt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

PDA-Nutzung
Wenn in einer Institution entschieden wurde, PDAs einzusetzen, so mssen
diese in die allgemeine Sicherheitsstrategie eingebunden werden.
Bei der Nutzung von PDAs gibt es eine Vielzahl von Mglichkeiten, diese vor
Missbrauch zu schtzen. Damit diese Mglichkeiten auch genutzt werden,
sollte eine Sicherheitsrichtlinie erstellt werden, in der alle umzusetzenden
Sicherheitsmechanismen beschrieben werden. Jede Institution sollte sich die
Mglichkeiten und Risiken des PDA-Einsatzes bewusst machen. Hierbei
sollten zwei Sicherheitsaspekte im Vordergrund stehen:
- die Sicherheit der auf PDAs gespeicherten Daten und
- die Auswirkung der PDA-Nutzung auf die Sicherheit anderer IT-Systeme
innerhalb einer Institution.
Aufbauend auf die PDA-Sicherheitsrichtlinie sollte fr die Benutzer ein
kurzes und bersichtliches Merkblatt fr die sichere Nutzung von PDAs
erstellt werden.
Schutz vor Missbrauch
Ein PDA hat nicht nur fr den Besitzer den Vorteil, leicht zu transportieren
und unauffllig zu verwahren zu sein, sondern auch fr einen Dieb. Daher
sollte auch ein PDA stets sicher aufbewahrt werden. Bei Dienstreisen sollten
sie nicht unbeaufsichtigt gelassen werden. Insbesondere sollten sie nicht in
Fahrzeugen zurckgelassen werden.
Praktisch alle Varianten von PDAs und Organizern lassen sich durch PINs
oder Passwrter gegen unbefugten Zugriff absichern. Leider sind nicht alle
vom Hersteller angebotenen Sicherheitsmechanismen so sicher, wie es
wnschenswert wre. Daher sollten sich PDA-Benutzer informieren, wie
zuverlssig die vorhandenen Sicherheitsmechanismen sind, z. B. ber das
Internet.
Solange keine besseren Sicherheitstools installiert sind, sollten aber auf jeden
Fall die vorhandenen Sicherheitsmechanismen genutzt werden (siehe auch
M 4.228 Nutzung der Sicherheitsmechanismen von PDAs). Alle Benutzer
sollten sich aber ber deren Wirkung und insbesondere deren Grenzen im
Klaren sein. Dabei sollten die Passwrter und PINs sorgfltig ausgewhlt
werden, also auch lang genug sein, damit sie nicht einfach berwunden
werden knnen. Die Passwrter drfen keinesfalls zusammen mit dem PDA
aufbewahrt werden.
Sensibilisierung der Benutzer
Alle PDA-Benutzer sollten nicht nur ber die Vorteile von PDAs aufgeklrt
werden, sondern auch ber potentielle Risiken und Probleme bei der Nutzung
sowie ber den Nutzen, aber auch die Grenzen der eingesetzten Sicherheits-
manahmen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Da auch fr die Betriebssysteme von PDAs (beispielsweise Palm OS,

Windows CE bzw. Windows Mobile, Symbian OS) immer wieder neue
Sicherheitslcken offengelegt werden, sollte sich das IT-Sicherheits-
management regelmig ber aktuelle Risiken informieren. Gegebenenfalls ist
es angebracht, die Mitarbeiter regelmig ber die neu bekanntgewordenen
Gefahren zu informieren und damit auch zu sensibilisieren.
Regelungen zur PDA-Nutzung
Allgemeine Regelungen
Auf einem PDA sind Daten in der Regel schlechter geschtzt als auf IT-Sys-
temen innerhalb der Organisation. Unabhngig davon, ob privat oder dienst-
lich angeschaffte PDAs genutzt werden, sollte der Arbeitgeber daher schrift-
lich regeln,
- welche Daten nicht auf einem PDA gespeichert werden drfen,
- dass Daten nicht berall eingegeben bzw. abgerufen werden sollten, da sie
dabei unter Umstnden mitgelesen werden knnen,
- wie, wann und durch wen Datensicherungen des PDAs durchzufhren sind,
- unter welchen technischen Einsatzbedingungen die PDAs eingesetzt
werden drfen. Hierzu gehren vor allem die Festlegung von Sicherheits-
manahmen, die Auswahl und Installation der erforderlichen Sicherheits-
hard- und -software sowie Vorgaben fr die sichere Konfiguration der
betroffenen IT-Systeme.
Ein PDA sollte mglichst nicht unbeaufsichtigt bleiben. Falls ein PDA in
einem Kraftfahrzeug zurckgelassen werden muss, so sollte das Gert von
auen nicht sichtbar sein. Das Abdecken des Gertes oder das Einschlieen in
den Kofferraum bieten Abhilfe. Ein PDA stellt einen Wert dar, der potentielle
Diebe anlocken knnte.
Wird ein PDA in fremden Brorumen benutzt, so sind die Sicherheitsrege-
lungen der besuchten Organisation zu beachten.
In fremden Rumlichkeiten wie Hotelzimmern sollte ein PDA nicht unge-
schtzt liegen gelassen werden. Alle Passwort-Schutzmechanismen sollten
sptestens jetzt aktiviert werden. Das Verschlieen des Gertes in einem
Schrank behindert Gelegenheitsdiebe.
Nutzung von privaten PDAs
Bei der Nutzung von privaten PDAs in einer Behrde oder einem Unter-
nehmen sind unter anderem die folgenden Punkte zu regeln:
- Die sinnvolle Nutzung von PDAs erfordert im Allgemeinen eine
Synchronisation mit einem PC, beispielsweise fr Terminkalender,
Adressbcher, E-Mail-Untersttzung und mehr. Daher muss geklrt
werden, ob die Installation der dafr bentigten Hard- und Software erlaubt
wird, und wer die Installation vornimmt. Dies sollte nicht den Benutzern
selbst berlassen werden.
- Es muss geklrt werden, inwieweit der Benutzer-Support bei Problemen,
die sich aus der Nutzung von privaten PDAs ergeben, Hilfestellung leistet.
Ebenso sollte im Vorfeld abgesprochen werden, wie private PDAs in die
IT-Strategie der Institution eingebunden werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Nutzung von dienstlichen PDAs

Bei der Nutzung von dienstlichen PDAs sind unter anderem die folgenden
Punkte zu regeln:
- Es muss geklrt werden, ob dienstliche PDAs auch mit privaten PCs
synchronisiert werden drfen. Dies erleichtert einerseits Terminab-
stimmungen, andererseits knnte dadurch Schadsoftware in die dienst-
lichen Systeme eingeschleppt werden und interne Dokumente knnten auf
die privaten PCs gelangen.
- Die Benutzer sollten darauf hingewiesen werden, wie sie sorgfltig mit den
PDAs umgehen sollten, um einem Verlust oder Diebstahl vorzubeugen
bzw. um eine lange Lebensdauer zu gewhrleisten (z. B. Akkupflege, Auf-
bewahrung auerhalb von Bro- oder Wohnrumen, Empfindlichkeit
gegenber zu hohen oder zu niedrigen Temperaturen).
- Die Verwaltung, Wartung und Weitergabe von PDAs sollte geregelt
werden.
Einbindung in andere Sicherheitslsungen
Bei der Benutzung von PDAs muss nicht nur berlegt werden, ob der Einsatz
von Sicherheitssoftware zum Schutz des PDAs selber sinnvoll ist, sondern
auch, wie der PDA mit der Sicherheitssoftware der Einsatzumgebung zusam-
menarbeitet. Dazu zwei Beispiele:
- Der Benutzer liest und schreibt auf seinem Desktop-PC hufig E-Mail, die
verschlsselt bzw. signiert ist. Auerdem mchte er seinen PDA nutzen,
um unterwegs E-Mail zu bearbeiten. Mit verschlsselten bzw. signierten
Mails kann er aber aus verschiedenen Grnden Probleme bei der Weiter-
verwendung auf dem PDA bekommen. So gibt es beispielsweise bisher nur
sehr wenige Verschlsselungs- bzw. Signaturanwendungen, die sowohl mit
den einschlgigen Mailprogrammen auf Office-Systemen als auch auf
PDAs kompatibel sind. Bei solchen Anwendungen werden auerdem oft
Chipkarten oder andere Sicherheitstoken als sicherer Speicherplatz fr die
bentigten kryptographischen Schlssel eingesetzt. Nur die wenigsten
PDAs lassen sich aber um Chipkarten-Leseeinrichtungen erweitern. Viele
PKI-Anwendungen arbeiten auerdem serverbasiert, bentigen also Zugriff
auf einen Server, um beispielsweise Zertifikate berprfen oder ffentliche
Schlssel von Kommunikationspartner abrufen zu knnen.
- Im Unternehmen werden alle Daten, sowohl auf den Clients als auch den
Servern, ausschlielich verschlsselt gespeichert. Wenn Benutzer nun
interne Daten auf PDAs transferieren wollen, kann zum einem passieren,
dass der Benutzer unterwegs feststellen, dass er zugriffsgeschtzte Dateien
geladen hat, die er auf dem PDA nicht lesen kann. Dies ist der fr die Ver-
traulichkeit der Daten bessere Fall. Typischerweise werden die auf den
PDA bertragenen Daten dort nmlich nicht oder nur schwach verschls-
selt, so dass sie weniger stark geschtzt sind als auf den internen Systemen.
Auch solche Flle, also die Einbindung von PDA-Applikationen in andere
Sicherheitssoftware im Unternehmen, muss daher unbedingt in der PDA-
Sicherheitsrichtlinie geregelt werden, um zu vermeiden, dass durch die PDA-
Nutzung das festgelegte Sicherheitsniveau reduziert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wo ntig: Nutzungsverbot von PDAs

Es sollte berlegt werden, ob die Nutzung oder sogar das Mitbringen von
PDAs in allen oder bestimmten Bereichen einer Behrde oder eines Unter-
nehmens eingeschrnkt werden sollte. Dies kann z. B. dort sinnvoll sein, wo
das Mitschneiden von Gesprchen oder das Fotografieren unterbunden werden
soll.
Wenn die IT-Sicherheitsrichtlinie der Institution es nicht zulsst, dass fremde
IT-Systeme wie beispielsweise PDAs mitgebracht werden, muss an allen Ein-
gngen deutlich darauf hingewiesen werden. Dies sollte dann auch regelmig
kontrolliert werden. Fr die Besucher sollte in diesem Fall eine Mglichkeit
geschaffen werden, mitgebrachte Mobiltelefone, PDAs oder Notebooks sicher
aufzubewahren. Beispielsweise knnen an den Eingngen Schliefcher zur
Verfgung gestellt werden.
- Existiert eine aktuelle Sicherheitsrichtlinie fr die PDA-Nutzung?
- Wie wird die Einhaltung der Sicherheitsrichtlinie fr die PDA-Nutzung
berprft?
- Besitzt jeder PDA-Benutzer ein Exemplar dieser PDA-Richtlinie oder ein
Merkblatt mit einem berblick der wichtigsten Sicherheitsmechanismen?
- Ist die Sicherheitsrichtlinie fr die PDA-Nutzung Inhalt der Schulungen zu
IT-Sicherheitsmanahmen?
- Werden die Benutzer von PDAs auf die Regelungen hingewiesen, die von
ihnen einzuhalten sind?
- Werden die Benutzer von PDAs auf die geeignete Aufbewahrung
hingewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.305 Geeignete Auswahl von PDAs

Verantwortlich fr Umsetzung: Leiter IT, Beschaffungsstelle, Administrator
PDAs gibt es in verschiedensten Varianten und Gerteklassen. Diese unter-
scheiden sich nicht nur in ihren Abmessungen und Leistungsumfang, sondern
auch bei Sicherheitsmechanismen und Bedienkomfort. Zudem stellen sie
unterschiedliche Voraussetzungen an Hard- und Software-Komponenten im
Einsatzumfeld.
Bei der Vielzahl verschiedener PDA-Modelle mit den unterschiedlichsten
Betriebssystemen, sind Kompatibilittsprobleme bei Hardware, Software auf
PDA und PC sowie Schnittstellen naheliegend.
Wenn einmal beschlossen worden ist, innerhalb einer Institution PDAs einzu- Anforderungsliste zur
Produkt-Bewertung
setzen, sollte daher eine Anforderungsliste erstellt werden, anhand derer die
am Markt erhltlichen Produkte bewertet werden. Aufgrund der Bewertung
sollten dann die zu beschaffenden Produkte ausgewhlt werden. Die Praxis
zeigt, dass es aufgrund verschiedener Einsatzanforderungen durchaus sinnvoll
sein kann, mehrere Gertetypen fr die Beschaffung auszuwhlen. Die
Gertevielfalt sollte aber zur Vereinfachung des Supports eingeschrnkt
werden.
Auerdem muss sichergestellt werden, dass eine Mglichkeit zur zentralen
und effektiven Verwaltung der einzelnen Endgerte und der darauf verwen-
deten Software vorhanden ist. Auch sollte die notwendige Serverinfrastruktur
einen mglichst geringen administrativen Aufwand erfordern.
Manche Funktionen von PDAs sind nur in Verbindung mit externen
Dienstleistern nutzbar. ber einen externen Dienstleister sollten keine internen
Daten ausgetauscht werden, wenn die Vertraulichkeit und Integritt der Daten
nicht gewhrleistet ist. Eine bertragung ber ein Mobilfunknetz ist bei-
spielsweise zwar meist zunchst verschlsselt ("Luftschnittstelle"), die Daten
werden dann aber oft innerhalb des Netzes des Mobilfunkanbieters unver-
schlsselt bertragen und auf dem Server des Dienstbetreibers unverschlsselt
gespeichert. Im Zweifelsfall sollen solche Dienste daher nicht genutzt werden.
Zunchst sollte eine Anforderungsanalyse durchgefhrt werden. Ziel der
Anforderungsanalyse ist es einerseits, alle im konkreten Fall in Frage kom-
menden Einsatzszenarien zu bestimmen und andererseits daraus Anforde-
rungen an die bentigten Hard- und Softwarekomponenten abzuleiten.
Die folgende Liste gibt einen groben berblick ber mgliche allgemeine Be-
wertungskriterien, erhebt jedoch keinen Anspruch auf Vollstndigkeit und
kann um weitere allgemeine Anforderungen erweitert werden.
1 Allgemeine Kriterien
1.1 Wartbarkeit
- Ist das Produkt einfach wartbar?
- Bietet der Hersteller regelmige Software-Updates an?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
1.2 Zuverlssigkeit/Ausfallsicherheit
- Ist das Produkt im Dauerbetrieb einsetzbar?
- Gibt es einen im Produkt integrierte Backup-Mechanismus?
- Kann eine automatische Datensicherung durchgefhrt
werden?
1.3 Benutzerfreundlichkeit
- Knnen Benutzer die Systeme ohne grere Schulungsma-
nahmen effektiv, sicher und fehlerfrei nutzen?
- Ist die Synchronisations-Software so konfigurierbar, dass die
Benutzer mglichst wenig mit technischen Details belastet
werden? Ist die Sicherheit dabei trotzdem immer gewhrlei-
stet?
- Sind Abmessungen und Gewicht bezogen auf den Einsatz-
zweck angemessen? Ist die Akku-Laufzeit ausreichend fr die
tgliche Arbeit?
1.4 Kosten
- Wie hoch sind die Anschaffungskosten der Hard- und Soft-
ware?
- Wie hoch sind die voraussichtlichen laufenden Kosten der
Hard- und Software (Wartung, Betrieb, Support)?
- Wie hoch sind die voraussichtlichen laufenden Kosten fr das
Personal (Administrator/Support)?
- Mssen zustzliche Soft- oder Hardware-Komponenten ange-
schafft werden (z. B. Docking-Station, Konvertierungssoft-
ware)?
2. Funktion
2.1 Installation und Inbetriebnahme
- Lsst sich das Produkt einfach installieren, konfigurieren und
nutzen?
- Kann das Gert sowie die Synchronisations-Software so
konfiguriert werden, dass die vorgegebenen Sicherheitsziele
erreicht werden knnen?
- Knnen wichtige Konfigurationsparameter vor Vernderun-
gen durch nicht befugte Benutzer geschtzt werden?
- Arbeitet das Produkt mit gngiger Hard- und Software zusam-
men (Betriebssysteme, Treiber)?
2.2 Administration
- Enthlt die mitgelieferte Produktdokumentation eine genaue
Darstellung aller technischen und administrativen Details?
- Knnen die PDAs ber eine zentral gesteuerte Management- Ist einfache
Software administriert werden? Ist die administrative Schnitt- Administration mglich?
stelle so gestaltet, dass auf fehlerhafte, unsichere oder inkonsi-
stente Konfigurationen hingewiesen wird oder diese verhin-
dert werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2.3 Protokollierung
- Bietet das Produkt Protokollierung an?
- Ist der Detailgrad der Protokollierung konfigurierbar?
- Werden durch die Protokollierung alle relevanten Daten
erfasst?
2.4 Kommunikation und Datenbertragung
- Untersttzt der PDA alle bentigten Datenbertragungs-
techniken (z. B. Infrarot, Bluetooth oder GSM)?
2.5 Sicherheit: Kommunikation, Authentisierung und Zugriff
- Hat der PDA geeignete Mechanismen zur Identifikation und
Authentisierung der Benutzer?
- Knnen mit dem Produkt die Daten zu anderen Endgerten
gesichert bertragen werden? Gilt dies fr alle Schnittstellen,
also z. B. auch fr drahtlose Verbindungen?
- Knnen zustzliche Sicherungsmechanismen (z. B. Verschls-
selungs- oder Virensuchprogramme) genutzt werden?
- Erlaubt die Produktarchitektur die nachtrgliche Installation
neuer Sicherheitsmechanismen?
- Wird dem mobilen Benutzer nur nach erfolgreicher Authenti-
sierung der Zugang zu lokalen Endgerten erlaubt?
- Gibt es benutzerfreundliche Mglichkeiten zur Datensiche-
rung?
Sind alle Anforderungen an das zu beschaffende Produkt dokumentiert, so
mssen die am Markt erhltlichen Produkte dahin gehend untersucht werden,
inwieweit sie diese Anforderungen erfllen. Es ist zu erwarten, dass nicht
jedes Produkt alle Anforderungen gleichzeitig oder gleich gut erfllt. Daher
sollten die einzelnen Anforderungen mit Gewichten versehen werden, die
reflektieren, wie wichtig die Erfllung der jeweiligen Anforderung ist. Auf-
grund der durchgefhrten Produktbewertung (gem dem erstellten Anforde-
rungskatalog) kann dann eine fundierte Kaufentscheidung getroffen werden.
Trotz einer Produktauswahl durch das IT-Management sollte immer damit Eigenwillige Mitarbeiter
gerechnet werden, dass Mitarbeiter andere PDAs bevorzugen und versuchen,
diese im Betrieb einzusetzen und eventuell sogar Untersttzung dafr einfor-
dern. Hierfr sollte eine geeignete Vorgehensweise definiert werden.
- Wurde eine Anforderungsanalyse durchgefhrt?
- Wurde eine Bewertung der relevanten Gerte anhand dieser Anforderungen
durchgefhrt?
- Wurde die Beschaffungsentscheidung mit den Administratoren und dem
technischen Personal abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 2.306 Verlustmeldung
Bei Ausfall, Defekt, Zerstrung oder Diebstahl eines IT-Systems sollte dies
umgehend gemeldet werden. Hierfr sollte es in jeder Organisation klare
Meldewege und Ansprechpartner geben. Vor allem bei einem Diebstahl muss
schnell gehandelt werden, da es hier nicht nur um die Wiederbeschaffung der
Gerte geht, sondern auch darum, potentiellen Missbrauch der betroffenen
Informationen zu verhindern.
Auf gestohlenen Gerten wie Laptops oder PDAs knnen sich vertrauliche
Daten befinden, nach deren Verlust umgehend gehandelt werden muss, bei-
spielsweise:
- Zugangsdaten wie Passwrter: Alle Zugangsdaten auf eventuell betroffe-
nen IT-Systemen mssen umgehend gendert werden.
- als vertraulich eingestufte Informationen (z. B. Patientenakten): Alle
betroffenen Bereiche (z. B. Fachabteilung, Kunden, etc.) mssen benach-
richtigt werden, um entsprechende Manahmen ergreifen zu knnen.
Wenn verloren geglaubte Gerte wieder auftauchen, ist dies nicht nur ein
Grund zur Freude, sondern sollte auch nachdenklich stimmen. Vor der erneu-
ten Inbetriebnahme sollten die Gerte auf eventuelle Manipulationen unter-
sucht werden (z. B. ob Schrauben geffnet oder Siegel entfernt wurden).
Auerdem sollten sie neu installiert werden, um sicherzustellen, dass sich
keine manipulierten Programme auf diesen befinden (siehe dazu M 4.28 Soft-
ware-Reinstallation bei Benutzerwechsel eines tragbaren PC).
- Wissen die Benutzer wie und wo sie Verlustmeldungen abgeben knnen?
___________________________________________________________________ ..........................................
Manahmenkatalog Personal M3 Bemerkungen
___________________________________________________________________ ..........................................
M3 Manahmenkatalog Personal
M 3.1 Geregelte Einarbeitung/Einweisung neuer Mitarbeiter.............. 1
M 3.2 Verpflichtung der Mitarbeiter auf Einhaltung
einschlgiger Gesetze, Vorschriften und Regelungen ............... 2
M 3.3 Vertretungsregelungen............................................................... 3
M 3.4 Schulung vor Programmnutzung ............................................... 4
M 3.5 Schulung zu IT-Sicherheitsmanahmen .................................... 5
M 3.6 Geregelte Verfahrensweise beim Ausscheiden von
Mitarbeitern ............................................................................... 8
M 3.7 Anlaufstelle bei persnlichen Problemen .................................. 9
M 3.8 Vermeidung von Strungen des Betriebsklimas...................... 10
M 3.9 Ergonomischer Arbeitsplatz .................................................... 11
M 3.10 Auswahl eines vertrauenswrdigen Administrators und
Vertreters ................................................................................. 12
M 3.11 Schulung des Wartungs- und Administrationspersonals ......... 13
M 3.12 Information aller Mitarbeiter ber mgliche TK-
Warnanzeigen, -symbole und -tne ........................................ 14
M 3.13 Sensibilisierung der Mitarbeiter fr mgliche TK-
Gefhrdungen........................................................................... 15
M 3.14 Einweisung des Personals in den geregelten Ablauf
eines Datentrgeraustausches................................................... 16
M 3.15 Informationen fr alle Mitarbeiter ber die Faxnutzung ......... 17
M 3.16 Einweisung in die Bedienung des Anrufbeantworters............. 18
M 3.17 Einweisung des Personals in die Modem-Benutzung.............. 19
M 3.18 Verpflichtung der Benutzer zum Abmelden nach
Aufgabenerfllung................................................................... 20
M 3.19 Einweisung in den richtigen Einsatz der
Sicherheitsfunktionen von Peer-to-Peer-Diensten................... 21
M 3.20 Einweisung in die Bedienung von Schutzschrnken ............... 23
M 3.21 Sicherheitstechnische Einweisung und Fortbildung des
Telearbeiters............................................................................. 24
M 3.22 Vertretungsregelung fr Telearbeit.......................................... 25
M 3.23 Einfhrung in kryptographische Grundbegriffe....................... 26
M 3.24 Schulung zur Lotus Notes Systemarchitektur fr
Administratoren ....................................................................... 39
M 3.25 Schulung zu Lotus Notes Sicherheitsmechanismen fr
Benutzer .................................................................................. 43
___________________________________________________________________ ..........................................
Manahmenkatalog Personal M3 Bemerkungen
___________________________________________________________________ ..........................................
M 3.26 Einweisung des Personals in den sicheren Umgang mit

IT.............................................................................................. 45
M 3.27 Schulung zur Active Directory-Verwaltung ............................ 47
M 3.28 Schulung zu Windows 2000 Sicherheitsmechanismen
fr Benutzer ............................................................................. 53
M 3.29 Schulung zur Administration von Novell eDirectory .............. 55
M 3.30 Schulung zum Einsatz von Novell eDirectory
Clientsoftware.......................................................................... 59
M 3.31 Schulung zur Systemarchitektur und Sicherheit von
Exchange 2000 fr Administratoren........................................ 62
M 3.32 Schulung zu Sicherheitsmechanismen von Outlook
2000 fr Benutzer .................................................................... 65
M 3.33 Sicherheitsberprfung von Mitarbeitern ................................ 66
M 3.34 Einweisung in die Administration des Archivsystems ............ 67
M 3.35 Einweisung der Benutzer in die Bedienung des
Archivsystems.......................................................................... 68
M 3.36 Schulung der Administratoren zur sicheren Installation
und Konfiguration des IIS........................................................ 70
M 3.37 Schulung der Administratoren eines Apache-
Webservers .............................................................................. 72
M 3.38 Administratorenschulung fr Router und Switches ................. 74
M 3.39 Einfhrung in die zSeries-Plattform ........................................ 77
M 3.40 Einfhrung in das z/OS-Betriebssystem .................................. 91
M 3.41 Einfhrung in Linux und z/VM fr zSeries-Systeme ............ 102
M 3.42 Schulung des z/OS-Bedienungspersonals.............................. 106
M 3.43 Schulung der Administratoren des Sicherheitsgateways ....... 107
___________________________________________________________________ ..........................................
Manahmenkatalog Personal M 3.1 Bemerkungen
___________________________________________________________________ ..........................................
M 3.1 Geregelte Einarbeitung/Einweisung neuer

Mitarbeiter
Personal
Neuen Mitarbeitern mssen interne Regelungen, Gepflogenheiten und Verfah-
rensweisen im IT-Einsatz bekannt gegeben werden. Ohne eine entsprechende
Einweisung kennen sie ihre Ansprechpartner bzgl. IT-Sicherheit nicht, sie
wissen nicht, welche IT-Sicherheitsmanahmen durchzufhren sind und
welche IT-Sicherheitspolitik die Behrde bzw. das Unternehmen betreibt.
Daraus knnen Strungen und Schden fr den IT-Einsatz erwachsen. Daher
kommt der geregelten Einarbeitung neuer Mitarbeiter eine entsprechend hohe
Bedeutung zu.
Die Einarbeitung bzw. Einweisung sollte zumindest folgende Punkte
umfassen:
- Planung der notwendigen Schulungen; arbeitsplatzbezogene Schulungs-
manahmen (s. auch M 3.4 Schulung vor Programmnutzung und M 3.5
Schulung zu IT-Sicherheitsmanahmen),
- Vorstellung aller Ansprechpartner, insbesondere zu IT-Sicherheitsfragen,
- Erluterung der hausinternen Regelungen und Vorschriften zur IT-Sicher-
heit.
Hilfreich zur Durchfhrung der Einarbeitung ist ein Laufzettel oder eine
Checkliste, aus der die einzelnen Aktivitten und der erreichte Stand der
Einarbeitung ersichtlich sind.
- Wie ist die Einarbeitung von neuem Personal im IT-Bereich geregelt?
- Wieviel Einarbeitungszeit wird jedem neuen Mitarbeiter zur Verfgung
gestellt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.2 Verpflichtung der Mitarbeiter auf Einhaltung

einschlgiger Gesetze, Vorschriften und
Regelungen
Verantwortlich fr Initiierung: Leiter Personal, Datenschutzbeauftragter, IT-
Bei der Einstellung von Mitarbeitern sollen diese verpflichtet werden, ein-
schlgige Gesetze (z. B. 5 BDSG "Datengeheimnis"), Vorschriften und
interne Regelungen einzuhalten. Damit sollen neue Mitarbeiter mit den beste-
henden Vorschriften und Regelungen zur IT-Sicherheit bekannt gemacht und
gleichzeitig zu deren Einhaltung motiviert werden. Dabei ist es sinnvoll, nicht
nur die Verpflichtung durchzufhren, sondern auch die erforderlichen Exem-
plare der Vorschriften und Regelungen auszuhndigen und gegenzeichnen zu
lassen bzw. fr die Mitarbeiter an zentraler Stelle zur Einsichtnahme vorzu-
halten.
Alle Mitarbeiter sollten insbesondere darauf hingewiesen werden, dass alle
Arbeitsergebnisse und alle whrend der Arbeit erhaltenen Informationen
ausschlielich zum internen und dienstlichen Gebrauch bestimmt sind.
- Auf welche Weise wird die Verpflichtung durchgefhrt?
- Wird die Verpflichtung schriftlich fixiert?
- Erhlt der neue Mitarbeiter die entsprechenden Unterlagen zur Einsicht
oder zum Verbleib?
- Ist den Mitarbeitern bekannt, welcher rechtliche Rahmen ihre Ttigkeit
bestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.3 Vertretungsregelungen
Verantwortlich fr Umsetzung: Vorgesetzte
Vertretungsregelungen haben den Sinn, fr vorhersehbare (Urlaub, Dienst-
reise) und auch unvorhersehbare Flle (Krankheit, Unfall, Kndigung) des
Personenausfalls die Fortfhrung der Aufgabenwahrnehmung zu ermglichen.
Daher muss vor Eintritt eines solchen Falles geregelt sein, wer wen in welchen
Angelegenheiten mit welchen Kompetenzen vertritt. Dies ist besonders im
Bereich der Informationsverarbeitung von Bedeutung, da dafr meist
Spezialwissen erforderlich ist und eine zeitgerechte Einarbeitung unkundiger
Mitarbeiter fr den Vertretungsfall nicht mglich ist.
Fr die Vertretungsregelungen sind folgende Randbedingungen einzuhalten:
- Die bernahme von Aufgaben im Vertretungsfall setzt voraus, dass der
Verfahrens- oder Projektstand hinreichend dokumentiert ist.
- Das Benennen eines Vertreters reicht in der Regel nicht aus, es muss ber-
prft werden, wie der Vertreter zu schulen ist, damit er die Aufgaben
inhaltlich bernehmen kann. Stellt sich heraus, dass es Personen gibt, die
aufgrund ihres Spezialwissens nicht kurzfristig ersetzbar sind, so bedeutet
deren Ausfall eine gravierende Gefhrdung des Normalbetriebes. Hier ist
es von besonders groer Bedeutung, einen Vertreter zu schulen.
- Es muss festgelegt sein, welcher Aufgabenumfang im Vertretungsfall von
wem wahrgenommen werden soll.
- Der Vertreter darf die erforderlichen Zugangs- und Zutrittsberechtigungen
nur im Vertretungsfall erhalten.
- Ist es in Ausnahmefllen nicht mglich, fr Personen einen kompetenten
Vertreter zu benennen oder zu schulen, sollte frhzeitig berlegt werden,
welche externen Krfte fr den Vertretungsfall eingesetzt werden knnen.
- Wie ist der Vertretungsfall in den einzelnen Organisationseinheiten gere-
gelt?
- Stehen ausreichend kompetente Vertreter zu Verfgung?
- Gab es in der letzten Zeit die Notwendigkeit von unvorhergesehenen Ver-
tretungen?
- Gibt es in einer Organisationseinheit einen "Single Point of Knowledge",
eine einzelne Person, die alleine ber Spezialwissen verfgt, das fr den
IT-Einsatz notwendig ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.4 Schulung vor Programmnutzung

Verantwortlich fr Initiierung: Leiter Personal, Vorgesetzte
Verantwortlich fr Umsetzung: Vorgesetzte, Verantwortliche der einzelnen
IT-Anwendungen
Durch unsachgemen Umgang mit IT-Anwendungen hervorgerufene Sch-
den knnen vermieden werden, wenn die Benutzer eingehend in die IT-
Anwendungen eingewiesen werden. Daher ist es unabdingbar, dass die Be-
nutzer vor der bernahme IT-gesttzter Aufgaben ausreichend geschult
werden. Dies betrifft sowohl die Nutzung von Standardprogrammpaketen als
auch von speziell entwickelten IT-Anwendungen.
Darber hinaus mssen auch bei umfangreichen nderungen in einer
IT-Anwendung Schulungsmanahmen durchgefhrt werden.
Stehen leicht verstndliche Handbcher zu IT-Anwendungen bereit, so kann
anstelle der Schulung auch die Aufforderung stehen, sich selbstndig einzu-
arbeiten. Eine wesentliche Voraussetzung dazu ist allerdings die Bereit-
stellung ausreichender Einarbeitungszeit.
- Werden Mitarbeiter, die eine IT-gesttzte Aufgabe neu bernehmen sollen,
ausreichend geschult? Wird ein Schulungsplan fr die Einfhrung einer
neuen IT-Anwendung erstellt?
- Welche IT-Anwendungen sind seit der letzten berprfung neu hinzu-
gekommen? Wie wurden die Mitarbeiter eingearbeitet? Welche
Schulungsveranstaltungen haben Mitarbeiter seitdem besucht?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.5 Schulung zu IT-Sicherheitsmanahmen

Verantwortlich fr Initiierung: Vorgesetzte, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: Vorgesetzte, IT-Sicherheitsmanagement
Die berwiegende Zahl von Schden im IT-Bereich entsteht durch Nachls-
sigkeit. Um dies zu verhindern, ist jeder einzelne zum sorgfltigen Umgang
mit der IT zu motivieren. Zustzlich sind Verhaltensregeln zu vermitteln, die
ein Verstndnis fr die IT-Sicherheitsmanahmen wecken. Insbesondere
sollen folgende Themen in der Schulung zu IT-Sicherheitsmanahmen
vermittelt werden:
- Sensibilisierung fr IT-Sicherheit
Jeder Mitarbeiter ist auf die Notwendigkeit der IT-Sicherheit hinzuweisen.
Das Aufzeigen der Abhngigkeit der Behrde bzw. des Unternehmens und
damit der Arbeitspltze von dem reibungslosen Funktionieren der
IT-Systeme ist ein geeigneter Einstieg in die Sensibilisierung. Darber
hinaus ist der Wert von Informationen herauszuarbeiten, insbesondere
unter den Gesichtspunkten Vertraulichkeit, Integritt und Verfgbarkeit.
Diese Sensibilisierungsmanahmen sind in regelmigen Zeitabstnden zu
wiederholen, eventuell auch durch praktische Hinweise z. B. in der Haus-
post.
- Die mitarbeiterbezogenen IT-Sicherheitsmanahmen
Zu diesem Thema sollen die IT-Sicherheitsmanahmen vermittelt werden,
die in einem IT-Sicherheitskonzept erarbeitet wurden und von den einzel-
nen Mitarbeitern umzusetzen sind. Dieser Teil der Schulungsmanahmen
hat eine groe Bedeutung, da viele IT-Sicherheitsmanahmen erst nach
einer entsprechenden Schulung und Motivation effektiv umgesetzt werden
knnen.
- Die produktbezogenen IT-Sicherheitsmanahmen
Zu diesem Thema sollen die IT-Sicherheitsmanahmen vermittelt werden,
die inhrent mit einem Softwareprodukt verbunden sind und bereits im
Lieferumfang enthalten sind. Dies knnen neben Passwrtern zur Anmel-
dung, der Pausenschaltung durch Bildschirmschoner auch Mglichkeiten
der Verschlsselung von Dokumenten oder Datenfeldern sein. Hinweise
und Empfehlungen ber die Strukturierung und Organisation von Dateien,
die Bewegungsdaten enthalten, knnen die Vergabe von Zugriffsrechten
erleichtern und den Aufwand zu Datensicherung deutlich reduzieren.
- Das Verhalten bei Auftreten eines Computer-Virus auf einem PC
Hier soll den Mitarbeitern vermittelt werden, wie mit Computer-Viren
umzugehen ist. Mgliche Inhalte dieser Schulung sind (siehe M 6.23
Verhaltensregeln bei Auftreten eines Computer-Virus):
- Erkennen des Computer-Virusbefalls
- Wirkungsweise und Arten von Computer-Viren
- Sofortmanahmen im Verdachtsfall
- Manahmen zur Eliminierung des Computer-Virus
- Vorbeugende Manahmen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der richtige Einsatz von Passwrtern

Hierbei sollen die Bedeutung des Passwortes fr die IT-Sicherheit sowie
die Randbedingungen erlutert werden, die einen wirksamen Einsatz eines
Passwortes erst ermglichen (siehe auch M 2.11 Regelung des
Passwortgebrauchs).
- Die Bedeutung der Datensicherung und deren Durchfhrung
Die regelmige Datensicherung ist eine der wichtigsten
IT-Sicherheitsmanahmen in jedem IT-System. Vermittelt werden soll das
Datensicherungskonzept (siehe Kapitel 3.4 Datensicherungskonzept) der
Organisation und die von jedem einzelnen durchzufhrenden Datensiche-
rungsaufgaben. Besonders bedeutend ist dies fr den PC-Bereich, in dem
jeder Benutzer selbst die Datensicherung verantwortlich durchfhren muss.
- Der Umgang mit personenbezogenen Daten
An den Umgang mit personenbezogene Daten sind besondere Anforderun-
gen zu stellen. Mitarbeiter, die mit personenbezogenen Daten (sowohl in
IT-Systemen als auch in Akten) arbeiten mssen, sind fr die gesetzlich
erforderlichen Sicherheitsmanahmen zu schulen. Dies betrifft den
Umgang mit Auskunftsersuchen, nderungs- und Verbesserungswnschen
der Betroffenen, gesetzlich vorgeschriebene Lschfristen, Schutz der Ver-
traulichkeit und die bermittlung der Daten.
- Die Einweisung in Notfallmanahmen
Smtliche Mitarbeiter (auch nicht unmittelbar mit IT befasste Personen wie
Pfrtnerdienst oder Wachpersonal) sind in bestehende Notfallmanahmen
einzuweisen. Dazu gehrt die Erluterung der Fluchtwege, die Verhal-
tensweisen bei Feuer, der Umgang mit Feuerlschern, das Notfall-Melde-
system (wer als erstes wie zu benachrichtigen ist) und der Umgang mit
dem Notfall-Handbuch.
- Vorbeugung gegen Social Engineering
Die Mitarbeiter sollen auf die Gefahren des Social Engineering hinge-
wiesen werden. Die typischen Muster solcher Versuche, ber gezieltes
Aushorchen an vertrauliche Informationen zu gelangen, ebenso wie die
Methoden, sich dagegen zu schtzen, sollten bekannt gegeben werden. Da
Social Engineering oft mit der Vorspiegelung einer falschen Identitt
einhergeht, sollten Mitarbeiter regelmig darauf hingewiesen werden, die
Identitt von Gesprchspartnern zu berprfen und insbesondere am Tele-
fon keine vertraulichen Informationen weiterzugeben.
Bei der Durchfhrung von Schulungen sollte immer beachtet werden, dass es
nicht reicht, einen Mitarbeiter einmal whrend seines gesamten Arbeits-
verhltnisses zu schulen. Fr nahezu alle Formen von Schulungen, insbeson-
dere Front-Desk-Schulungen, gilt, dass sehr viele neue Informationen auf die
Teilnehmer einstrzen. Diese gelangen nur zu einem kleinen Teil ins Lang-
zeitgedchtnis, 80% sind meist schon bei Schulungsende wieder vergessen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Daher sollten Mitarbeiter immer wieder zu Themen der IT-Sicherheit geschult

bzw. sensibilisiert werden. Dies kann beispielsweise
- in krzeren Veranstaltungen zu aktuellen IT-Sicherheitsthemen,
- im Rahmen regelmiger Veranstaltungen wie Abteilungsbesprechungen,
oder
- durch interaktive Schulungsprogramme, die allen Mitarbeitern zur
verfgung stehen,
erfolgen.
- Welche Themen bzgl. IT-Sicherheitsmanahmen wurden schon geschult?
- Werden neue Mitarbeiter entsprechend in die IT-Sicherheitsmanahmen
eingewiesen?
- Welche Schulungsmanahmen werden in welchen Intervallen angeboten?
- Decken die Inhalte der Schulungsmanahmen die erforderlichen Gebiete
ab?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.6 Geregelte Verfahrensweise beim Ausscheiden

von Mitarbeitern
Verantwortlich fr Initiierung: Leiter Personal, Vorgesetzte, IT-
Scheidet ein Mitarbeiter aus, so ist zu beachten:
- Vor dem Ausscheiden ist eine Einweisung des Nachfolgers durchzufhren.
- Von dem Ausscheidenden sind smtliche Unterlagen, ausgehndigte
Schlssel, ausgeliehene IT-Gerte (z. B. tragbare Rechner, Speicher-
medien, Dokumentationen) zurckzufordern. Insbesondere sind die
Behrden- bzw. Firmenausweise einzuziehen.
- Es sind smtliche fr den Ausscheidenden eingerichteten Zugangsberech-
tigungen und Zugriffsrechte zu entziehen bzw. zu lschen. Dies betrifft
auch die externen Zugangsberechtigungen via Datenbertragungs-
einrichtungen. Wurde in Ausnahmefllen eine Zugangsberechtigung zu
einem IT-System zwischen mehreren Personen geteilt (z. B. mittels eines
gemeinsamen Passwortes), so ist nach Ausscheiden einer der Personen die
Zugangsberechtigung zu ndern.
- Vor der Verabschiedung sollte noch einmal explizit darauf hingewiesen
werden, dass alle Verschwiegenheitserklrungen weiterhin in Kraft bleiben
und keine whrend der Arbeit erhaltenen Informationen weitergegeben
werden drfen.
- Ist die ausscheidende Person ein Funktionstrger in einem Notfallplan, so
ist der Notfallplan zu aktualisieren.
- Smtliche mit Sicherheitsaufgaben betrauten Personen, insbesondere der
Pfrtnerdienst, sind ber das Ausscheiden des Mitarbeiters zu unterrichten.
- Ausgeschiedenen Mitarbeitern ist der unkontrollierte Zutritt zum
Behrden- oder Firmengelnde, insbesondere zu Rumen mit IT-Systemen
zu verwehren.
- Optional kann sogar fr den Zeitraum zwischen Aussprechen der Kndi-
gung und dem Ausscheiden der Entzug smtlicher Zugangs- und Zugriffs-
rechte auf IT-Systeme sowie darber hinaus auch das Verbot, schtzens-
werte Rume zu betreten, ausgesprochen werden.
Als ein praktikables Hilfsmittel haben sich Laufzettel erwiesen, auf denen die
einzelnen Aktivitten des Ausscheidenden vorgezeichnet sind, die er vor
Verlassen der Behrde bzw. des Unternehmens zu erledigen hat.
- Wird das Ausscheiden eines Mitarbeiters geordnet durchgefhrt?
- Werden die zustndigen Stellen ber das Ausscheiden eines Mitarbeiters
unterrichtet?
- Wie wird sichergestellt, dass smtliche Zugangsberechtigungen und
Zugriffsrechte einer ausscheidenden Person entzogen und gelscht
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.7 Anlaufstelle bei persnlichen Problemen

Verantwortlich fr Initiierung: Leiter Personal, Personalrat/Betriebsrat
Verantwortlich fr Umsetzung: Personalabteilung, Personalrat/Betriebsrat
Fr eine unzureichende Aufgabenerfllung knnen oftmals persnliche Pro- Vertrauenspersonen
benennen
bleme eines Arbeitnehmers urschlich sein. Als Probleme lassen sich
beispielsweise hohe Schulden, Suchtkrankheiten aber auch Schwierigkeiten
am Arbeitsplatz (ber-/Unterforderung, Mobbing) aufzhlen. Um dem
Betroffenen bei der Bewltigung dieser Probleme zu helfen, kann es in vielen
Fllen hilfreich sein, wenn eine Vertrauensperson zur Verfgung steht. Dieser
Ansprechpartner sollte dabei sowohl die Interessen des Betroffenen im Auge
haben und konkrete Hilfestellung anbieten als auch die Interessen des Unter-
nehmens bzw. Behrde wahren und gemeinsam mit dem Betroffenen nach
Lsungsmglichkeiten suchen.
An diese Vertrauensperson mssen sich aber auch Vorgesetzte und Kollegen
wenden knnen, wenn wiederholt Aufflligkeiten Dritter wahrgenommen
wurden, die auf eine verminderte Zuverlssigkeit schlieen lassen. Die
Vertrauensperson muss dann die Mglichkeit haben, sich an den Betroffenen
zu wenden und Hilfe anzubieten.
Eine solche Stelle knnen Personalrat, Betriebsrat, Betriebsrzte einnehmen.
Die Einrichtung einer solchen Anlaufstelle ist allen Mitarbeitern bekannt zu
geben. Externe Stellen sind zum Beispiel die Beratungsstellen der gesetzlichen
Krankenkassen.
- An wen knnen sich Mitarbeiter bei persnlichen Problemen wenden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.8 Vermeidung von Strungen des Betriebsklimas

Personal, Personalrat/Betriebsrat
Verantwortlich fr Umsetzung: Vorgesetzte, Personalabteilung,
Personalrat/Betriebsrat
Durch ein positives Betriebsklima werden die Mitarbeiter einerseits zur Ein-
haltung von IT-Sicherheitsmanahmen motiviert, andererseits wird die Gefahr
von fahrlssigen oder vorstzlichen Handlungen reduziert, die den IT-Betrieb
stren knnen. Strungen des Betriebsklimas knnen dabei eine Vielzahl von
inner- und auerbetrieblichen Ursachen haben, treten jedoch hufig bei gravie-
renden innerbetrieblichen Vernderungen auf. Beispiele fr solche Vernde-
rungen sind Umstrukturierungen, Sanierungen, Verkauf oder Fusionen von
Organisationseinheiten und Outsourcing-Vorhaben. Diese knnen das Be-
triebsklima negativ beeinflussen, da sie meistens ngste unterschiedlicher Art
(z. B. Kompetenzverlust, Versagensngste, Arbeitsplatzverlust) hervorrufen.
Diese knnen besser bewltigt werden, wenn das Betriebsklima schon vor den
Vernderungen mglichst gut ist.
Auch unter IT-Sicherheitsaspekten sollte daher versucht werden, ein positives
Betriebsklima zu erreichen. Die Vielzahl der Mglichkeiten kann hier nicht
angefhrt werden, es sei lediglich eine Auswahl mglicher Manahmen ge-
nannt, deren Angemessenheit im Einzelnen zu prfen wre:
- Einrichtung eines Sozialraums,

- Vermeidung von berstunden,
- Einhaltung von Pausenzeiten,
- geregelte Aufgabenverteilung,
- gleichmige Arbeitsauslastung,
- leistungsgerechte Bezahlung.
Kommunikationsprobleme in einer Organisation fhren fast zwangslufig Kommunikation
auch zu Sicherheitsproblemen. Dies kann im Extremfall zu bewussten Sicher-
heitsverletzungen fhren. Wenn die Benutzer Sicherheitsmanahmen nur als
"lstig" empfinden, weil sie nicht ber deren Zweck informiert worden sind,
kann das bereits dazu fhren, dass diese umgangen werden.
Auch das berbringen schlechter Nachrichten muss mglich sein, ohne dass
der Bote deswegen Sanktionen befrchten muss. Es sollte ein Betriebsklima
vorhanden sein, in dem es fr jeden Betroffenen mglich ist, Sicherheitsvor-
flle innerhalb des eigenen Unternehmens bzw. der eigenen Behrde zu mel-
den, so dass diese auch offen angegangen werden knnen.
Mitarbeiter knnen nicht nur ber finanzielle Anreize motiviert werden, Motivation der
Mitarbeiter
wichtig ist vor allem die Anerkennung ihrer Arbeit. Mitarbeiter sollten, wo
immer mglich, in Entscheidungen mit einbezogen werden. Zumindest sollten
sie ber die Grnde fr die getroffenen Entscheidungen informiert werden,
damit sie auch an deren Umsetzung aktiv mitwirken.
Hufig uert sich z. B. Protest gegen die Auswahl bestimmter Hard- oder
Software darin, dass die Benutzer zu zeigen versuchen, dass die aufgezwun-
gene Hard- oder Software nicht so sicher ist, wie die von ihnen prferierte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Betriebsklima und das Verhalten von Mitarbeitern kann besonders bei Outsourcing
groen Vernderungen, wie etwa bei Outsourcing-Vorhaben, von besonderer
Bedeutung sein: unzufriedene oder verrgerte Mitarbeiter knnen ein solches
Vorhaben zum Scheitern verurteilen (z. B. Kndigung von Know-how-
Trgern in kritischen Phasen der Vernderung oder bewusstes Ignorieren von
Sicherheitsanweisungen), was fr das Unternehmen in Folge existenzbedro-
hend sein kann. Bei greren Umstrukturierungen oder Outsourcing-Vorhaben
ist die Beachtung folgender Aspekte empfehlenswert:
- Die Mitarbeiter sollten frhzeitig in Entscheidungsprozesse wie die Aus- Mitarbeiter einbeziehen
wahl eines Outsourcing-Dienstleisters eingebunden werden. Im weiteren
Projektverlauf sollten sie an der Gestaltung von eventuellen bernahme-
vertrgen beteiligt werden.
- Die Mitarbeiter sollten umfassend und frhzeitig ber Vernderungen
informiert werden und einen Ansprechpartner fr Probleme und Fragen
haben. Information durch die Zeitung statt durch die Firmen- oder Behr-
denleitung schafft Misstrauen, zerstrt Vertrauen und bereitet Spekulatio-
nen und Gerchten den Boden.
- Bei organisatorischen Vernderungen sollten den betroffenen Mitarbeitern
Zukunftsperspektiven aufgezeigt werden. Oftmals sind Outsourcing-
Dienstleister darauf angewiesen, dass ein mglichst hoher Anteil der Mit-
arbeiter des auszulagernden Bereichs zu ihnen wechselt. Nur so kann eine
befriedigende Dienstleistungsqualitt garantiert werden. Mitarbeiter, die
Zukunftsangst haben oder sich unfair behandelt fhlen, lassen in ihrer Ar-
beitsqualitt nach oder verlassen sogar vorzeitig das Unternehmen.
- Anspruchsvolle oder belastende Ttigkeiten, die im Rahmen von
Umstrukturierungen nicht zu vermeiden sind, sollten ausreichend gewr-
digt und anerkannt werden. Die erforderliche Mehrarbeit sollte honoriert
werden.
- Wie wird das Betriebsklima von den Mitarbeitern beurteilt?
- Wie beurteilen die Vorgesetzten das Betriebsklima?
- Welche Punkte, die das Betriebsklima negativ beeinflussen, werden am
hufigsten genannt?
- Gibt es bei greren Umstrukturierungen einen Verantwortlichen, der fr
die betroffenen Mitarbeiter als Ansprechpartner zur Verfgung steht?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.9 Ergonomischer Arbeitsplatz

Verantwortlich fr Initiierung: Leiter Haustechnik, Personalrat/Betriebsrat
Verantwortlich fr Umsetzung: Vorgesetzte, Personalrat/Betriebsrat,
Mitarbeiter
Beim sinnvollen und effektiven Einsatz der IT ist es neben der klaren
Beschreibung von Aufgaben, Pflichten, Rechten und Verantwortlichkeiten
erforderlich, dafr zu sorgen, dass die Nutzung der IT in optimaler Weise
erfolgen kann.
Der Arbeitsplatz ist ergonomisch zu gestalten. Stuhl, Tisch, Bildschirm und
Tastatur mssen individuell einstellbar sein, um eine mglichst fehlerfreie
Bedienung der IT zu ermglichen und zu frdern. Das beinhaltet u. a., dass
Rckenlehne, Sitzhhe und Sitzflche des Stuhls verstellbar sein mssen, aber
auch, dass die Arbeitsmittel so angeordnet werden knnen, dass fr die
jeweilige Arbeitsaufgabe eine mglichst geringe Belastung entsteht.
Ein entsprechend ausgestatteter Arbeitsplatz erleichtert es auch, IT-Sicher-
heitsmanahmen einzuhalten. Gibt es verschliebare Schreibtische oder
Schrnke, so knnen Datentrger, Dokumentationen, Unterlagen und Zubehr
darin verschlossen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.10 Auswahl eines vertrauenswrdigen

Administrators und Vertreters
Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung, Leiter Per-
sonal, Leiter IT, TK-Anlagen-Verantwort-
licher, IT-Sicherheitsmanagement
Den IT-System- oder TK-Anlagen-Administratoren und deren Vertretern
muss vom Betreiber groes Vertrauen entgegengebracht werden knnen. Sie
haben - in Abhngigkeit vom eingesetzten System - weitgehende und oftmals
alle Befugnisse. Administratoren und ihre Vertreter sind in der Lage, auf alle
gespeicherten Daten zuzugreifen, ggf. zu verndern und Berechtigungen so zu
vergeben, dass erheblicher Missbrauch mglich wre.
Das hierfr eingesetzte Personal muss sorgfltig ausgewhlt werden. Es soll
regelmig darber belehrt werden, dass die Befugnisse nur fr die erforder-
lichen Administrationsaufgaben verwendet werden drfen.
Da der Administrator hinsichtlich der Funktionsfhrigkeit der eingesetzten
Hard- und Software eine Schlsselrolle inne hat, muss auch bei seinem
Ausfall die Weiterfhrung seiner Ttigkeiten gewhrleistet sein. Hierzu
mssen die benannten Vertreter ber den aktuellen Stand der
Systemkonfiguration verfgen sowie Zugriff auf die fr die Administration
bentigten Passwrter, Schlssel und Sicherheitstoken haben.
Hat ein Unternehmen oder eine Behrde mehrere Administratoren mit ver-
gleichbaren IT-Systemkenntnissen, so knnen sich diese auch wechselseitig
vertreten, wenn diese dafr noch freie Kapazitten haben. In allen Bereichen,
in denen nur ein Administrator hauptverantwortlich IT-Systeme betreut,
sollten zwei Stellvertreter eingearbeitet werden, da bei lngerer Abwesenheit
des Administrators erfahrungsgem auch der Stellvertreter zeitweise nicht fr
Administrationsaufgaben zur Verfgung steht.
Um die Funktionsfhigkeit des IT-Betriebs zu gewhrleisten, muss insbeson-
dere bei bevorstehenden Personalvernderung oder Vernderungen der
Organisationsstruktur geprft werden, ob die erforderlichen Administra-
tionsttigkeiten auch durch die benannten Administratoren und deren Vertre-
tern bewltigt werden kann.
Insbesondere bei bevorstehenden Umzgen kann es durch Administra-
tionstaufgaben an einem weiteren Standort zu einem erheblichen hheren
Arbeitsaufkommen des Administrators kommen. Auch in solchen Fllen muss
sichergestellt sein, dass der Produktionsbetrieb am bisherigen Standort bis
zum Zeitpunkt des Umzugs nicht beeintrchtigt wird.
- Wie wurde die Zuverlssigkeit des Administrators bzw. seines Stellver-
treters festgestellt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.11 Schulung des Wartungs- und

Administrationspersonals
Personal, Leiter IT, TK-Anlagen-
Verantwortlicher, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: Vorgesetzte
Wartungs- und Administrationspersonal bentigt detaillierte Kenntnisse ber
die eingesetzten IT-Komponenten. Daher sollte es mindestens soweit geschult
werden, dass
- alltgliche Administrationsarbeiten selbst durchgefhrt,
- einfache Fehler selbst erkannt und behoben,
- Datensicherungen selbstttig durchgefhrt,
- die Eingriffe von externem Wartungspersonal nachvollzogen und
- Manipulationsversuche oder unbefugte Zugriffe auf die Systeme erkannt
werden knnen.
Entsprechende Schulungen werden in der Regel von den Herstellern der IT-
Systeme bzw. TK-Anlagen angeboten. Administratoren von TK-Anlagen soll-
ten auerdem in der Lage sein,
- das Betriebsverhalten der TK-Anlage mit Hilfe der Kontrollanzeigen an
den Gerten zu beurteilen,
- die TK-Anlage selbstndig auer- und in Betrieb nehmen zu knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.12 Information aller Mitarbeiter ber mgliche TK-

Warnanzeigen, -symbole und -tne
Verantwortlich fr Initiierung: TK-Anlagen-Verantwortlicher, IT-
Sicherheitsmanagement,
Die Bedeutung der Warnanzeigen, -tne und -symbole der TK-Anlage sollte
allen Mitarbeitern bekannt sein. Hierzu zhlen insbesondere:
- Aufmerksamkeitston fr direktes Ansprechen,
- Aufschalte-Warnton,
- Freisprechanzeige,
- Anzeige fr aktiviertes direktes Ansprechen,
- Anzeige fr automatischen Rckruf und
- Anzeige/Einblendung bei Dreierkonferenz.
Da die Nutzung bestimmter, eigentlich nicht freigegebener Leistungsmerk-
male (Beispiel: Zeugenschaltung) zu Beeintrchtigungen der IT-Sicherheit
fhren kann, sollten besonders deren Warnanzeigen und -tne bekannt sein.
- Erkennen die Mitarbeiter, wenn sich jemand auf ein Gesprch aufschaltet?
- Wissen die Mitarbeiter, was an einem Telefon bei direkter Ansprache
sicht- und hrbar ist?
- Ist am Telefon erkennbar, dass das Freisprechen aktiviert ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.13 Sensibilisierung der Mitarbeiter fr mgliche

TK-Gefhrdungen
Verantwortlich fr Initiierung: TK-Anlagen-Verantwortlicher, IT-
Sicherheitsmanagement,
Die Mitarbeiter mssen ber die mit dem Benutzen einer digitalen TK-Anlage
verbundenen Gefhrdungen informiert werden. Dies knnte z. B. durch eine
kurze Unterweisung oder mit Hilfe von Merkblttern geschehen. Es ist darauf
hinzuweisen, dass ein abnormes Verhalten der TK-Anlage gemeldet werden
soll. Bei Manipulationen an der TK-Anlage sollte eine unabhngige Kontroll-
instanz wie IT-Sicherheitsmanagement oder Datenschutzbeauftragte infor-
miert werden.
- Wird die Sensibilisierung in regelmigen Abstnden wiederholt?
- Werden neue Mitarbeiter auf mgliche Gefhrdungen im TK-Betrieb hin-
gewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.14 Einweisung des Personals in den geregelten

Ablauf eines Datentrgeraustausches
Mangelnde Information und Einweisung der Mitarbeiter fhrt in vielen Fllen
dazu, dass Restriktionen der Informationsweitergabe nicht oder nur unzulng-
lich eingehalten werden. Die Festlegungen, welchen Kommunikationspartnern
wann welche Daten bermittelt werden drfen (M 2.42 Festlegung der
mglichen Kommunikationspartner), ist den an einem Datentrgeraustausch
Beteiligten daher zwingend bekannt zu geben. Auerdem sind die prin-
zipiellen Schritte fr den Ablauf eines Datentrgeraustausches zu fixieren
(eventuell als Dienstanweisung) und die Mitarbeiter zur Einhaltung zu ver-
pflichten.
Zustzlich ist eine Sensibilisierung der am Datentrgeraustausch beteiligten
Mitarbeiter hinsichtlich mglicher Gefhrdungen und einzuhaltender Sicher-
heitsmanahmen vor, whrend und nach dem Transport der Datentrger not-
wendig.
Werden bestimmte IT-gesttzte Verfahren zum Schutz der Daten whrend des
Austausches eingesetzt (wie etwa Verschlsselung oder Checksummen-
Verfahren), so sind diese Mitarbeiter in die Handhabung dieser Verfahren aus-
reichend einzuarbeiten.
- Sind allen fr die Kommunikation zugelassenen Mitarbeitern die diesbe-
zglichen Regelungen bekannt?
- Sind die Mitarbeiter mit den eventuell einzusetzenden Verschlsselungs-
oder Checksummen-Verfahren vertraut?
- Sind die fr den Datentrgeraustausch Verantwortlichen hinsichtlich mg-
licher Gefhrdungen ausreichend sensibilisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.15 Informationen fr alle Mitarbeiter ber die

Faxnutzung
Alle Mitarbeiter sind auf die Besonderheiten der Informationsbermittlung per
Fax hinzuweisen sowie darber zu informieren, dass die Rechtsverbindlichkeit
einer Faxsendung stark eingeschrnkt ist. Bei Verwendung herkmmlicher
Faxgerte sollte eine verstndliche Bedienungsanleitung am Faxgert zur
Verfgung stehen. Beim Einsatz eines Faxservers sollten die Benutzer
mindestens eine Kurzreferenz zur eingesetzten Faxclient-Software erhalten.
Insbesondere ist, ggf. in Form einer Dienstanweisung, festzulegen,
- wer der Fax-Verantwortliche ist und damit fr die manuelle Verteilung
eingehender Faxsendungen und als Ansprechpartner in Fax-Problemfllen
zustndig ist,
- wer das Faxgert bzw. den Faxserver benutzen darf,
- dass das Versenden von vertraulichen Informationen per Fax vermieden
werden sollte,
- dass ein einheitliches Faxvorblatt benutzt werden soll,
- dass sich vor Austausch schutzbedrftiger Informationen ber FaxVersand
Empfnger und Absender hierber telefonisch verstndigen,
- dass ggf. Einzelsendenachweise bzw. bertragungsprotokolle fr die
korrekte bertragung zu kontrollieren und diese den Unterlagen beizu-
fgen und ggf. zu archivieren sind,
- dass beim Einsatz eines Faxservers mit automatischer Eingangs-Fax-
Verteilung fr die Akten ein Ausdruck von Eingangs-Faxsendungen zu
fertigen ist bzw. diese elektronisch zu archivieren sind,
- dass bei Ausgangsfaxen, die ber einen Faxserver versendet werden, fr
die Akten ein Ausdruck zu erstellen ist bzw. diese elektronisch zu
archivieren sind,
- dass die Adressbcher und Verteillisten regelmig kontrolliert werden,
damit die Faxe nicht versehentlich an falsche Empfnger gesendet werden.
- Sind alle Mitarbeiter ber die korrekte Faxnutzung informiert und werden
neue Mitarbeiter entsprechend eingewiesen?
- Wissen alle Mitarbeiter, an wen sie sich bei Faxproblemen wenden
knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.16 Einweisung in die Bedienung des

Anrufbeantworters
Jeder, der einen Anrufbeantworter in seinem Bereich einsetzt, sollte sich mit
der Bedienung vertraut machen und so Mglichkeiten und Grenzen des
Gertes kennen lernen. Somit werden Fehlbedienungen weitgehend ausge-
schlossen. Darber hinaus sollten die notwendigen, im Kapitel 8.3 Anruf-
beantworter genannten IT-Sicherheitsmanahmen transparent gemacht
werden.
- Hat jeder Benutzer eines Anrufbeantworters eine Einweisung erhalten?
- Werden Bedienungsanleitungen und Sicherheitshinweise vorgehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.17 Einweisung des Personals in die Modem-

Benutzung
Die Mitarbeiter sind ber mgliche Gefhrdungen, einzuhaltende Sicher-
heitsmanahmen und Regelungen beim Betrieb eines Modems zu unterrich-
ten. Hierbei sind insbesondere die Auswirkungen verschiedener Konfigu-
rationen auf die Betriebssicherheit des Modems zu vermitteln.
Jeder Modem-Benutzer sollte sich mit der Bedienung vertraut machen und so
Mglichkeiten und Grenzen des Gertes kennen lernen.
- Werden Bedienungsanleitungen und Sicherheitshinweise vorgehalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.18 Verpflichtung der Benutzer zum Abmelden nach

Aufgabenerfllung
Wird ein IT-System von mehreren Benutzern genutzt und besitzen die einzel-
nen Benutzer unterschiedliche Zugriffsrechte auf im IT-System gespeicherte
Daten oder Programme, so kann der erforderliche Schutz mittels einer
Zugriffskontrolle nur dann erreicht werden, wenn jeder Benutzer sich nach
Aufgabenerfllung am IT-System abmeldet. Ist es einem Dritten mglich, an
einem IT-System unter der Identitt eines anderen weiterzuarbeiten, so ist
jegliche sinnvolle Zugriffskontrolle unmglich. Daher sind alle Benutzer zu
verpflichten, sich nach Aufgabenerfllung abzumelden. Aus technischen
Grnden (z. B. damit alle offenen Dateien geschlossen werden) sollten auch
dann Regelungen fr die Abmeldung von IT-Systemen getroffen werden,
wenn keine Zugriffskontrolle realisiert ist.
Ist absehbar, dass nur eine kurze Unterbrechung der Arbeit erforderlich ist, Bildschirmsperre
kann an Stelle des Abmeldens auch die manuelle Aktivierung der Bildschirm-
sperre erfolgen (siehe auch M 4.2 Bildschirmsperr,). Bei lngerer Abwesen-
heit sollte die Bildschirmsperre automatisch aktiviert werden.
Einige IT-Systeme bieten die Mglichkeit, einen Zeitraum vorzugeben, nach automatisches
Abmelden
dessen Ablauf ein Benutzer bei Inaktivitt automatisch vom System abgemel-
det wird. Es sollte berlegt werden, ob dieses Verfahren benutzt wird, da es
auch zu Datenverlusten fhren kann. Eine automatische Abmeldung kann
z. B. bei PC-Pools mit starkem Publikumsverkehr zum Einsatz kommen, da
hier ein angemeldeter Benutzer den Arbeitsplatz mit Hilfe der Bildschirm-
sperre unberechtigterweise blockieren kann.
Je nach Arbeitsplatzumgebung ist abzuwgen, welche Vorkehrungen fr
kurzfristige Abwesenheiten von Benutzern zu treffen sind. So sollte eine
automatische Aktivierung der Bildschirmsperre bei Mehr-Benutzer-Systemen
schneller erfolgen als bei solchen fr einen Benutzer, also z. B. bereits nach
5 Minuten.
- Werden neue Mitarbeiter oder Vertreter gleichfalls verpflichtet?
- Wird an die Verpflichtung zum Abmelden regelmig erinnert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.19 Einweisung in den richtigen Einsatz der

Sicherheitsfunktionen von Peer-to-Peer-
Diensten
Gerade beim Einsatz von Peer-to-Peer-Diensten unter WfW und Windows 95,
bei denen die Benutzer selbst Sicherheitsaufgaben wahrnehmen mssen,
kommt der Einweisung in den richtigen Einsatz der Sicherheitsfunktionen
besondere Bedeutung zu. Daher ist jeder Benutzer vorab zumindest zu folgen-
den Punkten zu schulen:
Datenaustausch ber freigegebene Verzeichnisse
- Der Benutzer ist in die korrekte Benutzung der Freigabe von Ressourcen
sowie in das korrekte Aufheben der Verzeichnisfreigabe einzuweisen.
Insbesondere ist die Mglichkeit zu erlutern, freigegebene Verzeichnisse
oder Drucker durch Anhngen des Zeichens "$" an den Freigabenamen zu
verbergen. Dadurch ist fr andere Benutzer nicht ersichtlich, dass diese
Ressource freigegeben ist. Es ist darauf hinzuweisen, dass der Anreiz fr
Attacken vermindert werden kann, wenn man Freigabenamen benutzt, die
keine Rckschlsse auf den Inhalt zulassen und dass Ressourcen nur
solange freigegeben werden sollten, wie dies erforderlich ist.
- Die Bedeutung der Optionen bei Freigabe oder Verbinden von Verzeich-
nissen bzw. Druckern ist darzustellen und auf die Beachtung der jeweiligen
Voreinstellungen ist hinzuweisen:
Beim Start wieder Automatische Freigabe beim Starten von
freigeben WfW ohne Einwirkung des Benutzers
Beim Starten wieder Automatisches Verbinden beim Neustart
verbinden
Kennwort in der Speicherung des Passwortes (sicherheits-
Kennwortliste speichern kritisch), so dass es beim nchsten Verbin-
den nicht mehr eingegeben werden muss
Die Benutzer von Windows 95 und Windows NT/2000 sind darauf hinzu- Freigaben mssen
wieder entfernt werden
weisen, dass jede erfolgte Freigabe wieder explizit zurckgenommen
werden muss, da sie sonst auch nach einem Neustart bestehen bleibt.
- Die Bezeichnungen der mglichen Zugriffsrechte unter WfW und
Windows 95 sind nicht sprechend und mssen daher erlutert werden:
Schreibgeschtzter Zugriff Leserecht fr Dateien und Ausfhrungs-

recht fr Programme
Lese-/Schreibzugriff Lese-/Schreibrecht fr Dateien, Aus-
fhrungsrecht fr Programme, Recht zum
Anlegen und Lschen von Dateien
Zugriff abhngig vom Lese- und Schreibrecht knnen getrennt
Kennwort vergeben werden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Unter Windows 95 knnen Benutzer zwischen den Zugriffsrechten

Schreibgeschtzt, Alle Zugriffsrechte und Benutzerdefiniert whlen, wenn
der Zugriffsschutz auf Benutzer-Ebene realisiert ist. Dann mssen die
Benutzer darauf hingewiesen werden, dass Verzeichnisse nie mit Alle
Zugriffsrechte freigegeben werden sollten, sondern bestenfalls benutzer-
definiert mit Lese- und Schreibrecht fr andere Benutzer.
Sicherheitssensibilisierung
- Der Benutzer ist in die von ihm durchzufhrenden sicherheitsrelevanten
Kontrollen einzuweisen. Dazu muss er insbesondere unterrichtet werden,
wie der Netzwerkmonitor und die zugehrige Protokollfunktion einzu-
setzen sind.
- Der Umgang mit Passwrtern und deren Wechsel ist gem der Sicher- Umgang mit
Passwrtern
heitsstrategie darzulegen.
- Der Benutzer muss darber informiert werden, dass unter WfW und
Windows 95
- in der Datei [anmeldename].pwl Passwrter fr den Zugriff auf
Ressourcen anderer Rechner gespeichert werden,
- unter WfW in der Datei connect.dat die Ressourcen anderer WfW-
Rechner eingetragen sind, die beim Starten von WfW automatisch
wieder verbunden werden,
- in der Datei shares.pwl die eigenen Ressourcen eingetragen sind, die
beim Starten automatisch wieder freigegeben werden.
Diese Dateien knnen vom Benutzer gelscht werden, ohne die System-
integritt zu verletzen. Dies ist insbesondere bei der Datei [anmelde-
name].pwl sinnvoll, wenn versehentlich Passwrter gespeichert wurden.
- Sind Namenskonventionen fr die im Netz verfgbaren Rechner und Namenskonventionen
bekannt geben
Benutzer erstellt worden, sind diese und eventuell bereits vergebene
Namen den Benutzern bekannt zu geben.
- Haben alle Teilnehmer eine ausreichende Schulung zum sicheren Einsatz
von Peer-to-Peer-Diensten erhalten?
- Werden einzelne Aspekte der Schulungsinhalte zur Sensibilisierung spora-
disch wiederholt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.20 Einweisung in die Bedienung von

Schutzschrnken
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Hersteller
Nach der Beschaffung eines Schutzschrankes sind die Benutzer in die korrekte
Bedienung einzuweisen. Dies sollte auch bei der Neubertragung einer
Aufgabe erfolgen, die die Nutzung des Schutzschrankes umfasst. Dabei sind
zumindest folgende Punkte zu vermitteln:
- Der korrekte Umgang mit dem Schloss des Schutzschrankes ist vorzu-
fhren. Auf typische Fehler ist hinzuweisen, zum Beispiel das Nicht-
verwerfen von Codeschlssern. Die Regelungen zur Schlsselverwaltung,
Schlsselhinterlegung und Vertretungsregelung sind aufzuzeigen. Insbe-
sondere ist einzufordern, dass der Schutzschrank bei Nichtbenutzung, auch
kurzfristiger Art, verschlossen wird.
- Die Tastatur eines Servers ist unbedingt im Serverschrank aufzubewahren,
damit nicht unberechtigte Konsol-Eingaben erfolgen knnen.
- Im Falle eines Serverschrankes ist darauf hinzuweisen, dass unntige
brennbare Materialien (Ausdrucke, berzhlige Handbcher, Drucker-
papier) nicht im Serverschrank aufbewahrt werden sollen.
- Datensicherungstrger des Servers sollten in einem anderen Brandabschnitt
gelagert werden. Eine Aufbewahrung im Serverschrank ist daher
ungeeignet und nur dann zulssig, wenn ein Doppel der Datensicherungs-
bestnde in einem anderen Brandabschnitt ausgelagert ist.
- Wird ein klimatisierter Serverschrank eingesetzt, sollten die ffnungs-
zeiten des Serverschrankes minimiert werden. Gegebenenfalls ist spora-
disch zu kontrollieren, ob im Serverschrank Wasser kondensiert ist.
- Werden Personen, die einen Schutzschrank betreuen, in dessen Bedienung
eingewiesen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.21 Sicherheitstechnische Einweisung und

Fortbildung des Telearbeiters
Verantwortlich fr Umsetzung: Vorgesetzte, IT-Sicherheitsmanagement
Der Telearbeiter arbeitet teilweise oder ganz zu Hause. Das bedeutet, dass fr
die Telearbeit zum Teil andere IT-Sicherheitsmanahmen ergriffen werden
mssen als fr die Arbeit innerhalb der Institution. Deshalb ist es notwendig,
dass ein Sicherheitskonzept fr die Telearbeitspltze erstellt wird. Nach
Bekanntgabe des Konzeptes muss der Telearbeiter in die zu realisierenden
Sicherheitsmanahmen eingewiesen und eventuell in ihrem Umgang geschult
werden. Darber hinaus ist der Telearbeiter soweit im Umgang mit dem Tele-
arbeitsrechner zu schulen, dass er einfache Fehlerkorrekturen (z. B. Drucker-
patrone wechseln) wahrnehmen kann bzw. einfache Probleme selbstndig
lsen kann.
- Liegen fr die Telearbeit spezielle IT-Sicherheitskonzepte vor?
- Ist der Telearbeiter fr die Realisierung der IT-Sicherheitsmanahmen
geschult worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.22 Vertretungsregelung fr Telearbeit

M 3.22 Vertretungsregelung fr Telearbeit
Verantwortlich fr Initiierung: IT-Sicherheitsmanagement, Vorgesetzte
Verantwortlich fr Umsetzung: Telearbeiter
ber die Manahme M 3.3 Vertretungsregelungen hinaus sind im Falle der
Vertretung eines Telearbeiters weitere Schritte notwendig. Da der Telearbeiter
hauptschlich auerhalb der Institution ttig ist, muss ein Informationsfluss zu
seinem Vertreter vorgesehen werden. Auch eine Dokumentation der
Arbeitsergebnisse seitens des Telearbeiters ist unabdingbar. Ggf. sind
sporadische oder regelmige Treffen zwischen dem Telearbeiter und seinem
Vertreter sinnvoll.
Ergnzend dazu muss geregelt werden, wie der Vertreter im unerwarteten
Vertretungsfall Zugriff auf die Daten im Telearbeitsrechner oder am Tele-
arbeitsplatz vorhandene Unterlagen nehmen kann.
- Sind Vertreter fr Telearbeiter benannt worden?
- Ist ein Vertretungsfall probeweise durchgespielt worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.23 Einfhrung in kryptographische Grundbegriffe

Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Leiter IT
Der Einsatz von Kryptoprodukten kann fr die Benutzer zustzlichen Auf-
wand bedeuten oder - je nach Komplexitt der eingesetzten Produkte - sogar
vertiefte Kenntnisse erfordern. Daher sollten alle Mitarbeiter, die krypto-
graphische Verfahren und Produkte einsetzen sollen, fr den Nutzen und die
Notwendigkeit der kryptographischen Verfahren sensibilisiert werden und
eine Einfhrung in kryptographische Grundbegriffe erhalten. Dies gilt natr-
lich insbesondere fr diejenigen, die ein Kryptokonzept erstellen, Krypto-
produkte auswhlen, installieren oder betreuen sollen.
Der folgende Text soll ein elementares Verstndnis der grundlegenden
kryptographischen Mechanismen vermitteln. Nachfolgend wird an Beispielen
erlutert, in welcher Situation welche kryptographische Technik eingesetzt
werden kann.
Elemente der Kryptographie
Mathematische Methoden und Techniken, die zum Schutz von Information
gegen unbefugte Kenntnisnahme und/oder absichtliche Manipulation dienen
knnen, nennt man kryptographisch. Der Schutz der Information durch
kryptographische Methoden ist - im Unterschied zu infrastrukturellen und
technischen Sicherungsmanahmen - mathematisch-logischer Natur.
Bei kryptographischen Verfahren wird ein mathematischer Rechenvorgang
- ein Algorithmus - in konkrete Technik umgesetzt. Ihre Wirksamkeit beruht
darauf, dass ein potentieller Angreifer ein gewisses mathematisches Problem
nicht zu lsen vermag - und zwar nicht wegen mangelnder Fhigkeiten,
sondern wegen fehlenden Wissens um ganz bestimmte "Schlssel"-Infor-
mationen.
Kryptographische Methoden beziehen sich stets auf folgende Situation: Ein
Sender A (dieser wird, wie in der Kryptographie blich, "Alice" genannt)
schickt ber einen unsicheren Kanal eine Nachricht an einen Empfnger B (er
wird "Bob" genannt).
Sender und Empfnger drfen dabei auch identisch sein, unter einem Kanal ist
ein beliebiges Transportmedium zu verstehen. Bei der Verschlsselung lokaler
Daten sind Sender und Empfnger natrlich identisch, unter "Kanal" ist hier
das Speichermedium zu verstehen.
Kryptographische Grundziele
Auf Grund theoretischer und praktischer Erwgungen unterscheidet man vier
kryptographische Grundziele:
1. Vertraulichkeit/Geheimhaltung: Keine unbefugte dritte Partei E (sie sei
"Eve" genannt) soll an den Inhalt der Nachricht bzw. Datei gelangen.
2. Integritt: Unbefugte Manipulationen an der Nachricht bzw. Datei (z. B.
Einfgen, Weglassen, Ersetzung von Teilen) sollen entdeckt werden
knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
3. Authentizitt:
- Identittsnachweis (Authentisierung von Kommunikationspartnern):
Eine Kommunikationspartei (z. B. Person, Organisation, IT-System)
soll einer anderen ihre Identitt zweifelsfrei beweisen knnen.
- Herkunftsnachweis (Nachrichtenauthentisierung): A soll B beweisen
knnen, dass eine Nachricht von ihr stammt und nicht verndert
wurde.
4. Nichtabstreitbarkeit (Verbindlichkeit, non repudiation): Hier liegt der
Schwerpunkt verglichen mit der Nachrichtenauthentisierung auf der
Nachweisbarkeit gegenber Dritten.
- Nichtabstreitbarkeit der Herkunft: Es soll A unmglich sein, das
Absenden einer bestimmten Nachricht an B nachtrglich zu
bestreiten.
- Nichtabstreitbarkeit des Erhalts: Es soll B unmglich sein, den
Erhalt einer von A gesendeten Nachricht nachtrglich zu bestreiten.
Es ist klar, dass zwischen diesen Zielen Beziehungen bestehen, aber eine
wesentliche Einsicht der modernen Kryptographie ist folgende: Die Gewhr-
leistung von Vertraulichkeit bzw. von Authentizitt sind unabhngige
Grundziele eines kryptographischen Systems: Authentisierung beschrnkt den
Kreis der mglichen Sender einer Nachricht, Geheimhaltung den der mg-
lichen Empfnger.
Die grundlegende kryptographische Methode zur Wahrung von Vertraulich-
keit ist Verschlsselung, die grundlegenden Methoden zur Gewhrleistung
von Integritt, Authentizitt und Nichtabstreitbarkeit sind Hashfunktionen,
Message Authentication Codes (MACs), digitale Signaturen und krypto-
graphische Protokolle. Die einzelnen kryptographischen Konzepte werden
im folgenden kurz vorgestellt.
I. Verschlsselung
Verschlsselung (Chiffrieren) transformiert einen Klartext in Abhngigkeit
von einer Zusatzinformation, die "Schlssel" genannt wird, in einen zuge-
hrigen Geheimtext (Chiffrat), der fr diejenigen, die den Schlssel nicht
kennen, nicht entzifferbar sein soll. Die Umkehrtransformation - die Zurck-
gewinnung des Klartextes aus dem Geheimtext - wird Entschlsselung
genannt. In allen modernen Verschlsselungsalgorithmen sind Klartexte,
Geheimtexte und Schlssel jeweils als Folgen von Bits gegeben.
Um praktisch einsetzbar zu sein, mssen Verschlsselungsalgorithmen
folgende Mindestanforderungen erfllen:
- Sie sollten entzifferungsresistent sein, d. h. ohne Kenntnis des Schlssels
darf das Chiffrat nicht entschlsselt werden knnen, insbesondere muss
hierfr die Menge der mglichen Schlssel "ausreichend gro" sein, da
sonst ein einfaches Ausprobieren aller Schlssel mglich wre,
- sie mssen einfach einzusetzen sein, und
- Ver-/Entschlsselung mssen "schnell genug" sein.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Forderung nach Entzifferungsresistenz ist immer relativ zu den aktuellen

technischen und mathematischen Mglichkeiten zu betrachten. Wichtig bei
der Bewertung von Verschlsselungsalgorithmen ist, dass es zum Nutzungs-
zeitpunkt praktisch nicht mglich sein darf, das Chiffrat ohne Kenntnis des
Schlssels zu entschlsseln, d. h. nicht mit der dann verfgbaren Technik
innerhalb eines akzeptablen Zeitrahmens.
Wenn A und B eine vertrauliche Verbindung einrichten wollen, gehen sie wie
folgt vor:
1. sie vereinbaren ein Chiffrierverfahren,
2. sie vereinbaren einen Schlssel bzw. ein Schlsselpaar,
3. A verschlsselt eine Nachricht und sendet diese an B,
4. B entschlsselt das von A gesendete Chiffrat.
Es gibt zwei groe Klassen von Chiffrierverfahren:
Symmetrische Verschlsselungsverfahren benutzen denselben Schlssel
sowohl fr die Ver- als auch fr die Entschlsselung. Symmetrische Verfahren
werden deshalb gelegentlich auch als "ein-Schlssel"-Verfahren bezeichnet,
da die Kenntnis eines Schlssels ausreicht, um chiffrieren und dechiffrieren zu
knnen.
Bekannte symmetrische Verschlsselungsverfahren sind z. B. DES, Tripel-
DES, IDEA oder RC5.
Bei symmetrischen Verfahren unterscheidet man weiter zwischen Strom-
chiffren und Blockchiffren.
Bei Stromchiffren wird unter Verwendung des Schlssels eine mglichst
zufllig aussehende Bitfolge (ein Bitstrom) generiert, die auf die Klarbitfolge
(modulo 2) aufaddiert wird. Die Klarbitfolge wird also Bit fr Bit (durch
Addition von Schlsselstrombits) verschlsselt. Fr die Sicherheit von
Stromchiffren ist wesentlich, dass niemals zwei (verschiedene) Nachrichten
mit demselben Schlsselstrom verschlsselt werden - dafr muss mit spezi-
ellen Manahmen (Synchronisierinformation in Form eines Spruchschlssels)
gesorgt werden. Beispiele fr Stromchiffren sind RC4 und SEAL.
Bei Blockchiffren dagegen wird in einem Verschlsselungstakt jeweils ein

ganzer Block von Bits verschlsselt, heutzutage sind dies in der Regel 64 Bits.
Die meisten symmetrischen Verschlsselungsverfahren sind Blockchiffren,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
dazu gehren auch DES, IDEA oder RC5. Fr Blockchiffren sind eine Reihe
von Betriebsarten (Modi) definiert (und standardisiert). Es sind dies
- der ECB (Electronic Code Book)-Modus, bei dem jeder Block fr sich
- unabhngig von den anderen Blcken - verschlsselt wird,
- der CBC (Cipher Block Chaining)-Modus und der CFB (Cipher Feed
Back)-Modus, bei diesen Modi wird, nach Wahl eines zustzlichen Initia-
lisierungsvektors, eine Abhngigkeit der Chiffretextblcke von allen vor-
hergehenden Chiffretextblcken hergestellt, sowie
- der OFB (Output Feedback Modus), dieser Modus kann so aufgefasst
werden, dass die verwendete Blockchiffre zur Generierung eines
"Blockstroms" verwendet wird, der auf die Klarblcke bitweise (modulo 2)
aufaddiert wird.
Beim Einsatz symmetrischer Verfahren ist generell zu beachten, dass ein
Schlsselaustausch zwischen den Kommunikationspartnern vorausgegangen
sein muss. Dieser muss ber einen sicheren Kanal (z. B. Kurier, persnliche
bergabe) erfolgen und beide Parteien mssen anschlieend den Schlssel
geheim halten. Es gibt verschiedene Verfahren fr einen sicheren Schlssel-
austausch. In geschlossenen Systemen ist der Schlsselaustausch im allge-
meinen unproblematisch zu realisieren, da hier meist "sichere Kanle" vor-
handen sind. In offenen Systemen mit einer Vielzahl von Kommunikations-
partnern gestaltet sich dies schwieriger. Generell besteht jedoch das Problem,
dass bei einer Vielzahl mglicher Kommunikationspartner entsprechend viele
Schlssel vor der eigentlichen Kommunikation ausgetauscht werden mssen
und dass dabei die potentiellen Kommunikationspartner vorab bekannt sein
mssen.
Asymmetrische (Public Key) -Chiffrierverfahren dagegen benutzen zwei
verschiedene (aber mathematisch verwandte) Schlssel: einen "ffentlichen"
Schlssel (Public Key) fr die Verschlsselung, und einen "privaten" Schls-
sel (Private Key) fr die Entschlsselung. Das Schlsselpaar muss dabei fol-
gende Eigenschaft aufweisen: fr alle, die lediglich den "Public Key" kennen,
muss es praktisch unmglich sein, den zugehrigen "Private Key" zu bestim-
men oder eine mit dem "Public Key" verschlsselte Nachricht zu entschls-
seln.
Asymmetrische Verschlsselung hat also eine "Einbahn"-Eigenschaft: eine
Nachricht kann nicht wiederhergestellt werden, wenn der "Private Key"
vergessen oder gelscht wurde.
Die Bezeichnung "Public Key"-Verschlsselung rhrt daher, dass der "Public
Key" ffentlich bekannt gemacht werden kann, ohne die Sicherheit des Ver-
fahrens zu kompromittieren. Der "Private Key" hingegen muss geheim gehal-
ten werden.
Will nun Alice eine Nachricht verschlsselt an Bob senden, so holt sich Alice
den ffentlichen Schlssel Bobs aus einer frei zugnglichen Datei und ver-
schlsselt damit die Nachricht. Nach Erhalt der Nachricht benutzt Bob seinen
geheimen Schlssel, um die von Alice erhaltene Nachricht zu entschlsseln.
Wenn Alice und Bob ein asymmetrisches Verfahren zum Zweck der Vertrau-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
lichkeit verwenden, bentigen sie also keinen sicheren Kanal fr den Schls-
selaustausch, aber Alice muss sicher sein, dass sie tatschlich Bobs ffent-
lichen Schlssel benutzt und keinen Schlssel, der ihr als Bobs Schlssel
untergeschoben wurde. Wrde Alice eine Nachricht mit einem unterge-
schobenen Schlssel verschlsseln, so knnte der Tter, dem ja der passende
geheime Schlssel bekannt ist, die Nachricht entschlsseln. Der Sender ben-
tigt in der Regel die Besttigung einer vertrauenswrdigen dritten Partei, dass
der ffentliche Schlssel des Empfngers wirklich zu diesem gehrt. Diese
Besttigung, das "Zertifikat", wird im allgemeinen auch durch ein krypto-
graphisches Verfahren erzeugt und dem ffentlichen Schlssel beigefgt.
Zwei bekannte asymmetrische Verschlsselungsverfahren sind das RSA-
Verfahren (benannt nach den Erfindern Rivest, Shamir, Adleman) und die
Klasse der Elgamal-Verfahren. Zu letzteren gehren auch die auf Elliptischen
Kurven basierenden Verschlsselungsverfahren.
Symmetrische und asymmetrische Chiffrierverfahren haben z. T. sich ergn-
zende Vor- und Nachteile:
Vorteile (guter) symmetrischer Verfahren:
- Sie sind schnell, d. h. sie haben einen hohen Datendurchsatz.
- Die Sicherheit ist im wesentlichen durch die Schlssellnge festgelegt,
d. h. bei guten symmetrischen Verfahren sollte es keine Attacken geben,
die wesentlich besser sind als das Durchprobieren aller Schlssel (Brute-
Force-Attacken).
- Sie bieten hohe Sicherheit bei relativ kurzem Schlssel.
- Die Schlsselerzeugung ist einfach, da gewhnlich als Schlssel jede Bit-
folge einer festen Lnge erlaubt ist und als Schlssel eine Zufallszahl
gewhlt werden kann.
Nachteile symmetrischer Verfahren:
- Jeder Teilnehmer muss smtliche Schlssel seiner Kommunikationspartner
geheim halten.
- Zur Schlsselverteilung sind sie weniger gut geeignet als asymmetrische
Verfahren, insbesondere bei einer groen Anzahl von Kommunikations-
partnern.
- Fr Verbindlichkeitszwecke sind sie weniger praktikabel als asymme-
trische Verfahren, da bei der Verwendung symmetrischer Schlssel nicht
ohne weiteres erkannt werden kann, welcher der beiden Kommunikations-
partner die Nachricht verschlsselt hat. Dies lsst sich nur durch eine
zwischengeschaltete dritte Partei sicherstellen, die ber entsprechende
kryptographische Protokolle in den Nachrichtenfluss eingebunden wird.
Vorteile (guter) asymmetrischer Verfahren:
- Jeder Teilnehmer einer vertraulichen Kommunikation muss nur seinen
eigenen privaten Schlssel geheim halten.
- Sie lassen sich einfach fr digitale Signaturen benutzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sie bieten elegante Lsungen fr die Schlsselverteilung in Netzen, da die

ffentlichen Schlssel bzw. Schlsselzertifikate frei zugnglich auf zentra-
len Servern gespeichert werden knnen, ohne die Sicherheit des Verfahrens
zu beeintrchtigen.
- Sie sind gut geeignet fr Nicht-Abstreitbarkeitszwecke.
Nachteile asymmetrischer Verfahren:
- Sie sind langsam, d. h. sie haben im allgemeinen einen geringen Daten-
durchsatz.
- Sicherheit: fr alle bekannten Public-Key-Verfahren gilt:
- Es gibt wesentlich bessere Attacken als das Durchprobieren aller
Schlssel, deshalb werden (im Vergleich zu symmetrischen Verfah-
ren) relativ lange Schlssel bentigt, um ein gleich hohes Ma an
Sicherheit zu erreichen.
- Die Sicherheit beruht "nur" auf der vermuteten, aber von der Fach-
welt anerkannten, algorithmischen Schwierigkeit eines mathema-
tischen Problems (zum Beispiel die Zerlegung einer groen Zahl in
die Primfaktoren).
- Die Schlsselerzeugung ist i. allg. komplex und aufwendig, da die Erzeu-
gung "schwacher" Schlsselpaare vermieden werden muss.
Hybride Verfahren versuchen, die Vorteile beider Arten von Verschlsse-
lung zu kombinieren: sie benutzen asymmetrische Verschlsselung, um einen
Sitzungsschlssel ("Sessionkey") fr ein symmetrisches Verfahren zu ber-
mitteln, und verschlsseln die Massendaten mit dem symmetrischen Verfah-
ren. Der Sessionkey wird gewhnlich nur fr eine Sitzung (bertragung)
verwendet und dann vernichtet. Das asymmetrische Schlsselpaar wird je
nach Umstnden fr einen langen Zeitraum verwendet.
II. Integrittsschutz
Das Ziel des Integrittsschutzes ist es, dass ein Empfnger einer Nachricht
feststellen kann, ob er diese Nachricht unverflscht erhalten hat. Das Grund-
prinzip des Integrittsschutzes besteht darin, die Nachricht unverschlsselt
und unverndert zu bersenden, gleichzeitig aber bestimmte Kontroll-
informationen mitzuschicken, die die Kontrolle auf Unverflschtheit der
eigentlichen Nachricht ermglichen. Voraussetzung dazu ist allerdings, dass
der Empfnger die Kontrolldaten unmanipuliert erhlt. Fr diese Kontroll-
daten stellen sich damit folgende Bedingungen:
- Der Umfang der Kontrollinformationen muss mglichst gering sein, um die
zustzlich zu bertragenden Informationen zu minimieren.
- Praktisch jede Manipulation, auch nur eines einzelnen Bits der Nachricht
muss anhand der Kontrollinformationen feststellbar sein.
- Die Kontrollinformationen mssen unmanipulierbar bertragen bzw.
Manipulationen mssen entdeckt werden knnen.
Zur Berechnung der Kontrollinformationen werden typischerweise zwei Ver-
fahren verwendet: Hashfunktionen und Message Authentication Codes.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Eine (Einweg-)Hashfunktion ist eine Datentransformation mit folgenden

Eigenschaften:
- Kompressionseigenschaft: Beliebig lange Bitfolgen werden auf Bitfolgen
fester, i. allg. krzerer Lnge abgebildet (typischerweise 128 - 160 Bit).
- "Einweg"-Eigenschaft: Es muss "praktisch unmglich" sein, zu einem vor-
gegebenen Hashwert eine Nachricht zu finden, deren Hashwert der vorge-
gebene Hashwert ist.
- Kollisionswiderstand: Es muss "praktisch unmglich" sein, zwei Nachrich-
ten zu finden, die zum gleichen Hashwert fhren.
Mit Hilfe einer beiden Kommunikationspartnern bekannten Hashfunktion
knnen A und B die Integritt einer Nachricht berprfen: Alice hasht ihre
Nachricht, und bermittelt diese und den Hashwert so an Bob, dass die Unver-
flschtheit des Hashwertes gewhrleistet ist. Bob hasht die empfangene
Nachricht ebenfalls und vergleicht sein Ergebnis mit dem von Alice geliefer-
ten Hashwert. Stimmen beide Werte berein, so kann er davon ausgehen, dass
kein Bit der Nachricht verndert wurde.
Ein Message Authentication Code (MAC) ist eine kryptographische
Checksumme zur Nachrichtensicherung, also eine Datentransformation, bei
der zustzlich ein geheimer Schlssel in die Berechnung eingeht, mit folgen-
den Eigenschaften:
- Kompressionseigenschaft: Beliebig lange Bitfolgen werden auf Bitfolgen
fester, i. allg. krzerer Lnge abgebildet.
- Flschungssicherheit: Fr jeden, der nicht im Besitz des Schlssels ist,
muss es "praktisch unmglich" sein, den MAC-Wert einer neuen Nachricht
zu berechnen, selbst wenn er in den Besitz einiger alter Nachrichten mit
den zugehrigen MAC-Werten gelangt ist.
Besitzen Alice und Bob einen MAC und einen gemeinsamen, geheimen
MAC-Schlssel, so authentisiert Alice ihre Nachricht einfach dadurch, dass
sie den MAC-Wert der Nachricht berechnet und zusammen mit der Nachricht
an Bob schickt. Bob berechnet seinerseits den MAC-Wert der empfangenen
Nachricht mit dem auch ihm bekannten MAC-Schlssel. Stimmt dieser mit
Alices Wert berein, so kann er davon ausgehen, dass die Nachricht authen-
tisch ist (d. h. dass sie nicht verndert wurde und wirklich von Alice stammt).
Alice hat also ihre Nachricht durch Verwendung des nur ihr und Bob bekann-
ten Schlssels gegenber Bob authentisiert.
MACs werden hufig auf Basis symmetrischer Chiffrierverfahren konstruiert.
Die bekannteste Variante ist hierbei die Verschlsselung einer Nachricht mit
DES oder einem anderem Block-Chiffrierverfahren im CBC- oder CFB-
Mode. Dabei wird als MAC der letzte verschlsselte Block an die Nachricht
angehngt. Daneben gibt es aber auch MACs, die nicht auf Chiffrierverfahren
beruhen. Der MAC-Wert einer Nachricht kann als flschungssichere,
schlsselabhngige, kryptographische Checksumme dieser Nachricht ange-
sehen werden. Die Anwendung von MACs zum Zweck der Authentisierung
erfordert, dass beide Parteien den geheimen Authentisierungsschlssel zuver-
lssig schtzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Als Nebeneffekt des Integrittsschutzes kann mit oben skizzierten Verfahren

gleichzeitig vom Empfnger der Nachricht nachgeprft werden, dass die als
unmanipuliert verifizierte Nachricht nur vom tatschlich bekannten Sender
verschickt werden konnte. Dieser Schluss lsst sich ziehen, da nur dieser
Sender die notwendigen Schlssel zur Verschlsselung bzw. Ermittlung der
Kontrollinformationen besitzt.
III. Authentizittsnachweise
Bei der Authentisierung von Benutzern gegenber Kommunikations-
partnern/IT-Systemen bzw. Clients gegenber Servern sollen
- illegitime Zugriffe erkannt und abgewehrt werden,
- legitime Zugriffe erlaubt werden und
- sensible Daten auch bei bertragungen ber Netze geschtzt bleiben.
Dazu sind Verfahren erforderlich, die allen Beteiligten die Feststellung der
Identitt ihrer Kommunikationspartner unmiverstndlich erlauben. Dies
schliet einen Zeitaspekt ein: Alice will Bob in "real time" davon berzeugen,
dass tatschlich sie mit ihm kommuniziert. Die Haupttechniken fr solche
Authentisierungen sind kryptographische Challenge-Response-Protokolle.
Hierbei sendet Bob Daten an Alice und fordert sie auf (Challenge), ihm den
Besitz eines Geheimnisses (also einer Schlsselinformation) nachzuweisen,
und Alice demonstriert ihm diesen Besitz ohne das Geheimnis selbst preis-
zugeben, indem sie eine vom Geheimnis und seiner Challenge abhngige
Antwort sendet (Response). Bob wiederum berprft anhand der Antwort,
dass zur Berechnung der Antwort wirklich das korrekte Geheimnis verwendet
wurde.
Fr eine "starke" Authentisierung drfen sich die Challenges nicht wieder-
holen. Bei Challenge-Response-Verfahren knnen sowohl symmetrische als
auch asymmetrische Techniken verwendet werden.
Beispiel: Alice und Bob verstndigen sich vorab auf ein symmetrisches Ver-
schlsselungsverfahren und einen gemeinsamen kryptographischen Schlssel.
Zur Authentisierung sendet Bob eine Zufallszahl als Challenge an Alice. Alice
wiederum verschlsselt diese Zufallszahl mit dem gemeinsamen geheimen
Schlssel und sendet das Ergebnis zurck an Bob. Im nchsten Schritt
entschlsselt Bob die Nachricht und vergleicht, ob das Ergebnis seine anfangs
gewhlte Zufallszahl ist. Bei Gleichheit ist es tatschlich Alice, da nur sie den
geheimen Schlssel kennt.
IV. Digitale Signatur
Das kryptographische Konstrukt einer digitalen Signatur dient dem Ziel, fr
digitale Dateien und Nachrichten ein Pendant zur handschriftlichen Unter-
schrift einsetzen zu knnen. Dazu werden einige der schon erluterten
kryptographischen Verfahren wie Hashfunktionen und asymmetrische Ver-
fahren zusammengefhrt. Die wesentliche Voraussetzung fr digitale Signa-
turen ist, dass jeder Teilnehmer ein nur ihm bekanntes Geheimnis besitzt, mit
dem er zu beliebigen Dateien eine digitale Signatur bilden kann. Anhand von
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ffentlichen Informationen muss es dann mglich sein, diese digitale Signatur

zu berprfen.
In diesem Sinne ist eine digitale Signatur ein spezieller Integrittsschutz mit
zustzlichen Besonderheiten. Eine digitale Signatur ist eine Kontrollinfor-
mation, die an eine Nachricht oder Datei angehngt wird, mit der folgende
Eigenschaften verbunden sind:
- Anhand einer digitalen Signatur kann eindeutig festgestellt werden, wer
diese erzeugt hat, und
- es ist authentisch berprfbar, ob die Datei, an die die digitale Signatur
angehngt wurde, identisch ist mit der Datei, die tatschlich signiert wurde.
Kann also anhand der ffentlich zugnglichen Informationen die digitale
Signatur verifiziert werden, so ist einerseits die Integritt der signierten Datei
gegeben und andererseits die Nichtabstreitbarkeit, da nur die Person, der die
digitale Signatur eindeutig zugeordnet werden kann, diese Signatur anhand
ihrer geheimen Informationen gebildet haben kann. Zu beachten ist, dass
unterschiedliche Dateien auch unterschiedliche digitale Signaturen zur Folge
haben und das geringste nderungen an den Dateien zu nicht verifizierbaren
Signaturen fhren.
Beispiel: Ein weit verbreitetes Verfahren fr digitale Signaturen ist die umge-
kehrte Anwendung des RSA-Verfahrens. Dabei besitzt jeder Teilnehmer einen
nur ihm bekannten geheimen Signierschlssel. ffentlich zugnglich sind
Verifizierschlssel-Zertifikate, in denen der passende ffentliche Schlssel
und die Angaben zum Besitzer des passenden geheimen Signierschlssels
unflschbar miteinander verknpft sind. Diese Zertifikate werden von ver-
trauenswrdigen Stellen herausgegeben, die zuvor die Personalien der Teil-
nehmer geprft haben.
Um fr eine beliebige Datei eine digitale Signatur zu berechnen und zu prfen,
wird nun wie folgt vorgegangen:
1. Schritt: Alice berechnet den Hashwert der ausgewhlten Datei.
2. Schritt: Alice verschlsselt diesen Hashwert mit dem nur ihr bekannten
geheimen Signierschlssel. Das Ergebnis ist die digitale Signatur von Alice
zu dieser Datei.
3. Schritt: Alice bertrgt die digitale Signatur gemeinsam mit dem Verifi-
zierschlssel-Zertifikat und der Datei an Bob.
4. Schritt: Bob verifiziert das Zertifikat (z. B. mit dem ffentlichen Schlssel
einer Zertifizierungsstelle).
5. Schritt: Bob berechnet den Hashwert der erhaltenen Datei.
6. Schritt: Anhand des im Verifizierschlssel-Zertifikat enthaltenen ffent-
lichen Verifizierschlssels entschlsselt Bob die digitale Signatur.
7. Schritt: Bob vergleicht den in Schritt 4 berechneten Hashwert und die
entschlsselte Signatur. Sind sie identisch, so ist die digitale
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Signatur verifiziert. Besteht keine Gleichheit, kann Bob keine weiteren

Schlsse ziehen.
8. Schritt: Nach der Verifikation der digitalen Signatur kann Bob als
Ergebnisse festhalten:
- Falls sichergestellt ist, dass tatschlich nur Alice den geheimen
Schlssel besitzt, kann Bob sicher sein, dass die digitale Signatur
von Alice, die im Verifizierschlssel-Zertifikat aufgefhrt ist,
erzeugt wurde.
- Die erhaltene Datei ist identisch mit der Datei, fr die Alice die
digitale Signatur berechnet hat.
Betont sei, dass digitale Signaturen ausschlielich die Ziele Integritt und
Nichtabstreitbarkeit sicherstellen, jedoch in keiner Weise die Vertraulichkeit.
Eine digital signierte Nachricht wird im Klartext bertragen, ist sie ver-
traulich, muss sie zustzlich verschlsselt werden.
Enthlt eine digital signierte Datei eine Willenserklrung des Signierers, kann
dann anhand der Signatur diese Willenserklrung unabstreitbar dem Signierer,
ggf. auch vor Gericht, zugerechnet werden.
Die verwendeten Verifizierschlssel-Zertifikate wiederum sind selbst von der
vertrauenswrdigen Stelle digital signierte Dateien, die analog berprft wer-
den knnen und die Auskunft geben ber den Verifizierschlssel und die Per-
son, die den dazu passenden geheimen Signierschlssel besitzt.
Man beachte die Unterschiede zwischen MACs und digitalen Signaturen:
- Die digitale Signatur kann durch jeden, der das Verifizierschlssel-Zertifi-
kat besitzt, verifiziert werden, MACs dagegen nur durch die Parteien, die
den geheimen Authentisierungsschlssel kennen.
- Alices digitale Signatur einer Nachricht kann nur von Alice erstellt werden,
der MAC-Wert einer Nachricht dagegen von beiden Parteien, Alice und
Bob (und allen anderen, die den geheimen Authentisierungsschlssel
kennen). Es ist deshalb unmglich, MACs fr den Zweck der
Verbindlichkeit einzusetzen.
Mit Artikel 3 des Informations- und Kommunikationsdienste-Gesetzes
(Bundesgesetzblatt 1879, Teil 1, 1997) ist fr die Bundesrepublik Deutschland
ein Gesetz zur digitalen Signatur in Kraft getreten. Dieses regelt, welche
Sicherheitsanforderungen die technischen Komponenten, die fr digitale
Signaturen eingesetzt werden, erfllen mssen und welche Aufgaben Zerti-
fizierungsstellen, die Verifizierschlssel-Zertifikate ausstellen, haben. Darber
hinaus wird geregelt, wie die erforderliche Sicherheit der Komponenten und
Zertifizierungsstellen geprft wird. Im Ergebnis wird digitalen Signaturen
nach dem Signaturgesetz auch vor Gericht eine hohe Sicherheit zugebilligt.
Schlsselmanagement
Bei jedem Einsatz von Verschlsselung entsteht die Aufgabe, die Schlssel
angemessen zu verwalten. Es stellt sich die Frage, wie man
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Erzeugung/Initialisierung,
- Vereinbarung/Etablierung,
- Verteilung/Transport,
- Wechsel/Update,
- Speicherung,
- Beglaubigung/Zertifizierung,
- Rckruf,
- Wiedergewinnung im Fall von Vernichtung/Verlust,
- Vernichtung/Lschen,
- Archivierung und
- Escrow (treuhnderische Hinterlegung)
whrend des gesamten Lebenszyklus der Schlssel durchfhrt. Das Schls-
selmanagement kann und wird sich gewhnlich auch kryptographischer
Techniken bedienen. Es muss fr die Gesamtheit der Kryptomodule eines
kryptographisch basierten Sicherungssystems durchgefhrt werden. Geheime
Schlssel mssen vor unbefugter Aufdeckung, Modifizierung und Ersetzung
geschtzt werden. ffentliche Schlssel mssen vor unbefugter Modifizierung
und Ersetzung geschtzt werden. Angemessenes Schlsselmanagement ist die
Voraussetzung dafr, dass Information durch kryptographische Methoden
berhaupt geschtzt werden kann. Schlsselmanagement bentigt eigens
dieser Aufgabe gewidmete Ressourcen!
Zertifizierungsstellen
Trust Center bzw. Zertifizierungsstellen werden immer dann bentigt, wenn
man fr eine nicht mehr berschaubare Anzahl von Teilnehmern asymme-
trische Kryptoverfahren fr die digitale Signatur oder fr Verschlsselung
einsetzen will. Solche Verfahren bentigen bei der Signaturbildung bzw. der
Verschlsselung einen anderen Schlssel als bei der Signaturprfung bzw. der
Entschlsselung. Dazu wird benutzerbezogen ein Schlsselpaar korrespon-
dierender Schlssel erzeugt. Ein Schlssel, der so genannte ffentliche Schls-
sel, wird ffentlich bekanntgegeben. Der andere Schlssel, der so genannte
private Schlssel, ist absolut geheim zu halten. Mit dem privaten Schlssel
- und nur mit diesem - kann eine digitale Signatur erzeugt bzw. ein Text
entschlsselt und mit dem zugehrigen ffentlichen Schlssel - und nur mit
diesem - verifiziert bzw. verschlsselt werden. Will man nun die Echtheit der
ffentlichen Schlssel und die sichere Zuordnung der Schlssel zu Personen
sicherstellen, bedarf es der bereits erwhnten Trust Center / Zertifizierungs-
stellen, die die Zuordnung einer Person zu einem ffentlichen Schlssel durch
ein Zertifikat besttigen.
Innerhalb solcher Zertifizierungsstellen werden typischerweise folgende Auf-
gaben wahrgenommen:
- Schlsselgenerierung: Es sind fr die Zertifizierungsstelle und ggf. fr
Teilnehmer Schlsselpaare zu generieren.
- Schlsselzertifizierung: Die Teilnehmerdaten, der korrespondierende
ffentliche Schlssel und weitere Daten werden zu einem Zertifikat
zusammengefasst und von der Zertifizierungsstelle digital signiert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Personalisierung: Das Zertifikat und ggf. ffentlicher und privater Schls-

sel werden auf eine Signaturkomponente (i. a. eine Chipkarte) bertragen.
- Identifizierung und Registrierung: Die Teilnehmer werden gegen Vorlage
eines Ausweispapieres identifiziert und registriert.
- Verzeichnisdienst: Zertifikate werden in einem ffentlichen Verzeichnis
abrufbar gehalten. Darber hinaus muss der Verzeichnisdienst Auskunft
darber geben, ob ein Zertifikat gesperrt ist oder nicht.
- Zeitstempeldienst: Fr bestimmte Daten kann es notwendig sein, diese mit
einem vertrauenswrdigen Zeitpunkt zu verknpfen. Dazu wird der Zeit-
punkt an die Daten angehngt und das Ergebnis vom Zeitstempeldienst
digital signiert.
Trust Center knnen auerdem zustzlich Schlsselaufbewahrung als Dienst-
leistung anbieten, wenn die kryptographischen Schlssel fr Verschlsselung
eingesetzt werden sollen. Um bei Schlsselverlust noch auf die verschlssel-
ten Daten zugreifen zu knnen, kann dann der Schlsselbesitzer (und nur
dieser) eine Schlsseldublette erhalten, die im Trust Center geschtzt aufbe-
wahrt wird.
Schlsselverteilungszentralen
Die Sicherheit symmetrischer Verschlsselungsverfahren hngt davon ab, ob
der gemeinsam benutzte geheime Schlssel nur den zum Zugriff auf die
geschtzten Informationen berechtigten Benutzern bekannt ist. Im Falle des
Schutzes gespeicherter Daten, auf die nur deren Eigentmer Zugriff haben
soll, ist dies relativ einfach zu gewhrleisten, da dieser Eigentmer lediglich
den Schlssel so schtzen muss, dass Unbefugte nicht darauf zugreifen
knnen.
Anders sieht es jedoch aus, wenn Nachrichten, die von einem Sender ber ein
unsicheres bertragungsmedium an einen Empfnger zu bermitteln sind, mit
einem symmetrischen Verschlsselungsverfahren geschtzt werden sollen. In
diesem Fall muss der geheime Schlssel sowohl beim Sender als auch beim
Empfnger vorliegen, d. h. es muss eine Mglichkeit geschtzten Informa-
tionsaustauschs zwischen den beiden Partnern verfgbar sein. In der Praxis
wird dies oft durch die verschlsselte Verteilung von Kommunikations-
schlsseln durch so genannte Schlsselverteilungszentralen (Key Distribution
Centers, KDCs) realisiert, wobei ganze Hierarchien voneinander sicher-
heitstechnisch abhngiger Schlssel aufgebaut werden. Die hier zum Einsatz
kommenden Verfahren sind teilweise sehr komplex und hngen hinsichtlich
ihrer Sicherheit von einer Vielzahl von Komponenten ab, insbesondere von
der physischen, organisatorischen, personellen und technischen Sicherheit der
KDCs und der zur Kommunikation mit den KDCs vereinbarten Schlssel.
Eine Kompromittierung eines geheimen Schlssels, d. h. sein Bekanntwerden
gegenber einem unberechtigten Dritten, fhrt zum Verlust der Vertraulichkeit
aller Daten, deren Verschlsselung mit diesem Schlssel erfolgte bzw. davon
abhngt. Dies ist insbesondere dann kritisch, wenn einer der zentralen
Schlssel einer Schlsselverteilungshierarchie kompromittiert wurde.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Einsatz kryptographischer Verfahren

Bei sachgemem Einsatz sind kryptographische Verfahren hervorragend
geeignet, folgende Bedrohungen abzuwehren:
- Kenntnisnahme von Informationen durch Unbefugte,
- bewusste Manipulation von Daten durch Unbefugte und
- Manipulationen an der Urheberschaft von Informationen.
Der alleinige Einsatz von Kryptographie reicht allerdings nicht aus, um alle
Bedrohungen abzuwehren.
- Der Einsatz kryptographischer Methoden trgt nichts dazu bei, um die
Verfgbarkeit von Daten zu gewhrleisten (bei unsachgemem Gebrauch
von Verschlsselung droht sogar Datenverlust!).
- Kryptographische Methoden knnen gegen Denial-of-Service-Attacken
(siehe auch G 5.28 Verhinderung von Diensten) nichts ausrichten. Sie
knnen aber zur frhzeitigen Erkennung solcher Attacken beitragen.
- Sie helfen auch nicht gegen zufllige Verflschungen von Informationen
(etwa durch "Rauschen"). Sie knnen Verflschungen aber nachtrglich
erkennbar machen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.24 Schulung zur Lotus Notes Systemarchitektur fr

Administratoren
Um ein Lotus Notes-System korrekt und sicher administrieren zu knnen, ist
die Schulung der verantwortlichen Administratoren unumgnglich. Schon
kleine Konfigurationsfehler knnen dazu fhren, dass Sicherheitslcken ent-
stehen. Beispiele hierfr sind das unkontrollierte Anlegen von Cross-Zertifi-
katen und falsche Zugriffslisten (ACLs) fr Datenbanken. Aus diesem Grund
mssen Administratoren ber die Systemarchitektur von Lotus Notes und
insbesondere ber die Sicherheitsmechanismen informiert werden.
Bild 1 zeigt (vereinfacht) die allgemeine Architektur, der ein Client-Server-
Modell zugrunde liegt. Auf dem sogenannten Notes-Server werden Daten-
banken gehalten, die durch die Lotus Domino-Server-Software zum Zugriff
ber Netz angeboten werden. Der Zugriff auf die Datenbanken durch den
Benutzer kann durch zwei Client-Programme erfolgen:
1. Durch den originren Notes-Client, der von Lotus Notes als Client-Soft- Zugriff via Lotus Notes
Client-Software
ware bereitgestellt wird. Der Zugriff erfolgt hier ber das proprietre
Notes-Protokoll. Der Notes-Client leitet Bearbeitungsanfragen an den
Domino-Server weiter, der die Verarbeitung im Auftrag des Clients auf
den Datenbanken durchfhrt.
2. Durch einen Browser (Web-Client). Seit der Notes Version 4.6 ist es auch Zugriff via Browser
mglich, mit einem normalen Browser auf die Datenbanken eines Domino-
Servers zuzugreifen. Dazu wurde ein spezielles Web-Server-Modul bereit-
gestellt, das als HTTP-Server fungiert. Die Inhalte der Datenbanken
werden beim Zugriff dynamisch durch die sogenannte HTML-Engine in
das HTML-Format umgewandelt, damit eine Anzeige im Browser mglich
ist. Als Transportprotokoll kommt das Hyper Text Transfer Protocol
(HTTP) zum Einsatz.
Eine lokale Speicherung von Datenbanken (Repliken) ist, im Unterschied
zum Notes-Client, mit dem Web-Client nicht mglich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bild 1: berblick ber die Lotus Notes Architektur

Die Zugriffskontrollen eines Notes-Servers sind zweistufig ausgelegt (siehe zweistufige
Zugriffskontrolle
Bild 2) und basieren auf der Benutzerauthentisierung durch die Notes-ID oder
durch die Web-Authentisierungsmechanismen "Benutzername und Passwort"
oder "SSL-Zertifikat". Ist ein Benutzer authentisiert, so wird beim Zugriff auf
eine Datenbank eines Servers zunchst geprft, ob der Benutzer generell auf
den Server zugreifen darf. Ist dies erlaubt, so wird in einer zweiten Stufe
geprft, ob der Benutzer die angeforderte Operation auf der jeweiligen
Datenbank durchfhren darf.
Bild 2: Authentisierung und Zugriffskontrollen bei Lotus Notes

Der Zugriff auf einen Server kann auf verschiedene Arten eingeschrnkt
werden (siehe M 4.119 Einrichten von Zugangsbeschrnkungen auf Lotus
Notes Server). hnliches gilt fr die mglichen Zugriffsbeschrnkungen auf
Datenbanken (siehe M 4.120 Konfiguration von Zugriffslisten auf Lotus Notes
Datenbanken). Problematisch kann dabei sein, wenn die Zugriffsbe-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
schrnkungen auf Datenbanken so konfiguriert werden, dass sie eine

bestimmte Zugriffsbeschrnkung auf die Server voraussetzen. Werden die
Zugriffbeschrnkungen auf die Server verndert, knnen leicht Fehlkonfigu-
rationen entstehen (siehe Beispiel unten).
Die Schulung der Administratoren sollte folgende Aspekte bercksichtigen
und mindestens folgende Themen umfassen:
- Welche Mglichkeiten bietet die Zugriffskontrolle auf Server?
- Welche Mglichkeiten bietet die Zugriffskontrollen auf Datenbanken?
- Anhand welcher Kriterien und in welcher Reihenfolge entscheidet Lotus
Notes, ob einem Benutzer den Zugriff auf Inhalte in einer Datenbank
gestattet wird?
- Wie funktioniert die Benutzerauthentisierung?
- Wie funktioniert die Authentisierung mittels asymmetrischer krypto-
graphischer Verfahren?
- Welche Mechanismen fr Verschlsselung und digitale Signatur gibt es
und wie ist der Zusammenhang mit symmetrischen und asymmetrischen
kryptographischen Verfahren?
- Wie werden Zertifikate fr kryptographische Schlssel erzeugt, verteilt,
verwaltet und genutzt?
- Mit welchen Verfahren kann die Client-Server-Kommunikation (Notes-
Client, Web-Client) geschtzt werden?
- Wie kann eine hohe Verfgbarkeit von Notes Systemen erreicht werden?
- Wie ist eine effiziente Datensicherung fr Notes-Clients und -Server zu
gestalten?
Die angegebene Themenliste stellt nur eine Auswahl der wichtigsten Themen
dar, die an den Anwendungsfall angepasst und erweitert werden mssen.
Beispiel:
Im folgenden wird kurz dargestellt, welche Mechanismen bei der Zugriffs-
kontrolle beim Datenbankzugriff via HTTP ohne SSL ablaufen. Dieser
Prozess sollte den Administratoren erlutert werden, um ein Grundverstndnis
fr die Funktionsweise der Zugriffskontrolle zu vermitteln.
- Ein Benutzer versucht eine zugriffsbeschrnkte Operation auf einer Daten-
bank.
- Der Server berprft, ob der anonyme Zugriff auf den Server fr das
HTTP-Protokoll erlaubt ist.
- Ist der anonyme Zugriff erlaubt, so finden folgende berprfungen statt:
- Der Server sucht nach einem Eintrag "Anonymous" in der Daten-
bank-ACL. Existiert dieser, so erhlt der Benutzer anonymen Zugriff
mit den entsprechenden Rechten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist kein Eintrag fr "Anonymous" vorhanden, berprft der Server

den "-Default-"-Eintrag.
- Erlaubt der "-Default-"-Eintrag mindestens "Leser (Reader)"-Rechte,
so erhlt der Benutzer anonymen Zugriff mit den "Default"
-Rechten.
- Ist der anonyme Zugriff auf den Server nicht erlaubt und ist die Authenti-
sierung ber Benutzername und Passwort aktiviert, so fordert der Server
ber den Browser diese Authentisierungsdaten an.
- Der Server berprft, ob fr den angegebenen Benutzer ein Personen-
dokument im NAB (Namens- und Adressbuch) existiert und kontrolliert
anhand der dort angegebenen Informationen die Eingaben des Benutzers
(Benutzername und Internet-Passwort).
- Stimmen die Authentisierungsinformationen berein, so wird der erste
Eintrag im Benutzernamen-Feld des Personendokumentes benutzt, um den
Benutzer zu identifizieren und diesem entsprechende Zugriffsrechte ber
die Datenbank-ACL zuzuordnen.
Auch wenn eine Rollentrennung zwischen der Administration des Lotus Notes
Systems und des zugrundeliegenden Betriebssystems in Kraft ist, sollte den
Lotus Notes Administratoren Grundlagenwissen zum Betriebssystem
vermittelt werden. Anderenfalls wird eine Zusammenarbeit bei der Problem-
lsung erschwert.
- Sind die Administratoren auf den Umgang mit den Notes-System vorberei-
tet und insbesondere in sicherheitsrelevanten Aspekten geschult?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.25 Schulung zu Lotus Notes

Sicherheitsmechanismen fr Benutzer
Lotus Notes ist ein komplexes System, bei dem es wie bei allen komplexen komplexes System
Systemen bei fehlerhafter Nutzung oder Fehlkonfiguration unbeabsichtigt zu
Sicherheitslcken kommen kann. Dies gilt in besonderem Mae, wenn
Benutzer ohne entsprechende Schulung mit einem Notes-System umgehen.
Zwar wird die Systemkonfiguration in der Regel so eingestellt, dass diese nur
in Grenzen durch die Benutzer verndert werden kann, jedoch kann auch
Unkenntnis ber die einem Benutzer zur Verfgung stehenden Sicherheits-
mechanismen und -einstellungen dazu fhren, dass das System unsicher
genutzt wird.
Daher sollten alle Benutzer im Umgang mit Lotus Notes geschult werden. Umgang mit Notes
Datenbanken
Neben der reinen Nutzung der Client-Software ist es jedoch auch notwendig,
die Funktionsweise der Datenbanken, mit denen ein Benutzer voraussichtlich
arbeiten wird, zu erlutern und die Benutzer im Umgang mit der Datenbank zu
schulen. Dies ist erforderlich, da Notes Datenbanken viele Funktionen
anbieten knnen, so dass sie mehr als einen reinen Datenspeicher darstellen
(daher auch die Bezeichnung "Notes-Applikationen" fr Datenbanken).
Den Benutzern mssen insbesondere die ihnen zur Verfgung stehenden Sicherheits-
mechanismen
Sicherheitsmechanismen deutlich gemacht werden, so dass sie in der Lage
sind, diese korrekt und sinnvoll einzusetzen. Eine Schulung sollte u. a.
folgende Themen behandeln:
- berblick ber Zugriffskontrollmechanismen auf einem Server
- berblick ber Zugriffskontrollmechanismen auf Datenbanken
- Detaillierte Darstellung der Nutzung von Zugriffslisten auf Datenbanken
(Access Control List, ACL)
- Sicherer Umgang mit der Notes-ID und Nutzung der Inhalte einer
Notes-ID
- Authentisierung an der Web-Schnittstelle und deren Schwchen und
Strken
- Einstellen von Zugriffsbeschrnkungen beim Web-Zugriff auf Daten-
banken
- berblick ber die Funktionsweise von symmetrischen und
asymmetrischen kryptographischen Verfahren
- Umgang mit kryptographischen Zertifikaten (Anerkennen von Zertifikaten,
Bedeutung von Cross-Zertifikaten)
- Sicherer Umgang mit Internet-Zertifikaten
- Erzwingen der Kommunikationsabsicherung durch Portverschlsselung
und SSL-Nutzung
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Beschrnkungen fr die Ausfhrung aktiver Inhalte im Notes-Client

(Execution Control List, ECL)
- Nutzen der Verschlsselungsverfahren fr Datenbanken (Datenbank- und
Feldverschlsselung)
- Nutzen der E-Mail-Verschlsselung und Zweck von E-Mail-Signaturen
(Notes-Client und Browser)
- Sicherheitsunterschiede beim Zugriff mit dem Notes-Client und mit dem
Browser
Diese Themenliste muss anhand des vorliegenden Anwendungsfalls ggf. Kenntnis ber
Sicherheitsrichtlinien
angepasst und erweitert werden. Neben der reinen Schulung zu den Notes-
Sicherheitsmechanismen mssen die Benutzer jedoch auch Kenntnis ber die
Sicherheitsrichtlinien ihrer Organisation besitzen, damit diese bei der Nutzung
der Sicherheitsmechanismen auch entsprechend umgesetzt werden knnen
(siehe M 2.207 Festlegen einer Sicherheitsrichtlinie fr Lotus Notes).
- Sind die Benutzer mit den Notes-Sicherheitsmechanismen vertraut und
werden diese auch angewandt?
- Sind alle Benutzer mit den Inhalten der organisationseigenen Sicherheits-
richtlinie fr Lotus Notes vertraut?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.26 Einweisung des Personals in den sicheren

Umgang mit IT
Verantwortlich fr Initiierung: Leiter Personal, Leiter IT, IT-
Viele IT-Sicherheitsprobleme entstehen durch fehlerhafte Nutzung bzw. Kon-
figuration der IT. Um solchen Problemen vorzubeugen, sollten alle Mitarbei-
ter in den sicheren Umgang mit der IT eingewiesen werden. Hierzu sollten alle
Mitarbeiter entsprechend geschult werden (siehe auch M 3.4 Schulung vor
Programmnutzung, M 3.5 Schulung zu IT-Sicherheitsmanahmen und
M 2.198 Sensibilisierung der Mitarbeiter fr IT-Sicherheit).
Den IT-Benutzern sollten spezifische Richtlinien an die Hand gegeben wer- Benutzerrichtlinien
den, was sie im Umgang mit der IT beachten mssen. In einer solchen Richtli-
nie sollte verbindlich vorgeschrieben werden, welche Randbedingungen beim
Einsatz der betrachteten IT-Systeme einzuhalten und welche IT-Sicherheits-
manahmen zu ergreifen sind. Dabei sind die Benutzer klar und unmissver-
stndlich darauf hinzuweisen, was sie auf keinen Fall machen drfen. Diese
Richtlinien sollten verbindlich, verstndlich und verfgbar sein. Um die Ver-
bindlichkeit zu dokumentieren, sollten sie von der Behrden- bzw. Unterneh-
mensleitung oder zumindest vom IT-Verantwortlichen unterzeichnet sein. Sie
sollten kurz und verstndlich gehalten sein, so dass sie beispielsweise als
Merkzettel aufgehngt werden knnen. Zustzlich sollten sie im Intranet ab-
rufbar sein.
Benutzerrichtlinien sollten grundstzlich nur Regelungen enthalten, die auch Positiv formulieren!
umgesetzt werden knnen. Benutzerrichtlinien sollten so positiv wie mglich
formuliert werden. Beispielsweise knnte eine Benutzerrichtlinie statt:
Benutzer drfen keine Software selbstndig aufspielen.
folgenden Eintrag enthalten:
Alle IT-Systeme werden in einer Standardkonfiguration ausgeliefert, die
auf Ihre spezifischen Arbeitsbedingungen angepasst wurde und Ihnen ma-
ximale Sicherheit bietet. Bei Problemfllen knnen wir Ihnen durch eine
Neuinstallation der Standardkonfiguration eine schnelle Problemlsung ga-
rantieren. Bitte verndern Sie daher die Einstellungen mglichst nicht.
Wenn Sie zustzliche Hard- oder Software bentigen, wenden Sie sich
bitte an den Benutzerservice.
Beispiele fr Benutzerrichtlinien finden sich bei den Hilfsmitteln im Anhang.
Eine Benutzerrichtlinie fr die allgemeine IT-Nutzung sollte mindestens die
folgenden Punkte umfassen:
- Hinweis, dass keine IT-Systeme oder IT-Komponenten ohne aus-
drckliche Erlaubnis benutzt werden drfen
- Hinweis, dass nur diejenigen Mitarbeiter Informationen auf
IT-Systemen ndern drfen, die dazu autorisiert sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Umgang mit Passwrtern (siehe M 2.11 Regelung des Passwort-

gebrauchs)
- Nutzungsverbot nicht freigegebener Software (siehe M 2.9)
- Hinweis, dass dienstliche IT-Systeme nur fr dienstliche Zwecke
eingesetzt werden drfen
- Hinweise zur sicheren Verwahrung und Aufstellung von IT-Syste-
men und Datentrgern
- Schutz vor Computer-Viren
- Durchfhrung von Datensicherungen
- Nutzung von Internet-Diensten
Neben solchen Richtlinien mssen klare Aussagen darber vorliegen, welche
Benutzer auf welche Informationen zugreifen drfen, an wen diese weiter-
gegeben werden drfen und welche Manahmen bei einem Versto gegen
diese Richtlinien unternommen werden.
Bei Verlassen des Arbeitsplatzes sollte sich jeder Benutzer davon berzeugen, Auch bei kurzer Abwe-
senheit Arbeitsmittel
dass jedes Arbeitsmittel (Dokumente, Datentrger, etc.) sicher verwahrt ist schtzen
(siehe auch M 2.37 Der aufgerumte Arbeitsplatz). Alle IT-Systeme sollten
durch Passwrter gegen unbefugten Zugriff geschtzt sein. Bei unbeaufsich-
tigten IT-Systeme sollten alle offenen Sitzungen beendet worden sein oder
zumindest ein Bildschirmschoner aktiviert sein.
Die Grundkonfiguration aller IT-Systeme sollte mglichst eingeschrnkt sein.
In der Standardkonfiguration von Arbeitsplatzrechnern sollten nur die Dienste
vorhanden sein, die von allen Benutzern einer Gruppe bentigt werden (siehe
auch M 4.109 Software-Reinstallation bei Arbeitsplatzrechnern). Weitere
Programme oder Funktionalitten sollten nur dann aufgespielt bzw. freige-
schaltet werden, wenn die Benutzer in deren Handhabung eingewiesen und fr
eventuelle Sicherheitsprobleme sensibilisiert wurden.
Jede Benutzerordnung sollte in Zusammenarbeit mit Vertretern aller betei-
ligten Gruppen erstellt werden, insbesondere sollten Betriebs- bzw. Personal-
rat und Datenschutz- sowie IT-Sicherheitsbeauftragte rechtzeitig beteiligt
werden. Bei jeder nderung einer Benutzerordnung ist darauf zu achten, dass
diese wieder im Vorfeld beteiligt werden. Die genderte Benutzerordnung
muss allen Benutzern bekannt gegeben werden.
Die Aufgabenbeschreibung sollte alle fr die IT-Sicherheit relevanten Aufga- Sicherheitsaufgaben
gehren in Aufgaben-
ben und Verpflichtungen enthalten. Dazu gehrt u. a. die Verpflichtung auf beschreibung
die hausinternen IT-Sicherheitsleitlinien (siehe auch M 2.198 Sensibilisierung
der Mitarbeiter fr IT-Sicherheit).
Werden IT-Systeme oder Dienste in einer Weise genutzt, die den Interessen
der Behrde bzw. des Unternehmens widersprechen, sollte jeder, der davon
Kenntnis erhlt, dies seinen Vorgesetzten mitteilen. Gegebenfalls sind diszi-
plinarische Manahmen einzuleiten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.27 Schulung zur Active Directory-Verwaltung

Das Active Directory ist die zentrale Datenbank von Windows 2000, in der
Benutzerdaten, Gruppenzugehrigkeiten und andere Verwaltungsdaten
abgelegt werden.
Fr die Administration eines Windows 2000 Netzes werden detaillierte
Kenntnisse des Active Directory und seiner grundlegenden Konzepte bentigt.
Ansonsten kann es leicht zu Fehlkonfigurationen kommen, die erhebliche
sicherheitstechnische Auswirkungen haben knnen. Eine Schulung der
Administratoren auf diesem Gebiet ist daher unerlsslich.
Im Folgenden wird in kurzen Stichpunkten zusammengefasst, welche
Fachkenntnisse mindestens zur sicheren Administration des Active Directory
notwendig sind. Um diese Stichpunkte auch begrifflich besser einordnen zu
knnen, wird zunchst ein kurzer Abriss des Active Directory, seiner
Strukturen und Komponenten dargestellt.
Active Directory - Abriss
Das Active Directory Konzept von Windows 2000 greift weiter als das Integritt verschiedener
Domnen
Domnen-Konzept von Windows NT, da das Active Directory eine
Integration verschiedener Domnen in ein Gesamtverzeichnis erlaubt. Das
folgende Bild zeigt die mgliche Gesamtstruktur eines Windows 2000 Netzes:
Abb. 1: Gesamtstruktur eines Windows 2000 Netzes

Zwischen all diesen Domnen bestehen direkte (einzelne Pfeile) bzw. Vertrauensbeziehungen
indirekte (ber mehrere Pfeile hinweg) Kerberos-Vertrauensbeziehungen, so
dass die Authentisierung eines Benutzers oder Computers ber jeden Domain
Controller des Forests vorgenommen werden kann. Windows 2000 nutzt zur
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Namensauflsung von Rechnern das DNS (Domain Name Service) Verfahren

des Internets, so dass jede Domne ber einen eindeutigen Namen im DNS-
Format verfgen muss. Die Domnen sind dabei entsprechend ihrer Namen in
einer Baumstruktur angeordnet. Eventuell sind in einem Windows 2000 Netz
(Forest) mehrere solcher Bume zusammengefasst. Die Gliederung eines
Windows 2000 Netzes in Bume hat Auswirkungen auf die technische
Realisierung der Netzfunktionalitt, jedoch keine unmittelbaren
Auswirkungen fr die Rechtevergabe und Delegation von administrativen
Ttigkeiten. Hinweise zur Strukturierung eines Windows 2000 Netzes finden
sich in M 2.229 Planung des Active Directory.
Die Administration von Windows 2000 erfolgt im Wesentlichen innerhalb der Forest Root Domne
einzelnen Domnen. bergreifende Bedeutung fr das Active Directory hat
dabei nur die so genannte Forest Root Domne. Das ist die erste Domne, die
in einem Windows 2000 Netz installiert wird. Der Administrator dieser Forest
Root Domne ist in der Windows 2000 Voreinstellung das einzige Mitglied
der beiden Gruppen Schema-Admins und Organisations-Admins.
Mitglieder der Gruppe Schema-Admins knnen die Struktur der Active Schema-Admins
Directory Datenbank, das so genannte Schema ndern. Durch das Schema
wird bestimmt, aus welchen Objekten das Active Directory aufgebaut werden
kann (Definition von Objekttypen), wie die Objekte selbst aufgebaut sind
(Definition von Objektattributen) und wie die Objekte im Active Directory
angeordnet werden knnen (Definition der Struktur). Schemanderungen sind
immer ein weitreichender Eingriff in ein Windows 2000 Netz, da sie immer
alle Domnen des Forests betreffen. Auerdem knnen bestimmte
nderungen im Active Directory nicht mehr rckgngig gemacht werden.
Die Mitglieder der Gruppe Organisations-Admins, zu der in der Organisations-Admins
Voreinstellung der Administrator der Forest Root Domne gehrt, haben
besondere Befugnisse in allen Domnen des Netzes. Sie knnen z. B. neue
Domnen in den Forest aufnehmen und haben Administratorrechte auf allen
Domnen Controllern des Netzes.
Innerhalb einer einzelnen Domne erfolgt die Administration durch Mitglieder Domnen-Admins
der jeweiligen (domnen-spezifischen) Gruppe Domnen-Admins. Diese
Gruppe verfgt innerhalb einer Domne ber unbeschrnkte administrative
Berechtigungen. Es ist jedoch mglich, einzelne administrative Aufgaben
auch fr andere Benutzerkonten zu ermglichen und so administrative
Aufgaben zu delegieren (siehe auch M 2.230 Planung der Active Directory-
Administration).
Eine Delegation administrativer Aufgaben innerhalb einer Domne kann auch
so erfolgen, dass lediglich die Administration eines Teils der Benutzerkonten
und Computer einer Domne delegiert wird. Dies ist innerhalb der Grenzen
der so genannten OUs (Organizational Units) mglich, die zur Gruppierung
von Benutzer- bzw. Computerkonten innerhalb der Domne dienen.
Eine Vielzahl von Windows 2000 Konfigurationsparametern ist in den Gruppenrichtlinien
Gruppenrichtlinien zusammengefasst. Neben den lokalen Gruppenrichtlinien
auf jedem einzelnen Windows 2000 Rechner gibt es auch Gruppenrichtlinien,
die im Active Directory gespeichert sind. Dies gestattet es, Rechner oder
Benutzerkonten zentral zu konfigurieren. Wirkungsbereich einer solchen, im
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
AD gespeicherten Gruppenrichtlinie, knnen u. a. ganze Domnen oder OUs

sein. Hier dienen OUs zur Gruppierung gleichartig konfigurierter Rechner
oder Benutzerkonten. Da sich OUs schachteln lassen und mit einer einzelnen
OU mehrere Gruppenrichtlinien verbunden sein knnen, wirken auf einen
einzelnen Rechner u. U. viele verschiedene Gruppenrichtlinien ein (siehe auch
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000,).
Technisch gesehen ist das Active Directory als eine verteilte Datenbank verteilte Datenbank
realisiert, die auf den Domnen-Controllern des Windows 2000 Netzes
angesiedelt ist. Mit einigen Ausnahmen enthlt jeder Domnen-Controller
dabei nur die Daten seiner eigenen Domne. Diese Ausnahmen sind:
- Jeder Domnen-Controller enthlt die Schema- und Konfigurationsdaten
des gesamten Forests.
- Mindestens ein Domnen-Controller jeder Domne enthlt zustzlich noch
den Global Catalog.
Der Global Catalog enthlt die komplette Baumstruktur des Active Directory Global Catalog
des gesamten Forests, fr jedes der Objekte in diesem Baum enthlt der
Global Catalog allerdings nur bestimmte Attribute.
Im Unterschied zu Windows NT lassen sich die meisten nderungen an jedem
Domnen-Controller einer Domne durchfhren. Um die Eindeutigkeit
bestimmter kritischer Datenstze zu bewahren, gibt es allerdings
- zwei ausgezeichnete Aufgaben fr Domnen-Controller innerhalb des
Forests (Schema Master und Domain Naming Master) und
- drei ausgezeichnete Aufgaben fr Domnen-Controller innerhalb einer
jeden Domne (PDC Emulator, RID Master, Infrastructure Master).
Diese Rollen werden in der Windows 2000 Terminologie auch als FSMO- Flexible Single Master
Operations
Rollen (FSMO = Flexible Single Master Operations) bezeichnet. Bestimmte
nderungen knnen daher nur an dem Rechner vorgenommen werden, dem
die jeweilige Rolle zugeordnet ist.
Der Abgleich der Daten zwischen den einzelnen Domnen-Controllern kann
ber zwei verschiedene Replikationsmechanismen erfolgen. Welcher
Mechanismus verwendet wird, lsst sich ebenso konfigurieren wie die
Zeitabstnde, in denen die Replikation erfolgt.
Durch das Konzept der verteilten Datenbank kann eine gewisse
Ausfallsicherheit des Active Directory erreicht werden, problematisch sind
dabei jedoch die Inhaber der FSMO-Rollen.
Schulungsinhalte
Die Administration eines Windows 2000 Netzes wird im Allgemeinen, je nach Grundwissen
Gre und Komplexitt des Netzes, nicht von einem einzelnen Administrator,
sondern von einer ganzen Reihe von Administratoren mit speziellen Aufgaben
und Ttigkeitsbereichen durchgefhrt. Insoweit besteht auch nicht fr alle
Administratoren eines Windows 2000 Netzes der gleiche Schulungsbedarf.
Zur Gewhrleistung eines sicheren Betriebes muss jedoch jeder Administrator
ber ein hinreichendes Grundwissen verfgen, um seine eigenen Ttigkeiten
in einen Gesamtkontext einordnen zu knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schulungsinhalte sollten in jedem Fall die folgenden Stichpunkte umfassen

und diese erlutern. Wie tief ein Administrator sich mit den einzelnen Punkten
beschftigen muss, hngt von seinem spteren Ttigkeitsfeld ab.
Grundlagen
- berblick ber die Sicherheitsmechanismen von Windows 2000
- Sicherheitsverwaltung (MMC, Security Editor)
- Active Directory und DNS
- Vertrauensbeziehungen zwischen Domnen
- Notwendiger physikalischer Schutz aller Domnen-Controller als Trger
der Kerberos Daten
Active Directory
- Allgemeines: Planung, Einrichtung, Administration
- Schema-Verwaltung
- Replikation
- Backup
- Rechtevergabe
- Authentisierung
- Gruppenrichtlinien
PKI (Public Key Infrastruktur)
- Funktionsweise einer PKI
- Zertifikate und Zertifikatstypen
- Planung einer PKI
- Einrichten einer PKI
- Verwalten einer PKI
- Benutzerinteraktion mit der PKI
EFS (Encrypting File System)
- Funktionsweise des EFS
- Konfiguration des EFS (Recovery-Agent, Zertifikate)
- Schlsselbackup
- Schutz verschlsselt gespeicherter Dateien bei der Netzkommunikation
IPSec
- Funktionsweise des IPSec
- Konfiguration des IPSec
- Umgang mit ipsecmon.exe oder einem IPSec-Monitor eines Drittherstellers
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
WFP
- Funktionsweise der WFP
- Konfigurationsmglichkeiten der WFP
DFS (Distributed File Service)
- Funktionsweise des DFS
- Administration des DFS
- Planung der DFS-Struktur
- Schutz der ber DFS zugreifbaren Daten
Die einzelnen Active Directory Themen sollten dabei wie folgt detaillierter
dargestellt werden:
Schema-Verwaltung
Im Normalfall ist eine installationsspezifische Vernderung des AD-Schemas
durch einen Administrator nicht notwendig. Die Schulung kann sich insofern
auf die Problematik und Auswirkungen von Schema-Vernderungen
beschrnken.
Sollen individuelle Anpassungen des Schemas vorgenommen werden, sind
weitergehende Schulungen zu Interna des Active Directory notwendig.
Replikation des Active Directory
- Verwendete Mechanismen zur Replikation des Active Directory (RPC und
SMTP)
- Voreingestellte Parameter zur Replikation von Active Directory Inhalten
- Problematik der dezentralen Administration des AD im Zusammenhang
mit Replikationskonflikten
Backup
- Problematik des Erstellens eines "Backups des Active Directory"
- Wiedereinspielen von Backups eines Domnen-Controllers
- Zu ergreifenden Manahmen bei Ausfall von Domnen-Controllern, die
FSMO-Rollen innehaben
Rechtevergabe im Active Directory
- Vergabe von Zugriffsrechten auf AD-Objekte auf Attributsebene
- Vererbung von Zugriffsrechten und Blockade der Vererbung
- Mgliche Zugriffsrechte
- Delegation von administrativen Aufgaben auf der Ebene einzelner OUs
Authentisierung
- Kerberos
- PKI
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Smart Cards
Gruppenrichtlinien
- Lokale Gruppenrichtlinien und im Active Directory gespeicherte Gruppen-
richtlinien
- Konfigurationsmglichkeiten mit Hilfe von Gruppenrichtlinien
- Wann werden Gruppenrichtlinien angewandt? Wie lsst sich dies konfi-
gurieren?
- Gruppenrichtlinienobjekte (GPOs) sind Objekte im Active Directory
- Gruppenrichtlinienobjekte knnen an Standorte / Domnen / OUs gebun-
den werden
- Reihenfolge, in der Gruppenrichtlinien abgearbeitet werden
- Mglichkeiten, die Anwendung von Gruppenrichtlinien zu kontrollieren
- Vergabe von Zugriffsrechten auf Gruppenrichtlinien
- No Override Eigenschaft der Bindung eines Gruppenrichtlinien-
objektes an ein AD-Objekt
- Block Policy Inheritance Eigenschaft von AD-Objekten
- Wurden alle Administratoren fr die Arbeit mit Windows 2000 geschult?
- Ist der Umgang mit allen relevanten Sicherheitsmechanismen dargestellt
worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.28 Schulung zu Windows 2000

Sicherheitsmechanismen fr Benutzer
Verantwortlich fr Umsetzung: Vorgesetzte, Leiter IT
Die Sicherheit der auf Windows 2000 Rechnern gespeicherten Daten hngt zu
einem groen Teil auch vom korrekten Umgang der Benutzer mit den
Windows 2000 Sicherheitsmechanismen ab. Um diese effektiv nutzen zu
knnen, sollten Benutzer von Windows 2000 Rechnern entsprechend geschult
werden.
Benutzersicht auf Sicherheitsmechanismen
Beim Umgang mit Windows 2000 Rechnern kann ein groer Teil der sicher-
heitsrelevanten Einstellungen dem Benutzer durch entsprechende Vorarbeiten
und Voreinstellungen des Administrators abgenommen werden. Um einheit-
liche und berprfbare Rechnerkonfigurationen zu erhalten, ist ein solches
Vorgehen unabdingbar.
Einige sicherheitsrelevante Einstellungen knnen allerdings vom Benutzer Zugriffsrechte auf eigene
Dateien und
selbst vorgenommen werden. Dazu gehren die Zugriffsrechte auf die eigenen Verzeichnisse
Dateien und Verzeichnisse eines Benutzers. Die Zugriffsrechte darauf knnen
einzelnen Benutzern oder Benutzergruppen eingerumt bzw. verweigert
werden. Widersprechen sich die fr einen Benutzer konfigurierten Zugriffs-
rechte (z. B. weil der Benutzer Mitglied der beiden Gruppen A und B ist,
wobei der Zugriff fr Gruppe A zugelassen ist, whrend er fr Gruppe B
verweigert wird), so wird der Zugriff verweigert. Generell gilt zunchst auch
hier, dass die Zugriffsrechte auf die eigenen Dateien eines Benutzers vom
Administrator voreingestellt und automatisch auf neue Dateien und Ordner
bertragen werden. Da der Benutzer jedoch in der Regel die Mglichkeit
besitzt, die Zugriffsrechte zu verndern, ist es notwendig, dass jeder Benutzer
entsprechend geschult wird (siehe dazu auch M 4.149 Datei- und
Freigabeberechtigungen unter Windows 2000).
Ein weiterer Punkt, auf den eine Benutzerschulung eingehen muss, ist die Encrypting File System
Verwendung des verschlsselnden Dateisystems EFS (Encrypting File
System). Neben der Vermeidung von Fallstricken bei der Benutzung des EFS
sollte hier vor allem vermittelt werden, in welchem Ausma EFS die Vertrau-
lichkeit von Dateien schtzen kann, und wo dieser Schutz aufhrt (siehe auch
M 4.147 Sichere Nutzung von EFS unter Windows 2000).
Schulungsinhalte
Die folgenden Stichpunkte fassen notwendige Schulungsinhalte fr den siche-
ren Umgang von Benutzern mit Windows 2000 zusammen:
Verwendung von Zugriffsrechten im NTFS Dateisystem
- Schutz von Dateien durch Zugriffsrechte
- Vererbung von Zugriffsrechten
- Kopieren und Verschieben von Dateien
- bergabe einer Datei an einen neuen Besitzer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sensibilisierung fr Beschrnkungen des Schutzes von Dateien durch

Zugriffsrechte
- Benutzer mit administrativen Rechten knnen Zugriffsrechte
umgehen.
- Bei direktem Zugriff auf die Hardware (z. B. nach Diebstahl) lassen
sich Zugriffsrechte umgehen.
- Dateien sind beim Transport ber das Netz nicht geschtzt.
Benutzung von EFS (siehe auch M 4.147 Sichere Nutzung von EFS unter
Windows 200)
- Nutzen von EFS (EFS bietet einen zustzlichen Schutz der Vertraulichkeit
von Dateien)
- Bedienung von EFS
- Problematik des "nachtrglichen Verschlsselns"
- Geeignete Passwort-Auswahl (Passwortqualitt ist wesentlich fr die
Effektivitt von EFS)
- Verwendung eines zustzlichen Startpasswortes mittels SYSKEY (wesent-
lich bei Verwendung lokaler Benutzerkonten)
- Sensibilisierung fr Beschrnkungen des Schutzes durch EFS
- Benutzer mit administrativen Rechten knnen die Verschlsselung
umgehen.
- Verschlsselt gespeicherte Dateien sind beim Transport ber das
Netz nicht geschtzt.
Sonstige Sicherheitshinweise
- Sicheres Lschen von Dateien (siehe auch M 4.56 Sicheres Lschen unter
Windows-Betriebssystemen, die analog auch auf Windows 2000 zutrifft)
- Sicherheitshinweise zum automatischen Erkennen von CD-ROMs bzw. zur
Autostart-Funktion (siehe auch M 4.57 Deaktivieren der automatischen
CD-ROM-Erkennung)
- Wurde eine Benutzerschulung zur Windows 2000 Sicherheit durchgefhrt?
- Sind die Benutzer in die Vergabe von Zugriffsrechten auf eigene Dateien
eingewiesen worden?
- Wurden die Benutzer auf die Sicherheitsmechanismen der verwendeten
Werkzeuge hingewiesen und in deren Nutzung geschult?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.29 Schulung zur Administration von Novell

eDirectory
Fr die Administration eines eDirectory-Verzeichnisdienstes werden detail-
lierte Kenntnisse ber dieses Produkt und seine grundlegenden Konzepte
bentigt. Sind diese Kenntnisse nicht vorhanden, kann es leicht zu Fehlkon-
figurationen kommen, die erhebliche sicherheitstechnische Auswirkungen
haben knnen. Eine Schulung von Administratoren auf diesem Gebiet ist
daher unerlsslich.
Im Folgenden wird kurz zusammengefasst, welche Themen bei der Schulung
der Administratoren behandelt werden sollten.
Der eDirectory-Verzeichnisdienst ist baumartig hierarchisch strukturiert. Die hierarchische Struktur
einzelnen Knotenpunkte des Verzeichnisbaums bestehen aus den Container-
Objekten, die wiederum andere Objekte enthalten knnen, und den so
genannten Leaf-Objekten, welche die Endpunkte (Bltter) des Verzeichnis-
baums darstellen. Jedes Objekt gehrt einer eindeutigen Objektklasse an. Die
Objektklasse definiert die Werte bzw. Attribute oder auch Eigenschaften,
welche einem Objekt dieser Objektklasse zugewiesen werden knnen. Zudem
werden hierarchische Relationen darin definiert, d. h. was potentielle Vater-
und Kindobjekte sein knnen. Es gibt dafr bereits eine Anzahl seitens
eDirectory vordefinierter Objektklassen. Die Definitionen der Objektklassen
werden im so genannten Schema festgehalten. Werden Vernderungen an der
Definition einzelner Objektklassen vorgenommen, z. B. eine Erweiterung des
zugehrigen Attributsatzes, so geschieht dies ber eine nderung bzw.
Erweiterung des Schemas. Eine Schemanderung ist gewissermaen die
sensibelste Operation berhaupt, die an einem eDirectory-Verzeichnisbaum
vorgenommen werden kann. Diese hat Auswirkungen auf den gesamten
Baum, so dass die bisherige Konzeption des Baums neu berdacht werden
muss. Die Administration des eDirectory-Schemas verlangt daher eine hohe
Kompetenz im Verzeichnisdienst und ein sehr hohes Sicherheitsbewusstsein.
Jedem einzelnen Objekt und jeder Objektklasse knnen Zugriffsrechte auf die Zugriffsrechte und
Vererbung
einzelnen Attribute des Objektes erteilt werden. Die explizite Zuweisung
erfolgt dabei ber die Trustee-Beziehungen, d. h. Eintragung von Trustees in
die Access Control List (ACL). Die Rechte reichen dabei von Supervisor, d. h.
einem vollstndigen Administrationsrecht, bis hin zum Browsen, was das
Durchlaufen des entsprechenden Verzeichnisbaum-Abschnittes gestattet. Die
Zugriffsrechte auf die Objekte vererben sich dabei standardmig in der
Baumhierarchie von oben nach unten. Es ist jedoch mglich, Einfluss auf den
Vererbungsprozess zu nehmen, in dem so genannte Inherited Rights Filter
(IRF) eingefhrt werden. Mit diesen Filtern knnen automatische Vererbun-
gen explizit ausgeblendet werden. Weiterhin besteht die Mglichkeit, so
genannte Sicherheitsquivalenzen zwischen einzelnen Objekten bzw. Objekt-
klassen X und Y zu definieren. Dabei werden smtliche Trustees von Objekt
X automatisch auch zu Trustees von Objekt Y, d. h. das Objekt Y besitzt
zumindest die gleichen Zugriffsmglichkeiten wie Objekt X.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schlielich kommen beim eDirectory-Zugriff dann die effektiven Rechte zum effektive Rechte
tragen, welche die Folge der oben genannten Rechtevergabe darstellen und bei
jedem einzelnen Zugriff dynamisch berechnet werden.
Im Intranet greifen die Benutzer ber geeignete Clientsoftware auf das Authentisierung
eDirectory zu. Der Zugriff der Clients auf das eDirectory erfolgt dabei ber
ein proprietres Protokoll, bei dem der private Schlssel des sich anmeldenden
Benutzers vom eDirectory verschlsselt an den Client geschickt wird. Bei
dieser Verschlsselung ist das Benutzerpasswort involviert. Gibt der Benutzer
nun sein Passwort ein, so kann der Client den privaten Schlssel entschls-
seln, und zwischen dem Client und dem eDirectory-Server findet ein
Challenge-/Response-Verfahren zur Authentisierung statt. Bei erfolgreicher
Authentisierung besitzt der Benutzer nun die fr ihn definierten Zugriffsrechte
auf das eDirectory.
Netzapplikationen und Internet-Benutzer greifen in der Regel ber das LDAP- LDAP-Zugriff
Protokoll auf den eDirectory-Verzeichnisdienst zu. Hierbei gibt es standard-
mig drei verschiedene Anbindungsarten: den anonymous bind, den proxy
user anonymous bind sowie den NDS-user bind. Die Voreinstellung ist, dass
der anonyme Login dabei die Rechte des [Public] Objektes hat, welches stan-
dardmig das uneingeschrnkte Browse-Recht auf den gesamten Verzeich-
nisbaum besitzt. Der anonyme Login setzt keine Authentisierung voraus. Fr
die Passwort-Authentisierung kann konfiguriert werden, ob dabei das Pass-
wort im Klartext bertragen werden darf oder nicht. Fr eine gesicherte
Anbindung ber LDAP steht das SSL-Protokoll zur Verfgung, und zwar
wahlweise mit ein- oder zweiseitiger Authentisierung.
Der eDirectory-Zertifikatsserver spielt eine wichtige Rolle fr die Rechtever- Zertifikatsserver
gabe und damit fr die Systemsicherheit. Ebenso hngen die Authentisierun-
gen im Netz sowie der Aufbau eines verschlsselten Kanals (via SSL) vom
Zertifikatsmanagement ab. Die sorgfltige Administration des eDirectory-
Zertifikatsservers ist daher besonders wichtig.
Der eDirectory-Verzeichnisdienst erlaubt zur Verbesserung der Skalierbarkeit Partitionierung
und Performance eine Partitionierung der Verzeichnisdatenbank auf mehrere
Server. Fr die Partitionierung eines Verzeichnisbaums sind dabei eine Reihe
von Regeln zu beachten, siehe dazu M 2.237 Planung der Partitionierung und
Replikation im Novell eDirectory
Wie die Vorgngerprodukte untersttzt der eDirectory-Verzeichnisdienst Replikation
Repliken zur Erhhung der Fehlertoleranz und des Systemdurchsatzes. Dabei
gibt es mehrere Typen von Repliken, nmlich Master Replica, Read/Write
Replica, Read-Only Replica, Filtered Read/Write Replica, Filtered Read-Only
Replica sowie Subordinate Reference Replica. Detaillierte Hinweise hierzu
finden sich in M 2.237 Planung der Partitionierung und Replikation im Novell
eDirectory
eDirectory untersttzt die rollenbasierte Administration sowie die Delegation rollenbasierte
Administration und
von Administrationsaufgaben. Entsprechend den bei der Planung getroffenen Delegation
Entscheidungen (siehe M 2.236 Planung des Einsatzes von Novell eDirectory
sowie M 2.238 Festlegung einer Sicherheitsrichtlinie fr Novell eDirectory)
mssen die verschiedenen Administratoren fr ihre jeweilige Aufgabe
geschult werden. Dies gilt besonders fr die Gruppe der Schema-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
administratoren, die in der Lage sind, das gesamte Datenbankdesign des

Verzeichnisbaums zu verndern (siehe oben).
Auch die Administration der eDirectory-Clientsoftware und des LDAP- Clientsoftware
Zugriffs setzt detaillierte Kenntnisse ber die Konfigurationsmglichkeiten
des Systems voraus. Dabei spielt auch das zugrunde liegende Betriebssystem
eine Rolle fr die Definition einer Sicherheitsumgebung, insbesondere der
Dateisystemsicherheit.
Weiterhin mssen auch die fr das Logging und Monitoring zustndigen
Administratoren genauestens in ihre Ttigkeit eingewiesen werden.
Schulungsinhalte
Die Administration eines eDirectory-Verzeichnisbaums wird im Allgemeinen, Grundwissen
je nach Gre des Netzes, nicht von einem einzelnen Administrator, sondern
von einer ganzen Reihe von Administratoren mit speziellen Aufgaben und
Ttigkeitsbereichen durchgefhrt. Insoweit besteht auch nicht fr alle
Administratoren eines eDirectory-Verzeichnisses der gleiche Schulungs-
bedarf. Zur Gewhrleistung eines sicheren Betriebes muss jedoch jeder Admi-
nistrator ber ein hinreichendes Grundwissen verfgen, damit er seine eigenen
Ttigkeiten in einen Gesamtkontext einordnen kann.
Schulungsinhalte sollten in jedem Fall die folgenden Stichpunkte umfassen
und diese erlutern. Wie tief sich ein Administrator mit den einzelnen Aspek-
ten beschftigen muss, hngt von seinem spteren Ttigkeitsfeld ab.
Grundlagen
- berblick ber die Sicherheitsmechanismen von eDirectory
- Sicherheitsverwaltung (ConsoleOne, iMonitor)
- Baumstruktur und Namensauflsung
- Vererbung innerhalb des Verzeichnisbaums
- notwendiger physikalischer Schutz aller eDirectory-Server inklusive
Replica
Verzeichnisdienst
- Allgemeines: Planung, Einrichtung, Administration
- Schema-Verwaltung
- Partitionierung
- Replikation
- Backup
- Rechtevergabe
- Rechtevererbung und Kalkulation der effektiven Rechte
- Authentisierung
Public Key Infrastruktur (PKI)
- Funktionsweise einer PKI
- Zertifikate und Zertifikatstypen
- Planung einer PKI
- Benutzerinteraktion mit der PKI
- eDirectory-Key Management Objects
- Administration des eDirectory-Zertifikatsservers
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Secure Sockets Layer (SSL)

- Funktionsweise des SSL-Protokolls
- Konfiguration von SSL
Lightweight Directory Access Protocol (LDAP)
- LDAP-Zugriff auf das eDirectory
- mgliche Anbindungen der Benutzer
Novell Client
- Funktionsweise des Novell Clients
- Authentisierung des Novell Clients
Die einzelnen Themen sollten dabei wie folgt detaillierter dargestellt werden:
Schema-Verwaltung
Oftmals ist eine installationsspezifische Vernderung des eDirectory-Schemas
durch einen Administrator nicht notwendig. Die Schulung kann sich insofern
auf die Problematik und die Auswirkungen von Schema-Vernderungen
beschrnken. Sollen individuelle Anpassungen des Schemas vorgenommen
werden, sind weitergehende Schulungen zu Interna von eDirectory notwendig.
Replikation
- Verwendete Mechanismen zur Replikation
- Voreingestellte Parameter zur Replikation von eDirectory-Inhalten
- Problematik der dezentralen Administration des eDirectory im Zusammen-
hang mit Replikationskonflikten
Backup
- Problematik des Erstellens eines "Backups des eDirectory"
- Wiedereinspielen von Backups eines eDirectory-Servers
- zu ergreifende Manahmen beim Ausfall von eDirectory-Servern, die die
Baumstruktur definieren (d. h. die erste eDirectory-Installation innerhalb
eines Verzeichnisbaums)
Rechtevergabe im eDirectory
- Vergabe von Zugriffsrechten auf eDirectory-Objekte auf Attributsebene
- Definition von Sicherheitsquivalenzen
- effektive Zugriffsrechte
- rollenbasierte Administration
- Delegation von administrativen Aufgaben
Auch wenn eine Rollentrennung zwischen der Administration des eDirectory-
Verzeichnisses und des zugrunde liegenden Betriebssystems in Kraft ist, sollte
den eDirectory-Administratoren Grundlagenwissen zum Betriebssystem ver-
mittelt werden. Anderenfalls wird eine Zusammenarbeit bei der Problem-
lsung erschwert.
- Wurden alle Administratoren fr die Arbeit mit eDirectory geschult?
- Ist der Umgang mit allen relevanten Sicherheitsmechanismen dargestellt
worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.30 Schulung zum Einsatz von Novell eDirectory

Clientsoftware
Verantwortlich fr Umsetzung: Leiter IT, Vorgesetzte
Fr den Einsatz im Intranet wird der eDirectory-Verzeichnisdienst auf einem
oder in der Regel mehreren Servern installiert. Die im eDirectory eingerich-
teten Benutzer und Benutzergruppen knnen dann ber geeignete eDirectory-
Clientsoftware auf den Verzeichnisdienst zugreifen, entsprechend der ihnen
im eDirectory erteilten Rechte.
Je nach Art der eingesetzten Clientsoftware erfolgt der Zugriff auf eDirectory Authentisierung des
Benutzers
fr den Benutzer transparent, so dass eine Schulung zu eDirectory-spezi-
fischen Aspekten der Software fr den Benutzer nicht notwendig ist. Sofern
der eingesetzte Client jedoch eine Authentisierung des Benutzers gegenber
dem eDirectory erfordert, wie z. B. der Novell Client fr Windows, mssen
dem Benutzer in einer Schulung zumindest die folgenden Inhalte vermittelt
werden:
- Funktionsweise und Anwendung des verwendeten Login-Mechanismus,
- Umgang mit Passwrtern sowie
- Umgang mit SSL-Authentisierung ber Benutzer-Zertifikat oder Passwort.
Wird ein LDAP-Client verwendet, der dem Benutzer ein Durchlaufen des Durchlaufen des
Verzeichnisbaums
hierarchisch angeordneten Verzeichnisbaums oder die Formulierung eigener
Suchanfragen auf der Ebene von LDAP-Attributen erlaubt, so ist zustzlich
eine Schulung der Benutzer zu den Themen
- Informationsmodell von eDirectory und
- effiziente Formulierung von Suchanfragen
erforderlich.
Neben den generellen Verzeichnisdienst-Clients (dem Novell Client fr unterschiedliche Client-
Applikationen
Windows sowie Libraries fr Unix-Betriebssysteme) gibt es noch eine Klasse
weiterer Client-Applikationen fr eDirectory, die ganz speziell zur Benutzer-
verwaltung in (auch heterogenen) IT-Landschaften dienen: das Novell Account
Management Modul. Diese Applikationen sind in den Anmeldevorgang der
entsprechenden Betriebssysteme eingebunden und bernehmen so auch die
Authentisierung von Benutzern. Daneben stehen die NDS-AS (NDS Authen-
tication Service) fr eine ganze Reihe von Plattformen (Linux, FreeBSD, HP-
UX, MVS, OS/390, Solaris) zur Verfgung. NDS-AS setzt den Einsatz von
Netware voraus (ab Netware 5.0, SP 4A).
Die Authentisierung ist ein wesentlicher Aspekt beim sicheren Betrieb von Single Sign On
eDirectory. Aus Sicht des Verzeichnisdienstes sollte dabei sichergestellt sein,
dass sich sowohl der Client gegenber dem System authentisiert, als auch der
Benutzer gegenber dem Client. War die Authentisierung erfolgreich, so bietet
eDirectory einen automatisierten Zugriff auf smtliche fr ihn zugngliche
Objekte und Services (so genannte Background Authentication). Auf diese
Weise wird ein Single Sign On realisiert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Authentisierung umfasst dabei folgende Schritte: Der Benutzer gibt beim Challenge-Response-
Novell Client seinen Benutzernamen ein, welcher direkt an das eDirectory Verfahren
weitergeleitet wird. eDirectory sucht den zugehrigen privaten Schlssel aus
seinem Verzeichnis und verschlsselt diesen. Bei dieser Verschlsselung ist
das Benutzerpasswort sowie ein Geheimnis des Clients involviert. Dieser ver-
schlsselte private key wird an den anfragenden Client bertragen. Der Benut-
zer wird nun nach seinem Passwort gefragt, welches er dem Client mitteilt.
Der Client entschlsselt daraufhin mit Hilfe dieses Passwortes und dem
Client-Credential den privaten Schlssel und hlt ihn im Arbeitsspeicher. Auf
Basis dieses private keys sowie dem Zertifikatsgegenstck findet nun die
eigentliche Authentisierung mit dem eDirectory gem einem Challenge-
/Response-Verfahren statt. Ist dieses erfolgreich, so ist der Benutzer einge-
loggt und der private Schlssel des Benutzers wird aus dem Arbeitsspeicher
des Clients gelscht.
Nach auen erscheint das System somit wie ein Passwort-gesttztes Authen-
tisierungsschema, nach innen werden asymmetrische kryptographische
Mechanismen eingesetzt.
Die Sicherheit der auf eDirectory-Servern gespeicherten Daten hngt zu einem
groen Teil auch vom korrekten Umgang der Benutzer mit den Sicherheits-
mechanismen ab. Um diese effektiv nutzen zu knnen, sollten Benutzer von
eDirectory-Clientsoftware entsprechend geschult werden.
Benutzersicht auf Sicherheitsmechanismen
Beim Umgang mit eDirectory-Clientsoftware kann ein groer Teil der sicher- Zugriffsrechte auf eigene
Dateien und
heitsrelevanten Einstellungen dem Benutzer durch entsprechende Vorarbeiten Verzeichnisse
und Voreinstellungen des Administrators abgenommen werden. Um einheit-
liche und berprfbare Client-Konfigurationen zu erreichen, ist ein solches
Vorgehen unabdingbar. Einige sicherheitsrelevante Einstellungen mssen
allerdings vom Benutzer selbst vorgenommen werden. Dazu gehren in der
Regel auf der Ebene des Betriebssystems die Zugriffsrechte auf die eigenen
Dateien und Verzeichnisse eines Benutzers. Eine Verwaltung der Zugriffs-
rechte auf Dateien mit den Mitteln von eDirectory ist direkt nur fr Datei-
Server auf Basis des Betriebssystems Netware mglich. Indirekt sind Datei-
zugriffsrechte auf anderen Plattformen ber die Organizational Roles admi-
nistrierbar.
Schulungsinhalte
Die folgenden Stichpunkte fassen die relevanten Schulungsinhalte zusammen.
Anhand des Nutzungsszenarios sollte hieraus eine geeignete Auswahl getrof-
fen werden:
- Funktionsweise und Anwendung des verwendeten Login-Mechanismus,
- Umgang mit Passwrtern,
- Umgang mit SSL-Authentisierung ber Benutzer-Zertifikat oder Passwort,
- Informationsmodell von eDirectory,
- effiziente Formulierung von Suchanfragen,
- Grundkenntnisse ber die unterliegenden Betriebssysteme und deren
Sicherheitskonfiguration sowie
- sicheres Lschen von Dateien (siehe z. B. auch M 4.56).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wurde eine Benutzerschulung zur eDirectory-Sicherheit durchgefhrt?
- Wenn Benutzer Zugriffsrechte auf eigene Verzeichnisobjekte vergeben
knnen, wurden sie in den notwendigen Konzepten und Mechanismen
geschult?
- Wurden die Benutzer auf die Sicherheitsmechanismen der verwendeten
Werkzeuge hingewiesen und in deren Nutzung geschult?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.31 Schulung zur Systemarchitektur und Sicherheit

von Exchange 2000 fr Administratoren
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Leiter IT
Um ein Exchange 2000 System korrekt und sicher administrieren zu knnen,
ist die Schulung der verantwortlichen Administratoren unumgnglich. Schon
kleine Konfigurationsfehler knnen dazu fhren, dass die Systemsicherheit
beeintrchtigt wird. Aus diesem Grund mssen Administratoren ber die Sy-
stemarchitektur und besonders ber die Sicherheitsmechanismen von Ex-
change 2000 informiert werden.
Exchange 2000 integriert sich in hohem Mae in das Active Directory von Kenntnisse ber Active
Directory
Windows 2000. Das Active Directory ist die zentrale Datenbank von Win-
dows 2000, in der Benutzerdaten, Gruppenzugehrigkeiten und andere Ver-
waltungsdaten abgelegt werden. Fr die Administration von Exchange 2000
werden daher Kenntnisse ber das Active Directory und seine grundlegenden
Konzepte bentigt. Sonst kann es leicht zu Fehlkonfigurationen kommen, die
erhebliche sicherheitsrelevante Auswirkungen haben knnen. Eine Schulung
der Administratoren auf diesem Gebiet ist daher unerlsslich (siehe auch M
3.27 Schulung zur Active Directory-Verwaltung).
Bei der Installation von Exchange 2000 auf einem Windows 2000 Server wird Routing Group
eine Schema-Erweiterung vorgenommen, um spezifische Exchange-Objekte
sowie zustzliche Attribute zu bereits bestehenden Objekten zu erzeugen. Im
weiteren Verlauf der Installation sind die sogenannten Routing Groups und die
Administrative Gruppe festzulegen. Dabei ist die Routing Group ein Verbund
von Exchange 2000 Servern, die ber eine hohe Bandbreite miteinander
kommunizieren. Die administrative Gruppe legt die administrativen Grenzen
des E-Mail-Systems bzw. von Teilsystemen fest. Diese Grenzen knnen
durchaus domnenbergreifend sein, mssen jedoch innerhalb eines Forests
liegen.
Das Exchange 2000 System verlangt die stndige Verfgbarkeit eines Global Global Catalog Server
Catalog Servers, der von speziellen Windows 2000 Domnen Controllern
angeboten wird. Auerdem mssen die Windows 2000 Netzdienste (speziell
DNS) eingerichtet und funktionsfhig sein. Danach muss die externe Anbin-
dung und die Verbindung zu eventuell vorhandenen fremden E-Mail-Syste-
men, z. B. X.400 oder ccMail, vorgenommen werden. Dabei sind die jeweili-
gen Protokolle zu aktivieren und es mssen entsprechende Regeln auf den
betroffenen Firewalls definiert werden.
Schlielich mssen dann noch E-Mail-Konten und News-Gruppen konfigu-
riert werden. Dies geschieht mittels Windows 2000 Gruppenrichtlinien.
Weitere allgemeine Hinweise zu Gruppenrichtlinien finden sich in M 2.231
Planung der Gruppenrichtlinien unter Windows 2000.
Die beschriebenen Aspekte beziehen sich jedoch nur auf die Server-Kompo-
nente des Exchange/Outlook 2000-Systems. Fr das Gesamtsystem ist zustz-
lich auch die Administration der Client-Komponente wichtig.
Entsprechend dem oben skizzierten Vorgehen ergeben sich in der Folge eine
Reihe administrativer Aufgaben, die von einem oder mehreren spezialisierten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Teams bewerkstelligt werden mssen. Eine intensive Schulung der Admini-

stratoren und ihrer Stellvertreter ist deshalb fr das reibungslose Funktionieren
des Systems besonders wichtig.
Die Schulung der Administratoren sollte zumindest folgende Themen
umfassen:
Grundlagen
- berblick ber die Sicherheitsmechanismen von Windows 2000
- Sicherheitsverwaltung (MMC-Snap-In)
- Active Directory und DNS
- Vertrauensbeziehungen zwischen Domnen
- Mglichkeiten der Zugriffskontrolle auf Server
Active Directory
- Replikation
- Verwendete Mechanismen zur Replikation des Active Directory
(RPC und SMTP)
- Voreingestellte Parameter zur Replikation von Inhalten des Active
Directory
- Problematik der dezentralen Administration des AD im Zusammen-
hang mit Replikationskonflikten
- Backup
- Problematik beim Erstellen eines "Backups des Active Directory"
- Wiedereinspielen von Backups eines Domnen-Controllers
- Rechtevergabe
- Zugriffsrechte auf AD-Objekte knnen auf Attributsebene vergeben
werden
- Mgliche Zugriffsrechte
- Delegation von administrativen Aufgaben auf der Ebene einzelner
OUs
- Gruppenrichtlinien
- Lokale Gruppenrichtlinien und im Active Directory gespeicherte
Gruppenrichtlinien
- Konfigurationsmglichkeiten durch Gruppenrichtlinien
- Wann werden Gruppenrichtlinien angewandt? Wie lsst sich dies
konfigurieren?
- Gruppenrichtlinienobjekte (GPOs) als Objekte im Active Directory
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Gruppenrichtlinienobjekte knnen an Standorte / Domnen / OUs

gebunden werden
- Reihenfolge, in der Gruppenrichtlinien abgearbeitet werden
- Mglichkeiten, die Anwendung von Gruppenrichtlinien zu
kontrollieren (Zugriffsrechte, No Override, Block Policy
Inheritance)
Exchange 2000
- Architektur eines Exchange 2000 Systems
- Grundlegende Konzepte und Routineaufgaben
- Routing Groups
- Administrative Gruppen
- Connectors zu fremden E-Mail-Systemen
- Outlook Web Access (OWA)
- E-Mail-Filter
- E-Mail-Folder und Public Folder sowie die Rechtevergabe auf diese
Objekte
- Schutz der Client-Server-Kommunikation (Outlook 2000 Client, Browser,
eingesetzte Verfahren)
Outlook 2000
- Benutzerprofile
- aktive Inhalte und potentiell gefhrliche Dateiformate
- Auto-Reply-Funktion
- Wurden alle Administratoren fr die Arbeit mit Windows 2000 und Active
Directory geschult?
- Ist der Umgang mit allen relevanten Sicherheitsmechanismen von Ex-
change 2000 dargestellt worden?
- Wurden im Rahmen der Schulung die mglichen E-Mail-Clients, insbeson-
dere Outlook 2000, behandelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.32 Schulung zu Sicherheitsmechanismen von

Outlook 2000 fr Benutzer
Exchange/Outlook 2000 ist ein komplexes System, so dass es bei Fehlnutzung
oder Fehlkonfiguration unbeabsichtigt zu Sicherheitslcken kommen kann.
Dies gilt besonders dann, wenn die Benutzer nicht hinreichend im Umgang
mit Exchange/Outlook 2000 geschult sind. Zwar wird die System-
konfiguration in der Regel so eingestellt, dass diese nur in Grenzen durch die
Benutzer verndert werden kann. Unkenntnis ber die einem Benutzer zur
Verfgung stehenden Sicherheitsmechanismen und -einstellungen knnen
jedoch dazu fhren, dass das System unsicher genutzt wird.
Daher sollten alle Benutzer im Umgang mit Outlook 2000 geschult werden. Grundlagen ber
Exchange 2000
Neben der reinen Nutzung der Client-Software ist es jedoch auch notwendig,
den E-Mail-Benutzern die grundlegende Funktionsweise des Exchange 2000
Systems zu erlutern.
Den Benutzern muss insbesondere vermittelt werden, welche
Sicherheitsmechanismen ihnen zur Verfgung stehen, so dass sie in der Lage
sind, diese korrekt und sinnvoll einzusetzen. Eine Schulung sollte u. a.
folgende Themen behandeln:
- berblick: Zugriffskontrolle auf einen Exchange-Server
- berblick: Zugriffskontrolle auf E-Mail-Konten
- Anerkennen von Zertifikaten (Was bedeuten Cross-Zertifikate?)
- Authentisierung an der Web-Schnittstelle sowie deren Schwchen
und Strken
- Sicherer Umgang mit Internet-Zertifikaten
- Erzwingen der Kommunikationsabsicherung: Port-Verschlsselung
und SSL-Nutzung
- Beschrnkungen fr die Ausfhrung aktiver Inhalte in Outlook 2000
- E-Mail-Verschlsselung und E-Mail-Signaturen
- Aktivierung der erweiterten Sicherheit von Outlook 2000
- Speicherung von Benutzerprofilen
- Umgang mit Offline-Ordnern
- Sicherheitseinstellungen fr persnliche Ordner (Verschlsselung)
- Gefhrdungen bei der Nutzung der Out of Office-Funktionalitt
- Umgang mit Verteilerlisten
- Umgang mit Stellvertreterberechtigungen (send as)
- Verhaltensregeln fr die Nutzung des Outlook Web Access (sofern
diese Funktionalitt berhaupt zur Verfgung gestellt wird)
- Umgang mit Outlook-Formularen
Diese Liste stellt nur einen Ausschnitt aus den notwendigen
Sicherheitsthemen dar und muss organisationsspezifisch angepasst und
erweitert werden. Neben der reinen Schulung zu den Sicherheitsmechanismen
von Outlook 2000 mssen die Benutzer jedoch auch die geltenden
Sicherheitsvorschriften kennen, damit diese bei der Nutzung der
Sicherheitsmechanismen auch entsprechend umgesetzt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.33 Sicherheitsberprfung von Mitarbeitern

Verantwortlich fr Initiierung: Leiter Personal, IT-Sicherheitsmanagement
Die Mglichkeiten, die Vertrauenswrdigkeit von neuem oder fremdem Per-
sonal berprfen zu lassen, sind in Deutschland, aber auch in vielen anderen
Lndern, rechtlich sehr eingeschrnkt. Dazu kommt, dass die Ergebnisse meist
wenig aussagekrftig sind, wie z. B. bei polizeilichen Fhrungszeugnissen.
Grundstzlich sollte aber vor der bernahme von neuen oder externen Mitar-
beitern in Projekte berprft werden, ob
- diese hinreichende Referenzen haben, z. B. aus anderen, hnlichen Projek-
ten, und
- der vorgelegte Lebenslauf des Bewerbers aussagekrftig und vollstndig
ist.
Darber hinaus kann es sinnvoll sein, sich akademische und berufliche Quali-
fikationen besttigen zu lassen, beispielsweise durch Nachfragen an der Uni-
versitt oder frheren Arbeitgebern oder Kunden. Auch die Identitt des Be-
werbers sollte verifiziert werden, z. B. durch Vorlage von Ausweispapieren.
Wenn externes Personal intern eingesetzt wird oder im Rahmen von Projek-
ten, Kooperationen oder Outsourcing-Vorhaben auf interne Anwendungen und
Daten zugreifen kann, sollten vergleichbare berprfungen wie fr eigene
Mitarbeiter durchgefhrt werden. Bei der Vertragsgestaltung mit externen
Dienstleistern sollte vertraglich festgehalten werden, welche Seite solche
berprfungen durchzufhren hat und in welcher Tiefe diese erfolgen.
- Wie wird die Vertrauenswrdigkeit von eigenen und fremden Mitarbeitern
berprft?
- Werden die Referenzen von neuen Mitarbeitern hinterfragt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.34 Einweisung in die Administration des

Archivsystems
Um ein Archivsystem korrekt und sicher administrieren zu knnen, mssen
sich die Verantwortlichen und hier vor allem die Administratoren und Archiv-
verwalter mit den eingesetzten Systemen auskennen. Hierfr ist eine Schulung
der verantwortlichen Archivverwalter und Administratoren notwendig. Da-
durch sollen Konfigurationsfehler und Fehlverhalten vermieden werden. Die
Schulung sollte mindestens folgende Themen umfassen:
- Systemarchitektur und Sicherheitsmechanismen des verwendeten Archiv-
systems und des darunterliegenden Betriebssystems,
- Installation und Bedienung des Archivsystems, Handhabung der ver-
wendeten Archivmedien und Kennzeichnung der Archivmedien (siehe
auch M 2.3 Datentrgerverwaltung),
- Einsatzbedingungen (Klimatisierung, etc.) des Archivsystems und der
Archivmedien,
- Dokumentation der Administrationsttigkeiten,
- Protokollierung der Systemereignisse am Archivsystem,
- Vorgehensweise bei der Auffrischung der Datenbestnde (siehe M 2.263
Regelmige Aufbereitung von archivierten Datenbestnden und M 2.264
Regelmige Aufbereitung von verschlsselten Daten bei der Archi-
vierung),
- Grundbegriffe von Verschlsselung und digitaler Signatur, wenn
kryptographische Verfahren verwendet werden,
- Vorgehensweise bei der Vernichtung ausgesonderter Archivmedien,
- Systemberwachung und Wartung (Operating) des Archivsystems,
- Eskalationsprozeduren, z. B. bei
- Nichteinhaltung von Reaktionszeiten,
- Unterschreiten der Rest-Speicherkapazitt der Archivmedien,
- Manipulation oder Sabotage des Archivsystems oder Ereignissen
hherer Gewalt sowie
- unberechtigten Zugriffen auf archivierte Daten.
Die Schulung der Administratoren und Archivverwalter ist zu dokumentieren.
Bei Systemnderungen sollten die Administratoren und Archivverwalter ent-
sprechend weitergebildet werden.
- Sind die Administratoren des Archivsystems den Vorgaben entsprechend
geschult worden?
- Werden die Administratoren regelmig weitergebildet, z. B. bei
nderungen am System?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.35 Einweisung der Benutzer in die Bedienung des

Archivsystems
Die Archivierung ist eine besonders verantwortungsvolle Aufgabe und stellt
hohe Anforderungen an die Bedienung. Die dafr vorgesehenen Mitarbeiter
sind auf diese Verantwortung besonders hinzuweisen und vorzubereiten.
Hierzu mssen die Benutzer entsprechend geschult werden.
Eine derartige Schulung sollte unter anderem folgende Themen umfassen:
- Vorgehensweise bei der Umwandlung analoger Daten:
Die korrekte Vorgehensweise bei der Erfassung der Dokumente, der Um-
wandlung in die elektronische Form sowie der elektronischen Archivierung
sind zu erlutern und anhand von praktischen Beispielen zu ben.
- Rechtliche Rahmenbedingungen der Archivierung:
Bei der Archivierung sind rechtliche Anforderungen einzuhalten (siehe
M 2.245 Ermittlung der rechtlichen Einflussfaktoren fr die elektronische
Archivierung). Diese Anforderungen und die Folgen bei Nichteinhaltung
mssen den Benutzern deutlich gemacht werden.
- Schutz der Vertraulichkeit und Integritt der Dokumente:
Die korrekte Vorgehensweise bei der Behandlung vertraulicher Dokumente
sowie bei der Integrittssicherung und -prfung archivierter Dokumente ist
zu demonstrieren. Auf mgliche Folgen bei fehlerhafter Bedienung ist hin-
zuweisen.
- Besonderheiten bei der Verwendung von WORM-Medien:
Auf die Besonderheiten bei der Speicherung auf einmal beschreibbare
Medien ist besonders hinzuweisen, das heit es ist zu beachten, dass
einmal gespeicherte Daten nicht mehr gelscht werden knnen (allenfalls
eine neue Version knnte erneut archiviert werden). Dies kann nicht nur zu
Kapazittsengpssen, sondern auch zu Datenschutz- oder Vertraulichkeits-
problemen fhren, da Daten nur als "zu lschen" markiert, aber nicht tat-
schlich gelscht werden.
- Organisationsspezifische Sicherheitsrichtlinien und ihre Anwendung bei
der elektronischen Archivierung:
Bei der Konzeption des Archivsystems sind blicherweise diverse Sicher-
heitsmanahmen vorgesehen worden, die von den einzelnen Benutzern des
Archivsystems umgesetzt werden mssen. Dies kann z. B. die Art der
Kennzeichnung der Archivmedien oder auch den Umgang mit als vertrau-
lich oder anderweitig klassifizierten Informationen betreffen. Alle Benutzer
mssen auf diese organisationsspezifischen Sicherheitsrichtlinien hinge-
wiesen werden.
Die Schulung der Mitarbeiter ist zu dokumentieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind fr die Benutzer des Archivsystems Schulungen zur Bedienung
vorgesehen?
- Wird die Teilnahme der Benutzer an den Schulungen dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.36 Schulung der Administratoren zur sicheren

Installation und Konfiguration des IIS
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement,
Die Gefahr eines Angriffs auf einen aus dem Internet erreichbaren IIS ist sehr
gro. Aus diesem Grunde sollten nicht nur funktionale Aspekte bei der
Installation und Konfiguration eine Rolle spielen. Insbesondere die Sicherheit
ist von groer Bedeutung, da nicht nur der Server selbst bedroht ist, sondern
dieser u. U. auch als Ausgangspunkt fr Angriffe auf das gesamte Netz
missbraucht werden kann.
Sicherheitslcken im IIS basieren zum einen auf Schwachstellen der Software,
z. B. Programmierfehler. Obwohl Microsoft bei Bedarf neue Hotfixes und in
gewissen Abstnden Service Packs verffentlicht, werden sowohl in Windows
wie auch in allen Versionen des IIS immer wieder Schwachstellen entdeckt,
fr die erst nach einiger Zeit Hotfixes verfgbar sind und die erst nach
lngerer Zeit in Service Packs bercksichtigt werden. Zum anderen entstehen
Sicherheitslcken durch fehlerhafte Konfiguration des Systems, beispielweise
durch standardmig installierte Beispielanwendungen und Scripts.
Um eine sichere Installation und Konfiguration des IIS zu gewhrleisten,
mssen die verantwortlichen Administratoren ber entsprechende Kenntnisse
und Qualifikationen verfgen. Das bedeutet, dass den Administratoren die
relevanten Gefahren und Sicherheitslcken bekannt sind und dass sie wissen,
welche wirksamen Manahmen zur Absicherung des IIS-Systems
durchzufhren sind.
Aus diesem Grund sind regelmige Schulungsmanahmen fr die
Administratoren durchzufhren.
Bei der Planung von Schulungsmanahmen ist zu beachten, dass der IIS nicht
alleine betrachtet werden kann. Voraussetzung fr eine sichere Installation des
IIS ist ein sicher konfiguriertes Betriebssystem. Auerdem steht ein Web-
Server in der Regel nicht alleine, sondern ist in eine Systemumgebung
(weitere Server und Clients) eingebunden. Aufgrund dieser Komplexitt ist
ein umfangreiches Schulungsprogramm zu empfehlen, in dem folgende
Themenschwerpunkte zu bercksichtigen sind:
- Gefahren und Risiken bei vernetzten Systemen
- Gefahren und Risiken eingesetzter Dienste, beispielsweise http, ftp, telnet
- Sicherheitslcken im Betriebssystem und der IIS-Software
- Grundlegende Architektur der IIS-Software
- Funktionalitten der einzelnen Komponenten
- Zusammenspiel mit dem Betriebssystem
- Zugriffsrechte auf Dateien
- Bedienung der Admin-Werkzeuge
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sichere Einbindung in die Systemumgebung, z. B. durch Einrichten einer

Demilitarisierten Zone (DMZ)
- Sichere Installation und Konfiguration des Betriebssystems, z. B.
Konfiguration der Netzeinstellungen
- Sichere Installation und Konfiguration des IIS, z. B. Absicherung von
virtuellen Verzeichnissen
Damit sichergestellt ist, dass die Administratoren auch ber aktuelle
Sicherheitsrisiken im Zusammenhang mit dem IIS und ber aktuelle
Entwicklungen in der Informationstechnik informiert sind, sollten die
Schulungen in regelmigen Abstnden, z. B. halbjhrlich, durchgefhrt
werden.
- Welche Schulungsmanahmen werden in welchen Intervallen angeboten?
- Decken die Inhalte der Schulungsmanahmen die erforderlichen Gebiete
ab?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.37 Schulung der Administratoren eines Apache-

Webservers
Um den Apache-Webserver korrekt und sicher administrieren zu knnen, ist
eine Schulung der verantwortlichen Administratoren unumgnglich. Schon
kleine Konfigurationsfehler knnen dazu fhren, dass Sicherheitslcken ent-
stehen. Besonders die korrekte Konfiguration von Zugangsbeschrnkungen zu
bestimmten Bereichen des Webangebots erfordert gute Kenntnisse der vor-
handenen Mglichkeiten und ihrer Beschrnkungen.
Aufgrund der starken Interaktion zwischen den Sicherheitsmechanismen der
Apache-Software und des zugrundeliegenden Betriebssystems mssen den
Administratoren des Apache-Webservers auch die Sicherheitsmechanismen
des Betriebssystems bekannt sein. Dies gilt auch dann, wenn die Administra-
toren des Apache-Webservers nicht gleichzeitig auch fr die Administration
des Betriebssystems zustndig sind.
Neben den Aspekten der allgemeinen Betriebssystemsicherheit sollten fol-
gende Aspekte Gegenstand der Schulung sein:
- Methoden der Installation des Apache-Webservers (Installation ber die
Paketverwaltung des Betriebssystems, Binrversionen der Apache Foun-
dation, gegebenenfalls Kompilieren aus dem Quellcode).
- Konfigurationsmglichkeiten des Apache-Webservers, Syntax der Konfi-
gurationsdateien.
- Mglichkeiten zur Einbindung des Apache-Webservers in den Startprozess
des Betriebssystems.
- Mechanismen der Benutzerauthentisierung beim Apache-Webserver, Ein-
satzgebiete, Vor- und Nachteile der einzelnen Mechanismen.
- Einrichten und Verwalten von Zugangsbeschrnkungen beim Apache-
Webserver.
- Zusammenspiel der Konfiguration von Zugangsbeschrnkungen in der
Apache-Konfiguration mit Zugriffsberechtigungen auf Betriebssystem-
und Dateiebene, beispielsweise bei Verwendung von URL-Rewriting oder
symbolischen Links.
- Mglichkeiten zur Aufteilung von Kompetenzen zwischen den Server-
Administratoren und "Redakteuren", Entwicklung von Rechte- und Rol-
lenkonzepten.
- Mglichkeiten zur Abbildung eines "organisatorischen" Rechte- und
Rollenkonzepts mit Hilfe der Benutzer- und Rollenverwaltung des Be-
triebssystems.
- Einsatzmglichkeiten und Konfiguration von SSL beim Apache-
Webserver.
- Manahmen zur Sicherstellung der Verfgbarkeit beim Apache-
Webserver.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Mglichkeiten und Risiken beim Einsatz von CGI-Skripten und Server-

Erweiterungen. Kriterien zur Auswahl geeigneter Erweiterungen und Pro-
grammiermethoden.
- Datensicherung beim Apache-Webserver.
- Sind die Administratoren auf den Umgang mit dem Apache-Webserver
vorbereitet und insbesondere in sicherheitsrelevanten Aspekten geschult?
- Sind die Administratoren im Umgang mit dem genutzten Betriebssystem
und seinen sicherheitsrelevanten Aspekten geschult?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.38 Administratorenschulung fr Router und

Switches
Fr den sicheren Betrieb von Routern und Switches ist es wichtig, dass alle
Arbeiten durch Personal durchgefhrt werden, das in der Lage ist, alle
gebotenen Funktionen und Sicherheitsmerkmale optimal zu nutzen. Daher ist
es unerlsslich, dass die Administratoren entsprechend geschult werden.
In den Schulungen sollten ausreichende Kenntnisse zu den fr die Einrichtung
und den Betrieb von Routern und Switches notwendigen Vorgehensweisen,
Werkzeugen und Techniken vermittelt werden. Dies gilt auch fr
herstellerspezifische Aspekte zum gewhlten Produkt. In dieser Manahme
werden Anforderungen an Schulungen beschrieben, die Administratoren in die
Lage versetzen, Router und Switches in einer typischen Umgebung
installieren und betreiben zu knnen.
In den Schulungen sollten die Grundlagen, Konzepte und Kenntnisse der
Kommandos zu Einrichtung, Betrieb, Wartung und Fehlersuche vermittelt
werden. Eine Schulung sollte eine ausgewogene Mischung aus Theorie und
Praxis darstellen.
Auch wenn in einer Gruppe von Administratoren die Aufgaben so verteilt
sind, dass jeder Administrator nur einen bestimmten Verantwortungsbereich
hat, ist es unverzichtbar, dass alle Administratoren ein allgemeines
Grundwissen besitzen. Die individuellen Schwerpunkte knnen davon
ausgehend gezielt ausgebaut und gepflegt werden. Zu vielen Produkten gibt es
von den Herstellern oder spezialisierten Anbietern hierfr ein umfangreiches
Angebot an aufeinander aufbauenden und individuell vertiefenden Seminaren.
Das Angebot an qualifizierten Schulungen stellt ebenfalls ein Kriterium dar,
das bei der Entscheidung fr einen bestimmten Hersteller bercksichtigt
werden sollte.
Fr Schulungsmanahmen sollte bereits bei der Beschaffung von IT- Budget fr Schulungen
Komponenten ein Budget eingeplant werden und ein Schulungsplan fr
Administratoren erstellt werden. Die Inhalte einer Schulung sollten die
- Grundlagen
- ISO/OSI Schichten Modell
- Netztopographien / -topologien und bertragungstechniken
- Verkabelung
- Aktive Netzkomponenten
- Grundlagen von IP und der damit zusammenhngenden Protokolle
(IP-Adressierung, Subnetting, IP, ICMP, TCP, UDP)
- berblick ber Hersteller und Produkte
- Switching
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Funktionsweise eines Switches

- "Cut Through" und "Store and Forward"
- Transparent Bridging Funktion (IEEE 802.1d)
- Spanning Tree Algorithmus (IEEE 802.1d)
- VLAN (VLAN Typen, Tagging, IEEE 802.1q)
- Routing
- Funktionsweise eines Routers
- Statisches und dynamisches Routing
- Dynamische Routing-Protokolle (RIPv1, RIPv2, OSPFv2, BGPv4,
IGRP, EIGRP)
- WAN-Anbindung
- Grundlagen der WAN-Technologien und Protokolle
- Vermittlungsarten (Fest-, Whlverbindung)
- Virtuelle Private Netze (VPN)
- Weitverkehrsverbindungen (xDSL, ISDN)
- WAN-Protokolle (PPP, Frame Relay)
- Einrichtung
- Zusammenbau und Verkabelung
- Einrichtung und Konfiguration von Routern und Switches
(Schwerpunkt: Betriebssystem)
- Betrieb
- Management der Gerte, Werkzeuge
- Integration in Netzmanagementsysteme (NMS)
- Protokollierung (syslog)
- Sicherung und Verwaltung von Konfigurationsdateien
- Fehlerbehebung
- Fehlerquellen und Ursachen
- Mess- und Analysewerkzeuge
- Teststrategien zur Fehlersuche
- Anforderungen an sichere Netzinstallationen
- IT-Sicherheit
- Grundlagen der IT-Sicherheit sowie fr Router und Switches
relevante IT-Sicherheitsaspekte
- Authentisierung, Autorisierung
- Kryptoverfahren und Anwendungen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Angriffsszenarien (Denial of Service Attacken, ARP-Spoofing, IP-

Spoofing)
- Gefahrenquelle "Default-Einstellungen"
- Vorsorgemanahmen, Reaktion und Analyse
- Incident Handling
- Steht ein Budget fr Schulungsmanahmen zur Verfgung?
- Wurde ein Schulungsplan fr Administratoren in Anlehnung an die
erwhnten Punkte erstellt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.39 Einfhrung in die zSeries-Plattform

Die zSeries-Architektur ist der Nachfolger der 1964 eingefhrten S/360- Komponenten von
zSeries-Hardware und
Architektur und wird bei heutigen Mainframe-Installationen hufig eingesetzt. Software
Die zSeries-Systeme (als Teil von IBMs eServer-Familie) knnen sowohl fr
Stapelverarbeitungen und Transaktionen als auch fr E-Business-Anwendun-
gen eingesetzt werden.
Zum Betrieb der zSeries-Plattform stehen die Betriebssysteme OS/390
(31 Bit-Architektur) und z/OS (64 Bit-Architektur) zur Verfgung. Da das
z/OS-Betriebssystem als Nachfolger von OS/390 gilt, sollte es bei neuen
Installationen eingesetzt werden.
Nachfolgende Abschnitte enthalten eine bersicht ber die Komponenten der
zSeries-Plattform, sie erheben jedoch keinen Anspruch auf Vollstndigkeit.
Umfangreiche und detaillierte Informationen sind in der einschlgigen
Literatur des Herstellers IBM zu finden (siehe Literaturhinweise am Ende der
Manahmenbeschreibung).
Das z/OS-Betriebssystem ist in der Manahme M 3.40 Einfhrung in das
z/OS-Betriebssystem beschrieben, das Betriebssystem Linux fr z/OS in der
Manahme M 3.41 Einfhrung in Linux und z/VM fr zSeries-Systeme.
Historie
Die Basis fr die zSeries-Architektur entstand im Jahr 1964, als IBM die
S/360-Architektur entwickelte und einfhrte. Von Anfang an war es Ziel der
Architektur, dass Maschinencode auf allen damaligen und zuknftigen
Modellen ohne wesentliche Modifikationen lauffhig sein sollte.
Im Laufe der Zeit erweiterte IBM sukzessiv die S/360-Architektur, wobei sich
die Bezeichnung mehrfach nderte, erst zu S/370, danach zu S/390 und jetzt
zur aktuellen zSeries. Die wesentlichen Grundlagen der Architektur (z. B.
Maschinencode, Register und Adressierung oder auch die Festlegung der
Relation zwischen Bit und Byte) wurden jedoch immer beibehalten und gelten
heute noch.
Mainframe-Architektur
IBMs Dokumentation z/Architecture Principles of Operations teilt das
zSeries-System in die Bestandteile
- Main Storage,
- einem oder mehreren Central Processing Units (CPUs),
- Operator Facilities,
- einem Channel Subsystem und
- I/O Devices
auf. Die I/O Devices hngen an sogenannten Control Units (CU), die wiede-
rum am Channel Subsystem hngen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die S/390-Architektur entspricht - mit Ausnahme der neuen zSeries-Funktio-

nen - im wesentlichen der zSeries-Architektur. Im Folgenden werden einige
Aspekte der z/Architektur dargestellt:
EBCDIC Code
zSeries-Systeme verwenden beim Abspeichern den sogenannten EBCDIC-
Code (Extended binary coded decimal interchange code) mit einer Lnge von
acht Bit, im Gegensatz zu dem bei anderen Rechner-Architekturen verwende-
ten ASCII-Code (sieben Bit). Kommunizieren Rechner miteinander, die unter-
schiedliche Formate einsetzen, sind Konvertierungen der Codes erforderlich.
Register
Ein zSeries-Rechner arbeitet mit verschiedenen Registern von 64 Bit Lnge
(z. B. Kontrollregister oder Mehrzweckregister). Der Instruction Operation
Code (IOC) bestimmt, welches Register verwendet wird.
Beim S/390-Rechner sind die Register 32 Bit lang.
Programmverzweigung (Linkage Convention)
Die zSeries-Architektur verwendet beim Aufruf eines Unterprogramms
mehrere Mehrzweckregister. Die Verwendung bestimmter Register ist in der
Literatur auch als Linkage Convention bekannt.
Alternativ ist die Benutzung eines Linkage Stacks mglich, wofr andere
Assembler-Instruktionen zur Verfgung stehen.
Speicherschutz
Ein zustzlicher Speicherschutz stellt bei der zSeries-Architektur sicher, dass
Fehler beim Speicherzugriff weitgehend vermieden werden. Die Hardware
teilt den Hauptspeicher in 4 kB groe Blcke auf und vergibt pro Block einen
Speicherschutzschlssel, der bei der spteren Verarbeitung berprft wird.
Diese Art des Speicherschutzes stellt eine der Strken des Betriebssystems
dar, da berschreiben fremden Speichers im normalen Problem-Modus weit-
gehend ausgeschlossen ist.
Ein-/Ausgabe
Der zSeries-Ein-/Ausgabe-Verkehr wird durch ein Channel Subsystem gesteu-
ert. Bis zu 65536 Ein-/Ausgabe-Einheiten knnen ber Steuereinheiten
(Control Units) an das Channel Subsystem angeschlossen und mittels Channel
Paths mit diesem verbunden werden.
Die einzelnen Anschlsse werden vom Channel Subsystem als logische Ver-
bindungen (Subchannels) gefhrt. Sie sind ber Channel Paths mit dem
Channel Subsystem verbunden.
Operator Facilities
Mit dieser Funktion kann der Systemadministrator, hnlich der BIOS-Kom-
munikation beim PC, mit dem zSeries-System in Verbindung treten und
Systemanpassungen vornehmen.
Zur Kommunikation dient ein herkmmlicher PC, der an das Service Element
angeschlossen ist und als Management Console bezeichnet wird (siehe auch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abschnitt Ein-/Ausgabe - zSeries-Mainframe-Konsolen). Diese Konsole dient

ausschlielich der Nutzung durch den Systemadministrator bzw. das
Wartungspersonal des Herstellers.
Betriebssystem-Untersttzung
Die z/Architektur untersttzt alle drei existierenden Hardware-Adressierungs-
bereiche, 24 Bit-, 31 Bit- und 64 Bit-Adressierung. Betriebssysteme und
Middleware-Produkte wurden fr die Mglichkeit der erweiterten Adres-
sierung angepasst. Viele Beschrnkungen, z. B. die 2 GB-Grenze bei S/390-
Systemen oder jetzt weitgehend unntige Funktionen, wie z. B. die Verla-
gerung von Seiten des Hauptspeichers in den erweiterten Speicher (Expanded
Storage), fallen damit weg. Dadurch kann der Durchsatz des Systems in vielen
Fllen erhht werden. Expanded Storage wird jedoch weiterhin bei S/390-(31-
Bit)-Anwendungen und z/VM untersttzt.
Anmerkung: Das S/390-System ist zwar in Bezug auf die Hardware ein
32 Bit-System, die Software darauf luft jedoch mit 31 Bit, da das erste Bit
zur Umschaltung zwischen 24 und 31 Bit-Modus bentigt wird.
Unterschiede der S/390-Architektur zur zSeries-Architektur
Der Hauptunterschied zwischen S/390- und zSeries-Systemen ist die erwei-
terte Adressierbarkeit. Whrend die S/390-Architektur nur die 31 Bit- Adres-
sierung untersttzt, wurden in den Rechnern der zSeries fast alle Register auf
64 Bit erweitert. Ein Umschalten zwischen den beiden Modi ist jederzeit
mglich.
Die neuesten zSeries-Systeme sind noch immer kompatibel zu frher ent-
wickelten 31 Bit-Programmen, es laufen sogar noch 24 Bit-Programme.
Hardware
Mainframe-Hardware ist in den verschiedensten Varianten verfgbar. Modelle
und Ausstattung lassen sich flexibel zusammenstellen, periphere Einheiten
knnen weitgehend beliebig daran angeschlossen werden. Eine vollstndige
Darstellung kann an dieser Stelle nicht gegeben werden.
Nachfolgend eine kurze bersicht ber die wichtigsten Merkmale:
Modelle
Zur Zeit sind die Typen S/390 (G5, G6 und Multiprise) aus der S/390-Archi-
tektur verfgbar, aus der zSeries-Architektur die Typen z800-Server, z900-
Server und z990-Server (Stand Ende 2003).
Prozessoren
Die Systeme sind auf bis zu 32 Prozessoren aufrstbar, wobei diese bei der
zSeries-Architektur dynamisch (d. h. whrend des Betriebs) hinzugefgt wer-
den knnen.
Hauptspeicher
Je nach Typ knnen zwischen 1 GB bis max. 256 GB Hauptspeicher ver-
wendet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kanle
Verfgbar sind 256 bis max. 512 Kanle, wobei unterschiedliche Kanaltypen
zusammen betrieben werden knnen (Escon, Ficon). Je nach Konstellation
gibt es Einschrnkungen.
Logical Partitioning
Ein zSeries-System lsst sich in bis zu 15, bei z990-Servern in bis zu 30,
sogenannte logische Partitionen (Logical Partition, LPAR) aufteilen. Dies
wird durch das interne PR/SM-Feature (teils Hardware, teils Microcode im
Licensed Internal Code) untersttzt. Jede einzelne Partition verhlt sich dabei
wie ein separates System. Auf den LPARs lassen sich unterschiedliche
Betriebssysteme installieren, so dass der Einsatz von Linux (fr zSeries)
parallel mit dem z/OS-Betriebssystem auf dem gleichen Rechner mglich ist.
Komponenten
- Multichip Module (MCM)
Die wesentlichen Komponenten des Rechners sind in sogenannten Multi-
chip Modules zusammengepackt und auf einem Glaskeramiktrger aufge-
bracht. Ein MCM beinhaltet Processor Unit Chips (PUs), Chips fr den
L2-Cache und dessen Ansteuerung sowie die Ein-/Ausgabe-Steuerung. Die
Verbindung aller Komponenten auf dem Trger erfolgt ber waagerechte
und senkrechte Leitungsverbindungen, die ber Kontakte mit der Platine
verbunden sind.
- Thermo Conduction Module (TCM)
Die in einem MCM entstehende Wrme leitet ein auf dem MCM sitzender
Khler (TCM) ab.
- SMP
Das MCM stellt einen in sich symmetrischen Multiprozessor (SMP) dar.
- Logical Channel Subsystem (LCSS)
Das LCSS ist eine Erweiterung des frher schon verfgbaren Channel Sub-
systems (CSS), das es erlaubt, von allen Processor Units aus bis zu 512
Kanle anzusprechen.
- HiperSockets
Die schnelle TCP/IP-basierende Verbindung zwischen LPARs und Virtual
Servers (Linux) stellt eine Art TCP/IP-Netz innerhalb des Servers dar.
- Intelligent Resource Director (IRD)
Der Intelligent Resource Director untersttzt den Workload Manager
(WLM) und besteht aus den wesentlichen Teilen
- LPAR CPU Management,
- Dynamic Channel Path Management (DCM) und
- Channel Subsystem Priority Queueing (CSSPQ).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei Problemen im System kann der Workload Manager dynamisch ber

den IRD veranlassen, dass LPAR-Gewichtungen verndert, Kanal-Pfade
umgehngt oder im Channel Subsystem I/O-Prioritten verndert werden.
Prozessoren und Einsatz
Die Prozessoren sitzen auf MCMs und bestehen im wesentlichen aus den fol-
genden Typen:
- Processor Units (Mikroprozessor-Chips),
- CPU (CP),
- Ein-/Ausgabe-Prozessoren,
- Reserve-PUs,
- Level 2 Cache Chips,
- System-Assist-Prozessoren (SAPs, Ausfhrung des Channel Subsystems),
- Storage Control Chips,
- Memory Bus Adapter Chips und
- Clock Chips.
Die Anzahl der standardmig gelieferten CPs und SAPs ist abhngig von
dem jeweils bestellten Modell. Die Anzahl der Reserve-PUs ist abhngig
davon, wie viele PUs insgesamt vorhanden und noch nicht mit Funktionen
belegt sind.
Reserve-PUs lassen sich leicht ber den Licensed Internal Code Configuration
Control (LICCC) via Host Management Console (HMC) den folgenden Funk-
tionen zuordnen:
- Central Processor (CP)
- Integrated Facility for Linux (IFL)
- Internal Coupling Facility (ICF)
- System Assist Processor (SAP)
Kryptographische Komponenten
Die zSeries bietet verschiedene kryptographische Hardware-Komponenten an,
die die Daten-Ver- und -Entschlsselung untersttzen.
- Cryptographic Coprocessor Facility (CCF)
Dieser Coprozessor ist auf dem Prozessormodul der 9672- und zSeries-
Hardware angeordnet (auer z990). Es sind ein oder zwei CCFs je Modul
erhltlich. Im CCF knnen die Schlssel DES Master Key, Key Manage-
ment Master Key (PKA KMMK) und Signature Master Key (PKA SMK)
gespeichert werden.
- Peripheral Component Interconnect Crypto Coprocessor (PCI-CC)
zSeries-Systeme untersttzen die PCI-CC-Karte, die zustzlich eingesetzt
werden kann, um die Funktionalitten und Performance des CCF zu unter-
sttzen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Peripheral Component Interconnect Crypto Accelerator (PCI-CA)

Diese neue Krypto-Karte wurde speziell entwickelt, um die SSL-Ver- und
-Entschlsselung auf zSeries-Systemen zu beschleunigen.
- z990 PCIX-CC Enhanced Cryptographic Functionality
Der PCIX Cryptographic Coprocesser ersetzt die CCF- und PCI-CC-
Krypto-Hardware im z990-Server.
Ein-/Ausgabe
Die Ein- oder Ausgabe von Daten luft bei der zSeries-Plattform ber ein Netz
von Verbindungen, die im folgenden kurz beschrieben werden:
Channel Subsystem (CSS)
Das Channel Subsystem ist eine Einheit (aus Hard- und Software), die fr die
Verarbeitung der Daten von und zu den Ein-/Ausgabe-Einheiten zustndig ist
und die CPU entlastet. Es besteht aus Kanlen (Channel Paths), die wiederum
in Unterkanle (Subchannels) unterteilt sind. Die Unterkanle fhren die
Kanalprogramme (Channel programs) aus. Bei dem zSeries-System z990
wurde das CSS zum Logical Channel Subsystem (LCSS) erweitert und unter-
sttzt jetzt mehr als 15 CPUs.
Escon / MIF
Escon-Kanle sind serielle Kanle, die als Folgeentwicklung der alten
Parallel-Channel-Entwicklung gelten knnen. Das Multiple Image Facility
(EMIF bis z/900 oder MIF ab z/990) untersttzt den parallelen Zugriff von
Ressourcen ber LPAR-Grenzen hinweg (resource sharing). Escon-Kanle
werden ber sogenannte Directors den Einheiten zugeordnet.
Ficon
Ficon-Express-Kanle (Fibre channels) knnen parallel zu Escon-Kanlen
betrieben werden. Bei der z990 knnen bis zu 120 solcher Ficon-Kanle ange-
schlossen werden. Die bertragungsrate reicht bis zu 100 MB pro Sekunde.
Auch Ficon-Kanle werden ber Directors den Einheiten zugeordnet.
Integrated Cluster Bus (ICB)
ICBs werden unter anderem im Rahmen der Sysplex-Kommunikation als
Coupling Link fr Highspeed-Verbindungen zwischen Systemen benutzt.
OSA/Express
OSA/Express bietet einen zSeries-Kanalanschluss fr Ethernet-Gerte wie
z. B. Switches oder Router.
Channel To Channel (CTC)
Channel-To-Channel-Verbindungen gestatten schnelle Verbindungen zwi-
schen zwei zSeries-Rechnern und werden von diversen Software-Produkten,
wie z. B. JES3 und VTAM, untersttzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zSeries-Mainframe-Konsolen
Die Host Management Konsole (HMC) erlaubt die folgenden Aktionen:
- Setzen von Datum und Zeit,
- Konfigurieren von LPARs und Systemen,
- Reset von Subsystemen,
- Boot Manager (Initial Program Load - IPL - einer LPAR),
- Laden des Microprogramms (Initial Microcode Load - IML - eines zSeries
Systems),
- Eingriff bei Fehlerbedingungen,
- Ersatz-MVS-Konsole und
- Fehlerkorrekturen seitens des Herstellers (Microcode-Patches).
Es knnen zwei Konsolen (Primary und Alternate) angeschlossen werden. Sie
sind fr das komplette System zustndig (alle LPARs) und nicht nur fr ein
spezielles Betriebssystem. Der Zugriff auf diese Konsolen muss aus Sicher-
heitsgrnden gut geschtzt sein.
Die z/OS-System-Konsolen (MVS) sind fr die Steuerung und Kontrolle eines
z/OS-Betriebssystems zustndig und lassen sich fr verschiedene Zwecke
konfigurieren, z. B. als Konsole fr alle Nachrichten aus dem Bandbereich
(Tape-Pool). Es sind mehrere MVS-Konsolen pro z/OS mglich, wovon nur
eine die Master-Konsole sein kann. Im Fehlerfall schaltet diese Konsole auf
die nchste verfgbare um. Der Zugriff auf die MVS-Konsolen (speziell auf
die Master-Konsole) muss aus Sicherheitsgrnden gut geschtzt sein.
Remote Support Facility (RSF)
zSeries-Systeme sind meist durch eine Remote-Konsole mit dem Hersteller
verbunden. Diese Funktion meldet erkannte Hard- und Software-Probleme
automatisch weiter, so dass Fehler oft behoben werden knnen, bevor der
Anwender einen Fehler selbst erkennt. Prinzipiell untersttzt diese Verbin-
dung auch die Installation von Patches durch den Hersteller, dies muss jedoch
vorher vereinbart und die Remote-Access-Verbindung entsprechend geschtzt
werden.
Parallel-Sysplex-Konzept
Sind die Anforderungen von einem System (einer LPAR) nicht mehr zu
bewltigen, knnen mehrere LPARs zu einem logischen Verbund, dem
Parallel Sysplex zusammengefasst werden. Dieser stellt sich nach auen als
eine Einheit dar.
Der Parallel Sysplex ist eine Zusammenarbeit von bis zu 32 z/OS-Systemen,
dies entspricht maximal 512 Prozessoren in einem Rechnerverbund. Innerhalb
dieses Verbundes knnen Lasten auf den Rechnern verteilt werden. Treten an
einer Maschine Probleme auf, lsst sich diese aus dem Verbund lsen. Die
Last wird von den im Sysplex verbleibenden Maschinen bernommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Coupling Facility (CF)

Die Coupling Facility (CF) hat die Aufgabe, die Arbeitslast der Systeme zu
steuern und Informationen fr alle Systeme zur Verfgung zu stellen. Sie
ist fr die flexible Lastverteilung und die Skalierung zustndig. Die CF
bernimmt Aufgaben des Locking, Caching und Queuing. Sie wird ber
den CFCC (Coupling Facility Control Code) gesteuert.
- Sysplex Timer
Damit die einzelnen Systeme innerhalb des Sysplex zusammenarbeiten
knnen, ist der Sysplex Timer ntig. Er bernimmt die Aufgabe, allen im
Sysplex befindlichen Systemen eine synchrone Tageszeit zu liefern.
- Work Load Manager (WLM)
Der Work Load Manager ist Teil einer jeden Betriebssystem-Instanz und
bernimmt in Verbindung mit der Coupling Facility einen wichtigen Teil
der Steuerung des Sysplex Clusters. Ein Teil des WLM ist der System
Resource Manager (SRM). Dieser bernimmt die berwachung der ange-
schlossenen Systeme. berwacht werden durch den SRM z. B. Prozessor-
last, Plattenauslastung, Hauptspeichernutzung und andere Parameter. Die
Informationen werden dazu genutzt, die Last auf die im Sysplex ange-
schlossenen Systeme zu verteilen (siehe Abschnitt zum Thema Intelligent
Resource Director).
- Cloning
Alle Systeme eines Sysplex Clusters werden auf Basis eines Plattensatzes
erstellt. Die lokale Anpassung erfolgt im Normalfall ber Variablen der
Systemkonfiguration.
Peripherie
Platten
Im Gegensatz zu anderen Betriebssystemen ist der Plattenbereich eines z/OS-
Betriebssystems in sogenannte Volumes aufgeteilt. Ein Volume umfasst bei der
Emulation einer Platte vom Typ 3390 Mod. 3 einen Speicherbereich von ca.
2,7 GB und ist in Zylinder und Spuren aufgeteilt.
Die Volumes sind an Steuereinheiten angeschlossen. Zur Steigerung der
Performance und Betriebssicherheit ist ein paralleler Anschluss an verschie-
dene Steuereinheiten mglich. Diese werden bestimmten Aufgaben zugeord-
net (z. B. JES-Spool-Datei oder System-Residenz) und lassen sich ber Sub-
channel-Adressen ansprechen.
Band
Das z/OS-Betriebssystem untersttzt verschiedene Bandeinheiten, von einzel-
nen Stationen bis zu Robotersystemen, in denen die Bnder automatisch ver-
waltet und zur Verfgung gestellt werden. Darber hinaus gibt es auch virtu-
elle Band-Systeme (z. B. VTS von IBM oder VSM von StorageTek), die
Dateien zuerst auf integrierten Festplatten zwischenspeichern. Danach werden
diese Dateien sehr effektiv auf Bnder in diesen Einheiten geschrieben
(Komprimierung und Ausnutzung der gesamten Bandlnge). VTS oder VSM
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden vom z/OS-Betriebssystem als Bandeinheit 3490 verarbeitet, d. h. aus

der Sicht des Betriebssystems handelt es sich um ein normales Band.
Drucker
Drucker werden von z/OS-Betriebssystemen sowohl direkt am Kanal als auch
als Netzwerkdrucker im SNA- oder TCP/IP-Netz untersttzt. Bei entspre-
chend groen Druckvolumina, z. B. in Druckzentren, erledigen z/OS-Systeme
auch reine Druckaufgaben.
Terminalfamilie 327x
Klassische 3270-Terminals an den entsprechenden Steuereinheiten sind heute
praktisch nicht mehr in Betrieb. 3270-basierte Terminals haben als PC-
Terminalemulation jedoch einen hohen Stellenwert und befinden sich noch
recht hufig im Einsatz (bekannt als "grner Schirm"). Sie basieren auf dem
TN3270-Protokoll und lassen sich so betreiben, wie die 327x-Terminals aus
frheren Jahren (von Modell 2 bis Modell 5 in verschiedenen Bildschirm-
Formaten).
SNA-Komponenten (Systems Network Architecture)
SNA ist eine hierarchisch aufgebaute Netztechnologie mit vordefinierten Ver-
bindungen. Die Knoten im Netz sind in der Regel als Hardware-Komponenten
ausgefhrt und werden als Physical Units (PUs) bezeichnet. Die Endpunkte
im Netz sind entweder Software-Schnittstellen zu einer Applikation
(Application Control Block, ACB) oder ein Terminal bzw. Terminal-Emulator
oder Drucker. Daneben gibt es seit lngerer Zeit die APPN-Technologie
(Advanced Peer to Peer Network), die sich von der hierarchischen Form deut-
lich unterscheidet.
SNA kommt heute als alleiniges Netzprotokoll nur noch selten zum Einsatz.
SNA-Netzinstallationen sind vielfach abgelst oder durch ein TCP/IP-Netz
ergnzt, so dass die Anzahl der im Betrieb befindlichen SNA-Hardware-
Komponenten stark rcklufig ist.
SNA-Topologie
Das hierarchische SNA-Netz war in der Vergangenheit so aufgebaut, dass
unter einem VTAM ein Front-End-Prozessor 3745/46 angeschlossen war.
Angeschlossen an diesen waren die Control Units, an denen letztlich die End-
gerte (Terminals, Drucker oder Applikationen) betrieben wurden. Diese
Konstellation ist heute zwar immer noch im Einsatz, Front-End Prozessoren
und auch Control Units werden von IBM jedoch nicht mehr vertrieben (aber
noch untersttzt). Die Anbindung an TCP/IP Netze erfolgt heute meistens
ber die Software-Funktion Enterprise Extender. SNA in der heutigen Aus-
prgung wird hauptschlich noch im Rechenzentrum benutzt, um SNA-
basierende Applikationen wie z. B. TSO (Time Sharing Option) anzubinden,
whrend das Netzwerk von TCP/IP abgedeckt wird.
- Physical Units (PUs)
Physical Units stellen physische Knoten im SNA-Netz dar. An diesen
knnen weitere Einheiten hngen. Zu den PUs gehren z. B. die oben
erwhnten Front-End-Prozessoren 3745/46. Darber hinaus existieren
Komponenten, die die frher vorhandenen Control Units (3174) emulieren
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
und deren Funktion wahrnehmen. VTAM im z/OS-Betriebssystem stellt

ebenfalls eine Physical Unit dar. Aus historischen Grnden werden selbst
neuere Funktionen (wie z. B. APPN) bei VTAM Displays immer noch als
Physical Units dargestellt, obwohl diese Bezeichnung hierbei eigentlich
ohne Bedeutung ist.
- Logical Units (LUs)
Eine Logical Unit stellt sich entweder als Schnittstelle zu einer Appli-
kation, als ein Terminal (oder Terminal-Emulator auf einem PC) oder als
ein Drucker dar.
Weitere Informationen zu SNA finden sich in der Manahme M 3.40 Einfh-
rung in das z/OS-Betriebssystem im Abschnitt Communications Server.
Support Elements (SEs)
Jede zSeries-Hardware besitzt zwei Support Elements (S/390-G5 Modelle
haben nur ein SE), die eine Konfiguration und Kontrolle des Systems erlau-
ben. SEs sind ber ein schnelles internes Ethernet-Netz untereinander und mit
den Prozessoren verbunden (ein Support Element ist ein IBM Laptop PC). Sie
erlauben die Systemkommunikation im Rahmen der Operator Facilities.
Firmware
Licensed Internal Code (LIC)
Zwischen der Hard- und der Software existiert auf einer weiteren Ebene der
Microcode (Licensed Internal Code). Fr den LIC gibt es bei PCs keine
direkte Entsprechung, am ehesten ist er mit dem BIOS bei einem PC ver-
gleichbar (siehe Abschnitt zum Thema IML).
Processor Resource/System Manager (PR/SM)
Der Processor Resource/System Manager ist eine LIC-Funktion und erlaubt
die logische Aufteilung der physischen zSeries-Hardware in verschiedene
Teile, Logical Partitions (LPARs) genannt. Jeder logische Rechner beinhaltet
sein eigenes Betriebssystem, wobei verschiedene Betriebssysteme parallel
eingesetzt werden knnen (also zum Beispiel z/OS, OS/390, TPF, Linux oder
VSE/ESA auf einer Hardware). Die gemeinsame Nutzung aller Ressourcen
wird von PR/SM kontrolliert.
Initial Microcode Load (IML)
Der IML ist ein Vorgang, der den LIC in einen nicht zugreifbaren Speicherbe-
reich ldt. Der IML bezieht sich immer auf die gesamte Maschine, d. h. mit
IML werden alle LPARs auf der Maschine neu initialisiert (und damit auch
die Betriebssysteme gestoppt). IML ist ein Teil der Operator Facilities und
kann ber die HMC-Konsole aktiviert werden. Der Aufruf des IML muss ent-
sprechend geschtzt werden.
Hardware Configuration Definition (HCD)
Zur Anpassung der Software-Konfiguration an die Hardware wird eine Datei
(I/O Definition File, IODF) erstellt, in der die logischen Subchannels auf den
physischen Channel Pathid abgebildet werden. Dem Bediener stehen dazu
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
verschiedene Tools zur Verfgung. Auf diese Tools sollte nur autorisiertes
Personal Zugriff haben.
Betriebssystem
Fr die S/390- und der zSeries-Architektur sind verschiedene Betriebssysteme
verfgbar (Stand Januar 2004):
S/390-Architektur (24 und 31 Bit):
- OS/390 Version 2, Release 10
- Linux on S/390
- z/VM Version 3, Release 1
- z/VM Version 4, Release 2 bis 4
- VSE/ESA Version 2, Release 5, 6, 7
- TPF Version 4, Release 1 (nur ESA-Mode)
z/Series-Architektur (64 Bit):
- OS/390 Version 2, Release 10
- z/OS Version 1, Release 2 bis 5
- Linux on zSeries
- z/VM Version 3, Release 1
- z/VM Version 4, Release 2 bis 4
Weitergehende Informationen ber die Betriebssysteme OS/390 und z/OS sind
in der Manahme M 3.40 Einfhrung in das z/OS-Betriebssystem zu finden.
Betrieb
IML
Der Start eines zSeries-Systems beginnt mit dem Initial Microcode Load
(IML). Er wird entweder ber die HMC-Konsole manuell initiiert oder mittels
entsprechender Definitionen automatisch angestoen. Der IML-Vorgang ldt
den Microcode und stellt die Systeminfrastruktur bereit (alle LPARs verfg-
bar, kein Betriebssystem geladen). Whrend des IML-Vorgangs whlt der
Bediener die gewnschte I/O-Konfiguration aus.
IPL
Das z/OS-Betriebssystem wird durch den Initial Program Load (IPL) von der
Host Management Console (HMC) aus aktiviert. Dabei muss mindestens die
IPL-Ladeadresse und der IPL-Parameterstring (Ladeadresse der IOCDS-
Datei) angegeben werden. Nach der NIP-Phase (Nucleus Initialization
Process) kommuniziert das z/OS-System mit dem Bediener ber die MVS-
Master-Konsole. Die weiteren Schritte hngen von den Definitionen des
Betriebssystems ab. Entweder wird das System manuell aktiviert (Ausnahme-
fall) oder automatisch.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Operation
Zu den Betriebsaufgaben gehrt das Starten und Stoppen der Tasks und Jobs,
Aktivieren von Ressourcen, Beantworten von Systemanfragen (Replies) und
Bereitstellen von Bandstationen (wenn ntig).
Monitoring
Das System kommuniziert mit dem Operator ber Nachrichten und Replies,
die an der MVS-Konsole ausgegeben bzw. eingegeben werden. Eine laufende
Kontrolle der Nachrichten ist daher notwendig. Dies kann entweder manuell
(relativ aufwendig) oder besser ber Automatismen erfolgen (separate Pro-
gramme). Gleiches gilt fr die Kontrolle der Stapelverarbeitung.
Literaturhinweise
Fr das zSeries-System existiert eine Vielzahl an Literatur und Dokumentatio-
nen. Die folgende Aufstellung beschrnkt sich auf die wichtigsten und fr die
Sicherheit des zSeries-Systems besonders relevanten Quellen der Firma IBM.
Die Aufstellung ist jedoch keineswegs vollstndig.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Redbooks
Formnummer Titel
SG24-5975-nn IBM @server zSeries 900 Technical Guide
SG24-6863-nn IBM @server zSeries 990 Technical Introduction
SG24-6851-nn z/OS Version 1 Release 3 and 4 Implementation
SG24-6540-nn Putting the latest z/OS Security Features to work
SG24-7023-nn Linux on IBM eServer zSeries and S/390: Best Practices
SG24-6981-nn ABCs of z/OS System Programming Volume 1
(Introduction to z/OS and storage concepts, TSO/E, ISPF,
JCL, SDSF, MVS delivery and installation)
SG24-6982-nn ABCs of z/OS System Programming Volume 2 (z/OS
implementation and daily maintenance, defining
subsystems, JES2 and JES3, LPA, LNKLST, authorized
libraries, catalogs)
SG24-5653-nn ABCs of System Programming Volume 3
(Introduction to DFSMS, storage management)
(Communication Server, TCP/IP, and VTAM )
(Base and Parallel Sysplex , system logger, global resource
serialization, z/OS system operations, automatic restart
management, hardware management console, performance)
SG24-6989-nn ABCs of z/OS System Programming Volume 9 (z/OS UNIX
System Services)
SG24-6990-nn ABCs of z/OS System Programming Volume 10
(Introduction to z/Architecture , zSeries processor
design, zSeries connectivity, LPAR concepts, and
HCD)
TIPS0382 z/OS V1R3 and V1R5 Technical Guide
SG24-7035-nn Unix System Services z/OS V1R4 Implementation
SG24-6968-nn Implementing PKI Services on z/OS
SG24-5637-nn OS/390 Parallel Sysplex Configuration Volume 1
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
IBM Dokumentation
Formnummer Titel
SA22-7832-nn z/Architecture Principles of Operation
SA22-7591-nn z/OS Initialization and Tuning Guide
SA22-7592-nn z/OS Initialization and Tuning Reference
SA22-7683-nn Security Server RACF Security Administrators Guide
SA22-7681-nn Security Server RACF System Programmers Guide
SA22-7682-nn Security Server RACF Macros and Interfaces
SA22-7684-nn Security Server RACF Auditors Guide
SA22-7801-nn z/OS Unix System Services Users Guide
GA22-7800-nn z/OS Unix System Services Planning
SA22-7670-nn z/OS SDSF Operation and Customization
SA22-7532-nn z/OS JES2 Initialization and Tuning Guide
SA22-7533-nn z/OS JES2 Initialization and Tuning Reference
SA22-7549-nn z/OS JES3 Initialization and Tuning Guide
SA22-7550-nn z/OS JES3 Initialization and Tuning Reference
SA22-7783-nn z/OS TSO/E Customization
SA22-7692-nn z/OS MVS Planning: Workload Management
SA22-7597-nn z/OS MVS JCL Reference
SA22-7593-nn z/OS MVS Installation Exits
SC34-4826-nn HTTP Server Planning, Installing and Using
SC31-8775-nn z/OS CS : IP Configuration Guide
SC31-8776-nn z/OS CS : IP Configuration Reference
SA22-7600-nn z/OS MVS Planning : Global Resource Serialization
SA22-7623-nn z/OS MVS Recovery and Reconfiguration Guide
SA22-7625-nn z/OS MVS Setting up a Sysplex
SA22-7630-nn z/OS MVS System Management Facilities (SMF)
SA22-7642-nn z/OS MVS Using the Subsystem Interface
SC26-7402-nn z/OS DFSMSdfp Storage Administration Reference
SC35-0422-nn z/OS DFSMShsm Storage Administration Reference
SC26-7405-nn z/OS DFSMSrmm Implementation and Cust. Guide
SC26-7414-nn z/OS DFSMSdfp Utilities
SC33-7989-nn z/OS HCM Users Guide
GC35-0033-nn Device Support Facilities Users Guide and Reference
SH19-8163-nn MVS/DITTO V2 Users Guide and Reference
SC33-1701-nn CICS RACF Security Guide
SG24-5363-nn IMS V6 Security Guide
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.40 Einfhrung in das z/OS-Betriebssystem

In seinen Grundstrukturen unterscheidet sich z/OS kaum von anderen Komponenten von
zSeries-Hardware und
Betriebssystemen. Sein Aufbau ist eingeteilt in Hardware-nahe Funktionen, Software
Betriebssystemprozesse und Benutzerprozesse. Zwischen dem eigentlichen
Betriebssystem (Base Control Program) und den Benutzerprozessen exis-
tieren eine Reihe von Subsystemen, von denen die bekanntesten das Job Entry
Subsystem fr die Behandlung der Stapelverarbeitung, die Time Sharing
Option fr die Untersttzung des interaktiven Betriebs und die Unix System
Services fr den Unix-kompatiblen Betrieb sind.
Die folgende Beschreibung gilt fr die Betriebssysteme OS/390 und z/OS. Zur
Vereinfachung wird nur noch z/OS aufgefhrt, eventuell vorhandene Unter-
schiede zu OS/390 werden angesprochen, wo sie existieren.
Base Control Program (BCP)
Dieser Teil des z/OS-Betriebssystems ist mit dem Unix-Kernel vergleichbar.
Hierin sind die wesentlichen Funktionen des Betriebssystems vereint, die
dementsprechend im Kernel-Modus laufen.
Subsysteme
Subsysteme erledigen Aufgaben des Betriebssystems, die nicht im Kernel
angesiedelt sind, und laufen in einem separaten Adressraum. Wird ein Sub-
system vor dem JES-Start vom MVS-Kernel aktiviert, erfolgt seine Inter-
pretation durch das z/OS selbst (dies erledigt dann der Master Scheduler), was
mit gewissen Einschrnkungen verbunden ist. Ansonsten startet das Job Entry
Subsystem weitere Subsysteme. Eine Definition in der Konfigurations-Datei
des z/OS (PARMLIB) legt fest, wie und in welcher Reihenfolge solche Sub-
systeme gestartet werden.
Subsysteme werden von IBM und von anderen Software-Herstellern geliefert.
Job Entry Subsystem (JES2/3)
Ein Stapelverarbeitungsauftrag wird im z/OS Batch-Job genannt. Dieser
besteht aus einer Reihe von prozeduralen Anweisungen, die gem der Job
Control Language (JCL) aufgebaut sind. Ein Batch-Job kann aus einem oder
einer greren Anzahl von Ablaufschritten (Steps) bestehen. Auch TSO-User
oder Started Tasks werden dem System ber JCL bekannt gemacht.
Das Job Entry Subsystem (JES) dient zur Verwaltung der Job-Verarbeitung
(hauptschlich Batch-Jobs, aber auch Started Tasks und TSO-User) und deren
Ein- bzw. Ausgaben. Aus historischen Grnden gibt es bis heute zwei unter-
schiedliche Systeme, JES2 und JES3.
Das JES2/3 wird als Primary Subsystem in der Subsystem-Tabelle von z/OS
gefhrt und sollte in einem z/OS-System als erste Task gestartet werden, da
erst im Anschluss daran Batch-Jobs gestartet werden knnen.
Die Verarbeitung der Jobs wird ber sogenannte Initiators kontrolliert. Dabei
werden unter anderem Klassen, Prioritten und Anzahl von Jobs definiert, die
parallel im System arbeiten. Ein- und Ausgaben werden in einer zentralen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Datei gespeichert, die Spool genannt wird. Mehrere Logical Partitions

(LPARs) lassen sich zu einem JES-Verbund zusammenlegen, bei JES3
Complex, bei JES2 Multiple Access Spool (MAS) genannt.
Beide JES-Subsysteme beinhalten hnliche Funktionen. JES3 bietet ber den
Standard hinaus Funktionen wie Networking (zur Automation von Batch-
Jobs), Clustering (LPAR-hnlicher Verbund mit Global/Local-Funktion,
jedoch nur auf JES-Basis) und Locate (Job wird nur gestartet, wenn alle
Ressourcen verfgbar sind). Viele Funktionen stehen dem Bediener parallel
zu den JES-Subsystemen ber andere z/OS-Funktionen zur Verfgung (z. B.
ber GRS, Sysplex, Job Scheduler Programme).
NJE (Network Job Entry) erlaubt das Versenden und Empfangen von Dateien,
Batch-Jobs und auch deren Ausgaben zwischen den einzelnen Netzknoten
eines Verbundes. So ist es damit z. B. mglich, einen Batch-Job vom System
A zum System B zu schicken, dort zu verarbeiten und die Ausgabe dann am
System C auszugeben.
Time Sharing Option (TSO)
Im Online-Betrieb ermglicht TSO einen Multi-Tasking- und Multi-User-
Betrieb.
Der TSO Terminal Control Address Space (TCAS), ein eigener Adressraum,
verwaltet dabei den Ablauf. Er initiiert und terminiert die einzelnen Benutzer-
adressrume (einen pro Benutzer) und verwaltet den Nachrichtenfluss
zwischen Terminal und Adressraum.
TSO untersttzt ber eine einfache Scriptsprache sogenannte Command Lists
(Clists), hufiger ist jedoch die modernere Interpreter-Sprache REXX im Ein-
satz. Zu Vereinfachung der Kommunikation steht dem Bediener ein weiteres
Software-Paket zur Verfgung, das Interactive System Productivity Facility
(ISPF). Es erlaubt einen Dialog im Full Screen Modus. Neben den Standard-
funktionen von ISPF kann der Bediener eigene Dialoge fr neue Applika-
tionen entwickeln.
Communications Server (CS)
Der Communications Server fr z/OS beinhaltet die Software-Komponenten,
die fr die Kommunikation von und zu einem Mainframe ntig sind. TCP/IP-
Komponenten, wie z. B. FTP-Server und TN-Server, sind in diesem Paket
ebenso enthalten wie SNA-Komponenten.
Der Communications Server liefert die folgenden Funktionalitten:
- Bereitstellung der TCP/IP- und SNA-Dienste
- Lastverteilung auf die Netzkomponenten in einem Sysplex-Verbund
- Kontrolle und Steuerung der VPN-Kommunikation
- Implementierung der Sicherheitskomponenten fr Applikationen
- Telnet-3270- und Secure-Telnet-3270-Untersttzung, Telnet/SSH zu den
Unix System Services des z/OS
- Untersttzung von IPv6 fr das z/OS-Betriebssystem
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Systems Network Architecture (SNA)

Ein Knoten im SNA-Netz ist durch eine Network Addressable Unit (NAU)
definiert. Die Wege zwischen den einzelnen Knoten werden in Form von
Routen konfiguriert. Die Weiterentwicklung des statischen SNA-Netzes,
Advanced Peer to Peer Networking (APPN) genannt, erlaubt den Einsatz
dynamischer Netzkonfigurationen hnlich dem TCP/IP-Netz.
Der Communications Server bildet eine Gateway-Funktion zwischen der heute
blichen IP-Netzinfrastruktur und den noch vielfach vorhandenen
SNA/APPN-basierenden Komponenten, wie z. B. TSO-, IMS- oder CICS-
Anwendungen.
SNA-Kommunikationsbeziehungen werden hufig ber das IP-Netz mittels
Enterprise Extender betrieben. Voraussetzung dafr ist APPN/HPR (High
Performance Routing).
Klassische SNA-Netze gelten als relativ sicher, da die Netzzugnge komplett
definiert sein mssen und das Gesamtnetz somit geschlossen ist. Als weiter-
fhrende Sicherheitsmanahme kann der Session Management Exit (SME)
von VTAM eingesetzt werden.
TCP/IP
TCP/IP ist unter den Unix System Services (USS) im z/OS implementiert. Der
TCP/IP-Service unter z/OS bietet hnliche Funktionen wie die IP-Dienste
anderer Unix-Versionen. ber den Telnet TN3270 IP-Service ist der Zugriff
auf SNA-basierende Anwendungen (TSO, CICS, IMS usw.) mglich. Unter
TCP/IP stehen fr z/OS eine ganze Reihe von Applikationen zur Verfgung,
wie z. B. ein HTTP-Webserver, Untersttzung fr File-Transfer via FTP, E-
Mail via SMTP, Network File System (NFS), Domain Name Service (DNS)
und weitere Services. TCP/IP untersttzt Verschlsselung ber IPSec, SSH
und TLS (SSL).
Durch den Einsatz von Dynamic VIPA (Virtual IP Address) wird es
ermglicht, dass beim Ausfall eines Systems innerhalb eines Parallel Sysplex
Clusters eine IP-Addresse automatisch von einem Backup-System
bernommen werden kann. Untersttzt die Anwendung diese Funktionalitt
auch, trgt dies wesentlich zur Erhhung der Verfgbarkeit bei.
Durch Einsatz des Workload Managers ist es darber hinaus mglich, eine
Lastverteilung der Netzdienste auf mehrere CPUs innerhalb eines Sysplex-
Verbundes zu erreichen.
TCP/IP gewinnt immer mehr an Bedeutung, wohingegen die Bedeutung des
SNA-Netzes abnimmt (speziell bei der Neuentwicklung von Applikationen).
Kerberos
z/OS untersttzt das Authentisierungssystem Kerberos.
AnyNet
Die Bezeichnung AnyNet steht fr zwei Funktionalitten, die mit dem
Communications Server ausgeliefert werden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- SNA over TCP/IP und

- AnyNet Sockets over SNA.
SNA over TCP/IP erlaubt es Applikationen, die nur das SNA-Protokoll unter-
sttzen, mit einem TCP/IP-Netz verbunden zu werden, ohne dass die Appli-
kationen angepasst werden mssen.
AnyNet Sockets over SNA erlaubt es Applikationen unter z/OS Unix System
Services (USS), Verbindungen ber ein vorhandenes SNA-Netz aufzubauen.
System Authorization Facility (SAF)
Die SAF ist ein Teil des z/OS-Betriebssystems und dient als Sicherheits-
schnittstelle zwischen dem System und dem Sicherheitssubsystem (z. B.
RACF, TopSecret, ACF2).
Resource Manager, z. B. IMS, DFHSM, JES oder CICS, fragen ber die SAF-
Schnittstelle bei RACF bzw. dem jeweiligen Sicherheitssubsystem an
(RACROUTE Macro), ob ein Anwender berechtigt ist, auf eine Ressource zu
zugreifen. SAF gibt die Antwort des Sicherheitssubsystems an den Resource
Manager zurck, woraufhin dieser den Zugriff gewhrt (Return Code ist
gleich Null) oder ablehnt (Return Code ist grer Null).
SecureWay Security Server fr z/OS
Der Secure Way Security Server fr z/OS bildet eine Sicherheitsplattform fr
das Mainframe-System. Der Secure Way Security Server umfasst folgende
Komponenten:
RACF (Resource Access Control Facility)
RACF ist eine Zusatz-Software zur Absicherung des z/OS-Betriebssystems.
RACF arbeitet mit Kennungen, Gruppen und Ressourcen (Dateien, Klassen),
die in der RACF-Datenbank eingetragen sein mssen. Anhand dieser Definiti-
onen regelt RACF nicht nur den Zugang zum System, sondern auch die
Zugriffe auf die Ressourcen. Jede Ressource, z. B. Datei, muss ber ein ent-
sprechendes RACF-Profil geschtzt sein. Durch den Einsatz von Platzhaltern
ist es mglich, mit einem generischen Profil eine Gruppe von Ressourcen zu
schtzen, womit die Verwaltung vereinfacht wird. Zugriffe auf diese so
geschtzten Ressourcen mssen dann entweder einzelnen Usern oder User-
gruppen durch die RACF-Administration vergeben werden.
Im RACF gibt es Attribute, die einem Besitzer hhere Rechte einrumen
knnen:
- SPECIAL - berechtigt zur Administration des RACF (Verwalten von
Gruppen, Kennungen und Ressourcen).
- OPERATIONS - fr Space Manager, mit diesem Recht knnen Dateien
verwaltet werden.
- AUDITOR - fr die berwachung der Ttigkeiten im Sicherheitsbereich
in der Funktion eines Audits.
Diese Rechte knnen zustzlich auf Gruppenebene vergeben werden (Group
Special, Group Operations, Group Auditor).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Fr die Berechtigung zur Nutzung interaktiver Programme, z. B. TSO oder

Unix System Services, bietet RACF zustzliche Segmente an. In diesen Seg-
menten werden die Rechte zur Nutzung der interaktiven Programme festge-
legt. Darber hinaus knnen Abrechnungsinformationen (Accounting) oder
Ressourcenbeschrnkungen (dem Anwender zur Verfgung stehender Haupt-
speicher, Anzahl zu startender Tasks) in diesen Segmenten festgeschrieben
werden.
Jeder Anwender (darunter fallen die Kennungen von Batch-Jobs, TSO-Usern
und Started Tasks) wird im laufenden System von RACF ber sogenannte
ACEEs (Accessor Environment Element) verwaltet. Das sind Kontrollblcke,
die bei der Initialisierung des Adressraumes angelegt werden.
Public Key Infrastructure (PKI)
RACF bietet den gesicherten Systemzugang mittels digitaler Zertifikate an.
Dies ist besonders fr den Einsatz im Internet/Intranet sinnvoll. RACF kann
Zertifikate erzeugen, signieren, prfen und verwalten. Die Zertifikate knnen
in der RACF-Datenbank oder in einer speziellen Hardware gespeichert wer-
den. Der Aufbau einer Public Key Infrastructure mit eigenen RACF-Zerti-
fikaten ist hiermit mglich. Auch der Zugang zu geschtzten Webserver-
Bereichen kann ber Zertifikate erfolgen.
Firewall Technologies
Die Firewall Technologies des Secure Way Security Server fr z/OS ermg-
lichen die Trennung interner und externer Netzbereiche. Sie untersttzen
folgende Funktionalitten:
- Packet Filter
- sichere Tunnel mit IPSec-Technik zum Aufbau von VPNs (Virtual
Private Networks)
- Socks Server
- FTP Proxy Server
- Network Address Translation (NAT) von einer internen zu einer externen
Adresse und zurck
Fr den Einsatz von IPSec wird zustzlich der Communications Server fr
z/OS bentigt.
LDAP
Zusammen mit dem Secure Way Security Server liefert IBM einen LDAP-
Server aus. Dieser untersttzt die gngigen LDAP-Clients und kann somit als
Auskunftssystem dienen. Zur Verwaltung groer Datenmengen kann sowohl
die RACF-Datenbank als auch eine unabhngige DB2-Datenbank eingesetzt
werden.
Distributed Computing Environment (DCE)
DCE ist eine Sammlung von Tools und Diensten, welche die Erstellung, Nut-
zung und Pflege von verteilten Anwendungen untersttzen. DCE unter z/OS
untersttzt das Distributed File System (DFS), welches innerhalb der DCE-
Umgebung die gemeinsame Nutzung von Daten (Sharing) erlaubt, und
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Network File System (NFS), welches unter anderem Unix-Workstations

gestattet, auf Daten der z/OS-Rechner zuzugreifen.
Integrated Cryptographic Service Facility (ICSF)
Das ICSF ist ein Software-Element, das mit der Krypto-Hardware und dem
Secure Way Security Server zusammenarbeitet, um die Ver- und Entschlsse-
lung zu beschleunigen.
Sysplex Failure Managements (SFM)
Die SFM Policy erkennt, ob Fehler an einem im Sysplex-Verbund arbeitenden
System aufgetreten sind und leitet gegebenenfalls entsprechende Manahmen
ein. Ohne SFM wird, falls eine Maschine im Verbund Probleme hat, eine
Nachricht an den Operator gesendet. Der Operator kann daraufhin das fehler-
hafte System aus dem Verbund nehmen und Recovery-Manahmen einleiten.
SFM erlaubt die Installation einer Policy, die bei bestimmten Fehlern automa-
tisch festgelegte Recovery-Aktionen initiiert und so den Betrieb der Maschine
aufrechterhalten kann.
Automatic Restart Manager (ARM)
Der ARM erlaubt ein schnelles Wiederherstellen von Subsystemen, die auf-
grund kritischer Ressourcen (z. B. Deadlocks) angehalten wurden. Hierdurch
werden die aktiven Systemeingriffe durch das Operating reduziert.
Global Resource Serialization (GRS)
GRS stellt in einer Multitasking/Multiprocessing-Umgebung sicher, dass der
Zugriff auf Ressourcen, die von mehr als einem Rechner benutzt werden,
koordiniert abluft. Im Rahmen einer Sysplex-Konfiguration sollte GRS in
jedem Fall eingesetzt werden.
GRS kann einerseits im RING-Modus konfiguriert werden. Dabei wird ein
RSA Message Control Block (Ring System Authority) sequentiell von z/OS-
System zu z/OS-System transportiert, in dem jedes System seine Anforderun-
gen eintrgt. Jedes System kopiert sich die RSA Message in den eigenen
Speicher, d. h. die Information ist nicht aktueller, als bei der zuletzt vorbeige-
kommenen RSA-Information.
Als weitere, modernere Konfiguration steht der STAR-Modus zur Verfgung.
Dabei sind alle z/OS-Systeme im Sysplex mit einer Lock Structure in der
Coupling Facility verbunden, wobei jedes z/OS-System nur die eigene Sicht
im lokalen Speicher halten muss. Die Abfrage nach Ressourcen durch GRS ist
im STAR-Modus effektiver als im RING-Modus.
Unix System Services (USS)
USS ist keine Unix-Portierung, sondern ein POSIX-kompatibles Subsystem
von MVS. Frher wurde es als Open Edition MVS vertrieben. Die Aufgabe
des USS Subsystems liegt im Betrieb POSIX-kompatibler Anwendungen.
Hierfr wurde das Hierarchical File System (HFS) und eine Unix Shell einge-
fhrt.Parallel zu HFS steht seit geraumer Zeit auch das Filesystem zFS zur
Verfgung, das fr alle neuen Entwicklungen benutzt wird (siehe auch nach-
folgendes Kapitel Dateisysteme und Zugriffsarten).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Unter USS laufen viele Programme, die auch unter POSIX-konformen Unix-
Betriebssystemen laufen knnen. So sind die Funktionen von TCP/IP fr z/OS
grtenteils unter USS realisiert. Ebenso steht ein HTTP-Webserver zur Ver-
fgung, der als Daemon unter USS oder als Started Task unter MVS laufen
kann.
System Managed Storage (SMS)
SMS vereinfacht das Verwalten von Daten auf Festplatten, indem diese Funk-
tion viele Aufgaben, z. B. das Anlegen von Dateien auf bestimmten Festplat-
ten, die Festlegung von Charakteristiken der Datasets usw., bernimmt.
Hierzu werden sogenannte ACS-Routinen (Automated Control Storage)
definiert, die nach vorgegebenen Regeln den Plattenspeicher verwalten.
Datasets werden dabei anhand ihrer Namensgebung in vorher festgelegte
Plattenpools gespeichert. Da Mainframe-Systeme nicht selten ber eine groe
Anzahl von Platten verfgen, vereinfacht SMS die Verwaltung der Dateien
auerordentlich. Die Verwaltung von SMS kann ber das interaktive Dialog-
System ISMF erfolgen (Interactive Storage Management Facility).
Im Rahmen des SMS-Konzepts gibt es eine Reihe von Software-Produkten,
die die effiziente Verwaltung von Daten in einer Umgebung mit dem z/OS-
Betriebssystem ermglichen (z. B. DFHSM- oder DFxxx-Produkte). Darber
hinaus stehen als Storage Management Funktionen eine Reihe von Dienst-
programmen zur Verfgung, die die Verwaltung der Datenbestnde unter-
sttzen.
Hierarchical Storage Manager (HSM)
HSM ist ein wesentlicher Bestandteil des SMS-Konzeptes von z/OS. Das Pro-
gramm-Produkt untersttzt die Verwaltung der z/OS-Dateien, die Daten-
sicherung sowie die effektive Nutzung von Speichermedien. Gesteuert ber
sogenannte Policies (Regel-Definitionen) werden von HSM zu vorgegebenen
Zeiten Dateien auf andere Medien verschoben (migriert) und dabei kompri-
miert. Es gibt zwei Migrations-Level:
- Migration-Level 1 auf HSM-eigene Platten
- Migration-Level 2 auf Bnder (in Roboterstationen) oder nach VTS
(Virtual Tape System)
Migrierte Dateien knnen erst wieder gelesen werden, wenn sie ber den
HSM wieder erstellt worden sind. Diese Funktion kann entweder manuell
initiiert werden oder erfolgt automatisch, wenn die Datei angesprochen wird
(Recall-Funktion).
Weiterhin knnen logische Dumps (bestimmte Dateien) oder Full Volume
Dumps (der Inhalt einer ganzen Festplatte) zu bestimmten Zeiten gestartet
werden und somit automatisch Datensicherungen durchgefhrt werden.
System Management Facility (SMF)
SMF ist die zentrale Protokollierungsfunktion im z/OS-Betriebssystem.
Nahezu alle Komponenten und auch viele ISV-Produkte (Independent
Software Vendor) schreiben SMF-Stze, in denen die Aktivitten protokolliert
werden. Auch RACF schreibt solche Stze. Hier ist besonders der Satztyp 80
wichtig fr sptere Auswertungen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Resource Measurement Facility (RMF)

RMF protokolliert das Systemverhalten in Bezug auf Kapazitt und Perfor-
mance. Die Protokolldaten werden als SMF-Stze gesichert und stehen fr
sptere Auswertungen zur Verfgung. RMF ist optional, alternative Pro-
gramme (Monitore) sind am Markt verfgbar.
Generalized Trace Facility (GTF)
Der Begriff Trace stellt die Mglichkeit dar, den Datenfluss zwischen zwei
Komponenten im System (z. B. einer Anwendung und einem Endbenutzer)
mitzuschreiben und in einer Datei zur spteren Auswertung zur Verfgung zu
stellen. GTF ist die zentrale Trace-Funktion von z/OS, die Traces von vielen
z/OS-Komponenten ermglicht. Darber hinaus werden auch Traces der Netz-
funktionen untersttzt. Zum Auswerten der Traces stehen verschiedene Pro-
gramme zur Verfgung, z. B. ACFTAP fr Netzanalysen. Fr Online-Traces
bietet sich auch NLDM an (Network Logical Data Manager), eine Kompo-
nente der NetView Software.
Transaktionsmonitore und Datenbanksysteme
IMS TM (Information Management System Transaction Monitor)
IMS TM wird die Transaktionskomponente des IMS-Systems genannt, mit der
die IMS-Transaktionen in einem IMS-System verwaltet und gesteuert werden.
(In lteren IMS-Versionen ist diese Funktion auch unter dem Krzel DC
bekannt.)
IMS DB (Information Management System Database)
IMS DB wird die Datenbankkomponente des IMS-Systems genannt, mit der
die IMS-Datenbanken in einem IMS-System verwaltet werden. Bei IMS-
Datenbanken handelt es sich um hierarchische Datenbankmodelle.
CICS TS (Customer Information Control System Transaction Server)
CICS TS ist ein weiterer Transaktionsmonitor. Mit CICS TS werden die
CICS-Transaktionen in einem System verwaltet und gesteuert. Als Datenbank
werden hufig VSAM-Files oder DB2-Datenbanken eingesetzt.
DB2 (Database 2)
DB2 ist ein Programmpaket, mit dessen Hilfe relationale Datenbanken erstellt
und verwaltet werden knnen. ber IMS TM, CICS TS oder ber die Sprache
SQL (Structured Query Language) knnen Daten in der Datenbank in
Tabellen abgelegt oder aus dieser Datenbank extrahiert werden.
IMS, CICS und DB2 sind nicht im Fokus des Bausteins S/390- und zSeries-
Mainframe und werden nur am Rande betrachtet.
File Transfer Protocol (FTP)
FTP-Programme erlauben den Transport von Daten sowohl zwischen z/OS-
Systemen, als auch zu und von anderen Plattformen.
FTP ist nicht im Fokus des Bausteins S/390- und zSeries-Mainframe und wird
nur am Rande betrachtet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Middleware
MQSeries (Message Queueing System)
MQSeries stellt eine Verbindung zwischen unterschiedlichen Applikationen
auf der Basis von Nachrichten (Messages) her, beispielsweise zwischen CICS,
IMS oder Batch-Applikationen. ber entsprechende APIs (Application Pro-
gramming Interfaces) werden die Nachrichten an MQSeries weitergegeben
und danach an die vorgegebenen Ziele ausgeliefert. Ist die Lieferung nicht
mglich, werden die Nachrichten zwischengespeichert (Queued) und erst dann
weitergeleitet, wenn der Verbindungsaufbau wieder mglich ist.
MQSeries ist nicht Gegenstand des Bausteins S/390- und zSeries-Mainframe.
Dateisysteme und Zugriffsarten
Dateien werden unter z/OS mit bestimmten Charakteristiken angelegt, z. B.
Gre, Art der Speicherung (innere Struktur), auf welcher Platte sich die Datei
befindet und unter welchem Dateinamen die Datei gespeichert und normaler-
weise zu finden ist. Insbesondere in Bezug auf die innere Struktur der Dateien
bestehen teilweise erhebliche Unterschiede zu anderen, hufig eingesetzten
Betriebssystemen. Nachfolgend die wichtigsten Dateitypen:
HFS (Hierarchical File System)
Das HFS-Filesystem ist mit typischen Unix-Dateisystemen vergleichbar. Es
wird in einem MVS Dataset abgelegt, das MVS-seitig mit den blichen
Werkzeugen verarbeitet werden kann (z. B. Datensicherung ber HSM).
Gegenber USS stellt sich das Filesystem hierarchisch dar. Daten in diesem
Filesystem werden im EBCDIC-Zeichensatz gespeichert.
z/OS File System (zFS)
Das zFS entspricht konzeptionell dem HFS, jedoch knnen hier mehrere File-
systeme in einem z/OS Dataset gespeichert werden und die Daten lassen sich
auch im ASCII-Zeichensatz abspeichern. Laut IBM ist zFS das strategische
Filesystem, in dem nur noch neue Funktionen entwickelt werden. zFS kann
bis jetzt nicht als Root-Filesystem verwendet werden.
MVS Physical Sequential (PS) Datasets
In dieser Art von Dataset knnen Daten nur sequentiell gelesen oder
geschrieben werden. Physical Sequential Datasets dienen im Systemumfeld
oft der Verarbeitung groer Datenmengen.
MVS Partitioned Organized (PO) Datasets
Partitioned Organized Datasets knnen mit einer Bibliothek verglichen
werden. In einem PO Dataset gibt es einen Index (Directory) und die
einzelnen Bcher (Member). Die Member enthalten die Informationen. Bei
hufigem Abspeichern von Membern muss die Datei zeitweise reorganisiert
werden. Dies kann durch die Benutzung einer PDSE-Datei (Partitioned Data-
set Enhanced) umgangen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Virtual Storage Access Method (VSAM)

Im z/OS-Betriebssystem stellt VSAM eine der wichtigsten Zugriffsmethoden
auf Dateien dar. Die Datenstze werden ber einen Index oder eine relative
Byte-Adresse gefunden. Vier VSAM-Dateiarten lassen sich unterscheiden:
- ESDS (Entry Sequenced Data Set)
- KSDS (Key Sequenced Data Set),
- RRDS (Relative Record Data Set) und
- LDS (Linear Data Set).
Weitere Zugriffsmethoden
Neben der allgemein bekannten VSAM-Methode gibt es weitere Methoden
wie Sequential Access Method (SAM) und Queued Sequential Access Method
(QSAM) sowie diverse andere Methoden, die hier wegen ihrer geringeren
Verbreitung nur am Rande erwhnt werden.
Server- und Client-Konzepte
Durch die Erweiterung des z/OS-Betriebssystems um den Unix System Server
(USS) knnen Rechner mit diesem Betriebssystem zustzliche Server- und
Client-Funktionen wahrnehmen. Beispiele fr solche Server-Funktionen sind
unter anderem der HTTP-Server, der FTP-Server oder der Domain Name
Server. Die FTP-Funktion lsst sich z. B. auch als Client einsetzen. Darber
hinaus wird das z/OS-System in heutigen 2-Schicht- oder 3-Schicht-Archi-
tekturen vielfach als Datenbank-Server eingesetzt, wo es mit anderen Platt-
formen kommuniziert.
Konfiguration des z/OS (OS/390)
I/O-Config
Die Eingabe-/Ausgabe-Konstellation eines z/OS-Betriebssystems wird im
Rahmen des HCD-Dialogs ber eine I/O-Konfiguration erstellt und ber das
Operator Facility (via HMC-Konsole) fr die jeweilige LPAR abgelegt. Zum
IML-Zeitpunkt ist bereits festgelegt, welche I/O-Profile fr die sptere Aus-
wahl zur Verfgung stehen. Ein dynamisches Nachkonfigurieren whrend des
Betriebs ist jederzeit mglich (siehe Manahme M 3.39 Einfhrung in die
zSeries-Plattform).
IPL Volume
Zum Starten eines z/OS-Betriebssystems bentigt das System ein spezielles
IPL-Volume, eine Platte mit einer speziellen Bootstrap-Routine, die die not-
wendigen Betriebssystemprogramme ldt und zum Starten bringt. Dieser Vor-
gang entspricht einem Boot-Vorgang bei Unix und nennt sich bei z/OS Initial
Program Load (IPL).
Parmlib / Proclibs
Eine (oder mehrere) Parameter-Datei(en) stehen ber den Parmlib-Mechanis-
mus zur Verfgung, um alle wesentlichen z/OS-Systemparameter zu definie-
ren. Dazu gehrt z. B., welche Subsysteme gestartet werden sollen, welche
Sicherheitsmechanismen aktiviert werden und welche Bibliotheken autorisiert
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sein sollen. Alle wichtigen System-Jobs - auch Started Tasks genannt - stehen
auf Prozedur-Bibliotheken (Proclibs) bereit, um zum Startzeitpunkt
aktiviertwerden zu knnen (siehe Manahme M 3.39 Einfhrung in die
zSeries-Plattform). Dieser Bereich muss sehr sorgfltig definiert und geschtzt
werden, da hier wesentliche Sicherheitsmechanismen verankert sind.
Kataloge
Dateien werden ber Kataloge gefhrt und dem System bekannt gegeben. Als
oberste Instanz existiert der Master-Katalog, an den ber Alias-Definitionen
verschiedene Benutzerkataloge angebunden sind.
Arbeitsdateien
Zur Minimalkonfiguration eines z/OS-Betriebssystems gehren mehrere
Arbeitsdateien, die bei Produktionsbeginn angelegt sein mssen:
- Syslog
- JES2/3 Spool und Checkpoint
- SMF-Dateien
- Log-Writer-Dateien
- Couple Datasets (bei Sysplex)
- Page Datasets zum Auslagern von Hauptspeicher
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.41 Einfhrung in Linux und z/VM fr zSeries-

Systeme
Neben den unter z/OS laufenden Unix System Services (USS) steht auch Linux
fr die zSeries-Hardware zur Verfgung.
Linux fr zSeries entspricht dem Linux fr andere Plattformen, die Modifika-
tionen im Kernel beziehen sich ausschlielich auf Anpassungen an die
zSeries-Hardware (Systemumgebung, CPU-Architektur und Hardware-
abhngige Treiber). Da das zSeries-Linux eine Portierung darstellt, arbeitet es
mit dem ASCII-Zeichensatz (im Gegensatz zum USS HFS-Dateisystem, das
im EBCDIC-Modus luft). Derzeit sind zwei Linux-Versionen fr diese Platt-
formfamilie erhltlich: eine 31 Bit-Version fr S/390-Hardware und eine
64 Bit-Version fr die zSeries-Hardware (das S/390-System ist zwar ein
32 Bit-System, die Software darauf luft jedoch mit 31 Bit, da das erste Bit
zur Umschaltung zwischen 24 Bit- und 31 Bit-Modus bentigt wird).
Betriebsarten von Linux unter zSeries
Es sind drei unterschiedliche Betriebsarten von Linux unter zSeries mglich:
- Linux Native auf zSeries Hardware
- Linux in einer zSeries LPAR
- Linux unter dem Trger-System z/VM
Linux Native auf zSeries Hardware
In dieser Betriebsart wird Linux als Single-System auf der zSeries Hardware
eingesetzt. Dies bedeutet, dass die gesamte zSeries Hardware vom Linux-
System benutzt wird. Single-Systeme stellen in der Praxis derzeit eher eine
Ausnahme dar.
Linux in einer zSeries LPAR
Bei dieser Variante erfolgt der Betrieb von Linux in einer LPAR (Logical
Partition) auf der zSeries-Maschine. Der LPAR-Mode der zSeries-Hardware
erlaubt den Betrieb von mehreren unabhngigen Betriebssystem-Installationen
auf einer zSeries-Maschine. Jede einzelne Partition verhlt sich wie eine
unabhngige Hardware. Auf diesen LPARs knnen unter anderem z/OS oder
Linux als Betriebssystem installiert werden.
Die Betriebsart Linux in einer zSeries LPAR kommt zum Beispiel in Betracht,
wenn zustzlich zu einem schon vorhandenen z/OS-Datenbank-Server Inter-
net-Applikationen, wie z. B. Webserver, betrieben werden sollen.
Die Konsolidierung von Linux und z/OS auf einem physischen zSeries-
System an Stelle zweier getrennter Systeme reduziert nicht selten den Auf-
wand fr die Installation und den Betrieb.
Linux unter dem Trger-System z/VM Linux unter z/VM
Es knnen mehrere Linux-Installationen auf einem zSeries-Rechner oder

innerhalb einer LPAR unter dem Trger-System z/VM betrieben werden. Das
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
z/VM stellt sogenannte virtuelle Maschinen zur Verfgung, unter denen die
einzelnen Linux-Installationen unabhngig von einander betrieben werden
knnen.
Die Betriebsart Linux unter dem Trger-System z/VM kommt zum Beispiel in
Betracht, wenn die z/Series-Hardware im Rahmen eines Server-Konsoli-
dierungsprojektes eingesetzt wird. Hierbei wird die Installation von Linux
durch das System-Cloning erleichtert. Es knnen viele Linux-Systeme parallel
auf einer Maschine betrieben werden. Darber hinaus erleichtert diese
Konstellation eine zentrale Kontrolle und Administration.
Communications Server for Linux on zSeries
Linux fr zSeries untersttzt ohne zustzliche Komponenten TCP/IP. Der
Communications Server for Linux on zSeries als separates Produkt ermglicht
zustzlich eine Kommunikation ber SNA oder TCP/IP mit anderen Systemen
in den folgenden Bereichen:
- Advanced Peer to Peer Networking (APPN)
- High Performance Routing (HPR)
- TN3270E Server
- Telnet Redirector
- SSL data encryption scalability
- Client Authentication
- Application Programming Support
- Advanced Program to Program Communication (APPC)
- Common Programming Interface for Communications (CPI-C)
Das Programm bietet den Administratoren und Bedienern Untersttzung bei
der Installation, Konfiguration und Problemanalyse.
HiperSockets
HiperSockets erlauben eine LPAR-bergreifende Kommunikation. Mit dieser
Funktion lsst sich innerhalb des Systems ohne eine zustzliche physische
Verbindung ein "systeminternes Netz" ber TCP/IP aufbauen.
Ein von Linux abgesetzter TCP/IP-Auftrag wird auf Maschinenebene abge-
fangen und an die adressierte Partition umgeleitet. Dies ist mit bertragungs-
raten von mehreren GByte/s mglich. Gegenber dem Linux-Betriebssystem
verhlt sich diese Kommunikationsschnittstelle wie ein herkmmliches
TCP/IP-Netz. Auch z/OS-Systeme in einer anderen LPAR lassen sich so mit
Linux-Systemen verbinden.
Integrated Facility for Linux (IFL)
Diese Hardware-Funktion gestattet den zustzlichen Einsatz von Linux auf
einem System. Die speziellen IFL-Prozessoren bringen zustzliche Rechen-
kapazitt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
IFL wird von PR/SM wie eine separate LPAR verwaltet, die jedoch nur
Linux-Betriebssysteme (oder z/VM mit Linux-Betriebssystemen) untersttzen
kann.
z/VM
Das Betriebssystem z/VM ermglicht eine - Software-basierte - Aufteilung
des Rechners in mehrere parallele Virtual Machines. z/VM verwaltet mit dem
Control Program (CP) die Hardware der Partition und stellt den Gast-
Betriebssystemen die Virtual Machines zur Verfgung.
Die Hardware-Zugriffe erfolgen ber das CP, das dem aufrufenden Betriebs-
system das Ergebnis in seiner gewnschten Form prsentiert.
Darber hinaus stellt z/VM das Conversational Monitoring System (CMS) zur
Verfgung, in dem z. B. Scripts ablaufen knnen, um korrektive Manahmen
durchzufhren oder neue Systeme zu aktivieren.
Linux-Sicherheitsaspekte
Hardware
Die Verbindung zwischen den Linux Betriebssystemen oder zwischen Linux
und z/OS-Systemen kann ber HiperSockets erfolgen. Diese sind integraler
Bestandteil der Hardware und ermglichen eine schnelle und - bei korrekter
Konfiguration - sichere TCP/IP-Verbindung.
Durch den z/VM-Einsatz wird die Bereitstellung und Absicherung der Hard-
ware zu einem Teil durch eine Software-Lsung ersetzt. Die Ressourcen sind
deshalb nicht als reale Hardware verfgbar, sondern werden virtuell in der
Software (z/VM) abgebildet. Dem entsprechend mssen die Ressourcen mit
Software-Mitteln abgesichert werden.
RACF/VM
Die Resource Access Control Facility for z/VM (RACF/VM) erweitert die
Standard-Security des z/VM um eine Zugriffskontrolle fr die Ressourcen des
z/VM-System. Daneben berprft es die Zugriffe auf die Systemressourcen
und die Virtual Machine.
DIRMAINT
Die zentrale Konfigurationsdatei von z/VM ist das z/VM-System-Directory.
Die Verwaltung dieser Datei wird von DIRMAINT untersttzt, wobei die
DIRMAINT-Funktion die folgenden Aufgabenbereiche abdeckt:
- Distributed Virtual Machine Management
- automatische Minidisk-Administration (Allokieren, Lschen, usw.)
- Untersttzung der Benutzer
- Auditing
- Backup/Recovery des Directory
Auch wenn das Directory mit einem herkmmlichen Editor bearbeitet werden
kann, ist DIRMAINT fr alle Installationen mit greren User-Anzahlen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
empfehlenswert, da die dialoggesttzte DIRMAINT-Funktion die Verwaltung

vereinfacht. Dies hilft bei der Vermeidung von Eingabefehlern.
Access Control
Die Steuerung der Zugriffskontrolle ist bei Linux im Wesentlichen ber drei
Mechanismen mglich:
- Permission Bits wie bei anderen Unix-Betriebssystemen
- Mandatory Access Control (MAC)
- Access Control Lists (ACLs)
Whrend die erste Methode in der Regel fr normale Sicherheitsanforderun-
gen ausreicht, sollten MAC und ACLs bei hheren Sicherheitsanforderungen
in Betracht gezogen werden. Fr MAC und ACLs sind zustzliche Software-
Komponenten erforderlich.
Pluggable Authentication Module (PAM)
Zur Zentralisierung der Benutzerverwaltung bietet es sich fr Linux auf
LPARs an, die Verwaltung der Userids ber ein z/OS-RACF abzuwickeln.
Dazu muss das Linux-System ber ein Pluggable Authentication Module
(PAM) verfgen und mit dem vorgeschalteten LDAP-Server des z/OS-RACF-
Systems ber die HiperSockets Verbindung aufnehmen.
Ist die Kennung im RACF administriert und sind User-ID und Passwort
korrekt, so wird der Zugang zu dem Linux-System freigegeben. Dateizugriffe
lassen sich jedoch nach wie vor nur ber die Sicherheitsmechanismen von
Linux (Permisson Bit) realisieren.
Transaction Processing Facility (TPF)
TPF ist ein weiteres Betriebssystem fr die zSeries-Plattform und stellt eine
Sonderform dar. Es handelt sich dabei um ein transaktionsorientiertes System,
das speziell im Bereich Flugzeugbuchung eingesetzt wird, wo es besonders
auf hohe Performance ankommt. Transaktionen laufen hierbei direkt im
Kernel-Modus.
TPF wird an dieser Stelle aus Grnden der Vollstndigkeit erwhnt und ist
nicht Gegenstand des Bausteins S/390- und zSeries-Mainframe.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.42 Schulung des z/OS-Bedienungspersonals

Verantwortlich fr Initiierung: Leiter IT, Leiter Personal
Verantwortlich fr Umsetzung: Administrator, Vorgesetzte
Der Betrieb von z/OS-Systemen ist komplex und so gestaltet, dass viele
Bereiche daran beteiligt sind. Es ist deshalb darauf zu achten, dass das
Bedienungspersonal die fr seine Ttigkeit bentigte Ausbildung erhlt.
Neben den Empfehlungen aus Manahme M 3.11 Schulung des Wartungs-
und Administrationspersonals sind fr die Mitarbeiter im z/OS-Bereich
zustzlich die folgenden Hinweise zu beachten:
- Die Administratoren sollten durch regelmige Teilnahme an
Schulungsmanahmen und Anwendertagungen entsprechend ihren
Aufgaben ausgebildet werden. Es sollte berlegt werden, die Ausbildung
anhand eines Schulungsplanes festzulegen.
- Zustzlich sollten RACF-Adminstratoren in allen sicherheitsrelevanten
Bereichen des z/OS-Systemes ausgebildet werden.
- Die Auditoren sollten entsprechend ihren Aufgaben geschult werden. Die
Aufgaben der Auditoren sind in Manahme M 2.291 Sicherheits-Berichts-
wesen und -Audits unter z/OS beschrieben.
- Es sollte berlegt werden, ob eine regelmige sicherheitstechnische Schu-
lung fr alle Mitarbeiter, die mit z/OS-Systemen arbeiten, durchgefhrt
werden sollte. Dabei sollte den Mitarbeitern das vorhandene Regelwerk,
die Sicherheitsdefinitionen und die Grnde, die zu den Sicherheitsma-
nahmen gefhrt haben, erlutert werden (Sensibilisierung fr ein Sicher-
heitsdenken).
- Werden alle Administratoren und Auditoren ihren Aufgaben entsprechend
ausgebildet?
- Ist ein Schulungsplan fr die Administratoren vorhanden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 3.43 Schulung der Administratoren des

Sicherheitsgateways
Ein Sicherheitsgateway stellt ein zentrales Element bei der Absicherung eines
Netzes gegen Gefhrdungen von auen dar. Deswegen ist es unerlsslich, dass
die Administratoren des Sicherheitsgateways ausreichend geschult sind, damit
sie in der Lage sind, alle gebotenen Funktionen und Sicherheitsmerkmale
optimal zu nutzen.
In den Schulungen sollten ausreichende Kenntnisse zu den fr die Einrichtung
und den Betrieb der Komponenten des Sicherheitsgateways notwendigen
Vorgehensweisen, Werkzeugen und Techniken vermittelt werden. Dies gilt
auch fr herstellerspezifische Aspekte zu einzelnen Produkten, die als
Komponenten des Sicherheitsgateways eingesetzt werden. Fr die
Anforderungen an die Schulungen fr Betriebssysteme von Rechnern, die als
Komponenten des Sicherheitsgateways eingesetzt werden sowie fr aktive
Netzkomponenten (insbesondere Router, die als Paketfilter Teil eines
Sicherheitsgateways sind) sollten die Hinweise in den jeweiligen Bausteinen
der Betriebssysteme beziehungsweise im Kapitel 7.11 Router und Switches
Allgemein sollten in den entsprechenden Schulungen folgende Elemente
enthalten sein:
- Grundlagen und Konzepte der Administration, Kenntnisse der Kommandos
zu Einrichtung, Betrieb, Wartung und Fehlersuche fr jede Komponente
des Sicherheitsgateways. Eine Schulung sollte eine ausgewogene
Mischung aus Theorie und Praxis darstellen.
- Grundlagen der IT-Sicherheit, insbesondere Vorsorgemanahmen,
Reaktion, Analyse und Incident Handling (siehe beispielsweise auch
Kapitel 3.8 Behandlung von Sicherheitsvorfllen)
- Angriffsszenarien (z. B. Denial of Service Angriffe, ARP-Spoofing, IP-
Spoofing, DNS-Spoofing, Viren und andere Schadsoftware)
- Grundlagen der Strukturierung von Netzen
- ISO/OSI Schichten Modell
- Grundlagen von IP und der damit zusammenhngenden Protokolle (IP-
Adressierung, Subnetting, IP, ICMP, TCP, UDP) und der verschiedenen
Mglichkeiten zur Filterung anhand der Header-Daten
- Grundlagen des Routing, statisches und dynamisches Routing, Grundlagen
der eingesetzten Routing-Protokolle und ihrer Sicherheitsaspekte
- Grundlagen der wichtigsten eingesetzten Protokolle der
Anwendungsschicht (beispielsweise SMTP, HTTP und HTTPS, Secure
Shell, SMB/CIFS) und der verschiedenen Mglichkeiten zur Filterung
anhand von Protokollbefehlen oder Befehlsparametern
- Grundlagen zum Thema Virtuelle Private Netze (VPN)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Grundlagen zum Thema Intrusion Detection/Intrusion Prevention

(IDS/IPS)
- Grundlagen zum Umgang mit verschlsselten Daten (Verschlsselung z. B.
mit HTTPS oder IPSec) und Mglichkeiten zur Behandlung verschlsselter
Daten
- Betrieb
- Management der Gerte, Werkzeuge
- Protokollierung
- Sicherung und Verwaltung von Konfigurationsdaten
- Fehlerbehebung
- Fehlerquellen und Ursachen
- Mess- und Analysewerkzeuge, Werkzeuge zur automatischen
berprfung der einzelnen Komponenten des Sicherheitsgateways
auf korrekte Funktion
- Teststrategien zur Fehlersuche
- Anforderungen an sichere Netzinstallationen
- Relevante rechtliche Aspekte wie Datenschutz, rechtliche Aspekte der
Netzanbindung (in Deutschland beispielsweise Teledienstegesetz) und
hnliche Regelungen
Auch wenn in einer Gruppe von Administratoren die Aufgaben so verteilt
sind, dass jeder Administrator nur einen bestimmten Verantwortungsbereich
hat, ist es unverzichtbar, dass alle Administratoren ein allgemeines
Grundwissen besitzen. Die individuellen Schwerpunkte knnen davon
ausgehend gezielt ausgebaut und gepflegt werden. Zu vielen Produkten gibt es
von den Herstellern oder spezialisierten Anbietern hierfr ein umfangreiches
Angebot an aufeinander aufbauenden und individuell vertiefenden Seminaren.
Das Angebot an qualifizierten Schulungen stellt ebenfalls ein Kriterium dar,
das bei der Entscheidung fr einen bestimmten Hersteller bercksichtigt
werden sollte.
Fr Schulungsmanahmen sollte bereits bei der Beschaffung von IT-
Komponenten ein Budget eingeplant werden und ein Schulungsplan fr
Administratoren erstellt werden. Die Inhalte einer Schulung sollten die
- Steht ein Budget fr Schulungsmanahmen zur Verfgung?
- Wurde ein Schulungsplan fr Administratoren in Anlehnung an die
erwhnten Punkte erstellt?
___________________________________________________________________ ..........................................
Manahmenkatalog Hardware/Software M4 Bemerkungen
___________________________________________________________________ ..........................................
M4 Manahmenkatalog Hardware und Software

M 4.1 Passwortschutz fr IT-Systeme ................................................. 1
M 4.2 Bildschirmsperre........................................................................ 2
M 4.3 Regelmiger Einsatz eines Viren-Suchprogramms.................. 3
M 4.4 Geeigneter Umgang mit Laufwerken fr
Wechselmedien und externen Datenspeichern .......................... 5
M 4.5 Protokollierung der TK-Administrationsarbeiten ................... 6.1
M 4.6 Revision der TK-Anlagenkonfiguration .................................... 8
M 4.7 nderung voreingestellter Passwrter ....................................... 9
M 4.8 Schutz des TK-Bedienplatzes .................................................. 10
M 4.9 Einsatz der Sicherheitsmechanismen von X-Windows ........... 11
M 4.10 Passwortschutz fr TK-Endgerte ........................................... 12
M 4.11 Absicherung der TK-Anlagen-Schnittstellen........................... 13
M 4.12 Sperren nicht bentigter TK-Leistungsmerkmale.................... 14
M 4.13 Sorgfltige Vergabe von IDs ................................................... 15
M 4.14 Obligatorischer Passwortschutz unter Unix............................. 16
M 4.15 Gesichertes Login .................................................................... 17
M 4.16 Zugangsbeschrnkungen fr Accounts und / oder
Terminals ................................................................................. 18
M 4.17 Sperren und Lschen nicht bentigter Accounts und
Terminals ................................................................................. 19
M 4.18 Administrative und technische Absicherung des
Zugangs zum Monitor- und Single-User-Modus..................... 20
M 4.19 Restriktive Attributvergabe bei Unix-Systemdateien
und -verzeichnissen.................................................................. 21
M 4.20 Restriktive Attributvergabe bei Unix-Benutzerdateien
und -verzeichnissen.................................................................. 22
M 4.21 Verhinderung des unautorisierten Erlangens von
Administratorrechten ............................................................... 23
M 4.22 Verhinderung des Vertraulichkeitsverlusts
schutzbedrftiger Daten im Unix-System................................ 25
M 4.23 Sicherer Aufruf ausfhrbarer Dateien...................................... 26
M 4.24 Sicherstellung einer konsistenten Systemverwaltung.............. 27
M 4.25 Einsatz der Protokollierung im Unix-System .......................... 28
M 4.26 Regelmiger Sicherheitscheck des Unix-Systems ................. 29
M 4.27 Passwortschutz am tragbaren PC ............................................. 31
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.28 Software-Reinstallation bei Benutzerwechsel eines

tragbaren PC ............................................................................ 32
M 4.29 Einsatz eines Verschlsselungsproduktes fr tragbare
PCs........................................................................................... 33
M 4.30 Nutzung der in Anwendungsprogrammen angebotenen
Sicherheitsfunktionen .............................................................. 35
M 4.31 Sicherstellung der Energieversorgung im mobilen
Einsatz...................................................................................... 36
M 4.32 Physikalisches Lschen der Datentrger vor und nach
Verwendung............................................................................. 37
M 4.33 Einsatz eines Viren-Suchprogramms bei
Datentrgeraustausch und Datenbertragung .......................... 38
M 4.34 Einsatz von Verschlsselung, Checksummen oder
Digitalen Signaturen ................................................................ 39
M 4.35 Verifizieren der zu bertragenden Daten vor Versand ............ 41
M 4.36 Sperren bestimmter Faxempfnger-Rufnummern ................... 42
M 4.37 Sperren bestimmter Absender-Faxnummern ........................... 43
M 4.38 Abschalten nicht bentigter Leistungsmerkmale..................... 44
M 4.39 Abschalten des Anrufbeantworters bei Anwesenheit .............. 45
M 4.40 Verhinderung der unautorisierten Nutzung des
Rechnermikrofons.................................................................... 46
M 4.41 Einsatz eines angemessenen PC-Sicherheitsproduktes............ 47
M 4.42 Implementierung von Sicherheitsfunktionalitten in der
IT-Anwendung......................................................................... 49
M 4.43 Faxgert mit automatischer Eingangskuvertierung.................. 50
M 4.44 Prfung eingehender Dateien auf Makro-Viren ...................... 51
M 4.45 Einrichtung einer sicheren Peer-to-Peer-Umgebung
unter WfW ............................................................................... 53
M 4.46 Nutzung des Anmeldepasswortes unter WfW und
Windows 95 ............................................................................. 56
M 4.47 Protokollierung der Sicherheitsgateway-Aktivitten............... 58
M 4.48 Passwortschutz unter Windows NT/2000................................ 59
M 4.49 Absicherung des Boot-Vorgangs fr ein Windows
NT/2000 System ...................................................................... 62
M 4.50 Strukturierte Systemverwaltung unter Windows NT............... 64
M 4.51 Benutzerprofile zur Einschrnkung der
Nutzungsmglichkeiten von Windows NT.............................. 74
M 4.52 Gerteschutz unter Windows NT/2000.................................... 79
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.53 Restriktive Vergabe von Zugriffsrechten auf Dateien

und Verzeichnisse unter Windows NT .................................... 81
M 4.54 Protokollierung unter Windows NT......................................... 88
M 4.55 Sichere Installation von Windows NT..................................... 92
M 4.56 Sicheres Lschen unter Windows-Betriebssystemen .............. 96
M 4.57 Deaktivieren der automatischen CD-ROM-Erkennung........... 98
M 4.58 Freigabe von Verzeichnissen unter Windows 95..................... 99
M 4.59 Deaktivieren nicht bentigter ISDN-Karten-
Funktionalitten ..................................................................... 101
M 4.60 Deaktivieren nicht bentigter ISDN-Router-
Funktionalitten ..................................................................... 102
M 4.61 Nutzung vorhandener Sicherheitsmechanismen der
ISDN-Komponenten .............................................................. 103
M 4.62 Einsatz eines D-Kanal-Filters ................................................ 104
M 4.63 Sicherheitstechnische Anforderungen an den
Telearbeitsrechner.................................................................. 105
M 4.64 Verifizieren der zu bertragenden Daten vor
Weitergabe / Beseitigung von Restinformationen ................. 110
M 4.65 Test neuer Hard- und Software.............................................. 113
M 4.66 Novell Netware - Sicherer bergang ins Jahr 2000 .............. 114
M 4.67 Sperren und Lschen nicht bentigter Datenbank-
Accounts ................................................................................ 116
M 4.68 Sicherstellung einer konsistenten Datenbankverwaltung ...... 117
M 4.69 Regelmiger Sicherheitscheck der Datenbank..................... 119
M 4.70 Durchfhrung einer Datenbankberwachung ........................ 121
M 4.71 Restriktive Handhabung von Datenbank-Links..................... 123
M 4.72 Datenbank-Verschlsselung .................................................. 124
M 4.73 Festlegung von Obergrenzen fr selektierbare
Datenstze.............................................................................. 126
M 4.74 Vernetzte Windows 95 Rechner ............................................ 128
M 4.75 Schutz der Registrierung unter Windows NT/2000............... 130
M 4.76 Sichere Systemversion von Windows NT ............................. 132
M 4.77 Schutz der Administratorkonten unter Windows NT ............ 134
M 4.78 Sorgfltige Durchfhrung von
Konfigurationsnderungen..................................................... 137
M 4.79 Sichere Zugriffsmechanismen bei lokaler
Administration ....................................................................... 138
M 4.80 Sichere Zugriffsmechanismen bei Fernadministration .......... 139
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.81 Audit und Protokollierung der Aktivitten im Netz .............. 140

M 4.82 Sichere Konfiguration der aktiven Netzkomponenten........... 143
M 4.83 Update/Upgrade von Soft- und Hardware im
Netzbereich ............................................................................ 145
M 4.84 Nutzung der BIOS-Sicherheitsmechanismen ........................ 146
M 4.85 Geeignetes Schnittstellendesign bei Kryptomodulen ............ 148
M 4.86 Sichere Rollenteilung und Konfiguration der
Kryptomodule ........................................................................ 150
M 4.87 Physikalische Sicherheit von Kryptomodulen ....................... 151
M 4.88 Anforderungen an die Betriebssystem-Sicherheit beim
Einsatz von Kryptomodulen .................................................. 152
M 4.89 Abstrahlsicherheit .................................................................. 153
M 4.90 Einsatz von kryptographischen Verfahren auf den
verschiedenen Schichten des ISO/OSI-Referenzmodells ...... 156
M 4.91 Sichere Installation eines Systemmanagementsystems.......... 163
M 4.92 Sicherer Betrieb eines Systemmanagementsystems .............. 165
M 4.93 Regelmige Integrittsprfung............................................. 168
M 4.94 Schutz der WWW-Dateien .................................................... 169
M 4.95 Minimales Betriebssystem..................................................... 171
M 4.96 Abschaltung von DNS ........................................................... 174
M 4.97 Ein Dienst pro Server............................................................. 175
M 4.98 Kommunikation durch Paketfilter auf Minimum
beschrnken ........................................................................... 176
M 4.99 Schutz gegen nachtrgliche Vernderungen von
Informationen......................................................................... 178
M 4.100 Sicherheitsgateways und aktive Inhalte ................................. 180
M 4.101 Sicherheitsgateways und Verschlsselung ............................ 182
M 4.102 C2-Sicherheit unter Novell 4.11 ............................................ 184
M 4.103 DHCP-Server unter Novell Netware 4.x ............................... 189
M 4.104 LDAP Services for NDS........................................................ 193
M 4.105 Erste Manahmen nach einer Unix-Standardinstallation....... 197
M 4.106 Aktivieren der Systemprotokollierung................................... 200
M 4.107 Nutzung von Hersteller-Ressourcen ...................................... 202
M 4.108 Vereinfachtes und sicheres Netzmanagement mit DNS
Services unter Novell NetWare 4.11 ..................................... 205
M 4.109 Software-Reinstallation bei Arbeitsplatzrechnern ................. 209
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.110 Sichere Installation des RAS-Systems................................... 210

M 4.111 Sichere Konfiguration des RAS-Systems .............................. 213
M 4.112 Sicherer Betrieb des RAS-Systems........................................ 217
M 4.113 Nutzung eines Authentisierungsservers beim RAS-
Einsatz.................................................................................... 223
M 4.114 Nutzung der Sicherheitsmechanismen von
Mobiltelefonen....................................................................... 225
M 4.115 Sicherstellung der Energieversorgung von
Mobiltelefonen....................................................................... 227
M 4.116 Sichere Installation von Lotus Notes ..................................... 228
M 4.117 Sichere Konfiguration eines Lotus Notes Servers ................. 230
M 4.118 Konfiguration als Lotus Notes Server.................................... 233
M 4.119 Einrichten von Zugangsbeschrnkungen auf Lotus
Notes Server........................................................................... 235
M 4.120 Konfiguration von Zugriffslisten auf Lotus Notes
Datenbanken .......................................................................... 237
M 4.121 Konfiguration der Zugriffsrechte auf das Namens- und
Adressbuch von Lotus Notes ................................................. 239
M 4.122 Konfiguration fr den Browser-Zugriff auf Lotus Notes....... 241
M 4.123 Einrichten des SSL-geschtzten Browser-Zugriffs auf
Lotus Notes............................................................................ 243
M 4.124 Konfiguration der Authentisierungsmechanismen beim
Browser-Zugriff auf Lotus Notes........................................... 246
M 4.125 Einrichten von Zugriffsbeschrnkungen beim Browser-
Zugriff auf Lotus Notes Datenbanken ................................... 249
M 4.126 Sichere Konfiguration eines Lotus Notes Clients.................. 250
M 4.127 Sichere Browser-Konfiguration fr den Zugriff auf
Lotus Notes............................................................................ 253
M 4.128 Sicherer Betrieb von Lotus Notes.......................................... 256
M 4.129 Sicherer Umgang mit Notes-ID-Dateien ............................... 259
M 4.130 Sicherheitsmanahmen nach dem Anlegen neuer Lotus
Notes Datenbanken ................................................................ 263
M 4.131 Verschlsselung von Lotus Notes Datenbanken.................... 265
M 4.132 berwachen eines Lotus Notes-Systems ............................... 268
M 4.133 Geeignete Auswahl von Authentikations-Mechanismen....... 270
M 4.134 Wahl geeigneter Datenformate .............................................. 273
M 4.135 Restriktive Vergabe von Zugriffsrechten auf
Systemdateien ........................................................................ 274
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.136 Sichere Installation von Windows 2000 ................................ 275

M 4.137 Sichere Konfiguration von Windows 2000............................ 278
M 4.138 Konfiguration von Windows 2000 als Domnen-
Controller............................................................................... 282
M 4.139 Konfiguration von Windows 2000 als Server........................ 285
M 4.140 Sichere Konfiguration wichtiger Windows 2000
Dienste ................................................................................... 288
M 4.141 Sichere Konfiguration des DDNS unter Windows 2000 ....... 291
M 4.142 Sichere Konfiguration des WINS unter Windows 2000........ 294
M 4.143 Sichere Konfiguration des DHCP unter Windows 2000 ....... 296
M 4.144 Nutzung der Windows 2000 CA............................................ 299
M 4.145 Sichere Konfiguration von RRAS unter Windows 2000 ....... 302
M 4.146 Sicherer Betrieb von Windows 2000 ..................................... 305
M 4.147 Sichere Nutzung von EFS unter Windows 2000 ................... 309
M 4.148 berwachung eines Windows 2000 Systems ........................ 313
M 4.149 Datei- und Freigabeberechtigungen unter Windows
2000 ....................................................................................... 317
M 4.150 Konfiguration von Windows 2000 als Workstation .............. 323
M 4.151 Sichere Installation von Internet-PCs .................................... 326
M 4.152 Sicherer Betrieb von Internet-PCs ......................................... 330
M 4.153 Sichere Installation von Novell eDirectory............................ 332
M 4.154 Sichere Installation der Novell eDirectory
Clientsoftware........................................................................ 335
M 4.155 Sichere Konfiguration von Novell eDirectory....................... 337
M 4.156 Sichere Konfiguration der Novell eDirectory
Clientsoftware........................................................................ 340
M 4.157 Einrichten von Zugriffsberechtigungen auf Novell
eDirectory .............................................................................. 341
M 4.158 Einrichten des LDAP-Zugriffs auf Novell eDirectory........... 345
M 4.159 Sicherer Betrieb von Novell eDirectory ................................ 348
M 4.160 berwachen von Novell eDirectory ...................................... 351
M 4.161 Sichere Installation von Exchange/Outlook 2000.................. 353
M 4.162 Sichere Konfiguration von Exchange 2000 Servern.............. 364
M 4.163 Zugriffsrechte auf Exchange 2000 Objekte ........................... 381
M 4.164 Browser-Zugriff auf Exchange 2000 ..................................... 386
M 4.165 Sichere Konfiguration von Outlook 2000.............................. 389
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.166 Sicherer Betrieb von Exchange/Outlook 2000 ...................... 413

M 4.167 berwachung und Protokollierung von Exchange 2000
Systemen................................................................................ 417
M 4.168 Auswahl eines geeigneten Archivsystems ............................. 424
M 4.169 Verwendung geeigneter Archivmedien ................................. 427
M 4.170 Auswahl geeigneter Datenformate fr die Archivierung
von Dokumenten.................................................................... 435
M 4.171 Schutz der Integritt der Index-Datenbank von
Archivsystemen ..................................................................... 442
M 4.172 Protokollierung der Archivzugriffe........................................ 444
M 4.173 Regelmige Funktions- und Recoverytests bei der
Archivierung .......................................................................... 446
M 4.174 Vorbereitung der Installation von Windows NT/2000
fr den IIS .............................................................................. 447
M 4.175 Sichere Konfiguration von Windows NT/2000 fr den
IIS .......................................................................................... 449
M 4.176 Auswahl einer Authentisierungsmethode fr
Webangebote ......................................................................... 452
M 4.177 Sicherstellung der Integritt und Authentizitt von
Softwarepaketen..................................................................... 457
M 4.178 Absicherung der Administrator- und Benutzerkonten
beim IIS-Einsatz .................................................................... 459
M 4.179 Schutz von sicherheitskritischen Dateien beim IIS-
Einsatz.................................................................................... 461
M 4.180 Konfiguration der Authentisierungsmechanismen fr
den Zugriff auf den IIS .......................................................... 463
M 4.181 Ausfhren des IIS in einem separaten Prozess ...................... 466
M 4.182 berwachen des IIS-Systems ................................................ 467
M 4.183 Sicherstellen der Verfgbarkeit und Performance des
IIS .......................................................................................... 471
M 4.184 Deaktivieren nicht bentigter Dienste beim IIS-Einsatz........ 474
M 4.185 Absichern von virtuellen Verzeichnissen und Web-
Anwendungen beim IIS-Einsatz ............................................ 476
M 4.186 Entfernen von Beispieldateien und Administrations-
Scripts des IIS ........................................................................ 479
M 4.187 Entfernen der FrontPage Server-Erweiterung des IIS............ 480
M 4.188 Prfen der Benutzereingaben beim IIS-Einsatz..................... 481
M 4.189 Schutz vor unzulssigen Programmaufrufen beim IIS-
Einsatz.................................................................................... 482
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.190 Entfernen der RDS-Untersttzung des IIS............................. 484

M 4.191 berprfung der Integritt und Authentizitt der
Apache-Pakete, ...................................................................... 486
M 4.192 Konfiguration des Betriebssystems fr einen Apache-
Webserver .............................................................................. 487
M 4.193 Sichere Installation eines Apache-Webservers...................... 489
M 4.194 Sichere Grundkonfiguration eines Apache-Webservers ........ 493
M 4.195 Konfiguration der Zugriffssteuerung beim Apache-
Webserver .............................................................................. 498
M 4.196 Sicherer Betrieb eines Apache-Webservers........................... 501
M 4.197 Servererweiterungen fr dynamische Webseiten beim
Apache-Webserver................................................................. 503
M 4.198 Installation eines Apache-Webservers in einem chroot-
Kfig ...................................................................................... 506
M 4.199 Vermeidung gefhrlicher Dateiformate ................................. 508
M 4.200 Umgang mit USB-Speichermedien........................................ 511
M 4.201 Sichere lokale Grundkonfiguration von Routern und
Switches................................................................................. 513
M 4.202 Sichere Netz-Grundkonfiguration von Routern und
Switches................................................................................. 517
M 4.203 Konfigurations-Checkliste fr Router und Switches ............. 523
M 4.204 Sichere Administration von Routern und Switches ............... 526
M 4.205 Protokollierung bei Routern und Switches ............................ 531
M 4.206 Sicherung von Switch-Ports................................................... 534
M 4.207 Einsatz und Sicherung systemnaher z/OS-Terminals ............ 536
M 4.208 Absichern des Start-Vorgangs von z/OS-Systemen............... 541
M 4.209 Sichere Grundkonfiguration von z/OS-Systemen.................. 543
M 4.210 Sicherer Betrieb des z/OS-Betriebssystems........................... 548
M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ......................... 552
M 4.212 Absicherung von Linux fr zSeries ....................................... 559
M 4.213 Absichern des Login-Vorgangs unter z/OS ........................... 562
M 4.214 Datentrgerverwaltung unter z/OS-Systemen........................ 563
M 4.215 Absicherung sicherheitskritischer z/OS-
Dienstprogramme................................................................... 565
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.216 Festlegung der Systemgrenzen von z/OS .............................. 567

M 4.217 Workload Management fr z/OS-Systeme ............................ 569
M 4.218 Hinweise zur Zeichensatzkonvertierung bei z/OS-
Systemen................................................................................ 570
M 4.219 Lizenzschlssel-Management fr z/OS-Software.................. 571
M 4.220 Absicherung von Unix System Services bei z/OS-
Systemen................................................................................ 572
M 4.221 Parallel-Sysplex unter z/OS ................................................... 574
M 4.222 Festlegung geeigneter Einstellungen von
Sicherheitsproxies.................................................................. 579
M 4.223 Integration von Proxy-Servern in das
M 4.224 Integration von Virtual Private Networks in ein
M 4.225 Einsatz eines Protokollierungsservers in einem
M 4.226 Integration von Virenscannern in ein
M 4.227 Einsatz eines lokalen NTP-Servers zur
Zeitsynchronisation................................................................ 609
M 4.228 Nutzung der Sicherheitsmechanismen von PDAs ................. 610
M 4.229 Sicherer Betrieb von PDAs.................................................... 612
M 4.230 Zentrale Administration von PDAs ....................................... 615
M 4.231 Einsatz zustzlicher Sicherheitswerkzeuge fr PDAs ........... 617
M 4.232 Sichere Nutzung von Zusatzspeicherkarten........................... 618
___________________________________________________________________ ..........................................
Manahmenkatalog Hardware/Software M 4.1 Bemerkungen
___________________________________________________________________ ..........................................
M 4.1 Passwortschutz fr PC und Server

Der Passwortschutz eines IT-Systems soll gewhrleisten, dass nur solche
Benutzer einen Zugriff auf die Daten und IT-Anwendungen erhalten, die eine
entsprechende Berechtigung nachweisen. Unmittelbar nach dem Einschalten
des IT-Systems muss der Berechtigungsnachweis erfolgen. Kann der Benutzer
die erforderliche Berechtigung nicht nachweisen, so verhindert der Passwort-
schutz den Zugriff auf das IT-System.
Realisiert werden kann der Passwortschutz an einem IT-System auf verschie-
dene Weise:
- Die meisten BIOS-Varianten bieten die Installation eines Boot-Passwortes
an. Bei Fehleingaben wird der Boot-Vorgang nicht fortgesetzt. Ein BIOS-
Passwort ist nicht schwer zu berwinden, schtzt aber vor Zufallsttern,
sollte also zumindest berall da eingesetzt werden, wo keine besseren
Zugriffsschutzmechanismen vorhanden sind (siehe auch: M 4.84 Nutzung
der BIOS-Sicherheitsmechanismen).
- Gute Betriebssysteme enthalten bereits Zugriffsschutzmechanismen. In den
meisten Fllen mssen diese aber noch aktiviert werden, beispielsweise
durch die Vergabe von Passwrtern fr alle Benutzer. Nheres hierzu
findet sich in den betriebssystem-spezifischen Bausteinen.
- Es wird Zusatzhardware oder -software installiert, die vor dem eigentlichen
Start des Rechners ein Passwort abfragt und bei falscher Passworteingabe
die weitere Nutzung des IT-Systems verhindert.
Fr den Umgang mit Passwrtern sind die Hinweise in M 2.11 Regelung des
Passwortgebrauchs zu beachten, insbesondere ist das Passwort regelmig zu
ndern.
- Ist auf den betroffenen Rechnern ein Passwortschutz installiert?
- Welche BIOS- Sicherheitsmechanismen sind aktiviert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.2 Bildschirmsperre
Unter einer Bildschirmsperre versteht man die Mglichkeit, die auf dem Bild-
schirm aktuell vorhandenen Informationen zu verbergen. Eine Bildschirmsper-
re sollte nur durch eine erfolgreiche Benutzerauthentikation, also z. B. eine
Passwortabfrage, deaktiviert werden knnen, damit bei einer krzeren Abwe-
senheit des IT-Benutzers ein Zugriffsschutz fr das IT-System gewhrleistet
wird.
Die Bildschirmsperre sollte sich sowohl manuell vom Benutzer aktivieren
lassen, als auch nach einem vorgegebenen Inaktivitts-Zeitraum automatisch
gestartet werden. Alle Benutzer sollten dafr sensibilisiert sein, dass sie die
Bildschirmsperre aktivieren, wenn sie den Arbeitsplatz fr eine kurze Zeit
verlassen. Bei lngeren Abwesenheiten sollten Benutzer sich abmelden.
Der Zeitraum, nach dem sich eine Bildschirmsperre wegen fehlender automatische Sperre bei
fehlenden Benutzer-
Benutzereingaben aktiviert, sollte gewisse Grenzen weder unter- noch ber- eingaben
schreiten. Der Zeitraum sollte nicht zu knapp gewhlt werden, damit die Bild-
schirmsperre nicht bereits nach kurzen Denkpausen anspringt. Dieser Zeit-
raum darf aber auf keinen Fall zu lang sein, damit die Abwesenheit des
Benutzers nicht von Dritten ausgenutzt werden kann. Eine sinnvolle Vorgabe
ist eine Zeitspanne von 15 Minuten. Das IT-Sicherheitsmanagement-Team
sollte Vorgaben fr die Einstellung der Wartezeit machen, die die Sicherheits-
anforderungen der jeweiligen IT-Systeme und deren Einsatzumgebung
bercksichtigen.
Die meisten Betriebssysteme enthalten bereits Bildschirmsperren. Bei deren Passwortabfrage
einschalten
Nutzung muss darauf geachtet werden, die Passwortabfrage zu aktivieren.
Eine passwortuntersttzte Bildschirmsperre wird von MS-Windows 3.x als
Bildschirmschoner angeboten. Die Dokumentation dazu sagt jedoch: "Ist eine
Non-Windows-Anwendung die aktuelle Anwendung, wird der Bildschirm-
schoner nicht automatisch aktiviert, unabhngig davon, ob die Anwendung in
einem Fenster, von der MS-DOS-Befehlszeile oder als Symbol ausgefhrt
wird." Unter Windows 95 aktiviert sich der Bildschirmschoner jedoch auch
bei DOS-Anwendungen. Neben MS-Windows gibt es weitere Produkte, die
einen passwortuntersttzenden Bildschirmschoner anbieten. Vor dem Einsatz
solcher Produkte ist zu berprfen, ob die Bildschirmsperre unter allen Appli-
kationen funktioniert.
Unter Unix kann eine Bildschirmsperre mit Programmen wie lock oder - unter
X-Windows - lockscreen erfolgen.
- Ist auf den betreffenden Rechnern eine Bildschirmsperre installiert?
- Wird die Bildschirmsperre konsequent eingesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.3 Regelmiger Einsatz eines Viren-

Suchprogramms
Zum Schutz vor Computer-Viren knnen unterschiedliche Wirkprinzipien
genutzt werden. Programme, die IT-Systeme nach bekannten Viren
durchsuchen, haben sich in der Vergangenheit als effektivstes und
wirksamstes Mittel in der Viren-Bekmpfung erwiesen. Von Vorteil ist, dass
neu erhaltene Software oder Datentrger schon vor dem ersten Einsatz geprft
werden knnen. Man kann daher eine Infektion mit bekannten Computer-
Viren grundstzlich vermeiden. Ein weiterer Vorteil ist, dass man durch das
Viren-Suchprogramm eine genauere Information ber den jeweils entdeckten
Virus erhlt. Die bekannten Viren sind durch Spezialisten analysiert worden,
so dass man wei, ob Schadensfunktionen vorhanden sind. Ein gutes Viren-
Suchprogramm muss daher nicht nur in der Lage sein, viele Viren zu finden,
sondern sie auch mglichst exakt identifizieren.
Zu beachten ist, dass Viren-Suchprogramme mit der Zeit ihre Wirksamkeit
verlieren, da sie nur die zu ihrem Erstellungszeitpunkt bekannten Computer-
Viren bercksichtigen, neu hinzugekommene jedoch meist nicht erkennen
knnen. Daher ist eine regelmige, mindestens vierteljhrliche
Aktualisierung des Viren-Suchprogramms erforderlich.
Durch Parametrisierung lassen sich bei Viren-Suchprogrammen Einstellungen
vornehmen, ber die festgelegt wird, welche Dateien geprft werden sollen
und in welchem Umfang die Prfung erfolgen soll. Hier ist es Aufgabe des IT-
Sicherheitsmanagements, die geeigneten Einstellungen zu ermitteln und den
Benutzern mitzuteilen bzw. als Voreinstellungen an diese weiterzugeben.
Ebenso wie andere Programme knnen Viren-Suchprogramme durch Aufruf
(transient) oder im Hintergrund (resident) genutzt werden. Die Betriebsart des
Suchprogramms hat entscheidenden Einfluss auf die Akzeptanz bei den
Benutzern und damit auf die tatschlich erreichte Schutzfunktion.
Beim transienten Betrieb muss das Viren-Suchprogramm durch den Benutzer
gestartet werden, der auerdem explizit festlegen muss, welche Datentrger
durchsucht werden sollen. Hierdurch knnen Infektionen erst im Nachhinein
festgestellt werden. Ein Viren-Schutz ist zwar grundstzlich mglich, jedoch
hngt die Wirksamkeit von der Sorgfalt der Benutzer ab.
Beim residenten Betrieb wird das Viren-Schutzprogramm beim Start des
Rechners in den Speicher geladen und verbleibt dort aktiv bis zum
Ausschalten. Es verrichtet seine Ttigkeit, ohne dass der Benutzer dabei
mitwirkt, er kann inzwischen seine eigentliche Arbeit, z. B. das Schreiben von
Texten, ausfhren. Diese Betriebsart hat erst in jngster Zeit mit dem
verstrken Einsatz von Windows-Programmen Bedeutung erlangt. Bei
Windows arbeitet die Verwaltung des Speichers effektiver als unter dem zuvor
vorwiegend genutzten MS-DOS. Die rasante technische Entwicklung hin zu
greren Speicherkapazitten der Computer untersttzte diesen Trend. Unter
MS-DOS waren speicherresidente Viren-Suchprogramme in ihrer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Leistungsfhigkeit von den Herstellern oft gegenber den transienten

vermindert, um Speicherplatz zu sparen. Der wichtigste Vorteil des residenten
Betriebes ist, dass die Sicherheitsmanahme (Viren-Suche) unabhngig vom
Benutzer wirksam ist. Dies erhht die Sicherheit. Gleichzeitig fhrt es zu
besserer Akzeptanz bei den Benutzern, da diese sich nicht aktiv um den
Virenschutz zu kmmern brauchen. Sie merken nicht einmal, dass im
Hintergrund das Schutzprogramm luft, solange kein Virus gefunden wird. Im
letzteren Falle wird die betroffene Datei fr den Zugriff gesperrt, d. h. der
Benutzer kann sie nicht verwenden, solange das Schutzprogramm aktiv ist.
Der Einsatz speicherresidenter Viren-Schutzprogramme unter Windows-
Betriebssytemen ist derzeit die beste Mglichkeit, sich vor Computer-Viren zu
schtzen, weil jede Datei vor ihrer Nutzung (ffnen zur Bearbeitung,
Kopieren, Drucken, Entpacken usw.) geprft und bei Viren-Befall gesperrt
werden kann.
Ein weitere prventive Manahme ist der Einsatz von Checksummen-
Prfprogrammen. Hierbei werden zum Schutz vor Vernderung von den zu
prfenden Dateien oder Systembereichen (z. B. Boot- und Partition-Sektor)
Prfsummen berechnet, die regelmig kontrolliert werden. Auf diese Weise
knnen nicht nur Verseuchungen mit bisher unbekannten Computer-Viren
erkannt werden, sondern auch andere unberechtigte Vernderungen an
Dateien.
Verhaltensregeln bei Auftreten eines Computer-Virus sind unter M 6.93
Notfallvorsorge fr z/OS-Systeme beschrieben.
- Wann wurde die letzte berprfung vorgenommen? Wurde das Ergebnis
dokumentiert?
- Wurden Computer-Viren gefunden? Wenn ja, so kann dies darauf hindeu-
ten, dass unerlaubt unautorisierte Software eingesetzt wurde.
- Wann wurde das eingesetzte Viren-Suchprogramm zuletzt aktualisiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.4 Geeigneter Umgang mit Laufwerken fr

Wechselmedien und externen Datenspeichern
Handelsbliche PCs sind heute in der Regel mit einem Diskettenlaufwerk und
einem CD-/DVD-ROM-Laufwerk bzw. CD-/DVD-Writer ausgestattet.
Zustzlich besteht die Mglichkeit, ber Schnittstellen externe Speicher-
medien anzuschlieen. Ein Beispiel sind USB-Memory-Sticks, die in die
USB-Schnittstelle gesteckt werden und von neueren Betriebssystemen (z. B.
fr Microsoft-Betriebssysteme ab Windows 2000) automatisch erkannt
werden. Durch solche Laufwerke fr Wechselmedien und externe Daten-
speicher ergeben sich folgende potentielle Sicherheitsprobleme:
- Der PC knnte von solchen Laufwerken unkontrolliert gebootet werden.
- Es knnte unkontrolliert Software von solchen Laufwerken eingespielt
werden.
- Daten knnten unberechtigt auf Wechselmedien kopiert werden.
Beim Booten von Wechselmedien oder beim Installieren von Fremdsoftware
knnen nicht nur Sicherheitseinstellungen auer Kraft gesetzt werden, sondern
der PC kann auch mit Computer-Viren und anderen Schadprogrammen infi-
ziert werden.
Diesen Gefahren muss durch geeignete organisatorische oder technische
Sicherheitsmanahmen entgegengewirkt werden. Hierfr bieten sich verschie-
dene Vorgehensweisen an, deren spezifische Vor- und Nachteile im Folgen-
den kurz dargestellt werden:
- Ausbau von Laufwerken
Der Ausbau der Laufwerke fr Wechselmedien bietet zwar den sichersten
Schutz vor den oben genannten Gefhrdungen, ist aber meist mit erheb-
lichem Aufwand verbunden. Weiterhin ist zu bercksichtigen, dass der
Ausbau unter Umstnden die Administration und Wartung des IT-Systems
behindert. Diese Lsung sollte in Betracht gezogen werden, wenn beson-
dere Sicherheitsanforderungen bestehen.
- Verschluss von Laufwerken
Fr einige Laufwerksarten gibt es abschliebare Einschubvorrichtungen,
mit denen die unkontrollierte Nutzung verhindert werden kann. Bei der
Beschaffung sollte sichergestellt werden, dass die Laufwerksschlsser fr
die vorhandenen Laufwerke geeignet sind und diese nicht beschdigen
knnen. Auerdem sollte darauf geachtet werden, dass die Schlsser her-
stellerseitig mit hinreichend vielen unterschiedlichen Schlsseln angeboten
werden. Nachteilig sind die Beschaffungskosten fr die Laufwerks-
schlsser und der Aufwand fr die erforderliche Schlsselverwaltung.
- Deaktivierung im BIOS bzw. Betriebssystem
Im BIOS bieten die meisten PCs Einstellmglichkeiten dafr, von welchen
Laufwerken gebootet werden kann. In Verbindung mit einem Passwort-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
schutz der BIOS-Einstellungen (siehe auch M 4.84 Nutzung der BIOS-

Sicherheitsmechanismen) kann dadurch das unkontrollierte Booten von
Wechselmedien unterbunden werden. Weiterhin knnen die vorhandenen
Laufwerke bei modernen Betriebssystemen einzeln deaktiviert werden.
Dies schtzt vor unberechtigter Nutzung, z. B. Installation von Fremdsoft-
ware oder Kopieren auf Wechselmedien.
Die Deaktivierung der Laufwerke im BIOS bzw. Betriebssystem hat den
Vorteil, dass keine Hardware-nderungen erforderlich sind. Die ent-
sprechenden Einstellungen im Betriebssystem knnen gegebenenfalls sogar
zentral vorgenommen werden. Wirksam ist diese Vorgehensweise jedoch
nur, wenn der Benutzer nicht ber die Berechtigungen im Betriebssystem
verfgt, um die Deaktivierung der Laufwerke rckgngig zu machen.
- Kontrolle der Schnittstellennutzung
Der Betrieb von externen Speichermedien wie USB-Memory-Sticks lsst
sich nur sehr schwer verhindern, wenn die verwendete Schnittstelle auch
fr andere (erlaubte) Zusatzgerte genutzt wird. So werden beispielsweise
Notebooks ausgeliefert, die zum Anschluss einer Maus nur die USB-
Schnittstelle zur Verfgung stellen. Dadurch ist es in der Regel nicht
sinnvoll, ein "USB-Schloss" zu verwenden oder die Schnittstelle durch
andere mechanische Manahmen zu deaktivieren.
Die Nutzung von Schnittstellen sollte daher durch entsprechende
Rechtevergabe auf Ebene des Betriebssystems oder mit Hilfe von
Zusatzprogrammen geregelt werden. Alternativ kann das Hinzufgen von
Gerten berwacht werden. Beim Anschluss von Datenspeichern an
externen Schnittstellen werden oft vom Betriebssystem Treiber bzw.
Kernelmodule geladen oder Eintrge in Konfigurationsdateien (wie der
Windows-Registry) erzeugt, die detektiert werden knnen. Einzelheiten
sind produkt- und betriebssystemspezifisch und werden in einer separaten
Manahme beschrieben (siehe auch M 4.200 Umgang mit USB-
Speichermedien ).
- Richtlinien fr die Nutzung
In vielen Fllen drfen die Benutzer die eingebauten Laufwerke fr
Wechselmedien oder Speichermedien an externen Schnittstellen durchaus
verwenden, die Nutzung ist jedoch durch entsprechende Richtlinien
reglementiert. Auf technischer Ebene sollte dann lediglich das Booten von
Wechselmedien im BIOS deaktiviert werden. Ausbau, Verschluss oder
Deaktivierung der Laufwerke im Betriebssystem kommen nicht in Frage.
In diesem Fall sollten die Richtlinien fr die Nutzung der Laufwerke und
Speichermedien so explizit wie mglich definiert werden. Beispielsweise
kann ein generelles Verbot ausgesprochen werden, nur das Kopieren
ffentlicher Text-Dokumente wird erlaubt. Die Richtlinien mssen allen
Benutzern bekannt gemacht und die Einhaltung kontrolliert werden. Die
Installation und das Starten von Programmen, die von Wechselmedien
eingespielt wurden, sollte untersagt und soweit wie mglich auch technisch
unterbunden werden (siehe auch M 2.9 Nutzungsverbot nicht
freigegebener Hard- und Software).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese rein organisatorische Lsung sollte nur dann gewhlt werden, wenn
die Benutzer hin und wieder oder regelmig auf die Laufwerke zugreifen
mssen. Anderenfalls sollte der Zugriff - wie oben beschrieben - durch
technische Manahmen unterbunden werden.
Bei der Auswahl einer geeigneten Vorgehensweise mssen immer alle Lauf-
werke fr Wechselmedien bercksichtigt werden, aber ebenso auch alle
Mglichkeiten, ber Vernetzung Daten auszutauschen, also insbesondere auch
E-Mail und Internet-Anbindungen. Wenn der PC ber eine Verbindung zum
Internet verfgt, ist es nicht allein ausreichend, alle Laufwerke fr Wechsel-
medien zu deaktivieren oder auszubauen. Besonderes Augenmerk ist auf den
Schutz vor Schadprogrammen, z. B. Computer-Viren oder Trojanische Pferde,
zu richten (siehe auch M 4.3 Regelmiger Einsatz eines Viren-
Suchprogramms).
Damit die Sicherheitsmanahmen akzeptiert und beachtet werden, mssen die
Benutzer ber die Gefhrdung durch Laufwerke fr Wechselmedien infor-
miert und sensibilisiert werden.
- Ist der Zugriff auf Wechselmedien unterbunden oder reglementiert?
- Sind die Benutzer ber alle Regelungen zum Umgang mit Laufwerken fr
Wechselmedien und externen Datenspeichern informiert?
- Ist sichergestellt, dass PCs nicht unkontrolliert von Wechselmedien
gebootet werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.5 Protokollierung der TK-Administrationsarbeiten

Alle Eingaben, die ber die Wartungseingnge der TK-Anlage vorgenommen
werden, sollten protokolliert werden. Dies kann entweder ber einen Proto-
kolldrucker und/oder auf anderen Speichermedien erfolgen. Auf die erzeugten
Protokolldateien darf der TK-Anlagenadministrator kein Schreibrecht
besitzen. Die vom Drucker erzeugten Ausdrucke sollten laufende Seitenzahlen
besitzen, die einzelnen Protokollmeldungen laufende Meldungsnummern.
Das BSI hat in Zusammenarbeit mit dem Zentralverband der Elektro- und
Elektronikindustrie (ZVEI) einen Katalog von Anforderungen erarbeitet, der
auch eine verbesserte Protokollierung beinhaltet. Dieser Katalog soll bei der
Beschaffung neuer TK-Anlagen fr Bundesbehrden zum Tragen kommen.
Bei vorhandenen TK-Anlagen sollte berprft werden, inwieweit die Her-
steller solche verbesserten Mglichkeiten als Update anbieten knnen.
- Findet eine Protokollierung statt?
- Besteht die Mglichkeit festzustellen, ob der Protokolldrucker ausgeschal-
tet wurde?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.6 Revision der TK-Anlagenkonfiguration (Soll-Ist-

Abgleich)
Verantwortlich fr Umsetzung: IT-Sicherheitsmanagement, Revisior
Nach jeder Konfigurationsvernderung, z. B. der Freigabe einer Berechtigung
fr einen Teilnehmer, sollte diese in eine Ist-Bestandsliste eingetragen werden.
Diese Liste kann per Hand oder automatisiert gefhrt werden. In regelmigen
(nicht unbedingt gleichmigen) Abstnden (z. B. alle 6 Monate) sollte diese
Ist-Bestandsliste zumindest stichprobenartig mit der Realitt verglichen
werden. Unstimmigkeiten sind mit Hilfe der Protokolle aufzuklren.
Insbesondere sollte kontrolliert werden, ob
- alle nicht vergebenen Rufnummern auch wirklich nicht eingerichtet sind,
- verbotene Berechtigungen auch nirgendwo vergeben sind,
- deaktivierte Leistungsmerkmale auch wirklich inaktiv sind,
- deaktivierte Dial-In-Funktionen auch wirklich inaktiv sind.
Das BSI hat in Zusammenarbeit mit dem Zentralverband der Elektro- und
Elektronikindustrie (ZVEI) einen Katalog von Anforderungen erarbeitet, der
unter anderem auch Forderungen nach einer besseren Untersttzung von
Revisionsttigkeiten beinhaltet. Dieser Katalog soll bei der Beschaffung neuer
TK-Anlagen fr Bundesbehrden zum Tragen kommen. Bei vorhandenen TK-
Anlagen sollte berprft werden, inwieweit die Hersteller solche verbesserten
Mglichkeiten als Update anbieten knnen.
- Ist es mglich, aus den Unterlagen heraus Angaben, beispielsweise ber
die Berechtigungen bestimmter Anschlsse, zu geben?
- Wann wurde die Dokumentation das letzte Mal an der Realitt berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.7 nderung voreingestellter Passwrter

IT-Sicherheitsmanagement, Leiter IT
Viele IT-Systeme, TK-Anlagen und Netzkoppelelemente (bspw. ISDN-
Router, Sprach-Daten-Multiplexer etc.) besitzen nach der Auslieferung durch
den Hersteller noch voreingestellte Standardpasswrter. Diese sollten als
erstes durch individuelle Passwrter ersetzt werden. Hierbei sind die
einschlgigen Regeln fr Passwrter zu beachten (vgl. M 2.11 Regelung des
Passwortgebrauchs).
Achtung: Bei einigen TK-Anlagen werden vorgenommene nderungen der
Konfiguration nur im RAM abgelegt. Dies gilt auch fr Passwortnderungen.
Daher ist nach einer solchen Operation stets eine Datensicherung vorzuneh-
men und eine neue Sicherungskopie zu erstellen. Unterbleibt dies, so ist nach
einem "Restart" der Anlage wieder das Standardpasswort gltig. Weiterhin
sollte berprft werden, ob nach Einrichten eines neuen Passworts das Stan-
dardpasswort tatschlich seine Gltigkeit verloren hat und nicht weiterhin fr
den Systemzugang genutzt werden kann.
- Ist die Anlage noch mit einem Standardpasswort versehen?
- Wurden die Sicherungskopien nach der Vergabe und Speicherung des
individuellen Passworts angelegt?
- Ist der Systemzugang mit dem Standardpasswort nach der Eingabe eines
neuen Passworts weiterhin mglich?
- Werden die einschlgigen Regeln zum "Passwort-Handling" beachtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.8 Schutz des TK-Bedienplatzes

Sollte die TK-Anlage mit Hilfe eines Bedien-PC administriert werden, so ist
dieser mindestens mit den fr PCs blichen Schutzmanahmen, siehe
Kapitel 5.1 DOS-PC (ein Benutzer), zu versehen.
Optional:
Sollte die TK-Anlage nicht ber ausreichende Sicherheitsfunktionen fr
Rechteverwaltung und Zugangsschutz verfgen, so kann berlegt werden,
marktgngige Zusatzeinrichtungen (Portcontroller) einzusetzen. Mit Hilfe
solcher Gerte knnen sichere Identifizierungs- und Authentisierungsver-
fahren realisiert werden.
- Ist der Bedien-PC mit einem Passwortschutz versehen?
- Steht der Bedien-PC in einer gesicherten Umgebung?
- Wer hat Zugang zum Bedien-PC?
- Wer hat Zugriffsrechte fr den Bedien-PC?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.9 Einsatz der Sicherheitsmechanismen von

X-Windows
Release 5 der X-Window-Software bietet nur wenige Manahmen, um die
Sicherheit bei der bertragung von Daten zwischen dem X-Server und dem
X-Client zu erhhen, so dass der Einsatz von X-Window-Software nur in einer
sicheren Umgebung empfohlen werden kann.
- Rechnerspezifische Zugriffskontrolle: Auf jedem X-Server gibt es eine Befehl xhost
Liste zugelassener Rechner, die mit dem Befehl xhost verndert werden
kann. Sie muss auf jeden Fall auf die Rechner beschrnkt bleiben, die einen
Zugriff auf den X-Server bentigen. Es sollte auf keinen Fall ein globaler
Zugriff mit xhost + ermglicht werden. Dies kann erreicht werden, indem
explizit Rechner in der xhost-Tabelle eingetragen werden. Darber hinaus
ist zu beachten, dass jeder Benutzer auf einem der zugelassenen Rechner
uneingeschrnkten Zugriff auf den X-Server hat. Diese Art der Zugriffs-
kontrolle kann deshalb nur dann empfohlen werden, wenn aus zwingenden
Grnden keiner der folgenden Mechanismen eingesetzt werden kann.
- Benutzerspezifische Zugriffskontrolle: Der X-Server Prozess lsst sich MIT-MAGIC-COOKIE
so konfigurieren, dass bei einem Login (z. B. mit Hilfe von xdm) ein NIS-Authentisierung
Schlssel generiert wird, der zur Authentisierung bei einer bertragung
zwischen Client und Server benutzt wird. Dieser Schlssel (MAGIC
COOKIE) wird im Heimatverzeichnis des Benutzers in der Datei
.Xauthority abgelegt und kann mit Hilfe des Befehls xauth an den X-Client
bertragen werden. Whrend allerdings der MIT-MAGIC-COOKIE-
Mechanismus nur als eine Art Passwort angesehen werden muss, das bei
seiner bertragung abgehrt werden kann, bietet ein in Verbindung mit
NIS angebotener und mit einer DES-Verschlsselung arbeitender Mecha-
nismus mehr Sicherheit und sollte deshalb bevorzugt werden.
- Zugriffskontrolle ber Secure Shell: Die Kommunikation zwischen X- abgesicherter Kanal
Client und X-Server kann auch ber einen abgesicherten Kanal einer ssh-
Verbindung erfolgen (siehe auch M 5.64 Nutzung von Secure Shell). Hier-
bei erfolgt sowohl eine rechnerbasierte als auch eine benutzerbasierte
Zugriffskontrolle. Die Authentisierungs- und Nutzdaten werden verschls-
selt. Fr einen sicheren Betrieb von X-Windows wird die Nutzung von
Secure Shell daher empfohlen.
Mit einem Zusatzprogramm knnen unter X-Windows die Tastendrcke eines Abhren von Tastatur-
eingaben
entfernten Rechners in Klarschrift bersetzt und eingesehen werden. Bei der
Benutzung des Programms xterm kann das Weiterleiten von Tastendrcken
verhindert werden, indem verhindert wird, dass KeyPress-Events, welche es
bekommt, noch an andere Applikationen weitergeleitet werden. Dafr muss
die secure keyboard-Option ber das xterm-Men eingeschaltet werden, so
dass das entsprechende Fenster exklusiven Zugriff auf die Tastatur hat.
- Wird verhindert, dass Benutzer durch den Befehl xhost + die rechner-
spezifische Zugriffskontrolle abschalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.10 Passwortschutz fr TK-Endgerte

Endgerte, insbesondere Telefone, knnen oft mit einem Passwortschutz ver-
sehen werden. Bei aktiviertem Passwortschutz stehen Leistungsmerkmale, wie
Rufumleitung, Heranholen von Rufen etc. erst nach Eingabe des Passwortes
zur Verfgung. Ohne die Kenntnis des Passwortes knnen in der Regel nur
interne Gesprche gefhrt werden. Um einen Missbrauch dieser Leistungs-
merkmale zu verhindern, sollte von dieser Mglichkeit des Passwortschutzes
immer Gebrauch gemacht werden.
- Knnen TK-Endgerte mit einem Passwortschutz versehen werden?
- Sind die Benutzer ber die Mglichkeit des Passwortschutzes aufgeklrt
worden?
- Wenn ja, wird diese Option in der Praxis genutzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.11 Absicherung der TK-Anlagen-Schnittstellen

Die Schnittstellen einer TK-Anlage, ber die Administrationsttigkeiten aus-
gefhrt werden knnen, stellen schtzenswerte Punkte dar. Sie sollten daher
besonders abgesichert werden. ber unbenutzte oder ungesicherte Schnitt-
stellen knnen von Unbefugten, etwa unter Zuhilfenahme eines Laptops,
Manipulationen am System durchgefhrt werden. Der Passwortschutz auf
einen TK-Bedienplatz oder PC-Gateway wre in einem solchen Fall
wirkungslos. Ziel ist es also, dies zu verhindern, zumindest aber den Versuch
erkennbar zu machen. Aus diesem Grund sollten die benutzten Schnittstellen
gut verschraubt und ggf. zustzlich verplombt werden. Unbenutzte Schnitt-
stellen knnen durch verschraubte und verplombte Abschlusskappen gesichert
werden.
- Sind alle Schnittstellen bekannt, ber die die TK-Anlage konfigurierbar
ist?
- Existieren an der Anlage frei zugngliche Schnittstellen?
- Sind die vorhandenen Anschlusskabel mechanisch an beiden Enden
gesichert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.12 Sperren nicht bentigter Leistungsmerkmale

Verantwortlich fr Initiierung: Behrden-/Unternehmensleitung,
TK-Anlagen-Verantwortlicher,
Der Umfang der verfgbaren Leistungsmerkmale sollte auf das notwendige
Minimum beschrnkt werden. Die Software nicht bentigter Leistungsmerk-
male sollte, wenn mglich, von der Anlage entfernt werden. Da dies in vielen
Fllen nicht mglich ist, knnen diese Leistungsmerkmale nur gesperrt
(deaktiviert) werden. Von Zeit zu Zeit sollte berprfte werden, ob diese
Leistungsmerkmale auch wirklich gesperrt sind.
- Werden freigegebene Leistungsmerkmale auf ihren tatschlichen Bedarf
geprft?
- Werden nicht genutzte und somit offensichtlich nicht erforderliche
Leistungsmerkmale gesperrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.13 Sorgfltige Vergabe von IDs

In Unix-Systemen werden anhand von Benutzer- und Gruppenkennungen von
Prozessen und Dateien unter anderem Verursacher von Aktionen festgestellt
und Rechte vergeben. Daher ist eine sorgfltige Vergabe dieser Kennungen
erforderlich.
Jeder Login-Name, jede Benutzer-ID (UID) und jede Gruppen-ID (GID) darf
nur einmal vorkommen. Auch nach dem Lschen eines Benutzers bzw. einer
Gruppe sollen Login-Name und UID bzw. GID fr eine bestimmte Zeit nicht
neu vergeben werden. Bei vernetzten Systemen muss auch system-
bergreifend darauf geachtet werden, dass Benutzernamen und IDs nicht
mehrfach vergeben werden. Dies ist insbesondere bei der Verwendung von
NFS wegen der Umsetzung der UIDs wichtig, damit keine Daten unberechtigt
gelesen werden knnen.
Jeder Benutzer muss Mitglied mindestens einer Gruppe sein. Jede in der Datei
/etc/passwd vorkommende GID muss in der Datei /etc/group definiert sein.
Jede Gruppe sollte nur die Benutzer enthalten, die unbedingt notwendig sind.
Dieses ist insbesondere fr die Systemgruppen (wie root, sys, bin, adm, news,
uucp, nuucp oder daemon) wichtig.
Logins mit UID 0 (Super-User) drfen auer fr den Systemadministrator root
nur fr administrative Logins nach vorher festgelegten Regeln vergeben
werden (siehe M 2.33 Aufteilung der Administrationsttigkeiten unter Unix).
Es ist sinnvoll, fr Login-Namen und UIDs bzw. GIDs Namenskonventionen
festzulegen. Weiterhin sollte regelmig berprft werden, ob alle UIDs
plausibel sind. Sie sollten also z. B. nur aus Ziffern stehen bzw. keine ungl-
tigen Kombinationen wie 00 oder 000 enthalten.
Die Dateien /etc/passwd und /etc/group sollten nicht mit Editoren bearbeitet
werden, da Fehler die Systemsicherheit stark beeintrchtigen knnen. Es
sollten ausschlielich die entsprechenden Administrationstools benutzt
werden, die allerdings sehr systemspezifisch sind.
- Nach welchen Regeln werden IDs vergeben?
- Werden die Dateien /etc/passwd und /etc/group regelmig auf Konsistenz
berprft?
- Stehen im UID-Feld von /etc/passwd wirklich Ziffern?
- Sind alle UIDs plausibel?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.14 Obligatorischer Passwortschutz unter Unix

Der Passwortschutz fr jeden Account auf einem Unix-Rechner stellt sicher,
dass nur ein berechtigter Benutzer sich unter seinem Login-Namen einloggen
kann, indem nach Eingabe des Login-Namens eine Authentisierung durch
Eingabe des Passworts erfolgt.
Bei der Verwendung von Passwrtern fr Benutzer und Gruppen sind die geeignete Version von
passwd verwenden
unter M 2.11 Regelung des Passwortgebrauchs beschriebenen Regeln zu
beachten. Es muss beachtet werden, dass bei einigen Systemen nur eine
begrenzte Zeichenanzahl bei der Passwort-Prfung bercksichtigt wird. Zur
Realisierung dieser Manahmen sollten nur Programmversionen von passwd,
die die Einhaltung dieser Regeln sicherstellen, oder administrative Manah-
men, z. B. Shellskripts und entsprechende cron-Eintrge, benutzt werden.
Als weitere Mglichkeit kann auch das Unix-Standard-Kommando passwd
durch andere Passwort-Programme mit erweiterter Funktionalitt ersetzt
werden. Dazu gehren auch die Public-Domain-Programme anlpasswd,
npasswd und passwd+, die bereits beim ndern des Passwortes durch den
Benutzer das neu gewhlte Passwort auf seine Gte testen und zurckweisen,
wenn dieses zu schwach ist. Sie sind z. B. ber den FTP-Server
ftp://ftp.cert.dfn.de/pub/tools/password/ erhltlich.
Die Passwrter sollen nicht in der allgemein lesbaren Datei /etc/passwd,
sondern in einer fr die Benutzer nicht lesbaren shadow-Passwortdatei
gespeichert sein. In jedem neueren Unix-System ist diese shadow-Mglichkeit
enthalten, aber leider nach einer Erstinstallation nicht immer aktiviert (so
muss z. B. unter RedHat Linux nach der Standardinstallation die Verwendung
der shadow-Passwortdatei mit dem Befehl pwconv aktiviert werden).
Die Datei /etc/passwd ist regelmig auf Benutzer-Kennungen ohne Passwort Benutzer-Kennungen
ohne Passwort sperren
zu untersuchen. Wird eine solche gefunden, ist der Benutzer zu sperren. Ist fr
Gruppen Passwortzwang vereinbart worden, so ist entsprechend die Datei
/etc/group zu prfen. Es empfiehlt sich jedoch, fr Gruppen keine Passwrter
zu vergeben und fr jede Gruppe nur so wenig Benutzer wie mglich einzu-
tragen. Das Wechseln zwischen Gruppen, in denen der Benutzer eingetragen
ist, wird dadurch erleichtert, und unberechtigtes Wechseln durch systema-
tisches Ausprobieren von Passwrtern mit Hilfe entsprechender Programme
ist nicht mglich.
Alle Logins, insbesondere diejenigen mit UID 0, sollten regelmig auf das
Vorhandensein und die Gte von Passwrtern getestet werden (siehe auch
M 2.11 und M 4.26). Neben den in M 4.26 Regelmiger Sicherheitscheck des
Unix-Systems beschriebenen Programmen knnen diese Logins auch z. B. mit
awk -F: {if ($3=="0") print $1} /etc/passwd
awk -F: {if ($2=="") print $1} /etc/passwd
ermittelt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wird die Benutzung von Passwrtern regelmig kontrolliert?
- Werden die Benutzer an der Wahl von schwachen Passwrtern gehindert
(z. B. mit anlpasswd)?
- Wie lange sind die Passwrter gltig?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.15 Gesichertes Login

Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement, Leiter
IT, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: Administrator, Administrator
Es sollte ein Login-Programm verwendet bzw. Optionen aktiviert werden, so
dass die folgenden Manahmen durchgefhrt werden knnen:
- Jeder Anwender muss eine eigene Kennung und ein eigenes Passwort
erhalten. Der Zugang ohne Kennung und Passwort darf nicht mglich sein.
Als Passwort-Ersatz kann die Authentisierung des Anwenders auch ber
elektronische Signaturen, Pass-Tickets oder hnliches erfolgen.
- Die Anzahl erfolgloser Login-Versuche wird beschrnkt.
- Nach jedem erfolglosen Login-Versuch vergrert sich die Wartezeit bis
zur nchsten Login-Aufforderung. Nach einer bestimmten Anzahl von
Fehlversuchen wird der Account und / oder das Terminal gesperrt. Dabei
ist zu bedenken, dass dadurch nicht der Administrator ausgesperrt werden
darf, es muss ihm an der Konsole eine Zugangsmglichkeit offen bleiben
(siehe auch M 1.32 Geeignete Aufstellung von Konsole, Gerten mit
austauschbaren Datentrgern und Druckern).
- Der Zeitpunkt des letzten erfolgreichen Logins wird dem Benutzer beim
Login gemeldet.
- Erfolglose Login-Versuche werden dem Benutzer beim Login gemeldet.
Eventuell sollte diese Meldung bei mehreren darauf folgenden Logins
wiederholt werden.
- Der Zeitpunkt des letzten Logouts wird dem Benutzer beim Login gemel-
det. Hierbei wird zwischen Logouts zu einem interaktiven Login und
solchen zu einem nicht-interaktiven Login (Logout von Hintergrund-
prozessen) unterschieden.
- Fr das Login ber Netze, in denen Passwrter unverschlsselt bertragen
werden, empfiehlt sich die zustzliche Verwendung von Einmalpasswr-
tern (siehe auch M 5.34 Einsatz von Einmalpasswrtern).
Spezielle Hinweise zur Absicherung des Login-Vorgangs unter z/OS finden z/OS
sich in der Manahme M 4.213 Absichern des Login-Vorgangs unter z/OS.
- Sind die Benutzer darauf hingewiesen worden, den Zeitpunkt des letzten
erfolgreichen Logins auf Plausibilitt zu berprfen?
- Wie hufig werden erfolglose Login-Versuche dem Benutzer gemeldet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.16 Zugangsbeschrnkungen fr Accounts und /

oder Terminals
Der Account und / oder das Terminal eines Benutzers sollen auerhalb der Sperre auerhalb der
Arbeitszeit
offiziellen Arbeitszeit gesperrt werden. Soweit das nicht mit vertretbarem
Aufwand mglich ist (zum Beispiel bei sehr unregelmigen oder hufig
wechselnden Arbeitszeiten), sollte die Sperrung zumindest zu den Zeiten
erfolgen, die grundstzlich auerhalb der Arbeitszeit liegen.
Falls Mitarbeiter nur an einem bestimmten Terminal oder IT-System innerhalb Beschrnkung auf be-
stimmte IT-Systeme
des Netzes arbeiten, ist die Nutzung der Benutzer-Kennung und des
dazugehrenden Passwortes auf diesen Rechner zu beschrnken, so dass ein
Einloggen von einem anderen Rechner aus ausgeschlossen ist. Insbesondere
sollte sich der Administrator nach Mglichkeit nur von der Konsole aus
anmelden. Dies kann auch technisch forciert werden (siehe auch M 4.21
Verhinderung des unautorisierten Erlangens von Administratorrechten).
Unter Unix ist fr Terminals der jeweilige Benutzer als Eigentmer des ent- Attributvergabe auf
Gertedateien
sprechenden Gertetreibers einzutragen. Sobald dieser sich ausgeloggt hat,
sollte automatisch wieder root Eigentmer werden. Nur der jeweilige
Benutzer sollte hierfr Leseberechtigung haben. Falls ein Benutzer Nachrich-
ten (z. B. mit talk) von anderen Systembenutzern empfangen mchte, muss er
ihnen Schreibberechtigung fr den Gertetreiber einrumen. Es ist zu ber-
prfen, ob dies unbedingt notwendig ist.
In PC-Netzen kann die Anzahl von gleichzeitigen Anmeldungen unter einem
Account von mehreren PCs aus beschrnkt werden. Zum Schutz vor dem
unbemerktem Eindringen von Angreifern sollte verhindert werden, dass sich
ein Benutzer an mehreren PCs gleichzeitig anmelden kann.
- Wurden Zeitfenster, d. h. temporre Zugangsbeschrnkungen, fr alle
Accounts und Terminals eingerichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.17 Sperren und Lschen nicht bentigter Accounts

und Terminals
Accounts, die ber einen lngeren Zeitraum nicht benutzt werden, sollten
gesperrt und spter gelscht werden. Wenn beim Lschen von Accounts
Dateien brig bleiben, die keinem existierenden Benutzereintrag mehr zuge-
ordnet sind, besteht die Gefahr, dass diese Dateien spter eingerichteten
Benutzern unberechtigt zugeordnet werden.
Beim Entfernen von Benutzern sind unter Unix die entsprechenden Eintrge in "verwaiste" Dateien
finden
/etc/passwd, /etc/group und das Heimatverzeichnis des Benutzers zu lschen.
Ebenso ist darauf zu achten, dass weitere Benutzereintrge in Dateien wie
/etc/hosts, shadow, u. a. gelscht werden. Die Daten des Heimatverzeichnisses
sollten vorher gesichert werden. Bei der Sperrung bzw. auf jeden Fall vor dem
Lschen eines Accounts sollte der betroffene Benutzer informiert werden.
Beim Lschen von Accounts ist darauf zu achten, dass auch die Dateien des
Benutzers gefunden werden, die nicht in seinem Heimatverzeichnis liegen.
Dies kann z. B. mit dem Programm find und der Option -uid erfolgen. Solche
Dateien mssen gelscht oder anderen Benutzern zugeordnet werden.
Weiterhin ist darauf zu achten, dass laufende Prozesse und noch anstehende
Auftrge gelscht werden, z. B. unter Unix in der crontab.
Ebenso sollten Terminals, die ber einen lngeren Zeitraum nicht benutzt
werden, gesperrt und spter entfernt werden.
Unter Unix sind vom System vorgegebene Logins (z. B. sys, bin, adm, uucp,
nuucp, daemon und lp), die nicht bentigt werden, zu sperren, indem in das
zugehrige Passwortfeld in der Datei /etc/passwd z. B. "LOCKED" einge-
tragen wird.
Wenn ein neu einzurichtender Benutzer seinen Account nur fr einen
begrenzten Zeitraum bentigt, sollte dieser nur befristet eingerichtet werden.
Es kann vorteilhaft sein, Accounts grundstzlich nur befristet einzurichten und
in regelmigen Abstnden (z. B. jhrlich) bei Bedarf zu verlngern.
Ist absehbar, dass ein Benutzer eines lokalen Netzes lngere Zeit abwesend ist
(Urlaub, Krankheit, Abordnung, ...), so sollte sein Account fr diese Zeit im
Netz-Server gesperrt werden, so dass das Arbeiten unter seiner Benutzer-
Kennung fr diese Zeit nicht mehr mglich ist. Jeder Benutzer sollte dem
Netzadministrator Zeiten lngerer Abwesenheit mitteilen.
- Wie wird berprft, welche Accounts lnger nicht benutzt wurden?
- Wird berprft, welche Accounts nicht mehr bentigt werden?
- Wird der Netzadministration mitgeteilt, dass ein Benutzer des Netzes fr
lngere Zeit abwesend sein wird?
- Wird sichergestellt, dass alle Dateien und Verzeichnisse gelschter
Accounts anderen Benutzern zugeordnet oder gelscht werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.18 Administrative und technische Absicherung des

Zugangs zum Monitor- und Single-User-Modus
Um das Aktivieren des Monitor-Modus und das Booten in den Single-User-
Modus zu verhindern, sollten folgende Manahmen ergriffen werden:
- Wenn es (abhngig von der Unix-Variante und der zugrunde liegenden BIOS-Passwort
Hardware) mglich ist, muss zum Schutz des Unix-Servers ein BIOS-
Passwort vergeben werden.
- Beim Booten in den Single-User-Modus sollte das Super-User-Passwort Super-User-Passwort
abgefragt werden, um Unberechtigten den Zugang zum Unix-Server zu
erschweren.
- Wenn Tastaturschlsser vorhanden sind, sollten diese zum Schutz der Tastaturschlsser
Systemkonsole benutzt werden, um den Zugang zum Monitor-Modus zu
verhindern.
- M 1.32 Geeignete Aufstellung von Konsole, Gerten fr austauschbare
Datentrger und Druckern
- M 4.21 Verhinderung des unautorisierten Erlangens von Administrator-
rechten
- Ist der Zugriff auf die Konsole durch Passwrter oder andere Manahmen
geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.19 Restriktive Attributvergabe bei Unix-

Systemdateien und -verzeichnissen
Die hier genannten Manahmen gelten fr Dateien und Verzeichnisse, fr die indirekt aufgerufene
Programme prfen
der Administrator zustndig ist, das heit fr solche, die entweder fr alle
Benutzer von Bedeutung sind oder die Administrationszwecken dienen. Es
reicht nicht aus, die Rechte eines Programms zu berprfen, es muss auch die
Rechtevergabe aller Programme berprft werden, die von diesem Programm
aus aufgerufen werden (insbesondere zur Vermeidung Trojanischer Pferde).
Die Attribute aller Systemdateien sollten mglichst so gesetzt sein, dass nur
der Systemadministrator Zugriff darauf hat. Verzeichnisse drfen nur die
notwendigen Privilegien fr die Benutzer zur Verfgung stellen.
Das s-Bit sollte nur gesetzt sein, wenn unbedingt erforderlich. Bei Shellskripts s-Bit vermeiden
soll das s-Bit nicht gesetzt sein. Das s-Bit darf nur vom Administrator gesetzt
werden, die Notwendigkeit hierfr ist zu begrnden und zu dokumentieren.
In Verzeichnissen, in denen alle Benutzer Schreibrechte haben mssen (z. B.
/tmp), sollte das t-Bit (Sticky-Bit) gesetzt sein.
Die Integritt aller bei Unix-Systemdateien und -verzeichnissen gesetzten Integritt prfen
Attribute sollte regelmig verifiziert werden, z. B. mit Tripwire oder USEIT
(siehe auch M 4.26 Regelmiger Sicherheitscheck des Unix-Systems).
- Wird die Attributvergabe bei Unix-Systemdateien regelmig berprft?
- Gibt es Listen, anhand derer diese berprfungen durchgefhrt werden?
- Ist das s-Bit nur dort gesetzt, wo es unbedingt erforderlich ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.20 Restriktive Attributvergabe bei Unix-

Benutzerdateien und -verzeichnissen
Die hier genannten Manahmen gelten fr Dateien und Verzeichnisse eines
Benutzers (incl. Mail-Dateien).
Die Benutzer sollten die Attribute ihrer Dateien und Verzeichnisse so setzen, Fremdzugriffe
verhindern
dass andere Benutzer nicht darauf zugreifen knnen. Wenn anderen Benutzern
der Zugriff erlaubt werden soll, sollten entsprechende Benutzergruppen
eingerichtet werden.
Fr benutzerspezifische Konfigurationsdateien wie .profile, .exrc, .login,
.cshrc sollte nur der jeweilige Eigentmer Rechte besitzen.
Auf Unix-Systemen haben diverse Programme benutzerspezifische Konfi-
gurationsdateien wie .exrc, .emacs oder .mailrc, die nach Programmaufruf
automatisch durchlaufen werden und Variablen und Optionen fr den
Benutzer setzen. Damit in diesen keine trojanischen Pferde installiert werden
knnen, sollte nur der jeweilige Eigentmer Zugriffsrechte besitzen.
Die Datei .exrc wird gelesen, bevor die Editoren ex oder vi gestartet werden.
Falls sich eine gleichnamige Datei im aktuellen Verzeichnis befindet, wird
diese bei einigen Unix-Versionen ausgewertet. Alle eingesetzten Unix-
Versionen mssen daraufhin berprft werden, da damit auch die Ausfhrung
von Betriebssystemkommandos bei jedem Editoraufruf mglich ist.
Das s-Bit sollte nur gesetzt sein, wenn unbedingt erforderlich. Bei Shellskripts s-Bit vermeiden
soll das s-Bit nicht gesetzt sein. Das s-Bit sollte nur nach Einbeziehung des
Administrators gesetzt werden, die Notwendigkeit hierfr ist zu begrnden
und zu dokumentieren.
umask
Mit umask (user file creation mode mask) wird fr jeden Benutzer festgelegt,
welche Attribute zur Regelung der Zugriffsrechte eine von ihm neu angelegte
Datei erhlt. In den benutzerspezifischen Konfigurationsdateien wie
/etc/profile oder den $HOME/.profile-Dateien sollte umask = 0027 (-rw-r-----)
oder umask = 0077 (-rw-------) eingestellt sein, damit die Dateiattribute fr
neu angelegte Dateien nur dem Erzeuger (und evtl. der Gruppe) Zugriffsrechte
geben.
Mail-Dateien
Die Attribute der Mail-Dateien sollten regelmig daraufhin berprft werden, Integritt prfen
ob nur der jeweilige Eigentmer auf die Dateien Zugriff hat. Die Integritt der
bei den Unix-Benutzerdateien und -verzeichnissen gesetzten Attribute sollte
regelmig verifiziert werden, z. B. mit Tripwire oder USEIT (siehe auch
M 4.26 Regelmiger Sicherheitscheck des Unix-Systems).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind die Benutzer ber die Bedeutung einer minimalen Rechtevergabe
informiert?
- Werden die gesetzten umask-Werte regelmig vom Administrator ber-
prft?
- Ist das s-Bit nur dort gesetzt, wo es unbedingt erforderlich ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.21 Verhinderung des unautorisierten Erlangens

von Administratorrechten
Durch den Befehl su kann jeder Benutzer Super-User-Rechte erlangen, wenn Zugriffe auf su be-
schrnken
er das entsprechende Passwort besitzt. Da die Anzahl fehlerhafter Versuche
bei su nicht beschrnkt ist, besteht ein erhhtes Risiko, dass das Passwort
durch systematisches Probieren mit Hilfe entsprechender Programme heraus-
gefunden wird. Deshalb sollte su nur fr den Super-User zugnglich sein.
Alternativ knnte ein modifiziertes su installiert werden, bei dem die Anzahl
erfolgloser Versuche beschrnkt ist, sich die Wartezeit bis zur nchsten
su-Aufrufmglichkeit nach jedem erfolglosen Login-Versuch vergrert und
nach einer bestimmten Anzahl von Fehlversuchen die Ausfhrmglichkeit
und / oder das Terminal gesperrt wird. Jede Verwendung des Befehls su sollte
protokolliert werden.
Wenn das System es zulsst, kann der Login-Name des Super-Users anders als
root genannt werden. Als zustzliche Super-User-Logins sollten aber nur
administrative Logins (siehe M 2.33 Aufteilung der Administrationsttigkeiten
unter Unix) geschaffen werden.
Der Administrator darf nur von der Konsole aus arbeiten, um zu verhindern, nur an der Konsole
administrieren
dass bei einem Abhren der Leitung sein Passwort bekannt wird. Unter Solaris
kann dies beispielsweise erreicht werden, indem die Datei /etc/default/login
entsprechend konfiguriert wird. Alternativ knnen Sicherheitsfunktionen
verwendet werden, die das Aussphen von Administratorpasswrtern
verhindern. Beispiele fr geeignete Mechanismen sind Secure Shell (siehe
Manahme M 5.64 Secure Shell) und Einmalpasswrter (siehe Manahme
M 5.34 Einsatz von Einmalpasswrtern).
Bei BSD-Unix kann sich root nur an Terminals einloggen, die in der Datei
/etc/ttytab als secure gekennzeichnet sind. Ist diese Option fr alle Terminal-
eintrge entfernt, kann sich ein Administrator an einem Terminal nur mit dem
Kommando su als root einloggen. Es sollte berlegt werden, eine Benutzer-
gruppe einzurichten, auf die die Ausfhrung des Kommandos su beschrnkt
ist.
Ist bei BSD-Unix die Konsole in der Datei /etc/ttytab als secure gekenn- Konsole nicht als secure
kennzeichnen
zeichnet, wird kein Passwort beim Hochfahren in den Single-User-Modus
abgefragt, daher muss dieser Eintrag unbedingt entfernt werden.
Die Datei /etc/ftpusers enthlt die Login-Namen, die sich nicht per ftp anmel- ftp fr administrative
Zugnge verbieten
den drfen. Bei ftp werden die Passwrter ber eine ungeschtzte Klartext-
verbindung bertragen. Daher sollten administrative Zugnge (root, bin,
daemon, sys, adm, lp, smtp, uucp, nuucp, etc.) hier eingetragen werden. Bei
einigen Standardinstallationen steht root nicht in dieser Datei.
Wenn ein Benutzer bzw. ein Benutzer-Programm eine Super-User-Datei s-Bit vermeiden
(Dateien mit Eigentmer root und gesetztem s-Bit) ausfhrt, erhlt dieser
Benutzer bzw. dieses Programm bei der Ausfhrung Super-User-Rechte. Das
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ist fr bestimmte Anwendungen erforderlich, kann aber unter Umstnden auch

missbruchlich benutzt werden. Deshalb ist darauf zu achten, dass nur die
notwendigsten Programmdateien Super-User-Dateien sind und keine weiteren
Super-User-Dateien von Dritten hinzugefgt werden.
Automatisches Mounten von Gerten fr austauschbare Datentrger:
Mit sich auf dem gemounteten Laufwerk befindenden s-Bit-Programmen kann automatisches Mounten
vermeiden
ein Benutzer Super-User-Rechte erlangen. Automatisches Mounten sollte
daher restriktiv gehandhabt werden. Manche Unix-Versionen bieten eine
Option des mount-Befehls, der dazu fhrt, dass das s-Bit fr das ent-
sprechende Filesystem ignoriert wird. Bei austauschbaren Datentrgern sollte
berlegt werden, diese Option anzuwenden.
Bei der Freigabe von Verzeichnissen, die von anderen Rechnern gemountet
werden drfen, sind die unter M 5.17 Einsatz der Sicherheitsmechanismen von
NFS beschriebenen Einschrnkungen zu beachten. Es sollten insbesondere
keine Verzeichnisse mit root-Rechten und nur bei Bedarf Verzeichnisse mit
Schreibrechten freigegeben werden.
- M 1.32 Geeignete Aufstellung von Konsole, Gerten fr austauschbare
Datentrger und Druckern
- M 4.18 Administrative und technische Absicherung des Zugangs zum
Monitor- und Single-User-Modus
- Ist der Befehl su nur fr den Administrator ausfhrbar?
- Wird die Verwendung des Befehls su automatisch protokolliert?
- Wer hat Schreibzugriff auf die entsprechenden Konfigurationsdateien?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.22 Verhinderung des Vertraulichkeitsverlusts

schutzbedrftiger Daten im Unix-System
Mit Unix-Befehlen wie ps, finger, who, last lassen sich Informationen ber Zugriff auf Kommandos
beschrnken
einen Benutzer (z. B. Arbeitsverhalten) ermitteln. Viele Unix-Derivate
enthalten dazu noch weitere Befehle wie z. B. listusers unter Solaris. Es ist zu
berlegen, ob das Ausfhren dieser Befehle fr jeden Benutzer erlaubt sein
soll (Datenschutz, Aussphen von Login-Namen u. .). Im Zweifelsfall sollte
der Zugriff auf diese Befehle beschrnkt werden.
Beim Aufruf von Kommandos drfen keine sensitiven Informationen als Passwrter nicht als
Kommandoparameter
Parameter mit eingegeben werden, wie z. B. ein Passwort, da andere Benutzer bergeben
mit ps diese Angaben sehen knnen.
Die Protokolldateien wie wtmp, utmp, wtmpx, utmpx, etc. sollten nach
Mglichkeit durch geeignete Zugriffsrechte vor unbefugtem Auslesen
geschtzt werden, da hieraus eine Vielzahl von Informationen ber die
Benutzer herausgelesen werden kann.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.23 Sicherer Aufruf ausfhrbarer Dateien

Es muss sichergestellt werden, dass nur freigegebene Versionen ausfhrbarer
Dateien und keine eventuell eingebrachten modifizierten Versionen
(insbesondere Trojanische Pferde) aufgerufen werden.
Daher soll das jeweils aktuelle Arbeitsverzeichnis (.) nicht als Pfad in der aktuelles Verzeichnis
nicht im Suchpfad
Variable PATH enthalten sein. Ausfhrbare Dateien sollen nur in dafr vorge-
sehenen Verzeichnissen gespeichert sein. In den in einer PATH-Variable ent-
haltenen Verzeichnissen darf nur der Eigentmer Schreibrecht haben. Dieses
soll regelmig berprft werden. Bei Unix-Systemen mit IFS-Variable soll
diese auf den Standardwert (space, tab und newline) gesetzt sein und insbe-
sondere nicht auf "/".
- Werden die PATH-Eintrge regelmig berprft?
- Befinden sich ausfhrbare Dateien verstreut im System?
- Sind die Regelungen fr ausfhrbare Dateien den Benutzern bekannt?
- Wird die Integritt der entsprechenden Konfigurationsdateien regelmig
verifiziert (z. B. mit Tripwire oder USEIT)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.24 Sicherstellung einer konsistenten

Systemverwaltung
Administrator
In vielen komplexen IT-Systemen, z. B. unter Unix oder in einem Netz, gibt
es eine Administratorrolle, die keinerlei Beschrnkungen unterliegt. Unter
Unix ist das der Super-User root, in einem Novell-Netz der SUPERVISOR
bzw. admin. Durch fehlende Beschrnkungen ist die Gefahr von Fehlern oder
Missbrauch besonders hoch.
Um Fehler zu vermeiden, soll unter dem Super-User-Login nur gearbeitet nicht unter Super-User-
Login arbeiten
werden, wenn es notwendig ist; andere Arbeiten soll auch der Administrator
nicht unter der Administrator-Kennung erledigen. Insbesondere drfen keine
Programme anderer Benutzer unter der Administrator-Kennung aufgerufen
werden. Ferner sollte die routinemige Systemverwaltung (zum Beispiel
Backup, Einrichten eines neuen Benutzers) nur mengesteuert durchgefhrt
werden knnen.
Durch Aufgabenteilung, Regelungen und Absprache ist sicherzustellen, dass Absprache unter den
Administratoren
Administratoren keine inkonsistenten oder unvollstndigen Eingriffe vor-
nehmen. Zum Beispiel darf eine Datei nicht gleichzeitig von mehreren
Administratoren editiert und verndert werden, da dann nur die zuletzt
gespeicherte Version erhalten bleibt.
Wenn die Gefahr des Abhrens von Leitungen zu Terminals besteht, sollte der Secure Shell verwenden
Administrator nur an der Konsole arbeiten, damit keine Passwrter abgehrt
werden knnen. Bei der Administration von Unix-Systemen kann eine
verschlsselte Kommunikation mit dem Protokoll Secure Shell erfolgen.
Hiermit ist eine gesicherte Administration von entfernten Arbeitsstationen aus
mglich (siehe auch M 5.64 Nutzung von Secure Shell).
Fr alle Administratoren sind zustzliche Benutzer-Kennungen einzurichten,
die nur ber die eingeschrnkten Rechte verfgen, die die Administratoren zur
Aufgabenerfllung auerhalb der Administration bentigen. Fr Arbeiten, die
nicht der Administration dienen, sollen die Administratoren ausschlielich
diese zustzliche Benutzer-Kennungen verwenden.
Alle durchgefhrten nderungen sollten dokumentiert werden, um diese nderungen dokumen-
tieren
nachvollziehbar zu machen und die Aufgabenteilung zu erleichtern (siehe
auch M 2.34 Dokumentation der Vernderungen an einem bestehenden
System). Fr die nachtrgliche berprfung durchgefhrter Administrator-
ttigkeiten kann mit dem Unix-Befehl script ein Protokoll der eingebenen
Befehle angefertigt werden. Dieser Befehl protokolliert die gesamte Terminal-
Sitzung in einer ASCII-Datei. Solch eine Datei kann dann bei Bedarf einem
elektronischen oder ausgedruckten Administrations-Journal beigefgt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wie ist sichergestellt, dass Eingriffe des Administrators nicht zu Inkon-
sistenzen fhren?
- Werden vor greren Eingriffen Backups gefahren?
- Haben die Administratoren zustzliche Benutzer-Kennungen mit einge-
schrnkten Rechten?
- Werden standardmig die zustzlichen Benutzer-Kennungen benutzt?
- Wird ein Administrations-Journal gefhrt? Werden dort alle nderungen
dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.25 Einsatz der Protokollierung im Unix-System

Die Protokollmglichkeiten des einzelnen Unix-Systems sind einzusetzen und
gegebenenfalls durch Programme oder Shellskripts zu ergnzen.
Folgende Manahmen sollen ergriffen werden:
- Die Protokoll-Dateien mssen regelmig ausgewertet werden. Die regelmige Auswertung
Auswertung sollte nicht immer zum selben Zeitpunkt erfolgen, um zu
verhindern, dass ein Angreifer diese Tatsache ausnutzt. Wenn z. B. der
Administrator jeden Tag um 17.00 Uhr die Systemaktivitten berprft,
kann ein Angreifer um 18.00 Uhr unbemerkt ttig werden.
- Je nach Art der protokollierten Ereignisse kann es erforderlich sein, automatische
Alarmierung
schnellstmglich einzugreifen. Damit der Administrator ber solche
Ereignisse (z. B. Protokolldatei zu gro, wichtige Serverprozesse abge-
brochen, mehrfach versuchte root-Logins whrend ungewhnlicher Tages-
zeiten, etc.) automatisch informiert wird, sollten halbautomatische
Logfileparser fr die Alarmierung eingesetzt werden (z. B. swatch,
logsurfer oder checksyslog).
- Soweit erforderlich, sollten die Protokolldateien gesichert werden, bevor
sie zu gro oder vom System gelscht werden.
- Informationen aus Dateien wie wtmp, utmp, wtmpx, utmpx, etc. sollten mit
Skepsis betrachtet werden, da diese Dateien leicht zu manipulieren sind.
- Die Datei-Attribute der Protokolldateien sollten so gesetzt sein, dass
Unberechtigte keine nderungen oder Auswertungen der Protokolle vor-
nehmen knnen.
- Folgende Protokolldateien sollten mindestens erstellt und kontrolliert
werden: Logins (auch Fehlversuche), Aufruf von su, Fehlerprotokollie-
rungsdatei / Protokollierung wichtiger Vorgnge (errorlog), Administra-
torttigkeiten (insbesondere von root ausgefhrte Befehle). Weitere Einzel-
heiten finden sich in M 4.106 Aktivieren der Systemprotokollierung.
Der Befehl last zeigt Login- und Logout-Informationen wie Zeitpunkt und
Terminal fr jeden Benutzer an. Der Administrator sollte mit diesem
Befehl regelmig berprfen, ob sich Benutzer auf ungewhnlichem Weg
anmelden, z. B. ber Modemleitungen oder ber FTP.
Wenn auf vielen Systemen Protokolldaten anfallen sollten, empfiehlt sich der dedizierter Loghost
Einsatz eines dedizierten Loghosts, der besonders abgesichert ist. Das Weiter-
leiten (Forward) der Syslog-Meldungen auf diesen Loghost muss in der
Syslog-Konfigurationsdatei aktiviert werden (siehe M 4.106 Aktivieren der
Systemprotokollierung).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die anfallenden Protokolldaten drfen nur benutzt werden, um die

ordnungsgeme Anwendung der IT-Systeme zu kontrollieren, nicht fr
andere Zwecke, insbesondere nicht zur Erstellung von Leistungsprofilen von
Benutzern (siehe auch M 2.110 Datenschutzaspekte bei der Protokollierung).
- Werden die Protokolldateien regelmig ausgewertet?
- Ist die Protokollierung noch aktiv und ausreichender Speicherplatz
vorhanden?
- Wird die Integritt der Konfigurationsdateien fr die Protokollierung
regelmig verifiziert und protokolliert (z. B. mit Tripwire oder USEIT)?
- Wie werden die Protokolldateien archiviert und gegen Manipulation und
unbefugte Einsichtnahme geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.26 Regelmiger Sicherheitscheck des Unix-

Systems
Unix-Betriebssysteme bieten standardmig verschiedene Sicherheitseigen- Tools verwenden
schaften an. Diese knnen jedoch nur zum Erfolg fhren, wenn sie sinnvoll
eingesetzt werden. Die hierfr notwendigen Einstellungen sollen mit Hilfe von
Tools automatisiert berprft werden, um
- Inkonsistenzen innerhalb eines Unix-Systems erkennen und beseitigen zu
knnen und
- den Systemverwalter in die Lage zu versetzen, das Unix-Betriebssystem
unter optimaler Ausnutzung der gegebenen Sicherheitsmechanismen zu
verwalten.
Diese Prfung kann mit im Unix-System vorhandenen Programmen, selbster-
stellten Shellskripts oder Public-Domain-Programmen erfolgen. Fr einige
Unix-Varianten sind auch kommerzielle Programme verfgbar.
Beispiele:
- pwck
Dieser Befehl gehrt zu den Standard-Betriebssystemkommandos. Mit
diesem Befehl nimmt man eine Konsistenzprfung der Datei /etc/passwd
vor. Es wird berprft, ob alle notwendigen Eintrge vorgenommen
wurden, ob das Login-Verzeichnis fr den Benutzer existiert und ob das
Login-Programm vorhanden ist. hnliche Funktionen beinhaltet unter
Solaris der Befehl logins, mit dem auch Accounts ohne Passwort gefunden
werden knnen.
- grpck
Mit diesem Befehl nimmt man eine Konsistenzprfung der Datei
/etc/group vor. Er gehrt ebenfalls zu den Standard-Betriebssystem-
kommandos. Es wird berprft, ob alle notwendigen Eintrge vorgenom-
men wurden, ob alle Mitglieder einer Gruppe auch in der Benutzer-
passwortdatei vorhanden sind und ob die Gruppennummer mit der dort
angegebenen bereinstimmt.
- tripwire
Mit diesem Programm knnen Integrittsprfungen von Dateien durch-
gefhrt werden. Dazu werden Prfsummen ber Dateien gebildet und in
einer Datenbank gespeichert. tripwire ist in verschiedenen kostenlosen
Versionen verfgbar.
- cops
Dieses Public-Domain-Programm dient zur berprfung der Sicherheit
von Unix-Systemen, z. B. werden verschiedene Systemeinstellungen,
Zugriffsrechte, SUID-Dateien etc. berprft und potentielle Sicherheits-
lcken aufgezeigt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- tiger
Mit diesem Public-Domain-Programm knnen Unix-Systeme hnlich wie
mit cops auf Sicherheitslcken berprft werden.
- SATAN
Mit diesem Public-Domain-Programm kann die Netz-Sicherheit analysiert
werden. Es berprft vernetzte Unix-Systeme auf bekannte, aber oftmals
nicht beseitigte Schwachstellen.
- BSI-Tool Sichere Unix-Administration (USEIT)
USEIT hat das BSI entwickeln lassen, um es Systemverwaltern zu
ermglichen, mit einem Tool die Sicherheitseinstellungen eines Unix-
Systems automatisiert zu berprfen. Es werden Prfungen der Konsistenz
von Systemdateien und des Systems selbst vorgenommen, die
Passwortstrke wird geprft und unsichere Prozesse festgestellt. Es werden
Prfsummen von Dateien und Dateiattributen erzeugt und geprft. Die
Netzsicherheit wird berprft und Penetrationstests knnen durchgefhrt
werden. Unsichere Ports und Dienste werden geprft. Die Protokollierung
wird berwacht. Kontrollen der eingespielten Hersteller-Patches und der
zutreffenden CERT-Verffentlichungen werden durchgefhrt. Weitere
Details zu USEIT knnen der IT-Grundschutz-CD entnommen werden.
- crack
Mit diesem Public-Domain-Programm berprft man, ob zu einfache,
leicht erratbare Passwrter vorhanden sind.
- Werden die Durchfhrung und die Ergebnisse des Sicherheitschecks doku-
mentiert?
- Welche Schwachstellen werden durch die eingesetzten Programme und
Shellskripts berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.27 Passwortschutz am tragbaren PC

Jeder tragbare PC sollte mit einem Passwortschutz versehen werden, der ver-
hindert, dass der PC unberechtigt benutzt werden kann. Die im Umgang mit
Passwrtern zu beachtenden Regeln sind in M 2.11 Regelung des Passwort-
gebrauchs aufgefhrt worden. Bei modernen tragbaren PCs sollte das BIOS-
Bootpasswort aktiviert werden, wenn dessen Nutzung mglich ist. Erst nach
Eingabe des korrekten Bootpasswortes wird der Rechner dann hochgefahren.
Ist keine Passwortroutine installiert, sollte, wenn keine Verschlsselung der
Daten erfolgt, die Speicherung von schutzbedrftigen Daten auf der Festplatte
verboten und deren Speicherung stattdessen nur auf Disketten zugelassen
werden. Diese Disketten sind dann getrennt vom tragbaren PC aufzube-
wahren, zum Beispiel in der Brieftasche.
Einige tragbare PCs sehen auch die Mglichkeit einer Pausenschaltung vor,
die ber eine spezielle Tastenkombination aktiviert werden kann. Erst nach
Eingabe des entsprechenden Passwortes ist die weitere Nutzung des tragbaren
PC mglich. Ist eine Pausenschaltung vorhanden, so sollte sie fr kurze
Arbeitsunterbrechungen genutzt werden. Ist es absehbar, dass die Unter-
brechung lnger dauert, ist der Rechner auszuschalten.
- Werden Passwrter fr tragbare PC benutzt? Werden die Regeln fr den
korrekten Umgang mit Passwrtern eingehalten?
- Wird bei der bergabe eines tragbaren PC das Passwort gewechselt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.28 Software-Reinstallation bei Benutzerwechsel

eines tragbaren PC
Wechselt der Benutzer eines tragbaren PC, so muss sichergestellt sein, dass
auf dem PC weder schutzbedrftige Daten noch Computer-Viren vorhanden
sind. Die Lschung von Daten kann durch vollstndiges berschreiben oder
mit Hilfe spezieller Lschprogramme vorgenommen werden. Ein aktuelles
Viren-Suchprogramm muss anschlieend zum Einsatz kommen. Beide
Vorgnge mssen fr alle benutzen Datentrger (Festplatte, Diskette)
durchgefhrt werden.
Es empfiehlt sich jedoch, die Festplatte des tragbaren PC neu zu formatieren
und anschlieend die erforderliche Software und Daten neu aufzuspielen.
Beim Formatieren von DOS-Datentrgern ist darauf zu achten, dass der Para-
meter /U (in DOS 6.2 enthalten) benutzt wird, damit das Formatieren nicht
ber den Befehl unformat wieder rckgngig gemacht werden kann.
- Wird vor der Formatierung sichergestellt, dass der vorhergehende Benutzer
keinerlei Daten von dem tragbaren PC mehr bentigt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.29 Einsatz eines Verschlsselungsproduktes fr

tragbare PCs
Um zu verhindern, dass aus einem trotz aller Vorsichtsmanahmen gestoh-
lenen tragbaren PC schutzbedrftige Daten ausgelesen werden knnen, sollte
ein Verschlsselungsprogramm eingesetzt werden. Mit Hilfe der marktgngi-
gen Produkte ist es mglich, einzelne Dateien, bestimmte Bereiche oder die
ganze Festplatte so zu verschlsseln, dass nur derjenige, der ber den gehei-
men Schlssel verfgt, in der Lage ist, die Daten zu lesen und zu gebrauchen.
Die Sicherheit der Verschlsselung hngt dabei von drei verschiedenen
Punkten zentral ab:
- Der verwendete Verschlsselungsalgorithmus muss so konstruiert sein,
dass es ohne Kenntnis des verwendeten Schlssels nicht mglich ist, den
Klartext aus dem verschlsselten Text zu rekonstruieren. Nicht mglich
bedeutet dabei, dass der erforderliche Aufwand zum Brechen des
Algorithmus bzw. zum Entschlsseln in keinem Verhltnis steht zum
dadurch erzielbaren Informationsgewinn.
- Der Schlssel ist geeignet zu whlen. Nach Mglichkeit sollte ein Schls-
sel zufllig erzeugt werden. Wenn es mglich ist, einen Schlssel wie ein
Passwort zu whlen, sollten die diesbezglichen Regeln aus M 2.11 Rege-
lung des Passwortgebrauchs beachtet werden.
- Der Verschlsselungsalgorithmus (das Programm), der verschlsselte Text
und die Schlssel drfen nicht zusammen auf einem Datentrger gespei-
chert werden. Es bietet sich an, den Schlssel einzeln aufzubewahren. Dies
kann dadurch geschehen, dass er auf einer Pappkarte in Form einer
Scheckkarte aufgeschrieben und anschlieend wie eine Scheckkarte im
Portemonnaie aufbewahrt wird. Werden die Schlssel auf Disketten
gespeichert, so sollten die Disketten getrennt vom tragbaren PC aufbewahrt
werden (z. B. in der Brieftasche).
Eine Verschlsselung kann online oder offline vorgenommen werden. Online
bedeutet, dass smtliche Daten der Festplatte (bzw. einer Partition) verschls-
selt werden, ohne dass der Benutzer dies aktiv veranlassen muss. Eine Offline-
Verschlsselung wird explizit vom Benutzer initiiert. Er muss dann auch ent-
scheiden, welche Dateien verschlsselt werden sollen. Zur Auswahl und
Nutzung von kryptographischen Verfahren sollte auch Kapitel 3.7 Krypto-
konzept beachtet werden.
Fr den Bereich der ffentlichen Verwaltung kann das BSI fr den Einsatz auf
stationren und tragbaren PCs ein Offline-Verschlsselungsprogramm unter
gewissen Randbedingungen zur Verfgung stellen, das den Sicherheits-
anforderungen im Bereich des mittleren Schutzbedarfs gengt. Ein Anforde-
rungsvordruck befindet sich im Teil Hilfsmittel des vorliegenden
IT-Grundschutzhandbuchs.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die Benutzer im Umgang mit dem Verschlsselungsprogramm
geschult?
- Werden Daten und Schlssel getrennt aufbewahrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.30 Nutzung der in Anwendungsprogrammen ange-

botenen Sicherheitsfunktionen
Einige der Standardprodukte im PC-Bereich bieten eine Reihe von ntzlichen
IT-Sicherheitsfunktionen, deren Gte im einzelnen unterschiedlich sein kann,
aber Unbefugte behindern bzw. mgliche Schden verringern. Im folgenden
seien fnf dieser Funktionen kurz erlutert:
- Passwortschutz bei Programmaufruf: das Programm kann nur gestartet
werden, wenn vorher ein Passwort korrekt eingegeben wurde. Dies
verhindert die unberechtigte Nutzung des Programms.
- Zugriffsschutz zu einzelnen Dateien: das Programm kann nur dann auf eine
geschtzte Datei zugreifen, wenn das mit dieser Datei verknpfte Passwort
korrekt eingegeben wird. Dies verhindert den unerlaubten Zugriff mittels
des Programms auf bestimmte Dateien.
- Automatische Speicherung von Zwischenergebnissen: das Programm
nimmt eine automatische Speicherung von Zwischenergebnissen vor, so
dass ein Stromausfall nur noch die Datennderungen betrifft, die nach
dieser automatischen Speicherung eingetreten sind.
- Automatische Sicherung der Vorgngerdatei: wird eine Datei gespeichert,
zu der im angegebenen Pfad eine Datei gleichen Namens existiert, so wird
die zweite Datei nicht gelscht, sondern mit einer anderen Kennung
versehen. Damit wird verhindert, dass versehentlich eine Datei gleichen
Namens gelscht wird.
- Verschlsselung von Dateien: das Programm ist in der Lage, eine Datei
verschlsselt abzuspeichern, so dass eine unbefugte Kenntnisnahme
verhindert werden kann. Die Inhalte der Datei sind damit nur denjenigen
zugnglich, die ber den verwendeten geheimen Kryptierschlssel
verfgen.
- Automatisches Anzeigen von Makros in Dateien: diese Funktion soll das
unbeabsichtigte Ausfhren von Makros verhindern (Makro-Viren).
Je nach eingesetzter Software und damit vorhandenen Zusatzsicherheitsfunk-
tionen kann der Einsatz dieser Funktionen sinnvoll sein. Fr mobil eingesetzte
IT-Systeme bietet sich insbesondere die Nutzung des Passwortschutzes bei
Programmaufruf und die automatischen Speicherung an.
- Welche Sicherheitsfunktionen bieten die eingesetzten Softwareprodukte?
- Welche dieser Funktionen werden regelmig genutzt?
- Werden die Benutzer auf diese Funktionen hingewiesen?
- Werden die sicherheitsrelevanten Hinweise in Handbchern oder Zertifi-
zierungsreports beachtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.31 Sicherstellung der Energieversorgung im

mobilen Einsatz
Verantwortlich fr Initiierung: Benutzer
Um die Energieversorgung eines tragbaren PC oder PDAs auch im mobilen

Einsatz aufrechterhalten zu knnen, werden blicherweise Akkus oder Batte-
rien eingesetzt. Je nach Kapazitt des Akkus bzw. der Batterie und Bauweise
des mobilen Endgertes reicht dies fr einen beschrnkten Zeitraum, z. B.
einige Stunden, aus. Damit nach Abfall der Betriebsspannung keine Daten in
flchtigen Speichern verloren gehen, sollten einige Randbedingungen ein-
gehalten werden:
- Die Warnanzeigen des mobilen Endgertes (falls vorhanden), die den
Spannungsabfall anzeigen, drfen nicht ignoriert werden. Die Warnan-
zeigen sollten so konfiguriert sein, dass nach der ersten Warnung noch
gengend Zeit vorhanden ist, um eine Datensicherung durchzufhren.
- Falls es absehbar ist, dass der mobile Einsatz lngerfristig ist, sind auflad-
bare Batterien vorher nachzuladen und ggf. geladene Ersatzbatterien mitzu-
fhren.
- Gerade bei lteren Akkus sind die Gebrauchzeiten verkrzt und die Entla-
dung gegen Ende der Kapazitt kann sehr schnell erfolgen. Beim Betrieb
mssen daher regelmige Datensicherungen durchgefhrt werden, um
Datenverlust zu vermeiden. Da sich solche Akkus auch im Stand-by-
Modus schnell entladen knnen, sollte der Ladezustand regelmig kon-
trolliert und Sicherungen der Konfigurationsdaten des Laptops oder PDAs
fr den Notfall mitgefhrt werden. Ein baldiger Austausch des Akkus
gegen einen neuwertigen ist empfehlenswert, sobald solche Alterser-
scheinungen auftreten.
- Beim Laden sollten die Hinweise im Handbuch des mobilen IT-Systems
beachtet werden, damit die Lebensdauer des Akkus nicht beeintrchtigt
wird.
- Vor einer Reise bzw. bei der bergabe eines mobilen IT-Systems ist der Ladezustand regelmig
berprfen
ausreichende Ladezustand der Akkus oder Batterien sicherzustellen. Der
Ladezustand der Akkus sollte regelmig berprft werden, da sich ein
Akku im Laufe der Zeit entldt, auch wenn er nicht verwendet wird.
- Das Ladenetzteil sollte optional mitgefhrt werden.
Es empfiehlt sich darber hinaus, whrend der Nutzung des mobilen IT-
Systems in kurzen Abstnden die verarbeiteten Daten auf einem nichtflch-
tigen Medium zu speichern. Dazu knnen auch automatische Datensiche-
rungen in Standardprogrammen benutzt werden.
Wenn eine lngere Nutzung des mobilen IT-Systems absehbar ist, z. B. bei Kurzschlsse am Akku
vermeiden
Dienstreisen, sollte ein geladener Ersatzakku mitgefhrt werden. Der Ersatz-
akku sollte in einer Schutzhlle verwahrt werden, da Schden durch ber-
hitzung oder Brand entstehen knnen, wenn die Kontakte des Akkus mit
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
leitenden Materialien in Berhrung kommen. Dies kann durch viele Gegen-

stnde des tglichen Gebrauchs wie Schlssel oder Ketten verursacht werden.
Jede Art IT-System sollte ausgeschaltet werden, bevor der Akku gewechselt
wird, damit der Speicher nicht beschdigt wird.
Hinweis:
Der schlechteste Aufbewahrungsort fr Akkus (vor allem Lithium-Ionen- stationrer Einsatz
Akkus) ist der angeschaltete Laptop im stationren Einsatz, also solange
dieser ohnehin ber eine Steckdose mit dem Stromnetz verbunden ist. Beim
Betrieb in einer Dockingstation sollte der Akku also mglichst vorher heraus-
genommen werden.
- Sind die Benutzer ber den optimalen Umgang mit Akkus aufgeklrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.32 Physikalisches Lschen der Datentrger vor

und nach Verwendung
Verantwortlich fr Umsetzung: IT-Verfahrensverantwortlicher
Neben den in Manahme M 2.167 Sicheres Lschen von Datentrgern
enthaltenen Hinweisen zur Lschung oder Vernichtung von Datentrgern sind
fr den Datentrgeraustausch folgende Punkte zu beachten:
Magnetische Datentrger, die fr den Austausch bestimmt sind, sollten vor
dem Beschreiben mit den zu bermittelnden Informationen physikalisch
gelscht werden. Es soll damit sichergestellt werden, dass keine Restdaten
weitergegeben werden, fr deren Erhalt der Empfnger keine Berechtigung
besitzt.
Eine fr den mittleren Schutzbedarf ausreichende physikalische Lschung
kann erreicht werden, indem der komplette Datentrger oder zumindest die
genutzten Bereiche mit einem bestimmten Muster berschrieben werden.
Mglich ist auch eine Formatierung des Datentrgers, wenn diese nicht wieder
rckgngig gemacht werden kann (Beispiel DOS Version 5.0: format /u). Es
werden einige handelsbliche Produkte angeboten, die sogar die physikalische
Lschung einzelner Dateien gewhrleisten.
In der Regel sind die bertragenen Daten auch fr den Empfnger schtzens-
wert. Analog ist auch hier nach dem Wiedereinspielen der Daten eine physi-
kalische Lschung des Datentrgers vorzusehen.
Auf den Einsatz von optischen Datentrger (hier: WORM) ist zum Zwecke
des Datenaustausches dann zu verzichten, wenn sich darauf weitere, nicht fr
den Empfnger bestimmte Informationen befinden, die nicht gelscht werden
knnen.
- Ist den fr den Austausch der Datentrger Verantwortlichen das Verfahren
des physikalischen Lschens bekannt?
- Stehen diesen Mitarbeitern geeignete Programme zum physikalischen
Lschen bereit?
- Sind die Empfnger von schtzenswerten Informationen ber den Schutz-
wert der bermittelten Daten informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.33 Einsatz eines Viren-Suchprogramms bei Daten-

trgeraustausch und Datenbertragung
Neben den in M 2.3 Datentrgerverwaltung dargestellten Umsetzungs-
hinweisen sollte unmittelbar vor und unmittelbar nach einer Datenbertragung
sowie beim Austausch bzw. beim Versand von Disketten oder anderen
Datentrgern eine Viren-berprfung durchgefhrt werden (vgl. M 4.3
Einsatz von Viren-Suchprogrammen). Dabei ist darauf zu achten, dass das
eingesetzte Viren-Suchprogramm auch Makro-Viren erkennen kann.
Ein Protokoll der Absender-berprfung sollte dem bermittelten Datentrger
beigefgt oder einer Datei, die elektronisch versandt wird, angehngt werden.
Es empfiehlt sich, dieses Protokoll als Kopie zu verwahren. Der Empfnger
htte anhand dieses Protokolls einen ersten Eindruck von der Integritt der
bermittelten Daten. Dies entbindet jedoch nicht von einer erneuten
Virenberprfung. Der Absender kann andererseits bei eventuellen
Beschwerden bezglich Virenbefall der Daten plausibel machen, dass ein
Befall bei ihm unwahrscheinlich war.
- Wird ein mglichst aktuelles Viren-Suchprogramm eingesetzt?
- Werden die zum Austausch vorgesehen Daten vor dem Austausch auf
Viren berprft?
- Wird ein Protokoll dieser berprfung an den Absender bermittelt?
- Werden empfangene Dateien und Datentrger vor dem Einspielen auf
Virenbefall hin berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.34 Einsatz von Verschlsselung, Checksummen

oder Digitalen Signaturen
Werden vertrauliche Informationen oder Informationen mit hohem Integri-
ttsanspruch bertragen und besteht eine gewisse Mglichkeit, dass diese
Daten Unbefugten zur Kenntnis gelangen, von diesen manipuliert werden oder
durch technische Fehler verndert werden knnen, sollte ein kryptogra-
phisches Verfahren zum Schutz der Daten fr den Transport oder die ber-
mittlung in Betracht gezogen werden.
Vertraulichkeitsschutz durch Verschlsselung
Fr die bertragung vertraulicher Informationen bedarf es deren Verschlsse- Einsatz eines sicheren
Verschlsselungs-
lung. Das entscheidende Merkmal eines Verschlsselungsverfahrens ist die algorithmus
Gte des Algorithmus sowie der Schlsselauswahl. Ein anerkannter Algo-
rithmus, der fr den mittleren Schutzbedarf ausreicht, ist der Tripel-DES, der
auf dem Data Encryption Standard (DES) basiert. Dieser ist leicht zu pro-
grammieren, zumal der Quell-Code in vielen Fachbchern in der Program-
miersprache C abgedruckt ist. Fr den Bereich der ffentlichen Verwaltung
kann das BSI fr den Einsatz auf stationren und tragbaren PCs ein Offline-
Verschlsselungsprogramm (Chiasmus fr Windows) unter gewissen Rand-
bedingungen zur Verfgung stellen, dass den Sicherheitsanforderungen im
Bereich des mittleren Schutzbedarfs gengt. Ein Anforderungsvordruck
befindet sich auf der CD-ROM zum Handbuch (siehe Anhang: Hilfsmittel).
Um den Anforderungen der Vertraulichkeit der zu bertragenden Informa- Zugriffsschutz auf das
Verschlsselungs-
tionen zu entsprechen, mssen das IT-System des Absenders und des programm
Empfngers den Zugriffsschutz auf das Verschlsselungsprogramm ausrei-
chend gewhrleisten. Ggf. sollte dieses Programm auf einem auswechselbaren
Datentrger gespeichert, in der Regel verschlossen aufbewahrt und nur bei
Bedarf eingespielt/genutzt werden.
Integrittsschutz durch Checksummen, Verschlsselung oder Digitaler
Signaturbildung
Ist fr den Datenaustausch lediglich die Integritt der zu bermittelnden Daten
sicherzustellen, muss unterschieden werden, ob ein Schutz nur gegen zufllige
Vernderungen, z. B. durch bertragungsfehler, oder auch gegen
Manipulationen geleistet werden soll. Sollen ausschlielich zufllige Vern-
derungen erkannt werden, knnen Checksummen-Verfahren (z. B. Cyclic
Redundancy Checks) oder fehlerkorrigierende Codes zum Einsatz kommen.
Schutz gegenber Manipulationen bieten darber hinaus Verfahren, die unter
Verwendung eines symmetrischen Verschlsselungsalgorithmus (z. B. DES)
aus der zu bermittelnden Information einen so genannten Message Authen-
tication Code (MAC) erzeugen. Andere Verfahren bedienen sich eines asym-
metrischen Verschlsselungsalgorithmus (z. B. RSA) in Kombination mit
einer Hashfunktion und erzeugen eine "Digitale Signatur". Die jeweiligen
erzeugten "Fingerabdrcke" (Checksumme, fehlerkorrigierende Codes, MAC,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Digitale Signatur) werden zusammen mit der Information an den Empfnger

bertragen und knnen von diesem berprft werden.
Fr die bermittlung oder den Austausch ggf. notwendiger Schlssel sei hier sichere
Schlsselbermittlung
auf Manahme M 2.46 Geeignetes Schlsselmanagement verwiesen. Weitere
Informationen zum Einsatz kryptographischer Verfahren und Produkte finden
sich in Kapitel 3.7 Kryptokonzept.
- Werden Verschlsselungsprogramme oder Checksummen-Verfahren zum
Schutz der Vertraulichkeit oder Integritt bereitgestellt?
- Sind die fr die Datenbertragung Verantwortlichen ber ein ordnungs-
gemes Schlsselmanagement informiert?
- Ist der Schutz der Vertraulichkeit/Integritt nur auf dem Transport- bzw.
bertragungsweg oder auch auf dem Empfnger- oder Absendersystem zu
gewhrleisten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Versand
Vor dem Versenden des Datentrgers ist dieser darauf zu berprfen, ob die
gewnschten Informationen - und auch nur diese - vom Datentrger rekon-
struierbar sind.
Um die korrekte bertragung zum Datentrger zu berprfen, kann ein Pro-
gramm eingesetzt werden, dass die ursprngliche mit der bertragenen Datei
zeichenweise vergleicht (auf einem PC unter DOS z. B. mittels des Befehls
comp).
Auch sollten alle Dateien des Datentrgers aufgelistet werden (z. B. mit dir
unter DOS oder ls unter Unix), um sicherzustellen, dass nur fr den Empfn-
ger bestimmte Dateien auf diesem Datentrger enthalten sind.
Befanden sich vorher andere Daten auf diesem Datentrger, so sind diese
physikalisch zu lschen (M 4.32 Physikalisches Lschen der Datentrger vor
und nach Verwendung).
- Werden die auszutauschenden Datentrger vor dem Versenden darauf
berprft, ob die gewnschten Information vollstndig vom Datentrger
rekonstruierbar sind?
- Werden die auszutauschenden Datentrger vor dem Versenden blicher-
weise darauf berprft, ob nur die gewnschten Information vom Daten-
trger rekonstruierbar sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.36 Sperren bestimmter Faxempfnger-

Rufnummern
Verantwortlich fr Umsetzung: Fax-Verantwortlicher, Fax-Poststelle
Besteht die Notwendigkeit, das zufllige oder absichtliche Versenden von
Informationen oder Unterlagen per Fax an eine nicht gewnschte Empfnger-
rufnummer zu verhindern, so bietet die heutige Technik dazu mindestens drei
Lsungen:
Bei einigen Faxgerten bzw. Faxservern ist es mglich, die Versendung von Einstellung am Faxgert
oder Faxserver
Faxen an bestimmte Faxempfnger-Rufnummern zu unterbinden (positiver
Ausschluss) oder alternativ alle Empfngerrufnummern auer einigen
ausgewhlten Rufnummern zu sperren (negativer Ausschluss).
Die gleiche Art der Berechtigungsvergabe kann auch in modernen TK- Einstellung an der TK-
Anlage
Anlagen erreicht werden, vorausgesetzt, das Faxgert ist ber eine solche
Anlage ans Telefonnetz angeschlossen.
Wenn ein Faxgert oder die TK-Anlage eine solche Mglichkeit nicht bietet, Benutzung einer
Zusatzeinrichtung
so kann zum Beispiel vom Betreiber des ffentlichen Netzes eine Zusatz-
einrichtung gemietet werden, die den Verbindungsaufbau zu bestimmten
Rufnummern (positiver und negativer Ausschluss) verhindert.
- Besteht die Notwendigkeit, bestimmte Faxadressaten auszuschlieen?
- Ist es vorgekommen, dass Faxsendungen an falsche Empfnger versandt
wurden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.37 Sperren bestimmter Absender-Faxnummern

Verantwortlich fr Umsetzung: Fax-Verantwortlicher, Fax-Poststelle
Damit bestimmte Faxsendungen das eigene Faxgert nicht blockieren knnen,
z. B. bei berlastung durch spezielle Faxaktionen von Werbeagenturen, kann
ggf. eine Sperre bestimmter Sender-Faxnummern realisiert werden.
Einige moderne Faxgerte (Gruppe 4) sind in der Lage, die bermittelte Auswertung der
Senderrufnummer durch
Senderrufnummer auszuwerten und den Empfang von Faxsendungen ausge- das Faxgert oder den
whlter Rufnummern zu verweigern. Dies gilt auch fr einige Faxserver, Faxserver
sofern diese an das ISDN-Netz angeschlossen sind. Daneben kann auch die
Faxabsenderkennung (CSID - Call Subscriber ID) zur Auswertung heran-
gezogen werden. Nachteilig ist allerdings, dass der Faxabsender die
Rufnummernbermittlung unterdrcken und die bermittelte Rufnummer
sowie die Absenderkennung manipulieren kann.
Eine weitere Mglichkeit besteht darin, dass beim Telefon-Netzbetreiber Einrichtung
geschlossener
kostenpflichtig eine geschlossene Benutzergruppe eingerichtet wird, wenn Benutzergruppen
Empfnger und Sender an digitalen Vermittlungsstellen angeschlossen sind.
Teilweise wird diese Mglichkeit auch von modernen TK-Anlagen angeboten
(vgl. auch Kapitel 8.1 TK-Anlage).
- Besteht die Notwendigkeit zur Sperre bestimmter Absender-Faxnummern?
- Sind dem Fax-Verantwortlichen die geschilderten Varianten von Gegen-
manahmen bekannt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.38 Abschalten nicht bentigter Leistungsmerkmale

Nicht bentigte Leistungsmerkmale (insbesondere die Fernabfrage) sollten
nach Mglichkeit abgeschaltet werden, um vor Missbrauch und Fehlbedie-
nung geschtzt zu sein. Zur Entscheidung, ob ein Leistungsmerkmal bentigt
wird, sollten auch die damit verbundenen Sicherheitsrisiken einbezogen
werden.
- Werden die Benutzer explizit aufgefordert, nicht bentigte Leistungs-
merkmale abzuschalten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.39 Abschalten des Anrufbeantworters bei

Anwesenheit
In Zeiten, in denen der Anrufbeantworter nicht bentigt wird, kann er zum
Schutz gegen Missbrauch abgeschaltet oder vom Telefonnetz getrennt werden.
Insbesondere in dem Fall, dass das Gert ber die Funktion der Raumber-
wachung verfgt, sollte dies konsequent durchgefhrt werden.
Zu beachten ist, dass sich in einigen Fllen die abgeschalteten Anrufbeant-
worter selbstndig aktiveren, wenn die Verbindung nach einer gewissen Zeit
nicht aufgebaut wird (z. B. nach 10-maligem Klingeln).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.40 Verhinderung der unautorisierten Nutzung des

Rechnermikrofons
Das Mikrofon eines vernetzten Rechners kann von denjenigen benutzt werden,
die Zugriffsrechte auf die entsprechende Gertedatei (unter Unix zum Beispiel
/dev/audio) haben. Unter Windows NT bestimmen die Zugriffsrechte auf die
entsprechenden Schlssel der Registrierung (HKEY_LOCAL-
_MACHINE\HARDWARE\.), wer das Rechnermikrofon aktivieren kann. Diese
Rechte sind daher sorgfltig zu vergeben. Der Zugriff auf die Gertedatei
sollte nur mglich sein, solange jemand an dem IT-System arbeitet. Wenn die
Benutzung eines vorhandenen Mikrofons generell verhindert werden soll,
muss es - wenn mglich - ausgeschaltet oder physikalisch vom Gert getrennt
werden.
Falls das Mikrofon in den Rechner integriert ist und nur durch Software ein- Zugriffsrechte setzen
und ausgeschaltet werden kann, mssen die Zugriffsrechte so gesetzt sein,
dass es kein Unbefugter benutzen kann. Dies kann z. B. erfolgen, indem unter
Unix allen Benutzern die Leserechte auf die Gertedatei /dev/audio bzw. unter
Windows NT die Zugriffsrechte auf die entsprechenden Schlssel der
Registrierung entzogen werden. Dadurch ist ausgeschlossen, dass ein normaler
Benutzer das Mikrofon benutzen kann, er kann aber weiterhin Audio-Dateien
abspielen.
Bei IT-Systemen mit Mikrofon ist zu prfen, ob Zugriffsrechte und Eigen- sicheres Deaktivieren
tmer bei einem Zugriff auf die Gertedatei verndert werden. Falls dies der
Fall ist oder falls gewnscht ist, dass jeder Benutzer das Mikrofon benutzen
kann und es nicht nur in Einzelfllen durch den Systemadministrator freige-
geben werden soll, muss der Administrator ein Kommando zur Verfgung
stellen, das
- nur aktiviert werden kann, wenn jemand an dem IT-System angemeldet ist,
- nur durch diesen Benutzer aktiviert werden kann und
- die Zugriffsberechtigungen dem Benutzer nach dem Abmelden wieder
entzieht.
Solange der Zugriff auf das Mikrofon durch kein sicheres Kommando geregelt physikalisches Trennen
wird, muss das Mikrofon physikalisch vom Rechner oder der Rechner vom
Netz getrennt werden.
Rechner mit eingebautem Mikrofon sollten whrend einer vertraulichen
Besprechung aus dem Raum entfernt werden oder zumindest ausgeschaltet
werden. Bei einem Laptop sollten alle evtl. vorhandenen Verbindungen zu
Kommunikationsnetzen, beispielsweise ISDN, die nicht bentigt werden,
getrennt werden. In den meisten Fllen ist es hierzu am einfachsten, das
entsprechende Kabel auszustecken.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Kann das Rechnermikrofon ausgeschaltet oder physikalisch vom Rechner
getrennt werden?
- Wer hat Zugriff auf die Mikrofon-Gertedatei bzw. auf die Teile der
Registrierung, die die Manipulation von Hardware-Einstellungen erlauben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.41 Einsatz eines angemessenen PC-Sicherheits-

produktes
schutzbeauftragter, Verantwortliche der ein-
zelnen IT-Anwendungen
Verantwortlich fr Umsetzung: Beschaffungsstelle, Administrator
Fr den DOS-PC mit mehreren Benutzern ist der Einsatz eines PC-
Sicherheitsproduktes vorzusehen. Fr die Beschaffung eines Produktes oder
fr die berprfung schon im Einsatz befindlicher Produkte kann folgende
Mindestfunktionalitt als Mastab genutzt werden. Mit ihr soll erreicht
werden, dass
- nur autorisierte Personen den PC benutzen knnen,
- die Benutzer auf die Daten nur in der Weise zugreifen knnen, die sie zur
Aufgabenerfllung bentigen,
- Unregelmigkeiten und Manipulationsversuche erkennbar werden.
Empfohlene Mindestfunktionalitt fr PC-Sicherheitsprodukte fr den
Einsatz bei DOS-PCs mit mehreren Benutzern:
- Identifikation und Authentisierung des Administrators und der Benutzer. Es
sollte eine Sperre des Systems nach 3 fehlerhaften Authentisierungsversu-
chen stattfinden, die nur der Administrator zurcksetzen kann. Wird ein
Passwort verwendet, sollte das Passwort mindestens sechs Stellen
umfassen und verschlsselt im System gespeichert werden.
- Rechteverwaltung und -kontrolle auf Festplatten und Dateien, wobei
zumindest zwischen lesendem und schreibendem Zugriff unterschieden
werden soll.
- Rollentrennung zwischen Administrator und Benutzer. Nur der Administra-
tor kann Rechte zuweisen oder entziehen.
- Protokollierung der Vorgnge Anmelden, Abmelden und Rechteverletzung
sollte mglich sein.
- Kein Systemzugriff auf Betriebssystemebene (DOS) darf fr Benutzer
mglich sein.
- Bildschirmsperre nach zeitweiser Inaktivitt der Tastatur oder Maus und
Reaktivierung mittels Identifikation und Authentisierung.
- Boot-Schutz soll verhindern, dass der PC unbefugt von Diskette gebootet
werden kann.
Sinnvolle minimale Evaluationstiefe und Mindeststrke der Mechanismen
fr Zertifikate nach ITSEC: E2, mittel.
Zustzliche Forderungen an das PC-Sicherheitsprodukt:
- Benutzerfreundliche Oberflche zur Erhhung der Akzeptanz.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Aussagekrftige und nachvollziehbare Dokumentation fr Administrator

und Benutzer.
Wnschenswerte Zusatzfunktionalitt des PC-Sicherheitsproduktes:
- Rollentrennung zwischen Administrator, Revisor und Benutzer; nur der
Administrator kann Rechte zuweisen oder entziehen und nur der Revisor
hat Zugriff auf die Protokolldaten,
- Protokollierung von Administrationsttigkeiten,
- Untersttzung der Protokollauswertung durch konfigurierbare Filterfunk-
tionen,
- Verschlsselung der Datenbestnde mit einem geeigneten Verschlsse-
lungsalgorithmus und in einer Weise, dass ein Datenverlust bei Fehlfunk-
tion (Stromausfall, Abbruch des Vorgangs) systemseitig abgefangen wird.
Die Realisierung dieser Funktionalitt kann sowohl in Hardware wie auch in
Software erfolgen. Bei der Neubeschaffung eines Produktes sollte Manahme
M 2.66 Beachtung des Beitrags der Zertifizierung fr die Beschaffung
bergangslsung:
Sollte eine kurzfristige Beschaffung bzw. ein zgiger Einsatz eines solchen
PC-Sicherheitsproduktes nicht mglich sein und haben die PC-Benutzer dieses
PC keine gemeinsamen Daten, kann als bergangslsung ein Ver-
schlsselungsprodukt eingesetzt werden. Mit diesem Produkt muss jeder
Benutzer zu Beginn der Arbeit die ihm zugeordneten Daten entschlsseln und
bei Beendigung der Arbeit wieder verschlsseln. Damit kann sichergestellt
werden, dass die Vertraulichkeit der Daten gewahrt bleibt, jedoch wird nicht
verhindert, dass die verschlsselten Daten manipuliert werden knnen. Die
Manipulation der Daten wird im allgemeinen bei der Entschlsselung erkannt,
da sich nicht sinnvolle Daten ergeben.
Fr den Bereich der ffentlichen Verwaltung kann das BSI fr den Einsatz auf
stationren und tragbaren PCs ein Verschlsselungsprogramm unter gewissen
Randbedingungen zur Verfgung stellen, dass den Sicherheitsanforderungen
im Bereich des mittleren Schutzbedarfs gengt (siehe Anhang: Hilfsmittel).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.42 Implementierung von Sicherheitsfunktiona-

litten in der IT-Anwendung
schutzbeauftragter, Verantwortliche der ein-
zelnen IT-Anwendungen
Verantwortlich fr Umsetzung: Anwendungsentwickler
Mehrere Grnde knnen zu der Notwendigkeit fhren, dass innerhalb der
Anwendungsprogramme selbst Sicherheitsfunktionalitten wie eine Zugangs-
kontrolle, eine Zugriffsrechteverwaltung und -prfung oder eine Protokollie-
rung implementiert werden mssen:
- Reichen die Protokollierungsmglichkeiten des IT-Systems einschlielich
zustzlich eingesetzter IT-Sicherheitsprodukte nicht aus, um eine ausrei-
chende Beweissicherung zu gewhrleisten, so mssen diese Protokoll-
elemente im Anwendungsprogramm implementiert werden. (Beispiel:
BDSG, Anlage zum 9, Eingabekontrolle: "zu gewhrleisten, dass nach-
trglich berprft und festgestellt werden kann, welche personenbezogenen
Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben
worden sind".)
- Reicht die Granularitt der Zugriffsrechte des IT-Systems einschlielich
zustzlich eingesetzter Sicherheitsprodukte nicht aus, um einen ordnungs-
gemen Betrieb zu gewhrleisten, so muss eine Zugriffsrechteverwaltung
und -kontrolle im Anwendungsprogramm implementiert werden. (Beispiel:
eine Datenbank mit einer gemeinsamen Datenbasis. Vorausgesetzt sei, dass
je nach Funktion des Benutzers nur Zugriffe auf bestimmte Felder zulssig
sind.)
- Ist es mit dem IT-System einschlielich zustzlich eingesetzter IT-Sicher-
heitsprodukte nicht mglich, den Administrator daran zu hindern, auf
bestimmte Daten zuzugreifen oder zumindest diesen Zugriff zu protokol-
lieren und zu kontrollieren, dann muss dies bei Bedarf durch zustzliche
Sicherheitsfunktionen im Anwendungsprogramm implementiert werden.
Zum Beispiel kann mit einer Verschlsselung der Daten verhindert werden,
dass der Administrator diese Daten im Klartext liest, wenn er nicht im
Besitz des zugehrigen Schlssels ist.
Diese zustzlichen Anforderungen an IT-Anwendungen mssen schon in der
Planung und Entwicklung bercksichtigt werden, da eine nachtrgliche Im-
plementation meist aus Kostengrnden nicht mehr mglich ist.
- Wird bei der Entwicklung neuer IT-Anwendungen systematisch festge-
stellt, welche Sicherheitsfunktionen die Anwendung bereitstellen muss?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.43 Faxgert mit automatischer Eingangs-

kuvertierung
Verantwortlich fr Umsetzung: Beschaffer
Faxgerte mit automatischer Eingangskuvertierung verhindern, dass einge-
gangene Faxe unberechtigt entnommen und unberechtigt gelesen werden.
Eingehende Faxe werden so geknickt, dass nur das Faxvorblatt sichtbar bleibt,
und dann in einem Klarsichtumschlag eingeschweit. Danach fllt der
Umschlag in ein verschliebares Fach im Faxgert. Zugriff auf die Umschlge
hat normalerweise nur der Berechtigte, der den Schlssel zu diesem Fach
besitzt. Eine unbefugte Kenntnisnahme ist vor Zustellung des Fax nur durch
gewaltsames ffnen des Faches oder Aufreien des verschweiten
Umschlages mglich und wird daher zumindest bemerkt.
- Ist die Anschaffung eines derartigen Gertes sinnvoll?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.44 Prfung eingehender Dateien auf Makro-Viren

Eingehende Dateien im Wege des Datentrgeraustausch oder bei elektro-
nischer bermittlung sind einer Viren-Prfung zu unterziehen. Dies gilt nicht
nur fr regulre Programm-Dateien, sondern auch fr solche Dateien, die
mittels Anwendungsprogrammen, die eine Makrosprache verwenden knnen,
erstellt wurden. Fr die nachfolgend aufgezhlten Anwendungsprogramme ist
derzeit bekannt, dass Makros mit Schadfunktionen erzeugt wurden:
- Winword (ab Version 2.0),
- Powerpoint,
- Excel,
- AmiPro.
Sofern ein aktuelles Viren-Schutzprogramm eingesetzt wird, das auch Makro- aktuelles Viren-Schutz-
programm verwenden
Viren erkennt, kann auf weitere Manahmen verzichtet werden. Darber
hinaus kann eine Testumgebung sinnvoll sein, um bersandte Dateien mit dem
jeweiligen Anwendungsprogramm auf Makro-Viren zu untersuchen.
Alternativ besteht die Mglichkeit, empfangene Dateien mit einem Editor zu
bearbeiten, der die Datei in ein Format umwandelt, in dem die Makros nicht
ablauffhig sind. Die empfangenen Dateien knnen auch mit so genannten
Viewern geffnet werden, die es kostenlos fr die Darstellung der verbrei-
tetsten Dateiformate gibt und die ebenfalls die Ausfhrung von Makros nicht
zulassen.
Dokumente sollten mglichst nur im RTF-Format nach auen gegeben Texte im RTF-Format
weitergeben
werden, da hierzu keine Makrosprache existiert und damit keine Gefahr von
Makro-Viren besteht. Die Umwandlung nach RTF ist im Allgemeinen ohne
nennenswerte Qualittsverluste mglich.
Als weitere Vorbeugung sollten Benutzer darauf hingewiesen werden, wie sie
die automatische Ausfhrung mglicherweise vorhandener Makros verhindern
knnen. Dies ist leider fr fast alle Programme und Versionen anders und
auch nicht immer zuverlssig.
Bei der Verwendung des RTF-Formats ist jedoch zu beachten, dass damit
unter bestimmten Voraussetzungen der Makrovirus-Schutz von Microsoft
Word umgangen werden kann. (Bekannte Viren werden jedoch von aktuellen
Viren-Schutzprogrammen gefunden.) Fr RTF existiert keine Makrosprache,
es knnen jedoch Verknpfungen mit Dokumentenvorlagen (DOT)
eingebettet sein, die ihrerseits Makros enthalten knnen. Wird eine solche
RTF-Datei geffnet und ist die Dokumentvorlage ebenfalls im Zugriff, fhrt
Microsoft Word in der Dokumentenvorlage evtl. enthaltene Makros ohne
Rckfrage aus. Betroffen sind die Versionen Word 97, 98, 2000 und 2001
(Mac). Patches zur Behebung dieser Schwachstelle sind fr die US-Versionen
von Word verfgbar (siehe Microsoft Security Bulletin MS01-028), fr
internationale Versionen sind sie angekndigt. Diese Patches sollten installiert
werden. Als zustzliche Sicherheitsmanahme kann ein nicht
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Makro-fhiges Viewer-Programm zur Anzeige von RTF-Dateien verwendet

werden.
- Befindet sich ein aktuelles Viren-Schutzprogramm im Einsatz, das auch
Makro-Viren erkennt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.45 Einrichtung einer sicheren Peer-to-Peer-Umge-

bung unter WfW
Fr jeden Rechner unter WfW sollte der Administrator die Peer-to-Peer-
Funktionalitten einzeln zulassen oder sperren und damit die WfW-Umgebung
benutzerspezifisch einschrnken. Dafr bentigt er das Administrationswerk-
zeug ADMINCFG.EXE.
Nach dem Aufruf von ADMINCFG.EXE muss zunchst die Sicherheitskonfi-
gurationsdatei WFWSYS.CFG geffnet werden, in der die Sicherheitseinstel-
lungen des jeweiligen WfW-Rechners gespeichert sind. ADMINCFG.EXE
kann dabei nicht nach verschiedenen Benutzern auf einem WfW-Rechner
unterscheiden.
Selbst wenn die Umgebung nicht eingeschrnkt werden soll, ist die Sicher-
heitskonfigurationsdatei WFWSYS.CFG mit einem Passwortschutz zu verse-
hen. Wird das Administrationswerkzeug ADMINCFG.EXE dazu lokal
installiert, ist es anschlieend wieder zu entfernen.
Mit Hilfe des Administrationswerkzeugs ADMINCFG.EXE knnen unter
Sicherheitsgesichtspunkten folgende Konfigurationen fr den Rechner vorge-
nommen werden:
Die Freigabeoptionen sind festzulegen:
- Wenn der Rechner nicht fr die Freigabe von Verzeichnissen vorgesehen
ist, ist die Option Dateifreigabe deaktivieren einzustellen. Die entspre-
chenden Funktionen stehen dann im Dateimanager nicht mehr zur Verf-
gung, es ist aber weiter mglich, sich mit Verzeichnissen anderer Rechner
zu verbinden.
- Wenn der Rechner nicht fr die Freigabe von Druckern vorgesehen ist, ist
die Option Druckerfreigabe deaktivieren einzustellen.
- Wenn der Rechner nicht fr Netz-DDE-Freigabe (z. B. Telefonieren unter
WfW, Datenaustausch ber die Ablagemappe) vorgesehen ist, ist die
Option Netz-DDE-Freigabe deaktivieren einzustellen.
Die Kennwortoptionen sind festzulegen:
- Bei aktiviertem Kennwort-Caching werden in einer Datei alle WfW-Netz-
verbindungen mit zugehrigen Passwrtern gespeichert, wenn dies vom
Benutzer beim jeweiligen Verbindungsaufbau gewnscht wird. Wieder-
holte Passworteingaben sind dann spter nicht mehr erforderlich. Die
Option Kennwort-Caching deaktivieren sollte eingestellt werden, zumin-
dest immer dann, wenn der WfW-Rechner nicht ber einen ausreichenden
Zugangsschutz (z. B. BIOS-Passwort) verfgt.
- Kennworte in Freigabe-Dialogfeldern lesbar anzeigen darf nicht aktiviert
sein, da sonst bei der Passwort-Eingabe dieses im Klartext auf dem Bild-
schirm erscheint.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ablauf des Anmeldekennwortes sollte auf den in der Sicherheitsstrategie

vorgegebenen Zeitraum eingestellt werden.
- Minimale Kennwortlnge muss auf mindestens 6 eingestellt werden.
- Alphanumerische Kennworte erzwingen sollte eingestellt werden. Buch-
staben-Zahlen-Kombinationen werden damit obligatorisch.
Die Administrator-Einstellungen sind festzulegen:
- Der Administrator muss ein Passwort fr die erstellte Konfigurationsdatei
WFWSYS.CFG festlegen, das nur ihm und seinem Stellvertreter bekannt
sein darf. Dieses Passwort ist sicher zu hinterlegen (vgl. M 2.22 Hinterle-
gen des Passwortes).
- ber Optionen aktualisieren knnen voreingestellte Sicherheitsprofile von
einem Server bernommen werden. Darber hinaus kann auch eingestellt
werden, dass beim Start eines Clients die Sicherheitskonfigurationsdatei
des Servers berprft und bei nderungen die lokale aktualisiert wird. Dies
erleichtert dem Administrator die zentrale Administration des WfW-
Netzes, das einfache Hinzufgen weiterer WfW-Rechner und das
Wechseln des Passwortes fr die Konfigurationsdatei.
Der Administrator muss darber hinaus beim Einrichtung eines WfW-
Rechners auch die weiteren Punkte beachten:
- Die Voreinstellung Beim Start wieder freigeben ist in den Freigabeober-
flchen (Datei- und Druckmanager) zu deaktivieren.
- Die Voreinstellung Kennwort in der Kennwortliste speichern ist in den
Verbindungsoberflchen (Datei- und Druckmanager) zu deaktivieren.
- In der Programmgruppe Systemsteuerung unter Netzwerk sollte gem der
Namenskonvention der Computername, der Name der Arbeitsgruppe und
der Standard-Anmeldename voreingestellt werden.
- Das WfW-Protokoll ist zu aktivieren (in der Programmgruppe Systemsteue-
rung unter Netzwerk). Dabei sollten smtliche Ereignisse aufgezeichnet
und die Protokolldatei ausreichend gro, beispielsweise 32 KByte, angelegt
werden.
- In der Programmgruppe Systemsteuerung unter Netzwerk sollte ber die
Schaltflche Start voreingestellt werden, ob eigene Anwendungen des
Rechners oder Zugriffe anderer mit Prioritt bedient werden. Ist der Zugriff
anderer nachrangig, sollte die Prioritt zugunsten schnellerer Ausfhrung
gewhlt werden.
- Beim Einsatz von Schedule+ ist darauf zu achten, dass das standardmig
vergebene Recht, offene oder besetzte Zeitblcke einzusehen, fr alle nicht
berechtigten WfW-Benutzer deaktiviert wird. Jeder Teilnehmer am selben
Post-Office ist sonst in der Lage, das zeitliche Arrangement der individu-
ellen Termine einzusehen.
WfW bietet die Mglichkeit, Sicherheitsprofile auf einem "Server" zu hinter-
legen, die die einzelnen Clients im WfW-Netz zur Aktualisierung abrufen.
Dadurch ist es mglich, die Sicherheitseinstellungen ber das Netz zu
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
administrieren. Um den administrativen Aufwand zu minimieren, sollte diese

Mglichkeit genutzt werden.
Wird ein Post-Office eingerichtet, dass von mehreren Benutzern zur Kommu-
nikation oder zur gemeinsamen Terminplanung genutzt werden soll, ist in
Erwgung zu ziehen, von diesem eine Datensicherung in angemessenen Zeit-
rumen anzulegen. Dies ist notwendig, um einem versehentlichen oder
absichtlichen Lschen des Post-Office entgegenzuwirken, da dies unter WfW
nicht sicher verhindert wird.
Die festgelegten Freigabeoptionen, Kennwortoptionen und Administrator- Optionen und
Einstellungen
Einstellungen sollten nachvollziehbar dokumentiert werden. Dies kann auch in dokumentieren
elektronischer Form erfolgen, wenn sichergestellt ist, dass auch bei nicht
funktionierenden Peer-to-Peer-Diensten auf die Dokumentation zugegriffen
werden kann. Die Dokumentation muss bei nderungen an den Optionen und
Einstellungen entsprechend aktualisiert werden.
- Werden die Sicherheitseinstellungen ber das Netz administriert?
- Werden die vorgenommenen Einstellungen in geeigneter Form dokumen-
tiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.46 Nutzung des Anmeldepasswortes unter WfW

und Windows 95
Verantwortlich fr Initiierung: Administrator
Meldet sich ein neuer Benutzer an einem Rechner unter WfW oder
Windows 95 an, wird er gefragt, ob er eine Kennwortliste
([anmeldename].pwl) unter seinem Anmeldenamen anlegen mchte. In dieser
Liste werden dann alle diejenigen Passwrter festgehalten, die von diesem
Benutzer beim Verbinden mit Ressourcen anderer mitgeteilt werden mssen.
Dies geschieht allerdings nur dann, wenn dieses "Caching" von Passwrtern
auf diesem Rechner explizit erlaubt ist und der Benutzer es im Einzelfall auch
wnscht.
Das Anmeldepasswort dient einzig und allein dem Schutz dieser Kennwort-
liste. Nur bei korrekter Eingabe des zum Anmeldenamen gehrigen
Passwortes wird diese entschlsselt und steht zur Verfgung.
Insbesondere wenn ein WfW- oder Windows 95-Rechner von mehreren
Benutzern eingesetzt wird, wird ein Schutz der gespeicherten Kennwrter
gegenber den Benutzern desselben Rechners nur durch ein individuelles
Anmeldepasswort gewhrleistet.
Das jeweilige Passwort ist geeignet auszuwhlen, regelmig zu wechseln und
sicher zu hinterlegen (vgl. M 2.11 Regelung des Passwortgebrauchs und
M 2.22 Hinterlegen des Passwortes).
Hinweise:
Werden vom Benutzer keine Passwrter in der Kennwortliste gespeichert, ist
auch kein Anmeldepasswort unter WfW notwendig. Wird also Passwort-
Caching grundstzlich vom Administrator mittels ADMINCFG.EXE unter
WfW bzw. ber die Systemrichtlinien unter Windows 95 deaktiviert, so ist das
Anmeldepasswort berflssig. Selbst Maskerade auf dem PC kann mit diesem
Authentisierungsmechanismus nicht verhindert werden, da jede Kennwortliste
umbenannt, der ursprngliche Anmeldename erneut genutzt und anschlieend
die ursprngliche Kennwortliste wieder zurckbenannt werden kann.
Wird allerdings Passwort-Caching erlaubt und auch genutzt, muss der Admi-
nistrator mittels ADMINCFG.EXE unter WfW bzw. ber die Systemricht-
linien unter Windows 95 die Mindestlnge des Anmeldepasswortes auf 6
setzen. Damit ist die Eingabe des Passwortes beim Anmelden unter WfW und
Windows 95 obligatorisch und kann nicht deaktiviert werden. In Ausnahme-
fllen, z. B. wenn der Rechner nur von einem Benutzer genutzt wird und ein
ausreichender Zugangsschutz (BIOS-Passwort, Bildschirmsperre, usw.)
besteht, kann das Anmeldepasswort deaktiviert werden. Eine Deaktivierung ist
mglich, wenn die Mindestlnge des Passwortes auf Null gesetzt wird.
Werden vom Benutzer versehentlich Passwrter in der Kennwortliste gespei-
chert, ist die Datei [anmeldename].pwl zu lschen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wird den WfW- bzw. Windows 95 Benutzern mitgeteilt, dass neben dem
Passwortschutz am PC (z. B. BIOS-Passwort) zustzlich das
Anmeldepasswort fr den Schutz der individuellen Kennwortliste unter
WfW bzw. Windows 95 notwendig ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.47 Protokollierung der Sicherheitsgateway-

Aktivitten
Es muss festgelegt werden, welche Ereignisse protokolliert werden und wer
die Protokolle auswertet. Die Protokollierung muss den jeweils geltenden
rechtlichen Bestimmungen entsprechen. Fr Protokolldaten ist in Deutschland
insbesondere die Zweckbindung nach 14 des BDSG zu beachten.
Fr den Einsatz der Protokollierung am Sicherheitsgateway sollten die
folgenden Punkte beachtet werden:
- Es muss mglich sein, die Protokolldaten (beispielsweise IP-Adressen)
eindeutig einzelnen Rechnern (oder Personen) zuzuordnen. Dabei mssen
jedoch die jeweils zutreffenden gesetzlichen Regelungen zum Datenschutz
beachtet werden.
- Die Protokolldaten sollten nicht nur auf den einzelnen Komponenten des
Sicherheitsgateways, sondern zustzlich auch auf einem zentralen
Protokollierungsserver (Loghost) gespeichert werden, so dass die Gefahr
des Datenverlustes durch einen Hacker-Angriff oder durch einen
Systemausfall verringert wird.
- Die bertragung der Protokollinformationen von den Komponenten zum
Loghost muss ber eine gesicherte Verbindung erfolgen, damit die
Protokollinformationen vor ihrer endgltigen Speicherung nicht verndert
werden knnen.
- Wenn bei der bertragung zum Loghost nicht-vertrauenswrdige Netze
passiert werden mssen, so mssen die Daten verschlsselt werden.
- Die Gre des freien Speicherplatzes auf dem verwendeten Medium sollte
- Bei einem Ausfall der Protokollierung (z. B. aufgrund fehlenden
Speicherplatzes auf der Festplatte) sollten alle Funktionen, die
Protokolldaten generieren, gesperrt werden. Idealerweise sollte das
Sicherheitsgateway jeglichen Verkehr blockieren und eine entsprechende
Meldung an den Administrator weitergeben.
- Die Protokolldaten sollten auf einem WORM-Medium ("Write Once, Read
Many") gespeichert werden.
- Art und Umfang der Protokollierung sollten sich an der Sensibilitt der zu
verarbeitenden Daten sowie am Verwendungszweck orientieren.
- Spezielle, einstellbare Ereignisse, wie z. B. wiederholte fehlerhafte
Passworteingaben fr eine Benutzer-Kennung oder unzulssige
Verbindungs-versuche, mssen bei der Protokollierung hervorgehoben
werden und sollten zu einer unverzglichen Warnung des Firewall-
Administrators fhren.
- Die einzelnen Komponenten sollten eine Zeitsynchronisation durchfhren,
um eine Korrelation der Daten zu ermglichen. Siehe dazu auch M 4.227
Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei kleinen Netzen, in denen nur ein einfaches Sicherheitsgateway eingesetzt

wird, kann gegebenenfalls auf einen zustzlichen Loghost verzichtet werden.
Umfang der Protokollierung am Paketfilter
Die Protokollierung am Paketfilter sollte zumindest alle Pakete erfassen, die Abgewiesene Pakete
protokollieren!
auf Grund einer Paketfilterregel abgewiesen werden.
Je nach Sicherheitsanforderungen sind eventuell zustzliche Klassen von
Paketen interessant:
- "Ungewhnliche" Pakete, beispielsweise mit einer fehlerhaften
Kombination aus TCP-Flags oder Pakete mit fehlerhaften Header-
Informationen.
Solche Pakete sollten zwar ohnehin durch eine entsprechende
Paketfilterregel abgewiesen und aus diesem Grund bereits von der
Protokollierung erfasst werden, aber es wird trotzdem empfohlen, solche
Pakete gesondert zu protokollieren, da sie beispielsweise Indizien fr
sogenannte "Stealth Scans" sein knnen. Auerdem kann eine Hufung
fehlerhafter Pakete auf technische Probleme im Netz hindeuten.
- Bei verbindungsorientierten (beispielsweise TCP-basierten) Protokollen
kann es sinnvoll sein, auch akzeptierte Pakete zu protokollieren, die zu
einem Verbindungsaufbau gehren (beispielsweise TCP-Pakete, die zum 3-
Wege-Handshake gehren), sowie eventuell zustzlich Pakete, die zum
Abbau einer bestehenden Verbindung gehren.
- Bei verbindungslosen Protokollen, ber die keine groen Datenmengen
bertragen werden (beispielsweise UDP-basierte Protokolle wie DNS)
kann es unter Umstnden sinnvoll sein, alle Pakete zu protokollieren.
Welche zustzlichen Klassen von Paketen protokolliert werden hngt in erster
Linie vom Schutzbedarf des vertrauenswrdigen Netzes ab. Allerdings bringt
die Protokollierung alleine keinen Sicherheitsgewinn, sondern die
Informationen mssen auch nach entsprechenden Kriterien ausgewertet
werden.
Von den Paketen, fr die eine Protokollierung gewnscht wird, sollten
mindestens die folgenden Informationen protokolliert werden:
- Quell- und Ziel-IP-Adresse
- Quell- und Zielport oder ICMP-Typ
- Datum und Zeit
- zutreffende Regel des Paketfilters
Wird zustzlich ein ALG verwendet, so kann auf die Protokollierung der
akzeptierten Pakete verzichtet werden, da der Proxy in diesem Fall meist
ausreichende Verbindungsinformationen protokolliert.
Umfang der Protokollierung am Application-Level-Gateway
Auf dem ALG, der durch den ueren Paketfilter vor der groen Masse Auf dem ALG alle
Verbindungen
unzulssiger Pakete geschtzt wird, sollten fr jeden (erfolgreichen oder protokollieren
versuchten) Verbindungsaufbau die folgenden Daten protokolliert werden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Quell- und Ziel-IP-Adresse

- Quell- und Zielport
- Dienst
- Datum und Zeit
- Verbindungsdauer
- eventuell Authentisierungsdaten oder ausschlielich Tatsache des
Fehlschlagens einer Authentisierung
Es muss mglich sein, fr bestimmte Benutzer die Protokollierung
abzuschalten, damit nicht wegen einer zu groen Anzahl von
Protokolleintrgen wichtige Informationen bersehen werden. Diese Auswahl
kann z. B. anhand des Rechteprofils einzelner Benutzer getroffen werden.
Fr die einzelnen Protokolle werden darber hinaus die folgenden
Einstellungen empfohlen:
DNS
- Ablehnung von Anfragen
- Zulassen von Anfragen
- von anderen Rechnern initiierte ("ausgehende") Zonen-Transfers
- vom ALG initiierte ("eingehende") Zonen-Transfers
Zonen-Transfers werden in der Regel vom Betreiber des DNS-Server
verhindert, so dass auf diese berprfungen auch verzichtet werden kann.
FTP
- Ziel-Adresse (URL)
- Abgelehnte PORT-Befehle
- Name der bertragenen Datei
- Menge der bertragenen Daten
- Statusnachricht
HTTP
- Verbindungsmethode (z. B. GET, POST, CONNECT)
- Hinweis auf angewandte Filterkriterien
- Statusnachricht
NNTP
- Statusnachricht
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SMTP
- E-Mail-Adresse des Absenders und des Empfngers der E-Mail
- Hinweis auf angewandte Filterkriterien
- Statusnachricht ber Erfolg oder Misserfolg der Weiterleitung
Bei folgenden Modulen braucht keine gesonderte Protokollierung erfolgen:
Modul Begrndung fr Wegfall der Protokollierung
HTTPS Wird "in Reihe" mit einem HTTP-Proxy geschaltet, der
bereits protokolliert.
Wartungsmodul Relevante Protokolldaten fallen nicht an.
IDS Protokolldaten werden auf dem IDS gesondert
geliefert. Diese sollten nicht zentral gespeichert
werden, um eine Umgehung von Modulen des
Sicherheitsgateways zu unterbinden.
Tabelle 1: Module ohne gesonderte Protokollierung
Die Protokollierung wird stark vereinfacht, wenn die Software die freie
Konfigurierbarkeit der "logging facility" (d.h. eine Kennzeichnung der
einzelnen Log-Eintrge) ermglicht. Dadurch ist es mglich, jedem Dienst
eine eindeutige Kennung zuzuordnen, anhand derer der Loghost die
Protokolldaten auf verschiedene Dateien verteilen kann.
Werden die Protokolldaten ber das Netz zu einem zentralen Loghost
geschickt, so muss darauf geachtet werden, dass die Log-Eintrge
verschiedener Rechner und Dienste so gekennzeichnet werden, dass sie
eindeutig zugeordnet werden knnen. Zustzlich ist es sinnvoll, wenn alle
Dienste ihre Protokolldaten fortlaufend nummerieren. Dadurch kann der
Verlust bzw. die Manipulation von Protokolldaten erkannt werden.
Auswertung der Protokolldaten
Die Auswertung von Protokolldaten kann mit speziellen Tools untersttzt
werden ("logfile analyzer"). Diese stellen die Protokolldateien auf
unterschiedliche Weise dar, wobei sich die meisten Tools regulrer Ausdrcke
bedienen, um relevante Daten aus den Protokolldateien zu extrahieren.
Obwohl Listen mit sinnvollen regulren Ausdrcken zum Zwecke der
Protokolldatenauswertung existieren, sind im Einzelfall meist Anpassungen
notwendig.
Beispiele fr verschiedene Ausgaben der Protokolldateien sind:
- Gruppierung und Markierung zusammengehrender Protokolldaten (z. B.
LogSurfer)
- Anzeige relevanter Protokolldaten, wobei irrelevante Daten mittels
regulrer Ausdrcke ausgeblendet werden knnen. Auf diese Weise
knnten beispielsweise diejenigen Protokolldaten ausgeblendet werden, die
eine erfolgreiche Operation (z. B. GET bei HTTP) dokumentieren (z. B.
checksyslog).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Anzeige von Angriffen. Die Analyse der Protokolldaten muss dabei in

Echtzeit vorgenommen werden.
- Statistische Analyse der Protokolldaten (z. B. wie oft trat welche Meldung
auf).
Neben der reinen Darstellung relevanter Protokolldaten existieren Tools, die
abhngig von einer erkannten Aufflligkeit Aktionen (z. B. Ausfhren eines
Befehls) ermglichen.
Auffllige Protokolleintrge sind beispielsweise:
- Gehuft auftretende Anfragen an Ports, auf denen keine Dienste laufen
- Nicht erfolgreiche Zugriffsversuche auf Komponenten des
Sicherheitsgateways
- Aus dem nicht-vertrauenswrdigen Netz eintreffende Pakete mit IP-
Adressen des vertrauenswrdigen Netzes (Hinweis auf IP-Spoofing)
- Verdchtige, ausgehende Verbindungen von Servern aus dem
vertrauenswrdigen Netz. Diese knnen ein Anzeichen dafr sein, dass
nach einem erfolgreichen Einbruch der Angreifer Daten aus dem
vertrauenswrdigen Netz nach auen kopiert oder von auen Dateien
nachldt, die er fr seine weiteren Aktivitten braucht.
Die Protokolldateien mssen regelmig ausgewertet werden und es sollte Regelmige
Auswertung
festgelegt werden, welche Auswertungen mindestens erfolgen sollen. Darber
hinaus sollten zumindest grobe Richtlinien dafr festgelegt werden, welche
Schritte unternommen werden, wenn bei der Auswertung auffllige Eintrge
festgestellt werden.
- Welche Informationen werden an den Paketfiltern protokolliert?
- Falls ein ALG eingesetzt wird: Welche Informationen werden vom ALG
fr die verschiedenen Dienste protokolliert?
- In welchen Abstnden und nach welchen Kriterien werden die Protokolle
ausgewertet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.48 Passwortschutz unter Windows NT/2000

Der Zugang zu einem Windows NT/2000 System muss fr jeden Benutzer
durch ein Passwort geschtzt sein. Benutzerkonten ohne Passwort drfen nicht
existieren, da sie eine Schwachstelle im System darstellen. Es ist wichtig, dass
auch die Benutzer die Schutzfunktion der Passwrter kennen, denn die
Mitarbeit der Benutzer trgt selbstverstndlich zur Sicherheit des gesamten
Systems bei.
Die Einrichtung eines neuen Benutzers und die Definition eines Passwortes individuelles
Anfangspasswort
erfolgt unter Windows NT mit Hilfe des Dienstprogramms Benutzer-Manager vergeben
ber das Kommando Neuer Benutzer. Unter Windows 2000 ist dazu fr Stand-
alone Rechner das Microsoft Management Consolen (MMC) Snap-in Lokale
Benutzer und Gruppen zu benutzen. Fr in Domnen angesiedelte Rechner
erfolgt das Anlegen neuer Benutzer ber das MMC Snap-in Active Directory
Benutzer und Computer. In jedem Fall sind dazu in den Feldern Kennwort und
Kennwortbesttigung ein Anfangspasswort mit maximal 14 Zeichen
einzugeben. Die Gro- und Kleinschreibung muss beachtet werden. Dabei
sollte ein sinnvolles Anfangspasswort vergeben werden, das dem Benutzer
mitgeteilt wird. Die immer gleiche Wahl des Anfangspasswortes oder die
Verwendung des Benutzernamens als Passwort erffnet eine Sicherheitslcke,
die mit geringem Aufwand vermieden werden kann.
Die Option Benutzer muss Kennwort bei der nchsten Anmeldung ndern
sollte bei allen neuen Konten gesetzt sein, damit das Anmeldepasswort nicht
beibehalten wird. Dagegen sollte die Option Benutzer kann Kennwort nicht
ndern nur in Ausnahmefllen verwendet werden, etwa fr vordefinierte
Konten im Schulungsbetrieb. Die Option Kennwort luft nie ab sollte nur fr
Benutzerkonten, denen mit Hilfe der Systemsteuerungsoption Dienste ein
Dienst zugewiesen wird (zum Beispiel der Reproduktionsdienst) verwendet
werden. Diese Option setzt die Einstellung Maximales Kennwortalter in den
Richtlinien fr Konten auer Kraft und verhindert, dass das Passwort abluft.
Fr Windows NT knnen ber den Benutzer-Manager Richtlinien fr
Benutzerkonten, Benutzerrechte und fr die Systemberwachung festgelegt
werden. Unter Windows 2000 erfolgt das Festlegen der Richtlinien entweder
durch das MMC Snap-in Lokale Sicherheitseinstellungen oder durch das
Snap-in Gruppenrichtlinien. Dabei knnen die Einstellungen der
Gruppenrichtlinien fr Rechner, die einer Domne angeschlossen sind, auch
ber das Active Directory gewartet und verteilt werden (siehe M 2.231
Planung der Gruppenrichtlinien unter Windows 2000).
Die folgenden Windows NT bezogenen Parameter und Werte finden sich
unter Windows 2000 analog in den lokalen Sicherheitseinstellungen unter
Kontorichtlinien bzw. in einer Gruppenrichtlinie unter Computerkonfiguration
/ Windows-Einstellungen / Sicherheitseinstellungen / Kontorichtlinien. Die
angegeben Werte knnen dort entsprechend eingestellt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
In den Richtlinien fr Benutzerkonten sollte als minimale Passwortlnge der

Wert 8 eingetragen werden (siehe auch M 2.11 Regelung des
Passwortgebrauchs).
Die Passworthistorie sollte grundstzlich eingeschaltet sein und wenigstens 6
Passwrter umfassen. Die Gltigkeitsdauer des Passwortes (Maximales Kenn-
wortalter) sollte auf einen Zeitraum von maximal 6 Monaten begrenzt sein.
Durch Festlegung eines Wertes fr das Minimale Kennwortalter kann ver-
hindert werden, dass Benutzer ihr Passwort mehrfach hintereinander ndern,
umso die Historienprfung zu umgehen. Das Minimale Kennwortalter sollte
jedoch nicht grer als 1 Tag gewhlt werden, um dem Benutzer jederzeit eine
Passwortnderung zu ermglichen.
Hinweis: Der Parameter Sofortige nderungen erlauben darf unter der
Version 3.51 von Windows NT nicht gewhlt werden, da sonst die Prfung
der Passworthistorie abgeschaltet wird. Dieser Parameter existiert unter
Windows 2000 nicht, sondern wird ber das minimale Kennwortalter gesetzt.
Benutzerkonten sollten nach wiederholten ungltigen Passworteingaben Benutzerkonten nach
mehreren Fehlversuchen
gesperrt werden, um Versuche zu erschweren, die Passwrter der Benutzer zu sperren
erraten. Die Option Konto sperren sollte auf jeden Fall aktiviert werden. Dazu
sollte die Option Sperren nach, die die Anzahl (1 bis 999) der ungltigen
Anmeldeversuche festlegt, die zur Sperrung des Kontos fhren, auf einen
Wert zwischen 3 und 10 gesetzt werden. Die Option Konto zurcksetzen nach,
die die maximale Anzahl von Minuten (1 bis 99999) zwischen zwei
ungltigen Anmeldeversuchen angibt, sollte auf etwa eine halbe Stunde
gesetzt werden. Wenn z. B. fr Sperren nach der Wert 5 und fr Konto
zurcksetzen nach der Wert 30 angegeben ist, erfolgt eine Sperrung nach 5
ungltigen Anmeldeversuchen, die innerhalb von 29 Minuten unternommen
wurden.
In der Regel sollte durch Aktivieren der Option Fr immer festgelegt werden,
dass die Sperre so lange aktiv bleibt, bis ein Administrator sie aufhebt. Sofern
hierdurch eine zu hohe Belastung der Administratoren verursacht wird, kann
auch ein geeigneter Wert als Dauer der Sperrung angegeben werden, damit
die Kontensperre nur fr eine begrenzte Zeitdauer erhalten bleibt. Wenn beab-
sichtigt ist, den Ursachen der Kontensperrung direkt nachzugehen, sollte ein
hinreichend langes Zeitintervall, z. B. 1440 Minuten (1 Tag) angegeben
werden, andernfalls sollte ein Wert von etwa 30 Minuten gewhlt werden.
Es ist zu beachten, dass das vordefinierte Administratorkonto von dieser
automatischen Sperrung ausgenommen ist, um ein vlliges Verriegeln des
Systems zu vermeiden (siehe M 4.77 Schutz der Administratorkonten unter
Windows NT).
Dagegen sollte von der Option Benutzer muss sich anmelden, um Kennwort zu
ndern kein Gebrauch gemacht werden. Insbesondere mit der Einstellung
Benutzer muss Kennwort bei der nchsten Anmeldung ndern fhrt diese Ein-
stellung dazu, dass neue Benutzer keinen Zugang zum Rechner erhalten.
Die in der folgenden Abbildung dargestellten Werte fr die Richtlinien geben
einen fr mittleren Sicherheitsbedarf ausreichenden Schutz:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind die Vorgaben fr die Benutzerkonten-Richtlinien dokumentiert?
- Werden die Einstellungen im Benutzer-Manager regelmig kontrolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.49 Absicherung des Boot-Vorgangs fr ein Win-

dows NT/2000 System
Windows NT/2000 kann nur dann sicher betrieben werden, wenn vom
Systemstart an gewhrleistet ist, dass eine geschlossene Sicherheitsumgebung
aufgebaut wird, also dass keine Wege an den Sicherheitsfunktionen des
Betriebssystems vorbei bestehen. Dies erfordert, dass sich alle durch
Windows NT/2000 schtzbaren Ressourcen unter der Kontrolle des
Betriebssystems befinden. Auerdem darf es auch keine Mglichkeit geben,
fremde Systeme oder offene Systemumgebungen zu starten, die den durch
Windows NT/2000 gebotenen Schutz unterlaufen knnen. Dazu sind die
folgenden Aspekte zu beachten:
- Alle vorhandenen Festplattenpartitionen mssen mit dem Dateisystem NTFS verwenden
NTFS formatiert sein. Partitionen, die mit den Dateisystemen FAT, VFAT
oder HPFS formatiert sind, knnen nicht gegen Zugriffe der Benutzer
geschtzt werden. Dies bedeutet einerseits, dass die auf ihnen abgelegten
Daten beliebigen Zugriffen aller Benutzer ausgesetzt sind, und andererseits
knnen diese Partitionen zum unkontrollierten Datenaustausch zwischen
Benutzern missbraucht werden.
- Ein hnliches Risiko stellen Diskettenlaufwerke dar, da Disketten unter Diskettenlaufwerke
sperren
Windows NT/2000 nur mit dem Dateisystem FAT bzw. VFAT formatiert
werden knnen. Aus diesem Grund sind Diskettenlaufwerke an allen
Rechnern, die nicht unter strikter physischer Kontrolle stehen,
grundstzlich zu sperren (siehe M 4.4 Geeigneter Umgang mit Laufwerken
fr Wechselmedien). Auf Windows NT/2000 Clients knnen die Disket-
tenlaufwerke auch durch Deaktivieren ber die Systemsteuerungsoption
Gerte bzw. Computerverwaltung/Gerte-Manager, Gert Floppy, die
Diskettenlaufwerke fr unprivilegierte Benutzer auer Betrieb gesetzt
werden. Hiervon sollte auf Windows NT/2000 Servern abgesehen werden
(siehe hierzu M 4.52 Gerteschutz unter Windows NT/2000).
- Verfgt der Rechner ber ein offenes Diskettenlaufwerk oder ist es Booten von CD-ROM
verhindern
mglich, von einem vorhandenen CD-ROM-Laufwerk zu booten, so
besteht die Gefahr, dass der Rechner mit einem anderen Betriebssystem als
Windows NT/2000 gestartet wird. Die gleiche Gefhrdung ergibt sich,
wenn auf einer lokalen Festplatte andere Betriebssysteme installiert sind.
Dann kann der Anwender mit verschiedenen Programmen die
Sicherheitsmechanismen von Windows NT/2000 umgehen. Inzwischen
gibt es mehrere Programme, mit denen man Dateien, die unter NTFS
geschtzt sind, von einer DOS-Umgebung oder einer Linux-Umgebung
lesen und z. T. auch ndern kann. Sowohl unter dem Betriebssystem MS-
DOS als auch unter dem Betriebssystem Linux werden die vom
Dateisystem NTFS gesetzten Sicherheitsattribute ignoriert. Der Anwender
hat daher von MS-DOS bzw. von Linux aus Zugriff auf alle Dateien des
Rechners. Aus diesem Grund drfen neben Windows NT/2000 keine
weiteren Betriebssysteme auf der Festplatte installiert sein. Auerdem ist
der Boot-Vorgang durch eine mit einem BIOS-Passwort geschtzte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Einstellung des BIOS so abzusichern, dass das System nicht von einem
eventuell vorhandenen Diskettenlaufwerk oder von einem CD-ROM-
Laufwerk aus gestartet werden kann (siehe M 4.1 Passwortschutz fr IT-
Systeme).
- Im Rahmen einer Neuinstallation von Windows NT/2000 hat man die BOOT.INI schtzen
Mglichkeit, die bestehende Installation des Betriebssystems zu
aktualisieren oder eine neue Version parallel zu installieren. Bei der
parallelen Installation wird die bestehende Dateistruktur nicht verndert,
doch wird das vordefinierte Administratorkonto mit einem neuen Passwort
neu angelegt. Dieser "neue" Administrator hat dann vollen Zugriff auf alle
Ressourcen des Rechners und damit auch auf alle Daten und Programme.
Um diese Mglichkeit der Neuinstallation zu verhindern, drfen Benutzer
nicht in der Lage sein, die Datei BOOT.INI im Wurzelverzeichnis der
ersten Platte zu verndern (siehe M 4.53 Restriktive Vergabe von
Zugriffsrechten auf Dateien und Verzeichnisse unter Windows NT,
M 4.149 Datei- und Freigabeberechtigungen unter Windows 2000).
- Mit Hilfe der Installationsprogramme kann auch eine Notfalldiskette (siehe
M 6.42 Erstellung von Rettungsdisketten fr Windows NT,
M 6.77 Erstellung von Rettungsdisketten fr Windows 2000) erzeugt und
mit dieser dann eine Systemrekonstruktion durchgefhrt werden. Dabei
wird der Zugriffsschutz der NTFS-Partition des Betriebssystems
aufgehoben. Es ist aus diesem Grund unbedingt erforderlich, die
Installationsprogramme, eine eventuell schon vorhandene Notfalldiskette
und die Setup-Disketten so zu verwahren, dass sie gegen unbefugten
Zugriff geschtzt sind. Schutz gegen diese spezifische Bedrohung bietet
auch die Sicherung der Diskettenlaufwerke (siehe M 4.4 Geeigneter
Umgang mit Laufwerken fr Wechselmedien) und die Absicherung des
Boot-Vorgangs durch die entsprechende Einstellung des BIOS (s. o.).
Unter Windows NT/2000 ist das lokale Anmelden auf dem Server nur fr
Benutzer mglich, denen das Benutzerrecht Lokale Anmeldung gegeben
wurde. Diese Benutzer sind auf die ihnen zugewiesenen Rechte und
Berechtigungen eingeschrnkt. Um einen Missbrauch der Mglichkeiten zum
Anmelden auf dem Server zu vermeiden, sind die Benutzerrechte und die
Zuordnungen zu Benutzergruppen entsprechend restriktiv vorzusehen (siehe
Manahmen M 2.93 Planung des Windows NT Netzes und M 4.50
Strukturierte Systemverwaltung unter Windows NT). Unter Windows 2000
erfolgt die Verwaltung der Benutzerrechte ber die lokalen
Sicherheitseinstellungen bzw. ber Gruppenrichtlinien (siehe
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000).
- Ist sichergestellt, dass Benutzer den Computer nicht von Disketten- oder
CD-ROM-Laufwerken booten knnen?
- Ist die Datei BOOT.INI im Wurzelverzeichnis der ersten Platte vor
Vernderungen geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.50 Strukturierte Systemverwaltung unter

Windows NT
Benutzergruppen sind unter Windows NT Zusammenstellungen von
Benutzerkonten. Wenn ein Benutzerkonto zu einer Gruppe hinzugefgt wird,
erhlt der betreffende Benutzer alle Rechte und Berechtigungen, die der
Gruppe erteilt wurden. So kann man leicht bestimmte Benutzer mit gemein-
samen Mglichkeiten ausstatten. Nach Mglichkeit sollten die Rollen der
Mitarbeiter auf Gruppen abgebildet und diesen Gruppen entsprechend ihren
Bedrfnissen die Zugriffsrechte zugeteilt werden.
Die Verwendung von Gruppen an Stelle der Zuweisung von Rechten und
Berechtigungen an einzelne Benutzer erleichtert die Administration und trgt
durch grere Transparenz zur Erhhung der Systemsicherheit bei. Auch bei
einer geringen Anzahl von Mitarbeitern sollten Gruppen gebildet werden.
Hierdurch muss bei einer Erweiterung keine grundstzliche Umstrukturierung
der Rechtestrukturen durchgefhrt werden.
Rechte und Berechtigungen sind additiv, d. h. fr einen Benutzer, der Mitglied
in mehreren Gruppen ist, gilt in Bezug auf eine Ressource die jeweils
weitestgehende Zugriffsberechtigung. Es gibt allerdings eine Ausnahme: Ist
ein Benutzer Mitglied einer Gruppe, der auf eine Ressource die Zugriffs-
berechtigung "Kein Zugriff" zugeteilt wurde, so kann der Benutzer auf diese
Ressource nicht zugreifen, auch dann nicht, wenn er Mitglied einer anderen
Gruppe ist, der auf diese Ressource die Zugriffsberechtigung "Vollzugriff"
erteilt wurde (siehe auchM 4.53 Restriktive Vergabe von Zugriffsrechten auf
Dateien und Verzeichnisse unter Windows NT).
Beispiel:
Benutzer Meier ist Mitglied der Gruppen "A" und "B". Der Gruppe "A" wurde
auf ein Verzeichnis "Rechnung" die Zugriffsberechtigung "Lesen", der
Gruppe "B" wurden auf dieses Verzeichnis die Zugriffsberechtigungen "Lesen
und Schreiben" zugewiesen. Der Benutzer Meier hat damit auf das
Verzeichnis "Rechnung" die Zugriffsberechtigungen "Lesen und Schreiben".
Das Benutzergruppenkonzept von Windows NT unterscheidet zwischen
globalen und lokalen Gruppen.
Lokale Gruppen
Die Gruppe wird "lokal" genannt, weil ihr Berechtigungen und Rechte nur fr
den Rechner erteilt werden knnen, auf dem sie definiert wurde. Auf
Rechnern unter dem Betriebssystem Windows NT (d. h. sowohl Servern als
auch Workstations), die keiner Domne angehren, gibt es nur lokale Grup-
pen. Um die Vergabe von Rechten und Berechtigungen zu strukturieren, wird
auf solchen Rechnern ausschlielich dieser Gruppentyp benutzt.
Gehrt ein Rechner unter Windows NT einer Domne an, so sind lokale
Gruppen ebenfalls verfgbar. Sie knnen dann Benutzerkonten aus dem eige-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nen Rechner und Benutzerkonten und globale Gruppen aus der eigenen
Domne und aus vertrauten Domnen beinhalten.
Lokale Gruppen knnen keine Berechtigungen auf Ressourcen anderer
Domnen erhalten. Es ist nicht mglich, eine lokale Gruppe zum Mitglied
einer anderen lokalen Gruppe zu machen. Lokale Gruppen werden im
Benutzermanager durch ein Gruppensymbol mit einem Computer dargestellt.
Globale Gruppen
Wenn ein Rechner, auf dem Windows NT ausgefhrt wird, einer Domne
angehrt, gibt es einen weiteren Gruppentyp, dem der Zugriff auf die
Arbeitsstation ermglicht werden kann. Es handelt sich um die "Globale
Gruppe", die an mehreren Orten verwendet werden kann: in der eigenen
Domne, auf Servern, auf Arbeitsstationen der Domne und in vertrauten
Domnen. Wenn eine Arbeitsstation einer Domne angehrt, bedeutet dies,
dass den globalen Gruppen der Domne und der vertrauten Domnen Berech-
tigungen und Rechte fr die Arbeitsstation sowie die Zugehrigkeit zu lokalen
Gruppen der Arbeitsstation erteilt werden knnen. Eine globale Gruppe kann
nur Benutzerkonten der eigenen Domne enthalten.
Globale Gruppen knnen nur auf dem primren Domnencontroller definiert
werden. Es ist nicht mglich, dass andere Gruppen Mitglied einer globalen
Gruppe werden. Globale Gruppen werden im Benutzermanager durch ein
Gruppensymbol mit einem Globus dargestellt.
Zusammenfassend empfiehlt sich folgendes Vorgehen zur strukturierten
Systemverwaltung:
Rechte und Berechtigungen werden lokalen Gruppen zugewiesen. Benutzer
werden Mitglied in globalen Gruppen, und die globalen Gruppen werden
Mitglied in lokalen Gruppen.
Neben der Unterscheidung in lokale und globale Gruppen gibt es auch noch
die Unterscheidung zwischen vordefinierten Benutzergruppen, besonderen
Gruppen und frei definierten Benutzergruppen:
Vordefinierte Benutzergruppen
Welche Aktionen ein Benutzer durchfhren kann, hngt von den Gruppen-
mitgliedschaften seines Benutzerkontos ab. Es sind mehrere Gruppen in
Windows NT vordefiniert, und standardmig wird jeder Gruppe ein
bestimmter Satz von Benutzerrechten erteilt. Bei Bedarf knnen mit dem
Benutzermanager zustzliche Gruppen erstellt und definiert werden, mit denen
den ihnen zugewiesenen Benutzern der Zugriff auf individuell zusam-
mengestellte Ressourcen ermglicht wird.
Zustzlich zu den Rechten werden einigen der vordefinierten lokalen Gruppen
vordefinierte Funktionen zugeteilt. Rechte und Zugriffsberechtigungen
knnen den Gruppen und Benutzerkonten direkt erteilt und ihnen entzogen
werden. Dagegen sind die vordefinierten Funktionen nicht direkt verwaltungs-
fhig. Vordefinierte Funktionen knnen fr einen Benutzer nur bereitgestellt
werden, wenn der Benutzer zum Mitglied einer geeigneten lokalen Gruppe
ernannt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Auf Rechnern, die unter dem Betriebssystem Windows NT als Mitglieds-

server (Server ohne Domnencontroller-Funktionalitt) oder als Workstation
konfiguriert sind, werden folgende lokale Gruppen standardmig bei der
Installation eingerichtet:
- Administratoren
- Sicherungs-Operatoren
- Hauptbenutzer
- Replikations-Operatoren
- Benutzer
- Gste
Die Rechte und Funktionen, die unter Windows NT auf Workstations und
Servern, die nicht als Domnencontroller konfiguriert sind, bestimmten vor-
definierten lokalen Gruppen erteilt werden, sind in der folgenden Tabelle
angegeben:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Auf Servern, die unter dem Betriebssystem Windows NT als Domnen-

controller konfiguriert sind, werden folgende lokale Gruppen standardmig
bei der Installation eingerichtet:
- Administratoren
- Sicherungs-Operatoren
- Server-Operatoren
- Konten-Operatoren
- Druck-Operatoren
- Replikations-Operatoren
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Benutzer
- Gste
Auerdem werden in dieser Konfiguration folgende globale Gruppen bei der
Installation angelegt:
- Domnen-Admins
- Domnen-Benutzer
- Domnen-Gste
Die Rechte und Funktionen, die unter Windows NT auf Domnencontrollern
bestimmten vordefinierten lokalen Gruppen erteilt werden, sind in der folgen-
den Tabelle angegeben:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hinweis: Die oben beschriebenen Rechte, die unter Windows NT standard-

mig vergeben sind, sind alle einzeln daraufhin zu berprfen, ob sie mit der
festgelegten Sicherheitsstrategie vereinbar sind (siehe M 2.91 Festlegung
einer Sicherheitsstrategie fr das Windows NT Client-Server-Netz). So sollte
beispielsweise das Recht "Zugriff auf diesen Computer vom Netz" der Gruppe
"Jeder" entzogen werden. Ob es ersatzweise der Gruppe "Benutzer"
zugestanden wird, ist im einzelnen zu klren.
Die folgenden vordefinierten Gruppen stehen unter Windows NT zur Verf-
gung:
- Administratoren - Die Gruppe "Administratoren" ist die mchtigste Gruppe
in Windows NT. Die Mitglieder dieser Gruppe verwalten die
Gesamtkonfiguration des Systems. Das vordefinierte Benutzerkonto
"Administrator" ist Mitglied der Gruppe "Administratoren". Falls ein
Rechner einer Domne angehrt, ist die Gruppe "Domnen-Admins"
standardmig Mitglied der Gruppe "Administratoren" dieses Rechners.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hinweis: Benutzerkonten dieser Gruppe sollten nur zu System-

verwaltungsarbeiten verwendet werden, die die volle Kontrolle ber das
System erfordern. Arbeiten, die unter eingeschrnkten Rechten durch-
gefhrt werden knnen, sollten nach Mglichkeit von Benutzerkonten aus
erledigt werden, die einer der anderen Gruppen angehren, um die Gefhr-
dung des Systems durch Arbeiten mit unbeschrnkten Rechten zu redu-
zieren. Insbesondere sollte fr jeden Administrator zur Erledigung der tg-
lichen Routinearbeiten jeweils ein Benutzerkonto angelegt werden, das nur
der Gruppe "Benutzer" oder einer bzw. mehreren frei definierten Gruppen
angehrt. Die Anzahl der Benutzerkonten in der Gruppe "Administratoren"
sollte so gering wie mglich gehalten werden.
Administratoren sind der normalen Zugriffskontrolle unterworfen und
besitzen nicht automatisch Zugriff auf jede Datei. Bei Bedarf kann ein
Administrator den Besitz einer Datei bernehmen und dadurch auf sie
zugreifen. Der Administrator kann die Datei jedoch in diesem Fall nicht
wieder an den ursprnglichen Besitzer zurckgeben, da Windows NT
hierzu keine Funktion bereitstellt.
- Domnen-Admins - Die globale Gruppe der "Domnen-Admins" ist Mit-
glied der lokalen Gruppe der Administratoren fr die betreffende Domne
und der lokalen Gruppen der Administratoren jedes Rechners in der
Domne, so dass die Domnen-Administratoren die Domnencontroller,
alle Server und alle anderen Rechner in der Domne verwalten knnen.
Das vordefinierte Administratorkonto des Domnencontrollers ist Mitglied
der Gruppe "Domnen-Admins".
- Hauptbenutzer - Die unter Windows NT Workstation definierte lokale
Gruppe "Hauptbenutzer" stellt den Benutzerkonten ihrer Mitglieder einge-
schrnkte administrative Funktionen bereit. Ein Hauptbenutzer kann Ver-
zeichnisse im Netz freigeben, die interne Uhr des Computers einstellen,
Drucker installieren, freigeben und verwalten sowie allgemeine
Programmgruppen erstellen. Sie knnen Benutzerkonten und Gruppen
erstellen und die von ihnen erstellten Benutzerkonten und Gruppen ndern
und lschen, und sie knnen fr die Gruppen "Hauptbenutzer", "Benutzer"
und "Gste" Mitglieder entfernen bzw. hinzufgen.
Hauptbenutzer knnen jedoch nicht die Gruppen "Administratoren",
"Domnen-Admins", "Konten-Operatoren", "Sicherungs-Operatoren",
"Druck-Operatoren" und "Server-Operatoren" verndern oder lschen,
und sie knnen auch keine Benutzerkonten von Administratoren verndern
oder lschen.
Hinweis: Diese Gruppe sollte verwendet werden, um Untersystem-
verwalter zu definieren, die den Systemverwalter von gewissen Routine-
aufgaben, insbesondere in der Verwaltung der Benutzerkonten, entlasten,
ohne jedoch dazu die volle Kontrolle ber das System zu erhalten.
- Konten-Operatoren - Die auf Domnencontrollern definierte lokale Gruppe
"Konten-Operatoren" entspricht weitgehend der unter Windows NT
Workstation definierten Gruppe "Hauptbenutzer".
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Benutzer - Die Zugehrigkeit zur lokalen Gruppe "Benutzer" bietet die

Funktionen, die ein Benutzer zur Durchfhrung der alltglichen Aufgaben
bentigt. Mit Ausnahme der vordefinierten Administrator- und Gastkonten
gehren alle Benutzerkonten der Arbeitsstation der Gruppe "Benutzer" an.
Wird ein neues Benutzerkonto hinzugefgt, so wird es automatisch
Mitglied dieser Gruppe. Falls ein Rechner einer Domne angehrt, ist die
Gruppe der Domnen-Benutzer standardmig Mitglied der Gruppe
"Benutzer" dieses Rechners.
Hinweis: Normalerweise sollten alle Benutzer, die keine erweiterten
Rechte bentigen, nur dieser vordefinierten Gruppe sowie geeigneten frei
definierten Gruppen angehren, die die Organisationsstruktur wider-
spiegeln. Zuordnungen zu den anderen vordefinierten Gruppen sollten nur
in begrndeten Einzelfllen vorgenommen werden. Dies bedeutet auch,
dass Benutzer keine Administratorrechte auf ihren Arbeitsplatzrechnern
erhalten sollten.
- Domnen-Benutzer - Die globale Gruppe der "Domnen-Benutzer" enthlt
ursprnglich das eingebaute Konto des Administrators fr die betreffende
Domne. Beim Anlegen neuer Konten werden diese automatisch in die
Gruppe der "Domnen-Benutzer" eingetragen. Diese Gruppe ist standard-
mig Mitglied der lokalen Gruppe "Benutzer" fr die betreffende Domne
und der lokalen Gruppen der "Benutzer" jedes Rechners in der Domne, so
dass die "Domnen-Benutzer" normalen Zugang und normale Rechte und
Berechtigungen bezglich aller Rechner in der Domne haben.
- Gste - Die lokale Gruppe "Gste" ermglicht es dem gelegentlichen oder
einmaligen Benutzer, sich anzumelden und mit eingeschrnktem Funk-
tionsumfang zu arbeiten. Das vordefinierte Gastbenutzerkonto ist Mitglied
der Gruppe "Gste". Die der Gruppe "Benutzer" erteilten Ressourcen-
berechtigungen knnen der Gruppe "Gste" vorenthalten werden, so dass
die Mglichkeiten der Mitglieder dieser Gruppe geeignet eingeschrnkt
werden knnen.
Hinweis: Nach Mglichkeit sollten dieser Gruppe auer dem vordefi-
nierten Gastkonto keine weiteren Benutzerkonten angehren, und das vor-
definierte Gastkonto sollte gesperrt sein (siehe M 4.55 Sichere Installation
von Windows NT). Auerdem sollte es vorsorglich mit einem Passwort
versehen werden, um unbefugten Zugriffen vorzubeugen, falls es kurz-
fristig entsperrt werden sollte.
- Domnen-Gste - Die globale Gruppe der "Domnen-Gste" enthlt
ursprnglich das eingebaute Gastbenutzerkonto fr die betreffende
Domne. Diese Gruppe ist Mitglied der lokalen Gruppe der Gste fr die
betreffende Domne.
- Sicherungs-Operatoren - Die Mitglieder der lokalen Gruppe "Sicherungs-
Operatoren", die standardmig auf allen Rechnern unter Windows NT
definiert ist, knnen Dateien und Verzeichnisse sichern und wiederher-
stellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Hinweis: Datensicherungen und die Wiederherstellung gesicherter Daten

sollten von einem Mitglied dieser Gruppe durchgefhrt werden. Es ist
hierzu nicht erforderlich, ein Administratorkonto zu verwenden.
- Druck-Operatoren - Die Mitglieder der auf Domnencontrollern definier-
ten lokalen Gruppe "Druck-Operatoren" knnen Drucker auf den
Domnencontrollern verwalten. Sie knnen sich auch auf diesen Servern
anmelden und sie herunterfahren.
Hinweis: Die Verwaltung von Druckern sollte von Mitgliedern dieser
Gruppe durchgefhrt werden, um die unntige Nutzung von Admini-
stratorkonten zu vermeiden.
- Server-Operatoren - Die Mitglieder der auf Domnencontrollern definier-
ten lokalen Gruppe "Server-Operatoren" knnen die Drucker- und Netz-
freigaben auf dem jeweiligen Domnencontroller verwalten. Weiterhin
knnen sie Dateien und Verzeichnisse sichern und wiederherstellen, den
Domnencontroller sperren und freigeben, die Festplatten des Domnen-
controllers formatieren und die Systemzeit verndern. Schlielich knnen
sie sich auch auf dem Domnencontroller anmelden und ihn herunter-
fahren.
Hinweis: Routinearbeiten zur Steuerung der Domnencontroller sollten
von Mitgliedern dieser Gruppe durchgefhrt werden, soweit sie mit den
Rechten dieser Gruppe ausgefhrt werden knnen. Nur Arbeiten, die die
vllige Kontrolle ber das System erfordern, sollten von Administrator-
konten aus durchgefhrt werden.
- Replikations-Operator - Die auf Rechnern unter Windows NT definierte
lokale Gruppe "Replikations-Operator" untersttzt die Funktionen der
Verzeichnisreproduktion. Der Gruppe "Replikations-Operator" sollte als
einziges Mitglied ein Domnenbenutzerkonto angehren, das zum Anmel-
den des Replikationsdienstes der Arbeitsstation dient.
Hinweis: Dieser Gruppe sollten keine Konten von Benutzern hinzugefgt
werden, und das dort vorhandene Benutzerkonto sollte nicht ber die
Rechte "Lokale Anmeldung" und "Zugriff auf diesen Computer vom Netz"
verfgen.
Besondere Gruppen
Zustzlich zu den oben erwhnten vordefinierten Gruppen erstellt
Windows NT einige spezielle, interne Gruppen, die vom Benutzermanager
nicht angezeigt werden. Sie werden jedoch in manchen Fllen in der Grup-
penliste angezeigt, beispielsweise beim Zuweisen von Berechtigungen zu
Verzeichnissen, Dateien, freigegebenen Netzverzeichnissen oder Druckern.
- Jeder - Jeder, der am Computer arbeitet. Dazu zhlen alle lokalen und
Fernbenutzer (d. h. die Gruppen "INTERAKTIV" und "NETZWERK"
zusammengenommen). Sie knnen auf das Netz zugreifen, sich mit den
freigegebenen Netzverzeichnissen der Arbeitsstation verbinden und den
Drucker der Arbeitsstation verwenden.
- INTERAKTIV - Jeder, der am Computer lokal arbeitet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- NETZWERK - Alle Benutzer, die ber das Netz mit diesem Computer ver-
bunden sind.
- SYSTEM - Das Betriebssystem.
- ERSTELLER-BESITZER - Der Benutzer, der folgendes erstellt hat oder
besitzt: ein Verzeichnis, eine Datei in einem Verzeichnis, einen Drucker
oder ein Dokument, das zu einem Drucker gesendet wurde.
Frei definierte Benutzergruppen:
Mit Hilfe von frei definierten Benutzergruppen ist es mglich, die Organisati-
onsstruktur einer Institution auf die Rechtestruktur abzubilden. So kann fr
jede Organisationseinheit, also z. B. fr jedes Referat bzw. fr jede Abteilung,
eine Gruppe gebildet werden, in der die Benutzer der jeweiligen Organisati-
onseinheit zusammengefasst sind. Den Gruppen werden dann die notwendigen
Berechtigungen auf Ressourcen zugewiesen. Werden innerhalb der Institution
fr vorbergehende Aufgaben Projektgruppen gebildet, so knnen auch diese
durch Zusammenfassung der Projektgruppenmitglieder in einer entsprechen-
den frei definierten Gruppe abgebildet werden.
Bei der Erstellung von frei definierten Benutzergruppen auf dem primren
Domnencontroller ist festzulegen, ob diese vom Typ lokal oder global sind.
- Wurde eine Strategie zur Verteilung der Benutzer auf die vordefinierten
Gruppen entsprechend den von diesen Benutzern bentigten Rechten fest-
gelegt?
- Ist diese Strategie dokumentiert?
- Wird regelmig kontrolliert, ob die Zuordnung der Benutzer zu den
Gruppen noch mit den aktuellen Aufgaben dieser Benutzer bereinstimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.51 Benutzerprofile zur Einschrnkung der

Nutzungsmglichkeiten von Windows NT
Benutzerprofile dienen der Speicherung von benutzerspezifischen Einstellun-
gen der Benutzerumgebung. Dies ist u. a. der Inhalt von Programmgruppen,
die Netzwerk- und Druckerverbindungen und die farbliche Darstellung des
Bildschirms. Weiterhin knnen ber Benutzerprofile die Mglichkeiten der
Benutzer, mit Windows NT zu arbeiten, in verschiedener Hinsicht einge-
schrnkt werden. Die Verwaltung der Profile erfolgt mit dem Benutzerprofil-
Editor (UPEDIT.EXE unter Windows NT 3.51 bzw. POLEDIT.EXE unter
Windows NT 4.0).
Benutzerprofile knnen fr verschiedene Einsatzzwecke erstellt werden:
- um bei Single-User-Systemen nach einer erneuten Anmeldung die
ursprnglich festgelegten Einstellungen wiederherzustellen,
- um bei Multi-User-Systemen fr jeden Benutzer eigene Einstellungen
festzulegen,
- damit bei server-gespeicherten Benutzerprofilen jeder Benutzer von jeder
NT-Workstation aus dieselbe Oberflche erhlt,
- um einheitliche Benutzerumgebungen zentral vorzugeben (sowohl bei
Stand-alone-Systemen als auch bei bei vernetzten),
- um eine eingeschrnkte Benutzerumgebung einzurichten, beispielweise um
zu verhindern, dass Benutzer nderungen an Desktop-Einstellungen
vornehmen, oder den Zugriff auf die Systemsteuerung einzuschrnken.
Grundstzlich muss zwischen lokalen und server-gespeicherten Benutzerpro-
filen unterschieden werden. Lokale Benutzerprofile werden nur auf dem loka-
lem IT-System abgelegt, whrend server-gespeicherte Benutzerprofile zentral
auf dem NT-Server verwaltet werden.
Fllt bei Verwendung von server-gespeicherten Benutzerprofilen der Server
aus, dann wird auf die lokale Kopie zurckgegriffen.
Daneben muss zwischen persnlichen und verbindlichen Benutzerprofilen
unterschieden werden. Persnliche Benutzerprofile sind vom Benutzer belie-
big nderbar, verbindliche werden vom Administrator vorgegeben.
Verbindliche Profile bleiben von einer Sitzung zur nchsten erhalten, whrend
einer Sitzung durchgefhrte Vernderungen gehen beim Abmelden verloren.
Diese Profile werden in dem Verzeichnis abgelegt, der im Profileintrag des
betreffenden Kontos angegeben ist, und sie tragen unter der Version 3.51 von
Windows NT die Dateinamenserweiterung .MAN. Ab Version 4.0 wird ein
Profil dadurch als verbindliches Profil gekennzeichnet, dass die Datei
NTUSER.DAT in NTUSER.MAN umbenannt wird.
Persnliche Profile, die auf einem Server abgelegt werden, knnen verwendet
werden, um Benutzern unabhngig von der Arbeitsstation, von der aus sie
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sich anmelden, dieselbe Umgebung zur Verfgung zu stellen. Persnliche

Profile werden in dem Verzeichnis abgelegt, der im Profileintrag des betref-
fenden Kontos angegeben ist, und sie tragen unter Version 3.51 die Datei-
namenserweiterung .USR.
Unter Version 3.51 werden die Benutzerprofile im Verzeichnis
%SystemRoot%\system32\config in den Benutzern zugeordneten Dateien
abgelegt. Dabei werden die folgenden Einstellungen im Benutzerprofil abge-
legt:
- Programm Manager: alle vom Benutzer einstellbaren Optionen ein-
schlielich Programmgruppen, Programme und ihre Eigenschaften, sowie
alle abspeicherbaren Einstellungen
- Dateimanager: alle vom Benutzer whlbaren Einstellungen einschlielich
der Netz-Verbindungen
- Kommandomodus: alle vom Benutzer whlbaren Einstellungen
- Druck Manager: netzweite Druckerverbindungen sowie alle abspeicher-
baren Einstellungen
- Systemsteuerung: alle Einstellungen fr Farben, Maus, Desktop, Zeiger,
Tastatur, Lndereinstellungen und Klnge sowie die Eintrge zur
Benutzerumgebung im Element "System"
- Zubehr: alle benutzerspezifischen Einstellungen der Anwendungen
- Fremdanwendungen: alle Einstellungen, die von diesen Anwendungen als
benutzerspezifische Optionen untersttzt werden
- Anmerkungen bei der online Hilfe: alle dort eingetragenen Anmerkungen
des betreffenden Benutzers
Ab Version 4.0 werden Benutzerprofile als Verzeichnisbaum unter dem
Unterverzeichnis Profiles des Windows-Verzeichnisses %SystemRoot%, also
im allgemeinen \WINNT\Profiles, als Verzeichnis mit dem Namen des Be-
nutzers, z. B. \WINNT\Profiles\Schmidt, abgelegt. Dabei wird die gesamte
Struktur der Arbeitsoberflche und insbesondere die Struktur der einzelnen
Programmgruppen dort abgelegt. Die folgenden Unterverzeichnisse knnen
dabei vorhanden sein:
- Anwendungsdaten: Anwendungsspezifische Daten
- Desktop: Elemente der Arbeitsoberflche einschlielich der direkt auf der
Arbeitsoberflche abgelegten Dateien und Shortcuts
- Druckumgebung: Shortcuts zu den Eintrgen in den Druckerordnern
- Favoriten: Shortcuts zu Programmeintrgen und Ordnern mit Favoriten
- Netzwerkumgebung: Shortcuts zu den Eintrgen der Netzumgebung
- Persnlich: Shortcuts zu den Eintrgen in den privaten Programmgruppen
- Recent: Shortcuts zu den zuletzt verwendeten Dokumenten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- SendTo: Shortcuts zu den Eintrgen, die im Kontextmen als Ziele von

Sende-Operationen, wie etwa zu einem Diskettenlaufwerk, verwendet
werden knnen
- Startmen: Struktur des gesamten Startmens einschlielich aller Shortcuts
zu Programmen und Programmgruppen
- Vorlagen: Shortcuts zu Dokumentenvorlagen
Sonstige Einstellungen, wie etwa der Verweis auf das als Hintergrund der
Arbeitsoberflche verwendete Bild oder andere benutzerspezifische Einstel-
lungen der Systemsteuerung, werden im Ordner Profiles in der Datei
NTUSER.DAT abgelegt.
Die folgenden Optionen knnen unter Version 3.51 verwendet werden, um die
Mglichkeiten der Benutzer mit Windows NT zu arbeiten in verschiedener
Hinsicht einzuschrnken:
- Einstellungen fr Programm Manager: Hier kann festgelegt werden, ob
Programme ber "Datei - Ausfhren" gestartet werden drfen, die aktuel-
len Einstellungen gespeichert werden drfen und ob allgemeine Pro-
grammgruppen angezeigt werden. Auerdem kann die Autostartgruppe
festgelegt werden.
- Einstellungen fr Programmgruppen: Hier kann der Zugriff auf bestimmte
Programmgruppen gesperrt werden und fr ungesperrte Programmgruppen
verschiedene nderungsbefugnisse vergeben werden.
- Den Benutzern kann das Verbinden bzw. Trennen von Netzdruckern ber
den Druckmanager erlaubt oder verboten werden.
- Es kann erzwungen werden, dass die Ausfhrung des Anmeldeskriptes
abgewartet wird, bevor der Programm-Manager gestartet wird. Diese
Option sollte immer aktiviert sein, damit die im Anmeldeskript vorge-
sehenen Aktionen auf jeden Fall durchgefhrt werden.
Ab der Version 4.0 knnen die folgenden Einschrnkungen mit Hilfe des
Systemrichtlinien-Editors festgelegt werden:
- Systemsteuerung: Hier kann der Zugriff auf die Systemsteuerungsoption
"Anzeige" beschrnkt werden. Wenn diese Option gewhlt wurde, knnen
noch zustzlich die Registerkarten "Hintergrund", "Bildschirmschoner",
"Darstellung" und "Einstellungen" einzeln ausgeblendet werden, und die
Option "Anzeige" kann auch als Ganzes deaktiviert werden.
Normalen Benutzern sollte der Zugriff auf die Systemsteuerung entzogen
werden, da unbeabsichtigte nderungen an den Systemeinstellungen Pro-
bleme verursachen knnen. Wenn zustzlich der Zugriff auf die System-
steuerungsoption "Anzeige" bzw. die Registerkarte "Bildschirmschoner"
entzogen wird, kann verhindert werden, dass Benutzer die Bildschirm-
sperre deaktivieren. Dann muss der Administrator natrlich beim Einrich-
ten von Benutzern die Bildschirmsperre aktivieren.
- Shell: Hier knnen folgende Einschrnkungen festgelegt werden:
- Befehl "Ausfhren" entfernen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ordner unter Einstellungen im Men "Start" entfernen

- "Task-Leiste" unter Einstellungen im Men "Start" entfernen
- Befehl "Suchen" entfernen
- Laufwerke im Fenster "Arbeitsplatz" ausblenden
- Netzwerkumgebung ausblenden
- Kein Symbol "Gesamtes Netzwerk" in der Netzwerkumgebung
- Keine Arbeitsgruppen-Computer in Netzwerkumgebung
- Alle Desktop-Elemente ausblenden
- Befehl "Beenden" deaktivieren
- Keine Einstellungen beim Beenden speichern
- System: Hier knnen folgende Einschrnkungen festgelegt werden:
- Programme zum Bearbeiten der Registrierung deaktivieren
- Nur zugelassene Anwendungen fr Windows ausfhren
Fr normale Benutzer sollte kein Zugriff auf die Registrierung mglich
sein, da nderungen an der Registrierung schwerwiegende Probleme ver-
ursachen knnen.
Die meisten Benutzer mssen mit dem IT-System nur bestimmte Aufgabe
wahrnehmen und bentigen dem entsprechend nur bestimmte Anwendun-
gen. Daher sollte ihr Zugriff auch auf diese Anwendungen, wie z. B. ein
Textverarbeitungsprogramm, eingeschrnkt werden.
- Windows NT Shell: Hier knnen folgende Einschrnkungen festgelegt
werden:
- Nur erlaubte Shell-Erweiterungen verwenden
- Allgemeine Programmgruppen vom Men "Start" entfernen
Unter Windows NT knnen sehr differenzierte Benutzerprofile erstellt
werden. Diese sollten entsprechend der Sicherheitspolitik der Behrde bzw.
des Unternehmens erarbeitet werden. Dies kann zeitaufwendig sein, da fr
verschiedene Benutzergruppen auch jeweils auf diese zurechtgeschnittene
Benutzerprofile erstellt werden sollten. Alle Benutzerprofile mssen vorher
darauf getestet werden, ob diese weder Lcken offen lassen noch die Benutzer
an ihrer Aufgabenerfllung hindern. Es ist auch zu bedenken, dass zu weitge-
hende Einschrnkungen nicht nur zur Unzufriedenheit der Benutzer bis hin zur
vlligen Ablehnung des Systems fhren knnen, sondern auch den
Administratoren viel Arbeit verursachen knnen, wenn diese stndig Be-
nutzerwnsche umsetzen mssen, wie z. B. eine andere Schriftgre einstel-
len.
Die Windows NT Umgebung wird durch die Werte des aktuellen Benutzer-
profils festgelegt, selbst wenn der aktuelle Benutzer weder ber ein vorge-
schriebenes noch ber ein persnliches Profil verfgt oder auch wenn aktuell
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
niemand angemeldet ist. Das User Default Profil wird unter den folgenden
Bedingungen geladen:
- wenn der aktuelle Benutzer ber kein eigenes (vorgeschriebenes oder per-
snliches) Profil verfgt und sich noch nie auf dem aktuellen Rechner
angemeldet hat;
- wenn ein Benutzer sich auf dem Gastkonto anmeldet.
Im ersten Fall werden die aktuellen Werte der Benutzerumgebung beim
Abmelden in ein neu erstelltes lokales persnliches Profil abgespeichert, im
zweiten Fall gehen sie beim Abmelden verloren.
Wenn niemand angemeldet ist, werden die aktuellen Werte fr den Bild-
schirmhintergrund und andere Umgebungsvariablen durch das System Default
Profil bestimmt.
- Ist das Gastkonto, sofern es nicht gesperrt ist, durch ein Profil auf die
minimal erforderliche Funktionalitt eingeschrnkt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.52 Gerteschutz unter Windows NT/2000

Normalerweise erlaubt Windows NT/2000 allen Programmen den Zugriff auf
Disketten und CD-ROMs. Es ist empfehlenswert, diesen Zugriff auf den
gerade interaktiv eingeloggten Benutzer zu beschrnken, indem die Gerte
diesem Benutzer beim Anmelden exklusiv zugeordnet werden.
Der Zugriff auf Diskettenlaufwerke sollte unter Windows NT 4.0 einge-
schrnkt werden, indem der Wert AllocateFloppies im Schlssel SOFTWARE
\ Microsoft \ Windows NT \ Current Version \ Winlogon des Bereiches
HKEY_LOCAL_MACHINE der Registrierung auf den Wert
REG_Zeichenfolge = 1 gesetzt wird. Hinweis: Der Typ REG_Zeichenfolge,
wie er in dem Programm Regedit.exe verwandt wird, entspricht dem Typ
REG_SZ im Programm Regedt32.exe.
Analog sollte der Zugriff auf CD-ROM-Laufwerke bei Bedarf eingeschrnkt
werden, indem der Wert AllocateCdRoms im Schlssel SOFTWARE \ Micro-
soft \ Windows NT \ Current Version \ Winlogon des Bereiches HKEY_LO-
CAL_MACHINE der Registrierung auf den Wert REG_Zeichenfolge = 1
gesetzt wird.
Unter Windows 2000 erfolgt die Konfiguration ber die lokalen Sicherheits-
einstellungen bzw. ber eine Gruppenrichtlinie. Die relevanten Parameter sind
unter Computerkonfiguration / Windows-Einstellungen / Sicherheitsein-
stellungen / Lokale Richtlinien / Sicherheitsoptionen zu finden und lauten:
- Zugriff auf CD-ROM-Laufwerke auf lokal angemeldete Benutzer
beschrnken
- Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschrn-
ken
Beide Optionen sind zu aktivieren.
Hinweis: Da die Gerte beim Abmelden wieder fr den allgemeinen Zugriff
freigegeben werden, mssen die Datentrger vor dem Abmelden aus den
Gerten entfernt werden.
Sofern Diskettenlaufwerke vollstndig abgeschaltet werden sollen, kann dies
auch dadurch geschehen, dass in der Systemsteuerungsoption Gerte unter
Windows NT bzw. Computerverwaltung/Gertemanager unter Windows
2000 das Laden des Treiberprogramms dadurch unterbunden wird, dass dem
Gert Floppy die Startart Deaktiviert zugewiesen wird. Nach dem nchsten
Systemstart steht dann das Diskettenlaufwerk berhaupt nicht mehr zur
Verfgung, und es kann nur von einem Administrator durch Zuweisen der
Startart System wieder nutzbar gemacht werden.
Auf Servern sollte das Laden des Treiberprogramms fr das Disketten-
laufwerk nicht unterbunden werden. Sofern das Diskettenlaufwerk doch
einmal gebraucht wird, z. B. zum Zwecke der Administration, muss dem
Gert Floppy die Startart System zugewiesen werden und der Server muss
heruntergefahren werden, da der Treiber erst beim Neustart wieder geladen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wird. Dies kann zu Strungen des Betriebes fhren. Server mssen in einer
gesicherten Umgebung aufgestellt werden.
Weiterhin erlaubt Windows NT/2000 allen Benutzern den Zugriff auf Band-
laufwerke, so dass jeder Benutzer den Inhalt jedes Bandes lesen und schreiben
kann. Normalerweise bringt dies keine Probleme mit sich, da zu einem gege-
benen Zeitpunkt jeweils nur ein Benutzer interaktiv angemeldet ist. Sofern
dieser jedoch ein Programm laufen lsst, das auch nach dem Ausloggen noch
auf das Bandlaufwerk zugreift, so kann dieses Programm mglicherweise auf
ein Band zugreifen, das der nchste Benutzer auflegt, der sich anmeldet. Aus
diesem Grund sollten Rechner, die sich nicht in einer kontrollierten Umge-
bung befinden und auf denen vertrauliche Daten verarbeitet werden, neu
gestartet werden, ehe das Bandlaufwerk genutzt wird.
Hinweis: Der Einsatz von selbstladenden Bandgerten, die mehrere Bnder
aus einem Reservoir laden knnen, darf nur unter sehr genau kontrollierten
Randbedingungen zugelassen werden. In der Regel sollten derartige Gerte
nur zur Datensicherung an einem Server installiert werden. Der interaktive
Zugriff normaler Benutzer auf diesen Server ist nicht zulssig (siehe auch
M 6.32 Regelmige Datensicherung).
Weitere Empfehlungen zum geeigneten Umgang mit Laufwerken fr Wech-
selmedien finden sich in der Manahme M 4.4.
- Wird die Einstellung der Schlssel AllocateFloppies und AllocateCdRoms
in der Registrierung regelmig kontrolliert?
- Wird die Einstellung der Parameter Zugriff auf CD-ROM-Laufwerke auf
lokal angemeldete Benutzer beschrnken und Zugriff auf Diskettenlauf-
werke auf lokal angemeldete Benutzer beschrnken in den Sicherheits-
einstellungen bzw. Gruppenrichtlinien regelmig kontrolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Dateien und Verzeichnisse unter Windows NT
In Windows NT wird zwischen den Zugriffsberechtigungen auf Freigabeebene
und den Zugriffsberechtigungen auf Datei- und Verzeichnisebene, die im
folgenden auch NTFS-Berechtigungen genannt werden, unterschieden. Die
Zugriffsberechtigungen auf Freigabeebene (Shares) werden in M 2.94
Freigabe von Verzeichnissen unter Windows NT betrachtet.
Zugriffsberechtigungen auf Datei- und Verzeichnisebene stehen im Gegensatz
zu den Freigabeberechtigungen (Share-Berechtigungen) nur auf Datentrgern
mit dem Dateisystem NTFS zur Verfgung. Sie werden in der Regel vom
Ersteller oder Besitzer eines Objektes (Verzeichnis oder Datei) vergeben. Auf
Servern erfolgt dies meistens durch den Administrator. Die Festlegung von
NTFS-Berechtigungen erfolgt unter Windows NT 4.0 typischerweise mittels
des Windows NT Explorers oder ber das Desktop-Symbol "Arbeitsplatz". Im
Kontextmen des entsprechenden Verzeichnisses bzw. der entsprechenden
Datei ist der Menpunkt "Eigenschaften"/"Sicherheit" auszuwhlen. Dadurch
gelangt man zu folgender Zugriffskontrolliste:
Abb.: Verzeichnisberechtigungen - Zugriffskontrolliste

Die entsprechende Zugriffskontrolliste findet sich unter Windows NT 3.51 im
Dateimanager unter "Sicherheit"/"Berechtigungen". In diese Zugriffskon-
trolliste knnen bestehende Benutzergruppen und Benutzer aufgenommen und
hier knnen jeder Benutzergruppe und jedem Benutzer Berechtigungen
zugewiesen und entzogen werden. Auch ist es mglich, Benutzergruppen und
Benutzer aus der Zugriffskontrolliste zu entfernen. Durch Aktivieren der
Option "Berechtigungen fr existierende Dateien ersetzen" knnen die fr das
Verzeichnis festgesetzten Berechtigungen auf alle Dateien dieses Verzeich-
nisses bertragen werden. Wird die Option "Berechtigungen fr Unterver-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zeichnisse ersetzen" gewhlt, werden die eingestellten Berechtigungen zudem

auf alle Unterverzeichnisse bertragen. Auf diese Weise lassen sich leicht
einheitliche Rechtestrukturen realisieren.
NTFS-Berechtigungen werden zunchst beim lokalen Zugriff wirksam.
Mssen z. B. mehrere Benutzer an einem Computer arbeiten, so ist es mg-
lich, durch Vergabe entsprechender Datei- und Verzeichnisberechtigungen
sicherzustellen, dass jeder Benutzer nur Zugriff auf seine Daten hat.
Auch beim Zugriff ber das Netz werden NTFS-Berechtigungen wirksam.
Voraussetzung fr den Netzzugriff ist aber, dass das Verzeichnis, auf das
zugegriffen werden soll oder in dem sich das gewnschte Unterverzeichnis
oder die gewnschte Datei befindet, zuvor freigegeben und mit einer ent-
sprechenden Freigabeberechtigung versehen wurde (s. M 2.94 Freigabe von
Verzeichnissen unter Windows NT). Im Zusammenspiel zwischen Freigabe-
berechtigung und NTFS-Berechtigung ist zu beachten, dass die jeweils
restriktivere Berechtigung magebend ist. NTFS-Berechtigungen lassen sich
feiner abstufen als Freigabeberechtigungen. Es ist insbesondere mglich, fr
jedes Unterverzeichnis und fr jede Datei gesonderte NTFS-Berechtigungen
zu vergeben. Von daher ist es auch mglich, Freigaben mit der Freigabe-
berechtigung "Vollzugriff" fr die Gruppe der Benutzer bzw. Domnen-
Benutzer zu versehen und die effektiven Zugriffsrechte ber die NTFS-
Berechtigungen zu vergeben.
Die NTFS-Berechtigungen werden unterschieden in spezifische (auch indivi-
duelle) Berechtigungen und vordefinierte Standardberechtigungen, die Kom-
binationen der spezifischen Zugriffsberechtigungen darstellen.
Es gibt folgende individuellen Berechtigungen:
R Lesen
W Schreiben
X Ausfhren
D Lschen
P Berechtigungen ndern
O Besitz bernehmen
Aus diesen Einzelberechtigungen sind unter Windows NT vorgegebene Stan-
dardberechtigungen kombiniert worden:
Standardberechtigung Einzelberechtigungen
Kein Zugriff -
Lesen RX
ndern RWXD
Anzeigen RX
Hinzufgen WX
Hinzufgen und Lesen RWX
Vollzugriff RWXDPO
Tabelle: Vorgegebene Standardberechtigungen unter Windows NT
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Der Besitzer einer Datei bzw. eines Verzeichnisses hat in jedem Fall das
Recht, Berechtigungen fr die Datei bzw. das Verzeichnis zu vergeben und zu
entziehen. Jeder, der ein Verzeichnis oder eine Datei erstellt, wird automatisch
Besitzer dieser Ressource. Der Besitz an einem Verzeichnis bzw. an einer
Datei kann durch "Besitz bernehmen" (P) an andere Benutzer bertragen
werden. Der Besitz an einem Verzeichnis oder einer Datei geht allerdings erst
durch die Besitzbernahme durch den Empfnger auf diesen ber. Es ist im
Gegensatz zu anderen Betriebssystemen nicht mglich, Dateien und Ver-
zeichnisse zu verschenken. Unabhngig von den Eintragungen in der
Zugriffskontrolliste knnen Administratoren in jedem Fall den Besitz an
Dateien und Verzeichnissen bernehmen.
Hinweis:
Benutzer sollten mglichst nie die Berechtigung "Vollzugriff" vergeben,
sondern hchstens die Berechtigung "ndern", damit ihnen nicht der Besitz
entzogen werden kann und sie immer die Hoheit ber die Rechtevergabe
behalten.
Alle Benutzer mssen darauf aufmerksam gemacht werden, regelmig mit
dem Dateimanager oder dem Explorer zu berprfen, ob sie noch Besitzer
ihrer Verzeichnisse und Dateien sind. Dies ist der einzige Weg, mit dem
Benutzer erkennen knne, ob von Ihnen gesetzte Zugriffsrechte umgangen
worden sind.
Die in den folgenden Abschnitten genannten Manahmen gelten hauptschlich
fr Dateien und Verzeichnisse, fr die der Administrator zustndig ist, das
heit fr solche, die entweder fr alle Benutzer von Bedeutung sind oder die
Administrationszwecken dienen. Es reicht nicht aus, die Rechte eines
Programms zu berprfen, es muss auch die Rechtevergabe aller Programme
berprft werden, die von diesem Programm aus aufgerufen werden
(insbesondere zur Vermeidung Trojanischer Pferde).
Die Attribute aller Systemdateien sollten mglichst so gesetzt sein, dass nur
der Systemadministrator Zugriff darauf hat. Verzeichnisse drfen nur die
notwendigen Privilegien fr die Benutzer zur Verfgung stellen.
Verzeichnisse des Betriebssystems und der Anwendungsprogramme
Die Dateien und Verzeichnisse des Betriebssystems selbst mssen gegen
unzulssige Zugriffe hinreichend geschtzt werden. Die standardmig
vorgesehenen Zugriffsrechte sollten unmittelbar nach der Installation des
Systems auf schrfere Formen der Zugriffskontrolle auf die betreffenden
Dateien und Verzeichnisse (das Windows-Verzeichnis, %SystemRoot%, z. B.
\WINNT, das Windows-Systemverzeichnis %SystemRoot%\SYSTEM32 und
eventuelle weitere Programmverzeichnisse, z. B. \MsOffice und \Programme,
und alle Unterverzeichnisse) eingestellt werden.
Dabei ist jedoch zu beachten, dass manche Programme, insbesondere 16-Bit
Programme, aber auch z. B. MS Winword 7.0, im Windows-Verzeichnis
und/oder im Programmverzeichnis Initialisierungs- und Konfigurationsdateien
anlegen. Sollen solche Programme genutzt werden, so kann es erforderlich
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden, den Benutzern das Zugriffsrecht "ndern" auf die betreffenden

Verzeichnisse und Dateien zu geben.
Nur Administratoren drfen auf diese Dateien und Verzeichnisse schreibenden
Zugriff haben. Fr alle anderen Benutzer ist der Zugriff so einzuschrnken,
dass sie dort nur lesenden und ausfhrenden Zugriff (RX) haben:
Benutzer(gruppe) Zugriffsrecht
SYSTEM Vollzugriff
Administratoren Vollzugriff
Benutzer Lesen
Tabelle: Zugriffsrechte auf das Betriebssystem und die Anwenderprogramme
Ggf. kann der Zugriff auf ausfhrbare Dateien (.EXE-, COM- und BAT-
Dateien) noch weiter eingeschrnkt werden, so dass nur ausfhrender Zugriff
(X) auf diese Dateien mglich ist. In hnlicher Weise sind die fr den
Systemstart kritischen Dateien \BOOT.INI, \NTDETECT.COM, \NTLDR,
\AUTOEXEC.BAT und \CONFIG.SYS gegen unbefugte Vernderung durch
unprivilegierte Benutzer zu schtzen.
Dabei sollte allerdings - am besten in einer Testumgebung - berprft werden,
ob alle Anwendungsprogramme bei dieser restriktiven Einstellung noch lauf-
fhig sind, oder ob einzelne Zugriffskontrollen doch um weitere Zugriffs-
mglichkeiten ergnzt werden mssen, um beispielsweise die Abspeicherung
temporrer Dateien oder von Konfigurationsinformationen in einem
Programmverzeichnis zu erlauben. Generell sollte jedoch der Zugriff auf die
Programmdateien selbst (.EXE-Dateien) und auf dynamische Bibliotheken
(.DLL-Dateien) fr die Gruppe "Jeder" auf lesenden Zugriff beschrnkt
werden, zumal diese Manahme auch einen gewissen Schutz gegen die
Verbreitung von Viren bietet.
Temporre Dateien
Temporre Dateien, die von verschiedenen Anwendungsprogramme zum
Auslagern und Zwischenspeichern von Daten verwendet werden, werden unter
Windows NT im Verzeichnis %TEMP% (in der Regel C:\TEMP) abgelegt.
Alle Anwender bentigen fr dieses Verzeichnis auch das Recht, hier Dateien
abzulegen, doch muss gleichzeitig verhindert werden, dass Benutzer auf
temporre Dateien anderer Benutzer Zugriff erhalten. Die Zugriffsrechte fr
das Verzeichnis sollten daher auf folgenden Wert gendert werden
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SYSTEM Vollzugriff
Ersteller/Besitzer ndern
Benutzer Hinzufgen
Tabelle: Zugriffsrechte bei temporren Dateien
Registrierung
Die Registrierung von Windows NT befindet sich im Unterverzeichnis
CONFIG des Windows-Systemverzeichnisses %SystemRoot%\SYSTEM32,
d. h. im allgemeinen im Verzeichnis C:\WINNT\SYSTEM32\CONFIG. Auf
dieses Verzeichnis muss der Anwender Zugriff haben, da die Registrierung
automatisch durch Einstellungen des Benutzers in Anwendungsprogrammen
gendert wird. Kann der Benutzer nicht auf dieses Verzeichnis zugreifen, fhrt
das zu Systemfehlern oder zu einem Absturz des Systems. Die auf dieses
Verzeichnis gesetzten Standardrechte, die mglichst nicht verndert werden
sollten, sind unter Version 3.51:
SYSTEM Vollzugriff
Ersteller/Besitzer ndern
Benutzer Anzeigen
Tabelle: Zugriffsrechte bei der Registrierung bei Windows NT, Version 3.51
Ab Version 4.0 sind die Standardrechte:
SYSTEM Vollzugriff
Ersteller/Besitzer Vollzugriff
Jeder Anzeigen
Tabelle: Zugriffsrechte bei der Registrierung ab Version 4.0
Die Gruppe "Jeder" sollte allerdings durch die Gruppe "Benutzer" ersetzt
werden. Nur wenn Gste auf dieses Verzeichnis Zugriff haben, muss die
Gruppe "Jeder" das Recht "Anzeigen" haben.
Bei der Installation legt Windows NT das Verzeichnis
%SystemRoot%\REPAIR an, um dort Konfigurationsinformationen abzu-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
speichern, die fr eine ggf. notwendige Reparatur einer bestehenden Installa-

tion bentigt werden. Diese Dateien werden mit Hilfe des Dienstprogramms
RDISK aktualisiert (siehe auch M 6.42 Erstellung von Rettungsdisketten fr
Windows NT). Da da mit Hilfe dieser Dateien und entsprechender Schadsoft-
ware Sicherheitsfunktionalitten von Windows NT auer Kraft gesetz werden
knnen, sollten die Rechte auf das Verzeichnis mit allen darin befindlichen
Dateien wie folgt gesetzt werden:
System Vollzugriff
Tabelle: Zugriffsrechte auf Verzeichnisse
Profile
Zum Abspeichern der Daten, die die Benutzeroberflche und Eintrge im
Men START ab der Version 4.0 beschreiben, legt Windows NT fr jeden
Benutzer vom System ein eigenes Profilverzeichnis im Unterverzeichnis
Profiles des Windows-Verzeichnisses %SystemRoot% (in der Regel
C:\WINNT\PROFILE) an. Unter der Version 3.51 werden Profile in Unterver-
zeichnissen des Systemverzeichnisses %SystemRoot%\SYSTEM32\CONFIG
bzw. in fr die einzelnen Benutzer explizit angegebenen Verzeichnissen
abgespeichert.
Auf diese Verzeichnisse muss der Benutzer vollen Zugriff haben, sofern er
seine Benutzeroberflche selbst verndern knnen soll. Dies ist jedoch nicht
immer gewnscht (vgl. M 4.51 Benutzerprofile zur Einschrnkung der
Nutzungsmglichkeiten von Windows NT). Beim ersten Anmelden des Be-
nutzers wird sein Benutzerprofil automatisch vom System erzeugt. Die Stan-
dard-Zugriffsrechte fr das Verzeichnis sehen wie folgt aus:
SYSTEM Vollzugriff
betreffender Benutzer Vollzugriff
Tabelle: Zugriffsrechte bei Profilverzeichnissen
Neben dem Profilverzeichnis fr den einzelnen Benutzer gibt es noch ein
Verzeichnis fr alle Benutzer (All Users) und ein Verzeichnis als Vorlage fr
neue Benutzer (Default User). Schreibenden Zugriff auf diese Verzeichnisse
sollte nur Systemverwalter haben. Die Zugriffsrechte sollten wie folgt gesetzt
werden:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SYSTEM Vollzugriff
Benutzer Lesen
Tabelle: Zugriffsrechte in den Verzeichnissen All Users und Default User
Diese Einstellungen sollten nur verndert werden, wenn man dem Anwender
das Recht nehmen mchte, seine Benutzeroberflche zu verndern.
Benutzer-Verzeichnisse
Die Verzeichnisse fr die Daten der einzelnen Benutzer sollten in der Regel so
geschtzt werden, dass nur die betreffenden Benutzer auf ihre Dateien
zugreifen knnen. Andere Benutzer, auch Administratoren bentigen in der
Regel keinen Zugriff auf die Daten eines Benutzers, es sei denn, dass dieser
selbst explizit zustzliche Zugriffsrechte vergibt. Damit ist in den meisten
Fllen die folgende Voreinstellung fr die Zugriffsrechte auf Benutzerver-
zeichnisse ausreichend:
SYSTEM Vollzugriff
betreffender Benutzer Vollzugriff
Tabelle: Benutzer-Verzeichniss-Zugriffsrechte
Benutzer, die einzelne Dateien oder Verzeichnisse anderen Benutzern
zugnglich machen wollen, sollten hierfr Verzeichnisse auerhalb ihres
Basis-Verzeichnisses einrichten. Ebenso sollten fr Projektgruppen, die
gemeinsam an bestimmten Dateien arbeiten, spezielle Verzeichnisse einge-
richtet werden. Die Zugriffsrechte auf solche Verzeichnisse sollten auch
wiederum explizit auf die Benutzer in diesen Gruppen beschrnkt werden.
Sperren der Zugriffsrechte fr Gste
Bei den oben beschriebenen Zugriffskontrolllisten ist davon ausgegangen
worden, dass keine Benutzer der Gruppe "Gste" zugelassen sind. Deswegen
ist die Gruppe "Jeder" durch die Gruppe "Benutzer" zu ersetzen. Mit dieser
Ma?nahme wird Gsten effektiv jede Mglichkeit zur Arbeit mit dem System
und zum Zugriff auf Daten entzogen. Da dies jedoch unter Umstnden dazu
fhren kann, dass bestimmte Anwendungssoftware nicht mehr korrekt luft,
sollte eine derartige nderung zuerst an einem Testsystem vorgenommen und
hinsichtlich ihrer Auswirkungen berprft werden, ehe sie allgemein umge-
setzt wird.
- Wird die Attributvergabe bei Systemdateien und der Registrierung regel-
mig berprft?
- Werden die Einstellungen der Benutzerprofile regelmig berprft?
- Gibt es Listen, anhand derer diese berprfungen durchgefhrt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.54 Protokollierung unter Windows NT

Die fr die Protokollierung sicherheitsrelevanter Ereignisse festgelegten
Regelungen knnen mit Hilfe der Option "Richtlinien" des Benutzer-
Managers umgesetzt werden, wobei fr den mittleren Schutzbedarf geeignete
Regelungen im allgemeinen denen der folgenden Abbildung entsprechen:
Abb.: berwachungsrichtlinien
Sofern auf einem Rechner Daten mit hheren Schutzanforderungen gespei-
chert und/oder verarbeitet werden, sollten zustzlich noch erfolgreiche und
abgewiesene Datei- und Objektzugriffe aufgezeichnet werden. Dabei sollte
sich diese Aufzeichnung auf die Dateien, die besonders schutzwrdige Infor-
mationen enthalten, sowie auf die zur Verarbeitung dieser Dateien bentigten
Programme beschrnken, damit die Protokolldatei nicht so umfangreich wird,
dass sie nicht mehr mit tragbarem Aufwand auswertbar ist.
Bei hheren Sicherheitsanforderungen sollten auch Zugriffe und Zugriffs-
versuche auf die Registrierung, zumindest fr die Schlssel
HKEY_LOCAL_MACHINE und HKEY_USERS, aufgezeichnet werden. Dabei
empfiehlt es sich, alle abgewiesenen Versuche aufzuzeichnen und von den
erfolgreichen zumindest die folgenden, die zu Vernderungen der Registrie-
rung fhren knnen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abb.: Registrierungsschlsselberwachung
Dabei ist zu beachten, dass Zugriffe auf die Registrierung nur dann aufge-
zeichnet werden, wenn bei den allgemeinen berwachungsrichtlinien die
berwachung der Datei- und Objektzugriffe aktiviert ist.
Bei der berwachung der Zugriffe auf die Registrierung fallen erhebliche
Mengen an Protokolldaten an, die auch ausgewertet werden mssen. Zudem
wirkt sich die Protokollierung dieser Ereignisse u. U. negativ auf die System-
performance aus. Es bietet sich unter Bercksichtigung der Sicherheits-
anforderungen ggf. das folgende alternative Vorgehen an: Abgewiesene
Zugriffsversuche auf die Schlssel HKEY_LOCAL_MACHINE und
HKEY_USERS werden so protokolliert, wie zuvor beschrieben. Die erfolg-
reichen Zugriffe auf diese Schlssel werden nicht protokolliert. Vielmehr wird
ein geeignetes Integrittssicherungsprogramm eingesetzt. So knnen
Vernderungen an diesen Schlsseln leicht erkannt werden. Der Nachteil
dieser Methode ist aber, dass der Urheber von Vernderungen nicht erkannt
werden kann.
Die Protokolldatei sollte durch Festlegung entsprechender Vorgaben mit dem
Dienstprogramm Ereignisanzeige so gro angelegt werden, dass alle innerhalb
eines vorgegebenen Zeitraums (beispielsweise in einer Woche) anfallenden
Eintrge mit Sicherheit abgespeichert werden knnen. Dabei sollte ein
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sicherheitsspielraum vorgesehen werden, so dass in der Regel maximal nur

etwa 30 % der Protokolldatei gefllt werden. Nach Ablauf des vorgesehenen
Zeitraums ist die Protokolldatei jeweils zu analysieren, zu archivieren und
dann zu leeren, um Platz fr neue Eintrge zu schaffen.
Um Systemausflle durch Vollschreiben der Protokolldatei zu vermeiden,
sollte normalerweise eine der Optionen "berschreiben falls notwendig" oder
"berschreiben lter als x Tage", wobei fr x die Lnge des vorgesehenen
Archivierungszyklus, z. B. 30 Tage, angegeben wird, gewhlt werden:
Abb.: Ereignisanzeige - Einstellungen

Fr Systeme, fr die erhhte Sicherheitsanforderungen bestehen, sollte statt
dessen die Option "Nie berschreiben (Protokoll manuell lschen)" gewhlt
werden, was allerdings zum Systemstillstand bei berlauf des Logs fhrt und
dann einen entsprechenden Aufwand verursacht.
Die Auswertung der Protokolle erfolgt mit dem Verwaltungsprogramm
Ereignisanzeige, das durch Auswahl geeigneter Filterregeln die gezielte Aus-
wertung sicherheitskritischer Vorgnge ermglicht:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abb.: Filter
Die Auswertung des Sicherheitsprotokolls sollte einer geeigneten, allgemein
verbindlichen Vorgabe folgen (siehe M 2.64 Kontrolle der Protokolldateien
und M 2.92 Durchfhrung von Sicherheitskontrollen im Windows NT Client-
Server-Netz).
- Werden die aufgezeichneten Protokolle regelmig geprft?
- Werden die mglichen Konsequenzen sicherheitskritischer Protokoll-
eintrge analysiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.55 Sichere Installation von Windows NT

Vor der Installation von Windows NT sollten einige berlegungen getroffen
werden, die im folgenden kurz dargestellt werden.
Sichere Systemversion
Schon bei der Beschaffung muss entschieden werden, ob Windows NT in der
englischen oder in der deutschen Version zum Einsatz kommen soll. Auer-
dem muss Windows NT, um sicher zu sein, wenigstens in der Version 3.51
mit dem jeweils aktuellen Service Pack betrieben werden (siehe auch M 4.76
Sichere Systemversion von Windows NT). Sofern eine ltere Windows NT
Installation vorhanden ist, sollte diese nach Mglichkeit auf die Version 4
oder zumindest auf die Version 3.51 aktualisiert werden.
Partitionen und Dateisysteme
Windows NT untersttzt neben dem eigenen Dateisystem NTFS auch das
DOS-Dateisystem FAT und das OS/2-Dateisystem HPFS. Ein Groteil der
sicherheitsrelevanten Einstellungen ist allerdings nur unter NTFS gltig. Bei
der Installation von Windows NT ist daher zu beachten, dass keine HPFS-
oder DOS-Partitionen angelegt werden, da fr diese kein Zugriffsschutz gilt,
so dass derartige Partitionen zum Unterlaufen des Schutzes von Windows NT
missbraucht werden knnen. Statt dessen mssen alle Partitionen mit dem
NTFS-Dateisystem formatiert oder, sofern frhere Daten beibehalten werden
sollen, zu diesem Dateisystem konvertiert werden.
Allerdings ist die Untersttzung des FAT-Dateisystems fr Disketten not-
wendig, da das NTFS-Dateisystem aufgrund seiner Gre nicht auf Disketten
untergebracht werden kann. Daher sollte der Zugriff auf Diskettenlaufwerke
beschrnkt werden (siehe M 4.52 Gerteschutz unter Windows NT/2000).
Konfiguration des Anmelde-Vorgangs
Normalerweise zeigt Windows NT beim Anmelden den Namen des letzten
Benutzers an, der sich am betreffenden Rechner eingeloggt hat. Diese Anzeige
sollte durch Eintrag/Vernderung des Wertes "DontDisplayLastUserName" im
Schlssel "SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon"
des Bereiches HKEY_LOCAL_MACHINE der Registrierung auf den Wert
REG_SZ = "1" verhindert werden.
Um unberechtigte Benutzer vor einem unzulssigen Zugriff auf das System zu
warnen, sollte vor dem eigentlichen Anmelde-Vorgang ein Fenster mit einem
geeigneten Text angezeigt werden. Dies wird durch Eingabe geeigneter Texte
in die beiden Eintrge "LegalNoticeCaption" und "LegalNoticeText" im
Schlssel "SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon"
des Bereiches HKEY_LOCAL_MACHINE der Registrierung erreicht.
Die betreffenden nderungen knnen mit Hilfe des Registrierungs-Editors
(des Programms REGEDT32.EXE im Windows-Systemverzeichnis
%SystemRoot%\SYSTEM32) vorgenommen werden. Dabei ist besondere
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Vorsicht anzuwenden, da fehlerhafte Einstellungen in der Registrierung dazu

fhren knnen, dass das System nicht mehr lauffhig ist. Ab der Version 4.0
von Windows NT knnen diese Werte mit Hilfe des Systemrichtlinien-Editors
zentral fr die einzelnen Arbeitsstationen vorgegeben werden.
Laden von Subsystemen
Die optionalen Subsysteme POSIX und OS/2 sollten nur dann installiert
bleiben, wenn sie zur Durchfhrung von Anwendungen auch tatschlich
bentigt werden. Sofern dies nicht der Fall ist, sollte auf ihre Installation ver-
zichtet werden, oder die Systeme sollten, falls diese schon erfolgt ist, wieder
gelscht werden. Dazu sind dann die Unterverzeichnisse POSIX bzw. OS2 des
Windows-Systemverzeichnisses %SystemRoot%\SYSTEM32 mit ihren even-
tuellen Unterverzeichnissen zu lschen. Weiterhin sind die folgenden
Programme und ladbaren Bibliotheken im Windows-Verzeichnis
%SystemRoot%\SYSTEM32 zu lschen:
- OS/2: OS2.EXE
OS2SRV.EXE
OS2SS.EXE
- POSIX: PSXDLL.DLL
PAX.EXE
POSIX.EXE
PSXSS.EXE
Auerdem sind folgende Eintrge im Teilschlssel

\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems im
Bereich HKEY_LOCAL_MACHINE der Registrierung zu lschen:
- OS/2: Eintrag "Os2" mit dem Wert %SystemRoot%\system32\os2ss.exe
- POSIX: Eintrag "Posix" mit dem Wert %SystemRoot%\system32\psxss.exe
Starten von Diensten
Sofern Dienste, die keine Standarddienste von Windows NT sind, konfiguriert
werden sollen, sollte bei Festlegung der Startart dieser Dienste (mit der
Systemsteuerungsoption "Dienste") nach Mglichkeit ein eigenes Benutzer-
konto zum Start jedes dieser Dienste vorgesehen werden, um die Befugnisse
des betreffenden Dienstes geeignet einschrnken zu knnen. Das dabei ver-
wendete Benutzerkonto muss ber das Recht "Als Dienst starten" verfgen,
und es sollte auer fr diesen Dienst nicht verwendet werden, also insbe-
sondere auch kein Login von Benutzern zulassen. Dienste, die nicht auf diese
Weise einem speziellen Benutzerkonto zugeordnet wurden, laufen im Kontext
der speziellen Benutzergruppe SYSTEM (siehe M 4.50 Strukturierte System-
verwaltung unter Windows NT), also mit den grtmglichen Zugriffsberech-
tigungen.
Gerteschutz
Sofern der Computer ber Diskettenlaufwerke, CD-ROM-Laufwerke und/oder
Bandlaufwerke verfgt, sollten diese nach Mglichkeit spezifisch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
geschtzt werden, wie in der Manahme M 4.52 Gerteschutz unter

Windows NT beschrieben.
Notfalldiskette
Bei der Installation bietet Windows NT an, eine Notfalldiskette mit den
wichtigsten Konfigurationsinformationen zu erzeugen. Von dieser Mglich-
keit sollte Gebrauch gemacht werden, und die Diskette sollte bei nderungen
am System jeweils aktualisiert werden (siehe M 6.42 Erstellung von
Rettungsdisketten fr Windows NT). Dabei empfiehlt es sich, die Aktuali-
sierung der Notfalldiskette jeweils nach dem nchsten Systemstart vorzu-
nehmen, wenn also sichergestellt ist, dass sich das genderte System noch
starten lsst.
Vordefinierte Benutzerkonten
Das vordefinierte Administratorkonto ist Mitglied der vordefinierten Gruppe
"Administratoren". Es erhlt die Rechte und Berechtigungen, die dieser
Gruppe erteilt wurden. Das Administratorkonto wird von der Person
verwendet, welche die Gesamtkonfiguration der Arbeitsstation oder des
Servers verwaltet. Der Administrator besitzt mehr Kontrollmglichkeiten ber
den Windows NT Computer als jeder andere Benutzer. Daher ist dieses Konto
besonders zu schtzen (siehe M 4.77 Schutz der Administratorkonten unter
Windows NT). Das vordefinierte Gastkonto ist Mitglied der Gruppe "Gste".
Es erhlt die Rechte und Berechtigungen, die dieser Gruppe erteilt wurden.
Beispielsweise kann sich ein Benutzer beim Gastkonto anmelden, Dateien
erstellen und diese wieder lschen sowie Dateien lesen, fr die ein Admi-
nistrator den Gsten die Leseerlaubnis erteilt. Das Gastkonto wird als Service
fr Benutzer eingerichtet, die gelegentlich oder nur einmal den Rechner
benutzen, so dass diese sich anmelden und mit eingeschrnktem Funktions-
umfang arbeiten knnen. Das Gastkonto ist bei der Installation von
Windows NT 4.0 zunchst gesperrt, und es wird mit einem leeren Kennwort
installiert. Das Gastkonto ist auf jeden Fall mit einem sicheren Passwort zu
versehen, und die Sperre sollte nicht aufgehoben werden, wenn es keine
schwerwiegenden Grnde fr seine Benutzung gibt. Das vordefinierte Gast-
konto kann umbenannt, aber nicht gelscht werden. Es sollte unmittelbar nach
der Installation umbenannt werden.
Das Erstbenutzerkonto wird fr den ersten Benutzer einer Arbeitsstation
eingerichtet. Da es Mitglied der Gruppe "Administratoren" ist, kann die
Arbeitsstation mit dem Erstbenutzerkonto vollstndig verwaltet werden. Das
Erstbenutzerkonto wird bei der Installation von Windows NT erstellt, wenn
die Arbeitsstation zu einer Arbeitsgruppe hinzugefgt wird oder wenn sie
nicht fr den Netzbetrieb konfiguriert wurde. Das System fordert zur Eingabe
eines Benutzernamens und eines Kennworts auf. Wenn der Rechner bei der
Installation von Windows NT zu einer Domne hinzugefgt wird, wird das
Erstbenutzerkonto nicht erstellt, weil erwartet wird, dass sich der Benutzer
unter Verwendung eines Kontos von der Domne anmeldet.
Hinweis: Sofern Windows NT bei der Installation ein Erstbenutzerkonto ein-
richtet, sollte dieses als Konto zur Systemverwaltung verwendet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Installation im Netz
Weiterhin ist zu beachten, dass alle Clients bei der Konfiguration ihrer Netz-
software als Mitglieder einer der vorher definierten Domnen (und nicht als
Mitglieder von Arbeitsgruppen) konfiguriert werden. Falls auf ihnen
Benutzerkonten bentigt werden, mssen diese immer als domnenweite
Konten und nicht als lokale Konten definiert werden, um die Entstehung
unberschaubarer Rechtestrukturen zu vermeiden.
Zur Vereinfachung der Installation einer greren Anzahl von Clients sollten
vorher Skripten definiert werden, die eine automatische Installation und
Konfiguration dieser Clients ermglichen. Software aller Art sollte zentral auf
einem Server bereitgestellt und von dort aus auf dem entsprechenden Rechner
installiert werden.
- Welchen Benutzern wurde die Zugangskontrollinformation (Benutzer-
name, Passwort) zu den vordefinierten Benutzerkonten mitgeteilt?
- Wird regelmig kontrolliert, ob das Gastkonto noch gesperrt ist, bzw.
wenn es genutzt werden muss, werden die der Gruppe "Gste" erteilten
Zugriffsrechte und die Gruppenzuordnung des Gastkontos regelmig
berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.56 Sicheres Lschen unter Windows NT und Win-

dows 95
Windows NT
Windows NT legt in einer Master Dateitabelle alle Dateiinformationen wie
Namen, Pfad und Attribute ab. Diese Angaben werden nicht verschlsselt.
Programme, die direkt auf die Festplatte zugreifen knnen, knnen unter Um-
gehung der Sicherheitsmechanismen von Windows NT auf alle Dateien
beliebig zugreifen. Dies gilt insbesondere fr Programme, die unter einem
anderen Betriebssystem als Windows NT auf demselben Rechner laufen.
Beim Lschen einer Datei unter dem Dateisystem NTFS wird diese nicht phy-
sikalisch gelscht oder berschrieben, sondern hnlich wie unter MS-DOS
lediglich dem Zugriff entzogen, wobei jedoch unter Windows NT - im Gegen-
satz zu der Situation bei MS-DOS - sichergestellt ist, dass ein Zugriff auf
diese gelschten Daten, etwa mit einem Rekonstruktionsprogramm oder unter
Verwendung direkter Plattenzugriffe, nicht mehr mglich ist. Dennoch knnen
gelschte Dateien unter anderen Betriebssystemen als Windows NT mit Pro-
grammen, die direkt auf die Festplatte zugreifen knnen, wieder hergestellt
werden.
Aus diesen Grnden muss Windows NT als einziges Betriebssystem installiert
sein, und es muss verhindert werden, dass andere Betriebssysteme von
Diskette gestartet werden knnen (siehe M 4.52 Gerteschutz unter
Windows NT und M 4.55 Sichere Installation von Windows NT).
Windows 95/ Windows NT
Ab Windows NT Version 4.0 und unter Windows 95 werden Dateien beim
Lschen, sofern der Benutzer nicht ausdrcklich ein direktes Lschen
verlangt, zunchst in einen benutzerspezifischen Bereich, den sogenannten
"Papierkorb", verlagert. Aus diesem Bereich werden sie erst dann entfernt,
wenn der von gelschten Dateien belegte Speicherplatz die fr das betreffende
Plattenlaufwerk vorgegebene Gre berschreitet oder wenn der Benutzer
explizit den Papierkorb leert. Der Inhalt des Papierkorbs sollte daher
regelmig gelscht werden, damit die Festplatte nicht zu voll wird und der
Benutzer nicht den berblick verliert. Die maximale Gre des fr den
Papierkorb reservierten Speicherplatzes kann auch unter "Eigenschaften" des
Icons "Papierkorb" auf einen geeigneten kleineren Wert, z. B. 2 MByte,
eingestellt werden. Dateien mit sensitivem Inhalt sollten nicht in den
Papierkorb verschoben werden, sondern explizit gelscht werden, indem beim
Lschen die Umschalttaste gedrckt wird.
Unter Windows 95 besteht zudem die Mglichkeit aus dem Papierkorb
gelschte Dateien durch Hilfsprogramme zu rekonstruieren. Dateien mit
besonders sensitivem Inhalt sollten daher - bevor sie in den Papierkorb
verschoben werden - vollstndig berschrieben werden (vgl. M 2.3
Datentrgerverwaltung).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist die Gre des Papierkorbs unter Windows NT Version 4.0 bzw. unter
Windows 95 auf einen sinnvollen Wert eingestellt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.57 Deaktivieren der automatischen CD-ROM-

Erkennung
Unter Windows 95, Windows NT 4.0 und Windows 2000 knnen CD-ROMs
automatisch erkannt und bearbeitet werden. Dadurch knnen auch auf der CD-
ROM gespeicherte Programme automatisch auf dem Rechner ausgefhrt
werden. Die automatische CD-ROM-Erkennung sollte unter Windows 95 und
Windows NT/2000 permanent unterbunden werden.
Unter Windows 95 ist dafr auf der Registerkarte GERTEMANAGER unter
der Systemsteuerungsoption SYSTEM fr die CD-ROM die Eigenschaft
Automatische Benachrichtigung beim Wechsel zu deaktivieren.
Unter Windows NT 4.0 und Windows 2000 ist fr die permanente
Deaktivierung der automatischen CD-ROM-Erkennung in der Registrierung
der Eintrag Autorun im Schlssel SYSTEM \ CurrentControlSet \ Services \
CD-ROM im Bereich HKEY_LOCAL_MACHINE auf den Wert
REG_WORD = 0 zu setzen.
Falls die automatische CD-ROM-Erkennung gewnscht wird, lsst sie sich
auch fr jede CD-ROM einzeln durch Drcken der Shift-Taste beim Einlegen
verhindern.
- Ist die automatische CD-ROM-Erkennung ausgeschaltet?
- Sind die Benutzer informiert, wie sie die automatische CD-ROM-
Erkennung temporr verhindern knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.58 Freigabe von Verzeichnissen unter Windows 95

Fr jeden Rechner unter Windows 95 muss entschieden werden, ob die Peer-
to-Peer-Funktionalitten bentigt werden, um sie dann einzeln zuzulassen
oder zu sperren. Dafr kann ber die Systemrichtlinien ber die Menpunkte
Systemsteuerung / Netzwerk / Datei- und Druckerfreigabe die Datei- und
Druckerfreigabe einzeln zugelassen oder gesperrt werden. Anschlieend muss
dem Benutzer der Zugriff auf diese Registerkarte entzogen werden.
Wenn die Dateifreigabe deaktiviert ist, stehen die entsprechenden Funktionen
im Dateimanager bzw. Explorer nicht mehr zur Verfgung, es ist aber weiter
mglich, sich mit Verzeichnissen anderer Rechner zu verbinden.
Der Administrator muss darber hinaus beim Einrichtung eines WfW-
Rechners auch die weiteren Punkte beachten:
- Unter Windows 95 ist durch die Systemrichtlinien sicherzustellen, dass die
Benutzer weder Rechner- noch Benutzernamen selbststndig ndern
knnen.
- Die Voreinstellung "Kennwort in der Kennwortliste speichern" ist in den
Verbindungsoberflchen zu deaktivieren.
- Rechner- noch Benutzernamen sollten gem den Organisationsvorgaben
vergeben werden. Durch die Systemrichtlinien ist sicherzustellen, dass die
Benutzer weder Rechner- noch Benutzernamen selbststndig ndern kn-
nen.
- Beim Einsatz von Schedule+ ist darauf zu achten, dass das standardmig
vergebene Recht, offene oder besetzte Zeitblcke einzusehen, fr alle nicht
berechtigten WfW-Benutzer deaktiviert wird. Jeder Teilnehmer am selben
Post-Office ist sonst in der Lage, das zeitliche Arrangement der individuel-
len Termine einzusehen.
Wird ein Post-Office eingerichtet, dass von mehreren Benutzern zur
Kommunikation oder zur gemeinsamen Terminplanung genutzt werden soll,
ist in Erwgung zu ziehen, von diesem eine Datensicherung in angemessenen
Zeitrumen anzulegen. Dies ist notwendig, um einem versehentlichen oder
absichtlichen Lschen des Post-Office entgegenzuwirken, da dies unter WfW
nicht sicher verhindert wird.
Unter Windows 95 ist es mglich, eine Remote-Administration einzurichten,
die Administratoren ermglicht, ber das Netz auf die einzelnen Workstations
zuzugreifen. Vor Aktivierung dieser Option ist abzuklren, ob dies mit den
Sicherheitszielen der Organisation vereinbar ist.
Durch die Aktivierung der Remote-Administration besteht die Gefahr, dass
- jemand Kennung und Passwort fr die Remote-Administration
ausprobieren kann, oder
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- ein Administrator jederzeit unbemerkt auf Benutzerrechner zugreifen kann.

Falls diese Eigenschaft zur Erleichterung der Workstation-Betreuung ge-
wnscht ist, ist zu berlegen, ob ein Adminstrator fr alle von ihm betreuten
Workstations dasselbe Administrator-Passwort verwenden soll. Dies lsst sich
zwar leichter merken, fhrt aber dazu, dass ein Angreifer auf alle
Workstations zugreifen kann, wenn er dieses eine Passwort herausgefunden
hat.
- Ist dokumentiert, welche Verzeichnisse auf welchen Rechnern fr den
Netzzugriff freigegeben sind?
- Werden die vorhandenen Freigaben an Vernderungen im Einsatzumfeld
angepasst?
- Ist dokumentiert, auf welchen Rechnern Remote-Administration
eingerichtet ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.59 Deaktivieren nicht bentigter ISDN-Karten-

Funktionalitten
Moderne ISDN-Karten sowie deren Kommunikationssoftware bzw. das in das
Karten-RAM geladene Betriebssystem besitzen zahlreiche, ber die reinen
ISDN-Funktionalitten hinausgehende Leistungsmerkmale. Solche"Komfort-
Funktionalitten", welche teilweise auch bei ausgeschaltetem IT-System ange-
sprochen werden knnen, sind:
- der Empfang und Versand von Faxen,
- Funktionen eines digitalen Anrufbeantworters,
- das Abhren eingegangener Aufzeichnungen des digitalen Anrufbeantwor-
ters,
- das Telefonieren ber ein im Lieferumfang der Karte enthaltenes Mikrofon
bzw. einen enthaltenen Hrer.
Soweit es mglich ist, sollten nicht bentigte Karten-Funktionalitten deakti-
viert werden, am besten durch das Entfernen des jeweiligen Softwaremoduls.
Lassen sich Karten-Funktionalitten lediglich durch Parameter konfigurieren,
so muss die korrekte Einstellung der Parameter regelmig geprft werden.
- Werden die zur Verfgung stehenden Funktionalitten auf ihren tatschli-
chen Bedarf geprft?
Funktionen gesperrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.60 Deaktivieren nicht bentigter ISDN-Router-

Funktionalitten
Neben Servicefunktionen bzw. der Fernwartung (siehe M 2.108 Verzicht auf
Fernwartung der ISDN-Netzkoppelelemente) knnen auch Funktionen der
Router-Betriebssysteme zu Sicherheitslcken fhren. Beispielsweise ist das
Aufrufen einer Telnet-Sitzung auf dem Router und das sich anschlieende
Manipulieren der Management Information Base mglich, wenn dieser mit
einem Unix-Betriebssystem ausgestattet ist.
Soweit es mglich ist, sind diese nicht bentigten Funktionalitten zu
deaktivieren, am besten durch das Entfernen des jeweiligen Softwaremoduls.
Lassen sich Karten-Funktionalitten lediglich durch Parameter konfigurieren,
so muss die korrekte Einstellung der Parameter regelmig geprft werden.
- Werden die zur Verfgung stehenden Funktionalitten auf ihren tatschli-
chen Bedarf geprft?
Funktionen gesperrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.61 Nutzung vorhandener Sicherheitsmechanismen

der ISDN-Komponenten
Verantwortlich fr Initiierung: Leiter-IT, IT-Sicherheitsmanagement
Sind gem Manahme M 2.106 Auswahl geeigneter ISDN-Karten in der
Beschaffung ISDN-Karten mit Sicherheitsfunktionalitten fr das IT-System
oder den Router, wie
- Fhigkeit zur Durchfhrung einer Authentisierung ber PAP und CHAP
(Password Authentikation Protocol und Challenge Handshake Authenti-
cation Protocol, RFC 1994),
- Einsatz eines Verschlsselungsverfahrens (symmetrisch/asymmetrisch) in
Hard- oder Software,
- Mglichkeit der Auswertung von CLIP-Rufnummern (Calling Line
Identification Presentation) zur Authentisierung,
- Mglichkeit des Fhrens einer Rufnummerntabelle fr das Durchfhren
eines Call-Backs und
- Mglichkeit der Protokollierung nicht erfolgreicher Verbindungsaufbauten
(Ablehnung aufgrund falscher Rufnummern- oder PAP/CHAP-Authen-
tisierung),
beschafft worden, sollten diese auch geeignet genutzt werden, wie es die Ma-
nahmen M 5.48 Authentisierung mittels CLIP/COLP, M 5.49 Callback
basierend auf CLIP/COLP, M 5.50 Authentisierung mittels PAP/CHAP und
M 4.34 Einsatz von Verschlsselung, Checksummen oder Digitalen Signatu-
ren beschreiben. Voraussetzung hierfr ist, dass alle Kommunikationspartner
mit ISDN-Karten, die mglichst gleiche Sicherheitsfunktionalitten aufwei-
sen, ausgestattet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.62 Einsatz eines D-Kanal-Filters

Verantwortlich fr Initiierung: Leiter-IT, IT-Sicherheitsmanagement
Verantwortlich fr Umsetzung: Administrator, Beschaffungsstelle
Ein D-Kanal-Filter wird zwischen ISDN-Anschluss (S2M oder S0) und ISDN-
Endgert oder ISDN-TK-Anlage geschaltet. Zum ISDN-Anschluss verhlt es
sich wie ein ISDN-Endgert und zum ISDN-Endgert wie ein ISDN-
Anschluss. Der D-Kanal-Filter berwacht den ISDN-D-Kanal auf unzulssige
Protokollaktionen und ist damit in der Lage, Manipulationsversuche ber den
D-Kanal zu detektieren und zu verhindern. Der Einsatz des D-Kanal-Filters ist
insbesondere dann sinnvoll, wenn mit qualifizierten Angriffen ber Remote-
Zugriffe (zum Beispiel bei Fernwartung und -administration) zu rechnen ist.
D-Kanal-Filter schrnken weiterhin Leistungsmerkmale und Dienste fr Ruf-
nummern bestimmter Kommunikationspartner in der Weise ein, dass es unter
konkreten Betriebszustnden nicht zu einem Missbrauch bzw. zur Gefhrdung
der ISDN-Endeinrichtung kommen kann. Versuche, unberechtigt Leistungs-
merkmale und Dienste zu nutzen, werden von D-Kanal-Filtern mit einem Ver-
bindungsabbau (Disconnect, Release) beantwortet und protokolliert.
Weitere Informationen zu dieser vom BSI initiierten Technologie knnen
unter der IT-Grundschutz-Hotline nachgefragt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.63 Sicherheitstechnische Anforderungen an den

Telearbeitsrechner
heitsmanagement
Die sicherheitstechnischen Anforderungen an den Telearbeitsrechner richten
sich nach dem Schutzbedarf der zu bearbeitenden Daten am Telearbeitsplatz
und der Daten, auf die der Telearbeiter ber den Kommunikationsrechner der
Institution zugreifen kann. Je hher der Schutzbedarf, desto mehr Manahmen
mssen ergriffen werden, um diesen Schutz zu gewhrleisten. Allgemeine
Sicherheitsziele fr den Telearbeitsrechner sind:
- Der Telearbeitsrechner darf nur von autorisierten Personen benutzt werden
knnen.
Damit wird sichergestellt, dass nur autorisierte Personen die Daten und
Programme, die im Telearbeitsrechner gespeichert sind bzw. auf die ber
den Kommunikationsrechner zugegriffen werden kann, nutzen knnen.
Autorisierte Personen sind der Administrator des Telearbeitsrechners und
der Telearbeiter nebst seines Stellvertreters.
- Der Telearbeitsrechner darf nur fr autorisierte Zwecke benutzt werden.
Damit wird untersttzt, dass der Telearbeiter den Rechner nicht
unautorisiert benutzt oder verndert. Dies beugt Schden durch
Fehlbedienung und Missbrauch vor.
- Schden aufgrund eines Diebstahls oder Defektes des Telearbeitsrechners
mssen tolerabel sein.
Telearbeitsrechner werden blicherweise in einer wenig gesicherten Umge-
bung eingesetzt, so dass mit Diebstahl zu rechnen ist. Dabei tritt ein
Verlust der Verfgbarkeit und ggf. der Vertraulichkeit der gespeicherten
Daten ein. Dennoch mssen die Schden gering bleiben.
- Versuchte oder erfolgte Manipulationen am Telearbeitsrechner sollen fr
den Telearbeiter erkennbar sein.
Damit wird sichergestellt, dass der Telearbeitsrechner in einem integren
Zustand verbleibt, auch wenn Manipulationsversuche nicht ausgeschlossen
werden knnen.
Fr einen Telearbeitsrechner sind folgende Funktionalitten sinnvoll:
- Der Telearbeitsrechner muss ber einen Identifizierungs- und
Authentisierungsmechanismus verfgen. Insbesondere ist
sicherzustellen, dass
- sicherheitskritische Parameter, wie Passwort, Benutzer-Kennung,
usw., sicher verwaltet werden. Passwrter drfen nie unverschlsselt
auf dem Telearbeitsrechner gespeichert werden.
- das Zugangsverfahren definiert auf Fehleingaben reagiert. Erfolgt
zum Beispiel dreimal hintereinander eine fehlerhafte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Authentisierung, ist der Zugang zum Telearbeitsrechner zu sperren

oder alternativ sind die zeitlichen Abstnde, nach denen ein weiterer
Zugangsversuch erlaubt wird, sukzessiv zu vergrern.
- das Setzen bestimmter Minimalvorgaben fr die
sicherheitskritischen Parameter mglich ist. So sollte die
Mindestlnge eines Passwortes sechs Zeichen betragen.
- nach zeitweiser Inaktivitt der Tastatur oder Maus automatisch eine
Bildschirmsperre aktiviert wird, die erst nach erneuter Identifikation
und Authentisierung deaktiviert werden kann.
- Der Telearbeitsrechner muss ber eine Zugriffskontrolle verfgen. Insbe-
sondere ist sicherzustellen, dass
- der Telearbeitsrechner verschiedene Benutzer unterscheiden kann.
Es muss mglich sein, mindestens zwei getrennte Rollen auf dem
Telearbeitsrechner einzurichten, nmlich Administrator und
Benutzer.
- mittels einer differenzierten Rechtestruktur (lesen, schreiben,
ausfhren, ...) der Zugriff auf Dateien und Programme regelbar ist.
- Soll der Telearbeitsrechner ber eine Protokollierung verfgen, knnen
folgende Anforderungen sinnvoll sein:
- Der Mindestumfang, den der Telearbeitsrechner protokollieren soll,
sollte parametrisierbar sein. Beispielsweise sollten folgende
Aktionen inklusive der aufgetretenen Fehlerflle protokollierbar
sein:
- bei Authentisierung: Benutzer-Kennung, Datum und Uhrzeit,
Erfolg, ...,
- bei der Zugriffskontrolle: Benutzer-Kennung, Datum und
Uhrzeit, Erfolg, Art des Zugriffs, was wurde wie gendert,
gelesen, geschrieben, ...,
- Durchfhrung von Administratorttigkeiten,
- Auftreten von funktionalen Fehlern.
- Die Protokollierung darf von Unberechtigten nicht deaktivierbar
sein. Die Protokolle selbst drfen fr Unberechtigte weder lesbar
noch modifizierbar sein.
- Die Protokollierung muss bersichtlich, vollstndig und korrekt sein.
- Soll der Telearbeitsrechner ber eine Protokollauswertung verfgen,
knnen folgende Anforderungen sinnvoll sein:
- Eine Auswertefunktion muss nach den bei der Protokollierung gefor-
derten Datenarten unterscheiden knnen (z. B. "Filtern aller unbe-
rechtigten Zugriffe auf alle Ressourcen in einem vorgegebenen Zeit-
raum").
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Auswertefunktion muss auswertbare ("lesbare") Berichte erzeu-

gen, so dass keine sicherheitskritischen Aktivitten bersehen
werden.
- Der Telearbeitsrechner sollte ber Funktionen zur Datensicherung verf-
gen. Diese sollten u. a. folgende Anforderungen erfllen:
- Das Datensicherungsprogramm muss benutzerfreundlich und schnell
arbeiten. Es sollte automatisierbar sein.
- Es muss konfigurierbar sein, welche Daten wann gesichert werden.
- Es muss eine Option zum Einspielen beliebiger Datensicherungen
existieren.
- Die Funktion muss das Sichern von mehreren Generationen ermgli-
chen.
- Datensicherungen von Zwischenergebnissen aus der laufenden
Anwendung sollen mglich sein.
- Soll der Telearbeitsrechner ber eine Verschlsselungskomponente
verfgen, ist zunchst zu berlegen, welche Funktionalitt bentigt wird:
die Verschlsselung ausgewhlter Daten (offline) oder automatisch der
gesamten Festplatte (online). Dies setzt voraus, dass ein geeigneter
Verschlsselungsalgorithmus eingesetzt wird und dass ein Datenverlust bei
Fehlfunktion (Stromausfall, Abbruch der Verschlsselung) systemseitig
abgefangen wird. Darber hinaus sind folgende Anforderungen sinnvoll:
- Der implementierte Verschlsselungsalgorithmus sollte - beim
Einsatz in Behrden - vom BSI anerkannt sein. Hier empfiehlt sich
eine individuelle Beratung durch das BSI. Auerhalb der Behrden
ist bei mittlerem Schutzbedarf der DES, bei hohem Schutzbedarf der
Triple-DES geeignet.
- Das Schlsselmanagement muss mit der Funktionalitt des Telear-
beitsrechners harmonieren. Dabei sind insbesondere grundstzliche
Unterschiede der Algorithmen zu bercksichtigen: Symmetrische
Verfahren benutzen einen geheim zu haltenden Schlssel fr die
Ent- und Verschlsselung, asymmetrische Verfahren benutzen einen
ffentlichen Schlssel fr die Verschlsselung und einen privaten
(geheim zu haltenden) fr die Entschlsselung.
- Der Telearbeitsrechner muss die sicherheitskritischen Parameter wie
Schlssel sicher verwalten. So drfen Schlssel (auch mittlerweile
nicht mehr benutzte) nie ungeschtzt, das heit auslesbar, auf dem
Telearbeitsrechner abgelegt werden.
- Soll der Telearbeitsrechner ber Mechanismen zur Integrittsprfung
verfgen, sind folgende Anforderungen sinnvoll:
- Es sollten Verfahren zur Integrittsprfung eingesetzt werden, die
absichtliche Manipulationen am Telearbeitsrechner bzw. den darauf
gespeicherten Daten sowie ein unbefugtes Einspielen von Program-
men zuverlssig aufdecken knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Bei der Datenbertragung mssen Mechanismen eingesetzt werden,

mit denen absichtliche Manipulationen an den Adressfeldern und
den Nutzdaten erkannt werden knnen. Daneben darf die bloe
Kenntnis der eingesetzten Algorithmen ohne spezielle
Zusatzkenntnisse nicht ausreichen, um unerkannte Manipulationen
an den obengenannten Daten vornehmen zu knnen.
- Der Telearbeitsrechner sollte ber einen Boot-Schutz verfgen, um zu
verhindern, dass unbefugt von auswechselbaren Datentrgern, z. B. von
Diskette oder CD, gebootet werden kann.
- Es sollte mglich sein, die Benutzerumgebung des Telearbeitsrechners
einzuschrnken. Damit soll der Administrator festlegen knnen, welche
Programme der Telearbeiter ausfhren kann, welche Peripheriegerte nutz-
bar sind und welche nderungen der Telearbeiter am System vornehmen
darf. Darber hinaus sollte der Telearbeiter Einstellungen, die fr den
sicheren Betrieb notwendig sind, nicht unautorisiert ndern und nicht
unerlaubt Fremdsoftware aufspielen knnen.
- Auf dem Telearbeitsrechner muss ein Computer-Viren-Prfprogramm
installiert sein, um regelmig den Rechner auf Computer-Viren
berprfen zu knnen. Vor dem Einspielen von Daten von
auswechselbaren Datentrgern, vor der Weitergabe von Datentrgern bzw.
beim Senden und Empfangen von Daten muss ein Virencheck durchgefhrt
werden. Da an Telearbeitsrechnern der Datenaustausch mit externen IT-
Systemen eine wesentliche Rolle spielt und da Einzelprfungen sehr
zeitaufwendig und umstndlich sind und daher hufig unterlassen werden,
sollte bei einem Telearbeitsrechner bevorzugt ein residenter Virenscanner
installiert sein.
- Wenn der Telearbeitsrechner ber Fernwartung administriert werden soll,
ist sicherzustellen, dass die Fernadministration nur autorisiert durchgefhrt
werden kann. Bei der Fernwartung muss eine Authentikation des Fernwar-
tungspersonals, die Verschlsselung der bertragenen Daten und eine
Protokollierung der Administrationsvorgnge gewhrleistet sein.
- Die Software auf einem Telearbeitsrechner sollte benutzerfreundlich sein.
Sie sollte leicht bedienbar, verstndlich und gut erlernbar sein, da
Telearbeiter strker auf sich alleine gestellt sind als andere Mitarbeiter.
Insbesondere sollte den Benutzern aussagekrftige und nachvollziehbare
Dokumentationen des Betriebssystems und aller installierten Programme
zur Verfgung gestellt werden.
Aus den obigen Funktionalitten sind diejenigen auszuwhlen, die aufgrund
der Sicherheitsanforderungen an den Telearbeitsrechner bentigt werden.
Anhand dieser Funktionalitten muss dann ein geeignetes Betriebssystem als
Plattform ausgewhlt werden. Wenn dieses nicht alle bentigten Funktiona-
litten untersttzt, mssen dazu Zusatzprodukte eingesetzt werden. Dabei
sollten mglichst alle Telearbeitsrechner einer Institution gleich ausgestattet
sein, um die Betreuung und Wartung zu erleichtern. Zur sicherheits-
technischen Eignungsprfung sollte Kapitel 9.1 beachtet werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Gesamtsystem ist durch die Administratoren so zu konfigurieren, dass

maximale Sicherheit erreicht werden kann.
- Bietet das ausgewhlte Betriebssystem des Telearbeitsrechners die notwen-
dige Funktionalitt? Sind Zusatz-Sicherheitsprodukte notwendig?
- Welche der zustzlich empfohlenen Manahmen sind realisiert?
- Akzeptieren die Telearbeiter die ergriffenen Sicherheitsmanahmen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Weitergabe / Beseitigung von
Restinformationen
Vor dem Versenden einer Datei per E-Mail oder Datentrgeraustausch bzw.
vor dem Verffentlichen einer Datei auf einem WWW-Server sollte diese
daraufhin berprft werden, ob sie Restinformationen enthlt, die nicht zur
Verffentlichung bestimmt sind. Solche Restinformationen knnen verschie-
denen Ursprungs sein und dementsprechend unterschiedlich knnen auch die
Aktionen sein, die dagegen zu unternehmen sind. Die hufigsten Ursachen fr
solche Restinformationen sind im Folgenden beschrieben.
Generell sollte Standard-Software wie z. B. fr Textverarbeitung oder Tabel-
lenkalkulation darauf berprft werden, welche Zusatzinformationen in damit
erstellten Dateien gespeichert werden. Dabei werden einige dieser Informa-
tionen mit, andere ohne Wissen des Benutzers gespeichert.
Vor der Weitergabe von Dateien sollten diese zumindest stichprobenartig auf
unerwnschte Zusatzinformationen berprft werden. Dazu sollte ein anderer
Editor benutzt werden als der, mit dem die Datei erstellt wurde.
Dabei ist darauf zu achten, dass nicht alle Restinformationen einfach gelscht
werden knnen, ohne das Dateiformat zu zerstren. Wenn z. B. aus einer
Textverarbeitungsdatei einige Bytes gelscht werden, erkennt das Textver-
arbeitungsprogramm unter Umstnden das Dateiformat nicht mehr. Um
Restinformationen zu beseitigen,
- kann die Datei in einem anderen Dateiformat abgespeichert werden, z. B.
als "Nur-Text" oder als HTML,
- knnen die Nutzdaten in eine zweite Instanz derselben Standard-Software
kopiert werden, wobei auf dem IT-System keine andere Applikation laufen
sollte. Dies empfiehlt sich insbesondere bei Dateien mit einer greren
nderungshistorie.
Um der Weitergabe von Informationen vorzubeugen, die ursprnglich mit
Wissen der Ersteller eingebracht worden sind, wie z. B. als "verborgen" for-
matierter Text, dessen Vorhandensein dann aber vergessen wurde, kann es
sinnvoll sein, die Datei ausdrucken. Dabei sollten dann alle Optionen aktiviert
werden, die beim Drucken versteckte Informationen mitausgeben.
Restinformationen/Slack-Bytes
Beim Datentrgeraustausch kann sogenannter Slack-Space ein Problem dar-
stellen. Jedes Betriebssystem hat eine kleinste physikalische Speichereinheit
mit festgelegter Gre. Unter DOS ist dies ein Sektor und umfasst 512 Byte.
Bei Unix-Systemen ist dies ein Block, die Gre eines Blocks hngt dabei von
der eingesetzten Unix-Variante ab. Unter DOS werden die einzelnen Sektoren
einer Partition logisch zu Zuordnungseinheiten (Cluster) zusammengefasst.
Wieviele Sektoren einen Cluster bilden, hngt von der Gre der Partition ab.
Wird eine Datei geffnet, werden ihr ein oder mehrere Cluster zugeordnet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die letzte Zuordnungseinheit wird dabei nicht vollstndig benutzt, wenn die
Dateigre der zu speichernden Datei nicht zufllig ein Vielfaches der
Clustergre ist.
Dies verbraucht zum einen Speicherplatz. Der durchschnittliche Speicher-
platzverbrauch hierdurch steigt mit der Clustergre. Da diese wiederum mit
der Partitionsgre steigt, sollten Partitionen nicht zu gro sein. Hierzu ein
Beispiel: Bei einer Partitionsgre zwischen 1024 und 2047 MB hat ein ein-
zelner Cluster 32 KB. Damit gehen durchschnittlich bei jeder Datei 16 KB
Speicherplatz verloren.
Ein anderes Problem hierbei ist, dass (bei DOS-basierten Betriebssystemen)
die restlichen Bytes des letzten Clusters bzw. Blocks mit zufllig im Haupt-
speicher stehenden Bytes aufgefllt werden, sogenannten Slack-Bytes. Diese
knnen sinnlose Eintrge, Informationen ber die Dateistruktur, aber auch
Passwrter enthalten. Auch bei einem Kopiervorgang von einem Datentrger
auf den anderen kann die Datei je nach Clustergre mit Slack-Bytes aufge-
fllt werden.
Vor der Weitergabe von Dateien sollte sichergestellt werden, dass diese keine
Slack-Bytes mehr enthalten. Dies kann mit Hilfe eines geeigneten Editors
(z. B. Hex-Editor) berprft werden. Fr das berschreiben der Slack-Bytes
steht z. B. das Public-Domain-Programm PRUNE zur Verfgung, dass von
den Webseiten des BSI heruntergeladen werden kann.
Daneben haben viele Windows-Applikationen das Problem, dass das jeweilige
Programm bei der Bearbeitung einer Datei den in Anspruch genommenen
Speicherplatz nicht durchgehend mit Applikationsdaten berschreibt, sondern
dass Lcken entstehen knnen, die ebenfalls alte Datenbestnde des IT-
Systems enthalten.
Verborgener Text / Kommentare
Eine Datei kann Textpassagen enthalten, die als "versteckt" oder "verborgen"
formatiert sind. Einige Programme bieten auch die Mglichkeit an, Kommen-
tare hinzuzufgen, die auf dem Ausdruck und oft auch am Bildschirm ausge-
blendet sind. Solche Textpassagen knnen Bemerkungen enthalten, die nicht
fr den Empfnger bestimmt sind. Daher mssen in Dateien, bevor sie an
Externe weitergegeben werden, solche Zusatzinformationen gelscht werden.
nderungsmarkierungen
Bei der Bearbeitung von Dateien kann es sinnvoll sein, hierbei nderungs-
markierungen zu verwenden. Da diese auf dem Ausdruck und am Bildschirm
ausgeblendet werden knnen, muss vor der Weitergabe von Dateien ebenfalls
berprft werden, ob diese nderungsmarkierungen enthalten.
Versionsfhrung
In praktisch allen aktuellen Office-Suites gibt es die Mglichkeit, verschie-
dene Versionen eines Dokumentes in einer Datei zu speichern. Dies dient da-
zu, um bei Bedarf auf frhere berarbeitungsstnde zurckgreifen zu knnen.
Dies kann aber sehr schnell zu riesigen Dateien fhren, z. B. wenn Graphiken
mitgefhrt werden. Auf keinen Fall sollte die Option "Version beim Schlieen
automatisch speichern" gewhlt werden, da hier bei jedem Schlieen einer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Datei die komplette Vorgngerversion zustzlich gespeichert wird.

Dateieigenschaften
Als Dateieigenschaften oder Datei-Info werden in der Datei Informationen
gespeichert, die bei spteren Suchen helfen sollen, Dateien wieder zu finden.
Dabei knnen je nach Applikation Informationen wie Titel, Verzeichnis-
strukturen, Versionsstnde, Bearbeiter (nicht nur der Unterschreibende),
Kommentare, Bearbeitungszeit, letztes Druckdatum, Dokumentnamen und -
beschreibungen enthalten sein. Einige dieser Informationen werden von den
Programmen selber angelegt und knnen nicht durch den Bearbeiter
beeinflusst werden. Andere Informationen mssen manuell eingegeben
werden. Vor der Weitergabe einer Datei an Externe ist zu berprfen, welche
zustzlichen Informationen dieser Art die Datei enthlt.
Schnellspeicherung
Textverarbeitungsprogramme nutzen die Option der Schnellspeicherung, um
nur die Vernderungen seit der letzten Sicherung und nicht das gesamte
Dokument speichern zu mssen. Dieser Vorgang nimmt somit weniger Zeit in
Anspruch als ein vollstndiger Speichervorgang. Ein vollstndiger Speicher-
vorgang erfordert jedoch weniger Festplattenspeicher als eine Schnellspeiche-
rung. Der entscheidende Nachteil ist jedoch, dass die Datei unter Umstnden
Textfragmente enthalten kann, die durch die berarbeitung htten beseitigt
werden sollen. Grundstzlich sollten daher Schnellspeicherungsoptionen
Entscheidet sich der Benutzer trotzdem fr die Schnellspeicheroption, sollte er
bei folgenden Situationen immer einen vollstndigen Speichervorgang
durchfhren:
- wenn die Bearbeitung eines Dokuments abgeschlossen ist,
- bevor eine weitere Anwendung ausgefhrt wird, die viel Speicherplatz in
Anspruch nimmt,
- bevor der Dokumenttext in eine andere Anwendung bertragen wird,
- bevor das Dokument in ein anderes Dateiformat konvertiert wird und
- bevor das Dokument per E-Mail oder Datentrgeraustausch versandt wird.
- Wurden die Benutzer ber die mglichen Gefhrdungen durch Restinfor-
mationen in Dateien informiert?
- Wurden die Benutzer ber die mglichen Gefhrdungen durch den Einsatz
von Schnellspeicheroptionen aufgeklrt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.65 Test neuer Hard- und Software

Vor dem Einsatz neuer Hardware-Komponenten oder neuer Software mssen
diese auf speziellen Testsystemen kontrolliert werden. Neben der Lauffhig-
keit des Produktes ist dabei insbesondere zu berprfen, dass der Einsatz
neuer Komponeten keine negativen Auswirkungen auf die laufenden IT-
Systeme hat. Da vor erfolgreichen Tests Schadfunktionen nicht ausgeschlos-
sen werden knnen und da bei Tests Fehler provoziert werden, sind immer
vom Produktionsbetrieb isolierte Testsysteme zu verwenden.
Der Einsatz isolierter Testsysteme ist auch erforderlich, um selbstextrahie-
rende Dateien, die z. B. per E-Mail empfangen wurden, auf Schadfunktionen
zu prfen.
Generelle Verfahrensweisen fr die Software-Abnahme und -Freigabe inklu-
sive des Testens sind in Kapitel 9.1 Standardsoftware beschrieben. Erst nach
bestandenem Test drfen neue Komponenten fr die Installation auf Produk-
tionssystemen freigegeben werden.
- Ist neue Hard- bzw. Software vor dem Einsatz getestet worden?
- Ist neue Software auf Computer-Viren geprft worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.66 Novell Netware - Sicherer bergang ins

Jahr 2000
Diese Manahme ist aus dem Manahmenkatalog herausgenommen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.67 Sperren und Lschen nicht bentigter Daten-

bank-Accounts
Datenbank-Accounts, die ber einen lngeren Zeitraum nicht benutzt werden,
sollten gesperrt und spter - falls mglich - gelscht werden. Bei der Sperrung
bzw. auf jeden Fall vor dem Lschen eines Datenbank-Accounts sollte der
betroffene Benutzer informiert werden.
Wenn ein neu einzurichtender Benutzer seinen Datenbank-Account nur fr
einen befristeten Zeitraum bentigt, sollte dieser auch nur befristet
eingerichtet werden, falls die Datenbank eine solche Mglichkeit zur
Verfgung stellt. Es kann vorteilhaft sein, Accounts grundstzlich nur befristet
einzurichten und in regelmigen Abstnden (z. B. jhrlich) bei Bedarf zu
verlngern.
Ist absehbar, dass ein Benutzer einer Datenbank lngere Zeit abwesend ist
(durch Urlaub, Krankheit, Abordnung, o. .), so sollte sein Account fr diese
Zeit im Datenbanksystem gesperrt werden, so dass das Arbeiten unter seiner
Benutzer-Kennung fr diese Zeit nicht mehr mglich ist. Es muss
sichergestellt sein, dass der Datenbankadministrator alle lngeren
Abwesenheitszeitrume von Benutzern mitgeteilt bekommt. Sinnvollerweise
sollte dies im Rahmen der blichen Abwesenheitsmeldungen ber die
Personalstelle erfolgen.
Darberhinaus sollte die Datenbankadministration schnellstmglichst ber das
endgltige Ausscheiden eines Benutzers informiert werden. Sptestens am
letzten Arbeitstag des Benutzers ist dessen Account zu sperren.
- Existieren organisatorische Regelungen fr befristete Datenbank-Accounts,
insbesondere dann, wenn das Datenbanksystem das Einrichten solcher
Accounts nicht untersttzt?
- Wie wird berprft, welche Datenbank-Accounts lnger nicht benutzt
wurden?
- Wird regelmig geprft, welche Datenbank-Accounts nicht mehr bentigt
werden?
- Wird der Datenbankadministration mitgeteilt, wenn Benutzer der
Datenbank fr lngere Zeit abwesend bzw. ausgeschieden sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.68 Sicherstellung einer konsistenten Datenbank-

verwaltung
Administrator
Die Datenbankadministrator-Kennung unterliegt prinzipiell keinerlei Be-
schrnkungen bei der Nutzung des Datenbanksystems, was die Gefahr von
Fehlern oder Missbrauch erhht. Deshalb sollte auch der Datenbankadmi-
nistrator neben seiner Administrator-Kennung eine normale Benutzer-
Kennung erhalten und nur dann unter der Administrator-Kennung arbeiten,
wenn es notwendig ist.
Durch Aufgabenteilung, Regelungen und Absprache ist sicherzustellen, dass
Administratoren keine inkonsistenten oder unvollstndigen Eingriffe vorneh-
men. Dabei sollten folgende Bedingungen erfllt sein:
- Die Art und Weise der Durchfhrung von nderungen sowie deren Doku-
mentation ist festzulegen.
- Art, Umfang und Grund der nderungen sind zu beschreiben.
- nderungen an Datenbankobjekten oder Daten sind prinzipiell durch den
Verantwortlichen der IT-Anwendung genehmigungspflichtig. Handelt es
sich dabei um ein zentrales Datenbankobjekt, so erfordert eine nderung
die Zustimmung aller Verantwortlichen der betroffenen IT-Anwendungen.
- Der Zeitpunkt der geplanten nderungen ist festzulegen und bekannt zu
geben.
- Vor der Durchfhrung von nderungen muss die Datenbank komplett ge-
sichert werden.
Um den Missbrauch weitgehend einzuschrnken und Inkonsistenzen zu
vermeiden, sollten zustzlich alle Datenbankobjekte einer Anwendung unter
die Verwaltung einer eigens fr die jeweilige Anwendung eingerichteten
Benutzer-Kennung gestellt werden. nderungen an den Datenbankobjekten
bleiben somit diesen speziellen Benutzer-Kennungen vorbehalten, so dass
selbst unter der Administrator-Kennung der Datenbank keine Modifikationen
vorgenommen werden knnen. Kenntnis ber das Passwort dieser speziellen
Benutzer-Kennungen sollte nur derjenige Datenbankadministrator haben, der
fr die Administration der entsprechenden anwendungsspezifischen Belange
verantwortlich ist.
Beispiel:
In einer Datenbank werden die Daten von drei Anwendungen A, B und C
verwaltet. Alle Datenbankobjekte, die ausschlielich der Anwendung A zuzu-
ordnen sind, werden unter der Datenbank-Benutzer-Kennung AnwA
eingerichtet und nur ber diese Kennung verwaltet. Analog wird mit den
Datenbankobjekten der anderen beiden Anwendungen verfahren. Auf diese
Weise knnen an den Datenbankobjekten der drei Anwendungen nur mittels
der jeweiligen Datenbank-Benutzer-Kennung Modifikationen vorgenommen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden (unter der Voraussetzung, dass die Zugriffsrechte entsprechend

restriktiv definiert wurden).
Datenbankobjekte, die von mindestens zwei der drei Anwendungen bentigt
werden, sollten unter einer zentralen Datenbank-Kennung eingerichtet und
verwaltet werden.
Das entsprechende Passwort der drei anwendungsspezifischen Kennungen ist
nur demjenigen Administrator bekannt, der fr die Verwaltung und Pflege der
Datenbankobjekte der jeweiligen Anwendung verantwortlich ist. Das Passwort
fr die Datenbank-Kennung, ber die die zentralen Datenbankobjekte
verwaltet wird, ist dagegen keinem dieser Administratoren bekannt, sondern
unterliegt der Obhut eines weiteren Administrators. Auf diese Weise kann
verhindert werden, dass die Administratoren der jeweiligen Anwendungen
Modifikationen an zentralen Datenbankobjekten vornehmen knnen, die unter
Umstnden die Funktionalitt der anderen Anwendungen beeintrchtigen
knnte.
- Wie ist sichergestellt, dass Eingriffe des Datenbankadministrators nicht zu
Inkonsistenzen fhren?
- Haben alle Datenbankadministratoren eine zustzliche Benutzer-Kennung
mit eingeschrnkten Rechten?
- Werden standardmig die zustzlichen Benutzer-Kennungen benutzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.69 Regelmiger Sicherheitscheck der Datenbank

Der Datenbankadministrator sollte regelmig, jedoch mindestens einmal
monatlich einen Sicherheitscheck des Datenbanksystems durchfhren.
Folgende Punkte sollten dabei u. a. geprft werden, wobei die mit (*)
markierten Punkte meist durch entsprechende Skripte automatisiert werden
knnen:
- Sind die erforderlichen und geplanten Sicherungs- und Sicherheitsmecha-
nismen aktiv und greifen sie auch?
- Gibt es Datenbank-Benutzer ohne Passwort? (*)
- Gibt es Benutzer, die lngere Zeit das Datenbanksystem nicht mehr benutzt
haben?
- Wer darf bzw. kann auer dem Datenbank-Administrator auf die Dateien
der Datenbank-Software bzw. auf die Dateien der Datenbank auf Betriebs-
systemebene zugreifen? (*)
- Wer hat auer dem Datenbank-Administrator Zugriff auf die System-
Tabellen?
- Wer darf mit einem interaktiven SQL-Editor auf die Datenbank zugreifen?
- Welche Benutzer-Kennungen haben modifizierende Zugriffsrechte auf die
Datenbankobjekte der Anwendungen? (*)
- Welche Benutzer-Kennungen haben lesende und / oder modifizierende
Zugriffsrechte auf die Daten der Anwendungen? (*)
- Welche Benutzer besitzen die gleichen Rechte wie der Datenbank-Admi-
nistrator? (*)
- Verfgt das Datenbanksystem ber ausreichend freie Ressourcen? (*)
Anmerkung:
System-Tabellen sind die Tabellen, mittels derer die Datenbank selbst
verwaltet wird. In diesen Tabellen werden beispielsweise die einzelnen
Datenbankobjekte, die Datenbankkennungen, die Zugriffsberechtigungen
sowie die Zuordnungen von Dateien zu Speichermedien verwaltet. Die
System-Tabellen werden vom DBMS selbst bei der Erstellung einer
Datenbank erzeugt. Eine Modifikation dieser Tabelleninhalte ist prinzipiell
immer mit Datenbankkennungen mglich, die Administratorrechte besitzen.
Werden die Daten der System-Tabellen durch UPDATE-, INSERT- oder
DELETE-Kommandos modifiziert, besteht ein hohes Risiko, dass die
Datenbank zerstrt wird. Aus diesem Grund sollte man auf die Vergabe von
modifizierenden Rechten auf die System-Tabellen verzichten. Selbst ein
lesender Zugriff sollte beschrnkt werden, da ber die System-Tabellen alle
Informationen der Datenbank ermittelt werden knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wann wurde der letzte Sicherheitscheck durchgefhrt?
- Werden die Durchfhrung und die Ergebnisse der Sicherheitschecks doku-
mentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.70 Durchfhrung einer Datenbankberwachung

Um die Verfgbarkeit, die Datenbankintegritt und die Vertraulichkeit der
Daten gewhrleisten zu knnen, ist eine regelmige Datenbankberwachung
erforderlich. Die wesentlichen Punkte, die es dabei zu beachten gilt, werden
im folgenden kurz erlutert.
Die Datenbank ist in regelmigen Zeitabstnden hinsichtlich einer mglichen
Fragmentierung zu berprfen, um gegebenenfalls Manahmen wie z. B. eine
Reorganisation der Datenbank planen und durchfhren zu knnen.
Datenbanksysteme verwalten den ihnen zur Verfgung gestellten
Speicherplatz in der Regel in der Form von Blcken fester Gre. Wenn Stze
in eine leere Tabelle eingefgt werden, werden neue Blcke fr diese Tabelle
reserviert und mit den Datenstzen gefllt. Bei diesem Neuanlegen ist es
mglich, die Blcke (mit Ausnahme des letzten) fast vollstndig zu nutzen.
Werden im spteren Betrieb Datenstze gelscht, wird der von ihnen belegte
Speicherplatz in den Blcken freigegeben. Dieser Platz kann dann
grundstzlich fr andere Datenstze genutzt werden. Da die Datenstze aber
alle unterschiedliche Lngen haben, kann in der Regel ein freier
Speicherbereich nicht zu 100 % ausgenutzt werden. Dadurch entsteht durch
die Datennderungen im Laufe der Zeit eine immer grere Anzahl kleiner
Lcken in den Blcken der Datenbank, die meist nicht mehr genutzt werden
knnen. Diese Lcken entstehen nicht nur durch DELETE- und INSERT-
Operationen, sondern auch durch UPDATEs, da ein Datensatz nicht mehr an
derselben Stelle gespeichert werden kann, wenn sich seine Lnge gendert hat.
Das Vorhandensein solcher Lcken erhht nicht nur den Speicherbedarf, son-
dern verlangsamt auch Datenbankoperationen, da Datenstze oder freier Spei-
cherplatz erst in einem greren Plattenbereich gesucht werden mssen.
Der Grad der Fragmentierung in den Blcken einer Tabelle kann durch den
Vergleich zwischen der Menge der Daten in den Datenstzen in der Tabelle
und dem von den Blcken der Tabelle belegtem Speicherplatz festgestellt
werden. Auswertungen ber den Fragmentierungsgrad werden fr einige
DBMSe auch von der mitgelieferten Administrationssoftware oder von
Zusatzprodukten untersttzt.
Sollte die Fragmentierung der Datenbank aufgrund einer der oben genannten
Grnde zu gro werden, muss eine Reorganisation durchgefhrt werden. Dies
kann z. B. manuell erfolgen, in dem zuerst alle Daten der Datenbank
exportiert, dann alle Tabellen neu berechnet und angelegt und schlielich alle
Daten in die neue Datenbank wieder importiert werden. Fr manche DBMSe
sind auch Hilfsprogramme zum Defragmentieren von Tabellen erhltlich.
Ebenso sind die Datenbankdateien regelmig hinsichtlich ihres Fllgrades zu
berprfen, um rechtzeitig Manahmen wie z. B. eine Erweiterung der Spei-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
cherkapazitten planen und durchfhren zu knnen. Manche DBMSe erlauben

es dem Administrator durch Definition bestimmter Parameter bereits beim
Anlegen der Tabellen einer zu starken und zu raschen Fragmentierung vorzu-
beugen. So kann fr eine Tabelle von vornherein eine bestimmte Menge
zusammenhngender Blcke reserviert werden, in denen zustzlich bereits
freier Platz fr nderungen im Betrieb bereitgehalten wird.
Beispiel:
Bei einer Oracle Datenbank wird jeder Tabelle eine feste Anzahl von Extents
zugeordnet. Der Begriff Extent wird im Oracle Sprachgebrauch als logische
Greneinheit verwendet. Die Daten einer Tabelle werden in mindestens
einem Extent abgelegt. Sobald die Kapazitt eines Extents ausgeschpft ist,
legt das DBMS automatisch ein weiteres Extent an. Beim Erstellen einer
Tabelle knnen dabei folgende Werte definiert werden:
- Gre des ersten Extent in Bytes
- Gre des zweiten Extents in Bytes
- Wachstum aller weiteren Extents in Prozent, wobei diese Zahl in Relation
zur Gre des zweiten Extents steht.
- Maximale Anzahl an Extents, die fr die Tabelle angelegt werden drfen.
- Mit dem Parameter PCTFREE wird festgelegt, wieviel Prozent der neuen
Blcke fr sptere nderungen freigehalten werden.
Es muss ebenfalls regelmig berprft werden, ob das Datenvolumen
tatschlich in dem Mae anwchst wie es ursprnglich angenommen wurde.
Wchst es langsamer, werden unntige Speicherressourcen gebunden, die
anderweitig verwendet werden knnten. Wchst es schneller, kann es unter
Umstnden zu Speicherengpssen kommen.
Darber hinaus ist die Auslastung der Datenbank ist regelmig zu prfen,
insbesondere im Hinblick auf die eingestellten Obergrenzen (siehe M 4.73
Festlegung von Obergrenzen).
Welche Informationen fr eine konkrete Datenbankberwachung relevant
sind, hngt von deren spezieller Funktionsweise, also von der eingesetzten
Datenbank-Standardsoftware ab. Dementsprechend sind auch individuelle
Manahmen einzuleiten, die die Datenbankkonfiguration dahingehend
modifizieren, dass sie den Anforderungen hinsichtlich
Zugriffsgeschwindigkeiten, durchzufhrender Transaktionen usw. gerecht
wird.
Eine Automatisierung der Datenbankberwachung kann mittels Skripten
durchgefhrt werden. Eine Voraussetzung ist allerdings, dass die Infor-
mationen in auswertbarer Form von der eingesetzten Datenbank-Software zur
Verfgung gestellt werden.
- Werden die Datenbankdateien, wichtige Tabellen und die Auslastung der
Datenbank regelmig berprft?
- Sind die berwachungszeitrume angemessen definiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.71 Restriktive Handhabung von Datenbank-Links

ber sogenannte Datenbank-Links (DB-Links) besteht die Mglichkeit, von
einer Datenbank aus auf die Daten einer anderen Datenbank zuzugreifen. Um
einen angemessenen Schutz der Daten zu gewhrleisten, sollte diese Technik
jedoch nur dann verwendet werden, wenn dies unbedingt notwendig ist.
Um die Berechtigungen eines Benutzers bei der Verwendung von DB-Links
kontrollieren zu knnen, ist ein entsprechendes Konzept hinsichtlich der
Definition von Benutzer-Kennungen erforderlich. So erhlt ein Benutzer
prinzipiell die Mglichkeit, auf eine fremde Datenbank zuzugreifen, wenn dort
die gleiche Benutzer-Kennung existiert, mit der sich der Benutzer an der
lokalen Datenbank anmeldet. Einen weitergehenderen Schutz erhlt man
durch die Mglichkeit, einen DB-Link mit expliziter Angabe einer Benutzer-
Kennung und eines Passwortes zu erstellen.
Prinzipiell ist zunchst einmal jeder Benutzer der Datenbank befugt, solche
DB-Links zu erstellen (unter der Voraussetzung, dass er in der Lage ist, das
entsprechende CREATE-Kommando auszufhren). Im allgemeinen sollte
jedoch nur der Administrator das Recht besitzen, DB-Links zu erstellen.
Insbesondere gilt dies fr DB-Links, die von allen Datenbankbenutzern
genutzt werden drfen (sogenannte PUBLIC DB-Links). Die Berechtigung
zur Erstellung von DB-Links sollte dagegen fr normale Benutzer-Kennungen
explizit nicht vergeben werden.
Weiterhin sollte die Anzahl von parallel nutzbaren DB-Links eines Benutzers
begrenzt werden, um die Belastung der Datenbank-Server unter Kontrolle
halten zu knnen. Ansonsten kann ein Angreifer dies ausnutzen, um die
Verfgbarkeit der Datenbank-Server zu reduzieren oder diese sogar voll-
stndig lahm zu legen.
Eine Dokumentation der vom Administrator angelegten DB-Links ist
unabdingbar. Die Dokumentation sollte neben der Verbindungsart (ber eine
spezielle Benutzer-Kennung oder unter der Voraussetzung, dass die jeweilige
aktuelle Datenbankkennung ebenfalls fr die verbundene Datenbank angelegt
wurde) auch beinhalten, welcher Benutzerkreis in der Lage ist, den
entsprechenden DB-Link zu nutzen. Wie bereits erwhnt, steht ein DB-Link,
der als PUBLIC definiert wurde, allen Datenbankkennungen zur Verfgung.
- Existiert ein Konzept zur Definition von Benutzer-Kennungen und inwie-
weit ist darin die mgliche Verwendung von DB-Links bercksichtigt?
- Welche Benutzer-Kennungen sind berechtigt, DB-Links zu erstellen?
- Existiert ein Konzept zur Verwendung von DB-Links? Falls ja, wurde es
umgesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.72 Datenbank-Verschlsselung
Verantwortlich fr Umsetzung: Administrator, Anwendungsentwickler
In Abhngigkeit von der Art der in einer Datenbank gespeicherten Informatio-
nen und den sich daraus ergebenden Anforderungen an deren Vertraulichkeit
und Integritt kann es notwendig werden, diese Daten zu verschlsseln. Dabei
kann zwischen einer Online- und einer Offline-Verschlsselung unterschieden
werden:
- Bei einer Online-Verschlsselung werden die Daten whrend des
laufenden Betriebs ver- und entschlsselt, ohne dass die betroffenen
Benutzer davon etwas merken. Dafr knnen Tools eingesetzt werden, mit
denen entweder auf Betriebssystemebene die gesamte Festplatte
verschlsselt wird, oder solche, mit denen nur die Anwendungsdaten der
Datenbank verschlsselt werden.
- Bei einer Offline-Verschlsselung werden die Daten erst nach ihrer
Bearbeitung verschlsselt und vor ihrer Weiterverarbeitung wieder
entschlsselt. Dies wird im allgemeinen mit Tools durchgefhrt, die nicht
in das Datenbanksystem integriert sind, und kann insbesondere fr
Datensicherungen oder Datenbertragungen sinnvoll sein. Dabei ist zu
beachten, dass gengend Platz auf der Festplatte vorhanden ist, da die Ver-
bzw. Entschlsselung nur dann erfolgreich ausgefhrt werden kann, wenn
auf der Festplatte gengend Platz fr das Original und die verschlsselte
Version der Datenbank verfgbar ist.
Darber hinaus besteht die Mglichkeit, Daten weiterhin im Klartext in der
Datenbank abzuspeichern, beim Zugriff ber ein Netz jedoch eine
verschlsselte Datenbertragung zu realisieren. Dies kann z. B. durch die
Secure Network Services der Oracle SQL*Net Produktfamilie durchgefhrt
werden.
Welche Daten mit welchem Verfahren zu verschlsseln sind, ist am besten
bereits bei der Auswahl der Datenbank-Standardsoftware festzustellen (siehe
M 2.124 Geeignete Auswahl einer Datenbank-Software). Dabei sollten die
Anforderungen hinsichtlich der Verschlsselung von Datenbestnden mit den
entsprechenden Leistungsmerkmalen der Datenbank-Software verglichen
werden. Als Mindestanforderung sollte sie in jedem Fall sicherstellen, dass die
Passwrter der Benutzer-Kennungen der Datenbank verschlsselt abgelegt
sind.
Falls die Anforderungen durch keine der am Markt verfgbaren Datenbank-
Standardsoftware abgedeckt werden knnen, sollte man den Einsatz von
Zusatzprodukten prfen, um die entsprechende Sicherheitslcke zu schlieen.
Falls auch keine Zusatzprodukte erhltlich sind, muss ein Konzept fr die
Umsetzung einer Verschlsselungsstrategie erstellt werden, das im Unterneh-
men bzw. in der Behrde umgesetzt wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden von der Datenbank oder durch Zusatzprodukte geeignete
Techniken zur Verschlsselung bereitgestellt?
- Sind die Verantwortlichen ber ein ordnungsgemes Schlssel-
management informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.73 Festlegung von Obergrenzen

Verantwortlich fr Umsetzung: Administrator, Anwendungsentwickler
Um den Zugriff auf ein Datenbanksystem besser kontrollieren zu knnen und
um die Performance zu verbessern, ist die Festlegung von Obergrenzen fr
bestimmte Parameter sinnvoll. Dabei sind vor allem die folgenden Punkte zu
beachten:
Festlegung von Obergrenzen fr selektierbare Datenstze
Insbesondere wenn groe Datenmengen in einer Datenbank abgelegt wurden,
sollte eine maximale Anzahl von Datenstzen definiert werden, die im
Rahmen eines Datenzugriffs selektiert werden knnen.
Existieren solche Obergrenzen nicht, so kann ein Benutzer gezielt oder
unbeabsichtigt beliebig umfangreiche Selects durchfhren. Dies behindert
nicht nur den einzelnen Benutzer in seiner Arbeit, sondern fhrt auch bei allen
anderen Benutzern der Datenbank zu langen Wartezeiten. Werden die
Datenstze dabei selektiert, um diese zu modifizieren, so sind sie solange fr
alle anderen Benutzer gesperrt, bis diese Transaktion beendet ist.
Die Obergrenzen mssen im Rahmen der Anwendungen definiert werden, die
auf die Datenbank zugreifen. Dabei mssen geeignete Kontrollen bzw.
Sperren realisiert werden, die die Einhaltung der Obergrenzen berwachen.
Stellt eine Anwendung Suchfunktionalitten bereit, so sollte die
uneingeschrnkte Suche generell abgelehnt und die Eingabe von Suchkriterien
gefordert werden.
Festlegung von Ressourcenbeschrnkungen
Eine weitere Mglichkeit, die von einigen Herstellern angeboten wird, ist die
Untersttzung von Ressourcenbeschrnkungen in Bezug auf die Benutzung
einer Datenbank. So knnen beispielsweise die Anzahl von Anmeldungen pro
Benutzer-Kennung, der maximale Anspruch auf CPU-Zeit pro Anmeldung,
die Gesamtdauer einer Datenbankverbindung, die maximal zulssige inaktive
Zeit whrend einer Anmeldung und vieles mehr definiert werden.
Beispiele:
Mit folgendem Kommando wird in einer Oracle-Datenbank fr die
Datenbankkennung "Meier" der temporre Tablespace "Temp" auf 100 MB
begrenzt:
ALTER USER Meier TEMPORARY TABLESPACE Temp QUOTA
100M ON Temp;
Mit dem nachfolgenden Befehl wird ein Profile "Tester" erstellt, das die
Anzahl der Sessions, die maximale CPU-Zeit pro Session, die maximale Zeit
einer Datenbankverbindung und die maximale Leerlaufzeit (IDLE) begrenzt.
Dieses Profile kann dann einzelnen Benutzern zugeordnet werden.
CREATE PROFILE Tester LIMIT
SESSIONS PER USER 2,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
CPU_PER_SESSION 6000,
IDLE_TIME 30,
CONNECT_TIME 500;
Eine Ingres-Datenbank erlaubt beispielsweise fr Benutzer und Gruppen das
Setzen von Grenzen fr die maximale Ein- und Ausgabe je Abfrage oder fr
die Anzahl von Stzen pro Abfrage.
Weiterhin kann auch die Anzahl der Benutzer beschrnkt werden, die
gleichzeitig auf die Datenbank zugreifen drfen. Durch deren Begrenzung
mittels Parametereinstellungen im DBMS kann gewhrleistet werden, dass die
maximal zur Verfgung stehende Zahl an Lizenzen fr die Datenbank-
Software nicht berschritten wird. Auerdem verursachen viele parallel
zugreifende Benutzer eine hohe Arbeitslast, dem der Datenbank-Server
eventuell nicht gewachsen ist, wodurch sich die durchschnittliche Dauer einer
Transaktion verlngert. Ist in diesem Fall aus bestimmten Grnden eine
Erweiterung der Ressourcen des Datenbanksystems nicht mglich oder nicht
gewnscht, schafft hier eine Begrenzung der maximal mglichen parallelen
Benutzerzugriffe ebenfalls Abhilfe.
Die diesbezglichen Anforderungen sollten bereits whrend der Auswahl
einer Datenbank-Standardsoftware geklrt werden, um gegebenenfalls ein
Konzept zur Umsetzung der Ressourcenbeschrnkungen zu erstellen (siehe
M 2.124 Geeignete Auswahl einer Datenbank-Software).
- Wird die Einhaltung von Obergrenzen in den Anwendungen kontrolliert
und umgesetzt?
- Wird eine uneingeschrnkte Suche in den Anwendungen prinzipiell unter-
bunden?
- Wurden die Anforderungen an eine Ressourcenbeschrnkung der
Datenbank formuliert und dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.74 Vernetzte Windows 95 Rechner

Werden Windows 95 Rechner in einem Netz betrieben (Novell Netware oder
Windows NT), so sollte die Mglichkeit genutzt werden, die jeweiligen
Systemrichtlinien auf Netzservern zu speichern und diese dort zentral zu ver-
walten.
Mit Hilfe der SYSTEMSTEUERUNG unter NETZWERK wird hierbei die
primre Netzwerkanmeldung, d. h. der Pfad fr die Systemrichtlinien festge-
legt. Standardmig werden die Benutzerprofile auf einem Novell Netware
Server unter SYS:PUBLIC abgelegt. Erfolgt die primre Netzanmeldung an
einem Windows NT Rechner, so werden die Benutzerprofile standardmig
unter NETLOGON (%SystemRoot%\SYSTEM32\REPL\IMPORT\SCRIPTS\)
abgelegt.
Die Aktivierung der Benutzerprofile wird mit Hilfe der SYSTEMSTEUE-
RUNG-KENNWRTER-BENUTZERPROFILE sichergestellt.
Abb.: Eigenschaften von Kennwrtern

Weiterhin sollte zudem der Betrieb von Windows 95 ohne
Netzwerkanmeldung gesperrt werden um eine Umgehung der
Systemrichtlinien auf lokaler Basis zu verhindern. Hierzu sollte mit Hilfe von
POLEDIT.EXE unter lokaler Computer-Netzwerk-Anmeldung die Option
NETZWERKBESTTIGUNG FR WINDOWS ZUGRIFF FORDERN
aktiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Abb.: Eigenschaften von Lokaler Computer

Gruppenrichtlinien werden unter Windows 95 ber SYSTEMSTEUERUNG-
SOFTWARE-WINDOWS-SETUP installiert und befinden sich standard-
mig in dem Verzeichnis
ADMIN\APPTOOLS\POLEDIT\GROUPPOL.INF.
Die Namen der jeweiligen Benutzergruppen mssen hierbei den eingerichteten
Benutzergruppen unter Novell Netware bzw. Windows NT entsprechen.
Um den ordnungsgemen IT-Betrieb sicherzustellen, sollte zustzlich
beachtet werden, dass das Programm POLEDIT.EXE nicht auf dem lokalen
Windows 95 Rechner installiert werden darf, da mit diesem Programm die
gltigen Systemrichtlinien von jederman dauerhaft verndert werden knnen.
Ebenso sollte in der Datei MSDOS.SYS der Wert BootKeys verndert werden
(BootKeys=1) um den Start von Windows 95 im "abgesicherten Modus" zu
unterbinden. Dies verhindert, dass die Systemrichtlinien nicht zur Anwendung
kommen.
Das BIOS des Computers sollte zudem einen Systemboot ber Diskette
verhindern, sowie das Diskettenlaufwerk mit einem Schloss versperrt werden,
um Einsatz von unautorisierter Software zu erschweren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.75 Schutz der Registrierung unter

Windows NT/2000
In der Registrierung eines Windows NT/2000 Systems werden alle wichtigen Zugriffsrechte auf
Registry-Dateien
Konfigurations- und Initialisierungsinformationen gespeichert. Dort wird u. a.
auch die SAM-Datenbank verwaltet, die die Benutzer- und Computerkonten
enthlt. Beim Einsatz von Windows 2000 gilt dies insbesondere fr Rechner,
die keiner Domne angeschlossen sind, oder Domnen-Rechner, auf denen
auch lokale Konten benutzt werden.
Die Registrierung eines Windows NT/2000 Systems besteht aus mehreren Zugriffsrechte auf
Registry-Eintrge
Dateien, die sich in dem Verzeichnis %SystemRoot%\SYSTEM32\Config
befinden. Aus diesem Grund sollten die Zugriffsrechte auf dieses Verzeichnis
und die darin enthaltenen Dateien so gesetzt werden, wie dies in M 4.53
Windows NT und in M 4.149 Datei- und Freigabeberechtigungen unter
Windows 2000 vorgeschlagen wird.
Zur Erhhung des Schutzes sollten unmittelbar nach der Installation des
Betriebssystems die folgenden sicherheitsrelevanten Teile der Registrierung
durch expliziten Eintrag von Zugriffsrechten mit Hilfe des Registrierungs-
Editors besonders geschtzt werden. Dies erfolgt mit Hilfe des Programms
REGEDT32.EXE im Windows-Systemverzeichnis %SystemRoot% \
SYSTEM32. Die Einstellungen sollten so erfolgen, dass die Gruppe Jeder fr
diese Teile nur ber die Zugriffsrechte Wert einsehen, Teilschlssel auflisten,
Benachrichtigen und Zugriff lesen verfgt:
- im Bereich HKEY_LOCAL_MACHINE:
\Software\Windows3.1MigrationStatus (mit allen Unterschlsseln)
\Software\Microsoft\RPC (mit allen Unterschlsseln)
\Software\Microsoft\Windows NT\CurrentVersion
unter dem Schlssel \Software\Microsoft\Windows NT\CurrentVersion\:
+ Profile List
+ AeDebug
+ Compatibility
+ Drivers
+ Embedding
+ Fonts
+ FontSubstitutes
+ GRE_Initialize
+ MCI
+ MCI Extensions
+ Port (mit allen Unterschlsseln)
+ WOW (mit allen Unterschlsseln)
- im Bereich HKEY_CLASSES_ROOT:
\HKEY_CLASSES_ROOT (mit allen Unterschlsseln)
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Dabei ist sorgfltig vorzugehen, da fehlerhafte Einstellungen in der Registrie- Einstellungen testen
rung dazu fhren knnen, dass das System nicht mehr lauffhig ist und nach
dem nchsten Starten eventuell nicht mehr bootet. Die hier genannten
Einstellungen sollten daher zunchst auf ein Testsystem angewendet und auf
ihre Lauffhigkeit in der aktuellen Umgebung kritisch geprft werden, ehe sie
allgemein eingesetzt werden.
Netzzugriff auf die Registrierung
Sofern diese Funktionalitt nicht unbedingt gebraucht wird, sollte auch der
Zugriff ber das Netz auf die Registrierung gesperrt werden. Dies ist ab der
Version 4.0 mglich, indem der Eintrag winreg im Schlssel
\System\CurrentControlSet\Control\SecurePipeServers im Bereich
HKEY_LOCAL_MACHINE auf den Wert REG_DWORD = 1 gesetzt wird.
In der Version 3.x besteht die Mglichkeit der expliziten Sperrung von Netz-
zugriffen auf die Registrierung nicht. Hier kann man sich damit behelfen, dass
die Zugriffsberechtigung fr Jeder auf die Wurzel des Bereiches
HKEY_LOCAL_MACHINE (nicht jedoch auf die darunter liegenden Schls-
sel!) entfernt wird, so dass nur noch Administratoren auf diesen Bereich
Zugriff haben. Diese nderung ist unbedingt auf einem Testsystem zu ber-
prfen, da sie zur Folge haben kann, dass einige Anwendungen nicht mehr
lauffhig sind. Es ist zu beachten, dass diese nderung nur bis zum nchsten
Systemstart bestehen bleibt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.76 Sichere Systemversion von Windows NT

Verantwortlich fr Umsetzung: Administrator, Beschaffer
Vor der Beschaffung des Betriebssystems Windows NT muss entschieden Auswahl der
Sprachversion
werden, ob die englische oder die deutsche Version beschafft werden soll. Es
ist nicht mglich, eine eindeutige Empfehlung abzugeben. Daher soll hier nur
aufgezeigt werden, welche spezifischen Vor- und Nachteile die Entscheidung
fr die eine oder andere Version mit sich bringt.
Die englische Version von Windows NT ist strker verbreitet als die deutsche
Version. Dies fhrt dazu, dass Tools, Service Packs und Hot Fixes fr die
englische Version schneller verfgbar sind. Es gibt auch Tools, die nur mit der
englischen Version von Windows NT einsetzbar sind. Es ist auch mglich, die
englische Version von Windows NT so zu konfigurieren, dass Fehler-
meldungen in deutscher Sprache ausgegeben werden.
Andererseits ergibt sich die gleiche Situation hinsichtlich der Verfgbarkeit
bei den Schadprogrammen. Auch diese werden fr die englische Version
schneller entwickelt und sind teilweise fr die deutsche Version berhaupt
nicht verfgbar.
Windows NT kann nur dann sicher betrieben werden, wenn mindestens die Auswahl des jeweils
aktuellen Service Packs
Version 3.51 oder die Version 4.0 installiert ist. Weiterhin wird die Installa-
tion des jeweils aktuellen Service Packs empfohlen. Vor dem Einsatz im
Wirkbetrieb sollte jedoch getestet werden, ob das Service Pack mit allen
Komponenten in der vorliegenden Umgebung problemlos zusammenarbeitet.
Eventuell mssen neben der Installation des Service Packs weitere Updates an
Hardware- oder Software-Komponenten vorgenommen werden. Fr die
Windows NT Version 3.51 ist bei Drucklegung das Service Pack 5 und fr
Windows NT Version 4.0 das Service Pack 6a verfgbar. Die installierte
Systemversion und das ggf. installierte Service Pack werden beim Systemstart
angezeigt.
Auerdem werden durch Microsoft so genannte Hot Fixes zur Verfgung Installation von
Hot Fixes
gestellt, die Updates zu dem jeweils aktuellen Service Pack darstellen. Die
jeweils aktuellen Hot Fixes sollten ebenfalls installiert werden, soweit sie
Funktionen des installierten Systems betreffen. Hot Fixes werden als Reaktion
auf aufgetretene Probleme kurzfristig erstellt. Dies bedingt auch, dass sie nicht
so ausgetestet sind, wie die Service Packs. Deshalb sollten auf einem System
auch nur die wirklich erforderlichen Hot Fixes installiert werden. Der System-
verwalter muss sich regelmig darber informieren, welches Service Pack
und welche Hot Fixes fr sein System aktuell sind.
Die einmalige Installation eines Service Packs oder eines Hot Fixes reicht Erneutes Einspielen bei
nderungen der
nicht fr die Sicherstellung der Systemintegritt. Jede nderung der System- Systemkonfiguration
konfiguration, die einen Zugriff auf die Installations-CD-ROM erforderlich
macht oder bei der neue Gertetreiber installiert werden mssen, bedingt eine
erneute Installation des aktuellen Service Packs und der notwendigen Hot
Fixes. Wird dies unterlassen, besteht die Gefahr, dass Systemdateien, die aus
dem jeweiligen Service Pack oder dem Hot Fix stammen, durch eine ltere
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Version ersetzt werden, was im schlimmsten Fall dazu fhren kann, dass ein
Windows NT System nicht mehr in Betrieb genommen werden kann.
Nach der Installation eines Service Packs oder eines Hot Fixes sollten die
Notfalldisketten aktualisiert werden (siehe M 6.42 Erstellung von Rettungs-
disketten fr Windows NT). Auerdem sollte die Sicherheitskonfiguration des
betroffenen Rechners berprft werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.77 Schutz der Administratorkonten unter

Windows NT
Bei jeder Installation eines jeden Windows NT Systems wird ein Administra-
torkonto angelegt. Auf Windows NT Rechnern, die als Workstation oder als
Server ohne Domnencontrollerfunktion installiert werden, ist dieses vor-
definierte Administratorkonto Mitglied der Gruppe "Administratoren". Auf
Servern, die unter dem Betriebssystem Windows NT als Primre Domnen-
controller installiert werden, wird das vordefinierte Administratorkonto bei
der Installation Mitglied der Gruppen "Administratoren", "Domnen-Admins"
und "Domnen-Benutzer". Es ist weiterhin mglich, beliebige auf einem
Windows NT Rechner definierte Benutzerkonten den Gruppen
"Administratoren" oder "Domnen-Admins" hinzuzufgen.
Das vordefinierte Administratorkonto und die nach der Installation den
Gruppen "Administratoren" bzw. "Domnen-Admins" hinzugefgten
Benutzerkonten erhalten die Rechte und Berechtigungen, die der oder den
Gruppen erteilt wurden, in denen sie Mitglied sind. Diese Konten werden von
den Personen verwendet, welche die Gesamtkonfiguration der Arbeitsstation
oder des Servers verwalten. Administratoren besitzen mehr Kontrollmglich-
keiten ber den Windows NT Computer als jeder andere Benutzer.
Das vordefinierte Administratorkonto unterscheidet sich aber in wesentlichen
Punkten von allen anderen Konten unter Windows NT: Es kann nicht gelscht
werden und es ist von der automatischen Sperre bei wiederholten Anmelde-
versuchen mit falschem Passwort ausgenommen. Auerdem kann es auf
Windows NT Workstations und auf Windows NT Servern ohne Domnen-
controllerfunktionalitt nicht aus der Gruppe "Administratoren" entfernt
werden. Auf Windows NT Domnencontrollern ist es nicht mglich, das vor-
definierte Administratorkonto sowohl aus der Gruppe "Administratoren" als
auch aus der Gruppe "Domnen-Admins" zu entfernen. Die Entfernung aus
einer dieser beiden Gruppen ist aber mglich. Damit wird verhindert, dass ein
Administrator zeitweise oder vollstndig aus dem System ausgesperrt wird.
Andererseits fhrt dieser Mechanismus zu einem erhhten Einbruchsrisiko.
An dieser Stelle muss ausdrcklich darauf hingewiesen werden, dass alle
nachtrglich angelegten Benutzerkonten, die durch Aufnahme in die Gruppen
"Administratoren" bzw. "Domnen-Admins" Administratorrechte erlangt
haben, selbstverstndlich durch andere Administratoren gesperrt und gelscht
bzw. aus den o. g. Gruppen wieder entfernt werden knnen. Auch ist die
automatische Sperre bei wiederholten Anmeldeversuchen mit falschem
Passwort wirksam, sofern diese in den Kontenrichtlinien definiert wurde.
Auf allen Windows NT Computern sollte das vordefinierte Administrator-
konto auf einen nicht leicht erratbaren Namen umbenannt werden. Es sollte
bereits bei der Installation mit einem sicheren Passwort (siehe M 2.11
Regelung des Passwortgebrauchs) versehen werden. Das Passwort sollte
mglichst die maximale Lnge von 14 Zeichen ausnutzen und ist sicher zu
hinterlegen. Es ist sinnvoll, fr die tgliche Administration nicht das vor-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
definierte Administratorkonto zu benutzen, sondern Benutzerkonten, die der

Gruppe "Administratoren" oder "Domnen-Admins" hinzugefgt wurden. Die
Passwortlnge dieser Konten sollte mindestens 8 Zeichen betragen. Das vor-
definierte Administratorkonto sollte lediglich fr den Fall benutzt werden,
dass ein Zugriff ber die nachtrglich angelegten Konten mit Administrator-
rechten nicht mglich ist, z. B. weil diese Konten wegen wiederholten
Anmeldeversuchen mit falschem Passwort gesperrt sind.
Auch ist es sinnvoll, danach ein neues Konto mit dem Namen "Administrator"
anzulegen, dieses mit einem Passwort zu versehen, es zu deaktivieren und
dieses Konto nur in der Gruppe "Gste" aufzunehmen. Diesem Konto drfen
keine besonderen Systemrechte zugewiesen werden, da es lediglich dazu
dient, einen potentiellen Angreifer auf eine falsche Spur zu fhren.
Weiterhin sollte das Sicherheitsprotokoll regelmig auf Anmeldeversuche
mit Konten, die ber Administratorrechte verfgen, berprft werden (siehe
M 4.54 Protokollierung unter Windows NT).
Es existiert eine spezielle Schadsoftware, mit der ein lokal angemeldeter
Benutzer der Gruppe "Administratoren" beliebige Benutzerkonten hinzufgen
kann. Um dies zu verhindern, sollte auf allen Computern unter dem Betriebs-
system Windows NT 4.0 mit dem Service Pack 3 der Hot Fix "getadmin-fix"
installiert werden, der durch Microsoft kostenlos zur Verfgung gestellt wird.
Nach der Installation des Service Packs 4 ist es nicht mehr erforderlich, den
o. g. Hotfix zu installieren.
Um ein Extrahieren des Administratorpasswortes zu verhindern, sollten auer-
dem die Rechte auf die Verzeichnisse %SystemRoot%\SYSTEM32\Config und
%SystemRoot%\SYSTEM32\Repair so gesetzt werden, wie dies in M 4.53
Windows NT vorgeschlagen wird. Auch mssen Notstartdisketten und evtl.
vorhandene Bandsicherungen unter Verschluss gehalten werden.
Abhngig vom Schutzbedarf der Daten, die mit Windows NT Workstations
verarbeitet werden, ist zu entscheiden, ob fr alle lokalen Administratoren-
konten das gleiche Passwort benutzt wird. Eine generelle Empfehlung kann
nicht gegeben werden, es sollte jedoch bei einer Entscheidung zugunsten des
gleichen Passwortes fr alle Workstations bedacht werden, dass ein Angreifer
im Falle der Kompromittierung dieses Passwortes auf allen betroffenen Work-
stations Administratorrechte hat.
Bei Windows NT Servern sollten noch folgende weitere Manahmen getrof-
fen werden. Es sollten die Administratorenkonten auf den verschiedenen
Servern nicht alle mit dem gleichen Passwort versehen werden. Weiterhin
sollte mglichst nicht ber das Netz fernadministriert werden. Dies wird
erreicht, indem der Gruppe "Administratoren" das Recht "Zugriff auf diesen
Computer vom Netz" entzogen wird. Wo auf eine Fernadministration z. B.
aufgrund rumlicher Gegebenheiten nicht verzichtet werden kann, sollten die
Angriffsmglichkeiten, die sich dadurch erffnen, so gering wie mglich
gehalten werden. Dazu gehrt, dass eine Anmeldung ber das Netz fr
Benutzerkonten mit Administratorrechten nur ber in den Kontenrichtlinien
festgelegte Rechner, die unter dem Betriebssystem Windows NT betrieben
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden, erlaubt wird. Diese Rechner sollten mglichst in gesicherten

Bereichen aufgestellt werden. Auf diesen Rechnern sollte zwingend die LAN-
Manager-Kompatibilitt abgeschaltet werden, um so zu vermeiden, dass
Passwrter von Benutzerkonten mit Administratorrechten unverschlsselt
bzw. nur schwach verschlsselt ber das Netz gesendet werden. Dazu ist es
erforderlich, bei einem Windows NT 4.0 mit Service Pack 3 den Hot Fix "lm-
fix" zu installieren. Sofern auf dem System bereits das Service Pack 4
installiert wurde, ist eine Installation des v. g. Hot Fix nicht notwendig. In
jedem Fall ist aber in der Registrierung der folgende Schlssel zu ergnzen:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\Lsa um den
Eintrag "LMCompatibilityLevel" vom Typ "REG_DWORD" und dem Wert
"2".
Ein so modifizierter Windows NT Rechner ist danach nicht mehr in der Lage,
auf Ressourcen zuzugreifen, die sich auf Rechnern befinden, die das
Windows NT Authentisierungsschema nicht beherrschen. Dies sind u. a. alle
Rechner, die unter dem Betriebssystem Windows 95 betrieben werden.
Auf Domnencontrollern reicht es nicht aus, der Gruppe "Administratoren"
das Recht "Zugriff auf diesen Computer vom Netz" zu entziehen, weil auf
Domnencontrollern das vordefinierte Administratorkonto automatisch Mit-
glied in den Gruppen "Domnen-Admins" und "Domnen-Benutzer" gewor-
den ist. Das vordefinierte Administratorkonto sollte daher aus der Gruppe der
"Domnen-Admins" entfernt werden. Dies ist mglich, solange dieses Konto
Mitglied der Gruppe "Administratoren" bleibt. Auerdem sollte das vor-
definierte Administratorkonto aus der Gruppe "Domnen-Benutzer" entfernt
werden. Dies ist allerdings nicht ohne weiteres mglich, da es die primre
Gruppe dieses Kontos ist. Es muss daher eine beliebige globale Gruppe ange-
legt werden, die nicht ber das Recht "Zugriff auf diesen Computer vom Netz"
verfgt. Das vordefinierte Administratorkonto ist dieser Gruppe hinzuzufgen
und es ist einzustellen, dass dies nunmehr die primre Gruppe des Kontos sein
soll. Erst danach kann das vordefinierte Administratorkonto aus der Gruppe
"Domnen-Benutzer" entfernt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.78 Sorgfltige Durchfhrung von Konfigurations-

nderungen
Die Durchfhrung von nderungen an einem IT-System im Echtbetrieb ist
immer als kritisch einzustufen und entsprechend sorgfltig muss hierbei
vorgegangen werden.
Bevor mit nderungen am System begonnen wird, muss als erstes die alte
Konfiguration gesichert werden, so dass sie schnell verfgbar ist, wenn
Probleme mit der neuen Konfiguration auftreten.
Bei vernetzten IT-Systemen mssen die Benutzer rechtzeitig ber die
Durchfhrung von Wartungsarbeiten informiert werden, damit sie zum einen
ihre Planung auf eine zeitweise Systemabschaltung einrichten knnen, und
damit sie zum anderen nach nderungen auftretende Probleme richtig
zuordnen knnen.
Die Konfigurationsnderungen sollten immer nur schrittweise durchgefhrt
werden. Zwischendurch sollte immer wieder berprft werden, ob die
nderungen korrekt durchgefhrt wurden und das IT-System sowie die
betroffenen Applikationen noch lauffhig sind.
Bei nderungen an Systemdateien ist anschlieend ein Neustart
durchzufhren, um zu berprfen, ob sich das IT-System korrekt starten lsst.
Fr Problemflle sind alle fr einen Notstart bentigten Datentrger vorrtig
zu halten, z. B. Boot-Disketten, Start-CD-ROM.
Komplexere Konfigurationsnderungen sollten mglichst nicht in den
Originaldateien vorgenommen werden, sondern in Kopien. Alle
durchgefhrten nderungen sollten von einem Kollegen berprft werden,
bevor sie in den Echtbetrieb bernommen werden.
Bei IT-Systemen mit hohen Verfgbarkeitsanforderungen ist auf
Ersatzsysteme zurckzugreifen bzw. zumindest ein eingeschrnkter IT-Betrieb
zu gewhrleisten. Das Vorgehen kann sich dabei idealerweise nach dem
Notfall-Handbuch richten.
Die durchgefhrten Konfigurationsnderungen sollten Schritt fr Schritt
notiert werden, so dass bei auftretenden Problemen das IT-System durch
sukzessive Rcknahme der nderungen wieder in einen lauffhigen Zustand
gebracht werden kann (siehe auch M 2.34 Dokumentation der Vernderungen
an einem bestehenden System).
- Werden Systemvernderungen schrittweise dokumentiert?
- Lassen sich die nderungen nachtrglich rckgngig machen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.79 Sichere Zugriffsmechanismen bei lokaler

Administration
Bei einigen aktiven Komponenten kann ber einen lokalen Zugriff die Admi-
nistration der Komponenten erfolgen. Solch ein lokaler Zugriff ist zumeist
ber einen seriellen Anschluss (blicherweise eine V.24 bzw. EIA-232-E
Schnittstelle) realisiert. Fr einen sicheren lokalen Zugriff sind die folgenden
Manahmen zu beachten:
- Die aktiven Netzkomponenten und ihre Peripheriegerte, wie z. B. ange-
schlossene Terminals, mssen sicher aufgestellt werden (siehe M 1.29
Geeignete Aufstellung eines IT-Systems),
- der lokale Zugriff zur Administration der lokalen Komponenten muss soft-
waretechnisch und/oder mechanisch gesperrt werden,
- eine eventuell vorhandenes Standardpasswort des lokalen Zugriffs muss
sofort nach Inbetriebnahme gendert werden (zur Auswahl des neuen
Passwortes siehe M 2.11 Regelung des Passwortgebrauchs),
- die Sicherheitseigenschaften dauerhaft angeschlossener Terminals oder
Rechner, wie z. B. automatische Bildschirmsperre oder Auto-Logout, sind
zu aktivieren (siehe M 5.11 Konsolen der Server und aktiven Netzkompo-
nenten sperren).
Eine lokale Administration bietet folgende Vorteile:
- Die Gefahr des Abhrens von Passwrtern wird reduziert.
- Auch bei einem Ausfall des Netzsegmentes, in dem sich die aktive Kompo-
nente befindet, oder bei einem Ausfall des gesamten Netzes ist eine Admi-
nistration weiterhin mglich.
Eine lokale Administration bietet allerdings auch folgende Nachteile:
- Aktive Netzkomponenten knnen im allgemeinen so konfiguriert werden,
dass eine lokale oder eine zentrale Administration der aktiven Netzkompo-
nenten mglich ist. Fr die Auswahl der Konfigurationsmethode kann
jedoch keine generelle Empfehlung gegeben werden. Zu bercksichtigen
ist jedoch, dass bei der Konfiguration fr eine ausschlielich lokale
Administration keine zentrale Administration der aktiven Netzkom-
ponenten mehr mglich ist. Diese muss dann immer vor Ort direkt an den
entsprechenden Komponenten vorgenommen werden. In diesem Fall
erhht sich auch die Reaktionszeit im Strungsfall, da unter Umstnden
lngere Wege bis zum Standort der Komponente zurckzulegen sind.
- Der lokale Zugriff ist durch die Realisierung ber eine V.24 bzw.
EIA-232-E Schnittstelle im allgemeinen langsamer als ein Fernzugriff ber
das Netz.
- Sind die Standardpawrter fr den lokalen Zugriff gegen sichere ausge-
tauscht worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.80 Sichere Zugriffsmechanismen bei Fern-

administration
Einige aktive Netzkomponenten knnen ber einen Netzzugriff
fernadministriert oder berwacht werden. Der Zugriff erfolgt entweder ber
verbindungsorientierte oder verbindungslose Protokolle. Hierzu gehren:
- Protokolle zur reinen Datenbertragung, beispielsweise um neue
Firmware-Versionen oder Konfigurationsdateien zu bertragen, z. B. FTP,
TFTP (von letzterem wird prinzipiell abgeraten) oder RCP (siehe auch
M 6.52 Regelmige Sicherung der Konfigurationsdaten aktiver
Netzkomponenten),
- Protokolle zur interaktiven Kommunikation, z. B. Telnet,
- Protokolle fr das Netzmanagement, z. B. SNMP oder CMIP.
Bei allen Zugriffsarten ist dafr Sorge zu tragen, dass kein unautorisierter
Zugriff erfolgen kann.
Hierzu sind die Standardpawrter bzw. Community-Namen der Netzkompo-
nenten gegen sichere Passwrter bzw. Community-Namen auszutauschen
(siehe M 4.82 Sichere Konfiguration der aktiven Netzkomponenten). Die
Kopplung von Community-Namen und Passwort betrifft bei vielen aktiven
Netzkomponenten die Protokolle FTP, Telnet, SNMP und CMIP. Einige
Komponenten bieten auch die Mglichkeit, den Zugriff auf der Basis von
MAC- oder IP-Adressen zu beschrnken. Soweit mglich, sollte diese Option
genutzt werden, um den Zugriff nur von dedizierten Managementstationen aus
zu gestatten.
Protokolle zur Datenbertragung (TFTP, FTP, RCP) sollten nur von der Netz-
komponente selbst aus initiiert werden knnen. Dies trifft insbesondere fr
nicht authentifizierende Protokolle wie TFTP zu. Fr interaktive
Kommunikationsprotokolle (Telnet) sollte die Auto-Logout-Option der
Netzkomponente aktiviert werden.
Bei den meisten der genannten Protokollen ist zu beachten, dass die
bertragung der Passwrter bzw. Community-Namen im Klartext erfolgt, also
prinzipiell abgehrt werden kann (siehe hierzu M 5.61 Geeignete
physikalische Segmentierung und M 5.62 Geeignete logische Segmentierung)
Beispiel: Die bei SNMP standardmig voreingestellten Community-Namen
"public" und "private" sollten gegen andere Namen ausgetauscht werden.
- Wurden alle Standardpawrter und Community-Namen gegen sichere
selbstgewhlte ausgetauscht?
- Knnen Datenbertragungen nur von den Netzkomponenten aus initiiert
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.81 Audit und Protokollierung der Aktivitten im

Netz
Eine angemessene Durchfhrung von Protokollierung, Audit und Revision ist
ein wesentlicher Faktor der Netzsicherheit.
Eine Protokollierung innerhalb eines Netzmanagementsystems oder an
bestimmten aktiven Netzkomponenten erlaubt es, gewisse (im allgemeinen zu
definierende) Zustnde fr eine sptere Auswertung abzuspeichern. Typische
Flle, die protokolliert werden knnen, sind z. B. die bertragenen
fehlerhaften Pakete an einer Netzkomponente, ein unautorisierter Zugriff auf
eine Netzkomponente oder die Performance eines Netzes zu bestimmten
Zeiten. Eine Auswertung solcher Protokolle mit geeigneten Hilfsmitteln
erlaubt beispielsweise einen Rckschluss, ob die Bandbreite des Netzes den
derzeitigen Anforderungen gengt, oder die Erkennung von systematischen
Angriffen auf das Netz.
Unter einem Audit wird die Verwendung eines Dienstes verstanden, der insbe-
sondere sicherheitskritische Ereignisse betrachtet. Dies kann online oder
offline erfolgen. Bei einem Online-Audit werden die Ereignisse mit Hilfe
eines Tools (z. B. einem Netzmanagementsystem) in Echtzeit betrachtet und
ausgewertet. Bei einem Offline-Audit werden die Daten protokolliert oder aus
einer bestehenden Protokolldatei extrahiert. Zu den mit Hilfe eines Offline-
Audits berwachten Faktoren gehren hufig auch Daten ber Nutzungszeiten
und angefallene Kosten.
Bei der Revision werden die beim (Offline-) Audit gesammelten Daten von
einem oder mehreren unabhngigen Mitarbeitern (4-Augen-Prinzip) berprft,
um Unregelmigkeiten beim Betrieb der IT-Systeme aufzudecken und die
Arbeit der Administratoren zu kontrollieren.
Die mit einem Netzmanagement-System mglichen Protokollierungs- und
Audit-Funktionen sind in einem sinnvollen Umfang zu aktivieren. Neben Per-
formance-Messungen zur berwachung der Netzlast sind dabei insbesondere
die Ereignisse (Events) auszuwerten, die von einem Netzmanagement-System
generiert werden, oder spezifische Datensammler (z. B. RMON-Probes)
einzusetzen, mit denen sicherheitskritische Ereignisse berwacht und ausge-
wertet werden knnen.
Bei der Protokollierung fallen zumeist sehr viele Eintrge an, so dass diese nur
mit Hilfe eines Werkzeuges sinnvoll ausgewertet werden knnen. Beim Audit
liegt die Fokussierung auf der berwachung von sicherheitskritischen
Ereignissen. Zustzlich werden beim Audit hufig auch Daten ber
Nutzungszeitrume und anfallende Kosten erhoben.
Dabei sind fr ein Audit insbesondere folgende Vorkommnisse von Interesse:
- Daten ber die Betriebsdauer von IT-Systemen (wann wurde welches IT-
System ein- bzw. wieder ausgeschaltet?),
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zugriffe auf aktive Netzkomponenten (wer hat sich wann angemeldet?),

- sicherheitskritische Zugriffe auf Netzkomponenten und Netzmanagement-
Komponenten mit oder ohne Erfolg,
- Verteilung der Netzlast ber die Betriebsdauer eines Tages oder eines
Monats und die allgemeine Performance des Netzes.
Weiterhin sollten folgende Vorkommnisse protokolliert werden:
- Hardware-Fehlfunktionen, die zu einem Ausfall eines IT-Systems fhren
knnen,
- Unzulssige nderungen der IP-Adresse eines IT-Systems (in einem
TCP/IP-Umfeld).
Ein Audit kann sowohl online als auch offline betrieben werden. Bei einem
Online-Audit werden entsprechend kategorisierte Ereignisse direkt dem
Auditor mitgeteilt, der ggf. sofort Manahmen einleiten kann. Dafr mssen
Ereignisse in geeignete Kategorien eingeteilt werden, damit der zustndige
Administrator oder Auditor auf wichtige Ereignisse sofort reagieren kann und
nicht unter einer Flut von Informationen den berblick verliert. Ist Rollen-
trennung notwendig? Bei einem Offline-Audit werden die Daten aus den
Protokolldateien oder speziellen Auditdateien mit Hilfe eines Werkzeuges fr
Auditzwecke aufbereitet und durch den Auditor berprft. Im letzteren Fall
knnen Manahmen zur Einhaltung oder Wiederherstellung der Sicherheit nur
zeitverzgert eingeleitet werden. Im allgemeinen wird eine Mischform aus
Online- und Offline-Audit empfohlen. Dabei werden fr das Online-Audit die
sicherheitskritischen Ereignisse gefiltert und dem Auditor sofort zur Kenntnis
gebracht. Zustzlich werden weniger kritische Ereignisse offline ausgewertet.
Fr Protokollierung und Audit knnen die Standard-Managementprotokolle,
wie z. B. SNMP und das darauf aufsetzende RMON, aber auch spezifische
Protokolle des eingesetzten Netzmanagement-Produkt verwendet werden.
Auf keinen Fall drfen Benutzer-Passwrter im Rahmen eines Audits oder
einer Protokollierung gesammelt werden! Dadurch wird ein hohes Sicherheits-
risiko erzeugt, falls es zu einem unberechtigten Zugriff auf diese Infor-
mationen kommt. Auch falsch eingegebene Passwrter sollten nicht proto-
kolliert werden, da sie sich von den gltigen Passwrtern meist nur um ein
Zeichen bzw. um eine Vertauschung zweier Zeichen unterscheiden.
Es muss weiterhin festgelegt werden, wer die Protokolle und Audit-Daten aus-
wertet. Hierbei muss eine angemessene Trennung zwischen Ereignisverur-
sacher und -auswerter (z. B. Administrator und Auditor) vorgenommen
werden. Weiterhin ist darauf zu achten, dass die datenschutzrechtlichen
Bestimmungen eingehalten werden. Fr alle erhobenen Daten ist insbesondere
die Zweckbindung nach 14 BDSG zu beachten.
Die Protokoll- oder Auditdateien mssen regelmig ausgewertet werden. Sie
knnen sehr schnell sehr umfangreich werden. Um die Protokoll- oder
Auditdateien auf ein auswertbares Ma zu beschrnken, sollten die
Auswertungsintervalle daher angemessen, aber dennoch so kurz gewhlt
werden, dass eine sinnvolle Auswertung mglich ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden die aufgezeichneten Protokoll- und Auditdaten regelmig
kontrolliert?
- Werden die mglichen Konsequenzen sicherheitskritischer Ereignisse
analysiert?
- Werden die Benutzer-Passwrter protokolliert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.82 Sichere Konfiguration der aktiven Netzkompo-

nenten
Neben der Sicherheit von Serversystemen und Endgerten wird die eigentliche
Netzinfrastruktur mit den aktiven Netzkomponenten in vielen Fllen vernach-
lssigt. Gerade zentrale aktive Netzkomponenten mssen jedoch sorgfltig
konfiguriert werden. Denn whrend durch eine fehlerhafte Konfiguration eines
Serversystems nur diejenigen Benutzer betroffen sind, die die entsprechenden
Dienste dieses Systems nutzen, knnen bei einer Fehlkonfiguration eines
Routers grere Teilnetze bzw. sogar das gesamte Netz ausfallen oder Daten
unbemerkt kompromittiert werden.
Im Rahmen des Netzkonzeptes (siehe M 2.141 Entwicklung eines Netzkonzep-
tes) sollte auch die sichere Konfiguration der aktiven Netzkomponenten
festgelegt werden. Dabei gilt es insbesondere folgendes zu beachten:
- Fr Router und Layer-3-Switching muss ausgewhlt werden, welche Proto-
kolle weitergeleitet und welche nicht durchgelassen werden. Dies kann
durch die Implementation geeigneter Filterregeln geschehen.
- Es muss festgelegt werden, welche IT-Systeme in welcher Richtung ber
die Router kommunizieren. Auch dies kann durch Filterregeln realisiert
werden.
- Sofern dies von den aktiven Netzkomponenten untersttzt wird, sollte
festgelegt werden, welche IT-Systeme Zugriff auf die Ports der Switches
und Hubs des lokalen Netzes haben. Hierzu wird die MAC-Adresse des
zugreifenden IT-Systems ausgewertet und auf ihre Berechtigung hin
berprft.
Fr aktive Netzkomponenten mit Routing-Funktionalitt ist auerdem ein
geeigneter Schutz der Routing-Updates erforderlich. Diese sind zur
Aktualisierung der Routing-Tabellen erforderlich, um eine dynamische
Anpassung an die aktuellen Gegebenheiten des lokalen Netzes zu erreichen.
Dabei kann man zwei verschiedene Sicherheitsmechanismen unterscheiden:
- Passwrter
Die Verwendung von Passwrtern schtzt die so konfigurierten Router vor
der Annahme von Routing-Updates durch Router, die nicht ber das ent-
sprechende Passwort verfgen. Hierdurch knnen also Router davor ge-
schtzt werden, falsche oder ungltige Routing-Updates anzunehmen.Der
Vorteil von Passwrtern gegenber den anderen Schutzmechanismen ist ihr
geringer Overhead, der nur wenig Bandbreite und Rechenzeit bentigt.
- Kryptographische Prfsummen
Prfsummen schtzen vor der unbemerkten Vernderung von gltigen
Routing-Updates auf dem Weg durch das Netz. Zusammen mit einer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sequenznummer oder einem eindeutigen Bezeichner kann eine Prfsumme

auch vor dem Wiedereinspielen alter Routing-Updates schtzen.
Die Auswahl eines geeigneten Routing-Protokolls ist die Voraussetzung fr
einen angemessenen Schutz der Routing-Updates. RIP-2 (Routing Information
Protocol Version 2, RFC 1723) und OSPF (Open Shortest Path First, RFC
1583) untersttzen Passwrter in ihrer Basis-Spezifikation und knnen durch
Erweiterungen auch kryptographische Prfsummen nach dem MD5 (Message
Digest 5) Verfahren verwenden.
- Wurde bei der Erstellung des Netzkonzeptes die sichere Konfiguration der
aktiven Netzkomponenten bercksichtigt?
- Wird ein geeignetes Routing-Protokoll eingesetzt?
- Wie werden die Routing-Updates geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.83 Update/Upgrade von Soft- und Hardware im

Netzbereich
Durch ein Update von Software knnen Schwachstellen beseitigt oder Funk-
tionen erweitert werden. Dies betrifft beispielsweise die Betriebssoftware von
aktiven Netzkomponenten wie z. B. Switches oder Router, aber auch eine
Netzmanagement-Software. Ein Update ist insbesondere dann notwendig,
wenn Schwachstellen bekannt werden, die Auswirkungen auf den sicheren
Betrieb des Netzes haben, wenn Fehlfunktionen wiederholt auftauchen oder
eine funktionale Erweiterung aus sicherheitstechnischen oder fachlichen
Erfordernissen notwendig wird.
Auch ein Upgrade von Hardware kann in bestimmten Fllen sinnvoll sein,
wenn z. B. eine neue Version eines Switches eine hhere Transfer- und Filter-
rate bietet. Durch diese Manahmen kann der Grad der Verfgbarkeit, der
Integritt und der Vertraulichkeit unter Umstnden erhht werden.
Bevor jedoch ein Upgrade oder ein Update vorgenommen wird, muss die
Funktionalitt, die Interoperabilitt und die Zuverlssigkeit der neuen Kom-
ponenten genau geprft werden. Dies geschieht am sinnvollsten in einem
physikalisch separaten Testnetz, bevor das Update oder Upgrade in den pro-
duktiven Einsatz bernommen wird (siehe M 4.78 Sorgfltige Durchfhrung
von Konfigurationsnderungen).
- Werden die Updates bzw. Upgrades vor einem produktiven Einsatz auf die
Interoperabilitt mit den bereits vorhandenen Komponenten berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.84 Nutzung der BIOS-Sicherheitsmechanismen

Moderne BIOS-Varianten bieten eine Vielzahl von Sicherheitsmechanismen
an, mit denen sich die Benutzer oder die Systemadministration vertraut
machen sollten. Auf keinen Fall sollten aber ungeschulte Benutzer BIOS-
Eintrge verndern, da hierdurch schwerwiegende Schden verursacht werden
knnen.
- Passwortschutz: Bei den meisten BIOS-Varianten kann ein Passwortschutz
aktiviert werden. Dieser kann verhltnismig einfach berwunden wer-
den, sollte aber auf jeden Fall benutzt werden, wenn keine anderen
Zugriffsschutzmechanismen zur Verfgung stehen. Meist kann ausgewhlt
werden, ob das Passwort vor jedem Rechnerstart oder nur vor Zugriffen auf
die BIOS-Einstellungen berprft werden soll. Teilweise knnen sogar
verschiedene Passwrter fr diese Prfungen benutzt werden. Um zu ver-
hindern, dass Unbefugte die BIOS-Einstellungen ndern, sollte das Setup-
oder Adminstrator-Passwort immer aktiviert werden.
Mit einigen (leider wenigen) BIOS-Varianten kann zustzlich der Zugriff
auf die Diskettenlaufwerke durch ein Passwort geschtzt werden. Dies
sollte benutzt werden, um das unbefugte Aufspielen von Software oder das
unbemerkte Kopieren von Daten zu verhindern.
- Boot-Reihenfolge: Die Boot-Reihenfolge sollte so eingestellt sein, dass
immer als erstes von der Festplatte gebootet wird. Beispielsweise sollte
also "C,A" eingestellt werden. Dies schtzt vor der Infektion mit Boot-
Viren, falls versehentlich eine Diskette im Laufwerksschacht vergessen
wird, spart Zeit und schont das Diskettenlaufwerk.
Die Umstellung der Boot-Reihenfolge soll verhindern, dass der Boot-Vor-
gang von einem externen Datentrger erfolgt. Hiermit soll gewhrleistet
werden, dass whrend des Boot-Vorgangs nicht auf eine im Disketten-
laufwerk eingelegte Diskette zugegriffen wird, wodurch ein Boot-Virus
den PC infizieren knnte (siehe G 5.23 Computer-Viren). Je nach verwen-
detem BIOS und Betriebssystem muss auch das Booten von anderen
austauschbaren Datentrgern wie CD-ROMs verhindert werden.
Ohne eine Umstellung der Boot-Reihenfolge knnen auch weitere Sicher-
heitsmanahmen wie Zugriffsschutzmechanismen (siehe M 4.1
Passwortschutz fr PC und Server) umgangen werden. Ein Beispiel hierfr
ist das Starten eines anderen Betriebssystems, so dass gesetzte Sicherheits-
attribute ignoriert werden (siehe M 4.49 Absicherung des Boot-Vorgangs
fr ein Windows NT System).
Generell sollte die Wirksamkeit der Umstellung der Boot-Reihenfolge
durch einen Boot-Versuch geprft werden, da einige Controller die interne
Reihenfolge auer Betrieb nehmen und eine getrennte Einstellung erfor-
dern.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Virenschutz, Virus-Warnfunktion: Wird diese Funktion aktiviert, verlangt

der Rechner vor einer Vernderung des Boot-Sektors bzw. des MBR
(Master Boot Record) eine Besttigung, ob diese durchgefhrt werden darf.
- Welche BIOS- Sicherheitsmechanismen sind aktiviert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.85 Geeignetes Schnittstellendesign bei Krypto-

modulen
Ein Kryptomodul sollte so beschaffen und konfigurierbar sein, dass der
gesamte Informationsfluss von und zu dem Modul oder gar ein unmittelbarer
physikalischer Zugriff auf den Datenbestand des Moduls kontrolliert bzw.
eingeschrnkt werden kann. Je nach Anwendungsfall bzw. Schutzbedarf
empfiehlt sich die Verwendung von physikalisch getrennten Ein- und Aus-
gabeports. In jedem Fall sollten die Modulschnittstellen so aufgebaut sein,
dass die einzelnen Datenkanle logisch voneinander verschieden sind, obwohl
sie mglicherweise einen gemeinsamen Ein- oder Ausgangsport teilen. Im
Zusammenhang mit dem Schlsselmanagement des Kryptomoduls muss
gewhrleistet sein, dass die Ausgabekanle von der internen Schlsselgenerie-
rung bzw. dem Eingabeport fr die manuelle Schlsseleingabe zumindest
logisch getrennt sind. In vielen Fllen werden zum Anschluss einer externen
Versorgungsspannung bzw. eines externen Versorgungstakts und zur aus-
schlielichen Verwendung von Reparatur- oder Wartungsaufgaben separate
Schnittstellen zur Verfgung stehen. Aus der Perspektive des Kryptomoduls
ist daher die folgende Aufteilung und Verwendung zweckmig:
- Dateneingabeschnittstelle, die all diejenigen Eingabedaten des Krypto-
moduls fhrt, die im Modul weiterverarbeitet oder bearbeitet werden (z. B.
kryptographische Schlssel, Authentisierungsinformationen, Statusinfor-
mationen von anderen Kryptomodulen, Klartextdaten etc.).
- Datenausgabeschnittstelle, die all diejenigen Daten des Kryptomoduls
fhrt, die vom Modul an dessen Umgebung gelangen sollen (z. B. ver-
schlsselte Daten, Authentisierungsinformationen, Steuerinformationen fr
andere Kryptomodule, etc.).
- Steuereingabeschnittstelle, die smtliche Steuerbefehle, -signale und -daten
zur Ablaufsteuerung und Einstellung der Betriebsweise des Moduls fhrt.
- Statusausgabeschnittstelle, die alle Signale, Anzeigen und Daten an die
Umgebung abfhrt, um den inneren Sicherheitszustand des Kryptomoduls
anzuzeigen.
Und schlielich
- Maintenance-Schnittstelle, die ausschlielich Wartungs- und/oder Repara-
turzwecken dient.
Die Dokumentation fr eine Kryptokomponente sollte eine Beschreibung
smtlicher Komponenten enthalten (Hard-, Firm- und/oder Software).
Ferner sollte die Dokumentation die komplette Spezifikation der Modul-
schnittstellen beinhalten zuzglich der physikalischen oder logischen Ports,
manuellen oder logischen Steuereinheiten, physikalischen oder logischen
Anzeigeelementen sowie deren physikalischen, logischen oder elektrischen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Eigenschaften. Wenn eine Kryptokomponente eine Maintenance-Schnittstelle

enthlt, sollte die Dokumentation auch die vollstndige Spezifikation der
durchzufhrenden Wartungsprozesse zur Verfgung stellen. Alle physika-
lischen und logischen Ein- und Ausgabekanle innerhalb des Moduls mssen
explizit offengelegt sein. Neben der konkreten Einbindung der Kryptokompo-
nente in eine vorgesehene Einsatzumgebung ist auch die Bedienung und
Benutzung der Kryptokomponente zu beschreiben.
Die Dokumentation sollte weiterhin eine Zusammenstellung der Sicherheits-
funktionalitt enthalten und womglich die Abhngigkeit von Hard-, Firm-
oder Software aufzeigen, die je nach Konzeption der Kryptokomponente nicht
unmittelbar zum Lieferumfang der Kryptokomponente gehren.
Die Dokumentation ber die Modulschnittstellen sind vom Modulhersteller
zur Verfgung zu stellen. Die Dokumentation wird beispielsweise von einem
Administrator bentigt, der beabsichtigt, das Kryptomodul in seine
Systemumgebung zu integrieren, oder von einem Evaluator, der eine
Sicherheitsbeurteilung des Kryptomoduls vornehmen mchte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.86 Sichere Rollenteilung und Konfiguration bei

Kryptomodulen
Viele kryptographische Sicherheitskomponenten bieten die Mglichkeit, dass
mehrere Nutzerrollen sowie die zugehrigen Handlungen, die durch das
autorisierte Personal ausgefhrt werden knnen, unterschieden werden kn-
nen. Abhngig vom Schutzbedarf sind hierzu Zugriffskontroll- und Authenti-
sierungsmechanismen erforderlich, um verifizieren zu knnen, ob ein Nutzer
zur Ausfhrung des gewnschten Dienstes auch tatschlich autorisiert ist. In
Bezug auf die unterschiedlichen Rollen bietet sich folgende Unterteilung an:
- Benutzerrolle, der die Benutzung und Verwendung der Sicherheitskompo-
nente obliegt (z. B. Endteilnehmer, Benutzer).
- Operatorrolle, die fr die Installation und das Kryptomanagement verant-
wortlich ist (z. B. Sicherheitsadministrator).
Und zumindest eine
- Maintenance-Rolle, die fr Wartungs- und Reparaturarbeiten zustndig ist
(z. B. Wartungstechniker, Revisor).
Bei Kryptokomponenten, bei denen die Benutzer- und die Administratorrolle
getrennt werden kann, sollte diese Mglichkeit auch genutzt werden und
durch die Administration Grundeinstellungen vorgegeben werden, wie z. B.
Passwortlnge oder Schlssellnge, so dass die Benutzer nicht aus Bequem-
lichkeit oder Unkenntnis unsichere Einstellungen whlen knnen.
Neben den unterschiedlichen Rollen gilt es entsprechend auch die verschie-
denen Handlungen bzw. die von der Sicherheitskomponente bereitgestellten
Dienste zu unterscheiden. Ein Kryptomodul sollte zumindest folgende Dienste
zur Verfgung stellen:
- Statusanzeige zur Ausgabe des momentanen Status der Kryptokomponente,
- Selbsttest zur Initialisierung und Durchfhrung von selbstndigen Selbst-
tests,
- Bypass zur Aktivierung und Deaktivierung eines Bypass mittels dessen
durch das Kryptomodul Klarinformationen bzw. ungesicherte Daten trans-
portiert werden.
Zur erforderlichen Authentisierung des Personals gegenber der Sicherheits-
komponente bieten sich eine Vielzahl von unterschiedlichen Techniken an:
Passwort, PIN, kryptographische Schlssel, biometrische Merkmale etc. Die
Kryptokomponente sollte so konfiguriert sein, dass bei jedem Rollenwechsel
oder bei Inaktivitt nach einer bestimmten Zeitdauer die Authentisierungs-
informationen erneut eingegeben werden mssen. Ferner empfiehlt sich an
dieser Stelle eine Beschrnkung der Authentisierungsversuche (z. B. indem
der Fehlbedienungszhler auf 3 gesetzt wird).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.87 Physikalische Sicherheit von Kryptomodulen

Wie in M 2.165 Auswahl eines geeigneten kryptographischen Produktes
beschrieben, knnen Kryptomodule in Software, Firmware oder Hardware
realisiert sein. Firmware- bzw. Hardware-Produkte werden insbesondere dann
gewhlt, wenn das Kryptomodul besonders manipulationsresistent sein soll.
Unter diesem Gesichtspunkt sollte das Kryptomodul unter Verwendung von
physikalischen Sicherheitsmanahmen oder unter Ausnutzung entsprechender
Materialeigenschaften so konstruiert sein, dass ein unautorisierter physika-
lischer Zugriff auf Modulinhalte erfolgreich verhindert werden kann. Dies soll
mglichen technischen Manipulationen oder sonstigen Beeintrchtigungen im
laufenden Betrieb vorbeugen. In Abhngigkeit von der Sicherheitsstufe des
Kryptomoduls sind hierzu beispielsweise die Verwendung von
Passivierungsmaterialien, geeignete Tamperschutzmanahmen oder mecha-
nische Schlsser in Betracht zu ziehen. Eine automatische Notlschung, die
eine aktive Lschung oder die Vernichtung aller im Klartext enthaltenen
sensitiven Schlsseldaten und -parameter bewerkstelligen kann, innerhalb des
Kryptomoduls nach identifizierten Angriffsversuchen, zhlt ebenfalls in diese
Manahmenkategorie.
Mit dem Einsatz von diversen Sensoren und berwachungseinrichtungen lsst
sich sicherstellen, dass das Kryptomodul - was Spannungsversorgung,
Taktung, Temperatur, mechanische Beanspruchung, elektromagnetische
Beeintrchtigung etc. anbelangt - in seinem vorgesehenen Arbeitsbereich
betrieben wird.
Zur Aufrechterhaltung seiner beabsichtigten Funktionalitt sollte das
Kryptomodul Selbsttests initiieren und durchfhren knnen. Diese Tests
knnen sich auf folgende Bereiche erstrecken: Algorithmentests, Software und
Firmwaretests, Funktionstests, statistische Zufallstests, Konsistenztests,
Bedingungstests sowie Schlsselgenerierungs- und -ladetests. Im Anschluss
an ein negatives Testergebnis sollte dem Benutzer des Kryptomoduls eine ent-
sprechende Fehlermeldung signalisiert und ein entsprechender Fehlerzustand
eingenommen werden. Erst nach Behebung der Fehlerursache(n) darf eine
Freischaltung aus diesem Fehlerzustand mglich sein.
Beim Einsatz von Softwareprodukten muss die physikalische Sicherheit des
Kryptomoduls durch das jeweilige IT-System bzw. dessen Einsatzumgebung
geleistet werden. Sicherheitstechnische Anforderungen an solche IT-Systeme
knnen den systemspezifischen Bausteinen entnommen werden.
Eine Softwarelsung sollte Selbsttests durchfhren knnen, um Modifi-
kationen durch Trojanische Pferde oder Coputer-Viren erkennen zu knnen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.88 Anforderungen an die Betriebssystem-

Sicherheit beim Einsatz von Kryptomodulen
Beim Einsatz von Kryptomodulen spielt deren Einbindung ins bzw. Abhn-
gigkeit vom jeweiligen Betriebssystem des Hostsystems eine wesentliche
Rolle. Das Zusammenwirken von Betriebssystem und Kryptomodul muss
gewhrleisten, dass
- das Kryptomodul nicht abgeschaltet oder umgangen werden kann (z. B.
durch Manipulation oder Austausch von Treibern),
- die angewendeten oder gespeicherten Schlssel nicht kompromittiert
werden knnen (z. B. durch Auslesen von RAM-Bereichen),
- die zu schtzenden Daten nur mit Wissen und unter Kontrolle des
Anwenders auch unverschlsselt auf Datentrgern abgespeichert werden
knnen bzw. das informationsverarbeitende System verlassen (z. B. bei
Netzanbindung),
- Manipulationsversuche am Kryptomodul erkannt werden.
Je nach Art des Kryptomoduls (Hardware- oder Software-Realisierung,
Einbindungsstrategie in die IT-Komponente etc.), den Einsatzbedingungen
und dem Schutzbedarf der zu sichernden Daten knnen sich unterschiedlich
starke Anforderungen bzgl. der Betriebssystem-Sicherheit ergeben. Bei in
Software realisierten Kryptomodulen ist der Einsatz eines sicheren Betriebs-
systems besonders wichtig. Kommerzielle PC-Betriebssysteme sind in der
Regel derart komplex und kurzen Innovationszyklen unterworfen, dass die
Daten- bzw. Systemsicherheit kaum nachweisbar oder beweisbar ist. Eine
Ausnahme knnen proprietre oder fr spezielle Anwendungen optimierte
Betriebssysteme bilden (z. B. spezielle Betriebssysteme in Kryptogerten).
Daher ist es beim Einsatz von kryptographischen Produkten auf Standard-
Betriebssystemen wie z. B. zur Dateiverschlsselung oder zur E-Mail-
Absicherung wichtig, dass alle Standardsicherheitsmanahmen fr dieses
Betriebssystem umgesetzt sind. Die sicherheitstechnischen Anforderungen an
diese IT-Systeme knnen den jeweiligen systemspezifischen Bausteinen ent-
nommen werden, so etwa fr Clients in Kapitel 5, fr Server in Kapitel 6.
In Hardware realisierte Kryptomodule knnen so konstruiert sein, dass sie
Mngel der Betriebssystem-Sicherheit kompensieren oder vollstndig aus-
rumen. Hier liegt die Verantwortung zur Erfllung der o. g. Anforderungen
allein beim Kryptomodul. Es muss z. B. erkennen knnen, ob unverschlsselte
Daten berechtigt oder unberechtigt am Modul vorbei auf Datentrger oder
andere Gerteschnittstellen geschrieben werden. Der Anwender muss in ber-
einstimmung mit der fr sein Umfeld individuell erstellten Sicherheitspolitik
entscheiden, welche Kombination Betriebssystem / Kryptomodul erforderlich
ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.89 Abstrahlsicherheit
Jedes elektronische Gert strahlt mehr oder weniger starke elektromagnetische
Wellen ab. Diese Abstrahlung ist als Strstrahlung bekannt und ihre maximal
zulssige Strke ist im Allgemeinen gesetzlich geregelt, in Deutschland ist
dies das Gesetz ber die elektromagnetische Vertrglichkeit von Gerten
(EMVG). Bei Gerten, die Informationen verarbeiten (PC, Drucker, Faxgert,
Modem, usw.) kann diese Strstrahlung auch die gerade verarbeiteten
Informationen mit sich fhren. Derartige informationstragende Abstrahlung
wird blostellende Abstrahlung genannt. Wird die blostellende Abstrahlung
in einiger Entfernung, z. B. in einem Nachbarhaus oder auch in einem in der
Nhe abgestellten Fahrzeug empfangen, kann daraus die Information
rekonstruiert werden. Die Vertraulichkeit der Daten ist damit in Frage gestellt.
Die Grenzwerte des EMVG reichen im allgemeinen nicht aus, um das
Abhren der blostellenden Abstrahlung zu verhindern. Hierzu mssen in
aller Regel zustzliche Manahmen getroffen werden.
Blostellende Abstrahlung kann einen Raum auf unterschiedliche Weise ver-
lassen:
- In Form von elektromagnetischen Wellen, die sich wie Rundfunkwellen
durch den freien Raum ausbreiten.
- Als leitungsgebundene Abstrahlung entlang metallischer Leiter (Kabel,
Klimakanle, Heizungsrohre).
- Durch berkoppeln von einem Datenkabel in parallel hierzu verlegte
Kabel. Auf dem Parallelkabel breitet sich die Abstrahlung aus und kann
von diesem noch in groer Entfernung abgegriffen werden.
- Als akustische Abstrahlung, z. B. bei Druckern. Die Detailinformationen
des Druckvorgangs breiten sich ber Schall beziehungsweise Ultraschall
aus und knnen mit Mikrofonen aufgenommen werden.
- In Form von akustischer berkopplung auf andere Gerte. Die
Schallwandlung in elektrische Signale erfolgt dabei durch schall-
empfindliche Gerteteile, die unter bestimmten Voraussetzungen hnlich
wie ein "Mikrofon" arbeiten knnen. Die weitere Ausbreitung erfolgt dann
entlang metallischer Leiter oder auch in Form elektromagnetischer Raum-
strahlung.
- Blostellende Abstrahlung kann auch durch eine uere Manipulation von
Gerten verursacht werden. Wird z. B. ein Gert mit Hochfrequenzenergie
bestrahlt, knnen die im Gert ablaufenden elektrischen Vorgnge die ein-
gestrahlten Wellen so beeinflussen, dass diese nun die verarbeitete Infor-
mation mit sich tragen.
In allen Fllen hat die Installation, also die Verkabelung der Gerte unter-
einander und mit dem Stromversorgungsnetz, einen wesentlichen Einfluss auf
die Ausbreitung und damit auch auf die Reichweite der Abstrahlung.
Vom BSI werden Schutzmanahmen entwickelt, welche die Gefhrdung ohne
wesentliche Kostensteigerung wirksam reduzieren. Dazu gehren:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Zonenmodell
Das Zonenmodell bercksichtigt die Ausbreitungsbedingungen fr blo-
stellende Abstrahlung bei den jeweiligen Gebude- und Gelndever-
hltnissen. Dabei wird die Abschwchung der Abstrahlung auf ihrem Weg
vom verursachenden IT-Gert zum potentiellen Empfnger messtechnisch
erfasst. Abhngig von den Gegebenheiten am Einsatzort knnen gege-
benenfalls Gerte eingesetzt werden, an denen nur geringfgige oder gar
keine Sonderentstrmanahmen durchgefhrt wurden.
- Quellenentstrung
Die Quellenentstrung bewhrt sich besonders bei der Neuentwicklung von
IT-Produkten. Hier wird die blostellende Abstrahlung bereits am Ent-
stehungsort innerhalb des Gertes unterdrckt oder so verndert, dass sie
nicht mehr auswertbar ist. Durch diese Methode kann z. B. auch der Ein-
satz kostengnstiger Kunststoffgehuse mglich werden, mit vernach-
lssigbar geringen Auswirkungen auf den Serienpreis.
- Kurzmessverfahren
Die Erarbeitung von Kurzmessverfahren und Manipulationsprfverfahren
erlaubt, auch nach Wartung, Reparatur oder mglichen unberechtigten
Zugriffen die Abstrahlsicherheit mit geringem Aufwand sicherzustellen.
- Einsatz abstrahlarmer bzw. abstrahlgeschtzter Gerte
Hersteller von PC-Bildschirmen werben hufig mit dem Begriff "abstrahl-
arm" nach MPR II, TCO oder SSI. Diese Richtlinien bercksichtigen
jedoch ausschlielich mgliche gesundheitsschdliche Auswirkungen der
Gertestrahlung. Die Messverfahren und Grenzwerte fr die Strahlung sind
daher fr den Nachweis blostellender Abstrahlung ungeeignet und
ermglichen wie auch Messungen zur elektromagnetischen Vertrglichkeit
(EMV) keine Bewertung der Sicherheit gegen unberechtigtes Mitlesen der
Daten.
Daneben werden aber auch speziell abstrahlgeschtzte IT-Systeme ange-
boten. Ein detailliertes Prfkonzept des BSI dient zur abgestuften Prfung
von IT-Gerten bzw. -Systemen. Grundgedanke dieses Konzeptes ist es,
den Umfang der Schutzmanahmen so gut wie mglich an die vom
Anwender angenommene Bedrohungslage anzupassen, um so bei mini-
miertem Kostenaufwand ein Optimum an Abstrahlsicherheit zu erzielen.
Ursprnglich wurde das Prfkonzept des BSI zum Schutz staatlicher Ver-
schlusssachen entwickelt, der Einsatz kann aber auch in der Privatwirt-
schaft sinnvoll sein, wenn Daten mit hohem Schutzbedarf bezglich Ver-
traulichkeit geschtzt werden sollen. So kann z. B. in vielen Fllen ein
nach dem Zonenmodell geprftes und fr den Einsatz in den Zonen 1-3
zugelassenes Gert (sog. "Zone 1-Gert") bereits einen hinreichenden
Schutz gegen unberechtigtes Abhren vertraulicher Daten infolge blo-
stellender Abstrahlung bieten. Ein Einsatz von kostengnstigen Zone 1-
Gerten wird daher vom BSI bei dem genannten Schutzbedarf empfohlen.
Ob ein Hersteller abstrahlgeschtzte Gerte gem dieser sog.
"TEMPEST"-Kriterien in seinem Lieferprogramm anbietet, sollte durch
eine Rckfrage beim Hersteller, beim BSI bzw. durch Einsicht in die offi-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zielle Produktbersicht BSI 7206, welche auf der Internetseite des BSI
unter dem Stichwort Publikationen verfgbar ist, geklrt werden. Dabei
gehrt zu der Aussage, dass fr ein Gert eine TEMPEST-Zulassung vor-
liegt, immer auch die Aussage des Zulassungsgrades (z. B. zugelassen fr
den Einsatz in den Zonen 1-3 gem Zonenmodell).
Weitere Informationen erhalten Sie unter:
Tel.: +49 (0) 1888 9582-502
E-Mail: ReferatIII12@bsi.bund.de
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.90 Einsatz von kryptographischen Verfahren auf

den verschiedenen Schichten des ISO/OSI-
Referenzmodells
Das OSI-Referenzmodell nach ISO
Kryptographische Verfahren knnen auf den verschiedenen Schichten des
ISO/OSI-Referenzmodells implementiert werden. Dieses Modell, welches in
Manahme M 5.13 Geeigneter Einsatz von Elementen zur Netzkopplung
dieses Handbuchs kurz erlutert wird, definiert vier transportorientierte
Schichten und drei anwendungsorientierte Schichten. Instanzen einer Schicht
in verschiedenen Systemen kommunizieren ber Protokolle miteinander. Jede
Schicht bietet der nchst hheren Schicht ihre Dienste an. Das kann neben den
blichen Kommunikationsdiensten auch ein Sicherheitsdienst sein. Welcher
Sicherheitsdienst in welcher Schicht des Schichtenmodells plaziert werden
sollte und welche Mechanismen dazu genutzt werden knnen, ist im Teil 2 der
ISO 7498 (Security Architecture) beschrieben.
Auch wenn konkrete Kommunikationssysteme, Referenzmodelle oder Proto-
kolle sich nicht immer konform zum ISO-Referenzmodell verhalten, so hilft
die Kenntnis des ISO-Referenzmodells bei der Beurteilung von Sicherheits-
funktionen von Produkten und erleichtert damit auch die systematische Erstel-
lung "sicherer" Gesamtsysteme.
Abb.: Beurteilung von Sicherheitsfunktionen von Produkten mit Hilfe der

Kenntnis des ISO-Referenzmodells
Im folgenden soll erlutert werden, welche Vor- bzw. Nachteile mit dem Ein-
satz von kryptographischen Verfahren auf den jeweiligen Schichten verbun-
den sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kryptographische Verfahren werden zur Sicherung verschiedener bei der

Kommunikation anfallender Informationen eingesetzt, also um Informationen
zu verschlsseln, mit kryptographischen Prfsummen zu versehen oder zu
signieren. Zum einen knnen die vom Benutzer zu bermittelnden Daten
gesichert werden, zum anderen aber auch Informationen, die sich beim
Informationsaustausch implizit ergeben (z. B. Verkehrsflussinformationen).
Sicherheitsbeziehungen knnen fr verschiedene Sicherheitsdienste in ver-
schiedenen OSI-Schichten gleichzeitig existieren. Oberhalb der Schicht, in der
ein Sicherheitsdienst realisiert ist, liegen die Informationen (bezglich dieses
Dienstes) ungesichert vor. Kryptographische Mechanismen (Verschlsselung,
digitale Signatur, kryptographische Prfsummen) liefern Beitrge zur
Realisierung wichtiger Sicherheitsdienste (Authentizitt, Vertraulichkeit,
Integritt, Kommunikations- und Datenursprungsnachweise).
Hierzu wird zunchst ein berblick ber die Gesichtspunkte gegeben, die fr
oder gegen den Einsatz von kryptographischen Verfahren auf den verschie-
denen OSI-Schichten sprechen:
Verwendung von kryptographischen Verfahren auf

oberen Schichten: unteren Schichten:
+: sinnvoll, wenn die Anwendungs- +: sinnvoll fr die Kopplung zweier
daten nahe der Anwendung ge- Netze, die als sicher gelten, ber
schtzt werden sollen bzw. der eine unsichere Verbindung, z. B.
"unsichere Kanal" mglichst kurz Kopplung zweier Liegenschaften
gehalten werden soll ber ffentliche Netze
+: auf jeden Fall immer dann, wenn +: zur Sicherung eines Netzes gegen
die Daten nicht auf den tieferen unbefugte Zugriffe
Schichten geschtzt werden
+: sinnvoll bei vielen, wechselnden +: immer dann, wenn Verkehrsfluss-
Kommunikationspartnern an ver- informationen geschtzt werden
schiedenen Standorten sollen, z. B. Adressinformationen
+: Benutzer knnen sie nach eigenen +: alle hherliegenden Header- und
Anforderungen einsetzen die Benutzerinformationen sind
verschlsselt
+: Absicherung nher am Benutzer +: transparent fr Benutzer, gerin-
und fr diesen erkennbarer geres Fehlbedienungsrisiko
-: hhlen Absicherung durch Fire- +: einfacheres Schlsselmanagement
walls aus
-: werden hufig fehlbedient -: Schutz nur bis in die Schicht, in der
die Sicherheitsprotokolle realisiert
sind
-: basiert hufig auf Software, -: hufig Hardware, also teuer und
kryptographische Schlssel und unflexibel
Algorithmen sind einfacher mani-
pulierbar
-: hhere Abhngigkeit vom -: bietet hufig keine Ende-zu-Ende
Betriebssystem bzw. darunter Sicherheit
liegender Hardware
Tabelle: Verwndung von kryptographischen Verfahren auf die OSI-Schichten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Ein einfaches Schlsselmanagement ergibt sich i.d.R. dann, wenn

Gruppenschlssel verwendet werden knnen, z. B. beim Aufbau von sicheren
Teilnetzen (VPNs), bei denen die Zugnge mit Kryptogerten versehen
werden.
Kryptographische Produkte fr die unteren Schichten liegen im
Anschaffungspreis meist deutlich ber solchen fr obere Schichten, dafr
werden allerdings auch weniger bentigt. Auerdem ist der Administrations-
und Implementierungsaufwand meist niedriger, da Sicherheitsdienste nicht in
verschiedensten Anwendungen implementiert werden mssen. Auch
"exotische" Anwendungen - ohne eigene Sicherheitsfunktionalitt - knnen
dadurch gesichert Daten austauschen.
In vielen Fllen bietet sich auch eine Kombination von kryptographischen
Diensten auf verschiedenen Schichten an. Dies hngt von den jeweiligen
Sicherheitsanforderungen und den Einsatzbedingungen ab, wie Kosten, Per-
formance und inwieweit entsprechende Komponenten erhltlich sind. Ent-
scheidende Faktoren sind auch die angenommenen Gefhrdungen, gegen die
die implementierten Sicherheitsdienste wirken sollen, sowie die zugrunde
liegende Systemarchitektur.
Sicherheits-Endgerte <-> Sicherheits-Koppelelemente
Sicherheitssysteme knnen als Endgert bzw. Teil eines Endgerts oder als
Koppelelement bzw. Teil eines Koppelelements ausgelegt sein.
Koppelelemente sind z. B. aktive Netzkomponenten wie Router oder
Gateways.
Im Unterschied zu Endgerten weisen Sicherheits-Koppelelemente gewhn-
lich zwei Netzschnittstellen auf, die auf einer fr dieses System typischen
Schicht ber ein Kryptomodul (Hard- oder Software) gekoppelt sind. Eine
Schnittstelle ist mit dem "sicheren" Netz verbunden (z. B. Hausnetz), die
andere Schnittstelle mit einem als "unsicher" bewerteten Netz (z. B. ffent-
liche Netze).
Sicherheits-Endgerte haben den Vorteil, dass die Sicherheitsmechanismen
gut an die Anforderungen der Anwendung angepasst werden knnen.
Typische SicherheitsEndgerte sind Kryptotelefone, Kryptofaxgerte oder
hard-/softwarebasierte Sicherheitslsungen fr PCs. Sicherheits-Endgerte
bieten i.d.R. Lsungen fr einzelne Arbeitspltze. Teilweise untersttzen diese
Lsungen lediglich einen Dienst. Die Grenzen sind hier jedoch flieend
(Telefonie ber Internet-PC, Kryptotelefon mit Dateneingang). In Endgerten
ist im Gegensatz zum Koppelelement die Wahl der Sicherheitsschicht nicht
eingeschrnkt, da Endgerte grundstzlich vollstndig sind, also ber 7
Schichten verfgen.
Sicherheits-Koppelelemente sind hufig derart leistungsfhig konstruiert, dass
sie grere Arbeitseinheiten bis hin zu ganzen Liegenschaften absichern
knnen. Dabei versuchen die Hersteller solcher Systeme mglichst viele
Dienste bzw. bergeordnete Protokolle zu untersttzen, damit eine universelle
Verwendung mglich ist. Auch die weitgehende Unabhngigkeit von den
Betriebssystemen der Endgerte liefert einen Beitrag zur universellen Ein-
satzbarkeit von Koppelelementen. Natrlich knnen auch einzelne Endgerte
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
durch Sicherheits-Koppelelemente abgesichert werden. Jedoch fhrt die

hhere Leistungsfhigkeit der Gerte hufig zu hheren Kosten. Bei
Koppelelementen handelt es sich definitionsgem um unvollstndige OSI-
Systeme. Daher ist auch die Implementierung von Sicherheitsdiensten auf die
Schichten beschrnkt, die das Koppelelement aufweist.
Auch Mischformen sind im Einsatz. Das setzt voraus, dass Sicherheits-
Endgerte und Sicherheits-Koppelelemente aufeinander abgestimmt sind,
insbesondere bezglich der verwendeten Sicherheitsmechanismen und
Sicherheitsparameter (z. B. kryptographische Schlssel).
Nutzer-, Steuer- und Managementinformationen
Ein Anwender ist hauptschlich an der bermittlung von Nutzerinformationen
an entfernte Anwender interessiert. Je nach konkretem Referenzmodell (z. B.
ISDN) werden aber zwischen den Systemen (Endgerte, Koppelelemente)
zudem Steuer-, Signalisier- und Managementinformationen zwecks
Aufbau/Abbau von Verbindungen, Aushandeln von Dienstgteparametern,
Konfiguration und berwachung des Netzes durch Netzbetreiber, usw. ber-
tragen.
Das jeweilige Netz hat dabei die Aufgabe, Benutzerinformationen unverndert
und unausgewertet zu bertragen, d. h. Benutzerinformationen mssen nur
von den Endgerten interpretiert werden knnen. Damit lassen sich diese
Informationen unabhngig von der brigen Netzinfrastruktur sichern, notfalls
sogar unter Verwendung proprietrer Sicherheitsfunktionen (geschlossene
Benutzergruppe). Steuer-, Signalisier- und Managementinformationen der
Transportschichten mssen von Netzelementen des Netzbetreibers
ausgewertet, gendert oder erzeugt werden knnen. Damit entziehen sich diese
Informationen einer vom Netzbetreiber unabhngigen Sicherung (z. B.
Verschlsselung) weitgehend. Die Sicherung dieser Informationen erfordert
neben entsprechenden Standards die vertrauensvolle Zusammenarbeit mit dem
Netzbetreiber. Bedrohungen knnen sich dadurch ergeben, dass
Sicherheitsfunktionen von Produkten falsch eingeschtzt werden. Bei der
Auswahl von Kryptogerten ist genau zu prfen, welche Informationsanteile
gesichert oder gefiltert werden. Ebenso ist im Umkehrschluss zu berprfen,
welche Informationen trotz des Einsatzes von Kryptogerten ungesichert
bleiben und in wieweit dies zu tolerieren ist.
Beispiel: Beim ISDN erfolgt die bertragung der Benutzerinformationen
i.d.R. ber die B-Kanle. Aber auch der D-Kanal, welcher primr fr die
Signalisierung genutzt wird, kann zur bertragung paketierter Daten verwen-
det werden. Ist das Ziel die Sicherung aller Benutzerdaten, so reicht im Fall
der bertragung von paketierten Daten ber den D-Kanal die Absicherung der
B-Kanle offensichtlich nicht aus.
Sicherheit in leitungsvermittelten Netzen
Bei leitungsvermittelten Netzen werden durch den Verbindungsaufbau Kanle
definierter Bandbreite eingerichtet, die den Kommunikationspartnern exklusiv
zur Verfgung stehen. Nach Einrichten der Verbindung erfolgt die ber-
tragung der Nutzdaten, anschlieend der Verbindungsabbau. Der Netzbe-
treiber kann Festverbindungen einrichten, bei denen dann der durch den Teil-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nehmer gewhnlich durchzufhrende Verbindungsauf- und -abbau entfllt.

Ein Beispiel fr ein leitungsvermitteltes Netz ist ISDN.
Durch den Verbindungsaufbau werden Nutzdatenkanle auf OSI-Schicht 1
zwischen den Kommunikationspartnern eingerichtet, die beim ISDN B-Kanle
heien. Um die Vertraulichkeit der bertragenen Nutzdaten zu gewhrleisten,
kann dieser Kanal verschlsselt werden. Soll darber hinaus der
Signalisierungskanal abgesichert werden, bei N-ISDN also der D-Kanal
(Schicht 1-3), so muss bedacht werden, dass als Gegenstellen eines Endgerts
sowohl das Endgert des Kommunikationspartners als auch Vermittlungs-
stellen des Netzbetreibers auftreten knnen. Der D-Kanal wird normalerweise
nicht verschlsselt, da hierzu besondere Anforderungen an den Netzbetreiber
zu stellen wren. In diesem Fall sollte man die berwachung und Filterung
des D-Kanals vorsehen (siehe auch M 4.62 Einsatz eines D-Kanal-Filters).
Leitungsverschlssler: Als Sonderfall muss die Verschlsselung synchroner
vollduplex Festverbindungen gesehen werden, da in diesem Fall die Vertrau-
lichkeit - auch des Verkehrsflusses - gewhrleistet werden kann. Stehen keine
Daten zur bertragung an, werden Flldaten verschlsselt, so dass auf der
Leitung immer ein kontinuierliches "Rauschen" zu sehen ist. Der Leitungs-
verschlssler stellt eine Alternative zur Verlegung geschtzter Leitungen dar.
Sicherheit in paketvermittelten Netzen
Bei paketvermittelten Netzen ist zwischen verbindungsorientierter und verbin-
dungsloser Paketvermittlung zu unterscheiden. Bei der verbindungsorien-
tierten Paketvermittlung wird whrend der Verbindungsaufbauphase eine
virtuelle Verbindung eingerichtet, wodurch der Datenpfad durch das Paketnetz
im Anschluss festgelegt ist. Datenpakete werden nach dem Verbindungs-
aufbau auf Basis der zugeordneten virtuellen Kanalnummer auf dem selben
Pfad durch das Netz geroutet. Sende- und/oder Empfngeradressen sind hierzu
nicht mehr erforderlich. Ein Beispiel hierfr ist das X.25-Netz.
Bei verbindungsloser Paketvermittlung gibt es keine Verbindungsauf und
-abbauphasen. Datenpakete werden - u. a. ausgestattet mit Quell- und Ziel-
adresse - einzeln vermittelt. Dies ist typisch fr LAN-Datenverkehr.
Die Wahl der Schicht, in der die Sicherheitsmechanismen wirken, bestimmt,
welche Informationsanteile gesichert werden. Je niedriger die gewhlte
Sicherheitsschicht, desto umfangreicher die Informationssicherung. Beim
Durchlauf der Benutzerdaten durch die Instanzen der Schichten 7 bis 1
(Sender) werden den Daten zustzliche Steuerinformationen hinzufgt. Geht
es also nicht nur um die Sicherung von Benutzerdaten, sondern auch um die
Sicherung des Verkehrsflusses, so bietet sich die Wahl einer niedrigen OSI-
Schicht an. Andererseits gilt: je niedriger die gewhlte OSI-Schicht, desto
weniger Koppelelemente (Repeater, Bridge, Switch, Router, Gateway) lassen
sich transparent berwinden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Koppelelement hchste Schicht des

Koppelelements
Repeater 1
Bridge, Layer-2-Switch 2
Router, Layer-3-Switch, X.25-Packet Handler 3
Gateway 7
Tabelle: Gegenberstellung: Koppelelement - ISO-Schicht
Sollen Sicherheitsdienste ber Koppelelemente hinweg wirken, dann sind sie
in einer Schicht zu implementieren, die oberhalb der hchsten (Teil-) Schicht
der Koppelelemente liegt. Dadurch wird sichergestellt, dass die ber-
mittlungseinrichtungen die gesicherten Informationen unverarbeitet/ uninter-
pretiert weiterleiten knnen.
Beispiele und Folgen fehlerhafter Netzkonfigurationen:
Beispiel 1: Smtliche Endgerte zweier ber Router und ffentliche Kom-
munikationsnetze gekoppelter LANs sollen zur Gewhrleistung der Vertrau-
lichkeit - insbesondere im Bereich ffentlicher Kommunikationsnetze - mit
Schicht-2-Verschlsselungskomponenten ausgestattet werden. Der Router
muss zur Weiterleitung der LAN-Datenpakete ber das ffentliche Netz die
Adressen der Schicht 3 auswerten. Da smtliche Schicht-3-Daten jedoch durch
die Schicht-2-Verschlsselung verborgen sind, kann die Auswertung der
Schicht-3-Adressen nicht erfolgreich durchgefhrt werden. Dadurch wird die
Datenbertragung verhindert. Zur Abhilfe mssen hier die Verschlsselungs-
komponenten fr Schicht 3 (obere Teilschicht) oder hher eingesetzt werden.
Beispiel 2: Ein Groteil des Schriftverkehrs einer Institution soll zuknftig
elektronisch ber X.400 (Schicht 7) abgewickelt werden. Zur Sicherung der
Datenintegritt plant die Institution den Einsatz von Schicht-4-Kryptokompo-
nenten in den Endgerten (hier PCs). Zum Zweck der Sicherung werden die
Datenpakete beim Sender auf Schicht 4 mit kryptographischen Prfsummen
versehen, welche von der zugehrigen Schicht-4-Kryptokomponente des
Empfngers geprft wird. Nur Datenpakete mit korrekten Prfsummen sollen
zugestellt werden. Falls aber nicht alle MTAs (Message Transfer Agents, also
die Vermittler fr elektronische Mitteilungen auf Schicht 7) ebenfalls mit
interoperablen Kryptokomponenten ausgestattet sind, knnen die MTAs ohne
Kryptokomponente keine gltigen Prfsummen erzeugen, so dass nachfol-
gende MTAs oder Endgerte mit Kryptokomponente die Daten laut Vorgabe
verwerfen mssen.
Aber selbst wenn smtliche genutzten MTAs ebenso wie die Endgerte mit
interoperablen Kryptokomponenten und Sicherheitsparametern ausgestattet
sind, ist die Datenintegritt nicht sichergestellt. Dann kann die abschnittsweise
Sicherung der Daten zwar gewhrleistet sein, eine Verflschung der Daten
innerhalb der MTAs ist jedoch unbemerkt mglich. Ferner knnten (je nach
Protokoll) einzelne Schicht-4-Datenpakete verloren gehen, was zu Lcken in
der Gesamtnachricht fhrt, deren Unversehrtheit eigentlich gesichert werden
sollte. Eine Abhilfe ist hier die Integrittssicherung der Daten auf Schicht 7.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wie die Beispiele zeigen, ist genau zu untersuchen, welche Netztopologie

vorliegt und welche Netzbereiche wie gesichert werden mssen, damit eine
angepasste Lsung mit den gewnschten (Sicherheits-)Merkmalen gefunden
werden kann.
Abschnittsweise Sicherheit <-> Ende-zu-Ende-Sicherheit
Benutzer von Kommunikationssystemen erwarten hufig, dass Sicherheits-
dienste durchgngig erbracht werden (Ende-zu-Ende-Sicherheit), also von der
Eingabe der Information (Daten, Sprache, Bilder, Text) am Endgert A bis zur
Ausgabe der Information an einem entfernten Endgert B. Ist kein durch-
gehender Sicherheitsdienst gewhrleistet, so existieren - abgesehen von den
beteiligten Endgerten - weitere Systeme, auf denen die Informationen unge-
sichert vorliegen. Existiert beispielsweise keine Ende-zu-Ende-Verschlsse-
lung zur Sicherung der Vertraulichkeit einer Kommunikationsbeziehung
zwischen zwei Teilnehmern, so liegen die Daten in mindestens einem weiteren
Netzelement unverschlsselt vor. Solche Netzelemente mssen lokalisiert und
durch zustzliche Manahmen abgesichert werden. Personal, welches Zugriff
auf insbesondere solche ungesicherten Netzelemente hat (z. B. Administrator),
muss entsprechend vertrauenswrdig sein. Sicherheitsdienste werden in
diesem Fall nicht durchgngig, sondern abschnittsweise erbracht. Auf die
angemessene Sicherung aller relevanten Abschnitte ist zu achten.
Mehrfache Sicherung auf verschiedenen OSI-Schichten
Gegen eine Mehrfachsicherung der zu bertragenden Informationen auf ver-
schiedenen OSI-Schichten ist nichts einzuwenden, wenn gewisse Regeln
befolgt werden, die bei standardkonformen Produkten jedoch implizit
gewhrleistet sind. Insbesondere bei der Verschlsselung sind die aus der
Schule bekannten Klammerregeln anzuwenden. So entspricht das Verschls-
seln dem ffnen einer Klammer, das Entschlsseln dem Schlieen einer
Klammer. Innerhalb der Klammer knnen nun wiederum weitere Sicher-
heitsmechanismen zur Anwendung kommen.
Nachteilig kann sich die Mehrfachsicherung dadurch auswirken, dass der
Datendurchsatz aufgrund zustzlicher Operationen reduziert wird oder dass
sich die bertragbare Nutzdatenmenge dadurch vermindert, dass zustzliche
Daten zur Erhhung der Redundanz (z. B. kryptographische Prfsummen)
bertragen werden mssen. Auch durch Daten, die vor der bermittlung ber
Kryptosysteme gesichert werden, z. B. digital signierte Dokumente, ergibt
sich implizit eine Mehrfachsicherung. Dadurch erhht sich die Sicherheit der
Datenbertragung hinsichtlich der verwendeten Sicherheitsdienste.
Oft lsst sich die Sicherheit des Gesamtsystems erst durch die Kombination
mehrerer Sicherheitsprotokolle oder Sicherheitsprodukte erreichen. Sind z. B.
anwendungsnahe Sicherheitslsungen verfgbar, deren vertrauenswrdige
Implementierung jedoch nicht (von unabhngiger Seite) berprft wurde
(z. B. Evaluierung nach ITSEC, CC) und existieren gleichzeitig vertrauens-
wrdige transportorientierte Sicherheitsprodukte zur Absicherung unsicherer
Netzabschnitte zwischen entfernten Liegenschaften, so kann durch die Kombi-
nation der Manahmen u. U. eine den Anforderungen gengende Gesamt-
Sicherheitslsung geschaffen werden. Nachteilig wirken sich dabei meist der
erhhte Administrationsaufwand und/oder erhhte Anschaffungskosten aus.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.91 Sichere Installation eines Systemmanage-

mentsystems
Die Installation eines Systemmanagementsystems erfordert eine umfangreiche
und sorgfltige Planung. Nach erfolgter Systemanalyse (siehe M 2.168),
Festlegung der Managementstrategie (siehe M 2.169) und Auswahl eines
geeigneten Managementsystems (siehe M 2.171) muss die Installation des
Produktes detailliert geplant und entsprechend umgesetzt werden. In
Abhngigkeit von der dem Management-Produkt zugrunde liegenden
Architektur ist fr das lokale Netz die konkrete Managementsystem-
konfiguration zu erstellen, die insbesondere der formulierten Manage-
mentstrategie Rechnung trgt.
Zur Installation der meisten Managementsysteme muss auf den beteiligten
Rechnern Managementsoftware installiert werden, die die Kommunikation
zwischen Managementkonsole oder -servern und dem lokalen Rechner ber-
nimmt. Oft mssen auf den zentralen Rechnern (Server oder Gateways) auch
Datenbanksysteme installiert werden, in denen die Managementinformationen
von der Managementsoftware persistent abgelegt werden. Je nach Produkt ist
hier auch die Einbindung eines schon vorhandenen Datenbanksystems mg-
lich. Generell stellt die zustzlich zu installierende Software Anforderungen
an die lokalen Ressourcen des Rechners. Daher ist bei der Planung zu beach-
ten, welche Systemressourcen lokal vorhanden sind. Unter Umstnden mssen
einzelne Systeme aufgerstet werden. Diese Kosten sollten bei der Auswahl
des Management-Produktes bercksichtigt werden.
Neben diesen Kriterien, die im wesentlichen den geregelten technischen
Ablauf des Systems garantieren sollen, ist aus Sicherheitsgesichtspunkten die
dem Managementsystem zugehrige Software und die entsprechenden Daten
in die Schutzbedarfsfeststellung gem IT-Grundschutzhandbuch (siehe
Kapitel 2) aufzunehmen und der Schutzbedarf als "hoch" bis "sehr hoch"
einzustufen. Die Kompromittierung des Managementsystems kann nicht nur
den Ausfall des gesamten Netzes nach sich ziehen; durch unbemerkte
Vernderungen am System kann vielmehr betrchtlicher Schaden entstehen,
der sehr schnell existenzbedrohende Formen annehmen kann.
Insbesondere ist bei der Installation auf folgende Punkte zu achten:
- Alle Rechner, auf denen Managementinformationen gelagert werden, sind
besonders zu sichern:
- Es sind die Manahmen gem IT-Grundschutzhandbuch Kapitel 5
und 6, je nach vorliegendem System, durchzufhren.
- Insbesondere sind die Betriebssystemmechanismen so zu konfigu-
rieren, dass auf die lokal gespeicherten Managementinformationen
nicht unberechtigt zugegriffen werden kann.
- Der Zugang zur Managementsoftware ist nur den berechtigten
Administratoren und Revisoren zu gestatten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Zutritt zu den Rechnern sollte beschrnkt werden.

- Die Kommunikation zwischen den Managementkomponenten sollte ver-
schlsselt erfolgen - sofern dies vom Produkt untersttzt wird - um zu
verhindern, dass Managementinformationen mitgehrt und gesammelt
werden knnen. Untersttzt das Produkt keine Verschlsselung, so sind
gesonderte Manahmen zu ergreifen, um die Kommunikation abzusichern
(siehe M 5.68 Einsatz von Verschlsselungsverfahren zur
Netzkommunikation).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.92 Sicherer Betrieb eines

Fr den sicheren Betrieb eines Systemmanagementsystems, welches auch aus
verschiedenen Management-Tools (siehe M 2.171 Geeignete Auswahl eines
Systemmanagement-Produktes) bestehen kann, ist die sichere Konfiguration
aller beteiligten Komponenten zu prfen und sicherzustellen (siehe auch
M 4.91 Sichere Installation eines Systemmanagementsystems). Hierzu ist es
ntig, die jeweiligen Betriebssysteme der Komponenten, die durch das
Systemmanagementsystem verwaltet werden und damit Teile des Systems in
Form von Software und/oder Daten installiert haben, entsprechend zu sichern.
Zur Absicherung gehrt dabei auch die sichere Aufstellung der Rechner, die
zentrale Aufgaben fr das Managementsystem erfllen (Managementserver,
Rechner mit Managementdatenbanken). Daneben muss fr die sichere Daten-
bertragung Sorge getragen werden (siehe M 5.68 Einsatz von Verschlsse-
lungsverfahren zur Netzkommunikation).
Auf die folgenden Punkte ist insbesondere whrend des laufenden Betriebs
eines Managementsystems zu achten:
- Im Rahmen der Fortschreibung der Systemdokumentation mssen die
durch das Managementsystem neu hinzugekommenen Hard- und Soft-
warekomponenten dokumentiert werden.
- Auch nderungen am Managementsystem selbst mssen dokumentiert
und/oder protokolliert werden.
- Die Fortschreibung gilt in gleicher Weise fr das Notfallhandbuch. Insbe-
sondere sind einerseits die Anlauf- und Recovery-Plne zu modifizieren, da
viele Standardfunktionen der verwalteten Betriebssysteme nach Einfhrung
eines Managementsystems nun nur noch mit Hilfe der Funktionen des
Managementsystems erfolgen knnen. Andererseits muss das Notfall-
handbuch aber auch Anweisungen dafr enthalten, wie das System ohne
Managementsystem (etwa bei Totalausfall zentraler Komponenten) inner-
halb kurzer Zeit in hinreichendem Mae (Notbetriebsregelung) verfgbar
gemacht werden kann (siehe auch Kapitel 3.3 Notfallvorsorge-Konzept).
- Ein Zugriff auf die Komponenten oder Daten des Managementsystems
erfolgt in der Regel ausschlielich durch das Managementsystem selbst
oder berechtigte andere Systemmechanismen (z. B. Datensicherungs-
system). Daher ist der Zugriff fr normale Benutzer zu unterbinden. Dies
gilt im Normalfall auch fr die Rolle des lokalen Administrators eines
einzelnen Rechners. Mu in Ausnahmefllen tatschlich direkt auf einem
Rechner auf die lokalen Komponenten des Managementsystems zuge-
griffen werden (z. B. bei Crashrecovery oder Neuinstallation von Kompo-
nenten, sofern das Managementsystem dies nicht im Rahmen des
Managements untersttzt), so sollte diese Berechtigung explizit und nur fr
die Durchfhrung dieser Aufgabe erteilt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Im Rahmen der Sicherheitspolitik mssen die Befugnisse festlegt sein.

Auch fr den Bereich Management ergibt sich eine Rollentrennung
Administrator und Revisor - je nach Produkt auch zwischen Administra-
toren mit unterschiedlichen Rechten (z. B. Arbeitsgruppenadministrator,
Bereichsadministrator). Es empfiehlt sich, bestimmte Rollen zu definieren
und gem diesen verschiedenen Rollen Benutzer mit entsprechenden
Berechtigungen einzurichten. Dadurch werden dem Zugreifenden lediglich
die Rechte auf Komponenten oder Daten des Managementsystems erlaubt,
die fr seine momentane Aufgabe ntig sind. Je nach Managementsystem
geschieht die Einrichtung der Benutzer im Managementsystem oder in der
Benutzerverwaltung der Rechner. Da die existierenden Systeme nicht
direkt die Definition unterschiedlicher Rollen (etwa Administrator und
Revisor) vorsehen, mssen die Rollen bestmglich durch das Einrichten
unterschiedlicher Benutzerkonten (z. B. "Administrator", "Revisor",
"RechnerAdmin", "Datenschutzbeauftragter") mit entsprechenden Berech-
tigungen nachgebildet werden. Je nach System ist diese Nachbildung der
Rollen nur unvollstndig und mit einigem Aufwand mglich, da u. U. fr
jede Systemkomponente (Dateien, Programme) die Berechtigungen fr die
einzelnen Rollen explizit vergeben und gewartet werden mssen.
- Der Zugang zur Managementsoftware ist durch sichere Passwrter zu
schtzen. Die Passwrter sollten gem Sicherheitspolitik regelmig
gendert werden.
- Funktionen der Managementsoftware, die gem Managementstrategie
nicht zum Einsatz kommen sollen, sind - wenn mglich - zu sperren.
- Die Protokollierungsdateien sind in regelmigen Abstnden auf Anoma-
lien (z. B. Ausfhrung von Funktionen, die nicht zum Einsatz kommen
sollen) zu untersuchen. Hier empfiehlt sich der Einsatz von Protokoll-
Analysatoren, die entweder in das Managementprodukt integriert oder auch
als Zusatzsoftware erhltlich sein knnen und die (meist) regelgesteuert im
Bedarfsfall Alarmmeldungen (z. B. Mail, Pager) erzeugen knnen.
- Das Managementsystem ist in Abstnden Integrittstests zu unterziehen, so
dass unberechtigte nderungen so frh wie mglich entdeckt werden
knnen. Dies gilt insbesondere fr smtliche Konfigurationsdaten des
Managementsystems.
- Wird ber das Systemmanagementsystem auch Software verteilt, so sind
auch die zu verteilenden Programmdaten regelmig auf Vernderungen zu
berprfen, um das Verteilen modifizierter Software ber das gesamte
Netz zu verhindern.
- Das Managementsystem sollte auf sein Verhalten bei einem Systemabsturz
getestet werden. Je nach Management- und Sicherheitspolitik muss ein
automatischer Neustart des Managementsystems oder lokaler Teilkompo-
nenten des Systems sichergestellt werden. Damit wird verhindert, dass
Rechner, die dem Managementsystem angeschlossen sind, lngere Zeit
nicht fr das Management zugreifbar sind (siehe auch M 6.57 Erstellen
eines Notfallplans fr den Ausfall des Managementsystems).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Beim Systemabsturz drfen die Managementdatenbanken nicht zerstrt

werden oder in einen inkonsistenten Zustand gelangen, damit vermieden
wird, dass ein mglicher Angreifer provozierte Inkonsistenzen zum Angriff
nutzen kann. Dazu muss das Managementsystem entweder auf ein Daten-
banksystem zurckgreifen, das entsprechende Recovery-Mechanismen
untersttzt, oder diese Mechanismen selbst implementieren (siehe M 2.170
Anforderungen an ein Systemmanagementsystem). Werden diese Mecha-
nismen von dem gewhlten System nicht zur Verfgung gestellt (z. B.
beim Einsatz von mehreren Management-Tools), sollten die Rechner, die
Managementinformationen speichern, maximal mglich (auch physika-
lisch) gesichert werden (siehe Kapitel 4 bis 6).
- Das Managementsystem sollte einen geeigneten Backup-Mechanismus zur
Sicherung der Managementdaten enthalten oder mit einem Backup-System
zusammenarbeiten. Beim Einspielen alter Datenbestnde aus einer Daten-
sicherung ist darauf zu achten, dass diese in der Regel manuell nachbe-
arbeitet werden mssen, um der aktuellen Systemkonfiguration zu ent-
sprechen.
- Auch mittels Backup-Verfahren gesicherte Managementdatenbestnde sind
so zu lagern, dass kein unberechtigter Dritter Zugriff darauf erlangen kann.
In der Regel sind die Daten nicht in sicherer Form auf dem
Backupdatentrger gespeichert, so dass sie von jedem, der ber das
Backup-Programme und ein entsprechendes Laufwerk verfgt, eingesehen
werden knnen.
- Die Aufteilung in Managementdomnen und deren Zustndigkeiten sollte
in regelmigen Abstnden auf Gltigkeit hin untersucht werden. Dies gilt
insbesondere fr den Fall innerbetrieblicher Umstrukturierungen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.93 Regelmige Integrittsprfung

Eine regelmige Kontrolle des Dateisystems auf unerwartete Vernderungen
hilft dabei, Inkonsistenzen zu erkennen. Dadurch knnen auch Angriffe
zeitnah entdeckt werden. Sollte tatschlich ein Angriff vorliegen, ist es
wichtig, das Vorgehen des Angreifers zu rekonstruieren. Dies dient einerseits
dazu, sicherzustellen, dass die Benutzer nicht auf verflschte Daten
zurckgreifen, andererseits dazu, verborgene Hintertren zu erkennen, die ein
Angreifer fr einen spteren Zugriff auf den Rechner installiert haben knnte.
Dazu knnen Programme genutzt werden, die kryptographische Prfsummen
ber einen Groteil der Dateien des Dateisystems berechnen. Unter Unix
bieten z. B. Programme wie tripwire oder aide diese Funktionalitt.
Vergleichbare Programme sind auch fr alle anderen verbreiteten
Betriebssysteme verfgbar, z.B. fr Windows 2000 / Windows XP das Tool
"File Checksum Integrity Verifier" (FCIV.EXE), das von Microsoft im
Internet kostenlos zur Verfgung gestellt wird.
Tripwire und hnliche Programme knnen jede Vernderung am Dateisystem
feststellen, da die Prfsummen bei einer Vernderung nicht mehr
bereinstimmen. Dabei testen sie meist nicht nur, ob die Datei selbst
modifiziert wurde, sondern auch eine Vernderung der Zugriffsrechte oder ein
Lschen mit anschlieendem Zurckspielen wird festgestellt. Mit einer
speziellen Einstellung kann in vielen Fllen auch ein nur lesender Zugriff auf
die Datei bemerkt werden.
Neben dem Dateisystem sollte es auch mglich sein, weitere wichtige
Elemente der Systemkonfiguration (beispielsweise unter Windows die
Registry) einer Integrittsprfung zu unterziehen.
Um zu verhindern, dass das Programm oder die Prfsummendatei von einem
Angreifer verflscht werden knnen, sollten sich diese auf einem Datentrger
befinden, der wahlweise nur einen lesenden Zugriff gestattet. Allerdings muss
die Prfsummendatei bei Vernderungen am Dateisystem ebenfalls gendert
werden, so dass sich bei kleinen Dateisystemen Disketten, bei greren
Wechselplatten empfehlen.
Eine Integrittsprfung sollte regelmig, beispielsweise jede Nacht,
durchgefhrt werden. Eine Benachrichtigung ber das Ergebnis sollte, auch
wenn keine Vernderungen festgestellt wurden, automatisch per E-Mail an
den Administrator erfolgen.
- Welche Integrittschecker werden eingesetzt?
- Wie hufig werden die Ergebnisse der Integrittschecker geprft?
- Wie sind die Prfsummendatei und das Programm selbst vor
Manipulationen gesichert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.94 Schutz der WWW-Dateien

Die Dateien und Verzeichnisse auf einem Webserver mssen gegen unbefugte
Vernderungen, aber auch - je nach Sicherheitsanforderungen - gegen unbe-
fugten lesenden Zugriff geschtzt werden. Werden Inhalte auf dem Webserver
dynamisch erzeugt, so gilt dies zustzlich und ganz besonders fr die Pro-
gramme (Skripte oder Server-Erweiterungen), die dafr verwendet werden.
Generelle Aspekte
Generell muss zwischen zwei verschiedenen Aspekten unterschieden werden,
nmlich dem Schutz vor unbefugtem Zugriff lokaler Benutzer und dem Schutz
vor unbefugtem Zugriff von auen ber das WWW.
Schutz vor unbefugten Vernderungen
Auf vielen Webservern ndern sich nur die Protokolldateien stndig, alle
anderen Dateien sind statisch. Dies trifft insbesondere auf Systemprogramme
und die WWW-Seiten zu. WWW-Seiten werden zwar regelmig aktualisiert,
sollten aber nicht auf dem Webserver selber bearbeitet werden.
Die Schreib- und Leserechte der WWW-Dateien sollten als lokale Dateien nur
berechtigten Benutzern Zugriff erlauben. Daher sollte bereits bei der Planung
des Webangebots ein Benutzer- und Rollenkonzept erstellt werden (siehe auch
M 2.173 Festlegung einer WWW-Sicherheitsstrategie).
Um sicherzustellen, dass keine Dateien auf dem Webserver unbemerkt abge-
ndert werden knnen, knnen ber alle statischen Dateien und Verzeichnisse
Prfsummen gebildet werden, z. B. mit einem Programm wie tripwire, siehe
auch M 4.93 Regelmige Integrittsprfung. Diese sollten dann regelmig
berprft werden.
Um zu verhindern, dass WWW-Dateien berhaupt von Unbefugten gendert
werden knnen, knnen statische Daten auf einem schreibgeschtzten Spei-
chermedium (z. B. CD-ROM oder Festplatte mit Schreibschutz) gespeichert
werden.
Falls das Webangebot nicht nur aus statischen HTML-Dateien besteht, son- Sichere Programmierung
eigener serverseitiger
dern bestimmte Inhalte dynamisch erzeugt werden, so mssen die dazu be- Programme
nutzten Programme (beispielsweise CGI-Skripte, Java Server Pages) beson-
ders sorgfltig programmiert werden, um zu verhindern, dass auf diesem Weg
ein unbefugter Zugriff oder gar eine Kompromittierung des Servers erfolgen
kann.
Auf dem Server mssen solche Programme vor unbefugtem Zugriff geschtzt Schutz von CGI-Skripten,
Programmen und Konfi-
werden. Nur die Benutzer oder Benutzergruppen, die unbedingt Zugriff auf gurationsdateien
diese Programme oder Skripte brauchen (etwa Entwickler oder Administrato-
ren), drfen eine Schreibberechtigung haben. Normalerweise drfen die Pro-
gramme nicht fr den Benutzer schreibbar sein, unter dessen Kennung der
Webserver-Prozess ausgefhrt wird. Fr normale Benutzer sollten insbeson-
dere Skripte nicht lesbar sein, da diese eventuell sensitive Informationen wie
Authentisierungsdaten fr den Zugriff auf Datenbanken enthalten knnen.
Gleiches gilt fr eventuell vorhandene Konfigurationsdateien.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schutz vor unbefugtem Zugriff ber das Internet

Der Zugriff ber das WWW auf Dateien oder Verzeichnisse eines Webservers
kann auf verschiedene Arten gesteuert werden.
Welche Arten der Zugriffssteuerung untersttzt werden und wie diese imple-
mentiert sind hngt vom verwendeten Serverprodukt ab. Die folgenden Mg-
lichkeiten sind verbreitet und werden von den meisten Webservern und
Clients untersttzt.
Authentisierung von Clients ber IP-Adressen
Der Zugriff auf WWW-Dateien kann bei vielen Servern auf frei whlbare IP-
Adressen, Teilnetze oder Domnen beschrnkt werden. Die Authentisierung
ber numerische IP-Adressen bietet nicht den Schutz kryptographischer Ver-
fahren, da sie ber einen auf IP-Spoofing basierenden Angriff unwirksam
gemacht werden kann. Bei IP-Spoofing flscht ein Angreifer IP-Pakete, um
vorzugeben, von einem vertrauenswrdigen IT-System zu kommen (siehe
G 5.48 IP-Spoofing). ber eine Firewall kann jedoch verhindert werden, dass
Externe vortuschen knnen, Interne zu sein. Wird der Zugriff nicht auf nu-
merische IP-Adressen oder Teilnetze sondern auf bestimmte Rechnernamen
oder Domainnamen beschrnkt, ist auerdem die Gefhrdung durch DNS-
Spoofing (siehe G 5.78 DNS-Spoofing) zu betrachten.
Wenn der WWW-Browser ber einen Proxy-Server auf den Webserver zu- Problem mit Proxy-
Servern
greift, ist zu bedenken, dass der Webserver nur die IP-Adresse des Proxy er-
fhrt. Ein Proxy kann aber nur dann als vertrauenswrdig angesehen werden,
wenn alle IT-Systeme und Benutzer, die hinter ihm verborgen sind, ebenfalls
vertrauenswrdig sind.
Wenn der Zugriff auf WWW-Dateien auf vorgegebene IP-Adressen, Teilnetze
oder Domnen beschrnkt wird, kann es daher sinnvoll sein, diese zustzlich
mit einem Passwort zu schtzen.
Passwortschutz
Eine weitere Mglichkeit der Zugriffssteuerung, die in praktisch allen Web-
servern implementiert ist, stellt der Schutz ber Benutzernamen und Pass-
wrter dar. Der Benutzer gibt beim erstmaligen Zugriff auf ein entsprechend
geschtztes Verzeichnis in seinem Browser einen Benutzernamen und ein
Passwort an, das zum Zugriff auf die entsprechende Ressource berechtigt.
ber das Protokoll HTTP lsst sich ein Passwortschutz (Benutzer-Authentisie-
rung) auf verschiedene Arten realisieren, die sich im Bezug auf Implementie-
rungsaufwand und Sicherheit unterscheiden.
In Abhngigkeit von den Sicherheitsanforderungen muss eine geeignete Me-
thode zur Benutzer-Authentisierung ausgewhlt werden. Bei hheren Sicher-
heitsanforderungen sollte SSL zur Verschlsselung der Datenbertragung und
gegebenenfalls auch zur Benutzer-Authentisierung ber Client-Zertifikate
eingesetzt werden. Nheres ist in M 4.176 Auswahl einer Authentisierungs-
methode fr Webangebote beschrieben, Informationen zu SSL finden sich in
M 5.66 Verwendung von SSL.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Dateiverschlsselung
Eine weitere Mglichkeit zum Schutz von WWW-Dateien ist es, Dateien ver-
schlsselt auf einem Webserver abzulegen, so dass nur diejenigen die Daten
lesen knnen, die im Besitz des richtigen kryptographischen Schlssels sind.
Dieses Vorgehen bietet zustzlich den Schutz vor unbefugtem lokalem
Zugriff, verlangt allerdings ein entsprechendes, unter Umstnden aufwendi-
ges, Schlsselmanagement.
Kontrollfragen:
- Wie werden die WWW-Dateien gegen unbefugten lokalen Zugriff ge-
schtzt?
- Sind CGI-Skripte und Konfigurationsdateien besonders geschtzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.95 Minimales Betriebssystem

Rechner in einem sicherheitskritischen Umfeld sollten so konzipiert sein, dass
sie mglichst wenig Angriffspunkte bieten. Da heutige Betriebssysteme
standardmig viele Netzdienste bereitstellen, reicht fr den Betrieb eines
sicheren Servers ein gut konzipierter Serverdienst (z. B. ein SSL-basierter
Webserver) nicht aus. Vielmehr muss auch das Betriebssystem abgesichert
werden, da ansonsten ber eine Schwachstelle im Betriebssystem die
Sicherheitsfunktionen des Serverdienstes umgangen werden knnten. Ein
sogenanntes minimales Betriebssystem zeichnet sich dadurch aus, dass es im
Idealfall keinen einzigen Netzdienst zur Verfgung stellt. Ein potentieller
Angreifer kann also eine Schwachstelle in einem Netzdienst dieses
Betriebssystems nicht ausnutzen. Und sollte ein Angreifer doch durch eine
Schwachstelle Zugriff auf den Rechner bekommen haben, so wird er durch
das Minimalsystem weiter behindert. Je weniger Programme ein Angreifer auf
einem Zielrechner vorfindet, desto schwieriger wird es fr ihn, weitere
Schwachstellen in dem Zielrechner zu finden bzw. auszunutzen. Auerdem
erleichtert dies die Pflege eines Servers sehr stark, da die Patches bzw. Service
Packs fr Diensteprogramme nicht mehr eingespielt werden mssen, wenn
diese nicht vorhanden sind.
Im folgenden wird die Konfiguration eines Betriebssystems anhand eines
Internet-Servers beschrieben, da hier im allgemeinen sehr hohe
Sicherheitsanforderungen an das Betriebssystem gestellt werden mssen.
Ein Internet-Server hat meist nur eine einzige Aufgabe: stabil eine bestimmte
Anzahl von Diensten (z. B. die Bereitschaft, E-Mail entgegenzunehmen)
anderen Rechnern zur Verfgung zu stellen. Das zugrunde liegende
Betriebssystem sollte keine weiteren Dienste anbieten. Deshalb sollte bei der
Installation eines Internet-Servers folgendes Vorgehen eingehalten werden:
1. Grundinstallation des Betriebssystems
Kann man bei der Installation den Umfang der zu installierenden Pakete
beeinflussen, so sollten schon hier nur die notwendigen Pakete eingespielt
werden. Die Notwendigkeit bestimmter Pakete ist allerdings nicht immer
zu erkennen, so dass zumindest die offensichtlich berflssigen Pakete
nicht eingespielt werden sollten.
2. Abschalten nicht bentigter Programme
Beim Start eines Rechners werden eine Vielzahl von Programmen
automatisch gestartet. Einige dieser Programme sind fr einen
Internet-Server vllig berflssig und sollten deaktiviert werden. Die
Deaktivierung kann durch das Verhindern des automatischen Starts
erfolgen (Startskripte unter Unix, Autostart und Dienstemanager unter
Windows NT) und durch zustzliches Lschen der entsprechenden
Programme. Aus Grnden der Sicherheit wird das Lschen empfohlen, da
dann ein Angreifer die Dienste nicht wieder reaktivieren kann. Allerdings
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ist es manchmal sehr schwierig, alle zu einem bestimmten Dienst

gehrigen Dateien zu finden und zu lschen, so dass im Zweifel das
Lschen unterbleiben sollte.
3. Konfiguration der Netzparameter
Falls dies nicht schon bei der Installation geschehen ist, mssen die
Netzparameter des Internet-Servers eingestellt werden. Relevant fr die
Sicherheit des Internet-Servers sind unter anderem die Wahl eines Default
Gateways und eines Domain Name Servers. Findet beispielsweise die
Kommunikation des Internet-Servers mit dem Internet ber einen Proxy
(siehe M 2.73 Auswahl eines geeigneten Firewall-Typs) statt, so ist ein
Default Gateway berflssig. Ohne ein Default Gateway ist eine direkte
Antwort vom Internet-Server ins Internet nicht mglich, so dass bei
Umgehung des Proxies keine Kommunikation, d. h. auch kein Angriff,
stattfinden kann. Auch DNS ist fr einen Internet-Server hufig berflssig
und sollte mglichst vermieden werden, da dies einen direkten
Kommunikationskanal zum Betriebssystem ermglicht (siehe M 4.96).
Zustzlich gibt es noch eine Vielzahl von Parametern, die den sogenannten
TCP/IP-Stack direkt beeinflussen, z. B. die maximale Gre von IP-
Paketen. Diese Parameter sind extrem stark vom jeweiligen Betriebssystem
abhngig, so dass hier nur das Abschalten von IP-Forwarding erwhnt
werden kann. Weitere nderungen knnten beispielsweise die Stabilitt
gegenber fehlerhaften IP-Paketen oder aber auch den Netzdurchsatz
erhhen.
4. Abschalten nicht bentigter Netzdienste
Einige bentigte Diensteprogramme stellen eine Vielzahl weiterer Dienste
bereit (insbesondere ist hier der inetd unter Unix gemeint). Die
entsprechenden Konfigurationsdateien sind auf die notwendigen
Netzdienste einzuschrnken (siehe auch M 5.16 bersicht ber
Netzdienste).
5. Installation von Sicherheitsprogrammen
Das Betriebssystem sollte um zustzliche Sicherheitsprogramme erweitert
werden, falls diese nicht schon Teil des Betriebssystems sind. Insbesondere
sinnvoll sind ein Integrittsprfprogramm (siehe M 4.93 Regelmige
Integrittsprfung) und ein Softwarepaketfilter (bei Windows NT schon
enthalten). Empfehlenswert sind zustzlich Programme zur Virensuche und
zur Auswertung der Protokolleintrge. Ist eine Fernadministration des
Internet-Servers gewnscht, so muss ein entsprechendes Sicherheits-
produkt installiert werden, z. B. der Secure Shell Daemon (siehe M 5.64),
und regelmig die Sicherheit des Systems berprft werden (siehe auch
M 4.26 Regelmiger Sicherheitscheck des Unix-Systems).
6. Konfiguration und berprfung der Netzdienste
Idealerweise stellt ein minimales Betriebssystem keinen einzigen
Netzdienst zur Verfgung und ist somit von auen nicht angreifbar. Gerade
in greren Netzen ist dieses Vorgehen aufgrund der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Administration nicht mehr praktikabel, so dass ein Fernzugang notwendig

ist. Ob der Internet-Server Dienste bereitstellt, kann sowohl unter Unix als
auch Windows NT mit dem Befehl netstat -a berprft werden. Jeder der
aufgelisteten Dienste sollte in seiner Konfiguration so eingeschrnkt
werden, dass nur berechtigte Rechner auf ihn zugreifen knnen (z. B. ist
der Fernzugang zum Internet-Server auf die Rechner des
Netzmanagements einzuschrnken).
7. Lschen nicht mehr bentigter Programme
Sobald die Installation eines minimalen Betriebssystems abgeschlossen ist,
sollten verschiedene Programme gelscht werden, die einem potentiellen
Angreifer hilfreich sein knnten. Insbesondere sind eventuell vorhandene
Compiler zu entfernen, da diese einem Angreifer ein wertvolles Hilfsmittel
sein knnten. Auerdem sind Compiler auf Internet-Servern auch deshalb
nicht sinnvoll, da diese Rechner Produktionsmaschinen sind und
Programmentwicklung und Tests auf anderen Rechnern durchgefhrt
werden sollten. Ebenfalls denkbar ist das Lschen aller Editoren, was
einem Angreifer die Manipulation von Konfigurationsdateien sehr stark
erschweren wrde. Allerdings ist dann auch die Administration
komplizierter. Bei nderungen an Konfigurationsdateien muss dann
jeweils wieder ein Editor installiert werden oder aber, und dies ist
empfehlenswert, die Konfigurationsdateien mssen auf einem anderen
Rechner editiert und dann berspielt werden.
Ein minimales Betriebssystem sollte natrlich kein Selbstzweck sein. Fr
einen Internet-Server muss selbstverstndlich noch der eigentliche Server-
dienst installiert werden. Ob dies am Ende der obigen Liste geschieht oder
beispielsweise zwischen den Punkten 6 und 7 oder auch direkt nach Punkt 1,
hngt von der jeweiligen Installation ab. Problematisch wird es, wenn die
Installation wegen fehlender Betriebssystempakete fehlschlgt, da man dann
die fehlenden Pakete suchen und selber nachinstallieren muss. Besser wre es,
der Hersteller des Serverdienstes gbe die Betriebssystemabhngigkeiten an,
so dass das Minimalsystem von Anfang an darauf ausgerichtet werden knnte.
Auch ein mit einem Minimalsystem konfigurierter Rechner ist nicht gnzlich
vor Angriffen geschtzt. Die wahrscheinlichste Ursache fr einen
erfolgreichen Angriff ist sicherlich der Serverdienst, aber auch das
Minimalsystem selber ist noch angreifbar, insbesondere nmlich der TCP/IP-
Stack, der die Netzpakete zur Applikation weiterleiten muss. Nahezu alle
bisher bekannt gewordenen Angriffe gegen den TCP/IP-Stack betrafen
allerdings nur die Verfgbarkeit, indem die betroffenen Rechner abstrzten,
d. h. ein Eindringen in Rechner ist noch nicht beobachtet worden. Um auch
diese Gefahr weiter zu verkleinern, sollte auch M 4.98 Kommunikation durch
Paketfilter auf Minimum beschrnken umgesetzt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.96 Abschaltung von DNS

Ein Internet-Server braucht normalerweise kein DNS (Domain Name System),
um Informationen zur Verfgung zu stellen, es sei denn, ber ihn wird die E-
Mail versandt, wovon aber abzuraten ist (siehe dazu auch M 4.97 Ein Dienst
pro Server). So wird bei den meisten WWW-Servern DNS nur dazu
verwendet, in den jeweiligen Protokolldateien Rechnernamen statt IP-
Adressen einzutragen. Diese Umwandlung von IP-Adressen zu Rechnernamen
knnte auch spter bei der Analyse der Protokolldateien durchgefhrt werden.
Zwar ist dann der Umgang mit den Protokolldateien etwas umstndlicher, aber
die Vertrauenswrdigkeit der Protokolldaten steigt. Die Zuordnung zwischen
einer IP-Adresse und einem Rechnernamen ist nmlich weder eindeutig noch
statisch. Ein Verzicht auf DNS gibt zustzlich Schutz vor DNS-Spoofing
(siehe M 5.59 Schutz vor DNS-Spoofing) und erhht hufig die Performance
des Internet-Servers.
Folgendes Szenario zeigt mgliche negative Auswirkungen:
Ein Angreifer verfge ber eine eigene Domain mit einem Test-PC. Dieser
Test-PC ist gleichzeitig auch DNS-Server fr diese Domain. Mit dem Test-PC
baut er eine Verbindung zu einem Internet-Server auf. Der Internet-Server
kennt am Anfang der Verbindungsanfrage nur die IP-Adresse des Test-PCs
und versucht, sich ber DNS den Rechnernamen des Test-PCs zu verschaffen.
Zu diesem Zweck muss das Betriebssystem eine Verbindung mit einem DNS-
Server aufnehmen, der sich wiederum die Daten von dem Test-PC holen
muss, da dieser der DNS-Server der Angreifer-Domain ist. Anstatt nun dem
DNS-Server des Internet-Servers zu antworten, kann der Angreifer nun auch
direkt eine beliebige Antwort zum Internet-Server selber schicken (unter
Verwendung von IP-Spoofing, siehe G 5.78). Auf diese Weise kann der
Angreifer nicht nur Daten zu dem eigentlichen DNS-Server schicken, sondern
auch direkt zum Internet-Server. Eventuelle Fehler in dessen Betriebssystem
knnten so ausgenutzt werden.
Hinweis: Soll beispielsweise der Zugriff auf einen WWW-Server nur einer
bestimmten Domain erlaubt sein, z. B. nur *.de, so kann allerdings nicht auf
DNS verzichtet werden. Jedoch ist ein solcher Zugriffsschutz sehr schwach
und daher nicht empfehlenswert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.97 Ein Dienst pro Server

Viele Schwachstellen in IT-Systemen sind einzeln nicht fr einen potentiellen
Angreifer ausnutzbar. Hufig wird erst durch die Kombination von
Schwachstellen ein erfolgreiches Eindringen in einen Rechner mglich. Eine
Empfehlung fr den Betrieb von sicheren Servern ist deshalb: Verschiedene
Dienste gehren auf verschiedene Rechner!
Auf einem Minimalsystem (siehe auch M 4.95 Minimales Betriebssystem)
sollte deshalb nur ein einziger Dienst aufgesetzt werden, also beispielsweise
entweder ein WWW-Server oder ein E-Mailserver. Auerdem sind einzelne
Dienste auch unterschiedlich in ihrer Sicherheitseinstufung. So ist ein
erfolgreiches Eindringen in einen WWW-Server unter Umstnden sehr
rgerlich, insbesondere wenn der Angreifer die extern verfgbaren WWW-
Seiten abndert. Zugriff auf interne Informationen ist dem Angreifer hierdurch
aber nicht mglich. Ist der WWW-Server aber gleichzeitig der E-Mailserver,
so kann der Angreifer unter Umstnden den gesamten E-Mail-Verkehr
mitlesen, was mglicherweise viel schlimmere Auswirkungen hat.
Die Aufteilung kann sogar noch verstrkt werden, indem fr einen einzelnen
Dienst verschiedene Aufgaben auf unterschiedliche Rechner verteilt werden.
So knnte es beispielsweise einen E-Mailserver A geben, der E-Mails aus dem
Internet annimmt und in das interne Netz weiterleitet, und einen anderen E-
Mailserver B, der E-Mails aus dem internen Netz an das Internet weiterleitet.
Da die Kommunikationsaufnahme aus dem Internet nur mit dem E-Mail-
server A mglich ist, kann ein Angreifer auch nur diesen attackieren. Der E-
Mailserver A darf selber keine E-Mails in das Internet verschicken, deshalb
kann dieser Rechner auch nicht fr E-Mail-Spamming missbraucht werden.
Eine Aufteilung verschiedener Dienste auf unterschiedliche Rechner hat unter
anderem folgende Vorteile:
- Leichtere Konfiguration der einzelnen Rechner
- Einfachere und sicherere Konfiguration eines vorgeschalteten Paketfilters
- Erhhte Widerstandsfhigkeit gegenber Angriffen
- Erhhte Ausfallsicherheit
Eine eventuelle negative Auswirkung wie erhhte Hardware-Kosten fr die
Anschaffung mehrerer Rechner sollte dadurch ausgeglichen werden knnen,
dass die einzelnen Rechner weniger Leistung erbringen mssen und dadurch
in der Summe bei gleicher Performance nicht teurer als ein besonders
leistungsfhiger Rechner sein mssen. Auch muss der Administrations-
aufwand nicht zwangslufig mit der Anzahl der Rechner steigen, da eine
einfachere Konfiguration der einzelnen Rechner fr Zeitersparnis sorgt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.98 Kommunikation durch Paketfilter auf Minimum

beschrnken
Paketfilter sind IT-Systeme mit spezieller Software, die die Informationen der
unteren Schichten des OSI-Modells filtern und entsprechend spezieller Regeln
Pakete weiterleiten oder abfangen (siehe M 2.74 Geeignete Auswahl eines
Paketfilters).
Die Konfiguration eines Paketfilters, der zum Schutz von Internet-Servern
eingesetzt wird, sollte sehr restriktiv sein, um die Widerstandsfhigkeit gegen
Angriffe zu maximieren. Zwar sollte ein gut konfigurierter Internet-Server
(siehe M 4.95) sich selbst vor Angriffen schtzen knnen, jedoch ist die Soft-
ware eines Internet-Servers viel komplexer und fehleranflliger als die eines
auf Sicherheit konzipierten Paketfilters. Der Paketfilter sollte nur diejenigen
Kommunikationskanle durchlassen, die fr die Funktion der Internet-Server
notwendig sind. Insbesondere ist nicht nur die Kommunikation zu kontrollie-
ren, die vom Internet zum Internet-Server initiiert wird, sondern auch die
Kommunikation, die der Internet-Server zum Internet hin aufbauen darf. Fr
viele Angriffe ist es eine notwendige Voraussetzung, dass der angegriffene
Rechner neue Verbindungen zum Internet hin aufbauen kann. Ist dies nicht
mglich, so sind auch viele Angriffe nicht erfolgreich. So war 1997 ein
Angriff auf News-Server sehr "beliebt", bei dem sich der Angreifer ber einen
Fehler in einem News-Daemon per E-Mail wichtige Systeminformationen
zuschicken lassen konnte. Htten die angegriffenen Rechner nicht die Berech-
tigung zum Verschicken von E-Mails gehabt, so htte der Angreifer auch
keine Rckmeldung bekommen. Der Angriff wre nicht erfolgreich gewesen.
Im folgenden werden einige Beispiele fr die Konfiguration von Paketfiltern
fr verschiedene Internet-Server dargestellt.
1. WWW-Server:
Internet darf auf Port 80 des WWW-Servers TCP
WWW-Server darf ins Internet von Port 80 TCP/ack, sonst nichts!
2. News-Server:
Newsfeed-Server drfen auf Port 119 des News-Servers TCP
News-Server darf von Port 119 auf Newsfeed-Server TCP/ack
News-Server darf auf Port 119 der Newsfeed-Server TCP
Newsfeed-Server drfen von Port 119 auf den News-Server TCP/ack
3. E-Mailserver (Provider stellt E-Mail-Gateway zur Verfgung):

E-Mailserver des Providers darf auf Port 25 des E-Mailservers TCP
E-Mailserver darf von Port 25 auf E-Mailserver des Providers TCP/ack
E-Mailserver darf auf Port 25 des E-Mailservers des Providers TCP
E-Mailserver des Providers darf von Port 25 auf E-Mailserver TCP/ack
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
4. E-Mailserver (eigenes Verschicken ins Internet):

Internet darf auf Port 25 des E-Mailservers TCP
E-Mailserver darf von Port 25 ins Internet TCP/ack
E-Mailserver darf auf Port 25 im Internet TCP
Internet darf von Port 25 auf den E-Mailserver TCP/ack
Werden nur diese Regeln implementiert, ist eine Kommunikationsaufnahme
aus dem Internet nur auf die freigegebenen Dienste beschrnkt. Knnen
zustzlich die Kommunikationspartner noch weiter eingeschrnkt werden
(siehe obige Beispiele 2 und 3), so kann ein Angreifer gar keine direkte
Verbindung zu dem Internet-Server aufbauen.
Hinweis: Obige Regeln knnen bewirken, dass der Internet-Server nicht von
jedem Rechner aus erreicht werden kann, da ICMP nicht durchgelassen wird.
Deshalb empfiehlt es sich, den ICMP Subtype icmp unreachable vom Internet
hin zum Internet-Server durchzulassen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.99 Schutz gegen nachtrgliche Vernderungen von

Informationen
Verantwortlich fr Umsetzung: Administrator, Benutzer
Dateien, die an Dritte weitergegeben werden, knnen von diesen im
allgemeinen auch weiterbearbeitet werden. Dies ist nicht immer im Sinne des
Erstellers. Daher wre ein Schutz gegen nachtrgliche Vernderungen,
auszugsweise Weitergabe oder Verarbeitung wnschenswert.
Hufig steht man vor dem Problem, dass Informationen ber das Internet oder
andere Netze Dritten zwar zur Verfgung gestellt, aber nicht hundertfach
ausgedruckt oder nahtlos in andere Werke integriert werden sollen.
Hierzu gibt es verschiedene Lsungen, die teilweise auch miteinander
kombiniert werden knnen. Beispiele hierfr sind:
- Die Verwendung von digitalen Signaturen, um unbemerkte nderungen an
Dateien zu verhindern (siehe auch M 4.34 Einsatz von Verschlsselung,
Checksummen oder Digitalen Signaturen oder M 3.23 Einfhrung in
kryptographische Grundbegriffe).
- Das Hinzufgen von Copyright-Vermerken zu WWW-Informationen oder
Dateien. Diese knnen wie folgt lauten: "Das Werk einschlielich aller
seiner Teile ist urheberrechtlich geschtzt. Jede Verwertung auerhalb der
engen des Urheberrechtsgesetzes ohne Zustimmung des Autors ist
unzulssig und strafbar." sowie "Copyright () 7/1999 by BSI".
- Die Verwendung von Dateiformaten, die nachtrgliche nderungen bzw.
auszugsweise Weiterverarbeitung erschweren. Hierfr kann z. B. Postscript
genutzt werden oder die Sicherheitseigenschaften von
Anwendungsprogrammen, z. B. bei PDF-Dateien.
PDF-Dokumente knnen bei der Erstellung mit Zugriffsbeschrnkungen
versehen werden. So kann z. B. das ffnen, Drucken oder Kopieren von
PDF-Dateien eingeschrnkt werden.
Mit Acrobat Exchange, also der Anwendung, mit der PDF-Dateien erstellt
und nachbearbeitet werden knnen, ist die Vergabe von zwei Arten von
Passwrtern mglich. Die einen werden zum ffnen des Dokuments, die
anderen zum ndern der Sicherheitsattribute bentigt. Gegen unbefugtes
ffnen geschtzte PDF-Dokumente werden dabei mit RC4 verschlsselt.
ber die Sicherheitsattribute knnen folgende Funktionen eingeschrnkt
werden:
- Drucken
- ndern des Dokuments
- Text oder Graphik auswhlen
- Notizen und Formularfelder hinzufgen oder ndern
So knnen sehr einfach die Rechte beschrnkt werden, so dass niemand mit
Cut and Paste die Inhalte einer Verffentlichung bernehmen kann. Wenn
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
im Extremfall sogar das Ausdrucken verhindert wird, kann die Datei nur
online gelesen werden.
Leider bietet dies nur einen rudimentren Schutz, da PDF-Dateien nmlich
auch mit Programmen geffnet werden knnen, die diese
Sicherheitsattribute ignorieren. Solange z. B. Drucken erlaubt wird, kann
das Dokument sogar jederzeit wieder in eine PDF-Datei ohne jegliche
Einschrnkungen verwandelt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.100 Sicherheitsgateways und aktive Inhalte

Eines der grten Probleme bei der Konzeption eines Sicherheitsgateways ist
die Behandlung der Probleme, die durch die bertragung aktiver Inhalte zu
den Rechnern im zu schtzenden Netz entstehen. Derzeit existieren noch keine
brauchbaren Programme, die eine hnlich wirksame Erkennung von
Schadfunktionen in ActiveX-Controls, Java-Applets oder Scripting-
Programmen ermglichen, wie sie im Bereich der Computer-Viren mglich
ist.
Die Gre der Gefhrdung, die von aktiven Inhalten fr die Rechner im zu
schtzenden Netz ausgeht, lsst sich anhand des folgenden Beispiels
darstellen: Ein Java-Applet bzw. der Browser darf gem der Java-
Spezifikationen eine Netzverbindung zu dem Server aufbauen, von dem es
geladen worden ist. Diese zur Zeit noch recht wenig benutzte Mglichkeit ist
eine zentrale Voraussetzung, wenn Netz-Computer (NC) oder hnliches
eingesetzt werden sollen, die auch ohne spezielle Initiierung durch den
Anwender Programme vom Server laden mssen. Um diese Eigenschaft trotz
der Verwendung eines Paketfilters vollstndig untersttzen zu knnen, mssen
sehr viel mehr Ports freigeschaltet werden oder es muss ein dynamischer
Paketfilter eingesetzt werden. Ist das der Fall, knnen Java-Applets verwendet
werden, um kaum zu kontrollierende IP-Verbindungen aufbauen zu knnen.
Die Kontrolle aktiver Inhalte kann auf verschiedene Weise geschehen:
1. Zentrale Filterung der aktiven Inhalte auf dem Sicherheitsgateway
Smtliche als schdlich eingestuften Inhalte werden von einer Komponente
des Sicherheitsgateways (in der Regel vom ALG) gefiltert, so dass keine
potenziell schdlichen Programme mehr auf den Client-Rechnern eintreffen.
Aktive Inhalte werden ber spezielle Tags innerhalb einer HTML-Seite
eingebunden. In der Regel werden aktive Inhalte anhand der entsprechenden
Tags aus einer HTML-Seite erkannt und gelscht, oder sie werden durch einen
Textbaustein ersetzt, der dem Anwender einen Hinweis ber die Tatsache der
Filterung gibt. Das Problem besteht dabei darin, dass wegen der komplexen
Mglichkeiten der aktuellen HTML-Spezifikation oft nicht alle zu lschenden
Tags von den Sicherheitsproxies erkannt werden.
Weiterhin ist problematisch, dass beispielsweise Java-Applets nicht
notwendigerweise als Datei mit der Endung .class verschickt werden mssen.
Stattdessen knnen auch komprimierte Dateien eingesetzt werden, die z. B.
die Endung .jar (Java-Archive) haben. Das bedeutet, dass ein Java-Filter auch
alle von den verwendeten Browsern untersttzten Dateiendungen fr Java-
Dateien kennen muss. Zustzliches Schadenspotential resultiert auch aus der
Mglichkeit, JavaScript aus Java heraus auszufhren. hnliche Probleme
existieren im Zusammenhang mit Flash-Objekten, .NET Assemblies und
anderen aktiven Inhalten.
Es sollte unbedingt beachtet werden, dass auch aktive Inhalte auerhalb von
Webseiten gefiltert werden mssen, beispielsweise in HTML-E-Mails.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2. Dezentrale Abwehr auf den angeschlossenen Clients

Die Ausfhrung aktiver Inhalte sollte normalerweise durch entsprechende
Einstellungen im Browser unterbunden werden. Die Umsetzung einer
Whitelist-Strategie fr aktive Inhalte wird von verschiedenen Browsern in
unterschiedlicher Weise und mehr oder weniger gut untersttzt (Beispiele:
Zonenmodell des Microsoft Internet Explorers, Browser-Profile bei Mozilla).
Idealerweise sollte ein Browser die Mglichkeit bieten, die Ausfhrung
bestimmter Typen aktiver Inhalte getrennt fr einzelne Server oder Domains
freigeben oder verbieten zu knnen.
Dabei ist allerdings zu beachten, dass es auf Grund von Schwachstellen in den
Browsern Angreifern mglich sein kann, entsprechende Einschrnkungen zu
umgehen.
Java-Applets, Acitve-X Objekte und mit Einschrnkungen auch Javascript Signierte aktive Inhalte
knnen mit einer digitalen Signatur versehen werden. Die Signatur dient dazu,
die Integritt und Authentizitt des jeweiligen aktiven Inhalts zu schtzen.
Werden ausschlielich signierte aktive Inhalte zugelassen, so bietet dies eine
erhhte Sicherheit vor Schadfunktionen. Diese Sicherheit ist jedoch nur
indirekt, da der Nutzer auf die Vertrauenswrdigkeit der Signaturstelle, die in
Zusammenarbeit mit dem Anbieter der aktiven Inhalte die Signatur erstellt,
angewiesen ist.
Selbst die vollstndige Deaktivierung der Ausfhrung aktiver Inhalte bietet
aber nur einen begrenzten Schutz vor bsartigen aktiven Inhalten. Aufgrund
der Vielzahl von Software-Schwachstellen in den Browsern knnen die
Sicherheitseinstellungen umgangen werden, so dass der intendierte Schutz
tatschlich nicht oder nicht in vollem Umfang existiert.
3. Installation von Anti-Viren-Software und Personal Firewalls auf
den Clients
Anti-Viren-Produkte knnen vor Viren, Makroviren und Trojanischen Pferden
schtzen, die durch aktive Inhalte automatisch heruntergeladen wurden. Sie
bieten einen guten Schutz vor bereits bekannten Schadprogrammen. Mehr zu
Anti-Viren-Produkten findet sich in Kapitel 3.6 Computer-
Virenschutzkonzept.
Personal Firewalls sind Programme, die auf dem Client-Rechner installiert Personal Firewalls
werden und dort meist mehrere Funktionen wahrnehmen. Sie bieten meist
neben der Funktion eines lokalen Paketfilters weitere Funktionen an.
Beispielsweise bieten einige Personal Firewalls die Mglichkeit einer
berwachung anderer Programme, die versuchen eine Netz-Verbindung
aufzubauen. Solche Verbindungsaufnahmen knnen dann meist entweder
automatisch anhand festgelegter Regeln oder im Einzelfall vom Benutzer
selbst erlaubt oder verboten werden. In einigen Fllen bieten sie auch
sogenannte "Sandboxen", die die Ausfhrung aktiver Inhalte kontrollieren und
auf unbedenkliche Operationen beschrnken knnen.
Personal Firewalls bieten zusammen mit Anti-Viren-Programmen einen recht
guten Schutz vor bsartigen aktiven Inhalten. Allerdings muss bercksichtigt
werden, dass die richtige Konfiguration dieser Programme zustzlichen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Administrationsaufwand erfordert, und dass Personal Firewalls selbst

Sicherheitslcken aufweisen knnen, die das System gefhrden.
Bei allen drei Optionen ist eine Sensibilisierung der Benutzer zustzlich Sensibilisierung der
Benutzer
notwendig. Zudem muss sichergestellt werden, dass die Einstellungen auf den
Clients bei allen unter Punkt 2 und 3 genannten Schutzvorkehrungen nicht
versehentlich oder absichtlich vom Benutzer deaktiviert oder umgangen
werden knnen.
Vorteile der zentralen Filterung Vorteile der dezentralen Filterung

- Einfache Installation und - Im Vergleich zur zentralen
Administration, da die Filterung hhere
Filtersoftware nur einmal Ausfallsicherheit, da die Filterung
installiert werden muss. dezentral erfolgt.
- Einfache Protokollierung und - Schutz vor verschlsselten aktiven
Auswertung, da im Gegensatz zur Inhalten. Bei Filterung auf dem
dezentralen Filterung keine Endgert knnen aktiven Inhalte
Protokolldaten von mehreren erkannt werden, da sie auf dem
Rechnern zusammengefhrt Endgert entschlsselt werden.
werden mssen.
- Die Ausfhrung von aktiven
- Im Gegensatz zur dezentralen Inhalten kann unabhngig vom
Filterung ist keine triviale Sicherheitsgateway abgeschaltet
Manipulation der Filtersoftware werden.
durch den Benutzer mglich.
- Es entstehen keine
- Filterprogramme fr aktive Inhalte Kompatibilittsprobleme, die sich
auf dem ALG sind dedizierte durch den Einsatz einer zentralen
Sicherheitsprodukte. Der Schutz Filtersoftware auf dem ALG
vor aktiven Inhalten auf den ergeben knnten.
Clients (z. B. im Browser) ist
hingegen oft fehlerhaft
implementiert.
- Die Verwendung der
Filtersoftware ist unabhngig von
der Software auf den Clients
mglich. Es entstehen keine
Kompatibilittsprobleme mit der
auf den Clients eingesetzten
Software
Tabelle: Vorteile der zentralen beziehungsweise dezentralen Filterung
Empfehlung
Die Entscheidung, wie mit aktiven Inhalten in Webseiten umgegangen wird,
hngt in erster Linie vom Schutzbedarf der betreffenden Clients ab. Die
folgende Tabelle kann bei der Festlegung der individuellen Strategie als
Grundlage dienen:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Schutzbedarf Empfehlung
der Clients
Normal Allgemein: Deaktivierung aktiver Inhalte im Browser und
Freischaltung nur fr vertrauenswrdige Websites.
Virenscanner auf dem Client (siehe auch Kapitel 3.6
Computer-Virenschutzkonzept).
Eine Filterung aktiver Inhalte auf dem Sicherheitsgateway
mit Freischaltung fr vertrauenswrdige Websites
(Whitelist) ist empfehlenswert.
Hoch Deaktivierung aktiver Inhalte im Browser und
Freischaltung nur fr vertrauenswrdige Websites.
Virenscanner auf dem Client (siehe auch Kapitel 3.6
Computer-Virenschutzkonzept).
Filterung aktiver Inhalte auf dem Sicherheitsgateway mit
Freischaltung fr vertrauenswrdige Websites (Whitelist).
Zustzlich Filterung von Cookies (Whitelist).
Die Kriterien, fr welche Websites aktive Inhalte
freigeschaltet werden, sollten deutlich restriktiver sein als
bei normalem Schutzbedarf.
Eine ergnzende Sicherheitsanalyse wird empfohlen, um
sicher zu stellen, dass ein angemessenes Sicherheitsniveau
erreicht wurde.
Bei zustzlichen Einsatz einer Personal Firewall auf dem Client.
oder speziellen
Anforderungen
Tabelle: Empfehlungen fr den Umgang mit aktiven Inhalten in Webseiten
Die Entscheidung fr eine bestimmte Vorgehensweise und die Grnde, die
dafr ausschlaggebend waren, sollten nachvollziehbar dokumentiert werden.
Eine zu "liberale" Einstellung oder gar eine generelle Freigabe aktiver Inhalte Vorsicht ist besser als
Nachsicht
ist auch bei normalem Schutzbedarf nicht zu empfehlen. Die mglichen
Schden, die durch bsartige aktive Inhalte in Verbindung mit Schwachstellen
in Webbrowsern oder im unterliegenden Betriebssystem entstehen knnen,
sind dafr zu gravierend. Falls fr bestimmte, Anwendungen aktive Inhalte
zwingend ntig sind, sollten sie nur fr die betreffenden Server freigegeben
werden.
Bei Neuentwicklungen browserbasierter Anwendungen oder bei einer Notwendigkeit aktiver
Inhalte hinterfragen
Weiterentwicklung einer bestehenden Anwendung, die aktive Inhalte im
Browser bentigt, sollte kritisch hinterfragt werden, ob die Verwendung der
aktiven Inhalte wirklich notwendig ist. Oft lassen sich aktive Inhalte bei
gleichwertiger Funktionalitt durch serverseitig dynamisch erzeugte
Webseiten ersetzen.
- Wie werden aktive Inhalte behandelt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.101 Sicherheitsgateways und Verschlsselung

Da im Internet die Daten ber nicht vorhersagbare Wege und Knotenpunkte
verschickt werden, sollten die versandten Daten mglichst nur verschlsselt
bertragen werden. Eine Verschlsselung des Datenverkehrs ber das Internet
kann auf zwei verschiedene Arten realisiert werden:
- Verschlsselung auf dem Sicherheitsgateway bzw. auf
Netzkoppelelementen, die zum Aufbau sicherer Teilnetze eingesetzt
werden kann
- Verschlsselung auf den Endgerten, die z. B. von Benutzern
bedarfsabhngig eingesetzt wird
Beide Verfahren haben spezifische Vor- und Nachteile, die je nach
Anwendungszusammenhang fr die eine oder die andere Variante sprechen.
Verschlsselung durch das Sicherheitsgateway
Um mit externen Kommunikationspartnern Daten ber ein offenes Netz
auszutauschen und / oder diesen Zugriff auf das eigene Netz zu geben, kann
der Aufbau von virtuellen privaten Netzen (VPNs) sinnvoll sein. Dafr sollten
alle Verbindungen von und zu diesen Partnern verschlsselt werden, damit
Unbefugte keinen Zugriff darauf nehmen knnen. Zum Aufbau von
verschlsselten Verbindungen knnen eine Vielzahl von Hard- und
Softwarelsungen eingesetzt werden. Sollen hierbei nur wenige
Liegenschaften miteinander verbunden werden, sind insbesondere Hardware-
Lsungen basierend auf symmetrischen kryptographischen Verfahren eine
einfache und sichere Lsung.
Mglichkeiten zur Einbindung von VPN-Komponenten in
Sicherheitsgateways finden sich in M 4.224 Integration von Virtual Private
Networks in ein Sicherheitsgateway.
Die Ver- und Entschlsselung kann gegebenenfalls auf verschiedenen Gerten
erfolgen. So knnte eine Hardware-Lsung im Paketfilter als Schlsselgert
arbeiten. Dies ist insbesondere dann sinnvoll, wenn keine unverschlsselte
Kommunikation ber dieses Gert gehen soll.
Die Integration der Verschlsselung auf dem ALG hat den Vorteil einer
leichteren (zentralen) Benutzerverwaltung. Zudem kann ein Angreifer, der
einen externen Informationsserver unter seine Kontrolle gebracht hat, die
verschlsselte Kommunikation nicht belauschen.
Verschlsselung auf den Endgerten
Zum Schutz der Vertraulichkeit bestimmter Daten, insbesondere bei der
Versendung von E-Mails, bietet sich auch der Gebrauch von Mechanismen an,
die eine Ende-zu-Ende-Verschlsselung ermglichen. Hierfr wird beim
Dienst E-Mail zum Beispiel das frei verfgbare Programmpaket PGP (Pretty
Good Privacy) sehr hufig eingesetzt (siehe M 5.63 Einsatz von GnuPG oder
PGP), fr den Zugriff auf andere Rechner das Secure-Shell Protokoll (SSH) .
Fr eine vertrauenswrdige Datenbertragung mit ausgewhlten Partnern im
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Internet sollten nur bertragungsprogramme und -protokolle verwendet

werden, die eine Verschlsselung der bertragenen Daten untersttzen.
Unsichere Klartextprotokolle wie Telnet und FTP sollten ohne zustzliche
Manahmen (etwa Tunneln ber eine verschlsselte Verbindung oder ein
echtes VPN) nicht mehr in ffentlichen Netzen eingesetzt werden.
Die Ende-zu-Ende-Verschlsselung der Daten stellt andererseits aber auch ein Problem der Ende-zu-
Ende-Verschlsselung
groes Problem fr den wirksamen Einsatz von Filtermechanismen eines
Sicherheitsgateways dar. Wenn die bertragung verschlsselter Daten ber
das Sicherheitsgateway zugelassen wird (z. B. SSL), sind Filter auf der
Anwendungsschicht nicht mehr in der Lage, die Nutzdaten beispielsweise auf
Viren oder andere Schadprogramme zu kontrollieren. Auch die
Protokollierungsmglichkeiten werden durch eine Verschlsselung stark
eingeschrnkt.
Eine Lsung dieses Problems kann darin bestehen, den Datenverkehr temporr Eventuell temporre
Entschlsselung auf
vom Sicherheitsgateway entschlsseln zu lassen. Beispielsweise existieren fr dem Sicherheitsgateway
SSL entsprechende Proxies, die die SSL-Verbindung am Sicherheitsgateway
terminieren und den entschlsselten Datenstrom fr eine Filterung zugnglich
machen. Gegebenenfalls knnen die Daten dann wieder fr die bertragung
zum Endgert verschlsselt werden.
Eine generelle Empfehlung fr oder gegen den Einsatz von Verschlsselung
ber das Sicherheitsgateway kann nicht gegeben werden. Dies hngt von den
Anforderungen im Einzelfall ab, daher sollte eine Bewertung im
Anwendungszusammenhang erfolgen.
Vor- und Nachteile der verschiedenen Realisierungsmglichkeiten
Auf dem Sicherheitsgateway: Auf den Endgerten:
+ Zentrale Datenprfung + Ende-zu-Ende Sicherheit
+ Zentrale Schlsselverteilung + Keine Protokollprobleme
+ Detailliertes Accounting +/- benutzerabhngig
- Zugriff vom Sicherheitsgateway - Keine Kontrollmglichkeiten auf
auf internes Netz dem Sicherheitsgateway
- Keine Ende-zu-Ende-Sicherheit - Oft werden Public-Key-
Infrastrukturen bentigt
Wird fr bestimmte Dienste oder Protokolle festgelegt, dass eine Ende-zu-
Ende-Verschlsselung eingesetzt (bzw. zugelassen) werden soll, so kann es
erforderlich werden, fr die Endgerte zustzliche Manahmen zu ergreifen.
Dies sollte im Rahmen einer ergnzenden Sicherheitsbetrachtung geprft
werden.
- Wird fr einen Dienst eine Ende-zu-Ende-Verschlsselung eingesetzt?
Falls ja: Wurde im Rahmen einer ergnzenden Sicherheitsbetrachtung
geprft, ob auf den Endgerten zustzliche Sicherungsmanahmen
erforderlich sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.102 C2-Sicherheit unter Novell 4.11

Zur Bewertung von IT-Produkten bzw. IT-Systemen haben sich als einheit-
licher Beurteilungsmastab international die US-amerikanischen Kriterien
TCSEC (Trusted Computer System Evaluation Criteria) bzw. die europ-
ischen ITSEC (Information Technology Security Evaluation Criteria) und
mittlerweile deren Weiterentwicklung CC (The Common Criteria for Infor-
mation Technology Security Evaluation) durchgesetzt. Novell Netware 4.11
hat im Herbst 1997 eine Zertifizierung gem Funktionalittsklasse C2 der
TCSEC durch das National Computer Security Center (NCSC) erhalten, dies
entspricht ITSEC Klasse F-C2/E2.
Der Einsatz eines zertifizierten Produktes bietet die Gewhr, dass die Sicher-
heitsfunktionalitt dieses Produktes unabhngig geprft wurde und den im
Evaluationslevel spezifizierten Standard nicht unterschreitet (siehe auch
M 2.66 Beachtung des Beitrags der Zertifizierung fr die Beschaffung).
Vielfach anzutreffende Standardflle sind in den genannten Sicherheitskri-
terien zu Funktionalittsklassen zusammengefasst. Die Anforderungen der
Funktionalittsklassen F-C2 sind im wesentlichen fr Betriebssysteme
gedacht. Darin sind z. B. folgende Merkmale definiert:
- bernahme der C1 Spezifikationen
- Existenz von Mechanismen zur Zugriffsbeschrnkung von Be-
nutzern auf bestimmte Dokumente
- Identifizierung von Benutzern
- Verfeinerung der Zugriffsberechtigungen
- Auditing aller sicherheitsrelevanten Ereignisse mit Zeitstempel, Benutzer-
name, Objekt und Meldung ber Erfolg bzw. Misserfolg
- Verwaltung der Audit Dateien (Zugriffsschutz, Steuerung des Umfangs,
etc.)
- Abgrenzung der Ressourcen (Zugriffsschutz)
- Abgrenzung von Daten aus verschiedenen Prozessen gegenber anderen
Prozessen selbst nach Freigabe
Die Einhaltung dieser Vorgaben wird in speziellen Testverfahren berprft.
Um C2-Sicherheit zu erreichen, reicht es allerdings nicht aus, ein C2-zertifi-
ziertes Produkt zu erwerben. Wesentlich fr die tatschliche Realisierung
eines C2-Systems ist die genaue Umsetzung der Vorgaben des Zertifizie-
rungsreports.
Die zur Erreichung der C2-Sicherheit bei Netware 4.11 notwendigen Sicher-
heitsoptionen wurden in der Datei SECURE.NCF zusammengefasst. In den
nachfolgenden Abschnitten wird die Datei SECURE.NCF dargestellt und die
einzelnen Optionen nher erlutert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Datei SECURE.NCF und ihre Optionen

Damit ein Novell Netware 4.11 Server die erweiterten Sicherheitsmechanis-
men nutzen kann, sind folgende Punkte zu beachten:
- Die Datei SECURE.NCF muss auf dem Server in SYS:SYSTEM gespei-
chert sein.
- Die Datei SECURE.NCF ist eine Ablaufdatei hnlich einer Batch-Datei
unter DOS und sollte daher nur mit einem ASCII-Editor (z. B. EDIT.NLM)
bearbeitet werden.
- Fr den Aufruf der Datei SECURE.NCF muss in der AUTOEXEC.NCF
die Zeile "SET ENABLE SECURE.NCF=ON" eingefgt werden.
Alternativ hierzu kann auch der Befehl "SECURE" in die
AUTOEXEC.NCF eingefgt oder dieser Befehl auf der Server-Konsole
abgesetzt werden.
Der nachfolgende Auszug aus der Datei SECURE.NCF zeigt nur die darin
enthaltenen Befehle. In der Originaldatei ist zu jedem Befehl eine kurze
Erluterung enthalten.
SET ALLOW UNENCRYPTED PASSWORDS = OFF
SET ALLOW AUDIT PASSWORDS = OFF
SET AUTOMATICALLY REPAIR BAD VOLUMES = ON
SET REJECT NCP PACKETS WITH BAD LENGTHS = ON
SET REJECT NCP PACKETS WITH BAD COMPONENTS = ON
SET IPX NETBIOS REPLICATION OPTION = 0
SET ADDITIONAL SECURITY CHECKS = ON
# SET CHECK EQUIVALENT TO ME = ON
# SET NCP PACKET SIGNATURE = 3
# SECURE CONSOLE
## DISPLAY NCP BAD COMPONENT WARNINGS
## DISPLAY NCP BAD LENGTH WARNINGS
Alle Befehlszeilen, die mit einem "#" auskommentiert wurden, sind zustz-
liche Sicherheitsparameter und fr die Einhaltung der C2 bzw. F-C2/E2
Bestimmungen nicht notwendig. Befehlszeilen, die mit "##" gekennzeichnet
sind, gehren nicht zum Standardumfang der Datei SECURE.NCF, stellen
aber im alltglichen Gebrauch eine sinnvolle Bereicherung dar.
Die Befehle im Einzelnen
Alle Befehle bzw. SET-Anweisungen knnen auch an der Konsole abgesetzt
oder mittels des Programms SERVMAN.NLM bzw. MONITOR.NLM gesetzt
werden.
Nachfolgend werden alle SET-Parameter der Datei SECURE.NCF beschrie-
ben und die Standardwerte (Default) angegeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
SET ALLOW UNENCRYPTED PASSWORDS = OFF (Default=OFF)

Dieser Parameter dient dazu, die Kompatibilitt von Netware 2.x Clients und
Print-Servern zu gewhrleisten. Ein Setzen des Parameters auf den Wert ON
hat zur Folge, dass ein Passwort, das zur Authentifizierung notwendig ist,
unverschlsselt zum Server bertragen werden kann. Dies begnstigt ein
unberechtigtes Eindringen in das betreffende System. Der Standardwert OFF
stellt sicher, dass beim Anmeldevorgang jedes Passwort verschlsselt werden
muss. Unverschlsselte Passwrter werden nicht akzeptiert.
SET ALLOW AUDIT PASSWORDS = OFF (Default=OFF)
Dieser Parameter steht in Verbindung mit den Auditing Mechanismen des
Netware-Betriebssystems. Beim Auditing werden gem der Vorgaben der
Konfigurationen mittels des Programms AUDITCON.NLM Vernderungen
(Manipulationen) an Objekten aufgezeichnet. Durch entsprechende Berechti-
gungen, die z. B. in der allgemeinen Berechtigungsvergabe des Betriebs-
systems fr jeden Auditor individuell eingestellt werden knnen, ist ein
Auditor in der Lage, die Auditing-Datei zu lesen. Die jeweilige Berechtigung
schrnkt dabei den Leseumfang ein. Der Standardwert OFF bewirkt, dass sich
der Auditor nicht durch ein zustzliches Passwort identifizieren muss.
SET AUTOMATICALLY REPAIR BAD VOLUMES = ON (Default=ON)
Mit diesem Parameter wird das Betriebssystem angewiesen, ein Volume, das
beim Systemstart nicht gemountet werden kann, durch den Aufruf des
Programms VREPAIR.NLM zu reparieren. Dies stellt sicher, dass nach einem
unkontrollierten Systemabsturz und dem darauf folgenden Neustart mgliche
Fehler auf Volumes (Datenbereichen der Plattenstapel) ohne zustzlichen
Eingriff des Systemadministrators behoben werden.
SET REJECT NCP PACKETS WITH BAD LENGTHS = ON (Default=OFF)
Dieser Parameter bewirkt in der Einstellung ON, dass NCP Pakete mit inkor-
rekter Lnge abgewiesen werden. Dabei kann es zu Fehlern mit lteren
Anwendungen (Utilities) kommen.
SET REJECT NCP PACKETS WITH BAD COMPONENTS = ON
(Default=OFF)
Dieser Parameter bewirkt in der Einstellung ON, dass NCP Pakete mit inkor-
rekten Komponenten abgewiesen werden. Auch hier kann es zu Fehlern mit
lteren Anwendungen (Utilities) kommen.
SET IPX NETBIOS REPLICATION OPTION = 0 (Default=2)
Dieser Parameter legt die Vorgehensweise des IPX Routers fest, wie mit
NetBIOS Broadcast Meldungen umzugehen ist. Fr die Werteauswahl stehen
zur Verfgung:
0= keine Replizierung von Typ 20 IPX Paketen
1= Replizierung von Typ 20 IPX Paketen an alle verfgbaren
Netzadapter
2= Replizierung von Typ 20 IPX Paketen mit zwei speziellen Filter-
funktionen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
a) Reverse Path Forwarding: Typ 20 IPX Pakete von derselben

Quelle werden nur einmal an alle verfgbaren Netzkarten
weitergeleitet, selbst wenn die Pakete ber unterschiedliche
Netzadapter empfangen wurden.
b) Split Horizon: Typ 20 IPX Pakete werden nicht in das Netz
zurckgeleitet, aus dem sie empfangen wurden.
3= Replizierung wie bei Option 2, aber nicht ber Weitverkehrsstrecken
SET ADDITIONAL SECURITY CHECKS = ON
Dieser Parameter aktiviert zustzliche Sicherheitsberprfungen, die mit fr-
heren NDS Versionen inkompatibel sind.
Die zuvor aufgefhrten Parameter sind fr die Einhaltung der Sicherheits-
zertifizierung gem Klasse C2 und Klasse F-C2/E2 zwingend erforderlich.
Die nachfolgenden Parameter knnen zur Erweiterung der Sicherheitsfunk-
tionen eingesetzt werden.
SET CHECK EQUIVALENT TO ME = ON (Default=OFF)
Dieser Parameter erzwingt am Server die berprfung des NDS Attributes
"Equivalent To Me". Wenn der Wert fr die erweiterte Sicherheit auf ON
gesetzt wird, mssen mit der Anwendung DSREPAIR die Attribute
"Equivalence" und "Equivalent To Me" synchronisiert werden. Das Aktivieren
der Option hat mglicherweise nachteilige Effekte auf die Authentifizie-
rungsgeschwindigkeit des Systems.
SET NCP PACKET SIGNATURE = 3 (Default=1)
Die Kommunikation eines Novell Netware Clients mit einem Novell Netware
Server wird durch das Netware Core Protokoll (NCP) gesteuert. Client und
Server tauschen hierbei einzelne Pakete aus, in denen die Daten enthalten sind.
Ein potentieller Angreifer kann diese Pakete mittels spezieller Programme
(siehe G 5.58 "Hacking Novell Netware") berwachen und die Datenpakete
hher privilegierter Benutzer manipulieren.
Um dieser Bedrohung entgegenzuwirken, wurde die Paket-Signatur
entwickelt. Bei der Anmeldung eines Benutzers am Netz wird ein geheimer
Schlssel ermittelt. Wann immer die Workstation daraufhin eine Anfrage ber
NCP an das Netz sendet, wird diese mit einer Signatur versehen, die aus dem
geheimen Schlssel und der Signatur des vorherigen Pakets gebildet wird.
Diese Signatur wird an das betreffende Paket angehngt und zum Server
gesandt. Bevor die eigentliche Anfrage bearbeitet wird, verifiziert der Server
die Paket-Signatur.
Durch den Parameter kann die Paket-Signatur am Server aktiviert werden.
Hierbei sind folgende NCP-Paket-Signatur Level mglich:
0= Es findet keine NCP-Paket-Signatur statt.
1= Der Novell Netware Server arbeitet auf Anforderung des Clients mit
der NCP-Paket-Signatur.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
2= Der Novell Netware Server fordert vom Client NCP-Paket-Signatur

an. Sollte der Client dieses nicht realisieren knnen, so wird die
Kommunikation zwischen Client und Novell Netware Server trotz-
dem zugelassen.
3= Die NCP-Paket-Signatur ist zwingend vorgeschrieben.
Zur Gewhrleistung der IT-Sicherheit sollte die NCP-Paket-Signatur mit dem
Wert "3" gewhlt werden und der Novell Netware Server sowie die Client-
Software der Arbeitsstationen entsprechend konfiguriert werden. Da sich
jedoch die Netzlast beim Einsatz der NCP-Paket-Signatur erhht, sollte im
Vorfeld des Einsatzes geklrt werden, ob die Performance hierdurch nicht
unzumutbar eingeschrnkt wird.
SECURE CONSOLE
Mit diesem Befehl werden mehrere Funktionen ausgelst. Daher sollte dieser
Befehl nur an sicherheitssensitiven Systemen ausgefhrt werden. Die Funk-
tionen sind:
1. Alle Suchpfaderweiterungen werden rckgngig gemacht. Fr den
Aufruf von NLMs steht nur noch der Suchpfad auf das Laufwerk
SYS:SYSTEM zur Verfgung.
2. Eine Suchpfaderweiterung mit dem Befehl SEARCH ADD ist nicht
mehr mglich.
3. Das Verndern von verschiedenen Server-Parametern mit dem
Befehl SET ist nicht mehr mglich.
4. Das Verndern von Systemzeit und Systemdatum ist nicht mehr
mglich.
5. Der System Debugger kann nicht mehr durch die spezielle Tasten-
kombination aufgerufen werden.
Hinweis: Da SECURE CONSOLE die Suchpfade auf das Systemminimum
reduziert, kann es zu erheblichen Problemen mit Serverapplikationen
kommen, die eine spezielle Suchpfaderweiterung bentigen.
DISPLAY NCP BAD COMPONENT WARNINGS
Mit diesem Parameter wird der Server angewiesen, eine Warnmeldung auf der
Konsole auszugeben, wenn NCP Pakete mit ungltigem Inhalt bzw. Anteilen
empfangen werden. Dies knnte auf Angriffe hindeuten.
DISPLAY NCP BAD LENGTH WARNINGS
Mit diesem Parameter wird der Server angewiesen, eine Warnmeldung auf der
Konsole auszugeben, wenn NCP Pakete mit ungltiger Lnge empfangen
werden. Dies knnte auf Angriffe hindeuten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.103 DHCP-Server unter Novell Netware 4.x

Beim Einrichten von TCP/IP-Protokollen entsteht ein hoher Aufwand, wenn
fr jede Workstation manuell die IP-Adresse, die Subnetz-Maske, das Default
Gateway, etc. vergeben werden mssen. Soll z. B. in einem Segment nur der
Default Gateway Eintrag gendert werden, erfordert dies einen hohen
Arbeitsaufwand und erhht zudem die Gefahr von Falscheingaben. Durch den
Einsatz eines DHCP-Servers (Dynamic Host Configuration Protocol) knnen
diese Aufgaben zentralisiert und automatisiert werden.
Um einen sicheren Umgang mit dem DHCP-Server von Novell Netware 4.x
zu gewhrleisten, ist es erforderlich, dass die Struktur des TCP/IP-Netzes,
dessen Adressen mit Hilfe des DHCP-Servers verwaltet werden sollen,
bekannt ist. Wichtig sind hierbei neben der Adressklasse (TCP/IP-Netz Klasse
A - C) auch die eingesetzten Subnetz-Masken und die Adressen der Default
Gateways, um segmentbergreifenden Datenverkehr auf TCP/IP Basis zu
ermglichen.
Im folgenden wird auf einige Aspekte bei der Konfiguration des DHCP-
Dienstes unter Novell Netware 4.x eingegangen, die fr die Sicherheit des
Gesamtsystems von besonderer Relevanz sind.
Konfiguration der TCP/IP-Segmente
ber die Option SUBNETWORK PROFILE werden die TCP/IP-Segmente
definiert, die vom Server versorgt werden sollen. Dabei werden Werte wie
Subnetzname, Adressbereich und Zuweisungsart vom Konfigurationsmen
des DHCP-Servers bei dessen Start automatisch ausgelesen. Soll der DHCP-
Server mehrere IP-Segmente versorgen, so ist es empfehlenswert, die auto-
matisch eingelesenen Werte zu lschen und durch "sprechende", manuell
konfigurierte Werte zu ersetzen. Wurde z. B. als Subnetzname "3CX9_1_EII"
ausgelesen, so ist es fr die Fehlersuche und fr sptere Konfigurationsar-
beiten fr dieses Segment einfacher, wenn dieser Eintrag manuell durch einen
Eintrag ersetzt wird, der das Segment besser beschreibt, z. B. der Name
"EthernetII". Andere sprechende Namensgebungen, die das Segment etwa
nach seiner topologischen Anordnung bezeichnen (Gebude A, 2. OG oder
Geschftsfhrung), sind ebenfalls einsetzbar.
Automatische Zuordnung von IP-Adressen
Ein wesentlicher Dienst des DHCP-Servers ist die automatische Zuordnung
von IP-Adressen. Der Parameter AUTOMATIC IP ADDRESS ASSIGN-
MENT kennzeichnet den Adressbereich, aus dem heraus der DHCP-Server
dynamisch die Adressen an die Netzknoten verteilt, die eine Adresse anfor-
dern. Dieser Bereich sollte so ausgewhlt werden, dass die Adressen fr
Server, Drucker und Router nicht in den Bereich der dynamischen Zuteilung
fallen. Generell sollten Servern, Druckern, Routern und den Netzknoten mit
dynamischer Adresszuordnung klar unterscheidbare IP-Adressbereiche zuge-
wiesen werden. Dadurch ist gewhrleistet, dass bereits am Adressbereich
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
erkennbar ist, zu welchem Typ ein Netzknoten gehrt, wenn Probleme im IP-
Bereich auftreten.
Statische Zuordnung von IP-Adressen
Fr bestimmte Komponenten im Netz ist es empfehlenswert, mittels einer
statischen Adresszuordnung die erforderliche IP-Adresse permanent auf die
MAC-Adresse (Medium Access Control) des Netzknotens zu binden. Hierzu
gehren z. B. Netzdrucker und Router. Der Vorteil einer statischen Zuordnung
durch einen DHCP-Server im Vergleich zu einer manuellen Konfiguration vor
Ort am Netzknoten ist die zentrale Verwaltung der Zuordnungen ber das
Konfigurationstool des DHCP-Servers. Obwohl Server ebenfalls zwingend
ihre IP-Adresse statisch zugeordnet bekommen mssen, werden diese nicht
ber den DHCP-Server vergeben. Bei Netware Servern erfolgt die Zuteilung
ihrer IP-Adresse immer manuell.
Die Konfiguration der statischen Adresszuordnung geschieht ber die Option
IP ADDRESS ASSIGNMENT. Der Knoten wird ber einen beliebigen
Namen dem Men hinzugefgt und die IP-Adresse direkt auf die Netzkarte
(MAC-Adresse) des Knotens gebunden. Fr die Auswahl des Namens
empfiehlt Novell, den Login-Namen des Benutzers zu verwenden, der an
diesem Arbeitsplatzrechner arbeitet.
Lease Time
Anhand der Lease Time wird festgelegt, wie lange ein Netzknoten, der seine
TCP/IP-Adresse vom DHCP-Server dynamisch erhlt, diese behalten kann.
Die Zuteilung der IP-Adressen wird dabei beim Booten des Netzknotens rea-
lisiert. Fr die Lease Time sollte ein Zeitraum von mindestens 24 Stunden
gewhlt werden, da sonst folgende Probleme auftreten knnen:
- Programme, deren Zugriffsberechtigungen anhand von TCP/IP-Adressen
erteilt werden, knnen nach einem Reboot des Rechners unter Umstnden
nicht mehr ausgefhrt werden, da sich die IP-Adresse des darauf zugrei-
fenden Rechners gendert hat. Die neue Adresse ist evtl. nicht berechtigt,
das Programm auszufhren.
- Wenn Arbeitsplatzrechner instabil laufen und pro Tag mehrfach erneut
gestartet werden, entsteht nach jedem Neustart eine unntige Netzlast
durch die Zuweisung einer neuen IP-Adresse.
- Beim Zugriff auf das Internet protokollieren zwischengeschaltete Proxy
Server die Internet-Seiten, die von den Arbeitsplatzrechnern aus aufgerufen
wurden. In den entsprechenden Protokolldateien werden meist die DNS
Namen der aufgerufenen Internet-Seiten den IP-Adressen der Rechner
zugeordnet, von denen aus diese Seiten angefordert wurden. Wenn sich
diese IP-Adressen stndig ndern, dann ist im Problemfall nur sehr schwer
nachvollziehbar, welcher Arbeitsplatzrechner zu welchem Zeitpunkt die
entsprechende IP-Adresse zugewiesen bekommen hat.
Die Vergabe einer Lease Time wird beim Einsatz von DHCP-Servern ben-
tigt, wenn sich in einem Netz mehr Knoten befinden, als IP-Adressen zur
Verfgung stehen. Mittels einer geeignet gewhlten Lease Time kann so eine
IP-Adresse, die frei geworden ist, weil der Knoten sie nicht mehr braucht (PC
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wurde ausgeschaltet), einem anderen Knoten, der eine Adresse vom DHCP-
Server anfordert, zugewiesen werden. In Netzen, die ber mindestens genauso
viele IP-Adressen verfgen wie Knoten installiert sind, kann auf die Konfigu-
ration der Lease Time verzichtet werden. Seit geraumer Zeit kann in LANs
mit sogenannten privaten IP-Adressen (siehe RFC 1597) gearbeitet werden.
Das Problem, mehr Knoten als IP-Adressen zu haben, kann somit umgangen
werden. Die Vergabe von privaten IP-Adressen nach diesen Vorgaben ist z. B.
aus Revisionsgrnden fr Netze, die einen Internet-Zugang realisieren,
empfehlenswert. Datenschutzrechtliche und mitbestimmungsrechtliche
Aspekte sind zu beachten.
Im DHCP-Server von Netware 4.x kann die Lease Time derzeit noch nicht
abgeschaltet werden. Es ist daher empfehlenswert, diese auf den maximalen
Wert von 10000 Tagen und 23 Stunden einzustellen.
Ausschluss bestimmter Netzknoten von der Adresszuordnung
Fr bestimmte Netzknoten kann die Zuweisung einer IP-Adresse unterbunden
werden. Unter dem Menpunkt EXCLUDED NODES sind hierzu dieselben
Schritte auszufhren, wie bei der statischen Zuordnung von IP-Adressen.
Hiermit wird erreicht, dass bestimmte Programme, die auf TCP/IP aufsetzen,
von diesen Arbeitspltzen aus nicht aufgerufen werden knnen. Diese
"Sperre" ist allerdings leicht zu unterwandern, indem dem "gesperrten" Netz-
knoten manuell eine IP-Adresse zugeordnet wird (sofern auf diesem Knoten
der TCP/IP-Protokollstack geladen wurde). Sobald bei der manuellen Zuord-
nung eine freie IP-Adresse gefunden wird, kann mit diesem Rechner genauso
ber TCP/IP kommuniziert werden, wie mit Knoten, die ihre IP-Adresse vom
DHCP-Server erhalten haben. Der Weg, Netzknoten ber EXCLUDED
NODES von der Vergabe einer IP-Adresse auszuschlieen, bietet daher nur
eine relative Sicherheit.
Das Sperren von MAC-Adressen fr die Vergabe durch den DHCP-Server
kann zudem dazu dienen, in Netzen mit mehreren DHCP-Servern die Lastver-
teilung zu steuern. Auerdem kann verhindert werden, dass Knoten, in deren
Segment sich ein eigener DHCP-Server befindet, die IP-Adresse von einem
DHCP-Server anfordern, der sich in einem anderen Segment befindet. Hierbei
sollte beachtet werden, dass in diesem Fall bei Ausfall des lokalen DHCP-
Servers lokalen Clients keine IP-Adresse zugeordnet werden kann. Der Ein-
satz der Option EXCLUDED NODES bedarf daher sorgfltiger Planung.
DHCP-Dienst in gerouteten Netzen
Ein zwischengeschalteter Router, der sich zwischen dem Segment des DHCP-
Clients und dem Segment des DHCP-Servers befindet, unterbindet u. U. die
DHCP-Anfrage. Router, die RFC 1542 kompatibel sind, besitzen einen soge-
nannten DHCP/BOOTP Relay Agenten. Dieser Agent sorgt dafr, dass DHCP
Relay Pakete weitergeroutet werden. Bei Routern, die nicht RFC 1542 kom-
patibel sind, mssen in jedem Netzsegment jeweils eigene DHCP-Server
definiert sein. Die Zuteilung einer IP-Adresse durch den DHCP-Server
geschieht dann auf dieselbe Art und Weise wie in nicht gerouteten Netzen.
Durch die Weiterleitung der DHCP Relay Pakete werden aber nicht automa-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
tisch die gesamten Broadcast Pakete weitergeleitet. "Normale" Broadcast

Datenpakete werden weiterhin vom Router herausgefiltert.
Einsatz von mehreren DHCP-Servern in Netzen
In Netzen, die ber eine entsprechende Gre verfgen, sollte unter Umstn-
den mit mehreren DHCP-Servern gearbeitet werden. Als Lastobergrenze gilt
in manchen Betriebssystemen die Verwaltung von 10000 IP-Adressen pro
DHCP-Server. Dieser Wert kann vom Netware DHCP-Server um ein Viel-
faches berschritten werden. Zudem sollte bei der berlegung, wieviele
DHCP-Server im Netz erforderlich sind, die Position der Router bercksich-
tigt werden.
Unabhngig von der Struktur des IP-Netzes ist bei Verwendung von mehreren
DHCP-Servern unbedingt zu verhindern, dass zwei (oder mehr) Netzknoten,
die von verschiedenen DHCP-Servern "versorgt" werden, dieselbe IP-Adresse
zugewiesen bekommen. Diese Gefahr besteht, wenn jeder DHCP-Server im
Netz (bzw. im Segment) jeweils den gesamten IP-Bereich verwaltet, der fr
die dynamische Vergabe eingerichtet wurde, da sich die DHCP-Server unter
Netware 4.x untereinander nicht synchronisieren. Jeder einzelne DHCP-Server
speichert seine Konfigurationsdaten in einer separaten DHCPTAB-Datei. Da
diese Datei unter Netware 4.x aber nicht Bestandteil der NDS ist, wird sie
auch nicht ber deren Replizierungsmechanismen auf andere Server verteilt,
bzw. mit anderen DHCPTAB-Dateien abgeglichen. Daher sollte bei
Verwendung mehrerer DHCP-Server jedem Server ein eigener IP-Adress-
bereich zugewiesen werden, den er exklusiv verwaltet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.104 LDAP Services for NDS

Das Lightweight Directory Access Protocol (LDAP) hat sich zum De-facto-
Standard fr den Zugriff auf X.500-Standard basierende
Verzeichnisinformationen ber das Internet/Intranet entwickelt. Die Novell
Directory Services (NDS) gehren zu den LDAP Directories, deren
Hauptaufgabe darin liegt, eine Vielzahl von Suchoperationen gleichzeitig
bearbeiten zu knnen. ber die NDS ist es dem Administrator mglich, alle
Firmenmitarbeiter und alle im Netz verfgbaren Ressourcen als Objekte in
einem hierarchischen Verzeichnisbaum anzulegen und zu verwalten. So
knnen z. B. den Benutzern Zugriffsrechte auf Unix-, Microsoft
Windows NT-, Novell Netware Server oder anderen Ressourcen wie der
Zugriff auf das Mailing-System und Druckern zugewiesen werden. Bisher
musste die Information in applikationsspezifischen Listen gepflegt und ber
die unterschiedlichen Systemgrenzen hinaus konsolidiert werden. Werden
verzeichnisfhige Applikationen eingesetzt, so entsteht ein "Single Point of
Administration", d. h. die Pflege der Gesamtinformation geschieht von einer
Stelle aus.
Alle auf X.500 basierenden Verzeichnisdienste verwenden ein Directory
Access Protocol (DAP), um die Verzeichnisinformationen zu synchronisieren
und eine Kommunikationsschnittstelle zwischen den unterschiedlichen
Netzkomponenten bereitzustellen.
Bei LDAP handelt es sich um ein Directory Access Protocol, dessen
Hauptaufgabe die schnelle Informationsextraktion, gesttzt auf einen
geringeren Protokolloverhead, ist. Es wird nicht der gesamte OSI-
Protokollstack implementiert, sondern LDAP setzt direkt auf dem TCP/IP
Protokoll auf. Als Folge daraus sind die LDAP Clients weit weniger komplex
als die DAP Clients. Da sich die Implementierung von LDAP auf den
Internet-Standard RFC 1777 absttzt, sind die Entwickler in der Lage,
plattformunabhngige Application Program Interfaces (APIs) zu verwenden.
Es muss daher keine Rcksicht auf die herstellerspezifische Notation
genommen werden, da der LDAP Server das Umsetzen einer LDAP Anfrage
in das erforderliche Format vornimmt.
In den LDAP Services for NDS fr Netware 4.11 ist LDAP Version 2
implementiert worden, die sich mit der Client-to-Directory Kommunikation
beschftigt. Die Version 3 von LDAP beinhaltet Spezifikationen zur
Directory-to-Directory Kommunikation, wie z. B. die Replikation und die
Synchronisation von Verzeichnisinformationen im Netz. Der Standard
(RFC 2551) ist aber bisher noch nicht endgltig verabschiedet worden. Eine
Implementierung von LDAP Version 3 kommt unter Netware 5 zum Einsatz.
Die LDAP Services for NDS bernehmen eine Mittlerfunktion zwischen der
NDS, die natrlich installiert sein muss, und dem LDAP Client. Der Client
stellt eine LDAP Anfrage an den Server, auf dem die LDAP Services laufen.
Diese Anfrage wird entgegengenommen und von den LDAP Services for
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
NDS in eine NDS Anfrage umgewandelt. Die NDS wertet die Anfrage aus
und liefert die angeforderten Informationen an die LDAP Services for NDS
zurck. Diese wiederum generieren aus der NDS Antwort eine LDAP Antwort
und leiten diese an den Client weiter.
Novell selbst bietet keinen LDAP Client an. Die gebruchlichsten Clients sind
derzeit Browser, wie z. B. der Netscape Communicator, die eine
entsprechende LDAP Schnittstelle haben. Es gibt aber auch andere, frei
verfgbare LDAP Clients im Internet. Dabei sind jedoch vor dem Einsatz
dieser Clients einige Dinge zu beachten. So ist zum Beispiel der Netscape
Communicator nicht in der Lage, Zugriffe auf LDAP Server zu gewhren, die
einen Benutzernamen und ein Passwort erfordern. Daher erkennen die LDAP
Services for NDS einen Benutzer, der diesen Browser als Client verwendet,
als Anonymous User und machen ihn standardmig zum Trustee von
[Public], was typischerweise nur ein Browse-Recht auf die NDS beinhaltet.
Wenn zustzliche Rechte bentigt werden, so ist ein Proxy User einzurichten,
der ber die entsprechenden NDS Rechte verfgt. Zustzlich muss im LDAP
Group Objekt noch das Proxy User Feature freigegeben werden.
Da die LDAP Services for NDS vollstndig in die NDS integriert sind, muss
bei der Installation eine Erweiterung des NDS Schemas vorgenommen
werden. Dies kann nur ber einen Account mit Supervisor Berechtigung auf
das [Root] Objekt erfolgen. Bei der Installation des ersten LDAP Servers in
einem NDS Baum wird das Datenbankschema der NDS erweitert, so dass die
zwei neuen NDS Objekte LDAP Server und LDAP Group zur Verfgung
stehen. ber diese beiden Objekte werden die LDAP Services for NDS
konfiguriert. Werden weitere LDAP Server in diesem NDS Baum installiert,
so ist es nicht notwendig, die Schemaerweiterung noch einmal zu installieren,
da die NDS bereits das aktuelle Datenbankschema besitzt.
Die Konfiguration der LDAP Services for NDS wird ber die Eigenschaften
("Properties") der beiden Objekte LDAP Server und LDAP Group festgelegt.
Die Einstellung ist anhand der erarbeiteten Sicherheitsstrategie vorzunehmen.
Im folgenden wird auf einige Properties eingegangen, die im Hinblick auf die
Sicherheit des Systems besonders relevant sind.
Log file size limit (LDAP Server Objekt)
Mit dieser Property kann die maximale Gre der in der Property Log
filename angegebenen Log-Datei eingerichtet werden. Erreicht die Log-Datei
die festgelegte Dateigre, so werden die Informationen der Log filename
Datei in die unter Backup log file angegebene Datei kopiert. Alle neuen Log-
Daten werden in die Log filename Datei geschrieben.
Default: 1.000.000
Minimum: 0 (unbegrenzte Dateigre)
Maximum: 4.294.967.295
Wird der Wert auf Null gesetzt, so besteht keine Grenlimitation fr die Log-
Datei. In diesem Fall sollte man die Datei nicht auf dem Volume SYS
ablegen, da die Datei so stark anwachsen kann, dass der verfgbare
Speicherplatz auf dem Volume komplett belegt wird. Als Folge knnen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Inkonsistenzen innerhalb der NDS auftreten, und die Verfgbarkeit des

Servers wird reduziert.
Im LDAP Group Objekt sind die folgenden Properties besonders
sicherheitsrelevant:
Suffix
ber das Feld Suffix wird der Unterbaum definiert, der den LDAP Clients zur
Verfgung gestellt wird. Ist dieses Feld leer, so wird den Clients Zugriff auf
den gesamten NDS Baum gewhrt, also vom [Root] Objekt aus. Stellt ein
Client eine Anfrage an den Server, die sich auf ein Objekt auerhalb des
definierten Unterbaums bezieht, so wird ein Fehler zurckgegeben, auer das
Feld Referral ist mit einem Wert belegt worden.
Referral
In dieses Textfeld kann ein Uniform Resource Locator (URL) eines
alternativen LDAP Servers eingetragen werden. Stellt z. B. ein Client eine
Anfrage an den Server, die dieser nicht beantworten kann, da das Suffix
gesetzt wurde, so wird diese URL an den LDAP Client zurckgeliefert. Der
Client ist nun in der Lage, seine Anfrage an diesen Server weiterzuleiten.
Enable NDS User Bind
Ist diese Checkbox aktiviert, so muss sich ein Benutzer bei einem Bind
Request mit seinem NDS Passwort authentifizieren. Die Passwrter werden
jedoch zwischen dem LDAP Client und dem LDAP Server nicht verschlsselt,
d. h. sie werden im Klartext ber das Netz bertragen. Durch einen geeigneten
Netzmonitor (Lanalyzer) ist deshalb ein Angreifer in der Lage, auf diese
Weise Passwrter auszuspionieren. Aus Sicherheitsgrnden sollte dieser Wert
nicht gesetzt werden, auer man verwendet Accounts, die speziell fr LDAP
Zugriffe eingerichtet worden sind und ansonsten keine weiteren Rechte in der
NDS und auf das Netware Dateisystem haben.
Proxy Username
Beim Proxy User handelt es sich um einen NDS Account, der kein Passwort
und auch keine Passwortnderung bentigt. Wird ein Anonymous Bind
(Verbindungsaufbau ohne Benutzername und Passwort) angefordert, so
authentifiziert der LDAP Server diese Anforderung mit dem Proxy Username
in der NDS. Typischerweise sind diese Proxy User in ihren Rechten stark
eingeschrnkt. Ist aber kein Proxy Username definiert worden, so werden
diese Anonymous Binds als Benutzer [Public] validiert und erhalten daher
auch die entsprechenden Rechte.
ber die Access Control Page erhalten die LDAP Services for NDS ein
zustzliches Sicherheitsfeature, die Access Control List (ACL). Die LDAP
ACL definiert die Zugriffsrechte auf die LDAP Objekt Properties fr Benutzer
und Gruppen. Der LDAP Server benutzt die ACL um festzustellen, ob eine
Benutzeranfrage an die NDS weitergereicht oder zurckgewiesen wird. Hat
ein Benutzer die entsprechenden Rechte, so wird die Anfrage an die NDS
weitergereicht. Die NDS ihrerseits prft, basierend auf den NDS Rechten, ob
die Anfrage bearbeitet oder zurckgewiesen wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ber das LDAP ACL Dialogfenster knnen den Benutzern Rechte

zugewiesen werden. Dabei sind folgende Abstufungen mglich:
None
Ist diese Option aktiviert, erhlt der Benutzer keinerlei Rechte auf den
NDS Baum.
Search
Dieses Recht erlaubt dem Benutzer, nach LDAP Objekt Properties zu
suchen. Diese mssen aber in der Access To Liste definiert sein. ber den
Add Button knnen Properties explizit freigegeben werden.
Compare
ber dieses Recht wird es dem Benutzer erlaubt, LDAP Objekt Property
Werte mit den korrespondierenden NDS Objekt Property Werten zu
vergleichen.
Read
Besitzt ein Benutzer das Read Recht, so ist es ihm erlaubt, die in der
Access To Liste definierten LDAP Property Werte zu sehen. Das Read
Recht umfasst das Search und das Compare Recht.
Write
Besitzt ein Benutzer das Write Recht, so kann er die in der Access To Liste
definierten LDAP Property Werte schreiben. Das Write Recht umfasst das
Search, Compare und Read Recht.
Neben diesen fnf Sicherheitsstufen im Zugriff (Access Level) lsst sich der
Zugriff noch weiter einschrnken. Z. B. kann durch das Feld IP Address
erzwungen werden, dass eine Anfrage nur von einer oder einer Gruppe von IP-
Adressen akzeptiert wird.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.105 Erste Manahmen nach einer Unix-

Standardinstallation
Die meisten Unix-Systeme entsprechen nach einer Standardinstallation nicht
den Anforderungen an einen sicheren Systembetrieb. Hier werden von den
Herstellern hufig zu viele sicherheitskritische Dienste und Konfigurationen
aktiviert bzw. mit zu weitreichenden Rechten versehen.
Die folgende bersicht soll exemplarisch das erste Absichern einer Standard-
installation aufzeigen:
- Vor der Installation ist der Administrator entsprechend zu schulen, insbe-
sondere hinsichtlich der Sicherheitsaspekte. In diesem Rahmen sollte er
sich ber alle potentiellen Sicherheitslcken des IT-Systems kundig
machen (siehe auch M 2.35 Informationsbeschaffung ber Sicherheits-
lcken des Systems). Dazu gehrt auch die Subskription entsprechender
Mailinglisten.
- Nach der Installation sollte das Account des Systemadministrators ein
gutes Passwort erhalten (siehe M 2.11 Regelung des Passwortgebrauchs).
- Es sollte berprft werden, welche Dienste auf dem IT-System laufen. Dies
kann z. B. mit dem Befehl netstat -a | grep listen berprft werden. Nicht
bentigte Dienste sollten deaktiviert oder entfernt werden (siehe M 5.72
Deaktivieren nicht bentigter Netzdienste).
- Wenn das System nicht als Mailserver fungiert, sollte der Maildaemon als
Netzdienst deaktiviert werden. Wenn Mail lokal auf dem System zugestellt
werden soll, kann sendmail mit der Option -q15 oder als Cron-Prozess
gestartet werden:
1 * * * * /usr/sbin/sendmail -q 2>&1 >/dev/null
Die Mail-Queue wird in regelmigen Abstnden geleert und die Mail
lokal zugestellt.
- Die aktuellste sendmail-Version des Herstellers sollte installiert werden
(siehe auch M 4.107 Nutzung von Hersteller-Ressourcen und M 5.19
Einsatz der Sicherheitsmechanismen von sendmail). Alternativ kann auch
auf Public-Domain-Mailprogramme wie z. B. qmail zurckgegriffen
werden. Die laufende sendmail-Version kann mit dem Befehl telnet
localhost 25 herausgefunden werden.
- Nach der Standardinstallation sollten die verfgbaren Security-Patches des
Herstellers installiert werden (siehe auch M 4.107 Nutzung von Hersteller-
Ressourcen). Danach ist unbedingt zu berprfen, dass durch die Patch-
Installation keine nichtbentigten Dienste aktiviert wurden.
- Die Filesysteme sollten restriktiv im- bzw. exportiert werden. Es ist darauf
zu achten, dass Filesysteme nicht fr alle schreibbar exportiert werden.
- Wenn zum Einsatz von NIS keine Alternativen existieren, sollte NIS+
eingesetzt werden, das ber erweiterte Sicherheitsmechanismen verfgt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wenn tftp verfgbar sein muss, dann sollte es mit der Option -s gestartet
werden, damit nicht jede Datei vom System kopiert werden kann (siehe
auch M 5.21 Sicherer Einsatz von telnet, ftp, tftp und rexec und M 5.72
Deaktivieren nicht bentigter Netzdienste).
- Die Protokollierungsfunktion des inetd sollte mit -t aktiviert werden, damit
jeder Verbindungsaufbauversuch protokolliert wird (vgl. M 5.72
Deaktivieren nicht bentigter Netzdienste). Hilfreich ist die Installation der
Public-Domain-Tools xinetd oder TCP-Wrapper. Mit diesen Tools knnen
u. a. alle Verbindungsversuche frhzeitig protokolliert werden, noch bevor
der angesprochene Daemon via inetd gestartet wird.
- Protokolldateien sollten tglich bzw. wchentlich untersucht werden. Zur
halb-automatischen Auswertung sollten Analyseprogramme wie swatch,
logdaemon oder logsurfer installiert werden (vgl. M 2.64 Kontrolle der
Protokolldateien).
- Regelmig sollten Sicherheitschecks mit USEIT, COPS, Tripwire oder
Tiger durchgefhrt werden.
- Neben allen anderen nicht bentigten Diensten sollten rshd, rlogind,
rexecd unbedingt deaktiviert werden (vgl. M 5.72 Deaktivieren nicht
bentigter Netzdienste). Zur Konvertierung von RPC-Programmnummern
in Portadressen wird von den meisten Herstellern das Programm rpcbind
mit ausgeliefert. Als Ergnzung bzw. als Ersatz sollte der Daemon
portmapper eingesetzt werden, wenn er fr die vorliegende Plattform
verfgbar ist.
Alle Clients, die diese Dienste benutzen, sollten fr normale Anwender
nicht ausfhrbar gemacht werden. Weitere Authentisierungsverfahren, die
auf Hostnamen beruhen, sollten vollkommen abgelst werden.
- Telnet sollte durch ssh ersetzt werden. ssh ermglicht eine stark verschls-
selte und authentisierte interaktive Verbindung zwischen zwei Systemen.
ssh ist als Ersatz fr telnet, rsh, rlogin und rcp zu verstehen. X-Windows
kann dadurch auch abgesichert bertragen werden (siehe auch M 5.64
Secure Shell).
- Xauth ist xhost vorzuziehen - es sollte niemals "xhost +" verwendet werden
(siehe auch M 4.9 Einsatz der Sicherheitsmechanismen von X-Windows).
- Aus der Konfigurationsdatei /etc/inetd.conf sollten alle nicht bentigten
Eintrge entfernt werden (siehe M 5.72 Deaktivieren nicht bentigter
Netzdienste).
- Die Konfigurationsdatei /etc/syslog.conf ist fr die Aktivierung der
Protokollfunktionen zu modifizieren (siehe M 4.106 Aktivieren der
Systemprotokollierung).
- Eine Liste aller world-writable Dateien und Verzeichnisse kann mit
folgenden Befehlen erstellt werden:
find / -type f -perm -22 -exec ls -l {} \;
find / -type d -perm -22 -exec ls -ld {} \;
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Ergebnisse sollten regelmig mit dem Installationszustand verglichen

werden.
- Die Programme Tripwire oder USEIT sollten vor der Inbetriebnahme
installiert werden, um eine Checksummenbersicht des installierten
Systems bei der Aufnahme in den Wirkbetrieb zu bekommen. Die erstellte
bersicht sollte auf einem nichtbeschreibbaren Datentrger gespeichert
werden.
- /var sollte eine groe Partition sein, damit ein vorstzliches Produzieren
von Protokolldaten das Unix-System nicht zum Stillstand bringt.
Alle durchgefhrten Vernderungen sollten sorgfltig dokumentiert werden
und unter allen Systemadministratoren abgestimmt werden. Diese Dokumen-
tation kann in Papierform erfolgen oder in einer Datei auf dem jeweiligen
System gefhrt werden. Sie sollte aber jederzeit eingesehen und aktualisiert
werden knnen (siehe auch M 2.34 Dokumentation der Vernderungen an
einem bestehenden System).
- Welche Dienste laufen auf dem IT-System?
- Sind alle verfgbaren Security-Patches ordnungsgem installiert?
- Werden alle nderungen zeitnah dokumentiert und unter allen System-
administratoren abgestimmt?
- Sind alle vorgenommenen nderungen an der Betriebssystemkonfiguration
dokumentiert und nach einer Neuinstallation nachvollziehbar?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.106 Aktivieren der Systemprotokollierung

Die systemeigene Unix-Protokollierung syslog dient dem Festhalten von
Informationen, die vom Betriebssystem oder von Anwendungsprozessen
generiert werden. Sicherheitsrelevante Ereignisse, wie versuchte Anmeldung
bzw. Ausfhrung des Befehls su sollten unbedingt protokolliert werden und
einer spteren Auswertung zur Verfgung stehen.
Der erforderliche Daemon syslogd wird in der Regel automatisch gestartet und
ber die Datei /etc/syslog.conf konfiguriert. Durch geeignete Rechtevergabe
muss sichergestellt werden, dass nur Systemadministratoren diese Datei
ndern knnen und dass die Protokolldateien in /var/log und /var/adm nur von
Systemadministratoren gelesen werden knnen. Alle nderungen an
/etc/syslog.conf sind zu dokumentieren. Bei der Anpassung an das vorliegende
IT-System sollte zunchst alles protokolliert werden, danach knnen bei
Bedarf stufenweise einzelne Bereiche deaktiviert werden. Durch eine aus-
reichende Dimensionierung der /var-Partition ist sicherzustellen, dass aus-
reichend Platz fr die Protokolldateien zur Verfgung steht. Das folgende
Beispiel fr eine Konfigurationsdatei ist in Anlehnung an eine SunOS-
Konfiguration erstellt worden und definiert eine ausfhrliche Protokollierung
in verschiedenen Dateien.
#ident "@(#)syslog.conf 1.3 93/12/09 SMI" /* SunOS 5.0 */
#
# Alle Meldungen werden zu einem Loghost geschickt, der in der Datei
# /etc/hosts definiert werden muss.
#
# Es muss TAB als Separator verwendet werden!
#
# Test: . syslogd mit der Option "-d" starten
# . syslogd mit kill -HUP nach jeder nderung dieser Datei starten
# . die Logdatei muss vor dem Start/Neustart bereits existieren
# . mit/usr/ucb/logger knnen Testmeldungen fr jede facility
# und priority generiert werden
#
*.err;kern.warning;auth.err;daemon.err /dev/console
*.alert;kern.err;daemon.err operator
*.alert root
# zeigt emerg-Meldungen auf Terminals an (verwendet WALL)
*.emerg *
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
#
kern.info ifdef(`LOGHOST, /var/log/kernlog, @loghost)
user.info ifdef(`LOGHOST, /var/log/userlog, @loghost)
mail.info ifdef(`LOGHOST, /var/log/maillog, @loghost)
daemon.info ifdef(`LOGHOST, /var/log/daemonlog, @loghost)
auth.info ifdef(`LOGHOST, /var/log/authlog, @loghost)
lpr.info ifdef(`LOGHOST, /var/log/lprlog, @loghost)
news,uucp.info ifdef(`LOGHOST, /var/log/newslog, @loghost)
cron.info ifdef(`LOGHOST, /var/log/cronlog, @loghost)
#
## alle anderen "local" Nachrichten, fr eigene Programme

local0,local1.info ifdef(`LOGHOST, /var/log/locallog, @loghost)
local2,local3,local4.info ifdef(`LOGHOST, /var/log/locallog, @loghost)
local5,local6,local7.info ifdef(`LOGHOST, /var/log/locallog, @loghost)
#
# alle Alarme und hher werden in eine separate Datei geschrieben:
*.err ifdef(`LOGHOST, /var/log/alertlog, @loghost)
#
# Beispiel Log levels:
# ------------------------------------
# su root failed for .. auth.err
# ROOT LOGIN REFUSED ON ... auth.err
# su root succeeded for.. auth.notice
- Sind die nderungen in /etc/syslog.conf dokumentiert worden?
- Ist sichergestellt, dass nur der Systemadministrator die Konfiguration
ndern darf?
- Ist sichergestellt, dass die Protokolldateien in /var/log bzw. /var/adm nur
fr den Systemadministrator lesbar sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.107 Nutzung von Hersteller-Ressourcen

Alle Hersteller von IT-Systemen oder IT-Komponenten bieten diverse Unter-
sttzungs- und Informationsangebote fr die Anwender ihrer Produkte. Dazu
gehren beispielsweise Hilfestellungen zur Problembehebung (Support,
Hotline, Updates, Patches, etc.) und Informationsmglichkeiten ber Sicher-
heitslsungen (WWW-Seiten, Newsgroups, Mailinglisten, etc.). Einige dieser
Angebote sind kostenfrei, andere nicht.
Bereits bei der Beschaffung von IT-Systemen oder -Produkten sollte berlegt
werden, welche Untersttzungsangebote der Hersteller in Anspruch genom-
men werden sollen, insbesondere wenn dies laufende Kosten verursacht.
Es sollte sichergestellt sein, dass fr alle eingesetzten IT-Systeme und
-Produkte regelmig berprft wird, ob neue Informationen ber Sicher-
heitsprobleme und Lsungsmglichkeiten seitens der Hersteller vorhanden
sind. Dies ist besonders bei allen Server-Betriebssystemen wichtig, da eine
Sicherheitslcke auf einem Server wesentlich mehr Schden verursachen kann
als eine, die nur ein einzelnes IT-System betrifft.
Sicherheitsspezifische Updates sollten, wenn sie nicht direkt vom Hersteller
auf CD-ROM geliefert werden, nur von vertrauenswrdigen Stellen bezogen
werden, z. B. von CERTs (siehe auch M 2.35 Informationsbeschaffung ber
Sicherheitslcken des Systems). Die Updates sind auf Unversehrtheit mittels
kryptographischer Methoden (MD5, PGP) zu berprfen, soweit die Dateien
entsprechend verschlsselt bzw. signiert angeboten werden.
Damit jederzeit auf sicherheitsrelevante Hinweise der Hersteller zugegriffen
werden kann, sollte fr alle eingesetzten Betriebssysteme und alle wichtigen
IT-Produkte eine bersicht gefhrt werden. Aus dieser sollte hervorgehen,
unter welchen WWW-Adressen sicherheitsspezifische Updates und Patches
bzw. Informationen der Betriebssystemhersteller gefunden werden knnen.
Dafr kann z. B. eine Tabelle wie die Folgende genutzt werden, die einen
berblick ber die entsprechenden Links zu bekannten Server-Betriebs-
systemen gibt. Die Tabelle enthlt zu dem jeweiligen Hersteller in der mit U
gekennzeichneten Zeile Adressen zu (sicherheitsspezifische) Updates und
Patches und in der mit I gekennzeichneten Zeile Adressen mit sicherheits-
spezifischen Informationen.
Berkeley Software Design, Inc. - BSD/OS

U ftp://ftp.bsdi.com/bsdi/patches/
I http://www.bsdi.com/services/support/
Caldera OpenLinux
U ftp://ftp.caldera.com/pub/openlinux/updates/
I http://www.calderasystems.com/support/security/
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Debian Linux
U http://cgi.debian.org/www-master/debian.org/security/ (deutsch)
http://cgi.debian.org/www-master/debian.org/
security/index.en.html (englisch)
I http://www.debian.org/security
http://www.debian.org/security/index.en.html
Digital Equipment Corporation - DEC
U http://www.service.digital.com/patches/
I http://www.unix.digital.com/
The FreeBSD Project -- FreeBSD
U ftp://ftp.FreeBSD.org/pub/FreeBSD/
I http://www.freebsd.org/security/security.html
Hewlett Packard -- HP
U http://europe-support.external.hp.com/
http://us-support.external.hp.com/
ftp://ftp.hp.com/pub/security/patches/
I http://europe-support.external.hp.com/
http://us-support.external.hp.com/
IBM
U http://service.software.ibm.com/aixsupport/
I http://www.ers.ibm.com/tech-info/index.html
The Open BSD Project -- OpenBSD
U http://www.openbsd.org/errata.html
I http://www.openbsd.org/security.html
RedHat Linux
U ftp://www.redhat.com/pub/updates/
http://www.redhat.com/download/mirror.html
http://www.redhat.com/corp/support/errata/index.html
I http://www.redhat.com/LinuxIndex/Administration/Security/
S.u.S.E. Linux
U ftp://ftp.suse.de/pub/suse_update/
I http://www.suse.de/de/support/security/index.html (auch englisch)
Santa Cruz Operation -- SCO
U ftp://ftp.sco.com/SSE/
I http://www.sco.com/security/
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Silicon Graphic Inc. -- SGI

U ftp://sgigate.sgi.com/patches/
I http://www.sgi.com/Support/security/security.html
Sun MicroSystems Inc. -- Sun
U http://sunsolve.sun.de/pub-cgi/us/pubpatchpage.pl
http://sunsolve.sun.com/pub-cgi/us/pubpatchpage.pl (abhngig von
Adresse des lokalen SunSolve Servers)
I http://sunsolve.sun.de/sunsolve/securitypub.html
http://sunsolve.sun.com/sunsolve/securitypub.html (abhngig von
Adresse des lokalen SunSolve Servers)
NT
U http://www.microsoft.com/security/
I http://www.microsoft.com/security/
Novell
U http://support.novell.de/
http://support.novell.com
I http://www.novell.com/corp/security/
Leider verndern sich Links erfahrungsgem hufig, so dass es wichtig ist,
diese regelmig auf ihre Korrektheit zu berprfen und, wenn es erforderlich
ist, zu aktualisieren. Fr die Inhalte, die sich unter den oben beispielhaft
angegebenen Links finden, kann daher selbstverstndlich auch keine Verant-
wortung bernommen werden.
- Woher werden Hersteller-Patches bezogen?
- Wie ist sichergestellt, dass immer die Informationen ber die aktuellsten
Patches vorliegen?
- Wie wird der Patch-Level-Stand der Systeme verifiziert?
- Wird die Integritt der Patches kryptographisch verifiziert (PGP, MD5)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.108 Vereinfachtes und sicheres Netzmanagement

mit DNS Services unter Novell NetWare 4.11
Jedem IT-System in einem TCP/IP-Netz muss eine eindeutige Adresse Verknpfung zwischen
IP-Adressen und Host-
zugewiesen werden. Das Internet Protocol (IP) beschreibt diese Adresse als namen
vier Dezimalzahlen getrennt durch einen Punkt, mit jeweils einem Werte-
bereich von 0-255. Da sich numerische Adressen schwer merken lassen,
knnen den IT-Systemen zustzlich erklrende Hostnamen, z. B.
www.bsi.bund.de, zugewiesen werden. Die Auflsung von Hostnamen in IP-
Adressen kann ber zwei Mechanismen durchgefhrt werden. Zum einen kann
eine ASCII-Textdatei namens HOSTS, die im SYS:ETC Verzeichnis abgelegt
wird, manuell erstellt werden. Diese Methode sollte unter sicher-
heitstechnischen und administrativen Gesichtspunkten nur in kleinen Netzen
angewandt werden, da diese Datei individuell auf jedem Server und jeder
Workstation abgelegt werden muss, um eine lokale Auflsung zu ermg-
lichen. Durch spezielle Routinen (z. B. Login Scripts) kann die Verteilung der
HOSTS Datei automatisiert werden.
Der zweite Mechanismus ist die Nutzung eines DNS-Servers. Im folgenden
werden einige Aspekte der Einrichtung und Konfiguration eines DNS-Servers
unter Novell NetWare 4.11 betrachtet, die im Hinblick auf die Sicherheit des
Systems besonders zu beachten sind.
Funktion der DNS-Komponenten
Die zwei Hauptbestandteile von DNS sind zum einen der Nameserver, zum
anderen der Resolver, der auf dem Client geladen wird und die Anfragen an
den Nameserver stellt.
- Primrer Nameserver
Er erhlt die DNS-Eintrge fr die Zonen, fr die er autorisiert ist, aus ein primrer Nameserver
pro Zone
einer Datei auf seiner Festplatte. Autorisiert bedeutet, dass der primre
Nameserver die DNS-Information nicht mit einem weiteren Nameserver
der Zone gegenprfen muss. Der primre Nameserver ist gleichzeitig auch
der Single Point of Administration fr die Domne. Es existiert nur ein
primrer Nameserver fr jede Zone.
- Sekundrer Nameserver
Dieser Server besitzt eine schreibgeschtzte Kopie der DNS-Datenbank Lastverteilung, Redu-
zierung des Netzver-
des primren Nameservers. Aktualisiert wird diese Kopie in einem defi- kehrs und Redundanz
nierten Zeitraum, der in dem Record Typ SOA (Start of Authority) festge-
legt wird. Record Typen definieren die Resource Records, die die Eintrge
in der DNS-Datenbank bilden. Der Kopiervorgang wird Zonentransfer
genannt und bildet die Grundlage fr die Aktualisierung der verteilten
DNS-Datenbank einer Domne. Sekundre Nameserver bernehmen
Aufgaben der Lastenverteilung, bieten die Mglichkeit, die DNS-Daten-
bank in der Nhe der Resolver zur Verfgung zu stellen, und schaffen die
Redundanz der DNS-Domneninformation. Mindestens ein sekundrer
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Nameserver sollte aus Grnden der Ausfallsicherheit fr jede Zone einge-

richtet werden.
- Resolver
Der Resolver ist die Software, die DNS-Anfragen an einen der definierten Anfragen an den DNS-
Server und Interpretation
Nameserver sendet. Dabei kann ein Nameserver, der die Namensauflsung der Antworten
nicht durchfhren kann, ebenfalls zum Resolver werden und die Anfrage
an einen Nameserver auerhalb der Domne senden. Der Resolver ber-
nimmt ebenfalls die Interpretation der Antworten des Nameservers und
gibt Informationen an die Programme zurck, die diese angefordert haben.
Einrichten des DNS-Servers
DNS wird bei einem NetWare 4.11 Server ber UNICON.NLM eingerichtet. drei Nameserver ein-
tragen
Zunchst wird ber Manage Global Objects unter Configure Server Profile
der DNS Client Access aktiviert. Es muss zumindest ein Nameserver aufge-
fhrt werden, der die Adressauflsung durchfhrt. Maximal knnen drei
Nameserver eingetragen werden. Damit ein groer Adressbereich schneller
erfasst werden kann und es sichergestellt ist, dass die Namensauflsung
durchgefhrt werden kann, sollten die Angaben fr die drei Nameserver
ausgeschpft werden. Die Reihenfolge der Nameserver bestimmt die
Abfragereihenfolge und sollte im Hinblick auf die Geschwindigkeit der
Namensauflsung festgelegt werden.
Der erste Nameserver kann der Haupt-DNS-Server der Behrde bzw. des
Unternehmens sein. Auch wenn dieser Server nicht jeden Host auerhalb der
eigenen Domne adressieren kann, bietet er die Mglichkeit, die Auflsung
von Hostnamen innerhalb der Organisation schnell durchfhren zu knnen.
Der zweite Nameserver kann der des Internet Service Providers (ISP) sein, um
Zugang zu einem umfangreicheren Datenbestand an Hostnamen zu
bekommen. Die Auflsungsgeschwindigkeit wird dabei durch die hhere
Auslastung, die Entfernung sowie die zur Verfgung stehende Bandbreite
meist etwas geringer sein als beim lokalen Nameserver. Hat die Redundanz
der eigenen Domne Prioritt, so sollte der Server mit der schreibgeschtzten
Kopie der DNS-Datenbank (sekundrer Nameserver) als zweiter Nameserver
eingetragen werden.
Der dritte definierte Nameserver kann ein sogenannter Root Server sein. Auf
diesen Servern sind die Daten aller registrierten Domnen abgelegt. Eine Liste
der Root Server kann unter ftp://rs.internic.net/netinfo/root-servers.txt
abgerufen werden.
Konfiguration der DNS-Server
Im Hauptmen von UNICON.NLM gelangt man ber Manage Services und
DNS zu den Konfigurations- und Administrationsfunktionen fr das Domain
Name System. Der Menpunkt Administer DNS erlaubt sowohl das Einrichten
einer Master Database als auch einer schreibgeschtzten Replica Database.
Die Domnen bzw. Zonen, fr die der primre Nameserver autorisiert ist,
werden im Hauptmen von UNICON.NLM ber Manage Services - DNS -
Administer DNS - Manage Master Database - Delegate Subzone Authority
eingegeben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
ber Manage Services - DNS - Administer DNS - Manage Master Database alle sekundren Name-
werden die DNS-Datenbankeintrge eingegeben. Bei einer Standard server in die Datenbank
Implementation von DNS mssen der Start of Authority (SOA), der den eintragen
Beginn fr die Autoritt einer Zone innerhalb der DNS-Hierarchie kennzeich-
net, und der Record Typ Name Server (NS) eingetragen werden. Der primre
Nameserver muss Eintrge fr alle sekundren Nameserver der Zone enthal-
ten. Die Verbindung dieser Zone zur DNS-Hierarchie wird durch Nameserver
Eintrge fr primre Nameserver, die Autoritt fr bergeordnete oder unter-
geordnete Zonen besitzen, sichergestellt. Damit die Namensauflsung fr die
Hosts in der Zone gewhrleistet ist, muss fr jedes zu adressierende Endgert
der Record Typ Address (A) eingetragen werden.
Innerhalb des Record Typ SOA werden unter anderem der Name und die
Adresse des Zonen-Verantwortlichen (Zone Supervisor) eingetragen.
Standardmig ist diese Adresse auf root.<domain_name> gesetzt. Weiterhin
werden im Record Typ SOA die Einstellungen fr das Synchronisations-
verhalten der sekundren Nameserver getroffen.
Refresh Validity Period bestimmt die Zeit, innerhalb der ein sekundrer
Nameserver noch Anfragen von Hosts beantwortet, nachdem er vergeblich
versucht hat, den primren Nameserver zu kontaktieren. Je krzer diese Zeit
eingestellt ist, desto geringer ist die Wahrscheinlichkeit, dass der sekundre
Nameserver ungltige DNS-Eintrge verschickt und so keine Namensauf-
lsung mglich ist. Aus Grnden der Ausfallsicherheit sollte diese Zeit nicht
zu kurz eingestellt werden, da bei einem Ausfall des primren Nameservers
das Domain Name System fr diese Zone dann nicht mehr funktioniert. Fr
diesen Parameter muss ein Kompromiss gefunden werden zwischen der
Wahrscheinlichkeit, einzelne Hostnamen nicht auflsen zu knnen, oder - bei
zu kurzer Periode - keine Endgerte ber individuelle Hostnamen ansprechen
zu knnen.
Das Minimum Caching Interval bestimmt die Zeit, in der Informationen aus
Anfragen im Cache des primren Nameserver gehalten werden. Wird diese
Einstellung zu kurz gewhlt, kann dies die Netzlast bei hufigen Anfragen
nach denselben Hosts erhhen und die Auflsung der Hostnamen in IP-
Adressen verzgern. Auf der anderen Seite kann ein zu groer Wert fr das
Minimum Caching Interval dazu fhren, dass veraltete Informationen weiter-
gegeben werden.
Verbindung zur externen DNS-Hierarchie
Anfragen ber Hostadressen auerhalb der eigenen Domne werden auto- Querverbindungen zur
Beschleunigung der
matisch durchgefhrt, sobald der DNS-Server luft. Informationen ber die Namensauflsung
DNS-Hierarchie erhlt der DNS-Server aus der Datei
SYS:ETC\DNS\ROOT.DB, die eine Liste ber Nameserver der US Top Level
Domnen enthlt. Unter dem Menpunkt Manage Services - DNS - Administer
DNS - Link to existing DNS Hierarchy kann ber zwei verschiedene
Methoden, nmlich Link Direct und Link Indirect via Forwarder, eine
Querverbindung zu anderen Domnen aufgebaut werden. Wird hufig auf
bestimmte Domnen zugegriffen, kann ber diese Verfahren die Auflsung
der Hostnamen beschleunigt werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Prfen von Nameservern

Mit Manage Services - DNS - Administer DNS - Query Remote Name Server
kann zum einen berprft werden, welche Informationen auf anderen Name-
servern abgelegt sind, und zum anderen ist es mglich festzustellen, ob ein
bestimmter Nameserver auf Anfragen antwortet. Dabei muss der Name bzw.
die IP-Adresse des Servers angegeben werden. Ebenso ist der Resource
Record Type, der abgefragt wird, und die Domne, aus der die Information
bentigt wird, anzugeben.
Backup der DNS-Datenbank
Regelmig sollte ein Backup der DNS-Datenbank angelegt werden. Dieses
Backup kann beispielsweise verwendet werden, um
- eine unbrauchbar gewordene DNS-Datenbank wiederherzustellen,
- die Datenbank auf einen anderen Server zu verschieben.
ber Manage Services - DNS - Save DNS Master to Text Files wird die
Datenbank in SYS:ETC/DBSOURCE/DNS/HOSTS abgelegt.
Verwendung von UNICON.NLM
Mit UNICON werden u. a. die Einstellungen fr das Domain Name System Zugriffsbeschrnkungen
vornehmen
getroffen. Aus administrativen und sicherheitstechnischen Gesichtspunkten ist
es unter Umstnden erforderlich, eine Aufgabenverteilung und Zugriffs-
beschrnkung vorzunehmen. Bei der Installation eines NetWare Produktes,
das ber UNICON gesteuert wird, werden im NDS-Verzeichnisbaum
Gruppenobjekte angelegt, die bestimmte Aufgabenbereiche innerhalb von
UNICON regeln. Benutzer, die bestimmte Aufgaben mit UNICON durch-
fhren sollen, werden der jeweiligen Gruppe als Mitglied zugefgt.
Gruppenname Verantwortungsbereich Zugngliche UNICON

Men Optionen
UNICON Voller Umfang von Zugang zu allen Men
MANAGER UNICON Optionen
UNICON SERVICES Starten, Anhalten und Start/Stop Services und

MANAGER Verwalten der Services Manage Services
UNICON HOST Verndern von Host Manage Global Objects -

MANAGER Eintrgen Manage Hosts
Kompatibilitt mit bind (Berkeley Internet Name Domain)

TCP/IP-Netze entwickelten sich aus der Unix-Umgebung heraus. Das am
weitesten verbreitete DNS-Programm fr Unix ist bind. Deshalb ist es wichtig,
dass andere DNS-Produkte auf bind abgestimmt sind. Der DNS-Service von
Novell ist mit der bind-Version 4.8.3 voll kompatibel.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.109 Software-Reinstallation bei

Arbeitsplatzrechnern
Bei Arbeitsplatzrechnern kann es hufiger zu Problemen mit dem Betriebs-
system oder den Anwendungen kommen, die nur durch den Benutzersupport
wieder behoben werden knnen. Dies kann z. B. durch Softwarefehler,
Konfigurationsnderungen, Aufspielen neuer Software oder Computer-Viren
verursacht werden.
Damit die Administratoren bei den oben beschriebenen Problemen auf den Standardkonfiguration
wiederherstellen
Benutzerrechnern nicht zeitaufwendig nach Fehlern suchen mssen, sollte eine
Software-Reinstallation der Standardkonfiguration vorgenommen werden.
Dafr muss zunchst der Rechner eindeutig identifiziert werden und dann ber Identifikation des IT-
Systems
eine entsprechende Dokumentation oder ein Programm anhand dieser
Identifikation genau ermittelt werden, welche Software in welcher Konfigu-
ration auf genau diesem Rechner installiert werden muss. Dabei ist es hilf-
reich, wenn sich die Systeme weitestgehend gleichen, zumindest in Bereichen
mit hnlicher Aufgabenstellung.
Es empfiehlt sich, die Festplatte des Arbeitsplatzrechners neu zu formatieren
und anschlieend die erforderliche Software und Daten neu aufzuspielen.
Eine Software-Reinstallation kann auf verschiedene Weise durchgefhrt zeitkritische
Reinstallation
werden, so gibt es z. B. spezielle Programme, die eine vorgegebene Konfigu-
ration von einem Server auf den neu zu installierenden Arbeitsplatzrechnern
berspielen. Hierbei ist zu beachten, dass solche Arbeiten meist in zweierlei
Hinsicht zeitkritisch sind: Die Neueinrichtung sollte mglichst schnell erfol-
gen knnen, damit das IT-System wieder verfgbar ist, und das Netz sollte
mglichst wenig belastet werden. Dies ist insbesondere bei Schulungsrechnern
oder PC-Pools wichtig.
Natrlich kann eine Reinstallation auch "von Hand" vorgenommen werden.
Zu diesem Zweck sollte als erstes eine Standardinstallation vorgenommen
werden. Im Anschluss daran werden die Besonderheiten der einzelnen
Rechner kopiert, wie spezielle Gertetreiber, andere Konfigurationsdateien
oder spezielle Software. Dafr mssen diese allerdings vorkonfiguriert
verfgbar sein, z. B. auf dem Netz oder auf mobilen Datentrgern. Ein
aktuelles Viren-Suchprogramm muss anschlieend zum Einsatz kommen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.110 Sichere Installation des RAS-Systems

Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement-Team
Nachdem im Rahmen organisatorischer Vorarbeiten die zur Realisierung not-
wendige Hard- und Software beschafft worden ist, mssen die einzelnen
Komponenten installiert und betrieben werden. In der Regel kann das RAS-
System in Folge nur dann sicher betrieben werden, wenn schon bei der Instal-
lation sorgfltig verfahren wird. Voraussetzung fr eine sichere Installation ist
die Auswahl geeigneter Hard- und Software fr den RAS-Zugang (Qualitt,
Interoperabilitt, Konformitt zu bestehenden Standards) durch den vorange-
gangenen Entscheidungsprozess (siehe M 2.186 Geeignete Auswahl eines
RAS-Produktes). Dies unterstreicht nochmals die Wichtigkeit eines geregelten
Entscheidungsprozesses.
Die physikalischen Komponenten eines RAS-Systems bestehen aus her-
kmmlichen IT-Systemen: meist aus mindestens einem Server und mehreren
Clients, Netzkoppelelementen, Modems oder anderen technischen Gerten.
Fr diese muss die physikalische Sicherheit, wie fr alle anderen Komponen-
ten eines Rechnernetzes, gewhrleistet werden. Daher sind zunchst die
generellen Sicherheitsmanahmen fr jede dieser Komponenten durchzu-
fhren, wie sie in den Kapiteln 3 bis 9 beschrieben sind.
Im Rahmen der Installation sollten folgende zustzliche Punkte Beachtung
finden:
- Weder das RAS-System noch Teile davon sollten whrend der Installati-
onsphase fr Benutzer oder fremde Dritte zugreifbar sein. Es sollten also
keine Verbindungen zum produktiven LAN und kein Anschluss an TK-
Systeme aktiv sein.
- Die Installation ist durch qualifiziertes Personal durchzufhren.
- Die Installation sollte gem der RAS-Systemplanung erfolgen.
- Die Installation und Konfiguration ist zu dokumentieren. Dies kann entwe- Sorgfltige
Dokumentation der
der durch eine separate Installationsdokumentation erfolgen, oder aber Installation
durch eine Besttigung, dass die Installation mit den Planungsvorgaben
bereinstimmt.
- Ergibt sich im Rahmen der Installation eine Abweichung von den
Planungsvorgaben (z. B. genderte Leitungsfhrung, zustzliche Gerte),
so sind diese zu dokumentieren und ein begrndeter nderungsvermerk in
die Planungsunterlagen zu bernehmen. Diese Dokumentation ist auch im
Hinblick auf die Verbesserung zuknftiger Planungen besonders wichtig.
- Das korrekte Funktionieren jeder einzelnen Komponente muss festgestellt
werden (z. B. durch Funktionsprfung bzw. Selbsttest).
- Fr jede sicherheitsrelevante Einstellung muss ein Funktionstest der
Sicherheitsmechanismen durchgefhrt werden. Beispielsweise sollte die
Kommunikationsverschlsselung mittels eines Netzanalysators berprft
werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Das korrekte Funktionieren des Gesamtsystems ist nach Abschluss der Systemtest vor Freigabe
Installationsarbeiten zu berprfen (Abnahme und Freigabe der Installa-
tion). In der Regel muss dies durch vorgegebene Abnahmekonfigurationen
und nachgestellte Nutzungsszenarien erfolgen. Bei den Tests ist darauf zu
achten, dass nur die zum Test befugten Personen Zugriff zum RAS-System
erhalten.
Die Installation eines RAS-Systems sollte mit einer sicheren Anfangskonfigu-
ration abgeschlossen werden, die zunchst nur den berechtigten Administra-
toren Zugriffe erlaubt (siehe auch M 4.111 Sichere Konfiguration des RAS-
Systems). Diese berfhren das RAS-System dann in einen sicheren Betriebs-
zustand. Ist dieser erreicht, kann der laufende Betrieb aufgenommen werden.
Beispiel:
Unter Windows NT gestaltet sich die Installation von RAS-Server und RAS-
Client sehr einfach und weist kaum Unterschiede auf, da der RAS-Dienst von
Windows NT sowohl Client- als auch Server-Funktionen enthlt.
Fr einen RAS-Client unter Windows NT gilt:
- Die Server-Funktionen des RAS-Dienstes mssen deaktiviert werden. Dies
erfolgt dadurch, dass auf allen Gerten, die fr Remote Access verwendet
werden knnen (z. B. Modem, ISDN-Karte, VPN-Adapter), nur ausgehen-
de Anrufe erlaubt werden. Zu den entsprechenden Dialogfeldern gelangt
man ber die Optionen Systemsteuerung, Netzwerk, Dienste, RAS-Dienst,
Gert, Konfigurieren.
- Fr den RAS-Client sind nur die ber Remote Access zugelassenen Proto-
kolle freizugeben. Dies geschieht ber Systemsteuerung, Netzwerk,
Dienste, RAS-Dienst, Gert, Netzwerk.
- Die Eigenschaften einer RAS-Verbindung werden ber das DF-Netzwerk
von Windows NT festgelegt. Hier sind die gem RAS-Sicherheitskonzept
notwendigen Parameter einzustellen (z. B. Datenverschlsselung erforder-
lich).
Fr einen RAS-Server unter Windows NT gilt:
- Die Client-Funktionen des RAS-Dienstes mssen deaktiviert werden. Dies
erfolgt dadurch, dass auf allen Gerten, die fr Remote Access verwendet
werden knnen, nur eingehende Anrufe erlaubt werden.
- Fr den RAS-Server sind nur die ber Remote Access zugelassenen Proto-
kolle freizugeben.
- Die gem RAS-Sicherheitskonzept notwendigen Parameter fr einge-
hende RAS-Verbindungen sind einzustellen. Dies geschieht ber System-
steuerung, Netzwerk, Dienste, RAS-Dienst, Gert, Netzwerk.
- Die Einwahl sollte nur berechtigten Benutzern gestattet werden. Dies kann
mit dem RAS-Manager oder dem Benutzermanager von Windows NT
erfolgen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind alle Abweichungen von den Planungsvorgaben fr das RAS-System
in den Planungsunterlagen vermerkt?
- Wurde ein Funktionstest der Sicherheitsmechanismen durchgefhrt (z. B.
berprfen der Kommunikationsverschlsselung mittels eines Netzana-
lysators)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.111 Sichere Konfiguration des RAS-Systems

Verantwortlich fr Initiierung: Leiter IT, IT-Sicherheitsmanagement-Team
Die Funktion und die Sicherheit eines RAS-Systems wird wesentlich durch
die eingestellten Konfigurationsparameter bestimmt. Da jedoch ein RAS-
System nicht aus nur einer Komponente und deren Konfiguration besteht,
ergibt sich naturgem eine erhhte Komplexitt fr die Gesamtkonfiguration.
Aufgrund dieser Komplexitt knnen leicht Konfigurationsfehler entstehen,
die die Sicherheit des Gesamtsystems verringern knnen. Das nicht
abgestimmte ndern eines Konfigurationsparameters bei einer Komponente
kann daher im Zusammenspiel mit den anderen Komponenten zu Fehlfunk-
tionen fhren. Im Extremfall kann dadurch auch die Sicherheit des LANs
Da die Konfiguration eines RAS-Systems in der Regel Vernderungen unter-
worfen ist (z. B. durch Personalnderungen, neue Nutzungsszenarien,
Systemerweiterungen), kann nicht davon ausgegangen werden, dass es genau
eine sichere (und statische) Konfiguration gibt, die einmal eingestellt und nie
wieder verndert wird. Vielmehr unterliegt die Konfiguration fortschreitenden
Versionsnderungen. Es ist Aufgabe der fr das RAS-System zustndigen
Administratoren, dass jeweils nur sichere Versionen der Systemkonfiguration
definiert werden und das System von einer sicheren Konfiguration in die
nachfolgende sichere Konfiguration berfhrt wird.
Generell kann zwischen den folgenden Konfigurationskategorien unter-
schieden werden:
- Die Default-Konfiguration ergibt sich durch die vom Hersteller vorein-
gestellten Werte fr die Konfigurationsparameter. Diese ist in der Regel
nicht ausreichend sicher und sollte daher nicht verwendet werden.
- Nach der Installation und vor der Inbetriebnahme muss - ausgehend von Voreinstellung muss
angepasst werden
der Default-Konfiguration - eine sichere Anfangskonfiguration durch die
Administratoren eingestellt werden. Hier sollten mglichst restriktive
Einstellungen gelten, so dass nur die berechtigten Administratoren
Vernderungen vornehmen knnen, um z. B. eine erste
Betriebskonfiguration einzustellen, die das geplante Sicherheitskonzept
umsetzt.
- Die sicheren Betriebskonfigurationen ergeben sich aus den jeweiligen
Konfigurationen im laufenden Betrieb. Hier muss auch regelmig
berprft werden, ob neu bekannt gewordene Sicherheitslcken
Anpassungen erfordern (siehe auch M 2.35 Informationsbeschaffung ber
Sicherheitslcken des Systems).
- Schlielich sollten sichere Notfallkonfigurationen im Rahmen der
Notfallplanung definiert und dokumentiert werden. Sie dienen dazu, auch
bei eingeschrnkter Betriebsfhigkeit die Sicherheit aufrechtzuerhalten. In
der Regel werden durch die Notfallplanung mehrere Notfallsituationen
definiert. Es empfiehlt sich, fr jede der definierten Situationen eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
adquate Notfallkonfiguration festzulegen. Im einfachsten Fall besteht die

Notfallkonfiguration darin, den Zugang zum RAS-System zu sperren.
Allgemein sollten folgende Punkte bei den gewhlten Einstellungen fr eine
sichere Konfiguration beachtet werden:
- Neben der Konfiguration des RAS-Systems kann auch die Aufteilung des Einrichtung von
Zugangsnetzen
Netzes in Teilnetze zur Zugriffssteuerung dienen. Aus Grnden der IT-
Sicherheit kann es daher zweckmig sein, so genannte Zugangsnetze
(Access-Networks) einzurichten (siehe auch M 5.77 Bildung von Teil-
netzen).
- Die Routing-Einstellungen der fr das RAS-System verwendeten Netz- Routing-Einstellungen
koppelelemente sollte zur restriktiven Steuerung des Netz-Verkehrsflusses
eingesetzt werden. Netzpakete drfen nur auf den erlaubten Verbindungen
weitergeleitet werden. Zustzlich erlauben moderne Netzkoppelelemente
das selektive Weiterleiten von Paketen innerhalb erlaubter Netzverbindun-
gen (Paketfilter-Funktion). Auf diese Weise kann z. B. erreicht werden,
dass ausschlielich Verbindungsanfragen an den HTTP-Dienst eines
Servers weitergeleitet werden.
- Das Einschrnken des Zugangs zu RAS-Clients ist insbesondere fr mobile
Rechner schwierig zu realisieren. Bei mobilen RAS-Clients ist es daher
besonders wichtig, dass sich die Benutzer strikt an die festgelegten
Regelungen halten (z. B. Diebstahlschutz, siehe auch Baustein 5.3
Tragbarer PC).
- Die sichere Konfiguration der RAS-Server-Software erfordert, dass die Nutzung vorhandener
Sicherheitsmechanis-
durch die Software angebotenen und im vorliegenden Einsatzszenario men
sinnvollen Sicherheitseinstellungen auch aktiviert sind und genutzt werden
knnen. Die Nutzung von bestimmten Sicherheitseinstellungen setzt u. U.
voraus, dass auch andere Komponenten des RAS-Systems entsprechende
Funktionen besitzen bzw. entsprechend konfiguriert werden knnen. So ist
z. B. bei der Nutzung der Rufnummernbertragung (Calling Line
Identification Protocol - CLIP) sicherzustellen, dass diese fr den
gewhlten Anschluss auch aktiviert ist. Damit die Benutzer-Identifikation
beispielsweise beim Zugriff ber das Internet ber X.509-Zertifikate
erfolgen kann, muss dem RAS-System der Speicherort der
Benutzerzertifikate bekannt sein. Dazu muss die RAS-Software entweder
externe Authentisierungsserver untersttzen oder eine eigene Zertifikats-
verwaltung anbieten.
Daher sollte vorab berprft werden, ob alle angebotenen
Sicherheitsmechanismen auch genutzt werden knnen oder ob hierzu
andere bzw. zustzliche Hard- oder Software bentigt wird. Im laufenden
Betrieb muss dann regelmig die Korrektheit der Einstellungen berprft
werden.
- Fr die sichere Konfiguration der RAS-Client-Software gelten hnliche Client-Konfiguration
Anforderungen wie fr die Server-Software. Zustzlich ist darauf zu
achten, dass zum RAS-Zugang bentigte Passwrter nicht durch die
Software gespeichert werden, auch wenn dies vielfach angeboten wird.
Wenn dies nicht technisch verhindert werden kann, muss es allen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Benutzern untersagt werden. Auerdem sollten alle Benutzer ber die

Problematik aufgeklrt werden.
- Damit Client und Server in sicherer Art und Weise kommunizieren
knnen, ist auf eine konsistente Konfiguration der beteiligten Kompo-
nenten zu achten (z. B. beim benutzten Verfahren zur Kommunikations-
absicherung).
- Die sichere und konsistente Konfiguration von Client und Server kann Einrichten von
standardisierten
dadurch untersttzt werden, dass eine Standardkonfiguration fr RAS- IT-Systemen
Clients (Hard- und Software) durch das RAS-Konzept festgelegt und durch
organisatorische Manahmen durchgesetzt wird. Dadurch wird erreicht,
dass nur eine feste Anzahl unterschiedlicher Client-Konfigurationen im
Einsatz ist. Dies erleichtert die gesamte Konfiguration, insbesondere hilft
es aber auch, eine sichere und konsistente Konfiguration
aufrechtzuerhalten.
- nderungen an der RAS-Systemkonfiguration sollten einem organisato- nderungsmanagement
rischen Prozess unterliegen, der sicherstellt, dass das RAS-System nur mit
geprften Konfigurationen aktiviert wird. Alle nderungen sollten
dokumentiert und genehmigt sein. Hinweis: Das Hinzufgen oder Lschen
von RAS-Benutzern macht in der Regel keine nderung der RAS-
Systemkonfiguration ntig, da diese nderungen oft durch die
Benutzerverwaltung des Betriebssystems (z. B. RAS unter Windows NT)
oder eines Authentisierungsservers (vgl. RADIUS, TACACS+) erfolgen.
- Die RAS-Konfiguration sollte regelmig berprft werden. Dabei ist Regelmige Prfung
der RAS-Konfiguration
sicherzustellen, dass alle Vorgaben der RAS-Sicherheitsrichtlinie umge-
setzt sind und die Einstellungen keine Schwachstellen aufweisen.
Obwohl RAS-Systeme eine recht einfache Aufgabe bernehmen, gestaltet sich
der Aufbau und der Betrieb hnlich komplex wie z. B. der eines Firewall-
Systems. Die hier angefhrten Themenbereiche sind daher immer im Rahmen
der RAS-Systemplanung und des RAS-Betriebes zu konkretisieren, zu erwei-
tern und anzupassen.
Beispiele:
- Unter Windows NT sollte die Berechtigung zum RAS-Zugriff nach der
Installation des RAS-Dienstes beschrnkt werden. Dies kann bei
Windows NT nur auf Benutzer-Ebene erfolgen, was bei vielen Benutzern
nicht mehr effizient ber den Benutzermanager zu administrieren ist. Das
Werkzeug zur RAS-Administration unter Windows NT erlaubt es hinge-
gen, auch allen Benutzern auf einmal die Einwahlberechtigung zu entzie-
hen.
- Fr einen RAS-Server sollte nur das Einwhlen erlaubt sein, abgehende
Verbindungen vom RAS-Server selbst sind in der Regel nicht notwendig
und sollten daher unterbunden werden. Unter Windows NT kann dies ber
den Eigenschaftsdialog des RAS-Dienstes fr jedes Gert, das fr Remote
Access geeignet ist (z. B. Modem, ISDN-Karte, VPN-Adapter),
konfiguriert werden. Zu den entsprechenden Dialogfeldern gelangt man
ber Systemsteuerung, Netzwerk, Dienste, RAS-Dienst, Gert,
Konfigurieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Bei Verwendung von RAS-Diensten sollten nur die Protokolle ber den
RAS-Zugang erlaubt werden, die auch tatschlich notwendig sind. Nicht
bentigte Protokolle sind entsprechend zu deaktivieren. Dies geschieht
unter Windows NT ber Systemsteuerung, Netzwerk, Dienste, RAS-Dienst,
Netzwerk, Servereinstellungen. Die Konfiguration der bentigten
Protokolle muss den Sicherheitsrichtlinien entsprechen, beispielsweise in
Bezug auf Authentisierung, Verschlsselung, IP-Adressbereich, lokaler
oder netzweiter Zugriff.
- Ist die RAS-Client-Software so konfiguriert, dass zum Zugang benutzte
Passwrter nicht gespeichert werden?
- Ist eine konsistente Konfiguration aller RAS-Komponenten sichergestellt?
- Wird die RAS-Konfiguration regelmig berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.112 Sicherer Betrieb des RAS-Systems

Voraussetzung fr den sicheren Betrieb eines RAS-Systems ist die sichere
Installation und Konfiguration der beteiligten Hard- und Software-Kompo-
nenten. Die Manahmen M 4.110 Sichere Installation des RAS-Systems und
M 4.111 Sichere Konfiguration des RAS-Systems mssen daher vor
Inbetriebnahme durchgefhrt worden sein. Zustzlich mssen alle
organisatorischen Ablufe definiert und umgesetzt worden sein (z. B.
Meldewege und Zustndigkeiten). Weiterhin ist zu beachten, dass die
angestrebte Systemsicherheit nur gewhrleistet werden kann, wenn auch die
physikalische Sicherheit der beteiligten Hardware-Komponenten sichergestellt
ist (siehe auch M 4.110 Sichere Installation des RAS-Systems).
Die Sicherheit eines RAS-Systems lsst sich grob in drei Bereiche aufteilen:
1. die Sicherheit des RAS-Servers,
2. die Sicherheit der RAS-Clients und
3. die Sicherheit der Datenbertragung.
Kann die gewnschte Sicherheit des RAS-Servers noch durch die Durch-
setzung einer lokalen Sicherheitsrichtlinie gesteuert werden, so unterliegt der
RAS-Client typischerweise nicht mehr der vollen Kontrolle des fr das LAN
verantwortlichen IT-Personals. Die Sicherheit der Datenbertragungsmedien
entzieht sich in der Regel vollstndig der Kontrolle. Aus diesem Grund muss
die Absicherung der Kommunikation zwischen Client und Server mit zustz-
lichen Mitteln erfolgen.
Im Umfeld des RAS-Servers sind folgende Empfehlungen fr den sicheren
Betrieb zu bercksichtigen:
- Der RAS-Zugang sollte durch den Einsatz von Protokollierungs- und berwachung des RAS-
Zugangs
Management-Werkzeugen einer stndigen berwachung unterliegen.
- Die im Rahmen der berwachung gesammelten Informationen sollten regelmige Auswertung
der Protokolldateien
regelmig durch einen geschulten Administrator kontrolliert werden. Er
sollte dabei nach Mglichkeit durch eine Software zur Auswertung von
Protokollierungsdaten untersttzt werden. Die Bestimmungen des Daten-
schutzes sind zu beachten (siehe auch M 2.110 Datenschutzaspekte bei der
Protokollierung).
- Werden Sicherheitsvorflle festgestellt, so sind sofort die vorher fest-
gelegten Manahmen zu ergreifen. Die festgestellten Sicherheitsvorflle
sollten in einem Vorfall-Report dokumentiert werden (siehe dazu auch
Baustein 3.8 Behandlung von Sicherheitsvorfllen).
- Damit eine geregelte Benutzer-Authentisierung (z. B. RAS unter
Windows NT, RADIUS, TACACS, TACACS+, SECURE-ID) beim RAS-
Zugriff mglich ist, muss die Konsistenz der Authentisierungsdaten
sichergestellt sein. Dies kann durch zentrale Verwaltung der Daten
(Authentisierungsserver) oder durch periodischen Abgleich geschehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Fr jede Verbindungsaufnahme ist immer die Benutzer-Authentisierung

ber den gewhlten Mechanismus durchzufhren. Insbesondere ist die
alleinige Nutzung des CLIP-Mechanismus (Rufnummernbertragung) zur
Authentisierung nicht ausreichend.
- Fr jede Verbindung sollte die Absicherung der Kommunikation durch
eines der im RAS-Sicherheitskonzept erlaubten Verfahren erzwungen
werden, damit die bertragenen Daten geschtzt sind.
- Die durch die Zugangstechnik zur Verfgung gestellten zustzlichen
Sicherheitsmechanismen (Nutzung der Rufnummernbertragung, Rckruf
einer voreingestellten Telefonnummer fr nicht mobile oder ber Mobil-
telefon angebundene RAS-Clients) sollten genutzt werden.
- Das RAS-System sollte in regelmigen Abstnden einer Revision unter- Revision
zogen werden. Die Rollen Administrator und Revisor drfen nicht der
gleichen Person zugeordnet werden.
- Die Anbindung eines tragbaren IT-Systems an ein LAN kann ber GSM Anbindung ber
Mobiltelefon
realisiert werden (siehe auch M 5.81 Sichere Datenbertragung ber
Mobiltelefone). Bei der Nutzung von RAS ber Mobiltelefon-Netze ist zu
beachten, dass sich der CLIP-Mechanismus (Rufnummernbertragung) in
der Regel nur als zustzliches Authentisierungsmerkmal eignet, da das ber
die Rufnummer identifizierte Mobiltelefon sehr leicht entwendet werden
kann.
Da RAS-Clients in der Regel in nicht vollstndig kontrollierten Umgebungen
betrieben werden, mssen fr diesen Fall spezielle Mechanismen, Verfahren
und Manahmen zum Einsatz kommen, die den Schutz des Clients gewhr-
leisten knnen. Insbesondere mobile RAS-Clients sind hier einer besonderen
Gefahr ausgesetzt, da diese physikalisch besonders leicht anzugreifen sind
(Diebstahl, Vandalismus). Ist ein RAS-Client kompromittiert, so besteht die
Gefahr, dass dadurch auch die Sicherheit des LANs beeintrchtigt wird.
Fr den sicheren Betrieb von RAS-Clients sind daher folgende Aspekte zu
bercksichtigen:
- Die Grundsicherheit des IT-Systems muss gewhrleistet werden (siehe
auch Bausteine 5.3 Tragbarer PC, 7.2 Modem, 8.6 Mobiltelefon und
9.3 Telearbeit).
- Da mobile RAS-Clients greren Risiken ausgesetzt sind als stationre, Festplattenver-
schlsselung
sollten diese durch zustzliche Manahmen gesichert werden. Hierzu bietet
sich eine Festplattenverschlsselung an, um sicherzustellen, dass von
abhanden gekommenen Gerten weder Daten ausgelesen noch unbefugt
eine RAS-Verbindung aufgebaut werden kann.
- Insbesondere beim RAS-Zugriff ber Internetverbindungen ist die Instal- aktuelle Computer-Viren-
Schutzprogramme
lation von Computer-Viren-Schutzprogrammen auf allen RAS-Clients
notwendig (siehe auch Baustein 3.6 Computer-Virenschutzkonzept).
- Es sollte berlegt werden, auf den RAS-Clients so genannte PC-Firewalls PC-Firewalls
einzusetzen und so vor unberechtigten Zugriffen aus dem Internet durch
Dritte zu schtzen. hnlich wie herkmmliche Firewalls (siehe Bau-
stein 7.3 Firewall) filtern PC-Firewalls die Pakete der Netzkommuni-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
kationsprotokolle. Die Filterregeln knnen jedoch meist dynamisch durch

den Benutzer erzeugt werden. Hierzu wird bei jedem Zugriff, fr den noch
keine Regel vorliegt, eine Auswahl an mglichen Reaktionen (z. B.
erlauben, ablehnen, bedingte Verarbeitung) angeboten, um eine neue Regel
zu definieren. Da es fr den Benutzer jedoch in vielen Fllen schwierig ist,
zwischen erlaubten und unberechtigten Zugriffen zu unterscheiden, sollte
der Regelsatz durch einen Administrator vorinstalliert werden.
- Auch RAS-Clients sollten in das Systemmanagement einbezogen werden, RAS-Clients in
Systemmanagement
soweit dies mglich ist. Dies erlaubt einerseits die berwachung der einbeziehen
Clients im Rahmen der Aufrechterhaltung des laufenden Betriebes. Ande-
rerseits knnen so einfach Software-Updates (Viren-Datenbanken,
Anwendungsprogramme) auf geregeltem Weg eingespielt werden.
Entfernte Rechner stellen jedoch erhhte Anforderungen an das System-
management, da diese nicht permanent mit dem Netz verbunden sind, so
dass die Rechner regelmig auf (unzulssige) Konfigurationsvernde-
rungen untersucht werden mssen. Hier kann - je nach Management-
produkt - die "Discovery"-Funktion genutzt werden, um den aktuellen
Zustand des Rechners zu erfassen. Es ist dabei zu beachten, dass diese
Erfassung der Informationen den RAS-Client belastet und die Daten ber
die RAS-Verbindung bertragen werden mssen. Bei RAS-Verbindungen
mit geringer Bandbreite (z. B. ber Mobiltelefon) kann dies zu nicht
akzeptablen Antwortzeiten fr den Benutzer fhren.
- Falls TCP/IP als Protokoll verwendet wird, sollte berlegt werden, fr eindeutige Zuordnung
von IP-Adresse und
RAS-Clients feste IP-Adressen zu benutzen und diese nicht dynamisch zu Rechner
vergeben. Dieses Vorgehen bedeutet zwar einen hheren administrativen
Aufwand (Wartung der Zuordnungstabellen), erlaubt jedoch eine
eindeutige Zuordnung von Netzadresse und Rechner. Der Nachteil bei
einer dynamischen Vergabe der Netzadressen besteht darin, dass
protokolliert werden muss, welchem RAS-Client zu welchem Zeitpunkte
eine bestimmte Netzadresse zugewiesen wurde. Anderenfalls ist es meist
nicht mglich festzustellen, welcher RAS-Client eine bestimmte Aktion
ausgefhrt hat.
Die Kommunikationsverbindung zwischen RAS-Client und RAS-Server
wird in der Regel ber Netze von Dritten aufgebaut. Die dabei benutzten
Netzkomponenten unterliegen meist nicht der Kontrolle durch den Betreiber
des LANs, mit dem die Verbindung aufgebaut werden soll. Es muss weiter
davon ausgegangen werden, dass die Daten nicht nur ber das Telekommuni-
kationsnetz eines Anbieters bertragen werden, sondern dass auch die Netze
von Kooperationspartnern des Telekommunikationsanbieters benutzt werden.
Dies gilt insbesondere beim Zugriff auf ein LAN aus dem Ausland. Um dem
Schutzbedarf der so bertragenen Daten gerecht zu werden, mssen Sicher-
heitsmanahmen getroffen werden, die z. B. die Vertraulichkeit der Daten
sicherstellen. Daher gilt fr die Datenbertragung:
- Die Nutzung der Datenverschlsselung fr alle bertragenen Daten ist fr
den sicheren Betrieb zwingend erforderlich.
- Es sollten Signaturmechanismen eingesetzt werden, um die Authentizitt
und Integritt der Daten sicherzustellen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Um diesen Anforderungen an den Schutz der Daten gerecht zu werden,

knnen verschiedene Sicherungsmechanismen fr RAS-Verbindungen benutzt
werden. Relevant sind hier unter anderem:
- Die Kommunikation kann auf niedriger Protokollebene verschlsselt Tunneling
werden (so genanntes Tunneling, siehe M 5.76 Einsatz geeigneter Tunnel-
Protokolle fr die RAS-Kommunikation). Dazu muss ein geeignetes
Verfahren ausgewhlt werden. Die herkmmlichen RAS-Systeme stellen
solche Verfahren standardmig, jedoch in unterschiedlicher Zahl und
Ausprgung zur Verfgung.
- Zur Verschlsselung kann auch SSL eingesetzt werden, wenn von der Ver- SSL-Verschlsselung
schlsselung auf niedriger Protokollebene aus bestimmten Grnden kein
Gebrauch gemacht werden kann. Dies gilt besonders fr Zugriffe auf
WWW-Server oder E-Mail-Server ber WWW-Browser, die
standardmig SSL-gesicherte Kommunikation untersttzen. Dazu sollte
auch M 5.66 Verwendung von SSL beachtet werden.
- Neben der Absicherung der Kommunikation durch Software kann auch der Verschlsselung durch
Netzkoppelelemente
Einsatz von verschlsselnden Netzkoppelelementen (Router, Modems)
erwogen werden. Diese sind besonders fr den stationren Einsatz und zur
Anbindung mehrerer Rechner sinnvoll, da die Verschlsselung transparent
erfolgt und die Clients und Server nicht belastet werden. Zu beachten ist
jedoch, dass die Gerte sorgfltig konfiguriert und gewartet werden
mssen.
- Fr den Austausch von E-Mails ber unsichere Kanle kann die Nutzung E-Mail-Verschlsselung
von E-Mail-Verschlsselung sinnvoll sein (siehe auch M 4.34 Einsatz von
Verschlsselung, Checksummen oder Digitalen Signaturen).
Die Sicherheit beim entfernten Zugriff ber eine RAS-Verbindung kann nur
dann gewhrleistet werden, wenn alle Komponenten des RAS-Systems
korrekt und konsistent konfiguriert sind. Zu beachten ist jedoch, dass je nach
Zugriffsverfahren ein Grossteil der benutzten Komponenten nicht der direkten
Kontrolle der lokalen RAS-Administration untersteht. Daher ist der RAS-
Zugang zu einem LAN mit besonderer Sorgfalt und Aufmerksamkeit zu
berwachen.
Beispiel:
Da Windows NT standardmig mit RAS-Untersttzung ausgeliefert wird,
soll der RAS-Dienst von Windows NT als Beispiel dienen. Die angebotene
Funktionalitt sowie die verfgbaren Sicherheitsmechanismen sind jedoch in
der Regel nur fr eine geringe Anzahl an RAS-Benutzern und Daten mit
geringem Schutzbedarf geeignet. Bei groen Benutzermengen und erhhtem
Schutzbedarf sollten auch zustzliche RAS-Produkte in Betracht gezogen
werden.
Fr RAS-Clients unter Windows NT gilt:
- Fr RAS-Clients sollte das Speichern von Benutzernamen und Passwort
zum automatischen Verbindungsaufbau abgeschaltet sein. Dazu muss die
Option "Kennwort speichern" im Verbindungsdialog des DF-Netzwerks
deaktiviert werden. Wurde das Passwort aus Versehen gespeichert, so kann
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
es wieder gelscht werden, indem in den Verbindungseigenschaften auf der

Karte "Sicherheit" der Knopf "Unsicheres Kennwort" gedrckt wird.
- Der automatische Aufbau einer DF-Verbindung sollte nur nach Bestti-
gung durch den Benutzer erfolgen. Dies geschieht ber die Option
"Automatisches Whlen immer besttigen" auf der Karte "Einstellungen"
in den "Benutzereigenschaften" einer DF-Verbindung. Vorzugsweise ist
das automatische Whlen jedoch komplett abzuschalten. Hierzu ist die
Option "Auto-Wahl nach Standorten aktivieren" fr alle Standorte auf der
Karte "Whlen" in den "Benutzereigenschaften" einer DF-Verbindung zu
deaktivieren.
- Es ist darauf zu achten, dass keine eingehenden Verbindungen erlaubt
werden. Fr die Einstellung "Anschlussverwendung" unter System-
steuerung, Netzwerk, Dienste, RAS-Dienst, Gert, Konfigurieren ist hierzu
die Option "Nur ausgehende Anrufe" zu aktivieren.
- Damit die Kommunikationsabsicherung (MPPE-Verschlsselung) benutzt
wird, muss fr die DF-Verbindung unter der Karte "Sicherheit" die
Option "Nur Microsoft-verschlsselte Echtheitsbesttigungen annehmen"
und "Datenverschlsselung erforderlich" aktiviert werden. Zu beachten ist,
dass dazu auch der RAS-Server entsprechend konfiguriert sein muss.
- Es sollte berlegt werden, jedem RAS-Client eine feste IP-Adresse zuzu-
ordnen. Dadurch wird die Nachvollziehbarkeit von Aktivitten, die ber
die RAS-Verbindung gettigt werden, erhht. Die IP-Adresse kann in den
TCP/IP-Eigenschaften der DF-Verbindung unter Telefonbuch, Server,
TCP/IP-Einstellungen, im Feld "IP-Adresse angeben" eingetragen werden.
Fr RAS-Server unter Windows NT gilt:
- Die RAS-Einwahl sollte nur den berechtigten Benutzern gestattet werden.
Fr alle anderen Benutzer ist die Option "Dem Benutzer Einwhlrechte
erteilen" zu deaktivieren. Dies kann entweder ber den Benutzermanager
oder ber den RAS-Manager erfolgen.
- Die Mglichkeit des Rckrufes durch den RAS-Server ist nur fr diejeni-
gen Benutzer zu aktivieren, fr die dies explizit vorgesehen ist. Wenn
mglich, sollte eine feste Rckrufnummer Verwendung finden.
- Damit RAS-Clients eine feste IP-Adresse anfordern knnen, ist die Option
"Remote Clients erlauben, eine vorbestimmte IP-Adresse anzufordern"
unter Systemsteuerung, Netzwerk, Dienste, RAS-Dienst, Gert, Netzwerk,
TCP/IP-Konfigurieren zu aktivieren.
- Soll von der MPPE-Verschlsselung Gebrauch gemacht werden, so ist dies
entsprechend zu aktivieren. Dies erfolgt ber das Dialogfeld System-
steuerung, Netzwerk, Dienste, RAS-Dienst, Gert, Netzwerk, Verschlsse-
lung.
- Fr einen RAS-Server unter Windows NT kann eingestellt werden, ob
RAS-Clients nur auf die Ressourcen des RAS-Servers oder auch auf das
Netz zugreifen knnen, an das der RAS-Server angeschlossen ist. Je nach
Verwendungszweck (z. B. Export lokaler Ressourcen, RAS-Zugangsserver
fr ein Netz) sollte die entsprechende Zugriffsbeschrnkung eingestellt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden. Dies geschieht ber die Option "TCP/IP-Clients drfen zugreifen

auf" unter Systemsteuerung, Netzwerk, Dienste, RAS-Dienst, Gert, Netz-
werk, TCP/IP-Konfigurieren.
- Werden alle festgestellten Sicherheitsverletzungen dokumentiert?
- Wird fr jede Verbindungsaufnahme immer die Benutzer-Authentisierung
ber den festgelegten Mechanismus durchgefhrt?
- Wird fr jede Verbindung die Absicherung der Kommunikation durch
eines der im RAS-Sicherheitskonzept erlaubten Verfahren erzwungen?
- Knnen mobile RAS-Clients durch zustzliche Manahmen gesichert
werden (z. B. Festplattenverschlsselung)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.113 Nutzung eines Authentisierungsservers beim

RAS-Einsatz
Fr RAS-Systeme mit vielen Benutzern muss darber nachgedacht werden,
wie die Benutzerverwaltung fr den RAS-Zugang effizient durchgefhrt
werden kann. In der Regel muss jeder RAS-Benutzer auch eine Systemiden-
titt (Benutzerkonto des Betriebssystems) erhalten bzw. ber ein solches
Benutzerkonto identifiziert werden. Einige Betriebssysteme bieten hier die
direkte Integration der RAS-Funktionalitt (z. B. Windows NT) und eine
gemeinsame Benutzerverwaltung. Fr mittlere und groe Netze, die organi-
satorisch meist in mehrere Teilnetze (Domnen, Verwaltungsbereiche) aufge-
teilt sind, besteht in vielen Fllen das Problem, dass in jedem Verwaltungs-
bereich eine getrennte Verwaltung der Benutzerdaten durchgefhrt wird.
Sollen sich Benutzer auch an fremden Teilnetzen anmelden knnen, mssen
hier Querberechtigungen (Cross-Zertifikate, Vertrauensstellungen) oder ein
zentraler Verzeichnisdienst eingerichtet und gepflegt werden. Eine weitere
Alternative ist, dass die Benutzer zustzlich ein Benutzerkonto in dem anderen
Teilnetz erhalten, dies erschwert aber die Verwaltung der Benutzerdaten.
Insbesondere im RAS-Kontext haben sich hier spezielle Authentisierungs-
systeme herausgebildet, die auch fr den "normalen" Authentisierungsprozess
bei der Systemanmeldung genutzt werden knnen. Typische Vertreter sind
beispielsweise RADIUS, TACACS, TACACS+, SecureID, SafeWord, etc.
Prinzipiell besitzen diese Systeme folgenden Aufbau:
- Die Authentisierungsdaten der Benutzer werden durch einen zentralen
Server verwaltet.
- Das Programm zur Systemanmeldung wendet sich zur berprfung der
vom Benutzer eingegebenen Authentisierungsdaten an den Authentisie-
rungsserver.
- Zur Kommunikation zwischen Anmeldeprozess und Authentisierungs-
server wird in der Regel ein abgesichertes Protokoll eingesetzt.
Der Anmeldeprozess muss dazu die Nutzung externer Authentisierungsserver
untersttzen und die Netzadresse des zu benutzenden Authentisierungsservers
muss in den Konfigurationsdaten des Anmeldeprozesses korrekt eingetragen
sein. Will sich ein Benutzer nun am System anmelden - gleichgltig ob er
dazu eine RAS-Verbindung benutzt oder sich direkt im LAN befindet - laufen
grob vereinfacht folgende Schritte ab:
- Findet ein Verbindungsaufbau mit dem System- oder RAS-Anmelde-
prozess statt, kontaktiert dieser den Authentisierungsserver und informiert
ihn ber den eingegangenen Verbindungswunsch eines Benutzers. Der
Authentisierungsserver sendet - sofern ein "Challenge-Response" Verfah-
ren zum Einsatz kommt - eine so genannte "Challenge" an den Prozess
zurck, der diese an den Benutzer weiterleitet.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Benutzer gibt sein Authentisierungsgeheimnis ein. Dies kann je nach

verwendetem System ein Passwort oder ein Einmalpasswort in den
unterschiedlichsten Ausprgungen (Nummern, Text) sein.
- Der Anmeldeprozess leitet die Daten (meist transparent fr den Benutzer)
an den Authentisierungsserver weiter.
- Der Authentisierungsserver verifiziert die Benutzerdaten und signalisiert
dem Anmeldeprozess das Ergebnis der berprfung.
- Der Zugang zum (Access-)Netz wird nach erfolgreicher berprfung
gewhrt.
Durch die Verwendung von zentralen Authentisierungsservern kann erreicht
werden, dass einerseits die Authentisierungsdaten konsistent verwaltet werden
und andererseits bessere Authentisierungsmechanismen genutzt werden
knnen, als sie von den Betriebssystemen standardmig untersttzt werden.
Hier sind insbesondere Chipkarten- und Token-basierte Mechanismen zu
nennen. Je nach System erzeugen diese z. B. Einmalpasswrter, die auf einem
Display angezeigt werden und die der Benutzer als Passwort angeben muss.
Fr mittlere und groe Netze wird die Verwendung von Authentisierungs-
servern insbesondere im RAS-Bereich empfohlen, da diese eine wesentlich
hhere Sicherheit bei der Benutzer-Authentisierung bieten. Bercksichtigt
werden muss jedoch, dass auch diese Server administriert und gewartet
werden mssen. Ein Authentisierungsserver muss so im Netz platziert werden,
dass er einerseits performant erreicht werden kann, aber andererseits auch vor
unberechtigten Zugriffen geschtzt ist.
- Wird das externe Authentisierungssystem durch das Betriebssystem und
das RAS-System untersttzt?
- Erlaubt die RAS-Client-Software die Nutzung eines Chipkartenlesers fr
chipkartenbasierte Authentisierungssysteme?
- Welche Sicherheitsmechanismen werden durch das externe Authentisie-
rungssystem angeboten?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.114 Nutzung der Sicherheitsmechanismen von

Mobiltelefonen
Mobiltelefone und dazu angebotene Dienstleistungen knnen an verschie-
denen Stellen durch PINs oder Passwrter abgesichert werden. Hierzu geh-
ren:
Zugriff auf die SIM-Karte
Die SIM-Karte kann durch eine vier- bis achtstellige PIN gegen unberechtig-
ten Zugriff geschtzt werden. Mit dieser PIN identifiziert sich der Teilnehmer
gegenber der Karte. Gelangt ein Unbefugter in den Besitz einer SIM-Karte,
kann er ohne Kenntnis der PIN diese Karte nicht aktivieren. Um eine miss-
bruchliche Nutzung der SIM-Karte zu verhindern, sollte daher unbedingt
diese PIN-Abfrage aktiviert werden, so dass die PIN nach dem Einschalten
des Mobiltelefons eingegeben werden muss. Die PIN sollte nicht zusammen
mit dem Mobiltelefon bzw. der SIM-Karte aufbewahrt werden.
Bei der Auslieferung ist meist die PIN-Abfrage deaktiviert und eine PIN
voreingestellt. Bei der ersten Benutzung sollte unbedingt die PIN gendert und
aktiviert werden. Hierbei sollte keine triviale oder leicht vorhersagbare PIN
gewhlt werden (1111, Geburtsdatum, etc.).
Hinweis: Auf der Tastatur der meisten Mobiltelefone sind unter den Ziffern
Buchstaben unterlegt. Dies kann dazu benutzt werden, sich statt PINs
Passwrter auszuwhlen, die leichter zu merken sind, aber natrlich auch
wieder nicht zu einfach sein sollten. Beispiel: "4AUGEN" entspricht der
PIN "428436".
Nach dreimaliger falscher PIN-Eingabe wird die SIM-Karte gesperrt. Um
diese Sperre aufheben zu knnen, muss ein achtstelliger Entsperrcode einge-
geben werden. Dieser wird hufig auch als PUK (PIN Unblocking Key) oder
Super-PIN bezeichnet. Nach zehnmaliger Falscheingabe der PUK wird die
Karte unbrauchbar. Dieser Entsperrcode wird normalerweise in einem PIN-
Brief zusammen mit der SIM-Karte ausgeliefert. Er sollte uerst sorgfltig
und vor unbefugtem Zugriff geschtzt aufbewahrt werden. Die PUK darf auf
keinen Fall zusammen mit dem Mobiltelefon aufbewahrt werden.
Neben der PIN gibt es mit der PIN2 noch eine weitere Geheimzahl, mit der
der Zugriff auf bestimmte Funktionen der SIM-Karte abgesichert werden
kann. Sie wird hufig benutzt fr Konfigurationsnderungen der SIM-Karte,
die nicht vom Benutzer selbst durchgefhrt werden knnen, z. B. Nutzungs-
restriktionen. Dies kann aber beispielsweise auch ein Firmentelefonbuch sein,
das nur nach der Eingabe der PIN2 gendert werden kann. Die PIN2 hat einen
eigenen Entsperrcode (PUK2).
Zugriff auf das Mobiltelefon
Darber hinaus gibt es im Allgemeinen noch einen Sicherheitscode fr das
Mobiltelefon (Gerte-PIN), um den Zugriff auf bestimmte Funktionen zu
schtzen. Auch dieser sollte schnellstmglich auf einen individuell gewhlten
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Wert gesetzt werden. Er sollte notiert und vor unbefugtem Zugriff geschtzt
aufbewahrt werden. Die Gerte-PIN muss nicht bei jedem Einschalten des
Mobiltelefons eingegeben werden. Mit ihr kann z. B. verhindert werden, dass
das Mobiltelefon mit einer anderen SIM-Karte benutzt wird (Diebstahlschutz).
Zugriff auf Mailbox
Beim Netzbetreiber kann fr jeden Teilnehmer eine Mailbox eingerichtet
werden, die unter anderem als Anrufbeantworter dient. Da die Mailbox von
berall und auch von beliebigen Endgerten aus abgefragt werden kann, muss
sie mit einer PIN vor unbefugtem Zugriff geschtzt werden. Bei der Neuein-
richtung vergibt der Netzbetreiber hierzu eine voreingestellte PIN. Diese sollte
unbedingt sofort gendert werden.
Weitere Kennwrter
Neben den diversen oben aufgefhrten Geheimnummern kann es fr
verschiedene Nutzungsarten noch weitere Kennwrter geben. Dies ist z. B. der
Fall beim Zugriff auf Benutzerdaten beim Netzbetreiber. So muss bei Fragen
an die Hotline wegen der Abrechnung u. U. ein Kennwort genannt werden.
Auch kostenpflichtige Dienstleistungen wie z. B. der Abruf von Informationen
oder die Durchfhrung bestimmter Konfigurationen seitens des Netzbetreibers
werden hufig durch zustzliche Kennwrter geschtzt. Diese sollten, wie alle
anderen Passwrter auch, sorgfltig ausgewhlt und sicher aufbewahrt
werden.
Generell sollte mit allen PINs und Passwrtern sorgfltig umgegangen werden
(siehe auch M 2.11 Regelung des Passwortgebrauchs).
Hinweis: Angreifer haben in jngster Zeit wiederholt versucht, telefonisch
die PIN oder PUK von Mobilfunknutzern zu erfragen, indem sie sich als
Mitarbeiter eines Netzbetreibers ausgegeben und einen technischen Defekt
vorgetuscht haben. ber Geheimnummern sollte nie telefonisch Auskunft
gegeben werden!
Es gibt viele verschiedene Sicherheitsmechanismen bei Mobiltelefonen.
Welche hiervon vorhanden sind bzw. wie diese aktiviert werden knnen, ist
abhngig vom eingesetzten Mobiltelefon, von der SIM-Karte und vom
gewhlten Netzbetreiber. Daher sollten die Bedienungsanleitung und die
Sicherheitshinweise vom Netzbetreiber sorgfltig daraufhin ausgewertet
werden. Beim Einsatz von Firmentelefonen empfiehlt es sich, die wichtigsten
Sicherheitsmechanismen sowohl vorzukonfigurieren als auch auf einem
bersichtlichen Handzettel zu dokumentieren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.115 Sicherstellung der Energieversorgung von

Mobiltelefonen
Verantwortlich fr Initiierung: Administrator, Benutzer
Um die Energieversorgung von Mobiltelefonen jederzeit aufrechterhalten zu
knnen, werden blicherweise Akkus eingesetzt. Je nach Kapazitt der Akkus
und Bauweise eines Mobiltelefons reicht dies fr einen beschrnkten Zeit-
raum, blicherweise einige Stunden, aus. Damit ein Mobiltelefon im Bedarfs-
fall jederzeit verfgbar ist bzw. keine Daten in flchtigen Speichern verloren
gehen, sollten einige Randbedingungen eingehalten werden:
- Die Warnanzeigen des Mobiltelefons, die den Spannungsabfall anzeigen,
drfen nicht ignoriert werden.
- Falls es absehbar ist, dass der mobile Einsatz lngerfristig ist, sollte das
Ladegert mitgefhrt werden.
- Beim Laden sollten die Hinweise im Handbuch zum Mobiltelefon beachtet
werden, insbesondere sollte die Lebensdauer des Akkus nicht beeintrch-
tigt werden.
- Bei der bergabe eines Mobiltelefons ist der ausreichende Ladezustand der Ladezustand regelmig
berprfen
Akkus sicherzustellen. Der Ladezustand der Akkus sollte regelmig
berprft werden, da sich ein Akku im Laufe der Zeit entldt, auch wenn er
nicht verwendet wird.
Es empfiehlt sich darber hinaus, auf dem Mobiltelefon gespeicherte Daten
(Telefonbuch, SMS, etc.) in regelmigen Abstnden auf einem anderen
Medium zu speichern.
Wenn eine lngere Nutzung des Mobiltelefons absehbar ist, z. B. bei Dienst- Kurzschlsse am Akku
vermeiden
reisen, sollte ein geladener Ersatzakku mitgefhrt werden. Der Ersatzakku
sollte in einer Schutzhlle verwahrt werden, da Schden durch berhitzung
oder Brand entstehen knnen, wenn die Kontakte des Akkus mit leitenden
Materialien in Berhrung kommen. Dies kann durch viele Gegenstnde des
tglichen Gebrauchs wie Schlssel oder Ketten verursacht werden.
Ein Mobiltelefon sollte ausgeschaltet werden, bevor der Akku gewechselt
wird, damit der Speicher nicht beschdigt wird.
Ein Mobiltelefon sollte keinen extremen Temperaturen ausgesetzt werden. Vorsicht vor extremen
Temperaturen
Insbesondere der Akku, aber auch das Display knnen anderenfalls ihre
Funktionsfhigkeit einben. Daher sollten weder Mobiltelefone noch Akkus
in geparkten Autos zurckgelassen werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.116 Sichere Installation von Lotus Notes

Schon im Rahmen des Installationsprozesses eines Lotus Domino Systems
sind sicherheitsrelevante Aspekte zu bercksichtigen. In der Regel gengt eine
Standardinstallation nicht den geltenden Sicherheitsanforderungen, so dass der
Installationsprozess erst dann als abgeschlossen betrachtet werden kann, wenn
direkt nach der Softwareinstallation eine sichere Konfiguration der Software
erfolgt. Folgende Schritte sind whrend oder direkt nach der Installation
durchzufhren:
Whrend der Installation:
- Es werden drei wichtige Notes-IDs erzeugt: die sogenannte Certifier-ID Passwrter fr Notes-IDs
festlegen
(Datei "cert.id"), die Server-ID (Datei "server.id") und die des
Administrators (Datei "user.id"). Fr alle Notes-IDs sind geeignete
Passwrter festzulegen. Die Notes-IDs sollten nicht im Names- und
Adressbuch gespeichert werden, sondern in Dateien, die geschtzt
vorgehalten werden.
- Lotus Notes bietet die Option, fr Datenbanken einen zustzlichen ACL- ACL-Eintrag fr
anonymen Zugriff
Eintrag (Access Control List, Zugriffsliste) fr die Gruppe "Anonymous" einrichten
mit dem Zugriffslevel "No Access" einzurichten. Gibt es keinen
"Anonymous"-Eintrag, so kommen in der Regel die Rechte des
"-Default-"-Eintrages zur Anwendung. Diese Option sollte daher genutzt
werden, um fr alle Datenbanken explizite Zugriffsrechte fr anonyme
Anwender eintragen zu knnen.
Nach der Installation:
- Die Certifier-ID sollte mit einem Mehrfachpasswort versehen werden, so
dass die ID nur im Vier-Augen-Prinzip genutzt werden kann. Die
Passwrter sollten eine hohe Qualitt besitzen. Mindestens eine Kopie der
Certifier-ID mit zugehrigen Passwrtern sollte an einem gesicherten Ort
aufbewahrt werden.
- Die mit einem Passwort versehene Kopie der Server-ID sollte mit
zugehrigem Passwort an einem gesicherten Ort aufbewahrt werden. Soll
der Domino Server automatisch gestartet werden, ist das Passwort der
Server-ID zu entfernen (Passwortlnge auf "0" setzen). Die Datei
"server.id", die in der Regel im "data"-Verzeichnis des Servers abgelegt ist,
muss mit entsprechenden Dateizugriffrechten vor unberechtigtem Zugriff
geschtzt werden. Die Datei darf nicht auf einem Netz-Share abgelegt
werden.
- Fr alle Verzeichnisse und Dateien des Domino Systems sollten
Zugriffsbeschrnkungen eingerichtet werden, so dass der direkte
Dateizugriff auf Betriebssystemebene nur autorisierten Administratoren
erlaubt ist.
- Der Zugriff auf den Server sollte beschrnkt werden, so dass nur die mit
der Konfiguration betrauten Administratoren auf den Server zugreifen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
knnen (siehe M 4.119 Einrichten von Zugangsbeschrnkungen auf Lotus

Notes Server).
- Fr alle Datenbanken mssen die ACL-Einstellungen kontrolliert werden. ACLs prfen
Dabei sollten alle Eintrge der ACL-Liste berprft werden, insbesondere
die "-Default-"-Berechtigung (siehe M 4.120 Konfiguration von Zugriffs-
listen auf Lotus Notes Datenbanken).
Fr jedes Domino-Server-Modul, das zum Einsatz kommt, muss sichergestellt
werden, dass whrend und nach der Installation keine unerlaubten Zugriffe
erfolgen, bis die Konfiguration abgeschlossen ist und ein sicherer Betrieb
gewhrleistet werden kann (siehe hierzu auch M 4.117 Sichere Konfiguration
eines Lotus Notes Servers).
Die Installation aller Domino-Server-Module muss dokumentiert werden, Dokumentation der
Installation
insbesondere die Konfiguration der Datenbanken und Systemdateien.
- Sind vor der Installation alle erforderlichen Parameter bekannt, die
whrend der Installation bentigt werden?
- Sind alle Nacharbeiten bekannt, die nach der Installation durchgefhrt
werden mssen?
- Wurde der Installationsvorgang, die Erstellung und Konfiguration der
Datenbanken und Systemdateien dokumentiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.117 Sichere Konfiguration eines Lotus Notes

Servers
Der Lotus Domino Application Server besteht aus einer Vielzahl von Funk-
tionsmodulen und kann daher nicht nur als reiner Datenbankserver genutzt
werden, obwohl sich daraus immer noch die meisten Anwendungsszenarien
ableiten. Durch die erfolgte Integration von Internet-Technologien stehen u. a.
auch folgende Module zur Verfgung:
- Das Datenbankservermodul erlaubt den Datenbankzugriff fr Notes- Datenbankzugriff
Clients.
- Das HTTP-Servermodul erlaubt den Datenbankzugriff via Browser und HTML
kann auch als normaler WWW-Server zum Bereitstellen von HTML-Seiten
genutzt werden.
- Das LDAP-Servermodul (Lightweight Directory Access Protocol) erlaubt LDAP
einen Zugriff auf die Benutzerinformationen fr LDAP-Clients.
- Die E-Mail-Servermodule (z. B. SMTP- und POP3-Server) erlauben die E-Mail
Nutzung von E-Mail mittels Internet-Protokollen.
- Das NNTP-Servermodul erlaubt den Zugriff auf sogenannte News-Nach- News
richten.
Je nach Einsatzszenario und dem vom Domino-Server angebotenen Funk-
tionsumfang muss berprft werden, welche Module durch die Standard-
installation aktiviert wurden und welche "Tasks" (als eigene Betriebssystem-
prozesse oder als Threads) daher durch den Server ausgefhrt werden,
Ebenso muss festgelegt werden, welche Module genutzt werden sollen. Nicht nur bentigte Module
aktivieren
genutzte Module drfen nicht installiert werden bzw. sind zu deaktivieren.
Jedes installierte Modul ist bei Fehlkonfiguration als potentielle Sicher-
heitslcke anzusehen. Dies gilt insbesondere fr die Module (z. B. HTTP,
POP, SMTP, LDAP), die Zugriffe auf Server-Daten auch mit Fremd-
programmen ermglichen (z. B. Browser, E-Mail-Programme).
Fr jedes aktivierte Modul muss eine entsprechende Sicherheitsplanung
durchgefhrt werden und diese ist durch geeignete Konfigurationsparameter
umzusetzen (siehe auch M 2.207 Festlegen einer Sicherheitsrichtlinie fr
Lotus Notes).
Da die meisten Funktionsmodule des Domino Application Servers in der
Regel auf Datenbanken aufsetzen und deren Informationen ber entspre-
chende Kommunikationsprotokolle fr Clients bereitstellen, muss in jedem
Fall eine sichere, datenbankbezogene Grundkonfiguration erstellt werden.
Danach sind weitere Konfigurationen der modulbezogenen Parameter not-
wendig.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Es gibt zwei Hauptzugriffsarten auf ein Notes-Systems: ber einen Notes-

Client und ber einen Browser. Die damit zusammenhngenden Empfehlun-
gen sind gesondert
- in M 4.118 Konfiguration als Lotus Notes Server, die die sicherheits-
relevanten Basiskonfigurationen beschreibt, und
- in M 4.122 Konfiguration fr den Browser-Zugriff auf Lotus Notes, die die
zustzlichen Konfigurationsmanahmen fr den Zugriff via Browser
beschreibt,
zusammengefasst.
Ein Notes-System besteht in der Regel nicht nur aus einem Notes-Server, Replikationskonzept
erstellen
sondern aus einem ganzen Serververbund (siehe auch M 3.24 Schulung zur
Lotus Notes Systemarchitektur fr Administratoren). Die einzelnen Server
knnen dabei Datenbanken untereinander replizieren. Dadurch kann Daten-
verlusten entgegengewirkt, aber auch eine Lastverteilung durch die Bereit-
stellung von Datenbank-Kopien auf mehreren Servern erreicht werden. Damit
die Aktualitt der Datenbankkopien in gewissen Grenzen gewahrt bleibt,
mssen Vernderungen an den Daten zwischen den Servern ausgetauscht
werden. Aus Sicherheitsgrnden muss daher ein Replikationskonzept erstellt
werden. Unter anderem sind dabei folgende Aspekte zu bercksichtigen:
- Welcher Server hlt das Original einer Datenbank?
- Auf welche Server soll eine Datenbank repliziert werden?
- Wie oft muss repliziert werden? Wann soll repliziert werden?
- Welche Informationen einer Datenbank sollen repliziert werden?
- Sollen nderungen an Replikaten einer Datenbank erlaubt sein und sollen
diese auf das Original bertragen werden?
- Drfen Benutzer server- oder clientseitige Replikate einer Datenbank
erzeugen?
- Ist das Verndern der Zugriffslisten oder Eigenschaften von Datenbanken
auf Replikaten erlaubt?
Die Zugriffberechtigungen einer Datenbank sind so zu setzen, dass die zur
Replikation notwendigen Operationen durchgefhrt werden knnen. Das
Replikationslog muss regelmig berprft werden.
Die Sicherheit eines Notes-Systems hngt auerdem auch von der Sicherheit Client-Sicherheit
der zum Zugriff benutzten Clients ab. Daher mssen in die Umsetzung einer
sicheren Konfiguration eines Notes-Systems auch die Client-Rechner und
Client-Programme einbezogen werden. Die dabei zu beachtenden IT-Sicher-
heitsaspekte sind in den Manahmen
- M 4.126 Sichere Konfiguration eines Lotus Notes Clients und
- M 4.127 Sichere Browser-Konfiguration fr den Zugriff auf Lotus Notes
zusammengefasst.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Da ein System in der Regel permanenten Vernderungen durch den laufenden kontinuierliche
Betrieb unterworfen ist, muss auch die Sicherheit stndig berprft und ggf. Anpassung
neu konfiguriert werden. Hinweise dazu finden sich in M 4.128 Sicherer
Betrieb von Lotus Notes.
Falls ein Netz- und Systemmanagementsystem im Einsatz ist oder zuknftig Managementsysteme in
die berlegungen
eingesetzt werden soll, ist dies in die berlegungen zur Konfiguration einzu- einbeziehen
beziehen. Beispielsweise ist zu klren, ob ber dieses System auch Notes-
spezifische Einstellungen auf den beteiligten IT-Systemen vornehmen soll und
ob das verwendete bzw. vorgesehene Produkt dies untersttzt. Gegebenenfalls
sind hier zustzliche Anpassungen oder Erweiterungen erforderlich.
- Besteht eine Sicherheitskonzeption fr den Einsatz der verschiedenen
Funktionsmodule von Lotus Notes?
- Ist dokumentiert, welche Module in welcher Konfiguration eingesetzt
werden sollen?
- Existiert ein Replikationskonzept?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.118 Konfiguration als Lotus Notes Server

Die Konfiguration eines Notes-Servers als Datenbankserver kann nur unter
Beachtung seiner Umgebung und des vorgesehenen Anwendungsprofils erfol-
gen (siehe dazu M 2.206 Planung des Einsatzes von Lotus Notes und M 4.117
Sichere Konfiguration eines Lotus Notes Servers). Generell ist auch die
physikalische Sicherheit und die sichere Konfiguration des Betriebssystems
des Rechners, auf dem die Notes-Software eingesetzt wird, fr die Sicherheit
einer Notes-Installation erforderlich. Die Manahmen der relevanten Bau-
steine aus den Kapiteln 4 und 6 (z. B. Serverraum, Schutzschrnke,
Windows NT Netz, Unix Server) sind daher jeweils anzuwenden.
Allgemein mssen folgende Aspekte fr die sichere Konfiguration eines Notes
Servers bercksichtigt werden:
- Die Zugangskontrolle fr den Server muss eingestellt werden. Diese regelt, Zugang zum Server
wer sich mit dem Server verbinden darf, und greift, bevor die Zugriffskon-
trollen auf Datenbanken zum Einsatz kommen. Die Zugangsbeschrnkun-
gen fr den Server mssen gem der Zugangsplanung konfiguriert werden
(siehe M 4.119 Einrichten von Zugangsbeschrnkungen auf Lotus Notes
Server).
- Die Zugriffskontrolle fr Datenbanken muss gem der Zugriffsplanung Zugriff auf Datenbanken
eingestellt werden. Dazu mssen die Zugriffslisten (Access Control Lists,
ACLs) fr alle Datenbanken gem der durchzusetzenden Zugriffs-
beschrnkungen gendert werden (siehe M 4.120 Konfiguration von
Zugriffslisten auf Lotus Notes Datenbanken und M 4.121 Konfiguration
der Zugriffsrechte auf das Namens- und Adressbuch von Lotus Notes).
- Der Administrationsprozess muss korrekt eingerichtet werden, damit die Administrationsprozess
durch den Prozess periodisch ausgefhrten administrativen Ttigkeiten
angestoen werden knnen. Hinweise hierzu finden sich in der Notes-
Hilfe.
- Alle Datenbanken sollten mit einer dafr vorgesehenen speziellen Notes- Notes-ID
ID signiert werden. Dabei sollten insbesondere Agenten und Skripte
signiert werden. Dadurch kann die Ausfhrung von Agenten und Skripten
auf Notes-Clients an die benutzte Signatur geknpft werden, so dass
unsignierte, fremde Agenten und Skripte nicht automatisch ausgefhrt
werden.
- Die notwendigen Logging- und Funktionsdatenbanken mssen erzeugt Protokollierung
werden. Nicht alle fr den Betrieb eines Domino-Servers notwendigen
Datenbanken werden whrend des Installationsprozesses angelegt. So muss
z. B. die Protokolldatenbank, die alle Zertifizierungsprozesse eines Servers
protokolliert (u. a. das Ausstellen von Benutzer-IDs) von Hand erzeugt
werden. Dies betrifft z. B. die Datei "certlog.nsf" und das Template
"certlog.ntf" (siehe auch M 5.86 Einsatz von Verschlsselungsverfahren
beim Browser-Zugriff auf Lotus Notes).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Server sollte in einem Serverraum (siehe Kapitel 4.3.2) bzw. in einem sichere Aufstellung
Serverschrank (siehe Kapitel 4.4) untergebracht werden. Die Serverkonsole
muss auerdem gegen unbefugtes Benutzen gesichert sein. Dazu ist
vorzugsweise der Sperrmechanismus des Betriebssystems (z. B.
Arbeitsstation sperren unter Windows NT) oder ein passwortgeschtzter
Bildschirmschoner (z. B. unter Unix) einzusetzen. Das Konsolenpasswort
von Lotus Notes zu aktivieren, bietet hier wenig Schutz, da es bei der
Eingabe im Klartext angezeigt wird und die Eingabezeile in der Regel ber
die Bildlaufleiste des Konsolenfensters wieder sichtbar gemacht werden
kann.
Befindet sich ein Server im Verbund mit weiteren Servern, so mssen zustz- Datenaustausch
zwischen Servern und
lich die Berechtigungen der Server untereinander konfiguriert werden. Dies Datenbankreplikation
betrifft auch den Datenaustausch zwischen Servern durch die Datenbankrepli-
kation. Die fr die Kommunikation erforderlichen Verbindungswege mssen
dabei durch Anlegen sogenannter Connection-Dokumente konfiguriert
werden. Hinweise zur u. U. notwendigen Verschlsselung von Kommunikati-
onsverbindungen sind in M 5.84 Einsatz von Verschlsselungsverfahren fr
die Lotus Notes Kommunikation beschrieben.
Die Sicherheit des Servers hngt auch von der Sicherheit der Benutzerauthen- Qualitt der Notes-ID-
Passwrter
tisierung ab. Diese wird wesentlich auch von der Sicherheit des Notes-ID-
Passwortes eines jeden Benutzers bestimmt. Fr die Passwrter knnen Quali-
ttsanforderungen eingestellt werden, die beim Erzeugen einer neuen Benut-
zer-ID festgelegt und dann auch bei jedem Passwortwechsel beachtet werden.
Es steht eine numerische Qualittsskala von 0 (kein Passwort) bis 16 zur
Verfgung. Die minimale Passwortqualitt fr Benutzer sollte auf den Wert
"8" oder hher eingestellt sein (siehe auch M 4.129 Sicherer Umgang mit
Notes-ID-Dateien).
- Ist die Konfiguration der Lotus Notes Server dokumentiert?
- Sind alle Kommunikationspartner eines Servers bekannt?
- Ist die physikalische Sicherheit der Server-Rechner gewhrleistet?
- Ist der Schutz der Notes-Server-Konsole gewhrleistet?
- Sind Zugriffsbeschrnkungen auf der Ebene der Betriebssysteme umge-
setzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.119 Einrichten von Zugangsbeschrnkungen auf

Lotus Notes Server
Bevor der Zugriff auf eine Datenbank eines Notes-Servers erlaubt wird, fhrt
der Server schon beim Verbindungsaufbau eines Clients eine erste Zugriffs-
kontrolle durch. Dadurch kann erreicht werden, dass die vom Server angebo-
tenen Datenbanken nur einem bestimmten Benutzerkreis zugnglich sind oder
dass der Zugang an weitere Eigenschaften geknpft ist. Folgende Mechanis-
men zur Zugriffsbeschrnkung knnen verwendet werden:
- Bei der Benutzerauthentisierung wird der in der Benutzer-ID enthaltene Prfung der Notes-ID
ffentliche Schlssel mit der Kopie des ffentlichen Schlssels des Benut-
zers im Namens- und Adressbuch verglichen. Dies verhindert, dass
geflschte IDs benutzt werden knnen.
- Der anonyme Zugriff auf den Server kann verweigert werden. Anonym ist anonymer Zugriff
ein Zugriff auch dann, wenn ein Benutzer mit einer Notes-ID zugreift, die
von einer Zertifizierungsinstanz ausgestellt wurde, die der Server nicht
kennt, d. h. es existiert kein gemeinsames Root-CA-Zertifikat (CA =
Certificate Authority) oder kein Cross-Zertifikat.
- Das Notes-ID-Passwort kann zustzlich berprft werden. Dabei wird zustzliche
Passwortprfung
jeweils ein Hash-Wert des aktuellen Passwortes genau einer Benutzer-ID
gespeichert und bei Passwortnderungen nachgezogen. Dadurch wird
erreicht, dass nur mit einer bestimmten Benutzer-ID auf den Server zuge-
griffen werden kann. Mit Kopien der Benutzer-ID (z. B. mit kompromit-
tiertem Passwort), die nicht das aktuelle Passwort tragen, ist das Anmelden
dann nicht mehr mglich. Achtung: Ist diese Option aktiviert, wird die
Benutzer-ID-Kopie, auf der zuerst das Passwort gendert wird, zu der ID,
mit der ab dann nur noch die Anmeldung mglich ist (dies kann auch die
des Angreifers sein).
- Der Zugriff kann auf die Benutzer eingeschrnkt werden, die im Namens-
und Adressbuch des Servers enthalten sind.
- Es knnen explizite Erlaubnis- und Ausschlusslisten angegeben werden Ja-/Nein-Listen
(Access/Deny Listen). Ausschlusslisten haben dabei Vorrang vor Erlaub-
nislisten. Dies kann z. B. dazu genutzt werden, einzelnen Benutzern den
Zugriff zu verweigern. Zur einfacheren Administration der Listen
empfiehlt sich die Verwendung von Gruppen.
- Auch Server besitzen eine Identitt und knnen in Access/Deny Listen
bzw. den darin enthaltenen Gruppen angegeben werden.
- Bestimmte Server-Operationen knnen auf eine Liste von Benutzern oder Funktionalitten
einschrnken
Gruppen eingeschrnkt werden. Beispiele fr solche Operationen sind das
Anlegen von Datenbanken, das Erzeugen von Replikaten, die Nutzung von
Monitoren, die Administration ber die Web-Schnittstelle und das Ausfh-
ren von Agenten und Skripten. Je nach Option kommen verschiedene Vor-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
gaben zum Einsatz, wenn keine explizite Liste angegeben wird. Beispiels-
weise drfen standardmig alle Benutzer neue Datenbanken anlegen.
- Notes erlaubt es, Server als Vermittlungs-Server, z. B. bei der Einwahl, Einsatz von
Vermittlungs-Servern
einzusetzen oder Server ber Vermittlungs-Server anzusprechen. Im planen
Rahmen des Notes-Sicherheitskonzeptes ist zu planen, ob dies notwendig
ist und welchen Benutzergruppen die Berechtigung zum sogenannten
"Pass-through"-Zugriff erteilt werden soll.
Es ist fr jede Server-Installation im Rahmen der vorhergehenden Planung zu
entscheiden, welche dieser Mechanismen genutzt werden sollen.
- Sind adquate Zugriffskontroll-Mechanismen auf den Notes Servern ein-
gerichtet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.120 Konfiguration von Zugriffslisten auf Lotus

Notes Datenbanken
Eine der wichtigsten Sicherheitsmechanismen eines Notes-Servers ist die
Zugriffskontrolle auf Datenbanken. Hiermit kann gesteuert werden, welcher
Benutzer mit welchen Rechten auf eine Notes Datenbank zugreifen kann.
Nachdem ein Client (Notes-Client oder Browser) die allgemeine Zugangskon-
trolle auf einen Server passiert hat (siehe M 4.119 Einrichten von Zugangsbe-
schrnkungen auf Lotus Notes Server), kommt die Zugriffskontrolle auf
Datenbanken zur Anwendung. Damit der Schutz fr die in den einzelnen
Datenbanken enthaltenen Daten gewhrleistet werden kann, mssen die
Zugriffslisten (Access Control Lists, ACLs) fr jede Datenbank korrekt ein-
gestellt werden. Dabei sind folgende Aspekte zu beachten:
- Fr jede Datenbank ist ein Zugriffskonzept zu entwerfen.
- Datenbanken knnen unter Notes grob in zwei Gruppen eingeteilt werden:
1. Systemdatenbanken, die fr den Ablauf des Notes-Systems not-
wendig sind (z. B. Protokolldatenbanken, Datenbank zur Zertifikats-
verwaltung), und
2. Datenbanken, die produktive Daten enthalten (z. B. Projektdaten-
banken).
Die unterschiedlichen Verwendungszwecke mssen in den Zugriffskon-
zepten bercksichtigt werden.
- Alle Systemdatenbanken mssen mit restriktiven Zugriffsberechtigungen
geschtzt werden, beispielsweise names.nsf, admin4.nsf, catalog.nsf,
log.nsf, event4.nsf, domcfg.nsf, domlog.nsf, setup.nsf, homepage.nsf,
certlog.nsf. Hinweis: Je nach Serverkonfiguration existieren einige der
genannten Datenbanken nicht oder es sind zustzliche vorhanden.
- Wenn eine gruppenbasierte Zugriffskontrolle eingesetzt wird, sollten alle
Benutzer aus der Zugriffsliste entfernt werden. Mindestens einer Gruppe
mssen "Manager"-Rechte zugeordnet werden. In der Regel wird beim
Erzeugen einer Datenbank der Benutzer, der die Datenbank erzeugt (in der
Regel ein Administrator), automatisch mit "Manager"-Rechten in die ACL
eingetragen. Auch dieser Eintrag sollte entfernt werden, damit nur noch
gruppenbasierte Rechte brigbleiben, aber erst dann, wenn alle adminis-
trativen Einstellungen an der Datenbank erfolgt sind.
- Bei der Konfiguration der Datenbank-Zugriffsrechte sollte nicht davon
ausgegangen werden, dass fr den Server Zugangsbeschrnkungen gelten.
Dies vermeidet Sicherheitslcken, wenn sich Zugangsbeschrnkungen auf
Server ndern oder Fehler enthalten.
- Auf produktiven Datenbanken sollten keine "Designer"-Rechte vergeben
werden. Fr Vernderungen am Datenbankdesign sollte ein Change-
Management existieren, das einen geregelten Update-Zyklus erlaubt und
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
beispielsweise die Phasen Antrag mit Begrndung, Entscheidung, Umset-

zung, Test, Einfhrung umfasst.
- ACL-Listen haben bei Client-lokalem Zugriff keine Wirkung. Ein Benut-
zer hat in der Regel volle Kontrolle ber eine Datenbank oder Daten-
bankreplik, die auf dem Client-Rechner gespeichert ist. Insbesondere kann
er Vernderungen an der Datenbank-ACL vornehmen und sich damit
"Manager"-Rechte zuweisen.
- Die Option "Konsistente ACL ber alle Repliken erzwingen" kann nicht
dazu benutzt werden, das Durchsetzen der ACL im lokalen Zugriff zu
erzwingen, da das entsprechende "Flag" durch existierende Administra-
tionswerkzeuge zurckgesetzt werden kann.
- Die Replikation einer Datenbank-ACL ber Domnengrenzen hinweg ist
nicht ohne weiteres mglich, da sich die Namensrume in der Regel unter-
scheiden.
- Der ACL-Eintrag "-Default-" legt die Berechtigungen fr Benutzer fest, die
durch keinen anderen ACL-Eintrag erfasst werden. In der Regel soll
solchen Benutzern kein Zugriff erlaubt werden ("No Access"). Die vorein-
gestellten Rechte dieses Eintrags sind immer zu berprfen und gege-
benenfalls zu verndern.
- Der ACL-Eintrag "-Anonymous-" legt die Berechtigungen fr Benutzer
fest, die sich nicht authentisiert haben (falls der Server das anonyme Ver-
binden erlaubt). Zur Zugriffsteuerung fr anonyme Benutzer sollte dieser
Eintrag in jeder ACL enthalten sein. Fehlt der Eintrag, so kommen in der
Regel die Rechte des "-Default-"-Eintrages zur Anwendung.
- Es mssen nicht nur Benutzern, sondern auch Servern Zugriffsrechte auf
eine Datenbank eingerumt werden. Dies gilt insbesondere fr Datenban-
ken, die repliziert werden sollen.
- Neben Zugriffsrechten knnen auch sogenannte Rollen zur Zugriffssteue-
rung in Skripten und Agenten einer Datenbank zum Einsatz kommen.
Auch die Zuteilung der Rollen muss im Rahmen der Zugriffsplanung
- Existiert fr jede Datenbank ein Zugriffskonzept?
- Werden die ACL-Vernderungen auf wichtigen Datenbanken regelmig
berprft (ACL-Log)?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.121 Konfiguration der Zugriffsrechte auf das

Namens- und Adressbuch von Lotus Notes
Das Namens- und Adressbuch (NAB) eines Notes-Servers ist die zentrale
Verwaltungsdatenbank, in der nicht nur die Benutzerverwaltung enthalten ist,
sondern auch die wesentlichen Konfigurationsdaten eines Servers. Hierzu sind
im NAB entsprechende Benutzerdokumente und Serverdokumente enthalten.
Die korrekte Zugriffskontrolle ber die ACL-Einstellungen des NAB ist daher
besonders wichtig. Bei der Konfiguration ist folgendes zu beachten:
- Das NAB enthlt personenbezogene Daten, die entsprechend geschtzt
werden mssen.
- Im NAB sind auch wichtige Daten abgelegt, die fr bestimmte System-
funktionen zugreifbar sein mssen, z. B. E-Mail-Adresse und Zertifikate
fr die E-Mail-Verschlsselung.
- Ein vollstndiger Schutz persnlicher Daten ohne gleichzeitige Funkti-
onseinbuen lsst sich in der Regel nur schwer realisieren.
Folgende Zugriffskonfigurationen auf das NAB fr Benutzer knnen unter-
schieden werden:
- Die Gruppe "Alle Benutzer (All Users)" erhlt "Autoren (Author)"-Rechte erweiterte Rechte
ohne optionale Attribute und ohne zustzliche Rollen. Benutzer drfen
dann im NAB auf die Informationen anderer Benutzer lesend zugreifen.
Insbesondere knnen jedoch folgende Felder der jeweiligen Registerkarten
(Tabs) ihres eigenen Personendokuments verndert werden:
- Basic: Personal Title, Generation Qualifier, Internet-Passwort
- Mail: Format preference incoming mail (z. B. MIME oder Richtext),
Encryption incoming mail
- Work/Home: alle Felder
- Misc: alle Felder
Diese Berechtigungskonfiguration (Author-Recht fr alle Benutzer) erlaubt
es insbesondere, dass Benutzer ihr eigenes Internet-Passwort verndern
knnen, das z. B. an der Web-Schnittstelle und beim E-Mail-Zugriff via
POP3 zur Authentisierung genutzt wird. Da zur Zeit keine integrierte
Qualittssicherung fr das Internet-Passwort angeboten wird, knnen
Benutzer so auch schwache Passwrter eintragen. Abhilfe kann hier nur
durch entsprechende Benutzerschulung geschaffen werden oder indem das
eigenstndige ndern des Internetpasswortes unterbunden wird (siehe
nachfolgend).
- Die Gruppe "Alle Benutzer (All Users)" erhlt "Leser (Reader)"-Rechte nur Lese-Recht
ohne optionale Attribute und ohne zustzliche Rollen. Mit dieser
Berechtigungskonfiguration knnen Benutzer nur lesend auf das NAB
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
zugreifen. Alle Vernderungen an ihrem eigenen Personendokument (z. B.

Verndern des Internet-Passwortes) mssen durch einen Administrator
erfolgen.
- Die Gruppe "Alle Benutzer (All Users)" erhlt keine Zugriffsrechte "Kein keine Zugriffsrechte
Zugriff (No Access)" auf das NAB. Diese Berechtigungskonfiguration
stellt zwar den Schutz der im NAB enthaltenen persnlichen Daten sicher,
hat jedoch Funktionseinbuen zur Folge, die fr den Betrieb eines Notes-
Systems nicht tolerierbar sind.
Fr administrative Ttigkeiten kann eine Rollenaufteilung erfolgen. Es knnen
jeweils Rollen vergeben werden fr das Erzeugen oder Verndern von
- Gruppendokumenten (Rollen "[GroupCreator]" und "[GroupModifier]"),
- Serverdokumenten (Rollen "[ServerCreator]" und "[ServerModifier]"),
- Benutzerdokumenten (Rollen "[UserCreator]" und "[UserModifier]") sowie
- allen restlichen Dokumente des NAB (Rollen "[NetCreator]" und
"[NetModifier]").
Die Aufteilung der Administrationsttigkeiten in verschiedene Rollen ist Trennung der
administrativen Rollen
generell zu empfehlen. Es sollte geprft werden, ob dies im vorliegenden
Einsatzumfeld zweckmig ist.
- Soll das NAB ber die Web-Schnittstelle sichtbar und zugreifbar sein?
- Soll das NAB in den Notes-Katalog aufgenommen werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.122 Konfiguration fr den Browser-Zugriff auf Lotus

Notes
Soll auf einen Lotus Domino Server mittels Browser zugegriffen werden, so
muss auch bei dieser Zugriffsart angemessene Sicherheit gewhrleistet
werden.
Zur Absicherung des Browser-basierten Zugriffs sollten folgende Empfehlun-
gen umgesetzt werden, die Server, Client und deren Kommunikationsmecha-
nismen betreffen:
1. Jeder Zugriff, der eine Authentisierung bentigt, sollte mit SSL geschtzt Einsatz von SSL
werden (siehe M 4.124 Konfiguration der Authentisierungsmechanismen
beim Browser-Zugriff auf Lotus Notes).
2. Es mssen Browser eingesetzt werden, die das SSL-Protokoll beherrschen starke Verschlsselung
(siehe M 4.127 Sichere Browser-Konfiguration fr den Zugriff auf Lotus
Notes). Der Browser sollte starke Verschlsselung untersttzen, also
Verfahren mit mindestens 80 Bit Schlssellnge.
3. Der Domino Server muss fr den SSL-geschtzten Web-Zugriff konfigu- geeignete
Programmversion
riert werden (siehe M 4.123 Einrichten des SSL-geschtzten Browser- einsetzen
Zugriffs auf Lotus Notes). Um starke Verschlsselung zu gewhrleisten,
sollte mindestens die Version 5.0.4 des Domino Servers zum Einsatz
kommen.
4. Auch auf Datenbankebene sollten Zugriffsbeschrnkungen eingerichtet Zugriffsbeschrnkungen
auf Datenbankebene
werden (siehe M 4.125 Einrichten von Zugriffsbeschrnkungen beim
Wird der Web-Zugriff auf ein Notes-System geplant, so sind auerdem noch
folgenden sicherheitsrelevanten Aspekte zu bercksichtigen:
- Das Notes-ID-Passwort darf nicht mit dem Internet-Passwort bereinstim-
men.
Fr die Authentisierung an der Web-Schnittstelle kann u. a. der Mecha-
nismus "Benutzername und Passwort" eingesetzt werden. Dabei kann das
sogenannte Internet-Passwort fr jeden Benutzer frei festgelegt werden.
Dies geschieht meist schon beim Anlegen neuer Benutzer. Es muss dabei
jedoch darauf geachtet werden, dass hier nicht von der Option Gebrauch
gemacht wird, das Internet-Passwort auf den Wert des Notes-ID-Pass-
wortes zu setzen. Dies hat im wesentlichen zwei Grnde: einmal besteht
die Mglichkeit, dass das Internet-Passwort auch im Klartext zwischen
Client und Server bertragen wird, so dass es leicht kompromittiert werden
kann. Weiterhin wird der Passwort-Hash im Personendokument eines
Benutzers im Namens- und Adressbuch gespeichert. Je nach Konfiguration
kann dieser Wert auch von anderen Personen eingesehen werden, so dass
eine Wrterbuchattacke auf den Hash-Wert durchgefhrt werden knnte.
In beiden Fllen kann nach Kenntnis des Internet-Passwortes auch auf eine
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Notes-ID-Datei zugegriffen werden, wenn hier das gleiche Passwort

gewhlt wurde (siehe auch M 4.124 Konfiguration der Authentisierungs-
mechanismen beim Browser-Zugriff auf Lotus Notes).
- Die gewnschte "Zugriffsart" fr Benutzer auf das Namens- und
Adressbuch muss eingerichtet werden.
Der Zugriff fr Benutzer auf das Namens- und Adressbuch kann "lesend"
und "schreibend" eingerichtet werden. Bei schreibendem Zugriff knnen
Benutzer nur ihr eigenes Personendokument verndern. Dadurch ist insbe-
sondere das Verndern des Internet-Passwortes durch den Benutzer mg-
lich, was u. U. die Administration vereinfacht. Nachteilig ist jedoch, dass
damit keine Kontrolle ber das Internet-Passwort, z. B. in Bezug auf Quali-
tt und Lnge, besteht und der Benutzer auch andere Eintrge seines
Personendokumentes editieren kann. Die "lesende" Konfiguration verhin-
dert dies, erfordert jedoch das Eingreifen eines Administrators, wenn ein
Benutzer sein Internet-Passwort verndern will. Der Benutzerzugriff auf
das Namens- und Adressbuch kann auch ganz unterbunden werden. Dies
hat den Vorteil, dass der Hash-Wert des Internet-Passwortes vor Kenntnis-
nahme durch Dritte geschtzt ist. Dies verhindert jedoch auch, dass das
Namens- und Adressbuch fr die Adressierung, z. B. von E-Mails, zur
Verfgung steht (siehe auch M 4.120 Konfiguration von Zugriffslisten auf
Lotus Notes Datenbanken und M 4.121 Konfiguration der Zugriffsrechte
auf das Namens- und Adressbuch von Lotus Notes).
- Sind alle Browser-Zugriffe auf Lotus Notes SSL-gesichert?
- Wurde festgelegt, welche Zugriffsart fr den Browser-Zugriff auf Lotus
Notes eingerichtet wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.123 Einrichten des SSL-geschtzten Browser-

Zugriffs auf Lotus Notes
Der Web-Zugriff auf einen Domino Server kann ungeschtzt ber das Proto-
koll HTTP (HyperText Transfer Protocol) oder mit SSL (Secure Socket
Layer) abgesichert ber das Protokoll HTTPS erfolgen. Generell kann ein
Server beide Varianten gleichzeitig untersttzen. Ist die Nutzung des unge-
schtzten Zugriffs mglich, so kann die SSL-Absicherung auch bei Bedarf
angefordert werden, wenn auf eine Datenbank zugegriffen wird, deren Daten
whrend der bertragung geschtzt werden mssen, oder wenn eine abge-
sicherte Authentisierung notwendig ist. Dazu kann in den Eigenschaften einer
Datenbank angegeben werden, dass fr den Zugriff eine SSL-Verbindung
erforderlich ist (siehe M 4.125 Einrichten von Zugriffsbeschrnkungen beim
Damit der SSL-Zugriff berhaupt ermglicht werden kann, muss der soge- SSL-Port aktivieren
nannte SSL-Port des Servers aktiviert werden. Dazu muss im Serverdokument
der Status des SSL-Ports auf den Wert "Enabled" (Aktiviert) gesetzt werden.
Durch diese Einstellung wird jedoch nur der SSL-Port zur Nutzung freige-
geben. Damit eine SSL-Verbindung zustande kommen kann, muss der Server
auf den SSL-Einsatz vorbereitet werden, indem fr ihn ein SSL-Zertifikat
ausgestellt wird (siehe M 5.86 Einsatz von Verschlsselungsverfahren beim
Browser-Zugriff auf Lotus Notes).
Sollen Web-Clients auf einen Server ausschlielich ber SSL-geschtzte
Verbindungen zugreifen, so kann dies auf zwei Arten erreicht werden:
1. Der ungeschtzte HTTP-Port wird deaktiviert, indem im Serverdokument HTTP-Port deaktivieren
der Status des HTTP-TCP/IP-Ports auf "Disabled" (Deaktiviert) gesetzt
wird. Durch diese Einstellung werden Client-Anfragen an den ungeschtz-
ten Port abgewiesen und es kommen keine unverschlsselten Verbindun-
gen mehr zustande.
2. Der ungeschtzte HTTP-Port wird auf den geschtzten SSL-Port umgelei- HTTP-Port umleiten
tet. Dazu wird im Serverdokument der Status des HTTP-TCP/IP-Ports auf
"Redirect to SSL" gesetzt. Diese Einstellung hat den Vorteil, dass Client-
Anfragen ber ungeschtzte Verbindungen nicht abgelehnt werden,
sondern - sofern der Client SSL untersttzt - ber eine geschtzte Verbin-
dung beantwortet werden.
Welche Konfiguration verwendet werden soll, hngt von den beabsichtigten
Einsatzszenarien ab (siehe M 2.210 Planung des Einsatzes von Lotus Notes im
Intranet mit Browser-Zugriff) und muss im Einzelfall entschieden werden.
Beispiele:
1. Folgende Tabelle zeigt die Einstellungen im Serverdokument, die unge-
schtzte anonyme Zugriffe sowie geschtzte authentisierte und anonyme
Zugriffe erlauben.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Das Anfordern der geschtzten Authentisierung muss dabei durch das

Aktivieren der Datenbank-Eigenschaft "Web access: Require SSL
connection" erfolgen (siehe M 4.125 Einrichten von Zugriffsbeschrnkun-
gen beim Browser-Zugriff auf Lotus Notes Datenbanken).
Darf der Zugriff auf eine solche Datenbank nicht anonym erfolgen, so ist
zustzlich ein ACL-Eintrag fr "Anonymous" mit dem Zugriffslevel "No
access" einzurichten (siehe M 4.120 Konfiguration von Zugriffslisten auf
Lotus Notes Datenbanken).
Serverdokument/Ports/Internet Ports:
HTTP-Einstellungen TCP/IP port status: Enabled
Name & Password: No
Anonymous: Yes
HTTPS(SSL)-Einstellungen SSL port status: Enabled
Client certificate: Enabled
Name & Password: Enabled
Anonymous: Yes
2. Folgende Tabelle zeigt die Einstellungen im Serverdokument, die die SSL-
Absicherung fr den Web-Zugriff erzwingen, indem entweder alle Anfra-
gen an den ungeschtzten Port auf den mit SSL geschtzten Port umgelei-
tet werden ("Redirect to SSL") oder indem Anfragen auf dem ungeschtz-
ten Port nicht beantwortet werden ("Disable").
HTTP-Einstellungen TCP/IP port status: Redirect to SSL
oder
Disabled
Name & Password: No
Anonymous: No
Client certificate: Enabled* oder
Disabled*
Name & Password: Enabled* oder
Disabled*
Anonymous: Yes* oder No*
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
*: Mindestens einer der Authentisierungsmechanismen muss aktiviert sein,

damit Anfragen vom Server angenommen werden. Sind alle Mechanismen
aktiviert und ist eine Authentisierung fr die angeforderte Web-Seite not-
wendig, wird zunchst nach einem Client-Zertifikat verlangt. Wenn der
Client nicht im Besitz eines Zertifikats ist, werden danach Benutzername
und Passwort angefordert.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.124 Konfiguration der

Authentisierungsmechanismen beim Browser-
Zugriff auf Lotus Notes
Bei der Nutzung von Browsern zum Zugriff auf einen Lotus Domino Server
muss entschieden werden, welches Authentisierungsverfahren an der Web-
Schnittstelle zum Einsatz kommen soll. An der Web-Schnittstelle stehen ver-
schiedene Authentisierungsmechanismen zur Verfgung:
1. Keine Authentisierung: Anonymer Zugriff
2. Authentisierung ber Benutzername und Passwort
3. Authentisierung mittels Client-Zertifikaten
Zunchst ist daher zu ermitteln, ob anonyme Zugriffe auf den Server erlaubt anonyme Zugriffe
werden mssen. Dies ist dann der Fall, wenn ffentliche Daten auch Benut-
zern zugnglich gemacht werden sollen, die keine Notes-Benutzer sind. Es
empfiehlt sich jedoch, ffentliche Daten auf einem speziellen Server zu halten,
der ausschlielich ffentliche Daten enthlt. Fr einen solchen Server kann der
anonyme Zugriff erlaubt werden. Auf einem Produktionsserver sollten
anonyme Zugriffe generell nicht erlaubt sein, so dass an der Web-Schnittstelle
immer authentisiert wird.
Die Art der zu nutzenden Authentisierungsverfahren hngt von verschiedenen
Faktoren ab. Folgendes muss dabei (auch im Rahmen einer Risikoabscht-
zung) bercksichtigt werden:
1. Authentisierung ber Benutzername und Passwort
Im Rahmen des HTTP-Protokolls kann ein Benutzer durch das Eingeben
von Benutzername und Passwort authentisiert werden. Die Daten werden
durch den Browser eingelesen und von diesem bei jeder Anfrage an den
Server (hier das Domino Web-Server-Modul) gesendet.
Folgende sicherheitsrelevanten Aspekte sind bei der Nutzung dieses
Authentisierungsverfahrens zu bercksichtigen:
a. Ohne SSL-Absicherung werden die Authentisierungsdaten bei jeder Web-Zugriff nur mit SSL
Anfrage nur in 7-Bit-Code umgewandelt aber offen (im base64-
Format) bertragen und knnen daher leicht abgehrt und durch
Dritte in Erfahrung gebracht werden. Der Web-Zugriff sollte daher
immer mit SSL erfolgen (siehe M 4.123 Einrichten des SSL-
geschtzten Browser-Zugriffs auf Lotus Notes).
b. Das Internet-Passwort muss verschieden vom Passwort der Notes-ID unterschiedliche
Passwrter whlen
gewhlt werden. Gelingt es einem Angreifer, das Internet-Passwort
in Erfahrung zu bringen, und wird dieses Passwort auch fr die
Notes-ID verwendet, so kann der Angreifer auch die Notes-ID
verwenden (sofern er darauf Zugriff erlangen kann). Mit der Notes-
ID kann der Angreifer dann ber einen Notes-Client auf das Lotus
Domino System zugreifen, und die erweiterten Funktionen von
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Notes-Clients nutzen, beispielsweise Zertifikate exportieren und das

Passwort der Notes-ID ndern).
c. In lteren Notes-Versionen (vor 4.6) wird das Internet-Passwort im aktuelle Notes-Version
einsetzen
Personendokument so gespeichert, dass gleiche Passwrter zum
gleichen Wert fhren (es wird ein sogenannter "unsalted hash"
genutzt). Dadurch ist es sehr einfach, gleiche Passwrter zu suchen
bzw. zu entdecken. ltere Notes-Versionen sollten daher mglichst
nicht eingesetzt werden.
d. An der Web-Schnittstelle existiert keine Beschrnkung fr Fehl- zustzliche
Sicherheitsprodukte
versuche bei der Authentisierung. Eine solche Beschrnkung kann
mit Hilfe von Zusatzprodukten von Drittherstellern nachgerstet
werden. Es wird empfohlen zu prfen, ob der Einsatz eines solchen
Zusatzprodukts im vorliegenden Anwendungsfall erforderlich ist.
Dieser Authentisierungsmechanismus weist bei seiner Nutzung ber unge-
schtzte Verbindungen inhrente Schwchen auf. Daher sollte der Zugriff
auf einzelnen Datenbanken fr Benutzer eingeschrnkt werden (siehe
Manahme M 4.125 Einrichten von Zugriffsbeschrnkungen beim
Browser-Zugriff auf Lotus Notes Datenbanken), wenn sie ber diesen
Mechanismus authentisiert werden.
2. Authentisierung mittels Client-Zertifikaten
Folgende sicherheitsrelevanten Aspekte sind bei der Nutzung dieses
Authentisierungsverfahrens zu bercksichtigen:
a. Damit Client-Zertifikate verwendet werden knnen, muss SSL Client-Zertifikate
erfordern SSL
(Version 3) mit Client-Authentisierung benutzt werden. Da alle
Browser-Verbindungen generell mit SSL gesichert werden sollten,
stellt dies keine Einschrnkung dar.
b. Jeder Benutzer (genauer: dessen Browser) muss mit einem Client- Zertifikats-Management
Zertifikat versorgt werden. Dies bedeutet entweder den Betrieb eines
eigenen Zertifizierungsservers oder das Einrichten einer
Vertrauensstellung fr eine externe Zertifizierungsstelle. Zustzlich
muss die Verwaltung der Zertifikate erfolgen. Dies bedeutet erhh-
ten Aufwand und setzt entsprechendes Wissen bei den Administra-
toren und auch Benutzern voraus. Insbesondere die Benutzer mssen
mit den Managementfunktionen fr Zertifikate im Browser vertraut
sein.
c. Die Sicherheit der Authentisierung hngt wesentlich von der lokalen Sicherheit der Clients
Sicherheit des Web-Clients ab (siehe M 4.127 Sichere Browser-
Konfiguration fr den Zugriff auf Lotus Notes).
Ein generelles Votum fr genau einen der beiden Mechanismen kann an dieser
Stelle nicht gegeben werden. Es ist jedoch mglich, beide Mechanismen
parallel zu aktivieren. In diesem Fall wird vom Server zunchst vom Client
eine Authentisierung mittels SSL-Client-Zertifikat angefordert. Besitzt der
Client kein Zertifikat oder verweigert der Benutzer die Nutzung des
Zertifikats, so kommt der Mechanismus "Benutzername und Passwort" zum
Einsatz.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beispiel:
Folgende Tabelle zeigt die Einstellungen im Serverdokument, die eine SSL-
Authentisierung mittels Client-Zertifikat ("Client Certificate" = Enabled)
und/oder die SSL-gesicherte Authentisierung ber Benutzername und Pass-
wort ("Name & Password" = Enabled) erzwingen. Damit keine unge-
sichertenVerbindungen angenommen werden, werden alle Verbindungs-
wnsche entweder an den SSL-Port weitergeleitet ("TCP/IP port status" =
Redirect to SSL) oder verweigert ("TCP/IP port status" = Disable). Der SSL-
Port wird so konfiguriert, dass auch keine anonymen Verbindungen ber eine
SSL-Verbindung angenommen werden ("Anonymous" = No).
HTTP-Einstellungen TCP/IP port status: Redirect to SS
L oder
Disable
Name & Password: No
Anonymous: No
Client certificate: Enabled oder
Disabled*
Name & Password: Enabled oder
Disabled*
Anonymous: No
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.125 Einrichten von Zugriffsbeschrnkungen beim

Browser-Zugriff auf Lotus Notes Datenbanken
Wird auf einen Lotus Domino Server auch mittels Browser zugegriffen, so
mssen neben den brigen Server-bezogenen Sicherheitsmechanismen (siehe
M 4.122 Konfiguration fr den Browser-Zugriff auf Lotus Notes) auch
Datenbank-bezogene Mechanismen zum Einsatz kommen. Damit wird einer-
seits erreicht, dass der Zugriff auf eine Datenbank nur erfolgen kann, wenn
eine gesicherte Verbindung zwischen Client und Server besteht (oder aufge-
baut werden kann), und andererseits kann der Zugriff fr Web-Clients generell
eingeschrnkt werden.
Folgende Datenbank-bezogenen Sicherheitsmechanismen sollten eingesetzt
werden:
1. Fr alle Datenbanken sollte die Nutzung von SSL (Zugriff mittels HTTPS) Zugriff nur ber SSL
als Zugriffsvoraussetzung in den Eigenschaften der jeweiligen Datenbank
aktiviert werden. Dies ist insbesondere dann wichtig, wenn der Server auch
fr den ungesicherten Zugriff mittels HTTP konfiguriert ist.
2. Wird als Authentisierungsverfahren "Benutzername und Passwort" genutzt mglichst restriktiver
Zugriffslevel
(siehe M 4.124 Konfiguration der Authentisierungsmechanismen beim
Browser-Zugriff auf Lotus Notes), so ist fr jede Datenbank der maximale
Zugriffslevel in den Datenbankberechtigungen einzustellen. Insbesondere
kann durch die Nutzung des Zugriffslevels "No Access" der Web-Zugriff
auf einzelne Datenbanken unterbunden werden. Falls der Web-Zugriff als
alleiniger Zugriffsmechanismus genutzt wird, muss bei der Wahl des
Zugriffslevels bedacht werden, dass fr die Benutzer an der Web-Schnitt-
stelle keine zustzlichen Funktionseinbuen entstehen sollten. In diesem
Fall mssen Benutzer in der Regel auch mindestens schreibenden Zugriff
erhalten, so dass dieser zugriffeinschrnkende Mechanismus nicht als
solcher verwendet werden kann.
Hinweis: Der in der Abbildung angegebene Zugriffslevel "Reader" stellt
keine Empfehlung fr den hier einzustellen Parameter dar. Vielmehr muss
dieser Wert fr jede Datenbank separat bestimmt werden.
Weiterhin ist folgender sicherheitsrelevanter Aspekt beim Web-Zugriff auf
Lotus Notes Datenbanken zu bercksichtigen: Kann auf einen Domino Server
ber die Web-Schnittstelle zugegriffen werden und wird die Authentisierung
mittels SSL-Client-Zertifikaten genutzt (siehe M 4.124 Konfiguration der
Authentisierungsmechanismen beim Browser-Zugriff auf Lotus Notes), so
knnen einzelne Datenbanken nicht vom Web-Zugriff ausgenommen werden.
Vielmehr werden den authentisierten Benutzern die fr sie eingetragenen
ACL-Berechtigungen zugestanden (siehe auch M 4.120 Konfiguration von
Zugriffslisten auf Lotus Notes Datenbanken).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.126 Sichere Konfiguration eines Lotus Notes Clients

Zum Zugriff auf einen Notes-Server wird in der Regel der Lotus Notes Client
benutzt. Fr den Zugriff auf den Server erfolgt eine Authentisierung durch die
Notes-ID. Die Notes-ID ist daher vor fremden Zugriffen geschtzt aufzube-
wahren. Naturgem muss auch die Client-Konfiguration so verndert
werden, dass ein mglichst sicheres Arbeiten mit dem Notes-Client erfolgen
kann.
Neben der physikalischen Sicherheit und der sicheren Betriebssystem- konfi-
guration der Clients (siehe auch die relevanten Bausteine in den Kapiteln 4
und 6), sind insbesondere die folgenden Notes-spezifischen Sicherheitsaspekte
zu bercksichtigen:
- Damit der Client auf die Notes-ID-Datei zugreifen kann, muss der Benut- Bildschirmschoner
aktivieren bei
zer das Notes-ID-Passwort eingeben. Nachdem die Notes-ID in dieser kurzfristiger
Form freigeschaltet wurde, kann im Prinzip jeder, der Zugriff auf die Kon- Abwesenheit
sole des Clients besitzt, auf den oder die Server authentisiert zugreifen. Um
dies zu verhindern, kann der Notes-Client durch Drcken der Funkti-
onstaste "F5" veranlasst werden, vor der nchsten Aktion das Notes-ID-
Passwort erneut abzufragen. Dieser Mechanismus kann zum Sperren des
Notes-Clients bei kurzzeitiger Abwesenheit vom Arbeitsplatz benutzt
werden (siehe auch M 4.129 Sicherer Umgang mit Notes-ID-Dateien). Die
Benutzer mssen darauf hingewiesen werden, dass bei Verlassen des
Arbeitsplatzes dieser oder ein anderer Passwort-geschtzter Bildschirm-
schoner zu aktivieren ist.
- Beim Zugriff auf Datenbanken werden - je nach Datenbank - auch aktive unsignierte aktive
Datenbankinhalte nicht
Datenbankinhalte (Skripten oder Agenten) durch den Client ausgefhrt. Je ausfhren
nach Ursprungsort birgt dies Gefahren, z. B. knnte jemand durch ein
trojanisches Pferd unerlaubten Zugriff auf lokale Datenbanken nehmen.
Alle Datenbanken und alle aktiven Inhalte sollten daher durch eine spezi-
elle Notes-ID signiert werden (siehe M 4.130 Sicherheitsmanahmen nach
dem Anlegen neuer Lotus Notes Datenbank). Danach kann ber die
sogenannte ECL (Execution Control List) eingestellt werden, ob aktive
Inhalte, die durch eine bestimmte Notes-ID signiert wurden, auf einem
Client ausgefhrt werden drfen und welche nicht: Generell kann hier
empfohlen werden, dass unsignierte aktive Datenbankinhalte nicht ausge-
fhrt werden drfen. Die ECL wird Server-gesteuert an alle Clients beim
Client-Setup verteilt. Problematisch ist, dass die ECL auf einem Client
unter Windows NT in der Datei "DESKTOP.DSK" gespeichert wird, die
der Benutzer lschen kann, so dass die ECL-Einstellungen umgangen
werden knnen. Daher sollten die Benutzer auf die Bedeutung dieser
Einstellung fr die Systemsicherheit hingewiesen werden. Das automa-
tische Update der Client-ECL kann jedoch auch periodisch geschehen, so
dass die Client-ECL immer wieder "aktiviert" werden kann. Dazu stehen
zwei Mechanismen zur Verfgung:
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Parameter "ECLSetup" wird in der Datei "Notes.ini" des Clients

auf einen Wert kleiner 3 gesetzt. Dadurch wird beim nchsten Start
des Clients die ECL vom Server geladen. Dies bedeutet jedoch einen
zustzlichen organisatorischen Aufwand, da der Parameter auf dem
Client verndert werden muss.
- Das Update erfolgt skriptgesteuert (Funktion "@RefreshECL")
durch Verndern der Schablone einer Datenbank, auf die Benutzer
regelmig zugreifen (z. B. die E-Mail-Datenbank). Dies erfordert
jedoch Eigenprogrammierung und das Verndern einer Datenbank-
Schablone.
Fr die eigentliche ECL gilt, dass die Berechtigungen fr alle ECL-Ein-
trge berprft und entsprechend der IT-Sicherheitsrichtlinie gesetzt
werden mssen. Insbesondere sollten die Eintrge "-Default-" und "Keine
Unterschrift (No Signature)" einer genauen Prfung unterzogen werden.
Um die sichere Kommunikation zwischen Server und Client zu erzwingen,
kann die Port-Verschlsselung genutzt werden (siehe M 5.84 Einsatz von
Verschlsselungsverfahren fr die Lotus Notes Kommunikation).
Beispiel:
Folgende ECL-Einstellungen knnen als Ausgangspunkt fr eigene ECLs
dienen. Je nach Anwendungsszenario mssen die ECLs um Berechtigungen
fr aktive Inhalte, die entsprechende Signaturen tragen, erweitert werden.
<admin> ist ein Platzhalter fr einen Administrator und <QS> ist ein Platzhal-
ter fr eine organisationsinterne Prfinstanz, die aktive Inhalte prft und zur
Benutzung freigibt.
Flag -Default- -keine <admin> Lotus <QS>

Unter- Notes
schrift- Tem-
plate
devel-
opment/
Lotus
Notes
Allow user to modify -- -- -- -- --
ECL
Access to the file X X X
system
Access to the current X X X
database
Access to X X X
environment
variables
Access to non-Notes X X X
databases
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Flag -Default- -keine <admin> Lotus <QS>

Unter- Notes
schrift- Tem-
plate
devel-
opment/
Lotus
Notes
Access to external X X X
code
Access to external X X X
programs
Ability to send mail X X X
Ability to read other X X X
databases
Ability to modify X X X
other databases
Ability to export data X X X
Access to the Work- X
station Security ECL
- Wird eine aktuelle Notes-Client Version eingesetzt?
- Wurden die Benutzer ber die Sicherheitsmechanismen des Notes-Clients
informiert?
- Wird die Notes-ID gesichert aufbewahrt, so dass das unbefugte Kopieren
nicht mglich ist?
- Wird ein Passwort-geschtzter Bildschirmschoner eingesetzt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.127 Sichere Browser-Konfiguration fr den Zugriff

auf Lotus Notes
Um ber die Web-Schnittstelle auf einen Lotus Domino Server zuzugreifen, Browser-Zugriff ber
HTTP
bentigt der Benutzer einen "Web-Client" in Form eines Browsers. Der
Zugriff auf die Serverdaten erfolgt durch Anfragen an das HTTP-Modul des
Domino Servers. Dieses extrahiert seinerseits die Daten aus den entsprechen-
den Datenbanken und wandelt sie in WWW-Seiten um, so dass diese vom
Browser des Benutzers dargestellt werden knnen. Durch die Nutzung von
aktiven Inhalten (JavaScript, Java-Applets) knnen Modifikationen der
Datenbankinhalte ber eine dem normalen Notes-Client nachempfundene
graphische Oberflche erfolgen.
Die Sicherheit beim Web-Zugriff hngt von der Sicherheit der beteiligten Server, Client und
Kommunikation mssen
Komponenten ab. Neben der sicheren Konfiguration der Server (siehe sicher sein
M 4.122 Konfiguration fr den Browser-Zugriff auf Lotus Notes) und der
Nutzung der Kommunikationsabsicherung (siehe M 5.86 Einsatz von
Verschlsselungsverfahren beim Browser-Zugriff auf Lotus Notes), ist die
Sicherheit des Web-Clients ein wesentlicher Faktor.
Bei Web-Zugriffen erfolgt die Speicherung der Authentisierungsgeheimnisse Schutz der
Authentisierungsdaten
auf dem Client. Erlangt ein unberechtigter Dritter Zugriff auf diese Daten, so
kann er unter den Berechtigungen des kompromittierten Benutzers auf die
Datenbanken eines Server zugreifen. Die in diesem Zusammenhang zu
schtzenden Authentisierungsdaten sind:
- Benutzername und Passwort fr den Web-Zugriff. Diese Daten sollten
nicht lokal gespeichert werden, da die Sicherheit der Authentisierung
darauf beruht, dass diese Daten ausschlielich dem jeweiligen Benutzer
bekannt sind und dieser sie bei jeder Authentisierung erneut eingibt. Leider
bieten moderne Browser vielfach die Mglichkeit, diese Daten lokal zu
speichern, so dass sie bei spteren Zugriffen auf die ebenfalls gespeicherte
Adresse des Servers automatisch an den Server bertragen werden. Daher
mssen die Benutzer darauf hingewiesen werden, dass das Passwort fr
den Web-Zugriff nicht lokal gespeichert werden darf.
- Kryptographische Schlssel und Zertifikate, die im Rahmen der SSL-
Client-Authentisierung benutzt werden. Da diese Authentisierungsdaten
nur in maschinenlesbarer Form vorliegen, ist die Speicherung der Daten
notwendig. In der Regel werden die Daten lokal auf dem Client abgelegt.
Generell kann unterschieden werden zwischen der physikalischen Sicherheit Sicherheit des Rechners
und des Browsers
des als Client verwendeten Rechners und der Sicherheit des als Web-Client
benutzten Browsers. Dadurch ergeben sich die im folgenden beschriebenen
Sicherheitsaspekte.
Durch das lokale Speichern der Authentisierungsdaten kommt der physika-
lischen Sicherheit besondere Bedeutung zu. Daher sollten fr die Client-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sicherheit die jeweiligen Bausteine aus Kapitel 5 sorgfltig umgesetzt werden.

Insbesondere sollten folgende Manahmen, sofern sie anwendbar sind, fr die
genutzten Rechner umgesetzt werden:
- M 4.1 Passwortschutz fr IT-Systeme
- M 1.33 Geeignete Aufbewahrung tragbarer PCs bei mobilem Einsatz
- M 1.34 Geeignete Aufbewahrung tragbarer PCs im stationren Einsatz
- M 1.44 Geeignete Einrichtung eines huslichen Arbeitsplatzes
- M 1.46 Einsatz von Diebstahl-Sicherungen
Zustzlich muss auch die Sicherheit des Browsers in Betracht gezogen
werden. Dies gilt insbesondere, wenn Authentisierungsdaten durch den
Browser lokal abgespeichert werden. Es mssen u. a. folgende Fragestellun-
gen bercksichtigt werden:
- Wo werden die Authentisierungsdaten gespeichert?
Mgliche Speicherorte sind z. B. eine Datei, eine Datenbank, die Registry,
eine Chipkarte oder der Systemzertifikatsspeicher (bei Windows 2000).
- Werden die Authentisierungsdaten geschtzt gespeichert?
Mgliche Schutzmechanismen sind beispielsweise Verschlsselung, Pass-
wort-Schutz oder ein PIN-geschtztes Hardware-Token (etwa eine Chip-
karte).
- Wie stark ist der Schutz der eingesetzten Sicherheitsmechanismen?
Bei Verschlsselung wird die Strke des Schutzes wesentlich durch die
eingesetzten Verfahren und die verwendeten Schlssellngen bestimmt.
Werden Authentisierungsdaten lokal auf dem Client gespeichert, so sollten
diese Daten so geschtzt sein, dass sie auch nach einer erfolgten physika-
lischen Kompromittierung des Rechners oder der Schutzmechanismen des
Betriebssystems nicht erlangt werden knnen. Dies erfordert in der Regel den
Einsatz von Verschlsselungsmechanismen durch den Browser. Werden diese
Anforderungen durch den Browser nicht erfllt, so muss im Rahmen einer
Risikoabschtzung entschieden werden, ob der Web-Zugriff dennoch erlaubt
werden soll. Dies hngt letztendlich auch davon ab, auf welche Daten zuge-
griffen werden soll.
Ein weiteres Problemfeld stellen die beim Web-Zugriff verwendeten aktiven aktive Inhalte
Inhalte dar. Damit die Funktionalitt der Web-Schnittstelle maximal genutzt
werden kann, muss im verwendeten Browser die Verarbeitung und die
Ausfhrung aktiver Inhalte aktiviert werden, da die vom Domino Server
generierten HTML-Seiten JavaScript und Java-Applets enthalten. Wird die
entsprechende Untersttzung im Browser deaktiviert, so ist mit fast vollstn-
digem Funktionsverlust zu rechnen.
Wird der Browser auch zum Zugriff auf das Internet genutzt, so ist hier jedoch gemischte Nutzung des
Browsers vermeiden
in der Regel die Ausfhrung aktiver Inhalte zu deaktivieren (siehe M 5.69
Schutz vor aktiven Inhalten). Erfolgt die Umstellung durch den
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Benutzer selbst, so kann durch die gemischte Nutzung leicht das Abschalten
aktiver Inhalte fr den Internetzugriff vergessen werden. Dies bedeutet dann
eine erhhte Gefahr fr das lokale Rechnernetz, da nun u. U. schdliche aktive
Inhalte durch den Browser ausgefhrt werden. Eine gemischte Nutzung des
Browsers sollte daher nach Mglichkeit vermieden werden.
Bei der Nutzung von Browsern knnen durch falsche Handhabung durch die Benutzer einweisen
Benutzer verschiedene Sicherheitsprobleme auftreten. Daher mssen die
Benutzer in deren sichere Bedienung eingewiesen und verpflichtet werden, die
aufgefhrten Sicherheitsrichtlinien zu beachten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.128 Sicherer Betrieb von Lotus Notes

Die Sicherheit eines komplexen Systems muss im Betrieb permanent
aufrechterhalten werden, insbesondere da sich im laufenden Betrieb notwen-
dige Systemvernderungen ergeben. Es gengt daher nicht, eine sichere
Anfangskonfiguration zu erzeugen (siehe M 4.116 Sichere Installation von
Lotus Notes und M 4.117 Sichere Konfiguration eines Lotus Notes Servers).
Folgende Sicherheitsaspekte sind im laufenden Betrieb fr ein Lotus Notes
System zu bercksichtigen.
- Die Sicherheit, die die Zugriffsmechanismen auf Lotus Notes Server und Sicherheit der Notes-ID
ist wesentlich fr die
Datenbanken bieten, basiert auf der Authentisierung der Benutzer durch Gesamtsicherheit von
ihre Notes-ID, die in einer Datei gespeichert wird. Die Systemsicherheit Lotus Notes
hngt damit direkt von der Sicherheit im Umgang mit der Notes-ID-Datei
ab. Im Rahmen des Sicherheitskonzepts (siehe M 2.207 Festlegen einer
Sicherheitsrichtlinie fr Lotus Notes), sind daher u. a. auch Richtlinien fr
den Umgang mit Notes-ID-Dateien festzulegen. Die dabei zu
bercksichtigenden Aspekte sind in der Manahme M 4.129 Sicherer
Umgang mit Notes-ID-Dateien zusammengefasst.
- Vernderungen in einem Notes-System ergeben sich insbesondere dann, sorgfltige Installation
von Datenbanken
wenn neue Datenbanken auf einem Server erzeugt werden. Neu angelegte
Datenbanken sind jedoch in der Regel noch nicht in die bestehenden
Sicherheitsstrukturen eingebunden. Die Installation einer Datenbank sollte
daher erst als abgeschlossen betrachtet werden, wenn mindestens die in der
Manahme M 4.130 Sicherheitsmanahmen nach dem Anlegen neuer
Lotus Notes Datenbanken zusammenfassten Schritte durchgefhrt worden
sind. Die Berechtigung zum Erstellen neuer Datenbanken oder zum Erzeu-
gen von Datenbank-Repliken kann explizit durch entsprechende Zugriffs-
listen gesteuert werden (siehe M 4.119 Einrichten von Zugangsbeschrn-
kungen auf Lotus Notes Server).
- Die in verschiedenen Datenbanken enthaltenen Daten besitzen in der Regel Verschlsselung von
Datenbanken
unterschiedlichen Schutzbedarf (siehe auch Kapitel 2.2 Schutzbedarfs-
feststellung). Lotus Notes bietet neben der reinen Zugriffskontrolle auch
die Mglichkeit, Datenbanken zu verschlsseln. Ergibt die Schutzbedarfs-
feststellung fr eine Datenbank die Notwendigkeit, die Daten mittels
Verschlsselung zu schtzen, so sind die Empfehlungen aus M 4.131
Verschlsselung von Lotus Notes Datenbanken zu bercksichtigen.
- Um Aussagen ber die Sicherheit eines Lotus Notes Systems zu erhalten, berwachung der
Systeme
ist es notwendig, das System zu berwachen. Ziel einer solchen ber-
wachung ist es, Verste gegen die geltenden Sicherheitsvorschriften zu
entdecken, bestehende Sicherheitslcken aufzudecken oder Fehlkonfi-
gurationen, die potentiell zu Sicherheitslcken fhren knnen, zu erkennen.
Ein entsprechendes berwachungskonzept sollte Teil des IT-Sicher-
heitskonzepts sein. Komplexe Systeme wie Lotus Notes knnen dabei in
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
der Regel nicht mehr manuell durch einzelne Administratoren berwacht

werden, sondern die berwachung muss automatisch durch entsprechende
Systemkomponenten oder Produkte von Drittherstellern erfolgen. Dabei
muss auch die Konfiguration der berwachung regelmig an das sich
verndernde System angepasst werden. Die Empfehlungen zur ber-
wachung sind in M 4.132 berwachen eines Lotus Notes-Systems zusam-
mengefasst.
- Ein wichtiger Aspekt der Sicherheit eines Lotus Notes Systems ist die gruppenbasiertes
Zugriffskonzept
konsistente Verwaltung von Benutzern und Berechtigungen. Das adminis-
trative Konzept hat dabei Auswirkungen auf die Komplexitt der durchzu-
fhrenden administrativen Aufgaben. Komplexe Ablufe knnen jedoch
dazu fhren, dass Fehlkonfigurationen entstehen. Um einen sicheren
Systemzustand zu erhalten, sollten die administrativen Aufgaben daher
mglichst einfach sein. Das Zugriffskonzept sollte deshalb auf Gruppen
basieren. Dadurch wird die Verwaltung von Zugriffsrechten auf Datenban-
ken wesentlich vereinfacht und weniger fehleranfllig. Beispielsweise
sollte im Rahmen des Gruppenkonzeptes eine sogenannte "Termination
Group" vorgesehen werden, in die alle "gelschten" Benutzer bernommen
werden und der alle Rechte explizit verweigert sind.
Hinweis: Unter der Version 4.x knnen Gruppen nur eine bestimmte
Anzahl von Benutzern aufnehmen, da diese in einem entsprechenden Feld
im Serverdokument gespeichert werden. Wird die maximale Feldgre
erreicht, so funktioniert die jeweilige Gruppe nicht mehr korrekt. Bei
Gruppen mit vielen Mitgliedern (z. B. alle Serverbenutzer, Termination
Group) empfiehlt sich daher die Schachtelung von Gruppen.
- Die Sicherheitseinstellungen eines Servers sollten regelmig berprft
werden.
- Die Protokolldateien eines Servers sollten regelmig berprft werden.
Dies kann manuell oder mit Hilfe von Tools geschehen.
Beispiele:
- Gruppenbasiertes Zugriffskonzept:
Ein Mitarbeiter wechselt die Abteilung, wodurch die Anpassung der
Zugriffsrechte erforderlich ist.
Werden benutzerbezogene ACL-Listen genutzt, so muss jede Datenbank
"angefasst" werden, um den Benutzer entweder aus der ACL-Liste auszu-
tragen oder neu einzutragen.
Werden gruppenbezogene ACL-Listen genutzt, so muss der Benutzer
lediglich in der Benutzerverwaltung aus den relevanten Gruppen entfernt
bzw. eingetragen werden. Die nderung kann zentral auf dem Benutzer-
objekt erfolgen.
- Termination Group:
Ein Mitarbeiter verlsst das Unternehmen. Das Konto wird versehentlich
nicht aus einer Notes-Gruppe gelscht. ber diese Gruppenmitgliedschaft
besitzt der ehemalige Mitarbeiter weiterhin das Recht, auf den Notes-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Server zuzugreifen. Da sein Notes-Konto jedoch auch in die Termination

Group eingefgt wird, erhlt er keinen Zugriff auf den Server. Der Grund
ist, dass der Termination Group explizit der Zugriff auf den Server (und
dessen Datenbanken) verweigert ist und Verweigerungen vorrangig
gegenber Zugestndnissen von Zugriffsrechten sind.
- Werden die Sicherheitseinstellungen der Notes Server regelmig ber-
prft?
- Werden die Protokolldateien der Notes Server regelmig berprft?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.129 Sicherer Umgang mit Notes-ID-Dateien

Lotus Notes-Benutzer authentisieren sich einem Domino Server gegenber Notes-ID ist
sicherheitskritisch
durch die Notes-ID. Die Notes-ID liegt in Form einer Datei vor und wird in
der Regel mit dieser identifiziert. In der Notes-ID knnen - neben dem Notes-
Zertifikat (zertifizierter ffentlicher Schlssel) und dem zugehrigen privaten
Schlssel eines Benutzers - auch weitere Informationen gespeichert werden.
So sind darin u. a. auch Internet-Zertifikate, symmetrische Verschlsselungs-
schlssel und Informationen, die zum Wiederherstellen von Notes-ID-Dateien
(Recovery-Informationen) bentigt werden, enthalten. Alle diese Informatio-
nen werden durch das sogenannte Notes-ID-Passwort geschtzt. Bevor die
Notes-ID genutzt werden kann, muss der Benutzer das entsprechende Pass-
wort eingeben. Da eine Notes-ID sicherheitskritische Informationen enthlt,
kommt ihr ein erhhter Schutzbedarf zu. Folgende Aspekte sind daher fr den
Umgang mit Notes-IDs zu bercksichtigen:
Notes-IDs knnen in vier Kategorien unterteilt werden: vier verschiedene
Kategorien von
1. Certifier-IDs: Diese stellen die Identitten dar, die Notes-IDs fr Server Notes-IDs
und Benutzer ausstellen. In der Regel reprsentieren Certifier-IDs organi-
satorische Einheiten innerhalb einer Behrde bzw. eines Unternehmens
und bilden eine Hierarchie. Certifier-IDs sind aufgrund ihres Verwen-
dungszwecks besonders sicherheitskritisch und mssen daher besonders
geschtzt werden. Dies gilt insbesondere fr die erste erzeugte Certifier-ID
- die sogenannte Root-Certifier-ID - mit der alle weiteren Certifier-IDs
signiert werden.
2. Server-IDs: Diese weisen Server gegenber Benutzern (genauer: deren
Notes-Clients) und anderen Servern aus. Damit ein Server lauffhig ist,
bentigt er eine eigene Identitt in Form der Server-ID. Die Server-ID wird
whrend der Serverinstallation automatisch erzeugt und durch eine
Certifier-ID zertifiziert. Da Server-IDs fr ausgezeichnete Systemkompo-
nenten zur Identifikation benutzt werden, mssen sie entsprechend gut
geschtzt werden.
3. Administrator-IDs: Diese weisen Administratoren gegenber Servern aus.
Administrator-IDs unterscheiden sich von Benutzer-IDs durch erweiterte
Privilegien, die die Administration von Servern ermglicht. Da Adminis-
tratoren unter den Benutzern eine privilegierte Stellung einnehmen, mssen
Administrator-IDs besonders geschtzt werden.
4. Benutzer-IDs: Diese weisen normale Benutzer gegenber Servern aus.
Entsprechend den unterschiedlichen Sicherheitsanforderungen mssen unter-
schiedliche Schutzmanahmen fr Notes-IDs getroffen werden. Zu betrachten
sind dabei die Aspekte
- Erzeugung,
- Gltigkeitsdauer,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Passwortqualitt,
- Verteilung und Aufbewahrungsort sowie
- Wiederherstellung.
Fr die Passwrter knnen Qualittsanforderungen beim Erzeugen einer neuen Qualittsskala fr
Passwrter
Benutzer-ID festgelegt werden. Dafr steht eine numerische Qualittsskala
von 0 (kein Passwort) bis 16 zur Verfgung. Generell stimmt zwar die
akzeptierte Passwortlnge mit dem numerischen Qualittswert berein, ist
jedoch nicht das einzige Bewertungskriterium. Leider ist aber zur Zeit keine
Liste von Lotus verfgbar, in der beschrieben wird, welche genauen Voraus-
setzungen ein Passwort zum Erreichen eines speziellen Qualittsniveaus erfl-
len muss.
Fr die verschiedenen Kategorien von Notes-IDs enthlt die folgende Liste
entsprechende Empfehlungen, die je nach Anforderungen adaptiert und erwei-
tert werden knnen.
- Certifier/Root-Certifier-ID:
- Erzeugung: Die ID wird automatisch beim Einrichten des ersten
Notes-Servers erzeugt. Erzeugung in sicherer Umgebung, unter
Vier-Augen-Prinzip.
- Gltigkeit: Lange Gltigkeit (mehrere Jahrzehnte, Default = 100
Jahre), wird nie gewechselt (Ausnahme: Kompromittierung der
Certifier-ID).
- Passwort: Mehrfachpasswort notwendig (mindestens zwei Perso-
nen, Vier-Augen-Prinzip). Erfordert sichere Passwrter (Notes-
Qualitt mindestens 10). Zur Realisierung des Vier-Augen-Prinzips
bietet Notes die Mglichkeit an, eine Notes-ID-Datei mit mehreren
Passwrtern zu schtzen. Die Notes-ID-Datei kann nur nach Eingabe
aller Passwrter verwendet werden. Es sind Intervalle fr den
erzwungenen Passwortwechsel anzugeben (empfohlen werden
hchstens 30 bis 40 Tage).
- Speicherung: Wird beim Anlegen neuer Benutzer oder Server
bentigt. Eine Speicherung im Namens- und Adressbuch (NAB) ist
nicht zulssig. Speicherung nur auf mobile Datentrger, z. B. Dis-
kette oder CD-ROM, zwei Sicherheitskopien mit hinterlegten Pass-
wrtern, an verschiedenen Orten vor fremden Zugriffen geschtzt
aufzubewahren.
- Wiederherstellung: Muss Wiederherstellungsinformationen enthal-
ten, damit damit zertifizierte Benutzer-IDs wiederhergestellt werden
knnen. Fr die Wiederherstellung sind weitere Schritte notwendig
(z. B. das Anlegen einer Datenbank), die in der Notes-Hilfe
beschrieben sind.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Server-ID:
- Erzeugung: Die ID wird automatisch bei der Serverinstallation
erzeugt. Erzeugung in sicherer Umgebung. Nutzung des Vier-
Augen-Prinzips.
- Gltigkeit: Lange Gltigkeit (mehrere Jahrzehnte, Default = 100
Jahre), wird nie gewechselt (Ausnahme: Kompromittierung).
- Passwort: Die Verwendung eines Passwortes erfordert die Pass-
worteingabe bei jedem Serverstart. Falls keine organisatorischen
Grnde dagegen sprechen (z. B. wenn der Remote-boot von Servern
an verschiedenen Standorten regelmig und ohne Vor-Ort-Unter-
sttzung erfolgen muss), wird die Nutzung von Server-ID-Pass-
wrtern empfohlen. Sicherheitskopien mssen immer mit einem
Passwort versehen sein. Es sind Intervalle fr den erzwungenen
Passwortwechsel anzugeben (empfohlen werden hchstens 60 Tage).
- Speicherung: Wird bei jedem Serverstart bentigt. Speicherung im
"Data"-Verzeichnis des Notes-Servers. Darf nicht auf einem Netz-
Share liegen. Eine Speicherung im Namens- und Adressbuch (NAB)
ist nicht zulssig. Wird kein Passwort verwendet (automatischer
Server-Restart), mssen restriktive Dateiberechtigungen eingerichtet
werden. Achtung: Kann eine nicht passwortgeschtzte Server-ID
von einem Unbefugten zugegriffen werden, so kann dieser (unter
den meist privilegierten Berechtigungen) auf andere Server zugrei-
fen. Sicherheitskopien analog zur Certifier-ID.
- Wiederherstellung: Enthlt die Wiederherstellungsinformationen
der Certifier-ID, mit der die Server-ID zertifiziert wurde.
- Administrator-ID:
- Erzeugung: Wird automatisch bei der Serverinstallation erzeugt
(Datei: "User.id"). Erzeugung in sicherer Umgebung. Nutzung des
Vier-Augen-Prinzips.
- Gltigkeit: Die Gltigkeit muss den lokalen Gegebenheiten ange-
passt werden. Hier mssen Sicherheit und administrativer Aufwand
beim Wechsel der Adminstrator-ID gegeneinander abgewogen
werden.
- Passwort: Die Administrator-ID muss mit einem Passwort versehen
sein. Aufgrund der privilegierten Stellung ist ein sehr sicheres
Passwort zu whlen (mindestens Notes-Qualitt 9-10). Es sind
Intervalle fr den erzwungenen Passwortwechsel anzugeben
(empfohlen werden hchstens 90 Tage).
- Speicherung: Die Administrator-ID ist dem Administrator auf
sicherem Weg zuzustellen. Eine Speicherung im Namens- und
Adressbuch (NAB) ist nicht zulssig. Die Notes-ID-Datei ist vor
fremdem Zugriff geschtzt aufzubewahren. Das Anlegen einer
Sicherheitskopie empfiehlt sich.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

der Certifier-ID, mit der die Administrator-ID zertifiziert wurde.
- Benutzer-ID:
- Erzeugung: Wird durch die Benutzerverwalter eines Servers
erzeugt. Erzeugung in sicherer Umgebung. Nutzung des Vier-
Augen-Prinzips, da die Certifier-ID bentigt wird.
- Gltigkeit: Die Gltigkeit muss den lokalen Gegebenheiten ange-
passt werden. Eine Gltigkeit von 2 Jahren hat sich jedoch in der
Praxis bewhrt.
- Passwort: Benutzer-IDs mssen mit einem Passwort versehen
werden. Ein sicheres Passwort ist zu whlen (Notes-Qualitt
mindestens 8). Es sind Intervalle fr den erzwungenen Passwort-
wechsel anzugeben (empfohlen werden 90 Tage).
- Speicherung: Die Benutzer-ID ist dem Benutzer auf sicherem Weg
zuzustellen. Eine Speicherung im Namens- und Adressbuch (NAB)
ist nicht zulssig. Die Notes-ID ist vor fremden Zugriffen geschtzt
aufzubewahren. Das Anlegen einer Sicherheitskopie empfiehlt sich.
der Certifier-ID, mit der die Benutzer-ID zertifiziert wurde. Alte
Notes-ID-Dateien (Version 4.x) mssen auf den neuen Recovery-
Mechanismus der Version 5 umgestellt werden (siehe Notes-Hilfe).
Generell ist fr den Umgang mit Notes-IDs zu bercksichtigen, dass diese zur Notes-ID-Passwort
sicher whlen und nicht
eindeutigen Benutzerauthentisierung (Ausweis) genutzt werden. Zwar sind die weitergeben
Notes-ID-Dateien durch ein Passwort geschtzt, dies muss jedoch von
entsprechender Qualitt sein und darf nur dem Besitzer der Notes-ID bekannt
sein. Wird das Passwort kompromittiert, so knnen sich u. U. unberechtigte
Dritte mit der Notes-ID einem Server gegenber ausweisen.
Ein Benutzer (oder Administrator) kann auch mehrere Kopien einer Notes-ID
besitzen. Jede Notes-ID-Kopie eines Benutzers kann mit einem eigenen Pass-
wort versehen sein. Ist eine Notes-ID-Datei unbefugt kopiert und deren Pass-
wort kompromittiert worden, so kann die unbefugte Nutzung ohne zustzliche
Manahmen nicht durch den Passwortwechsel auf dem Original unterbunden
werden.
- Werden alle Notes-ID gesichert aufbewahrt, so dass das unbefugte Kopie-
ren nicht mglich ist?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.130 Sicherheitsmanahmen nach dem Anlegen

neuer Lotus Notes Datenbanken
Werden auf einem Server neue Datenbanken angelegt, so geschieht dies durch
die Nutzung von Datenbankvorlagen (Templates), die das Datenbankdesign
bestimmen. Einige Datenbankvorlagen werden mit der Domino Software
ausgeliefert, sie knnen jedoch auch von Drittherstellern stammen oder selbst
erstellt werden.
Die Datenbankvorlagen enthalten das Datenbankdesign, zu dem u. a. auch
Skripten und Agenten gehren. Insbesondere sind in der Datenbankvorlage
auch Voreinstellungen fr die Zugriffskontrollliste (Access Control List,
ACL) enthalten. Generell empfehlen sich folgende Schritte nach dem Anlegen
einer neuen Datenbank:
- Alle von der Datenbankvorlage erzeugten ACL-Eintrge sind zu ber- neue ACLs prfen
prfen.
- Insbesondere sind die Berechtigungen fr den "-Default-"-Eintrag zu ber-
prfen. In der Regel sollte der Zugriffslevel auf "No Access" gesetzt sein
bzw. dahingehend verndert werden. Einige Vorlagen gewhren hier zu
weitgehende Rechte (z. B. "Manager"-Recht) oder enthalten u. U. eine
fehlerhafte Bezeichnung fr dieses Standardrecht. In der Vorlage ist hier
die Bezeichnung "-Default-" enthalten, statt "Default". Dies fhrt in der
neu erzeugten Datenbank zum fehlerhaften Eintrag "--Default--". Als Folge
wird der so generierte Eintrag von Lotus Notes nicht mehr als "Default"-
ACL-Eintrag erkannt. Hier muss die Vorlage korrigiert werden. Der Fehler
resultiert daraus, dass beim Erstellen einer Datenbank aus einer Vorlage
einem Eintrag, der die Zeichenkette "Default" enthlt, das Zeichen "-" als
Begrenzer vor- und nachgestellt wird.
- Zur Steuerung des anonymen Zugriffs sollte der Benutzer "Anonymous"
eingetragen und zunchst der Zugriffslevel "No Access" zugewiesen
werden.
- Die ACL muss entsprechend der fr die Datenbank geplanten
Zugriffskontrolle eingerichtet werden (siehe auch M 4.120 Konfiguration
von Zugriffslisten auf Lotus Notes Datenbanken).
- Fr jede Datenbank muss ein administrativer Server bestimmt werden, der
den fr die Datenbank verantwortlichen "adminp"-Prozess ausfhrt und die
Verwaltung der Datenbank bernimmt.
- Ist der Zugriff auf die Datenbank ber die Web-Schnittstelle notwendig, so
sind die damit verbundenen Einstellungen vorzunehmen (siehe M 4.125
Einrichten von Zugriffsbeschrnkungen beim Browser-Zugriff auf Lotus
Notes Datenbanken).
- Sollen die Daten der Datenbank beim Web-Zugriff geschtzt werden, so SSL aktivieren
muss das Erzwingen der SSL-Absicherung aktiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Als abschlieende Manahme ist die Datenbank und deren Inhalte (Skripte, Datenbank signieren
Agenten, Ansichten usw.) zu signieren. Dazu sollte eine spezielle Notes-ID
verwendet werden. Dies dokumentiert, dass die Datenbank geprft und fr
die unbedenkliche (bestimmungsgeme) Verwendung freigegeben ist.
Enthalten Datenbanken Skripte oder Agenten, die zur Ausfhrung bestimmter
Aktionen Notes-Rollen benutzen, so muss eine Planung der Rollenverteilung
durchgefhrt werden. Dies setzt eine detaillierte Dokumentation des Designs
(bei Drittherstellern) oder eine enge Kooperation mit den Datenbankent-
wicklern (bei Eigenentwicklung) voraus. In der Regel muss das Datenbank-
design von Eigenentwicklungen die lokalen Sicherheitsvorschriften und das
benutzte administrative Konzept bercksichtigen und darauf aufbauen.
- Wurden nach dem Anlegen einer neuen Datenbank alle Einstellungen
berprft?
- Ist jede Datenbank und deren Inhalte signiert worden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.131 Verschlsselung von Lotus Notes Datenbanken

Die abstrakte Struktur von Lotus Notes Datenbanken kann wie folgt darge-
stellt werden. Eine Datenbank enthlt mehrere Dokumente und ein Dokument
besteht aus mehreren Dokumentfeldern. Die Felder enthalten nun die eigent-
lichen Daten. Wenn Datenbanken Daten mit erhhtem Schutzbedarf enthalten,
so knnen diese zustzlich durch Verschlsselung geschtzt werden. Die
Verschlsselung kann dabei entweder auf Datenbankebene angewandt werden
- hier wird der gesamte Inhalt der Datenbank verschlsselt - oder es kann die
Verschlsselung einzelner Dokumentfelder erfolgen, wenn die Datenbank
Daten mit unterschiedlichem Schutzbedarf enthlt. Beispielsweise knnen in
einer Produktdatenbank die Felder mit bestimmten Einkaufspreisen verschls-
selt vorgehalten werden. Eine Verschlsselung auf Dokumentebene ist nicht
vorgesehen. Der Speicherort einer Datenbank - auf dem Server oder lokal
beim Client - hat einen entscheidenden Einfluss auf die Verschlsselungs-
mglichkeiten.
Folgende Aspekte sind fr die beiden Verschlsselungsarten zu bercksichti-
gen:
Datenbankverschlsselung
- Die Datenbankverschlsselung schtzt Datenbanken vor Angriffen auf
Dateiebene.
- Eine Datenbank kann nur fr genau eine Notes-ID verschlsselt werden.
Die Datenbank kann dann nur noch unter dieser Notes-ID zugegriffen
werden. Dies hat folgende Konsequenzen:
- Datenbanken, die auf dem Server abgelegt sind, knnen ausschlie-
lich mit der Server-ID verschlsselt werden (da in letzter Konse-
quenz der Server unter der Server-ID im Auftrag eines Clients auf
die Datenbank zugreift). In diesem Fall kann die Verschlsselung
nicht dazu eingesetzt werden, die Datenbankinhalte fr genau einen
Benutzer zugreifbar zu machen.
- Datenbanken, die vom Server auf einen Client repliziert oder lokal
angelegt wurden, knnen mit einer (beliebigen) Benutzer-ID ver-
schlsselt werden. Dies erfordert Zugriff auf die jeweilige ID sowie
das jeweilige Passwort. Nun kann nur noch unter dieser Benutzer-ID
auf die Datenbank (lokal) zugegriffen werden. Wird die Datenbank
auf den Server zurckrepliziert, so liegt die Datenbank dort nicht
mehr mit der Benutzer-ID verschlsselt vor. Ist die auf dem Server
gespeicherte Datenbank mit der Server-ID verschlsselt, so bleibt
diese weiterhin verschlsselt. Ist die Datenbank nicht verschlsselt,
bleiben die Daten unverschlsselt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Verschlsselungsgrad kann in drei Stufen eingestellt werden:

- "einfach (simple)": Hierbei wird eine einfache, Notes-eigene Kodie-
rung benutzt.
- "mittel (medium)": Es wird ein Notes-eigenes Stream-Cipher
Verfahren angewandt.
- "stark (strong)": Hierbei wird ein auf RC2/RC4 basierendes Verfah-
ren eingesetzt, das aber auch Notes-spezifisch ist.
- Die Nutzung der Verschlsselungsstufe "einfach (simple)" kann fr ver-
trauliche Daten nicht empfohlen werden.
- Datenbanken, die mit dem Verschlsselungsgrad "mittel (medium)" oder
"stark (strong)" verschlsselt wurden, knnen nicht komprimiert vorgehal-
ten werden.
- Die Daten zwischen Server und Client werden bei der Datenbankver-
schlsselung unverschlsselt ber das Notes-Protokoll bertragen. Gegen
Abhren mssen sie also zustzlich geschtzt werden (siehe dazu auch
M 5.84 Einsatz von Verschlsselungsverfahren fr die Lotus Notes
Kommunikation).
Feldverschlsselung
- Die Feldverschlsselung erlaubt den Schutz vor Angriffen auf Datei-
systemebene und bietet auch Schutz vor unerlaubter Einsichtnahme durch
den Administrator.
- Felder mssen durch das Datenbankdesign fr die Verschlsselung vorge-
sehen sein.
- Es knnen nur alle verschlsselbaren Felder eines Dokumentes gleichzeitig
verschlsselt/entschlsselt werden.
- Die Entschlsselung/Verschlsselung findet durch den Client statt. Die
verschlsselten Daten werden daher verschlsselt vom Server zum Client
bertragen.
- Zur Feldverschlsselung knnen sowohl symmetrische als auch asymme-
trische Schlssel eingesetzt werden.
- Es knnen gleichzeitig mehrere Schlssel (symmetrische und asymme-
trische) eingesetzt werden, so dass eine Verschlsselung fr mehrere
Benutzer erreicht werden kann.
- Symmetrische Schlssel knnen von jedem Benutzer mit dem Notes-Client
erzeugt werden. Fr den Schlsselaustausch sollten folgende Empfehlun-
gen bercksichtigt werden:
- Fr Gruppen muss der gemeinsame, geheime Schlssel auf sicherem
Weg verteilt werden. Der Notes-Client stellt hier eine E-Mail-
basierte Mglichkeit zur Verfgung, die den Schlssel geschtzt
bertrgt.
- Alternativ besteht die Mglichkeit, den Schlssel in eine (zunchst
ungeschtzte) Datei zu exportieren. Diese lsst sich mit einem
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Passwort verschlsseln und damit vor unberechtigtem Zugriff

sichern. Das Passwort muss den Empfngern der Datei jedoch auf
sicherem Weg mitgeteilt werden.
- Die Weitergabe eines solchen Schlssels durch die Empfnger an
Dritte kann durch eine entsprechende Option verhindert werden, so
dass die Nutzung des Schlssels auf die Empfnger begrenzt werden
kann.
- Beim Einsatz asymmetrischer Schlssel werden die ffentlichen Schlssel
der Benutzer verwendet, die auf die Feldinhalte zugreifen sollen. Dabei
werden die ffentlichen Notes-Schlssel benutzt, auf die ber das Namens-
und Adressbuch zugegriffen werden kann.
- Es muss sichergestellt sein, das die Verschlsselung mit jeweils mindestens
einem Schlssel der Benutzer erfolgt, die auf die verschlsselten
Feldinhalte zugreifen mssen.
Hinweis: Die Nutzung von sogenannten "hidden paragraphs" - Textfeldern, Verstecken schtzt nicht
die jedoch nicht angezeigt werden - ist nicht dafr geeignet, sensitive Daten zu
schtzen. Auch deren Inhalte knnen angezeigt werden, beispielsweise im
Eigenschaftsdialog einer Datenbank oder mit dem Notes-Designer.
In Abhngigkeit von der Art der in einer Datenbank gespeicherten Informa-
tionen und den sich daraus ergebenden Anforderungen an deren Vertraulich-
keit und Integritt kann es notwendig werden, diese Daten zu verschlsseln.
Die Randbedingungen hierbei sollten geregelt werden, z. B. in der Sicher-
heitsrichtlinie fr Lotus Notes (siehe M 2.207). Die Benutzer mssen ber die
Funktionsweise und Schutzmechanismen bei der Verschlsselung von Lotus
Notes Datenbanken informiert sein.
- Existiert ein Konzept fr die Verschlsselung von Lotus Notes Daten-
banken?
- Sind die Verantwortlichen ber ein ordnungsgemes Schlsselmanage-
ment informiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.132 berwachen eines Lotus Notes-Systems

Damit die Sicherheit eines Notes-Systems im laufenden Betrieb aufrecht
erhalten werden kann, ist eine berwachung des Systems unumgnglich. Nur
so lassen sich mgliche Konfigurationsfehler, eventuelle Sicherheitslcken,
Sicherheitsverste durch Benutzer oder Angriffe auf das System in Erfah-
rung bringen.
Bei der berwachung des Systems mssen in der Regel auch benutzerbe- benutzerbezogene Daten
zogene Daten gesammelt werden. Anderenfalls ist es nicht mglich, Benutzer
im Fall von Sicherheitsversten zur Verantwortung zu ziehen. Daher muss
mglichst frhzeitig der Datenschutzbeauftragte sowie der Personal- bzw.
Betriebsrat in die Planung des berwachungskonzepts einbezogen werden.
Lotus Notes bietet insbesondere unter IT-Sicherheitsaspekten bisher keinen
systematischen Auditing-Mechanismus, vielmehr werden Systemaktivitten in
verschiedenen Protokolldateien erfasst. Allerdings ist es mglich, automatisch
auf das Auftreten verschiedener Systemereignisse zu reagieren.
Generelle Empfehlungen zu Logging-Einstellungen knnen an dieser Stelle
nicht gemacht werden, da die Art und der Umfang der zu protokollierenden
Informationen stark vom jeweiligen Einsatzszenario und dem verwendeten
berwachungskonzept abhngt.
Folgendes ist fr die berwachung eines Notes-Systems zu bercksichtigen:
- Einige Protokoll-Datenbanken mssen explizit durch den Administrator Datenbank "certlog.nsf"
anlegen
oder Auditor angelegt werden (z. B. "certlog.nsf") oder das Erzeugen von
Protokolleintrgen muss konfiguriert werden (z. B. "domlog.nsf"). Das
Anlegen der Datenbank "certlog.nsf" wird dringend empfohlen, damit die
durch den jeweiligen Server zertifizierten Benutzer dokumentiert werden
knnen.
- Die Granularitt der Protokolleintrge ist vielfach nicht ausreichend, um
eine detaillierte berwachung zu gewhrleisten. Je nach Anforderungen
mssen hier u. U. weitere Manahmen auerhalb des Notes-Systems
ergriffen werden (z. B. durch den Einsatz von Drittprodukten, organisa-
torische Manahmen oder Eigenentwicklungen).
- Aktivitten auf den Clients werden nicht in den Server-Protokolldateien Protokollierung auf
Servern und Clients
erfasst. Es existieren jedoch auch lokale Protokolldateien auf den Clients.
- Die Protokolldateien knnen in mittleren und groen Systemen nur noch
werkzeuggesttzt berwacht und ausgewertet werden. Dritthersteller bieten
hierfr entsprechende Zusatzwerkzeuge an.
- Fr die Protokolldateien mssen restriktive Zugriffsrechte vergeben restriktive Zugriffsrechte
auf Protokolldaten
werden. Die Zugriffrechte fr Administratoren mssen je nach Auditing-
Sicherheitsrichtlinie entzogen werden. Statt dessen erhalten Revisoren ent-
sprechende Zugriffsrechte (in der Regel "Reader"-Zugriff).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Event-Datenbank ("events4.nsf") erlaubt die Definition von ber- berwachungsregeln

wachungsregeln, die beim Auftreten von bestimmten Ereignissen vordefi- einrichten
nierte Aktionen auslsen (z. B. Benachrichtigungen von Adminstratoren
oder Eintrge in das Betriebssystemprotokoll). Insbesondere fr die
Ereignisse der Kategorie "Sicherheit (Security)" mssen entsprechende
Aktionen gem berwachungskonzept eingerichtet werden.
- Der Protokollierungsgrad kann ber die Konfigurationsdatei von Lotus
Notes, z. B. "notes.ini" unter Windows NT, gesteuert werden. Die vorge-
gebenen Werte sollen berprft und gegebenenfalls angepasst werden.
- Die Gre der Protokolldateien muss der Serverbelastung angepasst
werden. So kann die Protokolldatei "log.nsf" von Lotus Notes ber Ein-
trge in der Konfigurationsdatei (z. B. den Parameter
"log=log.nsf,1,0,7,40000" in "notes.ini" unter Windows NT) konfiguriert
werden. Bei der Planung des Auditing-Konzeptes ist darauf zu achten, dass
keine Protokolleintrge unbeabsichtigt verloren gehen knnen.
- Wie knnen Protokolldateien gesichert und aufbewahrt werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.133 Geeignete Auswahl von Authentikations-

Mechanismen
Die Identifikations- und Authentikations-Mechanismen von IT-Systemen bzw.
IT-Anwendungen mssen so gestaltet sein, dass Benutzer eindeutig identifi-
ziert und authentisiert werden. Die Identifikation und Authentisierung muss
vor jeder anderen Interaktion zwischen IT-System und Benutzer erfolgen.
Weitere Interaktionen drfen nur nach der erfolgreichen Identifikation und
Authentisierung mglich sein. Die Authentisierungsinformationen mssen so
gespeichert sein, dass nur autorisierte Benutzer darauf Zugriff haben (sie
prfen oder ndern knnen). Bei jeder Interaktion muss das IT-System die
Identitt des Benutzers feststellen knnen.
Vor der bertragung von Nutzerdaten muss der Kommunikationspartner Systemnutzung immer
erst nach Identifikation
(Rechner, Prozess oder Benutzer) eindeutig identifiziert und authentisiert sein. und Authentikation
Erst nach der erfolgreichen Identifikation und Authentisierung darf eine
bertragung von Nutzdaten erfolgen. Beim Empfang von Daten muss deren
Absender eindeutig identifiziert und authentisiert werden knnen. Alle
Authentisierungsdaten mssen vor unbefugtem Zugriff und vor Flschung
geschtzt sein.
Im Folgenden werden verschiedene Kriterien aufgezeigt, die bei der Auswahl Auswahlkriterien
von Identifikations- und Authentikations-Mechanismen beachtet werden
sollten. Nicht alle marktgngigen Systeme erfllen alle Kriterien, diese sollten
aber bei der Auswahl entsprechend bercksichtigt werden. Viele IT-Produkte
beinhalten bereits neben ihrer eigentlichen Funktionalitt Authentikations-
mechanismen, beispielsweise Betriebssysteme. Hier ist zu berprfen, ob
diese den Ansprchen gengen oder ob sie um zustzliche Funktionalitten
erweitert werden mssen. Auch dazu eignen sich die folgenden Kriterien.
Administration der Authentikationsdaten
Es mssen Sicherheitsfunktionen bereitstehen, um Authentikationsdaten fr
Benutzer anlegen und verndern zu knnen. Diese Funktionen sollten nur von
dem autorisierten Administrator ausgefhrt werden knnen. Bei der Verwen-
dung von Passwrtern sollten autorisierte Benutzer ihre eigenen Authenti-
kationsdaten innerhalb festgesetzter Grenzen verndern knnen. Das
IT-System sollte einen geschtzten Mechanismus zur Verfgung stellen,
damit Benutzer ihre Passwrter selbststndig verndern knnen. Dabei sollte
es mglich sein, eine Mindestlebensdauer fr Passwrter vorzugeben.
Nach einer erfolgreichen Anmeldung sollte dem Benutzer Zeit und Ort seines
letzten erfolgreichen Zugriffs angezeigt werden.
Schutz der Authentikationsdaten gegen Vernderung
Das IT-System muss die Authentikationsdaten bei der Verarbeitung jederzeit
gegen Aussphung, Vernderung und Zerstrung schtzen. Dies kann
beispielsweise durch Verschlsselung der Passwortdateien und durch Nicht-
Anzeigen der eingegebenen Passwrter geschehen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Die Authentikationsdaten sind getrennt von Applikationsdaten zu speichern.

Systemuntersttzung
Beim Einsatz von organisationsweiten Authentikationsverfahren sollten diese
nur auf Servern betrieben werden, deren Betriebssystem einen adquaten
Schutz gegen Manipulationen bietet.
Bei der Auswahl von Authentikationsverfahren sollte darauf geachtet werden,
dass diese mglichst plattformbergreifend eingesetzt werden knnen.
Fehlerbehandlung bei der Authentikation
Das IT-System sollte Anmeldevorgnge nach einer vorgegeben Anzahl erfolg-
loser Authentikationsversuche beenden knnen. Nach Ende eines erfolglosen
Anmeldevorgangs muss das IT-System den Benutzer-Account bzw. das
Terminal sperren knnen bzw. die Verbindung unterbrechen. Nach erfolglosen
Authentikationsversuchen sollte das IT-System jeden weiteren Anmel-
deversuch zunehmend verzgern (Time-delay). Die Gesamtdauer eines
Anmeldeversuchs sollte begrenzt werden knnen.
Administration der Benutzerdaten
Das IT-System sollte die Mglichkeit bieten, den Benutzern verschiedene
Voreinstellungen zuweisen zu knnen. Diese sollten angezeigt und verndert
werden knnen. Die Mglichkeit, Benutzerdaten zu verndern, muss auf den
autorisierten Administrator beschrnkt sein. Wenn die Administration der
Benutzerdaten ber eine Kommunikationsverbindung erfolgen soll, muss
diese ausreichend kryptographisch gesichert sein.
Definition der Benutzereintrge
Das IT-System muss die Umsetzung der Sicherheitspolitik ermglichen,
indem fr jeden Benutzer die entsprechenden Sicherheitseinstellungen gewhlt
werden knnen.
Ein Authentikationsverfahren sollte auch erweiterbar sein, z. B. um die
Untersttzung starker Authentikations-Techniken wie dem Einsatz von Token
oder Chipkarten (siehe auch M 5.34 Einsatz von Einmalpasswrtern).
Passwortgte
Wenn Passwrter zur Authentikation eingesetzt werden, sollte das IT-System
Mechanismen bieten, die folgende Bedingungen erfllen:
- Es wird gewhrleistet, dass jeder Benutzer individuelle Passwrter benutzt
(und diese auch selbst auswhlen kann).
- Es wird berprft, dass alle Passwrter den definierten Vorgaben gengen
(z. B. Mindestlnge, keine Trivialpasswrter). Die Prfung der Passwort-
gte sollte individuell regelbar sein. Beispielsweise sollten vorgegeben
werden knnen, dass die Passwrter mindestens ein Sonderzeichen enthal-
ten mssen oder bestimmte Zeichenkombinationen verboten werden.
- Das IT-System generiert Passwrter, die den definierten Vorgaben gen-
gen. Das IT-System muss die so erzeugten Passwrter dem Benutzer
anbieten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Der Passwortwechsel sollte vom System regelmig initiiert werden. Die

Lebensdauer eines Passwortes sollte einstellbar sein.
- Die Wiederholung alter Passwrter beim Passwortwechsel sollte vom
IT-System verhindert werden (Passwort-Historie).
- Bei der Eingabe sollte das Passwort nicht auf dem Bildschirm angezeigt
werden.
- Nach der Installation bzw. der Neueinrichtung von Benutzern sollte das
Passwort-System einen Passwort-Wechsel nach der Erst-Anmeldung
erzwingen.
Anforderungen an Authentikationsmechanismen fr Benutzer
Das IT-System muss vor jeder anderen Benutzertransaktion die Benutzer-
identitt berprfen. Das IT-System sollte darber hinaus das Wiederein-
spielen von Authentikationsdaten fr Benutzer oder das Einspielen geflschter
oder kopierter Benutzerauthentikationsdaten erkennen und verhindern knnen.
Das IT-System darf die Authentikationsdaten erst dann berprfen, wenn sie
vollstndig eingegeben wurden.
Es sollte fr jeden Benutzer individuell einstellbar sein, wann und von wo er
auf das IT-System zugreifen darf.
Protokollierung der Authentisierungsmechanismen
Das IT-System muss die folgenden Ereignisse protokollieren knnen:
- Ein- und Ausschalten der Protokollierung.
- Jeden Versuch, auf Mechanismen zum Management von Authentikations-
daten zuzugreifen.
- Erfolgreiche Versuche, auf Authentikationsdaten zuzugreifen.
- Jeden Versuch, unautorisiert auf Benutzer-Authentikationsdaten zuzugrei-
fen.
- Jeden Versuch, auf Funktionen zur Administration von Benutzer-Eintrgen
zuzugreifen.
- nderungen an Benutzereintrgen.
- Jeden durchgefhrten Test auf Passwort-Gte.
- Jede Benutzung von Authentisierungsmechanismen.
- Jede Konfiguration der Abbildung von Authentisierungsmechanismen zu
spezifischen Authentikationsereignissen.
- Die Installation von Authentisierungsmechanismen.
Jeder Protokollierungseintrag sollte Datum, Uhrzeit, Art des Ereignisses,
Bezeichnung des Subjektes sowie Erfolg bzw. Misserfolg der Aktion enthal-
ten.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.134 Wahl geeigneter Datenformate

Verantwortlich fr Umsetzung: Leiter IT, Benutzer
Es gibt eine Vielzahl von unterschiedlichen Datenformaten, die von den ver-
schiedenen IT-Anwendungen untersttzt werden. Diese sind allerdings im
Allgemeinen nicht kompatibel, also untereinander austauschbar. Leider
knnen hufig nicht einmal IT-Anwendungen mit demselben Aufgabenfeld
(z. B. Textverarbeitungssysteme) mit den Datenformaten hnlicher Produkte
umgehen. Dieses Problem wird noch dadurch gesteigert, dass oft Anwen-
dungsprogramme nach einem Versionswechsel die Datenformate ihrer
Vorgnger nicht mehr verarbeiten knnen.
Daher muss bei der Beschaffung neuer Anwendungsprogramme untersucht Kompatibilitt neuer
Programme hinterfragen
werden, welche Datenformate untersttzt werden und wie verbreitet die
untersttzten Datenformate sind. Da viele wichtige Vorgnge dauerhaft elek-
tronisch gespeichert werden sollen, ist es ebenso wichtig zu hinterfragen,
welche "Lebensdauer" von einem Datenformat erwartet wird. Generell sollte
bei jedem Systemwechsel berprft werden, ob alle gespeicherten Daten mit
den neuen IT-Systemen oder IT-Anwendungen noch verarbeitet werden
knnen.
Ebenso muss aber auch bei jeder Nutzung eines Anwendungsprogramms Kann der Empfnger die
Daten lesen?
berlegt werden, in welchem Format die bearbeiteten Daten gespeichert
werden sollen. Dabei sollte immer bercksichtigt werden, wer und zu
welchem Zeitpunkt diese Daten lesen knnen soll.
Bei der Wahl von Datenformaten fr den Dateiaustausch sollte auch berck- Zusatzinformationen
verursachen Zusatz-
sichtigt werden, ob diese unerwnschte Zusatzinformationen enthalten knnen probleme
(siehe auch M 4.64 Verifizieren der zu bertragenden Daten vor Weitergabe /
Beseitigung von Restinformationen). Dateien, die in bestimmten
Datenformaten erstellt wurden, knnen auch andere sicherheitsrelevante
Probleme wie Makros und damit die Gefahr von Makro-Viren mit sich
bringen (siehe M 4.44 Prfung eingehender Dateien auf Makro-Viren).
Beispiel:
Bei der Textverarbeitung hat es sich als sinnvoll erwiesen, mit Microsoft
Winword erstellte Dateien im Rich Text Format (RTF) zu speichern. Dies
kann von einer greren Zahl von Textverarbeitungsprogrammen gelesen
werden und stellt darber hinaus sicher, dass die Datei keine Makro-Viren
enthlt.
- Gibt es Empfehlungen, welche Datenformate fr den Datenaustausch, die
Archivierung oder andere Anwendungsbereiche zu verwenden sind?
- Wird bei der Beschaffung neuer Programme hinterfragt, ob diese mit den
bisher untersttzten Datenformaten kompatibel sind?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................

Systemdateien
Systemdateien bzw. -verzeichnisse sind Dateien und Verzeichnisse, fr die der
Administrator zustndig ist. Diese sind entweder fr alle Benutzer von
Bedeutung oder sie dienen Administrationszwecken.
Auf Systemdateien sollten mglichst nur die Systemadministratoren Zugriff
haben. Der Kreis der zugriffsberechtigten Administratoren sollte mglichst
klein gehalten werden. Auch Verzeichnisse drfen nur die notwendigen Privi-
legien fr die Benutzer zur Verfgung stellen. Die Vergabe von Zugriffs-
rechten auf Systemdateien sollte grundstzlich restriktiv und nur in berein-
stimmung mit den hausinternen Sicherheitsrichtlinien erfolgen (siehe auch
M 2.220 Richtlinien fr die Zugriffs- bzw. Zugangskontrolle).
Systemdateien sollten getrennt von Applikationsdaten und Benutzerdateien Trennen von anderen
Dateien
gespeichert werden (siehe auch M 2.138 Strukturierte Datenhaltung). Dies
sorgt fr eine bessere bersicht und erleichtert auch die Durchfhrung von
Datensicherungen und die Sicherstellung des korrekten Zugriffsschutzes.
Der Zugriff auf Systemdateien sollte immer protokolliert werden. ber-
flssige, also nicht bentigte Systemdateien sollten vom System entfernt
werden, damit sie nicht fr Angriffe missbraucht werden knnen und auch
nicht stndig auf Integritt kontrolliert werden mssen.
Bei der restriktiven Vergabe von Zugriffsrechten reicht es nicht aus, nur die
Rechte eines Programms zu berprfen. Zustzlich muss auch die Rechte-
vergabe aller Programme berprft werden, die von diesem Programm aus
aufgerufen werden.
Die Integritt aller Systemdateien und -verzeichnisse sowie die Korrektheit regelmige Kontrolle
der Zugriffsrechte
der Zugriffsrechte sollte nach Mglichkeit regelmig verifiziert werden. Fr
viele Betriebssysteme gibt es dafr Tools, mit denen solche Prfungen schnell
und zuverlssig durchgefhrt werden knnen.
- Wird die Rechtevergabe auf Systemdateien regelmig berprft?
- Gibt es Tools oder Listen, anhand derer diese berprfungen durchgefhrt
werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.136 Sichere Installation von Windows 2000

Nach erfolgter Planung eines Windows 2000 Systems (siehe M 2.227 Planung
des Windows 2000 Einsatzes) muss das Windows 2000 Betriebssystem auf
den relevanten Rechnern installiert werden. Whrend der Installationsphase ist
ein Windows 2000 Rechner nicht vollstndig konfiguriert, so dass auch die
gewnschten Sicherheitseinstellungen noch nicht aktiviert sind. Es empfiehlt
sich daher, die initiale Konfiguration entweder in einer geschtzten Umge-
bung durchzufhren oder alternativ eine vorbereitete Standardkonfiguration
aufzuspielen.
Whrend der Installation erfolgt u. a. auch die Konfiguration der lokalen
Sicherheitseinstellungen. Die wichtigsten Grundeinstellungen beziehen sich
auf die
- Dateisystemsicherheit,
- Sicherheit der Registrierdatenbank (Registry),
- Sicherheit fr den Netzzugriff,
die whrend der Standardinstallation zunchst mit Standardwerten initialisiert Zugriffsrechte,
Basisdienste und
werden. Generell erfolgt die Installation eines Rechners in mehreren Schritten: Serverdienste
in einem ersten Schritt erfolgt nach dem Aufspielen der Systemdateien die konfigurieren
Konfiguration der Dateisystem- und Registrierdatenbanksicherheit durch das
Festlegen von Zugriffsrechten. Danach werden die Basisdienste eines Systems
konfiguriert, z. B. die Netzkonfiguration. In einem letzten Schritt erfolgt
insbesondere fr Server die Konfiguration von Serverdiensten. Fr Server, die
als Domnen-Controller betrieben werden sollen, erfolgt ein weiterer Schritt,
in dem die fr Domnen-Controller spezifischen Dienste (z. B. Active Direc-
tory, Kerberos) installiert und konfiguriert werden.
Das Hinzufgen eines Rechners zu einer Domne ist ein weiterer wichtiger Mitgliedschaft in einer
Domne
Konfigurationsschritt fr Clients und Server. Als Spezialfall ist hier die
Konfiguration des ersten Domnen-Controllers einer neuen Domne zu sehen.
Dabei sind besondere Sorgfalt und besondere Rechte notwendig, da nur ein
Mitglied der Gruppe Domnen-Admins eine neue Domne in einen existieren-
den Domnenverbund aufnehmen kann.
Generell ist bei der Installation aus Sicherheitssicht Folgendes zu beachten: Neuinstallation oder
Upgrade?
- Die geltenden Zugriffseinstellungen fr das Dateisystem und die
Registrierdatenbank eines Rechner nach einer Windows 2000 Installation
hngen davon ab, ob der Rechner neu installiert wurde oder ob ein
Upgrade (z. B. von Windows NT) auf Windows 2000 erfolgt ist. Bei einem
Upgrade kommen die Windows 2000 Standardeinstellungen nicht zum
tragen. Vielmehr werden die vorgefundenen Einstellungen bernommen.
Es ist dabei zu beachten, dass mit Windows 2000 die Trennung zwischen
Benutzer (User) und Hauptbenutzer (Poweruser) wesentlich strenger
erfolgt, so dass ein System nach einem Upgrade in der Regel mit weniger
strengen Sicherheitseinstellungen konfiguriert ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Nach Aufspielen der reinen Betriebssystemsoftware mssen auf Servern Dienste konfigurieren
weitere Dienste konfiguriert werden. Dabei ist zu beachten, dass auf Server
in der Regel sofort nach Einstellen der Netzparameter vom Netz aus zuge-
griffen werden kann. Daher muss der Netzzugriff entsprechend einge-
schrnkt werden.
- Soll ein neuer Rechner in eine existierende Windows 2000 Domne aufge- Konfiguration durch
Gruppenrichtlinien
nommen werden, so erlaubt es der Mechanismus der Gruppenrichtlinien,
die initiale Konfiguration deutlich abzukrzen. Beim Beitritt zu einer
Domne werden die fr den Rechner relevanten Gruppenrichtlinienobjekte
ausgewertet und der Rechner wird entsprechend konfiguriert. Dazu muss
entweder ein entsprechendes Computerkonto in der Domne vorbereitet
werden, oder das Computerkonto wird beim Beitritt erzeugt. Dazu sind
dann entsprechende administrative Berechtigungen notwendig. Wird das
Computerkonto erst beim Beitritt erzeugt, so muss das Computerkonto
anschlieend in die gewnschte Organisationseinheit (OU) im Active
Directory verschoben werden, da solche Computerkonten standardmig
im AD-Container Computer erzeugt werden. Damit solche Computer eine
Standardsicherheitseinstellung erhalten, bis sie in die gewnschte OU
verschoben sind, sollten diese Einstellungen ber die Gruppenrichtlinien-
einstellungen der Domne erfolgen, da an AD-Container keine Gruppen-
richtlinienobjekte angehngt werden knnen.
- Wird ein Rechner als Stand-alone Rechner betrieben, ist also dieser in Stand-alone-Rechner
keine Domne aufgenommen worden, muss die Konfiguration der
Gruppenrichtlinien, die auch die Sicherheitseinstellungen enthalten, lokal
erfolgen.
Fr die Installation von Domnen-Controllern gilt auerdem:
- Bei der Installation von Domnen-Controllern ist besondere Sorgfalt gefor-
dert, da diese im spteren Betrieb sensitive Daten speichern, beispielsweise
Passwrter oder Kerberos-Schlssel in nicht gehashter Form.
- Domnen-Controller drfen nur auf Rechnern installiert werden, die sich in
einer physikalisch sicheren Umgebung befinden (siehe auch M 1.29
Geeignete Aufstellung eines IT-Systems).
- Wird ein Windows 2000 Server zu einem Domnen-Controller herauf- starkes Passwort fr
Recovery Modus
gestuft, so muss ein Passwort angegeben werden, welches im so genannten
Active Directory Recovery Modus abgefragt wird. In diesem Modus, der
fr Notfallreparaturen am Active Directory gedacht ist, knnen u. a.
aktuelle Active Directory Daten mit Backup-Daten berschrieben werden.
Da dies eine sehr sicherheitskritische Operation darstellt, darf dieser
Zugang nicht ungeschtzt sein. Im Rahmen der Heraufstufung wird ein
Domnen-Administratorkonto erzeugt und das rechnerlokale Administra-
torkonto als Anmeldekonto fr den Active Directory Recovery Modus
genutzt. Dieses muss mit einem starken Passwort gesichert sein.
- Die Installationsreihenfolge der jeweils ersten Domnen-Controller einer Installationsreihenfolge
einhalten
Domne muss eingehalten werden. Die erste in einem Netz durch die
Installation eines zugehrigen Windows 2000 Domnen-Controllers
erzeugte Domne bernimmt die Rolle der Forest-Root-Domne (FRD),
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
die wichtige Verwaltungsaufgaben im zuknftigen Domnenverbund ber-

nimmt. Die Rolle der FRD kann nachtrglich nicht anderen Domnen
zugewiesen werden.
Hinweise zu Einstellungen der Gruppenrichtlinienparameter finden sich in
Manahme M 2.231 Planung der Gruppenrichtlinien unter Windows 2000.
- Wurden die installierten Zugriffsrechte fr Dateien und die Registrier-
datenbank bedarfsgerecht geplant?
- Wurden die Zugriffsrechte fr Dateien und die Registrierdatenbank bei
Systemen, die von Windows NT auf Windows 2000 aktualisiert wurden,
ebenfalls aktualisiert?
- Sind alle Gruppenrichtlinienobjekte installiert, damit neue Rechner mit den
neuen Sicherheitseinstellungen versorgt werden?
- Wurde die FRD als erste Domne installiert?
- Ist der AD Recovery Modus fr jeden Domnen-Controller mit einem
starken Passwort gesichert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.137 Sichere Konfiguration von Windows 2000

Nach der Installation von Windows 2000 Rechnern erfolgt deren Konfigu-
ration. Die jeweils vorzunehmenden Einstellungen hngen dabei wesentlich
vom Verwendungszweck ab. Grob kann bei Windows 2000 unterschieden
werden zwischen der Verwendung als
- Workstation oder Arbeitsplatzrechner,
- Server (Dateiserver, Applikationsserver, Dienstserver) oder
- Domnen-Controller.
Dabei kommen jeweils die entsprechenden Windows 2000 Versionen (Profes-
sional, Server, Advanced Server, Datacenter Server) zum Einsatz.
Fr die sichere Konfiguration ist jeweils zu beachten, dass neben der reinen System und Dienste
sicher konfigurieren
Betriebssystemkonfiguration, die im Wesentlichen ber Gruppenrichtlinien
erfolgen kann, auch die sichere Konfiguration einzelner Dienste notwendig ist.
Dies trifft insbesondere auf die Server-Versionen von Windows 2000 zu.
Folgende Punkte sind fr die sichere Grundkonfiguration eines Windows 2000
Systems zu beachten:
- Die Sicherheitseinstellungen sind gem der festgelegten Windows 2000
Sicherheitsrichtlinie und der Planung der Windows 2000 Gruppenricht-
linien umzusetzen (siehe M 2.231 Planung der Gruppenrichtlinien unter
Windows 2000).
- Die Anmeldeprotokollierung sollte aktiviert sein (siehe auch
M 4.148 berwachung eines Windows 2000 Systems).
- Fr Windows 2000 Professional (Arbeitsplatzrechner) darf der Autologon-
Mechanismus nicht genutzt werden.
- Eine ausreichende Passwortqualitt muss sichergestellt sein. Dies gilt
insbesondere dann, wenn die Dateiverschlsselung mit EFS (siehe
M 4.147 Sichere Nutzung von EFS unter Windows 2000) genutzt wird. Die
Benutzer sollten dementsprechend geschult werden.
- Fr jeden Benutzer muss ein eigenes Benutzerkonto eingerichtet werden.
Gemeinsam genutzte Konten sind abzulehnen, da in diesem Fall die
Verantwortlichkeit nicht eindeutig zuweisbar ist.
- Das Verwaltungskonzept (siehe auch M 2.227 Planung des Windows 2000 Benutzer- und
Administratorkonten
Einsatzes) sollte eine strikte Trennung von Benutzer- und Administrator- trennen
konten vorsehen. Administrative Ttigkeiten sollten nur unter Administra-
torkonten ausgefhrt werden. Umgekehrt sollten unter Administrator-
konten keine normalen Benutzerttigkeiten durchgefhrt werden. Windows
2000 bietet hier zur Untersttzung den run-as-Mechanismus an. Damit
knnen Personen mit administrativen Befugnissen unter normalen
Benutzerkonten angemeldet sein und fr administrative Ttigkeiten
Prozesse unter einem Administratorkonto starten, ohne sich vom System
abmelden zu mssen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Das Gast-Konto sollte nicht genutzt und daher mglichst auch nicht akti-
viert werden. Das Umbenennen des Gast-Kontos ist mglich, bietet jedoch
keinen wirklichen Schutz, da das Gast-Konto beispielsweise ber die
Security-ID (SID) des Kontos identifiziert werden kann.
- Konten sollten nach einer vorgegebenen Anzahl von Passwortfehleingaben
automatisch gesperrt werden. Die dann notwendige Freischaltung sollte nur
durch einen befugten Administrator erfolgen (siehe auch M 2.231 Planung
der Gruppenrichtlinien unter Windows 2000).
- Smtliche Verwaltungsaktivitten an Benutzerkonten sollten protokolliert
werden (siehe auch M 4.148 berwachung eines Windows 2000 Systems).
- Die im Rahmen der Windows 2000 Planung festgelegten Gruppen, die sich
an einem Rechner lokal oder ber das Netz anmelden drfen, mssen
- Fr alle Rechner muss ein passwortgeschtzter Bildschirmschoner aktiviert
sein, der nach einem vorgegebenen Zeitintervall automatisch startet.
- Ist die abgesicherte Kommunikation zwischen Windows 2000 Rechnern
gewnscht oder notwendig, so kann die Verschlsselung mittels IPSec
erfolgen (siehe M 5.90 Einsatz von IPSec unter Windows 2000).
In Abhngigkeit vom Verwendungszweck sind auerdem folgende Aspekte
jeweils zu bercksichtigen:
- Arbeitsplatzrechner: Die Sicherheit eines Arbeitsplatzrechners hngt im
Wesentlichen davon ab, ob ein Benutzer administrativ auf den Rechner
einwirken kann, welche Funktionen dem Benutzer verfgbar gemacht
werden und ob der Benutzer die ihm zur Verfgung gestellten Sicherheits-
mechanismen korrekt nutzt. Detaillierte Manahmen sind im Baustein 5.7
Windows 2000 Client, sowie in M 4.150 Konfiguration von Windows 2000
als Workstation und M 3.28 Schulung zu Windows 2000 Sicherheits-
mechanismen fr Benutzer beschrieben. Fr die Verwendung als Laptop ist
auerdem die Manahme M 4.147 Sichere Nutzung von EFS unter
Windows 2000 relevant.
- Server: Die Sicherheit eines Servers hngt im Wesentlichen davon ab, ob
die von ihm angebotenen Dienste sicher konfiguriert wurden. Dies muss
durch eine sichere Grundkonfiguration des Betriebssystems untersttzt
werden. Detaillierte Empfehlungen dazu finden sich in
M 4.139 Konfiguration von Windows 2000 als Server, sowie in der
Manahme M 4.140 Sichere Konfiguration wichtiger Windows 2000
Dienste und den dort referenzierten Manahmen.
- Domnen-Controller: Auf Domnen-Controllern werden im Active
Directory wichtige Systemdaten gehalten. Diese mssen besonders
geschtzt werden. Die fr Domnen-Controller spezifischen Manahmen
sind in M 4.138 Konfiguration von Windows 2000 als Domnen-Controller
zusammengefasst. Da einige wichtige Windows Dienste auch auf
Domnen-Controllern ablaufen knnen oder mssen, findet auch die
Dienste Anwendung.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Windows 2000 erlaubt es, Netzfreigaben fr jeden Rechner, d. h. fr Arbeits- Freigaben auf
platzrechner, Server oder Domnen Controller, zu konfigurieren. Netzfrei- Arbeitsplatzrechnern
gaben knnen unter Sicherheitsgesichtspunkten problematisch sein. Freigaben und Domnencontrollern
vermeiden
auf Arbeitsplatzrechnern sollten mglichst vermieden werden, da ein Netz-
zugriff auf diese in der Regel nicht sinnvoll ist (siehe auch
M 5.37 Einschrnken der Peer-to-Peer-Funktionalitten in einem server-
gesttzten Netz). Ausnahmen sollten daher begrndet und dokumentiert
werden. Fr Netzfreigaben auf Servern (z. B. Dateiserver, Druckserver) gilt,
dass die Freigaben durch Zugriffsrechte zu schtzen sind, so dass diese nur
den autorisierten Benutzergruppen zur Verfgung stehen. Die Zugriffsrechte
auf die durch die Freigaben zur Verfgung gestellten Ressourcen (z. B.
Dateien und Verzeichnisse) sind durch restriktive Zugriffsrechte zu schtzen.
Netzfreigaben auf Domnen-Controller stellen u. U. eine besondere Gefahr
dar, da die Daten auf Domnen-Controllern besonders geschtzt werden
mssen. Auch hier sind Freigaben zu begrnden und zu dokumentieren.
Generell sollte fr jede Freigabe eine Risikoabschtzung erfolgen. Die Sicher- restriktive Zugriffsrechte
vergeben
heit der durch eine Netzfreigabe angebotenen Ressourcen hngt vor allem von
den eingestellten Zugriffsrechten ab. Diese knnen unter Windows 2000
feingranular vergeben werden. Welche Zugriffsrechte zu verwenden sind,
kann nur im Einzelfall bestimmt werden. Generell gilt jedoch, dass die
Zugriffsrechte so restriktiv wie mglich vergeben werden sollten. Spezielle
Hinweise zum Umgang mit Dateizugriffsrechten finden sich auch in
M 4.149 Datei- und Freigabeberechtigungen unter Windows 2000.
Unter Windows 2000 wird standardmig Kerberos als Authentisierungs-
mechanismus eingesetzt. Da die Systemsicherheit auch von der korrekten und
zuverlssigen Authentisierung abhngt, kommt den Komponenten von
Kerberos eine wichtige Rolle zu. Die Windows 2000 Komponenten von
Kerberos bentigen keine umfangreiche Konfiguration und stellen nur wenige
Konfigurationsparameter bereit. Diese knnen ber Gruppenrichtlinien ange-
passt werden. Es existieren folgende Konfigurationsmglichkeiten:
Computer Richtlinien / Kontorichtlinien / Kerberos Richtlinien

Zugriffsbeschrnkungen Ist diese Einstellung aktiviert, berprft der Kerberos
durchsetzen KDC-Server (Key Distribution Center), ob der
Benutzer die notwendigen Benutzerrechte (z. B. Recht
zum Anmelden ber das Netz) zum Zugriff auf den
angeforderten Dienst besitzt, bevor das Ticket ausge-
stellt wird.
Max. Gltigkeitsdauer des Diese Einstellung bestimmt die maximale Gltigkeit
Benutzertickets eines Benutzertickets. Ist ein Ticket abgelaufen, so
muss es erneuert werden (s. u.).
Max. Gltigkeitsdauer des Nach Ablauf dieser Zeitspanne kann das Ticket nicht
Diensttickets mehr zur Authentisierung beim Dienst genutzt werden.
Einmal aufgebaute Dienstverbindungen werden jedoch
nicht abgebrochen, da die Authentisierung innerhalb
der Gltigkeitsdauer erfolgte.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Max. Toleranz fr die Kerberos Tickets enthalten Zeitstempel (Ausstellungs-

Synchronisation des zeit, Gltigkeitsdauer). Damit die Authentisierung
Computertakts mittels "alter" Tickets ausgeschlossen ist, mssen alle
Rechneruhren mglichst synchron laufen, was in einem
Windows 2000 Netz automatisch durch den integrierten
Zeitdienst gewhrleistet wird. Die hier angegebene
Zeitspanne gibt an, innerhalb welcher Toleranz Zeiten
auf verschiedenen Rechnern als "gleich" angesehen
werden.
Max. Zeitraum, in dem ein Gibt den Zeitraum an, nach der die Verlngerung eines
Benutzerticket erneuert Benutzertickets nicht mehr mglich ist. Ist diese Zeit-
werden kann spanne fr ein Benutzerticket abgelaufen, so muss sich
der Benutzer erneut gegenber dem Kerberos-Server
authentisieren, damit ein neues Benutzerticket ausge-
stellt werden kann. Die Komponenten von Windows
fhren diesen Vorgang transparent fr den Benutzer
durch, so dass keine neue Passworteingabe notwendig
ist.
Bei der Konfiguration der Parameter ber eine Gruppenrichtlinie (GPO) ist
Folgendes zustzlich zu beachten:
- Die Parameter sollten im Probebetrieb an die lokalen Gegebenheiten ange-
passt werden.
- Die GPO-Einstellungen werden nur wirksam, wenn sie zu einem GPO-
Objekt gehren, das mit einem Domnen-Objekt verbunden ist.
- Fr Stand-alone-Rechner wird Kerberos als Authentisierungsverfahren zur
Anmeldung an lokale Benutzerkonten nicht genutzt.
Neben den hier angesprochenen Windows 2000 spezifischen Manahmen
muss generell fr jeden Rechner bzw. fr jede Gruppe von Rechnern eine
Schutzbedarfsfeststellung erfolgen (siehe Kapitel 2.2), die die speziellen
Risiken, z. B. durch installierte Software oder Einsatzszenarien, bercksich-
tigt. Zustzlich sollten auch die generellen Manahmen Anwendung finden,
wie sie in den brigen relevanten Bausteinen des IT-Grundschutzhandbuchs
beschrieben sind.
- Sind alle Rechner gem der ihnen zugedachten Rolle konfiguriert?
- Werden die geplanten Protokolleinstellungen umgesetzt?
- Sind eventuell notwendige nderungen in den Kerberos-Parametern umge-
setzt und getestet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.138 Konfiguration von Windows 2000 als Domnen-

Controller
Domnen-Controller (DC) stellen in einem Windows 2000 Netz die zur
Verwaltung einer Windows 2000 Domne ntigen Dienste zur Verfgung,
unter denen der Active Directory Dienst (Active Directory Service, ADS) die
wichtigste Rolle einnimmt. In der Regel wird von einem DC auch der
Namensdienst DNS (Domain Name Service) angeboten, ohne den das Active
Directory nicht betrieben werden kann. Im DNS werden von Windows Refe-
renzen auf wichtige Windows 2000 Ressourcen gehalten, deren Integritt fr
das korrekte Funktionieren einer Windows 2000 Domne essentiell sind. Da
ein DC als Anmeldeserver fungiert, fhrt er den dazu notwendigen Kerberos-
Dienst aus. Die Kerberos-Komponenten auf dem DC bewahren zudem die im
Rahmen des Authentisierungs-Protokolls genutzten geheimen Schlssel auf.
Da jedem DC daher eine wichtige Rolle zukommt und durch ihn schtzens-
werte Daten gespeichert werden, sind fr die Konfiguration folgende Punkte
zu beachten. Daneben gelten auch fr einen Domnen-Controller die in der
Manahme M 4.137 Sichere Konfiguration von Windows 2000 und
M 4.139 Konfiguration von Windows 2000 als Server beschriebenen Aspekte
entsprechend.
- Die Sicherheit eines Domnen-Controllers leitet sich hauptschlich aus Sicherheit des
Betriebssystems und
zwei wesentlichen Bereichen ab: der Sicherheit der Betriebssystem- des ADS
konfiguration und der Sicherheit des Active Directories, welches auf
eigene Sicherheitsmechanismen zurckgreift (siehe auch M 3.27 Schulung
zur Active Directory-Verwaltung). Die Sicherheitseinstellungen des
Betriebssystems erfolgen im Wesentlichen durch Gruppenrichtlinien, die
Sicherheitseinstellungen des Active Directories erfordern entsprechende
Planung und Umsetzung (siehe M 2.229 Planung des Active Directory,
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000).
- An einem Domnen-Controller drfen sich nur berechtigte Administra-
toren lokal anmelden. Ein Benutzerbetrieb auf einem Domnen-Controller
darf nicht erlaubt werden. Nach einer Standardinstallation ist es normalen
Benutzern daher nicht gestattet, sich lokal an einem DC anzumelden.
- Ein Domnen-Controller sollte neben den zwingend notwendigen Standard keine zustzlichen
Dienste aktivieren
DC Diensten, wie z. B. ADS, Kerberos und DNS, keine weiteren Infra-
strukturdienste (z. B. DFS, DHCP) anbieten. Insbesondere vom Betrieb
eines DHCP-Servers auf einem DC muss aus Sicherheitsgrnden abgeraten
werden (siehe auch Microsoft Dokumentation zu DNS und DHCP). Beide
Dienste laufen unter den gleichen Berechtigungen ab. Dadurch knnen -
stark vereinfacht dargestellt - die Zugriffsrechte auf DNS-Daten nicht mehr
durchgesetzt werden, wenn der DHCP-Dienst Vernderungen an DNS-
Daten durchfhrt.
- Ein Domnen-Controller sollte keine (Applikations-) Serverdienste anbie-
ten, da bei Fehlern in den Serverprogrammen eine Kompromittierung des
DC und damit der gesamten Windows 2000 Domne mglich ist.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Domnen-Controller sollten so sicher wie mglich konfiguriert werden. Nach

der Standardinstallation sollte die Vorlagendatei secdc.inf oder hisecdc.inf
angewandt werden. Die Vorlagendateien finden sich im Windows 2000
Systemverzeichnis unter C:\WINNT\security\templates und knnen entweder
von der Kommandozeile mittels des Kommandos secedit konfiguriert werden,
oder ber die MMC-Plug-ins Sicherheitsvorlagen und Sicherheitskonfigu-
ration und -analyse angesehen oder angewandt werden. Wurde der Rechner
von NT nach Windows 2000 migriert und nicht neu installiert, so ist zunchst
das Template basicdc.inf anzuwenden, um eine Standard Windows 2000
Konfiguration zu erreichen. Je nach Umfeld mssen die durch die Vorlagen
secdc.inf bzw. hisecdc.inf vorgenommen Einstellungen angepasst werden.
Dies kann beispielsweise erforderlich sein, wenn im Netz noch Altsysteme,
z. B. OS/2, vorhanden sind, die weniger sichere Einstellungen bieten. Weitere
Hinweise zur Planung der Sicherheitseinstellungen finden sich in
M 2.231 Planung der Gruppenrichtlinien unter Windows 2000.
- Die Konfiguration des Kanals, der zur Kommunikation von Verwaltungs-
daten zwischen Rechnern einer Windows 2000 Domne genutzt wird,
sollte so sicher wie mglich sein (siehe dazu M 5.89 Konfiguration des
sicheren Kanals unter Windows 2000).
- Wenn mglich, sollte ein Domnen-Controller im native mode betrieben DC im native mode
betreiben
werden, damit alle Windows 2000 Mechanismen voll ausgenutzt werden
knnen. Dies sind beispielsweise universelle Gruppen, Gruppenschach-
telung und die Vergabe der RAS-Zugangsberechtigung ber eine Gruppen-
zugehrigkeit. Ein Umschalten in den native mode ist dann mglich, wenn
in der Domne kein Windows NT BDC (Backup-Domnen-Controller)
betrieben wird. Der Betrieb von Windows NT Servern und Workstations
ist auch im native mode mglich. Zu beachten ist, dass eine Rckkehr in
den mixed mode und damit zu einer NT-Domne danach nicht mehr
mglich ist.
- Kann ein Domnen-Controller in den so genannten AD-Restore-Modus Restore Modus durch
Passwort schtzen
gebootet werden, so ist es mglich, Vernderungen am AD durchzufhren,
indem z. B. alte Zustnde (teilweise oder vollstndig) von Backup-Medien
geladen werden. Diese Vernderungen lassen sich so einspielen, dass sie
nach dem regulren Booten durch die AD-Replikation an alle anderen DCs
einer Domne propagiert werden. Es ist daher sicherzustellen, dass der
AD-Restore-Modus durch ein geeignetes Passwort geschtzt ist und
Arbeiten in diesem Modus nur unter Einhaltung des Vier-Augen-Prinzips
erfolgen. Der AD-Restore-Modus ist kommandozeilenbasiert und Tipp-
fehler knnen gravierende Folgen haben, z. B. Lschen oder berschreiben
des falschen AD-Zweiges. Daher bietet das Vier-Augen-Prinzip hier neben
der Ttigkeitskontrolle auch eine Sicherheit durch die Kontrolle aller
Eingaben durch zwei Personen.
- Die Domnen-Controller der Forest-Root-Domne (FRD) sind aufgrund
der Sonderstellung der FRD besonders schutzbedrftig.
Generell ist fr jeden Domnen-Controller immer die physikalische Sicherheit
zu gewhrleisten, z. B durch Aufstellung in einem Serverraum.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Sind fr alle Domnen-Controller restriktive Zugriffsrechte auf Betriebs-
systemebene vergeben?
- Wurden die AD-Berechtigungen restriktiv vergeben?
- Ist die physikalische Sicherheit aller Domnen-Controller gewhrleistet?
- Sind nur die gem Planung bentigten Dienste fr jeden Domnen-
Controller installiert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.139 Konfiguration von Windows 2000 als Server

Die Nutzung von Windows 2000 als Serverbetriebssystem stellt eine der drei
Hauptnutzungsvarianten dar. Generell knnen Server als Rechner angesehen
werden, die Dienste zur Nutzung durch Clients, d. h. durch Arbeitsplatz-
rechner, aber auch durch andere Server, anbieten. Die angebotenen Dienste
knnen sehr vielfltig sein, wenn zustzliche Produkte von Drittherstellern
zum Einsatz kommen.
Schon in einer Standarddistribution von Windows 2000 Server sind verschie-
dene Dienste enthalten, die meist Systemdienst-Charakter besitzen und damit
als Infrastrukturdienste angesehen werden knnen (siehe auch
M 4.140 Sichere Konfiguration wichtiger Windows 2000 Dienste).
Aus Sicherheitssicht ist fr einen Server Folgendes zu beachten:
- Die Sicherheit eines Servers hngt wesentlich von den eingesetzten Dienste sicher
konfigurieren
Diensten ab. Ist ein Dienst fehlerhaft konfiguriert oder programmiert, so
knnen diese Fehler u. U. dazu genutzt werden, auf den Server in unbe-
rechtigter Weise zuzugreifen. Aus diesem Grund kommt der sicheren
Konfiguration aller von einem Server angebotenen Dienste eine besondere
Bedeutung zu. Hinweise zur sicheren Konfiguration von wichtigen
Windows 2000 Diensten finden sich in M 4.140 Sichere Konfiguration
wichtiger Windows 2000 Dienste. Fr die Konfiguration von Diensten von
Drittherstellern knnen an dieser Stelle keine allgemeinen Empfehlungen
geben werden.
- Auf einem Server sollten alle nicht bentigten Systemdienste abgeschaltet nicht bentigte Dienste
abschalten
werden. Dies verhindert, dass diese Dienste durch Dritte unberechtigt oder
fr Angriffe genutzt werden knnen.
- Die auf einem Server eingesetzten Dienste sollten auf ihre wechselseitige Vertrglichkeit der
Dienste prfen
Vertrglichkeit geprft werden. Oft entstehen Sicherheitslcken erst durch
die Kombination von Diensten. Die Vertrglichkeitsprfung ist jedoch
schwierig und erfordert in der Regel eine genaue Analyse. Allgemeine
Hinweise dazu lassen sich leider nicht geben. Es empfiehlt sich jedoch
auch aus Grnden der Fehlertoleranz, Dienste nicht auf einem Server zu
kumulieren, sondern auf verschiedene, u. U. dedizierte Server zu verteilen.
- Auf einem Server sollte kein Benutzerbetrieb stattfinden. Ausnahmen sind
naturgem Terminalserver. Die Konfiguration der zulssigen Benutzer
kann unter Windows 2000 ber Gruppenrichtlinien gesteuert werden. Die
dazu wichtigen Einstellungen sind die Benutzerrechte Logon Locally und
Access this computer from the network.
- Dienste knnen unter den Berechtigungen eines bestimmten Benutzer-
kontos ablaufen. Nach der Standardinstallation eines Dienstes wird jedoch
meist das Konto des lokalen Rechners (Local System) benutzt, welches
dem Dienst Betriebssystemprivilegien gibt. Fr Dienste, die diese privile-
gierten Berechtigungen nicht zwingend zum Ablauf bentigen, empfiehlt
sich daher die Nutzung eines eigenen, dedizierten Dienstkontos. Das ge-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
wnschte Konto ist nach dem Anlegen unter dem Punkt Dieses Konto auf
der Registerkarte Anmelden im Eigenschaftsdialog des Dienstes in der
Diensteverwaltung (Systemsteuerung/Computerverwaltung/Dienste) einzu-
tragen. Hier muss auch das Passwort des jeweiligen Kontos angegeben
werden. Auf diese Weise lsst sich auch die Zugriffskontrolle auf lokale
oder entfernte Ressourcen implementieren, so dass einem Dienst nur die
Zugriffsberechtigungen erteilt werden, die fr den geregelten Ablauf ntig
sind. Insbesondere verhindert dies, dass bei einer Kompromittierung des
Dienstes der Angreifer Betriebssystemberechtigungen erhlt.
Problematisch ist dabei jedoch, dass neue Dienste meistens standardmig
unter den Berechtigungen Local System ablaufen. Dies gilt auch fr die
Windows Standarddienste. Auerdem ist es oft unklar, ob diese Dienste
auch unter einem dedizierten Dienstkonto ablauffhig sind und welche
Berechtigungen diesem Konto eingerumt werden mssen. Dies kann im
Regelfall nur durch Tests herausgefunden werden.
- Werden fr Dienste dedizierte Dienstkonten genutzt, so sollten diese
Konten fr den interaktiven Zugang zum System gesperrt werden. Das
Anmelden als Dienst muss hingegen erlaubt werden. Auerdem ist ein
sicheres Passwort fr das Dienstkonto zu vergeben. Zur Verwaltung von
Dienstkonten existieren Produkte von Drittherstellern, die auch ein Pass-
wortmanagement erlauben.
- Fr komplexe Dienste, die meist ber eine lokale Datenhaltung verfgen, komplexe Dienste auf
dedizierten Rechnern
empfiehlt sich die Nutzung dedizierter Rechner. Beispiele hierfr sind u. a. betreiben
der RAS-Dienst und die Internet Information Services (IIS). Je nach Funk-
tion empfiehlt es sich auch, eine eigene Windows Domne fr gleichartige
Dienstrechner, wie z. B. fr Internetserver zu erzeugen, so dass auch auf
Domnenebene eine Trennung erfolgen kann. Je nach Einsatzszenario
knnen dann Zugriffsbeschrnkungen fr diese Domnenmitglieder einge-
richtet werden, wie beispielsweise der Entzug der Vertrauensstellung.
- Werden durch einen Server Netzfreigaben angeboten, wie beispielsweise Zugriffsrechte auf
Netzfreigaben
durch einen Dateiserver, so ist auf die Vergabe geeigneter Zugriffsrechte
zu achten. Dies betrifft sowohl die Netzfreigabe, als auch die durch die
Freigabe angebotenen Verzeichnisse und Dateien (siehe dazu auch
M 4.149 Datei- und Freigabeberechtigungen unter Windows 2000).
- Generell empfiehlt es sich, die Zugriffe auf die Ressourcen eines Servers Angriffe protokollieren
zu protokollieren. Daher sollten fr Server Protokolleinstellungen entwor-
fen und umgesetzt werden, die fr die berwachung im Rahmen der
jeweiligen Nutzungsszenarien geeignet sind. Diese mssen in das ber-
wachungskonzept (siehe M 4.148 berwachung eines Windows 2000
Systems) integriert sein. Da hier meist auch benutzerbezogene Daten erfasst
werden, sollte sowohl der Datenschutzbeauftragte als auch der Personal-
bzw. Betriebsrat rechtzeitig in die Planung einbezogen werden.
Die aufgezeigten Empfehlungen sind als Anregung fr weitere Manahmen zu
verstehen, die in Abhngigkeit spezieller Dienste und deren Funktion durch-
gefhrt werden mssen. Vor Einfhrung eines neuen Dienstes sollte daher
eine geeignete Analyse der Auswirkungen auf die Systemsicherheit sowie eine
Schutzbedarfsfeststellung erfolgen (siehe dazu auch Kapitel 2.2).
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Werden nur die bentigten Dienste auf einem Server ausgefhrt?
- Sind bei Nutzung mehrerer Dienste auf einem Server Abhngigkeiten und
Seiteneffekte bercksichtigt worden?
- Ist der lokale Benutzerbetrieb fr Server unterbunden worden?
- Werden Dienste - wenn mglich - unter eigenen Konten ausgefhrt?
- Werden Zugriffe auf die Server-Ressourcen gem des berwachungs-
konzeptes protokolliert?
- Sind fr Dateiserver bedarfsgerechte und minimale Zugriffsrechte auf die
Netzfreigaben und die freigegebenen Ressourcen vergeben?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.140 Sichere Konfiguration wichtiger Windows 2000

Dienste
Zum geregelten Betrieb eines Windows 2000 Netzes werden neben der reinen
Betriebssystemsoftware zustzliche Dienste bentigt. Als wichtigster Dienst
zum Betrieb einer Windows 2000 Domnenstruktur steht der Active Directory
Service (ADS) zur Verfgung, der damit eine zentrale Stellung einnimmt. Die
Sicherheit eines Windows 2000 Netzes hngt wesentlich von der Konfi-
guration des Active Directories ab, die daher der sorgfltigen Planung und
Umsetzung bedarf (siehe dazu M 2.229 Planung des Active Directory,
M 2.230 Planung der Active Directory-Administration, M 2.231 Planung der
Gruppenrichtlinien unter Windows 2000, M 3.27 Schulung zur Active
Directory-Verwaltung). Daneben existieren weitere Windows 2000 Dienste,
die je nach Bedarf (siehe M 2.227 Planung des Windows 2000 Einsatzes)
weitere Funktionen bernehmen knnen. Beispiele fr wichtige Dienste sind:
- DDNS-Dienst und WINS-Dienst zur Namensauflsung,
- DHCP-Dienst zur dynamischen Verwaltung von IP-Adressen,
- DFS-Dienst zum Aufbau virtueller, unternehmensweiter Dateibume,
- Windows PKI-Dienste zur Verwaltung von Zertifikaten,
- Windows RRAS-Dienst fr den Remote-Zugang.
Als Voraussetzung fr die Sicherheit eines Windows 2000 Netzes muss die
sichere Konfiguration jedes einzelnen eingesetzten Dienstes erfolgen. Dies gilt
auch fr die sichere Konfiguration der Zusammenarbeit einzelner Dienste
(z. B. DDNS und DHCP).
Folgendes ist fr die betrachteten Dienste zu bercksichtigen:
- Der DDNS (Dynamic Domain Name Service) ist zwingend einzusetzen, DDNS ist fr das AD
erforderlich
wenn eine Windows 2000 Domne aufgebaut werden soll, da das AD auf
DNS als Namensdienst angewiesen ist. Daher kommt der Integritt und
Konsistenz der Daten des DNS eine besondere Bedeutung unter Windows
2000 zu. Fehler in den DNS-Daten oder ein Ausfall des DNS-Servers
haben zur Folge, dass z. B. smtliche Anmeldeversuche fehlschlagen,
wenn keine Ausweichserver zur Verfgung stehen. Betroffen sind hiervon
auch die Anmeldeversuche eines Administrators direkt am DC. Hinweise
zur sicheren Konfiguration finden sich in M 4.141 Sichere Konfiguration
des DDNS unter Windows 2000.
- Der WINS (Windows Internet Name Service) Dienst ist zum Betrieb einer
reinen Windows 2000 Domne nicht notwendig und muss daher nicht
betrieben werden. Da ein Windows 2000 Netz jedoch meistens durch die
Migration eines bestehenden Netzes aufgebaut wird und dadurch zumin-
dest bergangsweise meist auch Altsysteme vorhanden sind, muss WINS
in der Regel weiter eingesetzt werden. Dies ist insbesondere dann notwen-
dig, wenn WINS-basierte Applikationen existieren, die nicht migriert
werden knnen. Durch den Parallelbetrieb von DDNS und WINS ergibt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
sich zustzlich das Problem der Konsistenz der jeweils gehaltenen Daten.
Hinweise zur sicheren Konfiguration von WINS finden sich in
M 4.142 Sichere Konfiguration des WINS unter Windows 2000.
- DHCP (Dynamic Host Configuration Protocol) bietet die Mglichkeit, Konsistenz von DHCP
und DDNS
Rechner dynamisch mit IP-Adressen zu versehen. Einem so genannten
DHCP-Server wird eine Menge von IP-Adressen bergeben, die er auf
Anfrage von DHCP-Clients dem anfragenden Rechner zuteilen kann. Die
IP-Adressen werden dabei nur fr eine bestimmte Zeit, die so genannte
Lease-Zeit, zugeteilt. Ist diese abgelaufen, muss eine erneute Anfrage an
den DHCP-Server gestellt werden. Hierbei kann eine neue IP-Adresse
angefragt oder die Lease-Zeit der alten Adresse verlngert werden. Ein
Rechner kann die IP-Adresse auch vor Ablauf der Lease-Zeit wieder frei-
geben. Aufgrund der dynamischen Zuordnung von IP-Adresse zu Rechner
und demzufolge auch zum Rechnernamen, muss bei nderungen der
Zuordnung auch eine nderung im Namensdienst (DDNS) erfolgen. Aus
Sicherheitssicht ergibt sich dabei das Problem, die Konsistenz der Namen
zur IP-Adressen-Zuordnung innerhalb des DDNS angesichts stndig
wechselnder Zuordnungen zu gewhrleisten. Hinweise zur sicheren Konfi-
guration und Nutzung von DHCP finden sich in M 4.143 Sichere Konfi-
guration des DHCP unter Windows 2000. Wenn es organisatorisch
mglich ist, sollte eine feste Bindung von IP-Adressen an die MAC-Adres-
sen der Netzwerkkarten in den einzelnen Rechnern angestrebt werden und
keine voll dynamische Vergabe erfolgen. Dies erleichtert zudem die
Auswertung von Protokollen auf anderen Systemen, wie z. B. Firewalls.
- Neben den Windows 2000 Systemmechanismen zur Authentisierung und PKI-Einsatz erfordert
Sorgfalt und Zeit
Absicherung von Kommunikationskanlen erlaubt Windows 2000 zustz-
lich die Verwendung PKI-basierter (Public Key Infrastructure) Verfahren.
Zur Verwaltung der dabei eingesetzten Schlssel und Zertifikate stellt
Windows 2000 PKI-Komponenten zur Verfgung. Die Kernkomponente
einer PKI-Architektur ist die Ausgabestelle fr Zertifikate (Certificate
Authority, CA). Hinweise zum Umgang und zur sicheren Konfiguration
der Windows 2000 CA finden sich in M 4.144 Nutzung der Windows 2000
CA. Es muss jedoch darauf hingewiesen werden, dass die Planung und der
Betrieb einer PKI Sorgfalt und Zeit bentigen und auch die lokalen Anfor-
derungen bercksichtigt werden mssen. Die angefhrten Empfehlungen
beziehen sich daher nur auf die technischen Besonderheiten der Windows
CA.
- Auch unter Windows 2000 steht mit dem Dienst RRAS (Routing & sichere Einwahl ber
RRAS
Remote Access Service) die Mglichkeit zur Verfgung, per Einwahl aus
der Entfernung auf Ressourcen eines Windows 2000 Netzes zuzugreifen.
Auerdem ist es hiermit mglich, abgesicherte VPN (Virtual Private
Networking) Verbindungen zwischen Teilnetzen verschiedener Standorte
herzustellen. Wird Benutzern die Mglichkeit zur Einwahl erffnet, erge-
ben sich automatisch neue Gefhrdungen fr ein Windows 2000 Netz. Nun
spielt auch die Sicherheit der zur Einwahl benutzten Rechner, z. B. am
heimischen Arbeitsplatz (siehe dazu auch Baustein 9.3 Telearbeit), und die
Sicherheit bei der Kontaktaufnahme (Authentisierung, Absicherung der
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Kommunikation) eine Rolle fr die Sicherheit des internen Netzes.

Hinweise zur Sicherheit bei der Nutzung von RAS-Diensten finden sich im
Baustein 7.6 Remote Access. Weitere Hinweise zu den Windows 2000
spezifischen Aspekten finden sich in M 4.145 Sichere Konfiguration von
RRAS unter Windows 2000.
Abschlieend muss darauf hingewiesen werden, dass die Konfiguration
einzelner Dienste immer von lokalen Gegebenheiten oder Anforderungen
abhngt. Die Konfiguration muss immer im Kontext gesehen werden. Im
Einzelfall muss sogar aufgrund lokaler Gegebenheiten auf weniger sichere
Konfigurationen ausgewichen werden. In diesen Fllen ist es jedoch wichtig,
dann zustzliche Schutzmanahmen einzusetzen, die geeignet sind, die
fehlende Sicherheit in der Dienstkonfiguration auszugleichen. Beispiele
hierfr sind der Einsatz einer zustzlichen Firewall oder auch organisatorische
Manahmen.
- Wurden die bentigten Infrastrukturdienste sinnvoll im Netz angesiedelt?
- Wurde eine Anhufung von Diensten auf wenigen Rechnern vermieden?
- Kann auf den zustzlichen Einsatz von WINS verzichtet werden?
- Wurde die Konfiguration der Dienste DDNS und DHCP aufeinander
abgestimmt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.141 Sichere Konfiguration des DDNS unter

Windows 2000
Der Dienst DDNS (Dynamic Domain Name Service) spielt unter Windows
2000 eine wichtige Rolle, da ohne ihn kein Active Directory (AD) - und damit
auch keine Windows 2000 Domne - betrieben werden kann. DDNS stellt
einen Namensdienst zur Verfgung, der u. a. eine Zuordnung von IP-Adressen
zu (symbolischen) Rechnernamen erlaubt. DDNS beruht dabei auf dem
Internet-Namensdienst DNS und erweitert diesen jedoch um die Mglichkeit,
Namen-Adressen-Zuordnungen dynamisch in die DNS-Datenbank des so
genannten DNS-Servers einzutragen oder aus dieser zu lschen. Auf diese
Weise wird die Nutzung des DHCP (Dynamic Host Configuration Protocol)
ermglicht, welches zur dynamischen Zuordnung von IP-Adressen zu
Rechnern verwendet werden kann.
Fr die Konfiguration und Nutzung des DDNS muss aus Sicherheitssicht
Folgendes bercksichtigt werden:
- Die von einem DDNS-Server verwalteten Zonendaten knnen entweder in Zonendaten im AD
speichern
einer Datei gespeichert werden, wie dies z. B. bei herkmmlichen DNS-
Servern der Fall ist, oder aber die Daten werden im AD gespeichert. Man
spricht dann von AD-integrierten Zonen. Die AD-integrierte Speicherung
bietet sicherheitstechnische Vorteile, so dass dies fr alle von einem
DDNS-Server verwalteten Zonen empfohlen wird. Die Auswahl, wie die
Informationen fr eine Zone abgelegt werden, erfolgt entweder beim
Anlegen der Zone oder kann nachtrglich im Eigenschaftsdialog einer
Zone verndert werden.
- Werden Zoneninformationen in Dateien gespeichert, so sind die Dateien
auf Dateisystemebene so abzusichern, dass auf diese nicht unbefugt zuge-
griffen werden kann. Vielmehr darf der Zugriff auf die Dateien nur dem
Konto des DNS-Administrators und dem DNS-Server-Prozess, der unter
dem lokalen Systemkonto abluft, mglich sein. Es ist zu beachten, dass
diese Dateien nicht mit EFS geschtzt werden knnen, da es sich um
Systemdateien handelt.
- Windows 2000 ist nicht zwingend auf den Einsatz eines Windows 2000
DDNS-Servers angewiesen, sondern kann auch mit anderen DNS-Server-
Implementationen zusammenarbeiten, solange diese bestimmte Anfor-
derungen erfllen, wie z. B. Untersttzung von SRV-Records und der
dynamischen Update-Mglichkeit. Aus Sicherheitssicht empfiehlt sich
jedoch insbesondere beim Betrieb eines Windows 2000 DHCP-Servers die
Nutzung von Windows 2000 DDNS-Servern, da diese das Update von der
korrekten Domnenidentitt eines DHCP-Clients abhngig machen.
- Zoneninformationen knnen zwischen DNS-Servern ausgetauscht und kein Zonentransfer an
unbekannte Rechner
damit aktualisiert werden. Dazu dient der so genannte Zonentransfer. Aus
Sicherheitssicht sollte der Zonentransfer nur von und an vertrauenswrdige
DNS-Server erlaubt werden. Dazu muss die Liste der DNS-Server erstellt
werden, die aktualisierte Zoneninformationen erhalten oder versenden sol-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
len. Durch die Zoneninformationen wird das gesamte Netz beschrieben

(Rechnernamen und IP-Adressen), so dass diese Information einem
Angreifer alle potentiellen Ziele aufzeigt. Aus diesem Grund darf der
Zonentransfer nur zwischen bekannten DNS-Servern stattfinden. Insbe-
sondere darf ein Zonentransfer an unbekannte Rechner oder gar an unbe-
kannte Rechner im Internet unter Sicherheitsgesichtspunkten nicht
stattfinden.
Fr das sichere Zusammenspiel mit einem DHCP-Server zum dynamischen
Verwalten von DNS-Eintrgen ist Folgendes zu bercksichtigen (siehe auch
M 4.143 Sichere Konfiguration des DHCP unter Windows 2000):
- Bei Nutzung von DHCP mit dynamischem DNS-Update sollten ausschlie-
lich AD-integrierte Zonen verwendet werden, damit die Option Secure
Update genutzt und aktiviert werden kann. Die Aktivierung erfolgt ber
den Eigenschaftsdialog der Zone auf der Registerkarte Allgemein durch
Auswahl von ndern beim Typeintrag und Auswahl der Option Active-
Directory-integriert. Dies stellt sicher, dass Vernderungen an dynamisch
erzeugten DNS-Eintrgen nur durch den berechtigten Besitzer mglich
sind. Zustzlich findet eine Zugriffskontrolle aufgrund der Domnen-
mitgliedschaft statt.
- Generell muss bei DNS Eintrgen zwischen dem so genannten Forward-
Mapping (Namen-IP-Addressen-Zuordnung) und dem so genannten
Reverse-Mapping (IP-Addressen-Namen-Zuordnung) unterschieden
werden. Bei einer Windows 2000 Standardinstallation erfolgt die dyna-
mische Registrierung des Forward-Mappings immer durch den DHCP-
Client, das Eintragen des Reverse-Mappings erfolgt durch den DHCP-
Server. Der DHCP-Client muss jedoch auf die DNS-Registrierung ausge-
legt sein, was fr ltere Windows-Versionen nicht der Fall ist: Hier muss
auch das Forward-Mapping durch den DHCP-Server erfolgen. Diese
Option kann im Eigenschaftsdialog auf der Registerkarte DNS aktiviert
werden. Es muss fr ein Netz generell entschieden werden, ob auch das
Forward-Mapping generell fr alle DHCP-Clients durch den DHCP-Server
erfolgt. Aus Sicherheitssicht muss generell verhindert werden, dass durch
"bsartige" DHCP-Clients falsche DNS-Eintrge vorgenommen werden
(siehe auch M 4.143 Sichere Konfiguration des DHCP unter Windows
2000).
- Fr wichtige Server sollten keine dynamischen Adressen verwendet
werden. Die Adressen wichtiger Server sollten statisch im DNS-Server
eingetragen werden. Die Berechtigungen fr das DNS-Record knnen
dabei so gesetzt werden, dass ein berschreiben der Adresse durch ein
dynamisches Update nicht mglich ist. Muss DHCP aus zwingenden
Grnden auch fr zentrale Server eingesetzt werden, so empfiehlt sich auch
hier, dass der Eintrag im DNS durch den Administrator vorgenommen
wird. Die Berechtigungen auf den DNS-Eintrag knnen jedoch so gesetzt
werden, dass ein Update durch den Server erlaubt ist. Die Option Secure
Update - die im Eigenschaftsdialog einer Zone aktiviert werden kann -
stellt dann die korrekte Rechneridentitt sicher.
- Das Lschen "alter" DNS-Eintrge erfolgt standardmig durch den DNS-
Server selbst und nicht durch den jeweiligen DHCP-Client. Dadurch kn-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
nen eine Zeit lang nicht aktuelle DNS-Zuordnungen existieren, die von
Angreifern ausgenutzt werden knnten. Hier empfiehlt es sich, das
Forward-Mapping durch den DHCP-Server nach Ablauf der Lease-Dauer
lschen zu lassen, damit inkonsistente Zuordnungen nur mglichst kurz
existieren. Diese Funktion lsst sich im Eigenschaftsdialog des DHCP-
Servers auf der Registerkarte DNS mit der Option Forward-Lookups
(Name zu Adresse) beim Ablauf des Lease lschen aktivieren. Es ist zu
beachten, dass auch hier, z. B. im Falle eines Rechnerausfalles, die Name-
IP-Adressen-Zuordnung noch bis zum Ablauf der Lease-Dauer im DNS-
Server existiert.
Zusammenfassend ergibt sich, dass DNS-Informationen sicherheitsrelevante,
schutzwrdige Daten darstellen. Kann ein Angreifer DNS-Informationen
verflschen, so kann die Sicherheit des gesamten Netzes kompromittiert
werden. Insofern erfordert insbesondere die Nutzung von DHCP mit DNS
eine sorgfltige Planung unter Sicherheitsgesichtspunkten.
- Knnen alle Zonen als AD-integrierte Zonen betrieben werden?
- Ist der Sichere Update fr alle AD-integrierten Zonen aktiviert?
- Ist fr alle Zonen das bertragen der Zoneninformationen so konfiguriert,
dass der Austausch nur mit bekannten DNS-Servern erfolgen kann?
- Sind die DNS-Eintrge fr wichtige Infrastrukturserver fest vorkonfi-
guriert?
- Ist der DHCP-Server so konfiguriert, dass durch ihn erzeugte DNS-
Eintrge nach Ablauf der Lease-Dauer automatisch gelscht werden?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.142 Sichere Konfiguration des WINS unter

Windows 2000
Der Windows Internet Naming Service (WINS) wurde unter Windows NT als mglichst auf WINS
verzichten
primrer Namensdienst zur Namen-Adressen-Auflsung verwandt. Unter
Windows 2000 hat der DNS (Domain Name Service) bzw. die Windows 2000
Variante DDNS (Dynamic DNS) diese Rolle vollstndig bernommen. Daher
ist WINS zum Betrieb eines Windows 2000 Netzes nicht mehr erforderlich. In
vielen Fllen ist es jedoch auch in Windows 2000 Netzen notwendig, weiter-
hin WINS anzubieten, da diese oft heterogen sind und Rechner oder Appli-
kationen enthalten, die nach wie vor auf die Namensauflsung mittels WINS
angewiesen sind. Wenn mglich, sollte auf den Betrieb von WINS jedoch
verzichtet oder der Betrieb von WINS nur so lange wie unbedingt notwendig
aufrecht erhalten werden.
Unter Sicherheitsgesichtspunkten sind beim Betrieb von WINS unter
Windows 2000 folgende Aspekte zu beachten:
- Werden zwei Strukturen zur Namensauflsung parallel betrieben, so
mssen beide Datenbestnde konsistente Informationen enthalten. Da aber
jeweils unterschiedliche Mechanismen zur Verwaltung eingesetzt werden,
kann dies zu Fehlern in den Datenbestnden fhren. Dies muss durch
regelmige Kontrollen verhindert werden.
- Die Sicherheit des WINS-Servers muss sichergestellt sein. Dazu gehrt Zugriffsrechte auf WINS-
Datenbanken
auch die Dateisystemabsicherung der WINS-Datenbanken, die unter
%SystemRoot%\System32\WINS abgelegt sind. Diese sollten auf restriktive
Zugriffsrechte berprft werden. In der Regel bentigt hier nur das
Systemkonto selbst Zugriffsrechte (Vollzugriff). Werden die Dateien selbst
von Hand gewartet, so mssen auch dem berechtigten Administrator
entsprechende Zugriffsrechte eingerumt werden.
- Da WINS das dynamische Aktualisieren (z. B. durch DHCP) untersttzt, "tomb-stoning"
muss die WINS-Datenbank periodisch nach alten, d. h. ungltigen Eintr-
gen durchsucht werden, die dann gelscht werden. In Umgebungen mit
mehreren Servern kann es passieren, dass durch Replikation ein Eintrag,
der gerade auf einem Server gelscht wurde, wieder auf diesen Server
repliziert wird. Dadurch kann das Lschen schwierig werden. Aus diesem
Grund kann ein Eintrag zunchst als "veraltet" deklariert werden, so dass er
zwar noch vorhanden ist, aber nicht genutzt wird. Durch die Replikation
verbreitet sich auch der Zustand eines so markierten Eintrages, so dass
nach einiger Zeit ein solcher Eintrag auf allen Servern als "veraltet"
markiert ist und dann automatisiert gelscht werden kann. Dieser auch
"tomb-stoning" genannte Prozess kann periodisch ausgefhrt werden. Die
relevanten Alterungsparameter, die angeben, ab wann ein Eintrag als alt
betrachtet wird, mssen im Eigenschaftsdialog des Servers auf der Karte
Intervalle an die lokalen Gegebenheiten angepasst werden. Neben dem
automatischen "tomb-stoning" sollte bei WINS in regelmigen Abstnden
auch ein manuelles "tomb-stoning" durchgefhrt werden, indem alle nicht
automatisch erkannten alten WINS-Eintrge ber das Vorgang-Men als
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
"veraltet" erklrt werden: Vorgang/Lschen, Option Lschen des Eintrags

zu anderen Servern replizieren (veralten). Fr die Sicherung der Konsis-
tenz stehen ber das "Windows 2000 Server Resource Kit" weitere Werk-
zeuge zur Verfgung, z. B. winschk.exe.
- WINS-Replikation, d. h. Austausch und Update der WINS-Daten zwischen WINS-Replikation
einschrnken
WINS-Servern, sollte nur zwischen bekannten und vertrauten WINS-
Servern erlaubt sein. Dazu muss die Liste der WINS-Server, mit denen
repliziert werden darf, fr jeden WINS-Server konfiguriert werden. Dies
verhindert, dass "bsartige" WINS-Server inkonsistente oder verflschte
WINS-Daten in einen WINS-Serververbund einbringen. Insbesondere
drfen WINS-Daten nicht mit Domnen, zu denen keine Vertrauens-
stellungen existieren (untrusted), ausgetauscht werden.
- WINS erlaubt die automatische Konfiguration der WINS-Replikationspart- kein Autodiscovery fr
WINS-Replikation
ner und der zur Replikation benutzten Topologie (Autodiscovery-
Funktion). Dieser Automatismus sollte nicht genutzt werden. Vielmehr ist
die WINS-Replikationstopologie zu planen und explizit ber die Repli-
kationspartnerlisten im Eigenschaftsdialog eines WINS-Servers zu konfi-
gurieren. Bei der Planung muss festgelegt werden, wo WINS-Server im
Netz angesiedelt werden und welcher Server mit welchem Server repliziert.
Wie bei DNS besteht die Hauptgefahr auch bei WINS darin, dass die
Adressen-Namens-Zuordnungen verflscht werden, wodurch Sicherheitsein-
stellungen unterlaufen werden. Daher sind diese Daten besonders schutz-
wrdig und erfordern die Umsetzung der angegebenen Schutzmanahmen. Je
nach Nutzungsszenario sind jedoch auch weitere Manahmen notwendig, wie
beispielsweise physikalische oder organisatorische Sicherheitsmanahmen.
Wird ein WINS-Server aus dem Betrieb genommen, so muss sichergestellt geregeltes
Decommissioning eines
werden, dass dies nach dem vorgeschriebenen Verfahren geschieht, um zu WINS-Servers
verhindern, dass dessen WINS-Daten weiter im Netz zwischen den verblei-
benden WINS-Servern repliziert werden. Im Wesentlichen muss dazu auf
allen WINS-Clients des zu entfernenden Servers die WINS-Konfiguration so
gendert werden, dass diese nicht mehr auf den WINS-Server zugreifen.
Danach mssen alle WINS-Eintrge des Servers, der entfernt werden soll,
zunchst als "veraltet" markiert werden (tomb-stoning). Anschlieend wird die
Replikation zu allen Replikationspartnern von Hand gestartet (fr den Eintrag
Replikationspartner Men Vorgang/Jetzt Replizieren). Nach erfolgreicher
Replikation mit allen Partnern kann der Server entfernt werden. Detaillierte
Hinweise zum korrekten Entfernen (Decommissioning) eines WINS-Servers
finden sich in der Windows 2000 Hilfe.
- Ist geprft worden, ob auf den Einsatz von WINS verzichtet werden kann?
- Sind die WINS-Dateien gegen unbefugten Zugriff geschtzt?
- Werden die WINS-Daten regelmig gewartet?
- Ist die automatische Konfiguration der WINS-Replikationspartner fr
jeden WINS-Server deaktiviert?
- Ist fr jeden WINS-Server die Liste der erlaubten Replikationspartner
konfiguriert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.143 Sichere Konfiguration des DHCP unter

Windows 2000
Mittels DHCP (Dynamic Host Configuration Protocol) lsst sich die Konfi-
guration von Rechnern beim Boot-Vorgang vornehmen. DHCP ist ein Client-
Server Protokoll: Ein DHCP-Server verwaltet einen oder mehrere Pools von
IP-Adressen, die er auf Anforderung an DHCP-Clients auf Zeit vergeben
kann. Die Client-Anforderung ist Broadcast-basiert und wendet sich an alle
DHCP-Server in einem Netz. Der Client whlt aus den verschiedenen Server-
Antworten eine beliebige aus; dies ist in der Regel die erste Antwort. Insofern
existiert prinzipiell keine feste Client-Server-Bindung. Die IP-Adresse wird
einem Client nur auf Zeit, der so genannten Lease-Dauer, zugeordnet. Ist diese
abgelaufen, so kann der Client die Verlngerung der Zuordnung beim Server
beantragen. Ist die maximale Lease-Dauer abgelaufen, so muss ein Neuantrag
erfolgen, wodurch in der Regel eine neue IP-Adresse festgelegt wird. Der
DHCP-Server lscht Adressen-Zuordnungen, wenn die Lease-Dauer
abgelaufen ist und keine Verlngerung beantragt wurde, oder wenn die
maximale Lease-Dauer abgelaufen ist. Die betroffene IP-Adresse wird dann
wieder in den Pool der nicht zugeordneten Adressen aufgenommen und kann
ab dann an andere Rechner vergeben werden. Der Windows 2000 DHCP-
Server kann auch mit dem lteren bootp-Protokoll umgehen, das ursprnglich
aus der Unix-Welt stammt. So knnen auch Rechner, auf denen nicht
Windows 2000 installiert ist, mit IP-Adressen versorgt werden.
Hufig wird DHCP nur zur dynamischen Zuordnung von IP-Adressen
verwendet, da das feste Eintragen von IP-Adressen auf Clients in einem
groen Netz mhsam ist. DHCP erlaubt jedoch auch die Konfiguration vieler
weiterer Netz-bezogener Parameter (z. B. DNS-Server). Diese Parameter -
insgesamt mehr als 70 - die auch DHCP-Optionen genannt werden, knnen fr
jeden Adresspool unterschiedlich konfiguriert werden.
Bei der Verwendung von DHCP ergeben sich mehrere Sicherheitsprobleme,
die bercksichtigt werden mssen:
- Erfolgt die IP-Adressen-Zuordnung dynamisch, kann eine bestimmte IP- synchronisierte Zeit und
konsistente
Adresse nicht mehr automatisch einem dedizierten Rechner zugeordnet Protokollierung
werden. Im Falle eines Angriffes oder bei der nachfolgenden Angriffs-
rekonstruktion muss daher immer zunchst festgestellt werden, welcher
Rechner zum fraglichen Zeitpunkt die entsprechende IP-Adresse erhalten
hat. Dies erfordert konsistente Protokolldateien sowie eine synchronisierte
Zeit innerhalb des gesamten Netzes, damit eine korrekte zeitliche Zuord-
nung der Eintrge aus Protokolldateien, die auf unterschiedlichen Rechnern
erzeugt wurden, mglich ist.
- Die IP-Adressen werden bis zum Ablauf der Lease-Dauer einem bestimm-
ten Rechner zugeordnet. Die Namen-Adressen-Zuordnung wird ent-
sprechend im DNS-Server registriert. Ist ein Rechner ausgeschaltet oder
kann ein Angreifer einen Rechner lahm legen, z. B. durch eine Denial-of-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Service-Attacke, so kann er u. U. dessen IP-Adresse bernehmen, solange

die Lease-Zeit noch nicht abgelaufen ist. Um die Zeitspanne zu verringern,
in der eine illegale bernahme einer IP-Adresse mglich ist, sollte der
DHCP-Server so konfiguriert werden, dass er das Forward-Mapping im
DNS-Server nach Ablauf der Lease-Zeit automatisch lscht.
- Damit beim Einsatz von DHCP die Zuordnung zu Rechnern mglichst Lange Lease-Zeiten
einrichten
statisch ist, empfiehlt es sich, eine lange Lease-Dauer (z. B. 6 Monate) ein-
zurichten. Auf diese Weise hat ein Rechner eine fast statische IP-Adresse
und DHCP kann zum Verteilen von Konfigurationen ber DHCP-Optionen
verwandt werden. Lange Lease-Zeiten knnen jedoch bei mobilen
Rechnern - je nach DNS-Update-Verfahren - auch zu Problemen fhren
(siehe unten).
- Die Vergabe von IP-Adressen an DHCP-Clients ist unter Sicherheits-
gesichtspunkten eine kritische Aktivitt. Aus diesem Grund sollten nur
berechtigte DHCP-Server in einem Netz existieren. Unter Windows 2000
knnen DHCP-Server nur betrieben werden, wenn diese im Active
Directory als autorisierte DHCP-Server registriert wurden. Dies erfolgt in
der DHCP-Verwaltung (MMC-Snap-In) ber Vorgang/Autorisieren. Es ist
jedoch zu beachten, dass ein Angreifer auch DHCP-Server einsetzen kann,
die nicht unter Windows 2000 betrieben werden, beispielsweise Linux
DHCP-Server. Solche DHCP-Server unterliegen nicht dieser Einschrn-
kung. Allerdings durchsuchen die Windows 2000 Komponenten auto-
matisch den Netzverkehr nach Nachrichten von nicht autorisierten DHCP-
Servern und melden solche. Eine explizite Konfiguration dieses Verhaltens
ist nicht notwendig.
- DHCP-Server sollten nicht auf einem Windows 2000 Domnen-Controller DHCP-Server nicht auf
Domnen-Controllern
ablaufen. Alle Betriebssystemkomponenten von Windows 2000 laufen betreiben
unter den Berechtigungen Local System ab. Ein Zugriffsschutz zwischen
diesen Komponenten existiert daher nicht. Eine entsprechende Empfehlung
wird auch von Microsoft selbst ausgesprochen.
- Wird DHCP auch fr zentrale Server eingesetzt (z. B. WWW-Server), so feste IP-Adressen fr
zentrale Server
empfiehlt es sich, entsprechende Adressreservierungen im DHCP-Server reservieren
einzutragen. Dazu wird die so genannte MAC-Adresse, die die eindeutige
Identitt der Netzkarte des relevanten Rechners darstellt, mit einer IP-
Adresse verknpft. Diese kann dann nur vom Rechner mit der eingetrage-
nen MAC-Adresse erfolgreich angefordert werden. Es ist jedoch zu
beachten, dass moderne Netzkarten auch das ndern der MAC-Adresse
zulassen, so dass auch dies keinen vollstndigen Schutz gegen die ber-
nahme von IP-Adressen bietet.
- Generell ist auch fr Arbeitsplatzrechner, die im Regelfall nicht stndig im
Netz bewegt werden, die Bindung der IP-Adresse an die MAC-Adresse zu
empfehlen. Dieses Vorgehen erfordert allerdings das Pflegen der MAC-IP-
Adressen-Zuordnung fr alle Arbeitsplatzrechner. Dies kann jedoch zentral
erfolgen und erleichtert die Auswertung von Protokollen auf anderen
Rechnern (z. B. auf einer Firewall), insbesondere in heterogenen Netzen.
- Der Windows 2000 DHCP-Server kann so konfiguriert werden, dass nicht
nur das Reverse-Mapping (IP-Adressen-Namen-Zuordnung), sondern auch
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
das Forward-Mapping (Namen-IP-Adressen-Zuordnung) im DNS-Server

eingetragen wird. Dies hat den Vorteil, dass dynamische DNS-Updates nur
durch DHCP-Server erfolgen knnen, so dass Vernderungen immer durch
die gleichen und bekannten Rechner ausgelst werden. Dieses Verfahren
besitzt jedoch auch verschiedene Nachteile:
- Die DNS-Records sind dann im Besitz des DHCP-Servers. Fllt
dieser aus, so mssen die DNS-Records vom Administrator von
Hand entfernt werden.
- Werden DHCP-Clients hufig bewegt, so erhalten sie ihre Adresse
ggf. von unterschiedlichen DHCP-Servern, werden jedoch beim
gleichen DNS-Server registriert. Dadurch kann das Adressen-Update
fehlschlagen, da das DNS-Record noch auf den vorherigen DHCP-
Server registriert ist und der aktuelle DHCP-Server nicht die Update-
Berechtigung besitzt. Die Wahrscheinlichkeit fr das Auftreten
dieses Phnomens kann dadurch verringert werden, dass krzere
Lease-Zeiten konfiguriert werden und die DHCP-Server nach Ablauf
der Lease-Zeit auch das Forward-Mapping im DNS-Server lschen.
- Tragen DHCP-Server auch das Forward-Mapping im DNS-Server
ein, so geschieht dies unter den Berechtigungen des DHCP-Servers,
dem diese Erlaubnis aufgrund seiner Domnenzugehrigkeit erteilt
ist. Da auf DHCP-Ebene keine Authentisierung erfolgt, knnen auf
diese Weise auch Rechner, die nicht Domnenmitglieder sind, im
DNS registriert werden. Erfolgt das Eintragen des Forward-
Mappings durch den DHCP-Client selbst und ist die Option Secure
Update fr die relevante DNS-Zone aktiviert, so knnen nur authen-
tisierte Rechner DNS-Updates vornehmen.
Zusammenfassend muss bercksichtigt werden, dass die Nutzung von DHCP
und dynamischen DNS-Updates jeweils mit Vor- und Nachteilen behaftet ist.
Die zu verwendende Konfiguration muss daher jeweils fr den Einzelfall nach
einer sorgfltigen Risikoabschtzung entschieden werden.
- Ist geprft worden, ob auf den Einsatz von DHCP verzichtet werden kann?
- Ist der DHCP-Server so konfiguriert, dass er die von ihm erzeugten DNS-
Eintrge automatisch nach Ablauf der Lease-Dauer wieder lscht?
- Sind fr alle nicht mobilen Rechner, die DHCP nutzen mssen, vorde-
finierte IP-Adressen reserviert und an die jeweilige MAC-Adresse gebun-
den?
- Ist geprft worden, ob alle dynamischen DNS-Eintrge ausschlielich
durch den DHCP-Server erfolgen knnen?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.144 Nutzung der Windows 2000 CA

Windows 2000 wird mit eigenen PKI-Komponenten ausgeliefert. Eine Haupt-
komponente jeder PKI (Public Key Infrastruktur) bildet dabei die so genannte
CA (Certificate Authority, Zertifikatsausgabestelle). Windows 2000 kann
generell auch ganz ohne PKI bzw. CA betrieben werden, wenn spezielle
Windows 2000 Funktionen, wie z. B. chipkartenbasiertes Logon und SSL-
Kommunikation zwischen Betriebssystemkomponenten, nicht genutzt werden.
Ist die Entscheidung fr den Aufbau einer Windows 2000 PKI gefallen und
wurde eine entsprechende PKI-Planung (siehe dazu M 2.232 Planung der
Windows CA-Struktur) durchgefhrt, so muss eine der Windows 2000 CAs
(Enterprise-CA oder Stand-alone-CA) installiert und betrieben werden.
Aus Sicherheitssicht ergeben sich dabei folgende Aspekte, die zu bercksich-
tigen sind:
- Gem der geplanten CA-Struktur mssen die notwendigen Vertrauens- Vertrauensstellungen
einrichten
stellungen eingerichtet werden. Es ist darauf zu achten, dass kein Fehler in
der Vertrauensstruktur existiert, da dies im Betrieb zu Sicherheitsprob-
lemen fhren kann, indem bestimmten Zertifikaten flschlicherweise ver-
traut wird. Die notwendigen Vertrauensstellungen werden entweder
whrend der Konfiguration als untergeordnete CA oder aber durch das
Eintragen von CA-Zertifikaten in die Liste der vertrauten Root-CAs
(Cross-Zertifizierung) eingerichtet.
- Rechner, auf denen die CA-Komponenten von Windows 2000 installiert CA-Komponenten
schtzen
sind, mssen besonders geschtzt werden. Insbesondere ist die physika-
lische Sicherheit und die sichere Konfiguration des Betriebssystems
notwendig (siehe auch M 4.137 Sichere Konfiguration von Windows 2000,
M 4.146 Sicherer Betrieb von Windows 2000). Vor der Installation der CA-
Komponenten muss bercksichtigt werden, dass nach der Installation der
CA-Komponenten keine Vernderungen der Domnenzugehrigkeit und
des Namens des benutzten Rechners mehr mglich sind. Der Rechner stellt
nun die Identitt der CA dar, die nicht verndert werden darf, so dass dies
von Windows 2000 auch nicht zugelassen wird.
- Es empfiehlt sich, dedizierte CA-Rechner zu benutzen, auf denen keine
weiteren Dienste ablaufen.
- Die Administration der CA darf nur den berechtigten CA-Administratoren
mglich sein.
Beim Betrieb einer Stand-alone-CA wird das Ausstellen von Zertifikaten
durch den CA-Administrator angestoen, nachdem die Rechtmigkeit der
Zertifikatsanforderung durch ihn berprft wurde. Dieser Autorisierungs-
schritt fehlt, wenn eine Enterprise-CA eingesetzt wird, die Zertifikatsanfragen
automatisch bearbeitet. Fr die Enterprise-CA sind daher auerdem die
folgenden Aspekte zu bercksichtigen:
- Soll unter Windows 2000 Smartcard-gesttztes Login ermglicht werden
oder sollen fr Rechner Zertifikate, z. B. zur Absicherung der Kommuni-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
kation von Betriebssystemkomponenten mittels SSL, benutzt werden, so

muss eine Enterprise-CA eingesetzt werden.
- Eine Enterprise-CA stellt Zertifikate nur dann aus, wenn das so genannte Enroll Permissions
konfigurieren
Zertifikats-Template dem Benutzer, der die Zertifikatsanforderung initiiert
hat, entsprechende Zugriffsrechte einrumt. Daher sind fr jedes Zertifi-
kats-Template die gem CA-Planung korrekten Zugriffsrechte (so
genannte Enroll Permissions) zu konfigurieren. Die Konfiguration ist
zweistufig. Zum einen erfolgt sie ber das MMC-Snap-in Certification
authority console. Hier knnen ber den Eigenschaftsdialog des CA-
Serverknotens die generellen Zugriffsberechtigungen auf den Server einge-
stellt werden. Damit kann den berechtigten Benutzergruppen das Recht
Enroll eingetragen werden. Zum anderen erfolgt die Konfiguration ber
das MMC-Snap-in AD Sites and Services im Eigenschaftsdialog der
einzelnen Zertifikats-Templates unter dem Konsolenpfad Services/Public
Key Services/Certificate Templates.
- Fr die Enterprise-CA erfolgt die Zertifikatsanforderung von Benutzern
ber spezielle WWW-Seiten, die so genannten Web Enrollment Pages, die
auf einem separaten Rechner mit installiertem WWW-Server gehalten
werden.
Fr den Zugriff auf diese Seiten sollte die Authentisierung nicht mittels Zugriff auf Web
Enrollment Pages
basic authentication erfolgen. Diese Methode hat nmlich den Nachteil, absichern
dass hier ohne zustzliche Manahmen, wie z. B. durch SSL-Absicherung,
das Benutzerpasswort mehrfach ungeschtzt bertragen wird. Das Pass-
wort ist zwar Base64-kodiert und damit auf den ersten Blick nicht entzif-
ferbar, aber ohne Probleme auswertbar.
Auerdem muss der Rechner, der die Web Enrollment Pages anbietet,
abgesichert werden, da dieser direkt mit dem CA-Rechner kommuniziert.
Netztopologisch muss der Rechner, der die Enrollment Pages anbietet, von
allen Benutzern zugreifbar sein, die berechtigt sind, Zertifikate zu bean-
tragen. Je nach Einsatzszenario kann auch eine Anordnung in einem
eigenen Netzsegment sinnvoll sein, wobei der Zugriff auf dieses Segment
beispielsweise durch Paketfilter kontrolliert werden kann.
- Soll die Enterprise-CA lediglich Zertifikate fr Rechner ausgeben und
keine Benutzerzertifikate erstellen, so muss die Untersttzung der Web
Enrollment Pages deaktiviert werden.
Generell muss auch bercksichtigt werden, dass die Rckruflisten ent-
sprechend dem CA-Konzept erstellt und verteilt werden mssen. Die aufge-
zeigten Manahmen mssen immer auf den konkreten Fall angepasst werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Wurde eine bedarfsgerechte PKI-Planung durchgefhrt?
- Sind alle Rechner, auf denen CA-Komponenten installiert sind, gegen
unbefugten Zugriff geschtzt?
- Sind alle Rechner, auf denen CA-Komponenten installiert sind, physika-
lisch geschtzt?
- Sind auf Rechnern, auf denen CA-Komponenten installiert sind, keine
anderen Infrastrukturdienste installiert?
- Sind fr alle CAs alle eingerichteten Vertrauensstellungen geprft worden?
- Sind fr alle Zertifikatsvorlagen die notwendigen Zugriffsrechte fr
Benutzer eingetragen?
- Ist eine Enterprise-CA installiert worden, wenn eine Benutzerauthenti-
sierung mittels Chipkarte geplant ist oder wenn die Kommunikation
zwischen Windows 2000 Systemkomponenten mittels SSL abgesichert
werden soll?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.145 Sichere Konfiguration von RRAS unter

Windows 2000
Auch unter Windows 2000 steht eine RAS (Remote Access Service) Kompo-
nente zur Verfgung, die jedoch auch als RRAS (Routing & RAS) bezeichnet
wird. Der RRAS-Server untersttzt dabei auerdem den Aufbau verschls-
selter Kommunikationsverbindungen, so dass damit ebenfalls VPN (Virtual
Private Network) Verbindungen mglich sind. Damit ist es z. B. mglich,
zwei Windows 2000 Netze ber ein unsicheres Kommunikationsmedium,
etwa das Internet, miteinander zu verbinden. Es ist zu bercksichtigen, dass
hierbei in der Regel das Firewall-Konzept entsprechend angepasst werden
muss, siehe dazu Baustein 7.3 Firewall. Allgemeine Hinweise zu RAS finden
sich auerdem im Baustein 7.6 Remote Access, so dass im Folgenden nur die
fr Windows 2000 spezifischen Empfehlungen aufgefhrt sind. Um im
konkreten Fall eine sichere RAS-Konfiguration zu erreichen, sind jedoch alle
relevanten Manahmenbndel auf ihre Anwendbarkeit hin zu berprfen und
entsprechend umzusetzen.
Der Windows 2000 RRAS-Server erlaubt als Besonderheit die Steuerung der Konfiguration durch
RAS-Richtlinien
Einwahlberechtigung fr Benutzer durch so genannte RAS-Richtlinien
(Policies). Hier knnen vielfltige Beschrnkungen fr die Einwahl festgelegt
werden, z. B. die maximale Leerlaufzeit vor Trennen der Verbindung, die
Vorgabe von Rufnummern, von denen aus die Einwahl erfolgen muss, sowie
die Vorgabe des Einwahlmediums. ber die RAS-Richtlinien werden jedoch
auch die erlaubten Authentisierungsverfahren festgelegt, deren Strke und
Sicherheit mageblich fr die Sicherheit eines Netzes mit RAS-Einwahl-
mglichkeit sind.
Bei der Windows 2000 RRAS Konfiguration ist dabei Folgendes zu berck-
sichtigen:
- Die Einwahl ist mit den zur Verfgung stehenden Mitteln zu beschrnken.
Windows 2000 bietet hierfr die folgenden Kriterien an:
- Leerlaufzeit: Zeitdauer ohne Aktivitten, nach der die Verbindung
getrennt wird. Standardmig ist diese Eigenschaft nicht eingestellt,
und Verbindungen im Leerlauf werden nicht durch den RAS-Server
getrennt.
- Maximale Sitzungsdauer: Zeitdauer, ber die eine Verbindung
maximal besteht. Nach Ablauf der maximalen Zeitdauer fr die
Sitzung wird die Verbindung getrennt. Standardmig ist diese
Eigenschaft nicht eingestellt, und beim RAS-Server besteht keine
maximale Zeitdauer fr Sitzungen.
- Tage und Uhrzeiten: Die Wochentage und Uhrzeiten, zu denen eine
Verbindung zulssig ist. Wenn der Wochentag und die Uhrzeit der
Verbindung nicht mit den konfigurierten Angaben bereinstimmen,
wird die Verbindung verweigert. Standardmig ist diese Eigen-
schaft nicht eingestellt, und beim RAS-Server bestehen keine
Einschrnkungen hinsichtlich des Wochentags oder der Uhrzeit. Die
berprfung auf zulssige Verbindungszeiten findet nur beim
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Aufbau einer Sitzung statt. Eine aktive Verbindung, die zu einem

zulssigen Zeitpunkt aufgebaut wurde, wird auch nach dem Ablauf
des zulssigen Zeitfensters nicht durch den RAS-Server getrennt.
- Einwhlnummer: Eine bestimmte Rufnummer, die ein Anrufer
verwenden muss, damit die Verbindung zugelassen wird. Wenn die
Einwhlnummer der Verbindung nicht mit der konfigurierten
Einwhlnummer bereinstimmt, wird die Verbindung verweigert.
Standardmig ist diese Eigenschaft nicht eingestellt, und beim
RAS-Server sind alle Einwhlnummern zulssig.
- Einwhlmedien: Arten der Medien, die ein Benutzer verwenden
muss, damit eine Verbindung zugelassen wird, wie beispielsweise
Modem (asynchron), ISDN oder virtuelles privates Netz (VPN).
Wenn das Einwhlmedium der Verbindung nicht mit dem vorge-
gebenen Einwhlmedium bereinstimmt, wird die Verbindung
verweigert. Standardmig ist diese Eigenschaft nicht eingestellt,
und beim RAS-Server sind alle Medienarten zulssig.
Generelle Empfehlungen zu den vorgenannten Parametern sind nicht
mglich. Entsprechende Festlegungen mssen sich am Schutzbedarf
des Netzes und dem beabsichtigten Einsatzzweck orientieren.
- Zur Authentisierung sollten nur starke Verfahren unter Verwendung aus- starke Authentisierung
reichend langer Schlssellngen eingesetzt werden. Welche Schlssel-
lngen als ausreichend sicher erachtet werden, hngt vom Einsatzszenario
ab und sollte in der RAS-Sicherheitsrichtlinie (siehe auch M 2.187 Fest-
legen einer RAS-Sicherheitsrichtlinie) festgelegt werden. Zu beachten ist,
dass alle RAS-Clients mindestens eines der festgelegten Verfahren unter-
sttzen mssen. Windows 2000 bietet standardmig folgende Authenti-
sierungsverfahren an: EAP-TLS, MS-CHAP v2, MS-CHAP, CHAP,
SPAP, PAP sowie nicht authentisierte Zugriffe.
- Nicht authentisierte Verbindungen drfen nicht angenommen
werden.
- Die Verfahren PAP, SPAP sowie MS-CHAP (in beiden Versionen)
werden als unsicher eingestuft und sollten daher nicht verwendet
werden.
- Muss MS-CHAP als Authentisierungsverfahren eingesetzt werden,
so sollte die Version 2 genutzt werden, da diese sicherer ist als
Version 1. Da auch in der Version 2 Sicherheitsprobleme gefunden
wurden, sollte auf eine neuere Version zurckgegriffen werden,
sobald eine solche verfgbar ist.
- EAP-TLS (Extensible Authentication Protocol-Transport Layer
Security) ist nur fr einen RAS-Server verfgbar, der Mitglied in
einer Windows 2000 Domne ist. EAP-TLS erlaubt standardmig
die zertifikats- und chipkartenbasierte Authentisierung, wobei
Microsoft aus Sicherheitsgrnden nur die Verwendung der chip-
kartenbasierten Variante empfiehlt.
- Die Nutzung von RADIUS erlaubt die zentrale Verwaltung von RAS-
Zugangsberechtigungen.
- RAS-Verbindungen sollten grundstzlich verschlsselt sein, um ein hohes Verschlsselung
aktivieren
Ma an Sicherheit zu gewhrleisten. Dazu sollten mglichst sichere
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Verfahren zum Einsatz kommen. Die Mglichkeit, unverschlsselte Ver-

bindungen aufzubauen, sollte deaktiviert werden. Folgende Mglichkeiten
werden durch Windows 2000 angeboten:
- Keine Verschlsselung: Diese Option ermglicht eine unverschls-
selte Verbindung und sollte nicht eingesetzt werden.
- Basisverschlsselung: Bei DF-Verbindungen und PPTP-basierten
VPN-Verbindungen wird die Microsoft Punkt-zu-Punkt-Verschls-
selung (MPPE) mit einem 40-Bit-Schlssel verwendet. Bei VPN-
Verbindungen, die auf L2TP und IPSec basieren, wird eine 56-Bit-
DES-Verschlsselung eingesetzt. Diese Option sollte nicht ver-
wendet werden.
- Starke Verschlsselung: Bei DF-Verbindungen und PPTP-basier-
ten VPN-Verbindungen wird MPPE mit einem 56-Bit-Schlssel
verwendet. Bei VPN-Verbindungen, die auf L2TP und IPSec
basieren, wird eine 56-Bit-DES-Verschlsselung eingesetzt. Diese
Option kann fr Verbindungen eingesetzt werden, die vor zuflligem
Mitlesen geschtzt werden sollen. Fr den Schutz vertraulicher
Informationen whrend der Netzbertragung sollte diese Option
nicht verwendet werden.
- Strkste Verschlsselung: Bei DF-Verbindungen und PPTP-
basierten VPN-Verbindungen wird MPPE mit einem 128-Bit-
Schlssel verwendet. Bei VPN-Verbindungen, die auf L2TP und
IPSec basieren, wird die 3DES-Verschlsselung (Triple DES)
eingesetzt. Diese Option ist nur nach Einspielen des "High-
Encryption-Pack" und des Service Pack 1 oder 2 verfgbar. Diese
Option sollte fr die Netzabsicherung gewhlt werden, wenn
vertrauliche Informationen bertragen werden.
- Die ausschlieliche Steuerung der Einwahl ber RAS-Richtlinien, z. B. in
Abhngigkeit der Zugehrigkeit zu einer Benutzergruppe, ist nur in
Domnen mglich, die im Native Mode betrieben werden.
- Die Einwahlberechtigung kann nicht ber eine Gruppenrichtlinie (GPO)
aktiviert werden. Dies muss fr jeden Benutzer einzeln erfolgen.
Die hier aufgezeigten Empfehlungen und Hinweise knnen nur allgemeine
Anhaltspunkte zur sicheren RAS-Konfiguration liefern, da die konkrete
Konfiguration sehr vom Einsatzszenario und den damit verbundenen Sicher-
heitsanforderungen abhngt. Insofern ist eine entsprechende Anpassung auch
unter Bercksichtigung der unternehmens- bzw. behrdenweiten Sicherheits-
leitlinie notwendig.
- Wurde ein bedarfsgerechtes RAS-Konzept entworfen und umgesetzt?
- Wurde das RAS-Konzept auf das Firewall-Konzept abgestimmt?
- Ist der RAS-Server so konfiguriert, dass er nicht authentisierte Verbindun-
gen verweigert?
- Werden nur starke Authentisierungsmechanismen eingesetzt?
- Werden die bertragenen Daten verschlsselt?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.146 Sicherer Betrieb von Windows 2000

Nach der Installation und initialen Konfiguration gem den im Vorfeld
geplanten Windows 2000 Konzepten und Sicherheitsrichtlinien erfolgt der
Betrieb von Windows 2000 Rechnern in der Regel im Netzverbund. Die
Sicherheit eines solchen Netzes hngt dabei einerseits von den eingestellten
Konfigurationsparametern ab. Sie wird aber auch andererseits mageblich
durch die Art und Weise der Konfigurationsnderungen bestimmt, die im
laufenden Betrieb erfolgen mssen. Dabei sind insbesondere auch Seiten-
effekte zu bercksichtigen, die unter Umstnden unbeabsichtigt zu Sicher-
heitslcken fhren knnen.
Windows 2000 bietet eine Reihe von Werkzeugen und Mechanismen an, die
die Administratoren bei der Aufrechterhaltung der Sicherheit eines laufenden
Systems untersttzen knnen.
- Windows File Protection ist ein Systemmechanismus von Windows 2000,
der sicherstellt, dass Systemdateien unverndert im Originalzustand vor-
handen sind. Der Mechanismus nutzt zwei Komponenten: den so
genannten SystemFileChecker (sfc.exe), der die Systemdateien auf ihre
Unverndertheit hin berprft (z. B. beim Systemstart) und vernderte
Dateien durch zwischengespeicherte Originaldateien ersetzt. Weiterhin
existiert ein berwachungsmechanismus, der beim schreibenden Zugriff
auf Systemdateien diese wieder durch die Originalversion ersetzt. Der
Mechanismus kann so konfiguriert werden, dass das berschreiben nach
einer entsprechenden Besttigung erfolgreich ist und die vernderte Datei
beibehalten wird. Die Konfiguration erfolgt ber die Kommandozeile
durch die Kommandos:
- sfc /enable: Vernderungen werden nach einer Besttigung ber-
nommen.
- sfc /quiet: Vernderte Dateien werden ohne Nachfrage durch die
Originale ersetzt.
- Windows 2000 bietet mit dem kommandozeilenbasierten Sicherheitseditor
secedit.exe bzw. dem MMC-Snap-in Sicherheitskonfiguration und -analyse
Werkzeuge zur Konfiguration der Sicherheitseinstellungen von Windows
2000 Rechnern. Die Sicherheitskonfiguration kann auch in einer
Datenbank gespeichert werden, gegen die dann ein Rechner auf Konfor-
mitt getestet werden kann. Dazu wird zunchst eine Datenbank neu
erzeugt (Vorgang/Datenbank ffnen, neuen oder existierenden Datenbank-
namen eingeben). Diese kann dann mit einer Sicherheitsvorlage (.inf-Datei,
siehe MMC-Snap-in Sicherheitsvorlagen) initialisiert werden. Mittels Vor-
gang/Computer jetzt analysieren bzw. Vorgang/System jetzt konfigurieren
kann eine Analyse oder Konfiguration des Systems anhand der Einstellun-
gen der Datenbank erfolgen. Die Datenbank selbst liegt in Dateiform vor
(.sdb-Datei) und kann auch auf andere Systeme bertragen werden. Aller-
dings sind die Aussagen bei Abweichungen von Zugriffsrechten auf Datei-
oder Registry-Ebene wenig hilfreich, da lediglich eine Abweichung
dokumentiert wird, nicht jedoch, welche Zugriffsrechte abweichen.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Die Sicherheitseinstellungen eines Windows 2000 Rechners erfolgen beim

Betrieb in einer Domne in der Regel durch die Anwendung von Gruppen-
richtlinienobjekten bzw. den in einem Objekt enthaltenen Einstellungen.
Auf diese Weise lassen sich nicht nur die Sicherheitseinstellungen effizient
und zentral auch fr groe Windows 2000 Netze verwalten. Im tglichen
Betrieb sind in der Regel auch nderungen von GPO-Einstellungen zu
erwarten. Die nderungen finden zentral an einem Domnen-Controller
statt und werden dann an die betroffenen Rechner verteilt. Dazu kann der
GPO-Mechanismus so konfiguriert werden, dass periodisch ein Update der
GPO-Einstellungen erfolgt, so dass die vernderten Einstellungen wirksam
werden knnen (siehe auch M 2.231 Planung der Gruppenrichtlinien unter
Windows 2000).
- Die Sicherheit des Systemzugangs kann durch die Verwendung von Smart-
card-basiertem Logon erhht werden. Die Authentisierung erfolgt dann
nicht ber einen Benutzernamen und ein mglicherweise schwaches Pass-
wort, sondern ber ein Zertifikat, welches auf einer Chipkarte gespeichert
ist. Windows 2000 kann so konfiguriert werden, dass Anmeldungen alter-
nativ ber Benutzername und Passwort bzw. mit Chipkarte oder
ausschlielich mit Chipkarte mglich sind. Generell knnen hier nur
Microsoft-konforme Zertifikate genutzt werden sowie Chipkarten, die von
Windows 2000 untersttzt werden.
Die Sicherheit eines Rechnersystems basiert immer auch auf der physika-
lischen Sicherheit der Rechner und Netzkomponenten. Diese muss auch fr
den Betrieb eines Windows 2000 Systems sichergestellt sein. Entsprechende
Manahmen finden sich in den Kapiteln 4, 5 und 6 des IT-Grundschutzhand-
buchs. Fr den sicheren Betrieb eines Windows 2000 Systems ist generell
Folgendes zu beachten:
- Die Sicherheit von Windows 2000 hngt wesentlich von der Sicherheit des geregelte Administration
des AD
Active Directories ab. Die hier enthaltenen Informationen mssen einer-
seits vor unberechtigter Vernderung geschtzt und andererseits konsistent
gehalten werden. Dies erfordert insbesondere bei Vernderungen entspre-
chende Sorgfalt. Es empfiehlt sich dringend, im Rahmen der Sicherheits-
planung nicht nur Werte oder Wertbereiche fr Parameter festzulegen,
sondern auch (innerbetriebliche oder administrative) Ablufe zu definieren,
die geeignet sind, die festgelegte Sicherheitsrichtlinie umzusetzen. So
sollte z. B. festgelegt werden, welche Schritte beim Anlegen eines neuen
Benutzer-Kontos durchzufhren sind, damit die notwendigen Vernde-
rungen vollstndig ausgefhrt werden.
Auch die Installation eines neuen zustzlichen Domnen-Controllers ist
eine sicherheitskritische AD-Vernderung, da dieser eine Kopie des AD
erhlt. Die physikalische Sicherheit sowie die konsistente und sichere
Konfiguration des zuknftigen Domnen-Controllers muss daher vor der
Eingliederung sichergestellt sein.
Windows 2000 erlaubt es, Domnen-Controller im so genannten Active
Directory Restore Modus zu betreiben. In diesem Modus ist der Active
Directory Service nicht gestartet und es knnen Reparaturarbeiten an der
AD-Datenbank erfolgen, indem bestimmte AD-Zweige von einem Backup-
Medium zurckgespielt werden. Die Vernderungen knnen so eingespielt
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden, dass sie in der gesamten Domne verteilt werden. Daher muss
dieser Vorgang unter grter Sorgfalt erfolgen. Es empfiehlt sich, den AD-
Restore-Modus nur im Vier-Augen-Prinzip zu nutzen, da Eingabefehler die
Integritt des AD zerstren knnen.
- Neben der Sicherheit des Active Directories und die durch die im AD fest- Sicherheit der
Systemdienste
gelegten Parameter bedingte Systemsicherheit muss auch die Sicherheit
wichtiger Systemdienste gewhrleistet werden. Hierbei spielt die Sicherheit
von DNS, WINS, DHCP, RAS sowie Kerberos eine besondere Rolle. Auch
hier muss bei nderungen sichergestellt werden, dass die fr Windows
2000 geltenden und festgelegten Sicherheitsrichtlinien nicht verletzt
werden. Hinweise zur Konfiguration dieser Dienste finden sich in der
Dienste und den darin referenzierten Manahmen.
- Fr die Verwaltung eines Windows 2000 Systems stehen standardmig Zugriff auf
Verwaltungstools
die so genannten Snap-ins der Microsoft Management Console (MMC- beschrnken
Snap-ins) zur Verfgung. MMC-Snap-ins stellen Verwaltungsmodule dar,
die ber eine standardisierte Schnittstelle in die MMC integriert werden
knnen. Der Zugriff auf die verschiedenen MMC-Snap-ins muss daher
reglementiert werden. Normalen Benutzern sollte der Zugriff auf System-
verwaltungswerkzeuge generell untersagt werden. Als Ausnahme ist hier
jedoch das MMC-Snap-in zur Verwaltung von Zertifikaten zu nennen,
welches auch von normalen Benutzern zum Verwalten der eigenen Zertifi-
kate genutzt werden muss. Der Zugriff auf die einzelnen MMC-Snap-ins
lsst sich dabei feingranular ber GPO-Einstellungen regeln.
- Die Verwaltungstools zum Zugriff auf die lokale Registry eines Rechners
(regedt32 und regedit) sollten nicht fr normale Benutzer zugreifbar sein.
Auch dies lsst sich durch GPO-Einstellungen erreichen.
- Die Sicherheit eines Windows 2000 Netzes hngt von vielen Faktoren ab. neue Applikationen
testen
Insbesondere knnen Sicherheitslcken auch durch Zusatzapplikationen
entstehen, die entweder fehlkonfiguriert sind oder Fehler in der Program-
mierung enthalten. Oft ergeben sich Probleme auch erst durch den gemein-
samen Betrieb mehrerer Anwendungen. Aus diesem Grund sind vor
Einfhrung einer neuen Applikation Tests durchzufhren, die einen ersten
Hinweis darauf geben, ob offensichtliche Probleme bestehen. Eine voll-
stndige Sicherheit kann hier jedoch nicht erreicht werden, da insbesondere
der Test auf Fehler durch Seiteneffekte in anderen Applikationen schwierig
durchzufhren und extrem aufwendig ist.
- Auch wenn nderungen sorgfltig und unter Einhaltung aller Vorsichts- berwachung des
Systems
manahmen erfolgen, kann die Existenz von Sicherheitslcken in einem
komplexen System nie ganz ausgeschlossen werden. Aus diesem Grund
sollte immer eine geeignete Systemberwachung stattfinden (siehe auch
M 4.148 berwachung eines Windows 2000 Systems). Dabei muss die
Strke und Genauigkeit der berwachung der Gefhrdungslage angepasst
sein. Die Art und Weise der berwachung kann dabei immer nur im
konkreten Fall festgelegt werden. Generell sollten auch die Ttigkeiten von
Administratoren durch die berwachung erfasst werden. Zustzlich
empfiehlt sich eine regelmige berprfung, damit eventuelle Lcken,
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
die durch Vernderungen des Systems entstehen knnen, mglichst aufge-

deckt werden.
- Unter Sicherheitsgesichtspunkten sind auch nderungen in der Domnen- Domnenstruktur stabil
halten
struktur kritisch. Daher sind diese nur nach sorgfltiger Planung durchzu-
fhren. Es ist schon bei der initialen Planung zu bercksichtigen, dass eine
Windows 2000 Domnenstruktur (Aufteilung in Domnen, Trees, Forests)
nachtrglich nur wenige Vernderungen erlaubt.
- Auch unter Sicherheitsgesichtspunkten ist es wichtig, dass alle den Betrieb Regelungen
dokumentieren
eines Windows 2000 Systems betreffenden Richtlinien, Regelungen und
Prozesse dokumentiert werden. Dazu sollten Betriebshandbcher erstellt
werden, die auch bei Systemnderungen aktualisiert werden mssen. Da
die Betriebshandbcher sicherheitsrelevante Informationen enthalten, sind
sie so aufzubewahren, dass einerseits Unbefugte keinen Zugriff auf sie
erlangen knnen, jedoch andererseits fr befugte Administratoren ein
einfacher Zugriff besteht.
Die aufgefhrten Empfehlungen knnen an dieser Stelle nur allgemeinen
Charakter besitzen, da die Aufrechterhaltung der Systemsicherheit auch von
lokalen Gegebenheiten abhngt. Daher mssen schon in der Planungsphase
eines Windows 2000 Netzes entsprechende Richtlinien zum sicheren Betrieb
erstellt werden, die die lokalen Anforderungen bercksichtigen. Unter
Umstnden kann es auch vorkommen, dass gewisse Sicherheitsmechanismen
nicht optimal sicher konfiguriert werden knnen. Dies ist z. B. der Fall, wenn
"alte" Applikationen weiter betrieben werden mssen, die nur auf schwache
oder keine Authentisierung ausgelegt sind. Hier muss dann durch entspre-
chend ausgleichende Gegenmanahmen an anderer Stelle - oder auf organi-
satorischer Ebene - eine zufrieden stellende Sicherheit garantiert werden.
Die Sicherheit eines Windows 2000 Systems im laufenden Betrieb hngt dabei Administratoren schulen
auch wesentlich vom Kenntnisstand der Administratoren ab. Daher ist die
Schulung und Fortbildung der Systemverwalter eine wichtige Schutz-
manahme (siehe auch M 3.27 Schulung zur Active Directory-Verwaltung), da
potentielle Sicherheitslcken nur von kompetenten Administratoren entdeckt
bzw. vermieden werden knnen. Daneben mssen auch die normalen Benutzer
in Sicherheitsaspekten geschult werden (siehe auch M 3.28 Schulung zu
Windows 2000 Sicherheitsmechanismen fr Benutzer), damit potentielle
Gefahren bekannt sind und die zur Verfgung stehenden Sicherheits-
mechanismen richtig eingesetzt werden knnen.
- Sind alle Betriebsablufe dokumentiert?
- Findet eine regelmige Kontrolle der Systemprotokolldaten statt?
- Ist sichergestellt, dass nderungen am AD nur von berechtigten Benutzern
vorgenommen werden knnen?
- Ist der Zugriff auf alle Administrationswerkzeuge fr Benutzer unterbun-
den worden?
- Werden die Administratoren regelmig geschult?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.147 Sichere Nutzung von EFS unter Windows 2000

Unter Windows 2000 steht das Dateisystem EFS (Encrypting File System -
verschlsselndes Dateisystem) zur Verfgung, das die Verschlsselung
einzelner Dateien untersttzt, die dafr gekennzeichnet werden mssen. Die
Dateiverschlsselung mittels EFS basiert auf einem hybriden Mechanismus,
der asymmetrische und symmetrische Verschlsselungsverfahren gemischt
einsetzt:
- Zur reinen Datenverschlsselung wird ein schnelles symmetrisches Verfah-
ren benutzt. EFS setzt hier das DESX-Verfahren ein, eine abgewandelte
Form des DES-Algorithmus. Der dabei benutzte Schlssel (der sogenannte
File Encryption Key, FEK) wird zufllig erzeugt.
- Zur Verschlsselung des FEK wird das asymmetrische RSA-Verfahren
eingesetzt. Die Verschlsselung des FEK erfolgt mit dem ffentlichen
Schlssel des Benutzers, der die Datei verschlsselt. Damit kann der FEK
nur noch mit dem privaten Schlssel dieses Benutzers entschlsselt und
zum Entschlsseln der Dateiinhalte verwendet werden.
Alle zur Ver- oder Entschlsselung bentigten Schlssel werden von Hibernation Modus nicht
benutzen
Windows 2000 bei der Benutzung in einem Hauptspeicherbereich abgelegt,
der nicht in die Auslagerungsdatei verlagert wird. Dadurch soll gewhrleistet
werden, dass die Schlssel nicht kompromittiert werden knnen, wenn ein
unberechtigter Dritter Zugriff auf die Auslagerungsdatei erhlt. Kritisch ist
jedoch in diesem Zusammenhang die Verwendung des Ruhezustandes
(Hibernation Modus), da hier der gesamte Hauptspeicherbereich in eine Datei
gespeichert wird, die dann notwendigerweise auch das Schlsselmaterial ent-
hlt. Daher sollte der Ruhezustand bei Verwendung von EFS nicht benutzt
werden. Dies ist besonders bei Laptops wichtig.
Die Verschlsselung mittels EFS kann jeder Benutzer pro Datei oder Benutzer schulen
Verzeichnis einstellen. ber den korrekten Umgang mit EFS sollten die
Benutzer geschult werden, ebenso sind sie ber die potentiellen Schwchen
dieser Art der Verschlsselung zu informieren.
Durch die Nutzung von EFS wird ein Sicherheitsgewinn erzielt. Die Benutzer
sollten sich allerdings darber bewusst sein, dass trotz des Verschlsselns von
Klartextdateien ein Restrisiko besteht, dass die Daten der gelschten Klartext-
datei teilweise oder ganz wiederhergestellt werden knnen. Dazu ist jedoch
spezielle Software und der Zugriff auf die Festplatte des jeweiligen Rechners
notwendig.
Damit die mittels EFS verschlsselten Dateien beim Verlust des privaten
Schlssels nicht vollstndig verloren sind, erfolgt immer eine zustzliche
Verschlsselung des FEK mit dem ffentlichen Schlssel des so genannten
Wiederherstellungsagenten (englisch Recovery Agent). Dadurch ist eine
Entschlsselung der Daten auch unter dem Benutzerkonto des Wiederher-
stellungsagenten mglich. Prinzipiell kann ein beliebiges Benutzerkonto als
Wiederherstellungsagent eingesetzt werden. Als Standardvorgabe wird von
Windows 2000 das Administratorkonto genutzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Beim Einsatz von EFS ist Folgendes aus Sicherheitssicht zu beachten:

- EFS ist vllig transparent fr den Benutzer. Ein Benutzer bemerkt damit
jedoch auch keinen Unterschied zwischen verschlsselten und unver-
schlsselten Dateien. Daher ist besondere Aufmerksamkeit gefordert, dass
sensitive Dateien auch tatschlich verschlsselt werden.
- Aufgrund der Transparenz fr Benutzer ist der Schutz der EFS-Datei- starke
Benutzerpasswrter
verschlsselung so stark wie das Passwort des jeweiligen Benutzerkontos. verwenden
Kann sich ein unbefugter Dritter erfolgreich unter einem Benutzerkonto
anmelden, so kann er auch auf alle verschlsselten Dateien dieses Benut-
zerkontos zugreifen. Wird EFS eingesetzt, empfiehlt es sich, generell
starke Passwrter fr jedes Benutzerkonto zu benutzen. Da auch Windows
2000 es erlaubt, eigene Passwortfilter zu nutzen, kann auf diesen Mecha-
nismus zurckgegriffen werden, um die Verwendung starker Passwrter
technisch zu erzwingen.
- EFS ist eine Dateiverschlsselung und keine Ordnerverschlsselung. Aller-
dings kann ein Ordner zur Verschlsselung markiert werden, und es
werden dann alle im Ordner befindlichen Dateien oder auch Dateien, die
neu in einem solchen Ordner erzeugt werden, verschlsselt. Es ist jedoch
prinzipiell mglich, auch unverschlsselte Dateien in einem solchen
Ordner zu halten bzw. zu erzeugen. Verschlsselte Dateien knnen auer-
dem an jeder Stelle im Dateibaum existieren und sind damit nicht an
Ordner gebunden, die zur Verschlsselung gekennzeichnet sind.
- Das Verschlsselungsmerkmal ist ein Dateiattribut, das wie alle anderen
Dateiattribute behandelt wird, d. h. beim Verschieben von Dateien bleiben
die Dateiattribute unverndert. Dies fhrt dazu, dass Dateien, die in einen
Ordner verschoben werden, der fr die Verschlsselung gekennzeichnet ist,
nicht automatisch verschlsselt werden. Dieses Verhalten lsst sich fr den
Windows Explorer ber eine Gruppenrichtlinie steuern und damit abschal-
ten, so dass auch verschobene Dateien verschlsselt werden. Dies ist die
Voreinstellung. Allerdings gilt dies gilt nicht fr das Arbeiten unter der
Kommandozeile von Windows. Benutzer mssen auf die Gefahr hinge-
wiesen werden, dass Dateien in Ordnern, die fr die Verschlsselung
gekennzeichnet sind, auch unverschlsselt sein knnen.
- Obwohl EFS keine Ordnerverschlsselung ist, empfiehlt es sich, verschls- spezielle Ordner fr
verschlsselte Dateien
selte Dateien in speziellen Ordnern vorzuhalten bzw. Ordner fr die verwenden
Verschlsselung zu kennzeichnen. Dies erleichtert das Arbeiten mit
verschlsselten Dateien.
- Die Verschlsselung einer Datei bietet keine Zugriffskontrolle. Insbeson-
dere knnen verschlsselte Dateien durch Dritte auch gelscht werden,
falls die Zugriffsrechte dies erlauben. Neben der Verschlsselung einer
Datei mssen daher auch entsprechende Einstellungen fr die Zugriffs-
kontrolle vorgenommen werden.
- Damit EFS eingesetzt werden kann, muss immer ein Wiederherstellungs-
agent definiert sein. Es empfiehlt sich, dafr ein spezielles Konto anzu-
legen, das ausschlielich fr diesen Zweck genutzt wird. Insbesondere
sollte dafr kein Administratorkonto verwendet werden, um den Schutz vor
dem Administrator zu erhhen. In Abhngigkeit vom ermittelten Schutz-
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
bedarf sollte darber nachgedacht werden, fr die Benutzung des entspre-

chenden Kontos ein Vier-Augen-Prinzip einzufhren, z. B. durch Pass-
wortteilung.
- Die Nutzung eines separaten Wiederherstellungsagenten bietet keinen voll-
stndigen Schutz vor dem Administrator, da dieser immer das Passwort
eines Benutzer zurcksetzen kann, um sich nachfolgend als Benutzer
anzumelden und auf dessen verschlsselte Dateien zuzugreifen.
- Der private Schlssel des Wiederherstellungsagenten sollte vom System Vier-Augen-Prinzip fr
Recovery Agent
gelscht werden, nachdem er auf ein Speichermedium exportiert worden
ist. Das Speichermedium muss an einem sicheren Ort aufbewahrt werden.
Der Zugriff auf das Speichermedium sollte nach dem Vier-Augen-Prinzip
erfolgen. Es empfiehlt sich, eine gesondert und sicher aufbewahrte Siche-
rungskopie des Schlssels anzulegen.
- Das Sichern aller privaten Schlssel beim Einsatz von EFS ist wichtig. alle privaten Schlssel
sichern
Hierzu mssen alle Profil-Daten auf allen Rechnern, d. h. alle Verzeich-
nisse unterhalb von Dokumente und Einstellungen/<Benutzername>, die
auch alle Benutzerschlssel und Zertifikate enthalten, durch den Backup-
Mechanismus erfasst werden.
- Wird EFS ohne serverseitig gespeichertes Benutzerprofil (roaming profile)
eingesetzt, so werden in Abhngigkeit von unterschiedlichen lokalen
Profilen unterschiedliche Schlssel zum Ver- und Entschlsseln des FEK
benutzt, da diese im Profil eines Benutzer (verschlsselt) gespeichert
werden. In diesem Fall ist es wichtig, alle Schlssel zu sichern. Insbeson-
dere knnen verschlsselte Daten von einem Rechner, die auf Band
gesichert wurden, nicht auf einem anderen Rechner wieder eingespielt
werden, da eine erfolgreiche Entschlsselung aufgrund unterschiedlicher
Schlssel dann nicht mglich ist.
- Das Verschlsseln von Systemdateien (Dateien mit gesetztem System-
attribut) und komprimierten Dateien ist nicht mglich.
- Die Windows Boot-Datei autoexec.bat muss vor Verschlsselung autoexec.bat nicht
verschlsseln
geschtzt werden, indem fr Benutzer der Schreibzugriff unterbunden
wird, da sonst eine Denial-of-Service-Attacke mglich ist.
- Werden verschlsselte Daten mit Programmen, wie z. B. einem Texteditor,
bearbeitet oder gedruckt, so werden dabei in der Regel temporre Dateien
erzeugt, die dann Daten im Klartext enthalten. Diese knnen dann je nach
Programm auch nach der Bearbeitung weiter bestehen. Damit ist je nach
Speicherort, z. B. Temp-Verzeichnisse oder Spool-Bereich, und Zugriffs-
berechtigung auch ein Zugriff durch unautorisierte Dritte mglich.
- Um eine grere Sicherheit bei der Verarbeitung von EFS-verschlsselten
Dateien zu erreichen, sollte berlegt werden, ob es zweckmig ist, auch
Verzeichnisse, die typischerweise temporre Daten enthalten (Temp,
Spool), fr die Verschlsselung zu kennzeichnen. Es ist dabei zu berck-
sichtigen, welche Datenmengen in diesen Verzeichnissen abgelegt werden
und welche Programme diese Verzeichnisse nutzen. Bei sehr hufigen
Zugriffen auf groe Datenmengen kann dies zu einem Performanceverlust
fhren.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- EFS bietet derzeit ber die graphische Oberflche von Windows 2000
keine Mglichkeit an, Dateien so zu verschlsseln, dass verschiedene
Benutzer darauf zugreifen knnen. Generell ist es jedoch mit EFS mglich,
eine Datei fr eine ganze Liste von Benutzern zu verschlsseln. Dazu muss
allerdings auf die EFS Programmierschnittstelle (EFS-API) zurck-
gegriffen und ein entsprechendes Programm geschrieben werden.
- Mit EFS verschlsselte Daten werden auf dem Rechner ver- und entschls- EFS ist keine
Netzverschlsselung
selt, der die Daten gespeichert hat. Dies bedeutet insbesondere, dass Daten,
die auf einem Server verschlsselt gespeichert werden, beim Zugriff durch
einen Client im Klartext ber das Netz bertragen werden. Mssen die
Daten in Abhngigkeit vom ermittelten Schutzbedarf auch whrend der
bertragung geschtzt werden, so sind zustzliche Manahmen zur
Absicherung der Netzkommunikation erforderlich. Hierfr kann z. B. SSL
oder IPSec verwendet werden, siehe dazu auch M 5.90 Einsatz von IPSec
unter Windows 2000.
- Wird EFS fr lokale Benutzerkonten eingesetzt, so muss die Registry-
Verschlsselung mittels des Kommandos syskey unter Verwendung eines
Passwortes erfolgen. Nur so knnen die lokalen Kontenpasswrter vor dem
Zurcksetzen durch "Hacker-Werkzeuge" geschtzt werden.
EFS ist nur bei richtiger Anwendung eine kostengnstige Alternative zur
Dateiverschlsselung mit anderen Werkzeugen. EFS kann beispielsweise auf
Laptops eingesetzt werden, um die fehlende physikalische Sicherheit
auszugleichen, so dass Daten vor dem unbefugten Zugriff an den Betriebs-
systemmechanismen vorbei geschtzt werden knnen. Der Einsatz von EFS
ist jedoch nicht in jedem Fall zweckmig, so dass fr den jeweiligen Einsatz-
zweck entschieden werden muss, ob EFS benutzt werden soll.
- Wird die Nutzung von EFS im Datensicherungskonzept bercksichtigt?
- Sind die Benutzer im korrekten Umgang mit EFS geschult?
- Sind mit EFS verschlsselte Dateien zustzlich durch restriktive Zugriffs-
rechte geschtzt?
- Wurde ein dediziertes Konto fr den Wiederherstellungsagenten erzeugt
und dessen privater Schlssel gesichert und aus dem System entfernt?
- Wird die syskey-Verschlsselung mit Passwort verwendet, wenn EFS mit
lokalen Konten eingesetzt wird?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.148 berwachung eines Windows 2000 Systems

Die berwachung von Rechnersystemen ist ein wichtiges Mittel zur
Aufrechterhaltung der Systemsicherheit und Systemintegritt. Nur so knnen
mgliche Sicherheitslcken, Verste gegen die geltenden Sicherheitsricht-
linien oder gar Angriffe durch Auen- und Innentter entdeckt und geeignete
Gegenmanahmen eingeleitet werden.
Die berwachung eines Windows 2000 Systems muss schon in der Planungs-
phase bercksichtigt werden, damit die relevanten Parameter entsprechend den
Anforderungen festgelegt werden knnen. Damit unter Windows 2000 eine
berwachung erfolgen kann, muss diese zunchst generell aktiviert werden.
Dies gilt insbesondere fr die Datei- und Registry-berwachung. Die
Aktivierung und die Konfiguration der berwachungskomponenten erfolgt
dabei ber folgende Gruppenrichtlinienparameter:
- Allgemeine Aktivierung der berwachungsfunktionen:
Es knnen jeweils die Werte Keine berwachung oder Erfolgreich
und/oder Fehlgeschlagen eingestellt werden.
Computer Richtlinien / Lokale Richtlinien / berwachungsrichtlinien
Parameter Empfehlung
Prozessverfolgung ber- Die Prozessverfolgung ist im allgemeinen nicht
wachen sinnvoll und sollte nur fr Debugging-Zwecke
aktiviert werden.
Rechteverwendung ber- Die Verwendung von Benutzerrechten sollte
wachen berwacht werden.
Richtliniennderungen Das Verndern von Richtlinieneinstellungen
berwachen (GPOs) ist eine sicherheitskritische Operation
und sollte berwacht werden.
Systemereignisse berwa- Aktiviert die Protokollierung der Boot-
chen Ereignisse.
Anmeldeereignisse ber- Die Protokollierung der Anmeldeereignisse auf
wachen dem lokalen Rechner (z. B. Arbeitsplatzrechner)
sollte aktiviert sein.
Anmeldeversuche ber- Die Protokollierung der Anmeldeversuche auf
wachen dem Domnen-Controller, der die Authenti-
sierung des Benutzers durchfhrt, sollte aktiviert
sein.
Kontenverwaltung ber- nderungen in den Konteneinstellungen sind
wachen sicherheitskritische Ereignisse und sollten ber-
wacht werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Objektzugriff berwachen Diese Option sollte aktiviert werden, da hier-

durch die Protokollierung von Datei- und
Registry-Zugriffen mglich wird.
Active Directory Zugriff Dies ist nur auf Domnen-Controllern relevant.
berwachen nderungen am AD sollten berwacht werden.
- Einstellungen fr die Protokolldateien:
1. Computer Richtlinien / Lokale Richtlinien / Zuweisen von

Benutzerrechten
Parameter Empfehlung
Verwalten von berwachungs- Dieses Recht ermglicht
und Sicherheitsprotokollen
- die Konfiguration der Audit-Einstellun-
gen fr die einzelnen Objekte (Dateien,
Registry, Active Directory),
- das Ansehen bzw. Lschen des Sicher-
heitsprotokolls.
Welcher Benutzergruppe (bzw. -gruppen)
dieses Recht eingerumt wird, hngt vom
berwachungskonzept ab. Prinzipiell sollte
dieses Recht restriktiv vergeben werden. Es
sollte dabei jedoch beachtet werden, dass
- auch zur Diagnose und Behebung von
nicht sicherheitsrelevanten Problemen
der Zugriff auf das Sicherheitsprotokoll
notwendig sein kann,
- Administratoren sich dieses Benutzer-
recht auch selbst einrumen knnen,
wenn es ihnen entzogen wird. Es
empfiehlt sich daher, diesen Vorgang zu
protokollieren (Option Rechteverwen-
dung berwachen).
2. Computer Richtlinien / Lokale Richtlinien / Ereignisprotokoll

- Aufbewahrungsmethode des Je nach Protokollierungskonzept kann
Anwendungsprotokolls gewhlt werden zwischen
- Aufbewahrungsmethode des Nach ... Tagen,
Sicherheitsprotokolls
berschreiben und
- Aufbewahrungsmethode des
Nicht berschreiben.
Systemprotokolls
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Anwendungsprotokoll Anzahl der Tage, wenn die Aufbewah-

aufbewahren fr rungsmethode Nach ... Tagen gewhlt
wurde.
- Sicherheitsprotokoll
aufbewahren fr
- Systemprotokoll
aufbewahren fr
- Gastkontozugriff auf An- Die Zugriffsbeschrnkung fr das
wendungsprotokoll ein- Gastkonto sollte aktiviert werden.
schrnken
- Gastkontozugriff auf Sicher-
heitsprotokoll einschrnken
- Gastkontozugriff auf
Systemprotokoll
einschrnken
- Maximale Gre des Die Gre muss so gewhlt werden, dass je
Anwendungsprotokolls nach Aufbewahrungsmethode auch bei
berdurchschnittlicher Systemaktivitt
- Maximale Gre des Sicher-
gengend Platz zur Verfgung steht.
heitsprotokolls
Dies ist besonders wichtig fr das Sicher-
- Maximale Gre des
heitsprotokoll, da sonst eine zeitliche
Systemprotokolls
Lcke in der Sicherheitsberwachung des
Systems entstehen kann.
Vorschlge fr die hier vorzunehmenden
Einstellungen finden sich in M 2.231
Planung der Gruppenrichtlinien unter
Windows 2000. Diese mssen jedoch den
realen Bedingungen (Tests im Probe-
betrieb) angepasst werden.
System bei Erreichen der max. Im Normalbetrieb ist dies mit Vorsicht zu
Sicherheitsprotokollgre behandeln. Diese Option ist jedoch in
herunterfahren Hochsicherheitsbereichen sinnvoll, wenn
Nachweisfhrung vor Verfgbarkeit geht.
In jedem Fall muss der Einsatz genau
abgewogen werden.
Im Rahmen der berwachung sind allgemein auch folgende Aspekte zu
bercksichtigen:
- Der Datenschutzbeauftragte und der Personal- bzw. Betriebsrat sollten DS-Beauftragten und
Personalvertretung
frhzeitig in die Planung mit einbezogen werden, da bei einer ber- beteiligen
wachung meist auch personenbezogene Daten erfasst werden, um im Falle
einer Sicherheitsverletzung zuverlssig den Verursacher feststellen zu
knnen.
- Damit die berwachungskomponenten Protokolleintrge generieren, muss
die berwachung ber die relevanten Gruppenrichtlinieneinstellungen
aktiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Windows 2000 stellt zur berwachung lediglich eine Protokoll-Funktiona-

litt zur Verfgung: Systemkomponenten und Applikationen erzeugen
Statusmeldungen, die in drei Protokolldateien (System-, Applikations- und
Sicherheitslog) gesammelt werden. Eine dedizierte Auditing-Architektur
zur Online-berwachung existiert nicht. Die Protokolldateien werden
jeweils lokal gespeichert und mssen im Wesentlichen von Hand ausge-
wertet werden.
- Der Aufbau einer zentralen Sammelstelle von Protokolldateien mit entspre-
chend automatisierter Auswertung kann durch Produkte von Drittherstel-
lern erreicht werden. Wird ein Werkzeug zum Netz- und Systemmanage-
ment eingesetzt (siehe auch Baustein 6.8 Netz- und Systemmanagement),
so ist es - je nach Produkt - mglich, die Windows 2000 Protokolle direkt
in dieses Werkzeug zu importieren.
- ber die Windows 2000 Auditing-Einstellungen knnen Zugriffe auf
Dateien oder Registry-Schlssel im Sicherheitsprotokoll aufgezeichnet
werden.
- Durch die berwachung fallen je nach Einstellung groe Datenmengen an. berwachungsparameter
erst testen
Zustzlich fhrt eine intensive berwachung zu Performanceverlusten.
Dadurch kann im Extremfall ein System so berlastet werden, dass ein
geregelter Betrieb nicht mehr mglich ist. Aus diesem Grund mssen die
geeigneten berwachungsparameter im Rahmen eines Testbetriebes ber-
prft und gegebenenfalls angepasst werden. Es ist zu beachten, dass die
Anpassung auch Einfluss auf das gesamte berwachungskonzept haben
kann, da bestimmte berwachungsaufgaben nicht mehr durchfhrbar sind.
Dies gilt insbesondere dann, wenn zustzliche Produkte eingesetzt werden,
die hohe Anforderungen an die protokollierten Ereignisse stellen. Dies sind
z. B. Programme, die eine automatische Analyse der Protokolldaten auf
Verhaltensanomalien, etwa fr die Erkennung von Angriffen, durchfhren.
Im Rahmen der berwachung von Systemfunktionen empfiehlt sich auch die AD-Replikation
kontrollieren
regelmige Kontrolle der AD-Replikation, durch die Konfigurationsnde-
rungen weitergereicht werden. Dazu knnen einerseits AD-Werkzeuge, wie
repadmin.exe oder showreps.exe, genutzt werden, andererseits sollten das
ADS-Log (Active Directory Service) und das FRS-Log (File Replication
Service) auf Fehlermeldungen hin berprft werden. Fehler in der Replikation
haben meist zur Folge, dass Konfigurationsnderungen nicht berall durch-
gefhrt werden. Dadurch besteht die Gefahr, dass einem Benutzer ungeeignete
oder zu viele Rechte zugestanden werden.
- Wurde ein bedarfsgerechtes berwachungskonzept entworfen und umge-
setzt?
- Wurde die Mglichkeit zur Protokollierung aktiviert?
- Werden wichtige Systemereignisse protokolliert?
- Wurden berwachungseinstellungen fr wichtige Systemdateien und
Registry-Eintrge konfiguriert?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.149 Datei- und Freigabeberechtigungen unter

Windows 2000
Das Dateisystem von Windows 2000 ist die Weiterentwicklung des Windows
NT Dateisystems. Die Mechanismen zur Zugriffssteuerung unterscheiden sich
dabei kaum. Die folgende Tabelle gibt einen berblick der mglichen
Zugriffsrechte auf Dateien. Diese erlauben unter Windows 2000 eine wesent-
lich detailliertere Konfiguration, als dies unter Windows NT mglich ist.
Zugriffsrechte fr Ordner Zugriffsrechte fr Dateien

Ordner durchsuchen Datei ausfhren
Ordner auflisten Daten lesen
Attribute lesen Attribute lesen
Erweiterte Attribute lesen Erweiterte Attribute lesen
Dateien erstellen Daten schreiben
Ordner erstellen Daten anhngen
Attribute schreiben Attribute schreiben
Erweiterte Attribute schreiben Erweiterte Attribute schreiben
Unterordner und Dateien lschen
Lschen Lschen
Berechtigungen lesen Berechtigungen lesen
Berechtigungen ndern Berechtigungen ndern
Besitzrechte bernehmen Besitzrechte bernehmen
Die Zugriffrechte knnen dabei auf Dateien oder Ordner angewandt werden.
Im Rahmen der Rechtevererbung ist es mglich, dass Rechte eines Ordners an
Dateien und/oder Unterordner weitergereicht werden, so dass eine einfache
Mglichkeit besteht, die Zugriffsberechtigungen in einem ganzen Teildatei-
baum durch die nderung an einer Stelle zu wechseln. Das Weiterreichen,
d. h. das Vererben, an die Objekte in einem Verzeichnis kann gezielt durch
folgende sieben Einstellungen kontrolliert werden, die angeben, auf welche
Objekte die Zugriffsrechte angewandt bzw. vererbt werden sollen:
- Nur diesen Ordner
- Diesen Ordner, Unterordner und Dateien
- Diesen Ordner, Unterordner
- Diesen Ordner, Dateien
- Nur Unterordner und Dateien
- Nur Unterordner
- Nur Dateien
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Durch die Option Berechtigungen nur fr Objekte und/oder Container in

diesem Container bernehmen kann zudem erreicht werden, dass die Rechte
nicht rekursiv in den jeweiligen Unterbaum weitervererbt werden, sondern nur
auf die Objekte im aktuellen Verzeichnis.
Zur Steuerung der Rechtebernahme auf Objekte beim Einsatz des Verer-
bungsmechanismus stehen zwei weitere Optionen zur Verfgung:
- Das bernehmen vererbter Rechte kann fr Objekte mit der Option
Vererbbare bergeordnete Berechtigungen bernehmen erlaubt oder
blockiert werden.
- Das bernehmen vererbter Rechte durch Objekte im Unterbaum kann mit
der Option Berechtigungen in allen untergeordneten Objekten zurcksetzen
und die Verarbeitung vererbbarer Berechtigungen aktivieren erzwungen
werden.
Stehen die beiden Rechte in Konflikt miteinander, so wird die erzwungene
bernahme der vererbten Rechte durchgesetzt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Diese Flle an unterschiedlichen Dateiberechtigungen im Zusammenspiel mit

den unterschiedlichen Vererbungsmechanismen macht die Verwaltung von
Zugriffsrechten fr den Benutzer unbersichtlich. Im Normalfall empfiehlt
sich daher, nur die zusammengesetzten Standardzugriffsrechte zu verwenden:
Ordner Dateien entspricht

Vollzugriff Vollzugriff alle Einzelberechtigungen
ndern ndern Lesen, Ausfhren ergnzt um Lschen
Lesen, Ausfhren Lesen, Ausfhren Lesen ergnzt um Datei ausfhren
Ordnerinhalt auflisten -
Lesen Lesen Daten lesen, Attribute lesen, erweiterte
Attribute lesen, Berechtigungen lesen
Schreiben Schreiben Daten schreiben, Daten anhngen, Attri-
bute schreiben, erweiterte Attribute
schreiben
Im Rahmen der Planung des Windows 2000 Einsatzes ist auch das Zugriffs-
konzept fr Dateien und Ordner zu entwerfen, durch das die detaillierten
Zugriffsrechte festgelegt werden. Dabei sind die organisatorischen und
geschftlichen Anforderungen zu bercksichtigen. Generell empfiehlt es sich,
fr die Windows 2000 Systemdateien restriktive Rechte zu vergeben.
Als Ausgangskonfiguration knnen folgende Berechtigungsvorgaben genutzt
werden, die jedoch auf jeden Fall an die lokalen Gegebenheiten angepasst
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
werden mssen. Die vorgeschlagenen Einstellungen gehen davon aus, dass die
Benutzerkennung Hauptbenutzer (Power-User) nicht verwendet wird, da
administrative Belange durch Administratoren mit entsprechenden Berechti-
gungen im Rahmen des Administrationskonzeptes abgedeckt werden. Aus
diesem Grund ist die Kennung Hauptbenutzer aus allen Zugriffslisten zu
entfernen. Zustzlich empfiehlt sich im Rahmen des Administrationskonzeptes
eine Gewaltenteilung, so dass die administrativen Berechtigungen auf entspre-
chende Konten aufgeteilt werden. Im Folgenden wird jedoch davon ausgegan-
gen, dass jeweils die Gruppe Administratoren die gesamte administrative
Gewalt hat. Die Berechtigungen gelten nur fr die angegebenen Verzeichnisse
oder Dateien und sind nicht fr die Vererbung gedacht.
Verzeichnis Rechte
Stammverzeichnis der
System- Administratoren: Vollzugriff
partition SYSTEM: Vollzugriff
Benutzer: Lesen
\WINNT Administratoren: Vollzugriff
SYSTEM: Vollzugriff
ERSTELLER-BESITZER: Vollzugriff
Benutzer: Lesen, Ausfhren
WINNT\REPAIR Administratoren: Vollzugriff
WINNT\SYSTEM32\CONFIG Administratoren: Vollzugriff
SYSTEM: Vollzugriff
Benutzer: Lesen
WINNT\SYSTEM32\SPOOL Administratoren: Vollzugriff
SYSTEM: Vollzugriff
ERSTELLER-BESITZER: Vollzugriff
Benutzer: Lesen
Verzeichnis / Datei Rechte

boot.ini Administratoren: Vollzugriff
ntldr SYSTEM: Vollzugriff
autoexec.bat Administratoren: Vollzugriff
config.sys SYSTEM: Vollzugriff
Benutzer: Lesen
TEMP Administratoren: Vollzugriff
SYSTEM: Vollzugriff
Benutzer: ndern
PROGRAMME Administratoren: Vollzugriff
SYSTEM: Vollzugriff
Benutzer: Lesen, Ausfhren
Dokumente und Einstellungen Administratoren: Vollzugriff
SYSTEM: Vollzugriff
Benutzer: Lesen
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Bei einer Aktualisierung eines Windows NT Rechners auf Windows 2000

werden nicht die Windows 2000 Standardberechtigungen installiert, sondern
es werden die vorhandenen Einstellungen bernommen. Daher muss bei
solchen Systemen immer berprft werden, ob die Berechtigungen konform
zum entworfenen Berechtigungskonzept sind.
Auch Windows 2000 erlaubt es, Verzeichnisse und die darin enthaltenen
Dateien ber eine Freigabe fr den Netzzugriff zur Verfgung zu stellen.
Dabei erfolgt die Zugriffskontrolle zweistufig. Zum einen knnen Zugriffs-
berechtigungen auf die Netzfreigabe selbst eingerichtet werden, die bestim-
men, wer generell auf die Netzfreigabe zugreifen darf. Zum anderen greifen
die oben beschriebenen, auf Dateisystemebene angegebenen Zugriffsrechte
auf Dateien und Verzeichnisse. Berechtigungen auf Netzfreigaben knnen nur
ber die Rechte
- Vollzugriff
- ndern
- Lesen
gesteuert werden. Eine feinere Kontrolle ist jedoch an dieser Stelle nicht
notwendig.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Um Datei-, Verzeichnis- und Freigabeberechtigungen festzulegen, sollten

folgende Regeln beachtet werden:
- Freigaben durch Arbeitsplatzrechner sind zu vermeiden (siehe auch M 5.37 Freigaben durch APCs
und DCs vermeiden
Einschrnken der Peer-to-Peer-Funktionalitten in einem servergesttzten
Netz, die analog fr Windows 2000 gilt).
- Freigaben durch Domnen-Controller sind ebenfalls zu vermeiden, da
Domnen-Controller sensitive Daten speichern.
- Freigaben auf Arbeitsplatzrechnern und Domnen-Controllern sind zu
begrnden und zu dokumentieren und sollten nur nach einer vorherigen
Risikoabwgung erfolgen.
- Fr alle Freigaben und die dadurch zugreifbaren Daten mssen die
Zugriffsberechtigungen so restriktiv wie mglich vergeben werden.
- Das Zugriffskonzept muss dokumentiert sein.
- Wurde ein bedarfsgerechtes Berechtigungskonzept entworfen?
- Sind die Berechtigungen aller Verzeichnisse und Dateien auf allen aktuali-
sierten Rechnern berprft worden?
- Sind die eingestellten Datei- und Verzeichnisberechtigungen von freige-
gebenen Verzeichnissen fr den Netzzugriff geeignet?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.150 Konfiguration von Windows 2000 als

Workstation
Die Verwendung von Windows 2000 auf Arbeitsplatzrechnern stellt neben
den allgemeinen Sicherheitsanforderungen an die Grundkonfiguration von
Windows 2000 (siehe M 4.137 Sichere Konfiguration von Windows 2000)
auch spezifische, arbeitsplatzbezogene Sicherheitsanforderungen. Die auf
Arbeitsplatzrechnern eingesetzte Version ist in der Regel Windows 2000
Professional, das als Clientsystem mit Windows 2000 Servern und Domnen-
Controllern kommuniziert.
Fr die Konfiguration als Workstation sind folgende Aspekte aus Sicherheits-
sicht zu bercksichtigen:
- Es empfiehlt sich, keine lokalen Daten auf Arbeitsplatzrechnern zu halten. Lokale Daten vermeiden
Dies hat einerseits Vorteile bei der Datensicherung und bietet zudem den
Sicherheitsvorteil, dass bei Kompromittierung des Systems lokal keine
sensitiven Daten vorzufinden sind. Kann eine vorgefertigte Standardkon-
figuration eingesetzt werden, so ist im Fehlerfall sehr einfach eine Neuin-
stallation mglich, ohne dass dabei Rcksicht auf lokale Datenbestnde
genommen werden muss.
- In Einzelfllen kann es notwendig sein, dass Daten aus Sicherheitsgrnden
lokal auf dem Arbeitsplatz gespeichert werden mssen, da z. B. nur der
Arbeitsplatzbenutzer darauf zugreifen darf und eine bertragung ber das
Netz nicht erfolgen soll. In diesen Fllen ist der Arbeitsplatz jedoch nicht
als Standardarbeitsplatz anzusehen, so dass besondere Regelungen fr
diese Art Arbeitsplatz geplant und umgesetzt werden mssen. Beispiele fr
entsprechende Manahmen sind starke Absicherung sowohl lokal als auch
im Netz, Einsatz von Plattenverschlsselung und die Einbindung in das
Backup-Konzept.
- Ein Arbeitsplatzrechner sollte so konfiguriert sein, dass ein Benutzer keine Benutzer darf nicht
administrieren
administrativen Ttigkeiten ausfhren kann. Dies betrifft einerseits die
Zugriffsrechte auf Dateien und die Registry und andererseits die Berech-
tigung zum Starten der Konfigurationswerkzeuge, wie z. B. der MMC-
Konsole oder auch der Registry-Editoren. Diese Einstellungen knnen ber
Gruppenrichtlinien verwaltet werden, so dass dies bei der Planung der
Gruppenrichtlinien bercksichtigt werden muss (siehe M 2.231 Planung
der Gruppenrichtlinien unter Windows 2000).
- Falls auf einem Arbeitsplatz sensitive Daten verarbeitet werden, empfiehlt
es sich, regelmig Verzeichnisse, in denen temporre Dateien abgelegt
werden, wie Temp, Tmp und das Drucker-Spool-Verzeichnis, zu bereinigen
und auch die Auslagerungsdatei beim Herunterfahren des Systems zu
lschen. Nur so kann gewhrleistet werden, dass sensitive Informationen
oder Restinformationen nicht zufllig zugreifbar sind. Um das Lschen der
Auslagerungsdatei beim Herunterfahren zu aktivieren, muss die Einstel-
lung Auslagerungsdatei des virtuellen Arbeitsspeichers beim Herunter-
fahren des Systems lschen aktiviert werden. Diese findet sich unter
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen in der

Verwaltung der lokalen Sicherheitsrichtlinien oder aber in Gruppenricht-
linienobjekten unter Computerkonfiguration/Windows Einstellungen/
Sicherheitseinstellungen/Lokale Richtlinien/Sicherheitsoptionen.
- Windows 2000 erlaubt es, die Arbeitsoberflche eines Benutzers in ihrer Einschrnkung der
Oberflche kann
Funktionalitt einzuschrnken. Dies kann sehr detailliert durch entspre- umgangen werden
chende Konfiguration der Gruppenrichtlinien (GPO-Einstellung) gesche-
hen. Es ist dabei zu beachten, dass diese Einschrnkungen nicht als starke
Sicherheitsmechanismen anzusehen sind. So kann zwar das Starten von
nicht durch den Administrator freigegebenen Programmen ber eine GPO-
Einstellung fr den Windows Explorer verhindert werden. Dies stellt
jedoch nicht sicher, dass nicht freigegebene Programme nicht doch durch
andere Mechanismen gestartet werden knnen. Beispiele hierfr sind Start
durch den Taskmanager, von der Kommandozeile oder durch ein anderes
Programm.
- Im Rahmen des berwachungskonzeptes (siehe M 4.148 berwachung
eines Windows 2000 Systems), welches auch die Protokollauswertung
beinhaltet, sollten wichtige lokale Systemdateien und Registry-Schlssel
berwacht werden.
- Arbeitsplatzrechner sollten neben den administrativen Standardfreigaben Freigaben vermeiden
keine Verzeichnisfreigaben zur Verfgung stellen. Werden Daten nicht
lokal gehalten, so ist dies auch nicht notwendig. Werden Verzeichnis-
freigaben verwendet, mssen auch Netzzugriffe zugelassen werden, was
als potentielle Gefhrdung angesehen werden muss (siehe auch
M 5.37 Einschrnken der Peer-to-Peer-Funktionalitten in einem server-
gesttzten Netz).
- Es sollte verhindert werden, dass Benutzer auf Arbeitsplatzrechnern Soft-
ware installieren knnen.
- Wird ein Arbeitsplatzrechner in eine Domne integriert, so muss dies in der
Regel unter den Berechtigungen des Domnen-Administrators erfolgen.
Wird administrative Delegation eingesetzt, so muss dazu ein entsprechend
berechtigtes Konto benutzt werden.
- Fr Laptops bestehen besondere Gefahren durch die fehlende physikalische Laptops besonders
schtzen
Sicherheit. Hier mssen besondere Vorkehrungen getroffen werden (siehe
auch Baustein 5.3 Tragbarer PC). Windows 2000 bietet hier als zustz-
lichen Schutz von Daten die Verschlsselung von Dateien mittels EFS
(Encrypting File System) an. Hinweise zur sicheren Nutzung von EFS sind
in M 4.147 Sichere Nutzung von EFS unter Windows 2000.
Zusammenfassend muss darauf hingewiesen werden, dass die Sicherheit von
Arbeitsplatzrechnern direkten Einfluss auf die Sicherheit des Gesamtsystems
hat und dieser damit ein hoher Stellenwert zukommt.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Ist sichergestellt, dass auch lokal gehaltene Daten durch das Datensiche-
rungskonzept erfasst werden?
- Wurde der Arbeitsplatzrechner so konfiguriert, dass durch Benutzer keine
administrativen Ttigkeiten ausgefhrt werden knnen?
- Werden temporre Dateien und Verzeichnisse regelmig gelscht?
- Ist EFS fr alle Rechner, die Dateien verschlsselt vorhalten sollen,
aktiviert?
- Werden Zugriffe auf wichtige Systembereiche berwacht?
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
M 4.151 Sichere Installation von Internet-PCs

Bei der Installation des Internet-PC mssen eine Reihe von Entscheidungen
getroffen werden, die Auswirkungen auf die IT-Sicherheit des Systems haben.
Hardware
Die Hardware des Internet-PCs ist so zu konfektionieren, dass nur die im
Einsatzkonzept vorgesehenen Komponenten vorhanden sind. Gegebenenfalls
mssen nicht vorgesehene Laufwerke oder Schnittstellen, z. B. Diskettenlauf-
werke oder interne Modems, entfernt oder deaktiviert werden (siehe auch
M 4.4 Geeigneter Umgang mit Laufwerken fr Wechselmedien).
Die Boot-Reihenfolge sollte im System-BIOS so eingestellt werden, dass der
Computer immer zuerst versucht, von der Festplatte zu starten, z. B. C: A:,
C only oder Harddisk first/only.
Der Zugang zum System-BIOS sollte durch ein Passwort geschtzt werden. BIOS-Passwort
Falls ein Betriebssystem ohne zwingende Benutzer-Authentisierung zum Ein-
satz kommt, z. B. Windows 9x/ME, kann darber nachgedacht werden, auch
ein Boot-Passwort im BIOS zu aktivieren. Dies bietet einen gewissen Schutz
vor Missbrauch durch Gelegenheitstter.
Betriebssystem
Im Anschluss an die Installation der Hardware wird das im Einsatzkonzept
vorgesehene Betriebssystem installiert. Zu beachten ist dabei, dass gngige
Betriebssysteme unterschiedliche Sicherheitsfunktionen bieten. Windows NT/
2000 und Linux verfgen beispielsweise ber eine wirksame Benutzertren-
nung und Zugriffsrechte. Diese Funktionen stehen bei Windows 9x/ME nur
ansatzweise oder gar nicht zur Verfgung, sind jedoch wichtig fr die Tren-
nung von Administrator- und Benutzerbereichen.
Grundstzlich sollten nur die Betriebssystem-Komponenten installiert werden, nur bentigte
Komponenten
die auch wirklich fr den festgelegten Einsatzbereich bentigt werden. Beson- installieren
ders kritisch zu prfen sind hierbei "Dienste" (Windows) bzw. "Daemons"
(Linux). Ein Internet-PC sollte in der Regel keine Dienste im Internet anbieten
(siehe auch M 5.43 Sichere Konfiguration der TCP/IP-Netzdienste unter
Windows NT und M 5.72 Deaktivieren nicht bentigter Netzdienste).
Nach der Installation des Betriebssystems mssen alle evtl. vergebenen
Standardpasswrter gendert werden. Unter Linux betrifft dies insbesondere
das root-Passwort, sofern die verwendete Distribution hierfr ein Standard-
passwort vergibt.
Vor der Inbetriebnahme mssen alle aktuellen sicherheitsrelevanten Patches sicherheitsrelevante
Patches einspielen
bzw. Updates eingespielt werden. Fr Windows-Betriebssysteme sind ent-
sprechende Informationen auf den WWW-Seiten der Firma Microsoft
(www.microsoft.com) erhltlich. Falls Linux eingesetzt wird, sollte zunchst
beim Hersteller der verwendeten Distribution nach verfgbaren Patches und
Updates gesucht werden. Falls das Angebot des Herstellers unzureichend ist,
sollten weitere Quellen hinzugezogen werden, z. B. www.linuxdoc.org.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
Weitere Empfehlungen hierzu finden sich in M 2.35 Informationsbeschaffung

ber Sicherheitslcken des Systems und M 4.107 Nutzung von Hersteller-
Ressourcen.
Fr Windows-Betriebssysteme gelten darber hinaus folgende Empfehlungen:
- Das jeweils aktuelle Service Pack sollte eingespielt werden.
- Als einziges Netzprotokoll sollte TCP/IP installiert werden.
- An das TCP/IP-Protokoll fr den Internet-Zugang sollten keine Dienste
gebunden werden.
- Die Datei- und Druckerfreigabe sollte deaktiviert werden. Es sollten keine
Shares zur Verfgung gestellt werden.
- Bei Verwendung des Internet Explorers sollte unter Extras | Internetoptio-
nen | Verbindungen die Funktion Vor dem Whlen Systemsicherheit prfen
aktiviert werden, falls diese Option angeboten wird.
- Der Windows Scripting Host (WSH) sollte deinstalliert werden, wenn dies
bei der verwendeten Konfiguration mglich ist. Anderenfalls sollten die
dem WSH zugeordneten Dateitypen, beispielsweise .vbs und .js, einem
Editor zugewiesen werden.
- Der Microsoft Personal Web Server sollte deaktiviert, mglichst sogar
deinstalliert werden.
- Die automatische CD-ROM-Erkennung sollte deaktiviert werden (siehe
auch M 4.57 Deaktivieren der automatischen CD-ROM-Erkennung).
- Falls die verwendete Windows-Version eine Benutzertrennung untersttzt,
sollten alle nicht bentigten Benutzerkonten, z. B. Gast, deaktiviert oder
gelscht werden. Unter Windows NT kann dies ber den Benutzer-
Manager erfolgen. Das Administrator-Konto sollte umbenannt und mit
einem starken Passwort geschtzt werden.
- Beim Einsatz von Windows 9x/ME kann darber nachgedacht werden,
einen passwortgeschtzten Bildschirmschoner zu verwenden. Dies bietet
einen gewissen Schutz gegen unberechtigte Zugriffe.
- Als Standardvorgang beim Doppelklick auf eine Datei vom Typ .reg sollte
Bearbeiten (mit Editor ffnen) und nicht Zusammenfhren eingestellt
werden. Unter Windows ME kann das entsprechende Dialogfeld ber den
Explorer via Extras | Ordneroptionen | Dateitypen erreicht werden.
- Es sollte geprft werden, ob anstelle der Standardnamen fr System- und
Datenverzeichnisse bzw. -dateien abweichende Pfadnamen verwendet
werden knnen. Schadprogramme suchen in vielen Fllen nach bestimmten
Dateien in Standardverzeichnissen, so dass durch diese nderung ggf. ein
zustzlicher Schutz erreicht werden kann. Es ist jedoch zu bercksichtigen,
dass dies zu Inkompatibilitten mit bestimmten Programmen fhren kann.
Bei der Verwendung von Linux sollten folgende Empfehlungen bercksichtigt
werden:
- Der Daemon inetd sollte nicht gestartet werden. Je nach Distribution wird
dies ber nderungen an den rc-Startdateien oder ber spezielle Administ-
rationstools konfiguriert.
- Der Portmap Daemon und der Name Service Caching Daemon sollten
nicht gestartet werden.
- Falls die verwendete Distribution spezielle Dienste zur Fernadministration
installiert, z. B. linuxconf oder swat, so sollten diese deaktiviert werden.
___________________________________________________________________ ..........................................
___________________________________________________________________ ..........................................
- Apache oder andere WWW-Server-Software sollte deinstalliert werden.

- Das Programm sendmail sollte nicht im Server-Modus gestartet werden.
Auch andere Daemons fr den Empfang von E-Mail ber das Protokoll
SMTP sollten deinstalliert oder zumindest deaktiviert werden. Sofern
bentigt, sollte E-Mail stattdessen via POP3 oder IMAP abgeholt werden.
- Als zustzliche Sicherheitsmanahme gegen Angriffe aus dem Internet
kann die Paketfilterfunktion ipchains bzw. iptables von Linux eingesetzt
werden. Einige Distributionen enthalten hierfr vorkonfigurierte Pakete.
Als zustzliche Sicherheitsmanahme kann eine so genannte Personal Fire-
wall installiert werden. Damit diese auch wirksam ist, muss sie sorgfltig fr
den jeweiligen Einsatzzweck konfiguriert werden. Insbesondere muss das
Programm so eingestellt werden, dass die Benutzer nicht mit einer Vielzahl
von Warnmeldungen belstigt werden, die sie nicht interpretieren knnen.
Weitere Empfehlungen finden sich in M 5.91 Einsatz von Personal Firewalls
fr Internet-PCs.
Client-Programme
Neben dem eigentlichen Betriebssystem sollten auf dem Internet-PC nur die
zustzlichen Programme installiert werden, die fr die Nutzung der im
Einsatzkonzept festgelegten Internet-Dienste erforderlich sind.
Falls die Nutzung des World Wide Web im Einsatzkonzept vorgesehen ist,
muss ein WWW-Browser installiert werden. Gngige Browser-Programme
sind der Internet Explorer, Netscape Navigator und Opera. Empfehlungen zur
sicheren Konfiguration dieser Browser finden sich der Manahme M 5.93
Sicherheit von WWW-Browsern bei der Nutzung von Internet-PCs.
Falls vom Internet-PC aus E-Mails gesendet oder empfangen werden sollen,
muss entweder ein E-Mail-Client installiert werden oder es muss auf einen
WWW-basierten E-Mail-Dienst (z. B. GMX oder Web.de) zurckgegriffen
werden. Gngige E-Mail-Clients sind Outlook, Outlook Express, Netscape
Messenger oder KMail. Empfehlungen zur sicheren Konfiguration dieser
Programme finden sich in der Manahme M 5.94 Sicherheit von E-Mail-
Clients bei der Nutzung von Internet-PCs.
Falls im Einsatzkonzept vorgesehen ist, weitere Internet-Dienste zu nutzen,
z. B. News oder Instant Messaging, mssen ggf. weitere Client-Programme
installiert werden.
Alle Programme sollten so konfiguriert werden, dass sie optimale Sicherheit
bieten, und die Benutzer sollten in deren sichere Nutzung eingewiesen
werden.
Tools
Im Hinblick auf den sicheren Betrieb eines Internet-PCs mssen in der Regel
zustzliche Tools installiert werden, die nicht Bestandteil des Betriebssystems
sind.
Unverzichtbar ist der Einsatz eines Viren-Schutzprogramms auf jedem Inter- Viren-Schutz
net-PC. Solche Programme sind von verschiedenen Herstellern erh

Bundesamt Für Sicherheit in Der Informationstechnik

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Bundesamt Für Sicherheit in Der Informationstechnik

Загружено:

Авторское право:

Доступные форматы

Bundesamt fr Sicherheit in der Informationstechnik 2004

Das vorliegende IT-Grundschutzhandbuch enthlt Standardsicherheitsmanahmen, Umsetzungshin-

Dr. Udo Helmbrecht

- Gesamtkoordination Frau Isabel Mnch, BSI

Bei der Fortschreibung und Weiterentwicklung vorhergehender Versionen des IT-Grundschutz-

- ConSecur GmbH - Innenministerium des Landes

1 Wegweiser durch das 4 Infrastruktur

Kataloge zu Manahmen und

Neues in Version 2004 des IT-Grundschutzhandbuchs

- Steigender Vernetzungsgrad: IT-Systeme arbeiten heutzutage nicht mehr isoliert voneinander,

1 Wegweiser durch das IT-Grundschutzhandbuch

1.1 IT-Grundschutz: Ziel, Idee und Konzeption

1. Wegweiser durch das IT-

1.1 IT-Grundschutz: Ziel, Idee und Konzeption

Bei den im IT-Grundschutzhandbuch aufgefhrten Manahmen handelt es sich um Standardsicher-

1.2 Aufbau und Lesart des Handbuchs

Lesart des Handbuchs

Einige Manahmen werden mit dem Hinweis optional gekennzeichnet. Beispiel:

M 2.11 Regelung des Passwortgebrauchs

1.3 Anwendungsweisen des IT-Grundschutzhandbuchs

Erfahrungsaustausch mit den Anwendern des IT-Grundschutzhandbuchs. Kommentare und

1.4 Kurzdarstellung vorhandener Bausteine

3.8 Behandlung von Sicherheitsvorfllen

5.6 PC mit Windows 95

6.6 Novell Netware Version 4.x

7.11 Router und Switches

1.6 Informationsfluss und Kontakte

2 Anwendung des IT-Grundschutzhandbuchs

2 Anwendung des IT-

Die Kernaufgabe des IT-Sicherheitsmanagements bildet die Erstellung des IT-Sicherheitskonzepts, da

Abbildung: Erstellung eines IT-Sicherheitskonzepts

- die maximale Datenbertragungsrate (z. B. 10 Mbps),

Abbildung: Beispiel eines bereinigten Netzplans

Nr. Beschreibung Plattform Anzahl Aufstel- Status Anwender/Admin.

S1 Server fr Personalverwaltung Windows NT-Server 1 Bonn, R 1.01 in Betrieb Personalreferat

A6 E Xchange (E-Mail, Terminkalender) X X

Legende: Ai X Sj = Die Ausfhrung der IT-Anwendung Ai hngt vom IT-System Sj ab.

Die nachfolgenden Schritte erlutern, wie fr IT-Anwendungen die adquate Schutzbedarfskategorie

Schutzbedarfskategorie "niedrig bis mittel"

4. Beeintrchtigung der - Die Beeintrchtigung wrde von einzelnen Betroffenen als

Schutzbedarfskategorie "sehr hoch"

Individualisierung der Zuordnungstabelle

Schritt 2: Betrachtung von Schadensszenarien

Schadensszenario "Beeintrchtigung der persnlichen Unversehrtheit"

Schadensszenario "Beeintrchtigung der Aufgabenerfllung"

- fehlerhafte Produktion aufgrund falscher Steuerungsdaten und

Darstellung der Ergebnisse

Beispiel: Bundesamt fr Organisation und Verwaltung (BOV) - Teil 6

Interpretation der Ergebnisse der Schutzbedarfsfeststellung

Schutzwirkung von Standard-Sicherheitsmanahmen nach IT-Grundschutz

2.3 Modellierung nach IT-

Bild: Ergebnis der Modellierung nach IT-Grundschutz

Bild: Schichten des IT-Grundschutzmodells

- Aufgrund der Aufteilung der Sicherheitsaspekte in Schichten knnen Einzelaspekte in resultieren-

2.3.1 Modellierung eines IT-Verbunds

zu Schicht 2: Sicherheit der Infrastruktur

Bestehen mehrere unterschiedliche Einsatzbereiche von Mobiltelefonen (beispielsweise mehrere

Sicherheitsgateway-System eingesetzt wird. Beispiele sind Internet-Anbindungen, Remote Access-

7.5 WWW-Server S5 S5 dient als Server fr das Intranet.

2.3.2 Modellierung neuer IT-Komponenten

3. Raumstation (als Infrastruktur)

2.4.2 Durchfhrung des Soll-Ist-Vergleichs

"entbehrlich" - Die Umsetzung der Manahmenempfehlungen ist in der vorgeschlagenen Art