Band B, Kapitel 9: Software

Transkript

1 Band B, Kapitel 9: Software

2 Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Tel.: Internet: Bundesamt für Sicherheit in der Informationstechnik 2013

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Definitionen Software-Modul Verfügbarkeit Untersuchungsbereich Einflüsse auf die Software-Verfügbarkeit Systemstruktur Betriebssystemkern Hardwarenahe Module, Treiber Systembibliotheken, Standardmodule Anwendungsspezifische Module (Standard- und Individual-Software) Klassifizierung von Fehlertypen Berechnungsfehler (fehlerhafte Algorithmen) Logische Fehler Datenfehler Schnittstellenfehler Ein-/Ausgabefehler Performancefehler Fehlerquellen im Entwicklungsprozess Fehler bei der Anforderungsdefinition Fehler beim Softwaredesign Fehler in der Implementierungsphase Fehler in der Testphase Fehler in der Software-Dokumentation Fehlerquellen beim Softwarebetrieb Installations-/Auslieferungsphase Eingabedaten Software-Konfiguration Benutzerkenntnisse Außerplanmäßige Systemlast Maßnahmen zur Sicherung hoher Verfügbarkeit Maßnahmen in der Entwicklungsphase Bewertung von Entwicklungsprozessen Qualitätsbewertung nach DIN ISO Maßnahmen bei der Anforderungsdefinition Maßnahmen beim Softwaredesign Maßnahmen bei der Implementierung Maßnahmen in der Testphase Fehlerprävention Fehlervorhersage Maßnahmen in der Betriebsphase Maßnahmen zur Überwachung von Software-Komponenten Maßnahmen zur Vorbeugung von Systemausfällen Maßnahmen zur Behebung von Systemausfällen Weitere Maßnahmen Software-Review...35 Anhang: Verzeichnisse...36 Bundesamt für Sicherheit in der Informationstechnik 3

4 Inhaltsverzeichnis Abkürzungsverzeichnis...36 Glossar...36 Literaturverzeichnis...36 Abbildungsverzeichnis Abbildung 1: Software-Module im Schalenmodell...7 Abbildung 2: Entwurfsmuster-Fassade...22 Abbildung 3: Testprozess nach dem V-Modell...28 Abbildung 4: Trennung einzelner Anwendungen durch virtuelle Umgebungen...32 Tabellenverzeichnis Tabelle 1: Fehler bei der Anforderungsdefinition...10 Tabelle 2: Fehler beim Softwaredesign...11 Tabelle 3: Fehler in der Implementierungsphase...12 Tabelle 4: Fehler in der Testphase...13 Tabelle 5: Fehler in der Software-Dokumentation Bundesamt für Sicherheit in der Informationstechnik

5 HV-Kompendium V 1.6 Band B, Kapitel 9: Software 1 Einleitung Der stark wachsende Umfang an Anwendungs- und System-Software und die zunehmende Zahl von Abhängigkeiten (zu anderen Programmen und Hardware-Varianten) tragen dazu bei, dass Software- Fehler die zunehmend dominierende Ausfallursache für Systemausfälle sind. Daher kommt der Verfügbarkeit von Software beim Entwurf hochverfügbarer IT-Systeme eine besondere Bedeutung zu. Das vorliegende Dokument beschreibt Verfahren und Methoden für die Entwicklung und den Betrieb von Software im HV-Umfeld. Da die Verfügbarkeit von Software zu einem großen Teil von Fehlern und deren Auswirkungen innerhalb der Programmmodule abhängt, widmet sich dieser Beitrag im Abschnitt 2 der Untersuchung von Fehlerarten und -ursachen. Die Kenntnis der möglichen Fehlerursachen ermöglicht eine systematische Aufstellung von Gegenmaßnahmen. Fehlervermeidung im Software-Bereich heißt insbesondere geeignete Techniken bei der Software- Entwicklung einzusetzen, da hier die Einflussmöglichkeiten typischerweise am größten sind. Die Verfahren zur Realisierung hoher Verfügbarkeit werden im Abschnitt 3 vorgestellt. 1.1 Definitionen In den nachfolgenden Abschnitten werden einige Begriffe eingeführt, die sich aus der Einbettung des vorliegenden Beitrags in die Gesamtstruktur des HV-Kompendiums (und hier insbesondere den methodischen Teil) ergeben Software-Modul In diesem Beitrag wird der Begriff Software-Modul als Bezeichnung für eine einzelne Software- Komponente verwendet. Ein solches Software-Modul kann aus der Sicht der Modellierung einer HV-Architektur nicht in weitere Einzelbestandteile untergliedert werden. Im Sinne der HV- Methodik stellt das Software-Modul (wie z. B. Kernel-Modulen oder auch Standard-Bibliotheken) ein HV-Objekt dar, welches zur Modellierung einer Gesamtarchitektur eingesetzt und auch im Hinblick auf seine Verfügbarkeit bewertet werden kann. Im betrachteten Kontext stellt eine Anwendung die Kombination eines oder mehrerer Software- Module dar, die während des Betriebs dem Anwender eine oder mehrere Funktionen zur Verfügung stellt. Als HV-Objekt stellt diese Anwendung den Geschäftsprozessen eine IT-Dienstleistung auf der Applikationsschicht zur Verfügung. Die Verfügbarkeit der Anwendung wird dabei durch die Verfügbarkeit der zugrunde liegenden Software-Module sowie weiterer HV-Objekte, von denen sie abhängt, beeinflusst Verfügbarkeit Die allgemeine Definition zur Verfügbarkeit soll hier zunächst für den Bereich Software konkretisiert werden. Die Verfügbarkeit eines Software-Moduls lässt sich als die Wahrscheinlichkeit definieren, dass ein Software-Modul, bzw. eine Anwendung zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen ist, d. h., es ist jene Zeit, die eine Anwendung nutzbar ist. Bundesamt für Sicherheit in der Informationstechnik 5

6 Band B, Kapitel 9: Software HV-Kompendium V Untersuchungsbereich Da innerhalb einer komplexen IT-Infrastruktur eine Vielzahl unterschiedlicher Software-Module verwendet wird, muss zur Untersuchung der unterschiedlichen Auswirkungen von Software-Fehlern auf die Verfügbarkeit zunächst die genaue Struktur des Untersuchungsbereichs festgelegt werden. Zur Beschränkung des Umfangs dieser Untersuchung wird hier auf die Analyse konkreter Implementierungen verzichtet. Stattdessen wird eine allgemeine Betrachtung durchgeführt, die sich auf die unterschiedlichen Systeme abbilden lässt. Bei der Beurteilung der Verfügbarkeit von Software-Modulen und bei den Maßnahmen zur Sicherung hoher Verfügbarkeit muss grundsätzlich zwischen den Phasen Entwicklung und Betrieb unterschieden werden. Der Großteil der in diesem Dokument beschriebenen Maßnahmen bezieht sich auf die Entwicklungsphase, da hier die Einflussmöglichkeiten naturgemäß am Größten sind. Allerdings ist die Betrachtung und Verbesserung der Verfügbarkeit während des Betriebs von mindestens ebenso hoher Bedeutung, da sich die verwendete IT-Infrastruktur in der Regel zu einem hohen Anteil aus bestehenden (Alt-) Anwendungen zusammensetzt, die nicht ohne Weiteres durch Neuentwicklungen ersetzt werden können. Dementsprechend werden auch für die Betriebsphase Kriterien zur Bewertung der Verfügbarkeit und Maßnahmen zur Verbesserung der Verfügbarkeit definiert. Für eine hohe Verfügbarkeit ist ein hohes Qualitätsniveau der einzelnen Module erforderlich. In diesem Dokument wird bewusst auf die Beschreibung allgemeiner Maßnahmen zur Qualitätssicherung verzichtet, da dies den Rahmen dieser Publikation sprengen würde. Es werden daher nur Maßnahmen und Kriterien aufgeführt, die eine direkte Relevanz im Hinblick auf die Verfügbarkeit haben. 6 Bundesamt für Sicherheit in der Informationstechnik

