Bundesamt für Sicherheit in der Informationstechnik

M 2.378 System-Entwicklung

Verantwortlich für Initiierung: Leiter IT

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

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 Sicherheitsmanagement ist schon zu diesem frühen Zeitpunkt über das Vorhaben einer System-Entwicklung zu informieren, damit die relevanten 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 Informationssicherheit 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 Sicherheitsmanagement abgestimmt werden. Falls sich im Laufe der System-Entwicklung Änderungen der Anforderungen ergeben, muss ebenfalls das Sicherheitsmanagement 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

  • Anforderungsdefinition,
  • Architektur- oder Fach-Entwurf,
  • Fein-Entwurf und
  • Realisierung durchlaufen werden.

Sicherheitsrelevante Phasenergebnisse der Anforderungsdefinition

In der Anforderungsdefinitionsphase müssen die Bedrohungen, Schwachstellen und Risiken für die Informationssicherheit 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,

  • Systeme (Hard- und Software) sowie deren Bestandteile und Eigenschaften festzulegen und zu identifizieren,
  • die systematische und kontrollierte Bearbeitung der notwendigen Änderungen und Verbesserungen zu steuern,
  • unbeabsichtigte, unkontrollierte oder ungesteuerte Veränderungen zu verhindern,
  • alle Zwischen- und Endergebnisse zu archivieren und zu verwalten,
  • Entwicklungen dezentral, d. h. in verschiedenen Entwicklungseinheiten nach einem einheitlichen (Sicherheits-)Standard durchzuführen,
  • alle Benutzer der Entwicklungswerkzeuge und der Entwicklungsdatenbank eindeutig zu identifizieren,
  • den Zugriff von Benutzern der Entwicklungswerkzeuge auf die Entwicklungsdatenbank in Abhängigkeit von der Benutzerrolle (need-to-know) zu kontrollieren,
  • die Integrität der Entwicklungsdaten zu gewährleisten,
  • Modifikationen der Entwicklungsdaten feststellen und zu Personen zuordnen zu können.

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.

Prüffragen:

  • Ist ein Prozess vorhanden, der sicherstellt, dass relevante Aspekte der Informationssicherheits schon bei der Konzeption einer System-Entwicklung berücksichtigt werden?

  • Existiert ein Vorgehensmodell zur Systementwicklung, welches sicherheitsspezifische Rollen, Aktivitäten und Ergebnisse berücksichtigt?

  • Werden bei der System-Entwicklung die Risiken für die Anwendung und die Einsatzumgebung idenfiziert und berücksichtigt?

  • Werden entwickelte Komponenten einem sicherheitstechnischem Test nach der Sicherheitsspezifikation unterzogen?

  • Sind die Anforderungen an die Entwicklungsumgebung definiert?

  • Sind für die System-Entwicklung angemessene Qualitätssicherungsmaßnahmen definiert?

  • Existieren für die System-Entwicklung Richtlinien zur Überführung von Anwendungen in die Produktion und zur Wartung?

  • Ist die Trennung von Test- und Echtdaten gewährleistet?

  • Sind Aufbewahrungsfristen für alle System-Komponenten definiert?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK