En digital Geneve-konvensjon?

Under åpningen av årets RSA Conference 2017 kom Brad Smith, President og Chief Legal Officer i Microsoft på scenen. Han leverte et sterkt argument for at verden nå er moden for en Digital Geneve-konvensjon.

Men; er verden virkelig moden for det, og hvorfor var det nettopp Microsoft som foreslo dette?

Geneve-konvensjonene består av fire traktater. Den første, som omhandler Forbedring av sårede og sykes kår i de væpnede styrker i felten, ble vedtatt helt tilbake i 1864 etter den brutale krigen mellom Sardinia, Frankrike og Østerrike. De tre andre konvensjonene er Konvensjonen om forbedring av sårede, syke og skibbrudnes kår i de væpnede styrker til sjøs, Konvensjonen om behandling av krigsfanger og Konvensjonen om beskyttelse av sivile i krigstid. Sistnevte er den konvensjonen som er relevant for forslaget fra Microsoft.

Hensikten med konvensjonene er å sørge for at alle nasjoner som har signert dem, er pålagt å vedta et lovverk som gjør brudd på konvensjonene straffbare. Tanken er altså å komme frem til internasjonalt vedtatte spilleregler for konflikt i det digitale rom. På den måten kan verdenssamfunnet unngå store globale, regionale eller lokale skadevirkninger som følge av angrep på digital infrastruktur.

Tilbake til forslaget fra Microsoft. De setter opp seks punkter :

1. No targeting of tech companies, private sector or critical infrastructure
2. Assist private sector efforts to detect, contain, respond to and recover from events
3. Report vulnerabilities to vendors rather than to stockpile, sell or exploit them
4. Exercise restraint in developing cyber weapons and ensure that any developed are limited, precise and not reusable
5. Commit to nonproliferation activities to cyberweapons
6. Limit offensive operations to avoid a mass event

Det første en kan spørre seg om, er om dette vil kunne fungere i praksis. Vil nasjonalstater virkelig innrette seg etter slike regler? What's in it for them?

Det er en generell enighet om at sikkerhet på internett i hovedsak er et anliggende for privat sektor. Privat sektor eier det aller meste av infrastrukturen, og det er i hovedsak privat sektor som både bruker og som blir angrepet gjennom internett. Nasjonale myndigheters rolle er i hovedsak avgrenset til å etterse at privat og offentlig sektor følger de spillereglene som er satt opp. Vil en Digital Geneve-konvensjon endre på dette? Ja, jeg tror det. Hvis nasjonalstatene gjøres mer ansvarlig for sikkerheten i det digitale rom, må vi forvente at de også vil ta en større rolle i sikringen av det. Hva det eventuelt kan bety vet vi ikke enda.

Et annet spørsmål her er om alle nasjonalstater faktisk ønsker en slik konvensjon. Foreløpig er det enorme forskjeller i nasjonale kapasiteter for krigføring i det digitale rom. Cyberoperasjoner er asymmetriske, billige og de gir effekt. Attribusjon er vanskelig, i alle fall vanskeligere enn ved tradisjonelle operasjoner. De nasjonene som har opparbeidet seg et fortrinn, hvorfor skal de ville gi slipp på det? 

Det er heller ikke slik at all sivil infrastruktur i det fysiske rom er beskyttet mot andre nasjoners krigføring. Veier, broer, strømlinjer, toglinjer osv kan være lovlige mål, dersom de direkte understøtter militære operasjoner. Generaladvokat Arne Willy Dahl skriver i sin Håndbok i militær folkerett at operasjoner i digital infrastruktur også kan være lovlige.

Poenget er at en Digital Geneve-konvensjon neppe vil kunne helt fjerne risikoen for at nasjonalstater angriper både sivil og militær digital infrastruktur. Men; en slik konvensjon kan trekke opp nye spilleregler som forhåpentligvis kan bidra til å forhindre at slike angrep får større skadevirkninger enn det som er nødvendig.

Et helt annet, og veldig interessant spørsmål er: Hvorfor er det nettopp Microsoft som kommer med dette forslaget? Hvorfor er det ikke en nasjonalstat som har foreslår det?

