Neue Regeln für die Web-App- und API-Sicherheit

Die meisten Webanwendungs- und API-Sicherheitstools wurden für eine vollkommen andere Ära entwickelt: eine Zeit, bevor Entwickler und Sicherheitsexperten zusammenarbeiteten, um mit integrierten Workflows sichere Software bereitzustellen. Eine Zeit, bevor Anwendungen auf der ganzen Welt verteilt und API-basiert waren. Eine Zeit, bevor Entwickler einen Befehl eingeben und sofort ein globales Update erwarten konnten. Aber wie unser CEO Joshua Bixby gerne sagt: „Auch Angreifer sind Entwickler.“ Und Angreifer lassen sich nicht durch herkömmliche Lösungen ausbremsen. Sie sind so agil wie eh und je und nutzen moderne Tools und Workflows, um neue Bedrohungen zu entwickeln und zu verbreiten. Es war noch nie so klar wie jetzt, dass es Zeit ist, etwas zu ändern. Deshalb stellen wir heute neue Regeln für die Sicherheit von Webanwendungen und APIs auf, in denen berücksichtigt wird, wie moderne Anwendungen entwickelt werden. 

Regel 1: Tools müssen die Angriffsabsicht bekämpfen, nicht spezifische Bedrohungen 

Sicherheitsteams haben sich lange Zeit auf die Bekämpfung spezifischer Bedrohungen konzentriert. Bei der Evaluierung neuer Tools stellen sie sich die Frage: „Kann mich das vor X schützen?“ Bei diesen Bedrohungen handelt es sich aber oft um Ereignisse wie Stuxnet oder den jüngsten SolarWinds Hack, die für Schlagzeilen sorgen. Außerdem führt diese Art der Evaluierung zu Tools, die nach Signaturen oder „Indicators of Compromise“ (IoCs), also Anzeichen einer Sicherheitsverletzung, suchen. IoCs enthalten Dinge wie die IP-Adressen bekannter Angreifer und reguläre Ausdrücke, die mit einer bestimmten Anfrage-URL übereinstimmen, auf die die jeweilige Malware abzielt. 

Signaturbasierte Tools sind allerdings nicht besonders gut darin, zwischen legitimem und bösartigem Traffic zu unterscheiden, und können mit der stetigen Zunahme an Bedrohungen nicht mithalten. Sie sind ganz einfach überfordert. Aktuelle Berichte sprechen von über 350.000 neuen Malwarevarianten pro Tag. 

Diese Herangehensweise funktioniert also nicht. Sie ist bereits bei Virenschutz-Angeboten gescheitert, die nicht vor Sicherheitsverletzungen schützen konnten, bei herkömmlichen WAF-Anbietern, die nur nach SQL-Injections oder Cross-Site-Scripting suchten, und bei Tools zur Bot-Abwehr, die nur auf den User Agent des anfragenden Browsers achteten. 

Die neuen Sicherheitsregeln für Webanwendungen und APIs erfordern den Umstieg auf eine intelligentere Herangehensweise, die innerhalb der Sicherheits-Toolchain für ausreichend Zuverlässigkeit sorgt. Anwender sollten sich darauf verlassen können, dass das System keinen legitimen Traffic blockiert oder bösartigen Traffic durchlässt. 

Um dies zu erreichen, braucht es neue Anforderungen an die Sicherheitstechnologie: Erstens müssen Anwender nach Tools verlangen, die nicht nur die Signatur des Traffics, sondern auch seine Absicht oder sein Verhalten berücksichtigen. Dafür müssen Faktoren wie die Geschwindigkeit der Anfrage, Tageszeit und Anmeldestatus des Nutzers mit einbezogen werden. 

Zweitens müssen Entwickler verlangen, dass Tools nicht nur im Überwachungsmodus, sondern auch im Blocking Mode ausgeführt werden. Tools, die aus Sorge um Fehlalarme nur im Überwachungsmodus laufen können, bestärken ein kaputtes System: Der Schaden ist bereits angerichtet, ehe das Team reagieren kann. Stellen Sie sich einen Superhelden vor, der an einer Straßenecke steht und „Haltet den Dieb“ ruft aber dann auf die Polizei wartet, statt seine Superkräfte zu nutzen dem Übel sofort ein Ende zu setzen. Sicherheits- und Operations-Teams ertrinken in Warnmeldungen. Und obwohl Teams auch weiterhin damit beschäftigt sein werden, bestimmte Bedrohungen proaktiv zu erkennen und darauf zu reagieren (mehr dazu später), brauchen sie Tools, die Bedrohungen zuverlässig blockieren, sobald sie auftreten, und das Problem nicht erst melden, sobald es zu einer Sicherheitsverletzung gekommen ist.  

