Demant blev ramt af ransomware: »Jeg mærkede i maven, at det ikke var helt godt«

18. juni 2021 kl. 03:4522
Demant blev ramt af ransomware: »Jeg mærkede i maven, at det ikke var helt godt«
Illustration: Demant.
Den danske virksomhed Demant overlevede et hackerangreb med et tab på mere end en halv milliard kroner. Her er, hvad vi kan lære af angrebet.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Et af danmarkshistoriens mest omkostningsfulde cyberangreb med ransomware begyndte med en sms fra høreappa­ratgiganten Demants asiatiske afdeling.

Angrebet gik nemlig for alvor i gang om natten, dansk tid, mens Solen stod højere i Asien.

Sms’en advarede dengang om en massiv 'business critical', som man kalder et it-angreb, der rammer kerneforretningen. Og så brød et månedlangt helvede ellers løs. Et helvede, der endte med at koste Demant 550 millioner kroner i tabt salg.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
22 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
22
21. juni 2021 kl. 12:22

Pointen er bare at hvis man kan finde fejl i den software der kører på din lokale boks så kan man også finde fejl i softwaren der styrer din SAN.

Sagen er ikke om der teoretisk set kan findes fejl, som kan give adgang.

Sagen er heller ikke at opnå 100% resilliens.

Det drejer sig om at verificere at backup-systemerne er adskilt, så flere sjældne eller usandsynlige hændelser skal finde sted i serie, før et katastrofalt tab hænder.

Der er en upper bound for sikkerheden, som de fleste admins vil være aldeles enige i:https://xkcd.com/538/

Og så kan man anstrenge sig for at hæve lower bound, ved teknisk solide strategier, herunder adskillelse af systemer, adskillelse af adgang, og evt. i sidste ende roterede offline offsite diske.

Problemet er at man lægger en hel del tillid til enkelt systemer og protocoller.

Nej, det er ikke et problem.

Det er et vilkår for eksistens.

21
20. juni 2021 kl. 10:28

Du har misforstået hvordan snapshots fungerer (på SAN, Ceph mv. ). I modsætning til hvor snapshots er håndteret af filsystemet eller det lokale operativsystem (dvs. ZFS, LVM, BTRFS) - så er snapshot på NAS/SAN/Ceph

Det forstår jeg selvfølgeligt godt. Pointen er bare at hvis man kan finde fejl i den software der kører på din lokale boks så kan man også finde fejl i softwaren der styrer din SAN. Og det behøver ikke engang at være fejl i softwaren på SAN'et. Det kan bare være at "bad guys" er kommet ind og fanger når en admin logger på SAN'et. Vupti ... så er han inde. De fleste har ikke tilstrækkelig IT hygiejne til at holde den slags fuldstændigt adskilt.

Problemet er at man lægger en hel del tillid til enkelt systemer og protocoller. Det bryder jeg mig ikke om. Normalt når vi designer for reliability så går vi ud fra at kun en (i sjældne tilfælde to) uafhængig fejl kan opstå indenfor et givet tidsrum. Den slags ryger ud af vinduet når hackere hoarder day zero exploits ... så er man nødt til at gå ud fra at rigtigt mange huller bliver udnyttet på samme tid. Huller som man ingen chance har for at kende på forhånd ...

20
20. juni 2021 kl. 08:31

Ransomware kan selvfølgeligt komme ind på alle mulige måder. Og alt efter metoden er der intet til hinder for at den krypterer en diske på blok niveau. Så ryger snapshots også.

Du har misforstået hvordan snapshots fungerer (på SAN, Ceph mv. ). I modsætning til hvor snapshots er håndteret af filsystemet eller det lokale operativsystem (dvs. ZFS, LVM, BTRFS) - så er snapshot på NAS/SAN/Ceph - håndteret på det remote system - og det fungerer ved at BLOKKE forbliver de samme imellem filsystemet og snapshottet INDTIL hosten (den har KUN har adgang til block devicet og dermed filsystemet derpå) skriver til en block - så lades den gamle block BLIVE (hvorefter snapshots begynder at optage plads - de koster 0 bytes fra start og tager derfor kun sekunder at oprette) - det kaldes Copy-On-Write.

Så NEJ ransomware der KUN har adgang til filsystemet (hvilket er sådan SAN/NAS mv. bruges) - kan IKKE ødelægge snapshots (medmindre det snapshot bliver adminstreret af samme OS - og det gør det IKKE når det gælder SAN/NAS/Ceph.

19
20. juni 2021 kl. 00:59

Altså ransomware kan KUN kryptere filer ved at "bryde ind via en åben port/service - f.ex. et website" ELLER ved at nogen kører den fordi de klikker på et link eller en vedhæftning i en email der kører den på laptop'en/arbejdscomputeren - og denne har disse filsystemer mountet lokalt. (eller ved at agere som gammeldags vira der scanner efter netværkstilgængelige services på lokalnettet og dermed spreder sig).

Ransomware kan selvfølgeligt komme ind på alle mulige måder. Og alt efter metoden er der intet til hinder for at den krypterer en diske på blok niveau. Så ryger snapshots også.

I praksis kan der være fejl i ssh, nfs, zfs, openvpn, linux-kernel, kubernetes, postgres, mariadb, etc. (og selvfølgeligt også i kommercielle produkter). Hvis man kan tjene mere 1-10mio. USD hver gang man "får bid" med ransomeware, så har man råd til at have en flok udviklere siddende der leder efter fejl. Måske fortæller man ikke engang udviklerne hvorfor de leder efter sikkerhedsfejl.

Når man har fundet fejl i et antal produkter så går man i gang med at automatisere angreb og først når man et automatiseret angreb der udnytter alle de sikkerhedshuller man har fundet slipper man skidtet løs på nettet. Og først der vil nogen have mulighed for at opdage hvad man har gang i ...

18
19. juni 2021 kl. 21:49

Jeg mener netop filsystem. Om det er et SAN, en Windows Server eller et tredje; fælles er at der ligger data der kan blive ramt af eksempelvis ransomware, menneskelig fejl mv. Angrebsvektoren behøves ikke nødvendigvis være selve frontend softwaren, men derimod den computer du sidder med, og administrere virksomheden.

Altså ransomware kan KUN kryptere filer ved at "bryde ind via en åben port/service - f.ex. et website" ELLER ved at nogen kører den fordi de klikker på et link eller en vedhæftning i en email der kører den på laptop'en/arbejdscomputeren - og denne har disse filsystemer mountet lokalt. (eller ved at agere som gammeldags vira der scanner efter netværkstilgængelige services på lokalnettet og dermed spreder sig).

et SAN har kun 2 angrebs vinkler.

1 - den uddeler devices - hvorpå computere ligger et filsystem - dette kan være mountet på en server eller en laptop og kryptering af disse er netop det snapshots beskytter i mod - da ligger på det underliggende block device - så dem kan du ikke gøre noget imod når du angriber filsystemet - så derfor kan sAN admin ALTID gå ind via controller/manager interface og restore til tidligere snapshot og dermed overskrive/tilbageføre alle ændringer til filsystemet (eller mounte et snapshot et andet sted og tilbageføre "dele".

  1. controlleren (dvs. de ip+porte den service lytter på) kan angribes - hvis man finder en angrebsvinkel på den. Denne kan IKKE nås fra desktop computere normalt - og hos os f.ex. lukker vi den slags adgang inde bag en service der kræver at man har en yubikey i sin computer og fysisk rør den - får at få adgang. (yubikeys anvender vi til AL adgang - også til git commit signing - det er super brugervenligt og øger sikkerheden imod arbejdscomputer indbrud betydeligt).

Jeg har lidt svært ved at følge din push/pull rettigheder til din backup. I første omgang var et sekundert SAN som det primære pushede til; og et restore var et pull fra den primære?

Jeg har anvendt mange forskellige metoder.. det afhænger af hvilket system jeg har skullet arbejde med.

Til vores eget anvender vi primært Borg - i append-only mode - på den måde kan klienten push'e backup fint - men kan ikke slette noget på offsite lokationen (medmindre de finder en sårbarhed i borg). Det er også det vi anbefaler vores medarbejdere (vi har en backup server alle medarbejdere kan smide backups til - og da borg krypterer hos klienten - kan vi ikke læse backup'en - men det gør det nemt for medarbejdere at have deres private backups et ekstra sted, hvis de vil :)

I AWS setups - der ikke ønsker borg - kører vi et seperate script der sync'er snapshots til offsite "hele tiden" - så der ville de skulle hacke en desktop der havde adgangen til aws - logge ind der og slette.. (ikke helt så nemt :)

De fleste ting har mulighed for at få sat op så man kan append-only - eller så backup pull'es (så angriber dermed ikke kan slette backup'en der er offsite).

Ved backup, skal produktion ikke have adgang til backup netværket. Backup'en skal pull fra produktion. Ved restore skal backup kunne push til produktion. På den måde sikre du dig at produktion aldrig vil kunne ødelægge backup'en.

Jeg stoler nok på Borg - til at jeg har add-only mode på den - men flere alternativer bruger pull modellen - og det er ganske rigtigt den bedste metode (da man så slet ikke har nogen service man kan forsøge at angribe for at nå til offsite backup'en :)

17
19. juni 2021 kl. 13:54

Så du mener ikke hvis filsystemet bliver ramt, men hvis SAN controlleren (eller i cephs tilfælde - hvis manager instanserne - dvs. selv ceph backend) bliver hacket ?</p>
<p>Det ville være rigtig skidt - helt enig. Der kan en "pull sync" af backup hjælpe (så kan det aktive system ikke nå backup systemet - og ellers bånd som du siger.

Jeg mener netop filsystem. Om det er et SAN, en Windows Server eller et tredje; fælles er at der ligger data der kan blive ramt af eksempelvis ransomware, menneskelig fejl mv. Angrebsvektoren behøves ikke nødvendigvis være selve frontend softwaren, men derimod den computer du sidder med, og administrere virksomheden.

Jeg har lidt svært ved at følge din push/pull rettigheder til din backup. I første omgang var et sekundert SAN som det primære pushede til; og et restore var et pull fra den primære?

Ved backup, skal produktion ikke have adgang til backup netværket. Backup'en skal pull fra produktion. Ved restore skal backup kunne push til produktion. På den måde sikre du dig at produktion aldrig vil kunne ødelægge backup'en.

16
19. juni 2021 kl. 12:20

Jeg tror vi snakker forbi hinanden. Jeg henviste til at dit filsystem i form af SAN, hvis det bliver ram af ransom.

Så du mener ikke hvis filsystemet bliver ramt, men hvis SAN controlleren (eller i cephs tilfælde - hvis manager instanserne - dvs. selv ceph backend) bliver hacket ?

Det ville være rigtig skidt - helt enig. Der kan en "pull sync" af backup hjælpe (så kan det aktive system ikke nå backup systemet - og ellers bånd som du siger.

Derudover så skal man have principle of least priviledge netværksmæssigt.. INGEN pods skal kunne nå controller på dit storage (udover den ene der "bestiller diske" i det).. På den måde kan du ikke via én hacket website/service nå controlleren og dermed skal du igennem "et par stykker" - før du overhovedet kan snakke med controlleren for at forsøge at hacke den.

Hvis nogen får hacket deres SAN - formoder jeg at controller/management ip+porte har været alt for frit tilgængelige.

Vi satser på at lukke ting ned netværksmæssigt - så der er "defense in depth" - og så have styr på at holde ting opdateret - for at undgå kendte sårbarheder ihvertfald.. Så skal angriberen alligevel finde mindst 2-3 "rigtig gode" 0-day sårbarheder i forskellig software - før de kan nå indtil f.ex. SAN controller/Ceph management porte.

De fleste backups er database backups - og der push'er jeg til en "add-only" service (såsom sftp) - så en angriber ikke kan smadre backup'en.. Man kunne også sagtens lave en pull istedet (der kan snakke med k8s og spørge "hvad den skal pull'e".. (som jeg har bygget før i puppet land) - hvor backup'en bare "opdager via puppetdb" - hvad den skal ud og hente.

Intet er perfekt - men vi forsøger at indtænke "dybden" i sikkerheden - og hele tiden justere, forbedre.. inkl. overvågning der forsøger at fange når nogen laver en fejl, og at lære alle at hvis de ser "noget underligt" - så formod ikke - spørg istedet og betvivl altid.. Så vi hele tiden forbedrer os..

IT er en stor opgave og stabil drift kommer ikke af "fire and forget" - men et løbende arbejde med at forbedre organisationen hele tiden - og hele tiden automatisere "nye problemer man opdagede".. justere ting efter som opdateringer/ny software giver nye muligheder osv. osv.

15
19. juni 2021 kl. 11:45

crypto angreb kan kun kryptere det aktive filsystem

Jeg tror vi snakker forbi hinanden. Jeg henviste til at dit filsystem i form af SAN, hvis det bliver ram af ransom. Det du omtaler for mig lyder mere som HA end en reelt backup. Kan dit primær SAN blive ramt, kan serveren pushe ransom til dit offsite også. Det skulle angiveligt have write permissions.

Jeg har arbejdet med Enterprise backup og derfor noget jeg brænder for. Jeg har set sysadmins, der har wipet hele deres SAN, så menneskelig fejl kan også forekomme. Derfor anbefaler jeg altid mindst 1 backup, gerne 2 og placeret på tape og offline (cold). Det kan ikke hackes.

14
19. juni 2021 kl. 11:06

Du har åbenlyst mere styr på dine egne løsninger end undertegnede som også efterhånden er langt fra det operationelle. Alligevei har jeg svært ved at se at et angreb á la Demants ikke også vil være ekstremt dyrt i din verden. Både angreb mod din Kubernetes installation eller din SAN synes at kunne give seriøse problemer.

Egentlig ikke - når man har snapshots hele tiden.. Man skal dog lige have "crypto-dimmeren" ud.. og i Kubernetes land "sletter" man bare den pod (svarende til en VM) der er ramt - og så ruller kubernetes en ny en op for dig.. Problemet er så bare at du hurtigt skal have fundet ud af hvordan den kom ind - for at lukke det hul.. Men recovery er super nemt i kubernetes land :)

  1. service er død..
  2. opdag at det er fordi filsystem er "smadret/krypteret"
  3. reetabler filsystem fra snapshot via admin-adgang i kubernetes
  4. slet smadrede service pods (nedskaler til 0 og bed k8s skaler op igen)
  5. voila.. (og finde så lige kilden - før lortet kommer ind igen..

Pkt. 5 er jo straks sværere.. forhåbent er ens logs en god kilde til info - inkl. logs af al ip-trafik der blev forsøgt (og afvist) - fordi man har ingress+egress filtrering på alle pods - så de KUN har netværksmæssigt adgang til de få ting de skal bruge (og man derfor gerne skulle opdage hvis et angreb forsøger at "angribe andre ting/scanne efter porte". (i kubernetes ligger logs UDENFOR pods - og vi streamer til central lokation)

Så er der en masse detaljer om "defense in depth" - og kubernetes er docker baseret - så man skal helst undgå at ens pods (docker) services kører som root for at minimere docker escapes.. og er man i tvivl om det - skal man wipe hele den k8s node den docker lå på (heller ikke svært - bare lidt flere pods der skal dræbes)..

Det er "nemt at designe" - men tager tid at bygge og kræver løbende vedligehold.. Efter at jeg har bygget "hen i mod" den slags i 20+ år som konsulent - så startede jeg et firma hvor vi bygger det samme - og forærer det til ALLE kunder - og genbruger det samme på tværs, så vi kan dele alle løbende forbedringer med alle kunder og IKKE skal genopfinde/re-implementere noget vi HAR gjort gør - men i stedet får tiden til at lave de løbende forbedringer der skal til.. Det har gjort livet meget sjovere for mig og mine medarbejdere :)

13
19. juni 2021 kl. 11:01

Hvis dit filsystem bliver ramt af ransomware, dvs. mange databaser og andre services rammes, hvilken backup løsning har I og hvilke tanker har du gjort om genetablering af infrastrukturen?

crypto angreb kan kun kryptere det aktive filsystem - så der er snapshot rigeligt - så med et cronjob der laver nyt snapshot hvert 5. minut - kan vi altid rulle tilbage til det seneste "gode snapshot".. (det kan ikke gøres fra den enkelte server de har hacket - men kan gøres som sysadmin).

Det svarer fuldstændig til at restore fra backup - men tager kun få sekunder af skifte til et snapshot i filsystemet.

Mht. reetablering af det hele kører vi offsite async (pga. write performance tab ved sync offsite).

Hvis du bruger ZFS - kan du bruge ZFS sync - for at pushe (async) til offsite location "pusher kun manglende writes, så kan godt gøres kontinuerligt - dvs. du vil højst mangle få sekunders writes".. Ligeledes kan Ceph køre async mirror mode.. og det kan SAN og NetApps også.

Og så have et aktivt kubernetes cluster på 2 lokationer - og som en del af major kubernetes opgraderinger (skal gøres hver 3-6 måned) flytter vi alle services til 1 af de 2 aktive clustre (og opskalerer det midlertidigt eller lever med manglende reservekapacitet) og sletter det ene cluster og re-installerer fra bunden på ny version (for at lave recovery test af på k8s version). Det tager ikke særlig længe.. Vi bruger KOPS til cloud kubernetes management og Puppet til vores fysiske/VMs hos Hetzner.

det drejer sig om at ensrette hvad man anvender af teknologier - af dem der kræver backup, så man kan bruge samme metodik til "så meget som muligt". Her er kubernetes fantastisk - og alt kan efterhånden køre i docker - og dermed i kubernetes.

12
18. juni 2021 kl. 23:44

i de fleste operator'er til kubernetes - til mysql og postgresql - der sørger den for at når du kører master/slave og "af en eller anden grund 'rydder en k8s node' - så bliver der automatisk rullet en ny slave op - fra backup'en (som jo kører automatisk) og derfra ruller den op fra binlog - som har ALLE writes indtil sidste sekund.

Du har åbenlyst mere styr på dine egne løsninger end undertegnede som også efterhånden er langt fra det operationelle. Alligevei har jeg svært ved at se at et angreb á la Demants ikke også vil være ekstremt dyrt i din verden. Både angreb mod din Kubernetes installation eller din SAN synes at kunne give seriøse problemer.

10
18. juni 2021 kl. 15:11

Men det hjælper dig jo ikke hvis nogen sletter data fra din database ... så ryger data begge steder. Min pointe er blot at fint at du har tænkt over tingene, men at starte et firma fra scratch er en dyr opgave. Og man taber en masse data.

i de fleste operator'er til kubernetes - til mysql og postgresql - der sørger den for at når du kører master/slave og "af en eller anden grund 'rydder en k8s node' - så bliver der automatisk rullet en ny slave op - fra backup'en (som jo kører automatisk) og derfra ruller den op fra binlog - som har ALLE writes indtil sidste sekund.

Binlog sætter du op til at den skrives til en seperate volume - som du snapshot'er f.ex. hvert 5 minut (snapshots på SAN/Ceph/NetApp) er gratis - og SKULLE nogen så wipe din db OG slette dine binlogs - vil operatoren kunne køre en ny op for dig fra backup+binlogs (hvor du lige skal restore det relevant snapshot på ~0,5) -og så har du re-installeret fra scratch.

Samme type scripts har fandtes i mange år til databaser på VM/fysisk - det er bare blevet gjort mere automatisk/nemmere i Kubernetes - så derfor foretrækker jeg det.

samme filsystem som binlog ligger på - ligger dine "fildata" også på - og her er daglig backup + snapshot interval'er lige så nemt.

snapshots er også den super nemme måde at tage backup af TB størrelse databaser (og databaser generelt) - da man så bare snapshot'er DB'en (tager et sekund hvor man fryser writes så snapshot er konsistent) - og så ruller en ekstra instans op - til at tage backup'en - så produktionen aldrig stopper når man tager backup :)

Du skal selvf. finde ud af HURTIGT hvorfra angriberen kom ind - for ellers kommer de jo bare tilbage igen :)

Her er firewalling imellem ALT super vigtigt -s å man STRAKS ser - når en hvilken som helst maskine forsøger at tilgå noget den IKKE PLEJER.. (og det vil blive afvist).

Det er heller ikke svært - alt vi opsætter VM/fysisk/k8s - har firewall regler med der styrer hvad den må.. og vi åbner helst ikke bare for alt - netop fordi det gør det umuligt at vide hvis man er blevet angrebet.

9
18. juni 2021 kl. 14:47

ja selvfølgelig.. når det er databaser - så kører vi master/slave (i kubernetes) - som kan lave automatisk failover (man skal alligevel have High-Availability) - og hvis man har behov for write skalering - kan man køre mysql med Galera istedet for (3-way writes) - og derfor kan man altid slette en given instans.. også uden nedetid :)

Men det hjælper dig jo ikke hvis nogen sletter data fra din database ... så ryger data begge steder. Min pointe er blot at fint at du har tænkt over tingene, men at starte et firma fra scratch er en dyr opgave. Og man taber en masse data.

8
18. juni 2021 kl. 14:09

Hvor gemmer du dit data? Kan du også bare wipe den maskine?

ja selvfølgelig.. når det er databaser - så kører vi master/slave (i kubernetes) - som kan lave automatisk failover (man skal alligevel have High-Availability) - og hvis man har behov for write skalering - kan man køre mysql med Galera istedet for (3-way writes) - og derfor kan man altid slette en given instans.. også uden nedetid :)

Hvis det er filsystemer så foretrækker jeg Ceph - men en 2xNetApp i HA mode eller et SAN er også super fint til HA.

7
18. juni 2021 kl. 14:06

Credentials ligger centralt (i LDAP - vores hedder keycloak) - så det har vi bare backup (automatisk vha. kubernetes operator) og mange services gemmer faktisk kun data på enten et filsystem eller en database - og begge ting automatiserer vi bare i Kubernetes - så der automatisk er styr af backup på de ENESTE stedet hvor systemer KAN ligge data (pga. kubernetes design :) - nemlig "PVC"'er - dvs. statiske diske der mountes ind, og vha. den database operator der styrer f.ex. alle postgresql databaser som en hvilken som helst service opretter en instans af.

Jeg har også bygget sådanne setups til mange store firmaer i mange år (med fysiske/VMs og Puppet) - og oftest er det ikke mere end MAX 20% af alle servere der har brug for backup - resten kan tilgå data der skal persisteres vha. filsystem (NFS etc.) - eller ved at snakke med en central database.

Vi kører Open Source på alt - da det giver os friheden til at bygge en vedligeholdbar (og nem at tage backup af etc.) infrastruktur.. og vi udnytter ofte det faktum at vi kan fikse vores problem i softwaren - og så sende "en pull request" til projektet (men vores eget problem ER løst - uden ekstern inddragelse - langt support sager osv.) - men det er en helt anden snak :)

