WAF vs RASP: skillnaden och när ni behöver båda

En WAF (Web Application Firewall) står framför applikationen och filtrerar HTTP-trafiken innan den når koden. RASP (Runtime Application Self-Protection) sitter inne i applikationen och stoppar en attack i samma ögonblick som den försöker göra något farligt, till exempel ändra en SQL-fråga. De löser alltså olika problem och fungerar bäst tillsammans. För en CISO, en CIO eller ett dataskyddsombud är den viktiga frågan sällan vilken produkt som vinner. Frågan är vilket skydd era riskbedömningar faktiskt kräver och om ni kan visa att skyddet är lämpligt. Där gör en oberoende säkerhetsgranskning mer nytta än ännu ett verktyg.

Kort sagt

• WAF körs vid kanten (reverse proxy, CDN, lastbalanserare) och ser HTTP-begäranden och svar. Den är oberoende av programmeringsspråk och tar bort mycket brus innan det når era servrar.
• RASP körs inuti applikationsprocessen och ser vad som faktiskt exekveras: SQL-satsen, filsökvägen, kommandot. Därför kan den stoppa attacker som har tagit sig förbi WAF:en.
• Teknikerna kompletterar varandra. WAF:en hanterar volym och känd skadlig trafik, RASP bekräftar och blockerar utnyttjande inne i koden.
• Båda kan misslyckas om de införs fel. En WAF som ligger kvar i detekteringsläge för alltid eller en RASP-agent som aldrig har lasttestats skyddar mindre än ni tror.
• Valet ska följa av er riskbedömning och dokumenteras, eftersom dataskyddsförordningen och NIS2-reglerna kräver säkerhetsåtgärder som står i proportion till risken.

Innehållsförteckning

• Så fungerar en WAF
• Så fungerar RASP
• WAF och RASP jämförda
• Vilka hot stoppar respektive teknik?
• Därför är det sällan antingen eller
• Vanliga fallgropar vid införandet
• Vad det betyder för GDPR, NIS2 och er dokumentation
• Så väljer ni: fem frågor att besvara
• Låt oss granska ert applikationsskydd
• Vår syn: tekniken är halva svaret
• Vanliga frågor
• Källor

Så fungerar en WAF

En WAF är en brandvägg som förstår webbtrafik. Enligt OWASP:s DevSecOps-riktlinje placeras den som reverse proxy, i ett CDN, i en ingress-kontroller eller i en lastbalanserare, och den ser HTTP-begäranden och svar. Den vet alltså hur trafiken ser ut, men inte vad applikationen gör med den.

Skillnaden mot en vanlig nätverksbrandvägg är vilken nivå den arbetar på. Microsoft Learn beskriver att en nätverksbrandvägg inspekterar lager 3 till 7, medan en WAF arbetar på lager 7 och förstår HTTP-semantiken: huvuden, frågesträngar, begärandets innehåll och cookies. Därför kan den känna igen vanliga attacker som SQL-injektion, cross-site scripting (XSS, där skadligt skript smugglas in i en webbsida) och sökvägsbläddring (path traversal, där angriparen försöker läsa filer utanför den tillåtna katalogen).

Detekteringen bygger i grunden på mönster. En WAF jämför trafiken mot regeluppsättningar med kända attacksträngar och avvikande beteenden. En peer-granskad studie från 2022 kallar WAF en black box-teknik: den gör en syntaktisk analys av trafiken utan tillgång till applikationens logik. Det är både styrkan och svagheten. Styrkan är att samma WAF kan skydda en Java-tjänst, en .NET-portal och ett äldre PHP-system utan att någon rör koden. Svagheten är att en angripare som formulerar om sin attack kan slinka igenom. Studien räknar upp tekniker för att kringgå en WAF, bland annat normalisering, HTTP Parameter Pollution, fragmentering, synonymer för SQL-funktioner, kommentarer inne i satser och växling mellan versaler och gemener.

Så fungerar RASP

RASP vänder på perspektivet. I stället för att granska trafiken utifrån byggs skyddet in i applikationens körmiljö, oftast via en agent (till exempel en Java-agent) eller ett bibliotek för det aktuella språket. Enligt OWASP observerar RASP farliga operationer i sitt sammanhang och kan blockera dem: en SQL-sats vars struktur har ändrats av användarindata, en filåtkomst utanför tillåten katalog eller en process som startas oväntat.