Außerdem müssen die Tools mit modernen Bedrohungen Schritt halten können, ohne die Sicherheits- und Operations-Teams mit Fehlalarmen zu überschütten. Moderne Cloud- und SaaS-Lösungen bieten Ihnen die volle Leistungsfähigkeit eines Produktsicherheitsteams, das den Bedrohungen immer einen Schritt voraus ist und proaktiv Updates bereitstellt. Sie müssen sich nicht um Patches kümmern oder sich mit den neuesten Bedrohungen beschäftigen.

Regel 2: Sicherheit und Nutzerfreundlichkeit gehen Hand in Hand 

Das Aufkommen von intuitiven, mit Verbrauchertools vergleichbaren Weberlebnissen in SaaS-basierten Tools hat die Nutzerfreundlichkeit in den Mittelpunkt der meisten Technologiebereitstellungen gerückt. Und doch hinken die Sicherheitslösungen kläglich hinterher. Herkömmliche Tools wurden entwickelt, um Enforcement und Kontrolle zu gewährleisten – nicht um ihren Nutzern das Leben leichter zu machen. Moderne Teams erwarten allerdings, dass sie mit ihren Tools interaktiv zusammenarbeiten können. Sie wollen integrieren, beobachten und handeln. 

Die Nutzeroberfläche ist der wichtigste Schutzschild für einen Bediener. Leider wird dort auch am häufigsten die Nutzerfreundlichkeit vernachlässigt. Herkömmliche Nutzeroberflächen können langsam und umständlich sein. Bediener müssen sich bei der Arbeit mit dem System oft in mehrere Nutzeroberflächen einloggen, selbst wenn sie Lösungen desselben Anbieters verwenden. Eine schlechte Nutzeroberfläche birgt eine Vielzahl von Risiken: Lücken bei der Einhaltung von Richtlinien und beim Enforcement, langsame und unkoordinierte Reaktionen auf aktuelle Bedrohungen und inkonsequente – oder im schlimmsten Fall nicht vorhandene – Transparenz des kompletten Sicherheitssystems. 

Eine Sicherheitslösung muss eine einzige, intuitive und einfach zu bedienende Nutzeroberfläche haben, die Kontrolle und Transparenz über die gesamte Lösung bietet. Observability sollte umfassend und integriert sein, um auf einen Blick absolute Transparenz über den Systemzustand zu ermöglichen. Außerdem müssen diese Lösungen auch für Sicherheits- und andere Teams geeignet sein, denn immer häufiger sind neben Entwicklern auch Leute von Operations am Kampf gegen Bedrohungen beteiligt. 

Moderne Tools müssen außerdem zum modernen Anwendungsdesign passen. Allzu oft werden Toolsets von einem Anbieter einfach als Paket verkauft, sind aber nicht wirklich zur technischen Integration geeignet. Eine Bekannte von mir nennt das „Integration auf Rechnung“. Selbst wenn Sie in Ihrem System zur Navigation zwischen verschiedenen Lösungen einfach nur von einem Tab auf den anderen wechseln müssen, verlieren Sie bei einem Angriff wertvolle Sekunden und die absolute Transparenz. Dieser Ansatz schwächt Ihre allgemeine Sicherheitslage durch technische Lücken und einen Mangel an Transparenz. Provider sollten standardmäßig Automatisierung und Integration anbieten, angefangen bei der vollständigen Kontrolle über Ihre APIs. Sämtliche Sicherheitslösungen sollten über nutzerfreundliche APIs verfügen, über die Sie auf alle Funktionen des Systems zugreifen können. Die Lösungen müssen sich nicht nur untereinander, sondern auch innerhalb der gesamten Response Toolchain problemlos integrieren lassen, einschließlich mit Tools wie Jira, PagerDuty, Slack und Splunk. Ebenso sollten sie Echtzeit-Logs und -Statistiken bieten, die Einblicke in die Daten aus dem vom Team verwendeten Sicherheits-Monitoring- oder Observability-System ermöglichen. Indem Sie alle Ihre Lösungen miteinander integrieren, können Sie die wahre Absicht eines Angreifers viel leichter erkennen.

