Derfor er brannmuren så godt som død

Organisasjoner som har en webapplikasjon, det vil si alle store firmaer, har en Web Application Firewall (WAF) installert for å beskytte sine data for brudd mot eiendeler. De siste årene har beste praksis vært å kun distribuere en WAF foran selskapets app.

Sannheten er at i dag, med den moderne applikasjonssyklusen i Devops, har man muligheten til å gi ut oppdateringer med høy frekvens. Da klarer ikke lenger den tradisjonelle brannmuren å følge med og vedlikeholdet som kreves har blitt vanskelig og tidkrevende.

Så hva bør sikkerhetspersonell gjøre? Hva vil forhindre at webapplikasjoner blir inngangsdøren til bedriftens infrastruktur? DevOps fortsetter å spinne ut nye koder, hvordan kan man vite om bedriftens brannmur skal beholdes eller begraves?

La oss se nærmere på hva det tar for en brannmur å holde tritt med Devops;

Viktigheten av kontekst

Mens nettverkssikkerhet handler om å overvåke statiske nettverk som bruker de samme protokollene, ble brannmuren designet for å beskytte webapplikasjoner som er tydelig forskjellig fra hverandre. Hver app er unik, og hver kode er forskjellig nyansert med sitt eget sett med sårbarheter. Allerede før introduksjonen av skylagring og Devops, ble brannmur sett på som en middelmådig sikkerhetsløsning.

Det er uunngåelig at bruk av en løsning som kun sitter foran appen i stedet for å bli integrert, gjør kontekstuell analyse umulig. Uten kontekst for å forstå innholdet i appen det blir samhandlet med, er det umulig å automatisere brannmurens utvikling parallelt med applikasjonens utvikling.

Avanserte brannmurer trenger «bare» omtrent en måned for å lære å lage en grunnlinje for en applikasjon, men det er lang tid å la en app være ubeskyttet. Det er derfor uunngåelig at administrator må gå inn og hjelpe til med å kalibrere brannmuren, og det er da vedlikeholdet blir tungt. Hvis brannmuren trenger tid til å lære og lage en basislinje hver gang innholdet eller koden endres, er det mye arbeid for administratoren for å redusere varsler og skape unntak.

Automatiser eller oppløs

Det har blitt vanskeligere for brannmuren å beskytte en webapplikasjon mot logiske angrep uten menneskelig inngripen. Virkeligheten er at de fleste brannmurer ikke er i varslingsmodus. Det er for farlig å la dem blokkere for mye, fordi det høye volumet av varsler vil føre til svikt.

Kanskje en administrator kan gjøre litt mindre finjustering, så de følsomme delene av appen er dekket av blokkeringsregler, men resten av appen vil bli beskyttet av en brannmur i varslingsmodus ved hjelp av mønstermatching og andre grove teknikker. Dette legger opp til en sikkerhetsløsning som ikke kan distribueres automatisk for å beskytte mot nye logiske angrep når appen utvikler seg.

Vær rask, eller dropp det!

Native cloud computing handler om smidighet. Det som tok to uker å programmere i 2015, tar nå bare få sekunder. Ved å utnytte mikrotjenester kan man endre applikasjoner drastisk på bare få minutter. I den moderne verden er det absurd bare å vurdere å bruke en standard sikkerhetsløsning før applikasjonen, som er avhengig av læring eller manuelle konfigurasjoner.

Hver gang en utvikler justerer koden og sender den ut, er det nesten alltid gjort uten konsultasjon med sikkerhetspersonell. Hvis du bruker en brannmur som er avhengig av antagelsen om at ALT i ditt landskap er generisk, er WAF så å si avviklet.

Brannmuren slik vi kjenner den er død og Devops drepte den. Nå er det på tide å gjennomføre en rettsmedisinsk analyse for å finne ut om WAF i det hele tatt har en puls, eller om den skal begraves.

Her er noen spørsmål du bør stille:

• Er WAF designet for skyen?

• Kan WAF bestemme legitime trafikkbrukere versus ondsinnede?

• Kan WAF dechiffrere BOTS og andre OWASP-angrepsvektorer fra legitime henvendelser?

Hvis du svarte nei på disse spørsmålene, er det på tide for deg å evaluere sikkerheten til sky-appen din.

Jørn Nygaard, Norgessjef Check Point Norge