Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden

(Engl. Originaltitel: Securing Windows 2000 Server Delivery Guide)

Version 0.01

Zusammenfassung

Der Entwurfs- und Umsetzungsleitfaden Absichern von Microsoft® Windows® 2000 Server stellt eine Methode für den Entwurf und die Implementierung eines Sicherheitslösungsprojekts vor. Die hier beschriebenen Phasen und Aktivitäten sollen als Hilfestellung für den schnellen Einsatz einer Sicherheitslösung dienen.

Einführung

Informationen zu diesem Leitfaden

Der Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden definiert die erforderlichen Phasen, Rollencluster und Zusatzkomponenten für die erfolgreiche Bereitstellung einer Sicherheitslösung in einem Unternehmen. Die in diesem Leitfaden vorgestellte Methode basiert auf umfassenden Erfahrungen aus der Prozessentwicklung für Sicherheitslösungsprojekte und ist nicht auf bestimmte Implementierungsszenarien beschränkt.

Die Methode baut auf Projektmanagementstandards und bewährten Methoden des Microsoft Solutions Framework (MSF) auf und kann damit an die vorhandenen Prozesse angepasst werden. Somit wird ein mehrfacher Einsatz im Rahmen von Sicherheitslösungsprojekten möglich. Dies garantiert Ihnen schnelle und kalkulierbare Ergebnisse. Der Bereitstellungsleitfaden richtet sich in erster Linie an IT-Programmmanager, Infrastruktur- und Softwarearchitekten, Sicherheitsspezialisten und Administratoren sowie Planer und Berater, die sich mit der Initiierung, Planung, Erstellung, Stabilisierung, Bereitstellung und dem Betrieb der Sicherheitslösung befassen.

Aufgabenhilfen

Eine Reihe von zusätzlichen Dateien soll Unternehmen bei der Durchführung der in diesem Leitfaden beschriebenen Aufgaben helfen. Diese sind in der selbstextrahierenden komprimierten Datei DelWin2k.exe enthalten. Nach dem Herunterladen können Sie die Inhalte dieser Datei in die in Tabelle 1 angegebene Struktur extrahieren. Die Ordner enthalten folgende Anhänge und Aufgabenhilfen.

Tabelle 1: Ordnerstruktur für das Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden

Ordner Inhaltsbeschreibung

C:\SCI Delivery Der Stammordner für alle in diesem Leitfaden enthaltenen Dateien.

C:\SCI Delivery\Job Aids Dieser Ordner enthält Vorlagen für die Implementierung einiger der in der Lösung beschriebenen Aufgaben.

Bereitstellungsmethode für übergeordnete Sicherheitslösungen

Dieser Leitfaden führt Unternehmen schrittweise durch den IT-Lebenszyklus eines Sicherheitsprojekts, von der „Einleitung“ oder „Initiierung“ bis zum „Betrieb“. Die Methode für Sicherheitslösungen definiert eine bestimmte Vorgehensweise für Sicherheitsprojekte, deren Phasen auf dem MSF und dem Microsoft Operations Framework (MOF) basieren. Die Projektmanagementphasen einer Sicherheitslösung lassen sich in sechs Gruppen mit jeweils einem oder mehreren Prozessen unterteilen.

Die in diesem Leitfaden vorgestellte Methode umfasst folgende Phasen:

Ermitteln übergeordneter Faktoren.Schwerpunkt dieser Phase ist es, die Eignung einer Lösung für eine bestimmte Geschäftsumgebung zu überprüfen. Dazu ist ein umfassendes Verständnis der vorhandenen Umgebung und die genaue Kenntnis der Unternehmensanforderungen ebenso nötig wie die Ermittlung der übergeordneten Ziele, die Gewichtung der Projektergebnisse und die Aufstellung eines Zeitplans mit Termin- und Kostenschätzungen. Wichtigstes Ergebnis dieser Phase ist das Ausgangsdokument mit dem Projektkonzept/Umfang.

PlanenDiese Phase befasst sich mit der detaillierten Planung für die Bereitstellung und den Betrieb der Sicherheitslösung. Das Projektteam definiert dabei die genauen Ziele des Sicherheitsprojekts. Ziel ist es, aus den denkbaren Alternativen den idealen Ansatz zu ermitteln, um die Projektziele optimal umzusetzen. Der Schwerpunkt liegt in dieser Phase auf der Analyse der gesammelten Daten. Wichtigstes Ergebnis dieser Phase ist ein Dokument zur Diskrepanzanalyse sowie ein vorläufiger Projektplan mit detaillierten Projektfristen, dem Projektbudget und einer Strategie für die Änderungsverwaltung (Change Management).

ErstellenIn dieser Phase wird der Entwurf zur Sicherheitsbewertung zuerst in einer Testumgebung geprüft und anschließend in einer Produktionsumgebung als Pilottest durchgeführt. Einen weiteren Schwerpunkt bildet die Koordination von Mitarbeitern und Ressourcen bei der Umsetzung des Sicherheitsverwaltungsplans.

StabilisierenIn dieser Phase wird eine Qualitätsverbesserung der Sicherheitslösung durchgeführt, um die erforderlichen Kriterien für eine Freigabe der Lösung für die Produktionsumgebung zu erfüllen. Den Schwerpunkt bilden in dieser Phase die getesteten Ergebnisse sowie die Analyse der Pilotziele und die Beseitigung der verbleibenden Probleme vor der Freigabe. Die Lösung muss sich zu diesem Zeitpunkt in einem stabilen Zustand befinden.

BereitstellenSchwerpunkt dieser Phase ist die Umsetzung der Entwurfspläne aus einer der früheren Projektphasen, anhand derer die Lösung in die Produktionsumgebung verlagert werden soll. Dazu gehört auch die Bereitstellung der in der Erstellungsphase entwickelten Konfigurationen. Von zentraler Bedeutung ist die Umsetzung der gesetzten Projektziele. Diese wird durch eine regelmäßige Fortschrittsüberwachung und -messung sichergestellt, so dass Abweichungen vom Projektplan schnell ermittelt und erforderliche Gegenmaßnahmen ergriffen werden können.

BetreibenEine Sicherheitslösung ist nur dann erfolgreich, wenn das Unternehmen auch in der Lage ist, sie in der eigenen Produktionsumgebung einzusetzen, zu verwalten und zu warten. In dieser Phase wird das dazu erforderliche Wissen vermittelt und das Projekt über ein formales Annahmeverfahren abgeschlossen. Nach Abschluss dieser Phase erfolgt die Verwaltung der Projektdokumentation und der bereitgestellten Lösung im Rahmen des normalen Geschäftsbetriebs. Mitarbeiter und Prozesse zählen zu den wichtigsten Komponenten jeder Sicherheitslösung. Servicepacks und Hotfixes allein reichen nicht aus, um eine stabile Sicherheit der Unternehmensumgebung zu gewährleisten. Die Sicherheitsabteilung muss zur Anwendung von Sicherheitspatches und für eine erfolgreiche Verwaltung der Lösung über zuverlässige Mitarbeiter und Prozesse verfügen.

Anmerkung: Die letzte Phase der hier vorgestellten Methode für Sicherheitslösungen gilt als eigenständige Phase, die mit Hilfe der MOF-Methode und -Prozesse entwickelt wird.

Zum Entwurfs- und Umsetzungsleitfaden Sichern von Windows 2000 Server gehören folgende Prozesse, die größtenteils in Kapitel 3: Sicherheitsrisikomanagement erläutert werden.

SRMD (Security Risk Management Discipline oder Sicherheitsrisikomanagement) bietet Hilfestellung zur:

Bewertung des Unternehmens

Ressourcenbewertung

Bewertung der Sicherheitsrisiken

Bedrohungsanalyse

Bewertung der Sicherheitsanfälligkeit

Entwicklung von Gegenmaßnahmen

Die Test- und Supportleitfäden zum Absichern von Microsoft® Windows® 2000 Server bieten Hilfestellung zu:

Tests

Sicherheitsbewusstsein

Lösungsimplementierung

Betrieb

Diese Prozesse werden in jeder Projektmanagementphase durchlaufen und gewährleisten eine sichere Umgebung. Hierzu stehen Aufgabenhilfen und Pläne zur Verfügung. Für jede Projektphase gibt es bestimmte Meilensteine und Ergebnisse. Da klare und präzise Meilensteine maßgeblich zum Erfolg eines Projekts beitragen, sieht die Methode für Sicherheitslösungen zu jeder Phase eine Meilensteinüberprüfung vor. Diese Überprüfung kann mit einer Genehmigung durch den Kunden für den Start der nächsten Projektphase verbunden werden.

Das MSF bietet Hilfestellung zu den Phasen „Planen“, „Erstellen“, „Stabilisieren“ und „Bereitstellen“ des Projektlebenszyklus in Form von Whitepapers, Bereitstellungsleitfäden, Fallstudien, Tools, Vorlagen und Schulungsunterlagen in den Bereichen Unternehmensarchitektur, Anwendungsentwicklung, Komponentenentwurf und Infrastrukturbereitstellung. Weitere Informationen zum MSF finden Sie unter: http://www.microsoft.com/business/services/mcsmsf.asp (englischsprachig).

Das MOF enthält Ratschläge für die Entwicklung oder betriebliche Optimierung von Verwaltungssystemen. Weitere Informationen zum MOF finden Sie unter: http://www.microsoft.com/business/services/mcsmof.asp (englischsprachig).

Abbildung 1 verdeutlicht den Zusammenhang zwischen MSF, MOF und der Methode für Sicherheitslösungen. Diese Methode ähnelt dem MSF und MOF insofern, als sie auf denselben Projektmanagementphasen basiert. Die Methode für Sicherheitslösungen bietet jedoch darüber hinaus zusätzliche Prozesse, welche Sie beim erfolgreichen Abschluss eines Sicherheitsprojekts unterstützen.

Abbildung 1: Die Methode für Sicherheitslösungen

Die oben dargestellten Phasen beinhalten die erforderlichen übergeordneten Aufgaben und Prozesse, um die Sicherheitsbewertung für ein Projekt durchführen zu können. Der Entwurfs- und Umsetzungsleitfaden für Sicherheitslösungen stellt Ihnen getestete Frameworks, Standards, bewährte Methoden und Ressourcen zur Verfügung. Damit sind alle wichtigen Entwurfsentscheidungen abgedeckt, die bei der Planung und Umsetzung eines Projekts zum Absichern der Windows 2000 Server-Umgebungsarchitektur zu treffen sind. Der jeweilige Arbeitsaufwand hängt entscheidend von der Komplexität der jeweiligen Unternehmensumgebung ab. Die Informationen in diesem Leitfaden sind für die Bestimmung der Sicherheitsverwaltungsprozesse und -funktionen von Windows 2000 Server und den zugehörigen Microsoft-Produkten von großem Nutzen. Darüber hinaus werden ebenso die Komplexitäten und Risikofaktoren einer unsachgemäßen Verwendung aufgezeigt.

Bei dem in diesem Entwurfs- und Umsetzungsleitfaden erläuterten Projektmanagement handelt es sich um eine Methode für die Sicherheitsverwaltung, die sich aus den verschiedenen Phasen der wichtigsten Projektmanagementstandards zusammensetzt. Um den Erfolg des Sicherheitsprojekts zu garantieren, muss die hier erläuterte Methode genau befolgt werden.

Diese Methode ist am IT-Lebenszyklus ausgerichtet, der bewährte Verfahren nach dem Industriestandard umfasst. Jedes Unternehmensnetzwerk ist aufgrund seiner Größe, den verwendeten Betriebssystemen, der Bandbreite, den Netzwerkanwendungen und Unternehmensanforderungen einzigartig. Dementsprechend variiert auch jedes Sicherheitsprojekt hinsichtlich Vorgehensweise, Umfang und Lösung. Bei der Erstellung des vorliegenden Leitfadens wurde diese Vielfalt berücksichtigt. Die einzelnen Abschnitte enthalten daher in einigen Fällen eher flexible Orientierungshilfen als definitive Antworten.

Die folgende Abbildung verdeutlicht den Zusammenhang zwischen den Grundlagen und Prozessen der Sicherheitsverwaltung und den einzelnen Projektmanagementphasen.

Abbildung 2: Die empfohlenen übergeordneten Sicherheitsgrundlagen der Sicherheitsverwaltung

Die empfohlenen übergeordneten Aktivitäten für ein Sicherheitslösungsprojekt, die Abbildung 2 aufgeführt und den entsprechenden Phasen zugeordnet wurden, lauten wie folgt:

1. Fördern des Sicherheitsbewusstseins und Sensibilisieren für die Prozesse der Sicherheitsverwaltung. Definieren der wichtigsten geschäftlichen Gründe und Anforderungen sowie Ermitteln von projektbezogenen Budgetinformationen. In dieser Phase muss das Sicherheitsprogramm im Hinblick auf unternehmensbezogene und betriebliche Zwecke bewertet werden.

2. Gewichten und Bewerten der Ressourcen, um mit der Planung und Umsetzung von Gegenmaßnahmen und Schutzmechanismen zu beginnen. Bewerten der vorhandenen Informationen über alle Projektbeteiligten. Dazu gehören die Erhebungsart der Daten, ihre Verwaltungskosten, mögliche Folgen eines Verlusts bzw. einer Zerstörung der Daten sowie mögliche Vorteile einer Weitergabe an Drittanbieter.

3. Den Schwerpunkt der nächsten Phase bildet die Analyse der Sicherheitsrisiken. Mit Hilfe der Ermittlung von Sicherheitsrisiken und der Bewertung möglicher Schäden können erforderliche Gegenmaßnahmen festgestellt und ihre Berechtigung belegt werden. Ein Risiko ist die Wahrscheinlichkeit, dass ein Angreifer eine Sicherheitslücke ausnutzt und ein System bzw. eine Umgebung beschädigt. Über die Risikobewertung wird sichergestellt, dass die ergriffenen Sicherheitsmaßnahmen kostengünstig, relevant, zeitnah und zielgenau sind. Die Risikoanalyse sollte sowohl unter quantitativen als auch unter qualitativen Gesichtspunkten durchgeführt werden, um den Zielen des Sicherheitsprojekts gerecht zu werden und um weitere Schritte zur Umsetzung einer sicheren Umgebung zu ermöglichen. Diese Phase umfasst auch die grundlegende Bedrohungsanalyse, die Einschätzung der Sicherheitsanfälligkeit und die Auswahl von Gegenmaßnahmen. Der Leitfaden Absichern von Windows 2000 Server gibt den Rahmen eines Sicherheitslösungsprojekts vor und erläutert ausführlich die Vorgehensweise bei der Analyse von Sicherheitsrisiken.

4. Ermitteln und Definieren der individuellen Sicherheitsanforderungen für die Anwendungen und die Infrastruktur des Kunden, an die der grundlegende Microsoft Solution for Security-Entwurf angepasst werden muss. In dieser Phase werden Pläne zur Schadensbegrenzung von Sicherheitsrisiken und Notfallpläne konzipiert, mit denen die Sicherung der

Unternehmensumgebung garantiert und gleichzeitig die Integrität, Vertraulichkeit und Verfügbarkeit der Daten gewährleistet wird.

5. Den Schwerpunkt dieser Phase bildet die Integration der individuellen Umgebungsanforderungen in die Entwurfsleitfäden der Unternehmensarchitektur zur Sicherheitsverwaltung. Gemeinsam mit den Ergebnissen der Sicherheitsrisikoanalyse bilden diese Daten die Grundlage, auf der die Entwicklung von Sicherungsmaßnahmen und anschließende Tests erfolgen.

6. Die Entwicklung von Sicherungsmaßnahmen beginnt in der Erstellungsphase der Methode für Sicherheitslösungen. In dieser Phase wird eine Testumgebung eingerichtet. Sie stellt die Architektur der vorgesehenen Sicherheitslösung nach und ermöglicht Tests und die Überprüfung der Sicherheitslösung hinsichtlich der Unternehmensanwendungen und der Systemumgebung.

7. In dieser Phase wird die Sicherheitslösung für die Windows 2000 Server-Umgebung anhand der Testergebnisse angepasst. Zusätzliche Tests dienen der weiteren Stabilisierung der Lösung.

8. In dieser Phase wird die Sicherheitslösung für Windows 2000 Server in die Produktionsumgebung verlagert und die Anforderungen des Pilottests werden erfüllt.

9. In dieser Phase wird schließlich die endgültige Sicherheitslösung freigegeben. Für die Steuerung und Wartung der Lösung sind künftig die Betriebs- und Supportverantwortlichen zuständig.

Diese allgemeinen Komponenten bilden die Grundlage für eine Sicherheitsverwaltung unter Berücksichtigung von Risikomanagement, Sicherheitsrichtlinien und Sicherheitsschulung. Sie haben sich im Rahmen stabiler Sicherheitsprogramme für Unternehmen bewährt. In den folgenden Abschnitten dieses Leitfadens werden die einzelnen Komponenten und Ergebnisse der Sicherheitsverwaltung kurz vorgestellt.

Wichtige Projektergebnisse von Sicherheitslösungen

Zusätzlich zum Entwurfs- und Umsetzungsleitfaden Absichern von Windows 2000 Server wird IT-Architekten, Planern und anderen Beratern empfohlen, die gesamte Dokumentation zur Sicherheitslösung sowie jede weitere Produktdokumentation zu lesen, die zugehörige Produkte behandelt bzw. auf die verwiesen wird. Abbildung 3 zeigt die Bereitstellungsmethode für Sicherheitslösungen in Verbindung mit dem hier vorliegenden Leitfaden. Aus der Abbildung wird ersichtlich, in welchen Phasen des Projektmanagements welche Leitfäden bzw. Handbücher zum Einsatz kommen.

Abbildung 3: Zusammenhang zwischen der Methode für Sicherheitslösungen und der Lösungsdokumentation Absichern von Windows 2000 Server

Jeder Hauptabschnitt von Absichern von Windows 2000 Server enthält Informationen zu den Sicherheitsprozessen und Rollenclustern der einzelnen Phasen sowie den Ergebnissen nach der Implementierung jeder Phase. Nachfolgend finden Sie eine Auflistung der Aufgabenhilfen mit ihren jeweiligen Ergebnissen. Jede Aufgabenhilfe wird nur kurz skizziert.

Aufgabenhilfen – Entwurfs- und Umsetzungsleitfaden

Die folgenden Aufgabenhilfen geben Kunden ausführliche Hilfestellung bei der Verwaltung eines Sicherheitsprojekts. Die in diesem Entwurfs- und Umsetzungsleitfaden vorgestellten Ansätze sind für IT-Administratoren und Berater geeignet, die für die Bereitstellung sicherer Lösungen in Unternehmensumgebungen verantwortlich sind. Dieser Leitfaden enthält folgende Aufgabenhilfen bzw. Ergebnisse:

1. Projektkonzept/Umfang. Das schriftlich erarbeitete Dokument zu Konzept und Umfang bildet die Basis für die weiteren Projektentscheidungen. Bei der Definition des Umfangs werden die wichtigsten Projektergebnisse in diesem Dokument in kleinere, übersichtlichere Komponenten unterteilt.

2. Projektrisikobewertung In die Gesamtrisikobewertung eines Projekts fließen sämtliche Risikodaten der einzelnen Projektebenen ein. Dieses dynamische Dokument bildet die Grundlage für das fortlaufende Risikomanagement und muss daher während des gesamten Zyklus aus Risikoanalyse, Planung und Überwachung auf dem aktuellen Stand gehalten werden.

3. Projektmasterplan Der Projektmasterplan erläutert die konzeptuelle, logische und physische Struktur des Sicherheitslösungsprojekts. Der Projektmasterplan dieses Entwurfs- und Umsetzungsleitfadens beschreibt die Funktionsspezifikationen und deren Zusammensetzung im Rahmen einer Sicherheitslösung.

4. Projektmasterzeitplan Im Projektmasterzeitplan werden die zu erledigenden Aufgaben mit ihren Abschlussterminen und Abhängigkeiten festgehalten. In einem letzten Abschnitt, der Aufgabensequenzierung, werden den einzelnen Aufgaben dann entsprechende Ressourcen zugeordnet. Der Projektmasterzeitplan wird während des gesamten Projekts fortgeführt und aktualisiert.

5. Funktionsspezifikation Diese Aufgabenhilfe bietet einen Einblick in die endgültige Sicherheitslösung. Die Funktionsspezifikation enthält ausführliche Erläuterungen zu den Entwurfszielen der Lösung und bildet einen wesentlichen Bestandteil des Sicherheitsentwurfsprozesses.

6. Kommunikationsplan Der Kommunikationsplan gibt vor, wie ein Projektteam zwischen internen Rollenclustern und externen Beteiligten kommuniziert. Der Plan legt auch die Kommunikation zwischen den Funktionsrollen des Sicherheitsprogramms und der Belegschaft des Unternehmens sowie zwischen den IT-Helpdesks und den Endbenutzern fest.

7. Budgetplan Der Budgetplan sammelt alle Budgetschätzungen für das Sicherheitsprojekt und bildet daraus die Einschätzung der Gesamtkosten. Alle Funktionsteams erstellen ihr eigenes Budget und reichen es dann beim Programmmanagement-Rollencluster ein, der daraus den Budgetmasterplan erstellt.

8. Entwicklungsplan Der Entwicklungsplan enthält die Vorgaben für die Konzeptüberprüfung zur Bewertung des Unternehmens, der Bedrohungsanalyse, der Einschätzung der Sicherheitsanfälligkeit und der Analyse des Sicherheitsrisikos. Erstellung und Ausführung dieses Plans erfolgen anhand der in Absichern von Windows 2000 Server geschildertem normativen Prozesse und Verfahren. Das Budget für den Entwicklungsplan ist ebenfalls in diesem Plan enthalten.

9. Schulungsplan Im Schulungsplan wird ermittelt, welche Benutzergruppen Sicherheitsschulungen erhalten sollen

und wie diese Schulungen der betreffenden Zielgruppe am besten vermittelt werden können. Darüber hinaus werden mögliche Mechanismen für den Wissensaustausch bewertet und der Ressourceneinsatz für die Erstellung von Lernunterlagen geprüft.

10. Testplan Der Testplan beschreibt die Strategie des Projektteams für das Testen der Lösung. Der Testplan muss an die im jeweiligen Unternehmen bestehenden Techniken zur Änderungskontrolle, die Verfahren der Konfigurationsverwaltung und den Mechanismen zur Problemverfolgung angepasst werden. Die Entwicklungs- und Testumgebungen müssen den Konfigurationen aus den Entwicklungs- und Testplänen entsprechen. Darüber hinaus enthält der Testplan auch Schritte zum Testen der Usability und Benutzererfahrung, Aktualisierungen zu den Schulungsunterlagen und Anweisungen zum deren Aufbau.

11. Vorlage für Änderungsanforderungen Die Vorlage für Änderungsanforderungen ist von entscheidender Bedeutung für einen erfolgreichen Änderungsverwaltungsprozess. Das Microsoft® Word-Dokument Change_Request_Template.dot kann verwendet werden, um Änderungen anzufordern und alle Änderungsanforderungen im Änderungskontrollsystem zu dokumentieren.

12. Checkliste zum Projektabschluss Die Checkliste zum Projektabschluss gibt Aufschluss darüber, ob die Kriterien für das Sicherheitsprojekt erfüllt wurden. Das Management prüft die Liste der Ergebnisse und hakt die entsprechenden Punkte in dieser Checkliste ab. Anhand dieser Liste erfolgt die Ergebnisbewertung nach Projektabschluss. Diese Aufgabenhilfe eignet sich auch zur Abzeichnung durch den Kunden.

Die folgenden Ergebnisse sind ebenfalls für das Sicherheitsprojekt erforderlich; es liegen jedoch keine Aufgabenhilfen dazu vor.

Übersicht über die ProjektbeteiligtenDiese Übersicht stellt die definierten Projektbeteiligten grafisch dar. Sie kann dazu beitragen, die politischen Zusammenhänge zwischen den einzelnen Beteiligten zu verstehen. Neben Risiken wie einer unzureichenden finanziellen Unterstützung oder Änderungspositionierung können damit auch Widerstände in wichtigen Bereichen oder Eskalationswege für die Problemlösung aufgezeigt werden.

SicherheitsprogrammzieleDie Sicherheitsprogrammziele können Bestandteil des Dokuments zu Konzept/Umfang sein. Ziel eines Sicherheitsprogramms ist jedoch der Schutz der Unternehmensressourcen. Die Sicherheitsprogrammziele sollten daher geeignete Vorgaben zu Richtlinien, Prioritäten, Standards und Strategien des Sicherheitsprogramms enthalten.

Aufgabenhilfen – Lösungsleitfaden

Die folgenden Aufgabenhilfen dienen dazu, die Lösungsarchitektur zu beschreiben, den Entwurf zu erläutern und den Zusammenhang zwischen diesen Aspekten und den Unternehmensproblemen aufzuzeigen. Die Informationen des Lösungsleitfadens richten sich an Berater, Designer, Systemtechniker und andere IT-Mitarbeiter. Ein ordnungsgemäß konzipierter Lösungsleitfaden muss die folgenden wichtigen Ergebnisse enthalten:

1. Analyse der SicherheitskomponentenDie Analyse der Sicherheitskomponenten ist eine Kombination aus Ressourcenbewertung, Unternehmensbewertung, Bedrohungsanalyse und Einschätzung der Sicherheitsanfälligkeit. Nachfolgend werden die einzelnen Bestandteile der Analyse der Sicherheitskomponenten im Überblick vorgestellt.

RessourcenbewertungslisteDer Wert einer Ressource entspricht der Summe der ermittelbaren Kosten, die aus einem Verlust oder einer Beschädigung der Ressource resultieren würden. Die Ressourcenbewertungsliste sollte neben den Anschaffungs- bzw. Entwicklungskosten jeder Ressource auch die Kosten für Verwaltung und Schutz, den Wert der Ressource für Eigentümer und Benutzer sowie weitere Werteinschätzungen berücksichtigen. Eine ausführliche Beschreibung der Ressourcenbewertungsliste finden Sie im Lösungsleitfaden.

Die Erstellung einer detaillierten Ressourcenbewertungsliste ist ein schwieriges Unterfangen, das den Umfang dieses Entwurfs- und Umsetzungsleitfadens überschreitet. Unternehmen führen Ressourcenbewertungen zu zahlreichen Zwecken durch - beispielsweise auf Anforderung von Versicherern. Die bereits zu einem früheren Zeitpunkt erfassten Daten zur Ressourcenbewertung stellen den Ausgangspunkt für das Sicherheitsprojekt dar. Bedenken Sie aber, dass das Projektteam die Informationen vermutlich erneut analysieren muss, da Daten von anderen Gruppen inzwischen veraltet sein können.

BedrohungsanalyseDie Analyse potenzieller Gefahren für Daten oder Systeme erfolgt im Rahmen einer Bedrohungsanalyse. Ein Angreifer könnte zum Beispiel ein Benutzer sein, der über einen Port der Firewall auf das Netzwerk zugreift, oder auch ein Prozess, der in einer Weise auf Daten zugreift, die gegen die Sicherheitsrichtlinien des Unternehmens verstößt. Die verschiedenen Angreifertypen werden in diesem Dokument mit ihren jeweiligen Sicherheitslücken und Risiken erfasst.

Einschätzung der SicherheitsanfälligkeitSchwerpunkt dieser Bewertung ist die Analyse von Software, Hardware oder unsicheren Verfahren, über die Angreifer unerlaubt auf einen Computer oder ein Netzwerk zugreifen können und so Zugang zu den Ressourcen der Umgebung erhalten. Es wird erläutert, welche Bedrohungen mit welchen Risiken verbunden sind und wie sich diese potenziellen Risiken im Einzelnen auswirken können. Auch hier gilt, dass eine Einschätzung der Sicherheitsanfälligkeit nicht zwingend erforderlich ist und über den Umfang des Leitfadens Absichern von Microsoft Windows 2000 Server hinausgeht. Gerade in den Anfangsphasen eines Sicherheitsprojekts kann eine solche Bewertung jedoch sehr hilfreich sein.

SicherheitsrisikoanalyseBei der Sicherheitsrisikoanalyse, die sich deutlich von der Projektrisikobewertung unterscheidet, geht es darum, relevante Risiken zu ermitteln und ihren möglichen Schaden zu bewerten. So kann die Berechtigung von Schutz- oder Gegenmaßnahmen nachgewiesen werden. Über die Sicherheitsrisikoanalyse wird gewährleistet, dass die ergriffenen Sicherheitsmaßnahmen kostengünstig, relevant, zeitnah und zielgenau sind.