Studien i ScienceDirect återger Gartners definition: RASP är en säkerhetsteknik som byggs in i eller länkas till en applikation eller dess körmiljö och som kan kontrollera exekveringen samt upptäcka och förhindra attacker i realtid. Studien beskriver RASP som en white box-teknik. Agenten installeras i applikationsservern och undersöker variabeltilldelningar i processstacken, och därför är tekniken helt beroende av applikationens programmeringsspråk.

Det praktiska värdet ligger i precisionen. När RASP ser att en inmatning faktiskt har förändrat en databasfråga behöver den inte gissa utifrån ett mönster. Den vet att attacken pågår. Därför kan den stoppa attacker som är kodade för att lura en WAF, och den ger utvecklarna exakt information om var i koden sårbarheten finns. Det gäller också svagheter som organisationen inte kände till, så RASP blir ett verktyg för både skydd och lärande.

WAF och RASP jämförda

Tabellen visar varför jämförelsen sällan landar i en vinnare. De två teknikerna sitter på olika ställen, ser olika saker och ägs ofta av olika team. Den sista raden är lätt att underskatta: ett skydd som ingen tydligt äger blir sällan väl underhållet.

Vilka hot stoppar respektive teknik?

Där WAF:en gör mest nytta

En WAF är byggd för att hantera stora mängder trafik vid kanten. Impervas vägledning om RASP pekar ut fyra områden där WAF är rätt verktyg: volymbaserade attacker (DDoS), automatiserade bottar som skördar eller skrapar innehåll, kontoövertagande genom credential stuffing (inloggningsförsök med läckta lösenord från andra tjänster) samt API-säkerhet.

Microsoft Learn lägger till två skäl som är särskilt relevanta för svenska verksamheter. Det första är regelefterlevnad: enligt sidan kräver PCI DSS, branschstandarden för kortbetalningar, en brandvägg för webbprogram framför alla program som bearbetar betalkortsdata. Det andra är publika API:er, som enligt samma sida behöver skydd mot begärandesmuggling, överdimensionerade nyttolaster och attacker på protokollnivå som nätverksbrandväggar inte inspekterar.

Där RASP gör mest nytta

RASP är den sista försvarslinjen. Den neutraliserar skadliga eller felformade nyttolaster inne i applikationen och har tillgång till detaljer om attacken, inklusive obehörig databasaktivitet. Eftersom den bedömer sammanhang i stället för att matcha mot svarta eller vita listor ger den få falsklarm, och det gör den lättare att köra i blockerande läge.

Den passar särskilt bra för applikationer som hanterar känsliga personuppgifter, som exponeras mot internet och som av olika skäl inte kan uppdateras snabbt: äldre affärssystem, leverantörsutvecklade portaler eller system där en kodändring kräver långa testcykler.

Därför är det sällan antingen eller

OWASP sammanfattar det tydligt: WAF/WAAP och RASP läggs i lager snarare än konkurrerar. WAF:en minskar bruset och hanterar volymbaserad och känd skadlig trafik, medan RASP bekräftar utnyttjande inne i applikationen där WAF:en inte kan vara säker. WAAP (Web Application and API Protection) är den bredare kategorin som utöver WAF-funktionerna även omfattar skydd mot bottar och för API:er.

Tänk på hur en riktig attack ser ut. En stor del av trafiken mot en publik tjänst är automatiserad skanning och kända attacksträngar. Den vill ni stoppa vid kanten, billigt och tidigt. Men den angripare som faktiskt riktar in sig på er verksamhet testar sig fram tills något går igenom. Då behövs ett skydd som inte bryr sig om hur attacken är kodad, utan om vad den försöker göra.

Lagerprincipen har också ett värde i incidenthanteringen. När något händer vill ni kunna se både vad som kom in vid kanten och vad som hände i applikationen. Med två oberoende källor blir det lättare att avgöra om personuppgifter faktiskt har exponerats, och det avgör i sin tur om och hur incidenten ska rapporteras. Hur dyrt det blir när den bedömningen brister syns i vår genomgång av hur kostnaden för dataintrång ökar.

