Sannsynlighetsberegning - et uungåelig onde?

Jeg har tidligere skrevet om risikohåndtering som en del av cybersikkerhet (1,2), og er blant dem som mener at å beregne sannsynlighet for visse typer cyberangrep ikke bare er meningløst, det er direkte farlig.

Jeg fikk dessverre ikke anledning til å overvære FFIs fremleggelse av sin rapport "Tilnærminger til risikoanalyse for tilsiktede uønskede handlinger", men jeg har diskutert dette tema med flere av forskerne ved FFI. Jeg har selv brukt både kvantitative og kvalitative metoder for risikovurderinger, og kjenner godt til hva det innebærer å bruke sannsynlighetsvurderinger i det arbeidet.

Det var derfor med interesse at jeg leste Lillian Røstads (Difi) innlegg om dette på digi.no (3). Jeg er imidlertid ikke enig i alt hun skriver, og denne blogposten skal forklare hvorfor. Kort merknad til hvorfor jeg svarer her, og ikke i kommentarfeltet på digi.no: Jeg ønsker å samle denne type argumentasjon på ett sted for fremtidig bruk, samt at jeg kan legge til figurer her.

Først til det vi er enige om. 

Begrepsbruken innen cybersikkerhet er preget både av at språket vårt er fattig i forhold til engelsk, og at ord or uttrykk ikke har et meningsinnhold som alle er enige om. Et klassisk eksempel er hvordan enkelte blander sammen begrepene trussel og sårbarhet. En skulle tro at så sentrale begreper ble brukt riktig, men det gjøre de ikke. Sannsynlighet er et annet slikt begrep som dessverre blir tillagt ulikt meningsinnhold av ulike mennesker og miljøer. 

Matematisk sannsynlighet og statistikk en én type sannsynlighetsberegning som brukes innen cybersikkerhet. Det kan enten være for å angi hvor hyppig en hendelse forekommer, eller hvor stor sannsynlighet det er for at den skal oppstå én gang. Denne type sannsynlighetsberegning er en del av de kvantitative metodene som gjerne også inkluderer beregninger for hvor mange hendelser en kan tåle før kostnadene blir for store, hvor dyre mottiltakene kan være osv. Det var flere presentasjoner på RSA 2015 som viste at disse metodene blir brukt innen finans og forsikringsbransjen. 

En annen type sannsynlighetsangivelse er de subjektive. Ekspertene vurderer subjektivt hvor sannsynlig det er at noe skal skje, og tilordner en verdi. Høy sannsynlighet.  75%. Tallverdi 4 (av 5). Fargen Gul. Disse verdiene er ofte basert på ekspertens gut-feeling, og jeg har vanskelig for å tro at de er særlig treffsikre for fremtiden. Dette gjelder spesielt for det FFI sin rapport omhandler, nemlig tilsiktede uønskede handliger. Å bruke fortidens erfaringer til å spå om fremtiden, er en dårlig idé om man skal tro Nassim Nicholas Taleb i sin bok om "low probability, high impact events" (4). Spesielt når det er snakk om målrettede angrep i komplekse adaptive systemer. Og det er det jo. 

Vi må rydde opp i begrepsbruken, der er vi helt enige.

På engelsk skiller man mellom probable (sannsynlig) og likely (trolig/mulig). Selv om det ikke alltid er klokt å innføre nye begreper i et allerede "begrepsforvirret" område, tror jeg at vi ville ha nytte av å skille tydeligere på dette på norsk.

En annen ting vi er enige om er at cybersikkerhet ikke må eksistere på "sin egen planet". Hvis cybersikkerhet ikke blir integrert i virksomheten, så feiler de ansvarlige. En virksomhet har mange typer risiki, og risiko i mot den delen av virksomheten som skjer ved hjelp av IKT kan selvfølgelig ikke adskilles fra virksomhetens totale risikostyring. Dette er ekstremt viktig fordi tilsynelatende riktige og viktige cybersikkerhetstiltak kan direkte motvirke virksomhetens behov på andre områder. De fleste som driver profesjonelt med cybersikkerhet vet dette. 

... men så blir vi uenige

Når Røstad beskriver risikotrekanten Verdi, Trussel, Sårbarhet, spør hun om ikke det bare er en annen måte å angi sannsynlighet på. Jeg mener at det ikke er det.

Allerede i 2003 innså det fremste informasjonssikkerhetsmiljøet i Forsvaret at den tradisjonelle (kvantitative) metoden for risikoanalyser ikke var egnet for å beskrive den reelle risikoen mot de IKT-løsningene som blir brukt i militære opersjoner. En ROS-analyse med risikokvadranter og det hele var et klassisk eksempel på at subjektive (sannsynlighets) vurderinger ble dyttet inn i en beregningsmodell som var laget for et helt annet formål. Resultatene kunne ikke brukes inn i de øvrige risikovurderingene, og sjefene forsto ikke det som ble forsøkt formidlet. Informasjonssikkerheten levde på sin egen planet.

Da vi startet opp med å vurdere risiko etter den nye metoden, lykkes vi med å formidle risiko til ledelsen slik at de kunne vurdere denne risikoen opp mot øvrige risiki mot sin avdeling og sitt oppdrag. Tiltakene kunne vurderes opp mot den operative konteksten, og han fikk økt sitt handlingsrom ved å kunne velge tiltak som normalt ligger utenfor området "cybersikkerhet". 

Jeg velger å fremstille risikotrekanten som overlappende sirkler. Den eneste reelle risiko er i skjæringspunktet mellom verdi, trussel og sårbarhet. Hvordan bruker vi denne metoden?

Verdivurdering

En slik risikovurdering begynner alltid med verdivurderingen. Denne gjennomføres sammen med lederen for virksomheten, eller en som har inngående kjennskap til virksomheten. Vi gjennomfører et halvveis strukturert intervju, der vi stiller spørsmål som: Hva er formålet med denne virksomheten? Hva er oppdraget? Hvilke ressurser/enheter har du for å løse oppdraget? Hvem er dine overordnede? Hvilket konsept for ledelse har de overfor deg? Hvilket konsept for ledelse har du overfor dine underlagte enheter? Mot slutten av intervjuet kommer vi inn på spøsmål som: Hvilken informasjon er du avhengig av for å ta beslutninger? Hvilken informasjon er det kritisk av du får formidlet til dine underlagte enheter? Hvilke systemer er bærer/behandler for denne informasjonen? Hva vil skje med opdraget dersom noen slår ut eller manipulerer de mest kritiske IT systemene?

Denne samtalen er viktig av flere grunner. For det første må risikoanalytikeren forstå virksomheten han skal vurdere. Det er ikke nok at han kjenner det tekniske godt, han må også vite hva formålet med virksomheten er og hvilke kortsiktige og langsiktige mål den har. Dette er viktig både for risikofastsettelsen og for å vurdere hvilke tiltak som er hensiktsmessige.

For det andre skaper denne samtalen er felles forståelse for hva som er det mest viktige, og hva konsekvensene kan være dersom noen angriper de kritiske IT systemene.

Samtalen er også grunnlaget for å utarbeide det kritiske informasjonsbehovet i forkant av sårbarhetsvurderingen.

Sårbarhetsvurdering

Så langt det er mulig gjør vi tekniske målinger eller penetrasjonstestinger. Generelt vil vi vite om den kritiske IT-løsningen inneholder de komponenter, tjenester og systemer det skal, eller om noen har plassert inn noe som ikke skal være der. Dernest vil vi vite om det som verdivurderingen har fastsatt som kritisk har sårbarheter. I Forsvaret måler man både tradisjonelle sårbarheter i IT løsningene, og muligheten for tap av informasjon gjennom elektromagnetisk stråling.

Et vesentlig poeng med sårbarhetsvurderingen er at det skal være faktiske målinger, ikke antakelser. Jeg har sett risikorapporter som inneholder vurderinger som "... virksomheten er avhengig av sin webserver, og slike er gjerne preget av feil som kan muliggjøre angrep mot serveren". Dette er nærmest verdiløse utsagn. Vi ønsker å vite helt konkret om webserveren har sårbarheter, hvilke det er, hvordan de utnyttes og hva de kan utnyttes til. Om en sårbarhet krever fysisk tilstedeværelse på webserveren, er selvsagt ikke en aktivistgruppe i Iran i stand til å utnytte den selv om de kan være en uttalt motstander av virksomheten.

En del av sårbarhetsvurderingen er hvor enkelt det er å utnytte den.  Dette kan også brukes til å vurdere hvilke trusler en skal bry seg om. Dersom utnyttelse av en sårbarhet krever svært dyrt utstyr eller høyt kompetanse og treningsnivå, så kan vi utelukke en del trusler. 

Trusselvurdering

Er det slik at dette bare er en annen måte å vurdere sannsynlighet? Nei, absolutt ikke.

Husk at malware ikke er en trussel. Heartbleed er ikke en trussel. En falsk epost som forsøker å lure deg til å oppgi DnB påloggingsinformasjonen er ikke en trussel.

En trussel er en person, gruppe, organisasjon, virksomhet eller nasjon som har vilje og evne til å angripe eller påvirke deg eller din virksomhet. Vi vil vite hvem denne gruppen er. Hvilke metoder de bruker. Hva deres intensjon er. Hvilke verktøy de bruker. Hva deres handlingsmønster er. Hvordan de vil reagere dersom vi iverksetter mottiltak osv. Dette er ikke noe annet enn det man gjør for annen type etterretningsinnhenting. For Forsvaret betyr det at denne type trusler blir beskrevet og behandlet på akkurat samme måte som øvrige trusler. Noen ganger er det jo faktisk de samme truslene som bruker ulike virkemidler for å oppnå sine mål.

Etterretningskildene kan være mange. I tillegg til det ens egen cyberhåndteringsenhet bygger opp av kunnskap om truslene, finnes det mange andre klilder. I Norge er det mange som får informasjon fra EOS-tjenestene. Flere store virksomheter, i tillegg til Forsvaret, har fokus på egne etterretninger om aktuelle trusler. I tillegg kan slik informasjon kjøpes fra stadig flere tilbydere av "threat intelligence". Her skal man imidlertid være litt på vakt. Noen ytterst få leverer etterretningsprodukter som kan sammenlignes med vanlig etterretning, men de fleste tilbydere av "threat intelligence" leverer teknisk informasjon om verktøy og metoder som truslene bruker. Det er ikke det samme.

Trusselbildet er i kontinuerlig endring. Nye trusler kan oppstå, og eksisterende trusler kan utvikle sine metoder over tid. For håndtering av målrettede angrep vil imidlertid fokus på et oppdatert trusselbilde være til svært stor hjelp når risiko skal fastsettes og til å håndtere hendelser når de skjer.

En systematisk tilnærming slik f.eks. Andrew Jones (QinetiQ) beskriver kan være til stor hjelp.

Risiko

Risikofastsettelsen skjer når vi vurderer de konkrete sårbarhetene vi har avdekket opp mot det vi vet om truslene, primært for de mest kritiske IT løsningene. Vi er selvsagt ikke naive. En sårbarhet kan enkelte ganger være så alvorlig i seg selv, at den skal håndteres selv om vi ikke er kjent med en trussel som har intensjon og evne til å utnytte den. På samme måte kan vi stå over for en trussel som vi vet har intensjon og evne, men der vi vet for lite om deres metoder. 

Denne tilnærmingen fjerner behovet for å gjette og vi snakker samme språk i cybersikkerhet som i virksomheten forøvrig. Trusler og risiko blir vurdert mer helhetlig, og tiltakene kan vurderes i en operativ kontekst. 

Risiko ved tilsiktede hendelser

Dette er de målrettede angrepene, de som skjer når virksomheten din står i en konfliktsituasjon med en trussel som har både evne og vilje til å gjennomføre cyberangrep. 

Forsvaret har tidligere fortalt om målrettede angrep der trusselaktøren gjennomførte delvis vellykkede angrep. Motstanderne det er snakk om har cybervirkemidler som en liten del av sitt repertoar. Angrepene ble oppdaget gjennom etterretninger, og håndteringen ble gjennomført som en del av den "normale" virksomheten.

For kort tid siden ble et målrettet angrep avverget før det fant sted som en direkte følge av etterretninger. Et hvert forsøk på å skulle kvantifsere en sannsynlighet for de hendelsene i forkant fremstår som en helt meningsløs oppgave. 

