QAMP – auf dem Weg zum Software Quality Engineering, Teil 4

Inhaltsverzeichnis

Softwareentwickler müssen Schulungen zur Applikationssicherheit erhalten, damit sie hinsichtlich der Sicherheit die richtigen Entscheidungen treffen können. Eine bekannte Sicherheitszertifizierung ist der "Certified Professional for Secure Software Engineering" (CPSSE), der sich auch als optionales Modul der QAMP-Zertifizierung heranziehen lässt.

In letzter Zeit spricht man zunehmend von der Notwendigkeit, auf die Applikationssicherheit zu achten. Doch was ist darunter genau zu verstehen? Geht es bei ihr um das Verwenden von Hacking-Techniken, um Sicherheitslöcher zu finden? Oder vielleicht um eine sichere Anwendungsarchitektur? Oder beschreibt der Begriff eine Gruppe von Techniken, die die Sicherheit von – eigentlich unsicheren – Anwendungen übernehmen, wie Web Application Firewalls?

Mehr Infos

QAMP – die Artikelserie

• QAMP-Einführung, ISTQB Certified Tester
• IREB Certified Professional for Requirements Engineering
• iSQI Certified Professional for Project Management
• ISSECO Certified Professional for Secure Software Engineering
• ECQA Certified Innovation Manager

Applikationssicherheit umfasst zwar alle diese Aspekte, geht aber weiter. Es ist ein methodischer Aspekt der Softwareentwicklung, von Anfang an auf Sicherheit zu achten und gegebenenfalls diese mit speziellen Tools zu ergänzen. Die folgende Übersicht versucht einen Überblick über die verschiedenen Aspekte von Applikationssicherheit zu geben. Die besprochenen Inhalte werden in der Zertifizierung "Certified Professional for Secure Software Engineering" (CPSSE) des Vereins ISSECO (International Secure Software Engineering Council) geprüft, die man auch als Teil der QAMP-Zertifizierung ablegen kann.

In der CPSSE-Zertifizierung werden sechs, den gesamten Anwendungslebenszyklus abdeckende Phasen des sicheren Software-Engineerings beschrieben, auf die im Folgenden eingegangen sei.

1. Security Requirements

Schon während der ersten Phase eines typischen Softwareprojekts ist es wichtig, an Sicherheit zu denken. Die Sicherheitsanforderungen sollten explizit beim Kunden eingeholt werden, auch wenn sie selbstverständlich erscheinen. Es ist von großem Vorteil, die Sicherheitsanforderungen explizit zu beschreiben, damit sie sich später in der Testphase validieren lassen. Wichtig dabei ist, gerade im Hinblick auf Sicherheit zu unterscheiden, ob eine Anforderung "funktional" – also die Existenz bestimmter Funktionen fordert – oder "nichtfunktional" ist – wenn die Software eine bestimmte Eigenschaft haben soll. Anforderungen für Softwaresicherheit sind oft nichtfunktional und deswegen schwer zu testen.

2. Secure Design

Die wichtigste Softwareentwicklungsphase im Hinblick auf Sicherheit ist das Secure Design: In dieser Phase gemachte Fehler sind extrem teuer in der Behebung und oft auch nicht durch zusätzliche Tools auszugleichen. Ein sicheres Design erfordert die Verwendung etablierter Sicherheitsmechanismen, sogenannter "Security Patterns", etwa eine sichere Kommunikation über SSL. Die Auswahl geeigneter Security Patterns ist ebenso wichtig wie eine auf Sicherheit überprüfte Architektur der Software. Diese Prüfung kann durch ein "Threat Modeling" erfolgen, das Angriffsszenarien nach Erfahrungswerten, aber auch einer Reihe methodischer Vorgehensweisen (wie Angriffsbäume, ähnlich zu Fehlerbäumen) durchspielt. Das Ergebnis dieser Phase ist womöglich ein Redesign der Software, ergänzt durch zusätzliche Sicherheitsanforderungen und eine Sicherheitsarchitektur des Produkts.

