image

"Ransomware versleutelde back-ups Universiteit Maastricht"

vrijdag 24 januari 2020, 09:30 door Redactie, 65 reacties

De aanvallers die toegang wisten te krijgen tot het netwerk van de Universiteit Maastricht en bestanden op allerlei systemen versleutelden, wisten ook de back-ups te versleutelen. Die stonden namelijk op de universiteitsservers en waren daardoor voor de aanvallers te bereiken, dat meldt de Volkskrant.

De back-ups bevatten onderzoeksgegevens en gegevens van studenten en medewerkers die tientallen jaren teruggingen. Eerder meldde universiteitsblad Observant dat de universiteit het door de aanvallers gevraagde losgeld had betaald om de bestanden terug te krijgen. Het zou om een bedrag van enkele tonnen gaan. Volgens bronnen waarmee de Volkskrant sprak ligt het bedrag tussen de 200.000 en 300.000 euro. Op 5 februari zal de universiteit in een symposium meer details over het incident vrijgeven.

Gisteren stelde D66 nog Kamervragen aan minister Grapperhaus van Justitie en Veiligheid over het aantal publieke instellingen dat door ransomware is getroffen en het gevraagde losgeld heeft betaald. "In hoeverre is het mogelijk om voor dergelijke beslissingen over het al dan niet betalen van losgeld eenduidig beleid te ontwikkelen? Ziet u additionele mogelijkheden voor beleid op het gebied van back-upbeleid?", vroeg D66-Kamerlid Kees Verhoeven de minister.

Reacties (65)
24-01-2020, 09:37 door Anoniem
Enkele tientallen jaren aan gegevens niet veilig offline opslaan is treurig en men komt hier weer gewoon mee weg.....
Natuurlijk zijn de ransomware verspreiders crimineel maar ja, als je het ze zo makkelijk maakt dan vraag je er ook wel een beetje om.

Ik hoop dat de kosten die bespaard zijn door gebrekkige IT inrichting/"security" het waard waren en het gevraagde losgeld dus geen probleem was. /sarcasme uit
24-01-2020, 09:39 door Anoniem
Dat de backup's op 'de' universiteitssevers stonden hoeft helemaal geen reden te zijn waarom de backup's geinfecteerd raakten. Dat de backup's online waren te bereiken is het probleem.
24-01-2020, 09:50 door karma4
Backups die online op het zelfde systeem staan? Noem dat alsjeblieft geen backup, zeker niet geschikt voor DR.
24-01-2020, 09:51 door Anoniem
Je moet er altijd voor zorgen dat backups onaantastbaar zijn.
24-01-2020, 10:07 door Anoniem
Door karma4: Backups die online op het zelfde systeem staan? Noem dat alsjeblieft geen backup, zeker niet geschikt voor DR.

Ik lees nergens dat de backup op hetzelfde systeem staat. De backup stond op de servers van de universiteit, hoogstwaarschijnlijk dus DE backup servers. Vooral door de groei van de hoeveelheid data zie je steeds minder dat men een backup op tape maakt, en die vervolgens ook nog handmatig uit de systemen verwijdert.

Het probleem met tape back-up in het kader van DR is ook dat het terugspoelen van al die tapes, als ze al allemaal leesbaar zijn, lang kan duren. Wij hebben het voor onze organisatie uit laten rekenen en, als je niet per server een tape-unit gebruikt, dat kost ongeveer een maand. Het nadeel van per server een tape-unit is bovendien dat je bij het maken van je back-ups per server een tape moet gaan gebruiken. Die wil je ook niet online laten, dus zelfs als er maar 100MB is gewijzigd sinds de laatste back-up, moet je een nieuwe tape pakken voor die server.

Werk je met back-up sets, waarbij dus meer servers op dezelfde tape terecht komen, dan hoef je niet iedere dag honder tapes te vervangen. Dan kun je volstaan met een magazijn met 10 tapes per dag.

Peter
24-01-2020, 10:09 door Anoniem
Zucht. Online backups...
Leuk voor als er een disk cluster dood gaat.
24-01-2020, 10:18 door Anoniem
Keer op keer zie je het mis gaan. Backups benaderbaar vanaf de servers = geen backup! Dit is gewoon puur een kwestie van de zaken niet op orde hebben.
24-01-2020, 10:33 door Anoniem
De Universiteit Maastricht (UM) heeft tussen de 200 duizend en 300 duizend euro betaald aan hackers die het universiteitssysteem met gijzelsoftware hadden vergrendeld. Het bestuur van de universiteit zag zich genoodzaakt te betalen omdat ook de back-up gekaapt was.

Universiteit Maastricht betaalde hackers kwart miljoen euro
door Mark Misérus en Huib Modderkolk, 24 januari 2020

https://www.volkskrant.nl/nieuws-achtergrond/universiteit-maastricht-betaalde-hackers-kwart-miljoen-euro~b0a1707b/
24-01-2020, 10:35 door Anoniem
In mijn tijd als hoofd ICT heb ik tot het laatst de Directie weten te overtuigen dat een backup fysiek op te bergen moet zijn in een kluis. En dat het niet meer op een tape past vind ik geen arugument: naar mijn mening heeft de backup-industrie dan liggen slapen.
24-01-2020, 10:43 door Anoniem
https://www.observantonline.nl/English/Home/Articles/articleType/ArticleView/articleId/17882/Cyberattack-started-back-in-October-Utrecht-was-secured
24-01-2020, 11:04 door Anoniem
Hallo allemaal,
In plaats van Rants kan men ook besluiten te leren...... Ook al DENK je je zaakjes op orde te hebben en kloppen je procedures. Dan nog kan er een niet voorziene fail plaats vinden.

Niets is waterdicht en een Backup server moet toegang hebben op tot de data van de servers om deze te back-uppen en een lokaal of remote file systeem om de back-ups weg te schrijven. 100% isolatie is dus IMHO niet mogelijk.
Interessant om te weten:

Waren de backup files versleuteld, of was de infectie ouder dan de retentie tijd? ,
Zodat bij een restore het randsome ware virus meteen weer actief werd.

Indien backup files versleuteld. Hoe toegang gekregen tot de backup server?

Natuurlijk had UM ook meerlaags beveiling. Welke fails hebben er opgetreden?
Hoe heeft het organisatie wijdt kunnen verspreiden?
Hoe heeft fail op fail op fail kunnen plaats vinden?

En fail op fail gebeurd niet alleen in de IT. NATG heef niet voor niets een programma wat "Seconds for disaster" heet. Idee is om van fails te leren en niet alleen maar te ranten.


,,
24-01-2020, 11:22 door Erik van Straten - Bijgewerkt: 24-01-2020, 11:25
Aan alle bijdragers hierboven: als criminelen dusdanig hoge privileges hebben dat ze bij jouw actuele data kunnen, vooral als ze weten dat je over veilige en recente back-ups beschikt, zullen ze vertrouwelijke informatie exfiltreren en je afpersen onder bedreiging van het openbaar maken (of verkopen) van die informatie.

Overigens, ook zonder dat je wordt afgeperst, wordt ongeautoriseerd gekopieerde vertrouwelijke informatie verkocht op Internet (dat is niks nieuws). Nb. een deel van het onderzoek op universiteiten wordt gefinancierd door bedrijven die, als tegenprestatie, bijvoorbeeld als eerste willen kunnen profiteren van onderzoeksresultaten. Alleen al om deze "geldstroom" niet in gevaar te brengen, is het net zo noodzakelijk voor universiteiten als voor bedrijven om ongeautoriseerde leestoegang tot onderzoeksmethodes en -resultaten zo goed als mogelijk te voorkomen.

Een goede back-up is vereist voor disaster recovery, maar helpt niet tegen alle (bestaande en opkomende) vormen van cybercrime!

M.i. moeten we daarom nu onze tijd niet verspillen aan het creëren van betere back-up oplossingen, maar ons concentreren op het voorkomen van ongeautoriseerde toegang en vervolgens escalatie van privileges. Hoe actuele malware dit doet, kun je o.a. in https://www.bleepingcomputer.com/news/security/trickbot-now-steals-windows-active-directory-credentials/ (vanochtend vroeg lokale tijd gepubliceerd) lezen.

Ik schreef dit al eerder, i.p.v. op back-up oplossingen moeten we m.i. focussen op:
1) het voorkomen dat criminelen toegang krijgen tot onze systemen;
2) (wetende dat 1 nooit voor 100% gaat lukken) het zo snel mogelijk ontdekken van intrusions;
3) het voorkomen dat de aanvallers eenvoudig meerdere systemen en/of accounts kunnen compromitteren, na één systeem of account te hebben gehacked;
4) het voorkomen dat aanvallers (snel) hoge privileges kunnen verkrijgen;
5) het voorkomen dat er überhaupt "God mode" privileges bestaan of inzetbaar zijn waarmee alle bestanden en/of back-ups in een domein (of daarbuiten) benaderd kunnen worden.

Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!
24-01-2020, 11:45 door Anoniem
De aanvallers die toegang wisten te krijgen tot het netwerk van de Universiteit Maastricht en bestanden op allerlei systemen versleutelden, wisten ook de back-ups te versleutelen. Die stonden namelijk op de universiteitsservers en waren daardoor voor de aanvallers te bereiken, dat meldt de Volkskrant.
Okee, ik weet niet wat de waarde is van dit bericht in de Volkskrant (ook kranten kunnen liegen is mijn ervaring), dus ik houd een slag om de arm, ..... maar ALS DIT WAAR IS, dan kun je totaal niet van welke beveiliging dan ook spreken. Een crimineel die zo gemakkelijk door de 'defensie' heen lacht, daar is gewoon geen beveiliging, daar was gewoon NIX.
24-01-2020, 11:49 door Anoniem
Door Anoniem: In mijn tijd als hoofd ICT heb ik tot het laatst de Directie weten te overtuigen dat een backup fysiek op te bergen moet zijn in een kluis. En dat het niet meer op een tape past vind ik geen argument: naar mijn mening heeft de backup-industrie dan liggen slapen.
Mijn back-ups zijn ook niet vastgekoppeld aan welk systeem dan ook en opgesloten in een afzonderlijke brandbeveiligde kluis. Je zou wel gek zijn als je dit niet doet!
24-01-2020, 11:54 door Anoniem
Backup's via een data-diode.
24-01-2020, 11:57 door Anoniem
Door Anoniem: In mijn tijd als hoofd ICT heb ik tot het laatst de Directie weten te overtuigen dat een backup fysiek op te bergen moet zijn in een kluis. En dat het niet meer op een tape past vind ik geen arugument: naar mijn mening heeft de backup-industrie dan liggen slapen.

Ik weet niet wanneer dat was maar tot 10 jaar geleden was dat een prima insteek, in deze dataslurpende tijd nauwelijks nog te doen.
24-01-2020, 11:59 door Anoniem
Dit bewijst dat het NIET had moeten gekund!!!
De UM is echt ZELF SCHULD dat het gebeurd is.
Stop het geouwehoer en fix it. De oplossing is echt EENVOUDIG.
Maak bu en plaats de physiek OFFLINE, dus op een andere lokatie, iedere dag opnieuw.
24-01-2020, 12:02 door Anoniem
Door Erik van Straten:
Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!

Ik weet niet wat je als "verkeerde adviezen" ziet, het is een feit dat er tegenwoordig te ondoordacht wordt omgegaan met backups. Vroeger was het normaal om een backup (tape of hard disk) te verwijderen. Dat kun je wel weg willen nemen door alles maar op de benaderbare hard disks te zetten, maar dat redt je niet in geval van rampen (brand, inbraak, overstroming, etc). Backups dienen altijd (deels) off line opgeborgen te worden.

De keuze die je schetst tussen backup goed regelen òf digitale inbraken voorkomen is er niet. Je moet beide doen.
24-01-2020, 12:04 door Anoniem
Door Erik van Straten: Aan alle bijdragers hierboven: als criminelen dusdanig hoge privileges hebben dat ze bij jouw actuele data kunnen, vooral als ze weten dat je over veilige en recente back-ups beschikt, zullen ze vertrouwelijke informatie exfiltreren en je afpersen onder bedreiging van het openbaar maken (of verkopen) van die informatie.

Overigens, ook zonder dat je wordt afgeperst, wordt ongeautoriseerd gekopieerde vertrouwelijke informatie verkocht op Internet (dat is niks nieuws). Nb. een deel van het onderzoek op universiteiten wordt gefinancierd door bedrijven die, als tegenprestatie, bijvoorbeeld als eerste willen kunnen profiteren van onderzoeksresultaten. Alleen al om deze "geldstroom" niet in gevaar te brengen, is het net zo noodzakelijk voor universiteiten als voor bedrijven om ongeautoriseerde leestoegang tot onderzoeksmethodes en -resultaten zo goed als mogelijk te voorkomen.

Een goede back-up is vereist voor disaster recovery, maar helpt niet tegen alle (bestaande en opkomende) vormen van cybercrime!

M.i. moeten we daarom nu onze tijd niet verspillen aan het creëren van betere back-up oplossingen, maar ons concentreren op het voorkomen van ongeautoriseerde toegang en vervolgens escalatie van privileges. Hoe actuele malware dit doet, kun je o.a. in https://www.bleepingcomputer.com/news/security/trickbot-now-steals-windows-active-directory-credentials/ (vanochtend vroeg lokale tijd gepubliceerd) lezen.

Ik schreef dit al eerder, i.p.v. op back-up oplossingen moeten we m.i. focussen op:
1) het voorkomen dat criminelen toegang krijgen tot onze systemen;
2) (wetende dat 1 nooit voor 100% gaat lukken) het zo snel mogelijk ontdekken van intrusions;
3) het voorkomen dat de aanvallers eenvoudig meerdere systemen en/of accounts kunnen compromitteren, na één systeem of account te hebben gehacked;
4) het voorkomen dat aanvallers (snel) hoge privileges kunnen verkrijgen;
5) het voorkomen dat er überhaupt "God mode" privileges bestaan of inzetbaar zijn waarmee alle bestanden en/of back-ups in een domein (of daarbuiten) benaderd kunnen worden.

Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!
Exfiltratie compliceert een aanval. Dit maakt de kans op succes voor de crimineel kleiner. Daarnaast is data die weg is nu eenmaal weg en betalen gaat daar niets aan veranderen. Na het betalen van een geldsom staat criminelen niets in de weg om de data nogmaals elders te verkopen, dus effectief moet je geëxfiltreerde data als bestaande in het publieke domein beschouwen.

Je zult echter maar moeilijk verder kunnen zonder data en goede back-ups zijn dan cruciaal.
24-01-2020, 12:25 door Anoniem
Door Anoniem: Backup's via een data-diode.
Een diode gaat maar één kant op. In dit geval van het te backuppen systeem naar de back-up. Dat is precies wat de ransomware ook nodig heeft. Dit is geen oplossing voor het probleem.
24-01-2020, 12:48 door Anoniem
Door Anoniem: In mijn tijd als hoofd ICT heb ik tot het laatst de Directie weten te overtuigen dat een backup fysiek op te bergen moet zijn in een kluis. En dat het niet meer op een tape past vind ik geen arugument: naar mijn mening heeft de backup-industrie dan liggen slapen.
Tegenwoordig heb je backups van een minimaal een Terrabyt nee dit doe je nie op tapes
24-01-2020, 12:49 door Anoniem
Dit krijg je als studenten je security regelen, lees nog in studie / geen ervaring, met alle respect voor de studenten…
24-01-2020, 12:59 door karma4
Door Anoniem: ….
Werk je met back-up sets, waarbij dus meer servers op dezelfde tape terecht komen, dan hoef je niet iedere dag honder tapes te vervangen. Dan kun je volstaan met een magazijn met 10 tapes per dag.
Peter
Het staat er inderdaad niet al wordt de suggestie wel gewekt.
Het hoeft voor mij geen tape te zijn. Het gaat er om dat je alle informatie ergens elders (denk aan brand) en compleet gescheiden (denk aan het opzettelijk/ per ongeluk verwijderen) en afgescheiden zonder wijziging alleen toevoegingen, hebt.
Met dat verhaal van 10 tapes per dag heb je de aandacht goed naar die belangrijke informatie gelegd, dat is de basis.
Het maken van images van elke machine is nooit werkbaar geweest. Een volledige backup dagelijks van alles net zo min.

