Enisa – European Network and Information Security Agency – har publisert et utspill for bedre sikkerhet i distribusjonen av applikasjoner til mobiltelefoner: Appstore security: 5 lines of defence against malware (pdf, 20 sider).
De peker på at det innen 2013 vil være flere avanserte mobiltelefoner i bruk enn pc-er, og at mobiltelefoner vil bli det typiske apparatet for å ta i bruk nettjenester. Det vil nødvendigvis tiltrekke svindleres oppmerksomhet, og mobilapplikasjoner risikerer å bli en sikkerhetsbyll.
Enisa analyserer sikkerhetsutfordringer knyttet til distribusjon av mobilapplikasjoner med utgangspunkt i en modell av et «app ecosystem» med prosesserer, aktører, kontroller og distribusjonsmetoder tilsvarende det man finner i iPhone Appstore, Android Marketplace og Mozilla Addons. I grove trekk er det tre roller – utvikler, kontrollør og bruker – som forholder seg til hverandre gjennom et titalls prosesser fra utvikleren søker om å få legge ut en applikasjon eller en oppdatering til applikasjonen kjører på brukerens apparat.
Sikkerhetsutfordringene i denne modellen analyseres på grunnlag av Microsofts STRIDE-metode, der trusler klassifiseres i seks kategorier: «spoofing» (ID-kapring), «tampering» (sabotasje av prosesser, dataflyt eller data), «repudiation» (utvisking av spor etter handling knyttet til en prosess eller til en rolle), «information disclosure» (lekkasje av følsomme data), «denial of service» (overbelastning som gjør normal bruk umulig) og «elevation of privilege» (uvedkommende skaffer seg rettigheter på urettmessig vis).
Analysen munner ut i fem typer krav til distribusjon av mobilapplikasjoner:
1. Kontroll av applikasjoner
Enisa krever kontroll for å hindre risikoen for at ondsinnede eller usikre applikasjoner legges ut i app-butikkene, og at butikkene selv tar ansvar for denne kontrollen. EU-organet peker på at deler av kodekontrollen kan automatiseres, og at man bør ty til manuell kontroll der applikasjonen har spesielt følsom funksjonalitet. Det må etableres pålitelige rutiner for å sikre at utviklere ikke kan legge tilby applikasjoner under falsk identitet. Oppdateringer må prioriteres slik at sårbarhetsfikser raskt når ut til brukerne.
2. Synliggjøring av utvikleres og applikasjoners rykte
Poenget med dette er å gi brukere innsyn i hva slags opplevelser andre har med en gitt applikasjon eller med andre applikasjoner fra en gitt utvikler. Enisa krever at rapporteringsmekanismen må skille mellom vanlig funksjonalitet på den ene siden, og sikkerhet og personvern på den andre. Hvis en applikasjon fungerer tilfredsstillende, men ber om tilgang til for eksempel personopplysninger den ikke har bruk for, bør informasjon om dette være tilgjengelig før applikasjonen lastes ned og eventuelt betales for.
Enisa understreker at selve ryktemekanismen må vernes, slik at en angriper som har lyktes i å plassere en tvilsom applikasjon, ikke kan dekke seg bak et antall falske identiteter for å gi applikasjonen et godt rykte.
3. Tilbakekalling av applikasjoner
Enisa mener at plattformer for smarte mobiltelefoner bør gjøre det mulig for app-butikker å avinstallere applikasjoner fra brukernes apparater. Det skal kunne skje på initiativ fra både mobiltelefonleverandøren og app-butikken selv. Det ligger i dette en åpenbar mulighet for misbruk. Enisa balanserer derfor dette kravet med at brukere må informeres på forhånd, og gis anledning til å beholde applikasjonen dersom det ikke er til skade for andre.
Enisa peker på at det kan være situasjoner der adgangen til å fjernavinstallere en mobilapplikasjon bør fjernes helt, slik at en organisasjon som gjør seg avhengig av en bestemt applikasjon, ikke risikerer å oppleve at den plutselig gjøres utilgjengelig.
4. Sikkerhetskrav til mobiltelefonen
Her foreslår Enisa en rekke krav:
- Mobiltelefoner skal bare kunne godta sertifiserte (signerte) applikasjoner.
- Applikasjoner skal kjøres isolert fra hverandre, det vil si i «sandkasser».
- Applikasjoner skal kjøres med minimalt med privilegier. Det skal være mulig for en bruker å godkjenne unntakstilfeller.
- Applikasjoner skal overvåkes av systemprogramvaren under kjøring, og brukeren skal ha tilgang til rapporter om hva en applikasjon faktisk gjør.
- Avinstallering må fjerne alle spor etter en applikasjon. Det skal ikke være mulig å lage «rootkits».
5. Begrensede brukerrettigheter
Utredningen drøfter dette tiltaket under overskriften «Jails or walled gardens». Hensikten er å hindre situasjoner der kode smitter fra nettsted til leser. I pc-verden kan man oppnå dette ved å skille mellom vanlig bruker og admin-bruker, altså en bruker med fulle rettigheter, og sørge for ikke å oppsøke nettsteder som admin-bruker. Da vil ethvert forsøk på å installere kode utløse et krav om admin-brukernavn og passord. Enisa foreslår at operativsystemet enten hindrer installasjon av applikasjoner fra annet enn tillatte og navngitte app-butikker, eller utsteder en advarsel i det man er i ferd med å installere en applikasjon fra en tjeneste som ikke står på en liste over anerkjente app-butikker.
Disse alternativene gir svært ulike muligheter til brukeren, og Enisa lister flere alternative modeller for å håndheve og styre begrensningene som pålegges brukeren i sikkerhetens navn. Et alternativ er at app-butikker går sammen om en felles sertifiseringsordning og at alle sertifiserte app-butikker godtas. Et annet, egnet for bedriftsbrukere, er at bare applikasjoner fra bedriftens egen app-butikk kan installeres. De øvrige alternativene er varianter av disse temaene, og avslører at Enisas appell til bransjen om kreative bidrag til å løse sikkerhetsproblemer rundt mobilapplikasjoner er alvorlig ment: Rapporten er et utgangspunkt for diskusjon. Det er langt igjen før faste og hensiktsmessige retningslinjer vil kunne formuleres.
Dokumentet er ikke gjenstand for høring, men Enisa vil sikkert være takknemlig for tilbakemeldinger.
