Purdue-modellen

Purdue Enterprise Reference Architecture utvecklades vid Purdue University i början av 1990-talet, primärt av Theodore Williams och kollegor som arbetade med PERA-modellen för tillverkningsföretagsintegration. Dess ursprungliga syfte var inte säkerhet utan integration: den tillhandahöll ett ramverk för att förstå hur olika funktionella system i ett tillverkningsföretag relaterade till varandra och hur information borde flöda mellan dem. Modellen beskrev affärsfunktioner, inte nätverkstopologi, och adopterades av ISA-95-standarden för enterprise-styrsystemintegration som formaliserade nivåerna och deras funktionsdefinitioner.

Modellens adoption som säkerhetsarkitektur kom senare, när ICS-nätverk började kopplas till företags-IT-nätverk och behovet av organiserad segmentering blev tydligt. Säkerhetspraktiker fann Purdue-nivåerna som ett användbart vokabulär för att beskriva var enheter befann sig och var gränser borde tillämpas. IEC 62443, ICS-säkerhetsstandardfamiljen, använder begreppen zoner och kanaler som stämmer överens med Purdue-nivåtänkandet. NIST SP 800-82, vägledningen för industriella styrsystems säkerhet, refererar till modellen som ett ramverk för att förstå ICS-arkitektur.

Den här historien är viktig eftersom den förklarar varför Purdue-modellen har både styrkor och begränsningar som säkerhetsverktyg. Den designades för att beskriva hur ett integrerat tillverkningsföretag borde fungera, och det gör den bra. Den designades inte för att beskriva hur motståndare rör sig genom nätverk, hur fjärranslutning skapar exponering eller hur molnarkitekturer förändrar dataflödesmönster. Att tillämpa den effektivt kräver förståelse för vad den byggdes för att göra och var den behöver kompletteras med annat tänkande.

I verkliga industriella miljöer är de rena nivåseparationerna i Purdue-modellen ofta stökigare än diagrammet antyder. Nivå 0 och Nivå 1 är vanligtvis de mest tydligt definierade: fysiska sensorer och ställdon ansluter till PLC:er och RTU:er via dedikerade fältbussar eller diskret kabling, och dessa anslutningar är relativt enkla att kartlägga och skydda. Styrlogiken som körs i Nivå 1-enheter är den närmaste något som är en hård gräns i de flesta ICS-miljöer eftersom att ändra den kräver antingen fysisk åtkomst till enheten eller åtkomst via en programmeringsanslutning från Nivå 2.

Nivå 2 och Nivå 3 tenderar att suddas ut i praktiken. Ingenjörsarbetsstationer, SCADA-servrar och historiksystem körs ibland på delad infrastruktur eller kommunicerar över samma nätverkssegment. I mindre anläggningar kan en enda server utföra både övervakningsstyrningsfunktioner och platsoperationsfunktioner simultant. Dessa konsolideringar drivs ofta av kostnad och operativ bekvämlighet, men de komprimerar de gränser som modellen förutsätter existerar och som säkerhetsarkitekturer är beroende av.

IDMZ är där mest arkitektonisk disciplin krävs och där den oftast saknas. I miljöer som har implementerat en IDMZ innehåller den ofta långt fler system än avsett: patchhanteringsservrar, antivirusuppdateringsspeglar, fjärråtkomstinfrastruktur, leverantörsanslutningspunkter och datautbytestjänster har alla ackumulerats där över tid. En IDMZ som har blivit ett allmänt nätverkssegment ger mycket svagare isolering än en som bara innehåller det minimalt nödvändiga antalet system med explicit definierade dataflöden i båda riktningarna.

IDMZ är det arkitektoniska elementet som översätter Purdue-modellens konceptuella nivåseparation till en faktisk säkerhetsgräns. Den befinner sig mellan OT-nivåerna och enterprise-IT-nätverket och innehåller system som behöver utbyta data över den gränsen. En väldesignad IDMZ har en brandvägg mot OT-nätverket, en separat brandvägg mot enterprise-nätverket och system däremellan som är specialbyggda för datautbyte snarare än allmän datorkraft. Ingen anslutning bör passera direkt genom IDMZ från ena sidan till den andra: alla dataöverföringar bör terminera vid ett system inuti IDMZ och ha sin ursprungspunkt från det systemet mot den andra sidan.