Wat ik nog wel een zie is een offload van een database dan wel een extra kopie van een data gebied als "de backup" aanduiden. Zoiets kan werken met herstel van een typo maar heeft zoals ik het zie geen waarde als backup.
Vervelend als daar het woord backup daarvoor foutief gebruikt is en dat als afgevinkte eis als gereed doorgaat.
24-01-2020, 13:10 door karma4
Door Erik van Straten: ...
4) het voorkomen dat aanvallers (snel) hoge privileges kunnen verkrijgen;
5) het voorkomen dat er überhaupt "God mode" privileges bestaan of inzetbaar zijn waarmee alle bestanden en/of back-ups in een domein (of daarbuiten) benaderd kunnen worden.

Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!
Ik lees in je reactie een enkel Windows benadering waarbij storage beheer doorloopt als ware het de desktops van gebruikers.
Zoiets lijkt me in vele opzichten als basis al niet goed. Ik weet dat het vaak de goedkoopste en snel nee te zetten methode is.
24-01-2020, 13:25 door Anoniem
Servers backuppen ? Op tape ? Handmatig offsite brengen ?
Sorry maar dat klinkt allemaal als adviezen van 15 jaar geleden. Als je erg veel data hebt zoals universiteiten (vaak honderden TB's) dan heb je een storage systeem. (EMC, Netapp, Fujitsu etc ...) Dan is backuppen naar andere disken de enige oplossing anders red je het niet in 24 uur. Zorg er wel voor dat die backup storage in een ander DC staat dan de primary.
24-01-2020, 13:33 door Anoniem
Door Anoniem:
Door Anoniem: In mijn tijd als hoofd ICT heb ik tot het laatst de Directie weten te overtuigen dat een backup fysiek op te bergen moet zijn in een kluis. En dat het niet meer op een tape past vind ik geen arugument: naar mijn mening heeft de backup-industrie dan liggen slapen.
Tegenwoordig heb je backups van een minimaal een Terrabyt nee dit doe je nie op tapes
En ook dat is geen excuus... Wij zijn een jaar geleden weer gebruik gaan maken van tape backups. Na een risicoinventarisatie zijn wij tot de conclusie gekomen, dat een ransomware attack onze business dermate zou ontregelen dat wij naast de reguliere backups (inderdaad online backup storage), ook ervoor hebben gekozen om een wekelijks offsite backup te maken. Juist in het geval van een compromised backup.
24-01-2020, 14:02 door Anoniem
Door Anoniem:
Door karma4: Backups die online op het zelfde systeem staan? Noem dat alsjeblieft geen backup, zeker niet geschikt voor DR.

Ik lees nergens dat de backup op hetzelfde systeem staat. De backup stond op de servers van de universiteit, hoogstwaarschijnlijk dus DE backup servers. Vooral door de groei van de hoeveelheid data zie je steeds minder dat men een backup op tape maakt, en die vervolgens ook nog handmatig uit de systemen verwijdert.

Het probleem met tape back-up in het kader van DR is ook dat het terugspoelen van al die tapes, als ze al allemaal leesbaar zijn, lang kan duren. Wij hebben het voor onze organisatie uit laten rekenen en, als je niet per server een tape-unit gebruikt, dat kost ongeveer een maand. Het nadeel van per server een tape-unit is bovendien dat je bij het maken van je back-ups per server een tape moet gaan gebruiken. Die wil je ook niet online laten, dus zelfs als er maar 100MB is gewijzigd sinds de laatste back-up, moet je een nieuwe tape pakken voor die server.

Werk je met back-up sets, waarbij dus meer servers op dezelfde tape terecht komen, dan hoef je niet iedere dag honder tapes te vervangen. Dan kun je volstaan met een magazijn met 10 tapes per dag.

Peter

"Die stonden namelijk op de universiteitsservers en waren daardoor voor de aanvallers te bereiken, dat meldt de Volkskrant."

Natuurlijk kunnen de backservers op het directe netwerk hangen als tapes te lang duren. Maar er zijn zoveel manieren om dat beter op te lossen. De "online" backup kun je altijd nog lekker een tijdje incrementeel backuppen elke paar dagen / week op tape. Je kan als het om gegevens van tientallen jaren gaat ook denken. Nouja, laten we van ieder half jaar even een aparte offline kopie maken in plaats van alles op "de" backupservers" te laten staan. Je kan extra backupservers achter de gewone hangen die slechts tijdelijk toegang hebben, backup, klaar en ze zijn weer een 2/3/4/week/maand offline en niet bereikbaar als tapes je te lang duren. Het gaat hier om backups van tientallen jaren data. Dat dat men op 1 online plek heeft bewaart is naief.
24-01-2020, 14:06 door Erik van Straten - Bijgewerkt: 24-01-2020, 14:09
Door Anoniem: Exfiltratie compliceert een aanval. Dit maakt de kans op succes voor de crimineel kleiner.
Kan ik jou inhuren als beveiligingsexpert?

Maakt niet uit of ze domain admin worden, onze data diode of feilloze firewall blokkeert elke bit van hinnen naar buiten?

Sjeemig, ben je nog nooit bij een doorsnee organisatie, laat staan een univeristeit, binnen geweest of zo? Ik wens je gigantisch veel geluk met jouw aanpak (dat zul je hard nodig hebben).
24-01-2020, 14:09 door botbot
Door Erik van Straten: Aan alle bijdragers hierboven: als criminelen dusdanig hoge privileges hebben dat ze bij jouw actuele data kunnen, vooral als ze weten dat je over veilige en recente back-ups beschikt, zullen ze vertrouwelijke informatie exfiltreren en je afpersen onder bedreiging van het openbaar maken (of verkopen) van die informatie.

Overigens, ook zonder dat je wordt afgeperst, wordt ongeautoriseerd gekopieerde vertrouwelijke informatie verkocht op Internet (dat is niks nieuws). Nb. een deel van het onderzoek op universiteiten wordt gefinancierd door bedrijven die, als tegenprestatie, bijvoorbeeld als eerste willen kunnen profiteren van onderzoeksresultaten. Alleen al om deze "geldstroom" niet in gevaar te brengen, is het net zo noodzakelijk voor universiteiten als voor bedrijven om ongeautoriseerde leestoegang tot onderzoeksmethodes en -resultaten zo goed als mogelijk te voorkomen.

Een goede back-up is vereist voor disaster recovery, maar helpt niet tegen alle (bestaande en opkomende) vormen van cybercrime!

M.i. moeten we daarom nu onze tijd niet verspillen aan het creëren van betere back-up oplossingen, maar ons concentreren op het voorkomen van ongeautoriseerde toegang en vervolgens escalatie van privileges. Hoe actuele malware dit doet, kun je o.a. in https://www.bleepingcomputer.com/news/security/trickbot-now-steals-windows-active-directory-credentials/ (vanochtend vroeg lokale tijd gepubliceerd) lezen.

Ik schreef dit al eerder, i.p.v. op back-up oplossingen moeten we m.i. focussen op:
1) het voorkomen dat criminelen toegang krijgen tot onze systemen;
2) (wetende dat 1 nooit voor 100% gaat lukken) het zo snel mogelijk ontdekken van intrusions;
3) het voorkomen dat de aanvallers eenvoudig meerdere systemen en/of accounts kunnen compromitteren, na één systeem of account te hebben gehacked;
4) het voorkomen dat aanvallers (snel) hoge privileges kunnen verkrijgen;
5) het voorkomen dat er überhaupt "God mode" privileges bestaan of inzetbaar zijn waarmee alle bestanden en/of back-ups in een domein (of daarbuiten) benaderd kunnen worden.

Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!

Je hebt helemaal gelijk in bovenstaande. Maar de adviezen voor betere en veiligere backupvoorzieningen zijn niet "verkeerd" ze zijn complementair. Beide moeten doorgevoerd worden.
24-01-2020, 14:13 door botbot
Door Anoniem: Backup's via een data-diode.

Ja, door ransomware geencrypte data die via de backup naar binnen wordt getrokken, wordt door die data-diode keurig tegen gehouden op weg naar buiten. Nuttig. Dan kan die geencrypte data in ieder geval niet meer gestolen worden van de backupserver. I think you're on to something here /sarcasm
24-01-2020, 14:21 door Erik van Straten
Door botbot:
Door Erik van Straten: Aan alle bijdragers hierboven: als criminelen dusdanig hoge privileges hebben dat ze bij jouw actuele data kunnen, vooral als ze weten dat je over veilige en recente back-ups beschikt, zullen ze vertrouwelijke informatie exfiltreren en je afpersen onder bedreiging van het openbaar maken (of verkopen) van die informatie.

Overigens, ook zonder dat je wordt afgeperst, wordt ongeautoriseerd gekopieerde vertrouwelijke informatie verkocht op Internet (dat is niks nieuws). Nb. een deel van het onderzoek op universiteiten wordt gefinancierd door bedrijven die, als tegenprestatie, bijvoorbeeld als eerste willen kunnen profiteren van onderzoeksresultaten. Alleen al om deze "geldstroom" niet in gevaar te brengen, is het net zo noodzakelijk voor universiteiten als voor bedrijven om ongeautoriseerde leestoegang tot onderzoeksmethodes en -resultaten zo goed als mogelijk te voorkomen.

Een goede back-up is vereist voor disaster recovery, maar helpt niet tegen alle (bestaande en opkomende) vormen van cybercrime!

M.i. moeten we daarom nu onze tijd niet verspillen aan het creëren van betere back-up oplossingen, maar ons concentreren op het voorkomen van ongeautoriseerde toegang en vervolgens escalatie van privileges. Hoe actuele malware dit doet, kun je o.a. in https://www.bleepingcomputer.com/news/security/trickbot-now-steals-windows-active-directory-credentials/ (vanochtend vroeg lokale tijd gepubliceerd) lezen.

Ik schreef dit al eerder, i.p.v. op back-up oplossingen moeten we m.i. focussen op:
1) het voorkomen dat criminelen toegang krijgen tot onze systemen;
2) (wetende dat 1 nooit voor 100% gaat lukken) het zo snel mogelijk ontdekken van intrusions;
3) het voorkomen dat de aanvallers eenvoudig meerdere systemen en/of accounts kunnen compromitteren, na één systeem of account te hebben gehacked;
4) het voorkomen dat aanvallers (snel) hoge privileges kunnen verkrijgen;
5) het voorkomen dat er überhaupt "God mode" privileges bestaan of inzetbaar zijn waarmee alle bestanden en/of back-ups in een domein (of daarbuiten) benaderd kunnen worden.

Trap niet in de val van symptoombestrijding, en security.nl bijdragers: hou op met het geven van verkeerde adviezen!

Je hebt helemaal gelijk in bovenstaande. Maar de adviezen voor betere en veiligere backupvoorzieningen zijn niet "verkeerd" ze zijn complementair. Beide moeten doorgevoerd worden.
Maar waar moet je NU mee beginnen, vooral als je al een prima back-up voorziening hebt die alleen kwetsbaar is voor criminelen die de identiteit van vertrouwde beheerders kunnen overnemen?

