IEC 62443-1-x: ordene alle krangler om

To personer sto ved siden av et 33 kV-koblingsanlegg på et 220 MW solkraftverk i fjor høst, begge med samme revisjonssjekkliste, begge flytende i samme standard, og begge fullstendig forbi hverandre. Sertifiseringsorganets hovedrevisor sa at inverter-SCADA-en «trengte SL 3». Integratorens prosjektleder svarte, rolig, «vi er allerede SL 3 — komponentene er sertifisert». Anleggets OT-ingeniør, som måtte leve med det de ble enige om, stilte det eneste spørsmålet som betydde noe: «SL 3 av hva? Mål, oppnådd eller kapabilitet? For hvilken sone?»

Det er den samtalen IEC TS 62443-1-1:2009 ble skrevet for å forhindre. Den klarer som regel ikke å forhindre den — ikke fordi standarden er dårlig, men fordi nesten ingen på et reelt anlegg faktisk har lest den. De har lest et leverandørwhitepaper som siterte den, en NIS2-kartleggingstabell som omskrev den, eller en lysarkpresentasjon som blandet den sammen med IEC 62443-3-3. Vokabularet driver da, revisjonen knirker, og anleggseieren betaler for misforståelsen.

Denne teksten er en sakte, deliberat gjennomgang av Del 1-dokumentene i ISA/IEC 62443 -serien — fundamentgruppen. Dette er dokumentene som definerer hva alle andre deler av serien mener med IACS, sone, kanal, sikkerhetsnivå, grunnkrav, essensiell funksjon, anleggseier, integrator og så videre. Hvis du allerede har lest mine gjennomganger av IEC 62443-2-x , IEC 62443-3-2 og 3-3 eller IEC 62443-4-1 og 4-2 , er dette teksten som forklarer hvorfor de andre tekstene bruker så mye tid på å være forsiktige med ordvalg.

TL;DR

IEC 62443-1-x er fundament-gruppen i IEC 62443-serien. Den eneste dokumentet i denne gruppen som for tiden er publisert som et frittstående IEC-dokument på IEC Webstore er IEC TS 62443-1-1:2009 (en teknisk spesifikasjon, utgave 1.0, fra juli 2009) og nyere IEC TS 62443-1-5:2023 (teknisk spesifikasjon om sikkerhetsprofiler). Delene 1-2 (hovedordliste), 1-3 (samsvarsmålinger for systemsikkerhet) og 1-4 (IACS-sikkerhetslivssyklus og bruksområder) er fortsatt under utvikling av ISA99 / IEC TC65 WG10 — de er referert gjennom serien, men du kan ikke i dag kjøpe dem som ferdige dokumenter. Det faktum alene løser overraskende mange workshop-krangler. Alt nedenfor forklarer resten.

1. Seriekartet — hvor 1-x sitter, og hvilke andre deler som avhenger av det

IEC 62443-serien er organisert, formelt, i fire dokumentgrupper. ISA99-komiteen — som ko-publiserer med IEC TC65/WG10 — beskriver dem som:

Generelt (1-x): terminologien, referansemodellen, det konseptuelle stillaset. Det er her IEC 62443-1-1 lever.
Retningslinjer og prosedyrer (2-x): hva en anleggseier-organisasjon må gjøre for å drive et program. IEC 62443-2-1:2024 er det levende ankerpunktet her; 2-3, 2-4 og det kommende 2-2 (for tiden IEC PAS 62443-2-2:2025) utdyper det.
System (3-x): tekniske systemnivå-krav. IEC 62443-3-2 er risikovurderings-/soneinndelings-standarden, IEC 62443-3-3 er katalogen over systemkrav knyttet til de syv grunnkravene.
Komponent (4-x): sikker utviklingslivssyklus for produktleverandører (IEC 62443-4-1:2018) og komponentnivå tekniske krav (IEC 62443-4-2:2019).

En nyere femte gruppe, Profiler (6-x og den planlagte 5-x-familien), ble lagt til etter at IEC formelt utpekte serien som en horisontal standard i 2021 — som betyr at vertikalindustri-komiteer burde referere til 62443 i stedet for å skrive sine egne. Den horisontale utpekingen er grunnen til at IEC TS 62443-1-5:2023 finnes: den spesifiserer ordningen som sektor-spesifikke profiler skrives og aksepteres etter.

Hvert senere dokument i serien peker tilbake til IEC 62443-1-1 for definisjoner. Når IEC 62443-3-3 skriver «SR 1.1 Human user identification and authentication … shall be capable of … Security Level 2», er ordet «Security Level» ikke definert der. Det er definert i 1-1. Når IEC 62443-2-1:2024 snakker om en «anleggseier» og en «tjenesteleverandør», er disse rollene definert i 1-1. Når IEC 62443-4-2 vurderer en komponent til SL-C 2 for FR3, sporer betydningen av grunnkrav, kapabilitet, nivå og komponent alle tilbake til 1-1. Hele serien henger fra denne kroken.

Det har to praktiske konsekvenser. For det første — hvis du designer et program i dag, må du eie og lese IEC TS 62443-1-1:2009. Ikke sammendrag av den. Den faktiske PDF-en fra IEC Webstore, publikasjon 7029 . For det andre — du må akseptere at dokumentet er seksten år gammelt og at andre utgave fortsatt skrives. Noe av språket har beveget seg videre (serien snakker om «tjenesteleverandører» og «automasjonsløsninger» med mer presisjon nå), men definisjonene av soner, kanaler, SL-T/SL-A/SL-C og de syv FR-ene i 1-1 forblir de kanoniske inntil andre utgave kommer.

2. IACS, ICS, OT, ICS-cybersikkerhet — hva standarden faktisk sier

Dette er det første folk tar feil av, og det første IEC 62443-1-1 definerer.

