IEC 62443-4-1 og 4-2: hva en OEM faktisk må bevise

Hvis du kjøper, spesifiserer eller drifter industrielt utstyr — en PLS, en RTU, en HMI, en industriell svitsj, en SCADA-gateway, en ingeniørarbeidsstasjon — har du nesten helt sikkert sett en leverandørbrosjyre som hevder å være «i samsvar med IEC 62443», «i tråd med 62443-4-2», eller «designet etter 62443-prinsippene». Disse formuleringene kan bety nesten hva som helst, fra en grundig revidert internasjonal sertifisering til lite annet enn ønsketenkning på et bildekort.

De to delene av standarden som nesten alltid blir nevnt er IEC 62443-4-1 (om hvordan produktet ble bygget) og IEC 62443-4-2 (om hva produktet kan gjøre). Denne artikkelen forklarer begge i klart språk og — viktigst av alt — angir hva en OEM må bevise objektivt for å underbygge et samsvarskrav, slik at du kan verifisere det heller enn å stole på det.

Denne teksten sitter i OEM-/produkt-hjørnet av IEC 62443-familien. Systemlaget — hvordan en anleggseier dimensjonerer sikkerhetskravet (3-2) og hvordan systemintegratoren leverer mot det (3-3) — dekkes i IEC 62443-3-2 og 3-3: hva anleggseiere og integratorer må bevise . Forvaltningssystem-laget — retningslinjene, programmene, tjenesteleverandørene og oppdaterings­disiplinen som omslutter det tekniske arbeidet — dekkes i IEC 62443-2-x: forvaltningssystemet bak et sikkert industrianlegg .

Den står også ved siden av to regulatoriske følgesvenner: spørsmålet om virksomhetens omfang, Gjelder NIS2 for ditt EU-prosjekt? , og spørsmålet om produktets omfang, Gjelder Cyber Resilience Act for ditt produkt? . Når en industriell OEM leverer til EU, lener CRAs essensielle krav seg i økende grad på IEC 62443-4-1/4-2-bevis som det praktiske beviset, og NIS2-anleggseiere under Vedlegg I kaskaderer de samme kravene tilbake gjennom sine leverandørkontrakter. Dokumentene henvender seg til ulike publikum, men beviskjeden løper gjennom dem alle.

Du kan kjøpe de offisielle standardene fra IEC Webstore: IEC 62443-4-1:2018 og IEC 62443-4-2:2019 .

En to-minutters orientering: IEC 62443-familien

IEC 62443 er en serie standarder for cybersikkerhet i industrielle automasjons- og kontrollsystemer (IACS). Den er utgitt i fellesskap av International Electrotechnical Commission (IEC) og International Society of Automation (ISA), og er organisert i fire nivåer, hver rettet mot et ulikt publikum.

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;

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

    A --> G[Del 1 — Generelt
Konsepter, terminologi, modeller]:::tier
    A --> P[Del 2 — Retningslinjer og prosedyrer
For anleggseier og operatør]:::tier
    A --> S[Del 3 — System
For systemintegratoren]:::tier
    A --> C[Del 4 — Komponent
For produktleverandøren / OEM]:::tier

    C --> C1[62443-4-1
Sikker utvikling
av produkt
PROSESS]:::focus
    C --> C2[62443-4-2
Tekniske sikkerhetskrav
for komponenter
PRODUKT]:::focus

De to vi bryr oss om her sitter begge i Del 4 — Komponent, og er produktleverandørens ansvar:

• IEC 62443-4-1 regulerer hvordan produktet utvikles — ingeniørprosessen, menneskene, kontrollene bak kulissene.
• IEC 62443-4-2 regulerer hva produktet teknisk sett kan gjøre — dets innebygde sikkerhetsfunksjoner.

Tenk på det slik: 4-1 er kjøkkenet og kokken; 4-2 er måltidet på tallerkenen. Et hygienisk kjøkken garanterer ikke et fantastisk måltid, og et tilsynelatende velsmakende måltid kan fortsatt komme fra et skittent kjøkken — derfor vil seriøse kjøpere ha forsikring om begge.

Hva IEC 62443-4-1 faktisk er