Onbegrijpelijk hoe mensen in hun eigen gelijk blijven volharden en weigeren open te staan voor goede argumenten. Als ik ongelijk heb, wat goed kan (ik ben ook maar een mens en heb veel fouten gemaakt in m'n leven), kom dan met goede tegenargumenten.

En nee, dat je moet back-uppen is dat niet, want UM had een back-up. Wat fout ging was dat iemand met voldoende privileges deze onbruikbaar kon maken. Om te beginnen moet je dat voorkomen, anders is ALLES in je ICT infra gebouwd op drijfzand.
24-01-2020, 14:39 door Anoniem
Maar waar moet je NU mee beginnen, vooral als je al een prima back-up voorziening hebt die alleen kwetsbaar is voor criminelen die de identiteit van vertrouwde beheerders kunnen overnemen?

Onbegrijpelijk hoe mensen in hun eigen gelijk blijven volharden en weigeren open te staan voor goede argumenten. Als ik ongelijk heb, wat goed kan (ik ben ook maar een mens en heb veel fouten gemaakt in m'n leven), kom dan met goede tegenargumenten.

En nee, dat je moet back-uppen is dat niet, want UM had een back-up. Wat fout ging was dat iemand met voldoende privileges deze onbruikbaar kon maken. Om te beginnen moet je dat voorkomen, anders is ALLES in je ICT infra gebouwd op drijfzand.
Ik moet je weer gelijk geven Erik. Ja, helaas merk ik dat ook dat mensen gewoon niet open staan voor verbetering. Zelfs 1 mm opschuiven naar het gezonde verstand kost de meeste mensen nog moeite. Ik vind dan ook dat wij in de security (ik werkte daar 14 jaar in) elke dag moeten bijleren. Wat vroeger een goede doordachte security was, kan dat morgen al helemaal niet zijn. En we moeten inderdaad ook toegeven dat we fouten maken, want hoe kun je in hemelsnaam van je fouten leren en migreren naar een betere security, als je die fouten niet eens erkent?
24-01-2020, 14:46 door Anoniem
Wat ik me nou afvraag, hoe wil je je backup hiertegen beschermen? Want je ziet in principe op je eigen netwerk toch niet dat je data onder water encrypt is zo lang de key ergens beschikbaar is? Een encrypted file die ik backup blijft toch ook in de backup toch encrypted? Als op enig moment de key verwijderd wordt, dan is mijn backup toch ook niet meer bruikbaar? Wel kan ik met een unmutated backup terug naar een moment dat de encryptie er nog niet was, maar wanneer dat weken (en in het Volkskrant artikel spreken ze van maanden) terug is en ik moet zo ver terug in de tijd, wat is dat voor een kostenpost?
24-01-2020, 14:48 door [Account Verwijderd] - Bijgewerkt: 24-01-2020, 14:49
Officieel weten we natuurlijk nog niks hier. Zet dan even je kalender op woensdag 5 februari 2020, want dan wordt er opening van zaken gegeven (althans dat hoop ik toch)

In de tussentijd is het wachten op voldoende journalisten die op deze persconferentie zullen verschijnen die ook de juiste vragen zullen gaan stellen. Ik ben wel benieuwd wat er precies waar is van alle berichten die wij tot nu toe gezien hebben (losgeld betalen, en de back-up affaire).
24-01-2020, 15:12 door Anoniem
Door Anoniem: Backup's via een data-diode.

Het cynisme druipt er vanaf en toch herkennen mensen het niet. :)
24-01-2020, 15:36 door Anoniem
Dat ze dat niet weten op een UNIVERSITEIT ???
Daar zou ik mij niet aanmelden.
24-01-2020, 15:51 door Anoniem
Ik snap niet waarom de overheid zichzelf en het volk niet beter beschermd door Linux (bv "Devuan") te adviseren
voor bedrijven, scholen en prive thuis.

Devuan heeft geen "system-d" en is niet gevoelig voor Windows virussen en ransomware
het is gratis, de overheid zou miljoenen kunnen besparen en ook meteen een veel veiliger OS hebben
dan Windows.

Het feit dat ze dit nog steeds niet doen, zegt eigenlijk al genoeg
De conclusie die ik hieruit trek is:
De mensen (het volk) dom houden, zodat ze via Windows 10 (wat gewoon een big brother os is) het volk kunnen blijven monitoren, en gelijk miljoenen verdienen aan ons surf gedrag....
24-01-2020, 16:23 door SPer - Bijgewerkt: 24-01-2020, 16:26
Door Anoniem:
Door karma4: Backups die online op het zelfde systeem staan? Noem dat alsjeblieft geen backup, zeker niet geschikt voor DR.

Ik lees nergens dat de backup op hetzelfde systeem staat. De backup stond op de servers van de universiteit, hoogstwaarschijnlijk dus DE backup servers. Vooral door de groei van de hoeveelheid data zie je steeds minder dat men een backup op tape maakt, en die vervolgens ook nog handmatig uit de systemen verwijdert.

Het probleem met tape back-up in het kader van DR is ook dat het terugspoelen van al die tapes, als ze al allemaal leesbaar zijn, lang kan duren. Wij hebben het voor onze organisatie uit laten rekenen en, als je niet per server een tape-unit gebruikt, dat kost ongeveer een maand. Het nadeel van per server een tape-unit is bovendien dat je bij het maken van je back-ups per server een tape moet gaan gebruiken. Die wil je ook niet online laten, dus zelfs als er maar 100MB is gewijzigd sinds de laatste back-up, moet je een nieuwe tape pakken voor die server.

Werk je met back-up sets, waarbij dus meer servers op dezelfde tape terecht komen, dan hoef je niet iedere dag honder tapes te vervangen. Dan kun je volstaan met een magazijn met 10 tapes per dag.

Peter
In principe hoeven de backup niet op tapes te staan (lang geleden in de tijd dat ik nog op mainframes werkte heb ik mmegemaakt dat backups van tapes niet meer te lezen waren ;-) )
Wat wel van belang is dat de backups nadat ze gemaakt zijn zoveel moegelijk airgapped zijn en bij het maken van een nieuwe backup (full, incremental of differential) de betreffende servers niet weer gekoppeld wprden maar dat dit wordt gedaan op een andere server. Tegenwoordig kost een TB niet veel dus dat zou geen probleem moeten zijn .
24-01-2020, 16:34 door karma4
Door Anoniem: Wat ik me nou afvraag, hoe wil je je backup hiertegen beschermen? Want je ziet in principe op je eigen netwerk toch niet dat je data onder water encrypt is zo lang de key ergens beschikbaar is? Een encrypted file die ik backup blijft toch ook in de backup toch encrypted? Als op enig moment de key verwijderd wordt, dan is mijn backup toch ook niet meer bruikbaar? Wel kan ik met een unmutated backup terug naar een moment dat de encryptie er nog niet was, maar wanneer dat weken (en in het Volkskrant artikel spreken ze van maanden) terug is en ik moet zo ver terug in de tijd, wat is dat voor een kostenpost?
Een Storage systeem kun je uitrusten met meerdere verbonden netwerken Je moet die gescheiden houden van wat aan je gebruikers kant zit en wat aan de storage beheerskant. Nee storage systemen maken geen deel uit van de rest van het netwerk als dat goed is. De touwtjes zelf moet je kunnen doorknippen. Vele mogelijkheden, kost wel wat.
24-01-2020, 16:57 door Anoniem
Door Anoniem:
Door Anoniem: Backup's via een data-diode.

Het cynisme druipt er vanaf en toch herkennen mensen het niet. :)

Veel hardwerkende systeembeheerders kunnen uitingen van cynisme missen als kiespijn, ook als ze "grappig" waren bedoeld, want het draagt niet bij aan een oplossing. De sfeer wordt er hier ook niet beter door.
24-01-2020, 17:07 door Anoniem
Door karma4: De touwtjes zelf moet je kunnen doorknippen. Vele mogelijkheden, kost wel wat.

Verkeerd om gedacht:
Je moet alleen verbinden tijdens het maken van de backup. Daarna weer losmaken.
24-01-2020, 18:12 door Erik van Straten
Door Anoniem: Wat ik me nou afvraag, hoe wil je je backup hiertegen beschermen? Want je ziet in principe op je eigen netwerk toch niet dat je data onder water encrypt is zo lang de key ergens beschikbaar is? Een encrypted file die ik backup blijft toch ook in de backup toch encrypted?
Klopt. De huidige praktijk is, voor zover ik weet, niet wat rootkits vele jaren geleden deden (in de pré-Windows DOS tijd al), namelijk bij het tonen van directories gegevens van de ongewijzigde bestanden laten zien (terwijl executables in werkelijkheid groter waren dan getoond), of mapnamen werden weggelaten in dat soort listings. Er bestond zelfs malware die zover ging dat als je een hash van een file liet berekenen, je de hash van het origineel terugkreeg (dit om tools als "tripwire" voor de gek te houden, en je te laten denken dat er niets aan de hand is.

Voor zover ik weet worden momenteel veelal eerst zoveel mogelijk accounts gecompromitteerd en systemen gebackdoored (op een zo onopvallend mogelijke manier), waarna, aan het einde van de werkweek of aan het begin van een vakantie, en masse bestanden, vooral "op servers" (d.w.z. op storage benaderbaar vanaf die servers), worden versleuteld en back-ups onklaar worden gemaakt. De bedoeling hiervan is om te voorkomen dat beheerders tussendoor iets merken en in kunnen grijpen.

Echter, in https://safebreach.com/Post/EFS-Ransomware (bron: [1]) kun je lezen over een scenario waarvan het wachten was tot iemand dit zou bedenken en melden. Op die manier zouden criminelen, gebruikmakend van standaard Windows tools (lastig te detecteren door virusscanners dus), op hun gemak bestanden kunnen versleutelen, zonder dat gebruikers en beheerders hier iets van hoeven te merken.

Mogelijke fix (naast het advies in die bijdrage): zorg voor een losstaand, veilig, systeem dat controleert wat gebackupped wordt, zoals anoniem beschrijft en ik aanvul in https://www.security.nl/posting/639865/Belgisch+bedrijf%3A+betalen+losgeld+ransomware+was+goedkoper#posting640019. Daar kun je, bij dit soort toekomstige ransomware, intrusions wellicht vroegtijdig mee ontdekken. Maar zodra er meedere accounts gecompromitteerd zijn, vooral als daar accounts met hogere privileges bij zitten, wordt het gevecht steeds moeilijker te winnen. Deze "fix" moet dan ook onderdeel zijn van een pakket maategelen, zoals ik in die bijdrage en hierboven kort maar krachtig beschrijf.

[1] https://www.theregister.co.uk/2020/01/21/efs_ransomware_poc/.
24-01-2020, 19:35 door karma4
Door Anoniem:
Verkeerd om gedacht: Je moet alleen verbinden tijdens het maken van de backup. Daarna weer losmaken.
Nope, ik hoefde het niet te bedenken, het is de Enterprise class benadering. Volledig gescheiden netwerken.
http://www.redbooks.ibm.com/redbooks/pdfs/sg245470.pdf figuur 1-10 bladzijde 12.
Het deel met de data en backup is volledig gescheiden van de gebruikerskant. Het kost wat zoiets, geen thuisgebruik san al hebben die een ruime opslagcapaciteit. Je verliest ook een aantal van de fysieke adapters in de dozen. Ecm an andere echt grote storageleveranciers doen het op de zelfde wijze.
24-01-2020, 20:09 door Anoniem
Door karma4:
Door Anoniem:
Verkeerd om gedacht: Je moet alleen verbinden tijdens het maken van de backup. Daarna weer losmaken.
Nope, ik hoefde het niet te bedenken, het is de Enterprise class benadering. Volledig gescheiden netwerken.
http://www.redbooks.ibm.com/redbooks/pdfs/sg245470.pdf figuur 1-10 bladzijde 12.
Het deel met de data en backup is volledig gescheiden van de gebruikerskant. Het kost wat zoiets, geen thuisgebruik san al hebben die een ruime opslagcapaciteit. Je verliest ook een aantal van de fysieke adapters in de dozen. Ecm an andere echt grote storageleveranciers doen het op de zelfde wijze.

zucht... mr google maar wat weer... malware/cryptoware op client komt via server desondanks nog steeds op die SAN. dat is ook logisch want als client 100% absoluut geen manier had om op SAN te komen, dan was er ook geen SAN mogelijk want dan hadden block devices / files ook niet via server aangeboden kunnen worden op client: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.
24-01-2020, 20:35 door Anoniem
"Echter, in https://safebreach.com/Post/EFS-Ransomware (bron: [1]) kun je lezen over een scenario waarvan het wachten was tot iemand dit zou bedenken en melden. Op die manier zouden criminelen, gebruikmakend van standaard Windows tools (lastig te detecteren door virusscanners dus), op hun gemak bestanden kunnen versleutelen, zonder dat gebruikers en beheerders hier iets van hoeven te merken."

oh. het is me nu duidelijk hoe je als UM maanden lang 'niets´ door kunt hebben.

hier helpt 'karma SAN op een appart netwerk' ook niet, want dit zit in de MS aangeleverde NTFS drivers/kernel. het enige wat je kunt doen is geen NTFS door MS laten doen of geen NTFS dus gebruiken dan. de beef van de cryptoware zit eigenlijk dus al in de officiele windows ntfs drivers: je hoeft het maar aan te zetten.

dit lijkt mij eigenlijk net zo naief stupide als bewust java scripts in pdf gaan proppen of macros automatisch uitvoeren uit documenten. had er iemand bij MS dit niet 'aan kunnen voelen´ ? het OS, dat eenvoudig powned kan worden, de baas laten zijn van de encryptie van een file systeem op file basis, daar zit de design error. het zou me niets verbazen dat dit is 'gemaakt' om met MW windows in ze cloud te kunnen werken en op die manier je ´data' voor de cloud vendor te beschermen.
25-01-2020, 01:53 door Anoniem
Lees vele verhalen hier. Universiteit en tapes ;) met backup per keer van honderen TB's ga je niet redden met tapes ! Ik ben denk ik de eerste die zeg dat mijn backup kennis te wensen overlaat, maar dat het wel wat ingewikkelde ligt dan even een tape pakken of zo. Zeker als je honderden TB's moet backuppen. Ook hier geldt weer, de beste stuurlui staat aan wal !
25-01-2020, 09:49 door karma4
Door Anoniem: zucht... mr google maar wat weer... malware/cryptoware op client komt via server desondanks nog steeds op die SAN. dat is ook logisch want als client 100% absoluut geen manier had om op SAN te komen, dan was er ook geen SAN mogelijk want dan hadden block devices / files ook niet via server aangeboden kunnen worden op client: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.

Het is de intro hoe je storagemanagement inricht in grote omgevingen. Je moet het gezien hebben om die link te vinden.
Nu geen google maar wat om iets te vinden maar google naar een link voor jou en de anderen.

De bediening en systemen blijven volledig gescheiden. Die apparatuur hoort overal buiten te blijven.
Je kan wat zien aan de hoeveelheid data en wat er veranderd. Prima om vreemd gedrag te zien en de boel op een signaal te stoppen. Of ze hebben deze aanpak niet of ze hebben dit deel toch aan het intern gehangen.


Je redenering dat de apparatuur de data transporteert en daarom besmet is, klopt niet.
Dan zou elk apparaat ofwel het hele internet dat transport doet besmet zijn. Ook een data diode valt daar dan onder.
En nee ook dat deel heeft weinig van doen dat het in een NTFS drive of ZFS driver zou zitten. Het zit aan de andere kant.
25-01-2020, 09:51 door Anoniem
Door Anoniem:oh. het is me nu duidelijk hoe je als UM maanden lang 'niets´ door kunt hebben.

EFS can be turned off for a machine by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1. Note: accessing this key requires administrator rights.

hier helpt 'karma SAN op een appart netwerk' ook niet, want dit zit in de MS aangeleverde NTFS drivers/kernel. het enige wat je kunt doen is geen NTFS door MS laten doen of geen NTFS dus gebruiken dan

Waar zit je aan te denken, als uitwijkmogelijkheid? Het mounten van bestaande NTFS server partities met de NTFS-3G driver onder een Linux instance?

dit lijkt mij eigenlijk net zo naief stupide als bewust java scripts in pdf gaan proppen of macros automatisch uitvoeren uit documenten. had er iemand bij MS dit niet 'aan kunnen voelen´ ?

Insecure by design. Men zou bijna gaan denken dat een kwade genius dat allemaal met opzet heeft uitgekiend.
Terwille van het winstbejag heeft men de onwetendheid van de gemiddelde eindgebruiker tot heilig verklaard.
25-01-2020, 11:22 door Anoniem
Door karma4:
Door Anoniem: zucht... mr google maar wat weer... malware/cryptoware op client komt via server desondanks nog steeds op die SAN. dat is ook logisch want als client 100% absoluut geen manier had om op SAN te komen, dan was er ook geen SAN mogelijk want dan hadden block devices / files ook niet via server aangeboden kunnen worden op client: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.

Het is de intro hoe je storagemanagement inricht in grote omgevingen. Je moet het gezien hebben om die link te vinden.
Nu geen google maar wat om iets te vinden maar google naar een link voor jou en de anderen.

De bediening en systemen blijven volledig gescheiden. Die apparatuur hoort overal buiten te blijven.
Je kan wat zien aan de hoeveelheid data en wat er veranderd. Prima om vreemd gedrag te zien en de boel op een signaal te stoppen. Of ze hebben deze aanpak niet of ze hebben dit deel toch aan het intern gehangen.


Je redenering dat de apparatuur de data transporteert en daarom besmet is, klopt niet.
Dan zou elk apparaat ofwel het hele internet dat transport doet besmet zijn. Ook een data diode valt daar dan onder.
En nee ook dat deel heeft weinig van doen dat het in een NTFS drive of ZFS driver zou zitten. Het zit aan de andere kant.


zucht... twee tegen voorbeelden om je stelling (a la "gebruik een SAN en no-more-crytpo-ellende") te ontkrachten:

1) de cryptoware zit in de windows clients en de data gaat encrypted van die bron af (via je servers, over smb) je SAN in.
2) de server gebruikt SAN en heeft een NTFS op die SAN, client wordt gehakt via phising, toegang to server wordt verkregen na tijd / social enginering en NTFS EFS wordt misbruikt => encrypted block device in je SAN [of je nu een disk in een server hebt via SAS/SATA of dat je SAN devices gekoppeld hebt via iSCSI of LUNs doet er niet toe].

dan nu omgekeerd, met je gestelde absoluutheid van je oplossing als startpunt in de logica.

dan komt je weer uit op: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.

een paradox => een onjuist startpunt => het gebruiken van een SAN kan in zijn absolute zin dus niet een oplossing zijn tegen cryptoware.

