IEC 62443-bevismappe: enkeltsides versjon

Tenk deg en Trinn 2-revisjon på en 120 MW solpark. Tre minutter inn spør revisor det stille spørsmålet høyt: «Det er interessant — vis meg nå beviset.» Programlederen åpner en SharePoint-mappe merket 62443_compliance. Inni ligger elleve PDF-er. Ni er leverandørbrosjyrer med ordene «62443-klar» trykt øverst. Én er et skjermbilde av en CSV. Den ellevte er den signerte kontrakten med EPC-en. Revisor lukker laptopen, smiler høflig, ber om en kaffe, og skriver sytten avvik inn i oppfølgingsbrevet.

Denne teksten finnes for at det ikke skal skje med deg.

TL;DR

Hvis du ikke kan fremlegge et spesifikt dokument på forespørsel, er du ikke faktisk IEC 62443-konform — uansett hva leverandørens glansede brosjyre sier. Dette er enkeltsides bevismappen: en stram, meningssterk sjekkliste over artefaktene en revisor vil be om under hver av de fire nummererte gruppene i standarden (IEC 62443-2-x, -3-x, -4-x), pluss et lite sett tverrgående punkter. Velg pakken som matcher rollen din, skriv den ut, og gå inn i neste prosjekt med den i hånden. Den femspørsmåls selvtesten på slutten er de mest nyttige 100 ordene i teksten.

Hvem dette er for

ISA/IEC 62443-serien definerer fire prinsipielle roller — anleggseier, integrator, tjenesteleverandør og produktleverandør — og hver artefakt under kartlegger til en av dem. Hvis du ikke allerede har lest IEC 62443-1-x fundamentteksten , start der: rolledefinisjonene og livssyklusmodellen for Industrial Automation and Control System (IACS) i IEC TS 62443-1-1:2009 er stillaset alt annet henger fra.

Anleggseiere (operatørene — kraftselskaper, produsenter, anleggseiere): pakken din er -2-1 + -3-2.
Integratorer og tjenesteleverandører (EPC-er, systemintegratorer, vedlikeholdsentreprenører): pakken din er -2-4.
Produktleverandører (PLC-, RTU-, gateway-, HMI-, inverter-, BMS-leverandører): pakken din er -4-1 + -4-2.
Alle skylder de tverrgående artefaktene i avsnitt 5.

En dypere gjennomgang av hver finnes i -2-x styringssystemteksten , -3-2 og -3-3-teksten , og -4-1 og -4-2-teksten . Denne er fuskelappen.

1. Hierarkiet av 62443-bevis

Revisorer — i hvert fall de gode — tenker i tre nivåer. Det bør du også.

Nivå 1: policy- og prosedyredokumenter. Hva du har til hensikt å gjøre. Charter for sikkerhetsprogrammet, risikovurderingsprosedyre, endringshåndteringspolicy. Billigst å produsere, lettest å fingere, svakest som bevis.
Nivå 2: opptak og operasjonelt bevis. Hva du faktisk gjorde. Signerte protokoller, lister over opplæringsoppmøte, billetteksporter, testrapporter, oppdateringslogger, revisjonsfunn med lukkedatoer. Det er her revisjoner vinnes eller tapes.
Nivå 3: uavhengige sertifiseringer. Hva en akkreditert tredjepart verifiserte. ISASecure CSA / SSA / SDLA-sertifikater, IECEE CB-ordningens testrapporter, eller akkrediterte revisjoner mot IEC 62443-2-4 for tjenesteleverandører. Dyrest, vanskeligst å argumentere mot.

Et modent program har alle tre. Et forsvarbart program har minst Nivå 1 og 2 over hele linja, med Nivå 3 plassert under komponentene med høyest risiko. Et «brosjyre-PDF»-program har ingen av disse og flere brosjyrer.

For produktsidens Nivå 3 spesielt driver ISASecure de tre produkt-/prosessordningene som oftest siteres i anbud — CSA mot IEC 62443-4-2, SSA mot IEC 62443-3-3, og SDLA mot IEC 62443-4-1 — alle under ISO/IEC 17065 . IECEE CB-ordningen gir den parallelle internasjonale samsvarsvurderingsruten gjennom IEC 62443 og er den de fleste europeiske kjøpere vil gjenkjenne.

2. Bevismappe for anleggseier — for `IEC 62443-2-1:2024` og `IEC 62443-3-2:2020`

