Ravnovesje med snemanjem in blokiranjem v WAF-u

Informatec Digital » Viri » Ravnovesje med snemanjem in blokiranjem v WAF-u

Iskanje pravega ravnovesja med beleženjem in blokiranjem v požarnem zidu spletne aplikacije (WAF) je postalo ena najpogostejših težav varnostnih in operativnih ekip. Požarni zid spletne aplikacije lahko ustavi zelo resne napade, če pa je konfiguriran preveč agresivno, lahko blokira legitimne nakupe, dostop ali klice API-ja. Če je konfiguriran preveč ohlapno, postane skoraj zgolj dekorativen. Ključno je, da skrbno prilagodite, kdaj beležiti, kdaj šteti, kdaj dovoliti in kdaj blokirati.

V tem članku se bomo poglobili v to, kako doseči to ravnovesje z uporabo sodobnih zmogljivosti WAF (seznami dovoljenih, pravila na podlagi frekvence, načini učenja, integracija SIEM, strojno učenje itd.), podprtih s konkretnimi primeri iz AWS WAF, ModSecurity, WAF-ov v oblaku in rešitev na lokaciji . Videli boste, kako omejiti lažno pozitivne rezultate, ne da bi pri tem znižali raven zaščite, kako organizirati pravilnike po aplikacijah in kako uporabljati beleženje kot zaveznika, ne pa kot stalen, neobvladljiv vir šuma.

Kaj je WAF in zakaj je registracija tako pomembna?

Požarni zid spletne aplikacije deluje kot inteligentna plast med uporabnikom in strežnikom ter v realnem času analizira promet HTTP/HTTPS. Za razliko od tradicionalnega omrežnega požarnega zidu, ki spremlja vrata in IP-je, WAF poglobi procese: URL-je, parametre, telesa zahtev, glave, piškotke, metode HTTP in drugo.

Njegovo poslanstvo je odkrivanje in zaustavljanje tipičnih napadov 7. stopnje : SQL injection, XSS, LFI/RFI, napadi na nadzor dostopa, zloraba API-jev, agresivno strganje podatkov, brute force in celo določeni vzorci DDoS na ravni aplikacije. Za to se zanaša na nize pravil, podpisov in varnostnih politik, ki se nenehno posodabljajo.

Beleženje je druga plat medalje. Vsako odločitev WAF – dovoljenje, blokiranje ali samo štetje – lahko spremlja podroben dogodek v dnevnikih . Ti dnevniki omogočajo:

• Preiskava incidentovrekonstruirati, kaj se je zgodilo in kako je bil izveden poskus izkoriščanja ranljivosti.
• Prilagodi pravila: zazna lažno pozitivne rezultate tako, da vidi, katere legitimne zahteve WAF blokira.
• Upoštevajte predpise: dokazati obstoj aktivnih kontrol (PCI DSS, GDPR, interne revizije itd.).
• Hranjenje SIEM: povezati napade na aplikacije z dogodki v omrežju, sistemu, identiteti itd.

Težava je v tem, da lahko slabo nastavljen WAF napolni dnevnike s tisoči nepomembnih dogodkov , zaradi česar je nemogoče najti tisto, kar je pomembno, in poleg tega povzroči neupravičene zavrnitve legitimnega prometa. Tukaj pride na vrsto umetnost igranja z načini beleženja, štetja in blokiranja.

Varnostni modeli v WAF: seznami blokiranih, seznami dovoljenih in hibridni pristop

Večina sodobnih WAF-ov združuje več pristopov filtriranja, kar neposredno vpliva na to, kako se zahteve beležijo in blokirajo . Na splošno lahko prepoznamo dve klasični filozofiji in zelo pogost hibridni model.

WAF, ki temelji na seznamu blokov, sledi negativnemu varnostnemu modelu. Njegovo osnovno načelo je: »Dovolim vse, razen tistega, za kar vem, da je zlonamerno.« Deluje z uporabo podpisov znanih napadov (SQL injection, XSS, vzorci botov itd.) in pravil, ki določajo, kaj se šteje za sumljivo. Sprva ga je lažje uvesti, vendar se zanašanje izključno na ta model tvega, da se bodo novi vektorji ali različice napadov lahko neopaženo prebili.

WAF s seznamom dovoljenih deluje obratno: »blokiraj vse, razen tistega, kar je izrecno dovoljeno.« Temelji na modelu pozitivne varnosti. Sprejema se le promet, ki ustreza definiranemu legitimnemu vedenju – poti, metode, parametri, formati, velikosti itd. Je veliko bolj varen, vendar zahteva precejšnje natančne nastavitve in lahko sprva povzroči lažne pozitivne rezultate, če ni pravilno pripravljen.