eigenlijk alleen continue monitoring van integriteit van data in de gehele keten tesamen met regelmatig data off-line dupliceren kan je helpen tegen cryptoware. je hebt dan enkel en alleen een DETECTOR waarop je zult MOET acteren als ie af gaat. je weet dat er iets mis is, maar echt voorkomen lukt je niet.

je kunt wel damage control methodiek toepassen:

je kunt het met een goede data infra architectuur wel iets moelijker maken snelle detectie te omzeilen door bijv geen MS met NTFS op storage servers te ontsluiten naar MS clients. als storage backend ander OSen zijn met andere FSen dan clients, dan moet een hacker vanuit een client twee typen OSen pownen en FSen een loer draaien. als je dan ook nog eens 2FA op je backend gebruikt wordt dat nog extra lastiger, maar again, als de data vanaf de client (de bron) meteen al cryptoware ridden je backend in gaat, dan heb je er niets aan gehad. het andere wat je dan kan helpen is niet alles op een hoop willen zodat het pownen van een client pool niet de data opslag van onafhankelijke data pools beinvloed. dit gaat echter weer tegen de alles-centraal-is-beter-want-dan-hebben-we-overzicht visie die in IT ook heerst als een dogma.

maar er is geen silver bullet.
25-01-2020, 12:57 door Anoniem
"EFS can be turned off for a machine by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1. Note: accessing this key requires administrator rights."

en dus ook weer aan door hacker die op je systeem zit.
25-01-2020, 15:43 door Anoniem
Het lijkt me toch of veel posters hier een backup als een copie van de data zien
Maar volgens mij is een backup veel meer dan dat: het betekent ook een veilige copie van je data.
Met een backup die via internet te manipuleren is als je rechten maar hoog genoeg zijn is er geen sprake van backup.
25-01-2020, 16:02 door Erik van Straten
Door Anoniem: "EFS can be turned off for a machine by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1. Note: accessing this key requires administrator rights."

en dus ook weer aan door hacker die op je systeem zit.
Die, bijv. via een wat oudere printer driver (zoals van Ricoh, zie https://seclists.org/fulldisclosure/2020/Jan/34), de noodzakelijke administrator "rechten" vaak eenvoudig kan verkrijgen - mocht het gecompromitteerde eindgebruiker-account de bijbehorende priviliges niet hebben.
25-01-2020, 17:27 door Anoniem
Privileged Access Management is niet voor niets een actueel en belangrijk thema.
25-01-2020, 17:42 door karma4
Door Anoniem:
zucht... twee tegen voorbeelden om je stelling (a la "gebruik een SAN en no-more-crytpo-ellende") te ontkrachten:
..
je kunt wel damage control methodiek toepassen:
...
maar er is geen silver bullet.
zucht … de clients byods van de studenten zijn niet geraakt.
Het is het interne netwerk met daar de endpoints, dat zijn er al een stuk minder maar wel ernstiger.
Nu lijkt het er op dat niet alleen de endpoints en wat daar aan hangt geraakt is maar meteen de kritische beheerders delen met de backups. Je SAN op een apart netwerk en op hardware niveau geeft een flink betere afscherming.
Als ze er Nasjes voor gehaald hebben want goedkoper en dat direct bij de gebruikers op het zelfde netwerk gezet hebben met de zelfde machines LDAP of AD voor beheer dan heb je die scheiding niet, Dat is vragen om problemen.
Je moet zorgen dat de backup niet geraakt wordt en er offline versies van zijn.
Heb je ooit wel eens een SAN meegemaakt? Geen hardware schijven meer in de betreffende machines.

Je moet de hele keten op orde hebben niet enkel her een der een malware scanner omdat het in afvinklijst staat.
Die versnelde invoering van carbon black wat op een SIEM lijkt geeft te denken.
25-01-2020, 18:47 door Anoniem
Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden.

Met alleen domeinbeheerrechten los je het veiligheidsprobleem dus niet op. Je moet het moeilijker maken met ten minste een fysieke schakelaar, air gap (uitnemen of wisselen van backupeenheden), of het beperken van rechten voor iedereen, dus ook voor alle domeinbeheerders. Alleen met een lokaal beheerderaccount zou je bij de reeds gemaakte backups moeten kunnen komen. Als je slim genoeg bent kun je dat failsafe inrichten mits de beheerders begrijpen wat ze wel en niet moeten doen (beheerder = weakest link). Als beheerders niet te vertrouwen zijn, maak dan altijd gebruik van een air gap. Dat zal dus de standaardsituatie moeten zijn in veel organisaties.

Het maakt verder niet uit of het op tapes staat of op hard disks, beide zijn fysiek verwijderbaar. Al is het maar door een netwerkkabel.
25-01-2020, 19:05 door Anoniem
Door Anoniem: "EFS can be turned off for a machine by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration to 1. Note: accessing this key requires administrator rights."

en dus ook weer aan door hacker die op je systeem zit.

Zo'n opmerking was te verwachten. Het punt mag duidelijk zijn.

Daarom moet men de administator accounts, en de fysieke locaties waar die terminals staan, ombouwen tot een oninneembare vesting. Slaag je daar organisatie niet goed in, en zowel met Windows, macOS of Linux is dat niet eenvoudig, dan trek je het in de strijd tegen criminelen snel aan het kortste eind.
25-01-2020, 23:45 door Anoniem
Door karma4:
Door Anoniem:
zucht... twee tegen voorbeelden om je stelling (a la "gebruik een SAN en no-more-crytpo-ellende") te ontkrachten:
..
je kunt wel damage control methodiek toepassen:
...
maar er is geen silver bullet.
zucht … de clients byods van de studenten zijn niet geraakt.
Het is het interne netwerk met daar de endpoints, dat zijn er al een stuk minder maar wel ernstiger.
Nu lijkt het er op dat niet alleen de endpoints en wat daar aan hangt geraakt is maar meteen de kritische beheerders delen met de backups. Je SAN op een apart netwerk en op hardware niveau geeft een flink betere afscherming.
Als ze er Nasjes voor gehaald hebben want goedkoper en dat direct bij de gebruikers op het zelfde netwerk gezet hebben met de zelfde machines LDAP of AD voor beheer dan heb je die scheiding niet, Dat is vragen om problemen.
Je moet zorgen dat de backup niet geraakt wordt en er offline versies van zijn.
Heb je ooit wel eens een SAN meegemaakt? Geen hardware schijven meer in de betreffende machines.

Je moet de hele keten op orde hebben niet enkel her een der een malware scanner omdat het in afvinklijst staat.
Die versnelde invoering van carbon black wat op een SIEM lijkt geeft te denken.

a) universeiten hebben een vendor lockin met microsoft. 40% korting. Anders kunnen ze niet eens een IT draaien door het kosten oogpunt
b) SIEM kost de nodige financiele middelen. Business case: echt vele malen meer dan 250.000. Zelf bij een SOC-as-a-service kijk je op subscriptions van 30.000 - 40.000 per maand. Ze worden per eps (event per second) of gebruiker model gecalculeerd.Maastricht had (uit mijn hoofd) 40000 studenten... dat is geen wisselgeld !
c) administrator accounts. Erik zei het al meerdere malen maar nogmaals: ze hadden admin privileges. Al jullie oplossingen van vereisen dat administrators niet op de backup kunnen komen op het netwerk..Practisch slecht uitvoerbaar.

mijn voorstel is wat simpeler: layered defense + security awareness naar je gebruikers.

