IEC 62443-2-x: forvaltningssystemet bak et sikkert industrianlegg

To av de andre tekstene i denne serien dekker den tekniske dimensjonen av IEC 62443. 4-1 og 4-2-artikkelen ser på hvordan en OEM beviser at produktet sitt er bygget sikkert og hva produktet faktisk kan gjøre. 3-2 og 3-3-artikkelen ser på hvordan anleggseieren dimensjonerer sikkerhetskravet til systemet sitt og hvordan systemintegratoren leverer mot det. Sammen dekker de fire standardene designet, komponentene og det leverte systemet. Det de ikke dekker — og det hele standardfamilien er ufullstendig uten — er den daglige driften. Menneskene som drifter anlegget, prosedyrene de følger, retningslinjene som styrer dem, oppdateringene som holder systemet aktuelt, og tjenesteleverandørene som kommer på stedet for å vedlikeholde det. Det er dimensjonen IEC 62443 Del 2 adresserer.

En nyttig måte å se hvorfor dette betyr noe er ved å utvide byggeanalogien fra forrige artikkel. Hvis 3-2 er arkitektens brief, 3-3 er byggeforskriften, 4-2 er kvalitetsmerket på hver komponent, og 4-1 er mursteinsfabrikkens kvalitetssystem, så er Del 2 sykehusets forvaltningssystem. Du kan ha de beste arkitektene, den strengeste byggeforskriften, de høyest gradede komponentene og de mest rigorøst kontrollerte produsentene, men hvis sykehuset deretter driftes med slurvete hygiene, uopplært personale, ingen revisjonsspor over hvem som gjorde hva, og intet system for tilbakekalling av defekt medisinsk utstyr, vil ingenting av det redde deg. Del 2 er det som gjør konstruksjonen betydningsfull i drift. Det er disiplinen som gjør et sikkert design om til et bærekraftig sikkert anlegg.

Det er fem aktive medlemmer av Del 2-familien — 2-1 til 2-5 — og de fordeler seg pent mellom to målgrupper. Anleggseieren er målgruppen for 2-1, 2-2 og 2-5, hvor 2-3 også berører dem. Tjenesteleverandøren — som standarden mener er systemintegratorer, vedlikeholdsentreprenører, managed service-leverandører og lignende tredjeparter som arbeider på eller i din IACS — er målgruppen for 2-4. Produktleverandøren dukker bare opp i Del 2 i en støtterolle (hovedsakelig i 2-3, der de må levere oppdateringsinformasjon for produktene sine i en form kundene faktisk kan bruke).

Dette blir viktig i EU-regulatorisk kontekst. Under NIS2 lander anleggseiers Artikkel 21-risikostyringsforpliktelser og Artikkel 21(2)(d) leverandørkjede-plikter direkte på territoriet 2-1 og 2-4 styrer. Under Cyber Resilience Act kobler Artikkel 14 sårbarhetsrapportering fra produktleverandøren til anleggseiers oppdateringsprogram som IEC TR 62443-2-3 kodifiserer. 2-x-standardene er det operasjonelle laget hvor EU-regulatoriske krav møter OT-virkeligheten.

Denne artikkelen jobber gjennom hver av de fem under-standardene etter tur, knytter dem deretter sammen og avsluttes med en sjekkliste for anskaffelse og revisjon.

De offisielle standardene utgis av IEC og ko-brandes av ISA. Primærkilder for hver: IEC 62443-2-1:2024 , ISA TR62443-2-2:2025 , IEC TR 62443-2-3:2015 , og IEC 62443-2-4:2015/AMD1:2018 . IEC 62443-2-5 er referert i familieoversikten på ISAs 62443-serieside .

2-x-familien i fugleperspektiv

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef ao fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef sp fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
    classDef tr fill:#f0e4ff,stroke:#6f42c1,color:#3a1a6b,stroke-width:1px;

    P2[Del 2 — Retningslinjer og prosedyrer
Forvaltningssystem-halvdelen
av IEC 62443]:::entry

    P2 --> S1[62443-2-1
Security Program Requirements
for IACS Asset Owners
2024-utgave
Målgruppe: Anleggseier]:::ao
    P2 --> S2[62443-2-2
Security Program Ratings
Metodikk for å vurdere
beskyttelseseffektivitet
Målgruppe: Anleggseier]:::ao
    P2 --> S3[62443-2-3
Patch Management in the
IACS Environment
Teknisk rapport ikke standard
Målgruppe: Anleggseier + produktleverandør]:::tr
    P2 --> S4[62443-2-4
Security Program Requirements
for IACS Service Providers
2023-utgave
Målgruppe: Tjenesteleverandør]:::sp
    P2 --> S5[62443-2-5
Implementation Guidance
for IACS Asset Owners
Praktisk håndbok
Målgruppe: Anleggseier]:::ao

En rask orientering før vi går inn i hver i detalj. To av disse — 2-1 og 2-4 — er fulle normative standarder: de inneholder krav som en organisasjon enten oppfyller eller ikke oppfyller, og det finnes eksterne sertifiseringsordninger (mer om disse nedenfor) som kan verifisere påstanden. Én av dem — 2-3 — er en teknisk rapport, ikke en standard, som betyr at det er veiledning heller enn reviderbare krav; det er fortsatt viktig, men terskelen for «samsvar» er annerledes. Én — 2-5 — er implementeringsveiledning: den forteller deg hvordan du skal gjøre det 2-1 sier du må gjøre. Og én — 2-2 — er en relativt nylig tilføyelse som gir en måte å måle hvor godt sikkerhetsprogrammet ditt faktisk er når du har bygget det. Sammen utgjør de et sammenhengende forvaltningssystem-rammeverk.

IEC 62443-2-1: anleggseiers sikkerhetsprogram

IEC 62443-2-1, formelt med tittelen «Security program requirements for IACS asset owners», er hjørnesteinen i Del 2 og uten tvil hjørnesteinen i anleggseiers hele IEC 62443-forpliktelse. Standarden ble først utgitt i 2010 og ble vesentlig omskrevet i august 2024 som en andre utgave — en oppdatering som materielt endret strukturen på kravene og bringer standarden nærmere hvordan organisasjoner faktisk driver sikkerhetsprogrammene sine i dag.

Hva den faktisk er

Med klart språk definerer 2-1 hva en anleggseiers industrielle cybersikkerhetsprogram må inneholde for å bli ansett som godt drevet. Standarden spesifiserer ikke hvordan selve IACS-en må bygges — det er jobben til 3-3 — men heller hvilke retningslinjer, prosedyrer, prosesser, opplæringsordninger, styringsstrukturer og kontinuerlige forbedringsmekanismer anleggseieren må ha pakket rundt IACS-en slik at den forblir sikker i drift. Den nærmeste analogen fra IT-verdenen er ISO/IEC 27001s Information Security Management System (ISMS), og 2024-utgaven av 2-1 gjør denne analogien eksplisitt ved bevisst å avduplisere kravene mot ISO 27001 slik at en organisasjon som allerede har et ISMS ikke trenger å gjøre alt dobbelt.

For å returnere til sykehus-analogien er 2-1 det kliniske styringsrammeverket — det dokumenterte systemet som sier hvordan sykehuset ledes, hvordan kliniske beslutninger tas og gjennomgås, hvordan personalet opplæres og kredensieres, hvordan hendelser rapporteres og undersøkes, hvordan pasientsikkerhet overvåkes, hvordan risikoer spores, hvordan retningslinjer holdes aktuelle, og hvordan hele apparatet kontinuerlig forbedres. Et sykehus med solid klinisk styring kan levere trygg behandling år etter år; et sykehus uten den er én dårlig dag unna en CQC-merknad (Care Quality Commission).

Security Program Elements

2024-utgaven av 2-1 organiserer kravene sine i Security Program Elements (SPEs) heller enn den løsere kapittelstrukturen i 2010-utgaven. Hvert SPE er en sammenhengende gruppering av krav som adresserer en bestemt dimensjon av sikkerhetsprogrammet. De spesifikke elementnavnene og antallene i den publiserte standarden dekker den organisatoriske og styringsmessige dimensjonen, konfigurasjonsstyring, nettverkskommunikasjon, databeskyttelse, brukertilgangskontroll, hendelses- og hendelsesstyring, forretningskontinuitet, systemvedlikehold og andre operasjonelle disipliner kjent fra bredere forvaltningssystem-praksis. Hovedkategoriene en anleggseier må adressere kan visualiseres slik:

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef elem fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;

    SP[IACS sikkerhetsprogram
per IEC 62443-2-1:2024]:::entry

    SP --> E1[Organisasjon
styring, roller,
opplæring, bevissthet,
fysisk sikkerhet]:::elem
    SP --> E2[Konfigurasjonsstyring
aktiva-oversikt,
baselines, endringskontroll]:::elem
    SP --> E3[Nettverkskommunikasjon
segmentering, kanaler,
fjerntilgang]:::elem
    SP --> E4[Datasikkerhet
beskyttelse av data
i hvile og bevegelse,
nøkkelstyring]:::elem
    SP --> E5[Brukertilgangs-
kontroll
identifikasjon,
autentisering,
autorisering]:::elem
    SP --> E6[Hendelses-
styring
deteksjon, respons,
gjenoppretting, lærdom]:::elem
    SP --> E7[Systemvedlikehold
oppdateringsstyring,
backup, integritet]:::elem
    SP --> E8[Forretningskontinuitet
tilgjengelighet,
katastrofegjenoppretting,
kontingens]:::elem
    SP --> E9[Leverandør- og
tjenesteleverandør-
styring
kobling til 2-4 og 4-1]:::elem
    SP --> E10[Samsvar og
revisjon
internrevisjon,
ledelsesgjennomgang,
kontinuerlig forbedring]:::elem

Det avgjørende konseptuelle grepet i 2024-utgaven er introduksjonen av en modenhetsmodell for å evaluere disse elementene. Den ekkoer strukturen brukt i IEC 62443-4-1 for OEM-utviklingsprosesser, og 2-1-modenhetsmodellen lar en anleggseier vurderes ikke bare på om de har en retningslinje på plass, men på hvor konsekvent og effektivt de anvender den på tvers av organisasjonen. En retningslinje som eksisterer på papir, men som følges ujevnt, er på et lavere modenhetsnivå enn den samme retningslinjen påviselig håndhevet på tvers av alle steder med revisjonsbevis. Modenhetsmodellen gjør standarden mye mer nyttig som et eksternt vurderingsinstrument enn 2010-utgaven var, fordi den gir vurderere en forsvarlig skala å score mot heller enn en binær «har eller har ikke».

En annen viktig endring er hva 2-1 bevisst ikke prøver å gjøre. 2024-utgaven erkjenner at mange anleggseiere allerede driver et ISO 27001 ISMS, og heller enn å duplisere retningslinje- og prosedyre-stilaset til et ISMS, deferer den eksplisitt til ISO 27001 for det generiske informasjonssikkerhetsforvaltningsapparatet og fokuserer 2-1s krav på de IACS-spesifikke tilleggene som et ISMS ikke naturlig dekker. I praksis betyr dette at en anleggseier med et modent ISMS kan bruke 2-1 som et fokusert gap-analyseverktøy heller enn et erstatningsrammeverk, som er en betydelig innsatsbesparelse og en betydelig forbedring i klarhet.

Hva anleggseieren må bevise objektivt

En forsvarlig påstand om samsvar med IEC 62443-2-1 ser ut som en sammenhengende bevispakke som dekker hvert av Security Programme Elements på et oppgitt modenhetsnivå, med sporbarhet til operasjonell praksis. Konkret betyr dette en dokumentert IACS-sikkerhetspolitikk godkjent på passende nivå i organisasjonen, en aktuell aktiva-oversikt over IACS-systemene i omfanget, et risikoregister som lenker til CRS-en produsert under 3-2 , opplæringsregistreringer for menneskene som designer, drifter og vedlikeholder IACS-en, revisjonsrapporter som demonstrerer at retningslinjer følges i praksis, en dokumentert hendelsesstyringsprosess med en reell historie av hendelser håndtert (eller en klar oversikt over overvåking med ingenting vesentlig å håndtere), en dokumentert endringsstyringsprosess som styrer hvordan tillegg og modifikasjoner til IACS-en godkjennes, og en ledelsesgjennomgangs-protokoll som viser at seniorledelse periodisk gjennomgår programmets effektivitet og autoriserer forbedringer.

Det finnes nå en fremvoksende tredjeparts-sertifiseringsrute for anleggseier-programmer: ISASecure ACSSA (Automation and Control System Security Assurance), kunngjort i 2023 og ment å dekke en operasjonell IACS på anleggseiers sted mot IEC 62443-2-1, 2-3 og de relevante delene av 3-3. ACSSA er nyere og mindre utbredt enn dens komponent-sides søsken (SDLA og CSA), men for anleggseiere i regulerte sektorer vil det sannsynligvis bli en stadig vanligere måte å bevise en 2-1-påstand. Der ACSSA ikke er i spill, er bevispakke-ruten — internrevisjonsrapporter, eksterne vurderingsrapporter fra anerkjente konsulenter, integrasjon med ISO 27001-overvåkingsrevisjoner — standardvalget. I begge tilfeller er nøkkelprinsippet det samme: en 2-1-påstand er bare så sterk som beviset bak den, og beviset må være aktuelt, organisasjonsomfattende og konsistent med hva en utenforstående faktisk ville finne hvis de tilbrakte en dag med å gå rundt på anlegget.

IEC 62443-2-2: vurdere hvor god programmet faktisk er

Hvis 2-1 forteller anleggseieren hva sikkerhetsprogrammet deres må inneholde, så adresserer IEC 62443-2-2 det relaterte men distinkte spørsmålet: hvordan vurderer vi hvor godt programmet faktisk fungerer? Den definerer en metodikk for å produsere en Security Programme Rating — en strukturert, forsvarlig scoring av en operasjonell IACS mot kravene i standardfamilien.

Motivasjonen for dette er praktisk. En anleggseier kan dokumentere et vakkert sikkerhetsprogram på papir som svikter i drift; en annen kan ha et mindre elegant program som følges rigorøst og er ekte effektivt. Å bare se på dokumentasjonen kan ikke skille dem. 2-2 introduserer en strukturert måte å evaluere operasjonell virkelighet — hva som faktisk er konfigurert på nettverket, hva som faktisk logges og overvåkes, hva som faktisk oppdateres, hva som faktisk testes — og å produsere en rating som er sammenlignbar på tvers av steder, på tvers av forretningsenheter og over tid.

Sykehus-analogien her er CQC-vurderingen (Care Quality Commission) kjent for alle som har hatt å gjøre med britisk helsetjeneste. Et sykehus vurderes som Outstanding, Good, Requires Improvement eller Inadequate basert på en strukturert vurdering mot publiserte kriterier. Vurderingen er sammenlignbar på tvers av sykehus, forsvarlig overfor regulatorer og pasienter, og nyttig internt for å prioritere forbedringsarbeid. 2-2 spiller en lignende rolle for et industrisikkerhetsprogram: den produserer en vurdering som har mening utover den umiddelbare revisjonen, med kriterier som enhver informert vurderer kan reanvende.

Vurderingen er ment å brukes på flere måter. Internt hjelper den seniorledelse med å sammenligne steder mot hverandre og mot selskapets egen historiske ytelse. Eksternt gir den en måte å underbygge cybersikkerhetspåstander overfor regulatorer, forsikringsselskaper og kunder uten å måtte publisere sensitiv intern dokumentasjon. I en anskaffelses- eller M&A-kontekst gir den et forsvarlig mål på cybersikkerhetsstilling som er uavhengig av noen enkeltleverandørs produkt. Og i den fremvoksende ACSSA-sertifiseringsordningen er en 2-2-aktig vurdering implisitt i vurderingsmetodikken.

Hva en anleggseier må demonstrere for å hevde en 2-2-avledet vurdering er i hovedsak selve vurderingen, metodikken den ble produsert med, beviset vurdert, og vurderens kompetanse. Som med 2-1 er en selv-erklært vurdering mye svakere enn en produsert av en anerkjent ekstern vurderer, og vurderingens verdi avhenger kritisk av at vurderen følger metodikken trofast — det samme poenget som gjøres om enhver sertifisering: sertifikatets troverdighet er sertifisørens troverdighet.

IEC TR 62443-2-3: å holde systemet aktuelt

IEC TR 62443-2-3 er oppdateringsstyrings-medlemmet av familien. «TR»-prefikset betyr noe: dette er en teknisk rapport heller enn en internasjonal standard. Skillet er konsekvensrikt. En teknisk rapport er informativ — den inneholder veiledning, anbefalinger og god praksis heller enn reviderbare krav. Du kan strengt tatt ikke være «ikke i samsvar med 2-3» på den måten du kan være ikke i samsvar med 2-1, fordi 2-3 ikke inneholder «skal»-klausuler å vurderes mot. Men den praktiske viktigheten av 2-3 er enorm, fordi oppdateringsstyring i en industriell kontekst er genuint vanskelig, og fraværet av et sammenhengende oppdateringsprogram er den vanligste enkelt-svakheten i en ellers godt drevet IACS.

Sykehus-analogien her er prosedyren for vedlikehold av medisinsk utstyr og håndtering av tilbakekallinger. Sykehusutstyr har produsent-vedlikeholdsplaner, periodiske tilbakekallinger, programvareoppdateringer og sikkerhetsvarsler. Noen av disse kan anvendes umiddelbart; noen krever at utstyret tas ut av drift, som har kliniske konsekvenser; noen krever omopplæring av personale; og noen — for veldig gammelt utstyr — må kanskje anvendes via kompenserende tiltak fordi produsenten har sluttet å utstede oppdateringer. Et sykehus som ignorerer tilbakekallinger er farlig; et sykehus som blindt anvender hver oppdatering uten testing i sin kliniske kontekst er også farlig. Disiplinen i å gjøre dette skikkelig er det 2-3 kodifiserer for det industrielle cybersikkerhets-ekvivalentet.

Hovedbidraget i 2-3 er en strukturert oversikt over hva et reelt IACS-oppdateringsstyringsprogram må adressere: de asymmetriske ansvarsforholdene mellom produktleverandøren (som må produsere oppdateringer, validere dem på sine produkter, og kommunisere dem i en brukbar form til sine kunder) og anleggseieren (som må konsumere den informasjonen, vurdere relevans i sin spesifikke driftskontekst, teste oppdateringer i et representativt miljø, planlegge anvendelse under vedlikeholdsvinduer, og verifisere at det oppdaterte systemet fortsetter å fungere riktig). 2-3 introduserer også standardiserte datastrukturer for å levere oppdateringsinformasjon — VPatch-konseptet er det mest omtalte eksempelet — slik at anleggseiere ikke trenger å oversette mellom hver produktleverandørs idiosynkratiske oppdateringsvarslingsformat.

For anleggseieren betyr det å demonstrere en troverdig oppdateringsstyringspraksis å vise et dokumentert program som dekker hver komponent i IACS-oversikten (inkludert, viktig, den lange halen av små innebygde enheter som er lett å overse), en prosess for å motta og triagere leverandørråd, en testet tilnærming for risikovurdering av hvert råd i den operasjonelle konteksten (fordi ikke hver CVE er like relevant for hver utplassering), bevis på oppdateringsanvendelse under planlagte vinduer med verifisering av systemoppførsel etter oppdatering, og en sammenhengende tilnærming for komponenter hvis leverandører ikke lenger utsteder oppdateringer — typisk gjennom kompenserende kontroller på nettverks- eller operasjonelt nivå.

For produktleverandøren går demonstrasjonen den andre veien. Leverandøren må vise at de produserer oppdateringer rettidig for sårbarheter som påvirker produktene deres, at de kommuniserer disse oppdateringene i en brukbar form, at oppdateringene har blitt testet i representative konfigurasjoner av produktet, og at de støtter anleggseiers testing gjennom klare utgivelsesnotater, regresjonstest-veiledning og tilbakeruller-prosedyrer. OEM-siden av 2-3 kobler naturlig til forpliktelsene i 4-1s Praksis 7 (Security Update Management) og til EU Cyber Resilience Acts sårbarhetshåndteringskrav , så for produktleverandører som opererer i regulerte markeder blir disse forpliktelsene i økende grad bakt inn i produkt-roadmap-disiplin heller enn behandlet som et valgfritt ekstra.

IEC 62443-2-4: tjenesteleverandørens sikkerhetsprogram