Zaradi prednosti in slabosti vsakega pristopa postaja vse pogostejši hibridni model, ki združuje sezname dovoljenih in blokiranih vsebin . V tem scenariju so opredeljeni pričakovani profili prometa (na primer, kaj predstavlja običajno prijavo ali zahtevo za plačilo), hkrati pa se uporabljajo podpisi in hevristike za odkrivanje tipičnih zlonamernih vzorcev. Za namene beleženja ta hibridni pristop omogoča:

• Označi kot dogodek z visokim tveganjem kar krši seznam dovoljenih predmetov.
• Obravnavaj kot opozorila srednje/nizke prioritete splošni vzorci seznamov blokov.
• Uporabite način »štetje«, da vidite, kaj bi kršilo pravilo, preden aktivirate blokado.

WAF v omrežju, na gostitelju in v oblaku: vpliv na beleženje in zaklepanje

Model uvajanja WAF močno vpliva na način ravnanja z beleženjem in blokiranjem prometa. Beleženje zahtev v omrežni napravi ni enako beleženju zahtev v agentu znotraj strežnika ali v upravljani storitvi v oblaku.

Omrežni WAF se običajno namesti kot fizična ali virtualna naprava znotraj infrastrukture, med internetom in aplikacijami. To je klasičen pristop, ki ga uporabljajo proizvajalci, kot je F5. Ponuja prednost visoke zmogljivosti in natančnega nadzora , vendar sta lahko konfiguracija in upravljanje zapletena. Beleženje se običajno pošlje v sistemski dnevnik ali centralni SIEM, zato je pomembno skrbno filtrirati shranjene podatke, da se izognemo preobremenitvi orodij za shranjevanje in analizo ter da se diagnosticirajo težave v omrežjih IP in DNS.

Gostiteljski WAF-i se izvajajo na istih strežnikih (ali vsebnikih), kjer se nahaja aplikacija, običajno kot modul ali agent (na primer ModSecurity, integriran v Nginx ali Apache; njegova kombinacija z utrjevanjem Linuxa z uporabo SELinuxa izboljša varnostno stanje). Ta model omogoča večji kontekst aplikacije in zelo specifična pravila na storitev, vendar za ceno porabe lokalnih virov in potrebe po bolj porazdeljenem upravljanju dnevnikov. Dnevnike je mogoče shraniti v lokalne datoteke in jih nato posredovati ali integrirati s centraliziranimi storitvami beleženja.

Oblačni WAF-i (Cloudflare, Akamai, Imperva Cloud, AWS WAF itd.) se integrirajo z uravnalniki obremenitve, omrežji CDN ali virtualnimi omrežji. Ponudniki običajno ponujajo nadzorne plošče in izvoz dnevnikov v S3, BigQuery, oddaljene sistemske dnevnike ali SIEM. Na splošno jih je lažje nastaviti, vendar morate svoje pravilnike beleženja prilagoditi modelu ponudnika: vrste dogodkov, obdobja hrambe, filtri resnosti itd.

Izbira enega ali drugega modela ni le tehnična odločitev, temveč tudi vprašanje, kako želite uravnotežiti beleženje in zaklepanje: storitev, ki jo upravlja oblak, poenostavi številne vidike, vendar boste morda želeli popoln nadzor nad tem, kje so shranjeni dnevniki zaradi pravilnikov o skladnosti ali zaupnosti, kar vas potiska k modelom na lokaciji ali hibridnim modelom.

Pogoji, pravila in spletni ACL-ji: kako se WAF odloči, ali bo blokiral, dovolil ali samo registriral

Ne glede na proizvajalca vsi sodobni WAF-i temeljijo na konceptu pogojev dostopa, pravil in politik . Razumevanje tega je ključnega pomena za uspešno uporabo načinov štetja, beleženja in zaklepanja v produkciji.

Pogoji opisujejo , kateri del zahteve se pregleda: izvorni IP, specifične glave HTTP (gostitelj, uporabniški agent, sprejetje, tip vsebine…), parametri poizvedbe, telo zahteve, piškotki, metoda HTTP, država izvora itd. Na primer, v AWS WAF Classic lahko določite pogoj IP z do 10.000 naslovi ali obsegi ali pogoj ujemanja nizov na delu URL-ja.