IEC 62443-4-1:2018, med tittelen «Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements», definerer en Secure Development Lifecycle (SDL) for industrielle produkter. Ifølge IECs egen beskrivelse dekker standarden «security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life» og gjelder utvikler og vedlikeholder av produktet, ikke integratoren eller sluttbrukeren.

Med andre ord: 4-1 er prosessfokusert. Den spør ikke «er fastvaren sikker?» Den spør «bygde du den på en måte som gjør sikker fastvare sannsynlig, gjentakbar og forbedrbar over tid?»

De 8 praksisene

Standarden grupperer kravene sine i åtte navngitte praksiser. Sammen dekker de hele buen fra opprinnelig produktidé til ende-av-støtte.

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

    SDL[Sikker utvikling
av produkt]:::entry

    SDL --> SM[Praksis 1 — SM
Security Management]:::step
    SDL --> SR[Praksis 2 — SR
Specification of
Security Requirements]:::step
    SDL --> SD[Praksis 3 — SD
Secure by Design]:::step
    SDL --> SI[Praksis 4 — SI
Secure Implementation]:::step
    SDL --> SVV[Praksis 5 — SVV
Security Verification
and Validation Testing]:::step
    SDL --> DM[Praksis 6 — DM
Management of
Security-Related Issues]:::step
    SDL --> SUM[Praksis 7 — SUM
Security Update
Management]:::step
    SDL --> SG[Praksis 8 — SG
Security Guidelines
for sluttbrukere]:::step

På tvers av disse åtte praksisene definerer standarden 47 toppnivå-krav, som igjen folder ut i hundrevis av underkrav. Sertifiseringsorganet Baker Hughes nevner dette eksplisitt i sitt offentlige whitepaper om sin egen IEC 62443-4-1 prosessvurdering: «there are a total of 47 top-level requirements, this actually consists of hundreds of sub-requirements» — og publiserer hjelpsomt sin egen poengsetting mot alle 47.

Modenhetsnivåer 1 til 4

IEC 62443-4-1 låner fra Capability Maturity Model Integration (CMMI)-tradisjonen. I stedet for å spørre «gjør dere X?» spør den «hvor godt gjør dere X?» Det er fire modenhetsnivåer (Maturity Levels, ML):

Et kritisk poeng som mange kjøpere går glipp av: under 62443-4-1 plukker du ikke «kirsebær» — for å hevde et gitt modenhetsnivå må alle relevante krav være oppfylt på det nivået. ML 2 på noen praksiser og ML 3 på andre er ikke «ML 3 totalt»; det er i beste fall ML 2 organisasjonsdekkende.

Hva 4-1 betyr praktisk for en OEM

Oversatt fra standardspråk er dette hva hver praksis betyr for menneskene som bygger produktet.

1. Security Management (SM) — «Noen har ansvaret, og det er jobben deres»

OEM-en må ha utnevnte roller for produktsikkerhet, allokert budsjett, definerte ansvarsområder, og integrert sikkerhetsaktiviteter i den formelle produktutviklingsplanen. Konfidensiell informasjon (kildekode, signeringsnøkler, trusselmodeller) må være kontrollert. Underleverandører og leverandører må holdes til samme standard.

Analogi: det er forskjellen mellom en fabrikk der noen er den navngitte HMS-ansvarlige med myndighet, opplæring og budsjett, og en der «sikkerhet» er den som tilfeldigvis tenker på det den uka.

2. Specification of Security Requirements (SR) — «Skriv ned hva ‘sikker’ betyr for dette produktet»

For hvert produkt (eller produktfamilie) må OEM-en produsere en skriftlig sikkerhetskontekst: hvor skal denne enheten leve, hvilke trusler står den overfor, hvilke tillitsgrenser krysser den, hvilke datastrømmer flyter inn og ut, hvilket mål-sikkerhetsnivå (SL-T) forventes? Disse kravene må godkjennes og versjonskontrolleres.

3. Secure by Design (SD) — «Bygg sikkerhet inn, ikke skru den på etterpå»