2. Gruppenrichtlinienstrategie und VorlagenDie Gruppenrichtlinienstrategie beinhaltet Sicherheitsvorlagen auf Basis empfohlener Standards und bewährter Methoden aus der Programmgruppe Absichern von Windows 2000 Server. Diese Vorlagen sollten in einer Tabelle dokumentiert und über INF-Dateien oder eine SDB-Sicherheitsdatenbankdatei implementiert werden. Darüber hinaus wird im Rahmen der Gruppenrichtlinienstrategie auch die Entwicklung des strukturellen Entwurfs zur Bereitstellung von Gruppenrichtlinien erörtert.

3. Übersicht zum IPSec-DatenverkehrDiese Übersicht enthält allgemeine Informationen zur Serverrolle, der Richtung und dem Ziel des Netzwerkverkehrs, der IP-Adresse der Schnittstelle, dem IP-Protokoll (Internet Protocol), dem TCP-Port (Transmission Control Protocol) und dem UDP-Port (User Datagram Protocol). Weitere Informationen zu IPSec (Internet Protocol Security) erhalten Sie in Kapitel 7: Absichern der Server anhand ihrer Rollen.

4. Kurzübersichtskarte zur Reaktion auf ZwischenfälleDiese Übersicht regelt den Eskalationsweg und den Lösungsprozess der Sicherheitsproblemverwaltung. Sie dient Ihnen als nötige Hilfestellung, um die richtigen Schritte zu ergreifen und damit effektiv auf Zwischenfälle zu reagieren. Die genaue Schrittreihenfolge hängt jedoch ganz vom jeweiligen Unternehmen und Zwischenfall ab. Weitere Informationen zur Reaktion auf Zwischenfälle erhalten Sie in Kapitel 10: Responding to Incidents (englischsprachig).

Folgende Ergebnisse für das Absichern von Microsoft Windows 2000 Server sind im Rahmen von Sicherheitsprojekten erforderlich, ohne dass dafür Aufgabenhilfen bereitstehen.

1. Bewertung des UnternehmensBei der Bewertung des Unternehmens werden Informationen aus der Bewertung der Sicherheitsanforderungen und Unternehmensziele für die Sicherheitslösung berücksichtigt. Die Bewertung enthält dokumentierte Verpflichtungen des Sicherheitsprogrammpersonals und des Unternehmens. Auf der Grundlage dieser Informationen kann das Sicherheitsprogramm in die aktuelle Geschäftsumgebung integriert werden, wobei dessen Leistungen effektiv überwacht

werden. Eine Bewertung des Unternehmens ist nicht zwingend erforderlich und geht über den Umfang des Leitfadens Absichern von Microsoft Windows 2000 Server hinaus. Gerade in den Anfangsphasen eines Sicherheitsprojekts kann eine solche Bewertung des Unternehmens jedoch sehr hilfreich sein.

2. GegenmaßnahmenplanDieser Plan enthält die Schutzmaßnahmen zur Reduzierung der potenziellen Risiken in einer Unternehmensumgebung. Der Plan definiert die Software, Hardware bzw. Verfahren, die zur Beseitigung oder Minderung von Sicherheitsrisiken implementiert werden sollten. Dieser Plan geht über den Umfang des Leitfadens Absichern von Microsoft Windows 2000 Server hinaus. Gerade in den Anfangsphasen eines Sicherheitsprojekts kann ein solcher Gegenmaßnahmenplan jedoch sehr hilfreich sein.

3. SystemsicherungsplanDer Systemsicherungsplan sieht bei der Bereitstellung von Windows 2000 Server die Umsetzung häufig durchgeführter Sicherungsschritte zur Absicherung der Umgebung vor. In diesem Dokument wird dargelegt, wie die Server durch Einzelschrittanleitungen anhand ihrer jeweiligen Rolle gesperrt werden können. Dieser Plan geht über den Umfang des Leitfadens Absichern von Microsoft Windows 2000 Server hinaus. Gerade in den Anfangsphasen eines Sicherheitsprojekts kann ein solcher Systemsicherungsplan jedoch sehr hilfreich sein.

4. ÄnderungsverwaltungsprozessDer Prozess zur Änderungsverwaltung ist der Aspekt der Dienstverwaltung, der die IT-Zuverlässigkeit untermauert und zur Stabilisierung der IT-Unternehmenssysteme beiträgt. Darüber hinaus ermöglicht dieser Prozess auch ein dynamisches Unternehmenswachstum mit schnellerer Einbindung von Änderungen, Erweiterungen und Übernahmen. Im Rahmen dieser Dienstverwaltungsfunktion erfolgt die Verwaltung und Steuerung sämtlicher Komponenten der IT-Betriebsumgebung. Diese umfasst die Anwendungsumgebung und die IT-Infrastruktur. Die Prozesse werden im Abschnitt Änderungskontrollsystem dieses Leitfadens und in Kapitel 8: Patchverwaltung von Absichern von Microsoft Windows 2000 Server kurz erläutert.

Aufgabenhilfen – Testleitfaden

Die folgenden Aufgabenhilfen kommen beim Entwickeln der Lösungsarchitektur und den Entwurfstests zum Einsatz. Hierdurch werden diese beiden Komponenten für die Produktionsumgebung stabilisiert. Die Informationen des Testleitfadens richten sich an IT-Experten, Systemtechniker und den Testrollencluster. Ein ordnungsgemäß erstellter Testleitfaden enthält folgende Ergebnisse:

1. Plan für den FehlerverfolgungszyklusDer erste Schritt dieses Plans, die Berichterstattung, beinhaltet die Eingabe von beim Sicherheitsentwurf ermittelten Fehlerberichten in ein Repository (in der Regel eine Datenbank). Neue Fehler werden standardmäßig als aktiv gekennzeichnet. Im zweiten Schritt des Testplans gewichtet der Entwicklungsleiter die Fehler nach ihrer Bedeutung und weist Projektteammitglieder zu ihrer Lösung zu. Dieser Schritt wird auch als Fehlerklassifizierung bezeichnet. Im dritten Schritt dieses Prozesses löst der Besitzer den Fehler auf, indem er ihn entweder beseitigt oder als unlösbar neu klassifiziert. Im letzten Schritt wird der Fehler von den Test- oder Programmmanagementrollen geschlossen. Die Entwickler können Fehler nicht selbst schließen, da dies ein Projektrisiko darstellen würde. Anhand von Regressionstests wird sichergestellt, dass der ursprüngliche Fehler durch den Fix tatsächlich beseitigt wurde. War der Fix erfolgreich, wird der Fehler geschlossen. Andernfalls wird der Fehler erneut als aktiv klassifiziert.

2. Vorlagen für UsabilitytestsDiese Vorlagen enthalten Tests, um die Nutzbarkeit einer Lösung aus Sicht der vorgesehenen Benutzer zu messen. Benutzer können dabei unter der Aufsicht von Testern bestimmte Aufgaben in einer Testumgebung durchführen. Die detaillierten Testvorlagen sind bei der Qualitätsbewertung der Lösung behilflich.

3. Testplan für GeschäftsfunktionenDieser Plan stellt einen Prozess bereit, der das Betriebspersonal und die Belegschaft des Unternehmens nach Implementierung der Sicherheitsmaßnahmen durch die Funktionstests der Unternehmensanwendungen und Prozesse führt.

Projektvoraussetzungen – Entwurfs- und Umsetzungsleitfaden

Die Methode für Sicherheitslösungen geht von folgenden Voraussetzungen aus:

1. Projektziel ist in der Regel ein besserer Schutz der Unternehmensdaten und -ressourcen. Sicherheitslösungsprojekte sind selbstverständlich hinsichtlicht einer größeren Sicherheit konzipiert, wodurch die Nutzbarkeit in gewissem Umfang einschränkt wird. Das Gleichgewicht zwischen Sicherheit und Nutzbarkeit muss in jeder Umgebung im Mittelpunkt stehen. Es ist davon auszugehen, dass die Nutzbarkeit in bestimmten Bereichen eingeschränkt werden muss.

2. Es empfiehlt sich, das Sicherheitslösungsprojekt auf der Grundlage der Microsoft Systems Architecture (MSA), dem MSA Enterprise Data Center (EDC), Version 1.5, aufzusetzen. Diese Konfiguration wird in Kapitel 4: Sicherheitsrisikomanagement im Einsatz von Absichern von Microsoft Windows 2000 Server ausführlich erläutert. Die MSA ist für den Erfolg eines Sicherheitslösungsprojekts nicht ausschlaggebend, wird jedoch als Fundament empfohlen.

3. Die Methode zur Bereitstellung von Sicherheitslösungen soll erfahrenen Beratern als Orientierungshilfe für den Ablauf von Sicherheitslösungsprojekten dienen.

4. Die Methode für Sicherheitslösungen soll keine bereits vorhandene Methode komplett ersetzen. Sie stellt vielmehr eine Reihe von klar definierten Prozessen bereit, mit denen bestimmte Aufgabenhilfen in das bestehende Sicherheitsverwaltungsprogramm eines Unternehmens integriert werden können. Obwohl nicht alle Aufgabenhilfen verwendet werden müssen, wird eine effiziente Sicherheitslösungentwicklung für Unternehmen durch die Methode für Sicherheitslösungen und die Aufgabenhilfen vereinfacht.

5. Projektanforderungen ändern sich im Laufe eines Projekts, so dass ein Änderungskontrollprozess eingerichtet werden muss, der zu Projektbeginn zwischen dem Kunden und dem Projektteam abzustimmen ist. Weitere Informationen dazu erhalten Sie im Abschnitt Änderungskontrollsystem weiter unten in diesem Leitfaden.

6. Absichern von Windows 2000 Server gibt einen Rahmen und Implementierungsplan vor, mit denen der Zeit- und Kostenaufwand für Entwicklung und Entwurf eines vollständig neuen Sicherheitslösungsprojekts deutlich reduziert werden kann. Da sich die Geschäftsanforderungen und Ausstattungen der Kunden von Projekt zu Projekt deutlich unterscheiden können, müssen Geschäftskunden und Berater die Rahmenlösung entsprechend anpassen.

7. Über den gesamten Projektverlauf werden bewährte Methoden aus dem MSF-Projektmanagement eingesetzt.

8. Schwerpunkt der Methode für Sicherheitslösungen ist nicht die Anwendungsentwicklung, sondern der Entwurf und die Implementierung der Infrastruktur.

9. Obwohl es sich bei der Architektur der Sicherheitslösung um einen extrem skalierbaren Sicherheitssystementwurf handelt, ist bei der Skalierbarkeitsbewertung der gesamten Lösung eine Reihe von Faktoren zu berücksichtigen. Diese erfordern eine Testumgebung.

10. Das Sicherheitsmodell muss der speziellen Anwendungen angepasst werden. Dies geht jedoch über den Umfang der Dokumentation der Sicherheitslösung hinaus.

11. Entwurf und Implementierung von Netzwerken für Tests, Entwicklung und Inhaltsbereitstellung gehen ebenfalls über den Umfang der Dokumentation der Sicherheitslösung hinaus.

Methode für Sicherheitslösungen

Das Sicherheitsframework umfasst den Lebenszyklus einer Lösung vom Projektbeginn bis zum tatsächlichen Einsatz. Das Framework basiert auf dem MSF-Prozessmodell, das von Microsoft ursprünglich für die Anwendungsentwicklung und Bereitstellung der Technologieinfrastruktur verwendet wurde. Bei diesem Prozessmodell handelt es sich aufgrund kurzer Entwicklungszyklen um einen iterativen Prozess. Er kann sich an wechselnde Projektanforderungen anpassen, indem die einzelnen Versionen der Lösung schrittweise durchlaufen werden. Voraussetzung dafür sind kontinuierliche Risikomanagement- und Testzyklen.

Projektteammodell für Sicherheitslösungen

Die Methode für Sicherheitslösungen umfasst sowohl das MSF-Teammodell als auch eine Organisationshierarchie für das Projektmanagement. Auf diese Weise werden Kommunikationsprobleme umgangen, die bei nur einer Teamstruktur häufig auftreten können. Da der Eindruck entstehen kann, dass dem MSF-Teammodell die Führungsrolle mit der übergreifenden Verantwortung für die Entscheidungsfindung fehlt, ein hierarchisches Modell dagegen die Zusammenarbeit und den Zusammenhalt im Team beeinträchtigen kann, verwendet die Methode für Sicherheitslösungen das Teammodell für den Entwurf und die Bereitstellung der Sicherheitslösung und die hierarchische Struktur für die Problemeskalation.

Übersicht über das MSF-Teammodell

Das MSF-Teammodell wurde über mehrere Jahre hinweg entwickelt, um einigen Nachteilen der strikt hierarchischen Struktur herkömmlicher Projektteams zu begegnen. Nach diesem Modell zusammengestellte Teams sind klein und disziplinübergreifend ausgerichtet. Die Verantwortung wird gemeinsam getragen und die Kompetenzen aller Mitglieder ergänzen sich, so dass das jeweilige Projekt optimal durchgeführt werden kann. Alle Mitglieder verfügen über ein gemeinsames Projektkonzept, ein ausgeprägtes Projektengagement, hohe Qualitäts- und Kommunikationsstandards sowie große Lernbereitschaft.

Das in Abbildung 4 dargestellte MSF-Teammodell fördert das Konzept einer Zusammenarbeit gleichberechtigter Partner, deren Rollen voneinander abhängig sind und einander ergänzen. Jedes Teammitglied leistet dabei einen gleich wichtigen Beitrag zum Projekt. Das Teammodell verstärkt das Zugehörigkeits- und Verantwortungsgefühl des Einzelnen, fördert die Zusammenarbeit auf gleichberechtigter Ebene und ermöglicht damit schließlich bessere Ergebnisse für den Kunden.

Anmerkung: Die folgenden Teamrollencluster können je nach Projektumfang und Kundenorganisation jeweils von einem einzelnen Teammitglied oder ganzen Teilteams übernommen werden.

Abbildung 4: MSF-Teamrollencluster

Das MSF-Teammodell legt großen Wert auf die Ausrichtung der Rollencluster an den Unternehmensanforderungen. Indem zusammengehörige Funktions- und Verantwortungsbereiche nach Ausrichtung und Schwerpunkt zusammengefasst werden, ermöglicht das MSF-Teammodell ein ausgeglichenes Team, das sämtliche grundlegende Projektziele umsetzen kann. Klar definierte Rollen und Ziele stärken das Verständnis des eigenen Verantwortungsbereichs und garantieren damit ein besseres Lösungsergebnis. Da jedes Ziel für den Projekterfolg mitentscheidend ist, werden auch die damit verknüpften Rollen als gleichwertig angesehen und gleichberechtigt an der Entscheidungsfindung beteiligt.

Der MSF-Ansatz zeichnet sich in erster Linie dadurch aus, dass die Funktionen und Tätigkeiten des Projektmanagements bei der Entscheidungsfindung nicht hierarchisch strukturiert sind. Das MSF richtet sich also gegen ein starres, „diktatorisches“ Projektmanagement, das die gleichberechtigte Zusammenarbeit – einen der wichtigsten Erfolgsfaktoren des MSF – erschwert oder unterbindet. Jede MSF-Teamrolle dient einem bestimmten Ziel. Jedes Ziel ist von gleich großer Bedeutung für das Projekt, und wichtige Entscheidungen werden vom Kernteam gemeinsam erarbeitet. Kann keine Einigung erzielt werden, übernimmt die Programmmanagementrolle die Schiedsrichterfunktion und trifft die endgültige Entscheidung, um den Fortgang des Projekts zu ermöglichen. Kriterien für diese Entscheidung sind stets die Kundenanforderungen und die projektvorgabengemäße Bereitstellung der Lösung. Alle anderen Rollencluster werden ausführlich im Abschnitt Ermitteln übergeordneter Faktoren dieses Leitfadens erläutert.

Weitere Informationen zu den MSF-Teamrollenclustern finden Sie unter: http://www.microsoft.com/business/services/mcsmsf.asp (englischsprachig).

Übersicht über das MOF-Teammodell

Oberstes Ziel des MOF ist es, mit Hilfe bewährter Methoden die verteilte Datenverarbeitung unter der Microsoft-Plattform zu unterstützen. In diesem Zusammenhang ist darauf hinzuweisen, dass sich das Teammodell in dieser Umgebung deutlich von den hierarchisch organisierten Betriebsteams in Rechenzentren mit herkömmlicher, zentraler Datenverarbeitung unterscheidet.

Das Verhältnis von Prozessbesitz und Funktionsorganisation ist nicht unproblematisch. Die Zuständigkeit für die Änderungsverwaltung kann beispielsweise viel einfacher in einer zentralisierten (Mainframe-)Umgebung an eine Person delegiert werden. Diese ist dann vermutlich für die gesamte Änderungskontrolle des Systems verantwortlich. Heutzutage ist die Änderungsverwaltung dagegen auf mehrere geografische Regionen, Geschäftsbereiche, Zeitzonen und sogar Unternehmen verteilt und damit weit schwerer einer einzelnen Person oder Gruppe zuzuweisen.

Abbildung 5: MOF-Teamrollencluster

Organisationsmodelle sind eng mit den darin verwendeten Prozessen verbunden. Da die Prozessverantwortung geteilt werden muss, muss das Modell die bewährten Standardmethoden, wie die Information Technology Infrastructure Library (ITIL) und das MOF, in der gesamten Branche bekannt machen.

Das MOF-Teammodell beschreibt:

1. Rollencluster für bewährte Methoden zum Strukturieren von Betriebsteams.

2. Die Schlüsselaktivitäten und Kompetenzen der einzelnen Rollencluster.

3. Die Verfahren zum Skalieren der Teams für unterschiedliche Unternehmensgrößen und -typen.

4. Bewährte Rollenkombinationen.

5. Grundlegende Prinzipien zum erfolgreichen Ausführen und Betreiben verteilter Computerumgebungen unter der Microsoft-Plattform.

Prozessmodell für Sicherheitslösungen

Das Prozessmodell für Sicherheitslösungen beschreibt eine übergeordnete Folge von Aktivitäten zu Entwicklung und Einsatz von IT-Sicherheitslösungen im IT-Lebenszyklus. Das Modell schreibt keine feste Folge von Verfahren vor, sondern ist flexibel genug, um sich an eine große Vielzahl von IT-Prozessen anzupassen.

Das Modell kombiniert zwei Industriestandard-Modelle: Wasserfall und Spirale. Zu den innovativen Aspekten des Sicherheitslösungsmodells gehört die Tatsache, dass es den gesamten Lebenszyklus einer Lösung umfasst – vom Projektbeginn bis zum tatsächlichen Einsatz. Auf diese Weise können sich Projektteams auf den Geschäftswert für den Kunden konzentrieren. Dieser kann erst umgesetzt werden, wenn der Lösungsbetrieb aufgenommen wird. Das Modell für Sicherheitslösungen vereinfacht zudem den reibungslosen Übergang von der Bereitstellung zum täglichen Betrieb. Das Unternehmen kann die Verwaltung der Lösung problemlos übernehmen, da der Betriebsprozess direkt an die Bereitstellungsphase anschließt. Punkt 6 der folgenden Abbildung kennzeichnet den letzten Meilenstein der Projektmanagementphasen und gleichzeitig den Beginn der Betriebsphasen der Lösung.

Abbildung 6: Die Phasen der Prozessmethode für Sicherheitslösungen

Die Methode für Sicherheitslösungen basiert auf Meilensteinen. Als Meilensteine werden bestimmte Projektetappen bezeichnet, in denen wichtige Ergebnisse erzielt wurden und geprüft werden können. Meilensteine bieten Gelegenheit zur Beantwortung bzw. Erörterung von Kernfragen, z. B.: Ist sich das Team über den Projektumfang einig? Haben wir die weitere Vorgehensweise ausreichend geplant? Haben wir unsere Entwicklungsvorgaben erfüllt? Ist die Lösung für den Kunden einsatzfähig? Liegen wir vor, in oder hinter dem Zeitplan? Muss der weitere Zeitplan angepasst werden?

Der Sicherheitslösungsprozess basiert auf dem MSF-Prozessmodell, das von Microsoft ursprünglich für die Anwendungsentwicklung eingesetzt wurde. Dieses Modell kann zur Anwendungsentwicklung in herkömmlichen Umgebungen verwendet werden, ist aber auch für die Entwicklung und Bereitstellung von Infrastrukturlösungen in Unternehmen, für Web-, E-Commerce- oder verteilte Anwendungen sowie für vielfältige andere zukünftige Initiativen geeignet. Die folgenden sechs Prozesse dienen der Sicherheitsverwaltung und entsprechen den Phasen der Sicherheitslösungsmethode (vgl. Abbildung 6 oben).

1. Start der ProjektdefinitionIn der Einführungsphase des Projekts wird eine der grundlegendsten Anforderungen für den Erfolg des Sicherheitsprojekts behandelt: die Abstimmung von Projektteam und Sicherheitsprogramm. Der Teamerstellungsprozess läuft bis zum Ende der Phase „Ermitteln übergeordneter Faktoren". Alle Teams benötigen ein klares Konzept des Endergebnisses, damit die Sicherheitslösung den Anforderungen des Unternehmens entspricht. Schwerpunkt dieser Phase ist, zu ermitteln, welches Geschäftsproblem bzw. welche Geschäftschance der Sicherheitsverwaltung zugrunde liegt. Alle an der Sicherheitsverwaltung beteiligten Parteien müssen die damit verbundenen Ziele, Voraussetzungen und Einschränkungen definieren.

2. Sicherheitsbewertung und -analyseBewertung und Analyse der Sicherheitsverwaltung erfolgen in der Planungsphase der Sicherheitslösungsmethode. Zu den einzelnen Prozessen gehören die Bewertung des Unternehmens, die Ressourcenbewertung, die Bedrohungsanalyse, die Einschätzung der Sicherheitsanfälligkeit und die Analyse des Sicherheitsrisikos. Auf diesen Prozessen basiert die anschließende Planung erfolgreicher Gegenmaßnahmen.

3. Entwicklung von SicherungsmaßnahmenDie Daten aus der Sicherheitsbewertung und -analyse ermöglichen die Entwicklung von Sicherungsmaßnahmen. In dieser Phase entwickeln, testen und prüfen Entwickler fortlaufend alle Gegenmaßnahmen zur Minderung der in den früheren Projektphasen ermittelten Risiken. Diese Sicherheitsentwicklungsprozesse werden vom Entwicklungsteam getestet und anhand von Qualitätskriterien bewertet.

4. Test der Sicherungsmaßnahmen und RessourcenfunktionenDie Testergebnisse zu den Sicherungsmaßnahmen und Ressourcenfunktionen sind weniger vorhersehbar. Alle unerwarteten Ergebnisse werden gekennzeichnet und in der Phase „Stabilisieren“ im Rahmen von Tests der Sicherungsmaßnahmen und Ressourcenfunktionen verwaltet. Obwohl die Entwicklung anhand bekannter Pläne und Spezifikationen erfolgt, gibt es immer eine unbekannte Anzahl an Fehlern mit unterschiedlichem Schweregrad. Microsoft bemisst die Qualität der Lösung mit Hilfe der Technik für Fehlerkonvergenz sowie der Zero-Bug-Bounce-Methode und prognostiziert so in dieser Phase das voraussichtliche Datum der Funktionsbereitschaft. Diese Themen werden weiter unten im Abschnitt Stabilisieren dieses Leitfadens erläutert.

5. Bereitstellung von Gegenmaßnahmen und SicherheitsrichtlinienDie Bereitstellung von Gegenmaßnahmen und Sicherheitsrichtlinien wird über die gesamte Bereitstellungsphase der Sicherheitslösungsmethode fortgeführt und in den MOF-Prozess übernommen. Bei den einzelnen Typen von Gegenmaßnahmen und Sicherheitsrichtlinien werden zwei Gruppen unterschieden: grundlegende und standortspezifische Sicherheitskomponenten. Grundlegende Sicherheitskomponenten befinden sich an einem zentralen Ort und sind für die gesamte Sicherheitslösung relevant. Standortspezifische Komponenten befinden sich dagegen an unterschiedlichen Standorten und ermöglichen Benutzern den Zugriff auf die Lösung und ihre Verwendung. Diese Themen werden weiter unten im Abschnitt Bereitstellen dieses Leitfadens erläutert.

6. Bereitstellung abgeschlossenZum Meilenstein „Bereitstellung abgeschlossen“ gehört auch das erforderliche Wissen zum Sicherheitsrisikomanagement. Diese Abschlussprozesse werden in den Betriebsstatus übernommen und im MOF-Prozess fortgeführt.Nach dem Abschluss der Sicherheitsbewertung und -analyse, der Entwicklung von Sicherungsmaßnahmen, der Eindringversuche und Ressourcenfunktionstests sowie der Bereitstellung von Sicherheitsrichtlinien und Gegenmaßnahmen durchläuft das Projekt die nun folgenden MOF-Prozesse. Vor der MOF-Phase werden Pilottests durchgeführt, um geeignetes Feedback zum Sicherheitslösungsentwurf zu erhalten. Im Allgemeinen werden die Pilottests während der Stabilisierungsphase vorab entwickelt. Da das Pilotprogramm jedoch auch in der Produktionsumgebung zum Einsatz kommt, wirken sich die Pilottests auch auf den allgemeinen Betrieb aus.

7. Erneute Bewertung der neuen und geänderten Ressourcen und SicherheitsrisikenHierbei handelt es sich um Prozesse innerhalb der Änderungsverwaltung. Neben der Änderungsverwaltung erfolgt in dieser Phase auch die Verwaltung der Sicherheitskonfiguration. Daran anschließend folgt das Release Management und die abschließende Bereitstellung der neuen Gegenmaßnahmen und Sicherheitsrichtlinien.

8. Entwicklung, Stabilisierung und Bereitstellung neuer/geänderter GegenmaßnahmenIn der Betriebsphase werden diese Prozesse von den System-, Sicherheits- und Netzwerkadministratoren verwaltet. Auch bei der Dienstüberwachung, der Dienststeuerung und der Planung der Auftragsausführung können Sicherheitsadministratoren in der Betriebsphase neue und verbesserte Gegenmaßnahmen einsetzen.

9. Sicherheitskundendienst, Incident Management und Problem Management LearningIn der Supportphase gewährleisten einzelne Gruppen im IT-Unternehmen eine stabile

Sicherheitsverwaltung der sicheren Umgebung über den Kundendienst und ein kontrolliertes Eskalationsmanagement in den Bereichen Incident und Problem Management.

10. Service Level Management, Financial Management und Availability ManagementZur Optimierung der Sicherheitsverwaltung gehören auch die Bereiche Service Level Management, Financial Management, Service Community Management, Availability Management, Capacity Management und Workforce Management.Um ein stabiles und leistungsfähiges Sicherheitsverwaltungsprogramm entwickeln, bereitstellen und verwalten zu können, müssen die Sicherheitslösung und MOF-Methoden als bewährte Methoden und Standards befolgt und eingehalten werden. Die erfolgreiche Kombination dieser Prozesse garantiert eine äußerst sichere Umgebung und stellt die Integrität, Vertraulichkeit und Verfügbarkeit der Ressourcen in der Unternehmensumgebung sicher. Abbildung 7 fasst die Standardphasen und -prozesse im Verlauf eines Sicherheitsprogramms für Unternehmen zusammen.

Abbildung 7: Das Prozessmodell für Sicherheitslösungen mit MSF und MOF

Obwohl die Programmmanagementrolle den gesamten Prozess in allen Phasen koordiniert, erfordert die erfolgreiche Umsetzung der einzelnen Meilensteine auch eine besondere Führungs- und Verantwortungsbereitschaft der anderen Teamcluster. Der Anteil jeder Rolle ist in den einzelnen Phasen unterschiedlich groß. Meilensteine können dazu beitragen, diese wechselnde Projektbeteiligung zu verwalten.

Tabelle 2: Wichtiges Steuerungsorgan für Meilensteine in den Phasen der Sicherheitslösung

Meilenstein Wichtiges Steuerungsorgan

Konzept/Umfang genehmigt Produktmanagement