De samme erfaringene har andre store norske virksomheter gjort. En av dem er Telenor, som gikk ut med informasjon om de hendelsene de var utsatt for i forbindelse med virksomheten i India. Hva skulle den subjektive sannsynligheten for de angrepene vært anslått til? 75% Medium? Rød?

For tilsiktede uønskede hendelser vil tradisjonell risikovurdering basert på subjektive sannsynlighetsberegninger være en katastrofe. De er unøyaktige og villedende og vil enten føre til at trusler blir underkommunisert, eller at de blir overkommunisert og at unødvendige tiltak forhindrer at virksomheten når sine mål. 

Avslutningsvis vil jeg medgi at kvantitative metoder og matematiske sannsynligheter kan ha noe for seg i visse sammenhenger. For en gitt malware kan de hende at du har nok empiri til å kunne beregne hvor stor sannsynlighet det er for at du vil bli forsøkt rammet. Om du kjenner spredningsmekansmen trenger du kanskje ikke empiri heller, dersom du kan analysere spredningsmekanismen i forhold til ditt digitale fotavtrykk. Dette gjelder imidlertid kun for hendelser som rammer tilfeldig, ikke for målrettede angrep.

(1) http://norcydef.blogspot.no/2013/03/frste-gang-publisert-pa-g-i-oktober.html

(2) http://norcydef.blogspot.no/2013/03/tidligere-publisert-pa-g-i-september.html

(3) http://www.digi.no/kommentarer/2015/06/25/riskovurdering-uten-sannsynlighet-gir-ingen-mening

(4) https://en.m.wikipedia.org/wiki/The_Black_Swan_(Taleb_book)

Bad Decisions Made Faster: How Qualitative Security Risk Assessments Are Making Things Worse

Derek Brink har skrevet et blogginnlegg for RSA hvor han hevder at kvalitative risikoanalyser fører til dårlige beslutninger.

https://blogs.rsa.com/bad-decisions-made-faster-qualitative-security-risk-assessments-making-things-worse/?utm_source=rss&utm_medium=rss&utm_campaign=bad-decisions-made-faster-qualitative-security-risk-assessments-making-things-worse

Argumentet er at man konstruerer risikomatriser (ja, du har sikkert sett disse 5x5 matrisene med grønne, gule og røde felter) som danner grunnlaget for beslutninger. Nivåene for risiko er som regel av typen "lav, medium,høy".

Vi må først se på det sistnevnte. Det finnes flere typer skalaer, og hvilken du bruker, og ikke minst hvordan du bruker de, har stor betydning.

Nominell skala: Dette er en kvalitativ skala som kan brukes til å skille ulike typer forekomster fra hverandre. "Orange, Brun, Sort". En kan ikke si at Orange er mer, mindre, bedre eller dårligere enn brun. De er bare forskjellige. Innen cyber defence kan denne skalaen brukes til å opprette ulike typer/klasser av angrep. "Mail-baserte angrep" og "Web-baserte angrep" for å si det enkelt.

Ordinal skala: Dette er en kvalitativ skala som kan brukes til å ordne forekomster i forhold til hverandre. "Low, medium, high". Low er mindre enn medium, som er mindre enn high. En kan ikke fastsette avstand mellom nivåene (medium kan være dobbelt så mye som low, men high kan være fire ganger så mye som medium). Det betyr at man feks ikke kan beregne standardavvik. Dette er svært viktig å merke seg.

Interval skala: Dette er en kvantitativ skala hvor man kan bruke aritmetiske metoder for analyse og beregning. Celcius temperaturskala er et eksempel på en slik skala. En kan ikke beregne ratio for forekomster i en slik skala. (En risiko med 50 poeng, er ikke nødvendigvis dobbelt så høy som en med 25 poeng)

Ratio skala: Dette er en kvantitativ skala hvor ratio mellom forekomster kan beregnes. En slik skala har et definert nullpunkt, slik at ratio for forekomster kan beregner i forhold til dette. Kelvin temperaturskala er et eksempel på dette.

