Av Richard Rostad, Promis Qualify
En cargo cult er som kjent når man legger stor innsats i å gjøre “alt” riktig uten at man får forventede resultater, ofte fordi man ikke har full forståelse eller oversikt over årsakssammenhenger. De originale cargo cult-ene oppstod ved at øybefolkninger etterapet amerikanske soldater i håp om at transportfly skulle komme med ‘cargo’. (Har forøvrig noen lagt merke til at når noe sendes over land med bil så heter det ship-ment mens når det sendes med lasteskip over havet så heter det car-go? Engelsk er et merkelig språk.)
Kan man dog kalle noe for en cargo cult når det ikke finnes noen som gjør det riktig og kan etterapes?
La oss se litt på moderne it-sikkerhet. Mellom 2003 og 2018 har det gått 15 år. Det er 15 år med forskning på sikkerhet, opplæring og bevisstgjøring av brukere vedrørende sikkerhet, implementering av mer teknisk sikkerhet, kryptering har blitt tilgjengelig for den allmenne sluttbruker og vi har endog fått en blank og fin ISO standard for sikkerhet som har gjennomgått to revisjoner (2005 og 2013) og stadig flere bedrifter og organisasjoner blir sertifisert etter ISO 27001.
Med andre ord skulle sikkerheten bli bedre og bedre.
La oss se på antallet dataelementer som har blitt stjålet i disse 15 årene. Grafen nedenfor omhandler naturlig nok de databruddene vi kjenner til slik at man kan forvente store mørketall, og det er også mange andre usikkerheter tilknyttet slik statistikk, men som en første approksimasjon kan man i hvert fall anta at selv med store usikkerheter så stemmer trenden:
Det ser ikke ut til at sikkerheten blir veldig mye bedre med tiden, på tross av all innsatsen.
La oss ta en kikk på en oversikt over ISO27001:
Dersom det ikke skulle gå umiddelbart frem av skissen hvilke elementer som har direkte innvirkning på det faktiske systemet vi ønsker å sikre, så har jeg tillatt meg å sette en rød ring rundt.
Resten av standarden går ut på at man skal definere en standard arbeidsprosedyre, revidere den prosedyren jevnlig, ha et system for å fange opp og dokumentere avvik fra prosedyren. På den annen side kan den prosedyren man gjerne følger være totalt ubrukelig og direkte ødeleggende for den faktiske sikkerheten.
Ute i den virkelige verden gir det seg stundom merkelige utslag; eksempelvis har jeg jobbet steder der jeg utarbeidet sikkerhetstestplaner, sikkerhetsarkitektur og prosedyrer, men der de ble hemmelighetsstemplet etter at jeg hadde levert dem fra meg slik at jeg ikke hadde lesetilgang. Ikke ofte man kommer over write-only tilgang. Akkurat i det tilfellet hadde det små konsekvenser da undertegnede har hukommelse god nok til å huske det jeg skriver i opptil flere sekunder, men man undrer seg jo litt over hvilke andre medarbeidere som kunne hatt nytte av den informasjonen.
Verre blir det når man behandler lister over kjente sårbarheter i biblioteker og rammeverk som særdeles begrenset informasjon; Angriperne kjenner allerede til slik informasjon, slik at hvis man begrenser tilgangen internt ender man opp med at de eneste man skjermer informasjonen for, er de utviklerne som kan hjelpe til med å utbedre sårbarhetene.
Ingen av disse handlingsmønstrene står imidlertid i veien for at man kan bli sertifisert etter ISO 27001. Noen ganger undrer jeg på om menneskeheten faktisk har kommet så langt at vi har nedfelt en Cargo Cult i en egen ISO standard?
Så hva kan man gjøre for å oppnå faktisk bedret sikkerhet?
- Lag mindre systemer
Små systemer er mer oversiktlige slik at problemer er mer synlige. Små systemer har også mindre angrepsflate, færre avhengigheter og er enklere å sikre. “Microservice: software small enough to fit in my head” – James Lewis (fritt etter gullfiskhukommelsen) - Opparbeid forståelse for god sikkerhetshygiene
Dagens leger vasker ikke hendene fordi de klikker gjennom håndvaskeinstrukser under nasjonal håndvaskemåned, de gjør det fordi de har skjønt årsakssammenhengen mellom hygiene og infeksjonsfrekvens. Likeledes gjør man ikke riktige sikkerhetsvalg som utvikler fordi man får mail med linker til instruksjoner om ikke å klikke på linker i mail hver oktober. - Og apropos utviklere; la utviklerne ta ansvar for egen applikasjonssikkerhet. Det er utviklerne som har mest direkteinnvirkning på sikkerheten til en applikasjon, og dermed utviklerne som bør opparbeide kompetanse og forståelse for emnet. Sikkerhet er ikke en egen disiplin med esoterisk kompetanse som skal skjermes fra omgivelsene.
- Bruk anti-personas og misbrukerhistorier
Mange i disse simidigdager er vant til brukerhistorier og personas på formatet “Som bruker A ønsker jeg X slik at jeg kan oppnå Y”. På samme måte kan vi lage historier for agenter som ikke ønsker å bruke systemet til et tiltenkt formål. Gi gjerne antipersonaene navn: “Som Kjell T. Ringen ønsker jeg å forfalske loggene slik at jeg kan stille urettmessige erstatningskrav”. Når utviklere, testere og andre i et prosjekt har vår venn Kjell og hans misbrukerbehov i bakhodet er det enklere å tenke sikkerhet under hele utviklingsløpet. - Bruk verktøy.
De aller fleste tekniske angrep skjer ved hjelp av automatiserte verktøy som analyserer et system for mulige sikkerhetshull. Det er ingen grunn til at slike verktøy skal være forbeholdt skurkene, men i dagens utviklingsløp settes det av lite tid og penger til denne typen analyser og tester. - PATCH
60% av alle vellykkede tekniske angrep skjer på grunn av en allerede kjent feil som det foreligger en fiks for. Gjennomsnittlig tid fra et sikkerhetshull fikses til det er implementert/ patchet hos en bedrift er 120 dager. Amazon AWS patcher på under 24 timer. Jeg har jobbet steder der man benytter seg av rammeverk og plattformer som ikke har blitt patchet på over 900 dager. Noen ganger går det galt. - Ta klare avgjørelser.
Det viktige med sikkerhetsarbeid er ikke hvilken av alternativene som velges, men at alle involverte har et bevisst forhold til valget. Stilt overfor en risiko kan man gjøre en av følgende:- Avoid – unngå sikkerhetshullet – kan vi klare oss uten denne funksjonaliteten?
- Mitigate – foreta grep som gjør funksjonaliteten sikrere – dette er det vanligste tiltaket
- Transfer – hvis man trenger sikker handel og ikke vil eksponere seg for risikoen med å lagre kredittkort, kan man bruke vipps og dermed overføre hele den risikoen til vipps
- Accept – aksepter at risikoen finnes og at det er mer kostbart å mitigere, enn konsekvensen dersom det skulle skje et sikkerhetsbrudd.
- Gjør sikkerhetsaktiviteter oftere
Et viktig moment i forbindelse med dev-ops er at hvis noe er vondt og vanskelig så gjør man det oftere og automatiserer det som kan automatiseres. Derfor bør man implementere sikkerhetsaktiviteter som en naturlig del av utviklingsprosessen slik at sikkerhetsarbeidet ikke blir en bremsekloss men hjelper til å dytte utviklingen raskere fremover - Test mer.
Et system som ikke fungerer som det burde og inneholder mange kjente og ukjente feil innehar også større sikkerhetsrisiko.
