Cybersikkerhet i vern: 14 sårbarheter i ett vernrelé, og bare ett sted varselet finnes

Den 8. september 2026 publiserte Siemens ProductCERT advisory SSA-142885. Den gjelder vernserien Reyrolle 7SR5 — integrert vern, kontroll, måling og automatisering for transformatorstasjoner. Alle versjoner før V2.70 er berørt.

Advisoryen inneholder 14 CVE-er. Den høyeste scoren er CVSS v3.1 9.8 / CVSS v4.0 9.3.

Det er ikke et lite varsel. Og det er verdt å se nøye på hva som faktisk står i det, for det forteller noe om hvordan hele denne klassen av utstyr er bygget — og om hvor dårlig tilpasset både regelverket og våre egne rutiner er til å håndtere det.

Hva som faktisk står i advisoryen

Den alvorligste er CVE-2026-62645 (9.8 / 9.3): webgrensesnittet eksponerer informasjon som lar en angriper beregne sesjons-ID-en. Resultatet er autentiseringsomgåelse. To beslektede CVE-er forklarer hvorfor det er mulig: CVE-2026-62646 (utilstrekkelig entropi i sesjonsgenereringen) og CVE-2026-62647 (tilfeldighetsgeneratoren initialiseres ikke fra en ekte tilfeldighetskilde).

Det er ikke en implementasjonsglipp. Det er en enhet der sesjonshåndteringen aldri var bygget for å motstå noen.

Resten av listen er i samme sjanger:

I tillegg fem arvede sårbarheter fra Cesanta Mongoose Web Server v7.14 (CVE-2024-42384, -42385, -42386, -42391 og -42392) — altså en tredjeparts webserverkomponent som sitter inne i vernet, og som gir integer overflow, out-of-range pointer offset og uendelige løkker.

Legg merke til hvordan de fordeler seg, for det avgjør hvilke tiltak som faktisk hjelper. Autentiseringsomgåelsen og RBAC-omgåelsen virker over nett: de to henger sammen, og den ene forsterker den andre. De to som gir varig fotfeste — minnekorrupsjon i oppdateringsprotokollen og usignert kodekjøring i maintenance mode — krever derimot fysisk tilgang til enheten, og kan ikke kjedes på en nettverksbasert inngang.

Det skillet er verdt å holde skarpt. Nettverkssegmentering gjør noe med de to første og ingenting med de to siste. Der er det adgangskontroll til stasjonen som er kontrollen — og det er en helt annen avdeling i organisasjonen.

Rettingen er V2.70 eller nyere. Og her kommer den viktigste setningen i hele advisoryen: Siemens tilbyr ingen CVE-spesifikke workarounds. Det finnes ingen kompenserende kontroll per sårbarhet. Eneste produktspesifikke tiltak er å patche.

Det Siemens i stedet gir, er generelle anbefalinger: brannmur, segmentering, VPN — og, spesifikt for kraftsystem, at operatører bør verifisere at det finnes «appropriate resilient protection measures» og «multi-level redundant secondary protection schemes» som begrenser konsekvensen av en cyberhendelse.

Les den siste en gang til. Siemens’ eget kompenserende tiltak mot en cybersårbarhet i et vern, er reservevern. Det er en ærlig anbefaling, og den sier alt om hvor vi er.

Varselet finnes ett sted

Her er detaljen som burde bekymre mest, og som ingen skriver om.

CISA publiserte ingen tilsvarende ICS-advisory for 7SR5. CISA publiserer fortsatt nye Siemens-varsler, så det er ikke et generelt fravær — men siden 10. januar 2023 har de sluttet å oppdatere Siemens-advisories utover den første publiseringen, og henviser til Siemens ProductCERT for det løpende bildet.

Konsekvensen er den samme uansett årsak: varselet om 14 sårbarheter i et vernrelé ligger i praksis på leverandørens egen portal, og du må selv ha bestemt deg for å se etter det.

Det finnes riktignok en sektorkanal. NVEs veiledning til § 7-7 peker eksplisitt på at virksomheten bør følge sårbarhetsvarsler fra KraftCERT og fra egne leverandører, og at IKT-sikkerhetskoordinator bør abonnere på dem. Men det er en kanal du må koble deg på. Den finner ikke deg.

Så spørsmålet blir ubehagelig raskt: hvem i din organisasjon abonnerer på Siemens ProductCERT? Og på Schneider, ABB, Hitachi Energy, GE Vernova, SEL og de andre? Hvis svaret er «IT-sikkerhet», er neste spørsmål om de vet hva en 7SR5 gjør i anlegget — for det trengs for å vurdere hva varselet betyr.

