Die Technologie schreitet weiterhin mit einer beispiellosen Geschwindigkeit voran. Die Entwicklung und Verwendung von Anwendungsprogrammierschnittstellen (APIs) ist ein besonders bemerkenswertes Beispiel.
Die neuesten Salt Labs State of API Security Report stellte fest, dass der gesamte API-Verkehr in 12 Monaten um 168 Prozent anstieg, wobei der API-Angriffsverkehr im gleichen Zeitraum um 117 Prozent zunahm. Vielleicht ist es verständlich, dass viele CISOs Schwierigkeiten haben, Schritt zu halten.
Gemäß demselben Bericht erlitten 94 % der Unternehmen innerhalb von 12 Monaten einen API-Sicherheitsvorfall. Zu dieser Gruppierung gehören bekannte Namen wie Experian, Peloton und Starbucks. Sogar Lego hatte eine knappe Chance, Ende letzten Jahres eine potenziell katastrophale API-Schwachstelle zu beheben. Riesige Unternehmen mit großen Sicherheitsbudgets geraten immer wieder in Konflikt mit API-Sicherheitsvorfällen. Offensichtlich sind traditionelle Anwendungssicherheitstechniken einfach nicht gewachsen, wenn es um die Sicherung von APIs geht.
Vor diesem Hintergrund sprachen wir mit Yaniv Balmas, VP of Research bei Salt Security, um einige der am häufigsten gestellten Fragen zur API-Sicherheit zu klären.
BN: Kann eine Zero-Trust-Architektur APIs schützen?
YB: Leider können viele API-Risiken nicht durch Zero Trust gemindert werden. Das Ziel von Zero Trust ist es, den Zugriff einzuschränken, während APIs Zugriff benötigen, um zu funktionieren. Die meisten APIs sind öffentlich oder offen, darauf ausgelegt, vom Internet als Ganzes und einem großen Kundenstamm genutzt zu werden, was Zero Trust vor einzigartige Herausforderungen stellt.
Darüber hinaus erfolgen API-Angriffe typischerweise in vertrauenswürdigen Kanälen und authentifizierten Sitzungen. Angreifer wissen, ob sie an die Schlüssel oder Zugangsdaten eines autorisierten Benutzers gelangen und auf wertvolle Daten zugreifen können. Durch Huckepack oder Hijacking authentifizierter Sitzungen mit gestohlenen aktiven Sitzungscookies, Authentifizierungstoken, Zwei-Faktor-Authentifizierungsherausforderungen, API-Schlüsseln und anderem Authentifizierungsmaterial werden Hacker nicht durch eine Zero-Trust-Architektur behindert. Denken Sie daran, dass laut dem State of API Security Report erstaunliche 94 Prozent der Exploits gegen authentifizierte APIs stattfinden.
Wenn es um Zero Trust geht, müssen Organisationen über die Prinzipien der Authentifizierung und Autorisierung hinausgehen. Sie benötigen einen API-Laufzeitschutz, um den Zugriff und das Verhalten eines autorisierten Benutzers kontinuierlich anhand von API-Ressourcen zu validieren, die Anomalien zu erkennen und die schlechten Akteure zu lokalisieren.
BN: Können Cloud-Sicherheitsangebote APIs schützen?
YB: Während einige Cloud-Sicherheitsanbieter Tools wie API-Management oder API-Gateways anbieten, reichen Einzelprodukte wie diese nicht aus, um Unternehmen vor API-Angriffen zu schützen. Diese Tools verfügen sowohl auf der Anwendungs-als auch auf der API-Ebene über begrenzte API-Sicherheitsfunktionen, sodass die APIs unzureichend geschützt sind. API-Angriffe sind effektiv Zero-Day-Exploits, was bedeutet, dass Sicherheitstools, die darauf ausgelegt sind, nach bekanntem „schlechtem“ Verhalten zu suchen – beispielsweise Signaturen oder IPs auf der schwarzen Liste –, APIs niemals angemessen schützen können. Es ist hier auch erwähnenswert, dass, da APIs Anwendungslogik sind, Cloud-Kunden die letztendliche Verantwortung dafür tragen, sie innerhalb des Modells der gemeinsamen Verantwortung für die Sicherheit zu schützen.
BN: Warum nicht IAM, WAFs oder API Gateways schützen APIs?
YB: Obwohl IAM, WAFs und API-Gateways allesamt notwendige und wichtige Tools im Sicherheits-Stack jeder Organisation sind, reichen sie nicht aus, um APIs zu schützen – vor allem, weil sie es nicht tun sorgen für die erforderliche Sichtbarkeit oder Sicherheitskontrollen.
Angreifer umgehen konsequent Zugangskontrollen und stehlen Schlüssel und Token. Moderne Hacker sind Experten darin, Zugriffskontrollen zu umgehen, sich auf eine authentifizierte Benutzersitzung zu stützen oder Authentifizierungsmaterial aus Datenverkehr, Gerätespeicher oder Anwendungscode zu ernten. Diese Angriffstechniken können von IAM-, API-oder WAF-Lösungen nicht erkannt werden.
Diese Tools können auch API-spezifische Probleme nicht erkennen – beispielsweise den Missbrauch von Geschäftslogik und Autorisierungs-Exploits –, da sie auf Signaturen und Regeln zur Angriffserkennung angewiesen sind. Erschwerend kommt hinzu, dass die ihnen innewohnenden API-Verwaltungskomponenten möglicherweise auch ausgenutzt werden können.
Darüber hinaus sind IAM, WAFs und API-Gateways alle auf Proxys angewiesen. Da Proxy-Modelle die API-Kommunikation verlangsamen, scheitern Organisationen normalerweise daran, jede verwendete API mit einem Gateway oder einer WAF zu vermitteln – insbesondere bei inneren oder internen APIs. Dies führt zu einem Mangel an Transparenz darüber, wie diese APIs verwendet werden.
BN: Können APIs mit Workload-Schutz gesichert werden?
YB: Workload-Sicherheit Schutz bietet viele Vorteile. Sie helfen unter anderem bei der Bereitstellung von Infrastruktursicherheit, um sicherzustellen, dass Sie keine Workloads auf anfälligen Softwareversionen ausführen, und sind auch nützlich, um den Zugriff auf eine Workload für externe Benutzer zu blockieren. Sie bieten jedoch keinen Kontext auf API-oder Anwendungsebene und können APIs daher nicht selbst sichern.
BN: Wie effektiv ist die Linksverschiebung zum Sichern von APIs?
YB: Während die Implementierung von Sicherheit in der Entwicklungsphase eine lohnende Praxis ist, bedeutet die Shift-Left-Unterstützung nicht, dass jede API vor der Produktion gesichert wird. Entwickler-Testtools können einfach nicht alle Schwachstellen identifizieren. Viele gängige API-Sicherheitsprobleme können im Rahmen von automatisierten Design-, Entwicklungs-und Build-Scans mit gängigen Sicherheitsanalyse-und Testtools nicht identifiziert werden – Schwachstellen in der Geschäftslogik können nicht erkannt werden, wenn die APIs nicht genutzt werden.
Photo Credit: Panchenko Vladimir/Shutterstock