Pravila združujejo enega ali več pogojev in jim dodelijo namen: dovoliti, blokirati ali prešteti. Ko ima pravilo več pogojev, se ti običajno ovrednotijo ​​z logičnim IN : vsi pogoji morajo biti izpolnjeni, da se pravilo sproži. Običajno pravilo brez pogojev se v praksi ne ujema z ničemer in njegovo dejanje se nikoli ne sproži.

Številni WAF-i, vključno z AWS WAF, imajo tudi pravila, ki temeljijo na hitrosti . Ta pravila štejejo zahteve, ki prispejo z naslova IP (ali niza naslovov IP, ki izpolnjujejo določene pogoje) v časovnem oknu, na primer petih minutah. Če je presežen prag – recimo 1.000 zahtev v petih minutah – pravilo začne veljati: blokiranje ali preprosto štetje. To je zelo uporabno za:

• Nadzor surova sila na prijavnih obrazcih.
• Omejite agresivno strganje ali nevljudne bote.
• Blaženje določenih vrst napadov DDoS na ravni aplikacije.

Naslednja raven je spletni ACL (seznam za nadzor dostopa) . Tukaj so pravila združena, določen pa je vrstni red ocenjevanja in privzeto dejanje (DOVOLI ali BLOKIRAJ). Zahteva prehaja skozi pravila po vrstnem redu; če se ujema z enim, se uporabi njeno dejanje, ocenjevanje preostalih pa se ustavi. Če se ne ujema z nobenim pravilom, se uporabi privzeto dejanje, določeno v ACL.

Kar zadeva uravnoteženje beleženja in blokiranja, se v ACL-ju odločite, ali želite, da je sistem privzeto permisiven (DOVOLJENJE in blokiranje samo po določenih pravilih) ali zelo omejujoč (BLOKIRANO, razen v izjemnih primerih). Poleg tega številne rešitve omogočajo nastavitev pravil v načinu »štetje« znotraj ACL-ja, tako da beležijo ujemanja, vendar ne blokirajo prometa – idealno za fazo optimizacije.

Bele liste in zmanjšanje šuma v dnevnikih

Dovoljeni seznami so temeljno orodje za zmanjšanje lažno pozitivnih rezultatov in šuma v dnevniku . Ideja je preprosta: v določenih kontekstih naročite WAF-u, naj ne uporablja direktive ali niza pravil za določen promet, ki ste ga že kategorizirali kot zaupanja vrednega ali za katerega veste, da je zunaj norme, vendar legitimen.

Na primer, v AWS WAF lahko ustvarite pravila za seznam dovoljenih, tako da se v primeru zahteve z določenega naslova IP ali obsega ali če se ujema z znanim vzorcem URL-ja in metodo HTTP ne uporabijo določeni pregledi podpisov. To pomaga pri:

• Preprečite notranje API-je, ki uporabljajo »čudne« vzorce ustvarjajo stalne lažno pozitivne rezultate.
• Zmanjšajte zakasnitev, ki jo povzroča poglobljen pregled prometa, ki ga že imate za zaupanja vrednega.
• Zmanjšajte količino nepotrebnih zapisov v dnevnikih WAF.

Na platformah, kot je ModSecurity, priporočen pristop ni spreminjanje standardnih pravil (npr. OWASP Core Rule Set), temveč ustvarjanje posebnih izključitev glede na ID pravila za določene parametre, poti ali uporabnike. To vam omogoča ohranjanje splošne zaščite, ne da bi pri tem ustvarili velike ranljivosti z onemogočanjem celotnih pravil na spletnem mestu.

Ključno je, da sezname dovoljenih vsebin naredimo kirurške , ne pa splošnega pristopa. Veliko bolje je izključiti določeno kombinacijo (pravilo X + parameter Y v URL-ju Z) kot pa globalno onemogočiti pravilo X. Na ta način ostane beleženje uporabno in ne ustvarjate nepotrebnih mrtvih peg.

Pravila in omejitve protokola: kdaj blokirati, kdaj opozoriti

Številni WAF-i vključujejo niz pravil za čiščenje protokola HTTP, ki delujejo kot prvi filter za popačen ali sumljiv promet . Ta pravila preverjajo zahtevane glave, metode, velikosti argumentov itd. in so pogost vir tako dobre zaščite kot lažno pozitivnih rezultatov, če niso pravilno razumljena.

Nekaj ​​zelo pogostih primerov:

• Manjka glava sprejema (Manjka glava Accept): To ni strogo gledano kršitev RFC, vendar številne zahteve brez te glave prihajajo iz avtomatiziranih orodij ali slabo napisanih skriptov. To lahko vpliva na prilagojene API-je ali odjemalce, ki je ne pošljejo. V mnogih okoljih je beleženje in štetje bolj pomembno kot popolno blokiranje.
• Manjka glava gostiteljaV skladu s standardi HTTP/1.1 je glava Host obvezna. WAF-i jo potrebujejo tudi za določitev pravilnika, ki ga je treba uporabiti. Blokiranje v tem primeru je običajno smiselno, vendar lahko med testiranjem ali zaradi napačno konfiguriranega notranjega prometa povzroči lažne pozitivne rezultate; pred omogočanjem strogega blokiranja je priporočljivo spremljati dnevnike.
• Manjka glava uporabniškega agentaTo pravilo poskuša omejiti rudimentarne bote in neidentificirani promet. Težava je v tem, da mnogi legitimni API-ji morda ne pošljejo uporabniškega agenta. Najbolj smiseln pristop je običajno beleženje in če se zazna dosleden in legitimen API, dodajte svoj IP ali vzorec na seznam dovoljenih.
• Validacija GET/HEAD s telesomČeprav RFC strogo ne prepoveduje pošiljanja telesa z zahtevami GET ali HEAD, to ni običajna praksa in lahko kaže na poskuse izogibanja. V mnogih primerih je prvi korak beleženje vseh teh zahtev in, če se ugotovi, da gre za sumljive anomalije, njihovo blokiranje.
• Manjka vrsta vsebine s telesomČe je prisotno telo, vendar ni Content-Type, je to jasen znak nepravilne uporabe protokola ali poskusa izogibanja analizi. V teh primerih je običajno smiseln agresivnejši pristop blokiranja, zlasti v okoljih, ki so povezana z internetom.

Poleg teh protokolnih pravil se pogosto uporabljajo tudi omejitve argumentov za zaščito pred poplavami na ravni aplikacij in napadi DoS. Na primer:

• Največje število argumentov na zahtevo (privzeto 255 v nekaterih WAF-ih).
• Največja dolžina posameznega argumenta (na primer 400 znakov).
• Skupna skupna velikost vseh argumentov (na primer 64.000 bajtov).

Te vrednosti so razumne za številne aplikacije, vendar obstajajo primeri – nalaganje kompleksnih obrazcev, napredni filtri, velika nalaganja JSON – kjer pride do lažno pozitivnih rezultatov. V teh scenarijih je najbolj preudaren pristop, da začnete z beleženjem in štetjem , pregledate, katere končne točke kršijo omejitve, in prilagodite le za te poti, namesto da odpravite vse omejitve za celotno spletno mesto.

Lažno pozitivni rezultati: kako jih odkriti in se ne ubiti pri poskusu

Lažno pozitiven rezultat je legitimna zahteva, ki jo WAF prepozna kot zlonamerno in jo blokira ali označi kot napad. Lažno pozitivni rezultat se jim ni mogoče izogniti, še posebej, če imate omogočen celovit nabor pravil, kot je OWASP CRS, vendar jih je mogoče profesionalno upravljati, da ne postanejo vsakodnevni glavobol.

Odkrivanje lažno pozitivnih rezultatov se začne s skrbnim pregledom dnevnikov . To vključuje pregled, katere zahteve so blokirane, katero pravilo jih sproži in kontekst, v katerem se pojavijo (URL, parametri, uporabnik, izvor itd.). Vizualna orodja in nadzorne plošče lahko pomagajo prepoznati porast napak 403 ali nenavadne vzorce.

Zelo priporočljiv pristop, tako s strani ponudnikov storitev v oblaku kot skupnosti ModSecurity, je uporaba načina simulacije ali štetja . V tem načinu pravila, ki jih želite preizkusiti, beležijo vsako ujemanje, vendar jih ne blokirajo. To vam omogoča, da na primer vidite, koliko legitimnih zahtev bi novo pravilo SQLi blokiralo, preden bi si ga drznili aktivirati v produkciji.

Prav tako je dobro, da pravila preizkusite v preizkusnem ali predprodukcijskem okolju , ki prejema dejanski ali simuliran promet. Orodja, kot sta OWASP ZAP ali skripti za ponovno predvajanje prometa, vam lahko pomagajo simulirati legitimne vzorce in znane napade za preizkus vedenja WAF-a.

