Ravnoteža između snimanja i blokiranja u WAF-u

Informatec Digital » Sredstva » Ravnoteža između snimanja i blokiranja u WAF-u

Pronalaženje prave ravnoteže između zapisivanja i blokiranja u WAF-u postalo je jedna od najčešćih glavobolja za sigurnosne i operativne timove. Vatrozid web aplikacije može zaustaviti vrlo ozbiljne napade, ali ako je konfiguriran preagresivno, može blokirati legitimne kupnje, pristup ili API pozive. Ako je konfiguriran prelabavo, na kraju postaje gotovo isključivo dekorativan. Ključno je pažljivo prilagoditi kada zapisivati, kada brojati, kada dopustiti i kada blokirati.

U ovom ćemo članku istražiti kako postići tu ravnotežu korištenjem modernih WAF mogućnosti (popisi dopuštenih stavki, pravila temeljena na frekvenciji, načini učenja, SIEM integracija, strojno učenje itd.), potkrijepljenih konkretnim primjerima iz AWS WAF-a, ModSecurityja, WAF-ova temeljenih na oblaku i lokalnih rješenja . Vidjet ćete kako ograničiti lažno pozitivne rezultate bez snižavanja razine zaštite, kako organizirati pravila prema aplikaciji i kako koristiti zapisivanje kao saveznika, a ne kao stalan, neupravljiv izvor buke.

Što je WAF i zašto je registracija toliko važna?

Vatrozid web aplikacije djeluje kao inteligentni sloj između korisnika i poslužitelja , analizirajući HTTP/HTTPS promet u stvarnom vremenu. Za razliku od tradicionalnog mrežnog vatrozida, koji prati portove i IP adrese, WAF dublje istražuje: URL-ove, parametre, tijela zahtjeva, zaglavlja, kolačiće, HTTP metode i još mnogo toga.

Njegova je misija otkriti i zaustaviti tipične napade 7. sloja : SQL injekcije, XSS, LFI/RFI, napade na kontrolu pristupa, zlouporabu API-ja, agresivno struganje, brute force, pa čak i određene DDoS obrasce na razini aplikacije. Da bi to učinio, oslanja se na skupove pravila, potpisa i sigurnosnih politika koje se stalno ažuriraju.

Zapisivanje je druga strana medalje. Svaka WAF odluka - dopustiti, blokirati ili samo brojati - može biti popraćena detaljnim događajem u zapisnicima . Ti zapisnici omogućuju:

• Istražite incidenterekonstruirati što se dogodilo i kako je pokušano iskorištavanje ranjivosti.
• Prilagodi pravilaOtkrivanje lažno pozitivnih rezultata provjerom legitimnih zahtjeva koje WAF blokira.
• Pridržavajte se propisa: pokazati da postoje aktivne kontrole (PCI DSS, GDPR, interne revizije itd.).
• Hranjenje SIEM-apovezati napade na aplikacije s događajima u mreži, sustavu, identitetu itd.

Problem je što loše podešen WAF može ispuniti logove tisućama nebitnih događaja , što onemogućuje pronalaženje onoga što je važno i, uz to, uzrokuje neopravdana odbijanja legitimnog prometa. Tu dolazi do izražaja umjetnost igranja s načinima zapisivanja, brojanja i blokiranja.

Sigurnosni modeli u WAF-u: liste blokiranih, liste dopuštenih i hibridni pristup

Većina modernih WAF-ova kombinira nekoliko pristupa filtriranja, što izravno utječe na način na koji se zahtjevi zapisuju i blokiraju . Općenito govoreći, možemo prepoznati dvije klasične filozofije, plus vrlo čest hibridni model.

WAF temeljen na popisu blokiranih slijedi model negativne sigurnosti. Njegovo osnovno načelo je: "Dopuštam sve osim onoga za što znam da je zlonamjerno." Djeluje korištenjem potpisa poznatih napada (SQL injekcija, XSS, obrasci botova itd.) i pravila koja definiraju što se smatra sumnjivim. Lakše ga je u početku implementirati, ali oslanjanje isključivo na ovaj model riskira da se novi vektori ili varijante napada provuku neotkriveno.

WAF s popisom dopuštenih radi na suprotan način: "blokiraj sve osim onoga što je izričito dopušteno". Temelji se na modelu pozitivne sigurnosti. Prihvaća se samo promet koji odgovara definiranom legitimnom ponašanju - rute, metode, parametri, formati, veličine itd. Mnogo je sigurniji, ali zahtijeva značajno fino podešavanje i može generirati lažno pozitivne rezultate u početku ako nije pravilno pripremljen.

