Slik jobber sikkerhetsekspert Bjørstad i Mnemonic – og dette er hans beste tips til utviklere

Tor Erling Bjørstad er fagansvarlig for applikasjonssikkerhet i Mnemonic, og leder et team på fem – snart seks – tekniske sikkerhetskonsulenter. Han har vært ansatt i Mnemonic i fem år, og jobber mye med blant annet sikkerhetstesting.

Bjørstad har doktorgrad (Ph.d.) i kryptografi, og er utdannet sivilingeniør i matematikk fra NTNU. Han har jobbet fulltid med sikkerhet i 12 år som forsker og som sikkerhetskonsulent.

– Mnemonic er et rent sikkerhetsselskap. Vi driver kun med sikkerhet, og prøver å gjøre det aller meste innenfor sikkerhet og muligheten til å være en helhetlig leverandør av det som knyttes til sikkerhet, sier Bjørstad.

Mnemonic har vært en del i media i høst sammenheng med deres samarbeidsrapport med Forbrukerrådet om sikkerheten i smartklokker for barn.

Tre avdelinger

Mnemonic er organisert i tre avdelinger: Avansert Trusselbeskyttelse, Produkt og Support og Risk Services.

– Vi tilbyr blant annet sikkerhetstjenester hvor vi hjelper kunder med å holde oversikt over hva som skjer i deres nettverk og systemer, og å varsle dem hvis det skjer noe. Der har vi døgnbasert drift og et stort tjenesteapparat, sier Bjørstad.

Mnemonic ble grunnlagt i år 2000 og er et norsk firma – 90 prosent eid av de ansatte. Gründerne jobber der fortsatt. De har noen internasjonale partnere og har begynt å bevege seg ut i verden – men er altså i utgangspunktet et norsk firma med base i Norge.

I Technical Risk Services-grupperingen – der Bjørstad leder en av gruppene – er de totalt 17 stykker.

– Det er en del fri konsulentvirksomhet knyttet til IT-sikkerhet og risiko i denne grupperingen, sier Bjørstad.

– Vi er logisk inndelt med avdelingsledere og gruppeledere. Det er en ganske flat organisasjon, og alle er praktiserende konsulenter. Noen jobber i tillegg til konsulentvirksomhet mer med overordnede ting som personalledelse, rekruttering og så videre.

Sikkerhetsesting av nye og gamle systemer

– Hva salgs oppdrag utfører dere, og hvordan jobber dere?

– Vi har alt fra veldig korte oppdrag til veldig langsiktige prosjekter. Jeg gjør begge deler, sier Bjørstad.

Han har flere ganger hatt rolle som sikkerhetsansvarlig i sikkerhetsprosjekter, med overordnet ansvar for å følge opp at det som lages henger på greip sikkerhetsmessig, at sikkerhetskrav blir ivaretatt, at de tar de riktige valgene rundt design, og at de følger opp utvikling og testing.

– Det er flere på avdelingen som jobber mer med langsiktige sikkerhetsprosjekter i ulike roller, som tekniske fageksperter, sier Bjørstad.

– Vi gjør også ganske mange oppdrag i sammenheng med at noen trenger å få gjort en sikkerhetstest eller penetrasjonstest. Dette er typisk fordi det er nytt system som skal lanseres – eller et gammelt system som ikke har vært testet på en stund, sier Bjørstad.

– Eller kanskje man ønsker å få et bilde av hvordan situasjonen egentlig er og ønsker at noen utenfra utfører den undersøkelsen. Dette er typisk mer tidsbegrensede oppdrag hvor vi går inn og prøver å forstå funksjonaliteten, brukergruppen, hvilke data som behandles og hvilke teknologier som er i bruk.

– Vi ser etter måter å utføre handlinger som ikke var tiltenkt da man laget systemet, som det egentlig ikke skulle vært mulig å gjøre, sier Bjørstad.

Både kommersielle og åpen kildekode-verktøy

Bjørstads og hans avdeling sitt hovedområde er altså applikasjonssikkerhet.

