IEC 62443-3-2 og 3-3: hva anleggseiere og integratorer må bevise

OEM-side-teksten i denne serien tar for seg de to standardene en produktleverandør må leve med: IEC 62443-4-1 (hvordan et produkt bygges) og IEC 62443-4-2 (hva produktet faktisk kan gjøre) — for den detaljerte gjennomgangen, se IEC 62443-4-1 og 4-2: hva en OEM faktisk må bevise . De er avgjørende, men de utgjør bare halve historien. Å kjøpe sertifiserte komponenter er én ting; å gjøre dem om til et fungerende industrielt kontrollsystem som er dimensjonert riktig mot de faktiske truslene, fornuftig partisjonert mellom soner, og levert med harde bevis for at det ferdige anlegget er like sikkert som designet var ment å være — det er en annen disiplin. Den disiplinen styres av to andre deler i samme IEC 62443-familie: IEC 62443-3-2 og IEC 62443-3-3.

Disse to standardene sitter ett nivå over 4-1 og 4-2. De lever på system-laget heller enn komponent-laget, og de besvarer to forskjellige men tett koblede spørsmål. IEC 62443-3-2 spør «hvordan finner jeg ut hvilket sikkerhetsnivå jeg faktisk trenger i hver del av mitt industrisystem?» IEC 62443-3-3 spør «hvis jeg har bestemt at jeg trenger et bestemt sikkerhetsnivå i en del av systemet, hva må den delen av systemet faktisk gjøre for å levere det?» Den ene produserer kravspesifikasjonen; den andre definerer hva som teller som å oppfylle den. Sammen sitter de mellom anleggseierens risikobilde og OEM-ens sertifiserte komponenter, og dette er også hvor den EU-regulatoriske kjeden — NIS2 for anleggseier-siden, Cyber Resilience Act for produkt-siden — oftest lander i reelle anskaffelseskontrakter.

Målet er det samme som sist. Hvem som helst kan hevde «samsvar med IEC 62443»; spørsmålet som betyr noe er hva de objektivt må kunne demonstrere for å underbygge påstanden. Standardene er formelle og strukturerte nok til at svaret faktisk er kjennbart — forutsatt at du vet hva du skal spørre etter.

Du kan kjøpe de offisielle standardene fra IEC Webstore: IEC 62443-3-2:2020 og IEC 62443-3-3:2013 .

En rask orientering i IEC 62443-familien

For å se hvor 3-2 og 3-3 passer inn, hjelper det å huske den fire-nivå-formen som hele IEC 62443-serien har. Del 1 etablerer terminologi og konsepter. Del 2 dekker retningslinjer og prosedyrer, hovedsakelig for anleggseieren og deres tjenesteleverandører — dekket separat i IEC 62443-2-x: forvaltningssystemet bak et sikkert industrianlegg . Del 3 — hvor dagens to standarder lever — dekker systemnivået. Del 4 dekker de individuelle komponentene som integreres inn i systemet.

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef tier fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef focus fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:2px;
    classDef dim fill:#f4f4f4,stroke:#888,color:#444,stroke-width:1px;

    A[IEC 62443-serien
Cybersikkerhet for IACS]:::entry

    A --> G[Del 1 — Generelt
Konsepter, terminologi]:::tier
    A --> P[Del 2 — Retningslinjer og prosedyrer
Anleggseier og tjenesteleverandør]:::tier
    A --> S[Del 3 — System
Anleggseier og systemintegrator]:::tier
    A --> C[Del 4 — Komponent
Produktleverandør / OEM]:::tier

    S --> S1[62443-3-2
Sikkerhetsrisikovurdering
for systemdesign
METODIKK]:::focus
    S --> S2[62443-3-3
Systemsikkerhetskrav
og sikkerhetsnivåer
KRAV]:::focus

    C --> C1[62443-4-1
SDL — prosess]:::dim
    C --> C2[62443-4-2
Komponent-kapabilitet]:::dim

De to standardene i søkelyset i dag sitter klart i Del 3, og de er felles ansvar for anleggseieren (operatøren av anlegget) og systemintegratoren (ingeniørorganisasjonen som designer og bygger det integrerte systemet). OEM-ens standarder fra Del 4 er relevante her fordi komponentene de leverer må kunne kombineres til et system som oppfyller 3-3, men OEM-en er ikke selv målgruppen for 3-2 og 3-3.

Den utvidede byggeanalogien

Før vi går inn i noen av standardene i detalj, vil en analogi hjelpe — resten av artikkelen lener seg på den. Å konstruere et industrielt kontrollsystem er ikke ulikt det å konstruere et sykehus. Det er flere distinkte fag involvert, hver med sin egen disiplin, og hvert må produsere bevis tilpasset sin rolle.

IEC 62443-3-2 er arkitektens brief og konstruksjonsingeniørens beregninger. Før en eneste murstein legges, bestemmer noen hvilke laster bygningen må tåle, hvor brannskillene skal være, hva slags vinduer som trengs gitt det lokale klimaet, om operasjonsstuene trenger redundant strømforsyning, og hvordan pasientflyter skilles fra personalstrømmer. Resultatet er et sett designbeslutninger med risikobegrunnede mål knyttet til seg: denne korridoren må være et brannskille; dette rommet må ha overtrykk; denne strømmateren må ha reserve. Disse beslutningene tas av folk som er kvalifisert til å ta dem, og signeres ut av bygningens eier. De er ennå ikke en bygning — de er briefen mot hvilken bygningen vil bli konstruert.

IEC 62443-3-3 er byggeforskriften. Den er regelboka som sier: gitt hvilken type bygning du konstruerer og designvalgene som følger av det, her er de spesifikke tingene som må være sanne om den ferdige strukturen. Branndører av en viss klasse må ha gradert hengsler og selvlukkende mekanismer. Nødutganger må være av en minimumsbredde. Operasjonsstuer i denne kategorien anlegg må ha den-og-den luftvekslingsraten. Forskriften er generisk — den kjenner ikke ditt spesifikke sykehus — men den forteller entreprenøren hva de må oppnå for å tilfredsstille designbriefen.

