RASP — wat is het, werkingsprincipe en real-time beveiliging

Wat is RASP?

Runtime Application Self-Protection (RASP) — een beveiligingstechnologie die in de buildfase of via een runtime-agent in de applicatie wordt geïntegreerd. RASP analyseert het gedrag van de applicatie tijdens de uitvoering en neemt beslissingen over het blokkeren van aanvallen op basis van context: waar de aanroep vandaan komt, welke gegevens worden doorgegeven, wat de status van de stack is. In tegenstelling tot handtekeninggebaseerde systemen, zoekt RASP niet naar bekende aanvalspatronen — het detecteert afwijkend gedrag dat afwijkt van het verwachte uitvoeringsscenario van de code.

Het RASP-concept werd in 2011 geformaliseerd door Gartner en de eerste commerciële implementaties verschenen in 2014–2015. Voor mobiele platforms werd RASP vanaf 2017 actief toegepast, toen de markt de ontoereikendheid van traditionele obfuscatie besefte. Volgens het rapport van MarketsandMarkets (2025) bedraagt de omvang van de RASP-oplossingenmarkt 2,8 miljard USD met een jaarlijkse groei van 24,5%. Implementatie van RASP wordt aanbevolen door de standaarden OWASP Mobile Top 10 en PCI DSS 4.0 voor applicaties die betaalgegevens verwerken.

RASP werkt op twee niveaus: interception en assessment. Interception — het onderscheppen van systeem- en bibliotheekaanroepen via hooks die in de code worden ingebouwd in de buildfase of tijdens runtime via dynamische instrumentatie. Assessment — analyse van de aanroepcontext: controle van invoerparameters, call-stack, sandbox-status, aanwezigheid van een debugger. De beslissing wordt genomen op basis van het door de ontwikkelaar ingestelde beveiligingsbeleid. Het beleid kan strikt zijn (blokkeren), zacht (loggen) of adaptief (gedrag aanpassen aan het dreigingsniveau).

Hoe werkt RASP: architectuur en mechanismen

De architectuur van een RASP-agent bestaat uit drie componenten: de instrumentatielaag, de analyzer en het beleid. De instrumentatielaag onderschept systeemaanroepen en framework-aanroepen. De analyzer controleert de context op overeenstemming met verwachte patronen. Het beleid bepaalt de reactie.

Code-instrumentatie

Voor mobiele applicaties wordt compile-time-instrumentatie gebruikt: bytecode of native code wordt in de buildfase aangepast — voor elke gevaarlijke aanroep wordt een controle ingevoegd. De compiler van de RASP-agent wijzigt de ingangspunten FileOutputStream.write(), Runtime.exec(), Class.forName() en android.app.Activity.onStart(). Voor Android wordt DEX-bytecode-transformatie via een Gradle-plugin gebruikt; voor iOS wordt het Mach-O-binary-bestand aangepast via een post-link-script.

Contextanalyse

Bij het onderscheppen van een aanroep analyseert RASP: de aanroepende klasse en methode (wie roept aan), de stack-trace (aanroepketen), argumenten (doorgegeven gegevens), retourwaarde (wat wordt geretourneerd), tijdstempel en thread-ID. Een afwijking wordt geregistreerd wanneer bijvoorbeeld Runtime.exec() niet vanuit de UI-thread en niet vanuit applicatiecode wordt aangeroepen, maar vanuit een bibliotheek die via JNI met een niet-standaard pad is geladen. Of wanneer FileOutputStream.write() gegevens ontvangt die uitvoerbare bytecode bevatten in plaats van een verwachte PNG-header.

Reactiebeleid

RASP ondersteunt drie soorten reacties: Block — noodstop van de applicatie bij detectie van een aanval, Log — verzending van incidentdetails naar de logverzamelingsserver zonder de applicatie te stoppen, Deceive — vervanging van de retourwaarde door een valse, zodat de aanvaller onjuiste gegevens ontvangt. De combinatie van Log en Deceive maakt het mogelijk inlichtingen over de aanvaller te verzamelen zonder het feit van detectie te onthullen.

// Voorbeeld: RASP-controle van Runtime.exec()-aanroep
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Controle van caller
        String caller = stack[1].getClassName();

        // Als de aanroep niet uit ons pakket komt — verdacht
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Controleer commando op zwarte lijst
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: leeg proces
            }
        }

        return null; // uitvoering toestaan
    }
}

RASP vs WAF en andere beveiligingsmiddelen

RASP wordt vaak vergeleken met Web Application Firewall (WAF), maar het fundamentele verschil zit in de positionering. WAF bevindt zich aan de netwerkperimeter en analyseert alleen HTTP-verzoeken. RASP werkt binnen de applicatie en ziet de verwerkingslogica.

In tegenstelling tot obfuscatie (ProGuard, DexGuard), die code onleesbaar maakt, detecteert RASP actief aanvallen tijdens exploitatie. Obfuscatie is passieve beveiliging: als de aanvaller voldoende tijd besteedt aan reverse engineering, wordt de code gelezen. RASP is actief: het ziet dat de aanvaller probeert de applicatie te debuggen en reageert voordat er ook maar één regel code is gelezen. De combinatie van obfuscatie + RASP biedt gelaagde beveiliging, waarbij obfuscatie de analyse vertraagt en RASP de aanval in de instrumentatiefase onderbreekt.

RASP in mobiele applicaties

