En WAF-administrator beskytter webapplikationer ved at skelne legitim trafik fra mønstre, der kan ligne angreb. I en dansk e-handelsvirksomhed kan en ny checkout-funktion efter en release pludselig udløse hundredevis af WAF-alarmer, mens kunder oplever fejl, udviklere fastholder, at trafikken er legitim, og SOC-teamet hurtigt skal afgøre, om problemet skyldes et angreb eller en regel, der rammer forkert.
Det er netop i den type situation, en WAF-administrator skaber værdi. Rollen handler om at konfigurere, overvåge og forbedre en Web Application Firewall, så webapplikationer beskyttes mod angreb som SQL-injektion, cross-site scripting og misbrug af API-endpoints, uden at legitime brugere bliver blokeret unødigt. Læsere, der mangler et teknisk fundament, kan med fordel begynde med en kort introduktion til hvad en WAF er, men karrierevejen kræver mere end produktkendskab.
En WAF-administrator arbejder i krydsfeltet mellem applikationssikkerhed, netværk, drift og compliance. I danske og nordiske organisationer betyder det ofte samarbejde med SOC, udviklingsteams, platformsteams, databeskyttelsesansvarlige og eksterne leverandører. GDPR og Datatilsynets vejledninger er relevante rammer, men rollen bør ikke forstås som juridisk rådgivning. Den praktiske opgave er at sikre, at organisationens tekniske kontroller understøtter krav til fortrolighed, integritet, tilgængelighed og dokumenterbar risikohåndtering.
Hvad laver en WAF-administrator i praksis?
En WAF-administrator beskytter webapplikationer ved at styre de regler og politikker, der vurderer HTTP- og HTTPS-trafik. Det kan være loginforsøg, formularinput, API-kald, filuploads, cookie-manipulation, URL-mønstre eller mistænkelige payloads. Hvor en traditionel netværksfirewall typisk ser på IP-adresser, porte og protokoller, arbejder en WAF tættere på applikationslaget og vurderer, hvordan webtrafikken faktisk opfører sig.
Arbejdet begynder sjældent med at blokere alt mistænkeligt. En moden WAF-funktion starter typisk i detection mode, hvor regler registrerer potentielle angreb uden at afvise trafikken. Herefter analyseres logs, falske positiver måles, og regler justeres efter applikationens reelle adfærd. Først når teamet har tilstrækkelig sikkerhed for, at en regel rammer korrekt, flyttes den gradvist til blokering. Den proces kræver ændringsstyring, dokumentation og en rollback-plan, så en aggressiv signatur ikke lammer en vigtig forretningsproces.
En almindelig fejl i nye WAF-implementeringer er at gå direkte i block-first uden tuning, springe den daglige loggennemgang over eller ændre regler uden et klart håndtryk med udviklingsteamet. Det giver ofte to problemer på samme tid: reelle angreb overses i støjen, mens legitime brugere bliver ramt af upræcise regler. En dygtig administrator bygger derfor en feedback-loop, hvor incident tickets, release notes og applikationsændringer løbende omsættes til forbedrede regler, undtagelser og eventuelt ændringer i selve applikationens sikkerhedskontroller.
Websikkerhedsfundamentet bag rollen
Rollen kræver en solid forståelse af de mest almindelige webapplikationsrisici. OWASP Top 10 bruges ofte som fælles sprog for risici som injection, broken access control, security misconfiguration og vulnerable components. Det betyder ikke, at en WAF alene kan løse alle kategorier, men den kan opdage, reducere eller købe tid mod flere typer angreb, mens udviklingsteamet retter årsagen i koden. En nyttig fordybelse er en gennemgang af OWASP Top 10, fordi den hjælper med at forbinde WAF-regler med konkrete applikationssvagheder.
Ud over OWASP bør en WAF-administrator kende grundprincipperne i sikker softwareudvikling, HTTP, TLS, cookies, sessionsstyring, autentificering og autorisation. For eksempel er en XSS-alarm ikke bare en teknisk hændelse i en logfil. Den bør føre til spørgsmål om output encoding, Content Security Policy, inputhåndtering og om sårbarheden kan misbruges i en brugers session. På samme måde bør SQL-injection-alarmer vurderes sammen med brugen af parametriserede forespørgsler, ORM-lag og databaseprivilegier.
Myndigheds- og branchekilder giver et godt fælles referencepunkt. NIST beskriver sikkerhedskontroller og risikostyring på et niveau, der passer til governance og drift. ENISA udgiver vejledning om cybersikkerhed og trusselsbilleder i europæisk kontekst. Datatilsynet er relevant, når webapplikationer behandler personoplysninger, og når organisationen skal kunne dokumentere passende tekniske og organisatoriske foranstaltninger. Disse kilder bør bruges som rammer, mens den konkrete WAF-konfiguration altid tilpasses applikationens risiko og arkitektur.
Arkitekturvalg: cloud, appliance, reverse proxy og open source
Valget af WAF-model påvirker både sikkerhed, drift og compliance. En cloud- eller CDN-integreret WAF kan give hurtig skalering, global edge-beskyttelse, DDoS- og bot-mitigering samt central administration på tværs af applikationer. Det passer ofte godt til offentlige websites, e-handel og SaaS-løsninger, hvor performance og global tilgængelighed er vigtige. Til gengæld skal organisationen forstå, hvor trafikken termineres, hvilke logs der lagres, og hvordan databehandlerforhold håndteres.
En appliance eller virtuel WAF i eget miljø kan være relevant, når trafik ikke må forlade bestemte netværk eller jurisdiktioner, eller når ældre applikationer kræver særlige netværksmønstre. En reverse proxy-model giver god kontrol over trafikken mellem bruger og applikation, men den tilføjer også et driftspunkt, som skal patches, overvåges og kapacitetsstyres. Inline placering kan blokere angreb direkte, mens mirrored eller out-of-band analyse giver synlighed med lavere risiko for brugerafbrydelser, men uden samme umiddelbare blokeringsevne.
Open source-baserede løsninger, eksempelvis ModSecurity med OWASP Core Rule Set, giver fleksibilitet og transparens, men kræver mere intern driftstid. Regelsæt skal versionsstyres, testes og rulles ud kontrolleret. I praksis har mange organisationer gavn af Git til WAF-regler og Infrastructure as Code med værktøjer som Terraform eller Ansible, fordi det skaber review-spor, gør ændringer reproducerbare og gør rollback lettere efter en regel, der viser sig at være for bred.
Et kort eksempel viser, hvordan en regel kan se ud i en ModSecurity-lignende kontekst. Formålet er ikke at kopiere reglen direkte ind i produktion, men at forstå, hvordan WAF-logik typisk knytter et mønster til en handling, en alvorlighed og et audit-spor.
Eksempel — simpel detektionsregel for mistænkeligt input
SecRule ARGS "(?i)(union select|sleep\(|benchmark\()" \
"id:120010,phase:2,log,pass,msg:'Possible SQL injection pattern',severity:CRITICAL,tag:'application-attack-sqli'"
Reglen logger et muligt SQL-injection-mønster i request-parametre, men den blokerer ikke, fordi handlingen er sat til pass. Det er et fornuftigt udgangspunkt i tuningfasen, hvor teamet skal kontrollere, om mønsteret rammer reelle angreb eller legitime søgninger, rapporter eller interne værktøjer. Før en sådan regel ændres til block eller deny, bør den testes mod forretningskritiske flows og have en dokumenteret rollback.
Den daglige driftsrytme
WAF-administration er en driftsdisciplin, ikke en engangsinstallation. En almindelig arbejdsdag kan begynde med gennemgang af alarmer fra natten, korrelation med SIEM-data og vurdering af, om trafikken er automatiseret scanning, credential stuffing, en fejl i applikationen eller en falsk positiv. Derefter følger ofte tuning, dialog med udviklere og dokumentation af ændringer. Hvis en ny release ændrer URL-struktur eller API-format, skal WAF-politikkerne måske opdateres, før fejlen rammer brugerne.
De mest nyttige målepunkter er dem, der siger noget om både sikkerhed og brugeroplevelse. Antal blokerede requests kan være interessant, men tallet alene siger ikke meget, hvis legitime kunder også rammes. En moden WAF-funktion måler derfor false positive rate på kritiske transaktioner, tid fra detekteret angreb til mitigering, stabil reduktion i kendt uønsket trafik og dækning mod de OWASP Top 10-kategorier, der faktisk er relevante for applikationen. Samtidig bør latency og fejlrate følges, så sikkerhedskontrollen ikke selv bliver en driftsrisiko.
Et typisk alarmformat kan hjælpe nye i rollen med at forstå, hvad der bør undersøges. I praksis vil formatet variere mellem leverandører, men felterne fortæller ofte den samme historie: hvilken regel udløste alarmen, hvilken del af requesten blev matchet, hvilken applikation var ramt, og hvad gjorde WAF'en ved trafikken.
Eksempel — WAF-alarm der kræver triage
{
"timestamp": "2026-03-14T09:42:18Z",
"action": "log",
"ruleId": "120010",
"severity": "critical",
"host": "checkout.company.dk",
"uri": "/payment/confirm",
"matchedData": "union select",
"sourceIp": "198.51.100.24",
"requestId": "req-7f29c8"
}
En erfaren administrator vil ikke kun se på matchedData. Der bør også undersøges brugerrejse, request-frekvens, geografi, tidligere aktivitet fra samme kilde, om checkout-flowet netop er ændret, og om applikationsloggene viser fejl eller databaseforespørgsler. Hvis hændelsen er reel, kan en midlertidig blokering være nødvendig. Hvis den skyldes legitim funktionalitet, bør reglen tunes snævert, så undtagelsen ikke åbner for bredere angreb.
Samarbejde med SOC, netværk og udvikling
En WAF-administrator får sjældent succes alene. SOC-teamet ser ofte hændelserne først og har brug for klare playbooks for, hvornår en alarm eskaleres, og hvilke data der skal med. Netværksteamet kan eje routing, TLS-terminering, DNS eller load balancing. Udviklingsteamet kender applikationens logik og kan afgøre, om et mønster er forventet adfærd eller et tegn på svag inputhåndtering. Rollen kræver derfor både teknisk præcision og evnen til at oversætte fund til handlinger, andre teams kan bruge.
Når WAF-arbejdet kobles til releaseprocesser, bliver det en del af DevSecOps frem for en separat kontrol sent i forløbet. Det betyder, at nye endpoints, API-kontrakter, sikkerhedsheadere og ændringer i autentificering tænkes ind før produktion. En praktisk introduktion til DevSecOps kan give kontekst for, hvordan WAF-regler, sikkerhedstests og udviklingsbacklogs kan hænge sammen uden at bremse alle releases unødigt.
Færdigheder der gør forskellen
Den tekniske kerne består af HTTP, TLS, DNS, reverse proxies, load balancing, API-sikkerhed, loganalyse og almindelige angrebsteknikker mod webapplikationer. Dertil kommer forståelse for scripting og automatisering, fordi gentagne regelændringer, logudtræk og miljøsammenligninger hurtigt bliver fejlbehæftede, hvis alt udføres manuelt. Kendskab til SIEM, ticketing, Git og cloud-platforme er også nyttigt, fordi WAF'en sjældent lever isoleret.
Kommunikation er lige så vigtig som konfiguration. En administrator skal kunne forklare, hvorfor en regel bør skærpes, hvorfor en undtagelse er risikabel, eller hvorfor en applikationsfejl ikke bør skjules permanent bag WAF'en. Den bedste WAF-drift bruger firewallen som sikkerhedskontrol og sensor, men lader ikke WAF'en blive en erstatning for sikker kode, patching eller adgangsstyring.
Certificeringer og læring uden at gøre dem til genvej
Certificeringer kan give struktur til læringen og gøre det lettere at dokumentere et bredere sikkerhedsfundament, men de er ikke i sig selv bevis på, at en person kan drive en WAF sikkert i produktion. Rollen kræver praktisk erfaring med tuning, incident response, logs, ændringsstyring og samarbejde med applikationsejere. En juniorprofil kan derfor stå stærkt ved at kombinere en grundlæggende sikkerhedscertificering med et labmiljø, hvor regler testes mod realistiske webflows.
Nogle certificeringer dækker emner, der er relevante for rollen, selv om de ikke er WAF-specifikke. CompTIA Security+ kan give et bredt fundament for sikkerhedsbegreber. CEH kan hjælpe med at forstå angriberens metoder. CISSP og CISM er mere relevante, når rollen bevæger sig mod arkitektur, governance, risikostyring eller ledelse. Valget bør afhænge af jobmål, eksisterende erfaring og hvor meget hands-on drift personen allerede har.
Karrierevej i Danmark og Norden
Indgangen til rollen kommer ofte fra systemadministration, netværk, SOC, cloud operations, udvikling eller penetrationstest. En netværksprofil har typisk styr på trafikflow, TLS og drift. En udvikler forstår kode, frameworks og releaseprocesser. En SOC-analytiker har erfaring med alarmer, prioritering og hændelsesrespons. Alle tre profiler kan blive stærke WAF-administratorer, hvis de supplerer med applikationssikkerhed og praktisk regelstyring.
Typiske arbejdsgivere omfatter finans, e-handel, SaaS, offentlige myndigheder, konsulenthuse, sundhedssektoren og større virksomheder med digitale selvbetjeningsløsninger. I Norden er rollen ofte blandet med cloud security, platform engineering eller AppSec, især i mindre teams. Det betyder, at jobtitlen ikke altid hedder WAF-administrator. Stillinger som application security engineer, cloud security specialist, security operations engineer eller platform security engineer kan indeholde mange af de samme opgaver.
Løn bør vurderes lokalt og med forsigtighed. Den oprindelige amerikanske reference til Web Security Administrator salary kan give et internationalt perspektiv, men den siger ikke nødvendigvis noget præcist om danske forhold. I Danmark bør kandidater hellere sammenligne med lokale kilder som Jobindex, IDA, fagforeninger og danske løndatabaser, og samtidig tage højde for branche, ansvar, vagtordning, cloud-erfaring og om rollen inkluderer incident response.
Sådan opbygges erfaringen
En praktisk vej ind i rollen er at bygge et lille lab med en sårbar testapplikation, en WAF i detection mode og et simpelt logflow. Det giver mulighed for at se forskellen mellem en generisk signatur, en falsk positiv og en målrettet regel. Næste skridt er at versionsstyre regler, skrive korte ændringsnoter og teste rollback. Den vane er værdifuld, fordi produktionsfejl i WAF-laget ofte skyldes for brede undtagelser, manglende review eller ændringer uden sammenhæng med applikationens releaseplan.
Efterhånden bør læringen flyttes tættere på virkelige driftsmønstre: API-beskyttelse, bottrafik, rate limiting, loginmisbrug, filupload-regler, sikkerhedsheadere og integration med SIEM. Projekter bør dokumenteres som små cases: hvilket problem skulle løses, hvilken risiko blev reduceret, hvilke falske positiver opstod, og hvordan blev ændringen valideret. Den type dokumentation er ofte mere overbevisende i en ansættelsesproces end en lang liste af værktøjer.
Næste skridt mod rollen
En karriere som WAF-administrator bygges bedst gennem en kombination af webforståelse, sikkerhedsdrift og disciplineret ændringsstyring. Rollen kræver evnen til at se både angrebsmønstre og brugeroplevelse, både compliancekrav og udviklingstempo. Den person, der kan reducere risiko uden at skabe unødvendig friktion for forretningen, bliver hurtigt værdifuld i et sikkerhedsteam.
A practical next step is to choose one application security skill area, build a small lab around it, and document the operational decisions as if they were going into production. Readynez kan indgå som én måde at strukturere den videre læring på, og Unlimited Security Training kan være relevant for sikkerhedsprofessionelle, der vil kombinere certificeringsforberedelse med løbende hands-on træning. Det vigtigste er dog, at læringen kobles til konkrete WAF-opgaver: logs, tuning, change management, samarbejde og målbar risikoreduktion.
