Was RASP hätte sein sollen

In den letzten Jahren hat die Anwendungssicherheit Welt hat den Aufstieg von gesehen Runtime Application Self-Protection (RASP) Technologie. Wie von Gartner beschrieben, ist RASP eine Sicherheitstechnologie, die in eine Anwendung oder deren Laufzeitumgebung integriert ist und in der Lage ist, Echtzeitangriffe zu kontrollieren und zu verhindern. Leider viele Webanwendungs-Firewall (WAF) Unternehmen sahen eine Gelegenheit, den Begriff zu nutzen. Sie führten „RASP-ähnliche“ Agenten auf der Netzwerkschicht ein, die die Definition der RASP-Technologie nicht vollständig umfassen.

Im Gegensatz dazu arbeitet die echte RASP-Technologie auf der Anwendungsebene, wo sie über den vollständigen Kontext des Benutzers, der Anwendungslogik und der Domäneninformationen verfügt. Dieser Kontext ermöglicht es einem RASP, fundierte Entscheidungen über die Sicherheit der Anwendung zu treffen und Exploits zu verhindern, bevor sie Schaden anrichten können. Infolgedessen sollte ein echter RASP keine Fehlalarme und eine reduzierte Latenz aufweisen, was eine sofortige Leistungssteigerung bietet. True RASP erfordert eine Liste unveränderlicher Regeln, die den Kontext verwenden, um zu verstehen, wann eine neue Schwachstelle eingeführt wird, und entsprechend zu handeln. Diese Unveränderlichkeit ist möglich, wenn Regeln auf der Anwendungsebene in die Codebasis integriert werden und nach der Bereitstellung keine Änderungen mehr erforderlich sind.

Drei Bereiche, in denen RASP schief gelaufen ist

1. Das Problem des bellenden Hundes: Die meisten Warnungen sind falsch positiv

Das Problem bei WAFs besteht darin, dass sie auf der Netzwerkebene arbeiten, einem verzögerten Indikator für die Ausführung von Anwendungen. Der daraus resultierende Mangel an Kontext führt zu hohen False-Positive-Raten, langen Wartezeiten und schlechter Leistung, da WAFs die Art einer Schwachstelle nur auf der Grundlage dessen, was sie zuvor ausgesetzt waren, erraten können.

Stellen Sie sich einen Wachhund im Garten vor, der bellt, wenn er ein Geräusch jenseits des Zauns hört. Diese Geräusche können die Annäherung eines Eindringlings, aber auch vorbeifahrende Autos sein. Der Wachhund kann den Unterschied nicht genau einschätzen, sodass die Schwere eines bestimmten Geräusches verloren geht, sodass die Personen im Haus nicht wissen können, welche Warnungen echt und welche falsch positiv sind. Dieses Szenario ist im Wesentlichen die Fähigkeit des standardmäßigen RASP-Angebots.

2. Das 999-Bösewicht-Problem: Nur in der Lage, eine Probe zu testen

Ob Sie es glauben oder nicht, einige Anbieter raten Ihnen, ihre Sicherheitslösung nur in Produktionsumgebungen auszuführen, wenn Sie nur eine Stichprobengröße schützen. Das bedeutet, dass es eine Probe zieht – vielleicht eine von 1,000 Anfragen – und diese Probe testet, während es festhält, was für die nächsten 999 passiert. Das heißt, wenn Sie ein guter Schauspieler sind, wird Ihre Signatur überprüft. Aber unabhängig davon, ob die folgenden 999-Akteure schlechte Absichten haben oder nicht, sie werden durchkommen. Dieser Mangel an Konsistenz ist alles darauf zurückzuführen, dass WAF-basierte RASPs die Leistungsanforderungen nicht erfüllen können, jede Anforderung testen zu müssen.

3. Das „Es dauert zu lange“-Problem: Latenz beeinträchtigt die Leistung

Jedes Mal, wenn Sie ein WAF-basiertes RASP verwenden, treten erhöhte Latenzen auf, da es die Codebasis der Anwendung in keiner Weise beeinflussen kann. In der Zwischenzeit müssen weit verbreitete RASPs ganze Text-Payloads an ihren Web-Analyzer senden und dann warten, bis sie zurückgesendet werden, was lange dauern kann. Und wenn Ihre Kunden auf Zahlungen warten, geben sie möglicherweise auf und suchen stattdessen Ihre Konkurrenten auf.