Det er her trusselmodellering bor. Arkitekturen og det detaljerte designet må analyseres for trusler (STRIDE, angrepstrær, eller tilsvarende), og de resulterende avbøtende tiltakene må designes inn før en linje produksjonskode er skrevet. Dybdeforsvar, minste privilegium og sikre standardinnstillinger må være eksplisitte arkitekturvalg, ikke ettertanker.

Analogi: i moderne bilbygging er deformasjonssoner, airbager og ABS designet inn i chassiset fra første skisse. Du kan ikke oppnå samme kollisjonssikkerhet ved å sveise ekstra plater på en ferdig bil på slutten av linjen. Samme logikk.

4. Secure Implementation (SI) — «Skriv koden ordentlig, og kontroller skrivingen»

Vedtatte kodestandarder (f.eks. CERT C, MISRA, SEI-veiledning), kollegafellesgjennomgang av kode, statisk applikasjonssikkerhetstesting (SAST) og regler for håndtering av usikret input. Kritisk dekker dette også tredjeparts- og åpen kildekode-komponenter: OEM-en må vite hva som er i produktet, hvor det kom fra og om det fortsatt støttes.

5. Security Verification and Validation Testing (SVV) — «Prøv å knekke det før noen andre gjør det»

Et dokumentert testprogram som inkluderer, som minimum: funksjonell sikkerhetstesting, sårbarhetsskanning, fuzz-testing, penetrasjonstesting, og angrepsflate-analyse. Resultatene skrives opp, defekter spores og testplanen er gjentakbar.

6. Management of Security-Related Issues (DM, defektstyring) — «Når noe blir funnet, hva skjer da?»

En dokumentert sårbarhetshåndteringsprosess: hvordan rapporter mottas (en publisert sikkerhetskontakt, helst en politikk for koordinert avsløring), hvordan de triageres, hvordan rotårsaksanalyse gjøres, hvordan rettelser produseres og spores, og hvordan kunder informeres. CVE-tildeling og en track record av CVE-håndtering er nøkkelbevis her.

7. Security Update Management (SUM) — «Oppdateringer som faktisk når feltet»

En dokumentert oppdaterings- og sikkerhetsoppdateringsprosess. Dette må dekke testing av oppdateringer før utgivelse, sikker levering (signerte oppdateringer), kundevarsling, støttetidslinjer og politikk for ende-av-liv.

8. Security Guidelines (SG) — «Fortell brukeren hvordan han skal bruke det sikkert»

Bruker-rettet dokumentasjon: herdingsveiledere, sikker konfigurasjonsveiledning, dybdeforsvars-anbefalinger, råd om kontostyring, instruksjoner for avvikling og en klar oversikt over hvilke sikkerhetsfunksjoner som finnes og hvordan de skrus på. Dette er praksisen som mest direkte kobler 4-1 til 4-2 — fordi 4-2-egenskaper kun er nyttige hvis kunden kan finne og konfigurere dem.

Hva en OEM må bevise objektivt for 4-1

Å demonstrere samsvar med IEC 62443-4-1 er sakens kjerne i OEM-ens påstand — og det bør ikke være en markedspåstand. Det bør være en posisjon OEM-en kan forsvare med dokumenter på bordet. Slik ser de dokumentene ut.

Dokumentariske og prosessuelle bevis

• En skriftlig, versjonskontrollert Secure Development Lifecycle-politikk som kartlegges på alle åtte praksiser og de 47 kravene.
• Et organisasjonskart som viser hvem som eier produktsikkerhet, med navngitte roller, opplæringsregistreringer og sikkerhetskompetanse hos nøkkelpersonell (utviklere, testere, arkitekter).
• Sikkerhetsopplæringsregistreringer for utviklings-, test- og produktledelsesstab — typisk oppdatert årlig.
• En produktsikkerhetsplan for det spesifikke produktet i omfanget, inkludert sikkerhetskonteksten, mål-SL, trusselmodell og tillitsgrenser.
• Et trusselmodelldokument for hvert produkt i omfanget (STRIDE, DREAD, angrepstrær eller tilsvarende) med sporbarhet inn i design og tester.
• Sikkerhetskravs-sporbarhet fra trusselmodellen → designbeslutninger → implementering → testtilfeller. En kjøper kan spørre: «Vis meg hvordan trussel T-17 i trusselmodellen er avdempet i designet, hvor i koden, og hvilken test som bekrefter det.»
• Skriftlige sikre kodestandarder som staben bruker, pluss kodegjennomgangsregistreringer og statisk analyseverktøy-utdata.
• Software Composition Analysis (SCA) registreringer eller en SBOM-stil oversikt over tredjeparts-/åpen kildekode-komponenter, med bevis på sårbarhetsovervåking mot dem.
• Et dokumentert testprogram med rapporter: sårbarhetsskanninger, fuzz-test-kampanjer, penetrasjonstest-rapporter, angrepsflate-gjennomgang.
• En publisert sårbarhetshåndteringspolitikk og politikk for koordinert avsløring, pluss en track record av CVE-er håndtert (tidslinjer, rådgivere, rettelser sendt).
• En oppdaterings- og sikkerhetsoppdateringsprosedyre med en reell historie av råd og oppdateringer.
• Sluttbruker-sikkerhetsretningslinjer, herdingsveiledere og produktsikkerhetsråd som OEM-en publiserer og vedlikeholder.

Tredjepartssertifisering — gullstandarden

Det mest troverdige objektive beviset er et tredjepartssertifikat utstedt av et akkreditert sertifiseringsorgan. For 62443-4-1 er de to hovedordningene:

• ISASecure SDLA (Security Development Lifecycle Assurance), drevet av ISA Security Compliance Institute (ISCI). Ifølge ISASecure-ordningsbeskrivelsen gjelder SDLA «applies to the development lifecycle processes of suppliers for control system products» og «certifies compliance to ISA/IEC 62443-4-1». SDLA tilbys på fire nivåer — SDLA Level 1, 2, 3 og 4 — som tilsvarer de fire modenhetsnivåene i standarden. Sertifisøren «evaluates the specific documented version of the organization's process to assess whether it meets the requirements stated in the SDLA specification» og «reviews representative artifacts to verify that each ISASecure SDLA requirement is being followed for products under the scope of the process».
• IECEE CB-ordningen for industriell cybersikkerhet, som tilbyr tilsvarende samsvarssertifikater utstedt av IECEE-anerkjente CBTL-er (Certification Body Test Laboratories). Se www.iecee.org .

To omfangsfeller å passe på

To detaljer på ethvert 4-1-sertifikat betyr mer enn overskriften:

1. Omfanget av prosessen — nøyaktig hvilket utviklingssted, hvilken forretningsenhet og hvilken produktlinje som dekkes. En leverandør som opererer i fem land kan kun ha ett sted sertifisert. Sertifikatet vil si det; brosjyren vanligvis ikke.
2. Modenhetsnivået som hevdes — og om vurdereren registrerte noen praksiser som «utenfor omfang» eller «ikke gjeldende». Baker Hughes' offentlige sertifikat, for eksempel, sier transparent at det ble vurdert til ML 2 og at 46 av de 47 praksisene var i omfang (én ble ekskludert, med begrunnelse). Det er den slags klarhet du skal se etter og spørre etter.

Hva IEC 62443-4-2 faktisk er

IEC 62443-4-2:2019, «Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components», definerer hva en individuell industriell komponent teknisk må kunne gjøre for å hevde et gitt sikkerhetsnivå. Per IECs egen omfangsuttalelse «provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs)» og definerer kapabilitets-sikkerhetsnivå for komponenter, SL-C(component).

Der 4-1 ser på utviklingsorganisasjonen, ser 4-2 på selve produktet — dets identifikasjonsmekanismer, tilgangskontroll, kryptografi, logging, oppdateringsmekanisme, herding, motstandsdyktighet.

De fire komponenttypene