IACS — Industrial Automation and Control System. Dette er 62443-fagtermen. IEC TS 62443-1-1:2009 definerer IACS bredt: en samling av personell, maskinvare, programvare og retningslinjer involvert i drift av en industriell prosess, og som kan påvirke eller influere dens trygge, sikre og pålitelige drift. Avgjørende — personell og retningslinjer er innenfor IACS-grensen. Det er ikke «nettverket». Det er ikke «kontrollerne». Det er det driftende sosio-tekniske systemet. IEC 62443-2-1:2024 forsterker dette — omfanget arver eksplisitt «den brede definisjonen og omfanget av hva som utgjør en IACS som beskrevet i IEC TS 62443-1-1».

ICS — Industrial Control System. Et snevrere begrep. Generelt brukt for å betegne kontrollteknologi-undersettet — PLS-er, DCS-er, SCADA, RTU-er, HMI-er, ingeniørarbeidsstasjonene og det industrielle nettverket som binder dem sammen. I den eldre IEC TR 62443-3-1:2009 var språket «ICS» fordi begrepet predaterer den IACS-sentrerte omformuleringen. I moderne 62443-dokumenter er det foretrukne paraplybegrepet IACS, med ICS som dukker opp som et nær-synonym i referanser til kontrollteknologi-laget.

OT — Operational Technology. Ikke et IEC 62443-begrep. OT er begrepet brukt av NIST SP 800-82 Rev. 3 (september 2023) , hvis tittel er «Guide to Operational Technology (OT) Security». NIST definerer OT som «programmerbare systemer og enheter som samhandler med det fysiske miljøet (eller styrer enheter som samhandler med det fysiske miljøet)». Revisjon 3 utvidet omfanget fra den eldre «ICS»-innrammingen av revisjon 1 og 2 fordi bygningsautomasjon, transport, fysisk adgangskontroll og miljøovervåking ikke passet behagelig under «industriell». OT er supersettet av ICS og det nærmeste eksterne begrepet til IACS, men OT inkluderer ikke personell og prosedyrer — det gjør IACS.

ICS-cybersikkerhet / OT-cybersikkerhet / IACS-sikkerhet. Brukt om hverandre i praksis. Internt i 62443 er de alle «IACS-cybersikkerhet».

Argumentet dette løser: i revisjonen jeg nevnte, var spørsmålet «er ingeniør-laptopen del av systemet?» omstridt. Integratoren argumenterte nei — det er IT, ikke en inverter. Anleggseieren argumenterte ja — den programmerer inverterne. Standarden er enig med anleggseieren. Under IEC 62443-1-1 er ingeniør-laptopen del av IACS-en fordi den påvirker trygg, sikker og pålitelig drift. Etiketten på dens aktiva-merke fritar den ikke.

I fornybar-energi-arbeid spesifikt betyr dette noe konstant. En solparks IACS inkluderer inverter-SCADA-en, meteorologi-stasjonens datavei, beskyttelsesreléene i 33 kV-koblingsanlegget, BESS batteristyringssystemet, nettverksutstyret i transformatorstasjonen, ingeniør-laptopene som O&M-teamet plugger inn månedlig og OEM-ens fjernsupport-VPN. Ingen av disse kan argumenteres ut av omfang på grunnlag av at de er «bare IT» eller «bare sikkerhet».

3. Referansemodellen (nivå 0-5) og hvordan den forholder seg til Purdue

IEC TS 62443-1-1:2009 legger ut en hierarkisk referansemodell brukt gjennom serien. Den er informert av Purdue Enterprise Reference Architecture (PERA) fra Purdue Universitys PLAIC-program, men er ikke identisk med den. 62443-referansemodellen definerer funksjonelle nivåer — abstrakte bånd — som beskriver hvor aktiviteter sitter i automasjonshierarkiet.

Nivåene, slik de brukes på tvers av serien:

Nivå 0 — Prosess. Det fysiske utstyret under kontroll: turbiner, transformatorer, invertere, ventiler, motorer, det faktiske utstyret som gjør arbeid.
Nivå 1 — Grunnkontroll. Sensorer, aktuatorer, kontrollere (PLS-er, IED-er, motorkontrollere, BMS-kontrollere). Sanntid, deterministisk.
Nivå 2 — Område- / overordnet kontroll. HMI-er, lokale SCADA-frontender, anleggshistorikkens innhentingslag. Operatørvendt, fortsatt sanntid-tilstøtende.
Nivå 3 — Sted- / driftkontroll. Anleggnivå-systemer: site-historian, MES-ekvivalenter, ingeniørarbeidsstasjoner, anlegg-omfattende SCADA. Fortsatt innenfor IACS.
Nivå 3.5 — DMZ. Den industrielle demilitariserte sonen. Meglet datautveksling mellom drift og virksomhetens enterprise. Ikke tilstede i den opprinnelige Purdue-modellen; lagt til i industriell cybersikkerhets-praksis og behandlet av 62443 som en sonegrense.
Nivå 4 — Forretningsplanlegging og logistikk på stedet. ERP, MES proper, forretningssystemer på stedsnivå.
Nivå 5 — Enterprise. Bedrifts-IT.

IEC 62443-1-1 er nøye på ett punkt som nesten alle tar feil av: nivåer er funksjonelle, ikke topologiske. To enheter på samme fysiske VLAN kan sitte på forskjellige referansemodell-nivåer. En PLS på nivå 1 kan være i samme rom som en historian på nivå 3. Referansemodellen forteller deg hva enheten gjør, ikke hvor Ethernet-kabelen ender.

Forholdet til Purdue er derfor «kompatibelt, ikke identisk». Purdue ga oss den hierarkiske metaforen. 62443 la til sikkerhetssone-resonnement på toppen — soner trenger ikke følge Purdue-nivåer, selv om de i de fleste velkonstruerte anlegg ender med å gjøre det av veldig gode grunner.

