Unternehmen investieren zu wenig in die App-SicherheitAngriffe auf die Anwendungsebene

Über die Hälfte der weltweit festgestellten Cyber-Angriffe finden auf Anwendungsebene statt. Doch Unternehmen investieren in die Sicherheit von Apps nur einen Bruchteil ihres Sicherheitsbudgets. Das sollte sich schleunigst ändern. Dazu sollte man aber wissen, welche Bereiche die Sicherheit von Anwendungen beeinflussen und wie Unternehmen ihre Apps gegenüber Cyber-Attacken absichern können.

Eine Studie von NTT belegt, dass inzwischen mehr als die Hälfte aller Cyber-Angriffe auf Anwendungen abzielen. Dennoch investieren Unternehmen nur knapp sechs Prozent ihres Sicherheitsbudgets in den Schutz der eigenen Apps. Warum ist das so?

In nicht technologischen Branchen spielte Software früher nur eine untergeordnete Rolle. Doch die Zeiten haben sich gewandelt. Ein Einzelhändler ist nicht mehr nur ein Einzelhändler. Um sich vom Mitbewerb zu unterscheiden, verwendet er Anwendungen, die für eine größere digitale Erfahrung seiner Kunden sorgen. Das Einzelhandelsunternehmen ist somit auch zu einem Software-Anbieter geworden. Dieser Sachverhalt gilt inzwischen für die meisten Unternehmen aus den unterschiedlichsten Sektoren.

Diese veränderte Rolle spiegelt sich allerdings noch nicht in den IT-Budgets wider. Unternehmen sollten jedoch umdenken: Denn herkömmliche IT-Sicherheitsbemühungen sind nicht in der Lage, die Risiken zu kontrollieren, die von dem Trend zur Bereitstellung digitaler Geschäftsfunktionen in immer größerem Umfang und mit immer höherer Geschwindigkeit ausgehen.

Wichtig in diesem Zusammenhang ist die Kenntnis über potentielle Gefahrenherde. Das sprichwörtliche „ABC“ der Risiken für die Anwendungssicherheit lässt sich in drei Kategorien einteilen:

• Assemble: Das Risiko entsteht immer dann, wenn Komponenten kombiniert werden, die die Grundlage von Anwendungen bilden, wie Betriebssystempakete, Frameworks und Bibliotheken.
• Build: In diesem Bereich entsteht ein Risiko, wenn Funktionen ohne Security by Design oder geeignete Sicherheitskontrollen implementiert werden.
• Configure: In diesem Abschnitt treten Risiken auf, wenn Anwendungen bereitgestellt werden, um neue Funktionen zu aktivieren, ohne die Standardeinstellungen abzusichern und frühere Entwicklungskonfigurationen weiterzuentwickeln.

Entwickler und Entscheidungsträger sollten die drei wesentliche Verfahren kennen, mit denen Unternehmen in allen „ABC“-Segmenten die Sicherheit von Apps verbessern:

• Hackerangriff simulieren: Dynamic Application Security Testing (DAST); DAST überprüft eine laufende Anwendung aus der Perspektive eines Angreifers. Die Verfahren und Techniken ähneln denen von Hackern. Das gängigste DAST-Tool ist ein Schwachstellen-Scanner, der die Benutzeroberfläche untersucht, um die Funktionsweise des Backend-Servers zu ermitteln. Es schickt manipulierte Anfragen an den Server, um Angriffe zu simulieren. Dadurch soll die Anwendung dazu gebracht werden, ein Verhalten an den Tag zu legen, das ihre Anfälligkeit in Bezug auf gängige Kategorien von Anwendungsschwachstellen belegt. Am effektivsten ist DAST, wenn es automatisierte Tests mit manuellen kombiniert. Damit erfasst die IT nicht nur Schwachstellen in der gesamten Breite der Anwendung, sondern kann sich aufgrund der Zeitersparnis auf komplexere Funktionen konzentrieren. DAST bietet einen Überblick über ausnutzbare Risiken, die von einem externen Bedrohungsakteur entdeckt werden können. Sie ist eine wichtige Grundlage für die Erkennung unmittelbarer Gefährdungen und informiert über die notwendigen Maßnahmen zur Reduzierung des Risikoprofils.
• Quellcode überprüfen: Static Application Security Testing (SAST); SAST untersucht den Quellcode der Anwendung auf Schwachstellen. Die automatisierte Analyse kann in drei Typen unterteilt werden: Mustervergleich, semantische Analyse und Laufzeitsimulation. Allerdings unterscheiden sich die sogenannten „Code-Scanner“ hinsichtlich der Leistungsfähigkeit. Einfachere Varianten bieten einen Musterabgleich, der sich einfach implementieren und schnell ausführen lässt, aber viele falsch-positive und -negative Resultate liefern kann. Anspruchsvollere Exemplare erfordern einen höheren Implementierungsaufwand und laufen langsamer. Dafür bieten sie jedoch eine genauere Erfassung von Sicherheitslücken und damit deutlich aussagekräftigere Ergebnisse. Eine automatisierte SAST-Lösung erkennt Implementierungsfehler, nicht jedoch Designfehler. Schwachstellen können aber durch beides entstehen. Daher ist es empfehlenswert, eine Automatisierung mit einer manuellen Codeüberprüfung während des gesamten Softwareentwicklungslebenszyklus (SDLC) zu kombinieren. Auf diese Weise werden Implementierungsfehler in der gesamten Codebasis aufgedeckt, und die Prüfer können sich auf Designaspekte der wichtigsten Funktionen und die damit verbundenen Sicherheitskontrollen konzentrieren.
• Technologie-Stack kontrollieren: Software Composition Analysis (SCA); SCA analysiert den von der Anwendung verwendeten Technologie-Stack, um öffentlich bekannte Schwachstellen und Lizenzrisiken zu erkennen. Die von SCA aufgedeckten Schwachstellen werden über einen Patch- oder Upgrade-Pfad behoben.

„Effektive Anwendungstests können helfen, Schwachstellen und Trends oder Tendenzen zu erkennen, die möglicherweise zur Verbreitung künftiger Sicherheitslücken führen“, erklärt Craig Hinkley, CEO der Abteilung Application Security bei NTT. „Ein ganzheitliches Programm für den Test der Anwendungssicherheit ist eine wichtige präventive und proaktive Technik, die dazu beitragen kann, das gesamte Bedrohungsprofil eines Unternehmens zu verringern. Anwendungen werden immer mehr zum Ziel von Angriffen, und dies sollte sich in den Ausgaben der Unternehmen für IT-Sicherheit widerspiegeln.“ (rhh)

NTT