Wie BSI-Anforderungen zur sinnvollen Ressourcenzuteilung führen

Inhaltsverzeichnis

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.

Schutzbedarfskategorie "gering"
Verstoß gegen Gesetze/Vorschriften/Verträge	Keine Auswirkung auf Gesetze oder Verträge
Beeinträchtigung des informationellen Selbstbestimmungsrechts	Es werden keine personenbezogenen Daten verarbeitet.
Beeinträchtigung der persönlichen Unversehrtheit	Eine Beeinträchtigung erscheint nicht möglich.
Beeinträchtigung der Aufgabenerfüllung	Die maximal tolerierbare Ausfallzeit ist größer als 72 Stunden. Die Beeinträchtigung würde von den Betroffenen als vernachlässigbar eingeschätzt werden.
Negative Innen- oder Außenwirkung	Keine Auswirkungen erwartet
Finanzielle Auswirkungen	Kein finanzieller Schaden zu erwarten

Schutzbedarfskategorie "normal"
Verstoß gegen Gesetze/Vorschriften/Verträge	Geringfügige Vertragsverletzungen mit maximal geringen Konventionalstrafen Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen
Beeinträchtigung des informationellen Selbstbestimmungsrechts	Es handelt sich um personenbezogene Daten, durch deren Verarbeitung der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen beeinträchtigt werden kann.
Beeinträchtigung der persönlichen Unversehrtheit	Eine Beeinträchtigung erscheint nicht möglich.
Beeinträchtigung der Aufgabenerfüllung	Die maximal tolerierbare Ausfallzeit liegt zwischen 24 und 72 Stunden. Die Beeinträchtigung würde von den Betroffenen als tolerabel eingeschätzt werden.
Negative Innen- oder Außenwirkung	Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.
Finanzielle Auswirkungen	Der finanzielle Schaden bleibt für die Institution tolerabel.

Schutzbedarfskategorie "hoch"
Verstoß gegen Gesetze/Vorschriften/Verträge	Vertragsverletzungen mit hohen Konventionalstrafen Verstöße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen
Beeinträchtigung des informationellen Selbstbestimmungsrechts	Es handelt sich um personenbezogene Daten, bei deren Verarbeitung der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt werden kann.
Beeinträchtigung der persönlichen Unversehrtheit	Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden.
Beeinträchtigung der Aufgabenerfüllung	Die maximal tolerierbare Ausfallzeit liegt zwischen einer und 24 Stunden. Die Beeinträchtigung würde von einzelnen Betroffenen als nicht tolerabel eingeschätzt.
Negative Innen- oder Außenwirkung	Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.
Finanzielle Auswirkungen	Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch nicht existenzbedrohend.

Schutzbedarfskategorie "sehr hoch"
Verstoß gegen Gesetze/Vorschriften/Verträge	Vertragsverletzungen, deren Haftungsschäden ruinös sind Fundamentaler Verstoß gegen Vorschriften und Gesetze
Beeinträchtigung des informationellen Selbstbestimmungsrechts	Es handelt sich um personenbezogene Daten, bei deren Verarbeitung eine Gefahr für Leib und Leben oder die persönliche Freiheit des Betroffenen gegeben ist.
Beeinträchtigung der persönlichen Unversehrtheit	Gefahr für Leib und Leben. Gravierende Beeinträchtigungen der persönlichen Unversehrtheit sind möglich.
Beeinträchtigung der Aufgabenerfüllung	Die maximal tolerierbare Ausfallzeit ist kleiner als eine Stunde. Die Beeinträchtigung würde von allen Betroffenen als nicht tolerabel eingeschätzt werden.
Negative Innen- oder Außenwirkung	Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung, eventuell sogar existenzgefährdender Art, ist denkbar.
Finanzielle Auswirkungen	Der finanzielle Schaden ist für die Institution existenzbedrohend.

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.

Bezeichnung	pers. Daten	Grundwert	Schutzbedarf
Telefonbanking: Aufzeichnung und Entgegennahme eines Kundenauftrags	x	Vertraulichkeit	sehr hoch
		Integrität	sehr hoch
		Verfügbarkeit	hoch
User-Neuanlage-Berater	-	Vertraulichkeit	gering
		Integrität	normal
		Verfügbarkeit	gering
Logfile für IT-Betrieb	-	Vertraulichkeit	gering
		Integrität	gering
		Verfügbarkeit	gering

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.

Schutzbedarfsausprägung	Schutzbedarfskategorie	Prüftechniken
Verfügbarkeit	hoch/sehr hoch	Whitebox-, funktionsorientierter Test
Verfügbarkeit	Normal	Whitebox-, Ad-hoc-Test
Verfügbarkeit	Gering	Whitebox-Test
Integrität	hoch/sehr hoch	Whitebox, funktionsorientierter Test
Integrität	Normal	Whitebox-, Ad-hoc-Test
Integrität	Gering	Whitebox-Test

Komponente	Schutzbedarf	Anzuwendende Testfallermittlungsart
Telefonbanking: Aufzeichnung und Entgegennahme eines Kundenauftrags	sehr hoch	Whitebox-, funktionsorientierter Test
User-Neuanlage-Berater	normal	Whitebox-, Ad-hoc-Test
Logfile für den Betrieb	gering	Whitebox-Test

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, 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)