Sie befinden sich hier: Themen IT-Grundschutz-Kataloge. Inhalt. Dokumententitel: M 2.378 System-Entwicklung - IT-Grundschutz-Kataloge - Stand 2006
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

M 2.378 System-Entwicklung

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Leiter IT, Administrator, Benutzer

System-Entwicklung findet im Sinne dieser Maßnahme statt, wenn Hardware, Software oder ein komplexes System, das aus mehreren Software- und Hardware-Komponenten besteht, erstellt, geändert oder ergänzt werden soll.

In allen diesen Fällen muss dieses Vorhaben vor der Durchführung mit der IT-Leitung und den betroffenen Fachabteilungen abgestimmt werden. Hierfür muss eine erste Übersicht der benötigten Leistungen und Anforderungen formuliert werden. Das IT-Sicherheitsteam ist schon zu diesem frühen Zeitpunkt über das Vorhaben einer System-Entwicklung zu informieren, damit die relevanten IT-Sicherheitsaspekte schon bei der Konzeption mit berücksichtigt werden können. Neben den Leistungen, die das System erbringen soll, müssen auf jeden Fall die möglichen Auswirkungen auf die Geschäftsprozesse und auf die IT-Sicherheit in der Organisation betrachtet werden.

Die Anforderungen an die Sicherheit eines IT-Systems sollten bereits vor Beginn der Entwicklung ermittelt und abgestimmt werden. Eine nachträgliche Implementierung von Sicherheitsmaßnahmen ist bedeutend teurer und bietet im Allgemeinen weniger Schutz als Sicherheit, die von Beginn an in den Systementwicklungsprozess oder in den Auswahlprozess für ein Produkt integriert wurde. Sicherheit sollte daher integrierter Bestandteil des gesamten Lebenszyklus eines IT-Systems bzw. eines Produktes sein.

Die hier aufgeführten Empfehlungen orientieren sich am "Planung und Durchführung von IT-Vorhaben in der Bundesverwaltung" (V-Modell) sowie teilweise an den Vorgaben der "Information Technology Security Evaluation Criteria" (ITSEC) und den "Common Criteria for Information Technology Security Evaluation" (CC).

Für die Erstellung der Anforderungen ist die Maßnahme M 2.80 Erstellung eines Anforderungskatalogs für Standardsoftware zu beachten. Dort werden die wesentlichen Punkte erläutert, die zur Festlegung der funktionalen und der sicherheitsrelevanten Anforderungen berücksichtigt werden müssen,.

Der Anforderungskatalog muss mit dem IT-Sicherheitsteam abgestimmt werden. Falls sich im Laufe der System-Entwicklung Änderungen der Anforderungen ergeben, muss ebenfalls das IT-Sicherheitsteam diesen zustimmen und der Anforderungskatalog aktualisiert werden. Der Anforderungskatalog bildet die Grundlage für die Abnahme und Freigabe des Produktes.

Vorgehensmodell

Die System-Entwicklung muss nach einem durchgängigen, einheitlichen und verbindlichen Vorgehensmodell durchgeführt werden. Diese müssen die strikte Einhaltung des Vorgehensmodell sicherstellen. Das Vorgehensmodell muss sicherheitsspezifische Rollen, Aktivitäten und Ergebnisse umfassen, durch die die Angemessenheit und Umsetzung sicherheitsbezogener Systemeigenschaften kontrolliert werden können.

Vor der Freigabe müssen mindestens die in den ITSEC/CC definierten Phasen

Sicherheitsrelevante Phasenergebnisse der Anforderungsdefinition

In der Anforderungsdefinitionsphase müssen die Bedrohungen, Schwachstellen und Risiken für die IT-Sicherheit der jeweiligen Anwendung, die Sicherheitsaspekte der Einsatzumgebung, die externen Vorgaben und das Projektumfeld untersucht werden. Im Rahmen einer Schutzbedarfsfeststellung wird daraus der Sicherheitsbedarf abgeleitet, der zur Formulierung von Sicherheitsanforderungen führt. Die Sicherheitsanforderungen müssen auf Konsistenz und Vollständigkeit geprüft werden (siehe auch M 2.80 Erstellung eines Anforderungskatalogs für Standardsoftware).

Sicherheitsrelevante Phasenergebnisse des Architektur-Entwurfs