Hvorfor dette betyr noe for fornybar-energi-anlegg: et moderne solparksted passer sjelden inn i lærebok-Purdue-diagrammet. Inverter-produsenter sender skytilkoblet telemetri direkte ut av nivå 1-enheter. BESS-systemer kommer ofte med sin egen muromringede sky på «nivå 3-ish» uten noensinne å passere en anleggshistorian. Vindturbiner kobler seg gjennom OEM-fjernsupport-tunneler som bygger bro mellom nivå 1 og 5 og later som om de ikke gjør det. IEC 62443-1-1 lar deg beskrive disse arkitekturene ærlig — etter sone og kanal, med eksplisitte referansemodell-nivåer for hver funksjon — uten å tvinge inn et rent Purdue-bilde som aldri har matchet virkeligheten.

4. Soner og kanaler — og hva som teller som en sonegrense

Det enkelt mest konsekvensrike paret av definisjoner i IEC TS 62443-1-1:2009:

En sikkerhetssone er en gruppering av logiske eller fysiske aktiva som deler felles sikkerhetskrav.
En kanal er en logisk gruppering av kommunikasjonskanaler — som deler felles sikkerhetskrav — som forbinder to eller flere soner.

Tre ting følger som fanger folk.

For det første — soner grupperes etter sikkerhets-krav, ikke etter topologi eller funksjon alene. En sone er hvilket som helst sett med aktiva du kan forsvarlig argumentere trenger samme beskyttelse, samme tillit, samme overvåking, samme tilgangsregime. To fysisk separerte vindturbinarrayer på forskjellige spenninger kan være én sone hvis de deler sikkerhetskrav. Én enkelt transformatorstasjons-kontrollbygning kan inneholde tre soner (reléebeskyttelse, stasjons-SCADA, telekom-gateway) hvis de funksjonene berettiger forskjellige beskyttelsesnivåer. Tommelfingerregelen jeg bruker i revisjoner: hvis to aktiva noen gang ville berettige forskjellige kontroller på dette stedets risikoregister — er de ikke i samme sone.

For det andre — kanaler er ikke «brannmuren». En kanal er en logisk konstruksjon: settet med kommunikasjonskanaler med felles sikkerhetsbehov som krysser en sonegrense. Brannmuren, svitsjen, datadioden eller VPN-konsentratoren er en komponent av kanalen, ikke kanalen i seg selv. Det er derfor IEC 62443-3-3-krav gjelder kanaler så vel som soner: en kanal har SL-mål, kapabiliteter og et eget oppnådd nivå.

For det tredje — «tillitssone» er ikke det samme som «sikkerhetssone». En tillitssone (i IT zero-trust-forstand) er en grense der identitet og policy revurderes. En 62443-sikkerhetssone er en grense der sikkerhets-krav endres. De overlapper, men er ikke synonymer. Å si «vi har zero-trustet OT-nettverket, så vi trenger ikke soner» er en kategorifeil. 62443-sone-definisjonen gjelder fortsatt; zero trust er ett mulig middel for å håndheve kanalen mellom to soner.

En praktisk sonegrense-sjekkliste for et hybrid fornybart sted:

Hvor endres det cyber-fysiske risikoprofilet? (f.eks. å bevege seg fra inverterkontroll til batteritermisk styring til nettbeskyttelse)
Hvor endres populasjonen av brukere / leverandører / tjenesteleverandører?
Hvor varierer regulatoriske eller kontraktuelle forpliktelser (f.eks. nettkode-mandaterte systemer vs. eieroperasjonelle systemer)?
Hvor endres konsekvensen av kompromittering i art (inntekstap vs. sikkerhet vs. nettstabilitet)?

Hvert bekreftende svar er en kandidat-sonegrense. Hver er, ifølge IEC 62443-1-1, grunnlaget for en kanal.

Dette er inngangen som IEC 62443-3-2 forbruker når den ber om et partisjonert System under Consideration (SuC) med dokumenterte soner og kanaler. Resonnementet lever i 1-1; metodikken lever i 3-2; kontrollkatalogen anvendt på hver sone og kanal lever i 3-3.

5. Sikkerhetsnivåer — SL-T, SL-A, SL-C og den ofte forvirrede SL 1-4 numeriske skalaen

Dette er seksjonen som, hvis jeg skrev denne posten for kun én person, ville vært hele posten.

IEC TS 62443-1-1:2009 definerer et Sikkerhetsnivå som et mål på tillit til at en IACS er fri for sårbarheter og fungerer på tiltenkt måte. Den definerer deretter fire numeriske bånd:

SL 1 — beskyttelse mot tilfeldig eller utilsiktet brudd.
SL 2 — beskyttelse mot tilsiktet brudd med enkle midler, lite ressurser, generiske ferdigheter og lav motivasjon.
SL 3 — beskyttelse mot tilsiktet brudd med sofistikerte midler, moderate ressurser, IACS-spesifikke ferdigheter og moderat motivasjon.
SL 4 — beskyttelse mot tilsiktet brudd med sofistikerte midler, utvidede ressurser, IACS-spesifikke ferdigheter og høy motivasjon.

Disse fire nivåene beskriver trusselaktørs-kapabilitet. De beskriver ikke, alene, et anlegg, et produkt, en sone eller en kontroll.

Det neste trinnet er der alle tar feil. Serien definerer tre typer Sikkerhetsnivå, og den numeriske skalaen (1-4) gjelder hver:

SL-T (Target / Mål) — sikkerhetsnivået en bestemt sone eller kanal trenger å oppnå basert på dens risikovurdering. SL-T velges, per-sone, per-FR, av anleggseieren i konteksten av IEC 62443-3-2 . Resultatet av risikovurdering er en SL-T-vektor — sju tall, ett per grunnkrav — for hver sone og hver kanal.
SL-C (Capability / Kapabilitet) — sikkerhetsnivået en komponent eller et system er i stand til å oppnå når riktig konfigurert og integrert. SL-C er hva en produktleverandør erklærer om en enhet, testet mot IEC 62443-4-2 for komponenter eller IEC 62443-3-3 for systemer. En sertifisert PLS kan være SL-C 2 på tvers av alle syv FR-er, eller SL-C 3 for FR1 og SL-C 2 for alt annet. Sertifikatet bærer vektoren.
SL-A (Achieved / Oppnådd) — sikkerhetsnivået som-bygget, som-driftet sonen eller kanalen faktisk leverer i tjeneste. SL-A måles (eller estimeres) etter design, integrasjon, idriftsetting og driftsoverlevering. Det er, i praksis, hva revisjonsbeviset ditt skal bevise.

