RASP — Runtime Application Self-Protection — is een beveiligingstechnologie die binnen een applicatie draait en haar van binnenuit beschermt. Door de runtime van de applicatie te instrumenteren, observeert RASP hoe invoer daadwerkelijk wordt gebruikt en kan het aanvallen detecteren en blokkeren op het moment van exploitatie, met context die een perimeterverdediging nooit ziet.
Hoe werkt RASP?
RASP koppelt zich aan de runtime van de applicatie — een JVM-agent, een .NET-profiler, een Node-instrumentatiehook — en onderschept beveiligingsrelevante operaties: databasequery's, bestandstoegang, commando-uitvoering, deserialisatie. Wanneer de data van een verzoek een van die operaties bereikt op een manier die overeenkomt met exploitatie (een parameter die de SQL-structuur herschrijft, een pad dat uit zijn directory ontsnapt), kan RASP dit loggen, alarmeren of de operatie binnen het proces blokkeren.
De bepalende eigenschap is context. Een perimeterfilter raadt kwaadaardigheid uit de vorm van het verzoek; RASP kijkt naar wat de code er daadwerkelijk mee doet, wat het grootste deel van de afweging tussen false positives en false negatives laat verdwijnen.
RASP vs WAF vs client-side monitoring
| WAF | RASP | Monitoring op de browserlaag | |
|---|---|---|---|
| Waar het draait | Vóór de app | Binnen de server-runtime | In de browsersessie van de bezoeker |
| Ziet | Verzoeken en antwoorden | De daadwerkelijke code-uitvoering | Scripts die op de pagina draaien |
| Blinde vlek | Hoe invoer wordt gebruikt | Alles aan de client-side | De interne werking van de server |
| Stopt | Bekende aanvalspatronen | Exploits die de runtime bereiken | Skimming, geïnjecteerde scripts, data-exfiltratie |
| Uitrol | Op netwerkniveau | Agent per taal/runtime | Scripttag |
Waar RASP stopt
De grens van RASP is het serverproces. Alles wat gebeurt nadat het antwoord is vertrokken — de JavaScript die je pagina en haar tientallen third-party leveranciers in de browser van de bezoeker uitvoeren — is er onzichtbaar voor. Een gecompromitteerde analytics-tag die een afrekenformulier skimt, raakt de geïnstrumenteerde runtime nooit aan; vanuit het perspectief van de server is er niets abnormaals gebeurd.
Die client-side kloof heeft zijn eigen aanvalsklassen — JavaScript-injectie, DOM-based XSS, Magecart — en, voor betaalpagina's, zijn eigen regelgevende antwoord in de vereisten voor scriptinventarisatie en manipulatiedetectie van PCI DSS 4.0.1 (6.4.3 en 11.6.1).
Het equivalent op de browserlaag
Het idee achter RASP — bewaak de runtime, niet de perimeter — geldt evenzeer voor de browser, waar de "runtime" elk script is dat in een echte sessie draait. Dat is wat de client-side monitoring van cside doet: het observeert wat elk script daadwerkelijk doet terwijl het draait — DOM-toegang, het uitlezen van formulieren, uitgaande verzoeken — en markeert gedrag dat er niet hoort te zijn. cside is geen RASP; het is dezelfde beschermingsfilosofie toegepast op de helft van de applicatie die RASP niet kan zien. De meeste volwassen stacks eindigen met een WAF aan de perimeter, RASP of gelijkwaardige controles in de server-runtime, en runtime-monitoring in de browser — gelaagde client-side beveiliging in plaats van één enkele oplossing.