Zbog prednosti i nedostataka svakog pristupa, hibridni model koji kombinira popise dopuštenih i blokiranih adresa postaje sve češći . U ovom scenariju definiraju se očekivani profili prometa (na primjer, što predstavlja normalnu prijavu ili zahtjev za plaćanje), a potpisi i heuristike se istovremeno primjenjuju za otkrivanje tipičnih zlonamjernih obrazaca. U svrhu evidentiranja, ovaj hibridni pristup omogućuje:

• Označi kao događaj visokog rizika ono što krši popis dopuštenih predmeta.
• Tretira kao upozorenja srednjeg/niskog prioriteta opći obrasci popisa blokiranih.
• Koristite način "brojanja" kako biste vidjeli što bi prekršilo pravilo prije aktiviranja bloka.

WAF u mreži, na hostu i u oblaku: utjecaj na zapisivanje i zaključavanje

Model implementacije WAF-a uvelike utječe na način na koji se obrađuje zapisivanje i blokiranje prometa. Zapisivanje zahtjeva na mrežnom uređaju nije isto što i zapisivanje na agentu unutar poslužitelja ili na upravljanoj usluzi u oblaku.

Mrežni WAF obično se implementira kao fizički ili virtualni uređaj unutar infrastrukture, između interneta i aplikacija. Ovo je klasičan pristup koji koriste proizvođači poput F5. Nudi prednost visokih performansi i granularne kontrole , ali konfiguracija i upravljanje mogu biti složeni. Zapisivanje se obično šalje u syslog ili središnji SIEM, a važno je pažljivo filtrirati ono što se sprema kako bi se izbjeglo preopterećenje alata za pohranu i analizu te kako bi se dijagnosticirali problemi u IP i DNS mrežama.

WAF -ovi temeljeni na hostu izvode se na istim poslužiteljima (ili spremnicima) gdje se nalazi i aplikacija, obično kao modul ili agent (na primjer, ModSecurity integriran u Nginx ili Apache; kombiniranje s Linux ojačanjem pomoću SELinuxa poboljšava sigurnosnu poziciju). Ovaj model omogućuje širi kontekst aplikacije i vrlo specifična pravila po usluzi, uz cijenu trošenja lokalnih resursa i zahtijevanja distribuiranijeg upravljanja zapisnicima. Zapisnici se mogu pohraniti u lokalne datoteke, a zatim proslijediti ili integrirati s centraliziranim uslugama zapisivanja.

WAF -ovi temeljeni na oblaku (Cloudflare, Akamai, Imperva Cloud, AWS WAF itd.) integriraju se s uravnoteživačima opterećenja, CDN-ovima ili virtualnim mrežama. Pružatelji usluga obično nude nadzorne ploče i izvoz zapisnika u S3, BigQuery, udaljene syslogove ili SIEM-ove. Općenito ih je lakše postaviti, ali morate prilagoditi svoje politike zapisivanja modelu pružatelja usluga: vrste događaja, razdoblja zadržavanja, filtre ozbiljnosti itd.

Odabir jednog ili drugog modela nije samo tehnička odluka, već i pitanje kako želite uravnotežiti zapisivanje i zaključavanje: usluga kojom se upravlja u oblaku pojednostavljuje mnoge aspekte, ali možda želite apsolutnu kontrolu nad mjestom pohranjivanja zapisnika zbog pravila o usklađenosti ili povjerljivosti, što vas gura prema lokalnim ili hibridnim modelima.

Uvjeti, pravila i web ACL-ovi: kako WAF odlučuje hoće li blokirati, dopustiti ili samo registrirati

Bez obzira na proizvođača, svi moderni WAF-ovi temelje se na konceptu uvjeta pristupa, pravila i politika . Razumijevanje ovoga ključno je za uspješno korištenje načina brojanja, bilježenja i zaključavanja u produkciji.

Uvjeti opisuju koji se dio zahtjeva pregledava: izvorna IP adresa , specifični HTTP zaglavlja (Host, User-Agent, Accept, Content-Type…), parametri upita, tijelo zahtjeva, kolačići, HTTP metoda, zemlja podrijetla itd. Na primjer, u AWS WAF Classicu možete definirati IP uvjet s do 10 000 adresa ili raspona ili uvjet podudaranja niza na dijelu URL-a.

