Konzept und Umsetzung eines versionsunabhängigen IT-Grundschutzbausteins am Beispiel von MS Exchange

Inhaltsverzeichnis

1. Einleitung
1.1. Motivation
1.2. Aufbau der Arbeit

2. Grundlagen
2.1. Definitionen und Begriffe
2.1.1. Groupware
2.1.2. Client-Anwendung (Client)
2.1.3. Server-Anwendung (Server)
2.1.4. Client-Server-System
2.1.5. Gefährdung
2.1.6. Risiko
2.2. Bundesamt für Sicherheit in der Informationstechnik (BSI)
2.3. Standards zu Informationssicherheit
2.3.1. BSI-Standards
2.3.1.1. BSI-Standard 100-1:Managementsysteme fürlnformationssicherheit(ISMS)
2.3.1.2. BSI-Standard 100-2:IT-Grundschutzvorgehensweise
2.3.13. BSI-Standard 100-3: Risikoanalyse aufder Basis von IT-Grundschutz
2.3.1.4. BSI-Standard 100-4:Notfallmanagement.
2.3.2. IT-Grundschutzkataloge
2.3.3. IT-Grundschutzbausteine
2.3.3.1. Gefährdungen
2.3.3.2. Maßnahmen
2.3.3.3. Lebenszyklusmodell.
2.3.3.4. Siegelstufen
2.3.4. Internationale Standards der ISO/IEC-27000-Reihe
2.3.4.1. ISO/IEC 27000
2.3.4.2. ISO/IEC 27001:2005
2.3.43. ISO/IEC 27002:2005
2.3.4.4. ISO/IEC 27005:2008
2.3.5. Weitere relevante Standards und Referenzen
2.4. Analysemethodik
2.4.1. Untersuchung versionsabhängiger IT-Grundschutzbausteine
2.4.1.1. Ausprägungen der Versionsabhängigkeit.
2.4.1.2. Existierende Lösungen für Versionsunabhängigkeit.
2.4.13. Versionsunabhängige Lösungsmöglichkeiten
2.4.2. Anforderungen an die Sicherheitsanalyse
2.4.2.1. Definition des Untersuchungsgegenstandes
2.4.2.2. Abgrenzung des Untersuchungsgegenstandes
2.4.2.3. Lebenszyklusmodell.
2.4.2.4. Gefährdungsanalyse aufBasis existierender Gefährdungskataloge
2.4.2.5. Neue Gefährdungen
2.4.2.6. Konsolidierung der Gefährdungslage
2.4.2.7. Bewertung derGefährdungslage
2.4.2.8. Maßnahmenentwicklung
2.4.2.9. Entwicklung der Prüffragen
2.4.2.10. Goldene Regeln
2.5. Grundlagen zu Microsoft Exchange
2.5.1. Aufbau und Funktionsumfang der Server-Anwendung
2.5.2. Versionshistorie des Microsoft-Exchange-Servers
2.5.2.1. MicrosoftExchange Server2003
2.5.2.2. MicrosoftExchange Server2007
2.5.2.3. MicrosoftExchange Server2010
2.5.3. Ausprägungen des Microsoft-Exchange-Servers
2.5.3.1. MicrosoftExchange 2003
2.5.3.2. MicrosoftExchange 2007
2.5.3.3. MicrosoftExchange 2010
2.5.4. Aufbau und Funktionsumfang der Client-Anwendung
2.5.5. Versionshistorie von Microsoft Outlook
2.5.5.1. Microsoft Outlook 2002
2.5.5.2. Microsoft Outlook 2003
2.5.5.3. Microsoft Outlook 2007.
2.5.5.4. Microsoft Outlook 2010
2.5.6. Ausprägungen von Microsoft Outlook

3. Versionsabhängigkeit der IT-Grundschutzbausteine
3.1. Ausprägungen der Versionsabhängigkeit
3.2. Zusammenfassung bisheriger Lösungen
3.3. Alternative Lösungsmöglichkeiten für den Bausteinentwurf

4. Sicherheitsanalyse zu Microsoft Exchange
4.1. Definition des Untersuchungsgegenstandes
4.1.1. Typisches Einsatzszenario
4.1.2. Abgrenzung gegenüber komplementären Microsoft-Produkten
4.1.3. Abgrenzung zu existierenden IT-Grundschutzbausteinen
4.1.3.1. Grundlegende IT-Grundschutzbausteine
4.1.3.2. Ergänzende IT-Grundschutzbausteine
4.1.3.3. Zuordnung zu einem Bausteinkatalog
4.1.4. Spezifikation des Untersuchungsgegenstandes
4.2. Sicherheitsbetrachtung
4.2.1. Lebenszyklusmodell
4.2.2. Gefährdungen
4.2.2.1. Aufnahme existierenderGefährdungen
4.2.2.2. Identifizierung neuer Gefährdungen
4.2.2.3. Konsolidierung und Bewertung der Gefährdungslage
4.2.3. Sicherheitsmaßnahmen
4.2.3.1. Aufnahme derSicherheitsmaßnahmen
4.2.3.2. Analyse der Sicherheitsmaßnahmen
4.2.3.3. Entwicklung der Prüffragen
4.2.4. Goldene Regeln aus der Sicherheitsanalyse
4.3. Zusammenfassung der Sicherheitsanalyse

5. Entwurf eines versionsunabhängigen
5.1. Anforderungen
5.1.1. Methodik
5.1.1.1. Das einfache Transformationsmodell (HB-VHF)
5.1.1.2. Das erweiterte Transformationsmodell (AB-HB-VHF)
5.1.2. Aufbauplanung
5.1.3. Zusammenfassung
5.2. Entwurfsphase
5.2.1. Entwurf der Gefährdungslage
5.2.2. Entwurf der Maßnahmenübersicht
5.2.3. Entwurf des Lebenszyklusmodells
5.2.4. Entwurf des IT-Grundschutzbausteins
5.2.5. Entwurf der „Goldenen Regeln“
5.2.6. Entwurf der versionsspezifischen Hilfsmitteldokumente
5.3. Zusammenfassung der Entwurfsphase

6. Evaluation des versionsunabhängigen
6.1. Untersuchung der Anforderungen
6.1.1. Evaluation des einfachen Modells (HB-VHF)
6.1.2. Evaluation des erweiterten Modells (AB-HB-VHF)
6.2. Bewertung und Empfehlung
6.2.1. Bewertung hinsichtlich der Gültigkeit
6.2.2. Bewertung aus Sicht der IT-Grundschutzanwender
6.3. Zusammenfassung der Evaluation

7. Fazit und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Anlagen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abstract

Groupware-Anwendungen - wie Microsoft Exchange - sind aus dem geschäftlichen Umfeld nicht mehr wegzudenken. Groupware beschleunigt indes nicht nur die Prozesse, sondern kann bei Betrei­bern und Diensteanbietern großen Schaden verursachen: Nichtverfügbarkeit des Systems oder Be­kanntwerden von vertraulichen Informationen sind hier prominente Beispiele. Nicht zuletzt die ge­setzlichen Anforderungen gemäß § 109 Telekommunikationsgesetz (TKG) zwingen den Betreiber von Kommunikationssystemen zur Abwehr von akuten Gefährdungen auf seine Daten und Infrastruktur.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet mit den BSI-Standards und den IT-Grundschutzkatalogen - zusammengefasst als „IT-Grundschutz“ - eine über die Grenzen Deutschlands hinweg akzeptierte Vorgehensweise für die Behandlung von allgemeinen und speziellen Gefährdungen an. Diese werden für typische Infrastrukturkomponenten und übergreifende Aspekte in Form der so-genannten IT-Grundschutzbausteine mit entsprechenden Maßnahmen angereichert. Die Bausteine werden in den IT-Grundschutzkatalogen kostenlos veröffentlicht und regelmäßig aktuali­siert.

Inhalt dieser Arbeit ist die Erstellung eines versionsunabhängigen IT-Grundschutzbausteins am Bei­spiel von Microsoft Exchange. Nach einer kurzen Vorstellung der Zusammenhänge von IT-Grund­schutz werden Microsoft Exchange und Microsoft Outlook betrachtet. Es werden die Anforderungen an einen neuen Baustein untersucht und Folgerungen für den Bausteinentwurf gezogen. Dabei wird besonderer Wert auf die Betrachtung von Versionsunterschieden und die Lösung des Problems der bisherigen Versionsabhängigkeiten innerhalb der IT-Grundschutzkataloge gelegt. Darauf aufbauend wird ein formales Verfahren zur Abstraktion und Konkretisierung bei der Bausteinerstellung entwi­ckelt, anhand dessen der Baustein für Microsoft Exchange schrittweise erarbeitet wird.

Als Ergebnis dieser Arbeit wird ein neuer versionsunabhängiger IT-Grundschutzbaustein „Microsoft Exchange / Outlook“ vorgestellt, der in einer nächsten Ergänzungslieferung zu den IT-Grundschutz- katalogen veröffentlicht wird.

Groupware such as Microsoft Exchange is indispensable in business life these days. Groupware does not only accelerate processes but can also cause a lot of damage to operators and service providers. Good examples of this are unavailable systems or the leaking of confidential data. Paragraph 109 of the telecommunications law forces operators of communication systems to protect their data and infrastructure from acute danger.

The German Federal Office for Information Security offers recommendations for a secure use of in­formation technology known as the IT-Grundschutz Methodology. Apart from providing guidelines for the implementation of a structured security process, it also provides specific advice for securely operating standard systems and applications. A module is offered for each system which introduces the system itself, shows common threats and presents recommended security safeguards. These mod­ules are published in IT-Grundschutz Catalogues and are updated on a regular basis.

This thesis describes the creation of version independant modules such as the module for Microsoft Exchange. Starting with an introduction to the IT-Grundschutz Methodology and a short presentation of Microsoft Exchange and Microsoft Outlook, the requirements for a module are discussed and con­clusions for module design are drawn. Particular attention is paid to the differences between version independent modules and a solution found for the problems of version dependent modules in the IT Grundschutz Catalogue. Further a formal method for the development of generic and detailed technical recommendations is presented, based on which the module Microsoft Exchange is compiled step-by-step.

The result of this thesis is a version independant module „Microsoft Exchange / Outlook“. It will be published in one of the next supplements of the IT-Grundschutz Catalogues.

1. Einleitung

Nahezu alle Geschäftsprozesse werden mittlerweile digital unterstützt und elektronisch gesteuert. Die fortlaufend anfallenden Informationen werden dabei gespeichert, verarbeitet und in privaten und öf­fentlichen Netzen übermittelt. Daraus ergibt sich die direkte Abhängigkeit zu vielen behördlichen oder privatwirtschaftlichen Aufgaben und Vorhaben, die ohne Informationstechnik (IT) nur sehr einge­schränkt durchgeführt werden können oder völlig zum Erliegen kommen. Deshalb können die origi­nären Behörden- und Unternehmensziele nur bei ordnungsgemäßem und sicherem IT-Einsatz erfüllt werden.

Microsoft Exchange setzt bei der digitalen Unterstützung und Steuerung von wichtigen Geschäftspro­zessen auf. Die Studie „Microsoft Exchange Server & Outlook Market Analysis, 2009-2013“ von der Radicati Group prognostiziert eine Verbreitung von 241 Millionen Microsoft-Exchange-Installationen bis Ende 2009 und eine Wachstumsrate in diesem Marktsegment von 11 % pro Jahr bis 2013 [REA09]. Nach [QUA06], [RAD07] und [STE09] ist Microsoft Exchange eines der führenden Kom- munikations-, Koordinations- und Kollaborationssysteme auf dem Markt.

Es existieren verschiedene Schwachstellen in Software, Betriebssystemen und Hardware, die in immer kleineren zeitlichen Zyklen beispielsweise durch Exploits zur Spionage ausgenutzt werden [SAN07], [END08]. Daraus erwächst ein Grundbedürfnis zum Schutz der verarbeiteten Daten, denn beim Ein­satz von Microsoft Exchange kommen diese unterschiedlichen Faktoren zusammen. Es besteht des­halb berechtigtes Interesse daran, die sensiblen Daten (Assets) zu klassifizieren und adäquat, d. h. an­gemessen im Sinne von effektiv bzw. effizient, zu schützen sowie die Sicherheit der IT zu planen, zu realisieren und zu kontrollieren.

Über die rein technischen Objekte, wie beispielsweise IT-Systeme, hinaus werden die organisatori­schen und personellen Rahmenbedingungen betrachtet, da Informationssicherheit nicht nur eine Frage der Technik ist. Dabei sind Betriebsumgebungen, Einsatzszenarien, die Verlässlichkeit von Dienst­leistungen, der richtige Umgang mit zu schützenden Informationen und viele andere wichtige Aspekte zu berücksichtigen [BSI08B]. Zu den schützenswerten Informationen gehören über die elektronischen Dokumente hinaus auch Papierdokumente und sonstige nicht digitalisierte Informationsträger.

Daraus ergibt sich der Bedarf zum Aufbau eines Managementsystems für Informationssicherheit (ISMS). Hierbei ist IT-Grundschutz eine anerkannte Methodik sowie eine Vorgehensweise, um Infor­mationsverbünde über Standardsicherheitsmaßnahmen abzusichern. Ziel des IT-Grundschutzes ist es, einen angemessenen Schutz für alle IT-gestützten Geschäftsprozesse und Informationen einer In­stitution zu erreichen. Dazu werden die IT-Grundschutzkataloge mit entsprechenden Gefährdungen und Sicherheitsmaßnahmen veröffentlicht.

Die IT-Grundschutzkataloge müssen ständig weiterentwickelt werden, um dem aktuellen Stand der Informationstechnik zu entsprechen. Dazu werden regelmäßig Bausteine zu neuen, aktuellen Themen veröffentlicht. Ziel eines jeden IT-Grundschutzbausteins ist es, die für das jeweilige Themengebiet spezifischen Gefährdungen und Maßnahmen zu identifizieren.

Diese Arbeit widmet sich der Entwicklung eines Modells zur Erstellung von versionsunabhängigen IT-Grundschutzbausteinen. Dabei ist insbesondere das Problem der bisherigen Versionsabhängig­keiten auf inhaltlicher, struktureller und formaler Ebene innerhalb der IT-Grundschutzkataloge zu lösen.

Am Beispiel von Microsoft Exchange Server und Outlook - einschließlich der Version 2010 - wird dieses neue Entwicklungsmodell angewandt und bewertet werden.

1.1. Motivation

Sowohl im behördlichen Umfeld als auch im privatwirtschaftlichen Bereich hat sich IT-Grundschutz als Standardreihe zur Informationssicherheit in Deutschland und anderen Ländern etabliert. Unter­nehmen und Behörden aller Größenordnungen verwenden die IT-Grundschutzkataloge als Hilfsmittel bei der Konzeption, Realisierung und Revision von Standardsicherheitsmaßnahmen. Über 1200 registrierte IT-Grundschutzanwender verzeichnete das Bundesamt für Sicherheit in der Infor­mationstechnik Ende 2008 [BSI08F].

In der Evolution der IT-Grundschutzkataloge [BSI08GS] wurden Anregungen und Bedürfnisse der IT-Grundschutzanwender aufgenommen und in den Ergänzungslieferungen, basierend auf Analysen der Marktrelevanz und Nachfrage, veröffentlicht. Die Entwicklungen zeigen, dass die Veröffentli­chung der IT-Grundschutzkataloge mit entsprechenden spezifischen Bausteinen und dem Release­Zeitpunkt von Anwendungen oder Betriebsystemversionen weit auseinander liegt oder zu Nachfolge­versionen keine Bausteine veröffentlicht werden. Darüber hinaus vergeht im ungünstigsten Fall bis zu ein Jahr, bis eine Aktualisierung der IT-Grundschutzkataloge erfolgen kann, wenn die Änderung direkt nach dem Redaktionsschluss vorgenommen wird.