3. Secure Coding

Diese Phase halten üblicherweise die meisten Softwareentwickler für die "eigentliche" Arbeit zum sicheren Programmieren, und in der Tat ist die Zielsetzung dort am offensichtlichsten. In ihr geht es darum, Coding-Fehler zu vermeiden, die Angreifern helfen, die Software "knacken" zu können. Dabei klassifizieren die Entwickler die Techniken nach den Angriffsmustern, etwa SQL-Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) und Insecure Direct Object Reference. Gegen diese Angriffe helfen Input- und Output-Validierung, Least Privilege sowie weitere Mechanismen zur sicheren Programmierung.

4. Security Testing

Das Testen von Softwaresicherheit ist ebenfalls relativ weit verbreitet und wird von vielen Beratungsunternehmen als Dienstleistung angeboten. Es gibt drei große Klassen von Testverfahren:

1. Blackbox-Tests, bei denen die Tester keinen Zugriff auf das Coding oder die Dokumentation haben.

2. Whitebox-Tests, bei denen den Testern der Zugriff auf den Quellcode, Designunterlagen et cetera möglich ist.

Bei beiden Verfahren versuchen die Tester, die Software zu "knacken", also Angriffe durchzuführen, um Schwachstellen zu identifizieren. Schließlich gibt es noch:

3. das klassische Softwaretesten, bei dem die Entwicklung von Test-Cases und deren Überprüfung das Erfüllen der Anforderungen realisieren.

Wichtig dabei ist, dass Softwareentwicklungsprojekte Sicherheit meist mit sogenannten "Negativtests" testen, in denen sie bestimmte Funktionen ausschließen, statt dass sie (bei "Positivtests") eine erforderliche Funktion auf Korrektheit prüfen. Um das sinnvoll einzusetzen, ist eine gute Vorbereitung in der Phase des Requirements Engineering erforderlich, insbesondere bei den nichtfunktionalen Sicherheitsanforderungen.

5. Secure Deployment

Software läuft immer in einer bestimmten Umgebung (auf einem Betriebssystem, mit einem Webbrowser et cetera). Diese ist oft die Quelle von Sicherheitsproblemen, insbesondere im Zusammenspiel mit Schwachstellen der neu entwickelten Software. Entsprechend sind die Sicherheitsanforderungen unter Umständen auch auf die Konfiguration der bestehenden Softwareumgebung anzuwenden, beziehungsweise es sind weitere Sicherheitstools und -techniken von Nöten, um die geforderte Sicherheit erreichen zu können (etwa: sicheres Konfigurieren des Webservers und Einsatz von SSL).

Zudem muss gewährleistet sein, dass der Installationsprozess selbst keine Sicherheitsschwachstellen hinterlässt, etwa durch Einrichten von Test-Accounts. Das "Scharf-Schalten" von Software (zum Beispiel das Abstellen erweiterter Fehlerinformation und Zugriffsmöglichkeiten über das Web für Administratoren) gehört ebenfalls in diese Phase.

6. Security Response

Keine Software ist fehlerfrei, und erfolgreiche Angriffe wird es immer geben. Auch wenn diese These vielleicht nicht immer zutrifft, stellt sie doch eine gute Arbeitshypothese dar, da sie auffordert, Vorsorge zu tragen für den Fall, dass schließlich ein Angriff gefunden wird. Um auf entdeckte Sicherheitsschwachstellen angemessen zu reagieren, ist eine Vorbereitung innerhalb der Entwicklungsorganisation erforderlich, und oft ist es sinnvoll, hierfür eine eigene Spezialistengruppe einzusetzen. Denn im Gegensatz zu vielen Standardsoftwarefehlern ist bei Sicherheitsproblemen zu entscheiden, wann ein Fehler dem Kunden kommuniziert wird: Eventuell ergibt es Sinn, ihn schon zu informieren, auch wenn noch kein Patch vorhanden ist, damit der Kunde selbst Vorsorge tragen kann.