Wat RASP had moeten zijn

De afgelopen jaren is de applicatiebeveiliging wereld heeft de opkomst gezien van zelfbescherming van runtime-applicaties (RASP) technologie. Zoals beschreven door Gartner, is RASP een beveiligingstechnologie die is geïntegreerd in een applicatie of de runtime-omgeving en in staat is om realtime aanvallen te controleren en te voorkomen. Helaas veel Webtoepassingsfirewall (WAF) bedrijven zagen een kans om de term te benutten. Ze introduceerden "RASP-achtige" agenten op de netwerklaag, die de definitie van RASP-technologie niet volledig omarmen.

Echte RASP-technologie werkt daarentegen op de applicatielaag, waar het de volledige context van de gebruiker, applicatielogica en domeininformatie heeft. Deze context stelt een RASP in staat om weloverwogen beslissingen te nemen over de beveiliging van de applicatie en exploits te voorkomen voordat ze schade kunnen aanrichten. Als gevolg hiervan zou een echte RASP nul valse positieven en verminderde latentie moeten hebben, wat een onmiddellijke prestatieverbetering oplevert. Echte RASP vereist een lijst met onveranderlijke regels die context gebruiken om te begrijpen wanneer een nieuwe kwetsbaarheid wordt geïntroduceerd en dienovereenkomstig te handelen. Deze onveranderlijkheid is mogelijk wanneer regels in de codebasis op de applicatielaag worden ingebakken en er zijn geen wijzigingen nodig als ze eenmaal zijn geïmplementeerd.

Drie gebieden waar RASP fout ging

1. Het probleem met de blaffende hond: de meeste waarschuwingen zijn valse positieven

Het probleem met WAF's is dat ze werken op de netwerklaag, een achterblijvende indicator van de uitvoering van applicaties. Het resulterende gebrek aan context leidt tot hoge fout-positieve percentages, lange wachttijden en slechte prestaties, aangezien WAF's alleen kunnen gissen naar de aard van een kwetsbaarheid op basis van waaraan ze eerder zijn blootgesteld.

Stel je een waakhond in de tuin voor die blaft wanneer hij een geluid voorbij het hek hoort. Deze geluiden kunnen de nadering van een indringer zijn, maar ook voorbijrijdende auto's. De waakhond kan het verschil niet nauwkeurig meten, dus de ernst van een bepaald geluid gaat verloren, waardoor het voor de mensen in huis onmogelijk wordt om te weten welke waarschuwingen echt zijn en welke vals-positieven. Dit scenario is in wezen de mogelijkheid van het standaard RASP-aanbod.

2. Het probleem met de 999 slechteriken: alleen in staat om een ​​monster te testen

Geloof het of niet, maar sommige leveranciers vertellen u dat u hun beveiligingsoplossing alleen in productieomgevingen moet gebruiken als u slechts een steekproef beschermt. Dat betekent dat het een steekproef trekt - misschien één op de 1,000 verzoeken - en die steekproef test terwijl het vastlegt wat er gebeurt voor de volgende 999. Dit betekent dat als je een goede acteur bent, je handtekening klopt. Maar ongeacht of de volgende 999 acteurs slechte bedoelingen hebben, ze komen er wel doorheen. Dit gebrek aan consistentie is allemaal omdat op WAF gebaseerde RASP's niet kunnen voldoen aan de prestatie-eisen van het moeten testen van elk verzoek.

3. Het "het duurt te lang"-probleem: latentie heeft invloed op de prestaties

Elke keer dat u een op WAF gebaseerde RASP hebt, ervaart u een verhoogde latentie, omdat deze de codebasis van de toepassing op geen enkele manier kan beïnvloeden. Ondertussen moeten algemeen beschikbare RASP's volledige tekstpayloads naar hun webanalysator sturen en vervolgens wachten tot deze wordt teruggestuurd, wat lang kan duren. En als uw klanten wachten op betalingen, geven ze het misschien op en gaan ze op zoek naar uw concurrenten.

Het verbeteren van dit proces is vergelijkbaar met code-optimalisatie. Bij het maken van een lijst hebben ontwikkelaars deze ingesteld om nieuwe items aan het begin van een lijst toe te voegen in plaats van aan het einde. Deze optimalisatie voorkomt dat de VM de hele lijst opnieuw opbouwt telkens wanneer een nieuw item wordt toegevoegd, waardoor de latentie toeneemt naarmate de lijst groeit. Compiler-ingenieurs hebben deze problemen aangepakt door begin jaren 2000 just-in-time (JIT) -compilatie te implementeren, waardoor code automatisch wordt geoptimaliseerd op basis van de nuances van de gegeven taal.

Waarom is de definitie van RASP zo afgezwakt?

Het ontwikkelen van RASP-technologie vereist een combinatie van vaardigheden op het gebied van beveiligingstechniek en software-engineering. Om effectief te zijn, moet de RASP-ontwikkelaar de architectuur van de applicatie en de nuances van de gebruikte programmeertaal grondig begrijpen. Dit vereist domeinexpertise die zeldzaam is onder beveiligingsprofessionals.

True RASP optimaliseert code voor zowel prestaties als beveiliging

Omdat de meeste RASP-platforms zich gedragen als WAF's, is er een enorme overhead aan verbonden, waardoor ze in de voorbeeldmodus moeten worden uitgevoerd. Een echte RASP daarentegen voert de daadwerkelijke bescherming uit tijdens de looptijd.

Deze bewerkingen bestaan ​​in het geheugen, wat zeer efficiënt is, en omdat dit zich in dezelfde ruimte als uw toepassingen bevindt, zijn ze zeer performant. Door de bescherming tijdens runtime uit te voeren, is het niet nodig om een ​​snelheidslimiet in te stellen of bescherming uit te voeren in steekproefomvang, omdat de daadwerkelijke bewerking slechts enkele milliseconden duurt.

Ongeacht eventuele wijzigingen in de applicatie, blijft de krachtige beveiliging constant. Deze filosofie sluit aan bij de filosofie van infrastructure-as-code, waarin je de gewenste staat van je infrastructuur definieert en wat er ook gebeurt in de omgeving, de staat van de infrastructuur blijft hetzelfde.

RASP loopt per definitie parallel met veel principes van infrastructuur-als-code. Deze parallel is mogelijk dankzij het diepe contextuele bewustzijn van de applicatie en de taal waarin deze is gebouwd. Leuk vinden infrastructuur-als-code, een echte benadering van RASP kan en moet gebruik maken van onveranderlijkheid om ervoor te zorgen dat regels worden toegepast ongeacht wijzigingen in de codebase.

Onveranderlijkheid is mogelijk door een controle uit te voeren op de uitvoer van een functie wanneer deze voor de eerste keer wordt aangeroepen en door ongezonde functionaliteit uit te schakelen met beschermde functionaliteit, zodat de toepassing altijd in orde is terwijl deze wordt uitgevoerd.

Met deze aanpak kan de beveiliging implementatie-agnostisch zijn en zijn er geen code wijzigingen in de toepassings code, afstemming of wachten op implementatie vensters vereist.

Door bescherming in de runtime uit te voeren, resultaten te patchen met onmiddellijke bescherming op alle draaiende instanties van de applicatie, elimineert men de behoefte aan constante valse positieven en neemt het risico van toekomstige exploits weg.

RASP kan en moet aan een hogere standaard worden gehouden

Kortom, RASP moet op een hoger niveau worden gehouden. Wanneer dit is gebeurd, is het mogelijk om duizenden applicaties te beveiligen, waardoor de totale eigendomskosten van uw WAF's worden verlaagd en burn-out in uw beveiligingsteams wordt voorkomen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been