- awareness om clicking baiting te verminderen
- email security gateway (microsoft atp, proofpoint, mimecast etc; url rewriting om phishing & malware (bijv. emotet) tegen te gaan
- web filteirng oplossing (umbrella bijv of liever zscaler) dns niveau callback verhelpen
- endpoint ransomware - threat mitigation. (sophos interceptx; tevens blokkert het credential escalation)
- als alles faalt; offline backup. Tape robot / library + procedures en processen wat te doen bij een disaster.

Eminus
26-01-2020, 06:05 door Anoniem
Door Anoniem: Lees vele verhalen hier. Universiteit en tapes ;) met backup per keer van honderen TB's ga je niet redden met tapes ! Ik ben denk ik de eerste die zeg dat mijn backup kennis te wensen overlaat, maar dat het wel wat ingewikkelde ligt dan even een tape pakken of zo. Zeker als je honderden TB's moet backuppen. Ook hier geldt weer, de beste stuurlui staat aan wal !

Je kennis van tapes laat te wensen over. LTO-8 is 12TB. Er zijn plannen voor bijna 200 TB.

Als je honderden TB's dagelijks moet backuppen doe je meestal iets fout. De bulk hoort eenmalig te zijn, alleen wijzigingen (diff's) hebben een dagelijkse backup nodig.
26-01-2020, 09:07 door Anoniem
Door karma4:
Door Anoniem:
zucht... twee tegen voorbeelden om je stelling (a la "gebruik een SAN en no-more-crytpo-ellende") te ontkrachten:
..
je kunt wel damage control methodiek toepassen:
...
maar er is geen silver bullet.
zucht … de clients byods van de studenten zijn niet geraakt.
Het is het interne netwerk met daar de endpoints, dat zijn er al een stuk minder maar wel ernstiger.
Nu lijkt het er op dat niet alleen de endpoints en wat daar aan hangt geraakt is maar meteen de kritische beheerders delen met de backups. Je SAN op een apart netwerk en op hardware niveau geeft een flink betere afscherming.
Als ze er Nasjes voor gehaald hebben want goedkoper en dat direct bij de gebruikers op het zelfde netwerk gezet hebben met de zelfde machines LDAP of AD voor beheer dan heb je die scheiding niet, Dat is vragen om problemen.
Je moet zorgen dat de backup niet geraakt wordt en er offline versies van zijn.
Heb je ooit wel eens een SAN meegemaakt? Geen hardware schijven meer in de betreffende machines.

Je moet de hele keten op orde hebben niet enkel her een der een malware scanner omdat het in afvinklijst staat.
Die versnelde invoering van carbon black wat op een SIEM lijkt geeft te denken.

zucht oh zucht oh zucht.... kereltje toch... wortd het weer te abstract voor je?

1) SAN v NAS is een nutteloze discussie. of je nu een NTFS powned met EFS, of dat je files een voor een encrypt. dat hoeft niet op de server te gebeuren, dat laatste, dat kan op een client zijn die de files een voor een encrypted via server je SAN in schiet, of direct dat NAS in. kortom, dwars door je 'afgeschermde netwerk van je SAN'.

2) of er nu een disk in een server zit via SATA/SAS of een LUN van een SAN die ontsloten wordt naar server, zodra server op SAN kan schrijven (en dat moet want anders was het geen nuttige server), dan kan via de NTFS EFS route een crypto attack insluipen. je server staat ALTIJD in verbinding met clients, want again, anders was het geen nuttige server weer.

3) afscherming is geen 100% silver bullet, het helpt in damage control, maar stukken kunnen aangevallen worden. SAN v NAS doet er daarbij niet veel toe. afscherming biedt alleen maar damage control, je moet nog steeds DETECTIE en ACTIE / RECOVERY daar boven op doen. damage control en afscherming, daamee koop je tijd en breng je vertraging in in de attacks at best, zodat je een DETECTIE kans hebt en een mogelijheid tot ACTIE voordat je gehele omgeving in een klap plat ist.

anyway, reageer maar weer met ruis en onzin, as usual.

over en uit.
26-01-2020, 09:11 door Anoniem
"Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden. "

nope, SCHRIJF rechten in de keten ergens. als een client geinfecteerd is, dan komt crypted data op je backup terrecht.

misschien wordt het nu duidelijk waarom de UM dat Carbon Black implementeerd op de clients?
27-01-2020, 16:24 door Anoniem
Door Anoniem: "Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden. "

nope, SCHRIJF rechten in de keten ergens. als een client geinfecteerd is, dan komt crypted data op je backup terrecht.

misschien wordt het nu duidelijk waarom de UM dat Carbon Black implementeerd op de clients?

Je spreekt het artikel tegen, wat is je bron? En wat heeft Carbon Black daarmee te maken?
27-01-2020, 18:11 door Anoniem
Door Anoniem:
Door Anoniem: "Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden. "

nope, SCHRIJF rechten in de keten ergens. als een client geinfecteerd is, dan komt crypted data op je backup terrecht.

misschien wordt het nu duidelijk waarom de UM dat Carbon Black implementeerd op de clients?

Je spreekt het artikel tegen, wat is je bron? En wat heeft Carbon Black daarmee te maken?

https://www.security.nl/posting/639539/Universiteit+Maastricht+voorziet+werkplekken+van+monitoringssoftware

https://www.observantonline.nl/Home/Artikelen/ArticleType/ArticleView/ArticleID/17882

https://www.carbonblack.com/products/enterprise-edr/
28-01-2020, 04:05 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: "Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden. "

nope, SCHRIJF rechten in de keten ergens. als een client geinfecteerd is, dan komt crypted data op je backup terrecht.

misschien wordt het nu duidelijk waarom de UM dat Carbon Black implementeerd op de clients?

Je spreekt het artikel tegen, wat is je bron? En wat heeft Carbon Black daarmee te maken?

https://www.security.nl/posting/639539/Universiteit+Maastricht+voorziet+werkplekken+van+monitoringssoftware

https://www.observantonline.nl/Home/Artikelen/ArticleType/ArticleView/ArticleID/17882

https://www.carbonblack.com/products/enterprise-edr/

Sorry, ik zie het verband niet. Misschien heb je niet begrepen waar ik het over heb, het gaat over rechten voor de malware om de backups te versleutelen zoals het was. Dat los je niet op aan de client kant. Als domeinbeheerder kun je al die beveiliging uitschakelen.
28-01-2020, 11:33 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: "Voor het versleutelen van allerlei (backup) bestanden heb je beheerrechten nodig. Dat zijn dezelfde beheerrechten als de beheerder gebruikt heeft om ongewild de ransomware infectie te verspreiden. "

nope, SCHRIJF rechten in de keten ergens. als een client geinfecteerd is, dan komt crypted data op je backup terrecht.

misschien wordt het nu duidelijk waarom de UM dat Carbon Black implementeerd op de clients?

Je spreekt het artikel tegen, wat is je bron? En wat heeft Carbon Black daarmee te maken?

https://www.security.nl/posting/639539/Universiteit+Maastricht+voorziet+werkplekken+van+monitoringssoftware

https://www.observantonline.nl/Home/Artikelen/ArticleType/ArticleView/ArticleID/17882

https://www.carbonblack.com/products/enterprise-edr/

Sorry, ik zie het verband niet. Misschien heb je niet begrepen waar ik het over heb, het gaat over rechten voor de malware om de backups te versleutelen zoals het was. Dat los je niet op aan de client kant. Als domeinbeheerder kun je al die beveiliging uitschakelen.

er is een (windows) client die data op een file server moet zetten en de data van die file server wordt gebackup-ed. als windows client nu cryptoware heeft, dan gaat data via server encrypted de backup in. je hoeft geen beheerder te zijn hiervoor, je hebt slechts schrijfrechten nodig.

carbon black is software die bij de UM nu de individual desktops monitord op inbraak.
29-01-2020, 14:43 door Anoniem
Leuk al die goedbedoelde adviezen, maar wat is er nu echt gebeurt en aan de hand?
Iedereen heeft blijkbaar een glazenbol en weet direct alle details om met een uitgebreid advies te komen :-)
Zonder extra informatie is iedereen aan het speculeren en gissen.

Motto: Gissen=Missen ;-)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.