Projektpläne genehmigt Programmmanagement

Umfang vollständig Entwicklung und Benutzererfahrung

Freigabe genehmigt Test- und Release Management

Bereitstellung abgeschlossen Release Management

Zu jeder Phase gibt es zudem Zwischenetappen, die zu dem endgültigen Abschlussmeilenstein hinführen. Abbildung 8 veranschaulicht diesen Vorgang.

Abbildung 8: Die Meilensteine der Sicherheitslösung

Ermitteln übergeordneter Faktoren

In dieser Phase können IT-Experten die Eignung eines möglichen Sicherheitslösungsprojekts überprüfen, indem sie das verfügbare Budget des Kunden, die vorrangigen Geschäftsanforderungen und den Problembereich in ihre Überlegungen einbeziehen. Geschäftskunden sollten in dieser Phase auf Ziele und Vorteile der Sicherheitslösung hingewiesen werden, so dass eine Einigung über das projektspezifische Potenzial einer Sicherheitslösung erzielt werden kann.

Zu Beginn dieser Phase wird zudem die folgende Kernfrage gestellt: „Welche Sicherheitsprobleme bestehen im Unternehmen und welche Möglichkeiten zur Sicherung der Unternehmensumgebung hat das Projektteam?“ In der Einführungsphase führt das Team Aufgaben durch und stellt Projektergebnisse auf, um die übergeordneten Anforderungen und Gesamtziele des Projekts für die Geschäftsprobleme oder -chancen zu definieren. Diese Phase endet mit dem Meilenstein „Konzept/Umfang genehmigt“ (siehe Abbildung 9), der anzeigt, dass Team und Kunde zu einer Einigung über Zweck und Richtung des Projekts gelangt sind.

Dieser Abschnitt des Entwurfs- und Umsetzungsleitfadens beschreibt ausführlich die Aufgaben in der Einführungsphase eines Projekts:

Zusammenstellen des Teams Das obere Management genehmigt das Projekt und benennt einen Programmmanager. Dessen erste Aufgabe ist es, ein Projektteam zusammenzustellen, das alle sechs MSF-Rollencluster abdeckt.

Definieren der Projektstruktur Das Team erstellt die Projektstruktur, welche die Verwaltungsstruktur für das Projektteam in der Planungsphase vorgibt. Dazu gehören auch die Standards, anhand derer das Team das Projekt verwaltet und unterstützt.

Definieren der Unternehmensziele Das Team identifiziert die Geschäftsprobleme oder -chancen und leitet daraus die Lösungsziele ab.

Bewerten der aktuellen Situation Das Team bewertet die aktuelle Unternehmenssituation und führt eine Diskrepanzanalyse durch, um einen geeigneten Ansatz zur Umsetzung des gewünschten Geschäftsergebnisses zu ermitteln.

Erstellen des Konzepts und Definieren des Projektumfangs Ein gemeinsames, klar formuliertes Konzept ist für den Projekterfolg von entscheidender Bedeutung. Das Team erarbeitet eine Konzeptaussage mit der langfristigen Richtungsvorgabe, die das Team im Hinblick auf die Unternehmensziele verfolgt. Das Team bestimmt und definiert zudem den genauen Projektumfang.

Definieren der vorrangigen Anforderungen und Benutzerprofile Das Team ermittelt die Anforderungen der einzelnen Hauptbeteiligten, Sponsoren sowie Endbenutzer und formuliert daraus das Lösungskonzept, stellt Kriterien für die Bewertung der Aussage zu Konzept/Umgang auf und entwickelt detailliertere Anforderungen, die in der nächsten Phase erläutert werden.

Erarbeiten des Lösungskonzepts Das Team wandelt die vorrangigen Anforderungen in ein erstes Konzept um, das den Ansatz für die Lösungsentwicklung skizziert. Das Lösungskonzept dient als erste Grundlage für den tatsächlichen Lösungsentwurf.

Bewerten des Risikos Das MSF empfiehlt einen proaktiven Risikoansatz. Das Team ermittelt Risikobereiche und erstellt Pläne dazu, wie in der Einführungsphase mit diesen Risiken umzugehen ist. Dieser fortlaufende Prozess wird während des gesamten Projektverlaufs regelmäßig wiederholt. Die größten Risiken werden in die Präsentation zur Meilensteinüberprüfung aufgenommen.

Bestätigen des Budgets In dieser Phase überprüft das Team die Mittel, die für die einzelnen Projektbereiche zur Verfügung stehen. Das geplante und verfügbare Budget sollten in etwa übereinstimmen.

Abschließen der Einführungsphase Zum Abschluss des Prozesses zur Meilensteingenehmigung wird eine Dokumentation zu diesen Aufgabenergebnissen angefertigt. Die Ergebnisse werden dem Management zur Genehmigung vorgelegt.

Zusammenstellen des Teams

Nach diesem Modell zusammengestellte Teams sind klein und disziplinübergreifend ausgerichtet. Die Verantwortung wird gemeinsam getragen, und die Kompetenzen aller Mitglieder ergänzen sich, so dass das jeweilige Projekt optimal durchgeführt werden kann. Alle Mitglieder verfügen über ein gemeinsames Projektkonzept, ein ausgeprägtes Projektengagement, hohe Qualitätsstandards sowie große Lernbereitschaft. Das Teammodell sieht keine Führungsrolle vor. Die Mitglieder arbeiten vielmehr auf gleichberechtigter Ebene zusammen, wobei jedes Teammitglied eine oder mehrere definierte Rollen übernimmt. Jede dieser Rollen rückt zu einem bestimmten Zeitpunkt in den Mittelpunkt des Prozesses.

Um die übergeordneten Unternehmensziele in ein klares Projektkonzept umformulieren zu können, benötigt ein Unternehmen ein Team auf der Grundlage der MSF-Rollen mit geeigneten, projektspezifischen Fähigkeiten. Dieses Team übernimmt die Definition des Projektkonzepts sowie -umfangs und gibt dem Unternehmen damit die allgemeine Richtung und realistische Erwartungen vor.

Definieren von Rollen und Verantwortungsbereichen

MSF geht von der Annahme aus, dass für den Erfolg jeder Lösung sechs wichtige Qualitätsziele erreicht werden müssen. Diese Ziele fungieren als Antriebsfaktoren und definieren den Schwerpunkt der sechs Teamrollen. Während das gesamte Team für den Projekterfolg verantwortlich ist, verbindet das Teammodell die sechs Ziele mit sechs voneinander abhängigen, disziplinübergreifenden Rollen, um die Verantwortung für die Umsetzung einzelner Projektaspekte eindeutig zuzuweisen und gemeinsame Fähigkeiten zu skizzieren.

Die MSF-Rollen können dafür verwendet werden, Funktionsbereiche und ihre zugehörigen Verantwortungsbereiche zu bestimmen. Sie sind unabhängig von bestimmten Organigrammformen oder Positionsbezeichnungen konzipiert, da sich diese Einteilung in jedem Unternehmen und Team ggf. deutlich unterscheidet. Eine Rolle bzw. ein Cluster kann, je nach Größe und Komplexität des Projekts und den für den Funktionsbereich erforderlichen Fähigkeiten, von einer oder mehreren Personen übernommen werden. In der Regel werden die Rollen auf verschiedene Gruppen innerhalb des IT-Unternehmens sowie, in Einzelfällen, auf Beauftragte im Unternehmen, externe Berater und Partner verteilt. Im Vordergrund steht dabei die Überlegung, welches Teammitglied für einen erfolgreichen Abschluss des Projekts am besten für welchen Rollencluster und die zugehörigen Funktionen, Verantwortungsbereiche und Beiträge in Frage kommt.

Programmmanagement

Um die Lösung im Rahmen der spezifischen Projekteinschränkungen einrichten zu können, sind ausgezeichnete Projektmanagementfähigkeiten erforderlich. Folgende Verantwortungsbereiche müssen durch geeignete Fähigkeiten und Techniken abgedeckt sein:

Koordinieren der Planung und Durchführen der Änderungskontrolle.

Definieren und Verwalten des Projektumfangs.

Erstellen eines Budgets und Verwalten der Kosten.

Erstellen und Verfolgen von Zeitplänen.

Zuweisen geeigneter Projektressourcen.

Verwalten von Verträgen und Anbietern sowie Akquirieren von Projektressourcen.

Koordinieren der Kommunikation inner- und außerhalb des Teams.

Vereinfachen des Risikomanagementprozesses.

Dokumentieren und Verfolgen des Qualitätsmanagementprozesses für das Team.

Das MSF-Teammodell enthält keine spezifische Projektmanagerrolle. Die meisten Funktionen des Projektmanagements werden jedoch von der MSF-Programmmanagementrolle übernommen.

Der MSF-Ansatz für das Projektmanagement zeichnet sich durch die folgenden drei Merkmale aus:

Die meisten der allgemein mit der Rolle „Projektmanager“ verbundenen Verantwortungsbereiche sind im Programmmanagement-Rollencluster des MSF zusammengefasst. Mit zunehmender Größe und Komplexität eines Projekts wird dieser Rollencluster in die zwei Bereiche Architektur/Spezifikationen und Projektmanagement unterteilt.

Bei Projekten größeren Umfangs können in MFS-Teams Projektmanagementtätigkeiten auf unterschiedlichen Ebenen anfallen. Je größer die Anzahl der Teammitglieder, desto mehr bietet sich eine Aufteilung der Projektmanagementtätigkeiten auf die Teamleiter der einzelnen MSF-Rollen an. Die Programmmanagementrolle ist dann für die Koordination der einzelnen Teamleiter und die Verwaltung der gesamten Lösung verantwortlich.

Große oder komplexe Projekte erfordern ggf. einen zusätzlichen Experten für das Projektmanagement bzw. ein Projektmanagementteam. Mit zunehmender Größe oder Komplexität bzw. zunehmenden Risiken werden häufig Spezialistenrollen oder -teams besetzt, die sich speziell mit einem bestimmten Projektbereich befassen. Bei der Programmmanagementrolle geschieht dies, indem die vielfältigen Aufgaben des Projektmanagements in kleinere, übersichtlichere Verantwortungsbereiche aufgeteilt werden. Diese Bereiche können dann einem Spezialisten für das Projektmanagement, Risikomanagement, die Lösungsarchitektur oder Zeitplanung übertragen werden.

Produktmanagement

Das Produktmanagementteam fungiert im Projektteam als Kundenratgeber. Es stellt sicher, dass das ganze Team die Anforderungen, Bedenken, Fragen und das Feedback des Kunden über den gesamten Projektverlauf hinweg berücksichtigt. (Als „Kunde“ wird hier diejenige Person, Personengruppe oder Abteilung im Unternehmen bezeichnet, die für die Projektfinanzierung verantwortlich ist und grundlegende Entscheidungen hinsichtlich der Implementierung treffen kann.) Das Produktmanagementteam fungiert auch als Verbindungsglied zwischen dem Team und dem Kunden, indem es die allgemeine Kommunikation koordiniert und auf die Erwartungen des Kunden eingeht. Die Mitglieder des Produktmanagementteams müssen die Unternehmensanforderungen der Lösung genau kennen, einschließlich ihrer Arbeitsweise, der Geschäftsprozesse und Richtlinien.

Zu den Verantwortungsbereichen des Produktmanagements im Projekt gehören:

Marketing: Stellt die allgemeine Akzeptanz der Sicherheitsmaßnahme sicher.

Geschäftswert: Wägt Unternehmensanforderungen und Sicherheitsrisiken sowie Eskalieren der Sicherheitsänderungen bis auf die höchste Ebene ab. (Falls dies zur Umsetzung nötig ist.)

Kundenberatung: Stellt sicher, dass die Sicherheitsänderungen nicht auf Kosten der Produktivität gehen.

Produktplanung: Stellt die Vorteile des Sicherheitsprojekts heraus.

Programmmanagement

Die Programmmanagementrolle ist dafür verantwortlich, das Team bei der Entscheidungsfindung anzuleiten und die Projektpläne voranzutreiben. Das Programmmanagement ist zuständig für die gesamte Kommunikation innerhalb des Teams und die Einhaltung der Unternehmens- und Projektstandards.

Die Teammitglieder mit dieser Rolle sollten außerdem ausreichend mit den technischen Schwierigkeiten vertraut sein, um Teamentscheidungen entsprechend zu beeinflussen. Hauptaufgabe dieser Rolle ist es, die Zielorientierung des Teams aufrecht zu erhalten. Eine detaillierte Kenntnis aller für das Projekt nötigen Fähigkeiten ist nicht unbedingt erforderlich. Die Programmmanagementrolle übernimmt bei der Entscheidungsfindung auch eine Mittlerfunktion und stellt sicher, dass Kompromisse von allen Teammitgliedern getragen werden können.

Zu den Verantwortungsbereichen des Programmmanagements im Projekt gehören:

Projektmanagement: Ermöglichen der frist-, ressourcen- und funktionsgerechten Bereitstellung der Sicherheitslösung in Absprache mit dem Team.

Lösungsarchitektur: Erstellen des Sicherheitsmaßnahmenplans (Projektplans) und eines Dokuments zur Funktionsspezifikation.

Prozesssicherung: Pflegen des Dokuments zu Projektrisiken.

Verwaltungsaufgaben: Anfertigen von Projektstatusberichten.

Entwicklung

Die Entwicklungsrolle ist verantwortlich für den Entwurf, die Erstellung und die Tests der Einheiten der grundlegenden Sicherheitslösung. Dazu gehören Schnittstelle, Schlüsselkomponenten und Datenbankschema ebenso wie die Integration in Drittanbietersysteme.

Die Entwicklungsmitglieder sind dafür zuständig, die Architektur und physische Struktur der Lösung zu erstellen, den Lösungs- und Funktionsentwurf auszuarbeiten, den Umsetzungsaufwand abzuschätzen, Prototypen zu erstellen, um die Entscheidungsfindung zu erleichtern und Entwicklungsrisiken zu mindern, und schließlich die Lösung selbst zu erstellen. Darüber hinaus fungieren die Mitglieder dieses Teams auch als Technologieberater, indem sie sich an der Technologiebewertung beteiligen und Empfehlungen zum Einsatz bestimmter Technologien aussprechen.

Die Entwicklungsrolle übernimmt die Aufwands- und Zeitschätzung selbst, da sie täglich mit den entwicklungstechnischen Ausnahmefaktoren zu tun hat und diese daher am besten einschätzen kann. Dieses Konzept der von unten nach oben verlaufenden Einschätzung stellt einen zentralen MSF-Grundsatz dar und wird vom MSF als „Bottom-Up“ bezeichnet. Ziel dieses Ansatzes sind hochqualitative Pläne, eine größere Verantwortung der Mitarbeiter, welche die Schätzungen erstellen, und eine bessere Arbeitsqualität.

Zu den Verantwortungsbereichen der Entwicklungsrolle im Projekt gehören:

Technologieberatung: Unterstützt das Team bei der Evaluierung möglicher Sicherheitsänderungen.

Implementierungsarchitektur und Design: Stellt die Tools und die Testumgebung für Sicherheitsänderungen bereit.

Infrastrukturentwicklung: Entwickelt Verfahren zur Umsetzung des Sicherheitsmaßnahmenplans.

Tests

Tester sind dafür zuständig, die Komponenten, Architektur und zugehörige Dokumentation im Hinblick auf die Funktionsspezifikation zu testen und die Einhaltung aller Anforderungen des Sicherheitsprojekts zu gewährleisten. Die Testrolle ist in vielfacher Hinsicht der wichtigste Bestandteil des Gesamtprojekts. Kann die Lösung nicht getestet werden, erhält das Team keine zuverlässigen Informationen darüber, ob alle Bestandteile ordnungsgemäß funktionieren, und kann Fehler vor der Freigabe nicht mehr beseitigen.

So wie es verschiedene Typen von Entwicklungsrollen gibt, gibt es auch verschiedene Testrollen für unterschiedliche Tests – je nach Bedarf beispielsweise zu Sicherheit, Leistung, Kompatibilität, Belastung, Nutzbarkeit usw. Die Mitglieder dieser Rolle müssen über vergleichbare Fähigkeiten verfügen wie die am selben Projekt arbeitenden Entwickler.

Zu den Verantwortungsbereichen der Testrolle im Projekt gehören:

Testplanung: Erstellt den Sicherheitstestplan.

Testengineering: Überprüft, ob die Lösung die Anforderungen der Funktionsspezifikation erfüllt.

Testberichte: Führt Tests durch und gibt entsprechendes Feedback.

Benutzererfahrung

Die Benutzererfahrungsrolle fungiert als Ratgeber für den Endbenutzer. Diese Rolle definiert die Funktionsanforderungen aus der Sicht des Endbenutzers. In der Regel fallen in diesen Rollenbereich das Grafikdesign, die Sicherstellung der Nutzbarkeit und die Oberflächenentwicklung. Weitere Schlüsselfunktionen dieser Rolle werden dagegen häufig übersehen. Zum Beispiel die Entwicklung der Hilfe-, Schulungs- und Kommunikationsunterlagen, zu denen u. a. häufig gestellte Fragen (FAQs) und andere Begleitdokumentation gehören.

Zu den Verantwortungsbereichen der Benutzererfahrungsrolle im Projekt gehören:

Technische Kommunikation: Gibt Änderungen an die Benutzer weiter.

Schulung: Führt Schulungen zu neuen Sicherheitsverfahren durch.

Verwendbarkeit: Gibt Benutzerfeedback zu Änderungen weiter.

Release Management

Die Release Management-Rolle ist am Entwurfsprozess beteiligt und gewährleistet die Einsatz-, Verwaltungs- und Supportfähigkeit der fertigen Lösung. Diese Rolle übernimmt eine Ratgeberfunktion für den Betrieb, den Produktsupport, den Helpdesk usw., um die reibungslose Bereitstellung und fortlaufende Verwaltung der Lösung zu ermöglichen. Mit Beginn der Entwicklungsphase ist das Release Management direkt mit dem Betriebsbereich verbunden.

Die Release Management-Rolle ist verantwortlich für die Koordination aller Aktivitäten zur erfolgreichen Einführung der Projektlösung und für die Definition und Dokumentation der Verwaltungsstrategien und -prozesse im Lebenszyklus. Die Mitglieder dieser Rolle fungieren als Supportratgeber für den IT-Betrieb im Team. Dazu gehören u. a. die Vorbereitung der Entwicklungs-, Test- und Stagingumgebungen und der Einsatz der Lösung.

Das Release Management muss mit der gesamten betrieblichen Umgebung vertraut sein, einschließlich des technischen Supports und Helpdesks. Die Mitglieder mit dieser Rolle müssen auch die Auswirkung der Lösung auf die Legacyumgebung kennen.

Zu den Verantwortungsbereichen der Release Management-Rolle im Projekt gehören:

Infrastruktur: Koordiniert Infrastrukturänderungen.

Support: Richtet den Kundendienst für Änderungen an der Computerumgebung ein.

Betrieb: Verteilt Betriebshandbücher.

Logistik: Verfolgt chronologisch Sicherheitsänderungen.

Zuweisen von Rollen

Obwohl jede Rolle bereits in der Einführungsphase eingerichtet werden sollte, muss zu diesem Zeitpunkt nicht unbedingt schon das gesamte Projektteam gebildet werden. Auch muss nicht jedes Teammitglied bereits vollständig für das Projekt zur Verfügung stehen. Wichtig ist jedoch, schon in der Einführungsphase für jede Rolle einen Teamleiter zu benennen.

Nach dem MSF-Modell sind alle sechs Rollen von gleich großer Bedeutung für das Team. Alle sechs Leiter sollten demnach von Beginn an vollständig für das Projekt zur Verfügung stehen. In der Praxis ist dies jedoch nicht immer möglich, da einige Teammitglieder zunächst noch andere Projekte abschließen müssen.

Beachten Sie bei der Zuweisung von Mitarbeitern zu Rollen folgende Richtlinien:

Sofern möglich, sollten die Produkt- und Programmmanagementrollen von Beginn an vollständig für das Projekt zur Verfügung stehen.

Obwohl der Entwicklungsleiter in der Einführungsphase noch andere Projekte abschließen kann, wäre es wünschenswert, dass diese Person bereits vollständig für das Projekt verfügbar ist. Gehen Sie davon aus, dass dieser Rolle zu einem späteren Zeitpunkt in der Entwicklungsphase noch weitere Teammitglieder zuzuweisen sind.

Obwohl der Testleiter in der Einführungsphase ggf. noch an anderen Projekten arbeiten kann, sollte diese Person von Projektbeginn an zumindest teilweise eingebunden sein und an allen wichtigen Entscheidungen beteiligt werden. Unter Umständen können der Testrolle in der Entwicklungsphase weitere Teammitglieder zugewiesen werden.

Der Leiter der Benutzererfahrungsrolle sammelt in der Einführungsphase Benutzerprofildaten. Diese Person kann in der Einführungsphase ggf. noch anderen Projekten zugewiesen sein. Zusätzliche Teammitglieder für diese Rolle können in der Entwicklungs-, Stabilisierungs- und Bereitstellungsphase benannt werden.

Der Leiter der Release Management-Rolle beteiligt sich in der Einführungsphase an der Bewertung der aktuellen Situation. Diese Person kann in der Einführungsphase noch anderen Projekten zugewiesen sein. Unter Umständen können zusätzliche Teammitglieder für diese Rolle in der Stabilisierungs- und Bereitstellungsphase benannt werden.

Alle Teammitglieder, die während der Einführungsphase noch an anderen Projekten arbeiten, müssen über ein gutes Zeit- und Arbeitsmanagement verfügen, um ihre Projektpflichten nicht zu vernachlässigen. Teammitglieder, die parallel an anderen Projekten arbeiten, stellen ein Risiko dar und sollten als solches vermerkt und überwacht werden.

Wenn der Programmmanager oder einer der anderen Leiter bereits darüber informiert ist, dass zu einem späteren Zeitpunkt noch weitere Mitglieder zu seinem Team hinzugefügt werden, kann dies in die Projektstruktur aufgenommen werden. Künftige Teammitglieder müssen zu diesem Zeitpunkt noch nicht in das Projekt einbezogen werden. Sie können ihnen jedoch bereits die Projektdokumentation für die Einarbeitung zur Verfügung stellen.

Bei der Lösungsentwicklung müssen die Teammitglieder in der Lage sein, klare und logische Beziehungen zwischen den Funktionen und Verantwortungsbereichen ihrer jeweiligen Aufgabe und denen der MSF-Teammodellstruktur herzustellen. Kunden, Partner und Microsoft haben vermutlich jeweils einen individuellen Entwicklungs- und Betriebsansatz und eine andere Organisationsstruktur. Diese Unterschiede müssen abgestimmt und überwunden werden, damit alle Parteien Personen in ihrem jeweiligen Unternehmen eindeutig bezeichnen und ihre Rollen im Projektverlauf oder bei der betrieblichen Verwaltung verstehen können. Eine übersichtliche Klassifizierung der Objekte kann die eindeutige Zuordnung dieser Beziehungen vereinfachen.

Die Microsoft Frameworks IT Occupation Taxonomy stellt eine wertvolle Ressource für Kunden und Partner dar. Anhand dieser Klassifizierung können, unabhängig von der jeweiligen Unternehmensstruktur, mühelos die Personen bezeichnet werden, die über die erforderlichen Talente zur erfolgreichen Umsetzung der Sicherheitslösung verfügen.

Wenn alle Projektbeteiligten zur Definition von Rollen und Funktionen dieselbe Terminologie verwenden, kann das Risiko von Fehlern und Missverständnissen deutlich verringert werden. Nach Projektabschluss kann die Klassifizierung auf die betriebliche Umgebung angewendet werden, um zu gewährleisten, dass die Sicherheitslösung auch weiterhin äußerst leistungsfähig bleibt.

Skalieren der Teams

Obwohl das MSF sechs Einzelrollen unterscheidet, bedeutet dies nicht, dass jedes Team aus genau sechs Personen bestehen muss. Je nach Art und Umfang eines Projekts kann das Kernteam aus mehr oder weniger als sechs Personen bestehen, von denen einige unter Umständen nur teilweise am Projekt arbeiten.

In einem Großunternehmen macht es häufig Sinn, einige Projektmitglieder vollständig für ihre Aufgaben freizustellen, um eine stabile Supportlösung zu entwickeln. Diese Teammitglieder arbeiten ausschließlich für dieses Projekt und tragen daneben keine weitere Verantwortung. Eine solche Struktur kann für kleine Unternehmen unpraktisch sein. Dort kann der Projektumfang klein gehalten werden, indem die Teammitglieder ihre Arbeitszeit zwischen dem Projekt und anderen Funktionen aufteilen. Das Lösungsteam muss diese Aspekte bei der Projektplanung und -zusammenstellung berücksichtigen.

Zusammenstellen von kleinen Teams

Für kleine Projekte, oder Projekte mit begrenzten Ressourcen, bietet sich ein kleines Kernteam an. In diesem übernimmt mindestens ein Mitglied zwei oder mehrere Rollen. Als Kombinationsmöglichkeiten der Projektrollen kommen beispielsweise in Frage:

Release Management und Benutzererfahrung.

Tests und Benutzererfahrung.

Programmmanagement und Release Management.

Einige Rollen sollten nicht miteinander kombiniert werden. Die Entwicklungsrolle sollte z. B. nicht für die Tests zuständig sein, da damit keine objektive Bewertung der Entwicklungsergebnisse erzielt werden kann. Auch sollte nicht ein und dasselbe Teammitglied für Programm- und Produktmanagement verantwortlich sein. Obwohl es verführerisch scheinen mag, diese beiden Rollen derselben Person zuzuweisen, könnten daraus Interessenskonflikte entstehen.

Bei kleinen Projekten kann das Kernprojektteam aus nur drei Personen bestehen: einer Person für das Programm- und Release Management, eine Person für die Entwicklung und eine Person für die Tests, die Benutzererfahrung und das Produktmanagement. Je nach Art des Projekts und Fähigkeiten der Teammitglieder können Sie auch eine andere Variation wählen. Berücksichtigen Sie dabei aber die oben genannten Einschränkungen.

Zusammenstellen von großen Teams

Bei Großprojekten bietet es sich an, einigen Rollen mehrere Teammitglieder zuzuweisen.

Dies betrifft in erster Linie die Entwicklungsrolle, die je nach Projektart in eine Reihe unterschiedlicher Funktionsteams unterteilt werden kann. Berücksichtigen Sie bei der Erstellung von Funktionsteams die logische Arbeitsteilung. Ein Team könnte beispielsweise mit der Erstellung des Back-End-Datenspeichers befasst sein, während ein anderes an der Entwicklung der Unternehmenslogikkomponenten der mittleren Stufe oder an Verwaltungsfunktionen arbeitet.

Jedes dieser Funktionsteams kann aus einem oder mehreren Entwicklern bestehen, und jeder Entwickler kann in einem oder mehreren Funktionsteams mitarbeiten. Berücksichtigen Sie bei der Aufnahme neuer Mitglieder stets, dass das Team nicht zu groß werden darf, um effektiv als Gruppe zusammenzuarbeiten.

Sie haben natürlich die Möglichkeit, kleine und große Teams zu kombinieren, indem Sie beispielsweise einem einzelnen Teammitglied mehrere Rollen zuweisen und parallel dazu mehrere

Teammitglieder zu einer anderen Einzelrolle zuweisen. Voraussetzung dabei ist, dass jedes Mitglied das Ziel der ihm zugewiesenen Rolle im Lösungsteam weiterhin mit oberster Priorität verfolgen kann.

Projektteamrollen für Sicherheitslösungen

Das Projektorganigramm für Sicherheitslösungen (siehe Abbildung 9 unten) weist neben einer hierarchisch aufgebauten Projektteamstruktur auch einen Eskalationsweg für möglicherweise auftretende Probleme auf. Es gewährleistet dabei aber dennoch den ungehinderten Kommunikationsfluss im Team. Obwohl die Rollen in dieser Struktur nicht notwendigerweise immer Einzelpersonen entsprechen, kann eine einzelne Person auch mehrere Rollen übernehmen. Je nach Projektumfang können sich Projektteamrollen häufig ändern. Die in diesem Modell beschriebenen Berater übernehmen eine Leitungsfunktion in ihrem jeweiligen Bereich. Sie arbeiten in der Regel mit einem oder mehreren Experten (Subject Matter Experts oder SMEs) zusammen. Dieses Teammodell für Sicherheitslösungen kombiniert die Effektivität der MSF- und MOF-Teammodelle.

Vor dem Implementierungsbeginn eines Sicherheitslösungsprojekts müssen die Rollen und Verantwortungsbereiche des Projektteams klar definiert und geeigneten Mitgliedern zugewiesen werden. Je nach Projektumfang kann jede Rolle einer Einzelperson oder einem Team mit eigenem Leiter zugewiesen werden. Die Teamleiter sind verantwortlich für die Verwaltung, Anleitung und Koordination ihres Teams, während sich die anderen Teammitglieder schwerpunktmäßig der Umsetzung der Teamziele widmen. Obwohl eine Person mehrere Rollen in einem Projektteam übernehmen kann, sollten bestimmte Rollen nicht kombiniert werden, wie z. B. Test- und Entwicklungsleiter, um die objektive Bewertung des Entwurfs nicht zu beeinträchtigen.

Berücksichtigen Sie bei der Teamauswahl und bei der Zuweisung von Rollen und Verantwortungsbereichen auch die jeweils erforderlichen Fähigkeiten, um die richtigen Personen den richtigen Rollen zuzuweisen. In den folgenden Abschnitten werden die empfohlenen Rollen innerhalb eines Projektteams mit ihren jeweiligen Verantwortungsbereichen erläutert.

Abbildung 9: Projektteamrollen für Sicherheitslösungen

Projektsponsor

Der Projektsponsor ist eine Führungskraft oder ein Mitglied des oberen Managements im Kundenunternehmen. Da der Projektsponsor die endgültige Verantwortung für den Erfolg bzw. das Scheitern des Projekts trägt, muss er dieselben Ziele verfolgen wie das Projektteam. Obwohl der Projektsponsor nicht in den täglichen Projektverlauf involviert ist, muss diese Person bei allen Meilensteinüberprüfungen einbezogen werden. Zu den wichtigsten Aufgaben des Projektsponsors gehört es, dem Team die eigenen Grundvorstellungen und Ziele zu vermitteln, über den Beratungsprogrammmanager Einfluss auf das Team zu nehmen und Hindernisse im Kundenunternehmen aus dem Weg zu räumen. Eine als Projektsponsor eines Sicherheitslösungsprojekts geeignete Person wäre beispielsweise der Sicherheitsbeauftragte des betreffenden Unternehmens.

Übersicht der Projektbeteiligten

Diese Übersicht ist bei der Zusammenstellung des Projektteams sehr hilfreich. Sie bildet die definierten Projektbeteiligten grafisch ab. Die Übersicht kann dazu beitragen, die politischen

Zusammenhänge zwischen den einzelnen Beteiligten zu verstehen. Neben Risiken wie einer unzureichenden finanziellen Unterstützung oder Änderungspositionierung, können damit auch Widerstände in Kernbereichen oder Eskalationswege für die Problemlösung aufgezeigt werden.

Produktmanagement

Der Produktmanager vertritt die Anforderungen und Interessen der Endbenutzer im Projekt und fungiert als Schnittstelle zwischen dem Projektteam und dem Kunden. Oberstes Ziel eines Produktmanagers sind die Kundenzufriedenheit und die anforderungsgerechte Bereitstellung der Lösung.

Der Produktmanager benötigt keinen technischen Hintergrund, muss dem Projekt aber in Vollzeit zur Verfügung stehen. Zu den wichtigsten Aufgaben des Produktmanagers gehört es, bei den Endbenutzern Informationen über Probleme und Risiken einzuholen, ihnen bei wichtigen Meilensteinen einen Projektüberblick und Statusbericht zu geben und sich direkt mit den anderen Projektteams auszutauschen.

Programmmanagement

Der Programmmanager benötigt ein technisches Verständnis der Gesamtlösung. Er muss mit Ansprechpartnern auf allen Unternehmensebenen kommunizieren können und eingehend mit dem Konzept, Umfang, Budget, Zeitplan und den Beteiligten des Projekts vertraut sein. Ziel des Programmmanagers ist der frist- und budgetgerechte Abschluss des Projekts. Der Programmmanager ist in Vollzeit für die tägliche Logistik verantwortlich.

Da gerade bei Budgetfragen und wichtigen Meilensteinterminen eine Zusammenarbeit mehrerer Projektgruppen unverzichtbar ist, wird empfohlen, den Kunden eng in das Programmmanagement einzubeziehen.

Produktmanager

Die Hauptziele des Produktmanagers sind die Kundenzufriedenheit und die anforderungsgerechte Bereitstellung der Lösung.

Verantwortungsbereiche

Zu den Verantwortungsbereichen des Produktmanagers im Projekt gehören:

Fungieren als zentraler Ansprechpartner.

Verwalten der Beziehung zum Projektsponsor zur Umsetzung der Sicherheitslösung.

Überwachen der Umsetzung der Sicherheitslösung beim Kunden.

Verwalten der projektspezifischen Risiken.

Eskalieren von Projektproblemen an den Kunden.

Zuweisen von Ressourcen zu Projektrollen in Absprache mit dem Projektmanager.

Unterstützen von Verfahren zur Prozessverbesserung im Rahmen der Sicherheitslösungsmethode.

Starke Präsenz beim Kunden vor Ort.

Festlegen und Verwalten von Kundenerwartungen, Statusberichten und Teamkommunikation.

Sammeln von Kundendokumentation, Kundenfeedback und Kundenerfolgsgeschichten.

Abwickeln der Kundenfakturierung.

Zusammenarbeit mit dem Supportberater während der gesamten betrieblichen Migration.

Koordinieren von Projektstart und -abschluss.

Erforderliche Fähigkeiten Hervorragendes Know-How im Verwaltungsbereich.

Vielschichtiges Kommunikationsvermögen mit Kunden, Sponsor und Team.

Schriftliches Verfassen von Statusberichten, Eskalationsdokumentation und Dienstplanungsangaben.

Erfahrungen im Eskalationsmanagement.

Erfahrungen in den Bereichen HR-Planung, Vertrags- und Akquiseprozesse, Ressourcenkoordination, Risiko-, Kosten-, Qualitäts-, Umfangs- und Sicherheitsmanagement.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Gute Kenntnis der Sicherheitslösung.

Ausgezeichnete Mitarbeiterführung.

Gleichwertige Voraussetzungen Zertifizierung als Project Management Professional (PMP).

Zertifizierung als Microsoft Certified Systems Engineer (MCSE).

Zertifizierung als Certified Information Systems Security Professional (CISSP).

Zertifizierung als Information Technology Infrastructure Library (ITIL).

Projektbeiträge Übersicht der Projektbeteiligten

Projektmasterplan

Projektkonzept/Umfang

Projektzeitplan

Kommunikationsplan

Projektorganigramm und Teammodell

Rollen und Verantwortungsbereiche

Sicherheitsprogrammziele

Risikoplan

Statusberichte

Kundenbesuchsberichte

Besprechungsprotokolle

Freigabeempfehlungen

Projektmanager

Der Projektmanager ist zuständig für die Projektintegrität. Dazu gehört beispielsweise die Abstimmung widersprüchlicher Forderungen einzelner Projektparteien. Der Projektmanager arbeitet eng mit dem Programmmanager zusammen und muss dem Projekt in Vollzeit zur Verfügung stehen.

Verantwortungsbereiche Verwalten der Prozesse und Verfahren des Sicherheitslösungsprojekts.

Zuweisen von Projektressourcen in Absprache mit dem Programmmanager.

Verfolgen von Änderungskontrollanfragen.

Verfolgen des Budgetverbrauchs.

Verwalten von Ressourcen.

Verwalten der Projekteskalation.

Verwalten des Projektzeitplans.

Koordinieren der teamübergreifenden Interaktion.

Verwalten von Risiken.

Unterstützen von Prozessverbesserungen im Rahmen des Sicherheitslösungsprojekts.

Erstellen von SOWs (Statements of Work) zu jeder Phase.

Sammeln von Kundenerfolgsgeschichten und gewonnenen Erfahrungen.

Koordinieren der Berichte zur Kundenzufriedenheit, der Projektübergabe an den Supportberater und des Projektabschlusses.

Überwachen der Kundenfakturierung.

Erforderliche Fähigkeiten Projektmanagementfähigkeiten zur Verwaltung des Sicherheitslösungsprojekts.

Vielschichtiges Kommunikationsvermögen mit Kunden, Sponsor und Team.

Schriftliches Verfassen von Statusberichten und Verwalten der Zeit- und Projektplandaten sowie der internen Eskalationsdokumentation für Beratungsprogrammmanager und Projektsponsoren.

Erfahrungen in den Bereiche HR-Planung, Vertrags- und Akquiseprozesse, Ressourcenkoordination, Risiko-, Kosten-, Qualitäts- und Umfangsmanagement.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Gute Kenntnis der Sicherheitslösung.

Ausgezeichnete Mitarbeiterführung.

Zertifizierung als PMP.

Zertifizierung als MCSE.

Zertifizierung als CISSP.

Zertifizierung als ITIL.

Projektbeiträge Sämtliche SOWs

Besprechungsprotokolle

Projektzeitplan

Budgetverfolgung

Kundenbesuchsberichte

Lösungsarchitekt

Der Lösungsarchitekt entwickelt eine maßgeschneiderte Sicherheitslösung für den Geschäftskunden und trägt dafür die endgültige Verantwortung. Der Lösungsarchitekt arbeitet in Vollzeit mit Entwicklern und Technikern aus unterschiedlichen Teams zusammen, um die vollständige Integration der Lösung in den folgenden Bereichen zu gewährleisten:

Betriebssystem

Anwendungen

Netzwerk

Sicherheit

Datenverwaltung

Der Lösungsarchitekt muss während der Entwicklung aktiv mit dem Kunden zusammenarbeiten und sicherstellen, dass der Kunde in wichtige Entscheidungen und Kompromisse zur technischen Implementierung einbezogen wird.

Verantwortungsbereiche Entwickeln und Einrichten der Sicherheitslösung.

Überwachen der Entwicklung der Architekturkomponenten.

Prüfen der Geschäftsaktivitäten für größeren Mehrwert der Lösung.

Anleiten des Teams bei der Erstellung von Wertaussagen (Value Statements).

Integrieren der Sicherheitslösung in die bestehende Unternehmensstruktur.

Entwickeln und Umsetzen des Kundenmigrationsplans.

Verwalten und Bereitstellen der Kundenbewertungsdaten.

Sicherstellen, dass der Kundenbewertungsprozess in die Planungsphase überführt werden kann.

Verwalten und Lösen von bereichsübergreifenden Integrationsproblemen.

Erstellen der Anforderungen der Testumgebung.

Unterstützen von Verfahren zur Prozessverbesserung bei der Datenanalyse.

Unterstützen von Planungsprozessen und -verfahren für Labordienste und Implementierung der Sicherheitslösung beim Kunden.

Erforderliche Fähigkeiten Vielschichtiges Kommunikationsvermögen mit Kunden und Team.

Professionelles schriftliches Ausdrucksvermögen.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Hervorragendes Know-how im Verwaltungsbereich, in der HR-Planung und im Risikomanagement.

Umfassendes Verständnis der von Microsoft unterstützten Anwendungsarchitekturen.

Umfassende Kenntnis der bewährten Methoden von Microsoft, der funktionalen Einschränkungen des Produkts und der offenen Systeme.

Gute Kenntnis der Generierung des Microsoft-Produktlebenszyklus, der Anforderungen produktbezogener Servicepacks und der verfügbaren Hotfixes.

Umfassendes Wissen und ausgezeichnete Kenntnis der Anwendungs- und Datenmigration, sowie der zugehörigen Strategien und Methoden.

Schulungserfahrung zur Unterstützung von Prozessen und Verfahren der Kundenbewertung.

Ausgezeichnete Mitarbeiterführung.

Gleichwertige Kenntnisse Zertifizierung als CISSP.

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Projektbeiträge Kundenbesuchsberichte

Lösungskonzept/Umfang

Diskrepanzanalyse

Vorläufiger Erstentwurf der Lösung

Lösungserstellungsplan

Plan für die betriebliche Migration

Entwicklungsleiter

Der Entwicklungsleiter ist an der Erstellung der Sicherheitslösung für den Kunden beteiligt. Er arbeitet, um eine vollständig integrierte Lösung zu gewährleisten, in Vollzeit mit Entwicklern und Technikern aus folgenden Bereichen zusammen:

Betriebssystem

Anwendungen

Netzwerk

Sicherheit

Datenverwaltung

Der Entwicklungsleiter muss während der Entwicklung aktiv mit dem Geschäftskunden zusammenarbeiten und sicherstellen, dass der Kunde in wichtige Entscheidungen und Kompromisse zur technischen Implementierung einbezogen wird.

Verantwortungsbereiche Unterstützen bei der Entwicklung und Bereitstellung der Sicherheitslösung.

Unterstützen bei der Entwicklung der Architekturkomponenten.

Prüfen der Geschäftsaktivitäten für größeren Mehrwert der Lösung.

Anleiten des Teams bei der Erstellung von Wertaussagen (Value Statements).

Integrieren der Sicherheitslösung in die bestehende Kundenstruktur.

Entwickeln und Umsetzen des Kundenmigrationsplans.

Verwalten und Bereitstellen der Kundenbewertungsdaten.

Sicherstellen, dass der Kundenbewertungsprozess in die Planungsphase überführt werden kann.

Verwalten und Lösen von bereichsübergreifenden Integrationsproblemen.

Erstellen der Anforderungen der Testumgebung.

Unterstützen von Verfahren zur Prozessverbesserung bei der Datenanalyse.

Unterstützen von Planungsprozessen und -verfahren für Labordienste und Implementierung der Sicherheitslösung beim Kunden.

Verwalten von Entwicklungsplan und Budget.

Erforderliche Fähigkeiten Vielschichtiges Kommunikationsvermögen mit Kunden und Team.

Professionelles schriftliches Ausdrucksvermögen.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Hervorragendes Know-how im Verwaltungsbereich, in der HR-Planung und im Risikomanagement.

Umfassendes Verständnis der von Microsoft unterstützten Anwendungsarchitekturen.

Umfassende Kenntnis der bewährten Methoden von Microsoft, der funktionalen Einschränkungen des Produkts und der offenen Systeme.

Gute Kenntnis der Generierung des Microsoft-Produktlebenszyklus, der Anforderungen produktbezogener Servicepacks und der verfügbaren Hotfixes.

Umfassendes Wissen und ausgezeichnete Kenntnis der Anwendungs- und Datenmigration sowie der zugehörigen Strategien und Methoden.

Schulungserfahrung zur Unterstützung von Prozessen und Verfahren der Kundenbewertung.

Ausgezeichnete Mitarbeiterführung.

Zertifizierung als CISSP.

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Projektbeiträge Kundenbesuchsberichte

Lösungskonzept/Umfang

Diskrepanzanalyse

Vorläufiger Erstentwurf der Lösung

Lösungstestplan

Lösungserstellungsplan

Plan für die betriebliche Migration

Finanzberater

Der Finanzberater prüft zusammen mit dem Kunden die geschäftlichen Auswirkungen der Lösung und erstellt daraus die finanzielle Projektbewertung. Der Finanzberater arbeitet eng mit dem Lösungsarchitekten zusammen und befasst sich in Vollzeit mit der Datensammlung und der Analyse der finanziellen und geschäftlichen Daten.

Verantwortungsbereiche Gespräche mit Projektbeteiligten und Benutzern im Unternehmen.

Informieren des Projektteams über die Vorteile der Sicherheitslösung und die Kostenschätzungen.

Anleiten des Projektteams bei der Identifizierung von neuen geschäftlicher Chancen.

Erstellen von Cashflowprognosen und Amortisierungsberechnungen.

Sammeln von Kundenerfolgsgeschichten und gewonnenen Erfahrungen.

Erforderliche Fähigkeiten Detaillierte Kenntnis der vertikalen Unternehmensstruktur des Kunden und seiner Geschäftstätigkeit.

Kommunikationsvermögen zum Sammeln, Bemessen und Analysieren der finanziellen und Geschäftsdaten des Kunden.

Vielschichtiges Kommunikationsvermögen mit Kunden, Sponsor und Team.

Hervorragendes Know-How im Verwaltungsbereich und Risikomanagement.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Gute Kenntnis der Sicherheitslösung.

Ausgezeichnete Mitarbeiterführung.

Zertifizierung als ITIL.

Projektbeiträge Lösungskonzept/Umfang

Untersuchung der geschäftlichen Auswirkungen

Finanzielle Projektbewertung

Kundenbesuchsberichte

Infrastrukturberater

Der Infrastrukturberater befasst sich in Vollzeit mit der Bewertung der Kundendaten, um daraus eine Sicherheitslösung und den Bericht zur Diskrepanzanalyse zu erstellen. Infrastrukturberater arbeiten in unterschiedlichen Teams, um die vollständige Integration der Lösung in folgenden Bereichen zu gewährleisten:

Betriebssystem

Netzwerk

Sicherheitsverwaltung

Sicherheitsprogramm

Datenverwaltung

Verantwortungsbereiche Verwalten der Prozesse und Verfahren zur Bewertung der Kundendaten.

Sicherstellen, dass im Anschluss an die Diskrepanzanalyse die Planungsphase folgen kann.

Unterstützen von Verfahren zur Prozessverbesserung bei der Datenanalyse.

Verwalten und Bereitstellen der Kundenbewertungsdaten.

Unterstützen von Planungsprozessen und -verfahren für Labordienste und Implementierung der Sicherheitslösung beim Kunden.

Bewerten der Infrastruktur, der Bereitstellungsprozesse und Kundenverfahren sowie Herausgeben von Empfehlungen.

Vorbereiten des Bewertungsberichts zur Supportfähigkeit der Sicherheitslösung.

Durchführen der Diskrepanzanalyse.

Validieren des Testplans.

Erforderliche Fähigkeiten Umfassende Kenntnis der Implementierung von Microsoft-Netzwerkdiensten, einschließlich Microsoft® Windows NT®-Domänen, dem Microsoft® Active Directory®-Verzeichnisdienst, Windows Internet Naming Service (WINS), Domain Name System (DNS) und Dynamic Host Configuration Protocol (DHCP).

Professionelles schriftliches Ausdrucksvermögen.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Umfassendes Verständnis der von Microsoft unterstützten Produktarchitekturen.

Umfassende Kenntnis der bewährten Methoden von Microsoft, der funktionalen Einschränkungen des Produkts und der offenen Systeme.

Gute Kenntnis der Generierung des Microsoft-Produktlebenszyklus, der Anforderungen produktbezogener Servicepacks und der verfügbaren Hotfixes.

Schulungserfahrung zur Unterstützung von Prozessen und Verfahren der Kundenbewertung.

Zertifizierung als CISSP.

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Projektbeiträge Kundenbesuchsberichte

Bericht zur Diskrepanzanalyse

Lösungstestplan

Lösungserstellungsplan

Plan für die betriebliche Migration

Sicherheitsanalyseleiter

Der Sicherheitsanalyseleiter ist an der Erstellung der Sicherheitslösung für das Unternehmen beteiligt. Er arbeitet, um eine vollständig integrierte Lösung zu gewährleisten, in Vollzeit mit Entwicklern und Technikern aus folgenden Bereichen zusammen:

Betriebssystem

Netzwerk

Sicherheit

Datenverwaltung

Der Sicherheitsanalyseleiter muss während der Entwicklung aktiv mit dem Geschäftskunden zusammenarbeiten und sicherstellen, dass das Unternehmen in wichtige Entscheidungen und Kompromisse zur technischen Implementierung einbezogen wird. Darüber hinaus prüft er die Sicherungsmaßnahmen und stellt so sicher, dass diese der Funktionsspezifikation und den Erwartungen der Unternehmensverantwortlichen entsprechen.

Verantwortungsbereiche Unterstützen bei der Entwicklung und Bereitstellung des Sicherheitslösungsprojekts.

Unterstützen der sicherheitsbezogenen Architekturkomponentenentwicklung.

Prüfen der Geschäftsaktivitäten für größeren Mehrwert der Lösung.

Anleiten des Projektteams bei der Erstellung von Wertaussagen (Value Statements).

Integrieren der Sicherheitslösung in die bestehende Unternehmensstruktur.

Entwickeln und Umsetzen des Migrationsplans für das Unternehmen.

Verwalten und Bereitstellen der Bewertungsdaten zum Unternehmen.

Sicherstellen, dass der Kundenbewertungsprozess in die Planungsphase überführt werden kann.

Verwalten und Lösen von Integrationsproblemen im Zusammenhang mit anderen Projekten.

Erstellen der Anforderungen der Testumgebung.

Unterstützen von Verfahren zur Prozessverbesserung bei der Datenanalyse.

Unterstützen von Planungsprozessen und -verfahren für Labordienste und Implementierung der Sicherheitslösung beim Kunden.

Erforderliche Fähigkeiten Vielschichtiges Kommunikationsvermögen mit Kunden und Team.

Professionelles schriftliches Ausdrucksvermögen.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Hervorragendes Know-how im Verwaltungsbereich, in der HR-Planung und im Risikomanagement.

Umfassendes Verständnis der von Microsoft unterstützten Infrastrukturarchitekturen.

Umfassende Kenntnis der bewährten Methoden von Microsoft, der funktionalen Einschränkungen des Produkts und der Sicherungsdienste und -systeme.

Gute Kenntnis der Generierung des Microsoft-Produktlebenszyklus, der Anforderungen produktbezogener Servicepacks und der verfügbaren Hotfixes.

Umfassendes Wissen und ausgezeichnete Kenntnis der Anwendungs- und Datenmigration, sowie der zugehörigen Strategien und Methoden.

Schulungserfahrung zur Unterstützung von Prozessen und Verfahren der Kundenbewertung.

Ausgezeichnete Mitarbeiterführung.

Zertifizierung als CISSP.

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Projektbeiträge Kundenbesuchsberichte

Lösungskonzept/Umfang

Diskrepanzanalyse

Vorläufiger Erstentwurf der Lösung

Lösungstestplan

Lösungserstellungsplan

Plan für die betriebliche Migration

Forschungsberater

Der Forschungsberater sammelt in der Phase „Ermitteln übergeordneter Faktoren“ Daten über den Kunden. Er arbeitet eng mit dem Infrastrukturberater zusammen, um einen vollständigen und genauen Bericht für die Diskrepanzanalyse zu ermöglichen. Die Rolle des Forschungsberaters muss ausschließlich während der Phasen „Ermitteln übergeordneter Faktoren“ und „Planen“ in Vollzeit besetzt sein.

Verantwortungsbereiche Verwalten der Prozesse und Verfahren zur Sammlung der Kundendaten.

Sicherstellen, dass genug Daten für die Bewertungsphase erfasst wurden.

Ausfüllen einer Reihe vordefinierter Vorlagen zum Skizzieren der Datensammlungsanforderungen.

Gegebenenfalls Kundenbesuche, um Informationen einzuholen und die Datensammlung zu unterstützen.

Weitergeben von Feedback an den Projekt- und Programmmanager für Prozessverbesserungen und Methodenaktualisierungen.

Erforderliche Fähigkeiten Professionelles Kommunikationsvermögen mit Kunden und Team.

Schriftliches Ausdrucksvermögen zum Dokumentieren der Ergebnisse aus der Prüfungsphase und zum Erstellen von Kundenbesuchsberichten.

Hintergrundwissen zum IT-Betrieb.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Allgemeinwissen zu Anwendungen, Speicher und Netzwerkarchitekturen.

Erfahrung im Verwalten von Kundenbeziehungen und Verträgen.

Schulungserfahrung zur Unterstützung von Prozessen und Verfahren der Kundendatensammlung.

Zertifizierung als ITIL.

Zertifizierung als MCSE.

Projektbeiträge Kundenbesuchsberichte

Implementierungsberater

Der Implementierungsberater ist für die Implementierung der Infrastruktur nach den Vorgaben des Projektteams verantwortlich. Der Implementierungsberater arbeitet zur Bereitstellung der Sicherheitslösung in Vollzeit mit dem Anwendungsberater zusammen.

Verantwortungsbereiche Verwalten von Verfahren zur Prozessverbesserung hinsichtlich Installation, Verwaltung und Einsatz der Sicherheitslösungsinfrastruktur.

Durchführen von Kundenbesuchen, um Geschäftskunden bei der Bereitstellung und Installation zu unterstützen.

Gegebenenfalls Entwickeln von Planungsprozessen und -verfahren für Labordienste.

Vollständiges Implementieren der Sicherheitslösung nach Vorgabe des Erstellungsplans für den Kunden.

Erforderliche Fähigkeiten Umfassende Kenntnis der Implementierungsverfahren von Microsoft-Netzwerkdiensten, einschließlich Microsoft Windows 2000 Windows NT-Domänen, Active Directory, WINS, DNS und DHCP.

Schriftliches Verfassen von Kundenbesuchsberichten und Statusberichten.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Umfassende Kenntnis der bewährten Methoden von Microsoft, der funktionalen Einschränkungen des Produkts und der offenen Systeme.

Gute Kenntnis der Generierung des Microsoft-Produktlebenszyklus, der Anforderungen produktbezogener Servicepacks und der verfügbaren Hotfixes.

Umfassendes Wissen zur Supportfähigkeit und den Methoden, um Technologie und Support zu möglichst niedrigen Gesamtkosten bereitzustellen.

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Zertifizierung als CISSP.

Projektbeiträge Kundenbesuchsberichte

Lösungserstellungsplan

Endentwurf

Plan für die betriebliche Migration

Testleiter

Der Testleiter ist für die Einrichtung einer qualitativ einwandfreien Sicherheitslösung zuständig. Der Testleiter sollte von Projektbeginn an in Vollzeit für das Projekt zur Verfügung stehen und sicherstellen, dass die Testanforderungen richtig verstanden und umgesetzt werden.

Der Testleiter koordiniert bei der Entwicklung und Ausführung von Testplänen die Anwendungs- und Infrastrukturteams und stellt so sicher, dass die speziellen Anforderungen des Sicherheitslösungsprojekts erfüllt werden. Er koordiniert zudem die Entwicklung individueller Testpläne zu den Ergebnissen der einzelnen Teams und fasst diese in einem umfassenden Testmasterplan zusammen, der die Integrität der Gesamtlösung garantiert.

Anmerkung: Da in den meisten Unternehmen bereits ein Test- und Freigabeprozess für Technologieprodukte eingerichtet ist, wird der Kunde vom Testteam häufig in das Sicherheitslösungsprojekt einbezogen.

Verantwortungsbereiche Erstellen der Anforderungen der Testumgebung für die Sicherheitslösung.

Informieren des Teams und der Projektsponsoren über Teststrategie, -pläne und -details.

Erarbeiten und Zuordnen der Testlogistik, einschließlich Ausstattung, Netzwerkverwaltung sowie unternehmensinterne und externe Netzwerkverbindungen.

Installieren der Hardware und Software.

Anpassen der Testverfahren und Testfolgen zur Validierung des Sicherheitslösungsentwurfs.

Erstellen von Kundentestplänen, Fallstudien und Testszenarien.

Ausführen von Tests zu Gegenmaßnahmen und Ressourcenfunktionen.

Durchführen von Überwachungs-, Prüf- und Reaktionstests.

Ausführen des Lösungstestplans.

Protokollieren der beim Testen ermittelten Fehler.

Informieren des Teams über die Ergebnisse der Testphase.

Überprüfen der Hardwarespezifikation für die Produktionslösung auf Vollständigkeit, Genauigkeit, Konsistenz und Gültigkeit.

Dokumentieren der Testergebnisse.

Aussprechen von Freigabeempfehlungen gegenüber dem Management.

Erforderliche Fähigkeiten Gute Kenntnis der Sicherheitslösung.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Gute Kenntnis aller Testprozesse und Testskripts für die Sicherheitslösung.

Genaues Überprüfen der komplexen Integration von Kundenanwendungen im Rahmen der Richtlinien zum Sicherheitslösungsentwurf.

Umfassende Kenntnis in den Bereichen Qualitätssicherung, Risikobewertung und Testverwaltung.

Anwendungsspezifische Zertifizierung (sofern vom Kunden gefordert).

Zertifizierung als MCSE.

Zertifizierung als ITIL.

Projektbeiträge Lösungstestplan

Lösungsfallstudien

