Funktionstüchtige Umgebung als Voraussetzung
Marc Ruef | 10.12.2012

Sicherheitsüberprüfungen (http://www.scip.ch/?dienstleistungen.auditing) können während verschiedenen Phasen eines IT-Projekts stattfinden. Da gibt es konzeptionelle Reviews (http://www.scip.ch/?dienstleistungen.conceptreview), die in einer frühen Phase herangezogen werden. Oder es gibt Analysetechniken wie Source Code Reviews (http://www.scip.ch/?dienstleistungen.sourcecodeanalysis), die während der Umsetzung bzw. des Aufbaus einer Lösung angegangen werden. Oder es werden Real-World Penetration Tests (http://www.scip.ch/?dienstleistungen.penetrationtest) gefahren, die während dem laufenden Betrieb angesetzt werden.

Eines haben sämtliche Analysemechanismen gemeinsam: Sie wollen eine spezifische Komponente auf ihre theoretische und funktionale Sicherheit hin überprüfen. Dies bedingt, dass die Funktionalität der Komponente in ihrem vorgesehenen Umfang gegeben sein muss. Man spricht hier davon, dass die Zielkomponenten "up and running" sind.

Diese Voraussetzung wird unsererseits in sämtlichen Phasen unserer Projekte deklariert. Sowohl beim Verkaufsgespräch als auch im Rahmen des Vertrags wird dieser Punkt notiert. Und auch beim ersten technischen Kickoff und bei der Anmeldung der jeweiligen Tests wird wiederum auf die Notwendigkeit dessen hingewiesen.

Oftmals sind Kunden aber mit der Funktionalität ihrer Lösungen überfordert. Gerade wenn neu aufgebaute Projekte zeitnah online gehen sollen und man aufgrund des engen Zeitplans unter enormen Druck steht. Dann haben funktionelle Anpassungen höchste Priorität, was sich halt dann eben genau auf die Zuverlässigkeit von Funktions- und Sicherheitstests auswirkt.

Das Ausbleiben der vollen Funktionstüchtigkeit der zu untersuchenden Komponente führt quasi eine Kombination aus Heisenbergsche Unschärferelation und Schrödingers Katze ein. Sicherheitsüberprüfungen kämpfen generell mit dem Problem fehlenden Determinsmus (theoretisch ist er möglich, praktisch kann er aber auch wirtschaftlichen Gründen nicht gewährleistet werden (http://www.computec.ch/projekte/tractatus/?s=tractatus&m=liste&h=2.1.2.6.2&l=6)). Da müssen nicht auch noch andere Unsicherheiten mitgetragen werden.

Als Sicherheitsberater stehen uns zwei intelligente Möglichkeiten zur Verfügung, wie wir in einer solchen Situation reagieren können: a) Entweder wir brechen sofort das Testing ab und verlangen die mehrfach erwähnte Funktionstüchtigkeit; oder b) wir führen das Testing weiter und dokumentieren sämtliche vermuteten Unschärfen, die es zu einem späteren Zeitpunkt erneut anzugehen gilt.

Es liegt nur selten an uns, dass wir hierbei eine Entscheidung herbeiführen und durchsetzen. Viel mehr informieren wir frühzeitig den Kunden über das Problem und legen die beiden Lösungsstrategien vor. Oftmals wird sich für die zweite Variante entschieden, um durch das parellele Testing den Zeitplan nicht noch mehr durcheinander zu bringen und um damit wenigstens die minimalen Anforderungen der IT-Sicherheit erfüllen zu können. Es ist sicher die bessere Lösung. Entscheiden kann man sich jedoch nur noch zwischen Dilemmas.