Taggat med: överbelastningsattack

Stora driftstörningar och överbelastningsattacker

Idag har det varit stora driftstörningar på flertalet ställen runt om i världen. Dels har Facebook haft problem under några timmar med inloggningar på dess plattformar såsom Instagram, WhatsApp, Messenger och Facebook.com. Dels har även det genomförts överbelastningsattacker (DDoS) mot flertalet svenska sajter såsom regeringen.se, Konkurrensverket, IMY. Och bakom DDoS-attackerna så står en eller flera pro-ryska hackergrupper enligt chatt-kanaler på kommunikationstjänsten Telegram.

Från telegram så kan vi även se att mål för DDoS har även varit www.riksgalden.se och isp.se. Projektet går under namnet DDoSia Project, samt så används Go Stresser som en av mjukvarorna för att skicka paket. Skrämdump från telegram:

Skärmdump från Riksdagens hemsida så som den ser ut just nu:

Troligtvis ej relaterat men flertalet undervattenskablar har också troligtvis kapats i röda havet:

En av många memes som skapades igår:

https://twitter.com/akande_x/status/1765057679465001065

Uppdatering: Läs CERT-SE:s råd gällande DDoS.

Så hanterar Er organisation en cyberincident

Så hanterar Er organisation en cyberincident

Jag blir kontaktad då och då av organisationer som behöver hjälp att hantera cyberincidenter. Som tur var så lämnar de flesta incidenter någon form av spår som gör det möjligt att i efterhand spåra och dra slutsatser från incidenten. Men med goda förberedelser så kan Er organisation bli bättre på att hantera incidenter.

Den första frågan du bör ställa dig är: Har Er organisation redan rutiner på plats vid en cyberincident? Om inte så börja med att efterfråga en redan nu eller upprätta en rutin.

Betänk även att de flesta incidenter uppdagas genom att en extern part kontaktar Er och informerar om en incident som drabbar Er. Därför är det bra att ha kontaktuppgifter tillgängliga till säkerhetsavdelningen såsom E-post: [email protected] eller en webbsida som upplyser om vem man ska kontakta.

Glöm inte att löpande dokumentera allt som händer och vid vilka tidpunkter. Upprätta även en incidentrapport som ni uppdaterar hela tiden.

Koordinera och informera

Vem är det som bör informeras om incidenten. Finns det en säkerhetschef eller IT-säkerhetschef? Bör VD och styrelse snabbt informeras samt press-avdelning om externa frågor börjar att inkomma från allmänheten eller journalister.

Följande bild kommer från NIST SP 800-61r2 och beskriver hur kommunikation kan ske till och från ett Incident Response Team:

Isolera och begränsa

Att snabbt isolera och begränsa incidenten är också en viktig faktor, men betänk även att om det är ett pågående intrång så kan personen eller personerna i fråga ändra sitt beteende om de upptäcker att de blivit bortkopplade eller upptäckta.

Ett exempel på hur en server eller klient kan isoleras är att helt enkelt att fysiskt koppla bort den från nätverket och låta den fortsätta köra.

Säkra bevis

Att snabbt se till att säkra bevis efter incidenten är viktigt. För desto längre tid som går desto mer bevis kan gå förlorade. Det kan röra sig om ram-minne som försvinner om en server eller klient stängs av eller logg-filer som roteras och raderas efter en viss tid.

Titta vilka brandväggsloggar ni har, E-postloggar och AD-loggar samt andra relevanta loggfiler. Säkra upp dumpar av RAM-minne, hårddiskkopior och annat.

Det kanske är så att ni även måste kontakta en extern driftpartner eller organisation för att erhålla loggfiler.

Utreda omfattningen

Om det är ett intrång så är det viktigt att utreda exakt vilka system som drabbats av intrånget. Vid en överbelastningsattack så är det bra att veta vilka system som attackeras. Och när det gäller informationsläckage så måste ni veta exakt vilka uppgifter som ni blivit av med när, samt hur.

Vilka legala skyldigheter har organisationen och regelverk är det som måste följas såsom GDPR? Där det är 72 timmar som ni har på Er att informera Datainspektionen om personuppgiftsincidenter.

Rensa upp och återställ

Först och främst rekommenderar jag alltid att installera om och börja om från början. Men det är sällan så lätt i en komplex IT-miljö där det finns hundratals servrar och kanske tusentals användare och klienter.

Återställning handlar oftast om att rensa upp innehåll i databaser, se över användare och patcha eventuella system om sårbara produkter utnyttjas.

Lär av incidenten

Att dra relevanta slutsatser och förbättra på sitt cyberförsvar är något som Er organisation ska göra efter och under en incident. En incident är sällan en enskild isolerad händelse och har det inte hänt innan så kommer det troligtvis att inträffa en incident.

Hur kan ni upptäcka attacker tidigare och förbättra på rutinerna för att återställa verksamheten och minska påverkan i den operativa verksamheten.

Betänk även att en incident kan dra ut på flera dagar, veckor eller månader. Därför är det viktigt att ni har en eller flera som kan rotera huvudansvaret för incidenten vilket bidrar till bättre uthållighet. Därav också det viktiga med att dokumentera allt, så det blir lättare att lämna över och följa upp.

Utbildning

Jag skulle nästan påstå att organisationer som övar, informerar samt utbildar sin personal löpande i att hantera incidenter kommer att bli bättre på att hantera dessa den dagen de uppstår.

Att alla i organisationen känner till hur de ska hantera och identifiera incidenter är av stor vikt. Och om ni känner att det finns brister i dagsläget så tveka inte att ta in hjälp, det finns många företag som hjälper till med alla steg jag har listat i detta blogginlägg.

Har ni inte rutiner på plats i dagsläget så ta en titt på NIST Special Publication 800-61 revision 2 som tar upp mycket av det jag skriver om i detta blogginlägg.

Badlock var inte så farlig som många trodde

Nu har information släppts om den beryktade Badlock-buggen. Det visar sig att den inte är så farlig som många hade förväntat sig, dvs mer en uppbyggd hype eller PR-trick.

Sårbarheten är en så kallad MITM-bugg och gör att angriparen måste sätta sig mellan klienten och SMB-servern. Även så handlar Badlock om en överbelastningsattack, DoS.

Microsoft ger den nivå ”Important”, dvs näst högsta nivån och buggen får CVE-2016-0128 samt CVSS nivå 7.1.

Intressant denna tisdag är även att Microsoft släpper sitt månatliga patchpaket som innehåller critical-fixar för Edge och Internet Explorer.
hype train