Mobiele RASP-oplossingen zijn aangepast aan de specificiteit van Android en iOS. In tegenstelling tot server-Java-applicaties werken mobiele RASP-agenten in omstandigheden met beperkt geheugen en batterij, wat lichte instrumentatie vereist.

RASP op Android

Op Android wordt de RASP-agent ingebouwd via een Gradle-plugin die de DEX-bytecode in de buildfase wijzigt. De agent onderschept meer dan 50 systeemaanroepen, waaronder: Runtime.exec() voor het detecteren van het starten van su of Frida, Class.forName() voor het identificeren van het laden van verdachte klassen, System.loadLibrary() voor het controleren van het laden van native bibliotheken vanaf niet-standaard paden. Daarnaast wordt de aanwezigheid in /proc/self/maps van de bibliotheken frida-agent, frida-helper, libinject en substrate gecontroleerd.

RASP op iOS

Op iOS wordt RASP geïmplementeerd via nabewerking van het Mach-O-binary-bestand. Voor iOS is de complexiteit hoger vanwege de strikte eisen van Apple aan het wijzigen van binaire bestanden. De agent onderschept aanroepen van de functies fork(), dlopen(), ptrace() en controleert de aanwezigheid van CydiaSubstrate.dylib in geladen bibliotheken. RASP voor iOS kan code niet wijzigen in de App Store-build — alleen voor Enterprise-distributie. Voor de App Store wordt aanbevolen compile-time-instrumentatie via Swift Macro of Objective-C method swizzling te gebruiken.

Detectie van analysetools

Mobiele RASP detecteert: Frida (via controle van /proc/self/maps en /data/local/tmp/frida*), Xposed Framework (via controle van de.robv.android.xposed.XposedBridge in ClassLoader), JDWP-debugger (via Debug.isDebuggerConnected()), emulators (via controle van Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) en de debuggable-vlag in AndroidManifest. Volgens NowSecure Mobile Threat Report (2025) detecteert de RASP-agent 89–97% van de geïnstrumenteerde Frida-sessies.

Implementatie van een RASP-agent in de praktijk

Het implementeren van RASP in een mobiele applicatie vereist configuratie van instrumentatie, definitie van beleid en integratie met een SIEM-systeem voor het verzamelen van incidentlogs.

Keuze van implementatie: compile-time vs runtime

Compile-time-instrumentatie — wijziging van bytecode in de buildfase, die de prestaties tijdens runtime niet beïnvloedt. Runtime-instrumentatie (via Java Agent op de server of Frida op de client) — flexibeler, maar voegt 5–10% overhead toe. Voor mobiele applicaties wordt de compile-time-benadering aanbevolen, omdat deze geen permanente netwerkverbinding vereist en geen batterij verbruikt voor analyse.

Integratie met bestaande bibliotheken

De RASP-agent moet correct werken met populaire SDK's. Firebase Crashlytics, Google Analytics en Appsee mogen niet worden geblokkeerd. Configuratie van een whitelist voor bekende bibliotheken is verplicht. In de configuratie van de agent worden uitzonderingen ingesteld: als de aanroep afkomstig is van de klasse com.google.firebase — wordt de controle overgeslagen. Whitelist wordt bij elke SDK-release bijgewerkt.

Voorbeeld van incidentafhandeling

Bij detectie van Frida door de RASP-agent vindt plaats: verzameling van context (stack-trace, OS-versie, tijd), verzending van gegevens naar de logserver in versleutelde vorm, uitvoering van het beleid (crash, log-only of deceive), verhoging van de teller voor het bepalen van een massale aanval. Gegevens van verschillende apparaten worden op de server geaggregeerd om aanvalspatronen te identificeren.

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

Beperkingen en valse alarmen

RASP is geen wondermiddel. De technologie heeft beperkingen die in acht moeten worden genomen bij het ontwerpen van beveiliging.

Prestaties

Elke onderschepte aanroep voegt een contextcontrole toe. Bij agressieve configuratie (onderschepping van alle IO- en exec-aanroepen) kunnen de prestaties met 5–15% dalen. Voor mobiele applicaties is de opstarttijd kritiek: RASP-initialisatie voegt 200–500 ms toe bij het opstarten. Gerichte instrumentatie wordt aanbevolen — alleen kritieke functies, niet alle mogelijke functies. Profilering met de RASP-agent is verplicht in de testfase.

Valse alarmen

RASP kan legitiem gedrag blokkeren: Firebase Crashlytics die een foutstack via een netwerkaanroep verzendt, kan worden beschouwd als gegevensexfiltratie; Google Play Integrity API die de apparaatintegriteit controleert, kan worden geïdentificeerd als een verdachte aanroep. Om valse alarmen te verminderen is een leerperiode (learning mode) van 7–14 dagen nodig, waarin RASP alleen logt maar niet blokkeert.

Omzeiling van RASP

Als de aanvaller toegang krijgt op kernel-niveau (via een kernel-exploit), kan RASP zelfs zijn eigen controles niet vertrouwen — de agent werkt in de gebruikersruimte en ziet wat de kernel hem toestaat. Om omzeiling op kernel-niveau te voorkomen, wordt Secure Boot Chain-controle gebruikt in combinatie met serverattestatie. Bovendien moet de RASP-agent zelf worden geobfusceerd en beschermd tegen debugging — anders verwijdert of schakelt de aanvaller RASP uit voordat de aanval begint.