Dansk hotelbooking betaler stor løsesum til ransomware-banditter: »Det var det første vi gjorde«

Dansk hotelbooking betaler stor løsesum til ransomware-banditter: »Det var det første vi gjorde«
Illustration: Techotel.
Direktør i it-sikkerhedsfirma advarer mod at betale løsesummer med det samme. Det forbedrer nemlig de kriminelles business case betragteligt.
14. juni 2021 kl. 03:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

»Jeg har overhovedet ikke tid til at tale. Jeg har mange opkald lige nu, og jeg sidder i møde. Jeg skal bruge al min tid på at løse det her,« lyder det fra Techotels direktør, Klaus Ahrenkilde, inden vi bliver enige om at snakke videre, når angrebet på dem er helt overstået.

Techotel leverer bookingsystemet Picasso til mere end 900 hoteller, der lige nu ikke aner, hvilke gæster der kommer i morgen, og hvad de har bestilt. Picasso har nemlig siden i onsdags været lagt ned af ransomware, og backuppen har de ukendte hackere brændt ned til grunden.

»Det er det første, hackerne gør, når de laver den her slags angreb,« lyder det fra Klaus Ahrenkilde.

Inden den korte samtale afsluttes, fortæller han, at Techotel med det samme betalte løsesummen til den endnu ukendte hackergruppe og henviser i øvrigt til selskabets driftsinfo-blog.

Forbedrer hackernes forretningsmodel

Men den tilgang til ransomware-angreb kan ende med at gøre truslen mod andre danske virksomheder mere alvorlig, lyder vurderingen fra Jacob Herbst, der er CTO i it-sikkerhedsvirksomheden Dubex.

»Grundlæggende er det sådan, at hver gang du som virksomhed betaler, sørger man for, at afpresnings-forretningen kan betale sig. Jo flere der betaler, jo bedre er forretningen. Hvis ingen betalte, ville ransomware forsvinde,« siger Jacob Herbst, der omvendt godt kan forstå de virksomheder, der betaler.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
61
20. juni 2021 kl. 15:22

Du har ret. Erindrede bare der var noget med en ransagning af hans diplomatfly i Europa og Frankrig hurtigt var ude og undskylde.

59
20. juni 2021 kl. 14:21

Jeg det er trods alt ved at være en måned siden Hviderusland “kaprede” et passagerfly sidst, og Frankrig kaprede for et par år siden et Peruviansk diplomatfly (med præsident i). Man kan kalde det hvad man vil, men det er ikke sidste gang vi ser kapringer af fly. (Måske ikke med kniv og revolver, men med kampfly i stedet)

58
20. juni 2021 kl. 12:04

Flykapringerne i 70'er stoppede først da man besluttede IKKE at forhandle med terroristerne. Hvis du kaprede et fly, så fik du til sidst ikke noget ud af det, og du var sikker på at dø. Døde civile unødigt? Ja, men flere var døde, hvis kapringerne var fortsat.

Der var også en del flykapringer i 80'erne og 90'erne. Flykapringer blev kraftigt reduceret efter 11. September da det blev klart at nogen flykaprere ikke havde noget ønske om at slå en handel af. Det betød at adgang til piloterne blev fjernet og at piloterne ville forsøge at lande flyet uanset om flykaprerne truede med at slå passagere og kabinepersonale ihjel. Oveni er passagererne blevet mere villige til at handle.

57
20. juni 2021 kl. 11:06

Betaler de i hemmelighed, så implicerer de også f.eks. banker i mulig hvidvaskning, og skjuler ting for revisionen.

56
20. juni 2021 kl. 10:45

Enig, det skal være ulovligt, og bankerne skel helle ikke have lov at være mellemled.

Flykapringerne i 70'er stoppede først da man besluttede IKKE at forhandle med terroristerne. Hvis du kaprede et fly, så fik du til sidst ikke noget ud af det, og du var sikker på at dø. Døde civile unødigt? Ja, men flere var døde, hvis kapringerne var fortsat.

55
19. juni 2021 kl. 21:45

Igen igen synes bitcoins at være knyttet til kriminel aktivitet, og kriminel aktivitet afhængig af bitcoins. Se nu at få lavet et internationalt forbud mod bitcoins og andre ikke sporbare pengetransaktioner.

53
16. juni 2021 kl. 16:47

Hvis man lukker firmaer der negligerer IT-sikkerhed, så dem der ikke gør ffår mere forretning, er det så ikke en win-win?

51
15. juni 2021 kl. 14:25

Og Linux er ikke glad for eksterne (dvs. ikke en del af linux kildekoden) kerne moduler..

Nu skal jeg ikke ind i en længere diskussion omkring licenser men det er ikke blot en diskussion omkring kerne moduler men også en mere grundlæggende diskussion omkring hvorvidt hvilke licenser der er gode og hvilke der ikke er. Jeg har altid savnet pragmatisme fra GPL-crowden helt fra Stallmans tid. Selvfølgeligt ville det være muligt for Linux kernen at have stabile hooks der tillod integration på kerne niveau. På den måde kunne man overkomme issues omkring licenser. Der kræver bare at man netop ønsker at overkommer de issues ...

50
15. juni 2021 kl. 13:26

Hvad mener du? Jeg troede at det var en inkombatilitet mellem licenser, der besværliggjorde ZFS on Linux.

Det er det også. ZFS er CDDL licensieret - og det er ikke kompatibelt med GPL licensen kernen har - så derfor downloader Ubuntu f.ex. kernemodulet til ZFS understøttelse og indlæser hos "brugeren" - der har lov til at bruge koden.. Og Linux er ikke glad for eksterne (dvs. ikke en del af linux kildekoden) kerne moduler..

49
15. juni 2021 kl. 13:24

Man kan med fordel spinne en databaseserver op på sin backupserver, som mounter datasettet og dumper til .sql formatet.

Jeg plejer at prøve at få metrics på alt.. på sql dumps, lader jeg helst backup jobbet (modtager siden) - ifbm. med developdumps bliver lavet, så før jeg kører "cleanup sql kommandoer" på den importerede backup - så tæller jeg antal tabeller, entries mv. - og laver nogle metrics på "indlæst ok", "antal tabeller i schema", "gennemsnit på rækker i tabeller" f.ex. - så jeg nemt kan lave noget overvågning hvis backup'en "virker forkert" - dvs. hvis nogen af disse tal svinger mere end jeg "synes de burde".

Når man alligevel laver developerdumps, er det meget rart.. og i og med developerdumps laves vha. indlæsning af backup - så får man også testet sin backup der. Det kræver selvf. at backup'en KAN indlæses "indenfor 24 timer".. Men hvis den ikke kan det - så BURDE man nok snarere have shard'et og gjort "den del der alligevel ofte bare er readonly" - til faktisk read-only - så man ikke behøver at tage backup af andet end de ændringer der er i ens datasæt, og bare kan nøjes med at køre "developdump-shards" på read-only delen på et mount af readonly prodata'ene.

Snapshots (på SAN/ceph mv.) mv. er ganske praktiske til TB størrelsesdatabaser - det går langt hurtigere at tage backups, mounte disse fra andre servere mv. :)

47
15. juni 2021 kl. 13:14

Man skal bare huske også at have en offlinebackup der bruger en anden "teknik" end ZFS.

Man kan med fordel spinne en databaseserver op på sin backupserver, som mounter datasettet og dumper til .sql formatet.

Og så er det en billig praksis at rotere eksterne backupdiske, til backups af lavere frekvens. Offline krypterede diske er dejligt resilliente overfor alskens ondskab.

Højfrekvens snaps til hurtig reetablering og minimering af datatab

Lavfrekvens eksterne offline diske til maximering af datasikkerhed.

ZFS sync kører typisk:

ssh produktion zfs send | zfs recv

Så et zfs angreb skulle være i en zfs incremental pakke, som ødelægger modtageren med modtagelen.

Og der er faktisk en udbredt udfordring i ZFS med sletning, omdøbning og oprettelse af dataset, som medfører sletning af dataset hos modtageren ved synkronisering.

Og eneste løsning på det problem, som jeg kender til, er at køre ZFS ...på ZFS. Så nedre filsystem backer øvre synkroniserede system op. Ellers kan man ikke genskabe tidligere dataset og nedarvninger, hvis de efterfølgende er slettet.

Den anden vej rundt vil en afsendelse af en backup til en server, der skal reetableres, være uberørt af zfs-sårbarheder, da afsenderen sender en statisk pakke via ssh.

46
15. juni 2021 kl. 13:03

Sikkerhed burde få en post i budgettet i virksomhederne som en særskilt ting, så man ikke bare skal finde det i den alm. it drift budget.

Jeg er ganske, ganske uenig. Sikkerhed er ikke en eller anden magisk sovs som man kan komme med bagefter. Som Klavs Klavsen har eksemplificeret, skal sikkerhed med ind fra starten af. Hele organisationen skal tænke i sikkerhed. At have en post til sikkerhed i budgettet vil være at skyde ansvaret over i ét sted i organisationen. Der er sådan set ikke noget galt i at der er en sikkerhedsansvarlig, men han skal ikke have et budget at bruge (men der skal være budget til at sikkerheden kan være høj nok!).

45
15. juni 2021 kl. 12:24

Og istedet for et dump, som kan være både driftsforstyrrende og vokse sig meget meget stort, så kan man med fordel benytte ZFS under sin database (eller appliklation), og tage komplette snapshots med timeintervaller, eller endnu oftere.

Helt enig. ZFS's mulighed for næsten "gratis" asynkron replikering af filesystemer og "gratis" snapshotting af filsystemer er fantastiske til backup. Så længe man ikke tror at snapshots på produktions serveren udgør backup.

Desværre sker ZFS on Linux på trods af Linus i stedet for i samarbejde med ham. På FreeBSD virker ZFS fantastisk men der synes problemet de manglende ressourcer til udvikling.

Og at den eksterne backupserver, (som selvfølgelig er off-site ift. produktionen) kan pull'e inkremental snapshots med høj frekvens.

Man skal bare huske også at have en offlinebackup der bruger en anden "teknik" end ZFS. Ellers åbner man sig igen for angreb der går gennem ZFS.

44
15. juni 2021 kl. 11:45

Jeg ynder at lave den slags ved at aflevere backup via sftp

Jeg kan anbefale at vende processen om.

Produktionen skal selvfølgelig være så beskyttet som muligt, men det er faktisk vigtigere at backupen er endnu mere beskyttet, og derfor kan man argumentere for at gå den anden vej rundt.

System monitors og backup servere pull'er hvad de skal bruge, og har kun adgang til få nødvendige scripts i produktionen.

Og istedet for et dump, som kan være både driftsforstyrrende og vokse sig meget meget stort, så kan man med fordel benytte ZFS under sin database (eller appliklation), og tage komplette snapshots med timeintervaller, eller endnu oftere.

Det betyder at en kompromitteret eller fejlramt produktionsserver kan rollback til et givent snapshot uden overførsel eller import at samtlige produktionsdata.

Og at den eksterne backupserver, (som selvfølgelig er off-site ift. produktionen) kan pull'e inkremental snapshots med høj frekvens.

Komplet reetablering til frisk databaseserver forløber med komplet overførsel af komprimeret ZFS snapshot eller hele poolen, hvis snaphistorik ønskes bevaret på bekostning af en større filoverførsel.

Føler man sig frisk og er omkostningerne til dobbel serverpark acceptable, kan teknikken udvides til at holde et failover miljø up to date i et sepearat datacenter. Så kan man switche når man mener at have lukket sikkerthedshullet.

43
15. juni 2021 kl. 10:42

Selvfølgelig skal myndighederne passe på os men dit eksempel svare til at politiet skal forhindre at tyve kan gå frit ind og ud af en bank, som har åbne bagdøre og overvågning tyvene kan undgå i månedsvis. Det er altså ikke politiets job at patruljere bankens indgange og lege dørmænd.</p>
<p>De myndigheder du forespørger beskyttelse fra, dem som kan beskytte mod et desideret angreb lavet fra udlandet, er ikke politiet men militæret,

Så hvor ringer du hen, når du er blevet angrebet? og hvad sker der så?

Lad os prøve at opstille en analogi til den analoge verden:

  • Du er godt til at producere en slags vare og service til dine kunder.
  • Derfor har du opbygget en butik, og vil gerne sælge varerne der.
  • En grum røver og forgifter varelageret og produktionen, og kræver løsepenge for at give dig modgiften.

Du gør det du er god til. Det kommer du somregel længst med. Der er nogle risici man tager, når man er en lille butik. Butikken overlevelse handler om kundernes tillid og at du kan levere varen. Hvis det lykkes at modvirke angrebet hurtigt overlever virksomheden. Ellers må den oftest lukke. Ejeren får noget erstatning fra forsikringen, men sjældent nok til at rede virksomheden.

I den analoge verden:

  • Du ringer til politiet, der straks kommer. Om muligt eftersætter røveren. derefter grundigt undersøger for spor. Der sættes et stor apparat i gang, via interpol mm. for at opspore og fange gerningsmændene. Det vil være overordentligt vanskeligt at slippe godt fra at modtage løsesummen, uden at blive sporet.
  • Et hold kemikere og miljøfolk, vil vurdere skaderne og forsøge at sikre, at ingen mennesker kommer tilskade. Evt. finde en modgift.

I den digitale verden:

  • Du ringer til politiet, der en måned senere, oplyser dig om at de ikke kan gøre noget, da det sikkert er udenlandske kriminelle. Det har vi ikke ressourcer og kompetencer til.
  • Landets dygtige sikkerhedseksperter fortæller dig, at du skulle have brugt din tid og penge på dygtige sikkerhedseksfolk i butikken og forsikret dig bedre. "Den butiksrude var vist heller ikke af armeret glas, og hvorfor har du ikke produktionen mindst to steder i forskellige byer, så det ville have taget længere tid for røveren?"
  • Du beskyldes for at være asocial hvis du betaler for at få afgiftet din butik, og i øvrigt er det hele din egen skyld, fordi du ikke har låst dine varer inde hele dagen.

Har jeg overset noget?

41
15. juni 2021 kl. 00:43

Bittorrent bruges til at distribuere pirat film, så lad os lukke Bittorrent, selvom det også bruges til meget ikke ulovligt.</p>
<p>Dollars/Euro bruges af kriminelle til betaling af narkotika, våben osv. Lad os afskaffe Dollars/Euro....

For alle andre finansielle transaktioner har vi alverdens lovgivning der skal begrænse kriminalitet. Det mangler for cryptovaluta. Derfor er cryptovaluta fantastisk til afpresning, hvidvask og generelt overførsel af kriminelle penge. Hvis du laver en cryptovaluta med samme regulering som traditionelle valutatransaktioner så vil ingen sige noget.

Men uden cryptovaluta vil der ingen ransomeware være. Derfor vil cryptovaluta blive banned. Det er bare et spørgsmål om hvornår de vestlige regeringer får nok.

37
14. juni 2021 kl. 17:48

Så gør det simpelthen strafbart at betale løsesum og problemet vil dermed forsvinde af sig selv.

Vil du gøre det strafbart, at indrømme at man har betalt løsesummen? Fordi jeg tror det bliver resultatet i sådan en situation.

Jeg synes det er godt at Techotel indrømme,r hvordan problemet er opstået fortæller om deres oplevelser. Det hjælper nemlig andre virksomheder med at lave deres risiko vurderinger. Så tommel op for det.

I tidens løb, er jeg blevet bedt om at forberede forskellige setups så de kan håndtere diverse ret så usandsynlige senarier. Fordi så mener ejeren af virksomheden, at være helt på den sikrer side. Samtidig blevet der intet gjort, for at afbøde ganske sansynlige senarier, som vil give ret lang nedetid, eller det som er være.

Hvad hjælper det fx med spejlede datacentre, hvis alle medarbedjere har adgang til at logge på begge steder og slette al data. Det er der selvfølgelig ingen medarbejdere der kunne finde på. Men deres computer kan, hvis den bliver bedt om det, af en tyv/virus/crypto bot/whatever.

Fejlen er at man overhovedet i dagligdagen har brug for en adgang, som også giver adgang til at slette data.

35
14. juni 2021 kl. 16:39

Jeg har altid forsøgt at få CI (automatisk test som en del af godkendelsen af features) gjort bedre - og helst rulle servicen man tester op fra grunden med faktiske data.. ( de føromtalte developer dumps fra prod ) - på den måde får jeg samtidigt testet min recovery fungerer - fordi jeg ruller en hel server/service og data op for hver feature der "vil ind i produktion" - fuldstændig automatisk.

Det er meget fint. Men i et stort setup med mange tusinde forskellige services, så er det stadigvæk en kompleks operation. Du skal bare have et par design- eller kodefejl før din recovery ikke bliver konsistent. Derfor er restore fra backup sjældent den først løsning man vælger. Læg oveni man nemt mister data fra de sidste timer, minutter, sekunder.

En forsvarlig opbevaring af backup er i et rum i en anden bygning, end der hvor serverne står, og hvortil der kræves en eller flere fysisk nøgler for at få adgang.

Ja ... men hvis hackerne nu også har inficeret backup serveren. Så hjælper det ingenting. Klavs skriver ovenfor om hans ssh løsning. Hvad hvis nogen fx udnytter en fejl i ssh (eller konfiguration deraf) til at komme ind i første omgang og derefter videre til backup serveren. Så er der selvfølgeligt offline backup, men den vil typisk være mange timer/dage gammel. Ikke acceptabelt i mange situationer.

Hvis det her var nemt som var der ingen der lavede fejl.

34
14. juni 2021 kl. 15:48

Det danske politi er ude af stand til at bekæmpe hackerne.

33
14. juni 2021 kl. 15:45

skal en virksomhed følge dem bliver IT anvendelsen kompliceret og tung

I midten af firserne og derefter kørte vore driftsfolk stabler af store, klodsede removable disks med dagens backup over til en nabovirksomheds aflåste kælder, som flyttede deres backups over i vores aflåste kælder. Sværere var det ikke. Senere blev det endnu nemmere med tapes, som fulgte samme rutine.

32
14. juni 2021 kl. 15:36

Citat fra artiklen: "backuppen har de ukendte hackere brændt ned til grunden"

Hvordan?

En forsvarlig opbevaring af backup er i et rum i en anden bygning, end der hvor serverne står, og hvortil der kræves en eller flere fysisk nøgler for at få adgang.

31
14. juni 2021 kl. 14:50

Selvfølgelig skal myndighederne passe på os men dit eksempel svare til at politiet skal forhindre at tyve kan gå frit ind og ud af en bank, som har åbne bagdøre og overvågning tyvene kan undgå i månedsvis. Det er altså ikke politiets job at patruljere bankens indgange og lege dørmænd.

Enig. Myndighederne kan fortælle folk, at de skal låse og bevogte deres banker. I nogle tilfælde måske kræve det (en cykellås er faktisk lovpligtig - ikke at det hjælper ret meget). Ellers kan de orientere om nye metoder til at bryde ind, og at der er nye tyve i byen (for nu at snakke i lignelser).

Man kan godt stille krav til ofrene. At myndighederne skulle fange hackerne "i luften", er jo netop det kedelige fænomen med FEs "snifferbokse" og andet ubehageligt i it-systemer.

30
14. juni 2021 kl. 14:46

Sagen er, at de fleste firmaer arbejder i fuldstændig blinde når det gælder om risikovurdering, og det er jo netop derfor af f.eks. CFCS eller dedikerede IT-sikkerhedsfirmaer kan bidrage til bl.a. den del af regnestykket.

tjoe.. jeg har aldrig set dem komme med gode løsninger på at forbedre recovery tid og backup dækning..

Jeg har altid forsøgt at få CI (automatisk test som en del af godkendelsen af features) gjort bedre - og helst rulle servicen man tester op fra grunden med faktiske data.. ( de føromtalte developer dumps fra prod ) - på den måde får jeg samtidigt testet min recovery fungerer - fordi jeg ruller en hel server/service og data op for hver feature der "vil ind i produktion" - fuldstændig automatisk.

Så uden ændring af kulturen (og krav om features ændres til også at omhandle krav om backup/recovery test vha. automatisering) - så kan et eksternt firma sige nok så meget..

29
14. juni 2021 kl. 14:37

Hvis det tager dem 16 dage så har de glemt at lave en fuldstændige almindelige risikovurdering af deres IT. sandsynlighed * omkostning hvis det sker.. laver man den beregning er det at sikre at der er backup (og test/stikprøve kontrol) en no-brainer.

Udfordringen er netop at risikovurderingen slår fejl. De 16 dage er måske blevet accepteret fordi risikoen blev vurderet til meget lav, f.eks. en gang pr. 10. år.

Når det så viser sig, at risikoen var langt, lang større, er det nemt at sige, at der er tale om en fejlvurdering. Men ingen i virksomheden vidste bedre på det tidspunkt.

Sagen er, at de fleste firmaer arbejder i fuldstændig blinde når det gælder om risikovurdering, og det er jo netop derfor af f.eks. CFCS eller dedikerede IT-sikkerhedsfirmaer kan bidrage til bl.a. den del af regnestykket.

28
14. juni 2021 kl. 14:33

Jeg foretrækker at have al vores konfiguration mv. som en del af git (gitops) og automatiseret - således at recovery går stærkere (fordi al konfiguration bare udrulles og kan genbruges på tværs) - og på den måde anvender jeg store del af min backup dagligt..

Tilbage står så kun de faktiske data - som oftest er en simpel genindlæsning af en database.. og dem anvender jeg helst dagligt, ved at lave developer dumps (der bliver anonymiseret/ryddet op som nødvendigt) og/eller bruge dem til at rulle et staging miljø jævnligt "til større changes" - eller hvad man nu vil.

Altsammen gratis recovery tests, som en del af hvad man ellers normalt ville gøre - hvis man gjorde det på en fornuftigt måde.. Og en optimering heraf - hjælper også på ens recovery tid, hvis man skulle behøve den "for real".

27
14. juni 2021 kl. 14:29

Sålænge der ikke er nogle ansvarlige myndigheder, der passer på borgerne og virksomheddere, er det et markedsvilkår. Man må betale, eller betale på den hårde måde. Som virksomhed kan det være fatalt.

Selvfølgelig skal myndighederne passe på os men dit eksempel svare til at politiet skal forhindre at tyve kan gå frit ind og ud af en bank, som har åbne bagdøre og overvågning tyvene kan undgå i månedsvis. Det er altså ikke politiets job at patruljere bankens indgange og lege dørmænd.

De myndigheder du forespørger beskyttelse fra, dem som kan beskytte mod et desideret angreb lavet fra udlandet, er ikke politiet men militæret, der som bekendt bygger grænser, bunkers og voldgrave. Jeg er ikke i tvivl om at det også vil være fremtiden indenfor IT, men det høre ikke hjemme i forbindelse med private virksomheder eller tyve og banditter. Skal de "beskytte" os kræver det at myndighederne filtrere data og "beskytter" dig mod data der strømmer ind i landet. Det er at skyde gråspurve med atomvåben at ligge ansvaret for IT sikkerhed hos myndighederne. Ansvaret er først og fremmest Techotel, deres ledelse og dem der har programmeret deres software. Myndighedernes job er at lave love om produktetansvar og putte banditterne i fængsel, medmindre man ønsker en politistat.

26
14. juni 2021 kl. 14:28

Det tager lang tid at reetablere systemerne. I gennemsnit over 16 dage nævnes her

Hvis det tager dem 16 dage så har de glemt at lave en fuldstændige almindelige risikovurdering af deres IT. sandsynlighed * omkostning hvis det sker.. laver man den beregning er det at sikre at der er backup (og test/stikprøve kontrol) en no-brainer.

Hvis det tager 16 dage at lave recovery - så har de glemt at udregne omkostning-per-dag - man skal helst angive recoveyr-tid som en del af sit scenarie - og hvis man angiver 16 dage der, bliver man bedt om at gå tilbage og gøre det bedre (vil jeg håbe :)

f.ex. sætter vi typisk PXE installers (vi bruger razor) og så Puppet til at tage over derfra (når det er VM/fysiske) - og har man styr på den del, tager det altså ikke 16 dage - medmindre man er i et fuldstændigt åbent netværk- hvor alle ens servere er blevet ramt samtidigt (hvilket jo igen vil være absurd - netværkssegmentering "er en ting" af netop sådan en årsag - så en virus eller andet, ikke frit kan sprede sig til alt via samme sårbarhed..

Disse angreb highlighter KUN at der er nogen der IKKE har styr på deres ting.. De har så helt klart sparet penge på driften.. Men forhåbentlig kan det kraftigt øgede fortællinger om dette og GDPR - til sammen gøre at IT begynder at blive taget mere alvorligt..

Hvis nu IT-chefer/bestyrelser/CEO's - rent faktisk KRÆVEDE at en restore test blev udført og der blev taget tid på tiden det tog og lavet opstillinger af "nogle scenarier" (som f.ex. cryptoangreb på medarbejder desktop.. crytoangreb på server osv.) - ) inkl. tid recovery så vil tage..

Desværre bliver den slags sjældent bedt om oppefra - og derfor forbliver fokus på features, features og features.. Og den naturlige prioritering er så derefter..

25
14. juni 2021 kl. 14:13

Det er korrekt, at certifikaterne sikrer en bestemt "performance", men det kan sagtens skrues sammen, så varen kan "modificeres" (indenfor visse rammer el. med krav om prøvning/test), uden at certifikatet ryger.</p>
<p>Metric (kender intet specifikt til IT sikkerhed) kunne jo være, om produktet er "sikkert" - så længe producenten med sine procedurer kan dokumentere at performance er tilstede, kan produktet modificeres uden at certifikatet ryger.

Ja, det har du ret i, og det var egentlig heller ikke min pointe. Så længe det er producenten som foretager modifikationerne, har du ret. Probelmet er når andre - ondsindede - foretager modifikationen. Så er IT systemet ikke klængere compliant. Man kan godt - som du påpeger - lave certificeringsordninger som hærder IT systemer imod dette så de forbliver compliant. Den slags systemer er blot meget besværlige at have med at gøre, og fravælges typisk i de civile anvendelser - hvilket var min pointe.

24
14. juni 2021 kl. 14:00

Problemet er at det er et våbenkapløb, så det at "have styr på backuppen" er et bevægeligt mål. Så vidt jeg forstår (udfra https://www.forbes.com/sites/forbestechcouncil/2021/03/03/backup-is-feeble-protection-against-ransomware/) så går de fleste ransomware-angreb også efter backuppen. Og hvis det er ikke blot er backupfilerne, kan det være efter backupsystemet, således at offline backup, båndbackup, eller hvad det nu er, skal integritetstjekkes konstant og man skal sikre sig at dette integritetssystem heller ikke bliver angrebet.

Det tager lang tid at reetablere systemerne. I gennemsnit over 16 dage nævnes her https://www.coveware.com/blog/2020/1/22/ransomware-costs-double-in-q4-as-ryuk-sodinokibi-proliferate

Derudover er kryptering kun et element af ransomware. Angriberen kan også få adgang til privat og industrihemmelig information hvor trusler om læk kan indgå som en del af afpresningen.

23
14. juni 2021 kl. 13:30

Jeg mener det er bedre at backup systemet selv henter backupfiler. På den måde behøver produktionsserveren slet ikke vide at der findes en backupserver. Det reducerer den mulige angrebsflade.

Det er bestemt også en løsning.. Begge er gode.. Dog betyder det at det er svært at lave restore.. (og det kan være nødvendigt på mørke tidspunkter hvor den backupansvarlige ikke lige er der - så almindelige admins SKAL have adgang til at restore backup).

sftp read-only adgang giver en restore mulighed, for admins der IKKE skal have adgang til at ødelægge backup af sikkerhedsårsager :)

Uagtet foretrækker jeg at lave automatisk backup discovery - så min systemkonfiguration for sikret backup (og ellers beklager sig).. Der er sftp backup script på den server der er sat op nemt.. men man kan godt lave det så det "opdages" at en given server har "en rolle" der gør at der skal hentes en backup fra den og sætte backup serveren op til dette..

22
14. juni 2021 kl. 13:27

Store virksomheder kan forsikre sig mod hackerangreb (se f.eks. Tryg: <a href="https://tryg.dk/erhverv/cyberforsikring">https://tryg.dk/erhverv/cyberf…; ). Problemet her er, at man som virksomhed skal have en omsætning på 100 mio årligt for at kunne tegne sådan en.

I mange mindre pengeinstitutter er netbanksforsikring/cyberforsikring med afpresningsdækning (dog ikke ved stats-drevet afpresning) nu en mere eller mindre fast bestanddel af en almindelig erhvervskonto: F.eks. Lunar og Fælleskassen

21
14. juni 2021 kl. 13:05

Lad den rene kaste den først sten. Det bliver ikke mig.

Tænk sig at man som firma har en hel branch i sin hule hånd og så ikke har styr på noget så 'basalt' som sikker backup !! Håber at de har fået en mega lærestreg ;-)

Hvad ved du om denne sag som vi andre ikke ved? Virksomheden siger selv at den havde backup men at backuppen også blev smadret (på deres BLOG kan man følge kampen for at redde data). Ved du hvad der er sket siden det var muligt for hackerne? Jeg ved det ikke men der skal blot være et enkelt hul før bad-guys er igennem ... er du sikker på at du ikke kunne have lavet samme fejl?

20
14. juni 2021 kl. 12:59

Det er lidt som i de gamle mafia-dag, hvor der opkrævedes "sikkerhedspenge"

Sålænge der ikke er nogle ansvarlige myndigheder, der passer på borgerne og virksomheddere, er det et markedsvilkår. Man må betale, eller betale på den hårde måde. Som virksomhed kan det være fatalt.

Så det hjælper ikke at moralisere, og mane til offervilje, mens vi andre ser pasivt på.

Rigtig mange, specielt mindre virksomhedder, udskyder alt med sikkerhed, og ordentlig kode, til bedre tider.... Hvis de ikke gjorde det, men skulle hyre meget dygtigere udviklere, ville mange af dem ikke klare sig i konkurancen. Det handler for dem om, at levere features, og helst i en fart. De tager en risiko, for at få en chance for at vokse sig store.

Vi må ikke gå med våben, og vi må ikke hyre nogle "IT-rockere" til at holde de andre ude. Vi har valgt en samfundsmodel, hvor staten sørger for vores sikkerhed og udøver den magt, der skal udøves - Det sætter jeg stor pris på.

Det er bare ikke rigtig nået til også at gælde på IT området. Så vi står ved en principiel korsvej; Skal staten sikre os mod ydre trusler? eller skal vi slippe kræfterne fri, og markedsgøre sikkerhed?

Det lader til at være den sidste vej, politikerne ønsker at gå.

Konsekvensen kunne blive at små virksomhedder, må se sig om efter nogen, der vil passe på dem. Og for en passende pris, og uddele "IT bank" til de andre banditter.

Måske med hovedsæde i Nordkorea eller Rusland, hvor man ikke rigtig straffes for at være voldelig på nettet?

19
14. juni 2021 kl. 12:36

Tænk sig at man som firma har en hel branch i sin hule hånd og så ikke har styr på noget så 'basalt' som sikker backup !! Håber at de har fået en mega lærestreg ;-)

18
14. juni 2021 kl. 12:26

Jeg ynder at lave den slags ved at aflevere backup via sftp - da jeg (med proftpd's sftp) kan sætte det op så brugeren der afleverer backup'en KUN kan TILFØJE nye backupfiler og KUN kan læse resten.. Så undgår man at de kan slette backup fra serveren du har backup af :)

Jeg mener det er bedre at backup systemet selv henter backupfiler. På den måde behøver produktionsserveren slet ikke vide at der findes en backupserver. Det reducerer den mulige angrebsflade.