Brink har jo rett i at en ordinal skala er kvalitativ, men som jeg har skrevet om i denne bloggen tidligere så er ikke problemet skalaen i seg selv, men hvordan den brukes. Når man tvinges til å bruke aritmetiske metoder (verktøy og algoritmer) så blir det som regel slik at man tilordner verdier (poeng) til nivåene i skalaen, slik at man kan gjøre kalkulasjoner. Dette er en grov feil som må unngås for enhver pris. Som jeg har skrevet om tidligere, dette skyldes at metodene fra et helt annet område (quality management) brukes for cyber defence/cybersikkerhet der vi står over for en motstander med intensjon og evne, ikke tilfeldige feil i en produksjonsprosess.

Det er ikke uvanlig å se ordinal skalaen i bruk i ekte kvalitative risikovurderinger, og jeg mener bestemt at det er nyttig å bruke en slik skala der. I slike risikovurderinger faller man ikke for fristelsen til å poengsette nivåene og å dytte dem inn i de meningsløse 5x5 matrisene.

3 Big Mistakes In Incident Response

I denne artikkelen presenteres det tre av de største feilene en kan gjøre når man håndterer cyberangrep.

http://www.darkreading.com/management/3-big-mistakes-in-incident-response/240154817/

Synes artikkelen i utgangspunktet er god. Hovedtema er at manglende SA (Situational Awareness) fører til feil beslutning. Det er imidlertid ikke alt jeg er enig i:

1. ASSuming It's An APT.
Budskapet er at selv om "it walks like a duck, its not a duck". Det er jo åpenbart mulig at "vanlige kriminelle" etterligner TTP'ene til etterretningsorganisasjoner og andre offensive cyberkapabiliteter, men er det grunn god nok til å la være å undersøke om en hendelse kan være utført av sistnevnte aktører?
Selvfølgelig ikke. Jeg mener at det tradisjonelle måten å tenke eskalering, ikke fungerer i en Cyber Defence organisasjon. Hendelseshåndtering som skjer i driftsorganisasjoner kan være organisert slik at den som trenger hjelp først kommer i kontakt med helpdesk. Denne kan være bemannet med personell som har mindre utdanning og erfaring enn det som kreves for å løse mer komplekse problemer. Hvorfor? Jo fordi at de aller fleste hendelsene kan løses med en "mekanisk" tilnærming til problemløsning. Det er derfor de utstyrt med flytskjema for problemløsning, og det er derfor du må snakke med noen andre hvis flytskjema ikke løser problemet. Eskalering funker for disse problemene.

For en Cyber Defence analytiker derimot, er det behov for at eksperten er i fremste rekke. Det krever mye kunnskap og mye erfaring for å kunne avgjøre om et stykke data/informasjon er relevant eller ikke. Jeg er blitt fortalt at akuttmottaket på sykehuset fungerer på samme måte. Det er eksperten som undersøker deg først. Det er vesentlig å finne ut om du bare har brukket armen i den bilulykken, eller om du også har en langt mer alvorlig hodeskade som skal behandles først.

Derfor skal Cyber Defence analytikeren undersøke saken først, og hver sak må behandles som om det er en avansert motstander en står over for.

2. Not Monitoring Traffic.
Sikkerhetsovervåking bygger SA. Det er ingen vei utenom. Vil du vite hva som skjer i nettverkene dine, så må du overvåke dem. Uten overvåking har du ingen evne til å håndtere hendelser. Er forøvrig helt enig i hva artikkelen skriver om Netflow analyse. Om jeg måtte velge kun ett verktøy for overvåking, ville det vært Netflow-analyse.

3. Focusing Only On The Malware. 
Selv om jeg er enig i at en ikke bør fokusere på malware alene, synes jeg artikkelen bommer med begrunnelsen. Malware-analyse kan være et viktig bidrag til å avdekke motstanders intensjon, kapabilitet og kapasitet. Det kan bidra til å avdekke hvilken informasjon som er kompromittert eller ødelagt, og hvilken som ikke er det. Å si at malware-analyse ikke kan gi deg "root cause" er direkte feil.

Til slutt en påstand fra artikkelen som jeg ikke kan la passere:

But identifying the attacker is not straightforward in cyberattacks, and incident response isn't about ID'ing the individual attackers, anyway, Cylance's Shook says.

Dette utsagnet plasserer "incident response" nærmere tradisjonell informasjonssystemsikkerhet, enn slik jeg tenker rundt cyber defence. For sistnevnte handler det åpenbart om å forsøke å identifisere hvem motstanderen er, hva han vil, hvilke kapabiliteter og kapasiteter han har. Det er blant annet her at Cyber Defence skiller seg ut fra informasjonssystemsikkerhet.

Three simple steps to determine risk tolerance

Denne artikkelen gir oss tre steg for å bestemme hvilken toleranse for risiko vi skal ha.

http://www.csoonline.com/article/731833/three-simple-steps-to-determine-risk-tolerance-

Ved første øyekast synes dette å være ganske tilforlatelig, selv om jeg må innrømme at jeg etterhvert har blitt immun mot alle de nye mote-ordene (Risk tolerance? Var vi lei av Risk Acceptance og Recidual Risk allerede?)

Det er en veldig grei og rett-frem tilnærming denne artikkelen gir oss:

1. Bestem hvor mye risiko du kan tåle
2. Finn ut hvilken motivasjon du har for sikkerhetsarbeidet
3. Bestem hvem som kan bestemme hvilken risiko du kan tåle

Jeg tror at mange vil kjenne seg igjen i følgende situasjon:

Den som er ansvarlig for det utøvende sikkerhetsarbeidet (CISO og ned) vet at omfanget og kompleksiteten i jobben deres er formidabel. En kan ikke forhindre sikkerhetsbrudd, fordi det ikke er forutsigbart. En kan ikke forsvare seg mot alt, fordi ressursene ikke strekker til. Med andre ord, ressursene må prioriteres. Prioritering betyr beslutning (ledelse) og er i seg selv en risiko. Hva om jeg har prioritert feil? 

Slik kan man i følge artikkelen ikke ha det, så en skal da ha et Enterprise Risk Management (ERM) system hvor risiko skal kvantifiseres (forferdelig dårlig idé). I praksis er min erfaring at slike systemer handler om én ting. Å øverføre ansvaret for beslutningene fra CISO til Styret, CEO, Adm Dir eller hvem det nå er som avnikker et slikt dokument. Nå er vi tilbake til ROS-analyser, rest-risiko og akseptansnivåer for risiko. CISO ønsker ikke at risiko-toleransen endrer seg hele tiden, for det gjør jo hverdagen uforutsigbar og stressende. Når ledelsen har besluttet hva de vil akseptere, så har CISO or sikkerhetsorganisasjonen fått sin høyre og venstre begrensing. Når det går galt, og CISO har levert innenfor sitt oppdrag, ja da er det vel noen andre som får ta støyten da.

Hvilken motivasjon en har til sikkerhetsarbeidet er sikkert greit å ha et forhold til, og jeg er enig i det artikkenel konkluderer med: Du vil ha en mix av alle typer motivasjon. Skal vi revideres i neste uke, sier du? Da er det KUN compliance som er viktig. Personvern synes å være svært viktig etter at man har hatt en større hendelse som rammer akkurat det området. Ellers tenker jeg at det er det virksomhetskritiske og operasjonelle som har størst fokus. For Forsvaret sin del, handler dette om liv og død. Informasjonssikkerhet, både det som gir reell sikkerhet og det som dessverre ødelegger for den, har betydning for menneskers liv i operasjonene. 

Derfor blir jeg litt oppgitt når dette pakkes inn i "systemer" og verktøy som bare tilfører ekstra avstand til den reelle risikoen. Det eneste som blir bedre er følelsen av å ha håndtert risiko.

Det siste punktet, hvem som kan bestemme, er jo åpenbart. Delegering av myndighet er jo noe en gjør i alle deler av en organisasjons virksomhet.

For meg handler dette mest om å lede og om a ta ansvar. Å lage intrikate systemer for måling av risko, og å binde nivået over deg til å ta på seg ansvaret for noe de uansett ikke kan forutsette fullt ut, er ikke å  lede eller å ta ansvar.  Å delta aktivt, og likeverdig, i de operative ledelsesprosessene er noe helt annet. 