In der Architektur-Entwurfsphase müssen die internen Kontrollen für die Anwendung, die Grundfunktionen der Informationssicherheit und die organisatorischen und technischen Sicherheitsmaßnahmen auf fachlicher Ebene spezifiziert werden.

Es muss geprüft werden, dass die Sicherheitsanforderungen durch die Spezifikationen des Architektur-Entwurfs konsistent und ausreichend detailliert dargestellt werden. Hierbei sollte eine klare logische Trennung zwischen Sicherheitskomponenten und anderen Komponenten vorgenommen werden.

Sicherheitsrelevante Phasenergebnisse des Fein-Entwurfs

In der Phase des Fein-Entwurfs müssen die Sicherheits-Spezifikationen des Fach-Entwurfs so weit verfeinert werden, dass sie als Basis für die Realisierung dienen können, ohne dass ein weiterer Interpretationsbedarf besteht. Alle Module, in denen Kontrollfunktionen durchgeführt werden, sicherheitsempfindliche Verarbeitungs- und Kommunikationsabläufe erfolgen und auf sensitive Daten zugegriffen wird oder von denen sensitive Daten übertragen werden, müssen identifiziert werden.

Es muss geprüft werden, ob der Fach-Entwurf durch den Fein-Entwurf konsistent verfeinert wird. Die für die Gewährleistung der Sicherheitsanforderungen notwendigen internen Kontrollen müssen durch die Definition von Programm-Schnittstellen (API, Application Program Interfaces) spezifiziert werden. Für eine bessere Handhabung sollten die Sicherheits-APIs klar strukturiert und von den übrigen Modulen getrennt sein.

Sicherheitsrelevante Phasenergebnisse der Realisierung

In der Realisierungsphase müssen die spezifizierten Sicherheitsanforderungen durch Nutzung der entsprechenden Sicherheits-APIs adäquat umgesetzt werden. Es muss geprüft und getestet werden, ob die Implementation ihrer Spezifikation, insbesondere der Sicherheitsspezifikation genügt.

Mindestanforderungen an die Entwicklungsumgebung

Eine integrierte Entwicklungsumgebung (Integrated Development Environment, IDE) ist ein Anwendungsprogramm zur Entwicklung von Software. Die integrierte Entwicklungsumgebung erleichtert das Entwickeln von IT-Systemen, da alle wesentlichen Bestandteile wie zum Beispiel der Compiler, Debugger oder der Editor zu einer Einheit zusammengefasst sind.

Es muss eine einheitliche und verbindliche Bibliotheksstruktur für die gesamte Entwicklung zugrunde gelegt werden. Namenskonventionen müssen sowohl für den Programmcode als auch für die Benennung von Modulen definiert und vorgeschrieben werden. Ziel ist dabei, wichtige Informationen wie z. B. Entwicklungsstadium und -ort, Dokumentationstyp etc. durch geeignete Bezeichnung hervorzuheben.

Es sind Methoden, Werkzeuge und Rollen zu definieren und einzusetzen, die es erlauben,

Es muss möglich sein, geprüfte und abgenommene Entwicklungsergebnisse festzuschreiben, so dass sie als Basis für die weitere Entwicklung dienen können. Insbesondere muss es möglich sein, an definierten Punkten des Vorgehensmodells die Entwicklung an unterschiedliche Entwicklungseinheiten zur Weiterführung zu vergeben.

Die eingesetzten Entwicklungswerkzeuge müssen es unterstützen, dass alle aufgrund von Modifikationen oder aufgrund von negativen Testergebnissen nötigen Änderungen nachgehalten, durchgeführt und qualitätsgesichert werden.

Auch die physische Umgebung, in der die System-Entwicklung stattfinden soll, muss bei der frühen Planung anhand der Sicherheitsanforderungen festgelegt werden. Dazu gehören unter anderem auch die Anforderungen an Zutritts- und Zugangskontrollmechanismen.

Qualitätssicherung (QS)

Die Qualitätssicherung muss bei Beginn der Entwicklung geplant werden. Dabei müssen geeignete Maßnahmen zur Einhaltung der Sicherheitsanforderungen festgelegt und in konstruktiver und analytischer Weise im Entwicklungsprozess verankert sein.

Neben der Kontrolle, ob das System die Funktionalitäten gemäß Spezifikation und Anforderungskatalog erfüllt, muss auch das Verhalten des Systems im Fehler- oder Missbrauchsfall überprüft werden.

Es muss QS-Maßnahmen zu definierten Reviewterminen, mindestens am Ende jeder Entwicklungsphase, geben. Darüber hinaus können im Bedarfsfall zusätzlich interne Reviews einberufen werden.

Während der Anforderungsdefinition und der Entwurfsphasen sind Testspezifikationen und Testfälle zu entwerfen und zu dokumentieren, die zur Prüfung der System-Qualität und der Einhaltung der Sicherheitsanforderungen geeignet sind. Während der Realisierungsphase und bei der Abnahme müssen entsprechende Tests durchgeführt werden.

Die Durchführung der Tests ist zu dokumentieren. Automatische Wiederholbarkeit und automatischer Abgleich der Testergebnisse (Regressionstest) sind anzustreben. Praxisdaten als Testdaten sind grundsätzlich nur in anonymisierter Form zulässig (siehe auch M 2.82 Entwicklung eines Testplans für Standardsoftware bzw. M 2.83 Testen von Standardsoftware).

Überführung in Produktion und Software-Wartung

Es muss einheitliche Richtlinien für die Überführung in die Produktion und für die System-Wartung geben.

Überführung in die Produktion

Die strikte Trennung von Entwicklung und Produktion, speziell der Verarbeitung von Testdaten und Echtdaten, muss gewährleistet werden. Es muss ein klar definiertes Freigabeverfahren für entwickelte Systeme und Anwendungen geben. Erst nach der Freigabe darf der Transfer aus der Test- in die Produktionsumgebung erfolgen. Sämtliche Programmteile, die lediglich Testzwecken dienen, sind vor der Freigabe zu entfernen. Mindestvoraussetzung für eine Freigabe ist das vollständige und erfolgreiche Durchlaufen einer Abnahme mit umfangreichen Tests in der Zielumgebung am Ende des Entwicklungsprozesses. Im Rahmen der Abnahme muss insbesondere festgestellt werden, ob sich die IT-Systeme und IT-Anwendungen in der Zielumgebung gemäß den Sicherheitsanforderungen verhalten.

Es muss sichergestellt sein, dass nur ordnungsgemäß freigegebene Programme bzw. Module zum Einsatz kommen (siehe auch M 2.85 Freigabe von Standardsoftware).

Wartung und Problemmanagement

Jegliche unautorisierte Veränderung eingesetzter IT-Systeme muss verhindert werden. Autorisierte Modifikationen müssen durch ein geeignetes Änderungs- und Konfigurationsmanagement nachvollziehbar sein. Im Rahmen des Änderungs- und Konfigurationsmanagements müssen auch Aufbewahrungsfristen für alle System-Komponenten definiert werden.

Auch nicht mehr im Einsatz befindliche Systemkomponenten, wie Programm-oder Modulversionen, Konfigurationsdaten und deren Dokumentation müssen für die Dauer der Aufbewahrungsfrist nachvollziehbar bleiben. Es muss ein klar definiertes Verfahren und eindeutig festgelegte Kompetenzen für die Rückmeldung von Systemproblemen an die zuständige Instanz geben.

Jede autorisierte Modifikation im System aufgrund festgestellter Mängel oder zur Erweiterung der Funktionalität muss gemäß dem gewählten Vorgehensmodell in der einheitlichen Entwicklungsumgebung mit einer kontrollierten Wieder-Überführung in die Produktion erfolgen. Es muss zusätzlich ein klar definiertes Verfahren für den Umgang mit Notfällen geben.

Software-Entwicklung durch Endbenutzer

Standardsoftware ermöglicht oft den Endbenutzern die Entwicklung und Nutzung von eigenen Programmen, um Routinetätigkeiten zu erleichtern (z. B. über Makroprogrammierung). Der unkontrollierte Einsatz solcher selbstentwickelter Programme kann allerdings ein Sicherheitsrisiko darstellen. Daher sollte in jeder Organisation die Grundsatz-Entscheidung getroffen werden, ob solche Eigenentwicklungen erwünscht sind oder nicht und wer diese erstellen darf (siehe M 2.379 Software-Entwicklung durch Endbenutzer). Eigenentwicklungen müssen ebenfalls getestet und freigegeben werden, bevor sie in der Produktivumgebung eingesetzt werden dürfen. Ebenso muss geklärt werden, wer diese Programme wartet und Probleme damit behebt. Die Regelungen für den Einsatz von selbstentwickelten Programmen sollte in einer Sicherheitsrichtlinie festgehalten werden.

Ergänzende Kontrollfragen: