IoT-sikkerhet del 3: Hvordan velge en sikker IoT-leverandør

Dette er tredje og siste artikkel av en serie i tre deler som gir en innføring i sikkerhetsaspekter ved IoT. Innleggene vil diskutere hva som er spesielt med akkurat dette, hva hovedutfordringene er og hvordan vi kan gjøre sikrere valg når vi investerer i IoT.

Vi fortsetter reisen i sikkerhetslandskapet til «Internet of Things» (IoT). I tilfelle du gikk glipp av første eller andre del av denne artikkelserien, kan det være lurt å gå tilbake og starte der. Vi har utforsket forskjeller og ulikheter mellom tradisjonell it-sikkerhet og IoT-sikkerhet, og sett hvordan mangfoldet av teknologi i kombinasjon med lite erfaring industrien, skaper sikkerhetsutfordringer.

Med hovedfokus på bedrifter skal vi nå se på hvordan vi gjøre en god og sikker investering i IoT likevel. Det finnes dessverre ingen joker vi kan dra opp av kortstokken, men det er mulig å sile ut en del leverandører hvis du vet hva du skal se etter.

I denne artikkelen trekker vi frem noen spørsmål du kan stille leverandøren. Hensikten er å avdekke problemer tidlig, og la de flinke elevene i klassen faktisk få differensiere seg på sikkerhet. Dette er bra for både bedriften din, og markedet generelt.

Var sikkerhet et tema under designfasen?

En effektiv måte å begynne utforskingen av en leverandørs sikkerhetsmessige ståsted, er å spørre om hvorvidt sikkerhet var påtenkt tidlig under designet av produktet. Får du en rimelig rask og tilfredsstillende respons på dette? Kanskje var spørsmålet overraskende for leverandøren, eller virket det forventet?

Spør gjerne etter dokumentasjon på designvalg og sikkerhetsmekanismer som er tatt i bruk. Hvis enheten for eksempel benytter kryptering, må også nøkkelhåndtering gjøres på en forsvarlig måte. Mindre erfarne leverandører kan se på sikkerhet som «nice-to-have»-funksjonalitet, noe man kan «legge til senere om nødvendig».

Vi vet jo at hvis sikkerheten ikke blir vurdert tidlig, kan det være umulig å sikre produktet i etterkant. En uttalelse av typen «vi oppdaterer softwaren på produktet for å inkludere sikkerhet» er et dårlig tegn både for produktets tilstand, og leverandørens generelle forståelse for kompleksiteten som er involvert.

Dersom leverandøren kan demonstrere at sikkerhet har blitt tatt seriøst fra starten, er dette åpenbart et veldig godt tegn, og burde gi konkurransefortrinn.

Hvordan passer produktet i en helhetlig sikkerhetsarkitektur?

Sikkerhet oppnås ikke med en enkelt hindring, men ved flere «lag» av hindringer. Disse er bygget opp av teknologier, prosesser og involvert personell. For eksempel kan enhetene beskytte data med sikker lagring, kryptert kommunikasjon til baksystemene, og i tillegg sørger brannmurer og andre systemer for at kun trafikk fra kjente kilder slipper til, og reagerer automatisk på oppførsel de anser som unormal.

Dette refereres til som dybdesikkerhet («defense in depth»), og illustreres under. En enkelt sikkerhetstjeneste, som autentisering, realiseres ved å kombinere ulike sikkerhetsfunksjoner på tvers av flere lag i arkitekturen. Produktet du vurderer å investere i vil mest sannsynlig spille en rolle i en større sammenheng, og spesielt hvis løsningen inkluderer mer enn bare endepunkter, for eksempel gatewayer og baksystemer, bør dette utforskes med leverandøren.

Hvis produktet benytter proprietære protokoller vokser arbeidsmengden med sikker integrasjon. Igjen vil ikke en detalj i programvaren sørge for sikkerheten, og dersom leverandøren eller din egen organisasjon ikke sitter på rett kompetanse, bør det vurderes å hente inn støtte fra en tredjepart.

Hvordan blir enhetene holdt oppdatert?