Vanliga fallgropar vid införandet

Ett felinställt skydd ger falsk trygghet. OWASP listar de misstag som oftast gör en WAF verkningslös:

1. Kvar i detekteringsläge för alltid. WAF:en loggar attacker men stoppar ingenting. Bestäm i förväg när och hur ni går över till blockering.
2. Blockering utan inställning. Regler som slås på rakt av stoppar legitim trafik, och då stängs de ofta av helt. Trimma först reglerna mot verklig trafik.
3. Direktåtkomst till origin. Om applikationsservern går att nå direkt, förbi moln-WAF:en eller CDN:et, kan angriparen helt enkelt gå runt skyddet.
4. WAF som enda åtgärd. En WAF-regel köper tid, men sårbarheten i koden finns kvar tills den rättas.
5. Trafik som inte kan inspekteras. Krypterad trafik som WAF:en inte kan dekryptera passerar oinspekterad.
6. Larm som ingen äger. Varningar utan en ansvarig mottagare leder inte till någon åtgärd.

För RASP rekommenderar OWASP att ni börjar där injektionsrisken är hög och kodändringar går långsamt. Starta i monitorläge och jämför fynden med WAF-loggar och resultat från dynamisk säkerhetstestning (DAST). Mät latens och minnesåtgång under lasttest innan ni slår på blockering, och planera agentuppdateringar tillsammans med uppdateringar av runtime och ramverk.

Lägg märke till att flera av punkterna inte handlar om teknik utan om styrning: vem som äger larmen, vem som beslutar om blockering och hur uppdateringar planeras. Det är där många införanden fallerar, och där en tydlig ansvarsfördelning gör störst skillnad.

Vad det betyder för GDPR, NIS2 och er dokumentation

Dataskyddsförordningen kräver att den som behandlar personuppgifter vidtar lämpliga tekniska och organisatoriska säkerhetsåtgärder utifrån riskerna med behandlingen. NIS2-direktivet, som i Sverige genomförs genom ny cybersäkerhetslagstiftning, ställer motsvarande krav på riskbaserade säkerhetsåtgärder för verksamheter i de sektorer som omfattas. Ingen av dem säger ”använd WAF” eller ”använd RASP”. Däremot förväntas ni kunna visa att ni har bedömt riskerna och valt skydd som står i proportion till dem.

I praktiken betyder det tre saker för en svensk organisation med publika webbapplikationer:

• Koppla skyddet till riskbedömningen. En kundportal med hälsodata, löneuppgifter eller betalningar har en annan riskprofil än en informationssajt. När en konsekvensbedömning avseende dataskydd visar höga risker ska de tekniska åtgärderna svara mot just dem.
• Dokumentera valet. Varför räcker WAF för system A men inte för system B? Ett dokumenterat resonemang är det ni visar en tillsynsmyndighet, en revisor eller en kund som ställer säkerhetsfrågor i en upphandling.
• Ställ krav på leverantörer. Många webbapplikationer drivs av personuppgiftsbiträden. Fråga hur deras applikationsskydd ser ut, på samma sätt som ni granskar avtal och hosting. Leverantörer som bygger in säkerheten från början, som en säker EU-hostad coachingplattform med integritet inbyggd i designen, gör det arbetet enklare.

Svenska exempel visar varför det spelar roll. Både en hackad advokatbyrå och tre kommuner som utsattes för dataintrång visar att följderna av ett intrång sällan stannar vid tekniken. De landar hos ledningen, dataskyddsombudet och de registrerade.

Så väljer ni: fem frågor att besvara

Använd frågorna som beslutsunderlag inför nästa budget- eller arkitekturbeslut:

1. Vilka applikationer är exponerade mot internet, och vilka personuppgifter hanterar de? Börja med en inventering. Utan den vet ni inte var skyddet behövs.
2. Hur snabbt kan ni rätta en sårbarhet i koden? Går det på dagar räcker ofta en WAF tillsammans med god säker utveckling. Tar det månader, eller är koden leverantörens, talar mycket för RASP.
3. Hanterar ni kortbetalningar eller publika API:er? Då är en WAF i praktiken ett grundkrav.
4. Har er teknikstack stöd för RASP? RASP är språkberoende. Kontrollera att era språk, ramverk och runtime-versioner stöds innan ni planerar.
5. Vem äger skyddet och larmen? Utse ansvariga för WAF-regler, RASP-agenter och incidentflödet innan något driftsätts.