Regel 3: Echtzeit-Angriffe erfordern Echtzeit-Reaktionen   

Malware ist ein Softwaresystem, und Softwaresysteme werden von Entwicklern erstellt. Also sind Angreifer Entwickler. Wer diesen Zusammenhang erkennt und verinnerlicht, versteht leichter, warum herkömmliche Sicherheitssysteme mit modernen Bedrohungen nicht Schritt halten können. Agile Angreifer nutzen fortschrittliche DevOps-Workflows, um schnell neue Methoden zu testen, anzupassen und einzusetzen. Das kann während eines einzigen Angriffs hunderte Male passieren. Aber wie können Sie Ihre Anwendungen überhaupt schützen, wenn Sie nicht in der Lage sind, mit derselben Geschwindigkeit auf Angriffe zu reagieren? Lassen Sie uns zunächst Folgendes klarstellen: Die Reaktionszeit wird nicht dadurch beschränkt, wie schnell Ihr Gehirn arbeitet, sondern durch die Geschwindigkeit Ihrer Sicherheitslösungen. Und dabei spielen zweierlei Faktoren eine Rolle:

Sofortige Transparenz 

Wenn es Minuten oder Stunden dauert, bis ein Angriff erkannt wird, ist es bereits zu spät. Angreifer haben einen langen Atem: Wenn der erste Versuch fehlschlägt, probieren sie es erneut. Und all das innerhalb von Minuten. Bis Ihre Sicherheitslösung die Daten an sich selbst oder an ein SIEM- oder Überwachungssystem weitergegeben hat, ist der Schaden bereits angerichtet. Echtzeit-Transparenz (gemessen in Sekunden) ist sowohl für automatisierte als auch für manuelle Workflows vorteilhaft. Sie ermöglicht es dem System, Logik für die Untersuchung von Bedrohungen in Echtzeit anzuwenden. Bediener haben dabei die Möglichkeit, auf Warnmeldungen zu reagieren, die einen menschlichen Eingriff erfordern. In beiden Fällen müssen Transparenz und Kontrolle Hand in Hand gehen. 

Sofortige Kontrolle 

Sobald Sie oder Ihr System eine Bedrohung erkennen, ist eine schnelle Reaktion oder Abhilfe gefragt. Der intelligentere, absichtsbasierte Ansatz zur Bedrohungsabwehr erfordert eine Vielzahl an Daten, um eine Entscheidung zu treffen. Absichtsbasierte Systeme funktionieren als selbstlernende und selbstheilende Systeme. Sie analysieren ständig Muster und Verhaltensweisen, um neue oder sich entwickelnde Bedrohungen vorherzusagen. Daher müssen sie Traffic nicht nur in Echtzeit erkennen und interpretieren können, sondern auch die Möglichkeit haben, neue Regeln als Reaktion auf sich ändernde Bedrohungen zu implementieren. 

Sofortige Transparenz und Kontrolle dürfen aber nicht auf eine einzelne Bereitstellung oder Region beschränkt werden. Die Verbreitung verteilter Systeme (entweder Multi-Regionen- und Multi-Cloud-Implementierungen oder verteilte Teams, die geschützt werden müssen) erfordert die Fähigkeit, über physische Standorte und Grenzen hinweg zu agieren. Es gibt einige Sicherheitslösungen, die schnell sind, solange Erkennungs- und Schutzmaßnahmen nur an einem einzigen Ort durchgeführt werden. Aber so funktioniert die Welt nun mal nicht mehr. Software und Menschen werden weltweit eingesetzt und die Sicherheit muss mit diesen Entwicklungen Schritt halten. Mehr zu dieser Erkenntnis und darüber, wie API-fähige Sicherheit eine schnelle Reaktion auf Angriffe ermöglichen kann, erfahren Sie im On-Demand-Webinar „API-First Security for Real-Time Attack Response“.