Die Grundschutz-Vorgehensweise sieht zwar die Anpassung von existenten Bausteinen für neue Software innerhalb der Modellierung oder der Risikoanalyse vor, jedoch ist das Umstrukturieren eines Bausteins bei signifikanten Änderungen aufwendig. Damit existieren Ansätze zur Unabhängigkeit der Bausteine von Release-Terminen und Herstellern, die eine weitergehende Analyse und eine ein­heitliche Methodik zum Aufbau von versionsunabhängigen Bausteinen offen lässt.

Die Bedürfnisse der IT-Grundschutzanwender gehen allerdings auch in weitere Betrachtungen mit ein: Die Versionsabhängigkeit erstreckt sich von der Bausteinebene über die konkreten Maßnahmen bis hin zu speziellen Gefährdungen der entsprechenden Produkte. Auch hier ist eine Analyse der vor­liegenden Gefährdungen sinnvoll und die Auflösung und Umstrukturierung vor dem Hintergrund ei­ner effizienten Risikoanalyse notwendig.

Nicht zuletzt stehen die Autoren von neuen IT-Grundschutzbausteinen bei jedem Versionswechsel ei­nes Produktes vor der grundlegenden Auseinandersetzung mit dem Thema IT-Grundschutz. Mit den Ansätzen zur Versionsunabhängigkeit innerhalb der IT-Grundschutzbausteine sollen Autoren die Möglichkeit zur effizienten versionsabhängigen Spezialisierung außerhalb von bestehenden Baustei­nen erhalten.

Die steigende Nachfrage nach einer Neuauflage des existierenden IT-Grundschutzbausteins B5.12 Exchange 2000 / Outlook 2000 und die Komplexität der Analyse von mehreren zwischenzeitlichen Generationen der Software sind die Ausgangspunkte für die erneute Auseinandersetzung mit dem Thema Microsoft Exchange. Der Umstand, dass sich Microsoft Exchange 2000 seit knapp vier Jahren nicht mehr innerhalb der Gewährleistungsfristen befindet [MIC06A], lässt eine Sicherheitsbetrachtung der aktuellen Lage sinnvoll erscheinen. Bei Microsoft Outlook 2000 sind mittlerweile ebenfalls die Gewährleistungsfristen abgelaufen [MIC05].

1.2. Aufbau der Arbeit

Am Beispiel von Microsoft Exchange und Outlook wird ein Modell zur versionsunabhängigen Erstellung von IT-Grundschutzbausteinen entwickelt. Dabei werden bestehende Lösungen für eine Versionsunabhängigkeit identifiziert und bewertet, neue Vorschläge erarbeitet sowie anhand des neuen Bausteins zu Microsoft Exchange / Outlook evaluiert.

Die vorliegende Arbeit gliedert sich in einen Grundlagenteil, der in Kapitel 2 in relevante Standards der Informationssicherheit und Microsoft Exchange / Outlook einführt. Insbesondere werden das The­ma IT-Grundschutz und methodische Grundlagen für die Sicherheitsanalyse beleuchtet.

Hierbei werden auch der Aufbau der IT-Grundschutzbausteine und grundlegende Architekturen einer Exchange-Umgebung vorgestellt. Die Grundlagen umfassen weiterhin die Client-Komponente Micro­soft Outlook und die spezifischen Erweiterungen und Neuerungen von Microsoft Exchange / Outlook seit der Version 2000.

Im Anschluss an den Grundlagenteil wird in Kapitel 3 die Versionsabhängigkeit von IT-Grundschutz- bausteinen diskutiert und mehrere Lösungsmöglichkeiten für eine Abstraktion von versionsspezifi­schen Maßnahmen und Gefährdungen gegenübergestellt. Dabei werden sowohl bereits etablierte bzw. veröffentliche Möglichkeiten, vorwiegend aber neue Lösungen, die aus dieser Arbeit hervorgehen, be­trachtet.

Die Sicherheitsbetrachtung (Kapitel 4) eröffnet auf Basis der methodischen Grundlagen die Ist-Analy­se der vorgestellten Microsoft-Exchange-Szenarien. Hierbei finden grundsätzliche Abgrenzungen und Schnittstellenuntersuchungen bereits existierender Bausteine statt. Jeweils zu Server- und Client­Komponenten wird anschließend das spezifische Lebenszyklusmodell erarbeitet und mit entsprechen­den Maßnahmen und Gefährdungen verknüpft. Neben der Herausarbeitung der Versionsunterschiede auf Maßnahmen- und Gefährdungsebene werden die Lizenzmodelle und Produktvariationen der Microsoft-Exchange- und Outlook-Komponenten analysiert und eingearbeitet.

Auf Basis der Lösungsvorschläge und der Sicherheitsanalyse wird in Kapitel 5 die Vorgehensweise zur Erstellung versionsunabhängiger IT-Grundschutzbausteine erarbeitet und am Beispiel von Micro­soft Exchange umgesetzt. Die Bewertung der Lösung wird in Kapitel 6 vorgenommen.

Zum Abschluss (Kapitel 7) werden die neuen Teile der Arbeit zusammengefasst und die Relevanz auf die zukünftige Entwicklung des IT-Grundschutzes diskutiert.

2. Grundlagen

Der Grundlagenteil befasst sich mit den formalen Hintergründen und den Standards zur Informations­sicherheit, die insbesondere Grundlage für die Methodik zur Erstellung eines neuen IT-Grundschutz- bausteins im Rahmen der Sicherheitsanalyse sind. Dabei werden die BSI-Standards des Bundesamtes für Sicherheit in der Informationstechnik sowie die dazugehörigen IT-Grundschutzkataloge vorgestellt und in Beziehung zu anderen wichtigen Standards, wie der Normenreihe 27000 der International Organization for Standardization (ISO) gesetzt. Weiterhin werden die Grundlagen und Komponenten von Microsoft-Exchange-Systemen versionsabhängig gegenübergestellt.

2.1. Definitionen und Begriffe

Bevor sich diese Arbeit der eigentlichen Sicherheitsanalyse annehmen kann, werden die für die weite­ren Betrachtungen wesentlichen Begrifflichkeiten definiert.

2.1.1. Groupware

Im Fokus von Groupware liegt die Unterstützung von Gruppen bei der Zusammenarbeit, bei der Ter­minabstimmung, -Koordination sowie bei der täglichen Kommunikation [EGR91]. Für weitere Defi­nitionen und Abgrenzungen zum Thema Groupware sei auf [TEU95], [TEN99] und [SL07] verwie­sen.

2.1.2. Client-Anwendung (Client)

Ein Client fragt Dienste von einem Server innerhalb eines Netzes ab. Ein Client ist typischerweise eine Anwendung, die auf einer Workstation bzw. Arbeitsplatz-PC zusammen mit anderen Program­men ausgeführt wird. Eine Workstation wird ebenfalls Client genannt.

2.1.3. Server-Anwendung(Server)

Ein Server ist eine logische Einheit, die einen bestimmten Dienst anbietet. Ein Dienst wird typischer­weise von einem Client über ein Netz nachgefragt und von einem Server bedient. Ein Server ist wei­terhin an ein Betriebssystem gebunden, das wesentliche Basisdienste anbietet. Innerhalb eines Be­triebssystems können mehrere Serverdienste ausgeführt und verwaltet werden. Das Betriebssystem wird auf einer physikalischen oder virtualisierten Hardware, die ebenfalls Server genannt wird, betrieben.

2.1.4. Client-Server-System

Ein Client-Server-System ist ein Kommunikationssystem, welches aus mindestens einem Server und einem oder mehreren vernetzten Clients besteht. Die Vernetzung ist dabei so realisiert, dass eine Kommunikation der Clients mit dem Server über offene oder proprietäre Protokolle innerhalb eines Netzes möglich ist, auf dessen Basis alle beteiligten Server und Clients miteinander kommunizieren. Ein System kann dabei mehrere Protokolle unterstützen und damit Kopplungen zwischen mehreren standardisierten Systemen ermöglichen.

2.1.5. Gefährdung

Eine Gefährdung Gi ist definiert als mindestens eine Bedrohung T¡ (Threat), für die mindestens eine Schwachstelle V¡ (Vulerability) existiert [BSI09o]. G¡ ist nicht gegeben, wenn eine entsprechende Si­cherheitsmaßnahme M¡ bezogen auf Gi erfolgreich wirkt (Abbildung 1). Eine Bedrohung T¡, die keine Schwachstelle ausnutzen kann, ist vernachlässigbar. Für eine Bedrohung T2, die eine Schwachstelle ausnutzen kann, besteht zumindest ein kalkuliertes Restrisiko in den Fällen, in denen entsprechende Sicherheitsmaßnamen umgesetzt sind. Bei fehlenden oder unzureichenden Sicherheitsmaßnahmen kann eine Bedrohung T3 entsprechende Schwachstellen V¡ ausnutzen und die Grundwerte Verfügbarkeit, Vertraulichkeit sowie Integrität kompromittieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Zusammenhang zwischen Bedrohung, Schwachstelle, Gefährdung und Maßnahme

2.1.6. Risiko

Ein Risiko R¡ ist eine Gefährdung Gi, deren Eintrittswahrscheinlichkeit Wgi und Auswirkung Igi für eine konkrete Institution bzw. Organisation 0¡ festgelegt und bewertet ist. Im Weiteren wird daher nicht von Risikoanalyse für eine konkrete 0i, sondern von allgemeinen Gefährdungen für den konkre­ten Untersuchungsgegenstand Uy gesprochen, der unabhängig von Oi ist.

2.2. Bundesamt für Sicherheit in der Informationstechnik (BSI)

Das BSI wurde am 1. Januar 1991 per Errichtungsgesetz [BSIG90] gegründet und ist eine Bundes­oberbehörde, die dem Bundesministerium des Innern untersteht. Als Behörde ist sie im Vergleich zu sonstigen europäischen Einrichtungen einzigartig, da hier die verschiedensten Aspekte der Informati­onssicherheit in einem Bundesamt zusammengefasst wurden [BUND09].

Das BSI hat eine besondere Aufgabe im Bereich der Informationssicherheit: Das BSI ist der zentrale IT-Sicherheitsdienstleister der Bundesverwaltung in Deutschland. Durch die Grundlagenarbeit im Be­reich der Informationssicherheit übernimmt das BSI Verantwortung für die Gesellschaft und ist somit eine tragende Säule der inneren Sicherheit in Deutschland.

Das BSI setzt sich verantwortungsvoll mit allen Fragen der Informationssicherheit auseinander:

Neben der Untersuchung und Bewertung bestehender Sicherheitsrisiken schätzt das BSI vorausschauend die Auswirkungen neuer Entwicklungen ab. Auf Grundlage dieses Wissens bietet das BSI vorwiegend der Bundesverwaltung, aber auch Bürgern, Dienstleistungen in den vier Kernberei­chen Information, Beratung, Entwicklung und Zertifizierung an.

Mit der rasanten Weiterentwicklung der Informationstechnik ist es eine selbstverständliche Aufgabe des BSI, sich mit den neu entstehenden Sicherheitslücken zu befassen. Im Bereich Information wer­den alle wichtigen Themen rund um Informationssicherheit aufbereitet und im Onlineangebot sowie in Form von Broschüren, Büchern und sonstigen Veröffentlichungen der Allgemeinheit zur Verfü­gung gestellt. Die Beratungsdienstleistungen des BSI gehen für behördliche und sonstige IT-Anwend- ergruppen von Fragen der Sicherheit in der Informationstechnik bis hin zur Unterstützung bei der Um­setzung konkreter Sicherheitsmaßnahmen. Zu den Zielgruppen gehören neben ΓΓ-Herstellern, Daten­schutzbeauftragten und Gutachtern auch Rechnungshöfe, Forschungseinrichtungen, Prüfstellen und Normungsgremien. Das BSI führt Prüfungen und Bewertungen der Informationssicherheit von IT- Systemen durch, einschließlich deren Entwicklung in Kooperation mit der Industrie. Mit der Zertifi­zierung prüft das BSI IT-Systeme hinsichtlich ihrer Sicherheitseigenschaften. Die Zulassung von IT- Systemen für die Verarbeitung geheimer Informationen gehört ebenfalls zu den Aufgaben [BSI09A], [AUG09].

„Die heutigen informationstechnischen Systeme bieten nach wie vor nur ungenügende Sicherheit, und die Frage nach der Verletzlichkeit unserer industriellen Gesellschaft durch Computerversagen, -mißbrauch oder -sabotage stellt sich immer dringlicher.

Auch bei technisch sicheren Informations- und Telekommunikations-Systemen können Risiken und Schäden durch unzureichende Administration und Anwendung entstehen“ [BUND09].

2.3. Standards zu Informationssicherheit

Im Bereich der Informationssicherheit haben sich verschiedene nationale und internationale Standards durchgesetzt, die z. T. zielgruppen- oder themenorientiert aufgebaut sind. Beispiele für unterschiedli­che Zielgruppen sind Topmanagement, IT-Sicherheitsbeauftragte, IT-Fachkräfte und Administratoren. Der Einsatz von Standards in Unternehmen und Behörden verbessert nicht nur das Sicherheitsniveau, sondern erreicht auch die Konsolidierung und Abstimmung zwischen verschiedenen Organisationen darüber, welche Sicherheitsmaßnahmen inwelcher Form umzusetzen sind [BSI08-1001], [WIK09t].

2.3.1. BSI-Standards

Mit dem IT-Grundschutz bietet das BSI eine pragmatische Methode an, um alle Geschäftsprozesse mit ihren Daten angemessen zu schützen.

Die BSI-Standards enthalten Empfehlungen des BSI zu Methoden, Prozessen und Maßnahmen mit Bezug zur Informationssicherheit. Das BSI greift dabei Themenbereiche auf, die für die Informations­sicherheit in Behörden oder Unternehmen relevant sind und für die sich national oder international sinnvolle und zweckmäßige Methoden (2.3.4) etabliert haben.

2.3.1.1. BSI-Standard 100-1: Managementsysteme fürlnformationssicherheit (ISMS)

Der BSI-Standard 100-1 [BSI08-1001] definiert allgemeine Anforderungen an ein ISMS und ist voll­ständig kompatibel zum ISO-Standard 27001 (2.3.4). Darüber hinaus werden die Empfehlungen der anderen ISO-Standards der ISO-2700x-Reihe, wie beispielsweise ISO 27002, kontinuierlich weiter eingearbeitet und auf Konformität geprüft. [BSI08-1001] bietet mit einer leicht verständlichen und systematischen Einführung und Anleitung in das Thema Informationssicherheit einen unverbindlichen Einstieg in ISMS.

Das BSI stellt den Inhalt der ISO-Standards in einem eigenen BSI-Standard dar, um einige Themen ausführlicher behandeln zu können und so eine eingängige Darstellung der Inhalte zu ermöglichen. Weiterhin ist der BSI-Standard 100-1 so gestaltet, dass dieser zur IT-Grundschutzvorgehensweise im BSI-Standard 100-2 analog verläuft. Durch die vereinheitlichte Struktur in beiden Dokumenten ist eine leichte Orientierung möglich [BSI09B].

2.3.1.2. BSI-Standard 100-2:IT-Grundschutzvorgehensweise