– Vi har en dedikert infrastruktur som vi har satt opp til for å gjøre sikkerhetstesting. Det er både satt opp adskilt fra alle andre systemer vi har, og med en del ekstra sikkerhetstiltak rundt. Der har vi en kombinasjon av kommersielt sikkerhetsutstyr og en god del verktøy basert på åpen kildekode, sier Bjørstad.

Han forteller at de i testing benytter seg av en god blanding av kommersielle og åpne sikkerhetsverktøy.

– Viktige åpne verktøy er blant annet distribusjonen Kali Linux, og programvare som nmap og sqlmap. For å simulere angrep mot Windows-miljø er Powershell Empire ett av flere eksempler på et veldig kraftig verktøy.

– Hvorfor bruker dere akkurat disse verktøyene?

– For eksempel Kali Linux kommer ferdig oppsatt med mange ulike verktøy. Det er alt fra verktøy til å installere en Wordpress-installasjon til verktøy for å dumpe og manipulere TCP/IP-pakker. Det er en god blanding av bedrifter og privatpersoner som bruker det. Det er en distro spesielt rettet mot sikkerhetsarbeid, sier Bjørstad.

– Det er noen åpen kildekode-verktøy som er best i klassen i det de gjør, og da gir det ikke så mye mening å bruke noe annet, sier Bjørstad.

– Og prinsippet gjelder begge veier – det er også en del kommersielle verktøy som er soleklart «best i klassen». Da bruker vi selvfølgelig dem også. Vi har en stor verktøykasse, sier Bjørstad.

Portskanning og søppeldata

– Vi bruker også Nmap. Nmap er et klassisk portskanningsverktøy som har veldig mange funksjoner, og som gjør veldig mye. Det er standard i verktøykassen for alle som driver med sikkerhet, sier Bjørstad.

– For webapplikasjoner er en såkalt SQL-injeksjon en av de mest alvorlige sårbarhetstypene. Kort forklart sender her sluttbrukeren inn noe «søppeldata » som blir håndtert på en måte som det ikke burde, forklarer Bjørstad.

Han forklarer at det han kaller søppeldata rett og slett er data som ikke er forventet, og at dette i et større perspektiv er roten til mange sikkerhetsproblemer.

– Denne søppeldataen treffer typisk en webserver i front og vikler seg ned gjennom applikasjonen og diverse logikk, og ender i en database-spørring. Og hvis denne søppeldataen blir tolket av databasen som databasesyntaks og ikke som data, så har du et problem, sier Bjørstad.

– Da har du også verktøy som heter sqlmap, som også er åpen kildekode, og som automatiserer prosessen fra å ha funnet et punkt hvor du kan sende inn noe til å gjøre en mer strukturert datauthenting. Det er typisk også et verktøy som brukes for å demonstrere at det er en reell sårbarhet, og som synliggjør hva som er konsekvensene av sårbarheten, sier Bjørstad.

Fremprovoserer feil

– Hvordan går dere konkret frem når du skal sikkerhetsteste for eksempel en webapplikasjon?

– Da vil første steg være å prøve å forstå hvordan det egentlig skal virke, og å kartlegge de interaksjonene som går mellom nettleseren og denne websiden ved normalbruk – og hvilke funksjoner som fins, sier Bjørstad.

– Vi danner oss et bilde av hvordan for eksempel denne nettsiden er bygget opp, både funksjonelt og teknisk.

Når en slik kartlegging er gjort, kan de begynne å se etter svakheter.

– En av måtene vi gjør det på er at vi kjører verktøy som automatisk begynner å forandre på forespørslene for å se om det da skjer noe annet, sier Bjørstad.

– På mer eller mindre intelligente måten prøver vi å fremprovosere feil. Det er også en prosess man kan gjøre mer manuelt dersom man har en mistanke om hvor det er lurt å begynne, sier Bjørstad.

Av sikkerhetsårsaker kan han ikke gi konkrete eksempler på hva de gjør for å fremprovosere feil:

– Men det er laget noen demoapplikasjoner som er ment å være sårbare som man kan sette opp og leke seg litt med. Da får man ganske fort en følelse for hvordan det funker, sier Bjørstad.

To klassiske websårbarheter

– Ett klassisk eksempel på en websårbarhet er det som kalles «cross site scripting», sier Bjørstad.

Han forklarer nærmere:

– En nettside består jo av sin egen logikk med HTML og JavaScript og stylesheets og så videre, og kjører i nettleseren til brukeren. Hvis du har en cross site scripting-sårbarhet betyr det at man finner teknikker der man kan få script som ikke hører hjemme på denne siden til å kjøre der.

Bjørstad presiserer at–dette strengt tatt ikke trenger å være «script».

– Poenget er at man får dyttet inn uønsket innhold. Hvorvid det er HTML eller JS eller CSS eller noe annet er ofte underordnet.

Han forteller at en bruker for eksempel kan legge inn ondsinnet data i en profiltekst eller annen ressurs. Når en annen bruker kommer forbi profilen, kan dataene bli tolket som et script eller annet innhold.

– Så angrepskoden går via nettsiden, men kjører i nettleseren til en annen bruker, sier Bjørstad.

– Det finnes noen sikringsmekanismer i nettleserne for å begrense hvordan JavaScript får lov til å kjøre. Men hvis man klarer å omgå dem kan man gjøre alt man kan gjøre med JavaScript, og det er stort sett veldig mye. Content Security Policy (CSP) er et eksempel på en slik mekanisme, sier Bjørstad.

Ett typisk eksempel vil være å hente ut og stjele sensitiv informasjon, og å utføre funksjoner i nettsiden, forteller han.

– Si at du har en meldingstjeneste og du sender en melding til en admin som inneholder et ondsinnet skript. Når admin åpner denne meldingen, kjører skriptet – og oppretter for eksempel nye brukere av seg selv.

– Vi jobber med å avdekke blant annet cross site scripting og å hjelpe kundene med å unngå den type feil. Vi prøver da som tidligere nevnt å interagere med disse applikasjonene på en måte som ikke er tiltenkt, og dermed endre på logikken i det som skjer, sier Bjørstad.

– Et annet klassisk eksempel på en websårbarhet er dette med manglende tilgangskontroll – at du for eksempel har en parameter som heter kontonummer, så endrer man parameteren til noe annet og spør på denne istedet, og så ser jeg plutselig kontoen til naboen.

– Kan bli oppfattet som forstyrrende element

– Hvor utbredt er disse sårbarhetene – har du en kvalifisert gjetning?

– Tidligere vil jeg si vi fant sårbarheter som cross-site scripting i så mye som annenhver eller tredjehver applikasjon vi testet, sier Bjørstad.

– De senere årene har nok dette blitt litt bedre, uten at jeg har eksakte tall på det. Det er ganske vanlig med de nevnte sårbarhetene.

– Det er rett og slett fordi det å validere data som kommer inn, og eventuelt sørge for å kode det på en sånn måte at det ikke blir misforstått et annet sted i systemet, ofte ganske krevende – og det ser vi også forbedringer på. Men det er ikke alle som er klar over at dette er noe de må tenke på, sier Bjørstad.

– Det vi gjør er en kvalitetssikring at ting er gjort riktig og at sikkerhetshensyn er ivaretatt. Men det handler også om å forstå risikoen: «Okei, vi har funnet dette, her er det som kan gå galt.»

– Når du er ute og snakker med bedrifter og utviklere, hvordan oppfatter du interessen for og kompetansen på sikkerhet?

– De fleste utviklere syns jo at sikkerhet er et spennende tema. Det er varierende hvor mye tid og mulighet de har hatt til å sette seg inn i det. Det er gjerne slik at det alltid er noe annet som også haster, sier Bjørstad.

Bedriften har med andre ord kanskje noe å tjene på å sette av tid og budsjett på sikkerhet – slik at utviklerne får nok tid og mulighet til å sette seg inn i det.

