Band B, Kapitel 9: Software - BSI

Band B, Kapitel 9: Software - BSI
Band B, Kapitel 9: Software
Bundesamt für Sicherheit in der Informationstechnik
Postfach 20 03 63
53133 Bonn
Tel.: +49 22899 9582-0
E-Mail: hochverfü[email protected]
Internet: https://www.bsi.bund.de
© Bundesamt für Sicherheit in der Informationstechnik 2013
Inhaltsverzeichnis
Inhaltsverzeichnis
1
1.1
1.1.1
1.1.2
1.2
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
3
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
Einleitung....................................................................................................................................5
Definitionen.......................................................................................................................................5
Software-Modul...........................................................................................................................5
Verfügbarkeit...............................................................................................................................5
Untersuchungsbereich.......................................................................................................................6
Einflüsse auf die Software-Verfügbarkeit...................................................................................7
Systemstruktur...................................................................................................................................7
Betriebssystemkern......................................................................................................................8
Hardwarenahe Module, Treiber....................................................................................................8
Systembibliotheken, Standardmodule..........................................................................................8
Anwendungsspezifische Module (Standard- und Individual-Software)........................................8
Klassifizierung von Fehlertypen........................................................................................................9
Berechnungsfehler (fehlerhafte Algorithmen)..............................................................................9
Logische Fehler............................................................................................................................9
Datenfehler...................................................................................................................................9
Schnittstellenfehler.......................................................................................................................9
Ein-/Ausgabefehler.......................................................................................................................9
Performancefehler........................................................................................................................9
Fehlerquellen im Entwicklungsprozess...........................................................................................10
Fehler bei der Anforderungsdefinition........................................................................................10
Fehler beim Softwaredesign.......................................................................................................10
Fehler in der Implementierungsphase.........................................................................................11
Fehler in der Testphase...............................................................................................................12
Fehler in der Software-Dokumentation......................................................................................13
Fehlerquellen beim Softwarebetrieb................................................................................................14
Installations-/Auslieferungsphase...............................................................................................14
Eingabedaten..............................................................................................................................14
Software-Konfiguration..............................................................................................................15
Benutzerkenntnisse.....................................................................................................................15
Außerplanmäßige Systemlast.....................................................................................................15
Maßnahmen zur Sicherung hoher Verfügbarkeit......................................................................16
Maßnahmen in der Entwicklungsphase...........................................................................................16
Bewertung von Entwicklungsprozessen.....................................................................................16
Qualitätsbewertung nach DIN ISO 9126....................................................................................18
Maßnahmen bei der Anforderungsdefinition..............................................................................20
Maßnahmen beim Softwaredesign..............................................................................................21
Maßnahmen bei der Implementierung........................................................................................23
Maßnahmen in der Testphase.....................................................................................................25
Fehlerprävention.........................................................................................................................28
Fehlervorhersage........................................................................................................................28
Maßnahmen in der Betriebsphase....................................................................................................29
Maßnahmen zur Überwachung von Software-Komponenten.....................................................29
Maßnahmen zur Vorbeugung von Systemausfällen....................................................................30
Maßnahmen zur Behebung von Systemausfällen.......................................................................33
Weitere Maßnahmen.......................................................................................................................35
Software-Review........................................................................................................................35
Anhang: Verzeichnisse.............................................................................................................36
Bundesamt für Sicherheit in der Informationstechnik
3
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.............................................................................14
4
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
1
Band B, Kapitel 9: Software
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 SoftwareFehler 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 SoftwareEntwicklung 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.
1.1.1
Software-Modul
In diesem Beitrag wird der Begriff „Software-Modul“ als Bezeichnung für eine einzelne SoftwareKomponente verwendet. Ein solches Software-Modul kann aus der Sicht der Modellierung einer
HV-Architektur nicht in weitere Einzelbestandteile untergliedert werden. Im Sinne der HVMethodik 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 SoftwareModule 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.
1.1.2
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
Band B, Kapitel 9: Software
1.2
HV-Kompendium V 1.6
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
HV-Kompendium V 1.6
2
Band B, Kapitel 9: Software
Einflüsse auf die Software-Verfügbarkeit
Die im Kapitel 1.1.1 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
Band B, Kapitel 9: Software
2.1.1
HV-Kompendium V 1.6
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 ITSystem 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.
2.1.2
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 Hardware­
funktionen. 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.
2.1.3
Systembibliotheken, Standardmodule
Anwendungen basieren aus Kosten- und Effizienzgründen zu einem großen Teil auf StandardBibliotheken, 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 SoftwareModule und Anwendungen. Verfügbarkeit hängt also von der „Härte“ (Etablierung) der
verwendeten Programmiersprache ab.
2.1.4
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
HV-Kompendium V 1.6
2.2
Band B, Kapitel 9: Software
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.
2.2.1
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.
2.2.2
Logische Fehler
Ein logischer Fehler liegt dann vor, wenn ein bestimmter Anwendungsfall in der Ablauflogik des
Programms nicht berücksichtigt oder fehlerhaft umgesetzt wurde.
2.2.3
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.
2.2.4
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.
2.2.5
Ein-/Ausgabefehler
Ein-/Ausgabefehler treten bei dem Lesen oder Schreiben externer Daten auf.
2.2.6
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
Band B, Kapitel 9: Software
2.3
HV-Kompendium V 1.6
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.
2.3.1
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
Fehlende
Anforderungen
Falsche
Abschätzung der
maximalen Last
Fehlende Definition
von Schnittstellen zu
anderen Systemen
Fehlertyp
Logische
Fehler
Beschreibung
Werden nicht alle Anforderungen erfasst, so ist die
Verfügbarkeit der Anwendung hinsichtlich dieser
Anforderungen ggf. eingeschränkt.
Performance
Wird die maximal zu erwartende Last falsch
berechnet, so wird die Verfügbarkeit der Anwendung
durch Performancefehler beeinflusst.
Schnittstellenfe Werden Schnittstellen zu anderen Software-Modulen
hler,
nicht berücksichtigt, so kann die unkorrekte
Ein/Ausgabefe Kommunikation die Verfügbarkeit der Anwendung
hler
beeinträchtigen.
Tabelle 1: Fehler bei der Anforderungsdefinition
2.3.2
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
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Fehler
Unberücksichtigte
Anforderungen
Fehlertyp
Logische Fehler
Nicht adäquate
Entwurfsmuster
zur Lösung der
Probleme
Logische Fehler,
Performance
Beschreibung
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.
Tabelle 2: Fehler beim Softwaredesign
2.3.3
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
Band B, Kapitel 9: Software
Fehler
Buffer Overflow
Fehlertyp
Datenfehler,
Schnittstellenfehler
Relative Pfade
Datenfehler,
Schnittstellenfehler
SQL-Injection
Datenfehler,
Schnittstellenfehler
Dekodierungsfehler
Datenfehler
HV-Kompendium V 1.6
Beschreibung
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
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.
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
2.3.4
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
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Fehler
Ungetestete
Funktionen
Fehlertyp
Berechnungsfehler,
logische Fehler
Ungetestete
Ablaufpfade
Logische Fehler
Ungetestete
Austrittspunkte
Logische Fehler
Beschreibung
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.
Tabelle 4: Fehler in der Testphase
2.3.5
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 unzu­
reichende 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 Anwendungs­
dokumentation mit in die Beurteilung der Verfügbarkeit einfließen.
Bundesamt für Sicherheit in der Informationstechnik
13
Band B, Kapitel 9: Software
Fehler
Undokumentierte
Funktionen
Undokumentierte
Datenformate
Undokumentierte
Fehlercodes
HV-Kompendium V 1.6
Fehlertyp
Schnittstellenfehler,
Performancefehler
Beschreibung
Werden nicht alle Funktionen eines Moduls in
der Dokumentation beschrieben, kann die Ver­
fügbarkeit im Betrieb der Anwendung hin­
sichtlich dieser Funktionen eingeschränkt sein.
Datenfehler, Schnitt­ Ist das Format der bereitzustellenden Eingabe­
stellenfehler
daten nicht vollständig dokumentiert, so kön­
nen qualitativ minderwertige Daten die Ver­
fügbarkeit der Anwendung im Betrieb beein­
trächtigen.
Logische Fehler
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 dokumen­
tiert, so beeinflusst die ggf. die Verfügbarkeit
des Software-Moduls während des Betriebs.
Tabelle 5: Fehler in der Software-Dokumentation
2.4
Fehlerquellen beim Softwarebetrieb
2.4.1
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.
2.4.2
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 WebApplikationen 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
HV-Kompendium V 1.6
2.4.3
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.
2.4.4
Benutzerkenntnisse
Fehlende Benutzerkenntnisse erhöhen das Risiko eines Systemausfalls durch Fehlbedienung.
2.4.5
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
Band B, Kapitel 9: Software
3
HV-Kompendium V 1.6
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.
3.1.1
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.
3.1.1.1
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
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.
3.1.1.2
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 15504 (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
Band B, Kapitel 9: Software
3.1.2
HV-Kompendium V 1.6
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 NichtEinhaltung 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
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
– Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (z. B. Bedienung, Ein-,
Ausgabe).
– Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen.
– Attraktivität: Anziehungskraft der Anwendung gegenüber dem Benutzer.
– Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Benutzbarkeit
erfüllt.
– Effizienz
Wie liegt das Verhältnis zwischen Leistungsniveau der Software und eingesetzten
Betriebsmitteln? - Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der
eingesetzten Betriebsmittel unter festgelegten Bedingungen.
– Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der
Funktionsausführung.
– Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel bei der Erfüllung der
Funktionen. Ressourcenverbrauch, wie CPU-Zeit, Festplattenzugriffe usw.
– Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Effizienz erfüllt.
– Änderbarkeit
Welchen Aufwand erfordert die Durchführung vorgegebener Änderungen an der Software? Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können
Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der
Anforderungen oder der funktionalen Spezifikationen einschließen.
– Analysierbarkeit: Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder
um änderungsbedürftige Teile zu bestimmen.
– Modifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder
Anpassung an Umgebungsänderungen.
– Stabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen.
– Prüfbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist.
– Übertragbarkeit
Wie leicht lässt sich die Software in eine andere Umgebung übertragen? - Eignung der Software,
von der Umgebung in eine andere übertragen werden zu können. Umgebung kann
organisatorische Umgebung, Hardware- oder Software-Umgebung sein.
– Anpassbarkeit: Fähigkeit der Software, diese an verschiedene Umgebungen anzupassen.
– Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung
notwendig ist.
– Koexistenz: Fähigkeit der Software neben einer anderen mit ähnlichen oder gleichen
Funktionen zu arbeiten.
– Austauschbarkeit: Möglichkeit, diese Software anstelle einer spezifizierten anderen in der
Umgebung jener Software zu verwenden, sowie der dafür notwendige Aufwand.
– Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit
erfüllt.
Bundesamt für Sicherheit in der Informationstechnik
19
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Die Analyse bestehender oder in der Entwicklung befindlicher Software anhand definierter
Qualitätsmerkmale und –vorgaben, ermöglicht die Kontrolle der bestehenden und die Ermittlung
des gewünschten Maßes an Softwarequalität. Die Integration entsprechender Kontrollmechanismen
in den Entwicklungsprozess bietet die Möglichkeit der Qualitätsverbesserung sowie -sicherung zu
entwickelnder Software.
3.1.3
Maßnahmen bei der Anforderungsdefinition
Die Anforderungsdefinition legt den Grundstein für die spätere Systemimplementierung und dient
der Ermittlung der Systemanforderungen und der Umgebungen des zu entwickelnden Systems. In
dieser Phase der Entwicklung ist es wichtig, die systemrelevanten Unternehmensprozesse zu
verifizieren und analysieren, um spätere Fehler aufgrund falscher Annahmen und
Ausgangsbedingungen zu verhindern.
3.1.3.1
Vollständige Anforderungen
Jede Funktion des endgültigen Systems muss bei der Anforderungsdefinition spezifiziert werden.
Dabei ist zu beachten, dass alle relevanten unternehmensinternen Prozesse vollständig und
inhaltlich richtig durch entsprechende Anforderungen abgebildet werden, um System- und
Anwendungsfehler aufgrund korrelierender Nebenprozesse zu verhindern.
3.1.3.2
Atomare Anforderungen
Jede Funktion muss durch genau eine Anforderung definiert sein.
3.1.3.3
Minimale Anforderungen
Jede Anforderung muss zu einer tatsächlich erforderlichen Funktion des Systems führen.
Überflüssige Anforderungen, die auf eine Funktion abgebildet werden, führen zu einer erhöhten
Komplexität des Systems.
3.1.3.4
Definition der Systemgrenzen
Bereits während der Anforderungsdefinition müssen die Grenzen des Systems festgelegt werden.
Hierbei muss definiert werden, welche Funktionen nicht vom System unterstützt werden, sowie die
maximale Last während des Betriebs festgeschrieben werden. Dabei ist die Erstellung einer sogen.
Referenzwoche hilfreich. Darunter wird die Ermittlung der durchschnittlich zu erwartenden Lasten,
bezogen auf den jeweiligen Beobachtungszeitpunkt, verstanden. Dies erfolgt im Rahmen einer
mehrwöchigen Analyse der auftretenden Lasten im Einsatzumfeld des zu entwickelnden Systems,
um auch temporäre Lastspitzen in die Betrachtung mit einfließen zu lassen.
3.1.3.5
Definition von Schnittstellen zu anderen Modulen
Die Schnittstellen jedes Moduls zu anderen Modulen müssen definiert werden. Hierdurch können
Abhängigkeiten der Module dokumentiert werden, damit die Maßnahmen zur Sicherung der
Verfügbarkeit koordiniert werden können.
3.1.3.6
Definition von Angriffszenarien
Um Resistenz der Anwendung gegen die möglichen Angriffe gezielt berücksichtigen zu können,
müssen diese Szenarien bereits so früh wie möglich analysiert und dokumentiert werden.
20
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
3.1.3.7
Band B, Kapitel 9: Software
Definition der Anwendergruppen
Vor allem beim Design der Benutzerschnittstelle müssen die Fähigkeiten und Kenntnisse der
potentiellen Anwender berücksichtigt werden. Hierzu muss bereits bei der Anforderungsdefinition
eine Definition der Anwendergruppen erfolgen.
3.1.4
3.1.4.1
Maßnahmen beim Softwaredesign
Verwendung von Standard-Architekturmustern
Architekturmuster definieren die fundamentalen Strukturen eines Softwaresystems. Zur
Vermeidung unnötiger Komplexität der Systemarchitektur sowie erschwerter Wartbarkeit und
Erweiterbarkeit ist die Verwendung von Architekturmustern im Softwaredesign empfehlenswert.
Die Wahl des Architekturmodells hängt dabei maßgeblich vom zu entwickelnden Softwaresystem
und deren Anwendungsgebiet ab.
Zur näheren Erläuterung seien hier nun beispielhaft zwei Architekturmuster genannt:
Pipes and Filters: Architekturmuster zur Entwicklung von Datenstrom verarbeitenden Systemen.
Dieses Muster sieht die Zerlegung des Softwaresystems in diverse Komponenten, sogen. Filter vor.
Der Austausch von Daten zwischen den Filtern erfolgt über Konnektoren, Pipes genannt. Die Filter
sind voneinander unabhängig und haben keine Kenntnis von der Identität der
informationsliefernden oder -empfangenden Filter. Das Systemverhalten wird über die Komposition
der einzelnen Filter definiert und beeinflusst.
Blackboard: Dieses Architekturmuster basiert auf der Nutzung einer gemeinsamen Datenstruktur,
das sogen. Blackboard von verschiedenen Komponenten, auch Agenten genannt. Diese Agenten
sind voneinander unabhängige Software-Komponenten, welche allein über das Blackboard
miteinander agieren. Agenten ändern den Zustand der gemeinsamen Datenstruktur und werden
bedingt durch den Zustand des Blackboards aufgerufen. Die Kontrolle des Systems beruht
ausschließlich auf dem aktuellen Zustand des Blackboards. Verwendung findet diese Architektur im
Bereich der Intelligenten Systeme, beispielsweise bei Multiagentensystemen.
Die Wahl des Architekturmodells beeinflusst die Struktur des Softwaresystems maßgeblich und
sollte daher mit Bedacht getroffen werden.
3.1.4.2
Verwenden von Standard-Entwurfsmustern
Zur Vermeidung unnötiger Komplexität und instabiler Systemarchitektur sollten beim
Systemdesign nur Standard-Entwurfsmuster angewendet werden. Design-Patterns sind
Lösungsbeschreibungen für ein spezifisches Entwurfsproblem. Ein Design-Pattern stellt dabei eine
von der Implementation unabhängige und wieder verwendbare Vorlage dar. Sie unterscheidet sich
von anderen Design-Patterns oft hinsichtlich des Anwendungsbezugs und ihrer Granularität. Die
nachfolgend dargestellten Beispiele dienen der näheren Erläuterung des Themas.
Fassade: Dieses Pattern bietet eine Schnittstelle zu einer Menge von Schnittstellen eines
Subsystems und dient der vereinfachten und vereinheitlichten Nutzung dieser Schnittstellen. Nach
dem Prinzip der autonomen Teilsysteme ermöglicht dieses Muster eine größtmögliche Abgrenzung
zwischen der Schnittstelle und der eigentlichen Umsetzung der Funktionalität.
Bundesamt für Sicherheit in der Informationstechnik
21
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Abbildung 2: Entwurfsmuster-Fassade
Bridge: Dieses Pattern dient der Entkopplung von abstrakter Schnittstellendefinition und
Implementierung durch Nutzung zweier getrennter Vererbungshierarchien. Die abstrakte Klasse
hält dabei eine Referenz zu einer Implementierung vor. Dies ermöglicht den dynamischen
Austausch der Implementierung während der Laufzeit. Ein weiterer positiver Effekt ist die
Möglichkeit Erweiterungen bzw. Anpassungen an der abstrakten Klasse ohne direkte
Auswirkungen auf evtl. Implementierungen vornehmen zu können.
Speziell zur Vermeidung von Fehlern im Softwaredesign ist der Einsatz von Entwurfsmustern
empfehlenswert. Diese sind auf ihre Anwendbarkeit hin ausgiebig getestet worden und in einer
Vielzahl von Projekten erfolgreich eingesetzt. Sie stellen eine gut durchdachte und zumeist elegante
Lösung eines spezifischen Problems dar und unterstützen somit die Vermeidung von Fehlern, was
zu einer Erhöhung der Softwarequalität führt.
3.1.4.3
Analyse des Designs mit Anti-Pattern
Als Anti-Pattern werden Entwurfsmuster bezeichnet, die auf ein schlechtes Softwaredesign
hindeuten. Ein Beispiel für Anti-Patterns ist God Class: Innerhalb des Design ist eine Klasse
22
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
allwissend und ist für viele unterschiedliche Aufgaben zuständig. Dies widerspricht dem Prinzip der
Kapselung objektorientierter Systeme.
Mit Hilfe der Anti-Pattern kann die Qualität des Software-Design beurteilt werden.
3.1.4.4
Verwenden von Fehlermaskierung
Als Fehlermaskierung wird ein Verfahren im Software-Design bezeichnet, bei dem ein Modul auf
unterschiedliche Art und Weise von unabhängigen Teams realisiert wird. Diesen Modulen wird
dann der sogenannte Maskierer vorgeschaltet, der mittels eines Ergebnisvergleichs fehlerhafte
Resultate ausschließt, solange diese nicht in der Mehrheit der Module auftreten.
3.1.4.5
Verwenden von Fehlerkompensierung
Beim Verfahren der Fehlerkompensierung werden die Ergebnisse auf Fehler untersucht und durch
ein nachgelagertes Modul wird das korrekte Ergebnis berechnet. Dieses erfordert eine
entsprechende Redundanz der Ergebnisdaten. Beispiele hierfür sind Kommunikationsprotokolle, bei
denen Übertragungsfehler erkannt und korrigiert werden können.
3.1.4.6
Verwenden von Fehlerbehebung
Beim Verfahren der Fehlerbehebung wird das Modul bei Erkennung eines fehlerhaften Ergebnisses
in einen definierten Zustand zurückgesetzt und die Berechnung des Ergebnisses wird wiederholt.
Fehlerbehebung kann vor allem dann sinnvoll angewendet werden, wenn temporäre Einflüsse den
Fehler verursacht haben. Beispiele hierfür sind:
– Speicherplatzmangel (sowohl Hauptspeicher als auch Festplattenspeicher),
– Kommunikationsprobleme mit anderen System (z. B. Netzwerkprobleme) und
– Interne inkonsistente Zustände, bedingt durch vorhergehende Ereignisse.
3.1.5
3.1.5.1
Maßnahmen bei der Implementierung
Pair-Programming
Beim Verfahren der Paarprogrammierung wird die Implementierung von zwei Entwicklern parallel
an einem Arbeitsplatz vorgenommen. Hierbei ist jeweils ein Programmierer für das Schreiben des
Codes verantwortlich, während der andere die Umsetzung prüft und mögliche Zusammenhänge
analysiert. Diese Rollenverteilung wird regelmäßig getauscht.
Dieses Verfahren führt zu einer höheren Codequalität, da der Programmierer in der Rolle des
Beobachters Fehler und Risiken schneller erkennen kann.
3.1.5.2
Test-First-Programming
Ebenso wie das Pair-Programming entstammt das Verfahren des Test-First-Programming der
„Extreme Programming“-Methode. Hier werden für neue Module zunächst geeignete Testmethoden
entwickelt, die ein automatisiertes und wiederholbares Testen des Moduls ermöglichen. Hierdurch
wird vermieden, dass durch genaue Kenntnis der Modulstruktur um Fehler „herum“ getestet wird.
Bundesamt für Sicherheit in der Informationstechnik
23
Band B, Kapitel 9: Software
3.1.5.3
HV-Kompendium V 1.6
Continuous Integration
Continuous Integration beschreibt ein Verfahren, bei der jede Änderung, die ein Entwickler an die
zentrale Quellcodeverwaltung übergibt, automatisch übersetzt und durch automatische Tests
überprüft wird. Änderungen, die die Stabilität z. B. durch Seiteneffekte beeinträchtigen, werden
somit unmittelbar erkannt.
3.1.5.4
Einsatz wieder verwendbarer Komponenten
Ähnlich dem Design-Pattern Ansatz beim Software-Design können auch bei der Implementierung
bestehende Module, deren hohe Verfügbarkeit bereits nachgewiesen wurde, verwendet werden.
Vorrausetzung für die Verwendbarkeit bestehender Module ist eine ausführliche und exakte
Dokumentation der Schnittstellen und Funktionen des Moduls.
3.1.5.5
Einsatz von Diagnose-Software
Während die syntaktische Korrektheit der entwickelten Software durch den Compiler überprüft
wird, findet eine semantische Prüfung auf dieser Ebene nicht statt. Mit zusätzlichen Werkzeugen ist
es jedoch möglich eine Reihe semantischer Fehler zu entdecken, hierzu zählen:
– Speicherlöcher (fehlende Freigabe dynamisch angelegter Speicherbereiche),
– Uninitialisierte Variablen und
– Laufzeitverhalten (Race conditions / Deadlocks).
3.1.5.6
Quellcode-Dokumentation
Für die meisten Programmiersprachen existieren Richtlinien zur Dokumentation des Quellcodes.
Wird der Code gemäß dieser Richtlinien codiert, können entsprechende Tools automatisch eine
ausführliche Zusammenfassung der Implementierung erzeugen, die als Grundlage für die
Entwicklung von Test, für die weitere Wartung der Software aber auch zur Beurteilung der
Verfügbarkeit verwendet werden kann.
3.1.5.7
Durchgängige Daten-/Parameterprüfung
Jedes Modul/Funktion ist selbst für die Prüfung der eingehenden und ausgehenden Daten und
Parameter verantwortlich. Es darf nicht angenommen werden, dass übergeordnete Methoden oder
Prozesse eine Fehlerfreiheit der Daten garantieren. Es ist dabei zu Empfehlen für jedes Modul
genau zu spezifizieren, welche Daten bzw. Parameter hinsichtlich ihres Formats und Inhalts als
gültig zu gelten haben.
3.1.5.8
Aktive Fehlerbehandlung
Jede Funktion muss so implementiert werden, dass Fehlerzustände explizit erwartet und aktiv
behandelt werden. Die betrifft vor allem auch die Kommunikation mit anderen Funktionen und
Modulen, bei denen Ergebnisse soweit möglich auf Sinnhaltigkeit überprüft werden müssen, damit
ggf. Maßnahmen wie Fehlermaskierung, Fehlerkompensation oder Fehlerbehebung angewendet
werden können.
3.1.5.9
Bestimmung des Code-Quality-Index
Der Code-Quality-Index ist ein standardisiertes Qualitätsmodell, welches auf Basis des
Forschungsprojektes „QBench“ entwickelt wurde.
24
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Es basiert auf empirischem Material, welches aus ausführlichen Untersuchungen bestehender
Projekte einzelne Qualitätsindikatoren einer konkreten Implementierung ableitet. Für jeden
Indikator werden die Qualitätseigenschaften
– Analysierbarkeit,
– Modifizierbarkeit,
– Stabilität,
– Prüfbarkeit,
– Austauschbarkeit,
– Zeitverhalten und
– Verbrauchsverhalten
untersucht. Zudem erfolgt eine Einschätzung bezüglich der Auswirkung auf den Kostenzuwachs.
Auf Basis der definierten Indikatoren kann mit Hilfe geeigneter Werkzeuge automatisch der
zugehörige Code-Quality-Index ermittelt werden.
3.1.6
Maßnahmen in der Testphase
Testprozesse dienen der Identifizierung von Fehlern in Softwaresystemen und sind daher ein
essentieller Baustein zur Realisierung von hochverfügbarer Software. Vollständig fehlerfreie
Software zu entwickeln ist nur sehr schwer umzusetzen. Es kann nicht von einer Fehlerfreiheit
ausgegangen werden. Auch nach erfolgreicher Durchführung verschiedenster Testverfahren kann
aufgrund des destruktiven Charakters eines Testprozesses nicht von vollständiger Fehlerfreiheit
gesprochen werden. Tests zeigen generell die Anwesenheit von Fehlern auf und nicht deren
Abwesenheit.
Hinsichtlich Art und Ausrichtung der Tests sind verschiedenste Testverfahren denkbar und finden je
nach Zielsetzung des Testprozesses Anwendung. Es ist es generell sinnvoll jeder Phase im
Entwicklungsprozess einen dementsprechenden Test entgegenzusetzen, um die korrekte Umsetzung
der jeweiligen Phase unter Berücksichtigung der jeweiligen Granularität zu überprüfen. Besondere
Anforderungen wie beispielsweise kritische Performancewerte sind gesondert mit speziellen
Testverfahren, wie beispielsweise JMeter zur Durchführung von Lasttests, auf erfolgreiche
Umsetzung hin zu prüfen.
In Anlehnung an den in Abschnitt 2.3 dargelegten Phasen eines Softwareentwicklungsprozesses,
werden im Folgenden dementsprechende Testverfahren dargestellt.
– Unit Tests
Unit Tests dienen der Funktionsverifkation von Modulen und Klassen und entsprechen
hinsichtlich der inhaltlichen Ausrichtung der Implementierungs- und Design-Phase. Überprüft
wird, inwieweit die in der Designphase modellierten und in der Implementationsphase
umgesetzten Klassen und Module mit der jeweiligen funktionellen Spezifikation
übereinstimmen. Bezogen auf die Granularität besitzen Unit Tests einen sehr hohen
Detaillierungsgrad, da einzelne Klassen auf ihre Funktionsfähigkeit geprüft werden.
Empfehlenswert ist es bei jeder Modifikation des Codes sämtliche als Testfälle definierte Unit
Tests durchzurühren, um evtl. Seiteneffekte in anderen Codebereichen erkennen zu können. Unit
Bundesamt für Sicherheit in der Informationstechnik
25
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Test eigenen sich dabei im Besonderen zur Testautomatisierung, wie beispielsweise durch
Verwendung von JUnit.
– Integration Tests
Integrationstests dienen dem Testen des Zusammenwirkens von mehreren, voneinander
abhängigen Modulen oder Komponenten und entsprechen der Designphase. Es gilt, die in dem
Architekturdesign definierten Abhängigkeiten und Interaktionen von Komponenten auf die
Funktionsfähigkeit und eventueller Fehler zu testen. Zeitlich ist diese Art von Tests nach einer
erfolgreichen Durchführung von Unit-Tests einzuordnen, um evtl. modulinterne Fehler
auszuschließen.
– System Tests
Systemtests dienen der Überprüfung des ganzen Softwaresystems. Es gilt dabei zu überprüfen,
inwieweit die in einem Pflichtenheft definierte Systemspezifikation eingehalten und vollständig
umgesetzt wurde.
– Acceptance Tests
Acceptance Tests dienen der Verifikation des ges. Systems hinsichtlich der in der
Anforderungsanalyse definierten Punkte. Es gilt dabei zu überprüfen, ob alle ermittelten
Anforderungen vollständig und fachlich richtig umgesetzt wurden.
Zu empfehlen ist es in diesem Zusammenhang auch Tests von einer ausgewählten Nutzergruppe
durchführen zu lassen um evtl. Unstimmigkeiten in der Bedienung oder in der Abbildung
vorhandener Arbeitsprozesse zu identifizieren. Speziell Letztere können als Quelle von schwer
zu verifizierenden Fehlern dienen und zu einem Akzeptanzverlust bei der Nutzergruppe führen,
was es im Sinne der Qualitätsoptimierung zu verhindern gilt.
Die Möglichkeiten verschiedener Testverfahren hängen maßgeblich von den zugrunde liegenden
Informationen über das zu überprüfende Softwaresystem ab. In Abhängigkeit von den vorliegenden
Struktur- und Codeinformationen können folgende Kategorien von Tests durchgeführt werden.
3.1.6.1
Blackbox Tests
Blackbox Testing, auch funktionales Testen oder datengesteuertes Testen genannt, betrachtet das zu
überprüfende System als sogen. Black box. D. h., es werden keinerlei Informationen bezüglich
interner Strukturen des Systems im Rahmen des Testvorgangs genutzt. Die zugrunde liegenden
Testfälle und Testdaten sind dementsprechend allein aus der Spezifikation herzuleiten. Überprüft
wird dabei der geforderte Funktionsumfang. Implementationsspezifische Besonderheiten sind nicht
Teil der Betrachtung.
Es existieren verschiedenste Blackbox basierte Testverfahren. Im Folgenden werden zwei
beispielhaft dargestellt.
– Äquivalenzklassenanalyse (Equivalence Partitioning)
Dieses Verfahren basiert auf der Identifizierung von Äquivalenzklassen auf Basis der zu
testenden Ein- und Ausgabedaten. Eine Äquivalenzklasse ist eine Zusammenfassung von Daten,
welche ein äquivalentes Verhalten beim zu testenden System hervorrufen. Dieses Vorgehen
ermöglicht eine erhebliche Reduktion der durchzuführenden Testfälle, bei Akzeptanz einer
gewissen Ungenauigkeit aufgrund der Äquivalenzklassenbildung.
– Grenzwertanalyse (Boundary Value Analysis)
Dieses Testverfahren führt eine Grenzwertanalyse der Testdaten durch, um stark fehleranfällige
Testfälle zu ermitteln. Dem Verfahren liegt die Erkenntnis zugrunde, dass Fehler gehäuft an den
Grenzwerten einer Äquivalenzklasse auftreten.
26
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Aufgrund fehlender Information bezüglich der internen Struktur des Systems ist eine
Überprüfung aller Programmzustände kaum oder nur mit extrem großem Aufwand möglich.
3.1.6.2
Whitebox Tests
Das Whitebox Testing, auch als logical driven Testing bezeichnet, betrachtet das zu überprüfende
System als gläserne box. Alle internen Strukturen des Systems werden in dem Test berücksichtigt.
Die Testdaten werden somit von diesen Informationen hergeleitet. Der Fokus dieser Tests bezieht
sich auf die Programmlogik. Eine funktionale Betrachtung wie beim Blackbox Testing erfolgt
hierbei nicht.
Ein Beispiel für ein Whitebox-basiertes Verfahren ist der Pfadüberdeckungstest.
Pfadüberdeckungstest basieren auf Darstellung des Kontrollflusses eines Softwaresystems bzw.
Moduls in einem Flowchart. Anhand dieser Diagramme erfolgt unter Verwendung der
Zyklomatischen Komplexitätsbestimmung die Ermittlung der durchzuführenden Testfälle. Die
Zykomatische Komplexität identifiziert alle unabhängigen Pfade des Flowcharts und ermöglicht
somit eine Reduktion auf die Mindestmenge an Testfälle um alle Anweisungen mindestens einmal
überprüfen zu können.
Im Vergleich zum Blackbox Verfahren bedeuten Whitebox Test wesentlich weniger Aufwand in
der Testumsetzung. Die ausschließliche Verwendung von Whitebox Test führt allerdings gewisse
Gefahren mit sich. Aufgrund der Kenntnisse der internen Struktur besteht die Gefahr kritische
Stellen unbemerkt zu „umschiffen“ und ungenügend zu testen. Daher ist zu empfehlen, Blackbox
und Whitebox Tests zu kombinieren um von den Vorteile beider Verfahrensweisen partizipieren zu
können.
3.1.6.3
Greybox Tests
Eine Alternative zu den beiden oben genannten Verfahren bieten Agile Software-Entwicklungs­
methoden wie beispielsweise XP. Aufgrund des Paradigmas der Test-orientierten Entwicklung
werden Testfälle vor der eigentlichen Implementierung der Komponenten erstellt. Greybox Testing
kombiniert den geringen Aufwand des Whitebox Testings mit der geringen Gefahr des
ungenügenden Testens kritischer, fehlerbehafteter Elemente.
Eine alleinige Nutzung von Greybox Tests ist allerdings nicht empfehlenswert. Greybox Tests sind
vielmehr als eine Erweiterung bestehender Black- und Whitebox Test anzusehen und sollten
entsprechend in den Testprozess integriert werden.
3.1.6.4
Standardisierte Testprozesse
Im Rahmen der Entwicklung von Software im Hochverfügbarkeitsbereich ist ein umfangreicher
Testprozess unabdingbar. Die Identifizierung und Beseitigung von Fehlern im Produktivbetrieb ist
hinsichtlich der Ausfallzeiten und Ressourcenbindung erheblich teuer als innerhalb der
Entwicklungsphase. Ein Fehler im Produktivbetrieb hat in der Regel den Teil- oder Komplettausfall
des jeweiligen Softwaresystems zur Folge. Im Sinne der Realisierung einer hohen Verfügbarkeit
gilt es daher hinreichend ausführliche und umfangreiche Tests im Rahmen eines standardisierten
Testprozesses in den Entwicklungsprozess zu integrieren, um zukünftige Ausfälle aufgrund von
Softwarefehlern möglichst zu verhindern.
Zusätzlich ist darauf zu achten, dass dieser Testprozess auch in die Wartungs- und Pflegephase des
Produktlebenszyklus entsprechen integriert wird und bei jeder Wartungs- und Pflegemaßnahme in
Gänze Verwendung findet.
Bundesamt für Sicherheit in der Informationstechnik
27
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Als Beispiel für einen innerhalb des Entwicklungsprozess integrierten Testprozess kann z. B. das VModell oder Rational Unifikator Process (RUP) [IBM08] genannt werden.
Abbildung 3: Testprozess nach dem V-Modell
3.1.7
Fehlerprävention
Eine genaue Untersuchung der unterschiedlichen Fehlerarten bei der Software-Entwicklung zeigt,
dass Muster für typische Fehlerquellen erkennbar sind. Diese Muster basieren in der Regel auf
menschlichen Eigenschaften, die die Entstehung von Fehlern begünstigen.
Werden die gefundenen Fehler innerhalb einer Anwendung protokolliert und klassifiziert, so kann
gezielt nach ähnlichen Fehlern gesucht werden.
Ein bekanntes Beispiel für die Protokollierung von Fehlern ist die Arbeit von Donald E. Knuth am
Satzprogramm TeX. Alle aufgetretenen Fehler (bisher 928) wurden in 15 Kategorien eingeordnet.
Ein Vergleich der Fehlerverteilung mit dem späteren Projekt METAFONT zeigt, dass eine ähnliche
Verteilung der gefundenen Fehler zu erkennen ist.
3.1.8
Fehlervorhersage
Bei Fehlervorhersage wird die Wahrscheinlichkeit auftretender Fehler und deren Folgen
abgeschätzt. Aufgrund der Betrachtung der Auswirkungen möglicher Fehler können sich gezielt
zusätzliche Maßnahmen zur Begrenzung der Eintrittswahrscheinlichkeit durchführen. Es können
beispielsweise gezielt Tests zur Entdeckung relevanter Fehler durchgeführt werden. Für den Betrieb
28
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
lassen sich außerdem Anzeichen für Fehlersituationen ermitteln, bei denen das System in einen
sicheren Zustand gebracht werden kann (fail-safe), bevor sich die eigentlichen Folgen des Fehlers
auswirken.
3.2
Maßnahmen in der Betriebsphase
Für den Betrieb von Software-Komponenten sind eine Reihe von Maßnahmen erforderlich, um eine
hohe Verfügbarkeit gewährleisten zu können. Diese Maßnahmen können je nach Art der SoftwareKomponente unterschiedlich sein, so benötigt die Sicherstellung einer hohen Verfügbarkeit eines
öffentlich zugänglichen Webservers zahlreiche Maßnahmen während des Betriebs der Software,
dem gegenüber ist für die Verfügbarkeit einer Standardbibliothek in erster Linie eine sorgfältige
Entwicklungs- und Testphase von Bedeutung, während des Betriebs kann nur wenig Einfluss auf
die Verfügbarkeit genommen werden.
Im Allgemeinen lassen sich Maßnahmen zur Gewährleistung von hoher Verfügbarkeit aufteilen in
Maßnahmen zur Überwachung von Software-Komponenten, Maßnahmen zur Vorbeugung von
Systemausfällen sowie Maßnahmen zur Behebung von Systemausfällen. Diese werden in den
folgenden Abschnitten genauer beschrieben.
3.2.1
Maßnahmen zur Überwachung von Software-Komponenten
Zur Erkennung kritischer Systemzustände oder von Ausfällen von Software-Komponenten sind
verschiedene Maßnahmen zu deren Überwachung erforderlich. Ohne die daraus gewonnenen
Informationen ist es oft nicht möglich, Maßnahmen zur Behebung von Fehlersituationen einleiten
zu können.
3.2.1.1
Protokollierung von Software-Konfigurationsänderungen
Jegliche Änderungen an der Konfiguration einer Software-Komponente bzw. deren Umgebung
sollte protokolliert werden, sodass eine spätere Nachvollziehbarkeit der Änderungen möglich ist.
Die hierbei festzuhaltenden Aktivitäten umfassen:
– Konfigurationsänderungen der Software-Komponente,
– Einspielung von Patches,
– Upgrade von abhängigen Softwarepaketen und
– Administrationsarbeiten am Host-System.
Jede dieser Änderungen sollte mit dem Änderungsdatum in einem Dokument festgehalten werden.
3.2.1.2
Monitoring von Software-Komponenten
Die Überwachung der Systemzustände von Software-Komponenten bildet die Grundlage, um in
Fehlersituationen eine zeitnahe Fehlerbehebung ermöglichen zu können. Typischerweise wird
hierfür die Existenz des Systemprozesses periodisch geprüft. Darüber hinaus können je nach Art der
Komponente auch auf anderem Wege Zustandsinformationen ermittelt werden (wie z. B.
Kommunikationsports).
In komplexen IT-Systemen bietet es sich an, derartige Zustandsinformationen mehrerer SoftwareKomponenten in einem zentralen Überwachungssystem zusammenzufassen.
Bundesamt für Sicherheit in der Informationstechnik
29
Band B, Kapitel 9: Software
3.2.1.3
HV-Kompendium V 1.6
Protokollierung von Systemereignissen
Die Protokollierung von Systemereignissen (typischerweise in Logdateien) bietet verschiedene
Möglichkeiten zur Untersuchung der Softwareverfügbarkeit. Fehlerzustände der SoftwareKomponente werden zeitlich festgehalten, zudem können Informationen ermittelt werden, welche
Folge von Systemereignissen zu einer Fehlersituation geführt haben.
Die Protokollierungsfunktionalität einer Software-Komponente muss bereits in der
Entwicklungsphase berücksichtigt werden. Während des Betriebs können die Protokoll-Logs zur
Analyse des Softwareverhaltens im Echtbetrieb herangezogen werden. Zudem erlauben flexible
Logging-Frameworks die Wahl der Detailstufe der Protokollierung und bieten Systemen, die sich
im Produktiveinsatz befinden, eine einfache Möglichkeit der Fehleranalyse.
Systemereignisse werden hierbei in der Regel einem Loglevel zugeordnet werden. Verschiedene
Logging-Frameworks bieten die Möglichkeit, beim Auftreten von kritischen Systemereignissen die
Log-Informationen nicht nur in einer Logdatei zu hinterlegen, sondern auch zuständige Personen
direkt zu benachrichtigen (SMS, Pager, E-Mail, Instant Messaging).
3.2.1.4
Fehlerreports von Software-Komponenten
Die Verfügbarkeit von Software-Komponenten, die unter der Kontrolle des Endanwenders laufen
(wie beispielsweise Textverarbeitungsapplikationen, Browser) wird im hohen Maße durch die
Robustheit der Anwendung gegenüber fehlerhaften Eingaben beziehungsweise fehlerhafter
Bedienung der Benutzer beeinflusst. Während eine direkte Überwachung derartiger SoftwareKomponenten eher unüblich ist, so besteht die Möglichkeit, in Fehlersituationen Informationen zur
Fehlerdiagnose auf Nachfrage hin an den Hersteller zu senden. Ein derartiger Mechanismus ist
insbesondere für Standardsoftware hilfreich, die in zahlreichen unterschiedlichen Umgebungen
eingesetzt wird.
3.2.2
Maßnahmen zur Vorbeugung von Systemausfällen
Um die Wahrscheinlichkeit des Ausfalls einer Software-Komponente auf ein Mindestmaß zu
reduzieren, sind präventive Maßnahmen erforderlich. Diese lassen sich unterscheiden in
organisatorische sowie technische Maßnahmen.
3.2.2.1
Erstellung der Dokumentation für den Betrieb
Um einen reibungslosen Betrieb zu ermöglichen, muss eine Software-Komponente in
ausreichendem Maße dokumentiert sein. Nur somit kann der ordnungsgemäße Gebrauch von
Software ermöglicht werden, um Fehlersituationen aufgrund von Fehlbedienung auszuschließen.
Folgende Dokumente sind für den Betrieb erforderlich:
Das Installationshandbuch beschreibt alle nötigen Schritte zur Installation auf dem Zielsystem und
gibt eine Übersicht über die Konfigurationsmöglichkeiten der Software-Komponente.
Im Benutzerhandbuch wird die ordnungsgemäße Nutzung der Software-Komponente aus
Benutzersicht erläutert. Das Benutzerhandbuch soll einen Überblick über die Funktionalität der
Software und deren korrekte Verwendung geben und mögliche Fehlerfälle samt
Behebungsmöglichkeiten auflisten. Ein klar verständliches Benutzerhandbuch verringert auch die
Wahrscheinlichkeit von Benutzerfehlern.
30
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Je nach Art der Software-Komponente kann auch ein Administrationshandbuch erforderlich sein, in
dem Wartungsarbeiten, mögliche Fehlerfälle und Möglichkeiten der Fehlerbehebung beschrieben
werden.
Für modular aufgebaute Software-Komponenten mit einer Vielzahl von manuellen
Konfigurationsmöglichkeiten unmittelbar nach der Installation sollten darüber hinaus sämtliche
Konfigurationsänderungen in einem Dokument zusammengefasst werden, um eine
Wiederherstellung der Software-Komponente ausgehend von einer Neuinstallation zu ermöglichen.
Hierzu zählen beispielsweise konfigurationsaufwendige Komponenten wie Web-Server oder EMail-Server.
3.2.2.2
Schulung des Personals
Neben der Bereitstellung von Dokumentation kann es bei komplexen Software-Komponenten
hilfreich sein, das Personal in der korrekten Verwendung der Software einzuweisen und zu schulen.
Dies gilt sowohl für Endbenutzer der Software-Komponente als auch für Administratoren, die für
deren Verfügbarkeit zuständig sind.
3.2.2.3
Schutz vor Manipulation der Software-Komponenten
Die Verfügbarkeit von Software wird maßgeblich davon beeinflusst, welche Möglichkeiten einer
beabsichtigten und unbeabsichtigten Manipulation der Software existieren. Folgende Maßnahmen
sollten durchgeführt werden, um die Möglichkeiten eines Angreifers beziehungsweise von
versehentlichen Änderungen einzuschränken:
– Verwendung einer sicheren Konfiguration der Software-Komponente,
– Betrieb der Software-Komponente in einer abgesicherten, minimalen Umgebung (sowohl
physikalisch als auch informationstechnisch) und
– kontinuierliche Überwachung der Integrität der Software-Komponente.
Je nach Art der Anwendung bestehen unterschiedliche Angriffsmöglichkeiten, so erfordert ein
öffentlich zugänglicher Webserver andere Schutzmaßnahmen als eine Client-Anwendung.
3.2.2.4
Abschalten nicht benötigter Leistungsmerkmale
Modulare Software-Komponenten, die eine An- und Abschaltung verschiedener
Leistungsmerkmale anbieten, sollten derart konfiguriert werden, dass nicht mehr als die für den
Betrieb erforderliche Funktionalität angeboten wird. Dies verringert die Komplexität der
Komponente und damit deren Fehleranfälligkeit sowie die Anzahl an Angriffsmöglichkeiten.
3.2.2.5
Sichere Grundkonfiguration einer Software-Komponente
Falls eine Software-Komponente durch verschiedene Anwendungsparameter beeinflusst wird, sollte
diese im Auslieferungszustand eine Konfiguration besitzen, die ein höchstmögliches Maß an
Zuverlässigkeit und Sicherheit bietet. Schränkt eine solche Konfiguration die Benutzbarkeit der
Software-Komponente über Gebühr ein, so muss ein geeigneter Kompromiss gefunden werden.
Dies sollte insbesondere für Standard-Software bedacht werden, die in verschiedenen Umgebungen
für verschiedene Einsatzzwecke verwendet werden kann.
Bundesamt für Sicherheit in der Informationstechnik
31
Band B, Kapitel 9: Software
3.2.2.6
HV-Kompendium V 1.6
Ein Dienst pro Host-System
Werden verschiedene Software-Komponenten auf demselben Host-System betrieben, besteht die
Möglichkeit der indirekten gegenseitigen Beeinflussung. Aufgrund der Fehleranfälligkeit von
Software-Komponenten im Allgemeinen besteht daher die Möglichkeit, dass Fehlersituationen eine
Auswirkung auf andere Dienste desselben Host-Systems haben, bis hin zum Totalausfall anderer
Dienste.
Eine Aufteilung verschiedener Dienste auf unterschiedliche Rechner hat daher folgende Vorteile:
– Vereinfachte Konfiguration der verschiedenen Host-Systeme,
– erhöhte Widerstandsfähigkeit gegenüber Angriffen und
– erhöhte Ausfallsicherheit.
Falls es die Art der Software-Komponente zulässt, sollte daher nach diesem Prinzip verfahren
werden. Dies ist insbesondere bei Serverapplikationen der Fall.
Als Alternative zur „Ein-Dienst-pro-Host-System“-Strategie kann nach dem Prinzip der Virtuali­
sierung eine Trennung der einzelnen Anwendungen innerhalb eigenständiger virtueller
Umgebungen durchgeführt werden.
Abbildung 4: Trennung einzelner Anwendungen durch virtuelle Umgebungen
32
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
Band B, Kapitel 9: Software
Durch diesen Ansatz wird die Beeinflussung der Verfügbarkeit einer Anwendung durch Fehler in
einer anderen Anwendung minimiert. Allerdings muss bei der Verfügbarkeitsbetrachtung hierbei
auch die verwendete virtuelle Umgebung berücksichtigt werden.
3.2.2.7
Sicherstellung der Integrität und Authentizität von Softwarepaketen
Da in der Software-Entwicklung der Einsatz wieder verwendbarer Software angestrebt wird,
besitzen Software-Komponenten in der Regel zahlreiche Abhängigkeiten zu anderen SoftwarePaketen. Um einen ordnungsgemäßen Betrieb gewährleisten zu können, ist vor der Inbetriebnahme
der Software-Komponente sicherzustellen, dass die Integrität und Authentizität der Software-Pakete
sichergestellt wurde. Hierzu können Prüfsummen bis hin zu digitalen Signaturen für SoftwarePakete verwendet werden.
Beispielsweise ist für den Betrieb von Web-Applikationen ein Applikationsserver erforderlich.
Dieser muss von vertrauenswürdiger Stelle heruntergeladen werden und/oder gegen eine bekannte
Prüfsumme der Anwendung geprüft werden, die von einer vertrauenswürdigen Quelle stammt.
3.2.2.8
Einspielung von Patches, Upgrade von Software-Komponenten
Ein Update von Software bzw. abhängigen Software-Paketen sollte durchgeführt werden, wenn
Schwachstellen bekannt sind, die durch das Einspielen eines entsprechenden Patches beseitigt
werden können. Ebenfalls ist es möglich, dass der Hersteller-Support für bestimmte Versionen eines
Softwarepakets ausläuft. In diesem Fall ist ein Upgrade auf eine aktuellere Version ratsam, um auch
zukünftig mit Software-Patches versorgt zu werden und/oder in Fehlersituationen Unterstützung zu
erhalten.
3.2.2.9
Redundanz von Software-Komponenten
Der Ausfall einer Software-Komponente kann, wie im Abschnitt Fehler: Referenz nicht gefunden
beschrieben, durch verschiedene Faktoren hervorgerufen werden. Durch die Verwendung
redundanter Komponenten kann einem Ausfall entgegengewirkt werden. Redundante Komponenten
können hierbei aktiv am System beteiligt sein, d. h. über Mechanismen wie Lastverteilung
Aufgaben bearbeiten. Passive Komponenten beteiligen sich nur dann am System, sobald eine der
aktiven Komponenten ausgefallen ist.
Insbesondere ist zu untersuchen, ob in einem IT-System Single Points of Failure existieren, deren
Ausfall zu einem Ausfall des Gesamtsystems führen. Für diese Komponenten ist eine redundante
Auslegung erforderlich.
3.2.3
Maßnahmen zur Behebung von Systemausfällen
Durch eine sorgfältige Vorgehensweise während der Entwicklungs- und Testphase sowie
vorbeugenden Maßnahmen während dem Betrieb, lässt sich zwar die Wahrscheinlichkeit eines
Systemausfalls reduzieren, dieser ist jedoch nie auszuschließen. Gründe hierfür können sein:
– nicht in der Testphase entdeckte Fehler in der Software,
– Fehler in der Betriebsumgebung der Software-Komponente (Betriebssystem, Hardware) und
– höhere Gewalt.
In einem solchen Fall ist das Ziel, die Ausfallzeit der Software-Komponente möglichst gering zu
halten. Hierzu sind organisatorische sowie technische Maßnahmen erforderlich, um eine effiziente
Bundesamt für Sicherheit in der Informationstechnik
33
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Behebung der Fehlersituation zu ermöglichen. Die hier besprochenen Maßnahmen konzentrieren
sich auf softwareseitige Aspekte. Hardwareseitige Themen wie die Erstellung eines Ersatzbe­
schaffungsplans werden im Rahmen dieses Dokuments nicht behandelt.
3.2.3.1
Dokumentation der Verfügbarkeitsanforderungen
Für ein IT-System sollte für die jeweils relevanten Software-Komponenten eine Übersicht über
Verfügbarkeitsanforderungen erstellt werden. Hierdurch werden besonders zeitkritische
Komponenten des Systems ausfindig gemacht. Im Falle eines (Teil-)Ausfalls gibt das Dokument
Auskunft über die tolerierbaren Ausfallzeiten und erleichtert die Priorisierung von
Fehlerbehebungsmaßnahmen. Im Zusammenspiel mit den in 3.1.8 beschriebenen Maßnahmen zur
Fehlervorhersage kann die Priorisierung auf Basis der Auswirkungen möglicher Fehler betroffen
werden.
3.2.3.2
Erstellung eines Notfallhandbuchs
Um eine schnelle Reaktion auf Notfallereignisse zu ermöglichen, sollten auch – soweit möglich die Behebung von Teil- bzw. Totalausfällen von Software-Komponenten im Notfallhandbuch
bedacht werden. Das Notfallhandbuch beschreibt die erforderlichen Maßnahmen auf ein derartiges
Notfallereignis.
Wichtig zur Bewertung und Bearbeitung von Notfallereignissen sind unter anderem die vollständige
Dokumentation der möglichen Fehlermeldungen und deren Zuordnung zu den betroffenen
Modulen.
3.2.3.3
Verteilung der Zuständigkeiten
Die Möglichkeit zur Behebung von Fehlersituationen erfordert die Anwesenheit des zuständigen
Personals. Dies umfasst Administratoren der Software-Komponente selbst sowie Zuständige für
Ressourcen, die für den Betrieb der Software-Komponente erforderlich sind. Dies können beispiels­
weise Datenbankadministratoren sein, ebenso Sicherheitsbeauftragte, die gegebenenfalls krypto­
graphische Token, die für den Start und den Betrieb der Software erforderlich sind, sicher
verwahren.
Die Zuständigkeiten sollten in einem Dokument festgehalten werden. Ebenso sollten für jede
Komponente mehrere Zuständige vorhanden sein. Im Falle von Fehlzeiten ist bei der Vertretungs­
regelung zu beachten, dass für jede Komponente die Mindestanzahl zuständiger Personen anwesend
sein sollte.
3.2.3.4
Erstellung eines Wiederanlaufplans
Je nach Komplexität eines IT-Systems kann es erforderlich sein, den Wiederanlaufprozess bei
Ausfall einer Software-Komponente zu dokumentieren. Hierbei müssen gegebenenfalls auch
abhängige Software-Komponenten berücksichtigt werden.
3.2.3.5
Automatisierung des Wiederanlaufs
Soweit der Ausfall einer Software-Komponente durch einen vorübergehenden Fehler hervorgerufen
wurde (beispielsweise durch eine fehlerhafte Reaktion auf eine äußere Eingabe), besteht die
Möglichkeit, durch die Automatisierung des Wiederanlaufs die Ausfalldauer der SoftwareKomponente zu minimieren. Hierzu ist eine Überwachung des jeweiligen Systemprozesses
erforderlich. Auf jeden Fall ist auf ein solches Ereignis hin eine Fehlerdiagnose durchzuführen.
34
Bundesamt für Sicherheit in der Informationstechnik
HV-Kompendium V 1.6
3.2.3.6
Band B, Kapitel 9: Software
Einrichtung eines Referenzsystems
Bei komplexen Anwendungen kann es hilfreich sein, ein zu einem produktiv eingesetzten System
weitestgehend identisches Referenzsystem einzurichten. Dies ermöglicht die Nachstellung von
Fehlersituation oder die Durchführung von Schulungsübungen ohne Beeinflussung des produktiven
Betriebs. Weiterhin besteht die Möglichkeit, dieses System in den Testprozess einbezogen werden,
siehe hierzu Abschnitt 3.1.6.
3.3
Weitere Maßnahmen
3.3.1
Software-Review
Reviews erhöhen die SW-Qualität und die Produktivität von SW-Projekten. Reviews können
unabhängig vom Vorgehensmodell, der Entwicklungsumgebung und der Programmiersprache
eingesetzt werden und sind ein universelles Hilfsmittel für den gesamten Lebenszyklus der
Software. Ein Review (Codeinspektion) besteht aus folgenden Schritten:
– Planung: ein Moderator, der die Code-Inspektionssitzung führt, und die sich auf die Sitzung
vorbereitenden Inspektoren werden benannt. Das Inspektionsmaterial wird gegen
Vorbedingungen (Vertraulichkeit, erforderliche Vorkenntnisse) geprüft und ca. 2 Wochen vor
der Inspektion an die Inspektoren verteilt. Der Sitzungstermin (Inspektionstermin) wird
festgelegt.
– Einführung: eine vom Moderator einberufene, vorbereitende Sitzung dient der Schulung der
Inspektoren für ihre Arbeit.
– Vorbereitung: die Teilnehmer erarbeiten sich anhand der verteilten Unterlagen ihr Verständnis von dem zu inspizierenden Programmcode.
– Inspektion: zum Inspektionszeitpunkt wird die Analyse des Programms durch die Inspektoren
gegen den Autor durchgeführt. Der Moderator leitet dabei die Sitzung, prüft die
Vorbedingungen und protokolliert die (Zwischen-) Ergebnisse.
– Korrektur: die Korrektur umfasst die Beseitigung der während der Inspektion gefundenen
Fehler in einer festgelegten Zeitspanne durch den Autor.
– Nacharbeit: es wird geprüft, ob alle Fehler behoben und mögliche Auswirkungen protokolliert
wurden. Dabei wird entschieden, ob eine weitere Inspektionssitzung erforderlich ist.
Die personelle Zusammensetzung beim Review richtet sich nach der Phase und dem Prüfziel. So
sind beispielsweise beim Review von Spezifikationsdokumenten sowohl Software-Entwickler als
auch Vertreter des Anwendungsbereichs mit einzubeziehen. Bilden beim Review ganz bestimmte
Richtlinien oder Standards die Prüfgrundlage und ist auch die Darstellungsform des Prüfergebnisses
gesetzlich vorgeschrieben, so handelt es sich um sogenannte Audits.
Bundesamt für Sicherheit in der Informationstechnik
35
Band B, Kapitel 9: Software
HV-Kompendium V 1.6
Anhang: Verzeichnisse
Abkürzungsverzeichnis
Ein komplettes Verzeichnis hierzu findet sich in Band AH, Kapitel 5
Glossar
Ein komplettes Verzeichnis hierzu findet sich in Band AH, Kapitel 6
Literaturverzeichnis
Ein komplettes Verzeichnis hierzu findet sich in Band AH, Kapitel 7
36
Bundesamt für Sicherheit in der Informationstechnik
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement