Ob Anwendungen oder APIs, ob traditionelle, moderne oder KI-Anwendungen – Programmierbarkeit ist ein wichtiges Werkzeug im Sicherheitsinstrumentarium, um Sicherheitsprobleme zu bewältigen.
Eine der Methoden, mit denen wir die Sicherheit von Anwendungen und APIs gewährleisten, besteht darin, sie auf Schwachstellen und Korrektheit zu testen, bevor wir sie für Kunden und Partner freigeben. Eine beliebte Technik zum Testen von Anwendungen und APIs ist das sogenannte Fuzz-Testing.
Beim Fuzz-Testing werden unerwartete Eingaben – etwa Zeichenfolgen anstelle von Zahlen, Sonderzeichen sowie zu lange oder zu kurze Eingaben – gesendet, um die Reaktion der API oder Anwendung zu ermitteln. Eine robuste Implementierung verarbeitet solche Eingaben, indem sie sie als ungültig zurückweist. Ebenso wichtig wie das Testen der Eingabeverarbeitung ist jedoch das Testen des Codes, der diese Eingabeverarbeitung durchführt.
Mit anderen Worten: Es reicht nicht aus, dass die Anwendungs- oder API-Logik ungültige Eingaben ablehnt; auch die Logik zur Überprüfung auf ungültige Eingaben muss robust sein.
Nun wird sich, wie so oft in der Welt der Anwendungssicherheit, jemand eine Eingabe ausdenken, die weder erwartet noch berücksichtigt wurde. Wir sehen darüber hinweg, dass viele Implementierungen zur Eingabebereinigung schlichtweg schlecht sind, und tun so, als wären sie alle robust und könnten 99 % aller fehlerhaften Eingaben erkennen.
Selbst unter dieser utopischen Annahme bleibt immer dieses eine Prozent, an das niemand gedacht hat. Auf diese Weise entstehen unter anderem Zero-Day-Schwachstellen.
Manchmal sind sie das Ergebnis eines Fehlers im Technologie-Stack. Vielleicht liegt es am Webserver, am Anwendungsserver oder am GraphQL-Server. Vielleicht steckt der Fehler in einem Konnektor zu einer Datenquelle, etwa einer Vektordatenbank, die den immer beliebteren Anwendungsfall der abrufgestützten Generierung (Retrieval-Augmented Generation, RAG) für generative KI unterstützt. Oder vielleicht treten neue Schwachstellen bei der KI-Inferenz auf, wie etwa Probllama. Schließlich bringt eine neue Ebene innerhalb der umfassenderen Anwendungsarchitektur auch neue Schwachstellen mit sich.
Das sind die Sicherheitslücken, die im Internet Panik auslösen. Ihnen verdanken wir Apache Killer (2011), HeartBleed (2014), Spectre und Meltdown (2018) sowie Log4Shell (2021).
Dabei handelte es sich um unvorhergesehene Schwachstellen. Von Entwicklern, SecOps-, DevSecOps- und QA-Teams konnte nicht erwartet werden, dass sie diese vorhersehen. Das konnten sie wirklich nicht.
Ungeachtet dessen, dass Entwickler und Sicherheitsexperten dies nicht vorhersehen konnten, muss beim Auftreten einer Zero-Day-Schwachstelle etwas unternommen werden. Dies gilt insbesondere, wenn eine Organisation durch den Einsatz der betreffenden Technologie gefährdet wäre. Dadurch wird aus einem Risiko eine Bedrohung, und Bedrohungen müssen neutralisiert werden.
An dieser Stelle kommt die Programmierbarkeit von Anwendungsdiensten ins Spiel.
Die Programmierbarkeit von Anwendungsdiensten ist nichts Neues. Unternehmen nutzen sie bereits seit den Anfängen des Internets, um verschiedenste Lösungen zu implementieren.
Zu den häufigsten Einsatzmöglichkeiten der Programmierbarkeit im Datenpfad gehören:
- Sicherheit: Programmierbarkeit ist entscheidend, um Zero-Day-Bedrohungen abzuwehren und neu auftretende Sicherheitsrisiken zu bewältigen.
- Anwendungsvermittlung: Ermöglicht eine nahtlose Benutzererfahrung bei Anwendungs-Upgrades und -Migrationen, unterstützt die Modernisierung und integriert neue APIs kosteneffizient.
- Service-Orchestrierung: Integriert Workflows und Dienste von Drittanbietern ohne Beeinträchtigung der Benutzer in Anwendungen und verkürzt so die Markteinführungszeit.
- Verfügbarkeit: Unterstützt Lastverteilung und moderne Bereitstellungsverfahren wie Canary-Releases und A/B-Tests.
Wir wissen, dass diese Anwendungsfälle weit verbreitet sind, denn das belegen unsere internen Daten. Mehr als 70 % unserer Kunden nutzen täglich programmierbare Funktionen für eine Vielzahl von Lösungen. Einige davon sind auf Sicherheit ausgerichtet.
Daher war es keine Überraschung, als wir den Gesamtmarkt untersuchten und feststellten, dass Programmierbarkeit bei den wichtigen technischen Funktionen für die API-Sicherheit an erster Stelle steht.
Die Vielseitigkeit einer API-Sicherheitslösung, die Programmierbarkeit unterstützt, ist nahezu grenzenlos. Und obwohl F5 bei dieser Funktion zweifellos Pionierarbeit geleistet hat, gehört sie inzwischen allgemein zum Marktstandard für Anwendungsdienste. Es gibt nur sehr wenige Anwendungsdienste – insbesondere solche, die auf den Schutz von Anwendungen und APIs ausgerichtet sind –, bei denen Programmierbarkeit nicht zu den Kernfunktionen gehört.
Das liegt daran, dass Programmierbarkeit die Grundlage dafür bildet, Zero-Day-Bedrohungen einzudämmen und Unternehmen in die Lage zu versetzen, Patch-Pläne gezielter zu entwickeln, die einen erheblichen Anteil ihrer Systeme betreffen.
Programmierbarkeit ermöglicht nun ja so gut wie alles. Doch im Bereich der Sicherheit – insbesondere der API-Sicherheit – ist sie nicht nur ein „Nice-to-have“, sondern unverzichtbar.
Weitere Einblicke zum Thema APIs finden Sie in unserem Bericht zum Stand der Anwendungsstrategie: API-Sicherheit.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.