6
18. juni 2021 kl. 13:58

I sidste instans er recovery nødvendigt - og der hjælper det selvfølgelig at forbedre effektiviteten af sin recovery.. anvender man systemkonfiguration (Jeg foretrækker puppet) - så kan man rulle en ny server (eller wipe og re-installere) på under 20 minutter.. og på under 1 minut, hvis det er en VM..

Hvor gemmer du dit data? Kan du også bare wipe den maskine? Hvad med credentials der bruges når den ene service skal snakke med den anden ... de skal også ligge et sted. Det er ikke noget man piller ved hver dag så der er også muligheder for at noget fejler når man forsøger at kommer op igen. Hvad med din source code og bygge server ... er du sikker på at den overlever? Måske var det den der var indgangen som i SolarWinds siutationen. Jeg har endnu til gode at se en virksomhed der kan wipe deres IT setup og komme op og køre på mindre end en uge.

Værst er næsten at man ingen anelse har om malware har fundet ud af at skjule sig i printere, overvågningskameraer, switche, firmware, etc. Alle devices hvor ens mulighed for at vurder om skidtet er malwareramt er meget lille og hvor recovery nemt kan betyde at devices skal på lossepladsen.

5
18. juni 2021 kl. 13:44

Hvis man først ”står med lorten” så forstår jeg godt, at CxO et eller andet sted overvejer at betale løsepengene.