Die Verbesserung dieses Prozesses ähnelt der Codeoptimierung. Beim Erstellen einer Liste richten Entwickler diese so ein, dass neue Elemente am Anfang einer Liste anstatt am Ende hinzugefügt werden. Diese Optimierung verhindert, dass die VM die gesamte Liste jedes Mal neu erstellt, wenn ein neues Element hinzugefügt wird, wodurch eine zunehmende Latenz verhindert wird, wenn die Liste wächst. Compiler-Ingenieure gingen diese Probleme an, indem sie in den frühen 2000er Jahren Just-in-Time-Kompilierung (JIT) implementierten, die den Code automatisch basierend auf den Nuancen der jeweiligen Sprache optimiert.

Warum wurde die Definition von RASP so verwässert?

Die Entwicklung der RASP-Technologie erfordert eine Kombination aus Sicherheits- und Software-Engineering-Fähigkeiten. Um effektiv zu sein, muss der RASP-Entwickler die Architektur der Anwendung und die Nuancen der verwendeten Programmiersprache genau verstehen. Dies erfordert Domänenexpertise, die unter Sicherheitsexperten selten ist.

True RASP optimiert Code für Leistung und Sicherheit

Da sich die meisten RASP-Plattformen wie WAFs verhalten, ist ein enormer Overhead damit verbunden, der es erforderlich macht, sie im Beispielmodus auszuführen. Im Gegensatz dazu führt ein echter RASP den eigentlichen Schutz zur Laufzeit durch.

Diese Vorgänge befinden sich im Arbeitsspeicher, was sehr effizient ist, und da dieser im selben Bereich wie Ihre Anwendungen vorhanden ist, sind sie sehr leistungsfähig. Da der Schutz zur Laufzeit ausgeführt wird, ist es nicht erforderlich, die Rate zu begrenzen oder den Schutz in Stichprobengrößen durchzuführen, da der eigentliche Vorgang nur wenige Millisekunden dauert.

Unabhängig von Änderungen an der Anwendung bleibt die leistungsstarke Sicherheit konstant. Diese Philosophie stimmt mit der Philosophie von Infrastructure-as-Code überein, bei der Sie den gewünschten Zustand Ihrer Infrastruktur definieren und der Zustand der Infrastruktur gleich bleibt, egal was in der Umgebung passiert.

RASP entspricht per Definition vielen Prinzipien von Infrastructure-as-Code. Diese Parallele ist aufgrund des tiefen Kontextbewusstseins der Anwendung und der Sprache, in der sie erstellt wurde, möglich. Wie Infrastruktur als Code, kann und sollte ein echter Ansatz für RASP Unveränderlichkeit nutzen, um sicherzustellen, dass Regeln unabhängig von Änderungen an der Codebasis angewendet werden.

Unveränderlichkeit ist möglich, indem die Ausgabe einer Funktion beim ersten Aufruf überprüft und alle fehlerhaften Funktionen durch geschützte Funktionen ersetzt werden, um sicherzustellen, dass die Anwendung während der Ausführung immer fehlerfrei ausgeführt wird.

Dieser Ansatz ermöglicht eine von der Bereitstellung unabhängige Sicherheit und erfordert keine Codeänderungen am Anwendungscode, keine Optimierung oder das Warten auf Bereitstellungsfenster.

Indem der Schutz während der Laufzeit ausgeführt wird und die Ergebnisse mit sofortigem Schutz auf allen laufenden Instanzen der Anwendung gepatcht werden, werden ständige Fehlalarme überflüssig und das Risiko zukünftiger Exploits beseitigt.

RASP kann und sollte auf einem höheren Standard gehalten werden

Kurz gesagt, RASP sollte auf einem höheren Standard gehalten werden. Auf diese Weise ist es möglich, Tausende von Anwendungen zu sichern, die Gesamtbetriebskosten Ihrer WAFs zu senken und Burnout in Ihren Sicherheitsteams zu verhindern.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been