Slik bygger du en sikker app for bedriften

Isometrisk fremstilling av appens sikkerhetsstruktur

En sikker app får ikke sikkerheten lagt på helt til slutt. Den er planlagt, kodet, testet og vedlikeholdt med sikkerhet som krav i hver fase, fra du bestemmer hva appen skal gjøre til den en dag skal fases ut. Det er også slik Nasjonal sikkerhetsmyndighet anbefaler at virksomheter jobber: en sikker utviklingsmetode, testing gjennom hele prosessen og forvaltning med sikkerhetsoppdateringer etter lansering. Her får du stegene i riktig rekkefølge, hva du bør kreve av dem som bygger appen, og hva som må være på plass når den først er ute hos brukerne.

Kort oppsummert

Avklar personopplysninger, regelverk og risiko før utviklingen starter, ikke når appen nesten er ferdig.
Bygg sikkerheten inn i design og kode: trusselmodellering, kodegjennomgang, kryptering og minst mulig tilgang.
Test underveis, og ta en penetrasjonstest før appen settes i produksjon.
Planlegg driften fra første dag: sikkerhetsoppdateringer, overvåking og en plan for hendelser.
Å rette sikkerhetsfeil i etterkant koster som regel mer enn å gjøre jobben riktig fra start.

Innholdsfortegnelse

Hva skiller en sikker app fra en vanlig app?
Før første kodelinje: krav, personvern og risiko
Sikkerhet i design og koding
Slik tester du appen før lansering
Etter lansering: oppdateringer, overvåking og hendelser
Når noen andre bygger appen for deg
Hva koster det å lage en sikker app?
Slik ser vi det
Bygg og test appen med de samme fagfolkene
Ofte stilte spørsmål
Kilder

Hva skiller en sikker app fra en vanlig app?

For brukeren ser en sikker app ofte helt lik ut som en usikker. Forskjellen ligger i hvordan den håndterer innlogging, lagrer data, snakker med serveren og reagerer når noen prøver å misbruke den. Det er de delene som avgjør om en kundedatabase lekker, om en ansatt får tilgang til mer enn hen trenger, eller om en angriper kan endre en pris i handlekurven.

NSM beskriver tre kjennetegn: appen er utviklet etter en sikker metode, den er testet gjennom hele utviklingen, og den forvaltes med sikkerhetsoppdateringer. NSM anbefaler også at sikkerhet er med i hele livsløpet, fra anskaffelse til avhending. Det betyr at du må tenke på hvordan data slettes når appen en dag legges ned, like mye som på hvordan brukerne logger inn i dag.

For mobilapper finnes det en felles kravliste mange bruker som målestokk. OWASP MASVS er bransjestandarden for sikkerhet i mobilapper, og den brukes både av utviklere som skal bygge sikre apper og av testere som skal kontrollere dem. Standarden deler kravene inn i områder som lagring, kryptografi, autentisering, nettverk, plattformbruk, kode og personvern. Den egner seg godt som vedlegg til en avtale, fordi den gjør “sikker” til noe målbart.

Sju områder i OWASP MASVS for mobilapper

For bedriften som helhet er NSMs grunnprinsipper for IKT-sikkerhet det naturlige rammeverket. Appen er bare én del av IKT-miljøet, og den er aldri sikrere enn serverne, skytjenestene og kontoene den henger sammen med.

Før første kodelinje: krav, personvern og risiko

De dyreste sikkerhetsfeilene oppstår ofte før noen har skrevet kode. En app som samler inn mer data enn den trenger, eller som er designet uten tanke på hvem som skal ha tilgang til hva, blir vanskelig å rette opp senere. Datatilsynets veileder om programvareutvikling med innebygd personvern peker på hva som bør være avklart før utviklingen starter:

Hvilke personopplysninger appen skal behandle. Navn, e-post, lokasjon, betalingsinformasjon, bilder eller helseopplysninger gir svært ulike krav.
Behandlingsgrunnlag og formål. Hvorfor samler dere inn dataene, og med hvilken rett? Svaret styrer hva appen får lov til å lagre.
Hvilke sektorregler som gjelder. En app for en klinikk, en bank eller et borettslag kan ha regler utover personvernforordningen.
Sikkerhetsrisikovurdering og behovet for DPIA. En vurdering av personvernkonsekvenser kan være påkrevd når behandlingen innebærer høy risiko for brukerne.
Toleransenivåer for risiko. Virksomheten bør bestemme på forhånd hvilken risiko den kan akseptere for sikkerhet og personvern.

Det siste punktet glemmes ofte, men det er avgjørende. Datatilsynets sjekkliste for krav understreker at toleransenivåene definerer hva som er akseptabel risiko i programvaren. Uten et slikt nivå har utviklerne ingen fasit når de må velge mellom en rask løsning og en trygg løsning.

Bruker de ansatte appen på jobbtelefoner, kommer en vurdering til. I NSMs temarapport om mobilapplikasjoner for tjenesteenheter anbefaler NSM sterkt at alle virksomheter gjør en overordnet risikovurdering for bruk av mobile enheter og applikasjoner, enten de bruker flåtestyring eller ikke.

Et eksempel: Et regnskapsbyrå i Bergen vil la kundene laste opp bilag fra mobilen. Allerede i planleggingen må byrået vite at bilagene kan inneholde personopplysninger om kundenes ansatte, hvor lenge de skal oppbevares, hvem i byrået som skal se dem, og hva som skjer hvis en telefon med appen blir borte. Svarene blir krav til innlogging, lagring og sletting. Trenger du hjelp med denne delen, er det det vi jobber med under risiko og regler.

Sikkerhet i design og koding

Når kravene er klare, skal de bli til arkitektur og kode. NSM og Datatilsynet peker på mange av de samme tiltakene, og de henger sammen.

Trusselmodellering før design

Trusselmodellering betyr å gå systematisk gjennom hvordan appen kan angripes: Hvem vil ha tak i dataene? Hvor går dataene? Hva skjer hvis noen manipulerer en forespørsel til serveren? NSM anbefaler trusselmodellering som en fast del av utviklingen. Gjort tidlig gir den utviklerne en liste over hva koden må tåle.

Velg verktøy og komponenter med omhu

En moderne app består i stor grad av tredjepartskomponenter: rammeverk, biblioteker, SDK-er for betaling, analyse og varsler. NSM anbefaler å bruke godkjente verktøy og rammeverk, å deaktivere utrygge funksjoner og moduler, og å velge moderne, oppdatert programvare med nyere sikkerhetsfunksjonalitet innebygd. I praksis betyr det en oversikt over hvilke komponenter appen bruker, og en rutine for å oppdatere dem når det kommer sikkerhetsfikser.

Tilgang og innlogging

Datatilsynets sjekkliste anbefaler at tilgangskontroll bygger på prinsippet om minste privilegium, og at administratorrettigheter gis til et begrenset antall personer. For en bedriftsapp betyr det at en vanlig bruker bare ser sine egne data, at serveren sjekker rettigheter på hver forespørsel, og at administratorpanelet ikke er åpent for alle med en konto.

Data på telefonen

Data som lagres lokalt på en mobil, er mer utsatt enn mange tror. Virksomheter bør forutsette at lokalt lagrede data kan nås av andre apper, og derfor bruke anerkjente krypteringsalgoritmer. Den beste beskyttelsen er likevel å ikke lagre mer enn nødvendig. Datatilsynet krever dataminimering, og det gjør appen både tryggere og enklere å forvalte.

Personvernvennlige standardinnstillinger

Ifølge Datatilsynet skal programvare ha standardinnstillinger som ivaretar brukernes personvern, for eksempel at stedstjenester er slått av som standard. Brukeren skal aktivt slå på det som deler mer data. NSM peker i tillegg på at trådløse teknologier som Bluetooth og NFC kan utnyttes til sporing og utilsiktet informasjonsdeling. Bruker appen slike funksjoner, bør de være begrunnet og avgrenset.

Kodegjennomgang og statisk analyse

NSM anbefaler statisk kodeanalyse og regelmessige kodegjennomganger. Statisk analyse er verktøy som leser koden og flagger kjente feilmønstre, som usikker håndtering av input eller hardkodede passord. Kodegjennomgang er et menneske med sikkerhetskompetanse som leser kritiske deler og stiller spørsmålene et verktøy ikke stiller. Begge deler hører hjemme i hver utviklingsrunde, ikke bare før lansering. Vi gjør dette som en del av sikker utvikling og kodegjennomgang.

Slik tester du appen før lansering

Sikkerhetstesting er ikke én test, men flere lag som fanger ulike feil. NSM anbefaler at testingen skjer gjennom hele utviklingen og omfatter disse testtypene:

Testtype	Hva den avdekker
Enhetstest	Feil i enkeltfunksjoner, for eksempel validering av input
Integrasjonstest	Feil i samspillet mellom appen, serveren og tredjepartstjenester
Systemtest	Om hele løsningen oppfyller sikkerhetskravene
Akseptansetest	Om løsningen er god nok til at virksomheten kan godkjenne den
Pilottest	Problemer som først dukker opp hos ekte brukere i liten skala
Inntrengingstest	Sårbarheter en angriper kan utnytte i praksis
Stresstest	Hvordan appen oppfører seg under stor belastning

Digitaliseringsdirektoratets prosjektveiviser om informasjonssikkerhet og personvern beskriver sikkerhetstesting som tester av funksjonelle krav, risikobaserte krav, sårbarhetstester og penetrasjonstester. Den slår også fast at testene skal bruke syntetiske personopplysninger. Ekte kundedata hører ikke hjemme i et testmiljø.

Tre ting gjør testingen mer verdt:

Separate miljøer. NSM anbefaler egne miljøer for utvikling, test og produksjon, slik at en feil i testen aldri rammer ekte brukere.
Tilpasset metode. Digitaliseringsdirektoratet påpeker at testmetodikken må passe både utviklingsmetoden og om produktet er egenutviklet eller kjøpt inn.
Retting før lansering. Feil og sårbarheter skal rettes før idriftsetting, ikke legges på en liste for “neste versjon”.

Den siste kontrollen før appen går ut, er en penetrasjonstest der en fagperson angriper appen og API-et slik en reell angriper ville gjort. Les mer om hvordan vi gjennomfører en sikkerhetstest av app og systemer.

Etter lansering: oppdateringer, overvåking og hendelser

En app er aldri ferdig. Nye sårbarheter blir kjent i biblioteker, operativsystemer endrer seg, og angripere prøver nye metoder. NSM anbefaler at programvaren forvaltes sikkerhetsmessig, med planlagte og distribuerte sikkerhetsoppdateringer. Når driften er satt bort, bør virksomheten sørge for sikkerhetsovervåking, rutiner for hendelseshåndtering og rapportering av avvik.

Datatilsynet anbefaler at det i overgangen til produksjon lages en plan for hendelseshåndtering og gjøres en full sikkerhetsgjennomgang av programvaren. Sjekklisten deres legger også vekt på at løsningen må kunne gjenopprette tilgangen til personopplysninger i tide etter en hendelse. Det krever backup som faktisk er testet.

En enkel driftsplan for en bedriftsapp bør svare på dette:

Hvem varsles hvis noe går galt, og hvem tar beslutninger?
Hvor ofte oppdateres komponenter og avhengigheter?
Hva logges, og hvem ser på loggene?
Hvordan gjenopprettes data, og hvor lang tid tar det?
Hvor kan eksterne melde fra om sårbarheter? Mange virksomheter har en egen side for dette, slik vi har med ansvarlig varsling.

Rydd også på jobbtelefonene. NSM anbefaler å avinstallere apper som ikke er i bruk og slette tilhørende data, fordi hver ubrukt app er en del av angrepsflaten. Appen henger dessuten ofte sammen med skytjenester og e-post, og der finner vi mange av svakhetene i praksis. Vi går gjennom slike miljøer under sikker sky og e-post.

Når noen andre bygger appen for deg

De fleste små og mellomstore bedrifter kjøper appen av et utviklingsmiljø. Ansvaret for dataene forsvinner likevel ikke ut av huset. NSM anbefaler derfor å integrere sikkerhet i selve anskaffelsen, slik at kravene står i avtalen og ikke kommer som en overraskelse i siste fase.

Disse spørsmålene bør du stille før du signerer:

Spørsmål til leverandøren	Hvorfor det betyr noe
Hvilken sikker utviklingsmetode bruker dere?	Viser om sikkerhet er en fast rutine eller noe som skjer tilfeldig
Gjør dere trusselmodellering og kodegjennomgang?	Fanger designfeil og kodefeil før testing
Hvilken standard tester dere mot?	Gjør “sikker” målbart, for eksempel mot OWASP MASVS
Er penetrasjonstest inkludert før lansering?	Avdekker sårbarheter en angriper kan utnytte
Hvem retter funnene, og når?	En rapport uten retting gjør ikke appen tryggere
Hvordan håndteres oppdateringer og hendelser etter lansering?	Sårbarheter dukker opp også etter at appen er levert

En leverandør som tar sikkerhet på alvor, beskriver gjerne åpent hvordan den beskytter kundenes data. Det gjelder særlig når appen skal håndtere sensitive opplysninger, som i helsesektoren. Se for eksempel hvordan en tjenesteleverandør presenterer sin beskyttelse av sensitive data overfor kundene: tydelige svar på slike spørsmål er et godt tegn når du skal velge hvem som skal bygge appen din.