Pravila kombiniraju jedan ili više uvjeta i dodjeljuju im namjeru: dopustiti, blokirati ili brojati. Kada pravilo ima više uvjeta, oni se obično procjenjuju logičkim I : svi uvjeti moraju biti ispunjeni da bi se pravilo aktiviralo. Normalno pravilo bez uvjeta, u praksi, ne odgovara ničemu i njegova se radnja nikada ne pokreće.

Mnogi WAF-ovi, uključujući AWS WAF, također imaju pravila temeljena na brzini . Ta pravila broje zahtjeve koji dolaze s IP adrese (ili skupa IP adresa koje ispunjavaju određene uvjete) tijekom vremenskog prozora, na primjer pet minuta. Ako se prekorači prag - recimo, 1.000 zahtjeva u pet minuta - pravilo stupa na snagu: blokiranje ili jednostavno brojanje. Ovo je vrlo korisno za:

• Kontrolirati brutalna sila na obrascima za prijavu.
• Ograničite agresivno struganje ili nepristojne botove.
• Ublažavanje određenih vrsta DDoS napada na razini aplikacije.

Sljedeća razina je web ACL (Access Control List) . Ovdje su pravila grupirana, a definirani su redoslijed evaluacije i zadana akcija (DOPUSTI ili BLOKIRAJ). Zahtjev prolazi kroz pravila redom; ako se podudara s jednim, primjenjuje se njegova akcija, a evaluacija ostalih se zaustavlja. Ako se ne podudara ni s jednim pravilom, primjenjuje se zadana akcija definirana u ACL-u.

Što se tiče uravnoteženja zapisivanja i blokiranja, ACL je mjesto gdje odlučujete želite li da sustav bude dopuštajući prema zadanim postavkama (DOPUŠTA i blokiranje samo određenim pravilima) ili vrlo strog (BLOKIRA osim u iznimnim slučajevima). Nadalje, mnoga rješenja omogućuju vam postavljanje pravila u načinu rada "brojanja" unutar ACL-a, tako da zapisuju podudaranja, ali ne blokiraju promet - idealno za fazu podešavanja.

Bijele liste i smanjenje šuma u zapisnicima

Dopuštene liste su temeljni alat za smanjenje lažno pozitivnih rezultata i šuma u zapisniku . Ideja je jednostavna: u određenim kontekstima kažete WAF-u da ne primjenjuje direktivu ili skup pravila na određeni promet koji ste već kategorizirali kao pouzdan ili za koji znate da je izvan norme, ali legitiman.

Na primjer, u AWS WAF-u možete stvoriti pravila dopuštene liste tako da se određene provjere potpisa ne primjenjuju ako zahtjev dolazi s određene IP adrese ili raspona ili ako se podudara s poznatim URL uzorkom i HTTP metodom. To pomaže u:

• Spriječite interne API-je koji koriste "čudne" obrasce generiraju stalne lažno pozitivne rezultate.
• Smanjite latenciju uzrokovanu dubinskom inspekcijom u prometu koji već smatrate pouzdanim.
• Smanjite količinu nepotrebnih zapisa u WAF zapisnicima.

Na platformama poput ModSecurityja, preporučeni pristup nije mijenjanje standardnih pravila (npr. OWASP Core Rule Set), već stvaranje specifičnih izuzeća prema ID-u pravila za određene parametre, putove ili korisnike. To vam omogućuje održavanje opće zaštite bez stvaranja velikih ranjivosti onemogućavanjem cijelih pravila na web-mjestu.

Ključno je u tome da se popisi dopuštenih učine kirurški , a ne općim pristupom. Mnogo je bolje isključiti određenu kombinaciju (pravilo X + parametar Y u URL-u Z) nego globalno onemogućiti pravilo X. Na taj način, bilježenje ostaje korisno i ne stvarate nepotrebne slijepe točke.

Pravila i ograničenja protokola: kada blokirati, kada upozoriti

Mnogi WAF-ovi uključuju skup pravila za sanitizaciju HTTP protokola koja djeluju kao prvi filter za oštećeni ili sumnjivi promet . Ta pravila provjeravaju potrebne zaglavlja, metode, veličine argumenata itd. i čest su izvor i dobre zaštite i lažno pozitivnih rezultata ako se ne razumiju pravilno.

Neki vrlo uobičajeni primjeri:

• Nedostaje zaglavlje za prihvaćanje (Nedostaje zaglavlje Accept): Ovo nije strogo kršenje RFC-a, ali mnogi zahtjevi bez ovog zaglavlja dolaze od automatiziranih alata ili loše napisanih skripti. To može utjecati na prilagođene API-je ili klijente koji ga ne šalju. U mnogim okruženjima, zapisivanje i brojanje je poželjnije od izravnog blokiranja.
• Nedostaje zaglavlje hostaPrema HTTP/1.1 standardima, zaglavlje Host je obavezno. WAF-ovi ga također trebaju kako bi odredili koju politiku primijeniti. Blokiranje ovdje je obično razumno, ali može generirati lažno pozitivne rezultate tijekom testiranja ili zbog pogrešno konfiguriranog internog prometa; preporučljivo je pratiti zapisnike prije omogućavanja strogog blokiranja.
• Nedostaje zaglavlje korisničkog agentaOvo pravilo pokušava obuzdati rudimentarne botove i neidentificirani promet. Problem je što mnogi legitimni API-ji možda neće slati korisničkog agenta. Najrazumniji pristup je obično evidentiranje i, ako se otkrije dosljedan i legitiman API, dodajte svoju IP adresu ili uzorak na popis dopuštenih.
• GET/HEAD validacija s tijelomIako RFC strogo ne zabranjuje slanje tijela s GET ili HEAD zahtjevima, to nije uobičajena praksa i može ukazivati ​​na pokušaje izbjegavanja. U mnogim slučajevima, prvi korak je evidentiranje svih tih zahtjeva i, ako se utvrdi da su sumnjive anomalije, njihovo blokiranje.
• Nedostaje Content-Type s tijelomAko postoji tijelo, ali ne i Content-Type, to je jasan pokazatelj nepravilne upotrebe protokola ili pokušaja izbjegavanja analize. U tim slučajevima, agresivniji pristup blokiranju obično ima smisla, posebno u okruženjima s pristupom internetu.

Uz ova pravila protokola, često se nalaze ograničenja argumenata za zaštitu od prelijevanja na razini aplikacije i DoS napada. Na primjer:

• Maksimalan broj argumenata po zahtjevu (prema zadanim postavkama, 255 u nekim WAF-ovima).
• Maksimalna duljina pojedinačnog argumenta (na primjer, 400 znakova).
• Ukupna kombinirana veličina svih argumenata (na primjer, 64 000 bajtova).

Ove vrijednosti su razumne za mnoge primjene, ali postoje slučajevi - složeni prijenosi obrazaca, napredni filteri, velika JSON učitavanja - gdje se javljaju lažno pozitivni rezultati. U tim scenarijima, najrazumniji pristup je započeti s evidentiranjem i brojanjem , pregledati koje krajnje točke probijaju ograničenja i prilagoditi samo za te rute, umjesto ukidanja svih ograničenja za cijelu web-lokaciju.

Lažno pozitivni rezultati: kako ih otkriti i ne umrijeti pokušavajući

Lažno pozitivan rezultat je legitimni zahtjev koji WAF identificira kao zlonamjeran i blokira ga ili označava kao napad. Neizbježni su, posebno kada imate omogućen sveobuhvatan skup pravila poput OWASP CRS-a, ali se njima može profesionalno upravljati kako ne bi postali svakodnevna glavobolja.

Otkrivanje lažno pozitivnih rezultata započinje pažljivim pregledom zapisnika . To uključuje ispitivanje koji se zahtjevi blokiraju, koje ih pravilo aktivira i konteksta u kojem se pojavljuju (URL, parametri, korisnik, podrijetlo itd.). Vizualni alati i nadzorne ploče mogu pomoći u prepoznavanju porasta 403 pogrešaka ili neobičnih obrazaca.

Toplo preporučeni pristup, i od strane pružatelja usluga u oblaku i od strane ModSecurity zajednice, jest korištenje načina simulacije ili brojanja . U ovom načinu rada, pravila koja želite testirati bilježe svako podudaranje, ali ih ne blokiraju. To vam omogućuje da vidite, na primjer, koliko bi legitimnih zahtjeva novo SQLi pravilo blokiralo prije nego što biste se usudili aktivirati ga u produkciji.

Također je dobra ideja testirati pravila u okruženju za testiranje ili predprodukciju koje prima stvarni ili simulirani promet. Alati poput OWASP ZAP-a ili skripti za reprodukciju prometa mogu vam pomoći u simuliranju legitimnih obrazaca i poznatih napada kako biste testirali ponašanje WAF-a.