Kjeden standarden vil at du skal gå er derfor: SL-T (fra risiko) → velg komponenter / system med tilstrekkelig SL-C → design og drift for å levere SL-A ≥ SL-T. Hvis SL-A faller under SL-T, må du enten akseptere restrisiko, anvende kompenserende tiltak eller endre designet.

Dette er hvorfor revisor og integrator argumenterte forbi hverandre i åpningsscenen. Integratoren sa «vi er SL 3» og mente SL-C 3 for komponentene de leverte. Revisor sa «vi trenger SL 3» og mente SL-T 3 for sonen. Ingen hadde målt SL-A. En komponent med SL-C 3 sluppet inn i en sone med SL-T 3 produserer ikke automatisk SL-A 3 — det avhenger av konfigurasjon, integrasjon, de omkringliggende kompenserende tiltakene, og om driftspraksisene (dekket i IEC 62443-2-1:2024 ) faktisk opprettholder kapabiliteten.

Tre videre feller som vokabularet fortsatt ikke fullt løser:

SL er per grunnkrav, ikke en enkelt skalar. Å si «vi er SL 2» uten en vektor på tvers av FR1-FR7 er, strengt tatt, ikke en 62443-uttalelse. Standarden forventer en tuppel. I praksis rapporterer mange programmer en enkelt dominerende verdi pluss unntak; det er forsvarlig hvis unntakene er oppført.
IACS-omfattende SL vs sone-SL. Det finnes ikke noe slikt som en «IACS-omfattende SL» i IEC 62443-1-1. SL gjelder soner og kanaler. En IACS er en samling av soner, hver med sin egen SL-T-vektor. Et enkelttall SL for et helt anlegg er en markedsføringsartefakt.
Modenhetsnivå (ML 1-4) er ikke Sikkerhetsnivå. Modenhetsnivåer dukker opp i IEC 62443-2-4 (tjenesteleverandør-krav) og IEC TS 62443-6-1:2024 (vurderingsmetodikken for 2-4). ML måler modenheten til en prosess. SL måler sikkerhetsnivået til en sone, kanal, system eller komponent. De er forskjellige skalaer for forskjellige ting, og er ikke utskiftbare.

6. De syv grunnkravene (FR1-FR7)

IEC TS 62443-1-1:2009 definerer syv grunnkrav. De er kolonnene i matrisen som resten av serien fyller inn.

FR1 — Identification and Authentication Control (IAC). Hvem eller hva ber om handling, og har de bevist det?
FR2 — Use Control (UC). Har de tillatelse til å gjøre den forespurte handlingen?
FR3 — System Integrity (SI). Opprettholdes integriteten til kode, data og konfigurasjon mot tilsiktet og utilsiktet endring?
FR4 — Data Confidentiality (DC). Er informasjon i hvile og i bevegelse beskyttet mot avsløring der det kreves?
FR5 — Restricted Data Flow (RDF). Er dataflyter partisjonert langs sone- og kanalgrenser?
FR6 — Timely Response to Events (TRE). Blir sikkerhetsrelevante hendelser oppdaget, logget, varslet og respondert på i tide?
FR7 — Resource Availability (RA). Holdes essensielle funksjoner tilgjengelige under stress, angrep eller degradering?

To viktige ting om FR-ene som vokabularet fortsatt snubler folk på.

FR-er er ikke kontroller. De er mål. IEC 62443-3-3 dekomponerer dem i systemkrav (SR) og kravsforsterkninger (RE), og IEC 62443-4-2 dekomponerer dem igjen til komponentkrav (CR). Frasen «vi er i samsvar med FR3» er meningsløs alene — hva som er meningsfullt er «vi oppfyller SR 3.1 til 3.9 på SL-C 2 i sone X, med RE for 3.4 og 3.8 anvendt». Hvis en leverandørs datablad bare sier «i samsvar med FR3» uten SR / CR-detalj og uten SL-vektor, behandle det som markedsføringskopi.

Rekkefølgen av FR-ene er ikke en prioritetsrekkefølge. FR1 er ikke «viktigere» enn FR7. I OT er det motsatte ofte tilfelle: FR7 (ressurstilgjengelighet) og FR3 (systemintegritet) overgår ofte FR4 (datakonfidensialitet) i risikoregisteret. FR-ene er en oppregning, ikke en rangering.

De syv FR-ene er også dimensjonene i hver SL-vektor. Når en integrator overlater deg en IEC 62443-3-3-samsvarsmatrise for et system, bør det være et 7-kolonners rutenett tastet til FR1 til FR7 med en SL-C-verdi i hver celle. Når anleggseieren utleder SL-T fra IEC 62443-3-2, har utgangen samme form. Grunnen til å matche former er slik at SL-C og SL-T kan sammenlignes komponent-for-komponent.

7. Roller — anleggseier, systemintegrator, produktleverandør, tjenesteleverandør

IEC 62443-1-1 introduserer rolle-taksonomien som resten av serien operasjonaliserer. Påfølgende ISA99-arbeid og ISAGCA Quick Start Guide skjerper disse til fire hovedroller:

Anleggseier. Organisasjonen som er ansvarlig for IACS-en i drift. I fornybar er dette IPP-en, energiselskapet, asset management-selskapet — den som bærer drifts- og regulatorisk ansvar for anlegget. Anleggseier-vendte krav lever primært i IEC 62443-2-1:2024 .
Produktleverandør. Organisasjonen som designer, utvikler og støtter et produkt — en komponent eller et system — brukt i IACS-en. Produktleverandører adresseres av IEC 62443-4-1:2018 (utviklingsprosess-krav) og IEC 62443-4-2:2019 (komponentnivå tekniske krav) .
Systemintegrator. Organisasjonen som tar produkter fra leverandører og setter dem sammen til en automasjonsløsning for en anleggseier. Integratorer adresseres av IEC 62443-2-4:2023 (sikkerhetsprogram-krav for IACS-tjenesteleverandører) i deres integrasjons-rolle, og av IEC 62443-3-2 og 3-3 der de utfører design og verifikasjon på vegne av anleggseieren.
Tjenesteleverandør. Organisasjonen som drifter, vedlikeholder, overvåker eller på andre måter betjener IACS-en etter overlevering. IEC 62443-2-4 dekker dem også — eksplisitt skille mellom integrasjons-tjenesteleverandører og vedlikeholds-tjenesteleverandører.

Vedlikeholds-tjenesteleverandør-rollen er den som er hyppigst usynlig i fornybar-kontrakter og den som forårsaker mest smerte i år-tre-revisjoner. OEM-en som leverer deg turbinene er en produktleverandør. EPC-en som bygde vindparken er en systemintegrator. O&M-leverandøren som kommer på sted hvert kvartal — og OEM-fjernsupport-teamet bak en VPN-tunnel — er en vedlikeholds-tjenesteleverandør, og IEC 62443-2-4-krav gjelder dem. Hvis O&M-kontrakten din er stille om cybersikkerhets-kapabilitetskrav, har du forskjøvet modenhetsrangeringen av programmet ditt ned. Det er et IEC 62443-2-1-problem forårsaket av et vokabularproblem fra 1-1.

Argumentet dette vokabularet løser: når «leverandøren» gjør fjernsupport en søndagskveld for å gjenopprette en inverter, er det en produktleverandør-handling eller en tjenesteleverandør-handling? Svaret betyr noe fordi kravsettene er forskjellige. Under IEC 62443-1-1 er det en tjenesteleverandør-handling (de utfører driftsarbeid på den som-bygde løsningen), og kontrakten din bør reflektere 2-4-kapabilitetskrav.

8. Essensielle funksjoner og kompenserende tiltak

To flere IEC 62443-1-1-begreper som alle bruker sløvt.

Essensiell funksjon. En funksjon hvis driftsstans, eller drift i degradert tilstand, kan forårsake uakseptabel konsekvens for sikkerhet, integritet eller tilgjengelighet. I et solparkanlegg inkluderer essensielle funksjoner: beskyttelse-utløsning ved 33 kV / HV-grensesnittet, BESS termisk runaway-nedstengning, primær frekvensrespons (hvis stedet leverer systemtjenester), og de sikkerhetsrelaterte kontrollene av eventuelt høyspentkoblingsanlegg. Essensiell funksjon er ikke det samme som viktig funksjon. Listen er «tap er uakseptabelt», ikke «tap er upraktisk». IEC 62443-3-3 sier eksplisitt at visse SR-er gjelder strengere der essensielle funksjoner står på spill — for eksempel lener krav rundt tjenestenekt-toleranse seg tungt på essensiell-funksjon-konseptet.

Den praktiske konsekvensen: når du tegner sonediagrammet for IEC 62443-3-2 , må hver essensielle funksjon ende opp identifisert og sporbar til en sone. SL-T for den sonen blir deretter påvirket av konsekvensen av kompromittering av den essensielle funksjonen. En sone som bare er vert for «viktige» funksjoner kan ha en lavere SL-T enn en som er vert for essensielle funksjoner.

Kompenserende tiltak. En kontroll anvendt fordi den iboende kontrollen ikke kan implementeres eller er upraktisk. Standardens logikk er: hvis du ikke kan oppfylle en SR direkte inne i en sone, kan du anvende et kompenserende tiltak andre steder (ofte i den omkringliggende kanalen, eller med prosedyremessige midler) forutsatt at du kan argumentere for at restrisikoen er ekvivalent. Kompenserende tiltak er ikke «vi droppet det fordi det var vanskelig». De er dokumentert, begrunnet og sporbart. Et rimelig eksempel: en eldre inverter-kontroller som ikke kan håndheve sterk menneskelig-bruker-autentisering direkte (FR1 / SR 1.1) kan kompenseres med en jump host inne i kanalen, pluss en admin-prosedyre som beviser hvilken navngitt person brukte hvilken økt — forutsatt at den kompensasjonen er dokumentert, testet og gjennomgått ved frekvensen sikkerhetsprogrammet krever.

Argumentet dette løser: når et anskaffelses-team skriver «systemet skal samsvare med IEC 62443-3-3 SL 2 på tvers av alle FR-er uten unntak», har de skrevet et anskaffelseskrav som kanskje er umulig å tilfredsstille med feltutstyret som fysisk eksisterer. Standarden forventer unntak, forventer kompenserende tiltak, og forventer at de argumenteres på papir. Å kjøpe som om kompenserende tiltak var et tegn på svakhet snarere enn en normal utgang av design er i seg selv en feillesning av IEC 62443-1-1.

9. Sikkerhetslivssyklusen (fra 1-4) — vurder, design, implementer, vedlikehold

IEC TR 62443-1-4 — IACS security lifecycle and use cases — er en teknisk rapport, fortsatt under utvikling på ISA99 / IEC TC65 WG10-nivået. Utkast har sirkulert i komiteen siden rundt 2013. Det er ment å gi en detaljert beskrivelse av den underliggende livssyklusen som resten av serien antar, med bearbeidede bruksområder. Det er ikke, per skrivende stund, et ferdig IEC-dokument på IEC Webstore . Det som er publisert — og bredt sitert — er ISAGCA Security Lifecycles-whitepaperet fra ISA's Global Cybersecurity Alliance, som fanger samme konseptuelle innhold i påvente av den formelle TR-en.

Livssyklusen serien bruker har fire brede faser:

Vurder. Risikovurdering, definisjon av SuC, soneinndeling og kanal-partisjonering, utleding av SL-T per sone og kanal per FR. Dette er hjemmet til IEC 62443-3-2 og inngangspunktet for ethvert nytt prosjekt eller større modifikasjon. IEC 62443-2-1:2024 gjør vurderingsfase-aktiviteter til et programkrav for anleggseiere.
Design og implementer. Valg av produkter og integratorer med tilstrekkelig SL-C mot SL-T, design av kompenserende tiltak, fabrikkakseptansetest (FAT) og site-akseptansetest (SAT) inkludert cybersikkerhets-testtilfeller, idriftsetting. IEC 62443-3-3 er designverifikasjons-referansen; IEC 62443-4-2 er komponentvalgs-referansen; IEC 62443-2-4 er integrator-kapabilitets-referansen.
Drift og vedlikehold. Oppdateringsstyring, kontohygiene, overvåking, hendelsesrespons, periodisk re-vurdering, leverandørkjede-kontroller for vedlikeholds-tjenesteleverandører. IEC 62443-2-1:2024 er driftsfase-referansen. IEC TR 62443-2-3:2015 dekker oppdateringsstyring.
Avvikle. Sikker håndtering av legitimasjon, konfigurasjoner, avviklede aktiva, restdata. Ofte den mest forsømte fasen. Vedlikeholdsdokumentasjonen sier «avvikle per OEM-instruksjoner» og OEM-instruksjonene er stille om cybersikkerhet.

Livssyklusen i 1-4 og ISAGCA's whitepaper er ikke lineær. Den er skjæringspunktet av tre livssykluser: produktlivssyklusen (eid av produktleverandører), automasjonsløsnings-livssyklusen (eid av integratorer) og driftslivssyklusen (eid av anleggseiere og tjenesteleverandører). Hvor de krysser hverandre er der kontrakter, bevis og overleveringer lever. Det er derfor cybersikkerhet for fornybar-energi-anlegg er så kontraktdrevet: livssyklusmodellen i 1-4 er den eneste måten å kartlegge hvem som må bevise hva til hvem ved hvilken milepæl.

Argumentet dette løser: «vi gjorde IEC 62443-3-2 i designfasen, så vi er i samsvar». Nei — 3-2 er én aktivitet i vurderingsfasen. Livssyklusen fortsetter de neste tjue årene. Et soneinndelings-dokument fra 2024 er foreldet innen 2028 med mindre det re-valideres. Livssyklus-innrammingen i 1-4 er det som tvinger den kontinuerlige re-valideringen inn i kontrakten.

10. Målinger (1-3) — hva «samsvarsmåling» forsøker og hvorfor det er vanskelig

IEC 62443-1-3 — System security conformance metrics (noen ganger skrevet som «compliance metrics» i eldre komiteekorrespondanse; den publiserte tittelen bruker conformance) — er under utvikling som en teknisk rapport. Dens mål: definere en metodikk for å utlede kvantitative målinger fra prosess- og tekniske krav som resten av serien spesifiserer. I klart språk — gjøre «samsvar med 3-3 SR 1.1 på SL-C 2» til et tall du kan måle, rapportere og spore.

Dette er vanskeligere enn det høres ut, og grunnene til at det er vanskelig er verdt å være ærlig om:

De fleste 62443-kravene er kapabilitetsuttalelser, ikke målinger. «Systemet skal være i stand til menneskelig-bruker-identifikasjon og autentisering» er binært ved første øyekast, men kapabilitet under forskjellige driftsforhold er det ikke. Teller en kapabilitet som krever manuell konfigurasjon? Bare når konfigurert? Bare når revidert?
SL er ikke en måling, det er et nivå. Å gjøre et nivå til en måling krever å bestemme hvilken andel av krav på det nivået må oppfylles, med hvilket bevis, ved hvilken frekvens. Forskjellige organisasjoner har forskjellige svar, og standarden er med rette tilbakeholden med å mandatere ett universelt svar.
Anleggseiere vil ha tidsserie-målinger. «Hvordan trender vår 62443-posisjon kvartal mot kvartal?» er et helt rimelig executive-spørsmål. 62443-rammeverket, født fra ingeniør- snarere enn informasjonssikkerhets-styring, har historisk vært bedre på punkt-i-tid-samsvar enn på tidsserie-telemetri.
IEC 62443-2-2 overlapper. Protection Scheme (SPS)-arbeidet i nåværende IEC PAS 62443-2-2:2025 introduserer sikkerhetsprogram-vurderinger (SPR) som gir et relatert men separat målerammeverk. Forholdet mellom 1-3-målinger og 2-2-SPR-er har vært et aktivt område for komitéarbeid.

Inntil 1-3 lander som en publisert TR, bygger anleggseiere sine egne målinger. Rimelige valg inkluderer: prosent av soner med aktuell 3-2-dokumentasjon; prosent av komponenter med SL-C ≥ SL-T per FR; prosent av vedlikeholds-tjenesteleverandører med dokumentert 2-4-kapabilitet; gjennomsnittlig tid fra CVE-publikasjon til patch-verifikasjon; prosent av essensielle funksjoner med testede tilbakefall-prosedyrer. Ingen av disse er 62443-mandatert, men hver er forsvarlig og sporbar til et 1-1-konsept.

Argumentet dette vokabularet løser: når ledelsen spør «er vi 62443-samsvarende — ja eller nei?» kan du korrekt svare «serien fungerer ikke slik». IEC 62443-1-1 definerer ikke en enkelt binær samsvarstilstand for en IACS. Den definerer roller, kapabiliteter, nivåer og soner, som hver kan vurderes. Et 62443-program i IEC 62443-2-1 kan være konformt. En komponent kan være SL-C-sertifisert. En sone kan ha en SL-A som møter dens SL-T. Anlegget som helhet er summen av disse uttalelsene, ikke et enkelt ja/nei. Å late som annet er det som produserer den uheldige salgspitchen «vi er 62443-samsvarende» — som vanligvis er kortform for «vi selger et produkt som noen sertifiserte en gang».

11. Argumentene dette vokabularet fortsatt ikke løser

For alt som IEC TS 62443-1-1:2009 avgjør, gjenstår mange argumenter genuint åpne. Noen handler om at verden har beveget seg videre siden 2009; noen handler om hull andre utgave er ment å lukke; noen handler om steder der standarden er intensjonelt taus.

Sky og IIoT. IEC 62443-1-1 ble skrevet før «skyen» var et rutinemessig utplasseringsmål for industriell telemetri. Hvor sitter AWS IoT Core på referansemodellen? Er det nivå 3? Nivå 4? Nivå 5? Er OEM-ens sky en sone av IACS-en i det hele tatt, gitt at anleggseieren ikke driver den? Den kommende IEC TR 62443-1-6 (Application of the ISA/IEC 62443 series to the Industrial Internet of Things) er ment å adressere nøyaktig dette. Inntil den lander, håndterer anleggseiere det fra sak til sak — oftest ved å behandle sky-endepunktet som en sone eid av en tjenesteleverandør med en definert kanal til den på-sted IACS-en.

Trådløst og 5G. Samme problem. Trådløse lenker er kanaler med særegne fysisklag-trusselsmodeller. Serien rommer dem bredt, men det praktiske spørsmålet om en 5G-slice er en kanal eller en sone er uavklart i publisert tekst.

Sikkerhet-cybersikkerhet-interaksjon. IEC 61511 (funksjonell sikkerhet) og IEC 62443 (cybersikkerhet) overlapper eksplisitt ved det sikkerhetsinstrumenterte systemet. Der sikkerhetslivssyklusen og cybersikkerhets-livssyklusen er uenige — for eksempel på oppdatering av sikkerhets-PLS-er — forsoner standardene seg ikke perfekt. Nylig ISAGCA-arbeid og IEC TR 63069:2019 gir delvis veiledning. Argumentet fortsetter i reelle revisjoner.

Horisontal utpeking og sektorprofiler. 2021-utpekingen av 62443 som en horisontal standard betyr at vertikalsektor-komiteer burde referere den snarere enn å omdefinere dens begreper. IEC TS 62443-1-5:2023 formaliserer ordningen for sektorprofiler. Men innholdet i sektorprofiler for fornybar energi, vann, bygningsautomasjon, medisinsk utstyr og så videre skrives fortsatt, og betydningen av «SL-T 2» på et sykehus skiller seg materielt fra «SL-T 2» på en vindpark. Vokabularet holder; kalibreringen skiller seg.

Andre utgave av 1-1. En andre utgave har sirkulert for komitégjennomgang siden 2021. Den vil raffinere noen definisjoner, legge til ontologi-drevet presisjon (WG5TG3-konsistens-arbeidsgruppen har gjort betydelig arbeid på dette) og reflektere lærdommer fra resten av serien. Inntil den er publisert, er IEC TS 62443-1-1:2009 den autoritative referansen, og det er en viss risiko for at samvittighetsfulle lesere finner lokal divergens mellom 2009-teksten og nyere deler.

Mandatorisk eller ikke? IEC 62443 er ikke, alene, en lov noe sted. Det europeiske NIS2-direktivet navngir «europeiske standarder og spesifikasjoner relevante for sikkerheten til nettverks- og informasjonssystemer» — og IEC 62443 er bredt sitert som den mest-relevante referansen for OT-omfanget, men direktivet mandaterer ikke 62443 med dokumentnummer. Norge, hvor jeg arbeider, transponerer NIS2 med tilsvarende slingringsmonn. EU Cyber Resilience Act pålegger bindende cybersikkerhets-essensielle krav på produkter med digitale elementer; harmoniserte standarder under CRA vil lene seg tungt på 62443-4-1 og 4-2, men igjen, dokumentnummer er ikke i den juridiske teksten. For fornybar-energi-operatører i Europa er det praktiske svaret: 62443 er frivillig ved navn, men funksjonelt påkrevd av anskaffelse, forsikring, regulator-forventning og leverandørkjede-press. Se mine gjennomganger om NIS2-anvendbarhet og CRA-anvendbarhet for detaljene.

Røde flagg i samtale

En kort feltguide. Disse er frasene som, når jeg hører dem i en workshop eller en revisjon, forteller meg at den som snakker ikke nylig har lest IEC TS 62443-1-1:2009 og sannsynligvis ikke har lest den i det hele tatt.

«Vi er SL 3-samsvarende.» Samsvarende mot hva? Mål, kapabilitet eller oppnådd? For hvilken sone? For hvilke FR-er? På hvilket bevis? Uten de kvalifikatorene er det en markedsføringsfrase.
«Hele anlegget er SL 2.» Det finnes ingen anlegg-omfattende SL i IEC 62443-1-1. SL gjelder soner og kanaler.
«OT og IACS er samme sak.» De overlapper, men OT (per NIST SP 800-82r3) er et bredere begrep og ekskluderer personell- og prosess-omfanget som IEC 62443-1-1 inkluderer i IACS. De er ikke synonymer.
«FR3 er en kontroll vi implementerte.» FR3 er et grunnkrav — et mål. Kontroller er SR, RE og CR under det. Hvis noen kaller en FR en kontroll, har de hoppet over et nivå av standarden.
«PLS-en vår er 62443-sertifisert.» Mot hvilken del? 4-1? 4-2? Ved hvilken SL-C? På tvers av hvilke FR-er? «62443-sertifisert» er ikke en spesifikasjon.
«Soner er bare VLAN-er.» Soner er grupperinger etter felles sikkerhetskrav. VLAN-er er én mulig håndhevelses-mekanisme for kanalen mellom soner. De to konseptene er på forskjellige abstraksjonsnivåer.
«Vi trenger ikke kompenserende tiltak, vi er fullt samsvarende.» Et 62443-design med ingen dokumenterte kompenserende tiltak på et reelt industrielt sted er nesten alltid ønsketenkning, ikke grundighet.
«IEC 62443-1-1 er bare definisjoner, vi kan hoppe over den.» Den definerer hvert begrep resten av serien hviler på. Å hoppe over den er hvordan revisjonssamtalen i åpningsscenen til denne posten skjer.
«Integratoren overleverte et SL-T-dokument, så vi er ferdige.» SL-T er inngangen til design, utledet fra risiko. SL-A er hva du må måle etter idriftsetting og måle på nytt gjennom livssyklusen. SL-T alene beviser intensjon, ikke leveranse.
«Modenhetsnivå 3 er lik sikkerhetsnivå 3.» De er forskjellige skalaer for forskjellige objekter. ML måler prosessmodenhet; SL måler sone-, kanal-, system- eller komponent-sikkerhet.

