BrandStory er et annonseprodukt, produsert etter gjeldende retningslinjer.

Retningslinjer for BrandStory

BrandStory er en markedsføringskanal for annonsører. Tanken bak annonseformatet er at firmaer med komplekse budskap skal få anledning til å gå i dybden på sine temaer, og ha mulighet til å få direkte feedback fra en relevant målgruppe.

Annonsørene er velkomne til å dele innsikt fra forskning og utvikling, refleksjoner rundt sin rolle i samfunnet og tanker om ledelse.

Produktreklame er ikke tillatt i dette formatet. Annonsører kan heller ikke bruke BrandStory som en kanal for tilsvar på journalistikk som utøves på redaksjonelle flater.

Nå skjer hackerangrep hvor intensjonen ikke er å skade IT-systemene dine direkte, men bruke systemene og virksomhetens gode navn og rykte til svindel på Internett. Uten gode sikkerhetsrutiner vil du sannsynligvis verken merke eller finne ut av noen ting før omdømmet er svertet.
Nå skjer hackerangrep hvor intensjonen ikke er å skade IT-systemene dine direkte, men bruke systemene og virksomhetens gode navn og rykte til svindel på Internett. Uten gode sikkerhetsrutiner vil du sannsynligvis verken merke eller finne ut av noen ting før omdømmet er svertet.
Innhold fra annonsør

BRANDSTORY: Akkurat nå misbruker noen kanskje IT-systemene dine umerkelig

Hacker deg for å svindle andre

Er IT-systemene dine kompromitterte? Merker du noe? Neppe. Mange får varsler eksternt fra om at deres egne systemer kjører uregelmessig trafikk på internett.

Har du opplevd at andre varsler deg om feil på dine egne systemer? Vi kan love at det er ingen positiv opplevelse.

Virksomheter som blir hacket ønsker sjeldent å fortelle om det fordi det kan skade omdømmet. Her bruker Basefarm to anonymiserte historier vi har førstehånds kjennskap til for å illustrere hva som kan inntreffe og hvordan vi kan håndtere det.

Ved helt vanlige angrep klarer hackere å få tilgang til servere som de utnytter til forskjellige typer nettaktiviteter. Dette samsvarer ikke med den vanlige forestillingen om at noen gjør et hack og skaper kaos som du umiddelbart merker.

Realiteten kan være tvert imot. Dine egne systemer blir ikke direkte berørt. I stedet blir virksomhetens gode navn og rykte utnyttet. På Internett betyr dette at henvendelser til privatpersoner og bedrifter ute i verden blir gjort fra dine IP-adresser og domenenavn.

Din virksomhet blir avsender av svindel!

Risikerer blokkering

Sikkerhetssystemer der ute kan merke slike ureglementerte henvendelser. Er du heldig, kan du derfor få varsel fra en venn, ektefelle eller forretningsforbindelse om at nettstedet ditt er blokkert hos arbeidsgiveren deres.

Basefarm isolerte den hackete VM-en for å finne spor etter hackeren. Sporene kunne ikke bare avsløre hackerens identitet, men også gi sikkerhetsekspertene idéer til hva de kunne lete etter videre.

Mange har opplevd dette. Dersom nettstedet ikke har en absolutt forretningskritisk funksjon, kan dette gå greit. Da blir oppgaven å ta ned nettstedet og få det opp igjen. Mange kan leve med et nettsted som er midlertidig nede. Det gjelder da å ha høyfrekvent backup og krysse fingrene for at hacket ikke skjedde for så alt for lenge siden, slik at ikke for mange senere oppdateringer går tapt. Alternativet blir å engasjere Basefarm eller andre til å rense opp i databaser og flate filer.

Dersom virksomhetens domenenavn og IP-adresser blir blokkert, er dette imidlertid langt verre enn bare et nettstedsangrep.

Da kan for eksempel også e-poster bli filtrert bort og ikke en gang komme frem til mottakerens søppelpostkasse. At snille e-poster havner i søppelpost-filteret er såpass vanlig at folk ofte gjennomgår filteret for å se om noe er havnet feil eller kikker der hvis de savner en mail. Men, ingenting er å finne i email-klientens spam-boks når henvendelsene er filtrert bort allerede på servernivå. Mailen blir borte uten at du vet at du har et problem.

Feil på enkelt oppsett

Sikkerhetskonsept fra Basefarm

Vi følger våre egne sikkerhetsråd som inkluderer å oppdatere/patche systemer fortløpende. Det gjelder også åpen kilde-kodesystemer hvor man ikke får varsler om oppdateringer fra leverandør.

Vi skanner regelmessig kundenes systemer med Detectify, lar helt ekte mennesker i vårt SIEM-team (Security Incident and Event Management) analysere og vurdere resultatene, fikse feil og anbefale mer langsiktige tiltak.

Vi har overvåking av systemer 24/7 og griper fatt i funn fortløpende.

Vi lagrer backuper lenge. Et hack kan nemlig ha skjedd i god tid før resultatene viser seg. Da kan loggfiler være gode kilder for å avsløre hvem som står bak og hvilken informasjon som er berørt.

De senere årene har vi sett hvordan store, globale virksomheter kan stoppe helt opp etter angrep. Da trenger man folk som kan rykke inn umiddelbart for å løse flokene og få situasjonen under kontroll. Basefarms SIRT (Security Incident Response Team) kjenner kundenes systemer og kan trå til umiddelbart.

Når du ikke steller med IT-sikkerhet til daglig er det vanskelig å innrette seg riktig.

Ta bare noe så IT-enkelt som et Wordpress-nettsted som ikke har oppgaver utover å profilere en bedrift. Nå er ikke Wordpress en sentral tjeneste for så mange Basefarm-kunder, men vi trekker frem eksempelet for å illustrere at selv enkle tjenester kan være utfordrende nok.

Wordpress-nettsteder ligger ofte på webhotell hos MSP-er som Basefarm – Managed Service Provider. Allerede før du bygger eget nettsted, er du prisgitt leverandørens sikkerhetsregime. Du vil nødvendigvis måtte stole på at leverandøren har kontroll. Men, kan du det? Er det godt nok å stole blindt på noen for noe så viktig?

Dersom du kjører inn roboten til Basefarm-partner Detectify, vil du kanskje få røde og oransje flagg opp som du kan sende videre til MSP-en. Men, der risikerer du å bli møtt med et skuldertrekk fordi forståelsen eller kanskje interessen eller viljen mangler.

Wordpress-nettsteder kombinerer flate filer på en filserver og innhold i database. Nettstedet er bygd opp med selve publiseringssystemet, ofte en mal og alltid med plugins. Du får varsler om behov for oppdatering – men, følger du varslene?

Våren 2019 viste det seg at en bredt anvendt Wordpress-plugin hadde sikkerhetsbrister selv i nyeste versjon. Det handlet om en grunnleggende struktur-feil. En fil med et tilforlatelig navn alla cache.php ble sneket inn på filserveren via plugin-en, sendte spam i mange retninger og ga aksess også til andre filer på samme filserver. Krise!

Ettersom man i Wordpress-filer også finner databasepassord i klartekst, er man riktig ute og kjøre uten gode rutiner for backup og restore. Men, det har man jo…vel?

Og, man har vel også installert ulike plugins som etablerer grunnleggende sikkerhet. For, de plugins-ene kjenner man naturligvis til.

Mye verre

Wordpress-eksempelet illustrerer en liten IT-sfære hvor mange verken har eller kanskje skal ha dybdeinnsikt. Det er et høyst reelt eksempel – hvor en sønn med arbeidsplass i «den store, norske banken» sendte faren skjermbilde som viste full blokkering av nettstedet til arbeidsgiveren hans.

Vi kjenner også til et annet case hvor en profilert, internasjonal virksomhet varslet om at kundene deres var blitt utsatt for phishing-kampanjer gjennom e-post, Facebook og Twitter.

Phishing innebærer å lure folk til å gi fra seg sensitiv informasjon som personnummer, kredittkortnummer og passord. Trafikken gikk til et nettsted og derfra videre til et annet, ny-etablert domene hvor kunde ble forsøkt utnyttet. Eieren av nettstedet ante ingen ting før den internasjonale virksomheten tok kontakt.