IEC 62443-4-2 er kvalitetsmerket på hver murstein, branndør og kursvern. Hver enkelt byggekomponent har blitt uavhengig testet og gradert. Når entreprenøren spesifiserer en branndør gradert til FD60, plukker de en dør med sertifikat på den graderingen.

IEC 62443-4-1 er mursteinsfabrikkens kvalitetsstyringssystem. Det er det som gir deg tillit til at det sertifiserte produktet på byggeplassen faktisk er det samme produktet som ble testet for kvalitetsmerket.

Sammen utgjør de fire standardene en kjede der hvert ledd har en klar eier og klare beviskrav. Anleggseieren produserer briefen (3-2). Entreprenøren bygger mot byggeforskriften (3-3) med sertifiserte komponenter (4-2) laget av kvalitetskontrollerte leverandører (4-1). Anleggseieren inspiserer, sertifiserer og drifter den ferdige bygningen. Hver overlevering er en definert artefakt, og hver part er ansvarlig for et definert omfang.

Med det bildet på plass, kommer de to standardene selv nå.

Hva IEC 62443-3-2 faktisk er

IEC 62443-3-2:2020, formelt med tittelen «Security risk assessment for system design», er metodikkstandarden for anleggseieren. Den forteller ikke hvordan ditt industrisystem må se ut; i stedet forteller den hvordan du selv kan finne ut det, på en strukturert og gjentakbar måte, basert på faktisk risiko i din faktiske driftskontekst.

Standardens sentrale bidrag er en arbeidsflyt — vanligvis omtalt som Zone and Conduit Requirements (ZCR)-prosessen — som tar en beskrivelse av systemet du har til hensikt å beskytte og produserer, som sin utdata, et partisjonert design med mål-sikkerhetsnivåer (Target Security Levels, SL-T) allokert til hver del. Den utdata er den formelle inngangen til neste fase: å velge og integrere komponenter som kan oppfylle de målene, som er der IEC 62443-3-3 tar over.

Hovedmålgruppen for 3-2 er anleggseieren, selv om de nesten alltid vil engasjere ekstern hjelp. Arbeidet krever både dyp prosesskunnskap om anlegget (som anleggseieren har) og spesialisert cybersikkerhetskompetanse (som vanligvis hentes inn, ofte via en systemintegrator eller en uavhengig risikokonsulent). Det endelige ansvaret forblir likevel hos anleggseieren. Hvis en systemintegrator kjører ZCR-workshopene for deg, overfører ikke det ansvaret for det resulterende designet til dem — det overfører ansvaret for kvaliteten på analysen, men beslutningene er dine å ta og signere ut.

Hva 3-2 ikke er, er like viktig å forstå. Det er ikke en risikovurderingsmetodikk i preskriptiv forstand — den forteller deg ikke om du skal bruke en NIST SP 800-30-tilnærming, en ISO 31000-tilnærming, en HAZOP-avledet tilnærming eller noe annet. Den forteller deg hva risikometodikken din må dekke og hva den må produsere, men den overlater valget av underliggende teknikk til organisasjonen din. Dette gjør 3-2 beundringsverdig fleksibel på tvers av sektorer — prosessindustrier kan koble den inn i sin eksisterende HAZOP/LOPA-kultur, mens diskret produksjon eller energiverk kan bruke metoder mer kjent for dem — men det betyr også at «samsvar med 3-2» krever mer enn å plukke en metodikk fra hylla. Det krever å demonstrere at den valgte metodikken faktisk gjør det 3-2 krever av den.

Hva 3-2 betyr praktisk: den syv-stegs arbeidsflyten

Hjertet av IEC 62443-3-2 er en nummerert arbeidsflyt. Selv om standarden uttrykker den mer formelt, koker den i praksis ned til sju steg som flyter fra en beskrivelse av «hva vi beskytter» gjennom til «her er det dokumenterte designet med risikobegrunnede sikkerhetsnivåer».

flowchart TD
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef step fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef decision fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
    classDef output fill:#ffe0b2,stroke:#e65100,color:#3d1e00,stroke-width:2px;

    Step1[Steg 1
Identifiser systemet
som vurderes SUC]:::entry
    Step2[Steg 2
Innledende høynivå-
risikovurdering]:::step
    Step3[Steg 3
Partisjoner SUC
i soner og kanaler]:::step
    Step4{Steg 4
Er innledende risiko under
tolerabel risiko?}:::decision
    Step5[Steg 5
Detaljert risikovurdering
per sone og kanal
Fastsett SL-T-verdier]:::step
    Step6[Steg 6
Dokumenter Cybersecurity
Requirements Specification CRS]:::step
    Step7[Steg 7
Anleggseiers godkjenning
og signering]:::output

    Step1 --> Step2 --> Step3 --> Step4
    Step4 -->|Ja — akseptabel| Step6
    Step4 -->|Nei — dypere analyse trengs| Step5
    Step5 --> Step6
    Step6 --> Step7

Det første steget er å identifisere systemet som vurderes (System Under Consideration, SUC). Dette høres trivielt ut, men er sjelden det. SUC-beskrivelsen må være spesifikk nok til at hvem som helst som leser den senere — en revisor, en etterfølger, en regulator — kan forstå nøyaktig hva som ble vurdert og hva som ikke ble det. I praksis betyr dette et høynivå-arkitekturdiagram, en oversikt over hovedutstyret og programvaren i SUC, et nettverkskart, en eksplisitt uttalelse om forretnings- og sikkerhetsfunksjonene SUC støtter, en liste over eksterne grensesnitt, og en klar merknad om hva som er utenfor omfanget. En SUC som er for snevert avgrenset etterlater farlige antakelser om grensen; en SUC som er for vidt avgrenset produserer analyser som er for grove til å være nyttige.

Det andre steget er en innledende høynivå-risikovurdering av SUC-en som helhet. Dette er en grovkornet, kvalitativ gjennomgang som stiller det enkle spørsmålet: hvis den verste troverdige cybersikkerhetshendelsen skjedde med denne SUC, hva ville konsekvensene vært for sikkerhet, miljø, produksjon, regulatorisk stilling og inntekt? Utdata er vanligvis én enkelt «verst troverdig» risikovurdering og en indikasjon på om SUC-en som helhet rettferdiggjør den mer granulære analysen som følger. I nesten alle reelle industrielle settinger gjør den det — men å ha den innledende vurderingen på fil bygger saken for det dypere arbeidet og gir en baseline som restrisikoen senere kan sammenlignes mot.

Det tredje steget er den sentrale designhandlingen i 3-2: å partisjonere SUC-en i soner og kanaler. En sone er en gruppering av aktiva som deler samme sikkerhetskrav — typisk fordi de har lignende funksjon, lignende konsekvens av svikt, lignende tillitsnivå, eller lignende driftsmiljø. En kanal er den kontrollerte kommunikasjonskanalen mellom soner. Å tegne sonene og kanalene er det som gjør et udifferensiert nettverksdiagram om til en sikkerhetsbevisst arkitektur. For å fortsette byggeanalogien, er dette øyeblikket hvor arkitekten bestemmer at «disse rommene utgjør operasjonsstue-suiten, denne korridoren forbinder dem med oppvåkningsavdelingen, og svingdørene på dette punktet vil være brannskillet». Beslutningen er konsekvensrik fordi alt nedstrøms — SL-T-allokering, komponentvalg, kanalbeskyttelsesmekanismer — flyter fra hvor du trekker disse linjene.

Det fjerde steget spør om den innledende risikoen vurdert i steg to, sett gjennom linsen av den foreslåtte partisjoneringen, allerede faller under anleggseiers tolerable risikoterskel. Hvis den gjør det — kanskje fordi SUC-en er liten, isolert og lav-konsekvens — kan prosessen gå direkte til dokumentasjon. I de fleste reelle industrielle situasjoner gjør den imidlertid ikke det, og arbeidsflyten beveger seg inn i hjertet av analysen i steg fem.

Steg fem er den detaljerte risikovurderingen, utført per sone og per kanal. Det er her trusler, sårbarheter og konsekvenser systematisk analyseres for hver sone og kanal ved å bruke uansett hvilken risikometodikk organisasjonen har vedtatt. Det avgjørende utfallet av dette steget er mål-sikkerhetsnivået (SL-T) for hver sone og kanal. SL-T uttrykkes i standardens én-til-fire-skala brukt andre steder i 62443, og — viktig — uttrykkes vanligvis per grunnkrav — så en enkelt sone kan ha en SL-T-vektor som (3, 2, 3, 2, 2, 2, 2) på tvers av FR1 til FR7. Ulike soner vil vanligvis ha ulike vektorer. En sone som inneholder det sikkerhetsinstrumenterte systemet til et raffineri, for eksempel, vil typisk kreve høyere SL-T for FR3 (System Integrity) enn ingeniørkontorets generelle IT-nettverk som sitter i en annen sone.

Steg seks er dokumentasjon. Utdata fra hele prosessen må fanges i en formell artefakt, konvensjonelt kalt Cybersecurity Requirements Specification (CRS). CRS-en registrerer SUC-beskrivelsen, sonene og kanalene, SL-T-ene, antakelsene som er gjort (for eksempel «vi antar at bedriftens brannmur blokkerer all innkommende SMB-trafikk til kontrollnettverket»), begrensningene som er erkjent (for eksempel «den eldre PLS-familien i bruk støtter ikke multifaktorautentisering, så kompenserende kontroller anvendes på kanalen»), og enhver restrisiko som bevisst er akseptert. CRS-en er mer enn intern dokumentasjon — den er den kontraktsmessige broen mellom anleggseier og systemintegrator. Det er det integratoren må levere mot under 3-3.

Det sjuende og siste steget er anleggseiers godkjenning. Standarden er eksplisitt på at anleggseieren er ansvarlig: en integrator eller konsulent kan ha produsert dokumentet, men anleggseieren må bevisst akseptere konklusjonene og restrisikoen det innebærer. I praksis betyr dette vanligvis signering på et definert seniornivå — ofte av noen i drifts- eller asset management-linjen som kan holdes ansvarlig for cybersikkerhetsstillingen ved anlegget.

Hva anleggseieren må bevise objektivt for 3-2

Når en anleggseier hevder samsvar med IEC 62443-3-2, bør de på forespørsel kunne produsere den dokumentariske oversikten over å ha gjort arbeidet skikkelig. Samsvar med 3-2 handler ikke om et sertifikat på veggen — det finnes ingen utbredt tredjepartssertifiseringsordning for anleggseier-samsvar med 3-2, slik ISASecure SDLA og CSA eksisterer for OEM-er. I stedet handler demonstrasjon om bevispakken.

En troverdig bevispakke begynner med SUC-beskrivelsen i nok detalj til at en ekstern vurderer kan spore tilbake hva som ble vurdert og hva som ble bevisst ekskludert. Den inkluderer metodikken som ble brukt — det eksplisitte risikovurderingsrammeverket valgt, med sine poenggivningsregler og risikoterskler. Den inkluderer trusselkildene som ble vurdert, ideelt med referanse til en aktuell trusselkatalog som ENISAs ICS-trusselrapporter, MITRE ATT&CK for ICS, sektorvise informasjonsdelings- og analysesentre (som E-ISAC for elektriske energiverk), eller nasjonale CSIRT-rådgivere. Den inkluderer risikoregisteret som resulterte fra stegene fire og fem, med hver sone og kanals risiko før kontroll og restrisiko skrevet ned. Den inkluderer sone- og kanaldiagrammet selv — typisk et nettverksaktig skjema overlagt med fargede sonegrenser og merkede kanaler. Og den kulminerer i Cybersecurity Requirements Specification, signert ut på et passende nivå i anleggseiers organisasjon.

Standarden foreskriver ikke hvor ofte denne øvelsen må gjentas, men god praksis er å gjennomgå CRS-en når SUC-en endrer seg vesentlig, når trussellandskapet skifter betydelig, eller i en fast syklus på typisk tre til fem år. Bevis på denne gjennomgangskadensen — møtereferater, versjonskontrollerte CRS-revisjoner, en dokumentert endringskontrollprosess — er i seg selv en nyttig demonstrasjon av samsvar.

Det er en finurlighet verdt å dvele ved. Samsvar med 3-2 er ikke det samme som å ha «lav risiko» i det resulterende systemet. En anleggseier kan fullt ut samsvare med 3-2 og fortsatt bevisst akseptere relativt høy restrisiko i noen soner — forutsatt at den beslutningen er dokumentert, begrunnet av forretningskontekst, og godkjent av noen med myndighet til å gjøre det. Det 3-2 krever er bevis på å ha resonnert om det skikkelig, ikke et bestemt utfall. Standarden er prosedyremessig i ånden, ikke preskriptiv om resultater. Dette er noen ganger ubehagelig for revisorer som forventer å se en «bestått/ikke bestått»-dom, men det er det riktige designet for en standard som må tjene alt fra et avløpsrenseanlegg til et atomkraftverk.

Hva IEC 62443-3-3 faktisk er

Hvis 3-2 spør «hvilket sikkerhetsnivå trenger jeg hvor?», så spør IEC 62443-3-3:2013 «hva må et system på et gitt sikkerhetsnivå faktisk kunne gjøre?». Den har tittelen «System security requirements and security levels», og er kravkatalog-standarden for systemlaget.

3-3 definerer systemkrav (System Requirements, SRs) gruppert under de samme syv grunnkravene som brukes andre steder i IEC 62443 — Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, og Resource Availability. Hvert SR er en kapabilitet som et integrert industrielt automasjons- og kontrollsystem må støtte, uttrykt på en måte som i stor grad er uavhengig av noen bestemt leverandørs produkter. Mange SR-er har en eller flere kravsforsterkninger (Requirement Enhancements, REs) som gjelder på høyere sikkerhetsnivåer — samme idé som i 4-2, der et grunnleggende SR forsterkes på SL 3 eller SL 4 med ekstra grundighet. Standarden inneholder i størrelsesorden femti pluss SR-er, med den totale tellingen som klatrer godt over hundre når REs inkluderes; den nøyaktige tellingen avhenger av hvordan du teller.

Målgruppen for 3-3 er hovedsakelig systemintegratoren — ingeniørorganisasjonen som tar anleggseiers CRS og gjør den om til et levert integrert system. Produktleverandøren bryr seg indirekte om 3-3 fordi komponentene deres, sertifisert til 4-2 , må kombineres på en slik måte at systemet som helhet kan oppfylle 3-3-systemnivå-kravene. Anleggseieren bryr seg fordi de må kunne verifisere at det leverte systemet faktisk oppnår det som ble spesifisert.

En nyttig mental modell er at 3-3 er til systemet det 4-2 er til komponenten. Begge standardene bruker de samme syv grunnkravene som sin organiserende ryggrad. Begge uttrykker krav på en leverandørnøytral måte. Begge graderer kravene etter sikkerhetsnivå 1 til 4. Forskjellen er integrasjonsnivået kravet gjelder på. Et 4-2-krav kan være «komponenten skal støtte unik brukerautentisering». Det tilsvarende 3-3-kravet kan være «systemet skal håndheve unik brukerautentisering på tvers av alle sine komponenter, inkludert føderering av identiteter der flere komponenter deltar i en enkelt brukersesjon, med revisjonsloggning av autentiseringshendelser som kan korreleres sentralt». Komponenten kan være kapabel, men integrasjonen er det som gjør kapabiliteten reell.

Hva 3-3 betyr praktisk

En god måte å forstå hva 3-3 faktisk krever, er å se på noen av systemkravene gjennom linsen av hva de oversettes til for ingeniørteamet som bygger systemet.

Under grunnkrav 1 (Identification and Authentication Control) forventer 3-3 at systemet leverer unik kontoidentifikasjon på tvers av alle brukere og enheter, støtter sterke autentiseringsmekanismer passende for SL-en, og — på høyere SL-er — krever multifaktorautentisering for sensitive operasjoner som ingeniørendringer eller modifikasjoner av sikkerhetssystemer. Praktisk betyr dette at et system på SL-T 3 ikke kan stole på delte innlogginger, generiske operatørkontoer eller hardkodede enhetspassord; identitet må være unik, sporbar og kryptografisk støttet.

Under FR 2 (Use Control) må systemet håndheve rollebasert tilgang, må begrense kjøring av mobilkode, må beskytte revisjonsinformasjon mot manipulasjon, og må støtte kontinuerlig overvåking av hvem som gjorde hva når. Dette oversettes til et system hvis ingeniørarbeidsstasjoner logger hver parameterendring til et manipulasjonsbevis revisjonsspor, hvis operatørskjermer begrenser hva en operatør kan gjøre basert på en definert rolle, og hvis programmeringsenheter ikke kan kjøre vilkårlig kode ved uhell eller ved en ondsinnet USB-pinne.

Under FR 3 (System Integrity) må systemet beskytte seg mot uautoriserte endringer av fastvare, konfigurasjon og data, både i bevegelse og i hvile. Kommunikasjonskanaler mellom soner (kanalene identifisert under 3-2) må beskytte meldingsintegritet, og systemet må støtte kryptografisk verifisering av programvaren og fastvaren som kjører på sine komponenter. På høyere SL-er utvider dette seg til å inkludere kontinuerlig integritetsovervåking og automatisert deteksjon av uautoriserte endringer.

Under FR 4 (Data Confidentiality) må sensitiv informasjon i bevegelse og i hvile beskyttes. På lavere SL-er kan dette bety transportlag-kryptering for ingeniørsesjoner; på høyere SL-er inkluderer det beskyttelse av legitimasjon i lagring, kryptering av lagrede konfigurasjonsdata, og beskyttelse mot side-kanal-avsløring på delt infrastruktur.

Under FR 5 (Restricted Data Flow) må systemet operasjonelt støtte sone-og-kanal-arkitekturen som er pålagt av 3-2. Det må støtte håndheving av kanalgrensene (typisk via brannmurer, énveis-gateways eller datadioder i høyere-SL-soner), det må forhindre uautorisert lateral trafikk mellom soner, og på høyere SL-er må det inkludere mekanismer for å oppdage og varsle ved brudd på kanal-policyen.

Under FR 6 (Timely Response to Events) må systemet produsere, lagre, beskytte og gjøre tilgjengelig et sammenhengende sett med sikkerhetsrelevante hendelser — logger som tillater deteksjon, undersøkelse og gjenoppretting. På høyere SL-er inkluderer dette integrasjon med Security Information and Event Management (SIEM)-systemer, evnen til å støtte nær-sanntidsvarsling, og rettsmedisinsk kvalitet på bevisbevaring.

Under FR 7 (Resource Availability) må systemet være motstandsdyktig mot tjenestenekt-forhold, må støtte sikkerhetskopiering og gjenoppretting av all kritisk konfigurasjon og data, og må kunne operere trygt når det er degradert. Dette er hvor industrispesifikke bekymringer — graceful feilmoduser, deterministisk oppførsel, prioriterte nøddrift — møter generiske krav til cybersikkerhetstilgjengelighet.

En nyttig måte å forestille seg 3-3 som helhet er som en sjekkliste av systemkapabiliteter, indeksert etter SL. På SL-T 1 er listen «beskytt mot tilfeldige eller utilsiktede brudd»; på SL-T 4 er listen «beskytt mot tilsiktede brudd med sofistikerte midler med utvidede ressurser, IACS-spesifikke ferdigheter og høy motivasjon» — bredt sett trusler i nasjonalstats-klasse. Listen over SR-er er den samme på tvers av alle fire SL-er; det som endres er dybden, grundigheten og ressursene for hver kapabilitet. Standarden er omhyggelig om dette — for hvert SR setter standardens hovedtekst SL 1-baselinen, og REs løfter den eksplisitt opp på SL 2, 3 og 4.

Det viktigste diagrammet: SL-T, SL-C og SL-A

Av alle konseptene i IEC 62443 er forholdet mellom de tre typene sikkerhetsnivå det som oftest blandes — og det som gjør mest skade når det misforstås. De tre er villedende like i sine forkortelser, og anskaffelsesdokumenter konflaterer dem rutinemessig. Å internalisere forskjellen er, etter min erfaring, det enkelt mest nyttige en kjøper eller operatør kan gjøre når de begynner å jobbe med denne standardfamilien.

flowchart TB
    classDef demand fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:2px;
    classDef supply fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:2px;
    classDef reality fill:#1e8e3e,stroke:#0b3d20,color:#ffffff,stroke-width:2px;
    classDef arrow fill:#f4f4f4,stroke:#666,color:#222,stroke-width:1px;

    SL_T[SL-T
MÅL sikkerhetsnivå
Hva sonen TRENGER
Fra IEC 62443-3-2
Eier: Anleggseier]:::demand

    SL_C[SL-C
KAPABILITETS sikkerhetsnivå
Hva KOMPONENTENE kan levere
Fra IEC 62443-4-2
Eier: Produktleverandør]:::supply

    SL_A[SL-A
OPPNÅDD sikkerhetsnivå
Hva som FAKTISK leveres
når installert og konfigurert
Eier: Systemintegrator
og anleggseiers drift]:::reality

    SL_T -->|driver valg av komponenter med tilstrekkelig| SL_C
    SL_C -->|når integrert og konfigurert produserer| SL_A
    SL_A -.må minst være lik.-> SL_T

SL-T, mål-sikkerhetsnivået, kommer ut av IEC 62443-3-2. Det uttrykker hva anleggseieren har bestemt er nødvendig i hver sone, basert på risikovurderingen. Det er en uttalelse om etterspørsel. Det tilhører anleggseieren.

SL-C, kapabilitets-sikkerhetsnivået, kommer ut av IEC 62443-4-2 . Det uttrykker hva et bestemt produkt teknisk er i stand til å levere når det er riktig konfigurert. Det er en uttalelse om tilbud. Det tilhører produktleverandøren.

SL-A, oppnådd sikkerhetsnivå, gjelder det leverte systemet. Det uttrykker hva det integrerte, installerte, konfigurerte og operasjonaliserte systemet faktisk gjør i det levende anlegget. Det er en uttalelse om virkelighet. Det er felles ansvar for systemintegratoren (for som-bygget) og anleggseieren (for som-driftet).

Tre regler styrer hvordan disse forholder seg, og det er regler jeg vil anbefale å lære utenat. For det første kan ingen sone oppnå en SL-A høyere enn det laveste SL-C av noen komponent som sitter i den sonen — din sone er bare så sterk som dens svakeste ledd, og en enkelt SL-C 1-komponent i en ellers SL-C 3-sone drar den oppnåelige SL-A-en tilbake til 1 for den FR-en komponenten er svak i. For det andre betyr en SL-A under SL-T-en at designet ikke har levert mot kravene; enten trengs ytterligere kompenserende kontroller (kanskje på kanalen, kanskje prosedyremessig), SL-T-en må revurderes mot revidert risikoaksept, eller restrisikoen må formelt aksepteres av anleggseieren. For det tredje er SL-C en kapabilitet, ikke en garanti: en komponent sertifisert til SL-C 3 utplassert med sikkerhetsfunksjonene slått av bidrar med ikke mer enn SL-C 1 til sonen, og den vanligste måten for en SL-A å komme til kort i forhold til en SL-T er at SL-C-kapable funksjoner forblir avskrudd i felt.

Denne tre-bokstavs-trioen er ryggraden i ethvert forsvarlig 62443-basert design. Når en leverandørbrosjyre sier «SL 3-sertifisert», er det første spørsmålet «SL-hva 3?». Når en anskaffelsesspesifikasjon sier «systemet skal være SL 2», er neste spørsmål «SL-T 2, SL-C 2 eller SL-A 2?» — fordi hvert innebærer en annen forpliktelse på en annen part. En velskrevet anbudstekst skiller dem eksplisitt: «systemet skal designes og leveres for å oppnå en SL-A på minst 2 på tvers av FR1 til FR7, med komponenter med dokumentert SL-C på minst 2, til støtte for en SL-T på 2 som bestemt i den vedlagte Cybersecurity Requirements Specification». Den ene setningen — som kombinerer alle tre SL-typene, navngir de relevante standardene, og peker tilbake til CRS-en — fjerner mye potensiell tvetydighet.

Hva systemintegratoren må bevise objektivt for 3-3

Når en systemintegrator hevder samsvar med IEC 62443-3-3 for et levert system, bør anleggseieren forvente en sammenhengende bevispakke som sporer fra CRS-en produsert under 3-2, gjennom design- og anskaffelsesbeslutningene, til det som-bygde systemet og dets idriftsettingstester. Denne bevispakken er sjelden et enkelt dokument; den er oftere en strukturert samling artefakter som, tatt sammen, danner et reviderbart spor.

Integratoren må demonstrere sporbarhet mellom hver SL-T i CRS-en og systemkravene i 3-3 som har blitt anvendt i designet. For hver sone må integratoren vise hvilke SR-er på det relevante SL-et som ble vurdert, hvilke som ble implementert, hvilke som ble kompensert for via andre midler, og hvilke som formelt ble notert som ikke gjeldende med en skriftlig begrunnelse. Dette fanges vanligvis i en kravsporbarhetsmatrise som løper langs designdokumentasjonen og vedlikeholdes gjennom hele prosjektlivssyklusen. Matrisen er det enkeltdokumentet en revisor oftest vil be om først.

Integratoren må demonstrere komponentvalgs-rasjonalet: at komponentene som er valgt for hver sone har en SL-C minst like høy som SL-T-en for den sonen, for hvert relevante grunnkrav. Dette beviset er typisk hentet fra komponentenes egne 62443-4-2 -sertifikater (ISASecure CSA, IECEE CB Scheme, eller tilsvarende) krysshenvist med integratorens stykkliste. Der en valgt komponent ikke har tredjeparts 4-2-sertifisering, må integratoren begrunne valget og vise hvordan de tilsvarende 3-3-SR-ene oppfylles gjennom arkitektoniske eller kompenserende tiltak — kanskje ved å plassere komponenten bak en høyere-SL-gateway, ved å isolere den i en undersone, eller ved å anvende prosedyremessige kontroller.

Integratoren må demonstrere at systemet har blitt verifisert og validert. Dette inkluderer designgjennomganger mot SR-ene, fabrikkakseptansetesting (FAT), site-akseptansetesting (SAT), og sikkerhetsspesifikk testing som konfigurasjonsrevisjoner, sårbarhetsskanning av som-bygde systemet, og — der SL-T-en rettferdiggjør det — penetrasjonstesting av representative angrepsbaner. Testrapporter må kobles tilbake, via sporbarhetsmatrisen, til SR-ene de verifiserer. En penetrasjonstest som produserer en hundresiders rapport som ikke kan knyttes til kravene den testet, er mye mindre nyttig enn et stramt avgrenset oppdrag rettet mot SR-ene som betyr noe.

Integratoren må demonstrere at det leverte systemet overleveres med dokumentasjonen som trengs for at anleggseieren skal kunne drifte det sikkert. Dette betyr herdingsguider, sikkerhetskonfigurasjons-baselines, kontooversikter, dokumentasjon for logg- og SIEM-integrasjon, sikkerhetskopierings- og gjenopprettingsprosedyrer, runbooks for hendelseshåndtering skreddersydd for det spesifikke systemet, og en sikkerhetsdriftsmanual som forklarer hvordan hvert grunnkrav overvåkes og vedlikeholdes i drift. Overleveringspakken er det som gjør SL-A bærekraftig heller enn et endags-øyeblikksbilde på slutten av idriftsettingen.

Tredjeparts-sertifiseringsruten for systemer er ISASecure SSA (System Security Assurance), som sertifiserer en spesifikk systemimplementasjon mot IEC 62443-3-3. Som CSA for komponenter, bærer SSA forutsetningen at leverandøren har en underliggende SDLA-sertifisert prosess for eventuelle komponenter de produserer internt. SSA er materielt mindre vanlig enn CSA, delvis fordi hver systeminstallasjon er skreddersydd, men det er det nærmeste man kommer et «kvalitetsmerke» for integrerte systemer i 62443-verdenen, og verdt å spørre etter når systemet det er snakk om er en av leverandørens standard produkttilbud (en pakkebasert SCADA-løsning, for eksempel) heller enn en engangs-integrasjon.

Det er også en fremvoksende søsterordning — ISASecure SDA (Site Deployment Assurance) — som er ment å dekke den utplasserte installasjonen på en måte SSA ikke gjør. Per skrivende stund er SDA i ulike pilotstadier på tvers av industrien. Anleggseiere bør følge med på dette, fordi det potensielt lukker tillitsgapet mellom «det leverte systemet» (SSA) og «systemet slik det faktisk drifter på mitt anlegg» (SL-A i sin sanneste forstand).

Hvordan 3-2, 3-3, 4-1 og 4-2 alle passer sammen

En ren måte å visualisere forholdet mellom alle fire standardene er å tenke på fire parter som overlater hverandre definerte artefakter, hvor hver part er ansvarlig for et definert omfang og hver overlevering støttet av bevis som en utenforstående vurderer kan kontrollere.

flowchart TB
    classDef ao fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef si fill:#1e8e3e,stroke:#0b3d20,color:#ffffff,stroke-width:1px;
    classDef ps fill:#e65100,stroke:#3d1e00,color:#ffffff,stroke-width:1px;
    classDef art fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;

    AO[Anleggseier]:::ao
    SI[Systemintegrator]:::si
    PS[Produktleverandør OEM]:::ps

    AO --> Art1[IEC 62443-3-2
Cybersecurity Requirements
Specification CRS
med SL-T per sone]:::art
    Art1 --> SI

    SI --> Art2[IEC 62443-3-3
Levert system
som oppnår SL-A og oppfyller SL-T
med sporbarhetsmatrise]:::art
    Art2 --> AO

    PS --> Art3[IEC 62443-4-2
Sertifiserte komponenter
med SL-C-vektor]:::art
    Art3 --> SI

    PS -.styres av.-> Art4[IEC 62443-4-1
SDLA-sertifisert
utviklingsprosess]:::art

Anleggseieren utfører risikovurderingen under 3-2 og produserer CRS-en. Systemintegratoren tar CRS-en og leverer et system som samsvarer med 3-3, ved å bruke komponenter sertifisert til 4-2 av produktleverandører hvis utviklingsprosesser er sertifisert til 4-1. Hver part overlater den neste en definert artefakt — en CRS, en SL-C-vektor med et sertifikat, et system med sporbarhet — og hver part er ansvarlig for et definert omfang.

En nyttig test av enhver konkret utplassering er å spørre, for et hvilket som helst kontrollmål, tre spørsmål i rekkefølge: hvem eier dette, hvilken standard styrer det, og hvilket bevis dokumenterer det? Hvis noen av disse tre svarene er uskarpe, har kjeden et svakt ledd. Hvis alle tre svarene er klare, har du en forsvarlig posisjon enten du ser på det som anleggseieren, integratoren, regulatoren, eller forsikringsselskapet.

To andre deler av 62443 sitter også ved siden av disse fire. IEC 62443-2-1 styrer anleggseiers bredere cybersikkerhets-forvaltningssystem — retningslinjene, prosedyrene, opplæringen og styringen som omslutter det tekniske arbeidet dekket i 3-2 og 3-3. IEC 62443-2-4 styrer sikkerhetsegenskapene til tjenesteleverandører (typisk systemintegratorer og vedlikeholdsentreprenører) — menneskene, prosessene og kompetansene de bringer til ditt anlegg. Begge dekkes i detalj i IEC 62443-2-x: forvaltningssystemet bak et sikkert industrianlegg . Et komplett bilde for et enkelt industristed krever vanligvis bevis under flere av disse delene samtidig, med 3-2 og 3-3 som danner den tekniske kjernen i design- og leveringshistorien.

Det EU-regulatoriske bakteppet er også verdt å nevne her. Under NIS2 er anleggseiere innenfor omfanget av Annex I-sektorer (energi, transport, vann, produksjon osv.) pålagt å implementere leverandørkjede-sikkerhetstiltak under Artikkel 21(2)(d); en dokumentert 3-2 CRS med SL-T-allokering er den mest forsvarlige måten å bevise at leverandørkjedekravene er risikobegrunnede heller enn vilkårlige. Under Cyber Resilience Act må industrielle produkter med digitale elementer plassert på EU-markedet oppfylle Annex I essensielle krav, som i praksis lettest bevises gjennom 4-2-sertifisering med den tilhørende 4-1-utviklingsprosessen — nøyaktig oppstrøms av kjeden som 3-3 deretter integrerer.

Vanlige fallgruver og røde flagg

Den mest hyppige fallgruven i 3-2-arbeid er å gjøre partisjoneringen før risikovurderingen. Fristelsen er enorm: ta det eksisterende nettverksdiagrammet, tegn noen bokser rundt det som allerede er segmentert på Layer 3, og kall de sonene. Dette produserer et sonekart som reflekterer historiske kablingsbeslutninger heller enn nåværende risiko, og det tenderer å under-beskytte nye høy-konsekvens-aktiva mens det over-beskytter lav-konsekvens legacy-aktiva. Risikovurderingen må drive partisjoneringen, ikke omvendt. En nyttig diagnostikk er å se på sonegrensene og spørre: er disse grensene i tråd med konsekvenskategorier, eller med VLAN-tagger? Hvis det siste, har soneinndelingen blitt gjort baklengs.

En annen vanlig fallgruve er å konflatere SL-T med SL-C i anskaffelsesdokumenter. En spesifikasjon som sier «systemet skal være SL 3» uten kvalifikasjon overlater til leverandøren å tolke om det betyr komponenter i stand til SL 3 (SL-C 3), et som-bygget system som oppnår SL 3 (SL-A 3), eller et mål drevet av risiko (SL-T 3). Disse innebærer ganske ulike kostnadsstrukturer og ganske ulike forpliktelser. Som diskutert tidligere, betaler disiplinen med å skille de tre SL-typene i anbudsspråk seg tilbake mange ganger i klarheten på den resulterende leveransen.

En tredje fallgruve er å anta at 4-2-sertifiserte komponenter automatisk gir et 3-3-samsvarende system. Det gjør de ikke. Integrasjonen betyr minst like mye som komponentene. Usikre kanalvalg, dårlig konfigurerte autentiseringssystemer, ubeskyttede jump-verter, uovervåket loggning, delte tjenestekontoer opprettet under idriftsetting og aldri fjernet — hvilken som helst av disse kan dra et SL-C 3 komponentsett ned til en SL-A 1-virkelighet. Tilstedeværelsen av sertifiserte komponenter er nødvendig, men ikke tilstrekkelig.

Et fjerde rødt flagg er påstander om «IEC 62443-samsvarende» uten et delnummer. Standarden har mange deler, hver med en definert målgruppe. En samsvarspåstand fra en systemintegrator bør nevne 62443-3-3 (og sannsynligvis 62443-2-4 for deres tjenesteleveransepraksis). En påstand fra en produktleverandør bør nevne 62443-4-1 og 62443-4-2 . En påstand fra en anleggseier bør nevne 62443-2-1 og 62443-3-2. Enhver påstand som ikke navngir en del er, i beste fall, upresis — og vanligvis et signal om at taleren ikke er kjent med hvordan standardfamilien er organisert.

En femte fallgruve er foreldede CRS-dokumenter. En CRS produsert for ti år siden for en SUC som siden har lagt til et nytt anlegg, to nye kontrollnettverk og en flåte fjernaksess-laptoper, er ikke lenger et troverdig dokument. Refresh-sykluser betyr noe, og bevispakken bør vise dem. En CRS uten en versjonshistorikk eller en definert gjennomgangsplan er en CRS bare i navn.

En sjette og mer subtil fallgruve er sone-omfangs-drift: soner som ble definert snevert under 3-2-analysen, men som gjennom anleggets levetid stille har absorbert ekstra aktiva gjennom små endringsordrer som hver virket rimelige isolert. Total-effekten er at SL-T-en opprinnelig allokert til sonen ikke lenger dekker alt i sonen. Sunn asset management-praksis — endringskontroll som eksplisitt refererer CRS-en, ny-vurdering når aktiva krysser sonegrenser — er det som forebygger dette.

En sjekkliste for anskaffelse og revisjon

Det følgende kan brukes som et kontraktsvedlegg, et leverandørspørreskjema eller en intern revisjons-sjekkliste.

For anleggseiers egen 3-2 bevispakke

En aktuell, versjonskontrollert System Under Consideration (SUC)-beskrivelse med omfang eksplisitt oppgitt.
Et eksplisitt risikovurderings-metodikkdokument som refererer rammeverket valgt (NIST SP 800-30, ISO 31000, sektorspesifikt eller annet) med poenggivningsregler.
En trusselkatalog trukket fra troverdige kilder (ENISA, MITRE ATT&CK for ICS, sektorvise ISACs, nasjonale CSIRT-rådgivere) med oppgitt aktualitetsdato.
Et sone- og kanaldiagram som viser partisjoneringen, med soner og kanaler entydig merket.
Et risikoregister som fanger risiko før kontroll og restrisiko per sone og per kanal.
En Cybersecurity Requirements Specification (CRS) som inneholder SL-T-vektoren for hver sone og kanal, antakelsene, begrensningene og eventuelle kompenserende tiltak som er forutsatt.
Anleggseiers signering av CRS-en på et definert seniornivå, med dato.
En gjennomgangskadens for CRS-en, med bevis på tidligere gjennomganger og dato for neste planlagte gjennomgang.

For systemintegrators 3-3 leveranse-bevispakke

En kravsporbarhetsmatrise som kobler hver SL-T i CRS-en til spesifikke systemkrav i 62443-3-3 og til designelementene som tilfredsstiller dem.
En stykkliste med hver komponents 62443-4-2-sertifikat referert (eller, der en komponent er usertifisert, en skriftlig begrunnelse og de kompenserende kontrollene som er anvendt).
Et designdokumentasjons-sett som viser sone-implementasjon, kanalbeskyttelsesmekanismer, autentiseringsarkitektur, loggningsarkitektur, sikkerhetskopiering- og gjenopprettingsarkitektur, og driftsgrensesnitt.
FAT-rapporter (Factory Acceptance Test) med sikkerhetsspesifikke testtilfeller koblet til SR-ene de verifiserer.
SAT-rapporter (Site Acceptance Test) inkludert konfigurasjonsrevisjon, sårbarhetsskanningsutdata, og enhver penetrasjonstesting utført.
En overleveringspakke inkludert herdingsguider, konfigurasjons-baselines, kontooversikter, SIEM-/loggintegrasjonsdokumentasjon, sikkerhetskopierings- og gjenopprettingsprosedyrer, og en sikkerhetsdriftsmanual.
En endringsstyringsprosess for det som-bygde systemet, som definerer hvordan etterfølgende modifikasjoner vil bevare den oppnådde SL-A og hvordan CRS-en vil bli konsultert på nytt.
Der det er aktuelt, et ISASecure SSA-sertifikat for systemet eller dets kjerneplattform, med omfang, nivå og gyldighetsdato.

Spørsmål til å stille en systemintegrator skriftlig

Hvilken versjon av IEC 62443-3-3 har det foreslåtte systemet blitt designet mot?
For hver sone i vår CRS, hva er den foreslåtte SL-C-profilen på komponentene valgt, og hvordan kartlegges den mot vår SL-T?
Hvilke komponenter i din foreslåtte stykkliste innehar et aktuelt tredjeparts 62443-4-2-sertifikat? For hver, hva er sertifikatnummeret, utstedende organ, sertifisert fastvare-/programvareversjon, og utløpsdato?
For enhver komponent uten tredjeparts 62443-4-2-sertifisering, hvilke kompenserende tiltak vil levere de relevante systemkravene?
Vil leveransen inkludere en sporbarhetsmatrise som kobler SL-T til SR til designelement til verifiseringstest? Kan vi se en prøve fra et tidligere prosjekt?
Hvilken endringsstyringsprosess vil gjelde for systemet etter overlevering, slik at modifikasjoner ikke uthuler den oppnådde SL-A?
Er din tjenesteleveranse-praksis sertifisert eller vurdert mot IEC 62443-2-4 ?

IEC 62443-3-2 er standarden som forteller anleggseieren hvordan de skal finne ut, på en strukturert og forsvarlig måte, hvilket sikkerhetsnivå hver del av deres industrisystem faktisk trenger. IEC 62443-3-3 er standarden som forteller systemintegratoren hva et integrert system på det sikkerhetsnivået faktisk må gjøre. Sammen sitter de mellom anleggseiers risikobilde og OEM-ens sertifiserte komponenter, og de er der beviskjeden enten henger sammen eller brister.

Behandle 3-2 som dokumentet som rettferdiggjør hele nedstrøms-programmet. En klar CRS, signert ut på riktig nivå og gjennomgått med fornuftig kadens, er den enkelt viktigste artefakten en anleggseier kan produsere — fordi det er linsen som hver påfølgende anskaffelse, hver systemoppgradering, hver sikkerhetsrevisjon og hver hendelsesrespons tolkes gjennom. Behandle 3-3 som spesifikasjonen en integrators arbeid blir bedømt mot. En sporbarhetsmatrise fra CRS gjennom til SR gjennom til verifisert testresultat er integratorens forsvar i enhver fremtidig tvist om systemet ble levert som spesifisert. Og husk alltid at komponenter med riktig SL-C, integrert i riktige soner og kanaler, kun blir en reell SL-A når noen drifter systemet dag etter dag med sikkerhetsfunksjonene skrudd på. Standardiseringsorganer kan ikke håndheve den delen — kun god drift kan.