Schutz Ihrer Anwendungen – unabhängig davon, wo sie sich befinden

Anwendungen sind überall, von Datenzentren bis hin zu Smartphones. Standort unabhängiges Arbeiten hat dazu geführt, dass mehr Anwendungen in die Cloud ausgelagert werden müssen. Das Anwendungswachstum kennt keine Grenzen. Es ereignen sich allerdings auch regelmäßig Datenschutzverletzungen bei Anwendungen. Wie schafft man es also, sie zu schützen? Ein Verständnis davon, welche Bedrohungsvektoren hier im Spiel sind, ist enorm wichtig dafür, eine „AppSec“-Strategie zu entwickeln und mit dem Schützen von Anwendungen zu beginnen.

Anwendungssicherheit sieht 2021 anders aus. Sie spielte schon immer eine wichtige Rolle für Bereiche, die möglichen Angriffen ausgesetzt waren, doch durch das Arbeiten im Homeoffice hat sich dies noch wesentlich intensiviert (Quelle: CIF). Wir haben bereits über BOTS gesprochen und dass sie Kunden zweifellos das meiste Kopfzerbrechen bereiten. Sie führen aktuell definitiv die Liste erfolgreicher Methoden für Datenschutzverletzungen an. Es ist bei ihnen auch kein Rückgang zu verzeichnen, sie werden vielmehr immer leistungsstärker.  Angesichts der Tatsache, dass 28 % aller Datenschutzverletzungen durch menschliche Fehler verursacht werden, ist es umso wichtiger, dafür zu sorgen, dass keine Hintertüren versehentlich offen bleiben.

Aber es sind nicht nur die BOTS!

Den Bereichen Zero-Day-Bedrohungen, Schwachstelle bei Web-Applikationen, Software-Supply-Chain und APIs (Application Programming Interface) muss ebenso viel Aufmerksamkeit gewidmet werden. Aus neuen Forschungsdaten geht hervor, dass 72 % von 750 befragten globalen Kunden innerhalb des letzten Jahres mindestens einen Sicherheitsverstoß aufgrund einer Anwendungsschwachstelle verzeichnet hatten. Bei fast 40 % waren es sogar mindestens zwei Verstöße. Auch in den Nachrichten wird weiterhin laufend über groß angelegte Beispiele solcher Verstöße berichtet.

APIs sind der Traum eines jeden Entwicklers. Unternehmen wenden sich immer mehr einer API-orientierten Entwicklung zu. APIs beschleunigen die Entwicklung neuer Anwendungsversionen enorm. Doch genau das birgt auch ein weiteres Risiko. Die höhere Sichtbarkeit dieser Anwendungen schafft eine völlig neue Angriffsfläche. Und wenn man dann noch Anwendungen mit einer einzigen Seite berücksichtigt, kann einem das durchaus schlaflose Nächte bereiten.

Denken Sie daran, wie man einen Scheck einlöst. Wenn Sie alt genug sind, erinnern Sie sich vielleicht daran, wie Sie von Ihren Großeltern einen Scheck zum Geburtstag bekommen haben. Sie mussten warten, bis die Bank öffnete, mussten den Scheck einzahlen und dann … erneut warten. Es dauerte ein paar Tage, bis das Ursprungskonto des Schecks überprüft und einige Details bestätigt werden konnten und dann musste man auf Antwort warten. Wenn das alles dann erledigt war, ging das Geld endlich auf Ihrem Konto ein. Und heute? Sofortige Überweisungen über eine App auf Ihrem Smartphone. Das geht wirklich schnell. Aber denken Sie mal darüber nach: Das ist nicht einfach nur eine Transaktion, sondern da passieren jede Menge an IT-Vorgängen hinter den Kulissen, damit diese eine Transaktion stattfinden kann – und alle davon müssen geschützt werden.

B2B-Endpunkt-Prüfungen erfolgen ohne menschliches Zutun, das wird alles von APIs erledigt und alle Bereiche stellen hier eine mögliche Bedrohung dar. Wieso? Überlegen Sie mal: APIs legen per Definition die Logik der Anwendung, die Anmeldedaten und Tokens des Benutzers sowie persönliche Daten aller Art frei – und das in Cloud-Geschwindigkeit direkt über Ihr Smartphone! Eine API-basierte Anwendung ist wesentlich anfälliger als eine traditionelle web-basierte App. Das liegt an der charakteristischen Art und Weise ihrer Bereitstellung, die einen direkten Zugriff auf vertrauliche Daten ermöglicht.

Beim Scrollen auf Facebook und beim Abrufen von Live-Aktientickern z. B. interagieren unsere Handys über APIs mit den Servern in den jeweiligen Rechenzentren. Beim Live-Scrollen findet eine laufende Authentifizierung dieser APIs über umfangreiche alphanumerische Strings statt. Dieser Traffic muss in Echtzeit inspiziert und gesichert werden. Anders als in dem Beispiel mit dem Scheck kann man hier nicht darauf warten, dass jemand aus der Mittagspause zurückkommt, um zu überprüfen, ob es sich hierbei um eine legitime Anfrage handelt.

Unternehmen lieben APIs, doch die Security hat Mühe, hier Schritt zu halten. BOTS stehen bereit, um rund um die Uhr auf ungesicherte APIs zuzugreifen. Dort können sie dann auf Kunden- oder Mitarbeiterdaten zugreifen und diese ganz nach Wunsch unbefugt offenlegen Es gibt zahlreiche Beispiele dafür, wie Test-APIs mit direktem Zugriff auf Produktionsdaten völlig ohne Sicherheitsmaßnahmen bereitgestellt werden (darunter auch die Datenschutzverletzung bei Facebook 2018). Mut macht aber trotz der Sicherheitsherausforderungen bei APIs eine auf den oben angesprochenen Forschungsdaten basierende Statistik, der zufolge 75 % aller Befragten sich mittlerweile der Risiken im Zusammenhang mit APIs bewusst sind. Das ist ein positives Anzeichen dafür, dass dieser Bereich nun ernst genommen wird.

Die Sicherung von APIs gehört nun zu den obersten Prioritäten im Security-Bereich. Wichtig ist eine umfassende, skalierbare und leicht bereitstellbare Plattform, mit der sich Anwendungen unabhängig davon, wo sie sich befinden, schützen lassen. Eine Web Application Firewall (WAF) mit Active Threat Intelligence ist die unkomplizierteste Möglichkeit, Ihre Anwendungen zu schützen und zu vermeiden, dass sich APIs zu den in diesem Blog erwähnten Bedrohungen entwickeln. Sie sollten in Ihrem Unternehmen unbedingt Schutzmaßnahmen gegen Zero-Day-Bedrohungen, BOTS, DDoS-Angriffe, Supply-Chain-Datenschutzverstöße, Credential-Stuffing, Client-Side Protection sowie internen Schutz gegen böswillige Mitarbeiter thematisieren, um nicht auch zu den bereits genannten 72 % zu gehören.Möchten Sie mehr erfahren? In einem neuen Seminar haben Barracuda-CTO Fleming Shi und weitere Barracuda-Experten sich mit aktuellen und neuen API- und Supply-Chain-Angriffen beschäftigt. Es ist hier on-demand verfügbar.