Svaren ger oftast ett tydligt mönster: en WAF som bas framför alla publika tjänster, RASP för de applikationer där risken är högst och rättningar tar längst tid, och en dokumenterad motivering som binder ihop allt.

Låt oss granska ert applikationsskydd

Evertrust genomför säkerhetsgranskningar, GAP-analyser och konsekvensbedömningar (DPIA) som visar var ert skydd räcker och var det brister, med en juridisk koppling till GDPR, NIS2 och ISO 27000. Läs mer om våra säkerhetsgranskningar och GAP-analyser.

Om ni behöver hålla ordning på åtgärder, risker och dokumentation över tid samlar vår GRC-plattform Trustview regelefterlevnaden enligt GDPR, ISO 27000, DORA, NIS2 och E-privacy på ett ställe.

Vår syn: tekniken är halva svaret

Diskussionen om WAF mot RASP förs oftast som en produktfråga. Vi menar att den hör hemma i riskhanteringen. Båda teknikerna är värdefulla, och de flesta organisationer med kritiska webbapplikationer har nytta av båda. Men värdet uppstår först när valet bygger på en genomtänkt riskbedömning, när någon äger skyddet och när beslutet går att visa upp.

Därför arbetar vi i skärningspunkten mellan juridik och informationssäkerhet. Ett dataskyddsombud, en CISO och en utvecklingschef ser samma applikation med olika ögon, och de behöver ett gemensamt underlag. Vi hjälper till att ta fram det: med granskningar som pekar ut var riskerna finns, konsekvensbedömningar som visar vad som står på spel för de registrerade och ett ramverk för att dokumentera varför åtgärderna är lämpliga.

Vårt råd är enkelt. Börja med frågan om vilka risker ni behöver hantera, inte med vilket verktyg ni ska köpa. Då blir både WAF och RASP rätt investeringar på rätt ställen.

Jesper

Vanliga frågor

Vad är skillnaden mellan en vanlig brandvägg och en WAF?

En nätverksbrandvägg filtrerar trafik på flera nivåer, framför allt utifrån adresser, portar och protokoll. En WAF arbetar på applikationsnivån och förstår HTTP: huvuden, frågesträngar, innehåll och cookies. Därför kan den känna igen attacker som SQL-injektion och XSS, som en vanlig brandvägg släpper igenom.

Kan RASP ersätta en WAF?

Nej, inte i de flesta miljöer. RASP ser bara den trafik som redan har nått applikationen och är inte byggd för att stoppa DDoS, bottar eller credential stuffing vid kanten. De två fungerar bäst i lager, med WAF:en som första filter och RASP som sista försvarslinje.

Är ett CDN samma sak som en WAF?

Inte automatiskt. Ett CDN distribuerar och cachar innehåll. En WAF kan köras i ett CDN, precis som i en reverse proxy, en ingress eller en lastbalanserare. Kontrollera att WAF-funktionen faktiskt är aktiverad och att er applikationsserver inte går att nå direkt förbi CDN:et.

Räcker en WAF för att uppfylla GDPR?

Ingen enskild teknik uppfyller GDPR på egen hand. Förordningen kräver lämpliga tekniska och organisatoriska åtgärder utifrån risken, och en WAF kan vara en viktig del av dem. Det avgörande är att valet bygger på en riskbedömning och att ni kan visa varför skyddet räcker för de personuppgifter applikationen hanterar.

Källor

• OWASP DevSecOps Guideline: Runtime Application Protection: WAF, WAAP, and RASP
• Microsoft Learn: Web Application Firewall för Azure-nätverk
• Systematic Approach for Web Protection Runtime Tools (ScienceDirect, 2022)
• A Guide to Runtime Application Self-Protection (RASP)

Rekommendationer

• Sårbarhet i Sonicwalls brandväggar utnyttjas i ransomware-attacker
• AI skapar nya möjligheter och risker inom cybersäkerhet