Dierentuin Artis getroffen door ransomware

De dierentuin in Amsterdam is getroffen door ransomware. Artis maakt bekend dat cybercriminelen zijn binnengedrongen op het netwerk van de dierentuin en dat sommige systemen daardoor niet werken.

Volgens Artis werd de aanval ontdekt door de 'externe ICT-partner' van de dierentuin. Het is nog niet duidelijk wat de omvang is van de aanval en of de aanvallers bijvoorbeeld toegang hebben gekregen tot persoonsgegevens of e-mailverkeer. Daarom heeft Artis uit voorzorg melding gedaan bij de Autoriteit Persoonsgegevens.

De dierentuin heeft ook aangifte gedaan bij de politie en doet verder onderzoek naar de aanval. Het is niet duidelijk wie er achter de aanval zit. Wel maakt Artis bekend dat de aanvallers 1 miljoen euro in cryptovaluta eisen. Verder wil de dierentuin nog geen details delen.

Dinsdag waren door de ransomwareaanval Artis-Micropia en Artis-Groote Museum gesloten. De dierentuin schrijft dat woensdag alles weer open is voor publiek. Artis-park kon dinsdag gewoon open blijven.

Reacties (125)

[R3m3d7]

Nu maar hopen dat ze de backup goed hebben dichtgetimmerd. Ik ben een aantal keer bij dit soort zaken betrokken geweest en de meeste backup implementaties zijn hier niet goed genoeg op voorbereid en worden credentials van gestolen waarna de config word aangepast zodat je er niet meer van kan restore of in z’n geheel encrypt.

[Dennism]

Die ervaring heb ik dan weer niet, ben ook meerdere malen ingezet bij slachtoffers van randomware en eigenlijk altijd wat het met de backups goed te herstellen, vaak gewoon een Veaam backup terugzetten van de getroffen VM's c.q. fileservers en ik bepaalde gevallen was de aanval zo 'knullig' dat simpelweg terugzetten via 'previous versions' alles terug te zetten was.

Dit waren uiteraard wel omgevingen waarbij de besmetting via een user (lees non-admin) account binnen is gekomen. Wanneer een administrator het binnenhaalt kan het uiteraard erger zijn, maar zo'n voorbeeld heb ik gelukkig nog niet in het wild gezien.

[jdh009]

Kun je er met een 'previous versions' voldoende zeker van zijn dat je in de toekomst veilig bent? Ik heb altijd 'aangeleerd' gekregen (bij privégebruik) dat een compromised systeem altijd een reinstall is + pw's die (minimaal) daarbij horen aanpassen. Daarbij bestanden los back-upen op verschillende schijven en locaties zodat je die terug kan zetten met minimale verliezen.

Edit: @Dennism bedankt voor je uitleg.

[Reactie gewijzigd door jdh009 op 22 juli 2024 15:11]

[Dennism]

Dat ligt eraan, in de meeste gevallen waarbij die methode werkt gaat het om bijv. een geïnfecteerde RDS server waarbij dan een fileshare waarbij die gebruiker toevallig toegang heeft encrypted is geraakt. In zo'n geval kun je dan soms met 'previous versions' (op de fileserver) het spul snel en veilig terugzetten afhankelijk van het type infectie. Ook ben ik ooit ergens moeten komen brandblussen waarbij dat de enige manier van backuppen was die ze hadden voor de file shares (niet heel verstandig natuurlijk).

De RDS kan je dan nuken en een nieuwe in de farm rollen (tenzij het een non-persistent RDS is, dan reboot je gewoon ) en het gebruikersprofiel VHD van de getroffen gebruiker nuke je ook.

Er kunnen echter ook uiteraard situaties zijn waarbij je dit niet kan vertrouwen en dan kan het inderdaad zo zijn dan je een meer tijdrovende manier van restore (of zelfs disaster recovery) moet toepassen, afhankelijk van de grootte van de calamiteit en de opties die je beschikbaar hebt., helaas heeft immers lang niet ieder bedrijf de backup procedures op orde, vaak zelfs, zeker bij de wat kleinere bedrijven erg onvoldoende en dan moet je daar dus komen 'brandblussen'.

[Reactie gewijzigd door Dennism op 22 juli 2024 15:11]

[R3m3d7]

Dat is mooi, ik heb meegemaakt dat ze via social engineering veeam credentials hadden weten te bemachtigen en dan kan je een restore vergeten. Het is ook de reden dan oa MFA op je backup extreem belangrijk is, gelukkig zijn er oplossingen waar dit native in zit.

[p0linskie]

Via social engineering de back-up sleutels weten te bemachtigen? Dan zijn ze toch wel heel erg af bij de IT-afdeling. Sws zou het wachtwoord maar een keer gebruikt moeten zijn en als erom gevraagd wordt moet bij een IT-er toch echt wel het lampje gaan branden waarvoor die sleutel gebruikt wordt.