Jeg har rodet en at lave en server til backup af hemmeligheder i privaten. Princippet er at den kun vil snakke med netop den device den netop er ved at lave backup af. Alt andet blokeres (TCP, UDP, ARP, ICMP). Når den er færdig med at lave backup så lukkes netværksinterfacet således at den slet ikke kan tilgås. Ved afslutning af backup placeres en status fil på en fil server sådan at man kan se hvordan backup er gået. Eneste adgang til backup serveren er ved rent fysisk at sætte sig foran den rigtige skærm med det rigtige keyboard.

17
14. juni 2021 kl. 12:09

Har hørt om flere steder der havde backup samme sted som deres servere - så da de fik indbrud, blev også backup'en stjålet :) Måske er det samme sket her.. Backup'en har været et lokalt "mysqldump" - lagt på et NFS share måske.. som derfor lige kunne slettes samtidigt.. dummere er de ransomware folk jo heller ikke :)

Jeg ynder at lave den slags ved at aflevere backup via sftp - da jeg (med proftpd's sftp) kan sætte det op så brugeren der afleverer backup'en KUN kan TILFØJE nye backupfiler og KUN kan læse resten.. Så undgår man at de kan slette backup fra serveren du har backup af :)

Tip hermed givet videre :)

16
14. juni 2021 kl. 12:08

»Folk der laver virus burde være i fængsel!,«

15
14. juni 2021 kl. 11:50

Det var da en naiv idé, selvfølgelig forsvinder problemet da ikke. Hash er også ulovligt, men det er da ikke forsvundet.

Jeg vil våge den påstand at det indirekte er ulovligt, der mangler bare domfældelse på området.

Når nogen betaler til nogen de ikke ved hvem er, så kan det meget let gå til terrororganisationer, ergo er det ulovligt.

Virksomheder der betaler må ikke kunne trække udgiften fra i skatteregnskabet, da de ikke kan dokumentere hvad pengene er brugt til og de ikke har en regning.

14
14. juni 2021 kl. 11:48

Hvor er politiet i sådan en sag?
... eller har de helt givet op?

Hvad kan politiet gøre? Hvis de er heldige så kan de finde en IP adresse i udlandet. Derefter kan man så gå igang med at kontakte myndighederne i det pågældne land. Hvis man sporer det til Rusland så synes svaret at være: "Send os alt hvad jeres efterretningstjenester ved om sagen og så gør vi måske noget (og måske giver vi oplysningerne til hackerne)". Sporing af bitcoins er heller ikke noget man bare gør, med mindre hackerne er komplet idioter.

I praksis er internettet et stort og lovløst område. Da jeg startede med internet var det fantastisk fordi alle opførte sig nogenlunde pænt. I dag er det ikke længer sådan.

Set i lyset af at internettet har fået vital betydning for rigtigt mange lande i vesten, så er vi nødt til at finde en måde at regulere det sådan at vi holder kreativiteten inde og kriminaliteten ude. Indtil videre har det været småt med ideer der balancerer begge behov. I praksis ender vi nok med et anarkistisk internet og nogle tilkoblede net som hver har forskellig regulering.

13
14. juni 2021 kl. 11:35

... eller har de helt givet op?

12
14. juni 2021 kl. 10:12

For rigtigt mange virksomheder vil downtime betyde tabt omsætning. Derfor vil første skridt når sådan noget sker være at sætte både plan A, B og C i gang. En af de planer indeholder vurdering af omkostninger ved at betale hackerne og risiko ved at gøre det. I de fleste tilfælde vil omkostningerne ved at betale være meget lavere end tabet i omsætning.

En af planerne vil også indeholde at rulle backuppen ind. Det kan være ekstremt tidskrævende hvis mange systemer er nede. Læg oveni tab af nyeste data etc.

Lovgivning mod betaling af løsesum vil ikke virke. Betalingen vil altid kunne skjules som konsulentydelser, betaling for værktøjer, etc. Og fordi værdien af at betale vil være høj, så vil virksomheder (og myndigheder) sno sig.

Forbud mod at virksomheder og banker håndtere cryptocurrency vil stoppe ransomware i løbet af få uger.

-----

Herudover en række key points omkring security og recovery:

  • Data-mirroring er ikke backup. Når originalen er smaderet så ryger spejlet også.
  • Online backup skal stadigvæk være off-site og på et andet netværk. Produktionsnetværk skal ikke kunne tilgå backupnetværk. Det samme gælder almindeligt brugte accounts.
  • Backup skal ske i et format sådan at man kan gå et antal versioner tilbage. Igangsættelse af backup og versionsstyring skal styres af backup serveren og ikke af systemer på produktionsnetværk.
  • Netværk bør micro-opdeles med firewalls imellem alle servere. Kun planlagt traffik må foregå.
  • Tilgang til internettet (incl. DNS) bør kun tillades for systemer hvor det er del af forretningsprocessen. IKKE for at hjælpe udviklere.
  • Alt produktionskode udvikles på et separat udvikler-netværk uden adgang til produktionsnetværket. Byggeservere placeres på helt eget netværk.
  • Alt kode der kommer ind i virksomheden sikkerhedsvurderes og reviewes i det omfang kilden ikke er 100% sikker.
  • Hellere have mange admin accounts hver med begrænset access end få med meget access.

Etc. etc. etc.

PS: Cloud gør hverken problemet større eller mindre. Bare anderledes.

11
14. juni 2021 kl. 10:12

@Torben Rune:

Arh, her synes jeg nu, at du skal læse op på, hvordan certificeringsordningerne fungerer - især i produktionssammenhæng.

Det er korrekt, at certifikaterne sikrer en bestemt "performance", men det kan sagtens skrues sammen, så varen kan "modificeres" (indenfor visse rammer el. med krav om prøvning/test), uden at certifikatet ryger.