CRA endrer ikke dette med det første. Rapporteringsplikten i forordning (EU) 2024/2847 fikk anvendelse 11. september 2026, men den gjelder aktivt utnyttede sårbarheter og alvorlige hendelser, og produsenten varsler koordinerende CSIRT og ENISA gjennom ENISAs felles rapporteringsplattform — ikke deg. SSA-142885 er proaktiv leverandørvarsling, ikke CRA-pliktig rapportering. Og Nkom presiserer at CRA per 11. september 2026 ikke er innlemmet i EØS-avtalen: norske myndigheter har ikke CRA-kompetanse, og norske produsenter må rapportere til et CSIRT i et EU-land. De fulle kravene kommer først 11. desember 2027.

Hvorfor et vern ikke kan sikres som en IT-enhet

Hele IT-sikkerhetsfaget er bygget rundt konfidensialitet først, integritet deretter, tilgjengelighet sist. I et vern er rekkefølgen omvendt — og det er ikke en preferanse, det er fysikk.

Tilgjengeligheten er sikkerhetsfunksjonen. Et vern som ikke svarer, verner ikke. Konsekvensen av CVE-2026-62648 er ikke at noen leser noe de ikke skulle. Konsekvensen er sekundene der selektivitetsplanen har et hull, og feilen eskalerer ett trinn høyere enn den var dimensjonert for.

Det blir tydeligst i IEC 61850. Stasjonsbussen bruker MMS over TCP/IP på port 102 til innstillinger og styring — den kan sikres med TLS etter IEC 62351-3 og -4. Men vernsignalene mellom IED-er går som GOOSE: multicast publisher/subscriber direkte på Ethernet lag 2, EtherType 0x88B8. Ingen IP. Ingen TCP. Dermed ingen TLS, ingen IPsec, og ingen brannmurkontroll av den typen du bruker på en 104-forbindelse. (Unntaket er R-GOOSE etter IEC 61850-90-5, som rutes over UDP/IP og dermed lar seg sikre på vanlig vis — men det er ikke det som går på stasjonsbussen i de fleste anlegg i dag.)

GOOSE i grunnutgaven har verken kryptering, autentisering eller integritetsvern. Angrepsvektorene er velkjente: spoofing, der en forfalsket melding med høyere stNum vinner over den ekte, og replay av tidligere fanget trafikk.

IEC 62351-6 finnes for å lukke autentisitet og integritet på GOOSE og Sampled Values — altså spoofing og replay. Konfidensialitet er ikke hovedpoenget der, og har lenge ikke vært levert i det hele tatt.

Grunnen til at den går tregt i felt er likevel verdt å si høyt: for de strengeste ytelsesklassene i IEC 61850-5 er ende-til-ende-budsjettet for utløsningskommandoer under 3 millisekunder (de mildere klassene tillater 10 ms), og kryptografisk validering koster tid innenfor nettopp det budsjettet. Sikkerhetsmekanismen er underordnet en tidsfrist satt av vernets krav til utkoblingstid, ikke av IT-sikkerhet.

Det er den grunnleggende forskjellen. I IT kan du alltid bruke litt mer tid på å være sikker. I vern kan du ikke.

Dette har skjedd før, og det var samme produsent

Dersom noen avfeier dette som teoretisk, finnes det et presedenstilfelle som er ubehagelig presist.

Industroyer, brukt mot strømnettet i Kyiv 17. desember 2016, hadde moduler for IEC 60870-5-101, IEC 60870-5-104, IEC 61850 og OPC DA. 61850-modulen koblet seg opp med MMS mot port 102, skannet selv nettverket etter IED-er, og lette etter logiske noder for bryterkontroll — CSW, Pos, stVal, Oper, SBO. 104-modulen sendte select-and-execute i løkke for å vippe brytere av og på.

Men den mest relevante delen for denne artikkelen er en egen modul rettet mot Siemens SIPROTEC vernrelé. Den utnyttet CVE-2015-5374 i EN100 Ethernet-modulen ved å sende en 18 bytes UDP-pakke til port 50000. Effekten, i ESETs formulering: enheten slutter å svare på kommandoer inntil den startes manuelt på nytt.

Dragos’ vurdering av hvorfor dette var med i verktøykassen er den setningen jeg vil at du skal ta med deg: å hemme vernplanen ved å sette vernrelé ut av spill kan utvide øydriften, og gjort i skala kan det utløse en større hendelse. Vernet var ikke målet i seg selv — det var det som skulle hindre at bryterhandlingene fikk lov til å bre seg.

