Før du velger en sikkerhetsløsning, må du vite hvilket problem du skal løse

Fire spørsmål som hjelper virksomheter å gjøre bedre sikkerhetsinvesteringer – og få tiltakene til å virke over tid.

Sikkerhetsinvesteringer starter ofte med en diskusjon om teknologi. Hvilke produkter bør vi vurdere? Hva kan de gjøre? Hva koster de?

Dette er relevante spørsmål. Men jeg mener vi bør begynne med et annet:

Hvilket problem prøver vi egentlig å løse?

Før vi velger en løsning, må vi forstå hva som er viktig for virksomheten, hvilke risikoer vi skal redusere, og hva investeringen skal gjøre oss i stand til å håndtere.

En sikkerhetspolicy kan slå fast at et tiltak er nødvendig. En arkitekturskisse kan vise hvor det hører hjemme. En lisensoversikt kan bekrefte at teknologien er anskaffet.

Ingen av delene dokumenterer i seg selv at virksomheten er bedre beskyttet eller bedre rustet til å håndtere en hendelse.

Sikkerhetsarkitekturen må fungere i hverdagen

Jeg har sett lignende referansearkitekturer gi svært ulike resultater i forskjellige virksomheter.

I ett tilfelle var arkitekturen teknisk god og teknologien egnet, men virksomheten manglet ressurser til å drifte løsningen effektivt. Etter hvert ble varsler liggende uten oppfølging, unntak hopet seg opp, og konfigurasjonene fikk mindre oppmerksomhet enn de krevde.

Beskyttelsen ble gradvis svekket, uten at en tydelig feil varslet om det.

I et annet tilfelle oppfylte løsningen kravene i en anerkjent standard innenfor området som ble vurdert. Likevel lå en viktig angrepsvei utenfor dette området. Virksomheten kunne dokumentere etterlevelse, men det betydde ikke at de relevante risikoene var tilstrekkelig håndtert.

Ingen av situasjonene skyldtes manglende vilje til å prioritere sikkerhet.

Begge viser hvorfor sikkerhetsarkitekturen må ta hensyn til mer enn tekniske krav. Den må bygge på virksomhetens faktiske risikobilde, hvordan arbeidet er organisert, og hvilke ressurser som finnes til å følge opp tiltakene.

Hva betyr dette i praksis?

La oss ta utgangspunkt i en tenkt transport- og logistikkvirksomhet med flere terminaler.

Hvis systemene ved én terminal blir kompromittert, kan virksomheten ha behov for å isolere dem og samtidig opprettholde driften ved de andre terminalene.

Det kan høres ut som et rent teknisk krav. Men for å gjøre det mulig må vi forstå hvordan terminalene kommuniserer, hvilke fellessystemer de er avhengige av, hva som kan isoleres forsvarlig, og hvem som har myndighet til å beslutte det.

Svarene påvirker både nettverkssegmentering, tilgangsstyring, overvåking og rutiner for hendelseshåndtering. De kan også vise at isolering vil få større konsekvenser for driften enn først antatt.

En produktsammenligning kan hjelpe oss med å finne egnet teknologi. For å forstå hvordan virksomheten faktisk skal håndtere en hendelse, må vi også involvere menneskene som kjenner den daglige driften.

Fire spørsmål før vi vurderer løsningene

Før vi sammenligner teknologier og leverandører, ville jeg startet med fire spørsmål.

De erstatter ikke en formell risikovurdering eller en gjennomgang av arkitekturen. Hensikten er å avklare om vi forstår problemet godt nok til å ta en begrunnet beslutning. Vi trenger ikke ha alle svarene fra starten, men vi må vite hva vi fortsatt trenger å undersøke.

1. Hva skal vi beskytte?

Begynn med funksjonene virksomheten er avhengig av, fremfor bare å lage en liste over systemer og applikasjoner.

En oversikt over IT-utstyret og systemene forteller oss hva som finnes. Når vi forstår hvordan de støtter virksomheten, ser vi også hvorfor de er viktige.

For logistikkvirksomheten kan det dreie seg om transportplanlegging, terminaldrift og kommunikasjon med sjåfører.

Hvilke funksjoner må være tilgjengelige? Hvor lenge tåler de et avbrudd? Hvilke systemer, mennesker og eksterne leverandører er de avhengige av?

Svarene gjør det lettere å identifisere kritiske avhengigheter og vurdere hvor det er behov for sterkere beskyttelse eller større motstandsdyktighet. Ulike systemer kan ha svært ulik betydning for virksomheten. Det bør sikkerhetsarkitekturen gjenspeile.

2. Hvilke trusler og angrepsveier er relevante?

Når vi vet hva som er viktig, må vi undersøke hvordan det kan rammes.

Trusselmodellering handler om å identifisere relevante angrepsscenarioer og forstå hvordan en angriper kan utnytte svakheter og avhengigheter. Vurderingen må ta utgangspunkt i virksomhetens teknologi, arbeidsmåter og forbindelser til eksterne aktører.

Kan en angriper nå et kritisk system gjennom en kompromittert brukerkonto? Kan en leverandørtilkobling åpne en utilsiktet vei inn i nettverket? Har brukere eller systemer fått mer omfattende tilgang enn de trenger?

Målet er å forstå hvilke scenarioer som er realistiske, hvordan eksisterende tiltak håndterer dem, og hvor vesentlige svakheter gjenstår.

Et nytt sikkerhetsprodukt kan være riktig tiltak. Andre ganger kan bedre konfigurasjon, tydeligere segmentering, færre tilgangsrettigheter eller bedre bruk av eksisterende løsninger gi større effekt.

3. Hva kan konsekvensene bli?

For å prioritere en teknisk svakhet må vi forstå hva den kan bety for virksomheten.

For logistikkvirksomheten kan en hendelse føre til forsinkede leveranser, stans i terminaldriften, eksponering av kundeopplysninger eller fare for liv og helse. Den kan også gi økonomiske tap, brudd på avtaler og plikt til å varsle myndigheter eller berørte parter.

Noen konsekvenser kan tallfestes. Andre må vurderes sammen med dem som har ansvar for drift, økonomi og virksomhetsledelse.

En viktig del av sikkerhetsrådgivningen er å gjøre teknisk risiko forståelig og relevant for dem som skal prioritere ressursene. Da kan sikkerhetsbehov vurderes sammen med virksomhetens øvrige risikoer.

Vi må derfor avklare både hva som kan gå galt, og hvorfor det er viktig å forebygge eller begrense konsekvensene.

4. Hva må virksomheten kunne gjøre under en hendelse?

Sikkerhetsarkitekturen må også legge til rette for handling når en hendelse oppstår.

Hvem skal oppdage og vurdere situasjonen? Hvilken informasjon trenger de for å ta en beslutning? Hvem har myndighet til å handle? Og kan nødvendige tiltak gjennomføres utenfor vanlig arbeidstid?

For logistikkvirksomheten krever isolering av en kompromittert terminal mer enn nettverkssegmentering. De ansvarlige må kunne identifisere berørte systemer, forstå konsekvensene av å isolere dem og vurdere hvilke tiltak som begrenser skaden uten å skape større problemer.

De må også vite hvordan kritiske funksjoner skal gjenopprettes, og hvordan de skal kontrollere at det er forsvarlig å gå tilbake til normal drift.

Dette krever oversikt, tydelig ansvar og avklarte prosedyrer. Samarbeidet mellom sikkerhetsmiljøet og dem som har ansvar for den daglige driften, må være på plass før hendelsen oppstår.

Hvem skal drifte løsningen om ett år?

De fire spørsmålene hjelper oss å avklare hva løsningen skal oppnå. Men resultatene avhenger også av at virksomheten kan følge den opp over tid.

