Voordat ransomware uw backups op de proef stelt, voert u zelf drie controles uit: kan iemand de backups verwijderen, kan een gestolen adminaccount erbij, en hoe lang duurt een echte restore ten opzichte van wat de organisatie kan verdragen?
De NCSC-richtlijnen over het beperken van malware- en ransomware-aanvallen zijn ondubbelzinnig. Actuele backups zijn de meest effectieve manier om te herstellen van een ransomware-aanval, ransomware richt zich actief op backups om de kans op betaling te vergroten, en aanvallers hebben gekopieerde bestanden vernietigd of het herstel verstoord voordat ze de aanval lanceerden. Test uw backups dus zoals een aanvaller dat zou doen.
Test 1: probeer uw eigen backup te verwijderen
De voorbeelden hier gebruiken Amazon S3 Object Lock. Zoek bij andere producten de equivalente immutability- of retention lock in uw backupoplossing. Controleer of die aan staat, wat de retentieperiode is en wie die kan verkorten of opheffen. Probeer vervolgens een permanente delete uit te voeren als gewone gebruiker, als uw meest bevoegde backupbeheerder en als een account dat een aanvaller aannemelijk kan overnemen. Leg vast bij wie dit lukt.
Werk voor S3 in een scratch bucket. Object Lock werkt alleen in buckets waarvoor S3 Versioning is ingeschakeld, controleer dat dus eerst. Gebruik governance mode, die AWS beschrijft als een manier om retentie-instellingen te testen voordat u een retentieperiode in compliance mode aanmaakt.
Pas in de scratch bucket nooit compliance mode toe. In compliance mode kan de retentiemodus niet worden gewijzigd en de periode niet worden verkort, en de enige manier om een met compliance mode vergrendeld object eerder te verwijderen is het verwijderen van het bijbehorende AWS-account.
Voer deze pogingen uit via de console en via de API of CLI, en vergelijk de uitkomsten:
| Poging | Gedocumenteerd resultaat |
|---|---|
| Permanente delete (verzoek met een version ID), door een gebruiker zonder de bypass-permissie | Access Denied, 403 Forbidden |
| Simple delete (zonder version ID) | 200 OK, plus een delete marker bovenop |
Verwijderen via de console door een gebruiker met s3:BypassGovernanceRetention | Lukt |
De tweede rij is geen falen: de vergrendelde versie blijft bestaan, omdat retentieperioden het aanmaken van nieuwe versies of delete markers niet tegenhouden. De derde rij is de zorg. De S3-console neemt standaard de header x-amz-bypass-governance-retention:true mee, waardoor iedereen met die permissie met een paar klikken objecten kan wissen die met governance mode zijn vergrendeld.
Stuur daarna dezelfde permanente delete als die gebruiker via de API of CLI, zonder de header. AWS eist die header bij elk verzoek dat governance mode overschrijft, dus dit zou Access Denied moeten opleveren. Lukt het toch, controleer dan de retentiemodus van de bucket en de lock-instellingen van de objectversie.
Controleer daarna wie de lock ongedaan kan maken
Maak een lijst van alle principals waarvan de policies s3:BypassGovernanceRetention toestaan, inclusief rollen, groepen en inline policies. Doe hetzelfde voor s3:PutObjectLegalHold: een legal hold verloopt nooit, en elke gebruiker met die permissie kan holds vrijelijk plaatsen en opheffen.
Verwijder beide permissies bij accounts die een aanvaller aannemelijk kan overnemen. Overweeg voor data die u niet kwijt mag raken compliance mode met een bewust gekozen retentieperiode.
Test 2: probeer met de verkeerde inloggegevens bij de backup te komen
Immutable storage helpt niet als de aanvaller de console beheert waarmee die storage wordt aangestuurd. Probeer in te loggen op de backupconsole en de storage met een domain admin, een backup-operatoraccount en een cloud IAM-gebruiker, en controleer of elk van die accounts data kan verwijderen of retentie-instellingen kan wijzigen.
De NCSC-richtlijnen bevelen voor backupaccounts deze beschermingsmaatregelen aan:
- Privileged Access Workstations en hardware firewalls die IP allow listing afdwingen.
- MFA, waarbij de MFA-methode niet is geïnstalleerd op het apparaat waarmee de backups worden beheerd.
- Privileged Access Management, zodat beheerders niet rechtstreeks bij waardevolle backupsystemen komen.
Backupschijven en USB-sticks horen niet permanent met uw netwerk verbonden te zijn, en de backupproducten moeten worden gepatcht. Controleer bij een clouddienst dat eerdere versies beschermd zijn tegen directe verwijdering en dat u ernaar kunt terugzetten, want diensten synchroniseren vaak direct nadat uw bestanden zijn vervangen door versleutelde kopieën.
Test 3: herstel iets, met een stopwatch
Kies een systeem waar de organisatie binnen een dag last van zou hebben en herstel dat vanuit de backup naar een schone, geïsoleerde omgeving, zodat een mee teruggezette infectie de productiesystemen niet kan bereiken. Noteer de verstreken tijd, wie wat deed en elk moment waarop iemand moest zoeken naar een wachtwoord, een licentiesleutel of een document dat op de servers staat die u aan het herstellen bent.
Als de restore halverwege mislukt, noteer dan de stap, de verstreken tijd, de oorzaak en de oplossing, begin opnieuw vanaf die stap en log de resterende tijd apart. Houd de stappen tussen de runs identiek, zodat de resultaten vergelijkbaar blijven.
Sluit backups vóór het herstel alleen aan op bekende schone apparaten en scan ze op malware voordat u bestanden terugzet. Ransomware kan zich in backups hebben gerepliceerd voordat het werd ontdekt, dus een restorepunt dat er schoon uitziet, hoeft dat niet te zijn.
Vergelijk uw gemeten tijd met wat de organisatie zegt te kunnen verdragen. Vraag dat getal vóór de test aan de systeemeigenaar, zodat u de doelstelling niet naar het resultaat toe schrijft. Volledig herstel na ransomware kan, voor zover het al mogelijk is, enkele weken duren, dus beschouw de uitkomst voor één systeem als een ondergrens.
Werk op papier uit wat er gebeurt als zowel de systemen op locatie als de cloudbackupservers onbruikbaar zijn en u moet herbouwen vanaf offline backups, en hoe u kritieke bedrijfsdiensten draaiende zou houden. Controleer dat draaiboeken, checklists en contactgegevens ergens beschikbaar zijn waar u zonder uw computersystemen bij kunt. Onze dienst voor incidentrespons omvat dit soort oefeningen, als u een blik van buiten wilt.
Waar u kunt beginnen
- Kies één bedrijfskritisch systeem en vraag de eigenaar hoe lang het uit de lucht mag zijn. Schrijf dat getal eerst op.
- Maak een scratch S3 bucket met versioning en Object Lock in governance mode, nooit in compliance mode. Probeer een permanente delete en een simple delete en noteer de responses.
- Herhaal de permanente delete als gebruiker met
s3:BypassGovernanceRetention, vanuit de console en vanuit de API of CLI zonder de bypass-header. Maak daarna een lijst van alle houders van die permissie en vans3:PutObjectLegalHold, en verwijder ze bij wie ze niet nodig heeft. - Probeer in te loggen op de backupconsole met een domain admin, een backup-operator en een cloud IAM-gebruiker. Plan waar een login lukte MFA op een apart apparaat en IP allow listing. Controleer dat er een offline kopie bestaat, die niet permanent verbonden is en waarvan daadwerkelijk is hersteld.
- Herstel het gekozen systeem naar een geïsoleerde omgeving vanuit een gescande backup, meet elke stap en vergelijk het resultaat met het getal uit stap 1.
- Dicht de grootste kloof en herhaal de tests telkens wanneer het backupontwerp verandert.
