Purdue-modellen i OT-sikkerhet: hvorfor den ikke lenger er nok alene

Purdue-modellen har vært ryggraden i industriell nettverkssikkerhet i over 30 år. Men dagens trussellandskap, skyintegrasjon og krav til sanntidssynlighet har gjort den utilstrekkelig alene. Her er hva som har endret seg, og hva moderne OT-sikkerhet faktisk krever.

Hva er Purdue-modellen?

Purdue-modellen (også kjent som Purdue Enterprise Reference Architecture, PERA) ble utviklet på tidlig 1990-tall og er i dag innebygd i internasjonale standarder som ISA/IEC 62443. Den deler OT-miljøet inn i fem hierarkiske nivåer:

• Nivå 0 – fysiske prosesser (pumper, ventiler, motorer)
• Nivå 1 – instrumentering og lokale kontrollere (PLC, RTU)
• Nivå 2 – prosesskontroll (SCADA, HMI)
• Nivå 3 – driftsadministrasjon (site operations, historiske data)
• Nivå 4 – bedriftsnettverket (ERP, forretningssystemer)

Mellom nivå 3 og 4 ligger en DMZ; en demilitarisert sone som skal hindre direkte kommunikasjon mellom OT og IT. Logikken var elegant: hold de industrielle systemene isolert, segmenter med firewalls, og anta at det som befinner seg innenfor grensene er trygt.

I 1992 var det en god modell.

Er Purdue-modellen fortsatt relevant?

Ja, som fundament. Nei, som komplett sikkerhetsarkitektur.

Soneinndelingen er fortsatt fornuftig, og prinsippet om å separere felt, kontroll og enterprise-nett gir mening. Men tre fundamentale skift har gjort Purdue-modellens forutsetninger utilstrekkelige alene.

Slik ser virkeligheten ut i OT-miljøer i dag

Spør en OT-ansvarlig i en norsk industri- eller energivirksomhet hvordan nettverket faktisk ser ut, og du vil sjelden få et svar som samsvarer med den rene Purdue-modellen. Det typiske bildet er noe slikt:

• Historian-serveren (systemet som logger produksjonsdata) sender produksjonsdata direkte til Azure eller en skybasert analyseplattform
• En eller flere leverandører har fjernaksess for vedlikehold og feilsøking
• Vedlikeholds-PCer kobles inn ved behov – gjerne med USB og uten konsekvent patchnivå
• IT og OT deler enkelte felles tjenester som Active Directory eller DNS
• Drift ønsker sanntidsdata til dashboards og beslutningsstøtte

Dette er ikke slurvete sikkerhetsarbeid. Det er den operative virkeligheten i 2025. Og det er en virkelighet Purdue-modellen ikke var designet for.

Tre skift som har endret forutsetningene

1. Air gap eksisterer ikke lenger i praksis

Den klassiske Purdue-tilnærmingen forutsatte fysisk isolasjon. I dag er dette en illusjon for de fleste virksomheter. Fjernoppkobling for leverandørvedlikehold, skybasert datainnsamling og IoT-sensorer med direktetilkobling har fjernet luftgapet i praksis.

2. Angriperne beveger seg mellom IT og OT

Dette er kanskje det viktigste skiftet. I flere av de store ransomware-angrepene mot industri de siste årene, inkludert Colonial Pipeline (2021) og angrep mot norsk og europeisk produksjonsindustri; har angriperne startet i IT-miljøet og deretter beveget seg inn i OT. De utnytter stol-på-alt-innenfor-grensen-logikken og gjemmer seg i legitim OT-trafikk over tid. Dette illustrerer hvorfor tradisjonell soneinndeling alene ikke lenger er tilstrekkelig, og hvorfor det er nødvendig med deteksjon som ser på tvers av domenene.

3. Sanntidssynlighet ble kritisk, og Purdue leverer ikke

Purdue-modellen ble designet for tilgjengelighet og stabilitet, ikke for deteksjon. Den sier ingenting om hvordan du oppdager at noen beveger seg lateralt mellom PLC-er, manipulerer prosessverdier eller eksfiltrerer data over tid. I en verden der digitalsikkerhetsloven stiller krav til hendelsesdeteksjon og rapportering, er en arkitektur uten innebygd overvåkningslogikk utilstrekkelig.

Hva moderne OT-sikkerhet faktisk krever

Svaret er ikke å kaste Purdue ut vinduet. Det er å bygge et moderne sikkerhetslag oppå det som fungerer.

Steg 1: Synlighet – du kan ikke beskytte det du ikke ser

Alt starter med å etablere et fullstendig aktivaregister over alle enheter i det industrielle nettverket. Passiv trafikkovervåkning gir innsikt i kommunikasjonsmønstre, protokollavvik og uautoriserte forbindelser, uten å påvirke driftsstabilitet.

Steg 2: Segmentering basert på faktisk trafikk

Soneinndeling bør speile virkeligheten, ikke tegnebordet. Hvilke systemer kommuniserer faktisk med hverandre? Hvilke forbindelser er nødvendige, og hvilke er det bare ingen som har stilt spørsmål ved?

Steg 3: Deteksjon inne i OT-sonen

Perimetersikkerhet stopper ikke angripere som allerede er inne. Moderne OT-sikkerhet krever deteksjon som ser på lateral bevegelse, avvikende kommunikasjonsmønstre og endringer i prosessverdier.

Steg 4: Integrert SOC for OT og IT

Den klassiske separasjonen mellom IT-sikkerhet og OT-sikkerhet er i ferd med å bryte ned av gode grunner. Angripere beveger seg fritt mellom domenene. Forsvarerne bør gjøre det samme. Et moderne SOC med OT-kompetanse korrelerer hendelser på tvers av IT og OT, reduserer responstid og gir et helhetlig trusselbilde.

Steg 5: Zero trust tilpasset OT-virkeligheten

Her er det viktig å være konkret: i OT handler zero trust sjelden om avansert identitetsstyring på 20 år gammelt feltutstyr. Det handler om å begrense hvilke systemer som kan kommunisere med hverandre, kontrollere og logge all fjernaksess, og redusere muligheten for lateral bevegelse dersom én enhet kompromitteres. Prinsippet er det samme som i IT – implementasjonen må tilpasses OT-virkeligheten.

Hva er forskjellen mellom Purdue-modellen og Zero Trust i OT?

Purdue definerer soner og barrierer mellom dem. Zero trust i OT handler om å ikke stole blindt på trafikk bare fordi den befinner seg innenfor en sone. De to er komplementære, og ikke konkurrerende.

Hvordan passer Purdue inn i IEC 62443?

IEC 62443 bygger på Purdue-modellens soneprinsipp, men utvider det med krav til sikkerhetsnivåer (Security Levels), risikostyring og leverandørkjede. Purdue gir strukturen; IEC 62443 gir kravene som fyller den.

Tre spørsmål å stille om ditt OT-miljø i dag

1. Har du oversikt over alle enheter i OT-nettverket – inkludert enheter som ikke var ment å være nettverkstilkoblet?
2. Vil du oppdage et angrep som beveger seg lateralt mellom PLC-er – eller vil du først merke det når prosessen stopper?
3. Håndteres OT-hendelser av samme SOC som IT – eller opererer de som separate siloer med ulik responstid og forskjellig trusselbilde?

Hvis svaret på ett eller flere av disse er «nei» eller «vet ikke», er det på tide å se nærmere på arkitekturen.

---

NetNordic hjelper virksomheter med å bygge moderne OT-sikkerhetsarkitektur; fra aktivakartlegging og sonedesign til SOC-integrasjon og kontinuerlig overvåkning.