Det er derfor at CISO'er skal sitte ved sjefens bord. Felles situasjonsforståelse og en dynamisk tilnærming til hvordan en skal forholde seg til risiko bør være målet.

Using Dependency Modeling For Better Risk Decisions

I denne artikkelen intervjuer Dark Reading Jim Hietala og Chris Baker fra Open Group. Tema er en ny standard som skal hjelpe oss å håndtere risiko bedre.

Using Dependency Modelling For Better Risk Decicions

Utgangspunktet for deres modell er attack-trees, en metode for å kartlegge "alt som kan gå galt".
(Attack Trees). Dessverre har jeg ikke noe særlig tro på denne metoden for å kartlegge risiko der truslene er uforutsigbare og dynamiske. Selv om wargaming kan være nytting i mange sammenhenger, bør det styres, og i tillegg til å gå gjennom de mest trolige scenariene, bør det styres mot å tenke utenfor boksen. Hva er det vi IKKE har tenkt på.

Hvorfor kan man ikke gjøre det i slike attack-trær da? Det er ingenting som forhindrer at man kan gjøre det, men kritikken mot denne metoden har vært at det er for lett å lage slike trær for det man allerede vet, og vanskelig å faktisk beskrive scenarier utenfor boksen. Mulig det er fordi at det ukjente er vanskelig å bryte opp og beskrive i detalj. Men unntak av i lærebøkene, har jeg ikke vært borti at noen bruker slike trær aktivt i sin risikohåndtering. Wargaming, som ligner på dette, brukes nok og kan som nevnt være fornuftig når det brukes riktig. "Hva er motstanders mest trolige handlemåte?" "Hva er motstanders farligste handlemåte?" er to spørsmål som kan lede til en god wargaming sesjon.

Artikkelen sier lite om innholdet i selve metoden, og jeg synes at svarene som representantene fra Open Group gir er preget av god gammeldags svada. Enkelte svar får meg imidlertid til å sperre opp øynene.

Baker: Within IT security risk management, one of the real benefits that start from deploying a dependency model in your environment is that it demands that you start by saying, 'What are we trying to achieve? What are our objectives?'

In the case of IT security, then you might adopt confidentiality, availability, and integrity, or some other issues around authentication and so on and so forth. And you will have systems that help you implement that.

Her faller jeg av. Et cyber defence team som stiller seg spørsmålet "Hva vil du oppnå?", og ender opp med å svare konfedensialitet, integritet og tilgjengelighet, er dømt til å feile. Et cyber defence team har som sin eneste oppgave å sørge for mission security, eller på norsk: Operasjonell handlefrihet.

The customer came to us basically saying, 'OK, I've got a 1,000 branches, and I've got 20 odd systems in every branch, and that's a big number. I'm getting red, amber, and green [alerts] from all of them. Every morning I come in and I have about 1,500 reds. All I want to know is, which of these reds are the most red?'

We're working with an organization that already provides that data within medium-sized environments to enable them to use our calculation engine and the open dependency modeling standard to communicate, capture that, and then give a prioritized list of outputs.

Jeg har overhodet ingen tro på at det går an å ha et oppdatert bilde på hvilke avhengigheter (koblet mot "business goals") som er gjeldende til enhver tid og hvordan de skal være prioritert i forhold til hverandre. Hva som er viktig for en virksomhet, kan forandre seg uke for uke, dag for dag. Kanskje enda oftere. En vil garantert sitte igjen med en oversikt som ikke er korrekt, og dermed et beslutningsgrunnlag som er feil.

Intervjuet ender med å love at vi skal få se mer til denne metoden om noen måneder. Jeg venter ikke i spenning.

Ps, har tidligere skrevet om risikohåndtering... Ligger i arkivet.

Supply Chain Risk Management

Supply Chain Security eller Supply Chain Risk Management blir stadig oftere nevnt. Det males noen temmelig sorte bilder, der utenlandske myndigheter planter avlytningsenheter eller "kill-switches" i nettverkskomponenter og annet IKT-utstyr som vi handler hos dem. Dette ser vi spesielt i USA, der Kinesiske Huawei og ZTE jevnlig anklages for å muligens ha slike bakdører. Jeg skriver muligens, for meg bekjent har det ikke vært påvist at utstyr fra de produsentene har slike bakdører.

