Miljödata-attacken: vad hände – och hur bryter vi nästa attackkedja?

Security, dashboards

En omfattande cyberattack mot systemleverantören Miljödata påverkar kommuner och lärosäten. Inlägget förklarar varför den här typen av intrång blir systemiska, vilka kod- och integrationsbrister som ofta utnyttjas och vilka kontroller som faktiskt sänker risken. Du får en konkret blueprint: från SAST/SCA, SBOM och secrets-hantering till API-perimeter, private-by-default-nät, detektion, respons och verifierad återställning.

Miljödata-attacken: vad hände – och hur bryter vi nästa kedja?

Systemleverantören Miljödata har utsatts för en omfattande cyberattack som påverkar kommuner och regioner över hela landet. Flera redaktioner rapporterar om utpressningsangrepp (ransomware), risk för läckta känsliga personuppgifter och att en stor majoritet av kommunerna använder leverantörens system (bl.a. Adato). Ärendet hanteras av Nationellt cybersäkerhetscenter och lokala krisgrupper är aktiverade. SVT Nyheter, TV4, Aftonbladet

Konsekvenserna syns både lokalt och nationellt: kommuner och lärosäten bekräftar påverkan; flera talar uttryckligen om risk för läckta uppgifter och att omfattningen ännu inte är klar. SVT Nyheter, Örebro University, Sveriges Radio

Varför den här attacken svider extra

  • Koncentrationsrisk: När en central leverantör servar en stor del av kommunsektorn blir ett intrång systemiskt. Angriparen “multiplicerar” effekten genom att gå på en hubb. TV4

  • Dataens natur: HR/rehab/arbetsmiljödata kan innehålla läkarintyg, omdömen och skyddsvärd PII – alltså hög skadepotential vid läckage. DN, Örebro University

  • Återställningstid: Vid ransomware är tiden till återställning ofta längre än man tror; även om backuper finns tar validering och sanering tid. (Se myndighetsrapporter och tidigare svenska case.) SVT Nyheter

Vad gör intrång via “koden” så vanligt?

De flesta större incidenter börjar inte med “Hollywood-hacking”, utan med välkända brister:

  • Auktorisering på objektnivå (IDOR): användare kan läsa/ändra poster de inte äger.

  • Bristande inputvalidering/encoding → injektioner, XSS, SSRF.

  • Hemligheter i kod/repo: API-nycklar, SAS-tokens, funktionsnycklar i URLer.

  • Svaga webhooker: saknar signatur/tidsfönster/idempotens.

  • Teknisk skuld: outdaterade tredjepartsbibliotek med kända CVE:er.

  • Överexponerade PaaS-ytor: “Public access” på databaser/lagring utan skäl.

Lägg till prispress och leveransstress: när upphandlingar och budgetar prioriterar kort sikt pressas kvalitetskontroller, test och härdning. Resultatet blir “features i tid” men säkerhet i efterhand – vilket i praktiken är samma sak som förhöjd risk.

 

“Kan leverantören garantera att inget händer?”

Nej. Seriösa leverantörer lovar riskreduktion och snabb återställning, inte absolut säkerhet. Informationssäkerhet är gemensamt ansvar: produkt, drift, process, användning och kundens egna beslut (t.ex. konfiguration, behörigheter, val av risknivå och budget). Om målet är högre säkerhet krävs investering – i tid, pengar och disciplin.

 

Verktyg som faktiskt sänker risken (och vad de gör)

  • SAST/quality gates: SonarQube, GitHub CodeQL – stoppar kända kodmönster och sårbarheter i PR innan de landar i main.

  • SCA & uppdateringsrobotar: Dependabot, Renovate – bevakar tredjepartsberoenden och föreslår patchar.

  • SBOM: CycloneDX – gör det möjligt att veta exakt vilka komponenter som kör och var riskerna finns.

  • DAST: test av körande app (t.ex. i review-miljö) för att hitta läckor och fel i autentisering/autorisering.

  • Secrets management: Azure Key Vault + rotation + Managed Identity – inga hemligheter i kod.

  • API-kant: Azure API Management – JWT/mTLS, schema/signatur-validering, rate limiting, IP/geo.

  • Nät & perimeter: Private Endpoints, stängd “Public access”, WAF via Front Door/App Gateway, DDoS-skydd.

  • Detektion & respons: Defender for Cloud + Microsoft Sentinel – larm på anomalier, playbooks för respons.