Als je via social engineering je back-up sleutels afgeeft moet je weg worden gehaald bij een toetsenbord imho.

[Vogel666]

Je wil ze kost niet geven waarbij de IT-verantwoordelijke van het bedrijf de GOD-modus op zijn gewone user-account aan heeft staan zodat hij ten alle tijden de ingehuurde IT-club naar huis kan sturen zonder zelf buiten gesloten te zijn.
Als je als hacker eenmaal domain admin bent, dan is die backup ook niet meer zo moeilijk te verkloten. Zeker als je als hacker rustig de tijd neemt om de ongehackte situatie uit retentie te laten lopen ben je al gehackte partij niet meer zomaar weer veilig.

[R3m3d7]

Het is wat ingewikkelder dan vragen om de sleutels en die afgeven maar ik ga hier niet de boel verdedigingen en het bleef uiteindelijk een menselijk fout.
Er zitten echt extreem junior mensen in rollen waar ze eigenlijk de verantwoordelijkheid niet van aankunnen en dat komt deels door het tekort aan goed ervaren personeel wat betaalbaar is voor het gemiddelde bedrijf.
De grootste fout was echter geen MFA oplossing op de backup die ook geen two-person-rule achtig iets actief had waardoor 1 persoon met 1 set credentials alles onderuit kon halen.

[dasiro]

als er hele parken dicht moeten lijkt me dat er toch wat crucialere dingen plat liggen of onbetrouwbaar zijn geraakt

[phoenix2149]

Vrienden hadden laatst deadbolt ransomware op hun NAS. niet zo diep genesteld dat schaduw kopie ook encrypt was, zoals jij stelt.

Ze hadden gelukkig minder dan de helft gebruikt dus genoeg backups. Kon na een update weer in de frontpage en alles terug zetten van een herstel punt.

Zelf heb ik een encrypted backup met persoonlijke sleutel in de cloud (iDrive) voor al mijn persoonlijke data. Multimedia zou jammer zijn, maar niet het einde van de wereld.

Erg bizar overigens hoe dit kon gebeuren…. Blijkbaar had een IT kundige vriend hun NAS ingesteld en heerlijk SSH open staan en poort 22 op router geforward. Want wie wil dat nou niet…..

[Reactie gewijzigd door phoenix2149 op 22 juli 2024 15:11]

[blorf]

Wat is het probleem met ssh open hebben staan? Gewoon zorgen dat je geen simpele wachtwoorden gebruikt. En zelfs dat maakt alleen in theorie verschil. Bruteforcen kan niet want na 3x fout krijgt je een delay + root notification

[Keypunchie]

En dan maar hopen dat er geen lek in sshd wordt ontdekt.

Of dat je ssh-key/danwel wachtwoord op de een of andere manier lekt.

"Defense in depth" is een heel verstandige aanpak. Een extra laag, zoals VPN toegang, is heel verstandig.

Dan moet er dus *en* een kwetsbaarheid in je VPN, en in (jouw versie van) sshd zitten. Of als iemand je wachtwoord heeft (op wat voor manier dan ook), dat ze nog niet je VPN toegang hebben.

(Two-factor is ook niet onverstandig)

[Reactie gewijzigd door Keypunchie op 22 juli 2024 15:11]

[deadinspace]

Een extra laag, zoals VPN toegang, is heel verstandig.

Dan moet er dus *en* een kwetsbaarheid in je VPN, en in (jouw versie van) sshd zitten.

Tenzij er een remote code execution vulnerability in je VPN zit, dan ben je kwetsbaar ongeacht wat SSH doet, en was je dat niet geweest zonder VPN. Meer software is niet altijd beter

[Keypunchie]

Hoezo dat?

Met het kraken van mijn VPN zit je in mijn netwerk, maar dan moet je nog gaan beginnen aan het mappen en kraken van diensten daar binnen.

In principe is dit het model dat ik bij veel organisaties heb gezien: een VPN naar een ‘extern’ LAN, waar je toegang hebt tot een of meerdere ssh-“opstap”servers, die zelf weer ook een pootje hebben in de echte ‘produktie’ LANs, zoals een beheernetwerk. (alles netjes gesegmenteerd).

Moet je dus eerst een VPN kraken, dan een ssh-server kraken en dan nog kun je alleen doorloggen.

Uiteraard is dat niet waterdicht, maar het is goed te monitoren en auditen. (En het begint wat minder relevant te worden met cloud computing/microservices, omdat het model nog heel erg server-gericht is, maar daar valt wel een mouw aan te
passen)

[blorf]

