NTT: – Altfor lite av IT-sikkerhets­budsjettet brukes der de fleste av angrepene skjer

Ifølge det globale trusseletterretningssenteret til den japanske IKT-kjempen NTT er så mye som 55 prosent av alle IT-angrepsforsøkene selskapet observerer, rettet mot applikasjoner. Av disse igjen er 2 av 5 rettet mot webapplikasjoner, mens de resterende er rettet mot andre typer applikasjoner.

I Norge er andelen enda høyere, 65 prosent, hvorav 29 prosent er webapplikasjoner og 36 prosent er andre typer applikasjoner.

Dette går fram av en fersk rapport fra selskapet. I den samme rapporten vises det til tall fra Gartner Group som forteller at bare rundt 5,5 prosent av de 59 milliarder dollar som blir brukt på IT-sikkerhet i år, brukes til applikasjonssikkerhet.

– Burde være minst 50 prosent

NTT mener dette er en uheldig skjevfordeling.

– Det burte kanskje være 50 prosent eller mer, snarere enn bare 5,5 prosent, sier Arnt Ove Nedrebø, kundedirektør i NTT Limited Security Division, til Digi.no.

– Ting snur seg så fort at man på administrativt nivå ikke rekker å ta innover at man beveger seg mot å bli et applikasjonsselskap. Angrepene er jo der, selv om rapporten ikke sier noe om hvor mange av angrepene som er vellykkede, og at det kan være mørketall, fortsetter han.

NTT peker på at risikoer relatert til applikasjonssikkerhet ikke ligner på tradisjonell IT-sikkerhetsrisikoer, som i stor grad handler om å kontrollere kjente risikoer mot kjente komponenter. Dette kan i stor grad løses med riktig brannmurinnstillinger og å sørge for at sikkerhetsoppdateringer blir installert.

Særlig web

Ikke minst webbaserte applikasjoner kan være en utfordring, da de ikke skiller mellom legitim og ondsinnet trafikk som går tvers gjennom brannmuren og inn i «bakgården», hvor man ofte finner virksomhetens viktigste verdier. Da er det avgjørende at webapplikasjonen ikke har sikkerhetshull.

Noe av problemet, ifølge NTT, er at protokollen som brukes – HTTP – aldri ble designet for sikker applikasjonsleveranse, noe som gjør at bygging av webapplikasjoner lett fører til feil.

Risikokategorier

NTT mener applikasjonssikkerhetsrisikoene kan fordeles på tre kategorier, «assemble» (A), «build» (B) og «configure» (C).

I A arves risiko når man bringer sammen komponenter som applikasjonen skal bygge på, slik som rammeverk, biblioteker og operativsystemfunksjonalitet.

I B skapes risiko når funksjonalitet lages, uten sikker design fra starten av, eller med egnede sikkerhetskontroller.

I C skapes risiko når applikasjoner rulles ut for å tilby ny funksjonalitet, dersom ikke standardinnstillingene «herdes».

Lite hjelp i tradisjonelle verktøy

Ifølge NTT åpenbarer risikoene i A og C seg til en viss grad for tradisjonelle IT-sikkerhetsmetoder, men det gjelder i svært liten grad det som skjer i B. Selskapet peker på at sju av de ti på OWASPs toppliste over webapplikasjonsrisikoer hører hjemme i B-kategorien.

NTT mener at vanlige sikkerhetsløsninger som IDS (Intrusion Detection System), IPS (Intrusion Prevention System) og WAF (Web Application Firewall) i begrenset grad vil være til hjelp. Spesielt IDS og IPS mangler den nødvendige konteksten, ved at de ikke kjenner irrgangene i de ofte komplekse webapplikasjonene. WAF er noe bedre stilt, ifølge NTT, men det vil kreve mye tid og ekspertise til konfigurering, vedlikehold og overvåking.

Ujevn testfrekvens

Svaret er ifølge NTT økt testing av applikasjonene, slik at sårbarhetene faktisk blir oppdaget før de blir utnyttet. Men det er ifølge Nedrebø ikke bare enkelt å få til.

– Applikasjonstesting er noe som foregår veldig ad hoc, også i det norske markedet, og har gjort det i mange år. Vi har, under ulike navn, levert tester til det norske markedet i mange år. Og det er helt klart at det for mange selskaper ikke har vært noe mønster innen testing, forteller han

– Nå snakker man om at det er digital vill vest. Vi snakker utviklere rundt omkring i de store netthandelsselskapene, og de har jo stort sett aldri tid til noen ting. De ligger etter med påfunn fra markedsavdelingene, og det er alltid nye ting som skal utvikles og faste datoer på dette. Dermed går det for lang tid mellom hver gang man får gjort en sikkerhetstest, selv om det er behov for kontinuerlig informasjon om sårbarheter og feil, fortsetter Nedrebø.

Koronasituasjonen har ført til at mange nettbutikker har fått det veldig travelt, og denne uken har for mange vært den store styrkeprøven.

– Jeg kan ikke si at den generelle testfrekvensen har gått noe opp av den grunn det siste halvåret. Kanskje snarere tvert imot.

Anbefaler kontinuerlig testing

I rapporten tar NTT derfor opp automatisert og kontinuerlig testing.

Det nevnes tre ulike metoder.

DAST (Dynamic Application Security Testing), som er testing av den kjørende applikasjonen, sett med angripernes perspektiv, uten innsidekunnskap om applikasjonen. Dette sender manipulerte spørringen til servere for å simulere angrep. Dette kan finne sårbarhetene, men utviklerne må selv finne årsaken til sårbarhetene.

SAST (Static Application Security Testing) handler om kodeanalyse. Det kan oppdage implementeringsfeil, men ikke designfeil. I disse tilfellene går verktøyet direkte til kilden til sårbarhetene, slik at utviklerne slipper å lete.

Den tredje varianten kalles for SCA (Software Composition Analysis). Den ser etter offentlig kjente sårbarheter, typisk i tredjepartskode som applikasjonen bygger på. Dette kan løses med tilgjengelige patcher eller oppdateringer.

– Når du kommer på jobb på morgenen, vil du få vite at det har oppstått noe et eller annet sted. Da vil du kunne rette på det med en gang. Det er langt mer avslappende enn å sitte å lese en 70 siders rapport to ganger i året. Så i stedet for å få dårlig tid på slutten av utviklingen, eller å stole annen type IT-sikkerhet, så er vi tilbake til å sikre applikasjonen fra begynnelsen av, sier Nedrebø.

– Det et klart det er en hel del billigere å gjøre ting med en SAST-løsning under kodingen, enn å gjøre det i all hast på slutten. Det blir også mer ro over det hele, og ro gjør at man får tid til å gjøre ting på en måte som er mer hensiktsmessig for alle, hevder han.

Et litt tungt samarbeid

Nedrebø mener at samarbeidet mellom utviklere og sikkerhetsfolk til tider kan være litt tungt.

– Det å kunne forstå hverandre riktig på kryss og tvers av «lingo», problemstillinger og ansvar kan være en utfordring i mange selskaper. Jeg tror det kommer av at man fra tradisjon av kommer fra to forskjellige verdener. Det burde egentlig også ha vært noe midt imellom. Med sikkerhetstesting tidlig får utviklerne funnene i et språk som de forstår, formulert i den koden de har gjort en feil i, sier han.

– De to gruppene har et felles ansvar, ved at selskapene nå oppleves gjennom applikasjoner, fordi alle nå er programvareselskaper. Da må man kombinere fagfeltene som nå er involvert i dette, og kanskje gjøre det på en litt annen måte, fortsetter Nedrebø.