Die IT-Grundschutzvorgehensweise wird im BSI-Standard 100-2 [BSI08-1002] erläutert. Dieser be­schreibt schrittweise, wie ein ISMS praxisorientiert aufgebaut, dokumentiert, etabliert und betrieben werden kann. Dabei bieten die Aufgaben des Sicherheitsmanagements und der adäquate Aufbau von Organisationsstrukturen für Informationssicherheit, wie beispielsweise ein Sicherheitsmanagement­team und ein IT-Sicherheitsbeauftragter, den Einstieg in das Thema. Die IT-Grundschutzvorgehens­weise beschreibt den Prozess der Erstellung und Umsetzung des Sicherheitskonzepts in der Praxis. Weiterhin beschäftigt sich der Standard mit der Aufrechterhaltung und Verbesserung der Informati­onssicherheit im laufenden Betrieb.

Der IT-Grundschutz unterstützt die Anwender bei der Umsetzung mit vielen Hinweisen, Hintergrund­informationen sowie Beispielen und konkretisiert dabei die sehr allgemein gehaltenen Anforderungen der ISO-Standards der 2700x-Reihe (2.3.4). Die IT-Grundschutzvorgehensweise wird anhand der IT- Grundschutzkataloge (2.3.2) weiter erklärt und über konkrete Hinweise, die auch auf technischer Ebene Sicherheitsmaßnahmen empfehlen, vertieft [KIL07].

2.3.1.3. BSI-Standard 100-3: Risikoanalyse aufder Basis von IT-Grundschutz

Das BSI bietet mit den IT-Grundschutzkatalogen bereits viele Standardsicherheitsmaßnahmen in den relevanten Bereichen: Organisation, Personal, Infrastruktur, IT-Systeme, Anwendungen und Netze, die bei normalem Schutzbedarf bzw. moderaten Sicherheitsanforderungen in der Regel angemessen zur Behandlung von typischen Gefährdungen von Geschäftsprozessen und Informationsverbünden sind. Bei höheren Sicherheitsanforderungen können die Sicherheitsmaßnahmen und die Gefährdungs­lage allerdings über die angebotenen Behandlungsmöglichkeiten hinausgehen. Eine passende und methodisch angelehnte Vorgehensweise zur Behandlung von Risiken ist dabei der BSI-Standard zur Risikoanalyse auf der Basis von IT-Grundschutz [BSI08-1003]. Der BSI-Standard 100-3 bietet genau die eben beschriebene nahtlose Weiterführung der IT-Grundschutzanalyse, falls die Sicherheitsan­forderungen des Unternehmens bzw. der Behörde erhöht sind oder wichtige Anwendungen oder Kom­ponenten betrieben werden, die nicht mehr mit den Bausteinen des BSI abgedeckt sind. Aber auch be­sondere Einsatzszenarien, also Rahmenbedingungen der Umgebung oder der Anwendung, können über die Risikoanalyse abgedeckt werden [BSI09B].

In der Risikoanalyse wird für die zutreffenden Objekte festgestellt, ob und in welcher Hinsicht über den IT-Grundschutz hinaus Handlungsbedarf zur Reduktion von Risiken für die Informationsverar­beitung besteht. Dazu werden die Gefährdungen aus den IT-Grundschutzkatalogen für die betreffen­den Objekte aufgelistet und bewertet [BSI08-1003].

2.3.1.4. BSI-Standard 100-4: Notfallmanagement

Die Sicherstellung der Kontinuität des Geschäftsbetriebs (Business Continuity Management - BCM) ist Inhalt des BSI-Standards 100-4 [BSI08-1004]. Für Unternehmen und Behörden wird ein systemati­scher Weg dargestellt, um ein angemessenes Notfallmanagement zu etablieren. Dabei steht die IT nicht im Mittelpunkt, jedoch werden mittelbar die Ausfallsicherheit der Geschäftsprozesse und somit der unterliegenden IT betrachtet sowie Vorbeugungsmaßnahmen für Notfälle und Krisen aufgezeigt. Notfallmanagement wird als Sicherung des Geschäftsbetriebs auch bei größeren Schadensereignissen verstanden und hilft, Schäden zu begrenzen [BSI09B].

„Mit dem neuen BSI-Standard 100-4 werden die sich aus der klassischen IT- Grundschutzvorgehensweise ergebenden Aussagen zum Thema Verfügbarkeit konkretisiert und differenziert. Bei vollständiger Umsetzung dieses Standards und des korrespondierenden Bausteins in den IT-Grundschutzkatalogen kann jede Institution ein effizientes Notfallmanagement etablieren“ [KES08].

2.3.2. IT-Grundschutzkataloge

Die IT-Grundschutzkataloge [BSI08B] des BSI sind als Loseblattsammlung mit rund 3800 Seiten ein Referenzwerk der Standardsicherheitsmaßnahmen für Organisationen, Geschäftsprozesse, IT- Systeme, Anwendungen und Netze. Dabei steht ein angemessener Schutz durch die geeignete Kombi­nation von organisatorischen, personellen, infrastrukturellen und technischen Sicherheitsmaßnahmen im Vordergrund. Die Maßnahmen der IT-Grundschutzkataloge bieten aber auch Ausgangspunkte für die Absicherung von IT-Systemen und Anwendungen mit erhöhten Sicherheitsanforderungen und lie­fern an vielen Stellen bereits entsprechende Sicherheitsmaßnahmen über den normalen Schutzbedarf hinaus [MAL09], [KIL07].

Die IT-Grundschutzkataloge enthalten einen Bausteinkatalog (Abbildung 13), der auf 76 Bausteine aufgeteilt ist. Dabei sind die Bausteine im IT-Grundschutzschichtenmodell [BSI08H] angeordnet, wie z. B. IT-Systeme und Netze. Die Bausteine beziehen sich auf spezifische Themen, wie z. B. allge­meiner Server oder Client unter Windows Vista. In den Bausteinen werden nun für jedes Thema die Sicherheitsaspekte dargestellt: Den spezifischen Gefährdungen werden die entsprechenden Sicher­heitsmaßnahmen in typischen Umgebungen gegenübergestellt. Die Sicherheitsmaßnahmen werden dazu in einem Lebenszyklusmodell angeordnet und deren Rahmenbedingungen beschrieben. Die IT- Grundschutzkataloge definieren außerdem typische Rollendefinitionen in Organisationen und stellen Hilfsmittel zur Arbeit mit dem IT-Grundschutz bereit [KUR09], [BSI08GS].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufbau der IT-Grundschutzkataloge

Eine detaillierte Erläuterung der Gefährdungen und Maßnahmen findet sich dann in den entsprechen­den Katalogen G lbisG5 bzw. M IbisM 6 der IT-Grundschutzkataloge [BSI08GS].

2.3.3. IT-Grundschutzbausteine

Wesentlicher Inhalt der IT-Grundschutzkataloge sind die enthaltenen Bausteine. Diese sind von ihrer Struktur her gleich aufgebaut: Jeder Baustein enthält eine Kurzbeschreibung und ein treffendes Logo für die betrachteten Komponenten bzw. das Thema. Darunter befindet sich eine Zusammenfassung der Gefährdungslage und die Maßnahmenempfehlungen. Die Bausteine an sich sind in die Kataloge Bl bis B 5 gruppiert. Diese Kataloge spiegeln das IT-Grundschutzschichtenmodell wider und be­stehen aus dem Katalog B l, den übergeordneten Aspekten der Informationssicherheit, Katalog B 2, Sicherheit der Infrastruktur, Katalog B 3, Sicherheit der IT-Systeme, Katalog B 4, Sicherheit in Net­zen und Katalog B 5, Sicherheit in Anwendungen [BSI08B].

Jeder Baustein wird in den sogenannten „Goldenen Regeln“ zu etwa zehn Aussagen separat zusam­mengefasst. Hier werden die Sachverhalte für die Sicherheit eines Bausteins dargestellt, die unver­zichtbar sind. Die „Goldenen Regeln“ dienen zum Kurzüberblick und zur Einordnung des jeweiligen Bausteins.

2.3.3.1. Gefährdungen

Die IT-Grundschutzkataloge analysieren innerhalb derjeweiligen Bausteine typische Schwachstellen und Bedrohungen für Einsatzszenarien sowie Komponenten und zeigen die daraus resultierenden Ge­fährdungen auf. Dabei werden nur jene Gefährdungen berücksichtigt, die eine entsprechende signifi­kante Eintrittswahrscheinlichkeit oder ein so hohes Auswirkungspotenzial haben, dass angemessene Sicherheitsmaßnahmen umgesetzt werden müssen. Neben globalen Gefährdungen, wie z. B. Schäden durch Feuer, Diebstahl, Schadsoftware, trojanische Pferde oder Hardware-Ausfall werden konkrete und spezialisierte Gefährdungen betrachtet, die auf Einzelsysteme und Anwendungen zugeschnitten sind. Durch die Unterstützung der IT-Grundschutzkataloge und die Integration in die IT- Grundschutzvorgehensweise bietet dieser Ansatz den Vorteil, dass Anwender für einen Großteil des Informationsverbundes keine Bedrohungs- und Schwachstellenanalyse durchführen oder individuelle Eintrittswahrscheinlichkeiten berechnen müssen.

Die Gefährdungen bilden die Basis für die Maßnahmenausgestaltung im jeweiligen Baustein [BSI08- 1001].

Obwohl das Einlesen in die Gefährdungen für die Erstellung eines Sicherheitskonzepts nach IT- Grundschutz nicht zwingend erforderlich ist, ist das Wissen über die Inhalte und das Verständnis für die Maßnahmen grundlegend zur Bewertung und Ermittlung von Gefährdungen im Rahmen der Risi­koanalyse.

2.3.3.2. Maßnahmen

Die IT-Grundschutzbausteine bestehen im Wesentlichen aus Maßnahmenempfehlungen, die sich aus der Gefahrdungslage ergeben. Es handelt sich pro Baustein um diejenigen Maßnahmen, die für dieje- weiligen Themen nach dem Stand der Technik umzusetzen sind, um eine angemessene Basissicherheit zu erreichen. Den Zusammenhang zwischen Gefährdungen und den empfohlenen Maßnahmen zeigen die Maßnahmengefährdungs- bzw. Kreuzreferenztabellen fürjeden Baustein [BSI08B].

Die Maßnahmenempfehlungen umfassen dabei üblicherweise die für einen ordnungsgemäßen und si­cheren Betrieb erforderlichen Aspekte in typischen Einsatzszenarien, auch wenn diese über den nor­malen Schutzbedarf hinaus gehen. Die Sicherheitsmaßnahmen beschränken sich nicht nur auf techni­sche Aspekte, sondern können auch aus anderen Bereichen, wie z. B. Organisation, Personal oder IT- Systemen und Anwendungen stammen. Dabei orientieren sich die Maßnahmen an den Grundwerten: Vertraulichkeit, Integrität und Verfügbarkeit.

Die Maßnahmentexte sind innerhalb des Basis-Sicherheitschecks [BSI08-1002] und in der Realisie­rung sinngemäß umzusetzen. Dabei sind die Maßnahmen so ausgelegt, dass sie möglichst universell angewendet werden können.

Neben der eigentlichen Umsetzungsempfehlung werden auch Verantwortliche bzw. Rollen genannt. „Verantwortlich für die Initiierung“ etwa bezeichnet hier die Personen oder die Rollen, die eine Um­setzung der Maßnahme veranlassen. „Verantwortlich für die Umsetzung“ adressiert die Personen oder die Rollen, die eine Maßnahme realisieren sollten.

Zusammenfassend werden am Ende der Maßnahmen ergänzende Kontrollfragen angeführt, die den Maßnahmentext abrunden und nochmals die Umsetzungsschwerpunkte der Maßnahmenempfehlung beleuchten sollen; sie stellen jedoch keine Prüffragen dar. Für Sicherheitsüberprüfungen, beispiels­weise Zertifizierungen, Revisionen und Audits, wurden mit der 10. Ergänzungslieferung der IT- Grundschutzkataloge für ausgewählte Bausteine und Maßnahmen sogenannte Prüffragen eingeführt. Diese ersetzen die Kontrollfragen und lösen diese mittelfristig ab. Im Gegensatz zu den Kontrollfrag­en sind die Prüffragen so formuliert, dass sie als verbindliche Checkliste benutzt werden können, um die adäquate Umsetzung der Maßnahmen bewerten zu können. Damit geben die Prüffragen Ziele und Ausrichtung der Sicherheitsempfehlungen vor und können damit als Referenz für Prüfungen benutzt werden [BSI08A].

2.3.3.3. Lebenszyklusmodell

Jeder Baustein enthält eine Übersicht über den Lebenszyklus für das betrachtete Themengebiet. Dazu werden die relevanten Maßnahmen jeweils einer der Lebenszyklusphasen - Planung und Konzeption, Beschaffung, Umsetzung, Betrieb und Notfallvorsorge - zugeordnet. Optional werden die Phasen Mi­gration und Aussonderung betrachtet. Neben der Zuordnung wird herausgestellt, welche Maßnahmen in welcher Phase der Bearbeitung zu welchem Zweck umgesetzt werden sollten. Die Themen Sicher­heitsmanagement und Revision werden übergreifend betrachtet, da diese den gesamten Lebenszyklus begleiten und kontrollieren [BSI08B]. Das Lebenszyklusmodell gilt entsprechend für die relevanten Gefährdungen, die indirekt über die Maßnahmen den einzelnen Phasen zugeordnet sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Lebenszyklus der Informationssicherheit

Typische Maßnahmen für die Phase „Planung und Konzeption“ (Abbildung 3) behandeln die Einsatz­szenarien und den Einsatzzweck, die Abwägung des Risikopotenzials, die Erstellung von Sicherheits­konzepten und entsprechende Richtlinien. In der Phase „Beschaffung oder Migration“ sind üblicher­weise Maßnahmen enthalten, die Anforderungen an zu beschaffende Produkte formulieren und Aus­wahlentscheidungen für bestimmte Produkte dokumentieren.

Die Lebenszyklusphase „Umsetzung“ beinhaltet Maßnahmen zu Testbetrieb, Installation und Konfi­guration sowie Schulung und Sensibilisierung aller relevanten Personen. Die Phase „Betrieb“ behan­delt üblicherweise Maßnahmen für den laufenden Betrieb, wie z. B. Überwachung, Protokollierung, Pflege, Weiterentwicklung, Änderungsmanagement und Wartung.

Bei der optionalen Lebenszyklusphase „Aussonderung“ kommen Maßnahmen wie Entzug von Be­rechtigungen und das Entfernen von relevanten Einträgen aus globalen Katalogen und Verzeichnissen wie z. B. LDAP und Microsoft Active Directory zum Tragen.

Die Phase „Notfallvorsorge“ gibt schließlich einen Überblick über angemessene Maßnahmen zu Da­tensicherung, Redundanz, Umgang mit Sicherheitsvorfällen und dem Erstellen eines Notfallplans.

Redundanzen können im Lebenszyklusmodell bei voneinander abhängigen Bausteinen auftreten. Um die Maßnahmen der Beschaffungsphase nicht zu wiederholen, enthält beispielsweise der Baustein B 5.16Active-Directory [BSI08I] hier keine Maßnahme, da dieser Baustein zu der Umsetzung des ele­mentaren Bausteins B 5.15 Allgemeiner Verzeichnisdienst [BSI08G] verpflichtet und hier die Auswahl des Produkts bereits entschieden wurde [BSI08B].

2.3.3.4. Siegelstufen

Die Umsetzung der IT-Grundschutzvorgehensweise wird seit Anfang 2006 vom BSI mit einem Zerti­fikat bestätigt, das die Anforderungen des internationalen Standards ISO 27001 abdeckt: Dem ISO- 27001-Zertifikat auf der Basis von IT-Grundschutz [AUG09]. Neben dieser Bestätigung durch die Zertifizierungsstelle des BSI können Behörden und Unternehmen auf dem Weg zur Zertifizierung auch die Erreichung wichtiger Meilensteine in zwei Vorstufen durch vom BSI lizenzierte Auditoren bestätigen lassen: das Auditor-Testat „IT-Grundschutz Einstiegsstufe“ und das Auditor-Testat „IT- Grundschutz Aufbaustufe“ [BSI09I].