Dragos legger til et nøkternt forbehold som er verdt å ta med: SIPROTEC ble sannsynligvis valgt rett og slett fordi det var den leverandøren som stod i anlegget i Kyiv. Dette er ikke en historie om Siemens. Det er en historie om at vern er et mål.

Industroyer2, 8. april 2022, var enklere — kun IEC-104, med åtte hardkodede IP-adresser og planlagt kjøring 16:10 UTC, sammen med wiperne CaddyWiper, ORCSHRED, SOLOSHRED og AWFULSHRED. ESET beskriver eksplisitt vernrelé i transformatorstasjoner blant målene, men har selv tatt forbehold om at analysen ikke fastslo nøyaktig hva som ble gjort mot hver enkelt enhet. Det forbeholdet bør stå.

Poenget er uansett etablert: en CVE i kommunikasjonsmodulen til et Siemens vernrelé har allerede vært våpengjort mot et kraftnett. Angrepsflaten er ikke den samme — CVE-2015-5374 satt i EN100-modulens Ethernet-implementasjon, mens 2026-settet sitter i en innebygd webserver — men mønsteret er: en nettverksstack i vernet som ikke tåler trafikk den ikke forventet. Og der 2015-sårbarheten ga tjenestenekt, gir 2026-settet autentiseringsomgåelse og rettighetseskalering over nett, pluss usignert kodekjøring for den som kommer fysisk til enheten.

Hva norsk regelverk faktisk krever

Her er en utbredt misforståelse verdt å rydde i: mange tror kraftberedskapsforskriften bare gjelder driftssentralen.

Det stemmer ikke.

Kraftberedskapsforskriften (FOR-2012-12-07-1157) har kapittel 7 om beskyttelse av driftskontrollsystem. § 7-16 Vern av kraftsystem i regional- og transmisjonsnett gjelder vernsystemene direkte, og NVEs egen veiledning sier det som avgjør spørsmålet: bestemmelsene i kapittel 7 gjelder for vernsystemene, med utgangspunkt i driftskontrollsystemets eller lokalkontrollsystemets klasse.

Lokalkontrollsystem er stasjonskontrollanlegget. Det er nettopp der en Reyrolle 7SR5 sitter. Hele kapittel 7 slår altså inn på vernet ditt, med sikkerhetsnivå bestemt av klassifiseringen.

Og fjerninnstilling av vern er ikke noe man må tolke seg fram til — det står i forskriftsteksten. § 7-10 om ekstern tilkobling krever at virksomheten har kontrollordninger for å godkjenne, vedlikeholde og avvikle ordninger for ekstern tilkobling «og for funksjoner for innstilling av vern».

Regelverkskjeden for akkurat denne saken blir dermed konkret:

• § 7-7 Håndtering av feil, sårbarheter og sikkerhetsbrudd. Du skal fange opp varselet. NVEs veiledning peker eksplisitt på at virksomheten bør følge varsler fra KraftCERT og fra leverandører.
• § 7-5 Kontroll ved endringer. Oppdateringen til V2.70 er en endring: den skal vurderes, testes og godkjennes. «Bare patch, da» er ikke et alternativ regelverket åpner for.
• § 7-4 Kontroll med brukertilgang. Du skal kunne kontrollere at kun rettmessige brukere har tilgang, og hvem som er eller har vært pålogget. Ordningene skal gjennomgås minimum årlig.
• § 7-10 Ekstern tilkobling. Ekstern tilgang skal normalt være stengt og kun åpnes ved behov.

Og nå den ubehagelige koblingen mellom § 7-4 og CVE-2026-62645: kravet om at kun rettmessige brukere har tilgang, og at du skal kunne kontrollere hvem som har vært pålogget, kan ikke innfris på en upatchet 7SR5. Sesjons-ID-en kan beregnes. Rutinene dine kan være aldri så gode; enheten kan ikke levere det forskriften krever.

Det er også verdt å merke seg hva som ikke står der: forskriften angir ingen frist. Ingen paragraf sier «kritiske sårbarheter skal lukkes innen X døgn». Kravet er at du har kontrollordninger — ikke at du er rask.

Til slutt regelverkslagene rundt: digitalsikkerhetsloven trådte i kraft 1. oktober 2025 og gjennomfører NIS1, ikke NIS2. NVE ble 30. september 2025 utpekt som tilsynsmyndighet og responsmiljø for energisektoren. NIS2 er per september 2026 fortsatt ikke innlemmet i EØS-avtalen — samtidig som EU-kommisjonen i januar 2026 la fram en pakke som allerede reviderer NIS2. For KBO-enheter er kraftberedskapsforskriften fortsatt det operative regelverket.

