zurück zum Artikel

Hinter der trockenen Bezeichnung Schutzbedarfsfeststellung des Bundesamts für Sicherheit und Informationstechnik verbergen sich praxisrelevante Hinweise für Entwickler-Teams, wo Prioritäten zu setzen sind.

Hinter der trockenen Bezeichnung Schutzbedarfsfeststellung des Bundesamts für Sicherheit und Informationstechnik verbergen sich praxisrelevante Hinweise für Entwickler-Teams, wo Prioritäten zu setzen sind.

Ein wesentlicher Erfolgsfaktor für den angemessenen Ressourceneinsatz ist die richtige Bewertung der Softwarekomponenten hinsichtlich ihrer potenziellen Auswirkungen auf die Geschäftsprozesse und der daraus resultierenden Risiken. Nur mit einer einheitlichen Bewertung können die Projektverantwortlichen die richtigen und angemessenen Maßnahmen planen und Mehrkosten vermeiden.

Bildlich gesprochen möchte man weder mit Papierkügelchen auf Dinosaurier noch mit Kanonen auf Spatzen schießen. Deswegen ist es gut, zuerst zu wissen, hinter welchem Geschäftsprozess sich der Dinosaurier versteckt, es also um existenzielle Prozesse geht. Dabei können unterschiedliche Ansätze und Methoden angewendet werden. Eine erfolgreiche und in der Praxis bewährte Vorgehensweise ist die vom Bundesamt für Sicherheit und Informationstechnik (BSI) entwickelte Schutzbedarfsfeststellung. Damit wird der Schutzbedarf einer Anwendung oder eines Geschäftsprozesses in Bezug auf die Verfügbarkeit, Vertraulichkeit und Integrität bewertet. Eigentlich geht es dabei darum, ein geeignetes Sicherheitskonzept für das Unternehmen zu entwickeln. Die Methode orientiert sich an den möglichen Schäden, die mit einer Beeinträchtigung der betroffenen Anwendungen und damit der jeweiligen Geschäftsprozesse (z. B. durch einen Softwarefehler) verbunden sind [1].

Doch diese eignet sich auch bestens für die Einschätzung von Softwareprojekten, wie der Artikel exemplarisch an den Prüftechniken im Testmanagement zeigt.

Die Spatzen und Dinosaurier trennen

Zunächst ist der Schutzbedarf gemäß der Empfehlung des BSI in Schadensklassen zu unterteilen. Zusätzlich zu den drei Standardklassen des BSI hat sich die Aufnahme der Klasse "gering" bewährt [1]:

• gering: keine nennenswerten Schadensauswirkungen.
• normal: Die Schadensauswirkungen sind begrenzt und überschaubar.
• hoch: Die Schadensauswirkungen können beträchtlich sein.
• sehr hoch: Die Schadensauswirkungen können ein existenziell bedrohliches katastrophales Ausmaß erreichen.

Zur Abgrenzung der Schutzbedarfskategorien empfiehlt das BSI, die Grenzen für die einzelnen Schadensszenarien zu bestimmen. Die vom BSI vorgeschlagenen Tabellen zur Einstufung der Kategorie "normal", "hoch", "sehr hoch" haben sich bewährt. Zusätzlich wurde der Vorschlag auf die Schutzbedarfskategorie "gering" angewendet. Die Tabellen 1, 2, 3 und 4 stellen die einzelnen Schadenszenarien in Abhängigkeit zur Einstufung dar.

Unter Beachtung des Grundsatzes "keep it simple" sollte der Projektleiter die Schadensszenarien an das Unternehmen anpassen sowie darüber hinaus die individuellen Gegebenheiten der Institution berücksichtigen: Ist in einem Großunternehmen ein Schaden in Höhe von 200.000 Euro gemessen am Umsatz und am IT-Budget gering, kann für ein Kleinunternehmen schon ein Schaden in Höhe von 10.000 Euro existenziell bedrohlich sein [1]. Eine monetäre Bezifferung der Auswirkung vereinfacht die Bewertung durch das Projekt deutlich.

Beispiel

Verdeutlichung am Beispiel

Als Nächstes sollte die Anwendung in Komponenten unterteilt werden. Hilfreich bei der Klassenbildung ist die Orientierung an den Geschäftsprozessen. Bei der Klassenbildung ist darauf zu achten, dass Komponenten mit unterschiedlicher Einschätzung auch differenziert betrachtet werden. Erst durch die Differenzierung kann eine angemessene Maßnahmenplanung für die Komponente oder den Geschäftsprozess erfolgen. Bei einer überwiegend hohen bis sehr hohen Einstufung sollte man die Aufteilung der Geschäftsprozesse hinterfragen. Das ist normalerweise ein Indiz für eine zu grobe Trennung.

Die Handhabung wird nun anhand des Beispiels "Einsatz einer Telefonaufzeichnung für das Telefonbanking in einer Bank" durchgespielt. Das Ergebnis der Bewertung sollte wie in Tabelle 5 oder in ähnlicher Form festgehalten werden, damit die Einschätzung für das Projektteam jederzeit transparent und nachvollziehbar ist. Die Bewertung sollte der Projektleiter gemeinsam mit dem Fachbereich kritisch hinterfragen.

Nach der Feststellung des Schutzbedarfs und dem daraus resultierenden Risiko lässt sich diese Einstufung im Projekt zur Planung der weiteren Maßnahmen heranziehen. Das Beispiel der Software-Prüftechniken demonstriert das nun.

Im Beispielprojekt haben sich die Projektleitung und das Testmanagement im Wesentlichen auf die folgenden Prüfarten verständigt:

1. Whitebox-Test durch die Entwickler
2. Blackbox-Test durch die Tester in den Ausprägungen [2] Ad-hoc- und funktionsorientierter Test

Auf weitere Prüftechniken und -stufen (u. a. Anwendungs-, Integrationstest) geht der Artikel zur Erläuterung der risikobasierten Vorgehensweise nicht ein. Sie sind im jeweiligen Projekt natürlich auch zu beachten.

Mit dem Whitebox-Test stellt der Entwickler die grundsätzliche Funktionsfähigkeit seiner Software mit Codeanalyse und -Reviews sicher. Erst nach dem bestandenen Whitebox-Test übergibt er die Software an das Testmanagement. Das Testteam ermittelt anschließend im Blackbox-Test die Testfälle anhand der Anwendungs- beziehungsweise Systemdokumentation. Im funktionsorientierten Test kommen die Äquivalenzklassenbildung, Ursachen-Wirkungs-Analyse, Entscheidungstabellen und die Grenzwertanalyse zum Einsatz. Bei der Testdatenerstellung berücksichtigen die Tester mindestens die Unter-, Ober- und Mittelwerte bei den Eingabedaten.

Beim Ad-hoc-Test wird auf eine systematische Vorgehensweise verzichtet, stattdessen bildet man übliche Geschäftsvorfälle ab. Bei der Testdatenerstellung ziehen die Beteiligten typische beziehungsweise praxisrelevante Werte heran. Durch den Verzicht beim Ad-hoc-Test auf Dokumentation und systematische Herangehensweise lässt sich mit dieser Prüftechnik deutlich Aufwand sparen. Die zwei Ansätze unterscheiden sich damit wesentlich in der Testabdeckung. Beim funktionsorientierten Ansatz wird im Vergleich zum Ad-hoc-Test eine deutlich höhere Testabdeckung erreicht. Ohne die zuvor durchgeführte Kategorisierung wären nun unter Risikogesichtspunkten für alle Komponenten ein Whitebox-Test und der funktionsorientierte Test durchzuführen. Alles andere wäre hinsichtlich des Qualitätsergebnisses zufällig.

Nach Festlegung des Schutzbedarfs und der Prüftechniken kann die Zuordnung der Prüftechnik erfolgen. Die Schutzbedarfsausprägung "Vertraulichkeit" hat nur indirekt Auswirkungen auf den Testumfang. Vielmehr sind daraus entsprechende Sicherheitsanforderungen abzuleiten. Die Vertraulichkeit lässt sich in dieser Betrachtung vernachlässigen. Die Zuordnung sollte gemeinsam mit dem Auftraggeber beziehungsweise Fachbereich erarbeitet werden. Auf Basis der Zuordnung in Tabelle 6 kann man nun die konkret anzuwendende Prüftechnik auswählen. Das Ergebnis der Prüftechnikauswahl für Beispielkomponenten dokumentiert Tabelle 7. Bei einer abweichenden Einstufung der Ausprägung Verfügbarkeit und Integrität wird die höchste Schutzbedarfskategorie ausgewählt.

Fazit

Nun hat der Leser eine einfache Methode zur Einschätzung der Risiken auf die Geschäftsprozesse erhalten und kann jetzt mit Papierkugeln auf Spatzen und mit Kanonen auf Dinosaurier schießen. Wichtig ist nun, den Aufwand für die Entwicklung und den Test in Abhängigkeit zum Risiko zu setzen und eine Ressourcenverschwendung zu vermeiden.

Abhängig vom Risiko, das aus der Komponente resultiert, kann der Projektleiter angemessene Maßnahmen einplanen, auch hat er ein klares und transparentes Regelwerk. Die Festlegung der Prüftechniken ist nicht mehr dem Zufall oder der Willkür überlassen. Unabhängig von der Festlegung der Prüftechnik liegt eine klare Vorgabe zur Notfallvorsorge vor – dem ursprünglichen Zweck der Methode. Zum Beispiel macht es wenig Sinn, ein Testteam auf eine Komponente zu jagen, die nur einen maximalen Schaden von wenigen hundert Euro verursachen kann und mehrere Tage ausfallen darf. In dem Fall reichen gegebenenfalls schon die Entwicklertests aus, und es lässt sich auf eine zusätzliche Teststufe verzichten.

Marc Schiffer
arbeitet als IT-Projektleiter in einem führenden Finanzkonzern. Er ist seit über elf Jahren in der IT im Finanzwesen beschäftigt.

Literatur

1. Bundesamt für Sicherheit in der Informationstechnik; BSI-Standard 100-2 IT-Grundschutz-Vorgehensweise [1], Version 2.0
2. Peter Liggesmeyer; Software-Qualität: Testen, Analysieren und Verifizieren von Software; Spektrum Akademischer Verlag, 2002
3. Helmut Balzert; Lehrbuch der Software-Technik, Bd. 1: Software-Entwicklung; Spektrum Akademischer Verlag, 2000 (2. Aufl.)
4. Glenford J. Myers; Methodisches Testen von Programmen; Oldenbourg, 2001 (7. Aufl.)

(ane [2])

URL dieses Artikels:
https://www.heise.de/-1812494

Links in diesem Artikel:
[1] http://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1002_pdf.pdf%29
[2] mailto:ane@heise.de

Copyright © 2013 Heise Medien