Det var alvorlig. Det er dessuten og dessverre en vanlig måte å lure på.

SIRT og SIEM

En sårbarhet i et vanlig nettsted kan gi tilgang til filserver hvor også andre filer ligger og kan bli skadet.

Et pust i bakken her. Dette caset og Wordpress-eksempelet viser en verden hvor folk flest og selv ikke IT-folk har oversikt. Det viser at man kan være sårbar selv når man har oppdatert «patchet» programvare og at sikkerheten kan bero på samarbeidspartnere som kanskje heller ikke har alt på stell.

Helt trygg kan man aldri bli.

Men, man kan bli veldig trygg.

Det viser seg i praksis at man kan sikre seg veldig langt på vei ved å holde systemene oppdaterte blant annet ved patching/programvareoppdateringer og oppfølging av funnene fra regelmessige scan med Detectify. Når ikke alle blir så trygge likevel, er fordi de faktisk ikke følger sikkerhetsbristene som blir avdekket.

Utrolig. Men, sant.

Basefarm ble inolvert i caset hvor den internasjonale virksomheten slo alarm. Dersom den hackete virksomheten hadde vært innenfor vårt driftsregime, ville normalt vårt SIEM-team (Security Incident and Event Management) ha oppdaget situasjonen.

Også dersom angrep mot formodning skulle lykkes, har vi et SIRT (Security Incident Response Team) som er godt kjent med kundenes systemer. SIRT-teamet rykker inn for å stoppe videre utvikling, avdekke hva som er berørt, hente fra backup og gjøre annet som får systemene opp i produksjon igjen. Teamet har langt bedre forutsetninger enn utenforstående til å redde dagen. Det er viktig når tiden er knapp.

Ikke rett feilen (med en gang)!

Her arvet vi imidlertid problemstillingen ved overføring til oss fra annet driftsmiljø.

Det første vi gjorde, var å forsikre oss om at feilen ikke ble rettet!

Ja, du leste riktig. For å sikre bevis fikk vi klonet driftsmiljøet (VM-er - virtuelle maskiner). Feilen ble rettet i klonene slik at originalen forble uberørt (riktignok bundet på hender og føtter) for videre analyse.

En Windows Server 2016 med IIS spilte en sentral rolle i hendelsen. Vi fant dessuten at virksomhetens nettstedsprogramvare ikke var patchet - oppdatert – siden 2013. I IT-sammenheng er dette ekstremt lenge siden. Nettstedsprogramvaren utgjorde en tikkende bombe som faktisk hadde eksplodert.

Dessverre forelå bare loggfiler for ca. to måneder, noen av disse fra backup. Loggfiler kan fortelle mye om hvem som har vært på besøk og vi skulle derfor gjerne ha hatt filer fra lengre tilbake. Heldigvis fant vi filen som hackeren hadde lastet opp og som rutet ofrene videre.

Med utgangspunkt funnet kunne vi også skannet serverne for lignende filer. Da gjorde vi flere funn.

Loggene viste også IP-adresser som hackeren brukte og hvilke filer vedkommende fikk tilgang til. Dette er svært sentralt.

Hva kan ha kommet på avveie?

Bevissheten om hva hackere har sett eller ikke sett er meget problematisk. Det tenker vi kanskje ikke så mye på i forveien, men etter et innbrudd så opptar det oss veldig: Hvilke hemmeligheter kan være kommet på avveie? Hvilke personopplysninger kan være stjålet og hvilke konsekvenser gir dette i forhold til for eksempel GDPR-regelverket? Må vi kontakte alle kunder og si at vi kanskje ikke har sikret persondataene deres godt nok, enda det ikke er sikkert at noen har hatt tilgang på dataene?

I det aktuelle tilfellet var heldigvis ikke sensitive persondata berørt.

Historien fortsatte. Vi gravde – og gravde mer. IP-adressene i loggene førte oss til et spesifikt land. Via ulike fora klarte vi å søke oss frem til miljøet som var kjent for nettopp å utnytte sårbarheten vi oppdaget. Før vi visste ordet av det, fant vi også et passord i klartekst som samsvarte med navnet på en kjent hacker.