Diskuter med leverandøren hvordan programvaren på IoT-enhetene kan holdes oppdatert. Selv om sikkerhet ble inkludert i designet, finner man alltid sårbarheter i etterkant. Oppdateringer og «patcher» har som formål å løse disse, og har vist seg å være helt nødvendig i enhver it-arkitektur.

Det er et vanlig problem at flere IoT-enheter ikke kan oppdateres. Dette er et sikkerhetsproblem i stor skala, og du bør forsøke å unngå det ved å få på plass et regime for sikre, automatiske oppdateringer. En uttalelse du ikke ønsker fra leverandøren din er «enheten allerede er sikret og oppdateringer blir ikke nødvendig».

Du vet nå bedre, og ønsker kanskje at programvareoppdateringer skal være del av kontrakten. Kan leverandøren dokumentere hvordan oppdateringer gjøres på en forsvarlig måte? Hvordan sørger man for at oppdateringen er autentisk? Er den beskyttet med hensyn til integritet, eller kan utenforstående endringer gå uoppdaget? Hva utløser en oppdatering? Etabler en prosess for å håndtere sårbarheter som oppdages, eller få det med i kontrakten som del av tjenesten leverandøren har ansvar for.

Benytter leverandøren seg av standarder der dette er mulig?

Selv om det er få standarder som dominerer i selve IoT-feltet, er dette ingen unnskyldning for å ikke benytte seg av standarder der det går an. Standard protokoller er grundig testet og gjenbrukt, gjør produktet bedre rustet til å tåle fremtidige endringer i infrastrukturen, og reduserer den totale sikkerhetsrisikoen.

Spesielt viktig er det at leverandøren bruker anerkjente standarder for kryptering, og ikke forsøker å finne på sin egen. Kryptografi er vanskelig å gjøre riktig, også for kryptografer. Likevel ser vi stadig amatører gjøre det selv. Det er marginale feilsteg som skal til for at den hjemmesnekrede kryptoen kan knekkes.

Følger leverandøren generelt god sikkerhetspraksis?

Spør leverandøren om utviklerne er kurset innen sikker koding, og om det generelt er fokus på å unngå vanlige sikkerhetsfeller.

Et klassisk eksempel, som forekommer overraskende ofte, er at enheten har administrasjonspassordet liggende i klartekst, fritt tilgjengelig. Utviklerne bør ha kjennskap til typiske sårbarheter og prinsipper for å unngå slike feller som "IoT sikkerhetsveiledning", "Topp ti sårbarhetsoversikt" og sikker kodepraksis fra OWASP.

Hvis leverandøren er stor, og løsningen du vurderer å kjøpe er kompleks, er det sannsynligvis en del formelle prosesser på plass for programvareutviklingen. Spør hvorvidt de har en sikker utviklingslivssyklus på plass, som Microsoft SDL. En slik prosess sørger for at sikkerhet er en del av hele utviklingsløpet.

Det vil alltid finnes mangler å peke på, men en åpen diskusjon rundt disse temaene kan gi et verdifullt inntrykk av sikkerheten som helhet hos leverandøren.

Eksiterer leverandøren om ti år?

Tingenes internett er i en modningsprosess som forårsaker raske forandringer i markedet. Dette skaper vinnere og tapere, og konsekvensen ved å ha investert tungt i en leverandør som går konkurs kan være vesentlig. Det kan bety slutten på sikkerhetspatcher, reparasjoner og kundeservice.

Sørg for at du har nok tillit til leverandørens helhetlige ståsted i markedet. Og siden enhetene mest sannsynlig ikke vil leve evig, få også på plass en strategi for å håndtere avvikling av IoT-produktene.

Ta sikkehet på alvor

Vi kan lære mye av å spørre ut leverandørene om sikkerhet. Idéen er ikke at løsningen må være sikkerhetsmessig vanntett, men at du velger en leverandør som har tatt sikkerhet seriøst fra et tidlig tidspunkt. Svarene du får på spørsmålene nevnt i denne artikkelen, vil sende deg langt i riktig retning.

Er du i tvil kan en tredjeparts vurdering være en god idé, primært for å identifisere risikoen du er eksponert for, hvordan du bør håndtere den og hvilke IoT-løsninger som passer inn i din sikkerhetsstrategi.