nrk.no

Tar i snitt over 200 dager å oppdage et datainnbrudd

Kategori: IT-sikkerhet

UTSATT FOR ANGREP: I forrige uke ble det kjent at Stortinget ble utsatt for et omfattende datainnbrudd. Foto: Eirik Pessl-Kleiven


IT-ekspert Håkon Lønmo er bekymret for at mange organisasjoner ikke klarer å fange opp forsøk på datainnbrudd før det er altfor sent.

– For de fleste norske virksomheter tar det lang tid før et datainnbrudd blir oppdaget, og ofte er det tredjepart som varsler dem om at de har hatt et innbrudd, sier Håkon Lønmo til NRKbeta.

Lønmo er direktør for cybersikkerhet ved BDO, ett av tre selskaper som er kvalitetssikret av Nasjonal sikkerhetsmyndighet (NSM) for levering av tjenester for å håndtere IT-hendelser.

Ifølge en IBM-rapport fra i sommer tar det i snitt 234 dager før man oppdager et datainnbrudd i Skandinavia. Når det først er oppdaget tar det i snitt 79 dager å håndtere det.

BEKYMRET: Håkon Lønmo mener flere bedrifter må overvåke hva som skjer i datasystemene slik at de kan oppdage datainnbrudd før det er for sent. Foto: BDO

– Stortinget oppdaget et angrep og varslet fort. Sett fra utsiden ser dette ut som noen som er blant de flinkeste i klassen, sier Lønmo.

Tirsdag forrige uke kunngjorde Stortinget at de ble utsatt for et omfattende datainnbrudd. Foreløpig er få detaljer om innbruddet offentlig kjent, men angriperne skal ha brutt seg inn i e-postkontoene til et mindre antall stortingsrepresentanter og ansatte.

PST har startet en etterforskning der en av hypotesene er at en statlig aktør står bak.

– Enorme mørketall

Thomas Tømmernes holder jevnlig foredrag for næringslivet om IT-sikkerhet. Han leder IT-sikkerhetssatsningen til konsulentselskapet Atea, et annet IT-selskap som er kvalitetssikret av NSM.

Ofte blir han invitert til å holde foredrag etter at en bedrift et utsatt for såkalt direktørsvindel. Det går ut på at en angriper tar seg inn i en virksomhet og utgir seg for å være selskapets sjef. Slik kan en angriper lure en økonomimedarbeider til å overføre pengebeløp på typisk 800.000 til 1,4 millioner kroner til angriperens bankkonto.

ØNSKER ÅPENHET: Thomas Tømmernes ønsker at flere bedrifter åpner opp om datainnbrudd slik at man kan lære av hverandre. Foto: Atea

– Det er enorme mørketall, sier Tømmernes, som forteller at de ofte får vite at flere selskaper har blitt utsatt for dataangrep, men holdt det for seg selv.

– De har ikke anmeldt det og de har ikke sagt det til noen. Det handler om at det er en følelse av maktesløshet, sier Tømmernes.

Viktig med sikkerhetsovervåkning

– Den kritiske fasen for en angriper er når de får et bein innafor. Om innbruddet ikke blir oppdaget da er det stor sannsynlighet for at de kan holde seg skjult helt til skaden er skjedd, sier Lønmo.

Lønmo og Tømmernes mener man må anta at angripere kan komme seg inn i bedriftens systemer, og de anbefaler derfor at man har systemer for å oppdage mistenkelig atferd i IT-systemene. Sikkerhetsovervåkning går ut på å innhente informasjon fra IT-systemene slik at bedriften kan sette små og store hendelser i sammenheng.

Det kan for eksempel være mistenkelig atferd fra en bruker, varsler fra antivirussystemer, eller at det sendes større mengder data ut fra bedriften.

– Et vellykket datainnbrudd vil etterlate seg spor på forskjellige måter. Det som ofte skjer er at sporene ikke blir analysert og sett i sammenheng tidlig nok, sier Lønmo.

Tømmernes i Atea anslår at i underkant av 300 norske virksomheter har systemer for sikkerhetsovervåkning.

– Det er helt krise, sier Tømmernes, som håper andelen går opp.

Les også: Eksperter tror IT-angrepet mot Stortinget kan være politisk motivert

Sju tips for bedre sikkerhet på nett:

  • Bruk to-faktor autentisering der det tilbys
  • Bruk unike passord (ett passord per tjeneste)
  • Bruk passordhåndteringsprogrammer
  • Privat kan du også lage en passordliste med penn og papir, men beskytt dokumentet som et verdipapir
  • Alltid bytt standardpassord på produktene du kjøper
  • Du kan også sjekke om ditt brukernavn og passord kan være tilgjengelig for andre ved å bruke tjenesten ‘;–have i been pwned?
  • Bruk sterke passord som er vanskelig å gjette/knekke

Kilde: Nasjonal Sikkerhetsmyndighet

8 kommentarer

  1. Jeg forstår ikke hvorfor praktisk talt ingen slike lister over sikringstiltak har med kryptert epost, og digital signering (som er en variasjon over samme basis-teknologi).

    Vi har hatt teknikkene klare i godt over tretti år, internasjonale standarder nesten like lenge. Alle større epost-klienter fikk støtte for det siden før årtusen-skiftet. Installasjon tar maks ti sekunder (for Windows: dobbeltklikk på sertifikat-fila du har fått tilsendt).

    Det var en viss bruk av kryptert epost for 15-20 år siden. I dag ser vi det så å si aldri. Hvorfor ikke?

    Svar på denne kommentaren

    • Erlend Andreas Gjære (svar til keal)

      Tre akademiske artikler som svarer på spørsmålet ditt, hvorfor kryptert e-post aldri har tatt av:

      Why Johnny can’t encrypt (1999):
      https://www.usenix.org/conference/8th-usenix-security-symposium/why-johnny-cant-encrypt-usability-evaluation-pgp-50

      Why Johnny still can’t encrypt (2006):
      https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf

      Why Johnny still, still can’t encrypt (2015):
      https://arxiv.org/abs/1510.08555

    • Interessante artikler – takk for linkene! – men i all hovedsak diskuterer de jo grensesnittet i ett spesifikt system, utviklet av (og i betydelig grad for) et svært datateknisk orientert miljø, der utviklerne sjelden har med ikke-tekniske sluttbrukere i utforming av arkitektur og design. Studiene viser hvorfor Johnny ikke kan bruke PGP.

      Vi klarer jo å kryptere på link-nivå (TLS / HTTPS); den vanlige bruker merker fint lite til det. Hva er egentlig det store problemet med å få S/MIME tatt i bruk?

      UI-problemene i PGP var så å si helt fraværende da jeg brukte SMIME under Windows. Jeg kjøpte et X.509 email-sertifikat og dobbeltklikket fila – så var jeg i gang. Jeg behøvde ikke vite noe som helst om ulike nøkkeltyper og hvordan de ble generert, nøkkellengder og lignende teknisk info. (Det var tilgjengelig, om jeg var ivrig, men det forstyrret ikke det ordinære UIet).

      Sendte jeg epost til en i kontaktlista mi som jeg hadde nøkkelen til, kom det opp en avkryssing at meldingen ville bli kryptert (hvis jeg ikke fjernet krysset). Kom det inn en melding med en nøkkel (som var ny for meg) i signaturen ble jeg spurt om den skulle legges inn i kontaktlista, naturligvis med default Ja. Utgående ukryptert epost (fordi jeg ikke hadde mottakerens nøkkel) fikk default en signatur på bunnen med min nøkkel; det kunne slås av både generelt og for individuelle mottakere om jeg ikke ville ha det.

      «Til hverdags» behøvde jeg ikke gjøre noe som helst etter at sertifikat-fila var dobbeltklikket. Slik som jeg stolte på at postklienten holdt passordet til POP-kontoen min for seg selv, kunne jeg gitt den adgang til privat-nøkkelen min, men jeg valgte å ha et passord på det (i tilfelle noen skulle sette seg ned ved min inloggede PC og begynne å rote) – jeg husker ikke om default var med eller uten passord.

      Det var bare en liten håndfull «manuelle» funksjoner, rettet mot bruker-funksjonene, uten tekniske elementer:

      En avkryssing for signering av utgående post – normalt slått av for ukryptert post. Krysset jeg av, ble meldingen signert (fortsatt ukryptert). For post som normalt ville gått ut kryptert (fordi jeg hadde mottakerens nøkkel) kunne jeg fjerne (kun) krysset for kryptering for en signert, ukryptert melding, eller også fjerne kysset for signering, for en ukryptert, usignert melding.

      Så var det katalogsøk-funksjon for å finne nøkkel til nye mottakere. Men X.500/LDAP ble aldri den globale distribuerte katalogen den var designet for (slik som DNS), så de var ikke noe særlig å søke i. De aller fleste som kunne handtere kryptert post publiserte nøkkelen sin i signaturen, så behovet var lite.

      Du kunne også dekryptere en melding permanent (default ble meldinger dekryptert først ved lesing på skjermen; i innkurven forble de krypterte) eller eksportere den til en egen fil.

      Kort sagt: Det fantes epost-klienter med et UI for kryptering så enkelt at bestemor kunne handtert det uten vanskelighet (så sant hun kunne bruke en Windows-PC i det hele tatt).

      PGP vant ikke hjertene til ikke-tekniske brukere mye av samme grunn som andre systemer av Unix/Linux/FOSS-opphav så å si aldri har erobret skrivebordet: Utviklerne har ikke god kontakt med skrivebords-brukere, og lager UIer for seg selv, ikke for bestemor.

      Andre lager UIer for bestemor. Men selv med det klarer ikke kryptert epost å slå gjennom. En mulig grunn er at ‘ingen’ markedsfører X.509 epost-sertifikater; folk vet ikke at muligheten finnes og hvor de skal gå for å få seg et sertifikat. Det burde være en offentlig tjeneste. Men kanskje myndighetene egentlig ikke ønsker at all epost skal være ende-til-ende-kryptert?

    • Håkon Lønmo (svar til keal)

      Kryptert e-post tok aldri av på samme måte som HTTPS for krypterting av websider. Først og fremst på grunn av PKI-utfordringen som må på plass for å sende kryptert e-post til andre virksomheter. Men de siste årene har overgang til skybasert e-post gjort kryptering mer tilgjengelig for hvermansen. I første omgang krypterting med STARTTLS, men også ende-til-ende-kryptering med S/MIME.

      Office365 Message Encryption støtter for eksempel å sende kryptert e-post med tilgangsstyring utenfor egen organisasjon.
      https://www.microsoft.com/en-us/microsoft-365/exchange/office-365-message-encryption

      Likevel er utfordringen i nyhetssaken her at når uvedkommende oppnår tilgang til din e-postkonto, så er det et ID-tyveri som skjer. De får tilgang til din private nøkkel og kan lese det samme som du har tilgang til, selv om e-posten er kryptert.

      Flere tjenester fra det offentlige og bankene benytter digitale postkasser som krever pålogging med BankID/ID-porten. Slike løsninger er absolutt å anbefale for sensitiv informasjon siden en hacket e-postkonto ikke automatisk gir tilgang til den sensitive informasjonen.

    • Brorparten av sikkerhetsproblemene har sin historiske rot i at IT-folk tenkte (og tenker) i utstakt grad på samme måte som ‘Sjef’. Ikke i kroner og øre, for å spare arbeid, kunne vise mer imponerende resultater raskere, går vi altfor ofte på akkord med sikkerheten.

      Eksempel: Mange sikkerhetsbrudd skyldes varianter av ‘code injection’ – vi sender data fra en bruker rett videre til en tolk, det er så enkelt å greit! I gamle dager mottok vi binære koder som måtte eksplisitt analyseres; det er så mye mer lettvint å sende kode/data rett videre, uten engang å ‘vaske’ dem (jfr. https://xkcd.com/327/).

      Vi knives om å være super-økonomiske, slik som ‘Sjef’, bare i mikrosekunder istedetfor kroner: En viktig grunn til at C skjøv ut Pascal var at siden C ikke gjorde noen form for sjekk på f.eks. array-indekser, og elendig type-kontroll, ‘vant’ C i alle hastighets-tester – men svært ofte på bekostning av sikkerheten.

      Mange sikkerhetsproblemer er knyttet til minneallokering. Det kunne vært handtert av automatisk minneadministrasjon, slik det er i en del språk. Men det kan koste oss diverse mikrosekunder, og det har vi ikke råd til hvis vi skal vinne hastighets-testene.

      Vi har trygge protokoller – men de er for komplekse til at en student kan implementere dem som et prosjekt-arbeide (f.eks. X.400).

      Vi har sikre mekanimer for innlogging / autentisering over nett, men det krever mer enn å sende et passord i klartekst fra en HTML form; du må inkludere f.eks. Kerberos-funksjonalitet på begge sider.

      Legg merke til hvor mange Internett-protokoller som starter med «Simple» eller noe lignende. Simple Mail Tranfer protocol, Simple Network Management Protocol, Simple File Transfer Protocol (lite i bruk i dag), Lightweight Directory Access Protocol, … Andre burde hatt «(too) Simple» i navnet, f.eks. NFS.

      At Internett-familien seiret i nett-krigene for 25-35 år siden var så å si aldri at protokollene hadde overbevisende tekniske meritter eller større funksjonalitet, men at de var så primitive at enhver IT-student kunne implmentere dem; det var dem han kjente til da han ble uteksaminert. I tillegg til at de var primitive kom at dokumentasjonen var fritt tilgjengelig – konkurrentene priset seg ut av markedet når universiteter og høgskoler ikke hadde råd til å kjøpe spesifikasjons-dokumentene.

      Så vi IT-folk kan slett ikke toe våre hender og peke på sjefene/økonomene. Vi har minst like stort ansvar selv.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.