Hij bedoelt een exploit in de VPN-software die in het ergste geval directe kernel manipulatie mogelijk maakt. Dan ben je overal omheen...

[Keypunchie]

Hoezo? Dan heb je mijn VPN-server. Die geeft je alleen maar netwerktoegang. Wat al erg genoeg is, maar dan heb e niet mijn ssh-server, of enige van mijn andere servers.

Ttoegegeven, niet alles zal een eigen stuk hardware hebben, maar de VPN draait absoluut op een eigen stuk hardware, juist om deze reden.

In mijn thuisnetwerk wordt de VPN door mijn modem/router verzorgd. Op zich niet ideaal, maar het is 'maar' een thuisnetwerk en op zich is het logisch om het op het netwerkniveau te zetten.

Bij mij thuis heb ik geen opstapserver, moet ik toegeven. Maar mocht iemand de modem-router/vpn kraken, dan mag hij nog steeds aan de bak om andere diensten binnen te dringen.

Dit is ook de reden waarom het geen gek idee is om IoT apparaten in hun eigen VLAN te stoppen. Die dingen communiceren meestal alleen maar via een Cloud-dienst en dan is het prima dat ze helemaal niks met de rest van je apparaten van doen hebben.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 15:11]

[blorf]

Alle deelnemende computers moeten er ook bij kunnen Dat is waar de kwetsbaarheid dan zou moeten zitten. Wat heb je nodig? Virtuele netwerkapparaten en een stukje client-software?

[Reactie gewijzigd door blorf op 22 juli 2024 15:11]

[Keypunchie]

geen idee wat je vraag is.

[blorf]

Wat heeft een client nodig om met de VPN-server te praten? Wel iets... Als de VPN-server een lek heeft die toegang van buitenaf mogelijk maakt dan heeft dat waarschijnlijk met het imiteren van een client te maken. Dat de server een andere computer is en zelf niet op de VPN zit, is niet zo heel relevant.

[Keypunchie]

voor een vpn-verbinding heb je een vpn-client nodig.

wat die doet is alleen maar op netwerk (tcp/op) niveau.

“Dat de server op een andere computer zit” is juist extreem relevant in deze.
je verkeer binnen een VPN-tunnel
is namelijk nog steeds versleuteld. De VPN verzorgt alleen netwerk toegang, maar heeft geen andere rechten inhet netwerk of op het netwerk.

Eerlijk gezegd: je bent nogal wijsneuzerig aan het doen. Ik vind het prima hoor, ik weet namelijk vrij goed waar ik het over heb, aangezien hoewel het geen specialisme van me is, wel materie is waar ik vrijwel dagelijks professioneel mee te maken hebt.

Als jij graag je ssh-poort op 22 plat aan het internet wilt zetten, moet je dat vooral doen.

Ik vertel je alleen maar dat dit niet best practice is. Niet in bedrijfsomgevingen, niet voor je thuisnetwerk.

Laat je vooral niet tegenhouden door je gebrek aan kennis over netwerken, VPN’s en concepten als ‘defense-in-depth’

Maar als je iets wilt leren, stel dan geen vragen uit de confrontatie met het idee dat je zonder die kennis wel gelijk zult hebben.

Aan onwetendheid valt wat te doen, aan moedwillige onwetendheid niet.

[blorf]

Ik dacht dat je een eigen server had. Dus toch een dienst.
Wat betreft ssh, dat heb ik naar buiten niet standaard open staan. Maar het zou het laatste zijn waar ik me druk over maak. Aan een sshd op poort 22 draaien zitten alleen maar theoretische risico's.Wat is het verschil in de praktijk? Een portscanner die daar een reactie registreert kan alvast zijn ssh-spullen laden?

[blorf]

Als je echt paranoid bent kun je ook een scriptje laten luisteren op een bepaalde poort. Daar moet je dan een geheime tekenreeks heen netcatten en dan start hij sshd op.

Dat met die VPN snap ik niet. Als je openbare ip waar sshd voor draait wordt aangevallen, lijkt
het mij er weinig toe doen via hoeveel computers dat gaat,,,

[Keypunchie]

Omdat een aanvaller dan eerst de vpn moet aanvallen ipv. de dienst zelf.

(voor de duidelijkheid, ik heb het over draaien van een vpn server, niet over een VPN dienst a la NordVPN)

port-knocking vind ik altijd wat obscure methode en introduceert vooral ook onzekerheid en ongemak voor jezelf, maar als je het leuk vind kan het.

Mijn benadering is om attack surface te verkleinen met goeie afscherming op netwerkniveau (ip firewalls voor alle diensten die niet publiek hoeven te zijn, vpn voor de prive-toegang) en op dienstniveau (sterke authenticatie, goeie encryptie).

Combineren met goed beleid op werkplekken (patching, virusscanner, sterke authenticatie) en diensten (patchen, patchen, patchen) en je komt een heel eind.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 15:11]

[blorf]

Het enige verschil is dan toch het ip van de ssh-server? Wat wel zou kunnen is dat die VPN-server iets heeft om verdachte activiteit te herkennen wat door de firewall heen komt.

[Keypunchie]

Nee. VPN is een volkomen andere dienst dan SSH. En je gebruikt andere credentials (mag ik hopen)

Je moet eerst authenticeren dat je überhaupt het ‘lokale’ netwerk (typisch ook weer een gesegmenteerd netwerk met beperkte connectiviteit) op mag en dan pas kun je als hacker pas beginnen de ssh-server aan te pakken.

[edit] ik denk dat je begrip van VPN nogal gekleurd wordt door publieke VPN diensten, die de bedoeling hebben om een cliënt te beschermen op een mogelijk ‘vijandig’ netwerk (of om je geolocatie te spoofen). Voor dienstbeveiligung is het juist een methode om een cliënt (en alleen die cliënt) toegang te verlenen tot een netwerk en de diensten daarop.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 15:11]

[blorf]

Een virtueel lokaal netwerk dat publiek bereikbaar is via een centrale login? Maar als je je druk maakt om de kwetsbaarheid van je ssh-server, die neem ik aan publiek is snap ik het niet. Wat maakt het voor verschil wat er allemaal achter een server gebeurt. Hij moet hetzelfde doen als een directe server.
Anderzijds, je kan natuurlijk op je VPN-netwerk een ssh-server laten draaien, maar dat is geen openbare service.

Overigens heb ik me nooit verdiept in zelf een VPN opzetten. Moet je dan wachten tot DNS "ingecached" is voordat je computers een publieke ipv6 + domeinnaam hebben die overal bereikbaar is? Een provider moet daaraan meewerken, lijkt me...

[Reactie gewijzigd door blorf op 22 juli 2024 15:11]

[Keypunchie]

Idd! Een ssh-service zou ik ook nooit publiek/plat op het internet draaien, is het punt!

[Geuze]

Eerlijk gezegd ik vertrouw meer op ssh dan eender welke andere vpn software.

Maar met ssh ingesteld om enkel Key authenticatie toe te laten. en fail2ban of iets dergelijks dat foutieve login pogingen dadelijk blokkeert denk ik dat ssh gerust open kan staan.

[laser50]

Om heel eerlijk te zijn is ssh op poort 22 opengooien zoiezo al een stom idee.

Trackers en bots zoeken het internet af voor precies die poort, ik maak er meestal 2201 of 2202 van en dan bespaar je eigenlijk al een hoop gezeik.

[fluffy1]

Zou je zeggen. Ik heb een VPS draaien waar ik SSH op open heb staan (met een sterk wachtwoord en waar updates minstens wekelijks opgeïnstalleerd worden. In essentie gewoon veilig dus).
Eerst op standaard poort 22. Hier werd ik plat gelopen door bots waardoor de performance van mijn VPS eronder begon te lijden.
Daarna op poort 2222. Ging een paar weken goed. Hierna hadden de bots door waar ze moesten zijn en begon het weer opnieuw. Same deal nadat ik naar poort 2223 ging.

Uiteindelijk heb ik SSH via port knocking verborgen. Is obscurity, geen security. Maar werkt goed genoeg om ervoor te zorgen dat de bots mijn SSH daemon met rust laten.

[laser50]

Ja ik heb daar zelf ook wel een tijd last van gehad, gelukkig draai ik linux tegenwoordig op een VM binnen windows, dus ik heb de poort niet openstaan naar buiten en gebruik gewoon een VPN

Leek mij toen verreweg de veiligste keuze

[YopY]

"gewoon" is te eenvoudig, zoals anderen ook al aangeven. Een paar extra tips; draai je SSH op een andere poort dan 22, en gebruik een andere username dan 'root' (of zorg ervoor dat je niet als 'root' in kunt loggen via SSH, dwz dat je als een andere gebruiker moet inloggen en dan binnen de SSH sessie van account moet wisselen (of gewoon sudo moet gebruiken). Dat houdt het merendeel van evt. brute-force aanvallen al tegen.

[blorf]

Alle ssh-servers zetten root-toegang standaard uit. Maar alsnog zou je er niks aan hebben want een systeem geeft als het goed is niet te kennen of een gebruikersnaam ook echt bestaat. En je hebt nog steeds geen wachtwoord...

En wat is het probleem met dat het op poort 22 draaien? Volgens mij is het in POSIX zelfs nog beter omdat poorten <1024 specifieke restricties hebben.

[Vogel666]

Access en authentication zijn 2 lagen van beveiliging.
Waarom zou je 1 van die barrieres op voorhand al slechten. Dan help je de hacker al half op weg en hoeft hij alleen nog maar authenticatie te hacken.

[devices]

Er zijn miljoenen servers met een open port 22. Was het daadwerkelijk een SSH expoit of gewoon een gevalletje standaard gebruiker met een standaard/makkelijk wachtwoord?

[phoenix2149]

Port forwarding is eigenlijk nooit verstandig.

Nee het waren geen standaard of makkelijke wachtwoorden. Het was een bekende lek op qnap NAS Ssystemem en met de poort open konden ze dus ransom ware deployed.

Maar goed ben geen expert, dat is duidelijk maar ze wille. Toch niet van buiten af naar de nas.

[Nas T]

Zelf heb ik een encrypted backup met persoonlijke sleutel in de cloud (iDrive) voor al mijn persoonlijke data. Multimedia zou jammer zijn, maar niet het einde van de wereld.

Maar dat voorkomt toch niet dat kwaadwillenden daar overheen dan weer een encryptie gooien, zodat je niet meer (met je eigen sleutel) bij je eigen data kan?
Een gijzelnemer gebruikt de waarde die iemand anders hecht aan de gijzelaar als machtsmiddel. De gegijzelde zal (gok ik) praktisch nooit als slaaf gebruikt/verkocht worden ...

[phoenix2149]

Ze zouden wel behoorlijk wat voor kennis moeten hebben willen gericht dat willen doen.

De personal key is overigens op iDrive zelf. Soort 2FA.
1: account en WW
2: encryption key

Dus je moet beiden hebben en de encryption key kan niet zomaar veranderd worden.

Enige wat mogelijk zou zijn is dat bij het encrypten de bestandsnamen gelijk blijven en dan met de auto-backup vervangen worden. Hmm zet je aan het denken.

[mjz2cool]

Om bestanden te encrypten heb je geen enkel wachtwoord of encryption key nodig, alleen toegang tot het apparaat waar de backups gemaakt worden. Als je backups op je pc maakt en die encrypted op die iDrive zet kan die iDrive nog zo goed zijn, dan nog kan malware je backups encrypten over je eigen encryptie heen.

[phoenix2149]

Ik upload de bestanden naar iDrive. Dus niet zozeer als een backup bestand die eerst gemaakt wordt op de NAS.

Bestanden die op iDrive staan kunnen dus van de NAS afgehaald worden etc.

Dus ok die bestanden te encrypten moeten ze just toegang krijgen tot de bestanden op iDrive zelf toch? Dat lijkt me lastiger.

edit:
overigens heeft iDrive ook nog eens 30 versies van de bestanden dus die kunnen ook terug gezet worden.
https://www.idrive.com/help/Windows/versioning

[Reactie gewijzigd door phoenix2149 op 22 juli 2024 15:11]

[mjz2cool]

Dat kan inderdaad, maar voordat het geupload wordt kan het al encrypted zijn, als er malware op je pc draait. Als zoiets dan al een poosje draait, kan het zelfs gebeuren dat ook die oudere versies encrypted zijn. Op het moment dat het dan lang genoeg draait kan die malware daarna de bestanden op je pc encrypten. Daarom is het zo belangrijk om een offline backup te hebben als er kritische data op staat. Daarmee voorkom je dat volautomatisch je backups ook encrypted worden.

[phoenix2149]

True.

Wat ik wel merkte bij vrienden waar ik het gelukkig had kunnen oplossen is dat uiteraard bij een encryptie, het bestand één keer was gewijzigd. Waardoor er dus meerdere priors beschikbaar konden zijn en ook waren. Er wordt enkel een vorige versie gemaakt wanneer er daadwerkelijk iets is veranderd natuurlijk.

Dan zou de software veel slimmer moeten handelen en meerdere keren “her encrypten” om dat de doorbreken.

Heb het idee dat ze gewoon snel money willen en niet te veel hoeven te ontwikkelen. Daarmee tref je juist de mensen die niet weten dat er iets van een versie backup mogelijkheid is. Sterker nog ze weten niet eens voorbij de ransomware splash screen te komen. Deze mensen zullen de (nu nog naar €800 aan) bitcoins betalen.

[Oon]

Iedere poort openzetten is natuurlijk onveilig, maar als je gewoon plaintext auth uit hebt staan en moderne keys gebruikt dan gaat SSH echt niet de reden zijn dat je ransomware binnenkrijgt. Zoals @devices aangeeft zijn er miljoenen servers die poort 22 gewoon open hebben staan, als er echt een simpele SSH-exploit zou zijn dan lag nu een significant deel van het internet plat.

Encrypted back-ups zijn leuk, maar moderne ransomware blijft een paar maanden inactief zodat het ook lekker in je back-ups zit, en alle bedrijven die zeggen dat hun back-ups ransomware proof zijn die liegen want dat is gewoon onmogelijk.

[xbeam]

Erg bizar overigens hoe dit kon gebeuren…. Blijkbaar had een IT kundige vriend hun NAS ingesteld en heerlijk SSH open staan en poort 22 op router geforward. Want wie wil dat nou niet…..

Iedere Iter, want lekker makkelijk

Wat is het probleem met ssh open hebben staan? Gewoon zorgen dat je geen simpele wachtwoorden gebruikt. En zelfs dat maakt alleen in theorie verschil. Bruteforcen kan niet want na 3x fout krijgt je een delay + root notification

Of gewoon een certificaatje gebruiken.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:11]