2024-utgaven av IEC 62443-2-1 erstattet det gamle Cyber Security Management System (CSMS)-språket med åtte Security Programme Elements (SPE-er) og la til en modenhetsmodell. Risikometodikken ligger fortsatt i IEC 62443-3-2:2020 , som definerer systemet under vurdering (SuC), sone-og-kanaltegningen, og utledning av Target Security Level (SL-T).

Grupper beviset ditt etter SPE. Hvis en revisor ikke finner noen av følgende på forespørsel, forvent et funn.

#	Artefakt	Hva revisor vil ta stikkprøve på	Rødt flagg
1	Charter / policy-dokument for sikkerhetsprogrammet	Godkjenningssignatur, omfangsuttalelse, gjeldende IACS-anlegg	Mer enn 24 måneder gammelt uten revisjonshistorikk
2	Styre-/ledelsesprotokoll for godkjenning	Godkjenningsdato, navngitt ansvarlig leder	Godkjenneren er samme person som skrev det
3	Risikovurdering etter `IEC 62443-3-2` for hver SuC	SuC-definisjon, trussel-katalog, konsekvensvurdering	Én global risikovurdering brukt på urelaterte anlegg
4	Sone- og kanaldiagram per SuC	Versjonert tegning, aktiva-til-sone-fordeling	Ingen kanalliste, eller kanaler tegnet men ikke listet
5	SL-T-vektorutledning per sone	Per-Foundational-Requirement (FR)-vektor — syv verdier, ikke én	Et enkelt «SL 2»- eller «SL 3»-krav uten FR-oppdeling
6	Risikoregister med restrisiko-aksept	Eier, behandling, restrisikoverdi, signering	Restrisikoer akseptert av samme ingeniør som vurderte dem
7	Baseline for aktivaregister (SPE 2 — `CM 1.1`)	Maskinvare, firmwareversjoner, programvare, nettverksporter	Firmwareversjoner som ikke matcher det som faktisk kjører i felt
8	Konfigurasjonsstyringsbaselinjer	Gullbilde, prosedyre for baselineavvik	Baselinjer som er eldre enn den siste firmwareoppdateringen
9	Internrevisjonsrapporter	Omfang, funn, korrigerende tiltak, lukkedatoer	Ingen internrevisjon i de siste 12 månedene
10	Protokoll fra ledelsesgjennomgang	Inputs gjennomgått, beslutninger tatt, tiltak tildelt	Et møte uten beslutninger registrert
11	Opplæringsregistre (SPE 1)	Rollebasert opplæringsmatrise, fullføringsdatoer per person	Generiske «cyberbevissthet»-sertifikater uten OT-innhold
12	Leverandørregister (med `-2-4`-vurderingsstatus)	Siste vurderingsdato, omfang, mangler	Leverandører listet uten vurderingsdato
13	Hendelsesresponsprosedyre + øvelsesopptak	Tabletop-protokoll, post-mortem etter reelle hendelser	Prosedyren finnes, men ingen øvelse i de siste 18 månedene
14	BCDR-plan + gjenopprettingstestbevis	Siste vellykkede gjenopprettingstest, RTO/RPO oppnådd	«Sikkerhetskopi kjører nattlig» uten gjenopprettingstest registrert
15	Unntaks-/avviksregister	Hvert unntak koblet til en kompenserende kontroll og en utløpsdato	Åpne unntak uten gjennomgangsdato

Mesteparten av artefaktkartet over sitter i SPE-er 1 til 8 — organisatorisk sikkerhet, konfigurasjonsstyring, nettverks- og kommunikasjonsbeskyttelse, komponentbeskyttelse, databeskyttelse, brukertilgangskontroll, hendelses- og hendelseshåndtering, og systemintegritet og -tilgjengelighet. ISA Global Cybersecurity Alliance (ISAGCA) Quick Start Guide er den reneste gratis referansen til SPE-strukturen hvis du ikke har IEC-teksten foran deg.

3. Bevismappe for integrator og tjenesteleverandør — for `IEC 62443-2-4:2023`

IEC 62443-2-4:2023 — utgave 2.0, publisert desember 2023 — definerer sikkerhetskapabilitetene en tjenesteleverandør tilbyr en anleggseier under integrasjon og vedlikehold, organisert i Security Programme (SP)-emner SP.01 til SP.12 (bemanning, assurance, arkitektur, trådløst, konfigurasjonsstyring, herding, anti-skadevare, oppdateringshåndtering, sikkerhetskopi/gjenoppretting, overvåkning, hendelseshåndtering, kontohåndtering, fjerntilgang). 2023-revisjonen konverterte mange tidligere «kapabiliteter» til påkrevde prosesser med dokumenterte utdata — som betyr at bevis nå er ikke-forhandlingsbart.

#	Artefakt	Kartlegger til	Rødt flagg
1	Bemannings- og kompetanseregistre	`SP.01`	Personell listet uten OT-spesifikk opplæring
2	Tjenesteomfangsdokument per kontrakt	`SP.02`	Et boilerplate-omfang gjenbrukt på urelaterte kontrakter
3	Sikker arkitektur-overleveringspakke	`SP.03`	Ingen sone/kanal-overlegg avtalt med anleggseieren
4	Trådløse konfigurasjonsopptak	`SP.04`	Trådløst brukt, men ingen deteksjonsprosess for ulovlige enheter
5	Herdingsbaselinjer anvendt per enhetsklasse	`SP.06`	Baselinjer fra en tidligere firmwaregenerasjon
6	Bevis for anti-skadevare-utrulling	`SP.07`	AV-signaturer sist oppdatert måneder før idriftsettelse
7	Oppdateringshåndteringsopptak	`SP.08`	Oppdateringer godkjent av anleggseieren, men aldri utrullet
8	Sikkerhetskopi- og gjenopprettingstestbevis	`SP.09`	Sikkerhetskopier finnes, gjenoppretting aldri testet på målmaskinvaren
9	Fjerntilgangsprosedyre + sesjonslogger	`SP.11`	Jump-host-logger som ikke registrerer kommandoer eller sesjonsvideo
10	Endringshåndteringsopptak	Tverrgående	Endringer implementert før godkjenningssignaturer

SP.05 (assurance) og SP.12 (hendelseshåndtering) sitter under det over som tverrgående kontroller og bør plukkes opp av den tverrgående pakken i avsnitt 5.

4. Bevismappe for produktleverandør — for `IEC 62443-4-1:2018` og `IEC 62443-4-2:2019`

IEC 62443-4-1:2018 definerer en Secure Development Lifecycle (SDL) bygget rundt åtte praksiser: Security Management (SM), Specification of Security Requirements (SR), Secure by Design (SD), Secure Implementation (SI), Security Verification and Validation Testing (SVV), Management of Security-related Issues (DM), Security Update Management (SUM), og Security Guidelines (SG). IEC 62443-4-2:2019 definerer så de tekniske Component Requirements (CR-ene) per Foundational Requirement, med kapabilitets-sikkerhetsnivå SL-C 1 til SL-C 4.

#	Artefakt	Kartlegger til	Rødt flagg
1	SDL-policy og opplæringsregistre	`SM-1` … `SM-13`	En policy som eksisterer, men ingen utvikler er opplært mot den
2	Trusselmodell per produkt	`SR-2`	Trusselmodell skrevet én gang ved lansering, aldri oppdatert
3	Sporingsmatrise for sikkerhetskrav	`SR-1` … `SR-5`	Krav uten testcase kartlagt
4	Bevis for sikker koding (SAST, DAST)	`SI-1`, `SI-2`	Skannerapporter med kritiske funn merket «akseptert» uten begrunnelse
5	Sikkerhetstestrapport (funksjonell, fuzz, pen-test)	`SVV-1` … `SVV-5`	Ingen bevis for tester-uavhengighet
6	Sårbarhetshåndteringsprosedyre med koordinert-rapporteringskontakt (CVD)	`DM-1` … `DM-6`	Ingen `security@`-postkasse, ingen PSIRT, ingen publisert policy
7	Software Bill of Materials (SBOM) — CycloneDX eller SPDX	`SM-9`, `DM-1`	En SBOM uten versjon, uten hash, uten oppdateringskanal
8	Sikkerhetsretningslinjer / herdingsveiledning for anleggseiere	`SG-1` … `SG-7`	En «brukermanual» med ett avsnitt om sikkerhet
9	Bevis for sikkerhetsoppdateringskanal	`SUM-1` … `SUM-5`	Oppdateringer utgitt, men ingen dokumentert leveringskanal
10	End-of-life (EOL) supportpolicy	`SUM-5`, `SG-7`	EOL-datoer som flyttes stille når det passer

For IEC 62443-4-2:2019, legg til en per-FR testbevispakke som kartlegger hvert CR-krav til et resultat, oppsummert av en akkreditert sertifiseringsorganisasjons rapport. En ryddig måte å gjøre dette på er å vedlegge ISASecure CSA-sertifikatet pluss de underliggende Functional Security Assessment (FSA-C)- og Vulnerability Identification Testing (VIT-C)-rapportene, eller tilsvarende under IECEE CB-ordningen . For utviklingsprosess-sertifisering alene — uten et produktsertifikat — er ISASecure SDLA eller en IECEE IEC 62443-4-1-vurdering tilsvarende. Merk at SDLA-ordningen tillater en leverandør å scope ut individuelle delpraksiser, så les alltid sertifikatets omfangsuttalelse, ikke bare logoen.

5. Tverrgående artefakter

Dette er de som programmer rutinemessig glemmer — og det er de revisorene liker å spørre etter, fordi de avslører om programmet faktisk drives eller bare er skrevet ned.

Risiko-akseptlogg signert av ledelsen. Ikke en prosjektleder. Ikke en «ansvarlig ingeniør». Den ansvarlige lederen som er navngitt i SPE 1-charteret, med en dato og en restrisikoverdi.
Register for kompenserende mottiltak. Der en kontroll ikke kunne implementeres innfødt, navngis det kompenserende tiltaket, begrunnelsen dokumenteres etter IEC TS 62443-1-1:2009-definisjonen, og effektiviteten gjennomgås på en angitt kadens. IEC 62443-2-1:2024 tillater eksplisitt kompenserende kontroller for eldre systemer — men bare hvis de er dokumentert.
Unntaks-/avviksregister. Hvert avvik fra en policy eller baseline, med en eier, en utløpsdato, og en kompenserende kontroll.
SL-T → SL-C → SL-A sporingsmatrise per sone. Anleggseieren utleder SL-T etter -3-2. Produktleverandøren publiserer SL-C etter -4-2. Integratoren leverer SL-A (oppnådd) i den som-bygget-konfigurasjonen. Revisorer elsker denne matrisen fordi gap faller ut av den visuelt.
Versjonskontroll-logg for bevismappen. Selve beviset trenger versjonskontroll. Hvis revisjonsmappen er «levende SharePoint» uten revisjonshistorikk, har beviset ditt ingen integritet.
Tidssynkroniseringsbevis. Ofte glemt. IEC 62443-3-3:2013 SR 2.11 (Timestamps) krever at komponenter gir pålitelige, synkroniserte tidsstempler for revisjonsopptak. Hvis PLC-en, jump-hosten og SIEM-klokken driver, er revisjonssporet ditt ikke juridisk brukbart. NIST SP 800-82 Rev. 3 gjør samme poeng i OT-termer.

6. Hva som IKKE teller som bevis

En kort, meningssterk rødflagg-liste. Ingen av det følgende vil overleve en revisjon alene:

Markedsførings-PDF-er som sier «62443-konform» uten et delnummer. IEC 62443 er en serie, ikke en enkelt standard. «Konform» med hvilket av de tretten-pluss dokumentene? Ved hvilket utgaveår? Mot hvilken SL? Uten det er kravet dekorativt.
Enkeltverdis SL-krav. «Vi er SL 3» er meningsløst. IEC 62443-3-3 og -4-2 uttrykker sikkerhetsnivåer som en syv-elements vektor — én per FR (Identification & Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability). En vektor som SL-C (3,2,3,1,3,2,3) er den riktige formen.
Leverandørsertifikater uten en omfangsuttalelse. ISASecure SDLA-sertifikatet, for eksempel, sier deg bare at prosessen ble vurdert for delpraksisene i omfang — som lovlig kan være et delsett. Les alltid omfangsannekset.
Samsvarsmatriser som ikke er signert, datert eller versjonskontrollert. Et Word-dokument som er redigert av seks personer med spor-endringer av er ikke bevis; det er et rykte.
Testrapporter fra før den siste store firmwareoppdateringen. En penetrasjonstest-rapport mot firmware v4.2 sertifiserer ikke v4.7. Leverandøren skylder en delta-vurdering eller en re-test.

7. Den femspørsmåls pre-revisjons-selvtesten

De mest nyttige 100 ordene i denne teksten. Kjør denne femspørsmåls testen før revisor krysser terskelen din. Hvis du ikke kan svare «ja, her er det» på alle fem, fiks det først.

Kan du fremlegge SL-T-vektoren for hver sone, utledet etter IEC 62443-3-2, signert i løpet av de siste 24 månedene?
Kan du fremlegge et fullstendig aktivaregister der firmwareversjonene matcher det som faktisk er utrullet på anlegget i dag?
Kan du fremlegge et internrevisjonsfunn fra de siste 12 månedene som resulterte i et korrigerende tiltak som nå er formelt lukket?
Kan du fremlegge bevis for at en vedlikeholdsleverandør er vurdert mot IEC 62443-2-4 i den siste kontraktssyklusen?
Kan du fremlegge restrisiko-akseptloggen, signert av relevant ledelsesmedlem, datert og aktuell?

Fem «ja»-svar er ikke samsvar — men fem «nei»-svar er definitivt ikke-samsvar.

8. Hvordan bruke dette som et prosjektverktøy

Tre konkrete bruksområder, i rekkefølge etter hvor ofte hver typisk dukker opp:

På et nytt prosjekt. Velg pakken som matcher rollen du spiller — eier, integrator eller leverandør — og bruk den som en leveranseliste i prosjektplanen. Hver rad blir et arbeidspakke-utfall.
På en revisjon. Produser den riktige pakken og sjekk alderen på hver artefakt. Alt eldre enn 12 måneder er et spørsmål som venter på å bli stilt; alt eldre enn 24 måneder er et funn som venter på å bli skrevet.
På innkjøp. Gi leverandøren en tilpasset versjon av produktleverandør-pakken som et anbudsannekse. «Lever hvert av punkt 1–10 med budet, ellers er budet ikke-responsivt.» Denne enkle taktikken hever bunnen i leverandørresponser raskere enn noen kontraktsklausul.

Den samme logikken underbygger NIS2-kartleggingsteksten — der NIS2-direktivet (EU) 2022/2555 krever «egnede og forholdsmessige tekniske, operasjonelle og organisatoriske tiltak», er disse artefaktene som demonstrerer dem. Og for produkter plassert på EU-markedet etter desember 2027, går CRA-anvendelsesteksten gjennom hvor produktleverandør-pakken her dobler som en CRA-samsvarsmappe.

Ofte stilte spørsmål

Hva er forskjellen mellom et -4-1-sertifikat og et -4-2-sertifikat? -4-1 sertifiserer prosessen — leverandøren har en dokumentert, revidert Secure Development Lifecycle. -4-2 sertifiserer produktet — en spesifikk komponent, ved en spesifikk firmwareversjon, oppfyller de tekniske Component Requirements på et angitt kapabilitets-sikkerhetsnivå. Du trenger begge; en leverandør med kun -4-2 har et testet produkt, men ingen garanti for at neste utgivelse vil bli utviklet på samme måte. En leverandør med kun -4-1 har en ren prosess, men ingen sertifisert produkt på hylla.

Hvor lenge bør jeg oppbevare bevis? Match det lengste av: IACS-levetiden (typisk 15–25 år for et fornybaranlegg), regulatorens oppbevaringsperiode (under NIS2-gjennomføring lander dette ofte på seks år etter hendelsen), og gruppens dokumentbevaringspolicy. Tidsstemplede revisjonslogger fra SR 2.11-relevante systemer bør oppbevares minst tre år på varm lagring, lenger på kald lagring. Slett aldri en artefakt mens et åpent funn refererer til den.

Trenger jeg ISASecure eller IECEE CB for å oppfylle -4-1? Nei. IEC 62443-4-1-samsvar kan være selverklært, andrepartsvurdert (av en kunde), eller tredjepartssertifisert. Selverklært bevis er akseptabelt for mange revisorer hvis det er nivå-2-grad: SBOM-er, testrapporter, sporingsmatriser, opplæringsregistre. Tredjepartssertifisering via ISASecure SDLA eller en IECEE CB-ordnings IEC 62443-4-1-vurdering kortslutter ganske enkelt samtalen. For produkter solgt inn i kritisk infrastruktur-anbud i Europa er tredjepart i økende grad de facto-kravet.

Hvor passer NIS2-bevis inn i denne pakken? NIS2-bevis er et supersett som forbruker 62443-pakken, ikke erstatter den. NIS2-anvendelsesteksten dekker hvem som er i omfang; NIS2-kartleggingen viser hvilke 62443-artefakter som tilfredsstiller hvilke Artikkel 21-tiltak. Praktisk: en anleggseiers -2-1-pakke dekker mesteparten av NIS2 Artikkel 21(2)(a)–(j); integratorens -2-4-pakke dekker (d) leverandørkjedesikkerhet; produktleverandørens -4-1/-4-2-pakke underbygger resten. Legg til NIS2-spesifikke punkter — 24-timers tidlig-varslingsmal, registrering hos kompetent myndighet, og attest på cyberopplæring av ledelsen — og du har en NIS2-forsvarbar posisjon bygd på et 62443-fundament.

Hvis denne sjekklisten reddet deg ett funn, har teksten betalt for seg selv. For å diskutere punkt 6 i noen av tabellene er LinkedIn veien å finne meg.