Testergebnisse

Testprogramme

Logistikberater

Der Logistikberater arbeitet in Vollzeit an der Definition der Bereitstellungs- und Migrationspläne für die Lösung und ermöglicht damit die reibungslose Verlagerung der Sicherheitslösung in den Produktionsbetrieb. Er koordiniert zudem die Aktualisierung der funktionsbezogenen Patchverwaltung und die Sicherheitskonfiguration.

Der logistische Aspekt ist bei der Bereitstellung einer Sicherheitslösung relativ kompliziert, da in den meisten Fällen auch eine Migration der Netzwerkkomponenten und Anwendungen erforderlich ist. Der Kunde ist in diesen Prozess häufig involviert. Neben dem Testteam sollte auch das Bereitstellungs- und Betriebsteam mit der bestehenden Infrastruktur vertraut sein. Darüber hinaus könnte diese Rolle auch dazu beitragen, die Umgebung zu modernisieren. Es wird also empfohlen, dass der Kunde die Implementierungsleitung übernimmt.

Verantwortungsbereiche Koordinieren der Hardware- und Softwareanbieter bei den Integrationstests von Komponenten und Lösung, den Pilottests und der Implementierung in der Produktionsumgebung.

Anschaffen der erforderlichen Hard- und Software nach Projektplanvorgabe.

Ermöglichen des Zugriffs auf Rechenzentrum und zugehörige Systeme.

Beziehen erforderlicher Netzwerkdienste von externen Gruppen nach Projektplanvorgabe.

Ermöglichen des physischen Zugriffs auf Rechenzentrum oder Serversperrbereiche.

Beziehen von Netzwerkdiensten und ggf. Einrichten des Zugriffs für das Projektteam.

Erforderliche Fähigkeiten Gute Kenntnis der Sicherheitslösungsmethode.

Gute Kenntnis der Sicherheitslösung.

Kenntnisse im Projektmanagement, um wichtige Meilensteine zu erreichen.

Ausgezeichnetes Kommunikationsvermögen.

Hervorragendes Know-how im Verwaltungsbereich.

Erfahrung mit Vertrags- und Akquiseprozessen, Ressourcenkoordination, Risikomanagement und Kostenverwaltung.

Zertifizierung als PMP.

Berater für Benutzerschulungen

Der Berater für Benutzerschulungen stellt sicher, dass IT-Mitarbeiter, Geschäftskunde und Endbenutzer ausreichend für den Einsatz und die Umsetzung der mit der Sicherheitslösung bereitgestellten Anwendungen und Systeminfrastruktur geschult sind. Er sollte während der gesamten Dauer in Vollzeit am Projekt mitarbeiten und sicherstellen, dass die Schulungsanforderungen von Beginn an richtig eingeschätzt und umgesetzt werden. Dieser Berater arbeitet eng mit dem Logistikteam zusammen, um an den Projektimplementierungsplänen orientierte Schulungsmodule und -pläne zu entwickeln.

Verantwortungsbereiche Bewerten der Schulungsanforderungen der IT-Mitarbeiter für die Sicherheitslösung.

Bewerten der Schulungsanforderungen der Endbenutzer für die Sicherheitslösung.

Erstellen des IT-Schulungsplans.

Erstellen des Schulungsplans für Endbenutzer.

Überwachen der Erstellung und Aktualisierung der gesamten Dokumentation zu Entwurf, Installation und Betrieb der Lösung.

Aufsicht über die Ausführung der Schulungspläne.

Erforderliche Fähigkeiten Zertifizierung als Microsoft Certified Trainer (MCT).

Zertifizierung als MCSE

Zertifizierung als ITIL

Projektbeiträge Schulungspläne

Supportberater

Der Supportberater leistet sinnvolle Supportdienste zur Unterstützung der Sicherheitslösung im Unternehmen. Er kann eine Vollzeitrolle ausfüllen.

Verantwortungsbereiche Verwalten der Supporterwartungen.

Verantwortung für Kundenbeziehung und Kundenzufriedenheit.

Lösungssupport

Erforderliche Fähigkeiten Durchführen von und Berichterstellung zu Konformitätstests hinsichtlich Diensten und Supportprozessen.

Schriftliches Verfassen eines Reaktionsplans für Zwischenfälle und von Statusberichten, Verwalten der internen Eskalationsdokumentation für den PM.

Vielschichtige Kommunikation mit Kunden sowie dem Support- und Sicherheitslösungs-Projekteam.

Schulungserfahrung zur Unterstützung der Prozesse und Verfahren für die Kundensupportbewertung und zur Bereitstellung des Reaktionsplans für Zwischenfälle.

Hervorragendes Know-how im Verwaltungsbereich und Risikomanagement.

Umfassende Kenntnis der Methode für Sicherheitslösungen.

Ausgezeichnete Kenntnis der Sicherheitslösung.

Ausgezeichnete Mitarbeiterführung.

Zertifizierung als ITIL.

Zertifizierung als MCSE.

Projektbeiträge Reaktionsplan für Zwischenfälle

Experte

Experten werden im Allgemeinen für kurze Zeiträume in das Projekt einbezogen und tragen Spezialwissen aus ihrem jeweiligen Fachgebiet bei. Obwohl sich die Projektanforderungen für Experten deutlich unterscheiden, sind sie häufig in folgenden Bereichen und Diensten involviert:

Netzwerkinfrastruktur

Sicherheitsverwaltung

Sicherheitsrisikoanalyse

Überwachung, Prüfung und Entwicklung von Reaktionen auf Zwischenfälle

Active Directory-Dienst

Internetfähige Clients

Datenbankverwaltung

Verantwortungsbereiche

Vermitteln von detailliertem Fachwissen an das Team.

Anspruchsvolles Fachwissen und Hilfe bei komplexen technischen Fragen.

Erforderliche Fähigkeiten Unterschiedlich, je nach Anforderungen des Sicherheitslösungs-Projektteams.

Zusammenfassung der für die Projektrollen erforderlichen Fähigkeiten und Zertifizierungen

Abbildung 10: Teamrollen mit ihren Fähigkeiten und Zertifizierungen

Definieren von Projektstruktur und bewährten Methoden

Die Projektstruktur regelt die Projektverwaltung und -unterstützung im Team und gibt die Verwaltungsstruktur für die folgenden Projektphasen vor.

Wichtigste Funktion der Projektstruktur ist es, die Teamstandards für das Projekt zu definieren. Dazu gehören u. a. Standards für die Kommunikation und Dokumentation sowie Verfahren zur Änderungskontrolle.

Das Programmmanagement übernimmt bei der Definition der Projektstruktur die Führungsrolle.

Definieren der Projektkommunikation

In der Projektstruktur kann das Programmmanagement Standards für die teaminterne Kommunikation aufstellen. Dazu gehören beispielsweise eine Berichtsstruktur für die Teammitglieder, Eskalationsverfahren für Projektprobleme, regelmäßig angesetzte Statusbesprechungen sowie weitere projektspezifische Kommunikationsstandards, die in der Einführungsphase definiert werden müssen.

Das Dokument kann die E-Mail-Namen, Aliasnamen, Telefonlisten, E-Mail-Adressen, Serverfreigaben, Verzeichnisstrukturen und weitere wichtige Informationen für die Teamorganisation enthalten. Unter Umständen bietet sich auch die Einrichtung einer speziellen Umgebung an, in der die Kommunikation und Fortschrittsüberwachung erfolgt und aktualisiert werden kann.

Kommunikationsplan

Der Kommunikationsplan gibt vor, wie ein Projektteam zwischen internen Rollenclustern und externen Beteiligten kommuniziert. Der Plan legt auch die Kommunikation zwischen den Funktionsrollen des Sicherheitsprogramms und der Belegschaft des Unternehmens fest. Darüber hinaus wird die Kommunikation zwischen den IT-Helpdesks und den Endbenutzern geregelt.

Definieren der Dokumentationsstandards

Die Projektstruktur kann auch Standards zur Erstellung der projektspezifischen Schulungsunterlagen und -dokumentation enthalten, darunter z. B. Standards für Vorlagen und Anwendungen, die bei der Dokumenterstellung zu verwenden sind.

Definieren der Änderungskontrolle

Der Programmmanager muss zudem Standards für die Änderungskontrolle in die Projektstruktur aufnehmen. Dazu kann die Erstellung täglicher Builds und der Einsatz von Software zur Quellcodeverwaltung und Versionskontrolle gehören, so dass Zugriffs- und Lösungskomponenten kontrolliert und Änderungen bei Bedarf rückgängig gemacht werden können.

Der Programmmanager kontrolliert alle Änderungen, die sich auf den Projektumfang auswirken könnten, und stellt den frist- und budgetgerechten Projektabschluss durch das Team sicher. Dies beinhaltet auch, möglichst nicht immer wieder neue Funktionen hinzuzufügen. Der Gesamterfolg des Projekts könnte sonst gefährdet sein.

Mit Hilfe der Änderungskontrolle kann das Team bereits zu einem frühen Zeitpunkt die grundlegende Dokumentation erstellen und diese dann in der Einführungs- und Planungsphase stetig bis zur endgültigen Version aktualisieren. Darüber hinaus ermöglicht die Änderungskontrolle in der Stabilisierungsphase der Lösung das Erfassen von metrischen Werten sowie Fehlern und anderen Problemen, die gegen Projektende auftreten können.

Zwischenmeilenstein: Projektstrukturentwurf

An diesem Meilenstein wurden die Mitglieder des Kernteams organisiert und ihren Projektrollen zugewiesen. Das Entwurfsdokument führt auch spezielle Verantwortungsbereiche auf, die im Dokumentabschnitt zur Projektstruktur erläutert werden.

Das Dokument zur Projektstruktur verdeutlicht zudem die Verantwortungskette gegenüber dem Kunden und legt die Ansprechpartner des Projektteams auf Kundenseite fest. Je nach Umfang des Projektes kann die Anzahl der Ansprechpartner unterschiedlich groß sein.

Definieren der Unternehmensziele

Die richtige Bestimmung der Unternehmensziele ist für den Projekterfolg von entscheidender Bedeutung. Der MSF-Ansatz zur Umsetzung von Unternehmenszielen besteht darin, Probleme, die dem Projekterfolg im Weg stehen, auszuräumen bzw. Chancen zu ergreifen und diese in Wettbewerbsvorteile umzuwandeln. Das Projektteam muss die Probleme und Chancen klar formulieren und sich darüber im Klaren sein, in welche Richtung sich das Unternehmen zum Verwirklichen seiner Geschäftziele entwickeln muss.

Auf der Grundlage der Problem-/Chancenaussagen für das Sicherheitsprojekt erarbeitet das Team anschließend ein gemeinsames Projektkonzept. Zu den Unternehmenszielen könnte beispielsweise gehören, den Verlust, der dem Unternehmen aus der aktuellen Sicherheitsumgebung entstanden ist, zu korrigieren und die Sicherheitsumgebung zu verbessern. Auch verpasste Geschäftschancen sollten hier aufgeführt werden. Probleme und Chancen sollten im Konzept erfasst oder aus dem Umfang ausgeschlossen werden. Beispiel für die Problem- oder Chancenaussage eines Unternehmens: Die aktuelle Windows 2000-Infrastruktur ist nur teilweise gesichert, und die eingerichteten Sicherheitsprozesse und -verfahren werden nicht optimal verwaltet.

Die IT-Abteilung hat in zunehmendem Maße mit Sicherheitsproblemen zu kämpfen. Das potenzielle Risiko für die Unternehmensressourcen wurde bislang nicht bewertet. Die Glaubwürdigkeit des Unternehmens ist gefährdet, sollten die eigenen Ressourcen beschädigt werden.

Unternehmensziele sind langfristiger ausgerichtet als die Übergangsprobleme, die bei der Umsetzung dieser Unternehmensziele überwunden werden müssen. Das Projektteam muss die beste Methode zur Definition der Ziele bestimmen und diese Ziele dann einvernehmlich festlegen.

Der Geschäftsplan des Unternehmens für die nächsten ein, drei oder fünf Jahre kann bei der Definition der Projektziele eine Hilfe sein. Oberstes Ziel ist es, die Projektziele klar zu formulieren und sicherzustellen, dass Ihre Lösung diesen Unternehmensanforderungen gerecht wird. Andernfalls besteht die Gefahr einer unklaren Zielvorgabe und eines schlecht definierten Endprodukts.

Bewerten der aktuellen Situation

Um eine Lösung erstellen zu können, die den vom Projektteam definierten Unternehmenszielen entspricht, müssen Sie die Diskrepanz zwischen der aktuellen und der gewünschten Unternehmenssituation aufdecken. Dies geschieht mit Hilfe einer Diskrepanzanalyse.

Zu den unterschiedlichen Unternehmens- und Technologiefragen, die in diesem Zusammenhang zu bewerten sind, gehört die Evaluierung der derzeitigen Sicherheitsprozesse und -verfahren im Unternehmen. Auf dieser Grundlage können dann Maßnahmen zur Umgebungsoptimierung getroffen werden.

Erstellen des Konzepts und Definieren des Projektumfangs

Die Erarbeitung des Projektkonzepts und die Bestimmung des Projektumfangs sind zwei gesonderte Bereiche. Beide sind für eine erfolgreiche Projektdurchführung unverzichtbar. Das Projektkonzept gibt Aufschluss über die allgemeinen, mit einer Sicherheitslösung verbundenen Zielvorstellungen. Der Projektumfang führt aus, inwieweit dieses Konzept im Rahmen der geltenden Projekteinschränkungen realisiert werden kann.

Erstellen des Projektkonzepts

Die Konzeptaussage basiert auf den Problemaussagen und beschreibt die langfristigen Unternehmensziele. Sie umfasst meist nur einen oder zwei Absätze und ist nicht an die tatsächlich geplante Projekttätigkeit gebunden. Gegensätzliche Interessen sollten jedoch so weit ausgeglichen werden, dass das Konzept von allen Teammitgliedern getragen und als Grundlage für die künftige Entscheidungsfindung herangezogen werden kann.

Für die Konzeptaussage eines Sicherheitslösungsprojekts kann beispielsweise Folgendes berücksichtigt werden:

Eine Bewertung der aktuellen Windows 2000-Umgebung und Sicherheitskonfigurationen.

Die Entwicklung eines Sicherheitsmaßnahmenplans auf der Grundlage dieser Bewertung.

Das Testen der Sicherheitsänderungen in der Umgebung vor der tatsächlichen Bereitstellung.

Das Umsetzen der Änderungen, sowie Bereitstellen der neuen Richtlinien und Verfahren in der Umgebung.

Das Team formuliert dieses Konzept in einer Konzeptaussage, die Bestandteil des Dokuments zu Konzept und Umfang ist. Es folgt ein Beispiel für eine Konzeptaussage in einem Projekt Windows 2000 Server absichern soll:

Die Windows 2000 Server-Umgebung wird im Rahmen der Sicherungsbemühungen des Unternehmens soweit verbessert, dass die Unternehmensressourcen umfassend geschützt sind. Geeignete Prozesse und Verfahren werden implementiert, damit das Unternehmen seine sichere Umgebung proaktiv verwalten kann.

Anmerkung: Für die Erstellung des Dokuments zum Lösungskonzept und -umfang ist eine entsprechende Vorlage verfügbar. Weitere Informationen finden Sie in den Aufgabenhilfen zu diesem Leitfaden.

Definieren des Projektumfangs

Der Projektumfang legt fest, was genau zu einem Projekt gehört und was nicht. Der Projektumfang basiert auf dem in der Konzeptaussage formulierten Gesamtkonzept und wendet darauf die projektspezifischen Ressourcen-, Fristen- und sonstigen Einschränkungsfaktoren an.

Das MSF verwendet zum Definieren des Projektumfangs das so genannte Kompromissdreieck. Diesem Modell zufolge sind die drei Elemente „Projektressourcen“, „Zeitplan“ und „Merkmale“ in jedem Projekt miteinander verbunden. Jede Einschränkung oder Erweiterung eines oder mehrerer dieser Elemente führt automatisch zu einem Kompromiss. Die Qualität ist nicht als eigenständiges Element in diesem Modell definiert. Sie gilt jedoch als Konstante, die in Form eines vorab vom Projektteam vereinbarten Qualitätsstandards ausgedrückt wird.

Abbildung 11: Das MSF-Kompromissdreieck

Möchte ein Unternehmen z. B. neue Funktionsmerkmale in die Lösung integrieren, muss das Team an irgendeiner Stelle im Projekt Abstriche machen. Sei es im Zeitplan, bei den Projektressourcen oder den für das Projekt definierten Merkmalen. Denkbar wäre auch, dass ein Projektteam der schnellen Umsetzung der Lösung den Vorzug gibt, statt weitere Funktionen aufzunehmen. Die Entscheidung muss in diesem Fall mit Blick auf das Unternehmensziel, sich von potenziellen Mitbewerbern abzusetzen und neue Kunden anzuwerben sowie dauerhaft an das Unternehmen zu binden, getroffen werden.

Ein Projektteam muss anschließend die getroffenen Kompromisse überprüfen und ermitteln, welche Funktionen unbedingt in der endgültigen Lösung enthalten sein müssen, um das Gesamtziel, eine schnelle Bereitstellung und zusätzlichen geschäftlichen Wert, umzusetzen.

Definieren der vorrangigen Anforderungen und Benutzerprofile

Um sicherzustellen, dass das Unternehmen von der Projektlösung in vollem Umfang profitiert, muss das Team die Anforderungen aller Projektbeteiligten, Sponsoren und Endbenutzer genau kennen. Diese Informationen stellen eine unverzichtbare Grundlage für die Erstellung des Lösungskonzepts dar, da sie wertvolle Kriterien für das Projektkonzept und den Projektumfang liefern. So können detailliertere Lösungsanforderungen erarbeitet werden, die in der nächsten Phase erläutert werden.

Definieren von Anforderungen

Dieser Prozess beginnt mit der Definition der wichtigsten Funktionsanforderungen und Merkmale, die für das Projekt zu berücksichtigen sind. Die Liste möglicher Anforderungen für die Lösung zum Absichern von Windows 2000 Server kann recht lang sein und u. a. folgende Aspekte enthalten:

Sicherheitsteams müssen Werkzeuge, Techniken und Methoden entwickeln, um die Infrastruktur des Unternehmens abzusichern.

Das Sicherheitsprogramm muss Sicherheitsrichtlinien für alle Computer unter Windows 2000 im Unternehmen erstellen.

Die Sicherheitsrichtlinien müssen einfach zu konfigurieren und einzurichten sein.

Sicherheitsrelevante Prozesse und Verfahren zur Änderungsverwaltung müssen effektiv und nahtlos verwaltet werden können.

Das Sicherheitsprogrammmanagement muss Richtlinienänderungen schnell im gesamten Unternehmen durchsetzen können.

Eingrenzen der Anforderungen

Nach Definition der möglichen Anforderungen begrenzt das Projektteam die Liste auf die wesentlichen Punkte. Dazu können zum Beispiel gehören:

Nur Sicherung der Windows 2000-Domänencontroller.

Nur Sicherung der Windows 2000-Infrastrukturserver.

Nur Sicherung der Windows 2000-Datei- und Druckserver.

Nur Sicherung der Windows 2000-Webserver.

Der Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden empfiehlt für die Definition des Projektumfangs die versionsbasierte Freigabe. Die versionsbasierte Freigabe erlaubt dem Projektteam eine rasche Reaktion auf anfallende Änderungen im Umfang, Zeitplan oder Risiko des Projekts. Kann das Team aus Zeit-, Budget- oder Ressourcengründen nicht das gesamte Projektkonzept bis zum vorgesehenen Datum umsetzen, dann kann es beschließen, das Gesamtkonzept im Rahmen einer späteren Version zu implementieren.

Während die Erstversion die Kernfunktionalität für die Benutzer enthält, können in späteren Versionen zusätzliche, auf die Kundenanforderungen abgestimmte Funktionen bereitgestellt werden. Die versionsbasierte Freigabe bietet auch die Möglichkeit, Änderungen auf der Grundlage des Feedbacks zu früheren Versionen vorzunehmen. Versionen sind besonders dann von Bedeutung, wenn der Zeitpunkt der Markteinführung sehr wichtig ist. In diesem Fall entscheidet das Team, welche Funktionen und Merkmale zwar wünschenswert sind, jedoch nicht unbedingt bereits in der Erstversion enthalten sein müssen.

Benutzerprofile

Zweck von Benutzerprofilen ist es, den Umgang der Benutzer mit der Lösung abzubilden. Das Mitglied, welches die Benutzererfahrungsrolle für die Sicherheitslösung übernimmt, vertritt die Perspektive der Endbenutzer. Die Benutzererfahrungs- und Produktmanagementrolle müssen zusammenarbeiten, um das Benutzerverhalten vorauszusagen. Dazu werden in erster Linie die verschiedenen Erfordernisse und Anforderungen der Benutzer identifiziert. Im Rahmen des MSF-Ansatzes beinhaltet dies die Profilerstellung für unterschiedliche Endbenutzerkategorien.

Zur Erfassung der Benutzeranforderungen ist es empfehlenswert Profile der voraussichtlichen Endbenutzer zu erstellen. Der Projekterfolg hängt entscheidend davon ab, dass jedes Teammitglied über ein genaues Verständnis der Endbenutzer und deren Anforderungen verfügt. Benutzerprofile kategorisieren die Endbenutzer, so dass das Team auf dieser Grundlage die Erwartungen, Projektrisiken, -ziele und -einschränkungen bewerten kann.

Erstellen von Benutzerprofilen

Die richtige Lösung kann nur dann erfolgreich entwickelt und verwaltet werden, wenn die Benutzerprofile verstanden werden und die Erwartungen der Benutzer genauesten bekannt sind. Dies sichert dem Unternehmen letztendlich zusätzlichen geschäftlichen Nutzen. Es gibt eine Reihe von Beispielprofilen, die bei der Sicherung von Windows 2000 Servern angewendet werden können.

Alle Benutzer, die auf Ressourcen auf Windows 2000 Servern des Unternehmens zugreifen, sollten bei der Sicherheitslösung berücksichtigt werden. Benutzer können unter Verwendung der folgenden Betriebssysteme eine Verbindung zum Unternehmensnetzwerk herstellen: Microsoft® Windows® 98 SR2, Windows NT Workstation, Version 4.0, Windows 2000 und Microsoft® Windows® XP.

Entwickeln des Lösungskonzepts

Das Lösungskonzept formuliert den Teamansatz zur Umsetzung der Projektziele und dient als Grundlage für den Übergang zur Planungsphase. Nachdem das Team das geschäftliche Problem identifiziert und das Projektkonzept, sowie den Projektumfang definiert hat, erstellt es daraus das Lösungskonzept mit der allgemeinen Vorgehensweise. Diese sollt die Erfüllung der Projektanforderungen sicherstellen.

Das Team muss bei jedem Projekt nach der jeweils am besten geeignete Methode suchen. Dabei kann es die Optionen im Lösungskonzept auf einige wenige Alternativen begrenzen. Dies könnte zum Beispiel eine gebrauchsfertige Lösung sein, oder eine auf unterschiedlichen Ebenen angepasste Lösung, die den einzelnen Geschäftsanforderungen umfassender gerecht wird. Nach eingehender Bewertung entscheidet sich das Team dann für das optimale Lösungskonzept.

Bei der Entwicklung des Lösungskonzepts sind folgende Kernfaktoren zu berücksichtigen:

Der Schwerpunkt liegt weniger auf speziellen Einzeltechnologien, als auf dem mit der Technologie zu erzielenden Geschäftswert.

Die Rolle des Konzepts bei der Vermittlung des Gesamtentwurfsansatzes an den Kunden und damit auch seine Rolle als Ausgangspunkt für die Entwurfsbesprechungen in der nächsten Planungsphase.

Zu den wichtigen Kriterien bei der Abstimmung von Lösungskonzept und Teamerfordernissen gehören:

Faktoren für den Projekterfolg

Betriebskonzept

Annahmekriterien

Zwischenmeilenstein: Dokumententwurf zu Konzept/Umfang

An diesem Zwischenmeilenstein wurde der Erstentwurf des Dokuments zu Konzept/Umfang abgeschlossen und dem Team, dem Kunden und den weiteren Projektbeteiligten zur Überprüfung vorgelegt. Während dieser Überprüfungs- und Überarbeitungsphase wird das Dokument mehrfach diskutiert und entsprechend geändert. In diesem Dokument sind die meisten Informationen und Entscheidungen zusammengefasst, die das Projektteam bis zu diesem Zeitpunkt getroffen hat: u. a. eine Aussage zur Geschäftschance, eine Beschreibung des Lösungskonzepts und eine Aussage zu den Entwurfsstrategien für die Lösung.

Bewerten des Risikos

Der Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden betont die große Bedeutung einer kontinuierlichen Risikobewertung während des gesamten Projekts. Risiken, definiert als mögliche Verluste, sind ein fester Bestandteil jedes Projekts. Zum Risikomanagement gehört das Voraussehen, Analysieren, Mindern und Vermeiden von Risiken.

Der im Entwurfs- und Umsetzungsleitfaden Absichern von Windows 2000 Server vorgestellte Ansatz für das Sicherheitsrisikomanagement ist proaktiv ausgerichtet und soll Ungewissheiten minimieren und gleichzeitig die Erfolgschancen vergrößern. Das Team bewertet fortlaufend, welche Probleme auftreten könnten, und bemüht sich dann, potenzielle Verluste zu vermeiden oder möglichst gering zu halten. Damit soll vermieden werden, dass das Team reaktiv arbeitet und erst auf Probleme reagiert, wenn diese tatsächlich auftreten. Alle Teammitglieder sind für die kontinuierliche Risikobewertung im Projekt verantwortlich. Das MSF empfiehlt, Risiken mit Hilfe eines formalen Risikomanagementtools zu verfolgen und zu kategorisieren, um so schwer wiegende Einzelrisiken bereits zu einem frühen

Zeitpunkt angehen zu können. Im folgenden Abschnitt wird die Quantifizierung der Hauptrisiken in einem Projekt erläutert.

Erstellen der vorläufigen Risikobewertung

Während der Einführungsphase erstellt das Team im Rahmen des Risikomanagements ein Dokument zur Risikobewertung, in dem alle bekannten Risiken zusammengefasst sind. Anschließend wird die Wahrscheinlichkeit (die Gefahr, dass das Risiko tatsächlich relevant wird) und die Auswirkung (die Höhe des aus dem Risiko resultierenden Verlusts) aller Risiken bewertet. Der Programmmanager übernimmt bei der Erarbeitung des Dokuments zur Risikobewertung die Führungsrolle.

Das Team kann bei der Wahl des geeigneten Lösungskonzepts die Risiken einzelner Konzeptvarianten vergleichen. Bei der Erstellung der ursprünglichen Risikobewertung werden numerische Skalen verwendet, um die Wahrscheinlichkeit und Auswirkung jedes Risikos zu bewerten. Anschließend wird der jeweilige Risikofaktor berechnet. Dazu wird folgende Formel angewendet:Wahrscheinlichkeit * Auswirkung = RisikofaktorAuf diese Art können Risiken miteinander verglichen und ihr jeweiliger Schweregrad bzw. ihre Priorität bestimmt werden. Diese Schlussfolgerungen sind nicht immer einfach – beispielsweise, wenn ein Risiko eine hohe Wahrscheinlichkeit, aber eine geringe Auswirkung aufweist, ein anderes Risiko dagegen entgegengesetzte Werte hat. Indem das Team die Risiken ihrer Priorität nach anordnet, können die größten Risiken zuerst bearbeit werden.

Nachdem das Team das Dokument zur Risikobewertung erstellt und die einzelnen Risikofaktoren ermittelt hat, kann es sich den Risiken mit der höchsten Priorität zuwenden. Diese Liste der oft „Top 10“ genannten Risiken muss nicht notwendigerweise genau zehn Risiken enthalten. Je nach Anzahl der insgesamt ermittelten Risiken, der jeweiligen Risikoart und dem Gesamtprojekt können hier mehr oder weniger Risiken aufgeführt werden. Der Programmmanager sollte diese Liste regelmäßig überprüfen und die Risiken ihrer aktuellen Bedeutung nach ergänzen bzw. neu ordnen.

Die Risiken in einem Sicherungsprojekt zu Windows 2000 Server sind stets lösungsspezifisch und können das Team vor neue, unbekannte Herausforderungen stellen. Mögliche Risiken sind zum Beispiel:

Fehlende Fähigkeiten, um das Projekt umzusetzen.

Mögliche Haftungsansprüche, z. B. aufgrund nachteiliger Beeinflussung des Unternehmensimages bzw. der Marke des Unternehmens. Zum Beispiel wenn die Website nicht ordnungsgemäß arbeitet oder häufig nicht verfügbar ist.

Sicherheitsrisiken, z. B. Angriffe auf das System durch Hacker oder Diebstahl vertraulicher Kundendaten wie Kreditkartennummern.

Risiko- und Einsatzbereitschaftsmodelle für Sicherheitslösungen

Risikomanagement

Der MSF-Ansatz für das Risikomanagement empfiehlt ein proaktives Risikomanagement, die ständige Risikobewertung und die Einbindung in den Entscheidungsfindungsprozess während der gesamten Dauer des Projekts bzw. des betrieblichen Lebenszyklus. Alle Risiken werden kontinuierlich bewertet, überwacht und bis zu ihrer Beseitigung verwaltet. Der MSF-Prozess für das Risikomanagement definiert sechs logische Schritte, mit denen das Projektteam aktuelle Risiken verwaltet, Strategien für das Risikomanagement plant und durchsetzt sowie wertvolles Wissen für das Unternehmen erfasst.

Abbildung 12: Das Modell zur Risikoanalyse

Risikobestimmung

Ziel der Risikobestimmung ist es, das Team für die potenziellen Probleme zu sensibilisieren. Als wichtiger Bestandteil des Risikomanagementprozesses sollte die Risikobestimmung so früh wie möglich vorgenommen und während des gesamten Projekts regelmäßig wiederholt werden.

Risikoanalyse

Im Rahmen der Risikoanalyse werden die Schätzungen oder projektspezifischen Risikodaten aus der Risikobestimmung so umformuliert, dass das Team eine Gewichtung der Risiken vornehmen kann. Auf die Weise können dann Teamressourcen für die Verwaltung der wichtigsten Risiken abgestellt werden.

Risikoplanung

Die Risikoplanung basiert auf der Risikoanalyse, um Strategien, Pläne und Maßnahmen zu formulieren. Diese Pläne werden genehmigt und dann in den täglichen Projektmanagementprozess und die Infrastruktur eingebunden, so dass das Risikomanagement als integrierter Bestandteil der geplanten Teamaktivitäten erfolgen kann. So wird die Risikoplanung mit der Projektplanung verbunden.

Risikoverfolgung

Bei der Risikoverfolgung wird der Status bestimmter Risiken und der Fortschritt der entsprechenden Maßnahmenpläne überwacht. Darüber hinaus werden Wahrscheinlichkeit, Auswirkung, Risikofaktor und weitere Messwerte für Änderungen überwacht, die sich auf Gewichtung, Risikopläne, Projektmerkmale, Projektbeteiligte oder Projektplan auswirken könnten. Anders als beim herkömmlichen Projektmanagement, das lediglich abgeschlossene Aufgaben erfasst, setzt die Risikoverfolgung den Risikomanagementprozess in den Projektmittelpunkt. Risikoberichte stellen sicher, dass das Team, der Sponsor und alle weiteren Beteiligten jederzeit über den aktuellen Status der Projektrisiken und die entsprechenden Pläne informiert sind.

Risikokontrolle

Dieser Prozess umfasst die Umsetzung der Risikomaßnahmenpläne und die zugehörigen Statusberichte. In den Bereich der Risikokontrolle gehören auch projektbezogene Änderungskontrollanfragen. Sie werden notwendig, wenn sich Änderungen am Risikostatus oder in

den Risikoplänen auf die Projektmerkmale, die Projektressourcen oder den Projektplan auswirken könnten.

Risikoerkennung

Hier werden die gewonnenen Erkenntnisse und die relevanten Projektbereiche und Tools aufbereitet. Darüber hinaus wird wieder verwertbares Wissen aus dem Team und dem Unternehmen gesammelt.

Readiness Management

Der MSF-Readiness Management-Ansatz zur Verwaltung der Einsatzbereitschaft umfasst einen Prozess zur Erfassung des Wissens, der Kenntnisse und Fähigkeiten, die zur Erstellung und Verwaltung von Projekten und Lösungen erforderlich sind. Der Readiness Management-Prozess besteht aus vier Schritten: Definieren, Bewerten, Ändern und Auswerten. Jeder dieser Schritte beinhaltet eine Reihe von Aufgaben, die der Umsetzung des nächsten Meilensteins dienen.

Abbildung 13: Der Prozess zur Wissenserfassung

Definieren

In dieser Phase werden die Szenarien, Kompetenzen und nötigen Erfahrungsniveaus ermittelt und beschrieben, die zur erfolgreichen Planung, Erstellung und Verwaltung der Lösung erforderlich sind. Zu diesem Zeitpunkt wird auch festgelegt, welche Rollen bestimmte definierte Kompetenzen benötigen. Je nach Rolle muss das betreffende Teammitglied über Erfahrungen in mindestens einer der definierten Kompetenzen verfügen.

Szenarien beschreiben die verschiedenen Projekttypen in einem typischen Unternehmen. Im Allgemeinen fallen Szenarien in eine der folgenden vier Kategorien: großes Potenzial, Strategie, Schlüsselbereich des Betriebs oder Support. Diese Kategorien entsprechen den einzelnen Phasen, Schwerpunktbereichen und spezifischen Herausforderungen, die ein Unternehmen bei der Entwicklung und Verwaltung von Technologien und Produkten üblicherweise durchläuft. Mit Hilfe der Kategorisierung von IT-Projekten kann die Planung der Einsatzbereitschaft vollständig auf das spezifische Projekt ausgerichtet werden. Unterschiedliche Szenarien erfordern unterschiedliche Ansätze, um die für den jeweiligen Projekttyp geeigneten Ressourcen und Fähigkeiten bereitzustellen. Nachdem das Szenario definiert wurde, können die entsprechenden Kompetenzen und Erfahrungen zugeordnet werden.

Kompetenzen beschreiben messbare Ziele oder Aufgaben, die von den jeweiligen Projektmitgliedern in einem bestimmten Szenario professionell umzusetzen sind. Über Kompetenzen wird ein Großteil der Tätigkeit jedes Teammitglieds bzw. seiner leistungsbezogenen

Verantwortungsbereiche definiert. Sie können sich eine Kompetenz als eine „Schöpfquelle“ vorstellen, das Fähigkeiten, Kenntnisse und Leistungsanforderungen enthält.

Der Erfahrungsgrad bezeichnet, wie gut Aufgaben in einem bestimmten Szenario ausgeführt bzw. Kompetenzen eingebracht werden können. Dabei geht es um Aufgaben, die Personen mit einem bestimmten Kenntnisstand ausführen können müssen. Der Erfahrungsgrad dient als eine Art Benchmark oder Ausgangspunkt dafür, die Diskrepanz zwischen den aktuellen Fähigkeiten der jeweiligen Person und den für den erfolgreichen Abschluss der Aufgaben erforderlichen Fähigkeiten zu analysieren.

In der Definitionsphase des MSF-Readiness Management-Prozesses werden die Ebenen festgelegt, auf denen die einzelnen Mitglieder ihre Rolle in dem betreffenden Szenario auszuführen haben. Anschließend wird der Erfahrungsgrad mit Kompetenzen verknüpft, so dass die Bewertungsergebnisse gemessen und auf eventuelle Lücken und Diskrepanzen hin analysiert werden können.

Bewerten

In dieser Phase werden die aktuell vorhandenen Kompetenzen der Mitglieder eingeschätzt. Gleichzeitig beginnt auch die Analyse der Kompetenzen für die einzelnen Rollen, um die Fähigkeiten der entsprechenden Teammitglieder zu bewerten. Anschließend werden die gewünschten Kompetenzen mit den bereits vorhandenen Kompetenzen abgeglichen. Basierend auf diesen Ergebnissen wird ein Lernplan erstellt, um die verbleibenden Kenntnislücken zu schließen. In der Bewertungsphase werden folgende Aufgaben ausgeführt:

Erfassen des vorhandenen Wissens bzw. der vorhandenen Kenntnisse und Fähigkeiten mittels Eigenbewertung oder Bewertungstests.

Analysieren der Erfahrungsdiskrepanzen auf der Grundlage dieser Daten. Eine solche Diskrepanz tritt auf, wenn ein Teammitglied auf einer niedrigeren Erfahrungsebene arbeitet als der für die Rolle eigentlich erforderlichen Ebene. Durch den Vergleich des aktuellen und des gewünschten Status werden Diskrepanzen ermittelt, welche die betreffenden Mitglieder dann anhand von Lernplänen überbrücken können.

Erstellen von Lernplänen mit geeigneten Ressourcen und Methoden (Schulungsmaterial, Kursunterlagen, Whitepaper, computergeschützte Schulungen, Einzelschulung oder Schulungen vor Ort bzw. zum Selbststudium), um die Wissenslücken zu schließen. Lernpläne sollten sowohl formale als auch informelle Lernaktivitäten beinhalten und die Mitarbeiter zum Erwerb eines höheren Erfahrungsgrades führen.

Ändern

In der Änderungsphase wird mit dem Erlernen neuer Fähigkeiten begonnen, um die Diskrepanz zwischen den aktuellen und den gewünschten Fähigkeiten zu überbrücken. Diese Phase umfasst folgende Aufgaben:

Schulung Praxisorientiertes Lernen und Anleiten nach Vorgabe des Lernplans.

Fortschrittsverfolgung Hierzu gehört die Überwachung von Mitarbeitern und die Dokumentation ihrer vorhandenen Fähigkeiten und geforderten Tätigkeitsbeschreibungen. Einzelfortschritte werden im Team, Projekt und im Unternehmen verfolgt, bis die Wissenslücken geschlossen sind. Mit Hilfe der Fortschrittsverfolgung kann die Einsatzbereitschaft von einzelnen Personen oder des Gesamtteams jederzeit überprüft werden. So können dann entsprechende Anpassungen vorgenommen werden.

Auswerten

In dieser Phase wird der Erfolg der Lernpläne ermittelt. Es wird überprüft, ob die gewonnenen Erkenntnisse in der täglichen Arbeit erfolgreich umgesetzt werden. Dabei stehen folgende Aufgaben an:

Überprüfen der Ergebnisse, um den Bedarf an weiteren Schulungen zu ermitteln bzw. um zu prüfen, ob das Gelernte in der täglichen Arbeit umgesetzt wird.

Verwalten des Wissens, damit Mitarbeiter im gesamten Lösungsteam und Unternehmen von diesem profitieren können. Dieser Wissensaustausch fördert die kollektive Teamarbeit und trägt zu einem dynamischen Lernumfeld bei. Darüber hinaus stellt ein formales System für das Wissensmanagement eine Möglichkeit dar, gemeinsame und wiederholt einsetzbare bewährte Methoden zu nutzen, um gleichzeitig die Kosten und Risiken für andere Projektteams zu reduzieren.

Der MSF-Readiness Management-Prozess verfolgt einen fortlaufenden, iterativen Ansatz und ist somit sowohl für Groß- als auch für Kleinprojekte geeignet. Im Rahmen der einzelnen Prozessschritte können verschiedene Aufgaben verwaltet werden, um die Kenntnisse und Fähigkeiten von einzelnen Personen, des Projektteams bzw. des Unternehmens aufeinander auszurichten. Die Readiness Management-Methode soll einen proaktiveren Ansatz von Einzelpersonen und Gruppen gewährleisten. Basierend auf dem Readiness Management werden Schritte zur proaktiven Verwaltung von Problemen errichtet, die vor allem bei der Einführung neuer Technologien oder der Verwaltung des Lösungsbetriebs auftreten können. Indem das Projektteam die erfolgskritischen Kompetenzen und Fähigkeiten vorab ermittelt, kann es Schulungsanforderungen für eine gelungene Lösungsimplementierung entsprechend planen und budgetieren.

Mit der genauen Kenntnis darüber, welche Tätigkeitsbeschreibungen und Kompetenzen zu welchen Projektrollen gehören, können Projektteams besser zuordnen, über welche Fähigkeiten die Mitglieder in den einzelnen Rollen verfügen müssen. Auf diese Weise können Stärken und Schwächen proaktiv analysiert und geeignete Schulungspläne konzipiert werden. Der MSF-Prozess verbessert damit die Erfolgsaussichten für die einzelnen Mitarbeiter, das Projektteam und die strategische Planung.

Projektrisikoaussage und -werkzeuge

In die gesamte Risikobewertung eines Projekts fließen sämtliche Risikodaten der einzelnen Projektebenen ein. Dieses dynamische Dokument bildet die Grundlage für das fortlaufende Risikomanagement und muss daher während des gesamten Zyklus aus Risikoanalyse, Planung und Überwachung auf dem aktuellen Stand gehalten werden. Weitere Informationen dazu entnehmen Sie bitte den Aufgabenhilfen zu diesem Leitfaden.

Weitere Projektergebnisse

Ein optionales Projektergebnis in der Phase „Ermitteln übergeordneter Faktoren“ ist die Bewertung des Unternehmens. Dabei wird anhand eines Arbeitsblattes ermittelt, ob das Unternehmen für die Implementierung einer Sicherheitslösung in Frage kommt. Weitere Informationen finden Sie in den Aufgabenhilfen zu diesem Leitfaden.

Ziele

Ziel in der Phase „Ermitteln übergeordneter Faktoren“ ist es, eine Erstbewertung zu Eignung und Potenzial einer Sicherheitslösung vorzunehmen. Dazu werden folgende Aufgaben ausgeführt:

Überprüfen der Finanzlage des Unternehmens.

Bewerten des Projektmfangs und des verfügbaren Budgets.

Ermitteln relevanter Probleme in Bezug auf die bestehende Infrastruktur und die vorhandenen Anwendungen.

Erfassen der technischen und geschäftlichen Anforderungen.

Abschließen der Phase „Ermitteln übergeordneter Faktoren“

Zum Abschluss der Einführungsphase gehört ein vollständiger Prozess zur Meilensteinüberprüfung. Das Team muss die Ergebnisse der einzelnen, in dieser Phase durchgeführten Aufgaben dokumentieren und dem Projektmanagement zur Genehmigung vorlegen.

Die wichtigsten Aufgaben und Ergebnisse der Phase „Ermitteln übergeordneter Faktoren“

Das Team erstellt die Projektergebnisse zu allen Aufgaben der Einführungsphase. Diese Ergebnisse dienen dem Team dann als Hintergrundinformation und Richtung für die weitere Projektarbeit und vermitteln dem Kunden darüber hinaus das Konzept und den Umfang des Projekts.

Zu den während der Phase „Ermitteln übergeordneter Faktoren“ erstellten Teamergebnissen gehören:

Konzept-/Umfangsaussage

Problemaussagen

Unternehmensziele

Konzeptaussage und Umfangsdefinition

Das Lösungskonzept mit dem Teamansatz für die weitere Projektplanung

Strategien zum Lösungsentwurf

Projektstruktur

Beschreibung und Zuordnung aller MSF-Teamrollen

Projektstruktur und Prozessstandards für das Projektteam

Risikobewertung

Liste der wichtigsten Risiken

Bericht zur Meilensteinüberprüfung

Bericht über den Projektfortschritt der einzelnen Teammitglieder

Bericht über den Projektfortschritt der einzelnen Teamleiter

Tabelle 3: Die wichtigsten Aufgaben in der Phase „Ermitteln übergeordneter Faktoren“

Kernaufgaben Verantwortlicher

Zusammenstellen des Teams Produktmanagement, Programmmanagement

Definieren der Unternehmensziele Produktmanagement

Bewerten der aktuellen Situation Programmmanagement

Erstellen des Konzepts und Definieren des Projektumfangs

Produktmanagement, Programmmanagement, Lösungsarchitekt und SMEs

Erstellen von Profilen zu Produktmanagement, Benutzerschulung

Benutzeranforderungen

Erarbeiten des Lösungskonzepts Programmmanagement

Bewerten des Risikos Programmmanagement

Definieren der Projektstruktur Programmmanagement

Abschließen der Phase „Ermitteln übergeordneter Faktoren“

Projektteam

Wichtiger Meilenstein: Konzept/Umfang genehmigt

Die Phase „Ermitteln übergeordneter Faktoren“ endet mit der Genehmigung des Meilensteins für Konzept und Umfang. Zu diesem Zeitpunkt haben sich das Projektteam und der Kunde über die Gesamtrichtung des Projekts geeinigt, einschließlich der Lösungsfunktionen und einen allgemeinen Umsetzungszeitrahmen.

Übergang zur nächsten Phase

Nach der vollständigen Erledigung aller Aufgaben der Einführungsphase muss das Team formal beschließen, dass das Projekt den genehmigten Meilenstein zu Konzept und Umfang erreicht hat. Durch ihre Genehmigung drücken die Teammitglieder ihre Zufriedenheit mit der durchgeführten Arbeit in ihrem Verantwortungsbereich aus.

Projektteams bestätigen einen Meilenstein in der Regel durch formale Abzeichnung. Die wichtigsten Projektbeteiligten, meist ein Vertreter jeder Teamrolle und alle wichtigen Kundenvertreter, die nicht selbst Mitglieder des Projektteams sind, signalisieren ihre Zustimmung durch Abzeichnung eines Dokuments, das besagt, dass der Meilenstein vollständig erreicht und umgesetzt wurde. Dieses Dokument gilt ebenfalls als Projektergebnis und wird zur späteren Referenz archiviert.

Planen

In der Planungsphase definiert das Team die Lösung: Was soll wie und von wem entwickelt werden? In dieser Phase erarbeitet das Team die Funktionsspezifikation, durchläuft den Entwurfsprozess und erstellt Arbeitspläne, Kostenschätzungen und Pläne für die einzelnen Projektergebnisse.

Bereits zu einem frühen Zeitpunkt in der Planungsphase analysiert und dokumentiert das Team die Lösungsanforderungen. Diese Anforderungen unterteilen sich in die vier Hauptkategorien: geschäftliche und betriebliche Anforderungen sowie Benutzer- und Systemanforderungen. Für den anschließenden tatsächlichen Lösungsentwurf und die Erstellung der Funktionsspezifikation ist entscheidend, die Zuordnungsfähigkeit der einzelnen Anforderungen und Lösungsfunktionen zu gewährleisten. Diese Zuordnung muss nicht 1:1 erfolgen. Tatsächlich kann es sogar so sein, dass einige Funktionen mehreren Anforderungen gerecht werden oder mehrere Funktionen für eine einzige Anforderung benötigt werden. Jede Anforderung muss jedoch ihrer entsprechenden Lösungskomponente zuzuordnen sein. So kann gewährleistet werden, dass die Entwurfsgenauigkeit stimmt und der Entwurf den Zielen und Anforderungen der Lösung gerecht wird.

Im Rahmen des Entwurfsprozesses werden abstrakte Konzepte systematisch in spezifische technische Detailangaben umgewandelt. Den ersten Schritt bildet in diesem Zusammenhang die systematische Analyse der Benutzerprofile (auch als „Rollen“ bezeichnet), welche die einzelnen Benutzertypen und ihre Tätigkeit beschreiben. Viele dieser Benutzerprofile werden oft schon in der Einführungsphase des Projekts erstellt. Die Benutzerprofile werden in eine Reihe von Verwendungsszenarien aufgeschlüsselt, bei denen jeweils ein bestimmter Benutzertyp einen bestimmten Tätigkeitstyp ausführt. Letztendlich ist jedes Verwendungsszenario in eine bestimmte Aufgabenfolge unterteilt, die der Benutzer zur vollständigen Ausführung der entsprechenden Tätigkeit durchläuft. Dieser Gesamtprozess wird als Storyboarding bezeichnet.

Der Entwurfsprozess erfolgt auf drei Stufen: dem konzeptuellen, logischen und physischen Entwurf. Jede dieser Stufen wird gestaffelt durchgeführt. Die Ergebnisse des Entwurfsprozesses werden in einer oder mehreren Funktionsspezifikationen dokumentiert. Die Funktionsspezifikationen beschreiben ausführlich die Merkmale und Verhaltensweise der einzelnen Funktionen sowie die Gesamtarchitektur aller Funktionen im Projekt.

Die Planungsphase endet mit dem Meilenstein „Projektplan genehmigt“. Dieser Meilenstein besagt, dass sich Projektteam, Kunde und die wichtigsten Projektbeteiligten über die Plandetails einig sind. Das Ziel des Teams ist es, in der Planungsphase die Lösung so zu dokumentieren, dass das Team sie pünktlich sowie kostengünstig entwickeln und bereitstellen kann. Diese Dokumente sind dynamischer Natur und müssen daher während der gesamten Planungsphase fortlaufend aktualisiert werden.

Durch eine sorgfältige Arbeit in der Planungsphase lassen sich Risiken verringern und die Aussicht auf einen Projekterfolg vergrößern. Das Team verfolgt während der gesamten Phase sämtliche bekannten Risiken und befasst sich ggf. mit den neu erkannten Risiken.

Dieser Abschnitt des Leitfadens beschreibt ausführlich, welche Aufgaben in der Planungsphase anfallen:

Entwickeln von Lösungsentwurf und -architektur. Das Team beginnt den Entwurfsprozess mit der Site und der Architektur und schließt ihn mit einem Entwurfsdokument ab, das in die Funktionsspezifikation aufgenommen wird.

Erstellen der Funktionsspezifikation. Das Team erarbeitet eine Funktionsspezifikation mit den Anforderungen, die beim Absichern von Windows 2000 Server zu berücksichtigen sind.

Entwickeln der Projektpläne. Das Team erstellt eine Reihe von Plänen dazu, wie die sechs Microsoft-MSF-Teamrollen ihre Aufgaben durchführen. Diese Pläne werden im Projektmasterplan zusammengefasst. Der Projektmasterplan stellt das „Dachdokument“ aller Pläne dar und enthält damit auch strategische Elemente wie Ansatz, Abhängigkeiten und Voraussetzungen für die Lösung.

Erstellen der Projektzeitpläne. Das Team erstellt den Projektmasterplan. In diesem Masterplan sind die Meilensteinpläne der einzelnen Teamrollen zusammengefasst, die diese bei der Planung ihrer jeweiligen Aktivitäten erarbeitet haben.

Erstellen der Entwicklungs-, Test- und Stagingumgebungen. Das Team erstellt gesonderte Entwicklungs- und Testumgebungen, um die Lösung außerhalb der Produktionsumgebung entwickeln und testen zu können.

Abschließen der Planungsphase. Das Team durchläuft die Meilensteingenehmigung und dokumentiert die Ergebnisse der in dieser Phase durchgeführten Aufgaben.

Planungsphase

Der Schwerpunkt der Planungsphase liegt auf der Koordination der Dienstbereitstellung und der Risikoreduzierung. Ziel ist es, einen Plan zu entwickeln und vorzulegen, der den Unternehmensanforderungen und Zielen des Kunden gerecht wird.

Projektergebnisse

Zu den Ergebnissen der Planungsphase gehören:

Lösungsentwurf

Funktionsspezifikation

Projektmasterplan

Budgetplan

Sicherheitsprojektplan

Sicherheitsmaßnahmenplan

Testumgebung-Erstellungsplan

SOW-Dokument für die Erstellungsphase

Kundenbesuchsbericht

Meilensteinüberprüfung zur Planungsphase

Lösungsentwurf

Das Dokument mit dem Lösungsentwurf stellt eine Erweiterung des vorläufigen Erstentwurfs dar, der in der Phase „Ermitteln übergeordneter Faktoren“ entwickelt wurde. Der Lösungsentwurf sollte eine Funktionsspezifikation mit ausführlichen Beschreibungen der Dienste und Funktionen enthalten, die im Rahmen der Sicherheitslösung bereitgestellt werden.

Zur Funktionsspezifikation sollte auch eine ausführliche Bewertung des Unternehmens gehören, in der folgende Bereiche abgedeckt sind:

Bewertung der Unternehmensziele

Finanzdaten

Technische Daten

Vorläufige Anforderungen für die Benutzerproduktivität

Funktionsanforderungen

Der Ausgangspunkt für Sicherheit ist eine klar definierte Richtlinie. Der erste Schritt zur Sicherung eines Unternehmens sollte daher in einer sorgfältigen Prüfung der dokumentierten Richtlinien bestehen. Eine betriebliche Bewertung führt im Allgemeinen zu einer ausführlichen Überprüfung der Richtlinien und Verfahren eines Unternehmens. Einige betriebliche Bewertungen können auch in den Bereich der eingesetzten Technologie hineinreichen.

Ziel einer betrieblichen Bewertung ist es, das Unternehmen bei der Bewertung des aktuellen Sicherheitsstatus und der Einsatzbereitschaft des Betriebsmanagements zu unterstützen. Darüber hinaus soll Hilfe bei allgemeinen und speziellen Empfehlungen zur Verbesserung der Sicherheitsbereitschaft und zur Senkung der Gesamtkosten im Unternehmen geleistet werden.

Ressourcenbewertung

In einem ersten Schritt zur umfassenden Sicherung der Computerumgebung eines Unternehmens werden die vorhandenen Ressourcen, die Bedrohungen, die sich auf die Umgebung auswirken könnten, und die Sicherheitsrisiken für die ermittelten Ressourcen bestimmt. Durch dieses Vorgehen ermitteln Sie eine Reihe von Sicherheitsrisiken, die Sie anschließend analysieren und gewichten können.

Ressourcen können ganz unterschiedlicher Art sein. Je nach vorhandenen Akquiseprozessen und Mechanismen für die Ressourcenverfolgung kann die Ermittlung dieser Ressourcen in manchen Unternehmen sehr einfach sein, in anderen dagegen extrem schwierig.

Während die Ressourcenermittlung ein qualitativer Prozess ist, sollten bei der Bewertung des potenziellen Wertes jedes Servers oder jeder Servergruppe die Gesamtvorteile für die Ziele des Unternehmens berücksichtigt werden. Dabei kann für jeden Server bzw. jede Servergruppe eine Gewichtung vorgenommen werden. Zu berücksichtigen sind jeweils die folgenden Hauptfaktoren:

Finanzieller Wert der Ressource

Herstellungskosten der Ressource

Kosten für den Schutz der Ressource

Wettbewerbswert der Ressource

Rückgewinnungskosten der Ressource

Alle Ressourcen eines Unternehmens auf ein und derselben Skala anzuordnen, ist oft problematisch. Es bietet sich daher an, die Ressourcen nach ähnlichen Technologien zu gruppieren und erst dann zu bewerten. Auf diese Art können Sie den relativen Wert unterschiedlicher Ressourcen viel einfacher vergleichen. Nachfolgend finden Sie eine Beispielliste, die Sie in ähnlicher Weise für Ihr Unternehmen übernehmen können.

Sicherheitsentwurf

Einhaltung bestehender Sicherheitsrichtlinien.

Domänensicherheitsentwurf

Serversperre

Sicherheitsrichtlinie

Active Directory-Entwurf

Gesamtstrukturentwurf

Domänenentwurf

OU-Architektur

FSMO-Rollenverteilung (Flexible Single Master Operation)

Systementwurf

Servernamenskonvention

Hardwaredesign

Systembereitstellung

Speicherarchitektur

Überwachung und Alarmierung

Supportdienste

Sicherungs- und Wiederherstellungsverfahren

Funktionsspezifikation

Diese Aufgabenhilfe gibt einen Einblick in die endgültige Sicherheitslösung. Die Funktionsspezifikation enthält ausführliche Erläuterungen zu den Entwurfszielen der Lösung und bildet einen wesentlichen Bestandteil im Sicherheitsentwurfsprozess.

Projektmasterplan

Der Projektmasterplan wird in der Planungsphase anhand der Ergebnisse und Rückmeldungen aus der Bewertungsphase angepasst.

Budgetplan

Der Budgetplan sammelt alle Budgetschätzungen für das Sicherheitsprojekt und bildet daraus die Gesamtkostenschätzung. Alle Funktionsteams erstellen ihr eigenes Budget und reichen es dann beim Programmmanagement-Rollencluster ein, der daraus den Budgetmasterplan erstellt.

Sicherheitsprojektplan

Im Sicherheitsprojektplan sind alle Schlüsselaktivitäten, Ressourcen und Zeitplanschätzungen für Entwicklung und Bereitstellung der Sicherheitslösung detailliert und nach Aufgabe gegliedert aufgeführt. Der Plan basiert auf der Projektgliederungsstruktur, die in der Phase „Ermitteln übergeordneter Faktoren“ erstellt wurde. Nachdem ein grundlegender Sicherheitsimplementierungsplan entwickelt und genehmigt worden ist, sollte der Sicherheitsprojektplan regelmäßig aktualisiert werden.

Anmerkung: Für die Erstellung eines Sicherheitsprojektplans zum Absichern von Windows 2000 Server – Entwurfs- und Umsetzungsleitfaden ist eine entsprechende Vorlage verfügbar. Weitere Informationen finden Sie in den Aufgabenhilfen zu diesem Leitfaden.

Sicherheitsmaßnahmenplan

Der Sicherheitsmaßnahmenplan enthält die allgemeinen Parameter für das Projekt. Der Plan wird auf der Grundlage der ersten Leitfadeninstanziierung für die Sicherungslösung erstellt, die ihrerseits auf den Bewertungsergebnissen basiert. Eine weitere Bewertung erfolgt anhand der in der Prüfungsphase gesammelten Daten. So kann ermittelt werden, welche Änderungen nötig sind, um den Erstentwurf an den Kundenlösungsentwurf anzupassen. Ergebnis dieser Bewertung ist ein empfohlener Supportplan. Die entsprechenden Aufgabenhilfen werden mit diesem Leitfaden geliefert.

Testumgebung-Erstellungsplan

Der Testumgebung-Erstellungsplan beschreibt die schrittweise Einrichtung der Testumgebung. Er basiert auf dem Lösungsleitfaden und dem Testleitfaden für die Sicherheitsbewertung.

SOW-Dokument für die Erstellungsphase

In diesem SOW-Dokument sind die Aufgaben und Ergebnisse der Erstellungsphase aufgeführt.

Kundenbesuchsbericht

Dieser Bericht enthält die bei Kundenbesuchen während der Planungsphase vereinbarten Ergebnisse. Meilensteinüberprüfung zur Planungsphase

Im Rahmen der Meilensteinüberprüfung zur Planungsphase erteilt der Kunde die Genehmigung zur Erstellungsphase überzugehen.

Die Meilensteinüberprüfung sollte Folgendes beinhalten:

Detaillierter Lösungsentwurf

Ausführlichen Projektmasterplan

Projektzeitplan

Überprüfung des Sicherheitsmaßnahmenplans

Übergeordneten Testumgebung-Erstellungsplan

Planungsprozess

Abbildung 14: Prozessfluss für die Planungsphase

Die wichtigsten Planungsaufgaben und die zugehörige Dokumentation der Sicherheitslösung

Zusammenfassend kann gesagt werden, dass die in der Planungsphase durchgeführten Aktivitäten schwerpunktmäßig dem Verfassen und der genaueren Spezifizierung von zuvor erstellten Plänen dienen. Der Lösungsentwurf, der auf der vorläufigen Version basiert, enthält zusätzliche Details zu den Funktionsspezifikationen. An der Ausarbeitung des Lösungsentwurfs sind der Lösungsarchitekt, der Infrastrukturberater, der Sicherheitsanalyseleiter und weitere Experten (SMEs) beteiligt.

Der Projektmasterplan wird vom Programm- und Projektmanager und mit Hilfe anderer Mitglieder des Projektteams ergänzt. An der Erstellung des Supportplans, welche anhand des Supportleitfadens für die Sicherheitsbewertung erfolgt, sind der Supportberater, SMEs und weitere Mitglieder des Projektteams beteiligt.

Der Testumgebung-Erstellungsplan wird vom Testleiter erstellt, der dabei den Erstellungs- und Testleitfaden zur Hilfe nimmt. Dieser Plan basiert auf der bei der Sicherheitsbewertung geprüften Umgebung und wird ggf. so geändert, dass er dem Lösungsentwurf entspricht.

Diese Anleitungen und Aufgabenhilfen geben den Rahmen für sämtliche Projektergebnisse der Sicherheitslösung vor. Darüber hinaus tragen sie zur Verkürzung dieser Projektphase bei. Der Leitfaden Absichern von Windows 2000 Server stellt eine ausgezeichnete Informationsquelle für die notwendigen Angaben in der Funktionsspezifikation dar. Neben diesen grundlegenden Informationen zur Sicherheitslösung muss die Funktionsspezifikation auch Strategien für die Implementierungsanforderungen der Sicherheitslösung enthalten.

Erstellungsphase

In der Erstellungsphase erfolgt der Großteil der Entwicklung des Lösungskomponentencodes und der zugehörigen Dokumentation. Einige Entwicklungsaufgaben können auch noch im Anschluss an die Tests in der Stabilisierungsphase fortgeführt werden.

Die Erstellungsphase beinhaltet jedoch mehr als nur die Codeentwicklung durch die Softwareentwickler. Darüber hinaus wird auch die Infrastruktur entwickelt, und alle Rollen sind an der Erstellung und den Tests der Lösungsergebnisse beteiligt. Das Team verfolgt während der gesamten Phase alle bekannten Risiken und befasst sich ggf. mit den neu erkannten Risiken.

Folgende MSF-Prozesse werden für die Erstellungsphase empfohlen:

Start des Erstellungszyklus. Das Team beginnt den Erstellungszyklus damit, den vollständigen Abschluss aller für die Entwicklungsaufnahme erforderlichen Aufgaben zu überprüfen, die in der Einführungs- und Planungsphase ausgeführt wurden.

Erstellen einer Konzeptüberprüfung. Das Team nimmt in einer Umgebung, die der Produktionsumgebung möglichst genau entspricht, eine letzte Überprüfung der Entwurfskonzepte vor.

Entwickeln der Lösungskomponenten. Das Team entwickelt die Lösung basierend auf den Kernkomponenten aus dem Leitfaden Absichern von Windows 2000 Server und erweitert diese um die spezifischen Lösungsanforderungen.

Erstellen der Lösung. Täglich oder zumindest häufig erstellte Builds ermöglichen das Sammeln relevanter interner Builds. Sie bezeichnen Punkte, an denen das Entwicklungsteam Schlüsselfunktionen der Lösung bereitgestellt hat.

Abschließen der Erstellungsphase. Das Team schließt alle Funktionen ab, stellt den Code und die Dokumentation bereit, erklärt die Lösung für vollständig entwickelt und durchläuft die Meilensteingenehmigung.

In der Erstellungsphase werden die anwendungsspezifischen Anforderungen analysiert, wodurch die anschließende Anpassung der Sicherheitslösung erleichtert wird. Diese Anforderungen sind in der überarbeiteten Funktionsspezifikation oder dem Dokument mit dem Lösungsentwurf zu berücksichtigen. Zu den Zielen der Erstellungsphase gehören das Verfassen der Gesamtlösung und die Erstellung sowie die Ausführung eines detaillierten, auf die Projektziele zugeschnittenen Testplans. In der Erstellungsphase wird zudem von einer Reihe geschulter Benutzer ein Pilottest durchgeführt, um bereits zu einem frühen Zeitpunkt wertvolles Feedback zu erhalten und die entsprechende Feinabstimmung des Projektsystems vornehmen zu können.

Projektergebnisse

Zu den Ergebnissen der Erstellungsphase gehören:

Schadensbegrenzungsplan für Sicherheitsrisiken

Lösungstestskripts

Lösungserstellungsplan

Lösungsentwurf

Projektmasterplan

Projektzeitplan

Notfallplan für Sicherheitsrisiken

SOW-Dokument für die Bereitstellungsphase

Kundenbesuchsbericht

Meilensteinüberprüfung zur Erstellungsphase

Schadensbegrenzungsplan für Sicherheitsrisiken

Der Schadensbegrenzungsplan für Sicherheitsrisiken basiert auf den Anforderungen, die im Rahmen der ursprünglichen Datensammlung erfasst wurden, sowie auf den zusätzlich ermittelten Anforderungen aus den bisherigen Projektphasen. In diesem Plan sollten Leistungs- und Skalierbarkeitstests sowie Nutzbarkeits- und Sicherheitstests enthalten sein.

Lösungstestskripts

In den Lösungstestskripts werden ggf. Anpassungen an den Testskripts vorgenommen, die im entsprechenden Testleitfaden für die Bereitstellung der geeigneten Sicherheitsrichtlinie enthalten sind.

Lösungserstellungsplan

Der Lösungserstellungsplan basiert auf dem in der Planungsphase entwickelten Testumgebung-Erstellungsplan und bietet eine schrittweise Anleitung zur Erstellung der Produktionsumgebung. Die vorgenommenen Änderungen am Testumgebung-Erstellungsplan leiten sich aus den Tests und Anpassungen des Lösungsentwurfs ab. Der Lösungserstellungsplan wird anhand der normativen Vorgaben aus dem Lösungshandbuch für die geeignete Sicherheitsbewertung geändert.

Lösungsentwurf

Der Lösungsentwurf, der auch eine detaillierte Funktionsspezifikation enthält, sollte anhand der Testergebnisse aktualisiert und mit dem Kunden sowie dem Projektteam abgesprochen werden.

Projektmasterplan

Der Projektmasterplan wird anhand der Ergebnisse und Rückmeldungen aus der Bewertungsphase geändert.

Projektzeitplan

Der Projektzeitplan ist mit allen Projektänderungen zu aktualisieren, die sich möglicherweise auf den Zeitplan auswirken können.

Notfallplan für Sicherheitsrisiken

In den Notfallplan für Sicherheitsrisiken sollten alle erforderlichen Änderungen aufgenommen werden, die sich aus den Pilottests des Lösungsentwurfs in einer Produktionsumgebung ergeben.

SOW-Dokument für die Bereitstellungsphase

In diesem SOW-Dokument sind die Aufgaben und Ergebnisse der Bereitstellungsphase aufgeführt.

Kundenbesuchsbericht

Dieser Bericht enthält die bei Kundenbesuchen während der Erstellungsphase vereinbarten Ergebnisse.

Meilensteinüberprüfung zur Erstellungsphase

Im Rahmen der Meilensteinüberprüfung zur Erstellungsphase erteilt der Kunde die Genehmigung zur Bereitstellungsphase überzugehen. Die Meilensteinüberprüfung sollte Folgendes beinhalten:

Übersicht über Testplan und Testergebnisse

Änderungen am Lösungsentwurf

Änderungen am Projektmasterplan

Änderungen am Erstellungsplan für die betriebliche Migration

Projektrisiken

Projektbudget

Projektzeitplan

Erörterung des Endbenutzerkommunikationsplans

Das in Abbildung 15 gezeigte Flussdiagramm bildet die Beziehungen zwischen Projektteam und Projektergebnissen in der Erstellungsphase eines Sicherheitsprojekts ab.

Erstellungsprozess

Abbildung 15: Prozessfluss für Projektteam und Projektergebnisse in der Erstellungsphase

Die wichtigsten Erstellungsaufgaben und die zugehörige Sicherheitslösungsdokumentation

Die in der Erstellungsphase durchgeführten Aktivitäten befassen sich schwerpunktmäßig mit dem Test der Lösung in einer Testumgebung und ggf. der Anpassung des Lösungsentwurfs. Die Testmethoden und -skripts für die Sicherheitslösung werden so angepasst, dass sie den spezifischen Anforderungen der Sicherheitslösung gerecht werden. Darüber hinaus werden die endgültigen Testpläne erstellt und ausgeführt, um so die Funktionalität der Sicherheitslösung zu validieren und zu bestätigen. Der Testberater und der Lösungsarchitekt sollten sich fortlaufend darüber abstimmen, wie der Gesamtentwurf anhand der Testergebnisse optimiert werden kann.

In der Erstellungsphase wird die Pilotlösung in der Produktionsumgebung getestet und das Feedback zur Pilotversion in den endgültigen Lösungsentwurf übernommen. Basierend auf den Ergebnissen aus dem Pilottest werden Anpassungen im Supportplan und möglicherweise dem Lösungsentwurf vorgenommen.

Wie in früheren Phasen werden auch in der Erstellungsphase alle zugehörigen Pläne mit Hilfe des Test-, Erstellungs- und Betriebsleitfadens für die geeignete Sicherheitsbewertung erzeugt und weiterentwickelt.

Stabilisieren

In der Stabilisierungsphase werden die fertigen Funktionen der Lösung zum Absichern von Windows 2000 Server getestet. Darüber hinaus führt das Team geeignete Aufgaben durch und erstellt Projektergebnisse. So wird eine Lösungsversion mit allen Funktionen bereitgestellt, die das definierte Qualitätsniveau erreicht hat und in die Produktionsumgebung übertragen werden kann. Der Testschwerpunkt liegt in dieser Phase auf der Nutzbarkeit und dem Einsatz unter realistischen Umgebungsbedingungen. Das Team befasst sich vorrangig mit der Beseitigung, Sichtung und Gewichtung von Fehlern sowie der Vorbereitung der Lösungsfreigabe.

Zu Beginn dieser Phase werden Fehler häufig schneller gemeldet, als sie von den Entwicklern behoben werden können. Die Anzahl der Fehler und der erforderliche Zeitrahmen für ihre Beseitigung sind unmöglich vorauszusagen. Es gibt jedoch einige statistische Kennwerte, wie Fehlerkonvergenz und die Zero-Bug-Bounce-Technik, die zur Einschätzung der voraussichtlichen Stabilität der Lösung herangezogen werden können.

Das MSF vermeidet bei der Statusbeschreibung von IT-Projekten die Begriffe „Alpha“ und „Beta“. Diese Begriffe sind zwar allgemein gebräuchlich, werden aber für eine sinnvolle Verwendung zu unterschiedlich ausgelegt. Ein Projektteam kann auf eigenen Wunsch mit diesen Begriffen arbeiten. Voraussetzung dafür ist jedoch, dass diese eindeutig definiert und von allen Teammitgliedern, Kunden und sonstigen Projektbeteiligten verstanden werden.

Sobald ein Build als stabil genug für einen Release Candidate erachtet wird, wird die Lösung in einer Pilotgruppe umgesetzt. Den Abschluss dieser Phase bildet der Meilenstein „Freigabe genehmigt“. Dieser zeigt an, dass das Team und der Kunde alle verbleibenden Probleme übereinstimmend geklärt und aus dem Weg geräumt haben.

Dieser Abschnitt des Leitfadens beschreibt ausführlich, welche Aufgaben in der Stabilisierungsphase des Projekts anfallen:

Testen der Lösung. In diesem Abschnitt der Stabilisierungsphase implementiert das Team die in der Planungsphase erstellten Testpläne, die in der Entwicklungsphase weiter verbessert und getestet worden sind.

Durchführen des Pilottests. In diesem Abschnitt der Stabilisierungsphase verlagert das Team eine Pilotversion der Lösung aus dem Entwicklungs- in einen Stagingbereich und testet die Lösung an tatsächlichen Benutzern und Szenarien. Der Pilottest wird vor dem Beginn der Bereitstellungsphase durchgeführt.

Teamschwerpunkte in der Stabilisierungsphase

Die folgende Liste beschreibt die Schwerpunkte und Verantwortungsbereiche der einzelnen Teamrollen in der Stabilisierungsphase. Die Teams aus den Bereichen Test- und Release Management sind in dieser Phase besonders wichtig.

Tabelle 4: Teamschwerpunkte in der Stabilisierungsphase

Rolle Schwerpunkt

Produktmanagement Ausführen des Kommunikationsplans, Planen der Lösungseinführung.

Programmmanagement Verfolgen des Projekts, Sichtung von Fehlern.

Entwicklung Beseitigen von Fehlern, Optimieren des Codes.

Tests Testen, Melden von Fehlern und Fehlerstatus, Testen der Konfiguration.

Release Management Einrichten und Unterstützen der Pilotversion, Planen der Bereitstellung und des Betriebs, Unterstützen der Schulungsanforderungen.

Testen der Lösung

Durch den Testprozess sollen mögliche Lösungsprobleme noch vor der tatsächlichen Bereitstellung identifiziert und beseitigt werden. Die Tests starten parallel zur Lösungsentwicklung und enden mit der Bestätigung des Testteams, dass die Lösungskomponenten den Zielen des Projektplans hinsichtlich Qualität und Zeitplan entsprechen.

Das Entwicklungsteam entwirft, dokumentiert und schreibt Code, der in Form von Einheitentests und täglichen Builds getestet wird. Dieses Team verfolgt den Entwicklungsfortschritt anhand des Projektzeitplans, beseitigt die gemeldeten Fehler und dokumentiert die Testergebnisse.

Das Testteam entwirft und dokumentiert Testspezifikationen und Fallstudien, erstellt automatisierte Skripts und führt Akzeptanztests der für formale Tests vorgelegten Komponenten durch. Es bewertet und dokumentiert die Qualität der gesamten Lösung und die Vollständigkeit der Funktionen. Letztendlich wird bestätigt, dass alle Merkmale, Funktionen und Komponenten den Projektzielen entsprechen.

Die in der Planungsphase erstellten Testpläne werden in der Stabilisierungsphase umgesetzt.

Der Testplan unterteilt den Testprozess in folgende Elemente:

Codekomponententests

Datenbanktests

Infrastrukturtests

Sicherheitstests

Integrationstests

Benutzerakzeptanz- und Nutzbarkeitstests

Belastungs-, Kapazitäts- und Leistungstests

Regressionstests

Testen und Optimieren von Tools

Folgende Test- und Optimierungstools werden zum Absichern von Windows 2000 Server eingesetzt, um den Testprozess vollständig durchzuführen und Test- sowie Metrikdaten für die anschließende Messung bereitzustellen:

Testen der Einheitenkomponenten

Zweck der Funktionstests von Einheitenkomponenten ist das Ermitteln von Abweichungen zwischen der Funktionsspezifikation und der tatsächlichen Sicherheitskomponente. Allgemeine Smoke-Tests, Grenzbedingungen und Fehlerfallstudien basieren allesamt auf den Anforderungen der Funktionsspezifikation.

Bei Eindringversuchen werden Tools, Techniken und Methoden verwendet, um Angriffe auf sämtliche gesicherten Systeme nachzustellen. Die spezifischen Systeme sollten in der Ressourcenanalyse, der Funktionsspezifikation und dem Schadensbegrenzungsplan für Sicherheitsrisiken dargestellt sein. Im Rahmen der Tests wird die CPU-Last des Systems gemessen und überwacht. Darüber hinaus wird der Arbeitsspeicherverbrauch der einzelnen Lösungskomponenten verfolgt, der Auswirkungen auf die Server im Netzwerk hat.

Sicherheitstests

Die Anwendung muss unbedingt gegen Anwendungsfehler gesichert werden, die es einem Angreifer möglich machen würden, die Anwendungsarchitektur zuzuordnen, Zugang zu vertraulichen Systemdaten zu erhalten (einschließlich Anmeldeinformationen und Strings für Datenbankverbindungen) oder beliebigen Code auf einem Server auszuführen (wie z. B. bei einem Pufferüberlauf). Risiken, die aus ungeprüften Fehlern im System resultieren, können minimiert werden, wenn Sie den Benutzerkontext in dem die Systemprozesse ausgeführt werden, genau kennen und die Berechtigungen der einzelnen Konten möglichst gering halten, sowie die Zugriffe protokollieren.

Einige Fehler, beispielsweise Fehler im System und der Betriebssystemsoftware, können Sie u. U. nicht kontrollieren. Die sorgfältige Anwendung der neuesten Sicherheitspatches und Updates von Softwareanbietern stellt daher eine wichtige Aufgabe im Verwaltungsprozess dar, die einem Mitglied des Supportteams zugewiesen werden muss.

Geschieht dies nicht, könnte das für die Systeme bzw. das Unternehmen katastrophale Folgen haben. Zu den weiteren wichtigen Aspekten der Umgebungssicherung im Unternehmen gehört die Einrichtung von Prozessen und Verfahren zum Schutz vor unsicheren oder fehlenden Kennwörtern für Netzwerksysteme und Datenbanken, zur Validierung der Clienteingaben und zur Verhinderung des heimlichen Anwendungszugriffs. Diese Sicherheitsfehler lassen sich glücklicherweise einfach beseitigen.

Die wichtigste bei Sicherheitstests verwendete Technik ist der Verstoß gegen die eingebauten Sicherheitskontrollen. Auf diese Weise kann sichergestellt werden, dass die Schutzmechanismen das System vor unberechtigten Eindringungsversuchen schützen. Der Tester führt eine Systemüberlastung herbei, indem er wiederholte Anforderungen sendet, und so einen DoS-Angriff (Denial-of-Service) simuliert. Dieser macht anderen Benutzern die Netzwerknutzung unmöglich. Der Tester kann auch bewusst Systemfehler herbeiführen, um dann während der Wiederherstellung in das System einzudringen, oder er kann unsichere Daten nach einem Verschlüsselungsschlüssel durchsuchen, der den Systemzugriff ermöglicht.

Weiterführende Sicherheitsmechanismen

Erstellen und implementieren Sie eine Richtlinie, in der festgelegt ist, welche Ports auf jedem Computer verfügbar sein müssen, damit die Anwendung ordnungsgemäß arbeitet. Legen Sie darüber hinaus fest, welche Ports über die Firewall zur Verfügung stehen müssen (und in welcher Richtung). Alle Server und Netzwerkteilnehmer müssen für unberechtigte Ports gesperrt werden, um unberechtigte Zugriffsversuche auf Dienste zu unterbinden. Des Weiteren muss das Netzwerk so konfiguriert werden, dass der Zugriff über die Firewall auf bestimmten Ports nur auf spezielle Server gelenkt wird und so Angriffe über Netzwerk-Spoofing vermieden werden.

Treffen Sie zudem Maßnahmen, um sich vor verteilten DoS-Angriffen zu schützen. Diese Angriffe werden häufig dazu verwendet, den Zugriff auf kommerziell genutzte Websites zu verhindern. Der Siteadministrator sollte umfassend mit der Sicherheitsverwaltung vertraut sein und regelmäßige Sicherheitsüberprüfungen der Anwendung durch einen vertrauenswürdigen Drittanbieter veranlassen.

Akzeptanztests

Benutzer- und Nutzbarkeitstests beginnen in der Entwicklungsphase und werden während der Stabilisierungsphase fortgesetzt. Mit Hilfe dieser Tests wird sichergestellt, dass das neue System alle Benutzer- und Unternehmensanforderungen erfüllt. Diese Tests sind nicht zu verwechseln mit der Bewertung der Kundenakzeptanz, die zum Ende des Projekts erfolgt.

Akzeptanztests werden nach Abschluss der Funktionstests für ausgewählte Unternehmensfunktionen in der Produktionsumgebung durchgeführt. Dabei handelt es sich um die letzte Teststufe vor der Betriebsaufnahme durch das System. Anstelle der simulierten Daten, die im Rahmen des Testprozesses entwickelt wurden, erfolgt der Systemtest hier mit Daten, die von den tatsächlichen Benutzern oder Kunden zur Verfügung gestellt werden.

Durch Akzeptanztests werden häufig Fehler und Auslassungen in der Definition der Systemanforderungen aufgedeckt. Beispielsweise kann es sein, dass die Anforderungen nicht den tatsächlichen Funktionen und Leistungen entsprechen, die der Benutzer benötigt. Akzeptanztests können auch zeigen, dass das System nicht die erwartete Leistung und Funktionalität aufweist.

Durch Benutzerakzeptanztests erhalten Supportmitarbeiter und Benutzer zudem die Möglichkeit, sich im Rahmen praxisnaher Übungen mit der neuen Technologie vertraut zu machen. Dadurch lässt sich ermitteln, in welchen Bereichen der Lösung die Benutzer noch Verständnis-, Lern- und Verwendungsprobleme haben. Durch Versionstests kann das Release Management darüber hinaus Probleme identifizieren, welche die erfolgreiche Implementierung verhindern könnten.

Regressionstests

Bei Regressionstests werden bereits getestete Komponenten und die Systemfunktionalität erneut getestet, um das ordnungsgemäße Funktionieren auch nach Änderungen an bestimmten Teilen des Systems sicherzustellen. Werden Fehler in einer Komponente entdeckt, müssen diese durch geeignete Maßnahmen beseitigt werden. Das kann auch bedeuten, dass andere Komponenten erneut getestet werden müssen.

Komponentensystemfehler können sich erst spät im Testprozess zeigen. Der Prozess ist iterativ, da Informationen aus späteren Phasen in die früheren Abschnitte zurückgeführt werden müssen. Durch die Reparatur von Programmfehlern können weitere, neue Fehler entstehen. Der Testprozess muss daher wiederholt werden, nachdem Änderungen am System vorgenommen wurden.

Folgende Richtlinien sind bei Regressionstests zu beachten:

Testen Sie alle an der Lösung vorgenommenen Änderungen, um sicherzugehen, dass daraus keine neuen Probleme entstanden sind und die Betriebsleistung nicht beeinflusst wurde.

Alle nach Abschluss einer Testphase bzw. nach Abschluss des letzten Systemtestlaufs an der Lösung vorgenommenen Änderungen müssen einem umfassenden Regressionstests unterzogen werden. So wird sichergestellt, dass die Änderungen keine negativen Auswirkungen auf andere Systembereiche und sonstige Systeme haben.

Änderungen an den Lösungskomponenten können auch Änderungen der Tests selbst erforderlich machen. Das Projektteam muss Testdaten auf der Grundlage vordefinierter Spezifikationen entwickeln. Die ursprünglichen Testdaten sollten aus anderen Testebenen übernommen und dann gemeinsam mit den Fallstudien angepasst werden.

Testverfolgung und -berichterstattung

Die Testverfolgung und -berichterstattung erfolgt in kurzen Abständen während der Entwicklungs-, Test- und Stabilisierungsphase des Projekts. In der Stabilisierungsphase orientiert sich die Berichterstattung an der Anzahl der ermittelten Fehler. Die regelmäßige Information des Teams und anderer wichtiger Projektbeteiligter über den Teststatus garantiert eine hohe Projektqualität.

Zwischenmeilenstein: Fehlerkonvergenz

Als Fehlerkonvergenz wird der Punkt bezeichnet, ab dem das Team nachvollziehbar mehr Fehler beseitigt als neue Fehler entdeckt. Abbildung 16 verdeutlicht dies.

Da die Fehlerrate nach wie vor schwankt, auch wenn sie insgesamt zurückgeht, stellt die Fehlerkonvergenz in der Regel eher einen Trend als einen bestimmten Zeitpunkt dar. Nach der Fehlerkonvergenz sollte die Anzahl an Fehlern kontinuierlich bis auf Null zurückgehen.

Abbildung 16: Beispiel für Fehlerkonvergenz

Zwischenmeilenstein: Fehlerfreier Zustand

Als fehlerfreier Zustand wird der Zeitpunkt im Projekt bezeichnet, an dem die Entwicklung die Tests eingeholt hat und momentan keine aktiven Fehler vorhanden sind. Abbildung 17 veranschaulicht dies. Nach dem fehlerfreien Zustand liegen die Fehlerspitzen deutlich niedriger und die Fehleranzahl sollte weiterhin so lange abnehmen, bis das Produkt stabil genug ist, damit das Team den ersten Release Candidate erstellen kann.

Abbildung 17: Beispiel für einen fehlerfreien Zustand

Entscheidend für das Projekt ist eine sorgfältige Fehlersichtung, da jeder beseitigte Fehler das Risiko eines neuen Fehlers bzw. eines Regressionsproblems in sich birgt. Der fehlerfreie Zustand ist ein deutliches Zeichen dafür, dass sich das Team in der Endphase der Arbeit befindet und bald ein stabiler Release Candidate erstellt werden kann.

Anmerkung: Mit Sicherheit werden auch nach diesem Meilenstein noch neue Fehler gefunden. Dennoch kann das Team hier zum ersten Mal vermelden, dass vorerst keine aktiven Fehler mehr vorliegen. Dies verleiht dem Team zusätzlichen Antrieb, die Qualität der Arbeit zu optimieren.

Nach dem Zero-bug-Release liegen die Fehlerspitzen deutlich niedriger und die Fehleranzahl sollte kontinuierlich so weit abnehmen, dass das Produkt stabil genug ist und das Team den ersten Release Candidate entwickeln kann.

Zwischenmeilenstein: Release Candidates

