Hva RASP burde vært

De siste årene har applikasjonssikkerhet verden har sett fremveksten av runtime application self-protection (RASP) teknologi. Som beskrevet av Gartner, er RASP en sikkerhetsteknologi som er integrert i en applikasjon eller dets kjøretidsmiljø, i stand til å kontrollere og forhindre sanntidsangrep. Dessverre mange Brannmur for webapplikasjoner (WAF) selskaper så en mulighet til å utnytte begrepet. De introduserte "RASP-lignende" agenter på nettverkslaget, som ikke fullt ut omfavner definisjonen av RASP-teknologi.

I motsetning til dette, opererer ekte RASP-teknologi på applikasjonslaget, der den har full kontekst av brukeren, applikasjonslogikken og domeneinformasjonen. Denne konteksten lar en RASP ta informerte beslutninger om applikasjonens sikkerhet og forhindre utnyttelser før de kan forårsake skade. Som et resultat bør en ekte RASP ha null falske positiver og redusert ventetid, noe som gir en umiddelbar økning i ytelse. Ekte RASP krever en liste over uforanderlige regler som bruker kontekst for å forstå når en ny sårbarhet introduseres og handle deretter. Denne uforanderligheten er mulig når regler er bakt inn i kodebasen på applikasjonslaget og krever ingen endringer når de først er distribuert.

Tre områder der RASP gikk galt

1. Problemet med bjeffende hunder: De fleste varsler er falske positive

Problemet med WAF-er er at de fungerer på nettverkslaget, en etterslepende indikator på applikasjonskjøring. Den resulterende mangelen på kontekst fører til høye falske-positive priser, lange ventetider og dårlig ytelse, ettersom WAF-er bare kan gjette om naturen til en sårbarhet basert på hva de tidligere har vært utsatt for.

Se for deg en vakthund i hagen som bjeffer hver gang den hører en lyd utenfor gjerdet. Disse lydene kan være en inntrengers tilnærming, men de kan også være biler som går forbi. Vakthunden kan ikke måle forskjellen nøyaktig, så alvorlighetsgraden av en gitt støy går tapt, noe som gjør det umulig for folk i huset å vite hvilke varsler som er ekte og hvilke som er falske positive. Dette scenariet er i hovedsak funksjonen til standard RASP-tilbudet.

2. 999 Bad Guys-problemet: Kun i stand til å teste en prøve

Tro det eller ei, noen leverandører ber deg bare kjøre sikkerhetsløsningen deres i produksjonsmiljøer hvis du kun beskytter en prøvestørrelse. Det betyr at den tar en prøve - kanskje en av 1,000 forespørsler - og tester den prøven mens den fanger hva som skjer for de neste 999. Det betyr at hvis du er en god skuespiller, vil signaturen din sjekke ut. Men uansett om de følgende 999 skuespillerne har dårlige intensjoner eller ikke, kommer de gjennom. Denne mangelen på konsistens skyldes at WAF-baserte RASPer ikke kan håndtere ytelseskravene til å måtte teste hver forespørsel.

3. "Det tar for lang tid"-problemet: latens påvirker ytelsen

Hver gang du har en WAF-basert RASP, opplever du økt ventetid, siden den ikke kan påvirke applikasjonens kodebase på noen måte. I mellomtiden må allment tilgjengelige RASP-er sende hele tekstnyttelastene til webanalysatoren deres og deretter vente på at den blir sendt tilbake, noe som kan ta lang tid. Og hvis kundene dine venter på at betalinger skal gå gjennom, kan de gi opp og oppsøke konkurrentene dine i stedet.

Å forbedre denne prosessen ligner på kodeoptimalisering. Når du oppretter en liste, setter utviklere den opp til å legge til nye elementer i begynnelsen av en liste i stedet for slutten. Denne optimaliseringen forhindrer den virtuelle maskinen i å gjenoppbygge hele listen hver gang et nytt element legges til, og forhindrer økende latens etter hvert som listen vokser. Kompilatoringeniører tok tak i disse problemene ved å implementere just-in-time (JIT) kompilering på begynnelsen av 2000-tallet, som automatisk optimerer koden basert på nyansene til det gitte språket.

Hvorfor har definisjonen av RASP blitt så utvannet?

Å utvikle RASP-teknologi krever en kombinasjon av ferdigheter innen sikkerhetsteknikk og programvareteknikk. For å være effektiv må RASP-utvikleren ha en dyp forståelse av applikasjonens arkitektur og nyansene i programmeringsspråket som brukes. Dette krever domeneekspertise som er sjelden blant sikkerhetseksperter.

Ekte RASP optimerer kode for ytelse så vel som sikkerhet

Fordi de fleste RASP-plattformer oppfører seg som WAF-er, er det en massiv overhead involvert, som krever at de kjøres i prøvemodus. Derimot utfører en ekte RASP selve beskyttelsen i løpet av kjøretiden.

Disse operasjonene finnes i minnet, noe som er veldig effektivt, og fordi dette eksisterer på samme plass som applikasjonene dine, er de svært effektive. Ved å utføre beskyttelsen under kjøretiden, er det ikke nødvendig å rangere grense eller utføre beskyttelse i prøvestørrelser fordi selve operasjonen tar bare noen få millisekunder.

Uavhengig av eventuelle endringer i applikasjonen, forblir sikkerheten med høy ytelse konstant. Denne filosofien stemmer overens med filosofien om infrastruktur-som-kode, der du definerer ønsket tilstand for infrastrukturen din, og uansett hva som skjer i miljøet, forblir tilstanden til infrastrukturen den samme.

RASP, per definisjon, paralleller mange prinsipper for infrastruktur-som-kode. Denne parallellen er mulig på grunn av den dype kontekstuelle bevisstheten om applikasjonen og språket den er bygget på. Som infrastruktur-som-kode, en genuin tilnærming til RASP kan og bør gjøre bruk av uforanderlighet for å sikre at regler brukes uavhengig av endringer i kodebasen.

Uforanderlighet er mulig ved å utføre en sjekk på utdataene til en funksjon første gang den kalles opp og bytte ut eventuell usunn funksjonalitet med beskyttet funksjonalitet, for å sikre at applikasjonen alltid er sunn mens den kjører.

Denne tilnærmingen gjør at sikkerheten kan være distribusjonsagnostisk og krever ikke kodeendringer i applikasjonskoden, justering eller venting på distribusjonsvinduer.

Ved å utføre beskyttelse i kjøretiden, lappe resultater med umiddelbar beskyttelse på alle kjørende forekomster av applikasjonen, eliminerer man behovet for konstante falske positiver og fjerner risikoen for fremtidige utnyttelser.

RASP kan og bør holdes til en høyere standard

Kort sagt, RASP bør holdes til en høyere standard. Når du har gjort det, er det mulig å sikre tusenvis av applikasjoner, redusere de totale eierkostnadene for WAF-ene dine og bidra til å forhindre utbrenthet i sikkerhetsteamene dine.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://www.darkreading.com/attacks-breaches/what-rasp-should-have-been