SOFTWARE: Sicherheitsanalyse von Softwarelösungen

Ausgangslage

Software stellt einen integralen Bestandteil moderner informationstechnischer Systeme und Prozesse dar. Softwareprodukte und einzelne Softwarekomponenten besitzen einerseits eine große Bedeutung für die ordnungsgemäße Funktionsweise von Arbeitsabläufen und Geschäftsprozessen sowie andererseits für die Gewährleistung der Informationssicherheit. Sicherheitsrelevante Funktionen wie Authentifizierung, Autorisierung und Verschlüsselung sind hierbei wichtige Elemente, die keine Sicherheitsschwachstellen aufweisen sollten.

Zielsetzung

Im Rahmen des Sicherheitstests werden nach Absprache sicherheitsrelevante Funktionen des zu testenden Softwareprodukts auf Schwachstellen hin analysiert. Hierbei wird überprüft, ob definierte Schutzziele – wie beispielsweise die Vertraulichkeit, die Verfügbarkeit und die Integrität – gefährdet werden können.

Je nach Softwareprodukt kann das Ziel eines möglichen Angriffs beispielsweise darin bestehen, unautorisierten Zugriff auf bereitgestellte Funktionen oder Daten zu erhalten, eine Rechteausweitung auf dem Zielsystem über das installierte Softwareprodukt durchzuführen, implementierte Schutzmechanismen – wie zum Beispiel eine digitale Rechteverwaltung (Digital Rights Management) – zu umgehen oder geistiges Eigentum (Intellectual Property) bezüglich der Funktionalität des Softwareprodukts zu stehlen.

Durchführung

Die Sicherheitsanalyse von Softwareprodukten findet, sofern möglich, im Labor der SySS innerhalb einer entsprechenden Testumgebung statt. In Abhängigkeit von den verwendeten Technologien des Softwareprodukts, wie beispielsweise Programmiersprachen und Laufzeitumgebungen, sowie von Anforderungen an die Zielplattform, wie etwa Prozessorarchitektur und Betriebssystem, werden hierbei unterschiedliche Werkzeuge und Analysemethoden eingesetzt.

Die Funktionsweise vieler Softwareprodukte ist aufgrund fehlenden Zugangs zum Quelltext (Closed-Source-Produkte) im Gegensatz zu sogenannter Open-Source-Software nicht unmittelbar ersichtlich. Daher werden für die Schwachstellenanalyse von Softwareprodukten, die lediglich in kompilierter Form vorliegen, verschiedene Reverse Code Engineering-Methoden eingesetzt. Hierzu zählen einerseits die statische Codeanalyse von Binärprogrammen unter Verwendung von Softwaretools wie Decompiler (z. B. ILSpy für .NET-Anwendungen oder JD-GUI für Java-Anwendungen) und Disassembler (z. B. IDA Pro oder Hopper für verschiedene ausführbare Dateiformate unterschiedlicher Plattformen) und andererseits die dynamische Codeanalyse unter Verwendung von Softwaretools wie Debuggern (z. B. OllyDbg, x64dbg, dnSpy oder GNU Debugger) und sogenannter Dynamic Binary Instrumentation Tools (z. B. Frida oder DynamoRIO).

Kann der Quelltext für die zu testende Software in Teilen oder vollständig bereitgestellt werden, wird dies für eine Reduzierung des Testaufwands und für eine Verbesserung der Testdurchführung der Sicherheitsanalyse dringend empfohlen.

Mitwirkung des Kunden

Testvorbereitung: Um einen Sicherheitstest einer Softwarekomponente oder eines Softwareprodukts durchführen zu können, muss der SySS die entsprechende Software entweder in lauffähiger Form für die Untersuchung im SySS-Labor oder durch einen entsprechenden Zugang zu einer Testinstanz bereitgestellt werden. Für bestmögliche Testergebnisse sollten keine Einschränkungen bezüglich der Nutzung des Softwareprodukts vorhanden sein. Idealerweise hat die SySS die vollständige Kontrolle über das Testsystem mit der zu untersuchenden Software. Bei Whitebox-Tests von Softwareprodukten sollten der SySS der Quelltext der zu prüfenden Software und Unterlagen wie Handbücher und technische Dokumentationen zur Verfügung gestellt werden.

Ansprechperson: Die verantwortlichen Ansprechpersonen für den Sicherheitstest eines Softwareprodukts sollten innerhalb des Testzeitraums erreichbar sein.

Abhängigkeiten: Organisatorische und technische Abhängigkeiten sollten der SySS mitgeteilt werden. Dies kann im Rahmen des Kick-off-Gesprächs geschehen. Wenn das zu untersuchende Softwareprodukt bzw. die Softwarekomponente beispielsweise nicht isoliert funktionsfähig ist und daher nicht getrennt von anderen Systemen getestet werden kann, muss der SySS mitgeteilt werden, welche Tests an abhängigen Systemen durchgeführt werden können und welche Ansprechpersonen in diesem Fall zur Verfügung stehen.