hardware weggooien en media vernietigen

Duckduckgo, startpage of bing voor mijn part eens naar cyber disaster recovery plan.

Succes

Of dit precies is wat je zoekt, weet ik niet, maar via https://seclists.org/educause/2020/q4/202 vond ik vorige week een aantal links naar interessante openbare documenten waarin ook "recovery" aan de orde komt. In de bijdrage in die maillijst zijn die links "ingekapseld", hieronder vind je de links naar -vermoed ik- drie belangrijkste documenten (zie ook https://www.nccoe.nist.gov/projects/building-blocks/data-security voor aanvullende links).

Nb. in de uitgebreide "how to guides" in onderstaande PDF's wordt gebruik gemaakt van specifieke producten (die niet iedereen zal willen gebruiken), bijv. om snel weer up and running te zijn. Disclaimer: ik heb deze docs slechts even doorgebladerd, ik heb (nog) geen kwaliteitsoordeel (echter over het algemeen zijn NIST docs prima van kwaliteit).

Data Integrity: Recovering from Ransomware and Other Destructive Events
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-11.pdf

Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf

Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-26.pdf

Generiek advies voor "systemen die met malware zijn besmet" is lastig te geven. Zodra firmware kan zijn gewijzigd (zoals https://www.security.nl/posting/680362/Nieuwe+TrickBot-malware+in+staat+om+UEFI-firmware+te+manipuleren) is het advies van Anoniem 20:32 wellicht terecht. Mocht je gecompromitteerde systemen opnieuw inzetten, dan verdienen zij in elk geval bijzondere alertheid op anomalies tijdens het herinrichten en langdurig extra monitoring tijdens gebruik.

Als je vermoedt dat alle firmware onaangetast is, zou ik in elk geval het opslagmedium/media overschrijven met allemaal nul-bytes voordat je deze hergebruikt (dit om te voorkomen dat, mocht je ooit met "unerase" achtige software aan de gang gaan op zo'n medium en/of file-system cortuptie optreedt, diskblokken met malware-fragmenten weer "boven water" komen - de kans dat die kwaad doen is vermoedelijk niet zo groot, maar op alarm van een virusscanner voor zoiets zit niemand te wachten).

Aanvulling: op m'n todo-lijstje om een naar te kijken staat https://github.com/chipsec/chipsec:
Als iemand hier ervaring mee heeft, of met evt. alternatieven, lees ik dat graag!

Incident management

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=incident%20management


Gebruik op basis van jouw vraagstelling in de linkerkolom aangegeven [x] filters als volgt:


Small Business Guide: Response & Recovery

Step 1 Prepare for incidents
Step 2 Identify what's happening
Step 3 Resolve the incident
Step 4 Report the incident
Step 5 Learn from the incident


Op de website van de Nederlandse evenknie, de NCSC.nl , kun je ook veel Factsheets vinden.

Prettige feestdagen en een gelukkig nieuwjaar!

Vriendelijk dank voor de uitgebreide toelichting Erik. Waardevolle bijdrage!

Het is de moeite waard om eens te kijken bij https://www.informatiebeveiligingsdienst.nl of het NCSC.

Vroeger was er ook nog https://github.com/KPN-CISO/kpn-security-policy, maar zie daar even geen beleid meer staan.

Zo te lezen is de KPN policy verhuist naar https://ciso-ksp.kpnnet.org
Daar is het te vinden.

https://seclists.org/educause/2020/q4/202

Wat wordt hier bedoelt met:
Key issues found that contributed to “success” of threat actor and should be reviewed at your institutions:

· Dormant student user accounts (not disabled)

· Lack of tiered security model to protect core infrastructure

· Weakness in Domain Privileged Account Passwords

· Availability/use of obsolete encryption protocol (RC4)

· Unlimited access to virtual desktop environment

Het gaat hier om een maillijst van/voor het hoger- en universitair onderwijs in de USA, maar regelmatig zie ik daar informatie voorbijkomen die voor de meeste organisaties bruikbaar is. In dit geval ging het vooral om de informatie waar vanuit de betreffende mail naar verwezen wordt, die interessant zou kunnen zijn voor de TS. De items uit de mail die je gekopieerd hebt, hebben vooral betrekking op het voorkomen van compromittering van een heel netwerk.

Accounts die een geconfigureerde tijd niet meer gebruikt zijn. Als je weet dat bepaalde accounts helemaal niet meer, of gedurende wat langere tijd, niet zullen worden gebruikt, blokkeer deze dan. Nb. in Microsoft omgevingen raad ik het verwijderen van accounts (en groepen) af; vaak zijn er nog objecten (o.a. in archieven en back-ups) waarop permissies zitten - en die zijn gekoppeld aan een SID van een gebruiker of groep. Door een account te verwijderen, verdwijnt de koppeling tussen de naam (feitelijk een alias) en het account of groep; in plaats van namen zullen dan voortaan SID's worden getoond waardoor het een heel uitzoekwerk kan zijn om achteraf te bepalen wie of welke groep dat was. Veel beter kun je accounts, die (tijdelijk) niet worden gebruikt, disablen.

Onvoldoende segmentering.

Zwakke en/of hergebruikte (op meer dan 1 device) wachtwoorden van accounts met hogere privileges dan die van gewone gebruikers. Als je met een account (username + password), waarmee je op meerdere computers kunt inloggen, inlogt op één van die computers, en die computer is al eerder of wordt later gecompromitteerd, bestaat de kans dat de aanvaller daarmee alle computers waarop je met dat account kunt inloggen, compromitteert. Zorg dus dat beheeraccounts voor elke computer een uniek en niet te raden wachtwoord hebben (dus niet nimdaPC001, nimdaPC002 etc. als de PC's resp. PC001 en PC002 heten).

Voor het kraken van RC4 zijn zeer veel pogingen nodig, maar als je nauwelijks of niet monitort vallen aanvallen mogelijk niet op. Sta uitsluitend de laatste versie van SMB toe voor Microsoft en Samba file sharing (zie bijv. https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/the-rc4-removal-files-part-2-in-aes-we-trust/ba-p/1029439). Devices die dat niet ondersteunen, moet je upgraden - en als dat niet kan, naar een onveilig netwerksegment verplaatsen. En uitsluitend essentiële verbindingen ermee toestaan, en die strak monitoren.

Per virtuele desktop heb je minstens twee devices om je security-zorgen over te maken: (naast de server) de virtual desktop instance zelf en de client waar de gebruiker die instance mee benadert. Immers, als die client is gecompromiteerd (denk aan keyloggers - waarmee o.a. wachtwoorden kunnen worden afgekeken, het maken van screenshots en wellicht clipboard sharing en/of bestandsuitwisseling) kan de malware op die client hetzelfde als de gebruiker van die client. Als malware (of een live aanvaller) via die client, malware in de virtuele desktop weet te laden (bijv. via e-mail), en/of van boordmiddelen gebruik maakt, en de (op de virtuele desktop) ingelogde gebruiker schrijfrechten heeft op belangrijke bestanden, kan ransomware al een nachtmerrie worden. Dat virtuele desktops vaak over weinig geheugen beschikken, kan een reden zijn om daar geen antivirussoftware op te draaien - mede omdat deze toch nauwelijks werkt bij verse malware. Echter, zonder AV wordt er zeker niks gedetecteerd waardoor een aanvaller wellicht ook oudere PUP's als psexec en mimikatz ongestraft kan downloaden en draaien. Ook kan het lastig gevonden worden om alle software op de virtuele desktops up-to-date te houden, waardoor bekende privilege escalation kwetsbaarheden ongepatched kunnen zijn. Zelfs guest-to-host escapes kun je nooit voor 100% uitsluiten, en de gevolgen daarvan kunnen (vooral als je bij het ontwerp hier geen rekening mee hebt gehouden) dramatisch zijn.

HTH!