Poängen är inte varumärket – utan att varje steg i kedjan har mätbara skyddsräcken.

Så hade man brutit attackkedjan – en praktisk blueprint

1) I koden & pipelines (shift-left)

  • SAST + quality gates på PR (blockera High/CriticalNew Code), secret-scan varje commit.

  • SCA & SBOM (CVE-skanning, SBOM i build), auto-PR för patch.

  • DAST på review-miljö, IaC-policy som blockerar osäkra resurser.

  • Signerad supply chain (t.ex. Sigstore/Cosign, SLSA-nivåer) och bygg-provenans.

  • Threat-model/checklistor: IDOR, inputvalidering, SSRF, filuppladdning, deserialisering, webhook-replay.

Snabbt att införa: “New Code”-strategi i SonarQube, tvågodkännande + security-checklista per PR, Dependabot/Renovate.

2) Identitet & hemligheter (identity-first)

  • Managed Identity för alla tjänster; Key Vault-referenser och rotation.

  • Zero standing privileges (PIM för admin, CA/MFA).
    KPI: 100 % MI; 0 odaterade SAS/nycklar.

3) API-kant & nätverk (private-by-default)

  • API Management framför alla externa endpoints: OAuth2/JWT, mTLS, schema/signatur, rate limiting, IP/geo.

  • Webhook-skydd: HMAC-signatur, tidsfönster, idempotensnycklar.

  • Private Endpoints + VNet-integration; stäng public access. WAF + DDoS via Front Door/AppGW.
    KPI: 100 % externa endpoints bakom APIM.

4) Data, multitenancy & återställning

  • Minimera PII i nyttolast/loggar, maskning i APIM/App Insights.

  • Rättighetsstyrning i DB, TDE och fältkryptering.

  • Immutabla backuper + restore-övningar (PITR), soft delete/versioning.
    KPI: Verifierad återläsning inom mål-RTO.

5) Observability, detektion & respons

  • Defender for Cloud + Sentinel-regler (t.ex. ovanliga returspikar, 429-stormar, misslyckade signaturer).

  • Runbooks/playbooks: isolera tjänst, rotera nycklar, blockera tokens.

  • Canary-tokens/honungsslutpunkter för tidig varning.
    KPI: MTTR på säkerhetslarm, patch-lead time, “time-to-rotate”.

Tredjepart, pris och realpolitik

  • Tredjepartsrisk ≠ dåliga leverantörer. Integration med HR/ERP/3PL, e-post eller filöverföring ökar attackytan. Kräv SBOM, pen-testrapporter, incidentprocess och export av loggar.

  • Race-to-the-bottom i upphandling pressar bort säkerhetsarbete: hot-modeller, DAST, hårdning, restore-övningar, incidentövningar. Det syns inte i en featurelista – men det märks på faktiska incidenter.

  • “Bygg snabbt” utan kontroller blir dyrt senare: outage-timer + juridik + varumärkesrisk.

  • Betala för kontroll: säkerhet är en ekonomi av sannolikheter, inte ett löfte om perfektion. Budgetera för kontinuerliga kontroller, inte engångsprojekt.

För kommunledning & CIO: vad ni kan göra den här attack-veckan

  1. Inventera exponering: vilka externa endpoints finns, vad ligger bakom APIM/WAF, vad är publikt?

  2. Slå på miniminivåer: tvinga JWT i API:er, stäng public access till PaaS, aktivera Defender-planer.

  3. New-code-gate: SAST/SCA som blockerar i PR på alla kritiska repo.

  4. Hemligheter: flytta secrets till Key Vault; rotera allt som inte redan roterats.

  5. Backuper: testa återställning – inte bara att backuperna “finns”.

  6. Öva: tabletop för ett Adato-liknande scenario; mät MTTR och justera playbooks.

Avslutning

Miljödata-attacken påminner om att kodkvalitet, integrationer och drift är samma kedja. Att bryta nästa attackkedja handlar om disciplin och investeringar: från commit till produktion och återställning. Det finns inga garantier – bara kontroller som sänker sannolikheten, detektion som förkortar skadan och övning som förkortar återställningen. Och ja: vill man höja säkerheten så kostar det – men kostnaden för att låta bli syns som driftstopp, dataläckor och förlorat förtroende.