Hvordan gjøre risikovurdering av IoT-anskaffelser?

Bloomberg kunne i mars i år avsløre et cyberangrep som ga hackere direkte tilgang til videostrømmer fra 150.000 internett-tilknyttede videokamera fra oppstartsselskapet Verkada. Angriperne har demonstrert at de har tilgang til direkte videostrømmer, lagrede opptak og til og med root-tilgang til operativsystemet i hvert kamera. Selskaper som er berørt omfatter ifølge Bloomberg blant annet Tesla, Cloudflare, sykehus, politistasjoner, fengsler og skoler.

Mye kan sies om dette, fra spørsmål om personvern ved overvåking av ansatte til spekulasjoner om Verkada sine sikkerhetsrutiner og generelle betraktninger rundt IoT. Men det er lett å være etterpåklok og peke på mulige feil etter at alt er eksponert. Men hva kan vi lære av dette? Et vel så interessant perspektiv kan være: hvordan risikovurderinger kan brukes som et verktøy for å sikre at beslutninger som fattes også tar hensyn til informasjonssikkerhetsrisiko.

La oss først gjøre en liten avklaring og begrensning: dette er ment som utgangspunkt for en faglig diskusjon om risikovurdering. Dette er ikke komplett, og det må heller ikke tolkes som en lærebok, det er mye jeg hopper over her. Med andre ord: ikke ta beslutninger om anskaffelse på bakgrunn av dette.

Så, med denne rammen, la oss sette i gang:

Verdivurdering

For det første må vi identifisere verdier som skal beskyttes. I utgangspunktet pleier det å være snakk om informasjon, og informasjonens konfidensialitet, integritet og tilgjengelighet. Informasjonen vi ønsker å beskytte i dette tilfellet inkluderer selvsagt alt man kan få tak i ved å se på video fra overvåkingssystemet (personopplysninger, forretningshemmeligheter, kanskje andre kategorier), videre er det informasjon om infrastrukturen dette overvåkingssystemet er en del av.

Når vi skal installere komponenter eller løsninger inn i vår infrastruktur er det også relevant å se på nettverkstilgang som en verdi/ressurs vi ønsker å skjerme.

Konsekvenser 

Neste punkt er å identifisere konsekvenser av brudd på informasjonssikkerheten. Konsekvensene vil henge tett sammen med verdiene vi har listet opp. Mye er åpenbart her: brudd på personvern, konkurransevridning og markedsmanipulasjon. Dette kan videre ha økonomiske eller juridiske konsekvenser, eller i verste fall konsekvenser for liv og helse.

Detaljene her er avhengig av konteksten.

Konsekvenser av tilgang til vår infrastruktur er mer interessant: At en angriper kan se innsiden av vårt nettverk kan ha store og alvorlige konsekvenser. En slik tilgang bryter sannsynligvis med antagelser som er gjort i design av egne sikkerhetsmekanismer, men det kan også ha følgefeil langt ut over systemet som er angrepet.

Et eksempel her: Cloudflare er et selskap som leverer tjenester for distribuert innholdslevering, sikkerhet og skalerbarhet. Det har blitt poengtert på Twitter at IP-adressen Cloudflare-kameraet var bak er i en blokk Cloudflare typisk ber brukere om å hviteliste. Det betyr at en angriper med tilgang til et kamera kan bruke dette til å gi seg ut for å være Cloudflare i noen sammenhenger. Hva betyr dette for Cloudflare? Hva betyr det for deres kunder? Hva betyr det for sluttbrukere (som i deres sammenheng er hele internett)?

Trusselscenarier

Neste steg i prosessen er opplisting av trusselscenarier. Et verktøy jeg finner nyttig for å identifisere scenarier er STRIDE. I en trusselmodell må det defineres en grense for hva som inngår i systemet. Det som er innenfor grensen er det man ønsker å beskytte, det som er utenfor er trusler. Når man setter ut forvaltning til en ekstern part må også ansatte hos denne, og eventuelle tredjeparter med tilgang til deres infrastruktur må også være med i trusselmodellen.

Scenariene handler om hvordan trusselaktører på utsiden av systemrammen bryter sikkerheten til verdiene på innsiden av rammen. Eksempler på slike scenarier her er:

• Påloggingsinformasjon på avveie (brukernavn/passord).
• Feil i autentiseringsmekanisme.
• Overvåking av trafikk inn og ut av systemet.
• Denial of service.

Sannsynlighet

Til slutt gjenstår å estimere sannsynlighet for ulike scenarier. Det har blitt påpekt at som kunde har man lite annet valg enn å stole på leverandøren, og, gitt at dette er en stor og anerkjent leverandør er det kanskje nærliggende å si at sannsynlighet er lav. Jeg vil påstå at det betyr man allerede har tatt en beslutning, og risikovurderingen er bare en papirøvelse.

Hvis man derimot vinkler dette litt annerledes vil risikovurderingen kunne være et grunnlag for å fatte en beslutning, men da må den lages på et tidspunkt hvor det faktisk er handlingsrom.

For eksempel: i stedet for å spørre "hva er risikoen ved å outsource system X til leverandør Y", må vi heller spørre:

• Hva er gevinsten ved å installere et overvåkingssystem?
• Hva er gevinsten ved at dette overvåkingssystemet er tilgjengelig over Internet?
• Hvilke alternative leverandører har vi?
• Hvis vi skal koble det til Internett, skal vi bruke vårt vanlige nettverk/IP adresserom eller skal vi anskaffe en helt separat forbindelse for dette? Hva er fordelen ved det første, hva er kostnaden ved det andre?

Basert på dette kan man skissere alternative løsninger basert på ulike leverandører eller ulike typer av leverandører og ulike måter å sette opp og integrere løsningene på.

Så kan man estimere konsekvenser, sannsynlighet og risiko for hver av disse alternative løsningene. Vi trenger ikke en absolutt skalering av risiko, bare en relativ skalering som gjør oss i stand til å sammenligne ulike alternativ. Hvilke scenarier er mest sannsynlige? Hvilke leverandører stoler vi mest på? Hvilke konsekvenser vil være mest alvorlige? Basert på dette kan man også designe og iverksette egne sikkerhetsmekanismer for å redusere konsekvensen av et innbrudd.

Konklusjon 

Vi må jo tro at de som velger å installere Internet-tilknyttet kameraovervåking ser noen gevinster de ønsker å oppnå. Hvis vi lister alternative løsninger og estimerer (relativ) risiko knyttet til hver av disse har beslutningstagere en reel mulighet til å veie funksjonalitet, gevinst, kostnad og risiko opp mot hverandre.

Det blir ofte sagt at store, profesjonelle leverandører av sky-tjenester er vel så sikre som å drifte systemer i sin egen kjeller. Dette er en vurdering som er avhengig av flere faktorer, men la oss ta det utgangspunktet her. En annen antagelse er at man er nødt til å stole på leverandøren. Det ligger en antagelse til grunn om at man ikke klarer å estimere sannsynligheten for scenariene man identifiserer i risikovurderingen. Konsekvensen av dette er at estimering av sannsynlighet i risikovurderingen ender på «lav».

Det er for så vidt sant hvis man er en storkiosk eller et legekontor, men ikke hvis man er Tesla eller Cloudflare. Disse virksomhetene har både kompetanse og ressurser som kreves for å stille harde krav til leverandører, og de kan gå mye lenger enn å lese "trust"-delen av nettsiden deres (ref: https://www.verkada.com/trust/). De kan kreve å få se risikovurderinger som er gjort, stille spørsmål ved sikkerhetsstyringsystemet (ISMS: Information Security Management System), kreve penetrasjonstester eller sårbarhetsscanning utført av tredjeparter eller kreve uavhengig revisjon av styringssystemene.

Hvis konsekvensene er store nok spille det egentlig heller ingen rolle hvor liten sannsynligheten er. Hvis det finnes scenarier som kan føre til store konsekvenser må man enten finne en måte å redusere konsekvensene eller skrinlegge prosjektet. For Cloudflare sin del vil hele deres forretningsmodell stå på spill hvis brannmurer rundt i verden slutter å hviteliste deres IP-adresser. Mon tro om de tok det med i vurderingen da de installerte kameraovervåking?

// Forsidebilde: Rob Sarmiento | www.unsplash.com