Nadalje, ključno je uzeti u obzir operativni i reputacijski utjecaj lažno pozitivnih rezultata: prekidi plaćanja, neuspješne registracije korisnika, kritični API pozivi koji ne uspiju bez objašnjenja - sve to može imati izravne troškove u prihodima i imidžu robne marke. Preveliki broj lažno pozitivnih rezultata također preopterećuje sigurnosni tim upozorenjima koja ne dodaju vrijednost, što otežava prepoznavanje stvarnih incidenata.

Strategije za prilagodbu pravila i inteligentno korištenje registra

Upravljanje lažno pozitivnim rezultatima ne odnosi se na isključivanje pravila dok "sve ne radi", već na fino podešavanje WAF-a s kirurškom preciznošću . Tu dolaze do izražaja dobre prakse poput sljedećih:

Prvo, izbjegavajte globalno onemogućavanje pravila. Poželjno je stvoriti vrlo specifične iznimke : isključite ID pravila samo za određenu rutu, za određene parametre ili za interni promet. Na taj način ostajete zaštićeni u ostatku aplikacije i održavate korisne zapisnike.

Drugo, iskoristite način brojanja prije blokiranja. Aktiviranje novih pravila u početku samo u načinu zapisivanja omogućuje vam mjerenje koliko bi legitimnih zahtjeva bilo pogođeno. To možete nadopuniti upozorenjima u SIEM-u kako biste brzo otkrili generira li pravilo neuobičajenu količinu podudaranja.

Treće, integrirajte WAF sa SIEM-om ili centraliziranom platformom za evidentiranje . To olakšava povezivanje WAF događaja s drugim pokazateljima: neobičnom aktivnošću sustava, masovnim neuspjesima autentifikacije, sumnjivim promjenama konfiguracije itd. Također pomaže u određivanju prioriteta pravila koja treba prvo prilagoditi na temelju ozbiljnosti i učestalosti događaja.

Četvrto, dokumentirajte svaku promjenu: koje je pravilo fino podešeno, za koju krajnju točku, s kojim opravdanjem i s kojim dokazima. Za to može biti korisno konzultirati priručnike za poslužitelj . Ova dokumentacija ne samo da pomaže u održavanju interne kontrole, već je i neprocjenjiva u sigurnosnim revizijama i pregledima, gdje želite pokazati da se kontrole ne onemogućuju olako.

Automatizacija, strojno učenje i adaptivna pravila u WAF-u

Kako aplikacije rastu, a promet postaje složeniji, ručno upravljanje WAF-om postaje nerealno. Tu do izražaja dolaze automatizacija, napredna analiza zapisnika i, u nekim slučajevima, strojno učenje.

Prvo, integracija sa SIEM-om omogućuje vam izgradnju pravila korelacije i automatiziranih odgovora : na primjer, ako skup IP adresa opetovano aktivira pravila injekcije ili XSS-a, možete generirati automatsku radnju za dodavanje tih IP adresa na privremeni popis blokiranih ili pojačavanje razine inspekcije.

Drugo, neki WAF-ovi uključuju načine strojnog učenja koji promatraju legitimni promet tijekom definiranog razdoblja. Na temelju tih podataka predlažu ili prilagođavaju pragove, obrasce i profile normalnog ponašanja. To pomaže u smanjenju lažno pozitivnih rezultata kada se pravila prebace u način blokiranja i otkrivaju naknadna odstupanja prometa.

U istraživačkim i laboratorijskim okruženjima, tehnike nadziranog učenja korištene su za obuku modela koji razlikuju legitimni i zlonamjerni promet, poboljšavajući pravila koja se zatim koriste u produkciji. Iako nije čarobni štapić, ovaj pristup može pomoći u otkrivanju suptilnih obrazaca koje klasična pravila temeljena na potpisima ne mogu lako otkriti.

Konačno, kontinuirano automatizirano testiranje (korištenjem alata poput OWASP ZAP-a, prilagođenih skripti ili CI/CD cjevovoda) omogućuje vam da provjerite da promjene u WAF-u ne narušavaju kritične funkcionalnosti ili ostavljaju očite ranjivosti. Integriranje ovih testova u ciklus implementacije čini sigurnost prirodnim dijelom razvojnog toka, a ne zakrpom u zadnji čas.