At globale IT-selskaper har blitt en betydelig maktfaktor er det ingen tvil om. Produktene deres styrer og utvikler hvordan vi lever livene våre, og både vi som enkeltpersoner og nasjonalstater må forholde oss til dem nærmest som om de er stater i det digitale rom.

Microsoft vil nok helst at vi tenker på deres Corporate Social Responsibility, altså at de nå tar ansvar for verdensfreden. I alle fall i det digitale rom. Og det skal vi absolutt tenke på. Vi er avhengige av at de har intensjon om å ivareta våre behov, også det for trygghet.

Men; til syvende og sist tror jeg at vi ser dette fra Microsoft fordi det er i deres egen interesse å få på plass en Digital Geneve-konvensjon. Cyberkrig og cyberkriminalitet skaper frykt og reduserer tillit, og er derfor en motkraft til den globale digitaliseringen. Det er dårlig nytt for Microsoft, Apple og alle de andre globale IT-gigantene. De er avhengig av et miljø som muliggjør vekst. 

Heldigvis er det sammenfallende med våre egne interesser. Eller? 

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)

Cyber Situasjonsforståelse

Vi forstår intuitivt at beslutninger må tas på et riktig og rasjonelt grunnlag. Hva er de viktigste truslene mot virksomheten, og hva skal vi gjøre for å forberede oss? Hva er egentlig omfanget av hendelsen som nettopp har blitt oppdaget, og hvilke tiltak er de riktige å gjennomføre? Hvilke ressurser har vi tilgjengelig? Hvilke langsiktige tiltak må til?

Hva er egenlig cyber situasjonsforståelse, og hvordan oppnår vi det?

Situasjonsforståelse kan deles inn i tre nivåer:

1. Å oppfatte at en hendelse har funnet sted i tid og rom.
2. Å forstå hva det betyr at hendelsen har funnet sted
3. Å forutse hva hendelsen vil kunne føre til

La oss se på et eksempel:
1. Sikkerhetsovervåking avslører at store mengder data sendes fra en av virksomhetens datamaskiner til en IP-adresse i et annet land. Analytikeren oppfatter at dette skjer.

2. Analysene avslører at dataene er innholdet i en database som brukes av utviklingsavdelingen, og at de sendes til en nasjon der myndighetene er kjent for å bruke cyber-virkemidler for å støtte opp om sin nasjonale industri. Analytikeren forstår hva det er som har skjedd og iverksetter umiddelbart tiltak som forhindrer videre tap av informasjon.

3. Virksomheten analyserer situasjonen og kommer til at en konkurrent trolig står bak, og at han trolig vil bruke informasjonen til å vinne fremtidige kontraktsforhandlinger. Virksomheten forutser hva hendelsen kan føre til, og kan med bakgrunn i dette gjøre strategiske valg.

Enkelt? Overhodet ikke!

Det finnes mange forslag til hva et cyber situasjonsbilde skal være. Sjefen/styret ønsker et overordnet bilde, gjerne med noen farger som indikerer om alt er ok. Analytikeren setter gjerne opp sine egne triggere i alle mulige systemer for å raskest mulig fange opp hendelser. Mitt fokus er på ledelsen av enheten som skal håndtere hendelsen. Denne står midt mellom analytikeren og virksomhetens ledelse, og må innhente informasjon fra begge leire.

Fallgruver
Jeg har sette flere forsøk på å etablere løsninger for cyber situasjonsforståelse, og noen av dem har feilet ganske kraftig. En fellesnevner er  at man ikke har tatt seg tid til å vurdere hvilken informasjon det er behov for, men brettet opp ermene og laget en eller annen teknisk løsning. For deretter å finne ut at det ikke var noen som trengte det. Noen eksempler:

1. Dyre SIM/SIEM løsninger. Etter at løsningene er implementert oppdager du at de IKKE kan ta i mot noen logg-kilder som faktisk er helt kritiske. Korreleringen mot sårbarhetsundersøkelsene fungerer dårlig i praksis fordi du ikke klarer å måle systemene ofte nok. Løsningene forteller lite om virksomheten, altså hvilken kontekst hendelsene skal vurderes i. Resultatet er at en ikke vet om en gitt hendelse er alvorlig, og risk-score systemet er nærmest ubrukelig.