Hva koster det å lage en sikker app?

Prisen på en app avhenger av omfanget, og derfor gir seriøse leverandører et estimat først når de vet hva appen skal gjøre. Disse faktorene påvirker prisen mest:

Plattformer: Bare iOS, bare Android, begge, eller en webapp i tillegg.
Innlogging og roller: Enkel innlogging er rimeligere enn flere brukerroller med ulike rettigheter.
Integrasjoner: Kobling mot regnskap, betaling, CRM eller interne systemer gir mer arbeid og flere ting som må sikres.
Type data: Sensitive opplysninger krever strengere tiltak og eventuelt en DPIA.
Testomfang: Hvor grundig penetrasjonstesten skal være, og om API og backend er med.
Drift: Avtale om oppdateringer, overvåking og hendelseshåndtering etter lansering.

Det viktigste regnestykket er likevel dette: NSM påpeker at det ofte koster mer å rette sikkerhetsmangler i etterkant enn å forberede seg godt. Be derfor om et tilbud der sikkerhetstest, retting av funn og vedlikehold står som egne linjer, så du ser hele kostnaden og ikke bare byggeprisen.

Slik ser vi det

Vi ser det samme mønsteret igjen og igjen: appen blir bygget, så blir den testet, og så kommer en teknisk rapport som ingen i ledelsen helt forstår. Funnene havner i en skuff, og appen går i produksjon med de samme hullene.

Derfor jobber vi annerledes. Når vi bygger en app, er sikkerheten med fra første møte, ikke en post på slutten av prosjektet. Når vi tester, gir vi ledelsen en kort oppsummering på vanlig norsk: hva som er funnet, hva det betyr for bedriften, og hva som må gjøres. Og så retter vi hullene selv, i stedet for å overlate det til noen andre.

For små og mellomstore bedrifter uten egen IT-avdeling er dette det som gjør forskjellen. Du trenger ikke en tykk rapport. Du trenger en app som er trygg, og noen som tar ansvar for at den blir det. Hos oss snakker du direkte med fagpersonen som gjør jobben, uten mellomledd eller selgere.

Sejad

Bygg og test appen med de samme fagfolkene

Vi utvikler mobil- og webapper med sikkerheten bygget inn fra starten, og vi tester og retter dem selv. Du får konkrete anbefalinger, en oppsummering ledelsen forstår, og direkte kontakt med fagpersonen som gjør jobben. Se hva vi kan bygge for deg under utvikling av apper og systemer.

Clevo

Har dere allerede en app, eller er en leverandør i gang med å bygge den? Da kan vi gå gjennom koden og teste løsningen før den går ut til kundene. Start med en sikkerhetstest av appen, så får du vite hvor dere står og hva som må til.

Ofte stilte spørsmål

Hvor mye koster det å lage en app?

Det avhenger av plattformer, funksjoner, integrasjoner og hvor sensitive data appen skal håndtere. En enkel app med få skjermer og ingen integrasjoner koster langt mindre enn en app med flere brukerroller og kobling mot interne systemer. Be om et tilbud der sikkerhetstest og vedlikehold er tatt med, så unngår du dyre overraskelser senere.

Kan jeg lage min egen app uten å kunne kode?

Det finnes verktøy som lar deg sette sammen enkle apper uten kode. Så snart appen skal behandle kundedata eller kobles mot bedriftens systemer, gjelder de samme kravene til personvern, tilgangsstyring og testing som for enhver annen app. Da lønner det seg å la fagfolk med sikkerhetskompetanse bygge og teste løsningen.

Trenger appen en penetrasjonstest før lansering?

Ja, hvis appen håndterer personopplysninger, betaling eller tilgang til bedriftens systemer. NSM regner inntrengingstest som en del av testingen før idriftsetting, og feil som blir funnet, skal rettes før appen går i produksjon. En penetrasjonstest viser hvilke svakheter en angriper faktisk kan utnytte.

Hva betyr innebygd personvern i en app?

Innebygd personvern betyr at personvernet er planlagt og bygget inn gjennom hele utviklingen, ikke lagt til etterpå. I praksis handler det om å samle inn minst mulig data, ha personvernvennlige standardinnstillinger og begrense hvem som har tilgang. Datatilsynet har en egen veileder for utviklere om hvordan dette gjøres.