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.
Kort samengevat: runtimebescherming van binnenuit de applicatie
- Wat het is: Een technologie die binnen de runtime van een applicatie draait en aanvallen blokkeert op het moment van exploitatie, met de uitvoeringscontext van de code zelf.
- RASP versus WAF: Een WAF filtert verkeer aan de rand op patronen; RASP kijkt naar wat de code werkelijk doet, wat het grootste deel van de afweging tussen valse positieven en valse negatieven wegneemt.
- Waar het stopt: RASP instrumenteert alleen de serverruntime, dus browseraanvallen (Magecart, formjacking, DOM XSS) vallen volledig buiten zijn bereik.
Weinig tijd? Bekijk de client-side monitoring van cside. Het past het RASP-idee om de runtime te bewaken toe op de browser, de helft van de applicatie die RASP niet kan zien.
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.
