Penetration Testing ist nicht alles Softwareentwicklung – ohne Sicherheitskonzept keine sichere Anwendung

In der Softwareentwicklung kommt die Sicherheit häufig nicht über den Status eines Add-on-Features hinaus. Unsicher entwickelte Applikationen untergraben nur allzu oft die Unternehmenssicherheit und führen zu weitreichenden Schäden. Was fehlt ist ein Sicherheitskonzept, das die Risiken der jeweiligen Applikation berücksichtigt.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

TXOne Networks

Specops Software GmbH

(ISC)2 Inc.

Sichere Anwendungsentwicklung bedeutet mehr als die Penetrationstests am Ende des Entwicklungsprozesses. Alle am Entwicklungsprozess beteiligten Personen müssen vielmehr Sicherheit als wichtiges Qualitätsmerkmal verstehen.

Am Anfang eines Entwicklungsprojekts sollten Sicherheitsanforderungen und Risiken auf der Geschäftsebene identifiziert und festgehalten werden. Nur darauf aufbauend kann anschließend ein angemessenes Sicherheitskonzept für die Applikation erarbeitet werden.

Softwareanforderungen und Sicherheit

In der Anforderungsanalyse muss folglich nicht nur die fachliche Funktionalität berücksichtigt werden, sondern auch die Sicherheit. Es gilt die richtigen Weichen zu stellen, damit zeit- und kostspielige Nachjustierungen im Nachhinein nicht mehr notwendig sind.

Für dieses Vorhaben erweist es sich als hilfreich, wenn bereits ein Information-Security-Management-System (ISMS) etabliert ist, das auf bewährten Standards wie ISO 27001 basiert. Innerhalb des ISMS werden Richtlinien und Prozesse beschrieben, die eine Grundlage dafür schaffen, Risiken und Bedrohungen zu identifizieren und bestmöglich kontrollierbar zu machen.

Die dabei zu erarbeitenden Richtlinien, Konzepte und Handlungsanweisungen regeln auch Bereiche der Applikationsentwicklung und des sicheren Betriebs. Sie bieten ein Grundgerüst für das Sicherheitskonzept der zu entwickelnden Software.

Beispielsweise empfiehlt der ISMS-Standard ISO 27001 im Control A.12.2.1, dass alle Daten, die in eine Applikation eingegeben werden, auf ihre Richtigkeit und Zweckmäßigkeit überprüft werden sollten. Dabei handelt es sich um eine grundlegende Maßnahme, um typische Applikationsschwachstellen, wie SQL-Injection und Cross-Site-Scripting zu verhindern.

Seite 2: Bewährte Sicherheitsmechanismen integrieren

Bewährte Sicherheitsmechanismen integrieren

Eine weitere Quelle für Anforderungen bildet ein bestehendes Betriebsumfeld, in das die neue Applikation integriert werden soll. In der Regel sind hier bereits Sicherheitsmaßnahmen bzw. -infrastrukturen etabliert, die man berücksichtigen sollte. Dadurch kann auf bewährte Verfahren zurückgegriffen werden.

Viele Unternehmen nutzen zum Beispiel eine zentrale Authentifizierungsinfrastruktur (z.B. den CA SiteMinder Web Access Manager), um nicht nur eine Single-Sign-On-Funktion zu bieten, sondern auch Anforderungen aus der Security-Policy des Unternehmens (z.B. Passwort-Regelungen, Anforderungen an das Benutzermanagement, etc.) zentral umsetzen zu können. In einem solchen Fall müssen neue Applikationen das Rad nicht neu erfinden, sondern können bewährte Sicherheitsmaßnahmen wiederverwenden.

Die letzte und wichtigste Quelle für Anforderungen bildet der Fachbereich, der eine Applikation anfordert. Die fachlichen Funktionalitäten einer Anwendung werden typischerweise mit dem Fachbereich abgestimmt und in Use Cases (Anwendungsszenarien) erfasst.