Nach dem ersten fehlerfreien Zustand wird eine Reihe von Release Candidates für die Pilotgruppe entwickelt. Jedes Release stellt dabei einen Zwischenmeilenstein dar.

Folgende Richtlinien sind zu beachten, um ein Build als Release zu erklären:

Jeder Release Candidate weist sämtliche Elemente auf, um als Produktionsrelease in Frage zu kommen.

Release Candidates werden auf ihre Einsatzbereitschaft hin getestet. Das heißt, es wird geprüft, ob alle erforderlichen Bestandteile vorhanden sind.

In der anschließenden Testperiode wird ermittelt, ob ein Release Candidate in der Produktionsumgebung eingesetzt werden kann, oder ob das Team einen neuen Release Candidate mit geeigneten Fixes entwickeln muss.

Release Candidates müssen innerhalb des Teams sorgfältig und umfassend getestet werden. Der Schwerpunkt liegt dabei auf der Entfernung von den Fehlern, welche die Einführung des Systems verhindern würden (Show Stopper).

Für die Tests ist ein Sichtungsprozess erforderlich, damit auch alle neu entdeckten Fehler noch beseitigt werden können.

Der erste Release Candidate ist vermutlich nicht die letzte, tatsächlich freigegebene Version. Bei den intensiven Tests werden meist noch wichtige Show Stopper entdeckt, die vor der Systemeinführung beseitigt werden müssen.

Bei jedem neuen Release Candidate sollten weniger Fehler zu finden, zu berichten und zu beseitigen sein. Jeder Release Candidate ist insofern von Bedeutung, als sich das Team dem Ende der Bereitstellungsphase nähert und die Qualität ins Zentrum der Bemühungen rückt.

Durchführen des Pilottests

In der Pilotphase testet das Team die Gesamtlösung so umfassend wie möglich in einer tatsächlichen Produktionsumgebung. Ein Pilot Release wird in einem Teil der Produktionsumgebung bzw. für einen Teil der Benutzergruppe bereitgestellt. Je nach Projektkontext kann dies in verschiedener Weise geschehen:

In einem Unternehmen kann die Pilotversion auf eine Benutzergruppe oder eine Reihe von Servern in einem Rechenzentrum ausgerichtet sein.

Bei der Webentwicklung können Sitedateien auf Stagingservern oder in Ordnern eingerichtet werden, die live im Internet sind, aber Testwebadressen verwenden.

Anbieter von kommerziell verwendeten Softwareprogrammen, wie Microsoft, überlassen Produkte häufig vor der endgültigen Freigabe einer bestimmten Gruppe von Benutzern (Early Adopter-Programme).

All diesen Pilotprogrammformen ist gemeinsam, dass die Tests unter tatsächlichen Einsatzbedingungen erfolgen. Der Pilottest ist erst dann abgeschlossen, wenn das Team garantieren kann, dass die Lösung in der Produktionsumgebung eingesetzt werden kann und alle Lösungskomponenten ordnungsgemäß arbeiten. Die folgenden Punkte spielen zum Stabilisieren der Lösung eine wesentliche Rolle:

Vor dem Beginn des Pilottests müssen das Team und die Testteilnehmer die entsprechenden Erfolgsfaktoren klar und übereinstimmend festlegen. Diese Kriterien sollten den Erfolgskriterien aus der Entwicklungsphase zugeordnet werden können.

Alle im Rahmen des Pilottests ermittelten Probleme müssen aus dem Weg geräumt werden. Dazu können weitere Entwicklungen vorgenommen und die Lösungen sowie Problemumgehungen für die Installationsteams und die Mitarbeiter im Produktionssupport dokumentiert bzw. ergänzend in das Schulungs- oder Hilfematerial aufgenommen werden.

Vor dem Start des Pilottests muss eine Supportstruktur und ein Prozess für die Problemlösung eingerichtet werden. Dazu müssen die Supportmitarbeiter u. U. speziell geschult werden. Die Verfahren, die während eines Pilottests für die Problemlösung verwendet werden, können sich deutlich von denen unterscheiden, die bei der Bereitstellung und dem späteren Produktionsbetrieb zum Einsatz kommen.

Über eine Test- oder Probeausführung aller Bereitstellungselemente können noch vor der tatsächlichen Bereitstellung eventuelle letzte Probleme ermittelt und der reibungslose Ablauf des Bereitstellungsprozesses sichergestellt werden.

Nachdem genügend Pilotdaten gesammelt und ausgewertet wurden, muss das Team für das weitere Vorgehen eine grundlegende Strategie wählen:

Staffelung: Ein neues Release wird für die Pilotgruppe bereitgestellt.

Rollback: Ein Rollbackplan wird ausgeführt und die Pilotgruppe wird (so weit wie möglich) auf den Konfigurationsstand vor Beginn des Pilottests zurückgesetzt. Anschließend beginnt das Team den Testprozess mit einer stabileren Version von vorne.

Aussetzung: Der gesamte Pilottest wird ausgesetzt.

Patch und Fortführung: Für den vorhandenen Code wird ein Patch oder Fix erstellt.

Übergang zur Bereitstellungsphase.

Erstellen der Pilottestberichte

Nach Abschluss der einzelnen Pilottestzyklen fertigt das Team detaillierte Berichte dazu an, welche Erkenntnisse gewonnen und wie neue Informationen gehandhabt bzw. neue Probleme gelöst wurden. Der Pilottest kann zu folgenden Ergebnissen führen:

Identifizierung zusätzlicher Risiken.

Häufig gestellte Fragen (FAQs) für Schulungszwecke.

Ermittlung von Benutzerfehlern.

Fundierte Beiträge und Unterstützung durch Pilotbenutzer.

Dokumentation zu Bedenken und Problemlösungen.

Dokumentationsupdates, insbesondere zu Hilfedateien und Bereitstellungsplänen.

Schlussfolgerung, ob alle Erfolgskriterien erfüllt wurden.

Abschließen der Stabilisierungsphase

Zum Abschluss der Stabilisierungsphase gehört ein vollständiger Prozess zur Meilensteinüberprüfung. Das Team muss die Ergebnisse der einzelnen, in dieser Phase durchgeführten Aufgaben, dokumentieren und dem Projektmanagement zur Genehmigung vorlegen.

Die wichtigsten Aufgaben und Ergebnisse der Stabilisierungsphase

Zu den während der Stabilisierungsphase erstellten Teamergebnissen gehören:

Gold Release

Versionshinweise

Hilfe und Schulungsmaterial für Endbenutzer

Test- und Fehlerberichte

Testprogramme

Prüfung der Zuordnungsfähigkeit

Dokumentation und ausführbare Dateien

Projektdokumente

Risikomanagement (aktualisiert)

Meilensteinüberprüfungsbericht

Bericht über den Projektfortschritt der Teammitglieder

Bericht über den Projektfortschritt der Teamleiter

Tabelle 5: Aufgaben und Verantwortliche in der Stabilisierungsphase

Kernaufgaben Verantwortlicher

Testen der Lösung Testteam

Durchführen des Pilottests Release Management

Abschließen der Stabilisierungsphase Projektteam

Wichtiger Meilenstein: Freigabe genehmigt

Die Stabilisierungsphase endet mit dem Meilenstein „Freigabe genehmigt“. Zu diesem Zeitpunkt hat das Team alle verbleibenden Probleme beseitigt und die Lösung zur vollständigen Bereitstellung freigegeben. Dieser Meilenstein bietet Kunden und Benutzern, dem Betriebs- und Supportpersonal, sowie wichtigen Projektbeteiligten die Möglichkeit, die Lösung zu evaluieren und verbleibende Probleme zu ermitteln, die vor der Stabilisierung und der endgültigen Freigabe noch beseitigt werden müssen.

Übergang zur nächsten Phase

Nachdem alle Aufgaben zur Stabilisierungsphase vollständig erledigt wurden, muss das Team formal genehmigen, dass das Projekt den Meilenstein der Freigabe erreicht hat. Mit dem Übergang zur nächsten Phase geht die Verantwortung für die laufende Verwaltung und Unterstützung der Lösung offiziell vom Projektteam auf die Betriebs- und Supportteams über. Durch ihre Genehmigung drücken die Teammitglieder aus, dass sie mit der durchgeführten Arbeit in ihrem Verantwortungsbereich zufrieden sind.

Projektteams bestätigen einen Meilenstein in der Regel durch formale Abzeichnung. Die wichtigsten Projektbeteiligten, meist ein Vertreter jeder Teamrolle und alle wichtigen Kundenvertreter, die nicht selbst Mitglieder des Projektteams sind, signalisieren ihre Zustimmung durch Abzeichnung eines Dokuments, das besagt, dass der Meilenstein vollständig erreicht und umgesetzt wurde. Dieses Dokument gilt ebenfalls als Projektergebnis und wird zur späteren Referenz archiviert.

Testen der Geschäftsfunktionen

Dieser Plan stellt einen Prozess bereit, der das Betriebspersonal und die Belegschaft des Unternehmens nach der Implementierung der Sicherheitsmaßnahmen durch die Funktionstests der Unternehmensanwendungen und Prozesse führt.

Bereitstellen

In dieser Phase stellt das Team die Lösungstechnologie und -komponenten bereit, nimmt die Stabilisierung vor, übergibt das Projekt an die Betriebs- und Supportteams und holt die endgültige Kundengenehmigung für das Projekt ein. Nach der Bereitstellung wird ein Projektfazit gezogen und ein Bericht zur Kundenzufriedenheit angelegt. Die Stabilisierung wird eventuell noch parallel dazu fortgesetzt, bis alle Projektkomponenten von der Test- oder Stagingumgebung in die Produktionsumgebung verlagert wurden.

Zu den wichtigsten Aufgaben in dieser Phase gehören die Vorbereitung der Bereitstellung, die Überprüfung ob die Umgebung für die Lösungsfreigabe bereit ist und anschließend die tatsächliche Bereitstellung auf den Unternehmensservern. Nach der Bereitstellung, Stabilisierung und Übertragung der Lösung in die Betriebsumgebung zieht das Team ein Projektfazit. Die Phase endet mit dem Meilenstein „Bereitstellung abgeschlossen“.

Dieser Abschnitt des Leitfadens beschreibt ausführlich die Aufgaben in der Bereitstellungsphase:

Verfahren für Bereitstellung und Betrieb: Das Team erstellt formale Bereitstellungs- und Betriebsverfahren zur Durchführung der entsprechenden Aufgaben.

Bereitstellung und Stabilisierung: Das Team nimmt die tatsächliche Bereitstellung der Komponenten und der Site vor.

Projektfazit: Das Team nimmt mit dem Kunden und dem Projektteam die Endbewertung vor.

Bereitstellungsphase

In der Bereitstellungsphase werden alle Lösungsaspekte sorgfältig synchronisiert, einschließlich der Umgebungsinfrastruktur und Anwendungen, der Endbenutzer und Systemstandorte. Darüber hinaus müssen die vereinbarten Termine für Projektanwendungen eingehalten werden, die von der Lösungsbereitstellung betroffen sind.

In der Bereitstellungsphase müssen die einzelnen Projektbeteiligten koordiniert, sowie die geeigneten Zielgruppen für den Projektübergang ermittelt und vorbereitet werden. Für den Fall, dass die Bereitstellung fehlschlägt, sollten Sicherungs- oder andere alternative Rollbackpläne vorhanden sein. Die jeweilige Bereitstellungsstrategie richtet sich nach Legacynetzwerk, -systemen und -anwendungen.

Projektergebnisse

Zu den Ergebnissen der Bereitstellungsphase gehören:

Lösungserstellungsplan

Endgültiger Projektmasterplan

Endgültiger Projektzeitplan

Lösungsentwurf

Endgültiger Kundensupportplan

Plan für die betriebliche Migration (auf der Grundlage des beim Pilottest erstellten Implementierungsplans)

Kundenbesuchsbericht

Meilensteinüberprüfung zur Bereitstellungsphase

Betriebshandbuch für den Kunden

Projektabschlussbericht

Kundenreferenz

Bericht zur Kundenzufriedenheit

Lösungserstellungsplan

Der Lösungserstellungsplan wird mit allen Änderungen aktualisiert, die im Laufe der Bereitstellungsphase vorgenommen werden.

Endgültiger Projektmasterplan

Der Projektmasterplan wird anhand der Ergebnisse und Rückmeldungen aus der Bereitstellungsphase angepasst.

Endgültiger Projektzeitplan

Der Projektzeitplan ist mit allen Projektänderungen zu aktualisieren, die sich möglicherweise auf den Zeitplan auswirken können.

Lösungsentwurf

Der Lösungsentwurf wird mit allen Änderungen aktualisiert, die im Laufe der Bereitstellungsphase vorgenommen werden.

Endgültiger Kundensupportplan

Der Kundensupportplan muss in der Bereitstellungsphase aktualisiert und anschließend dem Kunden zur Genehmigung vorgelegt werden.

Plan für die betriebliche Migration

Der Plan für die betriebliche Migration stellt zum Teil eine Überarbeitung des Implementierungsplans dar, der während der Pilotimplementierung erstellt wurde. Der Plan enthält folgende Projektinformationen:

Umfang: Skizziert die von der Migration betroffenen Betriebsbereiche.

Zielsetzung: Beschreibt die Ergebnisse der Produktionsmigration.

Risiken: Erläutern die Risiken für die Produktionsumgebung.

Produktionsimplementierungsplan: Enthält Meilensteine und Verfahren für die Implementierung der Lösung in der Produktionsumgebung.

Rollbackplan: Sieht Verfahren für die Wiederherstellung einer früheren Produktionsumgebung vor.

Supportanforderungen: Definieren das nötige Supportausmaß und die Verfahren zur Beseitigung von Benutzerproblemen.

Ressourcenanforderungen: Beschreiben die Infrastruktur, das Projektteam und wichtige Kundenressourcen, die für die Implementierung und Unterstützung der Produktionsumgebung benötigt werden.

Schulungsanforderungen: Bereiten die Endbenutzer auf die Implementierung der Lösung in der Produktionsumgebung vor.

Kundenbesuchsbericht

Dieser Bericht enthält die bei Kundenbesuchen während der Bereitstellungsphase vereinbarten Ergebnisse.

Meilensteinüberprüfung zur Bereitstellungsphase

Die Meilensteinüberprüfung zur Bereitstellungsphase erfolgt im Rahmen einer Präsentation, nach welcher der Kunde die endgültige Entscheidung trifft, ob der Lösungsentwurf in die Produktionsumgebung verlagert werden kann. Die Meilensteinüberprüfung sollte Folgendes beinhalten:

Änderungen am Lösungsentwurf, Lösungserstellungsplan, Projektmasterplan und Projektzeitplan.

Projektbudget

Risikoplan

Plan für die betriebliche Migration

Betriebshandbuch für den Kunden

Das Betriebshandbuch für den Kunden ist anhand aller Projektänderungen zu aktualisieren, die während der Bereitstellungsphase vorgenommen werden.

Projektabschlussbericht

Der Projektabschlussbericht untersucht die vom Kunden und dem Projektteam im Laufe des Projekts gewonnenen Erkenntnisse. Dazu zählen sowohl die Erfolge als auch die Fehlschläge. Der Projektabschlussbericht ist vor allem dann sinnvoll, wenn er unmittelbar nach der Produktfreigabe und der Bereitstellung angelegt wird.

Die im Projektabschlussbericht aufgeführten Angaben stammen häufig aus den Meilenstein- und Projektteamüberprüfungen. Darüber hinaus kann der Projektabschlussbericht Versionshinweise enthalten, die sowohl bekannte Probleme und Problemlösungen für die aktuelle Version behandeln, als auch die endgültige Version der Dokumentation der Sicherheitslösung aufführen.

Kundenreferenz

Wird das Projekt allgemein als Erfolg angesehen und beschlossen, dass der Kunde als Referenzkunde für die Beratungsorganisation in Frage kommt, kann der Programmmanager um eine Kundenreferenz bitten. Diese Referenz wird meist in Form eines so genannten MOU (Memorandum of Understanding) oder einer Pressemitteilung abgegeben.

Bericht zur Kundenzufriedenheit

Zum Projektabschluss wird ein Bericht zur Kundenzufriedenheit erstellt, um den Projekterfolg einzuschätzen.

Das Flussdiagramm in Abbildung 18 erläutert die wichtigsten Aufgaben und Ergebnisse der Bereitstellungsphase.

Bereitstellungsprozess

Abbildung 18: Prozessfluss für die Bereitstellungsphase

Die wichtigsten Bereitstellungsaufgaben und die zugehörige Dokumentation der Sicherheitslösung

Die Bereitstellungsphase endet mit dem Freigabemeilenstein, nachdem das Projektteam alle verbleibenden Probleme beseitigt und die Sicherheitslösung in Betrieb genommen hat.

Bevor die Freigabe in der Produktionsumgebung erfolgen kann, müssen Produktionstests für das Sicherheitslösungsprojekt durchgeführt werden. Alle Testpläne werden in der tatsächlichen Produktionsumgebung ausgeführt, und die Ergebnisse werden vor der endgültigen Migration ein letztes Mal den Hauptentscheidungsträgern zur Genehmigung vorgelegt.

Alle in der Bereitstellungsphase an der Kundenumgebung vorgenommenen Änderungen müssen in der zugehörigen Dokumentation aktualisiert werden, einschließlich Lösungserstellungsplan, Projektmasterplan, Projektzeitplan, Lösungsentwurf und Kundensupportplan.

Alle Supportverträge müssen vorliegen, ehe der Sicherheitslösungsentwurf in den täglichen Betrieb übernommen werden kann. Mit diesem Meilenstein geht die Verantwortung für die laufende Verwaltung und Unterstützung der Lösung offiziell vom Projektteam auf die Betriebs- und Supportteams über. Informationen zu den betrieblichen Aspekten einer Sicherheitslösung entnehmen Sie bitte dem Betriebshandbuch für eine geeignete Sicherheitsbewertung. Dieses dient als Grundlage für die Entwicklung von Supportprozessen für projektspezifische Anforderungen.

Betrieb

Der Abschnitt zum Lösungsbetrieb ist keine Phase der Methode für Sicherheitslösungen, sondern ein neues Projekt speziell zu den MOF-Bereichen, aus denen der Kunde den größten Gewinn für seine Investition erzielen kann. Das ursprünglich in der Erstellungsphase entwickelte Betriebshandbuch für den Kunden kommt im Betriebsprozess zum Einsatz. Der Erfolg dieses Projekts hängt davon ab, wie einfach Lösung, Anwendungsupdates und Anwendungssupport zu verwalten sind und ob der Skalierbarkeits- und Sicherheitsansatz proaktiv genug angelegt ist.

Projektergebnisse

Neben der Datensammlung für die Planung des künftigen Wachstums und der zukünftigen Kapazitäten gehören folgende wichtige Projektergebnisse zur Einführungsphase des Betriebsprozesses:

Kundenbesuchsbericht

Endgültiges Betriebshandbuch für den Kunden

Reaktionsplan für Zwischenfälle

Änderungsverwaltungsprozess

Sicherheitserkenntnisse

Checkliste zum Projektabschluss

Kundenbesuchsbericht

Dieser Bericht enthält die bei Kundenbesuchen während des Betriebsprozesses vereinbarten Ergebnisse.

Endgültiges Betriebshandbuch für den Kunden

Das endgültige Betriebshandbuch für den Kunden muss während des Betriebsprozesses ggf. geändert und abschließend fertig gestellt werden.

Reaktionsplan für Zwischenfälle

Dieser Plan regelt den Eskalationsweg und den Lösungsprozess der Sicherheitsproblemverwaltung.

Änderungsverwaltungsprozess

Der Prozess zur Änderungsverwaltung ist der Aspekt der Dienstverwaltung, der die IT-Zuverlässigkeit nachweist und damit zur Stabilisierung der IT-Systeme des Unternehmens beiträgt. Darüber hinaus fördert dieser Prozess auch ein dynamisches Geschäftswachstum mit schnellerer Einbindung von Änderungen, Expansionen und Übernahmen. Im Rahmen dieser Dienstverwaltungsfunktion erfolgt die Verwaltung und Steuerung sämtlicher Komponenten der IT-Betriebsumgebung. Dies gilt sowohl für die Anwendungsumgebung, als auch für die IT-Infrastruktur.

Checkliste zum Projektabschluss

Die Checkliste zum Projektabschluss gibt Aufschluss darüber, ob die Kriterien für das Sicherheitsprojekt erfüllt wurden. Das Management prüft die Liste der Ergebnisse und hakt die entsprechenden Punkte in dieser Checkliste ab. Anhand der Checkliste zum Projektabschluss erfolgt die Endbewertung nach Projektabschluss. Diese Aufgabenhilfe eignet sich auch für die Abzeichnung durch den Kunden.

Übersicht über die Sicherheitslösungsdienste der einzelnen Phasen

Abbildung 19 fasst die Phasen dieser Methode zusammen und bildet die Entstehung der wichtigsten Ergebnisse in den einzelnen Phasen ab.

Abbildung 19: Die wichtigsten Ergebnisse in den einzelnen Phasen der Sicherheitslösungsmethode

ÄnderungskontrollsystemUnternehmen, die noch keinen eindeutig definierten Änderungskontrollprozess eingerichtet haben, können sich am nun folgenden System orientieren. Den Unternehmen, die bereits ein eigenes Änderungskontrollsystem implementiert haben, kann dieser Abschnitt bei der Beseitigung eventueller Schwachstellen helfen. Die Ziele des Änderungskontrollprozesses lassen sich mit folgenden Aufgaben umreißen:

Prüfen aller im Projektverlauf angeforderten Änderungen.

Bestimmen der Auswirkungen sämtlicher Aufgaben auf das Projekt.

Umlegen dieser Auswirkungen auf Projektleistung, -kosten und -zeitplan.

Bewerten des Nutzens und der Kosten von angeforderten Änderungen.

Identifizieren alternativer Änderungen, die zum selben Ergebnis führen könnten.

Bewilligen oder Ablehnen von Änderungsanforderungen.

Informieren aller Beteiligten über Änderungen.

Sicherstellen, dass bewilligte Änderungen ordnungsgemäß umgesetzt werden.

Erstellen monatlicher Statusberichte, in denen alle aktuellen Änderungen zusammengefasst sind und die damit verbundenen Projektauswirkungen prognostiziert werden.

Zur Umsetzung dieser Aufgaben empfiehlt es sich, einen Änderungskontrollausschuss einzurichten. In diesem Ausschuss sollten folgende Rollen aus dem Projektteam vertreten sein:

Projektsponsor

Produktmanager

Programmmanager

Lösungsarchitekt

Leiter für Benutzererfahrung

Weitere Teammitglieder je nach Projekt

Grundlagen für den Änderungskontrollprozess

Der Änderungskontrollprozess basiert vor allem auf folgenden Daten:

Projektmasterplan: Dieser Plan stellt die Grundlage dar, auf der die Änderungen kontrolliert werden.

Berichte zur Projektleistung: Diese Berichte geben Aufschluss über die Projektleistung und können Änderungen im Umfang, Zeitplan, den Kosten, der Qualität, dem Risikoplan und der Vertragsverwaltung enthalten.

Änderungsanforderungen: Änderungsanforderungen können auf ganz unterschiedliche Weise auftreten: mündlich oder schriftlich, direkt oder indirekt, extern oder intern, spontan, gesetzlich vorgeschrieben oder optional.

Anmerkung: Zum Einreichen von Änderungsanforderungen ist in diesem Entwurfs- und Umsetzungsleitfaden eine entsprechende Vorlage verfügbar.

Richtlinien für den Änderungskontrollprozess

Ein formaler Änderungskontrollprozess sollte aufgenommen werden, sobald ein erstes vollständiges Projektergebnis vorliegt. In den meisten Fällen wird der Änderungskontrollprozess ab der Prüfungsphase der Sicherheitslösungsmethode verwendet.

Der einfach gehaltene Änderungskontrollprozess der Sicherheitslösungsmethode umfasst folgende Schritte:

1. Identifizieren von Änderungen Jedes Mitglied des Projektteams kann Änderungen identifizieren und vorschlagen.

2. Vorschlagen von Änderungen Änderungsanforderungen werden dokumentiert und dem Änderungskontrollausschuss vorgelegt.

3. Bewerten der Änderungsauswirkung Der Änderungskontrollausschuss prüft, welche Auswirkungen die Umsetzung der vorgeschlagenen Änderungen auf das Projekt hätte. Folgende Bereiche können betroffen sein:

Technologie

Budget

Zeitplan

Leistung

Vertrag

4. Prüfen und Bewilligen bzw. Ablehnen von Änderungen Der Änderungskontrollausschuss kann einen Änderungsvorschlag ablehnen, wenn die Implementierungskosten in keinem Verhältnis zum voraussichtlichen Nutzen dieser Änderung stehen. Es sollten nur Änderungsvorschläge mit einem ausgewogenen Kosten/Nutzen-Verhältnis bewilligt werden.

5. Ausführen bewilligter Änderungen

Nachdem eine Änderungsanforderung bewilligt oder abgelehnt wurde, stehen folgende Aufgaben an:

1. Das Ergebnis der Änderungsanforderung wird dokumentiert.

2. Alle Beteiligten werden über die Entscheidung und ggf. den Plan für die Änderungsimplementierung informiert.

Anmerkung: Je nach Häufigkeit und vom Änderungskontrollausschuss eingeschätzter Bedeutung der Änderungsvorschläge empfiehlt es sich, Änderungsanforderungen zu sammeln und dann mehrere Vorschläge gleichzeitig zu entscheiden.

Abbildung 20 verdeutlicht die Schritte im Änderungskontrollprozess.

Abbildung 20: Der Änderungskontrollprozess

Ergebnisse aus dem Änderungskontrollprozess

Die wichtigsten Ergebnisse aus dem Änderungskontrollprozess sind:

Projektmasterplan Dokumentaktualisierungen, ggf. einschließlich Genehmigung der Projektbeteiligten.

Korrekturmaßnahmen Aktivitäten, mit denen die voraussichtliche künftige Projektleistung auf den Projektmasterplan abgestimmt werden soll.

Erfahrungsberichte Dokumente mit den gewonnenen Erkenntnissen des Projektteams und Kunden, die dann für andere aktuelle und künftige Projekte genutzt werden können.

Zusammenfassung

In diesem Leitfaden wurden bewährte Methoden erläutert, die auf erkannten Unternehmensanforderungen für die Erstellung von Sicherheitslösungen basieren und anhand einer Reihe von Methoden auf Grundlage bewährter Vorgehensweisen für den Kunden umgesetzt werden. Der Leitfaden zeigt, wie der Sicherheitsaspekt sinnvoll in einen Infrastrukturentwurf eingeplant und der hohe Sicherheitsstandard der neuen Umgebung aufrechterhalten werden kann.

Darüber hinaus wurden die einzelnen Phasen, Rollencluster und Projektergebnisse erläutert, aus denen sich die erfolgreiche Umsetzung eines Sicherheitslösungsprojekts in einer Unternehmensumgebung zusammensetzt. Die hier vorgestellten Methoden basieren auf umfassenden Erfahrungen bei der Entwicklung von Sicherheitslösungsprojekten, auf Standards des Projektmanagements und bewährten Vorgehensweisen des MSF. Die Sicherheitslösungsmethode für diesen Entwurfs- und Umsetzungsleitfaden kann an die vorhandenen Prozesse angepasst und damit mehrfach im Rahmen von Sicherheitslösungsprojekten eingesetzt werden. Dies garantiert Ihnen schnelle und vorhersehbare Ergebnisse.

Der Leitfaden Absichern von Windows 2000 Server führt Unternehmen schrittweise durch den IT-Lebenszyklus eines Sicherheitsprojekts, von der „Einleitung“ oder „Initiierung“ bis zum „Betrieb“. Die Methode definiert eine bestimmte Vorgehensweise für Sicherheitslösungsprojekte, die sowohl das MSF als auch das MOF (Microsoft Operations Framework) als Grundlage für Sicherheitslösungen verwenden, mit denen Unternehmensumgebungen gesichert und dauerhaft sicher gehalten werden können.

© 2002 Microsoft Corporation. Alle Rechte vorbehalten.

Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.

Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.

© 2002 Microsoft Corporation. Alle Rechte vorbehalten. Active Directory, Microsoft, Windows und Windows NT sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

Weitere in diesem Dokument aufgeführte Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA 00