Die Sicherheit von Software, insbesondere von webbasierten Anwendungen, gewinnt immer mehr an Bedeutung. Denn zum einen nimmt die Anzahl an erfolgreichen Hackerangriffen stetig zu, zum anderen steigt die Nutzung von Cloud-basierter Softare (=webbasierte Software) stetig an, und damit auch das Datenvolumen, das dem Risiko von Hackerangriffen bzw. Leakages ausgesetzt wird.

Eine kürzliche veröffentliche TOP5 Liste der weltweit größten Hacks in einem Artikel der CNBC zeigt auf, dass auch bei großen Playern der Digitalisierungsökonomie der Sicherheitsstandard keineswegs ausreicht; die TOP5 Liste zeigt vor allem auf, dass wir Data Leakages in einem ungeheuren Ausmaß erleben:

Die Anforderung an eine hohe Sicherheit gehört mithin in den Anforderungskatalog bei jedem Softwareentwicklungsprojekt – unabhängig von der Technologie, in der die Software entwickelt wird. Product Manager, IT Projektmanageer und auch Projekleiter bei beauftragenden Unternehmen müssen zwingend ein Grundverständnis für IT Sicherheit und Begriffe wie Sicherheitsarchitektur, architekturelles Sicherheitsreview oder Secure Coding Guidelines mitbringen.

Das Rezept für Sichere Software: Vorgaben, Prozesse, Technologien, Personen

Die Geschwindigkeit der Entwicklung bei vielen Playern der Digitalen Ökonomie ist bisweilen schwindelerregend, unter dem Stichwort DevOps werden mehrmals am Tag neue Releases produktiv gesetzt, bei manchen Unternehmen im Minutentakt. Es ist naheliegend, dass unter diesen Bedingungen besondere Anstrengungen unternommen werden müssen, um die Anwendungssicherheit sicherzustellen.

Vor allem größere Unternehmen veranstalten hierfür auch sogenannte Hacking Events, bei dem White Hat Hacker und Sicherheitsexperten eingeladen sind, eine Software zu hacken, sprich: Sicherheitslücken aufzudecken; üblicherweise werden hier sogenannte Bug Bountys ausgelobt, von wenigen Tausend Euro bis hin zu über 100.000 EUR. Je nach Bug Finding. Auch Apple hat gerade sein Bug Bounty Programm deutlich ausgebaut.

Ein Hacking Events ist aber immer nur das Sahnehäubchen auf einer Sicherheitsstrategie. Wirklich zentral sind vor allem 4 Faktoren: Technologie, Personen, Prozesse und Vorgaben.

Technologie

Unter den Aspekt Technologie fällt erstens die Tatsache, dass Entwickler heute nicht mehr jede Sicherheitskontrolle selbst implementieren müssen. Softwarentwickler können Third-Party-Sicherheitskomponenten als modulare Bausteine nutzen (z.B. Single-Sign-On), und die Frameworks selbst bieten bereits Sicherheitsfeatures (z.B. Angular JS für die Webentwicklung).

Dem Entwickler bzw. Security Tester wiederum stehen sogenannte SAST Tools zur Verfügung; die Abkürzung steht für Static Application Security Testing, hier wird der Programmcode selbst auf Schwachstellen analysiert. Bekannte Tools im Markt sind etwa HP Fortify oder Checkmarx.

Mit sogenannten DAST Tools (Dynamic Application Security Testing) lassen sich die bekannten Penetrationstests durchführen. Auch hier gibt es zahlreiche (kommerzielle) Anbieter, aber auch OpenSource Angebote wie etwa das OWASP ZAP: Letzteres Tool ist eines der aktivsten Open Web Application Security-Projekte und hat bereits den Flaggschiff-Status erhalten.

Gartner 2019 Magic Quadrant for Application Security Testing“ width=Gartner 2019 Magic Quadrant for Application Security Testing

Personen

Was allerdings nützt die beste Technologie, wenn Softwareentwickler bzw. Qualitätsingenieure/Tester diese Tools nicht bedienen können oder gar nicht erst kennen? Der Aufbau von Kompetenz zur Entwicklung von Software mit hoher Anwendungssicherheit ist darum zentral. Es beginnt mit der Schaffung von Awareness für das Thema Security. Je nach Rolle im Entwicklerteam ist dann spezifisches Know-How erforderlich:

Der ist für die übergreifende Sicherheitsarchitektur verantwortlich. Da ein großer Teil von Sicherheitslücken in heutigen Anwendungen auf Designfehler zurückzuführen sind, kommt ihm eine besondere Bedeutung im Softwareentwicklungsprozess zu; ich erlaube mir, auch auf den no-brainer hinzuweisen, dass sich Fehler im Design in späteren Entwicklungsphasen nur noch mit hohem Aufwand (und entsprechender Verzögerung für den Auslieferungszeitpunkt im Softwareprojekt) beheben lassen.