Zujeder Maßnahme wird eine der drei Qualifizierungsstufen veröffentlicht, um einordnen zu können, ob die jeweilige Maßnahme für die IT-Grundschutzqualifizierung gefordert wird. Weiterhin gibt es zusätzliche Maßnahmen und sogenannte Wissensfragen, die für die Qualifizierung nicht von Bedeu­tung sind.

Für eine ISO-27001-Zertifizierung auf der Basis von IT-Grundschutz sind beispielsweise alle (A)-, (B)- und (C)-Maßnahmen umzusetzen [BSI09D]; diese stellen das Minimum dessen dar, was an ange­messenen Maßnahmen zu realisieren ist.

Maßnahmen werden als (A)-Maßnahmen gekennzeichnet, wenn diese mindestens und vorrangig um­zusetzen sind. Sie müssen für alle drei Ausprägungen der Qualifizierung nach IT-Grundschutz voll­ständig abgearbeitet sein. Die Qualifizierungsstufen beginnen mit den Auditor-Testaten: „IT-Grund­schutz Einstiegsstufe“ und „IT-Grundschutz Aufbaustufe“. Die letzte Qualifizierungsstufe ist das „ISO-27001-Zertifikat auf der Basis von IT-Grundschutz“. (B)-Maßnahmen werden als solche gekennzeichnet, um das Auditor-Testat „IT-Grundschutz Aufbaustufe“ und das „ISO-27001-Zertifikat auf Basis von IT-Grundschutz“ zu erreichen. Zusätzlich müssen für ein „ISO-27001-Zertifikat auf Basis von IT-Grundschutz“ die mit (C) gekennzeichneten Maßnahmen umgesetzt sein.

(Z)-Maßnahmen müssen nicht umgesetzt werden. Sie stellen Ergänzungen dar, die vor allem bei höhe­ren Sicherheitsanforderungen hilfreich sein können. (W)-Maßnahmen dienen ausschließlich der Wis­sensvermittlung von Grundlagen zu dem entsprechenden Thema. Die Inhalte sind für das Verständnis und die Umsetzung der anderen Maßnahmen hilfreich und haben deshalb keine Qualifizierungsrele­vanz [BSI08A].

2.3.4. Internationale Standards der ISO/IEC-27000-Reihe

In den internationalen Normungsorganisationen ISO und International Electrotechnical Commission (IEC) wurde beschlossen, die Standards zur Informationssicherheit in der 2700x-Reihe zusammenzu­führen. Die Reihe wächst stetig und rekrutiert Beiträge meist aus anerkannten Standards der britischen Normungsorganisation [BRI09].

Zur weiteren Vertiefung sei auf einen Überblick unter [WIK09A] verwiesen. Eine praxisorientierte Einführung gibt [HAR08].

2.3.4.1. ISO/IEC 27000

Der ISO-Standard 27000 [ISO05x1] gibt einen allgemeinen Überblick über Managementsysteme für Informationssicherheit und über die Zusammenhänge der verschiedenen Standards der ISO-2700x-Fa- milie. Hier finden sich außerdem die grundlegenden Prinzipien, Konzepte, Begriffe und Definitionen für ISMS.

2.3.4.2. ISO/IEC 27001:2005

Der ISO-Standard 27001 [ISO05x2] ist der erste internationale Standard zum Management von Infor­mationssicherheit, der auch eine Zertifizierung ermöglicht. ISO-27001 gibt auf ca. zehn Seiten allge­meine Empfehlungen und spezifiziert die Anforderungen für Herstellung, Einführung, Betrieb, Über­wachung, Wartung und Verbesserung eines dokumentierten ISMS auch unter Berücksichtigung der Risiken. Hierbei kann der Standard unabhängig von der Größe und Art der Organisation angewendet werden [WIK09A]. In einem normativen Anhang wird auf die „Controls“ aus ISO/IEC 27002

[ISO05x3] verwiesen. Anders als in den IT-GrundschutzkatalKatalogen finden sich hier keine detaillierten Umsetzungshinweise, sondern übergreifende Anforderungen.

2.3.4.3. ISO/IEC 27002:2005

Das Ziel von ISO 27002 [ISO05x3] ist es, ein Rahmenwerk für das ISMS zu definieren. ISO 27002 befasst sich daher hauptsächlich mit den erforderlichen Schritten, um ein funktionierendes Sicher­heitsmanagement aufzubauen und in der Organisation zu verankern. Die erforderlichen Sicherheits­maßnahmen werden auf den circa 100 Seiten des ISO-Standards ISO/IEC 27002 überblicksartig be­schrieben. Die Empfehlungen sind in erster Linie für die Managementebene gedacht und enthalten daher nur wenige technische Hinweise. Die Umsetzung der Sicherheitsempfehlungen der ISO 27002 ist eine mögliche Ausgestaltung der Anforderungen des ISO-Standards 27001 [BSI08-1001]. Einen Vergleich zwischen ISO 27002 und den IT-Grundschutzkatalogen bietet [BSI08E].

2.3.4.4. ISO/IEC 27005:2008

Mit ISO 27005 [ISO08x5] wird ein Handlungsleitfaden für die Risikoanalyse von Informationssicher­heit beschrieben, ohne auf eine konkrete Methodik einzugehen. Dabei werden allerdings Bezüge zur ISO-27001 konkretisiert und die Einbettung in das ISMS vorgenommen [FRI08].

2.3.5. Weitere relevante Standards und Referenzen

Im Hinblick auf die Sicherheitsanalyse, insbesondere bei der Recherche nach relevanten Gefährdun­gen, sei auf eine Übersicht und Bewertung der gängigen Methoden zur Risikoanalyse in Bezug auf In­formationssicherheit der European Network and Information Security Agency (ENISA) [ENIS07Í] verwiesen.

Unter anderem werden die Methoden des französischen Standards zur Risikoanalyse EBIOS (Formali­sierung von Bedürfnissen und Identifizierung von Sicherheitszielen) bei der Betrachtung von Gefähr­dungen herangezogen. EBIOS [ANSS09] wird von der französischen Agentur für Netz- und Informationssicherheit (ANSSI) zur Verfügung gestellt.

2.4. Analysemethodik

In den folgenden Punkten wird die Vorgehensweise zur Analyse beschrieben. Ausgehend von der Un­tersuchung bestehender IT-Grundschutzbausteine hinsichtlich der Versionsabhängigkeit wird eine Methodik für die Sicherheitsanalyse vor der Erstellung eines neuen IT-Grundschutzbausteins vorge­stellt.

2.4.1. Untersuchung versionsabhängiger IT-Grundschutzbausteine

Die IT-Grundschutzkataloge müssen den kurzen Innovationszyklen und kurzen Versionswechseln Rechnung tragen. Dazu bieten die Kataloge mit der Bausteinstruktur einen modularen und leicht er­weiterbaren Ansatz [BSI08-1002]. Ergebnis der Untersuchung versionsabhängiger Bausteine ist eine Übersicht der momentan vorhandenen IT-Grundschutzbausteine, die versionsabhängige Inhalte ent­halten, wie beispielsweise bestimmte Screenshots von Anwendungen, Konfigurationseinstellungen oder Handbuchzitate.

2.4.1.1. A usprägungen der Versionsabhängigkeit

Die Analyse soll aus den vorhandenen IT-Grundschutzkatalogen diejenigen Bausteine eingrenzen, die offensichtlich eine Zuordnung oder Gültigkeitseinschränkung aufweisen:

Fürjeden Baustein B¡ aus der Menge GSK soll geprüft werden, ob dessen Gültigkeit auf eine bestimm­te Version eingeschränkt wurde. Dazu findet sich meist in der Bausteinzusammenfassung ein Hin­weis. Im ersten Schritt kann dazu eine Aufteilung in herstellerspezifische Bausteine erfolgen.

Als Untersuchungsmenge UM kommen nun diejenigen B¡ in Betracht, bei denen eine entsprechende Markierung für die Versionsabhängigkeit vorliegt.

Für die ermittelte UM wird für jeden enthaltenen B¡ die Detailtiefe DT¡ mit DT:={abstrakt\konkret} festgestellt. Als „konkret“ soll dabei B¡ markiert werden, falls sich die enthaltenen Sicherheitsmaßnah­men nur auf die markierte Version beziehen und sich eine Generalisierung nicht umsetzen lässt. Ne­ben der Markierung ist eine Beschreibung der versionsspezifischen Umsetzung VU¡ innerhalb des Bausteins anzugeben: Insbesondere soll bewertet werden, ob sich Bausteinaufbau und -umsetzung für Folgeversionen des Bausteins eignen, und wie die versionsspezifische DT¡ umgesetzt wird.

2.4.1.2. Existierende Lösungen für Versionsunabhängigkeit

Die Analyse soll aus den vorhandenen IT-Grundschutzkatalogen diejenigen Bausteine feststellen, die keine Zuordnung oder Gültigkeitseinschränkung in Bezug auf Versionierung aufweisen:

Fürjeden Baustein B¡ aus der Menge GSK soll geprüft werden, ob dessen Gültigkeit auf ein bestimm­tes Produkt, allerdings ohne Versionsbezug, eingeschränkt wurde. Dazu kann die Bausteinzusammen­fassung Hinweise geben. Im ersten Schritt kann dazu eine Aufteilung in produktspezifische Bausteine erfolgen. Ebenfalls sind die Erkenntnisse aus 2.4.1.1 mit einzubeziehen.

Als Untersuchungsmenge UMVU kommen nun diejenigen B¡ in Betracht, bei denen eine entsprechende Markierung für die Versionsunabhängigkeit vorliegt.

Für die ermittelte UMVU wird jeweils für jeden enthaltenen B¡ die Detailtiefe DT¡ mit DT:={abstrakt\ konkret} festgelegt. Als „abstrakt“ soll dabei B¡ markiert werden, falls sich die enthaltenen Sicher­heitsmaßnahmen auf keine bestimmte Version beziehen und sich eine Generalisierung mit angemesse­nem Aufwand umsetzen lässt. Weiterhin wird für jeden B¡ dessen Lösungsansatz für die Versionsun­abhängigkeit beschrieben. Danach erfolgt eine Bewertung, inwiefern sich die enthaltenen Sicherheits­maßnahmen M¡ versionsunabhängig verhalten und wie - falls vorhanden - eine versionsspezifische Spezialisierung realisiert ist.

2.4.1.3. Versionsunabhängige Lösungsmöglichkeiten

Aus der Analyse der UM und UMVU sollen Lösungsmöglichkeiten für den Aufbau von neuen IT- Grundschutzbausteinen Bneu mit Versionsbezug identifiziert werden. Dabei ist für DTneu ein moderates Abstraktionsniveau ohne konkreten Versionsbezug zu berücksichtigen. Bneu soll hierdurch bis auf Maßnahmenebene versionsunabhängig ausgestaltet sein. Gleichzeitig sollen konkrete versionsabhän­gige Vorgaben bereitgestellt werden. Um diese Herausforderung zu realisieren, sind entsprechende Lösungsansätze zu identifizieren und zu bewerten.

2.4.2. Anforderungen an die Sicherheitsanalyse

Ausgangsbasis für die Erstellung neuer Bausteine sind die aktuellen Versionen der IT-Grundschutz- vorgehensweise [BSI08-1002] sowie derIT-Grundschutzkataloge [BSI08A].

Jeder erstellte Baustein muss den Anforderungen, der Struktur und der Qualität der IT- Grundschutzkataloge genügen: Der Schwerpunkt eines jeden IT-Grundschutzbausteins liegt von der Intention her nicht auf der Beschreibung derjeweiligen Technik, sondern auf Empfehlungen, wie z. B. zur sicheren Planung, zu Installation und Betrieb. Allgemeine Empfehlungen, die nicht nur auf den jeweiligen Baustein zutreffen, sind nicht dessen Bestandteil, sondern finden sich in anderen Bausteinen der IT-Grundschutzkataloge.

Neben der Definition und Abgrenzung des Untersuchungsgegenstandes Uy und letztendlich dem pas­senden Zielobjekt für den Baustein sind in der Sicherheitsanalyse mögliche Gefährdungen für normale Einsatzumgebungen zu spezifizieren. Gegenüber den Gefährdungen werden Sicherheitsmaßnahmen erarbeitet und bewertet, die das Risiko vermindern sollen. Im Folgenden wird die Methodik vorge­stellt, die erforderliche Aspekte und Anforderungen für die Erstellung eines neuen Bausteins berück­sichtigt.

2.4.2.1. Definition des Untersuchungsgegenstandes

Der Untersuchungsgegenstand Uy wird anhand einer Kurzbeschreibung definiert und beinhaltet die ty­pischen Komponenten, die in der Sicherheitsanalyse betrachtet werden. Als Anforderung für einen IT- Grundschutzbaustein ist neben der textuellen Beschreibung von Uy eine grafische Repräsentation in Form eines Bausteinlogos zu entwerfen. Damit kann der Untersuchungsgegenstand visuell hervorge­hoben werden und erhält so eine bildliche Darstellung der wesentlichen Inhalte Uy.

2.4.2.2. Abgrenzung des Untersuchungsgegenstandes

Sofern es sich bei dem Untersuchungsgegenstand Uy um eine Produktgruppe oder ein spezifisches Produkt innerhalb einer Gruppe handelt, wird Uy gegenüber anderen gängigen Produkten Py abge­grenzt. Dabei sind beispielsweise der gleiche Hersteller, Konkurrenzprodukte oder ergänzende Pro­dukte die Abgrenzungskriterien.

Ein typisches Einsatzszenario ESi ist zu definieren, welches die Einordnung von Uy im Gesamtkontext zulässt: In einer Übersicht - beispielsweise anhand eines Netztopologieplans - werden die betrachte­ten Komponenten und relevante Schnittstellen dargestellt. Durch die Abgrenzung kann danach das ty­pische Einsatzszenario ESi auf das Wesentliche zu Uyreduziert werden.

Weiterhin ist eine Abgrenzung von Uy zu bestehenden IT-Grundschutzbausteinen GSBi erforderlich, um Redundanzen und Schnittstellen feststellen zu können:

Bestehende IT-Grundschutzbausteine GSB¡ werden dann in die Sicherheitsanalyse von Uy einbezogen, wenn diese direkten Einfluss auf Uy nehmen können, komplementär zu Uy wirken oder Redundanzen zu Uy aufweisen. Obligatorisch ist der Einfluss eines vorhandenen Vorgängerbausteins UV mit Bezug zu Uy.

Nach erfolgter Abgrenzung wird Uy einem Bausteinkatalog BK¡ mit i:={Bl - Übergeodnete Aspekte, B2 - Infrastruktur, B3 - IT-Systeme, B4 - Netze, B5 - Anwendungen} zugeordnet. Dabei kann auch die Einordnung eines bereits bestehenden Vorgängerbausteins als Grundlage für die Auswahl angenommen werden.

2.4.2.3. Lebenszyklusmodell

Das spezifische Lebenszyklusmodell ist für den Untersuchungsgegenstand Uy festzulegen. Dazu er­folgt eine Bewertung, welche Lebenszyklusphasen [Abbildung in dieser Leseprobe nicht enthalten]

[Abbildung in dieser Leseprobe nicht enthalten]