Det er selvfølge ikke det rigtige, men hvis man kan slippe for en ”Mærsk” eller ”Demant” som er hamrede dyre i tab af produktivitet, tid, prestige, salg, samt erstatninger til kunder, så forstår jeg godt at man et lille øjeblik lader sig friste.

Når det er sagt, så er man bare nødt at udarbejde en plan for at Ransomware og sørge for at backups er plads, at spejle af laptops er klar til distribution, osv. osv.

4
18. juni 2021 kl. 13:14

principle of least priviledge er selvfølgelig "værktøjet" - for at beskytte sig imod spredning så vidt muligt.. Men nogen ting vil kunne komme igennem - hvis det er via sårbarheder i porte/services der SKAL kunne nås :) Her hjælper det selvf. at have styr på sine sikkerhedsopdateringer.

I sidste instans er recovery nødvendigt - og der hjælper det selvfølgelig at forbedre effektiviteten af sin recovery.. anvender man systemkonfiguration (Jeg foretrækker puppet) - så kan man rulle en ny server (eller wipe og re-installere) på under 20 minutter.. og på under 1 minut, hvis det er en VM..

Det hjælper både i hverdagen OG i recovery situationer at man anvender sine recovery planer i det daglige virke - fordi man får optimeret dem hastighedsmæssigt og testet dem ;)