– Baksiden ved å komme inn utenfra er at vi også kan bli oppfattet som et litt forstyrrende element – noe som kommer på toppen av alt annet de må bruke tid på, som er forståelig i en allerede tidspresset hverdag.

– Og hvis vi har blitt hyret inn for å gjøre en granskning er det nok aldri så veldig gøy å bli gransket. Det er litt som å gå til tannlegen, smiler Bjørstad.

– Det er viktig at vi sørger for at de de vi jobber med ikke opplever vårt arbeid som at vi prøver å ta eller henge ut noen. All programvare har bugs. Vi ønsker å oppdage og forstå sikkerhetsfeil i programvare, og bidra til å løse dem, presiserer Bjørstad.

– Vi har gjort sikkerhetsoppdrag fra nærmest enkeltpersonforetak til store, internasjonale konsern. Vi oppdager til dels store feil både i stort og smått, påpeker han også.

– Sluttresultatet langt der oppe er at de som er prosjektledere eller sikkerhetsansvarlig og så videre får oversikt over risikoene som er der, og mulighet til å prioritere tiltak og planlegge aktiviteter.

– På et mer teknisk nivå kan vi si vi har funnet dette og dette, her er våre vurderinger og anbefalinger. Så prøver vi å kommunisere det på alle nivåer.

Topp ti websårbarheter

– Hva bør bedrifter og særlig utviklere være ekstra obs på med tanke på applikasjonssikkerhet?

– Det finnes en liste over topp ti kjente websårbarheter. Open Web Application Security Project publiserer en liste over topp ti nettsårbarheter hvert tredje-fjerde år. Denne gir en grei oversikt over hva som er de viktigste områdene å være oppmerksom på, sier Bjørstad.

Open Web Application Security Project (OWASP) er et åpent og ikke-kommersielt

internasjonalt community som jobber med sikkerhet. OWASP publiserer nye lister over de ti vanligste websårbarhetene omtrent hvert fjerde år.

– Mnemonic var med å stifte OWASP Norge, og har deltatt helt siden oppstarten, og det siste året har jeg sittet i styret. Vi har jevnlige meetups med foredrag og faglig aktivitet, forteller Bjørstad.

Råd til bedriftens utviklere: – Spør om råd!

– Jeg vil også råde utviklere til å opprettholde knytingen mellom det tekniske og det funksjonelle. Du må være bevisst på kritikaliteten av det du driver med – det er stor forskjell på åpne data eller helseopplysninger.

– Hva er det verste som kunne skje? Det er viktig å ha dette tankesettet, sier Bjørstad.

Noe annet han mener er viktig for utviklere er å være kjent med i hvert fall de vanligste sårbarhetstypene og problemstlillingene som er relevante for de teknologiene man jobber med.

– En praksis som har fungert godt flere steder at man har en «security champion» i et utvikingsteam – en som ikke er fulltids-sikkerhetsekspert, men har en slags rådgiverrolle, og som både tenker sikkerhet i det daglige, men også har oversikt over hva man ikke vet – og vet å spørre om råd.

– For det er også et veldig viktig råd: Spør om råd! Om du er usikker på om det er noe det burde bli tatt hensyn til, er det bedre å ta den kvalitetssikringen tidlig, sier Bjørstad.

– I tillegg anbefaler jeg å følge med på sikkerhetsnyheter knyttet til de teknologiene og rammeverkene som man bruker, og å hele tiden være bevisst på hva som kan gå galt og muligheter for misbruk.

For bedrifter som ønsker å bygge opp et «software security program» internt på en mer strukturert måte, anbefaler Bjørstad det Creative Commons-lisensierte rammeverk BSIMM.

– For å lære mer om vanlige programvaresårbarheter, fins det flere sårbare applikasjoner som man kan sette opp og leke med, sier han.

Et par andre eksempler han trekker frem er OWASPsJavaScript-webapp Juice Shop, som er designet for å være usikker, samt Firing Range, hvor man kan teste sikkerhetsscanning for webapplikasjoner og avdekke sårbarheter.