Poleg tega je ključnega pomena upoštevati operativni in ugledni vpliv lažno pozitivnih rezultatov: prekinitve plačil, neuspehi registracije uporabnikov, kritični klici API-ja, ki ne uspejo brez pojasnila – vse to lahko neposredno vpliva na prihodke in podobo blagovne znamke. Preveč lažno pozitivnih rezultatov varnostno ekipo preobremeni tudi z opozorili, ki ne dodajo vrednosti, zaradi česar je težko prepoznati resnične incidente.

Strategije za prilagajanje pravil in inteligentno uporabo registra

Pri obvladovanju lažno pozitivnih rezultatov ne gre za izklop pravil, dokler »vse ne deluje«, temveč za natančno nastavitev funkcije WAF . Tukaj pridejo v poštev dobre prakse, kot so naslednje:

Najprej se izogibajte onemogočanju pravil po vsem svetu. Priporočljivo je ustvariti zelo specifične izjeme : izključite ID pravila samo za določeno pot, za določene parametre ali za notranji promet. Na ta način ostanete zaščiteni v preostalem delu aplikacije in vzdržujete uporabne dnevnike.

Drugič, pred blokiranjem izkoristite način štetja . Če nova pravila sprva aktivirate samo v načinu beleženja, lahko izmerite, koliko legitimnih zahtev bi bilo prizadetih. To lahko dopolnite z opozorili v SIEM, da hitro zaznate, ali pravilo ustvarja nenormalno količino ujemanj.

Tretjič, integrirajte WAF s SIEM ali centralizirano platformo za beleženje . To olajša povezovanje dogodkov WAF z drugimi kazalniki: nenavadna aktivnost sistema, množične napake pri preverjanju pristnosti, sumljive spremembe konfiguracije itd. Prav tako pomaga pri določanju prioritet pravil, ki jih je treba najprej prilagoditi glede na resnost in pogostost dogodkov.

Četrtič, dokumentirajte vsako spremembo: katero pravilo je bilo izpopolnjeno, za katero končno točko, s kakšno utemeljitvijo in s kakšnimi dokazi. Pri tem je lahko koristno posvetovanje s priročniki za strežnik . Ta dokumentacija ne pomaga le pri vzdrževanju notranjega nadzora, temveč je neprecenljiva tudi pri varnostnih revizijah in pregledih, kjer želite dokazati, da se kontrole ne onemogočajo kar tako.

Avtomatizacija, strojno učenje in prilagodljiva pravila v WAF

Ko aplikacije rastejo in promet postaja bolj zapleten, ročno upravljanje WAF-a postane nerealno. Tukaj pridejo v poštev avtomatizacija, napredna analiza dnevnikov in v nekaterih primerih strojno učenje.

Prvič, integracija s SIEM vam omogoča izdelavo pravil korelacije in avtomatiziranih odzivov : na primer, če niz IP-jev večkrat sproži pravila za vbrizgavanje ali XSS, lahko ustvarite samodejno dejanje, s katerim te IP-je dodate na začasni seznam blokov ali okrepite raven pregleda.

Drugič, nekateri WAF-i vključujejo načine strojnega učenja , ki opazujejo legitimen promet v določenem obdobju. Na podlagi teh podatkov predlagajo ali prilagodijo pragove, vzorce in profile normalnega vedenja. To pomaga zmanjšati lažno pozitivne rezultate, ko se pravila preklopijo v način blokiranja, in zaznati nadaljnja odstopanja prometa.

V raziskovalnih in laboratorijskih okoljih se tehnike nadzorovanega učenja uporabljajo za učenje modelov, ki razlikujejo med legitimnim in zlonamernim prometom, s čimer se izpopolnjujejo pravilniki, ki se nato uporabljajo v produkciji. Čeprav ni čarobno zdravilo, lahko ta pristop pomaga odkriti subtilne vzorce , ki jih klasična pravila, ki temeljijo na podpisih, ne zaznajo zlahka.

Končno, nenehno avtomatizirano testiranje (z uporabo orodij, kot so OWASP ZAP, skripti po meri ali cevovodi CI/CD) vam omogoča, da preverite, ali spremembe WAF-a ne motijo ​​kritične funkcionalnosti ali puščajo očitnih ranljivosti. Integracija teh testov v cikel uvajanja naredi varnost naravni del razvojnega procesa in ne le popravek v zadnjem trenutku.

Oblikovanje pravilnikov za vsako aplikacijo in črne sezname za vsako storitev

