Kompleksitet vs. Sikkerhet

På Cycon 2018 holdt Thomas Dullien en presentasjon om den stadig voksende kompleksiteten av datamaskiner i forbindelse med sikkerhet. Han hevdet at enhetsprodusenter har vesentlig endret den typiske produktutviklingssyklusen med sikte på å redusere <<time-to-market>>. Dette betyr at maskinvare- og programvareutvikling skjer nesten samtidig, mens integrering og testing starter tidligere og tidligere i prosessen. Det betyr også at hvordan vi løser tekniske utfordringer har endret seg dramatisk.

Dullien påpekte at historisk sett ville en enkel produksjonsoppgave kreve en enkel løsning, og en mer kompleks oppgave en mer kompleks (og dermed dyrere) løsning. Men i disse dager, med generelle CPUer, osv, heller produsenter og utviklere mot <<one-size-fits-all>> -løsninger. Via masseproduksjon er det nå billigere å kjøpe komplekse komponenter enn å utvikle den enkleste komponenten som gjør jobben.

Siden økt kompleksitet nesten ikke medfører noen merkostnad, kjøper vi komplekse komponenter med ekstra beregningskapasitet selv for de enkleste operasjonene – <<bare i tilfelle>>. Det er som å bestille en pizza og bli fortalt at du kan få pizza pluss ovnen til en lavere pris. For å få den beste avtalen, bestiller du pizza med ovn og kjøleskap – og ender opp med en samling av kjøleskap og ovner.

Kompleksitet har blitt et ubeskrivelig monster.

Men hva har dette å gjøre med sikkerhet?

Sikkerhet er per definisjon <<å være fri fra fare eller trussel>>. For å gjøre noe sikkert må vi forhindre og blokkere visse operasjoner, nemlig de som gjør systemet usikkert. I hovedsak begrenser sikkerheten handlinger og dermed kompleksitet. Å bestemme hva som skal begrenses har blitt mer utfordrende når kompleksiteten vokser. Det er en ting å begrense potensielle problemer med én pizza, men en helt annen utfordring for å sikre et hus fullt av pizzaovner.

Ta eksempelet IoT-enheter: En protokoll eller chip kan brukes til et bredt spekter av scenarier, trusselmiljøer og sikkerhetsmål. Å besvare spørsmålet <<er det sikkert?>> er umulig hvis vi ikke kan besvare spørsmålet <<hva betyr sikkerhet i denne sammenhengen?>> Med one-size-fits-all-computing vet vi vanligvis ikke brukskonteksten på forhånd.

Det er tydeligvis utfordringer fremover, og Dulliens presentasjon foreslår ingen løsning. Men han hevder at industrien omstrukturerer CPU-arkitekturen og den vil følgelig se annerledes ut om 15 år enn i dag – endringen vil være faktisk større enn de vi har sett innen CPU-arkitektur de siste 15 årene. Dette skaper en mulighet å vurdere sikkerhet samtidig med arkitektur. CPU-arkitektur påvirker maskinvare- og programvaresikkerhet, maskinvare- og programvare forsyningskjede problemer, maskinvarepålitelighet, og enhetsinspeksjon. Nå har vi en sjanse til å investere i forbedring av sikkerhet i disse områdene. Det som skjer nå vil definere datamaskiner og beregningsarkitektur for de kommende årene – og effektiviteten av sikkerhet.