Hvis 2-1 styrer anleggseiers hus, styrer IEC 62443-2-4 oppførselen til alle som kommer på anleggseiers sted for å designe, integrere, vedlikeholde eller drifte IACS-en. Standarden har tittelen «Security program requirements for IACS service providers», og dens nåværende utgave er 2023-andre-utgaven. «Tjenesteleverandøren» i 2-4 dekker et bredt spekter av organisasjoner: systemintegratorer (som designer og bygger det integrerte systemet per anleggseiers CRS), automasjonsentreprenører, vedlikeholdsentreprenører, managed-service-leverandører, sikkerhetstjenesteleverandører som kjører overvåking eller hendelsesrespons på vegne av anleggseier, og enhver organisasjon hvis folk har hender på anleggseiers IACS.

Sykehus-analogien her er medisinsk-bemanningsbyråets akkrediterings- og revisjonsregime. Et sykehus som tillater byråsykepleiere å arbeide på sine avdelinger må vite at byrået sjekker personalet sitt, opplærer dem, vedlikeholder deres profesjonelle registreringer, reviderer ytelsen deres, og selv er underlagt inspeksjon. Et sykehus som tar imot byråpersonale uten verifisering av noen av disse tingene er eksponert for klinisk risiko som ikke har noe å gjøre med hvor godt selve sykehuset er drevet. 2-4 spiller den samme rollen for tjenesteleverandører i det industrielle sikkerhetsrommet: den forteller anleggseieren hva som skal kreves av enhver som arbeider på deres IACS, og den forteller tjenesteleverandøren hva de må demonstrere for å være akseptable.

Strukturen i 2-4

2-4 organiserer kravene sine i Functional Areas — sammenhengende grupperinger av kapabiliteter en tjenesteleverandør må demonstrere. De viktigste Functional Areas som typisk refereres i litteraturen om standarden inkluderer følgende.

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef fa fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;

    SP[IACS tjenesteleverandør
sikkerhetsprogram
per IEC 62443-2-4:2023]:::entry

    SP --> F1[Bemanning av løsning
vurdert, opplært, kompetent
personale]:::fa
    SP --> F2[Forsikring
prosesser og revisjon
av tjenestekvalitet]:::fa
    SP --> F3[Arkitektur
sikker design og
integrasjonspraksis]:::fa
    SP --> F4[Trådløst
sikker håndtering av
trådløse teknologier]:::fa
    SP --> F5[Safety Instrumented
Systems SIS
spesifikke disipliner
for sikkerhetssystemer]:::fa
    SP --> F6[Konfigurasjonsstyring
baselines, endringskontroll,
versjonshåndtering]:::fa
    SP --> F7[Fjerntilgang
sikre verktøy og
tilgangskontroller]:::fa
    SP --> F8[Hendelsesstyring
loggning, overvåking,
hendelsesrespons]:::fa
    SP --> F9[Kontostyring
identiteter, privilegier,
legitimasjon]:::fa
    SP --> F10[Malware-beskyttelse
forebygging, deteksjon,
respons]:::fa
    SP --> F11[Oppdateringsstyring
levering, testing,
anvendelse]:::fa
    SP --> F12[Backup og gjenoppretting
data- og konfigurasjons-
bevaring]:::fa

Det eksakte antallet og merkingen av Functional Areas varierer noe mellom utgaver av standarden og mellom ulike organisasjoners sammendrag av den, men det substansielle innholdet er bredt sett stabilt: en tjenesteleverandør må ha påviselig kapabilitet på tvers av menneske-, prosess- og tekniske dimensjoner av hver aktivitet de utfører på anleggseiers IACS.

Som 4-1 for OEM-er, inkorporerer 2-4 en modenhetsnivå-dimensjon. En tjenesteleverandør kan vurderes på Maturity Level 1 (praksisen eksisterer, men er ad hoc), Level 2 (dokumentert og gjentakbar), Level 3 (konsekvent praktisert på tvers av organisasjonen med bevis), eller Level 4 (kontinuerlig målt og forbedret). En anleggseier som spesifiserer 2-4-samsvar i kontrakten sin bør spesifisere modenhetsnivået de krever, akkurat som de ville spesifisert en SL-T i 3-2.

Hva tjenesteleverandøren må bevise objektivt

Demonstrasjon her er veldefinert fordi det finnes en etablert tredjeparts-sertifiseringsordning. IECEE CB-ordningen for industriell cybersikkerhet utsteder sertifikater mot IEC 62443-2-4 gjennom akkrediterte sertifiseringsorganer, og disse sertifikatene er gjensidig anerkjent på tvers av IECEE-medlemsøkonomier. ISASecure har også drevet relevante ordninger i dette rommet på ulike tidspunkter. En tjenesteleverandør som hevder 2-4-samsvar bør kunne produsere et aktuelt tredjepartssertifikat som navngir versjonen av standarden, modenhetsnivået oppnådd per Functional Area (eller et enkelt globalt ML der det hevdes), sertifiseringsorganet, utstedelsesdatoen og utløpsdatoen — typisk tre år med overvåkingsrevisjoner i mellom.