Standarden anerkjenner at «en PLS» og «en Windows-ingeniørarbeidsstasjon» ikke er samme dyr, og ikke alle krav gjelder likt for begge. Så krav er delt i en felles kjerne (betegnet CR, for Component Requirement) pluss et lag av typespesifikke krav:

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

    CR[Felles komponentkrav — CR]:::entry

    CR --> SAR[SAR
Software Application
Requirements
f.eks. HMI-programvare,
ingeniørverktøy]:::type
    CR --> EDR[EDR
Embedded Device
Requirements
f.eks. PLS, RTU, IED,
sikkerhetskontroller]:::type
    CR --> HDR[HDR
Host Device
Requirements
f.eks. HMI-arbeidsstasjon,
ingeniør-PC, server]:::type
    CR --> NDR[NDR
Network Device
Requirements
f.eks. industriell svitsj,
brannmur, gateway]:::type

De syv grunnkravene

Alle krav i 4-2 er avledet fra de syv grunnkravene (Foundational Requirements, FRs) som ble innført helt tilbake i IEC TS 62443-1-1:

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

    FR[7 grunnkrav]:::entry

    FR --> FR1[FR1 — IAC
Identification and
Authentication Control]:::fr
    FR --> FR2[FR2 — UC
Use Control]:::fr
    FR --> FR3[FR3 — SI
System Integrity]:::fr
    FR --> FR4[FR4 — DC
Data Confidentiality]:::fr
    FR --> FR5[FR5 — RDF
Restricted Data Flow]:::fr
    FR --> FR6[FR6 — TRE
Timely Response
to Events]:::fr
    FR --> FR7[FR7 — RA
Resource Availability]:::fr