Als Anhaltspunkt kann auf die Festlegung eines Vorgängerbausteins Uv^LZP4.,4 zurückgegriffen werden. Die Verifikation und Konsolidierung kann dann auf Basis der Gefährdungslage und Maßnah­menempfehlungen erfolgen.

2.4.2.4. Gefährdungsanalyse auf Basis existierender Gefährdungskataloge

Die Gefährdungsanalyse basiert auf den Grundlagen des BSI-Standards 100-3. Die Gefährdungskata­loge enthalten mittlerweile knapp 450 Einzelgefährdungen. Dadurch ist die Identifizierung relevanter Gefährdungen aus den Gefährdungskatalogen nicht mehr mit geringem Aufwand - wie ursprünglich in der Intention des Standards angenommen - sondern mit erheblichem Strukturierungsmehraufwand verbunden: Beispielsweise sind Gefährdungen nicht von vornherein in Bezug auf die Grundwerte - Verfügbarkeit, Integrität und Vertraulichkeit - aufgeteilt. Dieser Sachverhalt erschwert die Behand­lung und das Durcharbeiten sämtlicher Gefährdungen bei Schutzbedarfsanforderungen, wenn nur ein Grundwert betroffen ist. Die nachfolgende Verfahrensbeschreibung bietet hierzu einen formalisierten Weg, um die relevanten Gefährdungen einzugrenzen.

Für die Identifizierung bietet sich auf der Ebene der Gefährdungen die Analyse der bereits veröffent­lichten Gefährdungen Gall aus den Gefährdungskatalogen an. Die relevanten Gefährdungen G werden wie folgt ausgewählt:

Die Gefährdung G; wird in die Sicherheitsbetrachtung SB mit einbezogen, falls G¡ für eine Vorgänger­version Uv des Untersuchungsgegenstandes Uy mit v<y veröffentlicht wurde; G¡ wird zu G hinzuge­fügt. Die Gefährdung G¡ ist weiterhin einzubeziehen, falls G¡ für einen abstrakten übergeordneten Baustein Uü oder einen Baustein für ein Konkurrenzprodukt Uk des Untersuchungsgegenstandes Uy veröffentlicht wurde; G¡ wird zu G hinzugefügt.

Weitere Quellen sind sind in [ENIS07Í] aufgeführt. Beispielhaft sei auf die Risikoanalysemethode EBIOS der französischen ANSSI verwiesen, die für die Konsolidierung der Gefährdungen G genutzt werden soll [ANSS09]. EBIOS arbeitet mit 42 Gefährdungen, die eine Überprüfung auf Vollständig­keit von bestehenden Gefährdungen in Standardszenarien erlauben. Alle verfügbaren Gefährdungen Gebios aus EBIOS werden zu den existierenden Gefährdungen Gall mit dem Inhalt GE hinzugefügt, sofern der Inhalt GIebiosj von GE abweicht (GIebiosjOGE). Falls GEbiosj und Gît übereinstimmen, dann werden Kreuzreferenzen KG zu den korrespondierenden Gefährdungen in Gall gesetzt; Gebiosj wird zu G hinzugefügt.

Weiterhin werden übergeordnete Gefährdungen über die Bedrohungskataloge des Information Security Forum (ISF) innerhalb der Risikoanalysemethodik „Information Risk Analysis Methodology“ (IRAM) identifiziert. Das ISF ist ein gemeinnütziger Verband von über 300 Groß­unternehmen, dessen Ziel die Vereinheitlichung von etablierten Vorgehensweisen in der Informations­sicherheit ist.

Mit der Verknüpfung der Schwachstellen und einer Statistik der Eintrittshäufigkeit der letzten Jahre von Mitgliederorganisationen ist eine Bewertung zur Auswahl auf dieser Basis möglich:

Alle verfügbaren Bedrohungen T und zugehörige Schwachstellen V werden analog der EBIOS Gefährdungen Gebios zu den Gefährdungen G hinzugefügt. Dabei wird die Eintrittshäufigkeit E¡ mit i:—{2003,2004,...2007} der letzten beiden Jahre festgestellt; bei einem Anstieg oder Stagnation wird „gestiegen“, bei einem Abstieg „gesunken“ festgestellt: GE—:{gestiegen\ gesunken}. Gleichzeitig werden Überschneidungen oder Duplikate Gd (mit Gd^Gf<—GE) aus G ausgefiltert und im Weiteren unbeachtet gelassen.

Die analoge Einbindung von weiteren Gefährdungskatalogen - wie beispielsweise aus dem Annex C der ISO 27005 [ISO08x5] - ist unter dem Gesichtspunkt der Konsolidierung sinnvoll. Es ist davon auszugehen, dass sich mit steigender Anzahl der Iterationen wesentliche Teile der Gefährdungen wiederholen und die Identifizierung bzw. Konsolidierung abgeschlossen werden kann. Die Gefahrdungslage G ist in jeder Iteration mit den entsprechenden Markierungen für die angewandte Quelle zu versehen, damit der Ursprung der Gefährdungen nachvollziehbar bleibt.

2.4.2.5. Neue Gefährdungen

Danach werden neue Gefährdungen Gn aus Produktrecherchen, Bedrohungsanalysen, Trendanalysen und Interviews identifiziert, auf Duplikate (mit Gd^GIj<=GIk) in G geprüft und ggf. hinzugefügt.

Die Identifizierung von eigenen Gefährdungen auf Basis der Literaturrecherche und Referenzinstallat­ionen wird nach folgender Methodik ausgeführt:

Das kartesische Produkt aus den Überschriften der Gefahrdungskataloge GK:={G1 - „Höhere Ge­walt“, G2 - Organisatorische Mängel, G3 - Menschliche Fehlhandlungen, G4 - Technisches Versa­gen, G5 - Vorsätzliche Handlungen} und den Grundwerten GW:={Verfügbarkeit (Availability) GWA, Vertraulichkeit (Confidentiality) GWC, Integrität GWI (Integrity)} wird im Hinblick auf den Unter­suchungsgegenstand zu neuen Gefährdungen G¡ herangezogen. Dabei sind neue Gefährdungen für Uy anhand der Überschriften aus GK verknüpft zu den Grundwerten GW zu eruieren. Beispielsweise könnte eine neue Gefährdung aus der Verknüpfung von G5 und GWA mit der nachfolgenden Frage­stellung identifiziert werden: Welche vorsätzliche Handlungen G¡ beeinträchtigen den Grundwert Ver­fügbarkeit von Uy mit signifikanter Wahrscheinlichkeit negativ.

2.4.2.6. Konsolidierung der Gefährdungslage

Danach werden alle identifizierten Gefährdungen - soweit nicht bereits geschehen - den Grundbedro­hungen und den Gefährdungskatalogen zugeordnet:

Zu jeder Gefährdung Gi wird jeweils vermerkt, welche Grundwerte GW¡ von G¡ bedroht werden und zu welchem Gefährdungskatalog GK die Gefährdung G¡ zugeordnet ist. Anhaltspunkte dazu geben die bereits zugeordneten Grundwerte innerhalb von EBIOS und IRAM sowie die Überlegungen für neue Gefährdungen (2.4.2.5).

Bei Client-Server-Systemen ist weiterhin die Entscheidung der Relevanz W¡ von G¡ in Bezug auf Uy zu treffen: Zujeder G¡ wird entschieden, ob diese auf den Server Ws, auf den Client Wc und auf die Kom­munikationsstrecke Wcom wirkt mit [Abbildung in dieser Leseprobe nicht enthalten].

2.4.2.7. Bewertung der Gefährdungslage

Bei der abschließenden Gefährdungslage G ist für jede Gefährdung Gi festzustellen, ob die Gefähr­dung auf den Untersuchungsgegenstand Uy zutrifft und die Abgrenzungskriterien erfüllt.

Die Auswahl der relevanten Gefährdungen Gr aus G erfolgt anhand einer Bewertungsfunktion:

Gefährdungen Gr sind dann relevant, wenn diese in normalen Einsatzszenarien oder Anwendungsfäl­len ohne spezielle Rahmenbedingungen Rsr, besondere technische Gegebenheiten Rtg oder Fachkennt­nisse Rt/auftreten können [BSI08-1003]. Gefährdungen Gnr, auf die diese Charakteristik nicht zutrifft, können im Rahmen der Risikoanalyse für höheren Schutzbedarf herangezogen werden, sind für die weitere Betrachtungjedoch nicht von Bedeutung. Im Weiteren reduziert sich die Liste der Gefährdun­gen G also auf Gr, mit der Differenzmenge Gnr. Eine Gefährdung G¡ ist auch dann relevant, wenn für den Inhalt GI¡ gilt: GI¡ bezieht sich nicht auf einen Wert aus R:={RsnRtg,Rf}. Als weiteres Abgren­zungskriterium können die festgestellten E¡ mit E¡={,gesunken“} herangezogen werden; somit kön­nen Gefährdungen aus dem Katalog wegfallen, deren Eintrittshäufigkeit rückläufig ist.

In den IT-Grundschutzbausteinen wird die Übersicht der analysierten Gefährdungen innerhalb der Ge­fährdungslage dargestellt. Um die Konsistenz und Übersichtlichkeit zu erhöhen, werden die Gefähr­dungstexte in denjeweiligen Bausteinen lediglich referenziert, wie z. B. G4.1 Ausfall der Stromver­sorgung. Aus dem Kürzel G GK.Gi geht die Position der Gefährdung innerhalb der Gefährdungskat­aloge hervor: Der Buchstabe „G“ steht dabei für Gefährdungskatalog und die Zahl Vier vor dem Punkt referenziert auf G 4, Technisches Versagen; die Zahl Eins nach dem Punkt bezeichnet die laufende Nummer der Gefährdung innerhalb des jeweiligen Katalogs [BSI08B]. Da für neue Gefährdungen noch keine laufende Nummer vorliegt, werden neue Gefährdungen über einen Bezeichner mit der Quelle [Abbildung in dieser Leseprobe nicht enthalten] referenziert. Bei geänderten oder vervollständigten Gefährdungen soll das Kennzeichen „MT“ auf Erkenntnisse dieser Arbeit hinweisen.

2.4.2.8. Maßnahmenentwicklung

Nach der Konsolidierung der Gefährdungen in G werden Sicherheitsmaßnahmen entworfen, die jeder Gefährdung G¡ entgegenwirken. Ziel ist die Verminderung des Restrisikos (2.1.5) auf einen allgemein hinnehmbaren Anteil - vergleichbar mit der Auffassung der Sicherung technischer Anlagen nach dem Stand der Technik oder IT-Grundschutz. Dazu werden bereits verknüpfte Maßnahmen aus U, heran­gezogen und zusätzlich erforderliche Maßnahmen aus Hersteller- und Sachverständigenquellen verar­beitet.

Für ein Standardszenario mit normalem Schutzbedarf ist ein auf den Gefährdungskatalog G abge­stimmter Maßnahmenkatalog Mzu entwerfen, bei dem folgende Schritte zu beachten sind:

Fürjede Gefährdung G, muss es mindestens eine Maßnahme Mt geben, die gegen G¡ angemessen wirkt und nach Umsetzung so mindestens das angestrebte Schutzniveau Sn erreicht. Eine Maßnahme M¡ wird dann in M aufgenommen, wenn diese das Gesamtrisiko vermindert, so dass ein normaler Schutz­bedarf gewährleistet werden kann; dazu muss M¡ anhand der Kriterien aus Sn:={SZ1,.,SZ6} bewertet werden. Dabei werden Verstöße gegen Gesetze, Vorschriften und Verträge, die Beeinträchtigung des informationellen Selbstbestimmungsrechts, der persönlichen Unversehrtheit, der Aufgabenerfüllung, negative Innen- oder Außenwirkung und finanzielle Auswirkungen untersucht (Tabelle 1). Für den Ausdruck - M¡ wirkt ausreichend auf G¡ - muss geprüft werden, ob die beschriebenen Szenarien in Sn allgemein mit umgesetzter M¡ erfüllt werden. Das angestrebte Schutzniveau Sn sei als normaler Schutzbedarf definiert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Definition der Schutzbedarfskategorie "normal" [BSI08-1002]

Analog zu den Gefährdungskatalogen istjede Sicherheitsmaßnahmen M¡ in genau einen Maßnahmen­katalog MK¡mit i={„M 1 - Infrastruktur“, „М2 - Organisation“, „М3 - Personal“, „M4 - Hard- undSoftware“, „M5 - Kommunikation“, „M6 - Notfallvorsorge“} zu gruppieren (M-^-MK). Dabei gilt, dass die Abbildung G¡^M¡ auf GK¡^MK¡ angewendet werden kann; so kann die Zuordnung der Gefährung G¡ zu einem Gefährdungskatalog GK und zu einer Maßnahme M¡ für die entsprechende Verknüpfung der Maßnahme M¡ zu dem Maßnahmenkatalog MK¡ genutzt werden.

Jede Maßnahme M¡ wird zu genau einer Phase LZP¡ des Lebenszyklusmodells zugeordnet: M^LZPi. Gleichzeitig muss begründet werden, warum die Zuordnung von M¡ zu LZP¡ erfolgt ist. Weiterhin muss jede Maßnahme M¡ unter normalen Einsatzbedingungen umgesetzt werden können; also sollte sich der Inhalt MI¡ insbesondere nicht auf R:={Rsr,Rtg,Rtf} beziehen und zumutbar sein: M¡ sollte Ge­schäftsprozesse nicht merklich verlangsamen oder gar blockieren und die Belastung der Mitarbeiter durch die Umsetzung der Maßnahme nicht unangemessen ansteigen. Die wirtschaftlichen Aspekte bei einer Umsetzung sollen ebenfalls verhältnismäßig sein [MAY09]. Bei neuen Maßnahmen ist auf Re­dundanzfreiheit zu anderen Bausteinen zu achten; eine Spezialisierung oder Generalisierung einer vorhandenen Maßnahme ist injedem Fall möglich.

Die Inhalte Mli der Maßnahmen sind anhand von wissenschaftlichen Methoden zu ermitteln: Hierbei dienen Sicherheitsdokumente und -richtlinien, Interviews mit Sachverständigen, Literatur aus einschlägigen Quellen sowie Referenzumgebungen zu Laborbedingungen als Grundlage.

Sofern Versionsabhängigkeiten bei Uy relevant sind, müssen diese in eine Relation zu den erstellten Gefährdungen G und Maßnahmen M gebracht werden. Bei versionsabhängigen Aspekten einer Mi ist demnach die Versionszuordnung MV¡ in Bezug auf Uy zu treffen: Zujeder M¡ wird festgelegt, auf wel­che Versionen MV¡ zutreffend ist. Durch diese Zuordnung ist indirekt ein Rückschluss auf die ver­knüpfte Gefährdung G¡ zu M¡ möglich.

Derjeweilige Baustein referenziert auch hier nur auf die entsprechende Maßnahme, wie z. B. M 1.15 (A) Geschlossene Fenster und Türen. M MKi.Mi steht für den Maßnahmenkatalog - hier ,,M 1“ für In­frastruktur - und die Ziffer 15 für die laufende Nummer der Maßnahme innerhalb des Katalogs. Mit dem Buchstaben in Klammern - hier (A) - wird zu jeder Maßnahme Mi die Qualifizierungsstufe Q¡ mit i={(A),(B),(C),(W),(Z)} (2.3.3.4) angegeben, also eine Einstufung, ob diese Maßnahme für eine IT-Grundschutzqualifizierung gefordert wird [BSI08B]. Bei geänderten oder vervollständigten Maßnahmen soll das Kennzeichen „MT“ auf Erkenntnisse dieser Arbeit hinweisen.

2.4.2.9. Entwicklung der Prüffragen

Zujeder Maßnahme Mi werden Prüffragen MP erstellt, die folgenden Anforderungen genügen:

Eine Prüffrage MP] ist stets eine geschlossene Frage F¡, die nur mit „Ja“ oder „Nein“ beantwortet wer­den kann, mit MiP]:={Fj^[Ja\Nem]}. Die Antwort „Ja“ bedeutet, dass die jeweilige Anforderung er­füllt ist. Die Aspekte der Prüffrage MP] müssen sich als zwingend umzusetzende Anforderung im Text der zugehörigen Maßnahme MIi wiederfinden. Je Prüffrage ist aber stets nur ein Aspekt zu be­trachten. Prüffragen müssen in der Regel allgemeiner und abstrakter formuliert werden als der Maß­nahmentext, da sonst eine unübersichtliche und unhandliche Anzahl an Prüffragen entsteht.

Eine Prüffrage kann evtl. nur in einem bestimmten Kontext relevant sein. Dann ist die Prüffrage durch eine entsprechende Formulierung so zu kennzeichnen. Ist eine Prüffrage MP] für die Sicherheitsbe­trachtung SB von Uy unverzichtbar, wird diese als elementar, ansonsten mit vertiefend gekenn­zeichnet: MP]^{Uy^[elementar\vertiefend]}.

Die einzelnen Prüffragen müssen auf die Lebenszyklusphase, der die jeweilige Maßnahme zugeordnet ist, abgestimmt sein. In Planungs- und Überblicksmaßnahmen ist es häufig nicht zweckmäßig, nach Aspekten aus den Umsetzungsmaßnahmen zu fragen. Beispielsweise muss in der Planungsphase ent­schieden werden, welche Dienste und Protokolle auf einem IT-System zugelassen werden, in der Um­setzungsphase müssen diese dann sicher konfiguriert werden. Hiervon können aber auch Ausnahmen existieren.

2.4.2.10. Goldene Regeln

Die „Goldenen Regeln“ GR enthalten eine Zusammenfassung der Sicherheitsanalyse Uy^{G,M[MP]} über die Sachverhalte eines Bausteins, die unverzichtbar sind. Diese Sachverhalte eines Bausteins sind aus der Sicherheitsanalyse zu Uy ableitbar und sollen die zwingend umzusetzenden Anforderungen aus den Maßnahmenempfehlungen enthalten. Da diese Anforderungen bereits in den elementaren Prüffra­gen MP verarbeitet werden, sind die Aspekte der elementaren Prüffragen MP vorrangig einzubeziehen (MiP]^{Uy^elementar}). Damit geben die „Goldenen Regeln“ einen Kurzüberblick der wesentlichen Sicherheitsaspekte des jeweiligen Bausteins.

2.5. Grundlagen zu Microsoft Exchange

Microsoft Exchange ist ein Managementsystem für Nachrichten, das überdies Funktionen im Bereich der Workflow-Unterstützung bietet: Microsoft Exchange ist unter anderem dazu gedacht, in mittleren bis großen Behörden bzw. Unternehmen den internen und externen Austausch von Nachrichten, wie z. B. E-Mails, zu ermöglichen. Die Nachrichten können mit Exchange verwaltet, zugestellt, gefiltert und versendet werden. Ebenso werden typische Kommunikationsanwendungen wie Newsgroups, Ka­lender, Aufgabenlisten und Unified Messaging angeboten und von Exchange verwaltet.

Microsoft Outlook ist ein E-Mail-Client, der Bestandteil des Office-Paketes von Microsoft ist. Neben der reinen E-Mail-Funktion bietet Outlook eine Reihe von Zusatzfunktionen, die Kommunikationab­läufe und Messaging innerhalb von Geschäftsprozessen in Unternehmen und Behörden erleichtern sollen.

Es handelt sich hierbei um eine typische Client-Server-Anwendung, wobei Microsoft Exchange die Server- und Microsoft Outlook die Client-Komponente darstellen.

Microsoft-Exchange-Systeme, im Weiteren als Kurzfassung für die Betrachtung einer Exchange-Ser­ver- und Outlook-Client-Anwendung angeführt, werden in Unternehmen und Behörden eingesetzt, um interne und externe Unternehmens- bzw. Behörden- und Kommunikationssabläufe zu integrieren und elektronisch zu unterstützen. Diese Eigenschaften werden auch unter dem Begriff Groupware zusam­mengefasst.

Microsoft bietet eine umfangreiches Sortiment an Anwendungen, Komponenten und Erweiterungen an, so dass mit dem Begriff „Microsoft-Exchange-System“ nicht eindeutig eine bestimmte Referenz­installation oder Gruppe von Komponenten gekennzeichnet werden kann. Im Rahmen dieser Arbeit kann daher nicht auf alle verfügbaren Microsoft-Produkte eingegangen werden; die Darstellung be­schränkt sich im Folgenden auf typische und in der Praxis häufig anzutreffende Installationen.

Ein kurzer Überblick über Microsoft-Exchange-Systeme und wichtige Fachbegriffe aus dem Microsoft Exchange-Umfeld finden sich im nachfolgenden Abschnitt.

2.5.1. Aufbau und Funktionsumfang derServer-Anwendung

Ein Beispiel für ein typisches Microsoft-Exchange-System ist ein Microsoft-Exchange-Server 2010 mit den Komponenten Client-Zugriffsserver, Hub-Transport-Server, Postfachserver und Unified- Messaging-Server. Auf der Client-Seite kommt typischerweise Microsoft Outlook aus der Microsoft- Office-Familie zum Einsatz. Weitere Bestandteile der aktuellen Exchange-Version, derzeit Exchange 2010, sind der Edge-Transport-Server und der globale Katalogserver (Abbildung 4). Als Erweiterung bietet sich beispielsweise Microsoft Sharepoint als Datenintegrationsplattform an. Microsoft System Center Operation Manager ist im Bereich der Dienste-Überwachung angesiedelt und Microsoft Data Protection Manager bietet integriertes Back-up-Management an.

Der strukturelle und topologische Aufbau eines typischen Microsoft-Exchange-Systems ist insbeson­dere vom Einsatzszenario abhängig: Die Bandbreite von Topologien kann sich von kleinen Unterneh­men und Behörden, die normalerweise über einen einzigen Server verfügen, auf dem alles ausgeführt wird, bis hin zu großen Unternehmen und Behörden, die normalerweise getrennte Server für einzelne Funktionen und Liegenschaften haben, erstrecken (Abbildung 4). Dieser unterschiedliche Aufbau spiegelt sich ebenfalls in der Active-Directory-Standort-Topologie wider: Das Microsoft-Exchange- System basiert und integriert den Verzeichnisdienst Active-Directory. Der Integrationsgrad steigt mit jeder Version von Microsoft Exchange [MIC06]. Der Verzeichnisdienst kann auf mehrere Katalogser­ver verteilt sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Typisches Microsoft-Exchange-System mit zwei Standorten

Ein Microsoft-Exchange-System unterscheidet den Bereitstellungsort des Dienstes und den Ort der In­anspruchnahme des Dienstes: Ein Dienstbereitstellungsort (Service Delivery Location - SDL) bezieht sich auf einen physikalischen Ort, an dem sich Microsoft Exchange und andere Server befinden. Ein SDL muss alle abhängigen Dienste bieten, die von Microsoft Exchange benötigt werden; neben einer lokalen Netzinfrastruktur (Local Area Network - LAN) gehört die Namensauflösung (Domain Name System - DNS) und die Bereitstellung von Verzeichnisdiensten unter Verwendung von Active- Directory-Domänencontrollern bzw. globalen Katalogservern zu den unverzichtbaren Standortfakto­ren.

In Abbildung 4 wird der DNS-Dienst, die Funktionen der Domänencontroller und Verzeichnisdienste, von den Globalen Katalogservern S-GC_01 und S-GC_02 bereitgestellt. Optional enthalten SDLs auch öffentliche, externe Netzverbindungen und entmilitarisierte Zonen (Demilitarized Zones - DMZ) bzw. Perimeternetze. Ein SDL kann aus einem oder mehreren Subnetzen bestehen und einen oder mehrere Active-Directory-Standorte enthalten. SDLs entsprechen einem einzelnen physikali­schen Gebäude oder einer dedizierten Umgebung mit einem allgemeinen Backbone-Netz; SDLs sind immer durch eine Weitverkehrsnetzverbindung (Wide Area Network - WAN) voneinander getrennt. In Abbildung 4 ist diese Verbindung durch die Standortverknüpfung charakterisiert: In der Darstel­lung werden die Standorte A und B über ein weiteres Perimeternetz voneinander getrennt.

Auf einen SDL kann eine kollektive Gruppe von Clients von einem Ort zugreifen (Client Service Lo­cation - CSL). Ein CSL kann sich am selben Ort wie ein SDL - CSL A und B - oder an einem vom SDL getrennten Ort - CSL C - befinden. Ein CSL umfasst dabei auch Geräte, die ein gängiges Client­Zugriffsprotokoll über ein öffentliches Netz verwenden (Abbildung 4).

Zu dem typischen Funktionsumfang eines Microsoft-Exchange-Systems an einem SDL gehören neben der Bereitstellung von E-Mails, der Verwaltung von Terminen in Kalendern, dem Verwalten von Auf­gaben, Kontakten und Adressen auch die Ablage von Dokumenten sowie Notizen. Ein Client kann
von einem CSL über Microsoft Outlook oder Outlook Web Access (OWA) den Funktionsumfang eines Exchange-Servers nutzen. Mit OWA kann nicht der volle Funktionsumfang genutzt werden, was in der Natur von Web-Clients begründet ist. Gängige E-Mail-Clients - basierend auf POP3 (Post Office Protocol, Version 3), IMAP4 (Internet Message Access Protocol, Version 4revl) sowie SMTP (Simple Mail Transfer Protocol) - sind indes auf die E-Mail-Funktionen beschränkt. Für eine detaillierte Beschreibung der E-Mail-Protokolle sei auf die RFC-Dokumente der Internet Engineering Task Force (IETF) - [MMR96], [CRI03] und [KLE08] - verwiesen.

Das Microsoft-Exchange-System bietet laut [MIC09T], [MIC09S] und [BRE08] mit dem ActiveSync- Protokoll ein verbreitetes proprietäres Synchronisierungsprotokoll für mobile Geräte. Sicherheitsfunk­tionen hinsichtlich Vertraulichkeit und Integrität bietet Exchange über die zertifikatsbasierte Authenti- fizierung und Verschlüsselung über eine Public-Key-Infrastruktur (PKI) mit der Unterstützung für Se­cure/Multipurpose Internet Mail Extensions (S/MIME) [GMC95], die Unterstützung für das Sender-ID-E-Mail-Authentifizierungsprotokoll [MIC07U] und die Leitungsverschlüsselung zwischen Client und Server. Die Interoperabilität wird mit sogenannten Konnektoren für Drittherstellerprodukte und durch weitere Transportprotokolle in Microsoft Exchange gesichert.

Neben einem Anti-Spam-Filter werden auch Annahme- und Verweigerungslisten (White- / Blacklists) verwaltet [WIK09]. In diesem Zusammenhang sei auf die rechtliche Übersicht zu Spam und dessen Filterung in [ROT08] verwiesen.

Neben der geografischen Einordnung von Microsoft-Exchange-Systemen werden ebenfalls die physi­kalischen Topologien betrachtet; die Beschreibung eines Netzes über die Verteilung von Serverdienst­en und -rollen auf physikalische Elemente geht von SDLs mit einem Server, mit mehreren Servern bis hin zu mehreren Standorten. Dabei können die Serverdienste zentralisiert oder verteilt sein.

Microsoft-Exchange-Systeme unterscheiden sich zum Teil erheblich in den Ausprägungen und Ver­sionen. Einen Überblick über Änderungen, neue und nicht mehr unterstützte Funktionen geben die nächsten Abschnitte.

2.5.2. Versionshistorie des Microsoft-Exchange-Servers

Microsoft-Exchange-Systeme haben einige Evolutionsschritte bis hin zu der aktuellen Version Micro­soft Exchange Server 2010 durchlaufen. Ein Vergleich der wesentlichen Veränderungen und Verbes­serungen seit der Version 2000 soll nachfolgend dargestellt werden. Die Versionsnummern, d. h. 2000, 2003, 2007 und 2010, sind von den Veröffentlichungsterminen der Software abgeleitet und wer­den typischerweise verwendet [WIK09]. Man findet auch Kurzformen wie Exchange2k, Exchange2k3 usw. in Fachdiskussionsforen. Neben den Versionsschritten werden zu gegebenem Anlass auch so ge­nannte Servicepacks (SP) veröffentlicht; diese enthalten kumulierte Sicherheitspatches und erweitern ggf. Funktionen. Im Weiteren werden auch Hinweise zu den aktuellen Servicepacks gegeben.

2.5.2.1. Microsoft Exchange Server 2003

Wesentliche Veränderungen zu der Vorgängerversion - Microsoft Exchange Server 2000 - haben sich zu der Version 2003 nicht ergeben, da auf der gleichen Quellcodebasis entwickelt wurde. Nennens­werte Änderungen ergeben sich vor allem im Zusammenhang mit der Nutzung eines Windows­Server-Betriebssystems ab Version 2003 und von Microsoft Outlook ab Version 2003 [MIC06L].

Für eine Übersicht der Microsoft-Exchange-2000-Funktionen, die entweder eingestellt oder in andere Produktlinien integriert wurden, sei auf [MIC06L] verwiesen. Hervorzuheben ist die Verlagerung zahlreicher Funktionen für die Zusammenarbeit in Echtzeit, z. B. Chat, Instant Messaging, Konferen­zen und Multimedia-Messaging auf den Microsoft Live Communications Server bzw. Microsoft Offi­ce Communications Server [MIC07D]. Diese Funktionen sind in Microsoft Exchange Server 2003 nicht mehr vorhanden [MIC06L]. Gegenüber dem Schlüsselverwaltungsdienst für sicheren E-Mail­Versand unter Microsoft Exchange 2000 steht nun eine Standard-X.509v3-Zertifikatsimplementierung [CSF08] für PKI-Lösungen zur Verfügung, die X.509v3-Zertifikate unterstützen.

Microsoft Exchange Server 2003 muss mindestens auf einem Windows-Server-Betriebssystem der Version 2000 (SP3) ausgeführt werden; erst mit einem Server-Betriebssystem ab der Version 2003 kann Microsoft Exchange Server die damit verbundenen Vorteile nutzen, wie z. B. geringere Band­breitennutzung bei der Replikation der Verzeichnisdienste, durchgängige Kerberos-Authentifizierung und Snapshot-Datensicherungen [М1С061]. Im Gegenzug unterstützt Windows Server 2003 die Installation der Version 2000 des Exchange-Servers nicht mehr [MIC06L].

Die Verwaltung des Exchange-Servers, d. h., Anlage und Pflege von Benutzern, E-Mail-Postfächern und Verteilergruppen werden vollständig über den Verzeichnisdienst abgebildet; die Integration wird durch eine Active-Directory-Schema-Erweiterung bei der Installation des Microsoft Exchange Servers realisiert [WIK09]. Eine Einführung in das Thema Schema-Erweiterung bieten [MIC09U] und [CAR01].

Als Reaktion auf die zunehmende SPAM-Flut und unerwünschte Massen-E-Mails ist mit dem Intelli­gent Message Filter (IMF) erstmals eine Filterung implementiert. Daneben wurden die Antispam-Lö­sungen mit Sender-ID und der Unterstützung für globale Annahme- und Verweigerungslisten sowie in Echtzeit abfragbare Verweigerungslisten (Real Time Block List - RBL) verbessert.