2. Enkle PowerPoint/SharePoint dashboards. Disse ser flotte ut. Kanskje noen i ledelsen så et slikt dashboard et sted, og nå skal det innføres i din virksomhet også. Energien legges i utformingen av dashboardet, og ikke så mye i arbeidet med å innhente og analysere informasjonen som skal presenteres. Resultatet er at det "dør på rot".

3. Egenutviklede løsninger. Disse er gjerne bedre tilpasset de behovene og systemene som virksomheten har, men med mindre en har en egen utviklingsavdeling er det stor fare for at løsningen ikke blir oppdatert eller holdt ved like.

The good way to do it
I stedet bør man starte med å analysere hvilken informasjon som er nødvendig for å kunne ta gode beslutninger. Hvis en tar seg tid til å løfte blikket og se hvilken informasjon analytikere og ledelse har behov for, ender du kanskje opp med et informasjonsbehov som er annerledes enn det du først trodde.

En slik tilnærming ble presentert på NATO Cooperative Cyber Defence Centre of Excellence i 2014 i et paper(1) av Dressler, Moody, Bowen og Koepke. Jeg liker spesielt godt at de beskriver hvilke dataklasser som inngår i en helhetlig cyber situasjonsforståelse. De enkelte dataklassene må vurderes med tanke på hvilket informasjonsbehov du har, hvordan informasjonen skal samles inn, analyseres og presenteres.

Dataklassene som inngår i cyber situasjonsforståelse

Cyber events
Dette er alle hendelser som er relevante i analysearbeidet. Det inkluderer naturligvis informasjon fra inntrengningssystemene, men også alle andre logg-kilder som må samles inn for å kunne fastslå et hendelsesforløp.

Key Cyber Terrain
For å forstå en hendelse, eller for å forstå hvilke mottiltak som er mest hensiktsmessig, må en forstå cyberlandskapet. Store virksomheter kan ha store og komplekse IT-løsninger, spredt utover mange funksjonsområder og geografiske avstander. I en gitt situasjon er imidlertid ikke alle deler av nettverket like viktig. "Key cyber terrain" kan feks være avgrenset til internett-portalen, ordresystemet eller serverne som kjører en spesifikk versjon av operativsystemet. For å forstå hva som er viktig, må dette avklares sammen med den eller de som driver virksomheten.

Ongoing operations
For store virksomheter, som Forsvaret hvor jeg har min bakgrunn, kan det være flere pågående operasjoner samtidig. Håndteringen av flere samtidige hendelser må koordineres med tanke på tid, rom, ressurser osv. I tillegg må de kunne presenteres samlet for ledelsen.

Cyber readiness
Hvilke cyberkapasiteter har virksomheten? Hva er status for utstyret? Er treningsnivået tilstrekkelig? Er bemanningen god nok? Er de ute på oppdrag, eller er de disponible? Når en leder hendelseshåndtering, må en vite hvilke ressurser som er tilgjengelig. Å legge planer for ressurser du ikke har er en dårlig idé.

Cyber vulnerabilities
Hvilke sårbarheter har du i ditt "Key cyber terrain"? Er det oppdatert? Er det minimert? Har du tilstrekkelig konfigurasjonskontroll og en oppdatert oversikt over hvilke sårbarheter som finnes i de mest kritiske delene av ditt cyberlandskap.

Threat Landscape
Hvilke trusler står virksomheten over for? Hva vet du om truslene? Hvilke intensjoner driver dem til å angripe akkurat din virksomhet? Hvilke teknikker og metoder bruker de? Hvordan kan du oppdage om de har angrepet virksomheten? Hvordan kan du forberede deg på å avskjære angrepene? Har du sårbarheter i ditt key terrain som truslene som er mest relevante for deg kan utnytte? Trusselbildet er dynamisk og i konstant endring.

Først når du har vurdert disse dataklassene nøye og funnet ut hvor informasjonen oppstår, hvordan du skal samle den inn og vurdere den, først da kan du utvikle en løsning for hvordan den skal presenteres. En til tilnærming vil også skape den nødvendige forankringen både oppover og nedover i organisasjonen, og sørge for at alle forstår hvilken rolle de spiller i etableringen av situasjonsforståelsen.

Først da kan du si at det er en felles situasjonsforståelse.

(1) Operational Data Classes for Establishing Situational Awareness in Cyberspace

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.