[VIPGAMER]

Qnap neem ik aan?

[mjz2cool]

SSH forwarden kan prima, ik doe dat zelf met een aangepaste poort, en password authentication uitgeschakeld. Ook houd ik de auth.log in de gaten, als daar verdachte mislukte inlogpogingen in staan pas ik de poort aan. Mocht het echt een risico opleveren schakel ik de NAT regel uit en stel ik een VPN server in. Zolang mijn private keys niet uitlekken is er niets aan de hand.

[Mopperman]

Of de bekende infinity loop: al maanden binnen zijn, vervolgens in al je backups zitten er frauduleuze bestanden die - bij aanklikken - zich weer verspreiden…. Kan in macro’s en alles verborgen zitten.

[jdh009]

Dat hoor je inderdaad wel vaker, zeker als de aanvaller zich al een tijdje 'schuil' houdt in je netwerk en daardoor je back-ups kan besmetten. Hoe zet je zo'n backup implementatie dan goed op als (klein) bedrijf en zorg je ervoor dat je voorbereid bent? Is de 3-2-1 backup regel voldoende en ben je daarme voldoende voorbereid?

[R3m3d7]

3-2-1 is niet voldoende want die is meer tegen traditionele verstoringen en DR scenario's.
Als het om ransomware gaat moet je denken aan een hele andere set met voorbereidingen en checklists waaraan je je backup omgeving kan toetsen.
Het is te offtopic voor hier maar mocht je meer willen weten stuur mij maar een PBtje.

[ari2asem]

ik vraag me oprecht af:

- wat voor gegevens kunnen ze (de hackers) bij artis weghalen ?? mailadres, iban-nummer, legitimatie, etc etc....?

[phoenix2149]

Gegevens abonnement houders, werknemer/werkgever gegevens of wellicht mail adressen database voor nieuwsbrief.

Buiten dat ligt de infrastructuur plat van Artis. Planning voedsel leveringen betalingsverkeer etcetera. Behoorlijk impact.

[Northstar]

En dat niet niet alleen, kassa systeem kan ook getroffen zijn natuurlijk.

[Prince]

Medische gegevens van dieren, medicatie, allergiëen, behandelingen, stamboomgegevens, contracten,...
Veel van die dieren kosten stukken van mensen om gewoon al te hebben en vereisen soms dure en erg specifieke voeding.
Het systeem welk dier welke voeding/medicatie/inenting kreeg op welk moment en hoeveel telkens is vrij belangrijk. Dat kan je niet een paar dagen offline houden.

[MatthijsMack]

Deze data staat in een systeem wat ZIMS (Zoo Information Management System) heet. En wordt beheerd door een ander bedrijf. Die hebben neem ik aan wel de juiste maatregelen genieten om data verlies te voorkomen.

Daarnaast wordt veel nog steeds ouderwets in logboeken bijgehouden door de dierverzorgers zelf. Deze data wordt (verschilt per tuin) dan wel weer in ZIMS gezet. Soms wordt er een ouderwets archief van opgebouwd.

En als laatste, de dieren kosten geen geld. Voeding, huisvesting en verzorging natuurlijk wel. Maar dierentuinen aangesloten bij EAZA betalen geen geld voor dieren maar slechts voor het transport. Dit om de fokprogramma’s te bevorderen en om te voorkomen dat een diersoort die dan duur zou zijn maar door een select aantal tuinen gehouden kan worden.

Natuurlijk zal Artis wel bepaalde contracten of gegevens hebben die ze liever niet op straat hebben. Maar ik snap niet dat mensen een aanval doen op een dierentuin en daar dan geld proberen los te krijgen. De meeste tuinen verdienen namelijk geen miljoenen of miljarden zoals sommige (naar mijn mening) onbelangrijke bedrijven wel doen en dat zomaar op de plank hebben liggen.

[iFap]

Het is niet alleen kwestie van gegevens publishen. Ze kunnen ook je gehele infrastructuur platleggen waardoor je niet meer je business kunt runnen. Vaak zitten ze zelfs al in je back-up en kun je ook niet zomaar restoren. Dan is betalen meestal de enige uitweg. Hoe dan ook, gevolg is naast reputatieschade ook gewoon heel veel inkomstenverlies. Soms leidt dat zelfs tot deuren sluiten.

[latka]

Die school had 50 miljoen nodig volgens de directie om door te gaan. De random die ze betaalde was 100.000. Het zal niet geholpen hebben maar de ransomware is daar gebruikt als excuus voor een onderliggend probleem.

[Houtenklaas]

Wellicht is het niet eens bewust getarged, maar "vangst" bij het uitzetten van aas. Het zal die boeven jeuken wie ze te pakken nemen, zolang het maar potentieel geld in het laatje brengt.

[MiesvanderLippe]

Staat niks over de scope in de publicatie. Kan alles zijn van een mailbox van een vakantie medewerker tot totale overname van het bedrijfsnetwerk.

[multikoe]

Het gaat er volgens mij bij ransomware niet zozeer om dat je wat steelt om te gebruiken. Je steelt iets om het vervolgens alleen tegen betaling terug te geven.

[pepsiblik]

Identiteits diefstal. Op zich is het stelen van NAW gegevens niet zo’n issue. Maar dan gaan de dieven die data combineren met andere bronnen. Er ontstaat zo een compleet profiel en daar kunnen criminelen weer van alles mee.

[noltha]

Nou, hopelijk hebben ze degelijke back-up systemen en komen ze weg zonder losgeld te betalen. Wat een stelletje pannenkoeken weer, laat die dierentuin en andere bedrijven toch gewoon met rust.

[gimbal]

Ik denk niet dat het moraalridders zijn helaas.

[Slavy]

En daarom moet je dus niet aan een MSP beginnen. Kost veel geld en meestal krijg je mediocre service en onderhoud. Gewoon eigen beheer doen en daar in invensteren.

[KryTech]

Dat lijkt me nogal kort door de bocht. Vooral in MKB met vaste beheerders die er al wat jaren zitten is het bijhouden van de markt, risico's kennen en herkennen nogal een uitdaging. Ongemerkt roesten ze vast en zijn ze niet heel vooruitstrevend en veranderen ze liever niet te veel.

Althans dat is wat ik in de praktijk zie en ook niet zo gek gezien het tempo waarin alles veranderd in het IT landschap.

[Blokker_1999]

Niet alleen dat, maar met diversificatie heb je ook de mogelijkheid tot specialisatie. Een klein bedrijf met 1 of 2 beheerders die alles doen heeft ook al snel als nadeel dat er niet veel is dat ze door en door kennen. De kans wordt dan al snel een heel stuk groter dat je niet verder komt dan de basissetup van vele producten en dat je onbedoeld fouten maakt die net weer zeer eenvoudig te misbruiken zijn.

[Keypunchie]

Dit is echt onzin. Een dierentuin moet juist geen volledige IT-afdeling willen hebben.

Dat is geen competentie van ze, de strijd om talent kunnen ze nooit winnen en al snel zullen de kosten ook de spuigaten uit lopen omdat ze weinig schaalvoordelen kunnen halen.

Cloud en Managed Services is juist heel geschikt voor zo’n organisatie. Wel belangrijk dat je je leveranciers goed kort houdt, maar dat kan gelukkig met juist alleen een goeie IT-manager en niet een hele afdeling aan eigen personeel.

[jvr]

Een klein IT team lijkt me wel handig. Dit maakt je een goede opdrachtgever.
Ipv doe maar een WiFi en oja iets met opslag en het moet goedkoop zijn.
Een kritische klant is de beste klant.

Moet je alles zelf willen doen..... Nee absoluut niet.

[xbeam]

Te kritisch en er gebeurd niets bij die klant en draaien ze over 10 jaar nog op Windows XP omdat ……

[Reactie gewijzigd door xbeam op 22 juli 2024 15:11]

[mjz2cool]

Het ligt eraan welke afdeling kritisch is. Als de it afdeling kritisch is kan dat juist goed zijn. Gaat het om management, tja, dan krijg je dat soort taferelen inderdaad. Helaas maak ik dat met mijn werk dagelijks mee, en ook genoeg voorbeelden waarin het echt een keer fout moet gaan voordat er wordt vernieuwd (productie plat, dataverlies, dat soort dingen).

[xbeam]

Hier ook bij klanten. Ik noem jou kritisch een minimale noodzakelijke expertise. Maar vaak heb je in kleine (10 werk plekken) omgevingen alleen een management die ook gaat over IT. Daar is soms het invoeren van wachtwoord kluis al helse klus. Want …….. vindt dat lastig Of nee ik heb goed wacht wachtwoord dus niet nodig.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:11]