Metric (kender intet specifikt til IT sikkerhed) kunne jo være, om produktet er "sikkert" - så længe producenten med sine procedurer kan dokumentere at performance er tilstede, kan produktet modificeres uden at certifikatet ryger.

10
14. juni 2021 kl. 09:51

og tak for åbenheden og hvis den forsætter efter restablering så bliver alle klogere.

9
14. juni 2021 kl. 09:08

Som kunde kan jeg se om et potentielt produkt jeg har tænkt mig at købe er CE og UL mærket, men hvordan pokker kan jeg se om det IT mæssig er en gang klamp ?

De mærkningsordninger sikrer at produkterne virker som de skal. Producenterne har ansvaret for mærkningen, og for at produktet lever op til det. Det ansvar forsvinder hvis produktet modificeres.

IT systemer har den udfordring, at de hele tiden "modificeres" - oftest af producenterne, men en gang imellem af andre. Når det sker fungerer produktet ikke som foreskrevet, og producentens ansvar er væk.

Der findes sikkerhedsstandarder man kan anvende til formålet - og der findes også akkrediteringsordninger, men skal en virksomhed følge dem bliver IT anvendelsen kompliceret og tung. I praksis bruges dette kun i militære anvendelser.

8
14. juni 2021 kl. 08:56

Måske var det også en ide at IT branchen blev voksen og begyndte at tænke produktsikkerhed, og at denne blev reguleret ved lov. Hvis man laver en mobiltelefon så er el-sikkerhed, RF sikkerhed og spektrum m.m. reguleret ved lov for at beskytte forbrugeren. IT virker stadig til at være den rene vilde vesten og helt op til hvad de enkelte leverandører og firmaer synes der er godt nok. Som kunde kan jeg se om et potentielt produkt jeg har tænkt mig at købe er CE og UL mærket, men hvordan pokker kan jeg se om det IT mæssig er en gang klamp ?

7
14. juni 2021 kl. 08:52

.. Jævnføre at der ikke kan garanteres at beløbet ikke direkte eller indirekte går til finansiering af terroisme?

Ligesom virksomheder ikke må foretage forretning med embargo-ramte regioner og selskaber er de vel her ude i at støtte hvad der potentielt kan være fremmede statsmagter.

Ud fra deres support side indikerer deres meldinger også at indbruddet har lækket fortrolige oplysninger, hvorfor at de nu har indgivet rapport omkring GDPR brud.

Når man ikke har brug for en rolig nats søvn kan man altid spille hasard med ens backup strategi!

6
14. juni 2021 kl. 08:45

Hvis virksomhedsledelsen risikerer fængselsstraf, mon så ikke langt de fleste vil være tilbageholdende med at betale?</p>
<p>Hvad virksomhedens overlevelse angår, så er det vel det man har forsikring til at tage sig af.

Enig. Straf i den sammenhæng gør ondt værre.

Store virksomheder kan forsikre sig mod hackerangreb (se f.eks. Tryg: https://tryg.dk/erhverv/cyberforsikring ). Problemet her er, at man som virksomhed skal have en omsætning på 100 mio årligt for at kunne tegne sådan en.

Måske det var en idé, at få forsikringsbranchen gjort mere interesseret i dette område, så de - i kombination med en forsinkring - kan hjælpe også mindre virksomheder med at imødegå angreb. På den måde opstår der både en incitament til at få gjort noget ved problemet, og virksomhederne har styrke til at stå imod afpresningsforsøg.

5
14. juni 2021 kl. 08:40

Forstår ikke problemet med backup, den ligge jo ikke online på lokalitet.

Den er altid offline og man mister kun en dags arbejde med nedbrud.

Hvis man altså ikke har så dårlig sikkerhed at indbruddet er gået under radaren i månedsvis

4
14. juni 2021 kl. 08:24

Hvis virksomhedsledelsen risikerer fængselsstraf, mon så ikke langt de fleste vil være tilbageholdende med at betale?

Hvad virksomhedens overlevelse angår, så er det vel det man har forsikring til at tage sig af.

3
14. juni 2021 kl. 07:51

Det var da en naiv idé, selvfølgelig forsvinder problemet da ikke. Hash er også ulovligt, men det er da ikke forsvundet.

Det eneste, der opnås ved at gøre det ulovligt, er at virksomheder i endnu højere grad vil holde angreb for dem selv, så de har mulighed for at betale i hemmelighed, hvis det skulle blive nødvendigt. Og hvis virksomhedens overlevelse afhænger af det, så ville virksomheder lukke, hvis det ikke måtte betale.

Awareness (artikler som denne), uddannelse, fokus og åbenhed er vejen frem.

2
14. juni 2021 kl. 07:30

Håber at virksomhederne snart får styr på backup, procedure, og generelt brugt penge på sikkerhed... Sikkerhed burde få en post i budgettet i virksomhederne som en særskilt ting, så man ikke bare skal finde det i den alm. it drift budget.

1
14. juni 2021 kl. 06:43

"Grundlæggende er det sådan, at hver gang du som virksomhed betaler, sørger man for, at afpresnings-forretningen kan betale sig. Jo flere der betaler, jo bedre er forretningen. Hvis ingen betalte, ville ransomware forsvinde,« siger Jacob Herbst, der omvendt godt kan forstå de virksomheder, der betaler."

Så gør det simpelthen strafbart at betale løsesum og problemet vil dermed forsvinde af sig selv.