Regel 4: Jeder, der für Entwicklung, Sicherheit und Operations verantwortlich ist, muss wie ein Entwickler denken 

Wir haben die Weiterentwicklung von isolierten Teams, die unabhängig (und mühsam) an der Auslieferung von Software arbeiten, hin zur Zusammenführung von Sicherheit, Entwicklung und Operations durch das Secure-DevOps-Modell miterlebt. Wir können diesen Prozess aber noch lange nicht als „erfolgreich abgeschlossen“ betrachten. Viele Führungskräfte aus Sicherheit und Entwicklung glauben, dass die Überbrückung der technischen und kulturellen Kluft zwischen den Teams zu schnelleren und sichereren Entwicklungszyklen von Anwendungen führen wird. Veraltete Praktiken und Tools bremsen die Teams aber weiterhin aus.  

Eine nennenswerte Einschränkung ist, wenn Secure DevOps mehr als Performance-Kunst statt als echte Integration ausgelegt wird. Stehen Sicherheitsteams und ihre bevorzugten Tools am Ende der Bereitstellungs-Pipeline, entspricht das nicht unbedingt Secure DevOps. Es sorgt auch nicht für eine schnellere Auslieferung der Software. Bei echtem Secure DevOps werden Sicherheits- und Schwachstellenüberprüfungen direkt in das automatisierte Test- und Bereitstellungs-Framework integriert. Es bietet Sicherheitsteams die Möglichkeit, ein integraler Bestandteil des Entwicklungsteams zu sein. Sie sind nicht erst zum Schluss involviert, um eine Liste von Schwachstellen abzuliefern und zu hoffen, dass diese behoben werden, bevor das System zum Einsatz kommt. Im Gegenzug schreiben die Entwickler Code mit sicheren Entwicklungspraktiken und automatisierte CI/CD-Pipelines testen nicht nur, ob alles funktioniert, sondern auch auf gängige Sicherheitslücken. Außerdem besitzt das Sicherheitsteam die erforderlichen Kompetenzen und Befugnisse, um umfassende Sicherheitsprüfungen durchzuführen, falls das automatisierte System etwas übersehen sollte. 

Damit Secure DevOps sein Versprechen auch halten kann, müssen Sicherheitsteams, Operations-Mitarbeiter und Entwickler eine entwicklungsorientierte Denkweise annehmen, die sich auf die Bereitstellung sicherer Software konzentriert. Räumen wir nun noch einige Schwierigkeiten bei der Verwaltung von Sicherheitsprodukten und -funktionen aus dem Weg, damit Sicherheitsexperten von Bedienern zu Entwicklern werden können. So wird nicht nur das Gesamtsystem zuverlässiger und sicherer, sondern den Mitarbeitern wird auch ein reizvollerer Karriereweg geboten.

Bessere Sicherheit ist entscheidend für die Entwicklung besserer Software

Es ist fünfzehn Jahre her, dass Amazon AWS eingeführt und die Migration in die Cloud eingeläutet hat. In dieser Zeit haben wir Hunderte von neuen Frameworks, Sprachen, Services und Tools gesehen (und viele von uns haben sie übernommen!), um schnellere und nutzerorientiertere Anwendungen zu entwickeln. Und ehrlich gesagt, hat das eine Menge Spaß gemacht. Aber der bisher kaum vermeidbare Kompromiss zwischen schneller und sicherer Bereitstellung von Software lässt sich heute tatsächlich lösen.

Dies lässt sich nur durch Sicherheitslösungen bewerkstelligen, die den Bedürfnissen moderner Teams gerecht werden. Lösungen, die Sicherheit als integralen Bestandteil der kulturellen und technischen Aspekte der Softwareentwicklung sehen. Es reicht nicht aus, Software schnell bereitzustellen. Sie muss auch sicher sein. Fastly konzentriert sich auf die Entwicklung von Webanwendungs- und API-Sicherheitslösungen, die den hier aufgeführten Regeln entsprechen. Wir sitzen alle im selben Boot.

Um noch tiefere Einblicke zu erhalten, sehen Sie sich die Anwendungsfälle für die einzelnen Regeln in unserem E-Book „Neue Regeln für die Web-App- und API-Sicherheit“ an.