Systemer endres, nye tjenester tas i bruk, konfigurasjoner avviker gradvis fra det som var planlagt, og integrasjoner kan slutte å fungere. Varsler må vurderes, unntak må følges opp, og sikkerhetstiltak må testes.

Dette krever tid, kompetanse og tydelig eierskap.

Noen virksomheter har kapasitet til å håndtere oppgavene selv. Andre bruker en ekstern leverandør eller kombinerer interne og eksterne ressurser. Hvilken modell som passer, avhenger av virksomhetens behov og forutsetninger.

En løsning med mange funksjoner kan også kreve mer spesialistkompetanse, større driftsinnsats og investeringer i støttesystemer. Disse kostnadene må med i vurderingen før anskaffelsen.

En god sikkerhetsløsning må både dekke behovet og kunne driftes forsvarlig over tid.

Gjør svarene til et tydelig beslutningsgrunnlag

Før vi går i dialog med leverandører, bør vi kunne beskrive behovet uten å nevne et bestemt produkt.

En kort beskrivelse kan samle de viktigste kravene:

Vi må beskytte [kritisk funksjon] mot [relevant trussel eller angrepsvei], fordi en hendelse kan føre til [konsekvens for virksomheten]. Under en hendelse må [ansvarlig rolle] kunne [nødvendig handling] innen [tidsramme].

Dette erstatter ikke en fullstendig kravspesifikasjon, men gir de involverte et felles utgangspunkt.

To forhold bør avklares i tillegg:

• Drift og ansvar: Hvem skal følge opp løsningen etter innføringen, hvilken kompetanse og kapasitet krever den, og hvordan fordeles ansvaret?
• Dokumentasjon av effekt: Hvordan skal vi undersøke om tiltakene virker som forutsatt, og om virksomheten kan håndtere en hendelse?

Hvordan effekten vurderes, avhenger av tiltaket. Det kan være nødvendig å teste om relevante hendelser blir oppdaget, gjennomgå konfigurasjoner, kontrollere tekniske funksjoner eller øve på hendelseshåndtering.

Når dette avklares før innføringen, blir det også lettere å oppdage når beskyttelsen svekkes eller behovene endrer seg.

Med et tydelig beslutningsgrunnlag kan leverandørene vurderes ut fra hvor godt de løser virksomhetens problem, og hva det krever å opprettholde effekten over tid.

Begynn med én kritisk funksjon

Du trenger ikke gjennomgå hele sikkerhetsarkitekturen for å komme i gang.

Velg én funksjon virksomheten er avhengig av. Undersøk hva den trenger for å fungere, hvilke risikoer som kan ramme den, og hvordan dere vil håndtere et avbrudd. Involver dem som kjenner den daglige driften, sammen med dem som har ansvar for teknologien og sikkerheten.

Dere kan finne at eksisterende tiltak er tilstrekkelige. Dere kan også oppdage manglende oversikt, uklart ansvar eller avhengigheter som trenger bedre oppfølging. Begge deler gir et bedre grunnlag for å prioritere.

En god sikkerhetsbeslutning fører ikke alltid til en ny anskaffelse. Noen ganger ligger den største forbedringen i å bruke det virksomheten allerede har, på en bedre måte.

Målet er å gi virksomheten den beskyttelsen og håndteringsevnen den faktisk trenger.

I neste artikkel ser jeg nærmere på oversikt i sikkerhetsarbeidet: Hva kan virksomheten faktisk se, hvor oppstår blindsonene, og hvorfor gir ikke mer data nødvendigvis bedre forståelse av det som skjer?

En samtale verdt å ta?

Står dere foran en sikkerhetsinvestering, eller er dere usikre på om dagens løsninger dekker behovet? Jeg tar gjerne en samtale om hvilke spørsmål det er viktig å avklare før dere går videre.

Transport- og logistikkvirksomheten i denne serien er et fiktivt eksempel, brukt for å gjøre problemstillingene konkrete uten å beskrive en virkelig virksomhet.

Forfatter