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

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)