V kompleksnih okoljih – na primer pri ponudniku gostovanja ali internetnem ponudniku – en sam pravilnik WAF ni dovolj, še posebej, če gre za senčno IT . Pogosto je za istim uravnalnikom obremenitve več domen ali aplikacij, vsaka z različnimi varnostnimi potrebami in profili prometa . Tukaj postane oblikovanje pravilnikov in seznamov, specifičnih za storitve, bistveno.

Ilustrativen primer je uravnalnik obremenitve HTTP/S, ki deluje kot obratni posredniški strežnik za več spletnih mest (npr. www.company1.com in www.company2.com) za enim samim virtualnim naslovom IP. V tem scenariju je mogoče WAF konfigurirati tako, da ovrednoti glavo gostitelja in izvorni naslov IP takoj, ko zahteva prispe, še preden doseže modul za uravnavanje obremenitve.

Logika bi bila nekako takšna: WAF preveri, ali se kombinacija SERVER_NAME (gostitelj) in IP-ja odjemalca ujema s črnim seznamom, specifičnim za spletno mesto. Če je IP naveden kot blokiran za www.company2.com, ne pa tudi za www.company1.com, se v prvem primeru pošlje odgovor 403 Forbidden. »Čist« promet se nato posreduje modulu za uravnoteženje obremenitve, ki odloči, kateri zaledni sistem streže zahtevo.

To omogoča vzdrževanje na primer črnih seznamov, specifičnih za domeno , namesto enega samega globalnega seznama za celotno dostopno točko. Na ravni beleženja se vsaka zavrnitev zabeleži v sistemskem dnevniku s podrobnostmi, kot so ID pravila, ujemajoči se pogoj, URL, gostitelj in IP-naslov odjemalca, kar olajša nadaljnjo analizo in razširitev ali odpravljanje napak na teh seznamih.

Nauk zgodbe je, da bolj ko so vaši pravilniki segmentirani (po aplikaciji, okolju, vrsti uporabnika), boljše lahko najdete ravnovesje med beleženjem in blokiranjem: na administrativnih portalih ste lahko zelo strogi, na informativnih spletnih mestih pa nekoliko bolj prilagodljivi, na primer z vedno dokazili v dnevnikih, zakaj je bila vsaka odločitev sprejeta.

Onkraj klasičnega WAF-a: zaščita WAAP in API-ja

Pokrajina groženj se ni ustavila. Danes so številne aplikacije izvorno zasnovane v oblaku, uporabljajo arhitekture mikroservisov in razkrivajo javne in zasebne API-je , zaradi česar so glavne tarče napadalcev. Tradicionalni WAF-i so se razvili v širše platforme, znane kot WAAP (zaščita spletnih aplikacij in API-jev) ali WAAS (varnost spletnih aplikacij in API-jev).

Te rešitve ne le samodejno odkrijejo spletne aplikacije, temveč tudi prepoznajo končne točke API-ja , sprejemajo specifikacije, kot sta OpenAPI ali Swagger, in uporabljajo to definicijo za preverjanje skladnosti zahtev: pričakovani tipi podatkov, dovoljeni parametri, omejitve velikosti itd. Glede na končno točko (na primer tisto, ki obravnava zelo občutljive podatke) se lahko uporabi veliko višja raven pregleda in blokiranja.

Na ravni beleženja WAAP ponavadi generira dogodke, bogate s kontekstom : katera natančna končna točka API-ja je bila napadena, katera operacija (GET, POST, PUT…), kateri uporabnik ali žeton je bil vpleten, kateri del specifikacije je bil kršen itd. To omogoča natančnejše odločitve o blokiranju, namesto da bi se zanašali izključno na generične vzorce koristnega tovora.

Poleg tega številna orodja WAAP vključujejo zaščito pred DoS, specifično za aplikacije in API, filtriranje geolokacije, upravljanje ugleda IP-naslovov, zaznavanje botov in strganja podatkov ter možnosti za prilagajanje ravni opozoril za vsako storitev posebej. Spet gre za to, da imate možnost odločanja, kje želite bolj robusten pristop in kje želite dati prednost nemotenemu delovanju , ne da bi pri tem žrtvovali trdno podatkovno bazo dnevnikov za preiskovanje morebitnih incidentov.

Dobro uglašen WAF – bodisi klasičen, na osnovi WAAP ali integriran v oblačni ekosistem – skupaj postane bistvena komponenta sodobne obrambe aplikacij in API-jev, saj je sposoben združevati podrobno beleženje, inteligentno blokiranje in nenehno prilagajanje spreminjajočim se grožnjam.