[Viper_Core]

Een beetje MSP doet goed mee.

"eigen beheer", "on-premise servers", dat is natuurlijk hopeloos ouderwets aan het raken.

Een systeembeheerder die specialist is op tal van gebieden zoals, beveiliging en backup, data en device management, die werkt natuurlijk niet meer bij een dierentuin.

Belangrijk is dat je contractuele overeenkomst met de MSP goed is.

Laat dat bekijken door een specialist, als je die kennis zelf niet hebt.

[jeroen79]

Is specialist op tal van gebieden niet wat tegenstrijdig?

[Zeerob]

Gewoon eigen beheer doen en daar in invensteren.

invensteren? Bedoel je op Windows overgaan?

[mjz2cool]

Eigen beheer kan vaak lang niet uit, de kosten zijn dan veel hoger, en je moet er continue bovenop zitten om de boel veilig te houden.

[parend]

Gegevens over de dieren het voederen de ziektes. Hoop dat ze cyberhonden aan de hoogste boom gaan ophangen. Duffe laffe gastjes.

[MineTurtle]

Ik hoop dat de dieren hier ook niet door in gevaar zijn gekomen.

[Kiswum]

Nou daar ben je dus mooi mee in de aap gelogeerd. Vermoedelijk dachten ze eerst dat het een bug was.

[mjl]

Of een arachnid.

[TwiekertBOB]

Het was phishing.

[Stefandepefan]

Dit is wel een treurig verhaal, want ik werd vandaag nog gebeld door Artis of ik donateur wou worden. De dierentuin heeft het door corona zwaar te lijden en heeft daardoor 40 mensen moeten laten gaan (mogelijk ook mensen van hun IT afdeling denk ik dan) en werd mij verteld hebben ze een schuld van 20 miljoen euro op het moment. Natuurlijk kan je het zien als een zielig verhaal om mij te laten doneren, maar ik geloof dat ze het als dierentuin echt zwaar hebben en dit helpt niet mee om als bedrijf te herstellen.

[computerjunky]

Gewoon betalen van gelden aan criminelen strafbaar maken met een extreem hoge boete van 5x jaar omzet of iets dergelijk. Als er niet meer betaald word dan is de lol er snel vanaf. Het blijft momenteel bestaan doordat er steeds maar weer betaald word.
Of natuurlijk crypto verbieden want dat is wat dit alles mogelijk maakt. Voor crypto was het heel lastig uitbetaald te krijgen omdat dan je geld extreem makkelijk traceerbaar was.

[Daoka]

Toch zou ik wel uitzonderingen willen zien. Denk aan ziekenhuizen, brandweer, en ook de dierentuin. Als dit zorgt voor gevaar van de onschuldige dieren vind ik niet dat dagen of zelfs weken offline kunnen blijven. Maar ja uiteindelijk brengt die uitzonderingen wep risico's mee. De kans is wel groter dat juist dus zulke uitzonderingen eerder aangevallen wordt omdat ze mogen betalen.

Al verwacht ik trouwens niet dat verbieden echt zal helpen. Of ze betalen evengoed maar zal het minder snel bekend worden. Of de data wordt dan misschien weer verkocht aan andere. Ik kan me best voorstellen dat men wel zou willen weten waar de concurrentie aan zit te werken zodat je hier eerder iets vergelijkbaars maken.

[computerjunky]

Nee, dan creëer je juist een bewust doel wat het probleem alleen maar serieuzer maakt. De meest kwetsbare groep word dan gewoon het enige doelwit en dat is zeer onwenselijk.

En bedragen van tonnen of miljoenen kan je niet 123 verbergen in de boekhouding dus nee er zal niet betaald worden als dat je belastingfraude oplevert.

Maar crypto verbieden is dan ook het makkelijkste. Alle brokers opdoeken en internationaal de sites offline halen en onbeschikbaar maken. Probeer dan nog maar eens te betalen met een niet traceerbare manier. Het zijn de brokers die dit mogelijk maken momenteel.

[batjes]

Ook dan moet je het principe van "We don't negotiate with terrorists" aanhouden. Anders worden dat soort partijen het voornamelijke doelwit.

Het moet niet lonen en dat we daar als maatschappij her en der ons verlies moeten incasseren, het zij zo.

[Soneraxx]

Wel maakt Artis bekend dat de aanvallers 1 miljoen euro in cryptovaluta eisen.

Nog een reden waarom ik geen fan ben van crypto…

[Blokker_1999]

Of het nu crypto, dollars of roebels zijn, maakt niet uit. Neem 1 methode weg en ze verzinnen wel iets anders. Er zijn nog altijd landen waar het bankgeheim heilig is.