Für die Sicherheitsarchitektur von Software hat etwa der Trend zur Microservice-Architektur eine besondere Relevanz; die traditionelle monolithische Anwendungen wird zunehmend ersetzt. Damit entsteht die Anforderung, die vielfältigen Vertrauensbeziehungen zwischen verschiedenen Microservices und Containern zu managen, denn an den verschiedenen Schnittstellen zwischen Microservices muss je die Frage geklärt werden, ob es sich um einen vertrauenswürdigen Nutzer handelt. Außerdem sollte für das Softwaredesign ein altbewährtes Prinzip greifen: Keine unnötige Speicherung von vertraulichen Daten (vgl. PCI Data Security Standard).

Beim nächsten Schritt der Softwareentwicklung gilt: Die Softwareentwickler müssen ein Bewusstsein über potentielle Schwachstellen von Software haben sowie die Methoden kennen, um solche Schwachstellen zu heben. Um etwa automatisierte Angriffe („Bruteforce“) bei Anmeldemasken von Web-Anwendungen auszuschließen, kann beispielsweise die Gesamtanzahl der Anmeldeversuche begrenzt werden. Außerdem sollten fehlerhafte Anmeldeversuche protokolliert werden. Und – um bei dem Beispiel zu bleiben – sollten schwache Passwörter überhaupt verhindert werden, indem Mindestanforderungen an Passwortlänge und -komplexität von der Softwareanwendung sichergestellt werden (vgl. Vorgabe NIST 800-63).

Testingenieure wiederum müssen mit SAST und DAST-Tools vertraut sein. Darüber hinaus müssen Tester im Hinblick auf bestimmte Angriffsszenarien geschult werden, etwa die sogenannte XXE Attacke: Hierbei können beim Upload von XML-Dateien schädliche Inhalte hochgeladen werden; um XXE Risiken mithilfe von DAST Tools zu erkennen, sind manuelle Schritte erforderlich, was einer spezifischen Schulung für Tester bedarf.

Für all diese Rollen im Entwicklungsprozess einer Software (Softwarearchitekten, Softwareentwickler und Tester) gibt es inzwischen im Internet umfangreiche Informationsquellen. IT Fachkräfte können hier insbesondere auf umfangreiche Checklisten, CheatSheets und Ähnliches der OWASP Foundation zurückgreifen; das Open Web Application Security Project ist eine offene Community, die 2001 gegründet wurde und inzwischen in vielen Bereichen De-Facto-Standards in punkto Anwendungssicherheit gesetzt hat.

Prozesse und Vorgaben

Um eben diese De-Facto-Standards bei der Anwendungsentwicklung systematisch (!) durchzusetzen, bedarf es Prozesse und Vorgaben. Darunter fallen etwa Secure Coding Guidelines, aber auch Vorgaben zu Testing- und Freigabeprozessen.

Unternehmen können sich hierbei an dem – von OWASP entwickelten – Application Security Verification Standard orientieren. Dieser bietet ein umfangreiches Framework von “security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.”. Hier finden sich umfangreiche Empfehlungen, Best-Practices zu Themen wie Nutzerauthentifizierung, Session Management, Datenschutz, Verschlüsselung und mehr.

Anwendungssicherheit in Ihrem Entwicklungsprojekt

Grundsätzlich gilt: Anwendungssicherheit sollte explizit Teil der Anforderungen sein. Da Web-Anwendungen die für Hackerangriffe anfälligste Software ist, sollen die verschiedenen Optionen hieran dargestellt werden.

Definition detaillierter technischer Anforderungen an die Anwendungssicherheit: Wie bereits beschrieben werden von der Organisation OWASP zahlreiche Guidelines bereitgestellt – vom Application Security Verification Standard bis hin zu den TOP 10 Kritischsten Sicherheitsrisiken für Webanwendungen. Der Auftraggeber für ein Softwareentwicklungsprojekt kann etwa Standards von besonderer Relevanz für ein Softwareprojekt in die Anforderungen mit übernehmen oder referenzieren. Dies erfordert jedoch ein gutes technisches Verständnis, die Überprüfung einer Einhaltung lässt sich zudem nur schwierig umsetzen.

Ein einfacherer (und vergleichsweiser kostengünstiger) Weg besteht darin, in den Anforderungen zu definieren, dass ein Penetrations-Test mit einem oder mehreren definierten Tools erfolgreich abgeschlossen werden muss (vgl. etwa: Die 13 besten Tools für Anwendungssicherheit oder Web-Security-Tests mit Open-Source-Werkzeugen). Hierbei muss im Einzelfall definiert werden, ob und welche (insignifikanten) Schwachstellen akzeptiert werden.

Bei besonders sicherheitskritischen Web-Anwendungen kann man einen Schritt weitergehen und einen spezialisierten Dienstleister beauftragen, eine solche Software auf Anwendungssicherheit zu testen, indem diese professionelle Hackerangriffe simulieren. Dienstleister sind etwa touringsecure.de oder 8com.de. Einen Beispielbericht eines solchen professionellen PEN-Tests finden Sie etwa hier.

Sebastian Zang
Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.