7 HV-Kompendium V 1.6 Band B, Kapitel 9: Software 2 Einflüsse auf die Software-Verfügbarkeit Die im Kapitel definierte Verfügbarkeit wird durch eine Vielzahl von Faktoren beeinflusst. Hauptsächlich wird die Verfügbarkeit durch die Menge der Softwarefehler, die in der Entwicklungsphase entstanden sind, negativ beeinflusst. Darüber hinaus gibt es aber auch Faktoren, die im Betrieb der Software die Verfügbarkeit beeinflussen. Zu diesen Faktoren zählt z. B. die Software-Konfiguration, die Qualität der Eingabedaten, aber auch weichere Faktoren, wie die Anwendungsdokumentation und der Kenntnisstand der Anwender. In diesem Kapitel werden die einzelnen Faktoren dokumentiert. Aus diesen Faktoren werden dann im Folgenden die möglichen Maßnahmen zur Verbesserung der Verfügbarkeit abgeleitet. 2.1 Systemstruktur Gängige IT-Systeme besitzen im Allgemeinen eine vergleichbare Systemarchitektur, nach der sich die einzelnen Software-Module klassifizieren lassen. Abbildung 1: Software-Module im Schalenmodell In der Regel kann man davon ausgehen, dass der Einfluss der jeweiligen Module auf die Verfügbarkeit des Gesamtsystems zunimmt, je zentraler das Modul in der Systemstruktur angesiedelt ist. Bundesamt für Sicherheit in der Informationstechnik 7

8 Band B, Kapitel 9: Software HV-Kompendium V Betriebssystemkern Der Betriebssystemkern bildet das Zentrum der Softwarearchitektur. Er enthält mindestens die Funktionen zur Speicher- und Prozessverwaltung (Mikrokernel) und ggf. auch Treiber für Hardware-Komponenten und weitere systemnahe Funktionen (monolithischer oder hybrider Kernel). Der Betriebssystemkern stellt i. d. R. eine Standardkomponente dar, die nicht individuell für ein IT- System konzipiert und entwickelt wird. Die Maßnahmen zur Sicherung der Verfügbarkeit beziehen sich daher im Wesentlichen auf die Beurteilung der Kompatibilität des Betriebssystemkerns zu anderen individuellen Komponenten Hardwarenahe Module, Treiber Sofern nicht bereits im Betriebssystemkern enthalten, bilden diese Module die Schnittstelle zur Systemhardware und ermöglichen den höher liegenden Schichten die Nutzung der Hardwarefunktionen. Hierzu zählen auch Module, die z. B. zur Steuerung technischer Anlagen genutzt werden. Die hier genannten Module werden häufig durch den Hersteller der zugehörigen Hardware-Module bereitgestellt. Die Verfügbarkeit dieser Softwaremodule hat prinzipbedingt unmittelbare Auswirkungen auf die entsprechenden Hardwaremodule, sodass diesen Modulen bei der Betrachtung der Verfügbarkeit des Gesamtsystems eine besondere Bedeutung zukommt Systembibliotheken, Standardmodule Anwendungen basieren aus Kosten- und Effizienzgründen zu einem großen Teil auf Standard- Bibliotheken, die von mehreren Anwendungen genutzt werden. Außerdem stellen die gängigen Betriebssysteme Bibliotheken, wie z. B. die Standard C++ -Bibliothek (stdc++), mit Standardfunktionen zur Verfügung. Diese Module werden i. d. R. nicht vom Hersteller der Anwendungs-Software, sondern vom Betriebssystemhersteller oder Drittanbietern geliefert. Die Verfügbarkeit dieser Komponenten wirkt sich auf unterschiedliche Anwendungen aus, so haben z. B. Fehler in der Standard C++ -Bibliothek einen Einfluss auf alle C++ -basierten Software- Module und Anwendungen. Verfügbarkeit hängt also von der Härte (Etablierung) der verwendeten Programmiersprache ab Anwendungsspezifische Module (Standard- und Individual-Software) Innerhalb dieser Modulebene werden fachspezifischen Funktionen einer Anwendung realisiert. Im Gegensatz zu den Standard-Bibliotheken können bei der Konzeption dieser Module die spezifischen Verfügbarkeitsanforderungen besser berücksichtigt werden. Anwendungsspezifische Module können innerhalb eines Einsatzgebietes ggf. durch unterschiedliche Anwendungen oder unter unterschiedlichen Betriebsbedingungen eingesetzt werden. 8 Bundesamt für Sicherheit in der Informationstechnik

9 HV-Kompendium V 1.6 Band B, Kapitel 9: Software 2.2 Klassifizierung von Fehlertypen Softwarefehler sind im Allgemeinen durch zwei mögliche Auswirkungen gekennzeichnet. Die Anwendung liefert ein fehlerhaftes Ergebnis und / oder das Ergebnis steht nicht innerhalb der erforderlichen Zeit zur Verfügung. Auf Basis dieser grundsätzlichen Auswirkungen werden in den folgenden Abschnitten Fehlertypen unterschieden Berechnungsfehler (fehlerhafte Algorithmen) Der Algorithmus zur Bearbeitung der Daten liefert für einen oder mehrere Ausgangsdaten nicht das erwartete Ergebnis. Gründe hierfür können grundsätzliche Fehler innerhalb des Algorithmus oder Fehler bei dessen Umsetzung sein Logische Fehler Ein logischer Fehler liegt dann vor, wenn ein bestimmter Anwendungsfall in der Ablauflogik des Programms nicht berücksichtigt oder fehlerhaft umgesetzt wurde Datenfehler Datenfehler treten immer dann auf, wenn das Format der vorliegenden Daten nicht korrekt durch die Anwendung abgearbeitet werden kann. Dies schließt auch die Behandlung fehlerhafter Daten ein Schnittstellenfehler Schnittstellenfehler verursachen eine unkorrekte Kommunikation zwischen Modulen oder Systemen. Hierin enthalten sind Fehler, bei denen Daten in nicht erwarteter Form an andere Komponenten weitergegeben werden, aber auch die nicht korrekte Behandlung empfangener Daten Ein-/Ausgabefehler Ein-/Ausgabefehler treten bei dem Lesen oder Schreiben externer Daten auf Performancefehler Performancefehler führen zu Laufzeiten, welche im Produktivbetrieb nicht tolerierbar sind. Das bedeutet, die zu liefernden Ergebnisse werden nicht innerhalb der geforderten Zeit vom System bereitgestellt. Je nach Anwendungstyp hat dies zur Folge, dass die verzögerten Daten nicht mehr genutzt werden können, wie beispielsweise bei Echtzeitsystemen oder die zu verarbeitenden Lasten nicht bewältigt werden können und somit zu Produktivitätseinbußen führen. Bundesamt für Sicherheit in der Informationstechnik 9

10 Band B, Kapitel 9: Software HV-Kompendium V Fehlerquellen im Entwicklungsprozess Den größten Einfluss auf die Verfügbarkeit von Software haben Fehler innerhalb der beteiligten Software-Module. Die Ursachen für diese Fehler liegen i. d. R. in der Entwicklungsphase der Software. Der typische Softwareentwicklungsprozess kann in fünf Phasen gegliedert werden: Anforderungsdefinition, Design, Implementierung, Test und Dokumentation. Im Folgenden werden die Fehlerarten und deren Auswirkungen auf die Verfügbarkeit für die einzelnen Phasen beschrieben Fehler bei der Anforderungsdefinition Zu Beginn des Entwicklungsprozesses werden die Anforderungen an ein Software-Modul erfasst. Hier werden bereits die Grundlagen für die spätere Verfügbarkeit der Anwendung gelegt. Fehler Fehlertyp Beschreibung Logische Fehler Fehlende Anforderungen Falsche Abschätzung der maximalen Last Fehlende Definition von Schnittstellen zu anderen Systemen Performance Schnittstellenfe hler, Ein/Ausgabefe hler Tabelle 1: Fehler bei der Anforderungsdefinition Werden nicht alle Anforderungen erfasst, so ist die Verfügbarkeit der Anwendung hinsichtlich dieser Anforderungen ggf. eingeschränkt. Wird die maximal zu erwartende Last falsch berechnet, so wird die Verfügbarkeit der Anwendung durch Performancefehler beeinflusst. Werden Schnittstellen zu anderen Software-Modulen nicht berücksichtigt, so kann die unkorrekte Kommunikation die Verfügbarkeit der Anwendung beeinträchtigen Fehler beim Softwaredesign Innerhalb der Designphase entstehen die meisten schwerwiegenden Fehler, die im Betrieb einer Anwendung die Verfügbarkeit beeinflussen. Da diese später nur mit großem Aufwand zu korrigieren sind, erfordert diese Phase besondere Maßnahmen zur Sicherung der Verfügbarkeit. 10 Bundesamt für Sicherheit in der Informationstechnik