Under hvert FR sitter et antall komponentkrav (CRs), som hver kan ha en eller flere kravsforsterkninger (Requirement Enhancements, REs) som slår inn på høyere sikkerhetsnivåer. Totalt antall CR-er er rundt 60–70 (ofte sitert som 67) før REs og komponenttypespesifikke varianter telles; det presise antallet avhenger av hvordan du teller typespesifikke EDR/HDR/NDR/SAR-regler. Noen publiserte sammendrag (som Security Compass' oversikt) refererer til «more than 140 specific cybersecurity requirements» når REs og komponentvarianter inkluderes.

Sikkerhetsnivåer 1 til 4 — gradert etter trusselmodell

Genialiteten i 4-2 er at samme krav kan gjelde med økende strenghet avhengig av hvem du forventer skal angripe deg. De fire sikkerhetsnivåene er:

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef sl1 fill:#fff8dc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
    classDef sl2 fill:#ffe9b3,stroke:#cc7a00,color:#5a3300,stroke-width:1px;
    classDef sl3 fill:#ffc987,stroke:#b35900,color:#4a2200,stroke-width:1px;
    classDef sl4 fill:#ff9966,stroke:#992600,color:#3a0d00,stroke-width:1px;

    T[Sikkerhetsnivåer
under IEC 62443]:::entry

    T --> S1[SL 1
Beskytt mot
tilfeldige eller utilsiktede
brudd]:::sl1
    T --> S2[SL 2
Beskytt mot tilsiktede brudd
med enkle midler,
lite ressurser, generiske ferdigheter,
lav motivasjon]:::sl2
    T --> S3[SL 3
Beskytt mot tilsiktede brudd
med sofistikerte midler,
moderate ressurser, IACS-spesifikke
ferdigheter, moderat motivasjon]:::sl3
    T --> S4[SL 4
Beskytt mot tilsiktede brudd
med sofistikerte midler,
utvidede ressurser, IACS-spesifikke
ferdigheter, høy motivasjon
dvs. nasjonalstats-klasse]:::sl4

Analogi: tenk på Euro NCAP-kollisjonstest-rangeringer for biler. En én-stjerners bil er gate-lovlig, men du vil ikke sette familien din i den på motorveien. En fem-stjerners bil er konstruert for å absorbere et alvorlig sammenstøt. SL 1 til SL 4 fungerer på samme måte: du velger nivået driftsmiljøet ditt rettferdiggjør, og du betaler (i kostnad, kompleksitet og konfigurasjonsoverhead) deretter. For de fleste generelle industrielle miljøer har ISASecure offentlig argumentert for at SL 2 er et fornuftig minimum for nye anskaffelser.

Hva 4-2 betyr praktisk for en OEM

Hver FR oversettes til produktegenskaper som en bruker faktisk kan se og konfigurere. Et ikke-uttømmende utvalg:

• FR 1 – Identification & Authentication Control (IAC): unike brukerkonti, rollebaserte identiteter, multifaktorautentisering, passordpolitikk, kontolåsning, enhet-til-enhet-autentisering med kryptografiske legitimasjoner, støtte for offentlig nøkkel-infrastruktur.
• FR 2 – Use Control (UC): rollebasert tilgangskontroll, sesjonsstyring, sesjonsutløp, restriksjoner på utførelse av mobil kode, USB-port-kontroll, trådløs tilgangsstyring, revisjonsloggning og loggbeskyttelse.
• FR 3 – System Integrity (SI): signert fastvare, secure boot, integritetsbeskyttede oppdateringer, malware-beskyttelse, input-validering, feilhåndtering som ikke lekker interne detaljer, manipulasjonsdeteksjon.
• FR 4 – Data Confidentiality (DC): krypterte kommunikasjoner (TLS eller tilsvarende), beskyttelse av kryptografiske nøkler, kryptering av data i hvile der det er relevant.
• FR 5 – Restricted Data Flow (RDF): soneinndeling, segmentering, evne til å delta i en Zones-and-Conduits-arkitektur, restriksjon av unødvendige nettverkstjenester.
• FR 6 – Timely Response to Events (TRE): revisjonsloggning med tilstrekkelig detalj, tidsstempling av logg, loggvideresending (f.eks. til syslog/SIEM), kroker for kontinuerlig overvåking.
• FR 7 – Resource Availability (RA): motstand mot tjenestenektangrep, feilsikker oppførsel, beskyttelse mot ressursuttømming, backup og gjenoppretting.

Det som endrer seg mellom SL 1 og SL 4 er essensielt grundigheten og dybden i disse mekanismene. SL 1 kan kreve «komponenten skal støtte autentisering»; SL 3 vil kreve unik per-bruker-autentisering med kryptografiske mekanismer; SL 4 vil legge til manipulasjonssikker legitimasjonslagring og motstand mot sofistikerte angrep.

Komponenttypen betyr også noe. En PLS (EDR) forventes å ha integritetsbeskyttet fastvare og en maskinvare root-of-trust; en HMI-arbeidsstasjon (HDR) forventes å støtte virksomhets-kontostyring, anti-malware og OS-herding. Krav er omfangsbestemt til det som er rimelig for enhetsklassen.

Hva en OEM må bevise objektivt for 4-2

For 4-2 er beviset per produkt og per versjon. Det finnes ikke noe slikt som «vårt selskap er 4-2-sertifisert» — bare «dette eksakte produktet, ved denne eksakte fastvareversjonen, oppnår SL-C n mot IEC 62443-4-2».

Hva «bra» ser ut som

• Den spesifikke produktidentifikatoren: modellnummer, maskinvarerevisjon, fastvare-/programvareversjon.
• En uttalelse om det hevdede kapabilitets-sikkerhetsnivået (SL-C) — vanligvis én SL-C-verdi per FR, noen ganger publisert som en vektor som SL-C (2, 2, 2, 1, 2, 2, 2) på tvers av FR1–FR7.
• En erklæring om hvilken komponenttype produktet er vurdert som (SAR, EDR, HDR eller NDR) — og hvis det er en sammensatt enhet, hvordan delene har blitt klassifisert.
• Testrapporter som viser at hvert gjeldende CR og RE er oppfylt. Uavhengige testrapporter er langt sterkere enn egenerklæringer.
• En funksjonell sikkerhetsspesifikasjon for sluttbrukere: hva hver sikkerhetsfunksjon gjør, hvordan man aktiverer den, og hvilke restrisikoer som gjenstår hvis den er deaktivert.
• En herdings-/sikker konfigurasjonsveileder som forteller integratoren nøyaktig hvordan produktet skal distribueres slik at SL-C-kravet er oppnåelig i den faktiske installasjonen.

Skillet SL-C / SL-T / SL-A — vitalt å forstå

Disse tre forkortelsene blandes konstant og forårsaker reelle innkjøpsfeil:

• SL-C (Capability) — hva produktet teknisk er i stand til å levere når det er riktig konfigurert. Det er dette 4-2 og ISASecure CSA sertifiserer.
• SL-T (Target) — hva anleggseieren har bestemt er nødvendig i en gitt sone i anlegget, basert på sin risikovurdering.
• SL-A (Achieved) — hva som faktisk leveres når produktet er installert, konfigurert og integrert i det levende systemet.

Et produkt kan være SL-C 3-kapabelt men distribueres som SL-A 1 hvis anleggseieren skrur av funksjonene. Omvendt kan du ikke overskride din svakeste komponent: en sone bygget av SL-C 2-komponenter kan ikke oppnå SL-A 3 bare ved ønsketenkning.

Tredjepartssertifisering — gullstandarden

Hovedordningen er ISASecure CSA (Component Security Assurance). Fra ISASecure CSA-100-ordningsdokumentet: CSA «focuses on the security of software applications, embedded devices, host devices, and network devices, as defined by the ISA/IEC 62443-4-2 standard» og er «designed to certify to international standards ISA/IEC 62443-4-2 and ISA/IEC 62443-4-1». Programmet definerer fire sertifiseringsnivåer — CSA Capability Security Level 1, 2, 3 og 4 — og sertifiseringen undersøker tre ting i tillegg til utviklingsprosessen:

• SDA-C (Security Development Artifacts for Components) — utviklingsutdataene for dette produktet.
• FSA-C (Functional Security Assessment for Components) — sikkerhetsegenskapene produktet faktisk eksponerer.
• VIT-C (Vulnerability Identification Testing for Components) — skanning av produktet for kjente sårbarheter.

Kritisk krever CSA-ordningen at leverandøren innehar en gjeldende ISASecure SDLA-sertifisering for utviklingsprosessen. Som ISASecure SDLA-dokumentasjonen sier det: «application of ISA/IEC 62443-4-1 practices as verified by SDLA certification is intended to provide confidence that the component or system has security commensurate with its expected level of risk throughout the product's life-cycle». Kort sagt: ingen SDLA, ingen CSA.

Et levende register over CSA-sertifiserte komponenter vedlikeholdes på isasecure.org/end-users/iec-62443-4-2-certified-components — et godt første stopp for enhver verifiseringsøvelse. Det finnes også en IIoT-spesifikk utvidelse, ISASecure ICSA, for IIoT-komponenter og gatewayer, med Core- og Advanced-nivåer.

IECEE CB-ordningen utsteder også sertifikater mot 62443-4-2 og 62443-4-1, anerkjent internasjonalt mellom IECEE-medlemsorganer.

Hvordan 4-1 og 4-2 henger sammen

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef proc fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef prod fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;

    O[OEM / produktleverandør]:::entry

    O --> P[62443-4-1
SDLA sertifiserer
utviklingsprosessen
på modenhetsnivå 1–4]:::proc
    O --> Q[62443-4-2
CSA sertifiserer den
spesifikke produktversjonen
på SL-C 1–4]:::prod
    P -.forutsetning for.-> Q

To praktiske sannheter følger:

1. Du kan i prinsippet forestille deg et 4-2-samsvar produkt fra en leverandør uten 4-1-sertifisering, men i reelle tredjepartsordninger — og i ISASecure CSA spesielt — må utviklingsprosessen også vurderes. CSA krever eksplisitt SDLA (eller tilsvarende SDLPA-C prosessvurdering) som forutsetning. Så spørsmålet å stille en leverandør er sjelden «enten 4-1 eller 4-2»; det er «vis meg begge».
2. En leverandør som kun har SDLA forteller deg at prosessen er solid, men ikke at noe bestemt produkt når et bestemt SL-C. En leverandør som hevder CSA uten underliggende SDLA gjør et krav som ikke passer sertifiseringsordningen — behandle med forsiktighet.

Det er også her den EU-regulatoriske kjeden går sammen. Under Cyber Resilience Act lener Vedlegg I essensielle krav for produkter med digitale elementer seg tungt på påviselig sikker utvikling og komponent-egenskaper — nøyaktig det 4-1 og 4-2 koder for det industrielle domenet. Og under NIS2 artikkel 21(2)(d) kaskaderer anleggseierens leverandørkjede-sikkerhetsforpliktelser kontraktsmessige krav tilbake gjennom leverandørene: i praksis ankommer det ofte OEM-en som en forespørsel om 4-1 og 4-2-bevis.

Vanlige fallgruver og røde flagg

Visse formuleringer og situasjoner i en OEMs samsvarspåstand bør få en kjøper til å bremse før kontrakten signeres.

En kjøpers sjekkliste for anskaffelse

Bruk dette som et kontraktstillegg eller som et leverandør-spørreskjema.

Spørsmål å stille OEM-en skriftlig

1. Har selskapet et gjeldende ISASecure SDLA-sertifikat (eller tilsvarende IECEE 62443-4-1-sertifikat)? På hvilket modenhetsnivå? Utstedt av hvilket sertifiseringsorgan, på hvilken dato, utløper når?
2. Hva er omfanget av det SDLA-sertifikatet — hvilke utviklingssteder, hvilke forretningsenheter, hvilke produktlinjer?
3. For det spesifikke produktet som tilbys, har det et ISASecure CSA-sertifikat (eller tilsvarende IECEE 62443-4-2-sertifikat)?
4. Hva er det eksakte modellnummeret og fastvare-/programvareversjonen dekket av sertifikatet?
5. Hva er det hevdede SL-C for hvert av de syv grunnkravene (SL-C-vektoren)?
6. Hvilken komponenttype har blitt sertifisert — SAR, EDR, HDR eller NDR?
7. Vennligst gi sertifikat-PDF-en, den offentlige sertifiseringsrapporten (der tilgjengelig), og herdingsveilederen / funksjonell sikkerhetsspesifikasjon for produktet.
8. Vennligst gi URL-en til sårbarhetsavsløringspolitikken og en liste over CVE-er håndtert de siste 24 månedene for denne produktfamilien.
9. Hva er støtte- og oppdateringslevetiden for produktet, og den dokumenterte politikken for ende-av-liv?
10. Vennligst beskriv SBOM-en eller tredjeparts-komponentinventaret tilgjengelig for dette produktet.

Dokumenter å kreve på fil

• SDLA / IECEE 62443-4-1-sertifikat.
• CSA / IECEE 62443-4-2-sertifikat per produkt og versjon.
• Produkt-funksjonell sikkerhetsspesifikasjon.
• Herdings-/sikker konfigurasjonsveileder.
• Sårbarhetsavsløringspolitikk.
• Eksempel-sikkerhetsråd (for å bekrefte at en reell avsløringsprosess eksisterer i praksis).

Verifiseringssteg

• Kryss-sjekk sertifikatnummeret på ISASecure-sertifiserte produkter-registeret på isasecure.org/end-users/iec-62443-4-2-certified-components .
• For IECEE-sertifikater, verifiser på IECEE CB-ordningens sertifikat-database på iecee.org .
• Bekreft at sertifikatet er gyldig og at omfangsuttalelsen matcher modellen og fastvaren du faktisk kjøper.
• Sammenlign SL-C-vektoren mot ditt eget SL-T fra risikovurderingen din.
• Be om bevis for at produktet som leveres til deg matcher den sertifiserte versjonen — oppdateringer og mindre utgivelser kan flytte produktet utenfor det sertifiserte omfanget.

IEC 62443-4-1 spør OEM-en «Er du den typen organisasjon som kan bygge sikre produkter, gjentakelig, og holde dem slik?» IEC 62443-4-2 spør samme OEM «Har dette eksakte produktet, ved denne eksakte versjonen, de tekniske sikkerhetsfunksjonene som trengs for å motstå truslene i driftsmiljøet sitt?»

Sammen utgjør de ett av de mest grundige svarene den industrielle verden har på «hvordan vet jeg at denne OEM-en tar cybersikkerhet seriøst?» — men bare hvis du leser forbi brosjyren til sertifikatet, og forbi sertifikatet til omfanget.

Behandle dem som grunnmuren, ikke målstreken. Et sertifisert produkt, dårlig distribuert og aldri oppdatert, er ikke mer sikkert enn et usertifisert et. Og et usertifisert produkt, uansett hvor velmenende leverandøren er, ber deg ta all forsikring på tillit.