Der Security-Spezialist Radware rät Unternehmen, der Supply Chain der Unternehmens-Anwendungen bei Betrachtung der IT Security nicht bedingungslos zu vertrauen.
Um zu verstehen, warum die Supply Chain ein Bereich ist, der nicht übersehen werden sollte, ist es wichtig, die aktuelle Cyber-Bedrohungslandschaft zu verstehen und wie moderne Anwendungen aufgebaut sind.
Klassische Anwendungen wurden in einer 3-Tier-Architektur oder ganz monolithisch realisiert und am Perimeter mit Hilfe von traditionellen Application Delivery Controllern (ADC) und einer Web Application Firewall (WAF) geschützt. Heutzutage ist der Schutz von Anwendungen jedoch viel komplizierter. Die Anwendungen werden in verschiedenen Umgebungen gehostet – vor Ort und in der Cloud. Darüber hinaus sind sie auf zahlreiche API-Verbindungen zu internen und externen Diensten und Dutzende verschiedener JavaScript-Dienste von Drittanbietern angewiesen, um Prozesse in Bereichen wie Werbung, Bestandsverwaltung, Zahlungsdienste und in soziale Medien eingebettete Widgets und Inhalte zu unterstützen. Einige Beispiele für beliebte JavaScript-Dienste sind Marken wie Outbrain, Google Analytics, Tranzila, WordPress und Magento. Einige dieser JavaScript-Dienste sind sogar von JS-Diensten vierter oder fünfter Parteien abhängig, die als ihre eigene Supply Chain betrachtet werden können. Und ein erheblicher Teil der Inhalte, die Anwendungen den Endbenutzern präsentiert, wird nun vom Webbrowser zusammengestellt.
Die Herausforderungen beim Schutz von Anwendungen nehmen nicht nur aufgrund der Veränderungen in der Anwendungsarchitektur zu, sondern auch aufgrund der Weiterentwicklung der Bedrohungslandschaft. Die heutigen Angriffe sind leistungsfähiger, häufiger und komplexer und umfassen mehr Angriffsvektoren, so dass eine lokale WAF vor Ort reicht nicht mehr ausreicht, um die Daten einer Anwendung zu schützen. Viele Unternehmen verwenden daher laut Radware mehrere WAFs für ihre verschiedenen Umgebungen sowie DDoS-Schutzlösungen und Bot-Management-Tools. WAF-, DDoS-, Bot- und API-Schutz-Tools sind zum Standard geworden, wenn es um den Schutz der wichtigsten digitalen Assets und Datenzentren der Anwendung geht. Doch während sich die Server-seitige Sicherheit verbessert, suchen immer mehr Hacker nach neuen Wegen, um ihre Ziele zu erreichen, indem sie übersehene Dienste und Verbindungen von Drittanbietern in der Infrastruktur der Anwendungen missbrauchen. Hier starten sie Angriffe über die weniger geschützte und überwachte Client-seitige Lieferkette.
Hacker setzen zunehmend auf den Client statt den Server
Eine der Methoden, mit denen Hacker heute versuchen, Schwachstellen in der Application Supply Chain auszunutzen, ist Formjacking, auch bekannt als Magecart und Skimming. Dabei handelt es sich um eine verdeckte Angriffsmethode, bei der Hacker bösartige Malware in einem der Drittanbieterdienste der Anwendung verstecken. Sobald ein Benutzer eine HTML-Antwort von der Anwendung erhält, um eine Formularanfrage an den infizierten Drittanbieterdienst zu stellen, wird als Antwort ein bösartiger Code direkt in das Formular des Ziels injiziert. Er sammelt dann die sensiblen Daten, die der Endbenutzer eingibt, und sendet sie zurück an den Remote-Server des Angreifers.
WAFs können die Kommunikation zwischen Browser und Drittanbieter nicht überwachen
Auch wenn Unternehmen versuchen, die Applikationen und persönliche Daten zu schützen, können die Informationen, die Endbenutzer im Browser eingeben (z. B. Ausweisnummern, Adressen, Kreditkartennummern, Kontaktinformationen usw.), den in der Anwendung eingebetteten Diensten von Drittanbietern ausgesetzt werden. Diese werden von der Hauptanwendung automatisch als vertrauenswürdig eingestuft, werden aber nur selten überwacht. Unter dem Gesichtspunkt der Compliance und der Aufsichtsbehörden ist jedoch der Betreiber der Endanwendung für alle Verletzungen der Datenschutzbestimmungen oder den Diebstahl persönlicher Informationen im Browser genauso verantwortlich wie auf der Serverseite, also im Rechenzentrum – ob nun On-Premise oder in der Cloud. Endanwender besuchen eine Website und vertrauen dem Anbieter, ohne sich darum zu kümmern oder auch nur kümmern zu sollen, auf welche Dienste von Drittanbietern dieser zurückgreift.
Problematisch ist dabei laut Radware, dass herkömmliche WAFs so konzipiert sind, dass sie nur den eingehenden Datenverkehr zu den Anwendungen überwachen – den Datenpfad zwischen den Endbenutzern und der Anwendung. Da sie als On-Premise-Appliance oder als Reverse-Proxy-WAF in der Cloud eingesetzt werden, sind sie blind für die Kommunikation zwischen dem Browser des Endbenutzers und den Drittanbieterdiensten der Anwendung. Es ist jedoch aufgrund der Compliance-Bedingungen und des Kundenvertrauens zwingend erforderlich, dass die Privatsphäre der Endanwender nicht durch integrierte Drittanbieterdienste gefährdet wird. Dies wird zu einem Problem, wenn der Betreiber der Anwendung
– keine Möglichkeit hat, zu wissen, ob der JavaScript-Code von Diensten in der Supply Chain verletzt oder manipuliert wurde;
– keine Kontrolle über die Sicherheit von Diensten Dritter hat; und
– nicht die gesamte Software Supply Chain überwachen kann (einschließlich der Sub-Services von vierten und fünften Parteien).
Aus diesen Gründen empfiehlt Radware, der Client-seitigen Sicherheit ein höheres Gewicht zu geben und Schutztools zu verwenden, die Daten und Konten der Nutzer schützen und dabei helfen, die Compliance-Vorschriften einzuhalten. Schließlich ist es die Anwendung des Anbieters, die die Endnutzer dazu veranlasst hat, sich mit diesen Drittanbieteranwendungen zu verbinden.
Kriterien für Client-seitigen Schutz
Client-seitiger Schutz von Anwendungen basiert nach Radware vor allem auf vier Säulen:
Sichtbarkeit – in vielen Unternehmen ist die für die Sicherung der Anwendung zuständige Person nicht unbedingt über alle verschiedenen Drittanbieter-Dienste und -plattformen informiert, die verwendet werden. Daher sollte ein Client-seitiges Schutztool in erster Linie in der Lage sein, alle Drittanbieterdienste in der Lieferkette automatisch zu erfassen und offenzulegen.
Erkennung – Client-seitiger Schutz muss kontinuierlich alle Änderungen in der Supply Chain erkennen und den Betreiber darüber informieren. Dazu gehört auch ungewöhnliche Kommunikation oder unzulässige Skriptparameter zwischen den Browsern der Endbenutzer und den Drittanbieterdiensten der Anwendung.
Integrierte WAF-Lösung – Ein Client-seitiges Schutztool sollte nahtlos in die WAF integriert sein, damit es anomale und bösartige Anfragen abwehren und blockieren sowie Datenverluste verhindern kann.
Granulare Mitigation – Darüber hinaus sollten solche Lösungen in der Lage sein, Angriffe auf eine sehr granulare Weise abzuschwächen. Da die meisten JavaScript-Dienste von Drittanbietern in der Versorgungskette für die Anwendungsfunktionalität unerlässlich sind, ist es wichtig, eine Client-seitige Schutzlösung zu verwenden, die in der Lage ist, nur die bösartigen Skripte gezielt zu blockieren und nicht die Dienste lahmzulegen.
Laut Radware ist die Erhöhung der Sicherheit im Datenpfad zwischen dem Browser des Endanwenders und den Diensten von Drittanbietern in der Anwendungskette eine wichtige Verteidigungslinie. Sie kann Unternehmen nicht nur dabei helfen, Datenschutz- und Datensicherheitsstandards einzuhalten, sondern auch Datenlecks zu verhindern, die zu Kontoübernahmen führen können, sowie eine Vielzahl von Sicherheitsbedrohungen zu entschärfen.
Verantwortlicher für diese Pressemitteilung:
Radware GmbH
Herr Michael Gießelbach
Robert-Bosch-Str. 11a
63225 Langen
Deutschland
fon ..: +49 6103 70657-0
web ..: https://www.radware.com
email : radware@prolog-pr.com
Pressekontakt:
Prolog Communications GmbH
Herr Achim Heinze
Sendlinger Str. 24
80331 München
fon ..: +49 89 800 77-0
web ..: https://www.prolog-pr.com
email : achim.heinze@prolog-pr.com