Auch in Belangen der Informationssicherheit arbeitet Microsoft Exchange Server 2003 mit bewährten Techniken wie der Leitungsverschlüsselung mit Internet Protocol Security (IPSEC) [FSC03] zusammen; somit kann die Verschlüsselung zwischen einem Frontend- und Backendserver [MIC06I] realisiert werden. Auf höherer Ebene wird zwischen dem Frontendserver und mobilen Clients, wie beispielsweise Geräten, die ActiveSync und mobilen Internetzugang unterstützen, eine 128-Bit-SSL- Verschlüsselung angeboten. Über Outlook Mobile Access (OMA) oder ActiveSync stehen die Funktionen E-Mail, Adressbuch, Kalenderverwaltung, Aufgaben und Notizen über das Internet zur Verfügung [WIK09].

Daneben ist in puncto Verfügbarkeit auch die Wiederherstellung einer Microsoft-Exchange-Daten- bank über die sogenannte Recovery Storage Group in einem produktiven System möglich. Auch die Überwachung von Microsoft Exchange ist nun mit über 1700 Regeln ein effektives Werkzeug, um Protokolle auszuwerten.

Um mobile Microsoft Exchange-Nutzer ohne vorhandene VPN-Infrastruktur an das Unternehmens- bzw. Behördennetz anzuschließen, gibt es mit der Unterstützung für Remote Procedure Calls über das Hypertext Transfer Protocol (RPC-über-HTTP) eine Möglichkeit, dass Benutzer über das Internet eine direkte Verbindung mit dem Microsoft Exchange Server herstellen können [MIC06L].

Eine Übersicht über die Änderungen, die sich durch SP1 und SP2 ergeben haben, gibt [MIC09].

2.5.2.2. Microsoft Exchange Server 2007

Die grundlegende Änderung zur Vorgängerversion besteht im konsequenten Umstieg auf die 64-Bit- Architektur (2.5.3). Durch den Architekturumstieg kann wesentlich mehr Hauptspeicher verwaltet werden; so können z. B. drei bis viermalgrößere Benutzerpostfächer oder eine drei- bis viermal höhere Anzahl von Benutzern pro Server verwaltet werden.

Daneben führt Microsoft Exchange 2007 ein wichtiges neues Konzept, das der Serverfunktionen bzw. -rollen ein: Im Gegensatz zu einer zentralen Installation von Microsoft Exchange Server können nun verschiedene Serverfunktionen dediziert ausgewählt werden. Diese Segmentierung erlaubt die logi­sche Zusammenfassung von Aufgaben in Gruppen. Neben der zentralen Mailbox-Funktion, die für die Bereitstellung der Benutzerpostfächer in Postfachdatenbanken und Datenbanken der öffentlichen Ordner zuständig ist, wird über die Client-Access-Rolle der Postfachzugriff über OWA, POP3, IMAP4, Outlook Anywhere - unter Microsoft Exchange 2003 noch RPC-über-HTTP genannt - und Exchange Server ActiveSync ermöglicht. Die so genannte Hub-Transport-Serverrolle ist für das Rou­ting zwischen verschiedenen Standorten zuständig und wendet Richtlinien auf eingehende und ausge­hende E-Mail-Nachrichten an. Microsoft Exchange Server 2007 bietet in der Serverfunktion Unified Messaging Sprachkommunikation, Fax- und E-Mail-Messaging kombiniert und integriert an; Benut­zer können auf die Funktionen von einem Telefon und von einem Computer aus zugreifen. Zusätzlich kann die Edge-Transport-Serverrolle für den Schutz vor Schadprogrammen, Spam und zur Absiche­rung der Exchange-Infrastruktur in einer DMZ untergebracht werden [JS08].

Einen Überblick über die Microsoft-Exchange-Rollen der Version 2007 gibt [KRÖ07B].

Die Administrationstätigkeiten können unter Microsoft Exchange 2007 in einer Kommandozeilenum­gebung, auch Exchange-Verwaltungsshell oder -Powershell genannt, ausgeführt werden. Dabei sind alle Befehle und Verwaltungsoptionen erreichbar; beispielsweise lassen sich neue E-Mail-Konten an­legen oder mobile Geräte deaktivieren. Über Skripte mit Befehlsabfolgen lassen sich so Verwaltungs­aufgaben bequem automatisieren. Eine grafische Administrationsoberfläche mit reduziertem Befehls­umfang steht neben der Powershell parallel zur Verfügung. Die Unterstützung von administrativen Gruppen fällt in Microsoft Exchange Server 2007 aufgrund neuer Zugriffs- und Verwaltungskonzepte weg; aus Kompatibilitätsgründen werden bestehende administrative Gruppen aus einer Migration aber weiterhin mitgeführt [JS08].

Mit Microsoft Exchange 2007 werden asynchrone Replikationsmöglichkeiten unterstützt: Neben der Produktivumgebung wird eine Kopie der Speichergruppen kontinuierlich mit den Änderungen über Protokolldaten versorgt und so repliziert. Hierdurch können die normalen Datensicherungsvorgänge reduziert werden. Dabei kann sowohl eine lokale Redundanz in Form der fortlaufenden lokalen Repli­kation (Local Continuous Replication - LCR) und eine Data-Center-Redundanz über die fortlaufende Clusterreplikation (Cluster Continuous Replication - CCR) sichergestellt werden [MIC07L]. Als wei­teres Verfahren wird in SPI die fortlaufende Stand-by-Replikation (Standby Continuous Replication - SCR) angeboten.

Für eine Übersicht typischer Microsoft-Exchange-2007-Systeme sei auf [MIC06k] und [JS08] verwie­sen.

2.5.2.3. Microsoft Exchange Server 2010

Microsoft Exchange 2010 wurde optimiert für die Deployment-Szenarien, in denen die Exchange­Dienste innerhalb einer Organisation betrieben werden, so genannte „On-Premise“-Installationen; dar­über hinaus können die Exchange-Dienste auch „on-demand“ als externe Dienstleistung - Exchange Online - bereitgestellt werden. Microsoft selbst betreibt Rechenzentren, in denen Exchange Online betrieben und angeboten wird. Die Optimierung geht allerdings auch soweit, als dass „On-Premise“- Installationen nahtlos zusammen mit Exchange Online betrieben werden können; damit ist die Inte­gration von getrennten Exchange-Organisationen und die Skalierbarkeit durch Zukauf von Exchange- Online-Diensten äußerst flexibel. Ein weiteres Highlight ist die integrierte Archivierungsfunktion für Nachrichten: Damit ist ein einheitlicher Schutz von Informationen und die Einhaltung von Richtlinien im E-Mail-Archiv realisiert; die neue Funktion erleichtert die Speicherung und das Wiederauffinden von E-Mails im gesamten Unternehmen bzw. der gesamten Behörde mithilfe der intuitiven Exchange­Oberfläche [MAN09].

Die Datenbanken zum Verwalten der Informationsspeicher von Microsoft Exchange Server 2010 wur­den in ihrem Zugriffsverhalten umgestellt: Die Input-Output-Vorgänge auf den Festplattenspeichern waren vor der Version 2010 durch den kostspieligen Random-Access-Zugriff gekennzeichnet. Für diese Zugriffsart waren hochverfügbare und zuverlässige Festplattenverbünde (Abbildung 5) notwendig. Durch die Umstellung auf Microsoft Exchange 2010 sind nunmehr auch günstige SATA- Festplattenspeicher für den Einsatz als Informationsspeicher für die Datenbanken möglich: Microsoft Exchange 2010 verwendet sequenziellen Zugriff für die Verwaltung der Daten. Die Sicherstellung der Integrität und Verfügbarkeit wird über die Architektur des Microsoft-Exchange-Kerns realisiert: Wie­derherstellungsfunktionen nach Katastrophen und Hochverfügbarkeitsoptionen sind aus den Erfahrun­gen mit CCR und SCR in eine einzige Lösung kombiniert worden. Neben dieser Lösung sind die Möglichkeiten LCR, SCC und das Clustern der Mailboxserver obsolet. Der Paradigmenwechsel der Serverrollenaufteilung zieht sich nun konsequenterweise bis hin zu den Datenbanken: Einzelne Post­fachserver können zu Datenbank-Verfügbarkeitsgruppen (Data Availability Groups - DAG) verbun­den werden; diese bieten nun automatische Wiederherstellung auf logischer Postfachebene anstatt auf physikalischer Serverebene [MIC09R]. Damit entfallen konzeptuell auch die Speichergruppen, da die Postfachdatenbanken nun nicht mehr mit dem Microsoft Windows Server verbunden sind, sondern unabhängig verwaltet werden. Die Neuerungen treffen nicht auf die Informationsspeicher von öffent­lichen Ordnern zu.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Microsoft Exchange Server - Datenspeicherunterstützung [MIC09R]

Wichtige Neuerungen ergeben sich durch die Transport- und Routing-Funktionen in Microsoft Exchange Server 2010: Nunmehr sind Workflow-Genehmigungsprozesse innerhalb der E-Mail- Anwendung umsetzbar; das Konzept der „Shadow-Redundanz“ im Nachrichtentransport verhindert den Nachrichtenverlust innerhalb des Routings, indem der Absendeserver eine Kopie der versendeten Nachrichten zurückhält, bis der nächste Kommunikationspartner die Auslieferung bestätigt. Die Routing-Funktionen ermöglichen die Verknüpfung von mehreren Exchange-On-Premise- Installationen - „Cross-Premises“ - und Exchange-Online-Diensten. Routingoptionen, wie z. B. das Verhindern einer Weiterleitung oder das Verschlüsseln von Inhalten, werden über Regeln (Rights Management Services - RMS) implementiert. Diese können auch über die Exchange-Organisation bzw. SDLs hinaus mit entsprechenden Vertrauensstellungen realisiert werden.

Mit Microsoft Exchange Server 2010 wurde die Web-Unterstützung in Form von OWA stark ausgebaut: Die native Unterstützung der wichtigsten Marktbegleiter-Browser „Safari“ und „Firefox“ konnte durch die konsequente Vermeidung von Microsoft-spezifischen aktiven Inhalten und Erweiterungen umgesetzt werden. Weiterhin können die Administrationstätigkeiten (Exchange Control Panel - ECP) nun über die gleiche bekannte Web-Oberfläche von OWA durchgeführt werden. Granulare Rollen und Aufgabenzuordnungen für unterschiedliche Administratorrollen und Administration durch Benutzer, wie z. B. die Anlage eines neuen Mitarbeiters oder die Verwaltung von Verteilerlisten, können über das Konzept der rollenbasierten Zugriffskontrolle (Role Based Access Control - RBAC) verwaltet werden. Insgesamt orientiert sich der Funktionsumfang der OWA- Oberfläche nun deutlich stärker an der des Outlook-Software-Clients (2.5.4).

Einen Überblick über die überarbeiteten Microsoft-Exchange-Rollen der Version 2010 gibt [MIC08J].

2.5.3. Ausprägungen des Microsoft-Exchange-Servers

Microsoft Exchange Server wird jeweils als Standard- oder Enterprise-Edition ausgeliefert. Mit den Editionen werden funktionale Einschränkungen über entsprechende Lizenzen realisiert: Unterschiede ergeben sich meist durch die Anzahl der Speichergruppen, die Möglichkeit, mehrere Datenbanken zu verwalten, die maximale Größe von Datenbanken und die Hochverfügbarkeitsoptionen, wie z. B. Clustering [WIK09]. Die Ausprägungen werden anhand der in 2.5.2 angeführten Aufteilung beschrie­ben.

2.5.3.1. Microsoft Exchange 2003

Die Standard-Edition des Microsoft-Exchange-Servers 2003 ist für den Einsatz in kleineren Firmen optimiert; diese Edition kann nur eine Speichergruppe mit zwei Datenbanken zuje 16 Gigabyte (GB) verwalten. Die Enterprise-Edition bietet die Möglichkeit, bis zu vier Speichergruppen mitjeweils fünf Datenbanken zuje 16 Terabyte (TB) zu verwalten und ist damit ausreichend dimensioniert für große Unternehmen und besondere Anforderungen: [WIK09] und [KRÖ05] heben die Einbindung von Konnektoren hervor, die Protokolle von Drittherstellern oder X.400 bereit stellen. Daneben wird auch Hochverfügbarkeit durch den Betrieb mehrerer Server in einem Cluster gewährleistet.

Microsoft Exchange Server 2003 ist ausschließlich auf 32-Bit-Betriebssystemen lauffähig; dabei kommt entweder 32-Bit-Hardware (x86) oder x64-basierte Hardware, die mit 32-Bit-Anwendungen abwärtskompatibel ist, infrage [MIC06L].

2.5.3.2. MicrosoftExchange 2007

Die Standard-Edition des Microsoft-Exchange-Servers 2007 ist für kleine und mittlere Unternehmen zugeschnitten. Weiterhin ist das Lizenzmodell für einzelne dedizierte Serverrollen oder kleinere Nie­derlassungen eine Option. Während die Standard-Edition auf fünf Datenbanken pro Server beschränkt ist, ermöglicht die Enterprise-Edition die Verwaltung von bis zu 50 Datenbanken und die Bereitstel­lung in einem Microsoft Windows Failovercluster.

Die Aufteilung in zwei Editionen ist auch aufgrund der Lizenzierungsbestimmungen in Client­Zugriffslizenz-Editionen (Client Access License - CAL) erfolgt; CALs werden durch einen Produktschlüssel definiert. Für Details sei auf [MIC07] verwiesen.

Mit Microsoft Exchange Server 2007 wird die 32-Bit-Version nicht mehr als Produktivumgebung un­terstützt: Für Testumgebungen wie Labor-, Demonstrations- und Schulungsumgebungen kann die 32-Bit-Version weiterhin eingesetzt werden. Nunmehr ist die 64-Bit-Version für aktive Produktivum­gebungen vorgesehen. Hauptvorteil der nativen Unterstützung von 64-Bit-Betriebsystemen und -Hardware ist die Möglichkeit der Verwaltung von mehr als 4 GB Hauptspeicher im Betrieb des Ex­change-Servers [MIC08]. Daraus resultieren separate Sätze von Installationsmedien und Binärdateien für x64-Systeme sowie x86-Systeme.

2.5.3.3. Microsoft Exchange 2010

Die Unterschiede der Standard- und Enterprise-Editionen verhalten sich analog zu denen des Microsoft-Exchange-Servers 2007. Abweichend hierzu ist die Enterprise-Edition des Microsoft- Exchange-Servers 2010 erst auf Servern ausführbar, die mehr als fünf Datenbanken verwalten, und skaliert bis zu 100 Datenbanken pro Server. Dafür sind die Hochverfügbarkeitsoptionen über DAGs nun bereits in einer Standard-Edition-Lizenz einsetzbar [MIC09I].

Als Architektur- und Weiterentwicklungskonsequenz existiert in Microsoft Exchange Server 2010 ausschließlich die 64-Bit-Version, die auf einem 64-Bit-Microsoft-Betriebssystem, wie z. B. die x64- Version von Microsoft Windows Server 2003 oder die 64-Bit-Versionen des Microsoft Windows Servers 2008, ausgeführt werden muss. Der Migrationsschritt aus einer reinen 32-Bit-Server- Infrastruktur in die 64-Bit-Anforderungen wird z. B. in [FOL09] kontrovers diskutiert.

2.5.4. Aufbau und Funktionsumfang der Client-Anwendung