3
18. juni 2021 kl. 13:05

Historien viser meget godt hvorfor backup ikke er det rigtige svar på ransomeware. For selvom Demant havde backup af systemer og valgte ikke at betale, så endte det med at blive stjerne-dyrt.

Primært er opgaven selvfølgeligt at holde ransomeware og andet skidt ude. Men man er gigant naiv hvis man tror det er muligt. Der vil være noget der slipper igennem.

Derfor skal virksomheders systemer og netværk være resistente mod malware der er kommet ind i virksomheden. Basalt set skal man sikre at malware ikke kan sprede sig fra workstation til workstation og fra server til server.

Om lidt dukker "hvis I bare havde gjort sådan" crowden op. Hvis Demant havde valgt et andet OS. Havde haft en bedre firewall. Bedre governance omkring brug af workstations. Bedre deployment processer. Etc. etc. Men de har alle misset pointen: Det er nærmest umuligt at gøre det hele rigtigt. Derfor er det vigtigt med defence in depth og med at planlægge ud fra at malware kommer ind. Der er ingen silver bullet her.

2
18. juni 2021 kl. 11:49

Det er også en god ide at have en DC som er offline i tilfældet at et hacker angreb. Tag f.eks. Mærsk, havde de ikke haft en DC i afrika som var ikke var forbundet på det pågældende tidspunkt, så havde Mærk helt sikkert været i endnu større problemer.

1
18. juni 2021 kl. 11:00

Og dejljigt at der ikke undskyldes med "der var ikke noget vi kunne have gjort" :) Og godt de havde backup.

Problemet er jo ofte at cheferne bare accepterer "at formode der ER backup" - alt i mens de i det daglige rykker for helt andre ting "features, features..".

Chefer BØR, efter min mening, få indarbejdet en måde at arbejde med sin backup procedurer og teste dem - såvidt muligt som en del af det daglige virke.

Det kan gøres som en del af CI (der kan bruge backup data fra prod til at lave bedre tests f.ex. - med hvad end af anonymnisering der er nødvendig i ens datasæt) - ligesom man bør som chef bede om et KOMPLET overblik over ALLE data (og andet!) som der i dag SKAL være backup af for at kunne restore 100%..

Og så fokus og tasks på at få flyttet f.ex. al ikke-data (konfiguration f.ex.) over til automatisering (som så kan anvendes i CI f.ex. ) - for på den måde at nedbringe mængden af ting der behøves at være backup af (og testes) - og samtidig vil det forbedre kvaliteten af ens IT anvendelse.