Standardene, og hva de faktisk gir deg

IEC 62443 er rammeverket, og det finnes i norsk utgave for flere deler — blant annet NEK IEC 62443-4-1:2018 (sikker produktutvikling), NEK EN IEC 62443-4-2:2019 (tekniske krav til komponenter) og NEK EN IEC 62443-2-4:2024 (krav til tjenesteleverandører). NEK 820 dekker samme område.

Det nyttigste begrepet fra 62443 i denne sammenhengen er skillet mellom SL-T (target — nivået du har bestemt at sonen skal ha), SL-C (capability — det komponenten faktisk kan levere) og SL-A (achieved — det du faktisk oppnår).

Sett Reyrolle-saken inn i det: uansett hvilken SL-T du har satt for stasjonssonen, har en 7SR5 under V2.70 en SL-C som ikke kan bære den. Du kan ikke prosjektere deg opp fra en komponent som ikke kan holde tett. Det er et innkjøps- og kravspesifikasjonsproblem, ikke et driftsproblem — og det avgjøres i prosjekteringsfasen, av folk som ofte ikke vet at de avgjør det.

IEC 62443-3-2 gir deg soner og kanaler — metoden for å bestemme hvor grensene skal gå og hva som får krysse dem. IEC TR 62443-2-3 — en teknisk rapport, ikke en kravstandard — dekker patch management i IACS-miljø, som er nøyaktig den prosessen § 7-5 krever at du har.

IEC 62351 er protokollsikkerheten: -3 (TLS for 104 og MMS-transport), -4 (MMS-laget), -6 (GOOSE og Sampled Values), -8 (rollebasert tilgangskontroll), -9 (nøkkel- og sertifikatforvaltning) og -14 (sikkerhetslogging). Merk at 62351-8 er det direkte motstykket til CVE-2026-62650 — RBAC-omgåelsen. Standarden finnes. Den var bare ikke implementert godt nok i produktet.

Hva du gjør nå

Hvis du eier eller drifter anlegg:

1. Finn ut om du har Reyrolle 7SR5, og hvilken versjon. Hvis du ikke kan svare på det i dag, er det funnet — ikke sårbarheten.
2. Vurder, test og godkjenn oppgradering til V2.70 etter § 7-5. Planlegg revisjonsvinduet nå, ikke når det passer.
3. I mellomtiden: steng webgrensesnittet mot alt som ikke må nå det. Ekstern tilgang normalt stengt, jf. § 7-10.
4. Abonner på leverandørenes ProductCERT-varsler, og plasser ansvaret hos noen som forstår hva utstyret gjør i anlegget.
5. Gå gjennom Siemens’ egen anbefaling om redundant sekundærvern. Har du reservevern som faktisk er uavhengig av den enheten som er sårbar?

Hvis du prosjekterer:

1. Sett SL-krav i kravspesifikasjonen, ikke i et vedlegg ingen leser. Krev dokumentert SL-C mot NEK EN IEC 62443-4-2.
2. Krev navngitt kontaktpunkt for sårbarhetshåndtering, dokumentert støtteperiode og varslingsplikt mot deg som kunde — i kontrakten.
3. Krev SBOM. De fem Mongoose-sårbarhetene i denne advisoryen er hele argumentet: uten stykklisten vet du ikke hvilke tredjepartskomponenter som sitter inne i vernet.
4. Ta med fastvareversjoner i as-built-dokumentasjonen.

Det siste punktet er der jeg vil at denne artikkelen skal ende, fordi det er det som treffer vår egen praksis.

Vi dokumenterer kortslutningsstrømmer til tredje desimal. Vi dokumenterer selektivitet, spenningsfall, kabeltverrsnitt og vernkarakteristikker. Og så leverer vi et anlegg der ingen noe sted har skrevet ned hvilken programvareversjon som kjører på vernet.

For anleggene du har prosjektert de siste fem årene — finnes den listen?

For de aller fleste av oss er svaret nei. Det er ikke en cybersikkerhetsmangel. Det er en dokumentasjonsmangel, og den er vår.

Kilder

• Siemens ProductCERT SSA-142885
• NVE: Veileder til kraftberedskapsforskriften
• ESET: Industroyer — biggest threat to ICS since Stuxnet
• ESET: Industroyer2
• Dragos: CRASHOVERRIDE whitepaper
• Nkom om CRA-rapportering (11.09.2026)
• IEC: 62443-serien
• IEC: 62351-serien