Utover selve sertifikatet bør anleggseieren forvente at tjenesteleverandøren kan produsere det substansielle beviset som ligger til grunn for sertifikatet: opplæringsregistreringer og kompetansevurderinger for personalet som faktisk vil bli utplassert til anleggseiers sted, dokumenterte prosedyrer som dekker fjerntilgang, endringskontroll, hendelseshåndtering, oppdateringsutplassering og konfigurasjonsstyring, bevis på internrevisjon og ledelsesgjennomgang av disse prosedyrene, og en sikkerhetshendelses-håndteringskapabilitet med en track record. Som med 4-1 betyr omfanget av sertifikatet like mye som overskriftsvurderingen: et 2-4-sertifikat som dekker en bestemt forretningsenhet, en bestemt geografi eller en bestemt tjenestelinje forteller deg om det omfanget, ikke om hele organisasjonen. Å lese omfangserklæringen nøye er det enkelt viktigste verifiseringssteget.

Der en tjenesteleverandør ikke innehar et tredjeparts 2-4-sertifikat, men hevder samsvar med standarden, bør anleggseieren be om gap-analysen som støtter påstanden, korrigerende tiltak tatt, og eventuelle internrevisjonsbevis. Selv-erklært samsvar er ikke ingenting — det kan være et springbrett — men det bærer ikke samme tyngde som en sertifisert posisjon, og anleggseieren bør gjøre en klar beslutning om de aksepterer det for den type arbeid som kontraheres.

IEC 62443-2-5: den praktiske håndboken

Det siste medlemmet av Del 2-familien, IEC 62443-2-5, gir implementeringsveiledning for anleggseieren. Der 2-1 sier hva en anleggseier må ha i sikkerhetsprogrammet sitt, gir 2-5 råd om hvordan man faktisk gjør det. Det er en praktisk håndbok heller enn et kravdokument, og verdien dens ligger i de bearbeidede eksemplene, malene, organisatoriske mønstrene og pragmatiske rådene den tilbyr anleggseiere som er i starten av å bygge eller modernisere sikkerhetsprogrammet sitt.

Fordi 2-5 er veiledning, genererer den ikke et «samsvars»-spørsmål på samme måte som 2-1 og 2-4. Det finnes ingen sertifisering for å være «i samsvar med 2-5»; det finnes kun spørsmålet om en anleggseier har brukt den (og lignende veiledning fra ISA, ENISA, NIST og sektor-organer) for å informere implementeringsvalgene sine. For anleggseiere som bygger programmet sitt fra bunnen, er 2-5 et fornuftig utgangspunkt. For anleggseiere som allerede er lenger på vei, er den en nyttig sanity-sjekk.

Jeg vil ikke bruke lang tid på 2-5 fordi de substansielle forpliktelsene alle lever i dokumentene over. Men for fullstendighetens skyld bør alle som jobber seriøst med 2-1 være klar over at 2-5 eksisterer og bruke den.

Hvordan 2-x passer med resten av standardene

Det er verdt å trekke seg tilbake på dette punktet og se på hvordan Del 2 sitter ved siden av standardene dekket i de forrige artiklene. Diagrammet nedenfor viser de fire hovedpartene og standardene som styrer hver av dem, med artefaktene og sertifiseringene som flyter mellom.

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;
    classDef art2 fill:#f0e4ff,stroke:#6f42c1,color:#3a1a6b,stroke-width:1px;

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

    AO --> AO1[IEC 62443-2-1
Sikkerhetsprogram]:::art2
    AO --> AO2[IEC 62443-3-2
Risikovurdering, CRS, SL-T]:::art
    AO --> AO3[IEC 62443-2-3
Oppdateringsprogram
forbrukersiden]:::art2

    SI --> SI1[IEC 62443-2-4
Tjenesteleverandør-program]:::art2
    SI --> SI2[IEC 62443-3-3
Levert system
oppnår SL-A]:::art

    PS --> PS1[IEC 62443-4-1
SDL]:::art
    PS --> PS2[IEC 62443-4-2
Komponenter SL-C]:::art
    PS --> PS3[IEC 62443-2-3
Oppdateringsinformasjon
leverandørsiden]:::art2

    AO -.Eventuelt sertifisert.- ACSSA[ISASecure ACSSA
eller tilsvarende]
    SI -.Sertifisert til.- IECEE[IECEE CB Scheme
mot 2-4]
    PS -.Sertifisert til.- ISASec[ISASecure SDLA + CSA]

Bildet er nå komplett. Hver part har teknisk-side-standarder (3-x og 4-x delene dekket i de forrige artiklene) og forvaltningssystem-side-standarder (2-x-delene dekket her). Hver part har minst én rute til tredjeparts-sertifisering av sitt respektive omfang. Og hvert grensesnitt mellom parter styres av en definert artefakt: CRS-en flyter fra anleggseier til integrator, SL-C-vektorene og oppdateringsinformasjonen flyter fra produktleverandør til integrator og anleggseier, det leverte systemet med sporbarhet flyter fra integrator til anleggseier, og operasjonelle praksiser på anleggseiers sted styres av anleggseiers 2-1-program med tjenesteleverandører regulert av 2-4.

En nyttig diagnostikk når man ser på et reelt industristed er å gå gjennom hvert grensesnitt i dette bildet og spørre om den tilsvarende artefakten eksisterer, om den er aktuell, og om den blir handlet på. Der noe grensesnitt mangler sin definerte artefakt, er det grensesnittet et kjedeledd uten ledd.

Vanlige fallgruver og røde flagg

Den hyppigste fallgruven i 2-1-arbeid er å behandle det som en dokumentasjonsøvelse. En organisasjon skriver retningslinjene, arkiverer dem i et dokumenthåndteringssystem og anser seg selv som «i samsvar» med 2-1. 2024-utgavens modenhetsmodell er spesielt designet for å motvirke denne fellen — en retningslinje som er skrevet, men ujevnt anvendt, scorer på et lavt modenhetsnivå, og en ekstern vurderer som arbeider mot standarden vil finne det ut. Det mest nyttige spørsmålet å stille av enhver 2-1-påstand er «vis meg revisjonssporet av retningslinjen i drift på tvers av alle steder de siste tolv månedene», fordi det er det som skiller en Maturity Level 1-organisasjon fra en Maturity Level 3-organisasjon.

En annen fallgruve er å konflatere 2-1 med ISO 27001. De to standardene overlapper, men er ikke erstatninger. ISO 27001 styrer informasjonssikkerhet generisk; 2-1 adresserer spesifikt IACS-konteksten, inkludert de lange levetidene, legacy-komponentene, sikkerhetsinteraksjonene og operasjonelle virkelighetene som ISO 27001 ikke naturlig dekker. 2024-utgaven av 2-1 deferer bevisst til ISO 27001 for det generiske ISMS-laget, så en organisasjon med et ISMS bør ikke duplisere det stilaset, men de må legge til det IACS-spesifikke laget som 2-1 krever. En påstand om «vi er ISO 27001-sertifisert, så vi samsvarer med 2-1» er ikke, i seg selv, korrekt.

En tredje fallgruve påvirker tjenesteleverandører og deres anleggseier-kunder: 2-4-sertifikater med smalt omfang. Et stort ingeniørselskap kan ha et 2-4-sertifikat som dekker for eksempel deres automasjons-forretningsenhet i ett land, mens selskapets markedsføringsmateriale antyder at hele organisasjonen er sertifisert. Omfangserklæringen på sertifikatet er sannheten. Når man engasjerer en tjenesteleverandør, bør anleggseieren be om en kopi av sertifikatet og lese omfanget for å verifisere at det faktiske teamet som skal utplasseres er innenfor det. Der det utplasserte teamet er fra en søsterorganisasjon eller et nylig oppkjøpt selskap, dekker omfanget kanskje ikke dem.

En fjerde fallgruve er forvirring mellom 4-1 og 2-4. En produktleverandør kan ha et SDLA-sertifikat mot 4-1 (som dekker deres produktutviklingsprosess), men ikke et 2-4-sertifikat (som ville dekke deres tjenesteleveranse-praksis). De to adresserer ulike omfang og ulike aktiviteter, og det ene er ikke en erstatning for det andre. En organisasjon som både produserer produkter og leverer tjenester på anleggseiers sted trenger begge sertifikatene.

En femte fallgruve er IT-oppdateringsstyringspraksis anvendt umodifisert på OT. IT-verdenen har veletablerte mønstre for oppdateringsutplassering — typisk raskt, automatisert, hyppig anvendt — som oversettes dårlig til industrielle miljøer hvor oppdateringer må testes i representative konfigurasjoner, planlegges rundt produksjonsvinduer, og verifiseres for innvirkning på sanntids- og sikkerhetsoppførsler. En anleggseier hvis IACS-oppdateringsprogram drives av en IT-avdeling med IT-mønstre er i høy risiko for enten å anvende oppdateringer uten skikkelig validering eller, oftere, å anvende ingenting fordi IT-mønsteret ikke kan tilpasses. Disiplinen i TR 62443-2-3 eksisterer nøyaktig fordi OT-oppdateringsstyring er sin egen disiplin.

En sjette fallgruve, og en spesielt lumsk en, er at legacy-systemer stille ekskluderes fra sikkerhetsprogrammet. 2024-utgaven av 2-1 erkjenner eksplisitt at legacy-systemer uten produsentstøtte ikke kan oppfylle alle kravene direkte, og at kompenserende tiltak er det riktige svaret. Fallgruven er når legacy-systemer ekskluderes fra oversikten helt og stille aldres ut av enhver aktiv styring. Det riktige svaret er å beholde dem i programmet med deres kompenserende tiltak dokumentert og gjennomgått, ikke å droppe dem fra aktiva-registeret og håpe.

En sjekkliste for anskaffelse, revisjon og egenvurdering

Det følgende kan brukes som et kontraktsvedlegg, et internrevisjonsinstrument eller et egenvurderingsverktøy. Det er organisert etter parten som demonstrerer samsvar.

For anleggseiers egen 2-1 bevispakke

En aktuell, styre-godkjent IACS cybersikkerhetspolitikk som refererer IEC 62443-2-1 (2024-utgaven) og identifiserer SP-elementene som dekkes.
En dokumentert IACS aktiva-oversikt som dekker alle systemer i omfanget, inkludert legacy-systemer med deres kompenserende tiltak eksplisitt notert.
Et risikoregister koblet til CRS-en produsert under 62443-3-2 , med regelmessig gjennomgangskadens dokumentert.
Opplæringsregistreringer for personale med IACS-ansvar, inkludert oppfriskningssykluser og kompetansevurderinger.
Dokumenterte prosedyrer for endringskontroll, hendelsesrespons, oppdateringsstyring (per 62443-2-3), backup og gjenoppretting, og tilgangsstyring — med driftsbevis.
En aktuell egenvurdering eller ekstern vurdering av modenhetsnivå per SP-element, med prioriterte forbedringstiltak.
Internrevisjonsrapporter som dekker hvert SP-element med bevis på lukkede korrigerende tiltak.
Ledelsesgjennomgangsprotokoller som demonstrerer seniorledelses-engasjement med en definert kadens (typisk årlig).
Der det er aktuelt, et aktuelt ISASecure ACSSA-sertifikat eller tilsvarende tredjepartsvurdering, med omfangserklæringen gjennomgått mot det faktiske operasjonelle fotavtrykket.

For anleggseiers evaluering av en tjenesteleverandørs 2-4-påstand

Et aktuelt IECEE CB Scheme-sertifikat (eller tilsvarende) mot IEC 62443-2-4:2023, med utstedende organ, utstedelsesdato og utløpsdato tydelig oppgitt.
En omfangserklæring på sertifikatet som eksplisitt dekker forretningsenheten, geografien og tjenestetypen relevant for kontrakten.
En uttalelse om modenhetsnivået oppnådd per Functional Area (eller et enkelt globalt ML der det hevdes).
Opplærings- og kompetanseregistreringer for det spesifikke personalet foreslått for utplassering til anleggseiers sted.
Dokumenterte prosedyrer for aktivitetene tjenesteleverandøren vil utføre på anleggseiers IACS, med kobling til de sertifiserte Functional Areas.
Bevis på tidligere ytelse på lignende oppdrag med referansekunder.
En definert prosess for å håndtere hendelser som kan oppstå under oppdraget, med eskaleringsruter inn i anleggseiers egen hendelsesstyringsprosess under 2-1.

For anleggseiers evaluering av en produktleverandørs 2-3-bidrag

Et dokumentert sårbarhets-avslørings- og rådgiver-program med en track record av utstedte rådgivere.
Et definert oppdateringsleveringsformat (ideelt på linje med VPatch eller lignende maskinlesbart format) og en indikasjon på den typiske ledetiden fra sårbarhetsavsløring til oppdateringstilgjengelighet.
Utgivelsesnotater og testveiledning som følger hver oppdatering, tilstrekkelig til å støtte anleggseiers egen testing.
En definert støttelevetid per produkt med en klar slutt-på-støtte-dato, etter som anleggseieren må stole på kompenserende tiltak.
Der det er aktuelt, påviselig kobling til leverandørens 4-1 SDLA-sertifisering (den underliggende sikre utviklingsprosessen) og 4-2 CSA-sertifisering (komponentene i omfang).

For anleggseiers evaluering av sitt eget 2-3 oppdateringsprogram

En aktuell aktiva-oversikt som dekker hver komponent i IACS-en, med leverandør-rådgiverkanaler abonnert for hver.
En dokumentert triage-prosess for innkommende rådgivere med risikobasert prioritering.
Et testmiljø representativt nok til å validere oppdateringer før produksjonsutplassering.
En planlagt oppdateringsutplassering-syklus på linje med produksjons-vedlikeholdsvinduer, med verifisering av systemoppførsel etter oppdatering.
En dokumentert tilnærming for ikke-oppdaterbare komponenter, med kompenserende kontroller implementert og gjennomgått.
Målepunkter som demonstrerer programmets faktiske ytelse — typisk tid-til-oppdatering etter kritikalitet, andel av rådgivere anvendt versus utsatt med begrunnelse, og trender over tid.

Der 3-x - og 4-x -standardene adresserer hva i en IACS — hva systemet må gjøre, hva komponentene må støtte, hva designet må oppnå — adresserer 2-x-standardene hvordan den drives dag for dag, år etter år, gjennom det lange driftslivet til et industrianlegg. IEC 62443-2-1 styrer anleggseiers sikkerhetsprogram og er hjørnesteinen av familien på den operasjonelle siden. IEC 62443-2-2 gir en måte å vurdere hvor godt det programmet faktisk fungerer. IEC TR 62443-2-3 kodifiserer disiplinen i oppdateringsstyring for både anleggseiere og produktleverandører. IEC 62443-2-4 styrer tjenesteleverandørene som gjør arbeid på anleggseiers sted. IEC 62443-2-5 tilbyr praktisk implementeringsveiledning for å støtte 2-1.

Den enkelt viktigste mentale modellen å ta med seg fra denne artikkelen er at hver part har både en teknisk-side-forpliktelse og en forvaltningssystem-side-forpliktelse under IEC 62443, og at forsvarlig cybersikkerhet avhenger av at begge er på plass. En produktleverandør med en strålende SDL (4-1) men en kaotisk oppdaterings-rådgiverpraksis (2-3) er en halv leverandør; en systemintegrator med utmerket teknisk kapabilitet mot 3-3 men uten et sertifisert tjenesteprogram under 2-4 er en halv integrator; en anleggseier med en omhyggelig 3-2-risikovurdering, men uten et operasjonelt sikkerhetsprogram under 2-1 har bygget en bygning uten vaktmester.

Beviskjeden på tvers av hele IEC 62443 holder kun når hver part kan demonstrere sin del — med aktuelle sertifikater der de finnes, med substansielt bevis bak dem, og med en kultur av operasjonell disiplin som holder sertifikatene meningsfulle mellom revisjoner. Standardfamilien gir deg rammeverket. Det den ikke kan gi deg er viljen til faktisk å drive ting på den måten.