Dataintrång: vad du gör under de första 72 timmarna, och hur du förebygger det

Måndag morgon. Någon på supporten rapporterar att något konstigt pågår i systemet: anrop från okända adresser, konton som ingen känner igen, trafik klockan tre på natten. Inom några timmar står det klart att någon har åtkomst som den inte borde ha.

I det ögonblicket frågar ingen vem det var. Alla frågar samma sak: vad fick de se?

Klockan börjar ticka direkt

Om kunders eller användares personuppgifter berörs kräver GDPR att du anmäler incidenten till tillsynsmyndigheten, i Sverige Integritetsskyddsmyndigheten (IMY), utan onödigt dröjsmål och senast 72 timmar efter att du fick kännedom om den. Om risken för de berörda är hög måste du också informera dem.

För att kunna göra det behöver du svaret på tre frågor: vilka uppgifter angriparen kunde komma åt, vilka den faktiskt kom åt och om den fortfarande är inne. Om du inte vet är det enda ärliga att utgå från det värsta: att de såg allt. Och ”allt” betyder att du måste skriva till alla dina kunder.

Skillnaden mellan ”de såg tio poster” och ”vi var tvungna att informera varenda kund” avgörs inte på dagen för attacken. Den avgörs månader tidigare, i hur applikationen byggdes.

De hål angripare faktiskt använder

Attacker mot affärsapplikationer ser sällan ut som på film. Oftast krävs inget geni, bara en väg in genom en dörr som någon lämnat öppen:

• Lösenord sparade som vanlig text. Den som kommer åt databasen har alla lösenord. Och användarna återanvänder lösenorden till sin e-post och sin bank, så läckan slutar inte hos dig. Lösenord sparas aldrig, bara ett fingeravtryck av dem som lösenordet inte kan återskapas från.
• Applikationen skickar mer än skärmen visar. Skärmen visar ett namn och en e-postadress, men bakom den skickar applikationen hela posten, med fält som ingen ser om de inte letar. Angripare letar alltid.
• Någon annans data genom att ändra en siffra. Ändra ordernumret i adressen och du ser någon annans beställning. Det låter för enkelt för att vara sant, men bristande åtkomstkontroll ligger överst på OWASP:s lista över de vanligaste säkerhetsriskerna i webbapplikationer.
• Obegränsat antal försök. Utan en gräns kan en angripare prova lösenord eller nummer tusentals gånger i minuten tills något fungerar.
• Öppen självregistrering. Om vem som helst kan registrera sig behöver angriparen inte bryta sig in. Den skapar ett konto och tittar på allt en användare kan hämta inifrån.
• Adminsidor som nås från hela internet. Ett gränssnitt som fem personer i företaget behöver, och som vem som helst i världen kan komma åt.
• Loggar som inte visar något. Applikationen loggar fel, men inte vem som hämtade vad. På dagen för en incident är det skillnaden mellan ett svar och en gissning.

När det händer: ordningen

1. Stäng dörrenStäng av åtkomsten, byt nycklarna
2. Ta reda på vad de sågUr loggarna, inte genom gissningar
3. AnmälTill myndigheten och vid behov till de berörda
4. Åtgärda orsakernaSå att det inte händer igen

1. Stäng dörren. Stäng av åtkomst som inte borde finnas: inaktivera de misstänkta kontona, byt de lösenord, nycklar och tokens som angriparen kan ha sett. Snabbt, men utan att sudda ut spåren.
2. Ta reda på vad de såg. Använd loggarna för att rekonstruera vad angriparen gjorde, vilka uppgifter den kom åt och sedan när. Det här steget avgör allt annat.
3. Anmäl. Till myndigheten inom fristen, och till de berörda när risken är hög. Tydligt och ärligt: vad som hände, vilka uppgifter som berördes och vad du gör åt det.
4. Åtgärda orsakerna. Inte bara hålet de kom in genom, utan alla liknande hål. En angripare som hittade en öppen dörr har garanterat provat de andra.

10 frågor du kan ställa till ditt team i dag

Du behöver inte kunna programmera för att ställa dem. Du behöver bara insistera på ett tydligt svar:

1. Hur sparar vi användarnas lösenord? Rätt svar: som ett fingeravtryck (hash), aldrig som text.
2. Returnerar applikationen bara de uppgifter som skärmen faktiskt behöver?
3. Kontrollerar applikationen vid varje anrop att just den här användaren får se just den här posten?
4. Hur många inloggningsförsök tillåter vi innan kontot spärras?
5. Kan vem som helst registrera sig, och vad kan de se efter det?
6. Vem kan komma åt adminsidorna, och varifrån?
7. Loggar administratörerna in med tvåstegsverifiering?
8. Om någon tog sig in i morgon, skulle våra loggar visa vad de såg? Hur länge sparar vi loggar?
9. När uppdaterade vi senast bibliotek med kända sårbarheter?
10. Vem ansvarar om en incident inträffar klockan tre på natten, och vet den personen vad som ska göras?

Om du får ”vet inte” eller ”det borde vara okej” på fler än två av dem vet du var du ska börja.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien. Vi gör säkerhetsgranskningar av affärsapplikationer byggda på .NET, ASP.NET Core, Blazor och SQL Server. Vi går igenom koden, API:erna, inloggning och behörigheter, loggarna och konfigurationen, och du får en lista över hål rangordnade efter risk, med ett förslag på åtgärd för vart och ett.

Och när en incident redan har inträffat hjälper vi till med det mest brådskande: att stänga dörren, att med hjälp av loggarna ta reda på vad angriparen såg och att åtgärda orsakerna. Det första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• Dataskyddsförordningen (GDPR), artiklarna 33 och 34, EUR-Lex
• OWASP Top 10:2025, OWASP Foundation