Hvert av disse røde flaggene peker tilbake til en seksjon av IEC 62443-1-1. Botemiddelet er sjelden å krangle høyere; det er å åpne dokumentet og lese den relevante definisjonen sammen. Vokabularet, når delt, fjerner omtrent to tredjedeler av uenighetene som forbruker revisjonstid.

FAQ

Hva er IEC 62443-1-1?

IEC TS 62443-1-1:2009 er fundament-teknisk-spesifikasjonen for IEC 62443-serien. Publisert av IEC i juli 2009 (utgave 1.0), den definerer terminologien, konseptene og referansemodellene som resten av serien bruker — inkludert IACS, soner, kanaler, sikkerhetsnivåer (SL-T, SL-A, SL-C), de syv grunnkravene (FR1-FR7) og hovedrollene (anleggseier, produktleverandør, integrator, tjenesteleverandør). Den er tilgjengelig fra IEC Webstore som publikasjon 7029 . En andre utgave har vært i komitégjennomgang ved ISA99 / IEC TC65 WG10 siden 2021.

Hva er forskjellen mellom SL-T og SL-C?

SL-T (Target / Mål) er sikkerhetsnivået en bestemt sone eller kanal trenger å oppnå, utledet fra risikovurdering under IEC 62443-3-2 . SL-T er en anleggseier-utgang: den sier «denne sonen trenger SL 3 på tvers av disse FR-ene på grunn av risikoprofilet her». SL-C (Capability / Kapabilitet) er sikkerhetsnivået en komponent eller et system er i stand til å oppnå når riktig konfigurert. SL-C er en produktleverandør-utgang, sertifisert mot IEC 62443-4-2 (komponenter) eller IEC 62443-3-3 (systemer). En komponent med SL-C 3 sluppet inn i en sone med SL-T 3 leverer ikke automatisk SL-A (Oppnådd) 3 — det avhenger av konfigurasjon, integrasjon, kompenserende tiltak og driftspraksis.

Er IEC 62443 mandatorisk?

Alene, nei. IEC 62443 er en frivillig internasjonal standardserie, ikke lovgivning. Imidlertid refereres den eller stoles på av en voksende liste av rammeverk som er bindende — EU NIS2-direktivet, EU Cyber Resilience Act, sektorregulatorer og nasjonale transponeringer i land inkludert Norge. Anskaffelseskontrakter, forsikringskrav og leverandørkjede-forventninger siterer i økende grad spesifikke deler (vanligvis IEC 62443-2-1, 3-3, 4-1 og 4-2). Det praktiske svaret for en anleggseier i kritisk infrastruktur er: ikke mandatorisk ved navn, men veldig ofte mandatorisk gjennom tingene som er mandatoriske. Se mine poster om NIS2-anvendbarhet og CRA-anvendbarhet for hele resonnementkjeden.

Hvorfor er ikke IEC 62443-1-2 (hovedordlisten) tilgjengelig?

Fordi den, fra 2025-2026, fortsatt er under utvikling ved ISA99 / IEC TC65 WG10. ISAGCA Structuring the ISA/IEC 62443 Standards-skrivet bemerker at 1-2 «is a master glossary of terms and abbreviations used throughout the series» og at komiteen planlegger å levere den i et online-format. Inntil den publiseres som et ferdig IEC-dokument, forblir de autoritative definisjonene de gitt inne i IEC TS 62443-1-1:2009 og inne i hver nummerert dels egen definisjonsklausul. Kryssreferanse med NIST SP 800-82 Rev. 3 er nyttig for OT/ICS-terminologi som berører, men ikke er identisk med 62443's IACS-vokabular.

Hvordan forholder soner og kanaler seg til Purdue-modellen?

Purdue Enterprise Reference Architecture (PERA) er en hierarkisk funksjonell modell — nivå 0 til 5 — som beskriver hvor aktiviteter sitter i et automasjonshierarki. IEC 62443-1-1's referansemodell er informert av Purdue, men legger til sikkerhets-konseptene soner og kanaler på toppen. En sone grupperer aktiva som deler felles sikkerhetskrav; en kanal er settet med kommunikasjonskanaler mellom soner. Soner trenger ikke å være en-til-en med Purdue-nivåer, selv om de i velkonstruerte anlegg ofte er det av fornuftige ingeniørgrunner. De to modellene er komplementære, ikke konkurrerende.

Videre lesing på dette nettstedet: forvaltningssystem-synet er i IEC 62443-2-x: hva anleggseiere må bevise ; systemdesign-synet er i IEC 62443-3-2 og 3-3: hva anleggseiere og integratorer må bevise ; produktleverandør-synet er i IEC 62443-4-1 og 4-2: hva OEM-er må bevise . Les dem i hvilken rekkefølge du vil — men les denne først, fordi det er dokumentet de andre antar du allerede forstår.