Historikreplikeringsmönstret är det kanoniska exemplet på korrekt IDMZ-design. En Nivå 3-historiker samlar in processdata från OT-miljön. En separat replikeringstjänst inuti IDMZ hämtar data från Nivå 3-historikern och gör den tillgänglig för enterprise-rapporteringssystem. Enterprise-system frågar IDMZ-replikeringstjänsten, inte Nivå 3-historikern. OT-brandväggen tillåter bara replikeringsanslutningen från IDMZ till Nivå 3. Enterprise-brandväggen tillåter bara frågeanslutningar från enterprise-system till IDMZ. Ingen väg existerar från enterprise-nätverket till OT-miljön, och ingen väg existerar från OT-miljön till enterprise-nätverket.

Fjärråtkomst via IDMZ följer ett liknande mönster. Leverantörer och fjärroperatörer autentiserar sig till en jumpserver eller fjärråtkomstserver belägen inuti IDMZ. Från jumpservern kan de komma åt specifika OT-system via tillåtna anslutningar med sessionsloggning. Jumpservern är den enda kontrollpunkten: den tillämpar vem som kan ansluta, vad de kan komma åt och tillhandahåller en komplett post över all aktivitet. Ingen VPN eller direkt tunnel bör kringgå denna arkitektur genom att dirigera fjärranslutningar direkt till OT-nätverkssegment.

Purdue-modellen utvecklades innan molndatorkraft, allestedsnärvaro av internetuppkoppling och mjukvara-som-tjänst-plattformar existerade. Moderna industriella miljöer inkluderar i allt högre grad molnanslutna sensorer som skickar data direkt till molnplattformar, leverantörshanterade enheter som kontaktar supportportaler, fjärrövervaknings-tjänster som ansluter från internet och SCADA-som-tjänst-lösningar där övervakningssystem körs utanför anläggningsnätverket helt. Inget av detta passar in i den traditionella nivåhierarkin, och allt skapar uppkopplingsvägar som Purdue-modellen inte tar hänsyn till.

IT/OT-konvergens skapar ytterligare press på modellen. Organisationer som vill minska kostnader och förbättra operativ synlighet kör i allt högre grad OT-system på delad IT-infrastruktur, använder enterprise-identitetssystem för att hantera OT-åtkomst och dirigerar OT-data via enterprise-nätverksvägar. Dessa konvergenser motiveras ofta av operativa och finansiella fördelar, men de kollapsar de nivågränser som modellen förlitar sig på och kan skapa exponering som varken IT-teamet eller OT-teamet fullt ut äger eller förstår.

Det lämpliga svaret är inte att överge Purdue-modellen utan att behandla den som en startpunkt snarare än en komplett lösning. Moderna ICS-säkerhetsramverk, inklusive IEC 62443 och vägledningen i NIST SP 800-82 revision 3, erkänner att den traditionella modellen måste utökas med zon- och kanalanalys som tar hänsyn till icke-traditionell uppkoppling. Den underliggande principen, att olika nivåer av kritikalitet och risk bör separeras av kontrollerade gränser, förblir giltig oavsett om de specifika nivådefinitionerna mappar rent till den faktiska miljön.

Det praktiska värdet av Purdue-modellen i säkerhetsarbete är som ett strukturerat sätt att fråga var saker är, vad de kommunicerar med och om dessa kommunikationsvägar är lämpliga. En säkerhetsgranskning som kartlägger en OT-miljö mot Purdue-nivåer identifierar snabbt avvikelser: enheter på Nivå 2 som kommunicerar direkt med Nivå 4 utan att passera en IDMZ, fjärråtkomstanslutningar som terminerar inuti Nivå 1 snarare än i IDMZ, historiker som accepterar anslutningar från enterprise-system snarare än att skicka data uppåt via en kontrollerad väg.

Varje avvikelse från den avsedda arkitekturen är ett potentiellt fynd, men inte varje avvikelse är lika betydande. En Nivå 3-historiker med en ytterligare anslutning till ett enterprise-rapporteringssystem kan representera ett mindre policyundantag. En direkt anslutning från ett företagslaptop-nätverk till ett Nivå 1 PLC-subnät är ett kritiskt arkitektoniskt gap. Att prioritera fynd kräver förståelse för vilka avvikelser som skapar vägar som en angripare kan utnyttja för att förflytta sig från en miljö med lägre behörighet till ett styrnätverk med hög konsekvens.

Modellen tillhandahåller också ett vokabulär för att kommunicera arkitektoniska beslut till intressenter som inte är nätverksingenjörer. Att förklara för driftschefer och ledning att målet är att säkerställa att affärssystem inte kan nå styrsystem direkt, och att all datautbyte passerar en övervakad gräns, är enklare med en referensmodell med intuitiva nivåetiketter än med råa nätverkstopologidiagram. Purdue-modellens bestående värde ligger delvis i dess tydlighet som kommunikationsverktyg, vilket är varför den består även när de underliggande nätverksarkitekturerna har utvecklats avsevärt bortom vad modellen ursprungligen beskrev.