Um ein umfassendes Bild für die notwendige Sicherheit der Applikation zu erhalten, empfiehlt es sich auch mit dem Fachbereich abzuklären, welche Szenarien unerwünscht sind. Diese können analog als sognenannte Abuse Cases (Missbrauchsszenarien) dokumentiert werden.

Betrachtet man beispielsweise eine Ausschreibungsplattform mit einem Use Case „Angebotsabgabe“, der beschreibt, wie Anbieter ihre Angebote einstellen können, kann ein zugehöriger Abuse Case „Zugriff auf andere Angebote“ in Verbindung mit den Anbietern wie folgt dokumentiert werden: „Einem Anbieter A soll es nicht möglich sein, Angebote vom Anbieter B einzusehen.“

Solche Abuse Cases liefern aus fachlicher Sicht ein wichtiges Mittel für die Bedrohungs- und Schwachstellenanalyse und dienen auch als Grundlage für die Ausarbeitung des Berechtigungskonzepts als Bestandteil des umfassenden Sicherheitskonzepts.

Seite 3: Sicherheit in den restlichen Entwicklungsphasen

Sicherheit in den restlichen Entwicklungsphasen

Nachdem die Anforderungen ermittelt wurden, muss das Sicherheitskonzept in der Designphase ausgearbeitet und spezifiziert, in der Implementierungsphase umgesetzt und schließlich in der Testphase abschließend geprüft werden. Das Sicherheitskonzept bildet das zentrale Dokument, um sicherzustellen, dass die Sicherheit entlang des gesamten Entwicklungsprozesses angemessen berücksichtigt wird.

In der Designphase werden im Sicherheitskonzept die notwendigen Sicherheitskomponenten und -maßnahmen abgeleitet, die notwendig sind, um die ermittelten Sicherheitsanforderungen zu erfüllen. Dazu ist es notwendig Bedrohungsszenarien und zugehörige Schwachstellen zu identifizieren, die zu einer Nichterfüllung von Anforderungen bzw. zu Schäden führen könnten.

Grundlegende Sicherheitsmaßnahmen sind: Authentisierung, Autorisierung, Eingabevalidierung und Ausgabemaskierung, sichere Übertragung und zugriffsgeschützte Speicherung von Daten, Protokollierung kritischer Ereignisse und Fehlerbehandlung.

Implementierungs- und Testphase

Während der Implementierungsphase spielen Source-Code-Reviews eine entscheidende Rolle. Diese sollten eingesetzt werden, um typische Programmierfehler und Sicherheitselemente, die sich leicht überwinden lassen, zu identifizieren. Diese Maßnahme hilft, sich vor möglichen Fehlern und Sicherheitsschwachstellen im Code zu schützen.

Es wäre jedoch ein Fehler, sich allein auf die Reviews zu verlassen. Besser ist es, die beteiligten Entwickler durch Richtlinien für sicheres Programmieren zu unterstützen und damit die Fehlerquote möglichst niedrig zu halten.

In der Testphase wird die neu entwickelte Software schließlich auf Herz und Nieren überprüft. Dafür stehen zwei verschiedene Testmethoden zur Verfügung: Sicherheits- und Penetrationstests. Mit Hilfe der Sicherheitstests soll bewiesen werden, dass die Applikation sich resistent bei Verstößen gegen die festgelegten Sicherheitsanforderungen verhält. Implementierte Sicherheitsmaßnahmen dürfen nicht umgehbar sein.

Wie bei den fachlichen Tests werden Testfälle definiert, die die Wirksamkeit der Sicherheitsmaßnahmen überprüfen. Hier kommen auch die Abuse Cases aus der Anforderungsanalyse wieder zum Einsatz, aus denen Testfälle abgeleitet werden können.

Seite 4: Penetrationstests

Penetrationstests

Bei einem Penetrationstest geht es darum, Angriffe zu simulieren und die Sicherheit der Applikation abschließend zu prüfen. Damit sollten Personen oder Gruppen betraut werden, die nicht am bisherigen Software-Entwicklungsprozess beteiligt waren.

