Next: 4.5 Beispiele für Sicherheitsprobleme
Up: 4. Software- und Systemsicherheit
Previous: 4.3 Ansätze
Unterabschnitte
Aus der Perspektive der Hauptschwierigkeiten und genügend großer
Distanz betrachtet, hat die Systemsicherheit große Ähnlichkeit mit
der Softwaretechnik als Ganzes: die Hauptprobleme sind erstens, es gut
zu machen und zweitens, den Versuch dazu überhaupt durchzusetzen.
Allerdings liegt die Schwierigkeit bei der Sicherheit im Gegensatz zur
Softwaretechnik doch eher auf dem zweiten Punkt. Woran liegt das?
Dafür gibt es eine Reihe von miteinander verwandten Gründen:
- 1.
- Sicherheit kostet viel Geld, von dem man nie genau weiß, ob
man es wirklich investieren muß.
- 2.
- Risikoanalyse und Sicherheitsstreben tragen den Geruch des
Negativen und sind deshalb oft schwer vermittelbar.
- 3.
- Das Vorhandensein irgendwelcher Sicherheitsmaßnahmen wird
oft tendenziell mit vollständiger Sicherheit gleichgesetzt.
- 4.
- Auch die gegenteilige Haltung kommt vor: ,,Egal was wir machen,
wir kriegen es ja doch nie sicher.``
- 5.
- Sicherheitsmaßnahmen sind nicht sexy. Sie wirken nicht so
imponierend wie funktionelle Leistungen des Systems und sind deshalb
schwerer zu verkaufen.
- 6.
- Bei gewissen Arten von Risiken trifft man manchmal auf die
Haltung ,,Sicherheit ist was für Spießer``.
In einem gewissen Sinne kann man eine Risikoanalyse eigentlich nur
falsch machen, denn es gibt nur folgende drei Möglichkeiten, und alle
drei sind ungünstig:
Risiken werden überschätzt:
Vermeidbare Vermeidungskosten treten ein, Mittel und Aufmerksamkeit
werden von anderen wichtigen Bereichen abgezogen, evtl. werden
sinnvolle Möglichkeiten ungenutzt gelassen.
Dies ist die unsichtbare Niederlage.
Risiken werden unterschätzt:
Vermeidbarer Schaden tritt ein. Dies ist die klassische Niederlage.
Risiken werden richtig eingeschätzt:
Oft kann später der Wert der Risikoanalyse nicht bewiesen werden,
weil das Eintreten des Unglücksfalls aufgrund der Vorsorge ja gerade
vermieden wurde. Das kann die nächste Risikoanalyse negativ
beeinflussen. Dies ist die indirekte Niederlage.
Aufgrund dieser Effekte ist es ungeheuer schwer, das richtige Maß von
Sicherheitsanstrengungen zu finden und gegen Angriffe von Kritikern zu
verteidigen.
Hinter den Schwierigkeiten beim Durchsetzen von
Sicherheitsanstrengungen stecken, soweit es die Software angeht,
einige falsche Vorstellungen über die Eigenschaften von Software und
Systemen, die Software verwenden. Dies sind Varianten
bekannter Software-Mythen in der speziellen Fassung für sichere Systeme.
- 1.
- Computer sind billiger als die analogen oder elektromechanischen
Systeme, die sie ersetzen.
Das stimmt nicht unbedingt, wegen hoher Kosten für sichere Software.
- 2.
- Software ist leicht zu ändern.
Aber schwer korrekt zu ändern.
- 3.
- Computer sind zuverlässiger als die Geräte, die sie ersetzen.
Sie haben zwar weniger Ausfälle durch Alterung oder Verschleiß,
aber häufigere Versagen durch Softwaredefekte.
Zum Beispiel wurden in der Software des Space Shuttle im Zeitraum
von 1980 bis 1995 immerhin 16 lebensgefährdende SW-Defekte
entdeckt, obwohl die Software mit den höchsten nur denkbaren
Qualitätsansprüchen entwickelt wurde.
- 4.
- Eine Verbesserung der SW-Zuverlässigkeit steigert die Sicherheit.
Korrollar: formale Verifikation kann alle Fehler entfernen.
Beides ist leider nicht notwendigerweise richtig, denn viele
Sicherheitsprobleme
stammen aus falscher Anforderungsdefinition, falscher Spezifikation
oder falschem Systementwurf.
- 5.
- SW-Wiederverwendung steigert die Sicherheit.
Kann sein. Sie kann sie aber auch senken, weil die Komplexität der
Interaktionen nicht überschaut wird. Diese Problematik wird seit
einigen Jahren intensiv im Zusammenhang mit objektorientierter
Software diskutiert. Diese ist zwar durch die Vererbungstechnik
vielversprechend im Hinblick auf Wiederverwendung, erzeugt aber
ebenfalls durch die Vererbung zugleich äußerst komplexe
Wechselwirkungen zwischen Systemteilen, die sehr schwer zu
kontrollieren sind.
Next: 4.5 Beispiele für Sicherheitsprobleme
Up: 4. Software- und Systemsicherheit
Previous: 4.3 Ansätze
Lutz Prechelt
1999-04-13