11 HV-Kompendium V 1.6 Band B, Kapitel 9: Software Fehler Fehlertyp Beschreibung Logische Fehler Unberücksichtigte Anforderungen Nicht adäquate Entwurfsmuster zur Lösung der Probleme Tabelle 2: Fehler beim Softwaredesign Logische Fehler, Performance Werden nicht alle Anforderungen im Softwaredesign berücksichtigt, so ist die Verfügbarkeit der Anwendung hinsichtlich dieser Anforderungen ggf. eingeschränkt. Nicht geeignete Entwurfsmuster erhöhen die Komplexität des Software-Moduls führen so zu einer eingeschränkten Verfügbarkeit, z. B. hinsichtlich der Gesamtperformance. Sie erhöhen zudem das Risiko von logischen Fehlern bei der Implementierung des Moduls Fehler in der Implementierungsphase Die Fehler in der Implementierungsphase sind durch handwerkliche Fehler bei der Umsetzung des Designs gekennzeichnet, also fehlende oder unzureichende Überprüfung von Parametern und Fehlerzuständen. Viele Angriffsszenarien beruhen darauf, dass einer Anwendung über öffentliche Schnittstellen speziell codierte Daten zugeführt werden. Durch die fehlerhafte Behandlung dieser Daten werden dann unerwünschte Reaktionen der Anwendung verursacht, die z. B. im Falle eines Denial Of Service -Angriffs auch direkte Auswirkungen auf die Verfügbarkeit haben. Bundesamt für Sicherheit in der Informationstechnik 11

12 Band B, Kapitel 9: Software HV-Kompendium V 1.6 Fehler Fehlertyp Beschreibung Buffer Overflow Datenfehler, Schnittstellenfehler Werden einem Modul über eine Schnittstelle mehr Daten als erwartet übergeben, so kann es zu einem sogenannten Buffer Overflow kommen. Wenn das Modul nicht die Länge der übermittelten Daten prüft, werden die Daten über den vorgesehenen Bereich hinaus geschrieben und somit die Speicherstruktur (Heap oder Stack) zerstört. Durch geeignete Codierung der Daten kann zudem der Stack gezielt manipuliert werden, sodass die Relative Pfade SQL-Injection Datenfehler, Schnittstellenfehler Datenfehler, Schnittstellenfehler Ausführung schadhaften Codes möglich ist. An Stellen, an denen Pfade an ein Modul übergeben werden (Pfade in der lokalen Dateistruktur, aber auch URLs), können mittels relativer Pfadangaben Orte außerhalb des ursprünglichen Anwendungsbereichs adressiert werden. Dies ist vor allem dann kritisch, wenn die entsprechende Anwendung über weitergehende Zugriffrechte verfügt als der Benutzer. Verwendet ein Modul die eingehenden Daten für einen Zugriff auf eine Datenbank, so können über geeignete SQL-Befehle innerhalb der Daten zusätzliche Datenbankanweisungen ausgelöst werden. Dekodierungsfehler Datenfehler Fehlerhaft codierte Eingabedaten können innerhalb des Moduls zu inkonsistenten Zuständen führen und so die Verfügbarkeit beeinflussen. Tabelle 3: Fehler in der Implementierungsphase Fehler in der Testphase In der Testphase besteht die größte Herausforderung in der ausreichenden Testabdeckung, d. h., dass alle relevanten Elemente der Anwendung getestet werden. 12 Bundesamt für Sicherheit in der Informationstechnik

13 HV-Kompendium V 1.6 Band B, Kapitel 9: Software Ungetestete Funktionen Ungetestete Ablaufpfade Fehler Fehlertyp Beschreibung Berechnungsfehler, logische Fehler Ungetestete Austrittspunkte Tabelle 4: Fehler in der Testphase Logische Fehler Logische Fehler Werden nicht alle Funktionen eines Moduls in der Testphase überprüft, ist die Verfügbarkeit im Betrieb der Anwendung hinsichtlich dieser Funktionen eingeschränkt. Berücksichtigen die Tests nicht alle möglichen Pfade, die beim Ablauf der Funktion durchlaufen werden können, so können entsprechende Anwendungsfälle zu einer Beeinträchtigung der Verfügbarkeit führen. In der Testphase müssen auch alle möglichen Fehlermeldungen und Ausnahmen berücksichtigt werden, die zur Beendigung einer Funktion führen können. Wird die Behandlung dieser Ausnahmen nicht getestet, so können Fehlersituationen im Betrieb die Verfügbarkeit des Software-Moduls beeinflussen Fehler in der Software-Dokumentation Die Software-Dokumentation ist ein Faktor, der zunächst keinen unmittelbaren Einfluss auf die Verfügbarkeit einer Anwendung hat. Jedoch kann bei Anwendungsfällen, in denen der Benutzer die erforderlichen Bearbeitungsschritte nicht aus den bestehenden Kenntnissen und Erfahrungen ableiten kann, die Qualität der Dokumentation Auswirkungen auf die Qualität der Ergebnisse und die erforderliche Zeit zur Bearbeitung der Anforderung haben. Des Weiteren erschwert eine unzureichende Dokumentation die Wartung und Pflege des Produktes und führt somit zu verlängerten Wartungsphasen. In dieser Hinsicht sollte auch die Qualität und Vollständigkeit der Anwendungsdokumentation mit in die Beurteilung der Verfügbarkeit einfließen. Bundesamt für Sicherheit in der Informationstechnik 13

14 Band B, Kapitel 9: Software HV-Kompendium V 1.6 Fehler Fehlertyp Beschreibung Schnittstellenfehler, Performancefehler Undokumentierte Funktionen Undokumentierte Datenformate Undokumentierte Fehlercodes Datenfehler, Schnittstellenfehler Logische Fehler Tabelle 5: Fehler in der Software-Dokumentation 2.4 Fehlerquellen beim Softwarebetrieb Werden nicht alle Funktionen eines Moduls in der Dokumentation beschrieben, kann die Verfügbarkeit im Betrieb der Anwendung hinsichtlich dieser Funktionen eingeschränkt sein. Ist das Format der bereitzustellenden Eingabedaten nicht vollständig dokumentiert, so können qualitativ minderwertige Daten die Verfügbarkeit der Anwendung im Betrieb beeinträchtigen. Zur Behandlung von Fehlersituationen müssen dem Benutzer detaillierte Informationen zur Beurteilung und Analyse der Fehlerursache zur Verfügung stehen. Sind die möglichen Fehlercodes und meldungen nicht dokumentiert, so beeinflusst die ggf. die Verfügbarkeit des Software-Moduls während des Betriebs Installations-/Auslieferungsphase Die Verfügbarkeit des Gesamtsystems hängt nicht zuletzt von der korrekten Installation und initialen Konfiguration der Anwendung ab. Hier ist es z. B. wichtig, dass nur die tatsächlich benötigten Funktionen installiert werden, um die Wahrscheinlichkeit von Angriffpunkten oder fehlerhaften Modulen zu minimieren. Auf Betriebssystemebene kann mit einer sogenannten Härtung des System erreicht werden, dass nur benötigte Bibliotheken und Treiber vorhanden sind Eingabedaten Die Qualität der Daten, die dem System zugeführt werden, kann die Verfügbarkeit entscheidend beeinflussen. Treten bei der Bearbeitung der Daten eine Vielzahl von Fehlern auf, so kann dies die Bearbeitungszeit verlängern, auch wenn fehlerhafte Eingabedaten durch die Anwendung korrekt behandelt werden. Des Weiteren sei hier auf die gezielte Einflussnahme auf das Systemverhalten unter Verwendung von Techniken wie z. B. Buffer Overflow, Cross Site Scripting in Web- Applikationen oder SQL-Injection hingewiesen, welche die Beeinträchtigung der Systemintegrität und der Verfügbarkeit zur Folge haben können. Buffer Overflow Fehler können z. B. innerhalb eines Denial Of Service -Angriffs zum Absturz des Systems führen und somit die Verfügbarkeit erheblich reduzieren. Organisatorische oder technische Maßnahmen zur Sicherung der Datenqualität können hier die Verfügbarkeit des Systems steigern. 14 Bundesamt für Sicherheit in der Informationstechnik

15 HV-Kompendium V 1.6 Band B, Kapitel 9: Software Software-Konfiguration Eine fehlerhafte Konfiguration kann die Verfügbarkeit einiger oder aller Funktionen des Systems gefährden. Komplexe Systemkonfigurationen erhöhen das Risiko von Fehlern bei Änderungen der Einstellungen Benutzerkenntnisse Fehlende Benutzerkenntnisse erhöhen das Risiko eines Systemausfalls durch Fehlbedienung Außerplanmäßige Systemlast Innerhalb der Anforderungsdefinition für ein Software-Modul wird die maximal zu erwartende Last festgelegt. Tritt während des Betriebs eine darüber hinaus gehende Last auf, so kann es zu einer eingeschränkten Verfügbarkeit durch Überlast und unvorhergesehene Betriebszustände führen. Bundesamt für Sicherheit in der Informationstechnik 15

16 Band B, Kapitel 9: Software HV-Kompendium V Maßnahmen zur Sicherung hoher Verfügbarkeit Die Nutzung von Softwaresystemen im Hochverfügbarkeitsbereich erfordert den Einsatz von umfangreichen Maßnahmen zur Fehlererkennung und -prävention. Diese Maßnahmen sollten den in Kapitel 2.2 beschriebenen typischen Fehler vorbeugen. Im Folgenden erfolgt nun eine Betrachtung der einzelnen Phasen des Produktlebenszyklus von Software-Systemen und den jeweilig zu empfehlenden Maßnahmen. 3.1 Maßnahmen in der Entwicklungsphase Während der Entwicklungsphase sind die Möglichkeiten der Einflussnahme zur Erhöhung der Softwarequalität am größten und mit dem geringsten Aufwand umzusetzen. Ein entsprechend starker Fokus auf die Qualität der Software schon zu Beginn der Entwicklung ist notwendig Bewertung von Entwicklungsprozessen Um effektiv eine gesamtheitlich hohe Softwarequalität und damit eine hohe Verfügbarkeit zu erreichen, reicht die Betrachtung einzelner Teilprozesse wie beispielsweise des Wartungs- und Pflegeprozess nicht aus. Die gesamte Entwicklung und alle daran beteiligten Prozesse müssen analysiert, bewertet und entsprechend der Anforderungen kontrolliert werden. Hinsichtlich dessen wurden verschiedene Modelle zur Analyse und Bewertung von Entwicklungsund Produktionsprozessen entwickelt. Ein Modell mit einer entsprechend hohen Akzeptanz in der Wirtschaft ist das Capability Maturity Model Integration (CMMI). Dieser Nachfolger des Capability Maturity Model (CMM) wurde im Jahr 2002 veröffentlicht und ermöglicht die Bewertung von Entwicklungsprozessen anhand fest definierter Reife- und Fähigkeitsgrade Stufendarstellung Zur Bewertung von Entwicklungsprozessen beinhaltet das CMMI zwei verschiedene Darstellungsformen. Die Stufendarstellung sieht eine organisationsweite Zuweisung eines Reifegrades (Maturity Level) vor. Ein Reifegrad definiert verschiedene Ziele, welche erfüllt werden müssen, um den jeweiligen Grad im Rahmen einer Zertifizierung zugewiesen zu bekommen. Insgesamt sind fünf Reifegrade definiert: Reifegrad 1: Initial Prozesse sind nicht oder nur teilweise definiert. Ein Projektmanagement findet praktisch nicht statt. Reifegrad 2: Managed Zur Erreichung dieses Grades müssen div. Projektmanagement bezogene Prozesse in der Organisation definiert sein. Dies beinhaltet u. a., dass Projekte generell und von einer Projektleitung geführt werden, qualifizierte Personen dem Projekt zugeteilt werden und relevante Stakeholder in den Entwicklungsprozess mit einbezogen werden. Des Weiteren muss der Projektstatus während der Projektlaufzeit erkennbar sein, beispielsweise durch Milestones. Reifegrad 3: Defined Der Reifegrad Defined fordert einheitlich standardisierte Prozesse. Ziel sind 16 Bundesamt für Sicherheit in der Informationstechnik

17 HV-Kompendium V 1.6 Band B, Kapitel 9: Software organisationsweit konsistente Prozesse und die Verhinderung der Etablierung von sich unterscheidenden Prozessen in unterschiedlichen Projekten. Reifegrad 4: Quantitatively Managed Der Reifegrad Quantitatively Managed beinhaltet umfangreiche Messungen von Kennzahlen und Metriken zur Produkt- und Prozessqualität. Die ermittelten Ergebnisse dienen zur Steuerung anstehender Prozesse im Sinne der Prozessoptimierung. Reifegrad 5: Optimizing Der Reifegrad Optimizing erfordert einen konsequenten und kontinuierlichen Verbesserungsprozess unter Verwendung der ermittelten Kennzahlen und Metriken. Der Nachteil des CMMI Stufenmodells ist der geringe Detaillierungsgrad. Es erfordert die vollständige Umsetzung der definierten Ziele des jeweiligen Reifegrads. Die Nichterfüllung eines einzigen Ziels führt zur Rückstufung auf die nächsttiefere Stufe Kontinuierliche Darstellung Im Gegensatz zur Stufendarstellung ermöglicht die kontinuierliche Darstellung eine detailliertere Bewertung der Prozesse. Es erfolgt dabei eine separierte Bewertung einzelner Prozessbereiche. Ein Prozessbereich ist eine Zusammenfassung von inhaltlich zusammengehörigen Anforderungen, beispielsweise Projektplanung oder Anforderungsanalyse. Jedem Prozessbereich wird entsprechend den umgesetzten Zielen ein Fähigkeitsgrad (Capability Level) zugeteilt. Folgende Fähigkeitsgrade sind definiert: 0. Incomplete Dieser Grad wird automatisch zugeteilt, sollten die Anforderungen keines anderen Grads erfüllt sein. Es sind keine Anforderungen definiert. 1. Performed Die spezifischen Ziele des jeweiligen Prozessbereichs müssen erfüllt sein. 2. Managed Dieser Grad erfordert, dass Prozesse entsprechend dem Reifegrad 2 gemanagt werden. 3. Defined Prozesse werden auf Basis eines spezifizierten Standardprozesses gemanagt und verwaltet. 4. Quantitatively Managed Fähigkeitsgrad 4 beinhaltet umfangreiche Messungen von Kennzahlen und Metriken zur Prozesskontrolle 5. Optimizing Der Fähigkeitsgrad Optimizing erfordert eine kontinuierliche Prozessoptimierung auf Basis der ermittelten quantitativen Kennzahlen und Metriken. Eine Zertifizierung nach CMMI, ISO 9001 oder ISO (SPICE) ermöglicht eine standardisierte und nachhaltige Prozessoptimierung. Speziell die Kontinuierliche Darstellung nach CMMI ermöglicht eine gezielte Erkennung und Optimierung von kritischen Prozessen in der Entwicklung. Potentielle Fehlerquellen in den Entwicklungsprozessen können so aufgedeckt und nachgebessert werden. Somit kann nachhaltig eine hohe Softwarequalität erreicht werden. SPICE ist für Unternehmensprozesse mit dem Schwerpunkt auf der Softwareentwicklung entwickelt worden. Im Gegensatz zu CMMI definiert SPICE bisher noch keine Methoden zur Bewertung von Projekten oder Organisationen. Bundesamt für Sicherheit in der Informationstechnik 17

18 Band B, Kapitel 9: Software HV-Kompendium V Qualitätsbewertung nach DIN ISO 9126 Die in der DIN ISO 9126 definierten Qualitätsmerkmale ermöglichen die Qualität von Software ermitteln und bewerten zu können. Das Erreichen einer hohen Softwarequalität führt indirekt zu einer Verringerung der auftretenden Fehler im Produktivbetrieb der Software und somit zu einer Erhöhung der Verfügbarkeit. Im Gegensatz zum oben dargestellten CMMI bezieht sich ISO 9126 ausschließlich auf die Produktqualität und nicht die Prozessqualität. Definiert sind folgende Qualitätsmerkmale: Funktionalität Inwieweit besitzt die Software die geforderten Funktionen? - Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Angemessenheit: Eignung von Funktionen für spezifizierte Aufgaben, z. B. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen. Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z. B. die benötigte Genauigkeit von berechneten Werten. Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken. Sicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Funktionalität erfüllt. Zuverlässigkeit Kann die Software ein bestimmtes Leistungsniveau unter bestimmten Bedingungen über einen bestimmten Zeitraum aufrechterhalten? - Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. Reife: Geringe Versagenshäufigkeit durch Fehlerzustände. Fehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht- Einhaltung ihrer spezifizierten Schnittstelle zu bewahren. Robustheit: Fähigkeit, ein stabiles System bei Eingaben zu gewährleisten, die gar nicht vorgesehen sind. Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. Zu berücksichtigen sind die dafür benötigte Zeit und der benötigte Aufwand. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Zuverlässigkeit erfüllt. Benutzbarkeit Welchen Aufwand fordert der Einsatz der Software von den Benutzern und wie wird er von diesen beurteilt? - Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe. Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen. 18 Bundesamt für Sicherheit in der Informationstechnik