Durch die Unabhängigkeit, also eine unbefangene Sicht auf die Applikation, wird von neuem versucht, Schwachstellen im gesamten Design der Applikation zu identifizieren. Penetrationstests sollten immer von Experten durchgeführt werden, die über eine langjährige Erfahrung und ein breites Wissen um Angriffstechniken verfügen.

Im Gegensatz zur Designphase kommt es nicht darauf an, konstruktiv für alle Sicherheitsanforderungen geeignete Sicherheitsmaßnahmen zu definieren. Vielmehr sollen die Tester auf destruktive Weise die Schwächen der Applikation herausfinden, indem sie die Widerstandsfähigkeit angenommener Sicherheitsfunktionen testen.

In dieser Testphase kommen spezielle Tools zum Einsatz, die den Datenverkehr analysieren und in geeigneter Weise manipulieren können, z.B. Veränderung von Werten, die durch die Applikation fest vorgegeben werden. Darüber hinaus gibt es Tools, die die Applikation mit einer Vielzahl von zufällig generierten Eingaben bombardieren um die Robustheit und Wirksamkeit der Sicherheitsmaßnahmen testen.

Die fünf Phasen des Penetration Testing

Zum Thema Penetrationstests gibt es auch eine BSI-Studie mit dem Titel „Durchführungskonzept für Penetrationstests“, die als Orientierung sehr nützlich ist. Die Studie beschreibt fünf entscheidende Schritte: Vorbereitung, Informationsbeschaffung und -auswertung (Blackbox/Whitebox), Bewertung der Informationen/Risikoanalyse, aktive Eindringversuche und Analyse.

In der Vorbereitungsphase werden die Testparameter abgesteckt und definiert. Das beinhaltet die folgenden Aspekte: Informationsbasis (Blackbox/Whitebox), Aggressivität (passives Scannen, vorsichtig, systematisch, aggressiv), Umfang (betroffener Bereich), Vorgehensweise (verborgen/sichtbar), Technik (Netzwerkzugriff, andere Kommunikationskanäle, physikalischer Zugriff, Social Engineering) und Ausgangspunkt (extern/intern).

In der Informationsbeschaffungs- und Auswertungsphase gilt es, so viele relevante Informationen wie möglich zusammenzutragen. Hierbei müssen alle Services, Prozesse, die genutzten Geräte und Komponenten, die Netzwerkstruktur, die genutzte Technologie und die Frameworks ermittelt werden. Die gesammelten Informationen werden anschließend zusammengeführt, um potenzielle Schwachstellen und daraus resultierende Angriffsziele für Hacker zu identifizieren. Dazu werden automatisierte und manuelle Methoden, sowie verschiedene Tools verwendet.

Abschließend werden die Ergebnisse mit Hilfe festgelegter Kriterien danach bewertet, wie einfach es für einen Angreifer ist, die jeweilige Schwachstelle zu finden und sie für einen erfolgreichen Angriff zu nutzen. Diese Bewertung soll zu einer objektiven Einschätzung der jeweiligen Bedrohung führen. Als Basis für die Bewertung empfiehlt es sich, einen bewährten Kriterienkatalog wie die Common Methodology for Information Technology Security Evaluation (CEM) zu nutzen.

Die Ergebnisse der gesamten Testphase müssen denen der durchgeführten Softwarerisiko- und Anforderungsanalyse hinzugefügt werden. Nun lässt sich abschätzen, ob weitere Sicherheitsmaßnahmen notwendig sind. Spätestens jetzt zeigt sich, ob das Sicherheitskonzept sorgfältig ausgearbeitet und konsequent durchgeführt worden ist. Wenn ja, dann haben Sie einen großen Schritt dahin gemacht, die neue Applikation sicher zu machen.

Markus Wutzke

Markus Wutzke ist (ISC)²-zertifizierter CSSLP und Experte für sichere Software- und Systementwicklung.

(ID:2046092)