Hvor mye av dette er basert på reelle risiki, og hvor mye er nasjonal industripolitikk?

Når myndighetene, spesielt Forsvaret, gikk for å bruke COTS var dette begrunnet i at det ville spare utviklingskostnader, og det vil gi rask tilgang til ny teknologi. Den teknologiske utviklingstakten har økt dramatisk, så det gir god mening i en strategi der en tar del i andres utvikling, fremfor å skulle utvikle alt selv, eller i allianser med andre (f.eks. NATO).  Sikkerhetsutfordringene ved en slik strategi har vært kjent hele tiden, og etterhvert fikk man Common Criteria standarden for sertifisering av IKT-utstyr. CC har vært anvendt de siste 10 årene, og det har vært stilt krav om CC sertifisering, (EAL seritifisering) for utstyr som skal brukes i Forsvarets systemer. I praksis har dette medført at en gitt produsent sender et lite antall modeller til sertifisering, trolig fordi det er ganske kostbart. (Kostnadene blir jo i noen grad sendt til kundene, men likevel). I tillegg er en sertifiseringspriosess ganske omfattende, så det går også mye tid før et gitt produkt får sin sertifisering. 

Resultatet? Utstyret som er tillatt brukt er eldre, har dårligere funksjonalitet enn de siste produktene som slippes på markedet, og vil etterhvert nå sitt End-of-life tidspunkt og dermed ikke lenger være tilgjengelig for kjøp. Men vent litt. Var ikke poenget med COTS strategien at vi skulle høste av den teknologiske utviklingen? Når vi bruker CC på denne måten, frasier vi oss muligheten til å bruke ny teknologi for å oppnå økt effekt av vår IKT. Dette kan umulig være riktig?

Og det er det heller ikke. Derfor har blant annet NATO gått mer og mer bort fra å kreve EAL-sertifisering av utstyret, men utsteder heller Protection Profiles som er mer generelle, og mer rettet mot produsenten enn mot utstyret. 

Måten vi bruker CC på har altså tatt et steg "tilbake" i forhold til den detaljerte kontrollen av utstyret man hadde lagt opp til. Det passer dårlig for de som er forkjempere for en slik tankegang. 

Velkommen Supply Chain Risk Management. Vi ser de samme argumentene og løsningene som før. Trusselen males opp, standarder etableres og fokuset rettes mot utstyret. 

Top 2013 risks

NIST: SUPPLY CHAIN RISK MANAGEMENT (SCRM) FOR INFORMATION AND COMMUNICATIONS TECHNOLOGY

DHS: National Strategy for Global Supply Chain Security

... bare for å nevne noen.

Vi trenger forsåvidt ikke dra så langt for å høre de samme tankene. Vår egen Nasjonal Sikkerhetsmyndighet har uttrykt at Supply Chain Security har fokus, og at dette er noe de ønsker å lage retningslinjer for. Det kan i så fall bety at vi igjen skal gå i en retning av sertifisering av utstyr, med alle de ulemper det medfører. Om så skjer, betyr det at alle som er underlagt dette sikkerhetsregimet, igjen blir låst til utdatert og mer kostbart IKT utstyr. Dette er ganske dramatisk, ettersom vi heller burde omfavne ny teknologi. 

Er trusselen fra utenlandske myndigheter overdrevet? Er avlytting og kill-switcher bare fantasi? 

Helt sikkert ikke, men om vi lar denne potensielle trusselen gjøre slik at vi fratar oss selv muligheten til å opnå økt effektivitet og produktivitet... Ja da går jo vinningen opp i spinningen. 

Ønskedrømmen om en sikker supply chain bør gis opp, og i stedet finne måter å oppdage og håndtere reell risiko.  Stikkprøver er en mulighet, Cyber Defence team kan spille en rolle når det handler om å oppdage ondsinnet funksjonalitet i nettverksutstyr.  Men bland for all del ikke industripolitikk inn i dette.

(Caveat: Jeg snakker her kun om infosec-delen av Supply Chain Risk Management)