Dizajn pravila po aplikaciji i crne liste po usluzi

U složenim okruženjima - na primjer, kod pružatelja hostinga ili ISP-a - jedna WAF politika nije dovoljna, posebno kada je uključen shadow IT . Uobičajeno je imati više domena ili aplikacija iza istog uravnoteživača opterećenja, svaka s različitim sigurnosnim potrebama i profilima prometa . Ovdje je dizajniranje politika i popisa specifičnih za usluge ključno.

Ilustrativan primjer je HTTP/S load balancer koji djeluje kao obrnuti proxy za više web-mjesta (npr. www.company1.com i www.company2.com) iza jedne virtualne IP adrese. U ovom scenariju, WAF se može konfigurirati da procijeni zaglavlje hosta i izvornu IP adresu čim zahtjev stigne, čak i prije nego što stigne do modula za balansiranje opterećenja.

Logika bi bila otprilike ovakva: WAF provjerava odgovara li kombinacija SERVER_NAME (Host) i IP adrese klijenta crnoj listi specifičnoj za web-mjesto. Ako je IP adresa navedena kao blokirana za www.company2.com, ali ne i za www.company1.com, odgovor 403 Forbidden šalje se samo u prvom slučaju. "Čist" promet zatim se prosljeđuje modulu za uravnoteženje opterećenja, koji odlučuje koji backend poslužuje zahtjev.

To omogućuje održavanje, na primjer, crnih lista specifičnih za domenu , umjesto jedne globalne liste za cijelu pristupnu točku. Na razini zapisivanja, svako odbijanje se bilježi u syslog s detaljima kao što su ID pravila, podudarni uvjet, URL, host i IP adresa klijenta, što olakšava naknadnu analizu i proširenje ili otklanjanje pogrešaka na tim listama.

Pouka priče je da što su vaše politike segmentiranije (prema aplikaciji, okruženju, vrsti korisnika), to je finiju ravnotežu između evidentiranja i blokiranja moguće postići: možete biti vrlo strogi na administrativnim portalima i nešto fleksibilniji na informativnim web stranicama, na primjer, uvijek s dokazima u evidencijama zašto je svaka odluka donesena.

Više od klasičnog WAF-a: WAAP i API zaštita

Prijetnje nisu mirovale. Danas su mnoge aplikacije izvorno zasnovane na oblaku, koriste mikroservisne arhitekture i otkrivaju javne i privatne API-je , što ih čini glavnim metama napadača. Tradicionalni WAF-ovi evoluirali su u šire platforme poznate kao WAAP (Web Application and API Protection - zaštita web aplikacija i API-ja) ili WAAS (Web Application & API Security - sigurnost web aplikacija i API-ja).

Ova rješenja ne samo da automatski otkrivaju web aplikacije, već i identificiraju API krajnje točke , prihvaćaju specifikacije poput OpenAPI-ja ili Swaggera i koriste tu definiciju za provjeru usklađenosti zahtjeva: očekivanih tipova podataka, dopuštenih parametara, ograničenja veličine itd. Ovisno o krajnjoj točki (na primjer, onoj koja obrađuje vrlo osjetljive podatke), može se primijeniti mnogo viša razina provjere i blokiranja.

Na razini zapisivanja, WAAP obično generira događaje bogate kontekstom : koja je točno krajnja točka API-ja napadnuta, koja operacija (GET, POST, PUT…), koji je korisnik ili token bio uključen, koji je dio specifikacije prekršen itd. To omogućuje preciznije odluke o blokiranju, umjesto oslanjanja isključivo na generičke obrasce korisnog tereta.

Nadalje, mnogi WAAP alati uključuju DoS zaštitu specifičnu za aplikacije i API-je, filtriranje geolokacije, upravljanje IP reputacijom, otkrivanje botova i struganja te opcije za prilagođavanje razina upozorenja po usluzi. Opet, radi se o fleksibilnosti odlučivanja gdje želite robusniji pristup, a gdje želite dati prioritet nesmetanom radu , bez žrtvovanja solidne baze podataka zapisnika za istraživanje bilo kakvih incidenata.

Uzevši sve u obzir, dobro podešen WAF - bilo klasični, WAAP-bazirani ili integrirani u cloud ekosustav - postaje bitna komponenta moderne obrane aplikacija i API-ja, sposobna kombinirati detaljno bilježenje, inteligentno blokiranje i kontinuiranu prilagodbu promjenjivom krajoliku prijetnji.