Microsoft Outlook ist eine Anwendung, die als E-Mail-Client, Kollaborationswerkzeug und zum Ver­walten von persönlichen Informationen (Personal Information Manager - PIM) eingesetzt wird. Unter Mac OS von Apple bietet Microsoft mit Entourage eine vom Funktionsumfang ähnliche Anwendung an. In Verbindung mit dem Microsoft Exchange Server kann Outlook den vollen Funktionsumfang nutzen: Terminverwaltung, die Abstimmung von Besprechungen sowie die Verwaltung von mehreren Teilnehmern, Ressourcen und Räumen mit Terminüberschneidungen sind der Microsoft-Exchange Server-Verbindung vorbehalten. Microsoft Outlook bietet Kontaktdatenbanken sowie eine Notizen- und Aufgabenverwaltung unter einer Oberfläche an. Die Teilanwendungen sind dabei untereinander verzahnt und ermöglichen so beispielsweise die automatische Verwaltung von Geburtstagen der Kon­takte in der Kalenderansicht. Allerdings kann Outlook auch ohne Microsoft Exchange Server verwen­det werden, da die verbreiteten Internetprotokolle POP3, IMAPv4 und SMTP für die E-Mail-Funktion unterstützt werden.

Microsoft Outlook wird als Teil des Microsoft-Office-Pakets angeboten und ist hier komplementär in­tegriert [WIK09D].

2.5.5. Versionshistorie von Microsoft Outlook

2.5.5.1. Microsoft Outlook 2002

Charakteristisch an Outlook 2002 ist die neue interne Architektur; diese unterstützt nun den „Unified Mode“; während in Microsoft Outlook 2000 eine nachhaltige Unterscheidung des Einsatzszenarios - „Nur via Internet“, „Unternehmen“ oder „Keine-E-Mail-Nutzung“ - bereits während der Installation stattfand, ist nun die Wahl des Einsatzszenarios flexibel nach der Installation möglich [HOF99]. Ver­besserungen im Antwortverhalten der Anwendung ergeben sich durch eine Vergrößerung der RPC- Blöcke, die eine geringere Netz-Belastung mitbringt und die Möglichkeit zum Sendeabbruch von RPC-Anforderungen, falls der Exchange-Server nicht reagiert.

Neben funktionalen Erweiterungen, wie z. B. der Unterstützung von E-Mail-Konten über HTTP, der Authentifikation gegenüber Postausgangsservern und der Möglichkeit zur Unterdrückung von auto­matisierten Lesebestätigungen, sind auch Usability-Funktionen wie die Integration von Instant-Messa­ging und die Zusammenfassung von Erinnerungen in einem zentralen Dialogfenster hinzugekommen. Neben Funktionserweiterungen wurden allerdings nach [SLI09] und [KIE03] Konzepte wie Netzordner bzw. Arbeitsgruppenlösungen ohne Microsoft Exchange Server - MS-Mail-Postoffice - verworfen.

Für eine Übersicht der neuen Funktionen sei auf [KIE03] verwiesen.

2.5.5.2. Microsoft Outlook 2003

In erster Linie fällt bei Microsoft Outlook 2003 die überarbeitete grafische Benutzeroberfläche auf, die mehr Benutzerfreundlichkeit und effektiveres Arbeiten ermöglichen soll: Typischerweise findet sich links die Navigationsleiste, rechts ein Vorschau-Lese-Fenster in der E-Mail-Ansicht, und in der Mitte werden die Listenelemente dynamisch sortiert (Abbildung 6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Typische Aufteilung der Benutzungsoberfläche unter Microsoft Outlook 2003

Als E-Mail-Composer ist Microsoft Word 2003 aus dem zugehörigen Microsoft-Office-2003-Paket voreingestellt. Gerade in Kombination mit Microsoft Exchange Server 2003 werden neue Funktionen eingeführt: So werden ein intelligenter Abwesenheitsassistent und diffizile Nachrichtenregeln direkt auf dem Microsoft Exchange Server abgearbeitet. Auch in Sachen Gruppenzusammenarbeit wurden einige Neuerungen implementiert [WIK09]. Die Kombination mit Exchange-Server 2003 bietet nun die Möglichkeit, eine lokale Offline-Kopie der Postfachdaten im sogenannten „Cached-Mode“ anzule­gen, die sich bei Bedarf mit dem Exchange-Server synchronisiert und bei Verbindungstrennungen weiterhin die Arbeit mit Microsoft Outlook gewährleistet.

Mit Microsoft Outlook 2003 wird die Speichergrenze für die lokalen Outlook-Datenbanken - lokale PST und Offline-OST-Datenbanken - von zwei GB auf vier TB mithilfe des Unicode-Formats ange­hoben. Das neue Format ist nicht abwärtskompatibel zu Microsoft Outlook 2000 oder niedriger.

Die Verbindung mit Microsoft Exchange Server 2003 wird nun über das sogenannte RPC-über- HTTP(S)-Protokoll hergestellt: Microsoft Outlook 2003 kapselt die Daten - die RPC's - zwischen Server und Client in HTTP(S)-Datenströmen, die von Sicherheitsgateways und Paketfiltern typischer­weise durchgelassen werden. Auf diese Art ist eine verschlüsselte Verbindung zwischen Microsoft Exchange Server 2003 und einem Microsoft-Outlook-2003-Client von einem beliebigen Internetan­schluss realisierbar.

Aufgrund der Neuerungen in Bezug auf die Synchronisation zwischen Server und Client werden beim Abgleich nicht mehr ganze Dateordner synchronisiert, sondern einzelne Elemente, wie beispielsweise E-Mails und Notizen. Zusätzlich wirkt sich die Komprimierung der Datenpakete positiv auf die genutzte Netzbandbreite aus.

Für eine weitergehende Übersicht sei auf [KIE04] und [SLI09A] verwiesen.

2.5.5.3. Microsoft Outlook 2007

In Microsoft Outlook 2007 haben sich diverse Neuerungen in Hinblick auf ortsunabhängige und platt­formübergreifende Verbindungen mit anderen Personen durchgesetzt: Die Freigabe des Kalenders ist nun vereinfacht, Really Simple Syndication (RSS) wird nativ unterstützt und Microsoft Windows SharePoint Services 3.0 können integriert werden [WEI09A].

Ab Version 2007 werden in den Kontakten von Office Outlook 2007 japanische Yomi-Namen - die Speicherung der phonetischen Lautschrift - und internationale Domänennamen in E-Mail-Adressen unterstützt.

Zum Schutz der in Microsoft Outlook 2007 verwalteten Informationen werden Funktionen gegen Spam- und Phishing-Mails erweitert sowie neue Möglichkeiten angeboten: Mit E-Mail-Siegeln von Outlook können normale E-Mails von Massen-E-Mails unterschieden werden und mit dem Konzept der verwalteten E-Mail-Ordner können in Zusammenhang mit dem Exchange-Server 2007 Richtlinien zur Archivierung, Aufbewahrung und Speicherung realisiert werden.

Neben den verwalteten Ordnern wird ein Schutz- und Zugriffskonzept auf Elementebene angeboten: Mit der Verwaltung von Informationsrechten (Information Rights Management - IRM) können Richtlinien zum Schutz von E-Mail-Nachrichten vor unautorisiertem Zugriff bzw. unautorisierter Ver­wendung umgesetzt werden. Vor allem kann über IRM geregelt werden, welchen Personen Zugriff auf eine E-Mail-Nachricht gewährt werden soll und ob diese Personen zum Bearbeiten, Kopieren, Weiterleiten und/oder Drucken der Inhalte berechtigt sind [MIC09D].

Mit dem übergreifenden Konzept der Microsoft-Office-Diagnose aus der Version 2007 können auch Ursachen für Programmabstürze innerhalb von Microsoft Outlook 2007 diagnostiziert werden; stürzt während der Arbeit an mehreren Dateien der Client-PC ab, stellt Office-Diagnose die Dateien in der ursprünglichen Form wieder her [WEI09A].

In Kombination mit dem Microsoft Exchange Server 2007 können im Outlook-Posteingangsordner sowohl Voicemails als auch Telefaxe empfangen werden [MIC09D].

Für eine Übersicht der Neuerungen in Microsoft Outlook 2007 sei auf [MIC09D] verwiesen.

2.5.5.4. Microsoft Outlook 2010

Mit Microsoft Outlook 2010 werden die Konzepte und Strategien zur Benutzerfreundlichkeit und In­tegration der Kommunikationsmöglichkeiten weiter ausgebaut: Voicemails werden in der Vorschau des Posteingangs direkt von natürlicher Sprache in lesbaren Text umgewandelt und angezeigt [MAN09]. Auch die in Office 2007 eingeführte Ribbon-Oberfläche (Abbildung 7) für die anderen Office-Anwendungen wird nun in Outlook integriert [ECK09].

Die neue Funktion „MailTips“ verhindert das Versenden von unnötigen E-Mails oder warnt vor even­tuellen Missverständnissen beim Versenden an große Verteilergruppen oder externe Empfänger.

Mit den Funktionen „Clean Up“ und „Ignore“ können im Posteingang nunmehr Thread-basierte Zu­sammenfassungen der E-Mail-Nachrichten im Posteingang zur Verfügung gestellt werden und uner­wünschte Nachrichtendiskussionen ignoriert werden [JAN09].

Für eine Übersicht der Neuerungen in Microsoft Outlook 2010 sei auf [MIC09i]verwiesen.

2.5.6. Ausprägungen von Microsoft Outlook

Neben der normalen Microsoft Outlook Version gibt es eine Version mit dem Business Contact Ma­nager, dessen Funktionen zur Kunden- und Kontaktverwaltung auch mit der Versionshistorie (2.5.5) der Microsoft-Office-Pakete verändert und erweitert wurden. Auf die Ausführungen gehen [MIC09x], [MIC09H] und [WIK09D] näher ein.

Als Architektur- und Weiterentwicklungskonsequenz analog zu Microsoft Exchange Server wird nun auch im Client-Bereich eine 64-Bit-Version von Microsoft Outlook 2010 angeboten, die auf einem 64-Bit-Microsoft-Betriebssystem, wie z. B. der x64-Version von Microsoft Windows XP (SP3), Microsoft Windows Vista oder Microsoft Windows 7 ausgeführt werden kann. In der aktuellen Versi­on existieren beide Plattformen - 32- und 64-Bit - gleichberechtigt nebeneinander [SHA09]. Es ist al­lerdings nicht möglich, eine 32-Bit-Version von Microsoft Office 2007 mit einer 64-Bit-Version von Microsoft Office 2010zu aktualisieren [ECK09].

3. Versionsabhängigkeit der IT-Grundschutzbausteine

Die Umfrageergebnisse und Erfahrungswerte zeigen (Anlage 1), dass die Realisierungszyklen selbst und die Vielfalt der Baustein-Baustellen die Versionsabdeckung innerhalb der IT-Grundschutzkatalo- ge unzureichend abdecken kann. Erschwerend kommt hinzu, dass die Bausteine teilweise so spezi­fisch ausgelegt sind, dass eine Abstraktion auf jüngere Versionen im Rahmen der Modellierung [BSI08-1002] nur bedingt möglich ist. Diese Problematik wird auch nicht mit dem bisherigen Ver­ständnis der IT-Grundschutzkataloge lösbar sein. Zukünftige Veröffentlichungen müssen sich daher noch intensiver mit der Versionsproblematik und entsprechender Abstraktion beschäftigen. Die Pro­blemstellung ist auf die IT-Grundschutzbausteine beschränkt und betrifft nicht die übergeordneten Standards.

3.1. Ausprägungen der Versionsabhängigkeit

Der Untersuchungsbericht für die Markierung abhängiger IT-Grundschutzbausteine aus der 10. Ergän­zungslieferung der IT-Grundschutzkataloge zeigt, dass von 74 Bausteinen 17 Modulen direkt her­stellerabhängig und weiterhin 11 Modulen direkt versionsabhängig ausfallen (Anlage 2).

Die Bausteine der Schichten 3 - IT-Systeme - und 4 - Anwendungen - sind dabei im Wesentlichen auf Versionen und Hersteller geprägt.

Im Weiteren werden die versionsabhängigen Bausteine (Tabelle 2) untersucht. Typischerweise finden sich die Betriebssystemprodukte von Novell und Microsoft in der Schicht 3. Ebenfalls sind in Schicht 5 die Verzeichnisdienst-Anwendungen der genannten Unternehmen versionsspezifisch eingeschränkt. Daneben ergänzen die Web-Server-Produkte und Exchange die Untersuchungsmenge UM.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Definition UM

Alle aufgeführten Bausteine B¡ haben eine Detailtiefe DT¡ —{konkret}. Die Gültigkeit ist in derjewei- ligen Begründung angegeben und bezieht sich auf konkrete Ausprägungen und Versionen. Bei den Bausteinen B 3.103, B 3.205, B 5.9, B 5.10 und B 5.11 gibt der Bausteintext Hinweise auf eine Versi­onseinschränkung. Bei den verbleibenden Bausteinen ist sogar in der Bausteinüberschrift die zugehö­rige Version feststellbar. Hierdurch ist eine Weiterverwendung der Bausteine für Folgeprodukte nur eingeschränkt möglich, da beispielsweise Konfigurationsdetails mit versionsbezogenen Dialogmasken dokumentiert werden. Für Nachfolgeprodukte ist aus Sicht eines IT-Grundschutzanwenders eine sepa­rate Risikoanalyse erforderlich, da die vorhandenen Bausteine die Nachfolgeversion nicht vollständig abbilden [BSI08-1003]. Die Herstellerunabhängigkeit ist indes für alle Bausteine gewährleistet und über abstrakte Modulen wie z. B. B5.3 E-Mail bei B5.12 Exchange 2000/ Outlook 2000 realisiert.

3.2. Zusammenfassung bisheriger Lösungen

In der Vergangenheit hat es immer wieder Bestrebungen gegeben, die IT-Grundschutzkataloge mit ab­strakten und übergreifenden sowie hersteller- und versionsspezifischen Bausteinen zu gliedern; so geht aus der aktuellen Ergänzungslieferung der übergreifende Baustein B5.15 Allgemeiner Verzeich­nisdienst hervor, der durch die herstellerspezifischen Bausteine B5.16 Active-Directory oder B5.9 Novell eDirectory konkretisiert wird. Tabelle 3 enthält dazu die Liste der Bausteine, die einen Lö­sungsansatz für Versionsunabhängigkeit enthalten:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Lösung der Versionsabhängigkeit UMVU

Der überwiegende Teil der Bausteine vernachlässigt Versionsunterschiede, um so universell einsetz­bar zu sein. Als Vorteil erweist sich bei den Bausteinen B3.102 und B 3.204 die Tatsache, dass bereits eine Spezialisierung der allgemeinen Bausteine erfolgt ist. Als Nachteil der Versionsunabhängigkeit ergibt sich hieraus, dass Maßnahmen nicht mehr zutreffen oder den Stand der Technik nicht mehr oder nur teilweise abdecken. Am Beispiel von B 5.5 wird auf Kosten der Versionsunabhängigkeit auf Details verzichtet und an anderer Stelle stark konkretisiert; dies führt zu einem in sich inkonsistenten Eindruck. B 5.13 hingegen ist an sich auf eine bestimmte Basiskomponente eingeschränkt, diese wird jedoch auf einem durchgängig abstrakten Niveau mit Sicherheitsmaßnahmen abgebildet. Sicher­heitsmaßnahmen im Detail werden über eine zentrale Maßnahme mit der aktuellen Dokumentation re- ferenziert. So kann der entsprechende Versionsbezug hergestellt werden. B5.16 schränkt die Gültig­keit implizit auf die unterliegenden Serverbetriebssysteme ein und enthält so keine Lösungsmöglich­keit für Versionsunabhängigkeit; immerhin kann mit der Nennung der Serverprodukte abgeleitet wer­den, welche Maßnahmen für Nachfolgeprodukte nicht mehr zutreffen oder den Stand der Technik nicht mehr oder nur teilweise abdecken.

[...]