IEC 62443-4-1: sikker utviklingslivssyklus for industriprodukter

Hva er IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, ble publisert i januar 2018. Ifølge standardens eget omfang spesifiserer den prosesskrav for sikker utvikling av produkter som brukes i industrielle automatiserings- og kontrollsystemer. Livssyklusen den definerer, dekker definisjon av sikkerhetskrav, sikker design, sikker implementering, verifisering og validering, feilhåndtering, patchhåndtering og slutten av produktets levetid.

Den gjelder for dem som utvikler og vedlikeholder et produkt: produktleverandøren som lager kontrollere, innebygde enheter, nettverksutstyr, vertsprogramvare eller applikasjoner. Den gjelder ikke for integratoren eller brukeren av produktet, som har egne deler av serien. ISA publiserer serien som ISA/IEC 62443.

Standarden beskriver prosesskrav, policyer og prosedyrer, ikke tekniske sikkerhetsfunksjoner. De tekniske kravene til komponenter står i IEC 62443-4-2.

De åtte praksisene i IEC 62443-4-1

Kravene er gruppert i åtte praksiser, hver med en kort forkortelse som innleder krav-ID-ene. ISA Global Cybersecurity Alliance oppgir 47 krav totalt:

Praksis	Krav	Hva den dekker
1. Sikkerhetsstyring (SM)	SM-1 til SM-13	Planlegging og drift av sikkerhetsprosessen: ansvar, kompetanse, sikkerhet i utviklingsmiljøet, private nøkler, eksternt leverte komponenter og tredjepartskomponenter, verifisering av prosessen, kontinuerlig forbedring
2. Spesifikasjon av sikkerhetskrav (SR)	SR-1 til SR-5	Produktets sikkerhetskontekst, trusselmodell, produktets sikkerhetskrav og gjennomgang av dem
3. Sikker design (SD)	SD-1 til SD-4	Prinsipper for sikker design, dybdeforsvar i designen, designgjennomgang, beste praksis for design
4. Sikker implementering (SI)	SI-1 til SI-2	Gjennomgang av sikkerhetsimplementeringen og standarder for sikker koding
5. Testing av sikkerhetsverifisering og -validering (SVV)	SVV-1 til SVV-5	Testing av krav, testing av trusselreduksjon, sårbarhetstesting, penetrasjonstesting, testernes uavhengighet
6. Håndtering av sikkerhetsrelaterte problemer (DM)	DM-1 til DM-6	Motta, gjennomgå, vurdere, håndtere og offentliggjøre sikkerhetsproblemer i produktet
7. Håndtering av sikkerhetsoppdateringer (SUM)	SUM-1 til SUM-5	Kvalifisere, dokumentere og levere sikkerhetsoppdateringer i tide
8. Sikkerhetsretningslinjer (SG)	SG-1 til SG-7	Brukerdokumentasjon for dybdeforsvar, herding, sikker drift, kontoadministrasjon og avhending

Praksis 6: håndtering av sikkerhetsrelaterte problemer (DM)

DM er praksisen et PSIRT kjenner igjen som sin egen. Ifølge ISAGCA brukes prosessene til å håndtere sikkerhetsrelaterte problemer i et produkt som er konfigurert i tråd med dybdeforsvarsstrategien. De seks kravene følger et problem fra rapport til lukking:

• DM-1: Motta varsler om sikkerhetsrelaterte problemer
• DM-2: Gjennomgå sikkerhetsrelaterte problemer
• DM-3: Vurdere sikkerhetsrelaterte problemer
• DM-4: Håndtere sikkerhetsrelaterte problemer
• DM-5: Offentliggjøre sikkerhetsrelaterte problemer
• DM-6: Periodisk gjennomgang av praksisen for håndtering av sikkerhetsfeil

Enkelt sagt: Ta imot rapporter, sjekk dem, vurder dem, rett dem, informer brukerne og gjennomgå selve prosessen.

Den rekkefølgen er livssyklusen for sårbarhetshåndtering under et annet navn, og DM-1 og DM-5 er der koordinert offentliggjøring av sårbarheter kommer inn. Offentliggjøringen kan publiseres som en CSAF-advisory, med en VEX-erklæring for versjoner som ikke er berørt.

Praksis 7: håndtering av sikkerhetsoppdateringer (SUM)

SUM tar over der DM bestemmer seg for en retting. Prosessene sørger, slik ISAGCA oppsummerer det, for at sikkerhetsoppdateringer for produktets maskinvare, programvare eller firmware testes for regresjoner og gjøres tilgjengelige for brukerne i tide. De fem kravene er:

• SUM-1: Kvalifisering av sikkerhetsoppdateringer
• SUM-2: Dokumentasjon av sikkerhetsoppdateringer
• SUM-3: Dokumentasjon av sikkerhetsoppdateringer for avhengige komponenter eller operativsystemer
• SUM-4: Levering av sikkerhetsoppdateringer
• SUM-5: Levering av sikkerhetspatcher i tide

SUM-3 er kravet som strekker seg inn i leverandørkjeden din: oppdateringer av komponenter og operativsystemer produktet ditt er avhengig av. For et innebygd produkt bygget på en Linux-distribusjon kan det være de fleste patchene du leverer.

Modenhetsnivåer

IEC 62443-4-1 spør ikke om en prosess finnes; den spør hvor moden den er. Den bruker fire modenhetsnivåer, basert på CMMI for Development:

Nivå	Betydning
ML1 Initial	Prosesser utføres ad hoc eller er ikke dokumentert
ML2 Managed	Prosesser er dokumentert og beskriver hvordan aktiviteten leveres og styres
ML3 Defined (Practiced)	Prosesser er dokumentert, utført og repeterbare
ML4 Improving	Prosesser forbedres over tid ved hjelp av metrikker for ytelse og effektivitet

Forskjellen mellom ML2 og ML3 er praksis. En skriftlig DM-prosess kan være ML2. ML3 betyr at prosessen er utført og gjentatt: Problemer er mottatt, vurdert og lukket, oppdateringer er levert, og det finnes registreringer som viser det.

Sertifisering

• ISASecure SDLA. Programmet Security Development Lifecycle Assurance sertifiserer en utviklingsorganisasjons livssyklusprosess etter IEC 62443-4-1. Evalueringene utføres av godkjente SDLA-laboratorier som er akkreditert som samsvarsvurderingsorganer.
• Sertifiseringsorganer og IECEE CB Scheme. Test- og sertifiseringsorganer som Applus+ og TÜV Rheinland vurderer leverandører mot 62443-4-1 og oppgir oppnådd modenhetsnivå, også under IECEE CB Scheme, som gjelder i mer enn 50 land.

Et 62443-4-1-sertifikat dekker leverandørens utviklingsprosess, ikke et enkelt produkt. Produkter vurderes separat mot 62443-4-2.

Slik henger 62443-4-1 sammen med resten av serien

• IEC 62443-4-2, tekniske sikkerhetskrav til IACS-komponenter: hva produktet må kunne gjøre. 4-1 er hvordan du bygger og vedlikeholder det.
• IEC 62443-3-3, sikkerhetskrav til systemer og sikkerhetsnivåer: de tilsvarende tekniske kravene på systemnivå.
• IEC 62443-2-4, krav til sikkerhetsprogrammer for IACS-tjenesteleverandører: integratorene og vedlikeholdsleverandørene som installerer og vedlikeholder produktet ditt hos anleggseieren, og som er avhengige av sikkerhetsoppdateringene og retningslinjene dine.

Slik kobles IEC 62443-4-1 til PSIRT-arbeid

PSIRT-aktivitet	Hvor det hører hjemme i 62443-4-1
Mottak av sårbarhetsrapporter	DM-1
Prioritering og analyse	DM-2, DM-3
Retting	DM-4, SUM-1
Advisories og offentliggjøring	DM-5, SUM-2
Patcher for tredjepartskomponenter	SUM-3, med SM-9 og SM-10 om eksternt leverte komponenter og tredjepartskomponenter
Utgivelse av rettingen	SUM-4, SUM-5
Metrikker og gjennomgang av prosessen	DM-6, SM-13

Denne koblingen er vår egen, gjort ut fra kravtitlene. Standarden nevner ikke PSIRT-er ved navn; det samme arbeidet er beskrevet i FIRSTs PSIRT Services Framework og i ISO/IEC 30111.

SBOM-er som dokumentasjon for DM og SUM

Kravtitlene fra 2018 nevner ikke SBOM-er. Men mange av sikkerhetsproblemene i et industriprodukt ligger i komponenter leverandøren ikke har skrevet selv: Linux-kjernen, OpenSSL, BusyBox, en protokollstakk. Å svare på DM-2 og DM-3 for en ny advisory betyr å vite hvilke produkter og versjoner som inneholder den berørte komponenten. Å dokumentere SUM-3-oppdateringer betyr å vite hvilke komponentversjoner hver utgivelse ble levert med. På ML3 må disse svarene ha registreringer bak seg.

En komponentliste skrevet for hånd, eller en skanning av kildetreet, blir utdatert. En SBOM fra bygget som produserte utgivelsen, gjør ikke det, så lenge selve bygget er registrert.

Hvor CRACI passer inn

CRACI sertifiserer ikke noe under IEC 62443, og det driver ikke utviklingsprosessen din. Registreringene kan brukes som dokumentasjon for deler av den: oversikten over komponenter i hver utgivelse og overvåking av leverte bygg for nye sårbarheter.

CRACI kjører GitHub Actions-bygg, inkludert Yocto-bygg, på egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra cacher og avhengigheter ingen lockfile oppgir. Hver SBOM har en fullstendighetsstatus og eksporteres som CycloneDX eller SPDX. Overvåkede SBOM-er vurderes kontinuerlig på nytt, byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, og inventarvisningen viser hvilke versjoner som er rullet ut til hvilke produkter. Leverandør-SBOM-er for innkjøpte komponenter overvåkes sammen med dine egne bygg. Se sporing av sårbarheter og CRACI for PSIRT-er.

IEC 62443-4-1: ofte stilte spørsmål

Hva er IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, er delen av IEC 62443-serien som setter prosesskrav til leverandører som utvikler produkter for industrielle automatiserings- og kontrollsystemer. Den dekker sikkerhetskrav, sikker design, implementering, verifisering og validering, feilhåndtering, patchhåndtering og slutten av produktets levetid.

Hva er de åtte praksisene i IEC 62443-4-1?

Sikkerhetsstyring (SM), spesifikasjon av sikkerhetskrav (SR), sikker design (SD), sikker implementering (SI), testing av sikkerhetsverifisering og -validering (SVV), håndtering av sikkerhetsrelaterte problemer (DM), håndtering av sikkerhetsoppdateringer (SUM) og sikkerhetsretningslinjer (SG). Til sammen inneholder de 47 krav.

Hva er forskjellen på IEC 62443-4-1 og 62443-4-2?

4-1 handler om prosessen en leverandør bruker for å utvikle og vedlikeholde produkter. 4-2 setter tekniske sikkerhetskrav til selve komponentene, for eksempel innebygde enheter, nettverksenheter, vertsenheter og programvareapplikasjoner. En leverandør vurderes vanligvis mot 4-1 for utviklingsprosessen og mot 4-2 for et bestemt produkt.

Hvilke praksiser i IEC 62443-4-1 dekker sårbarhetshåndtering?

Hovedsakelig praksis 6, håndtering av sikkerhetsrelaterte problemer (DM-1 til DM-6), som dekker å motta, gjennomgå, vurdere, håndtere og offentliggjøre sikkerhetsproblemer, og praksis 7, håndtering av sikkerhetsoppdateringer (SUM-1 til SUM-5), som dekker å kvalifisere, dokumentere og levere sikkerhetsoppdateringer i tide. Dette er arbeidet et PSIRT gjør.

Hva er modenhetsnivåene i IEC 62443-4-1?

Fire nivåer, basert på CMMI for Development: ML1 Initial (ad hoc eller udokumentert), ML2 Managed (dokumenterte prosesser), ML3 Defined eller Practiced (dokumentert, utført og repeterbart) og ML4 Improving (prosesser som forbedres over tid ved hjelp av ytelsesmetrikker).

Hvordan blir man sertifisert etter IEC 62443-4-1?

Gjennom et akkreditert sertifiseringsorgan. ISASecures SDLA-program sertifiserer utviklingsorganisasjoner etter IEC 62443-4-1 gjennom godkjente laboratorier, og sertifiseringsorganer som TÜV Rheinland og Applus+ utsteder 62443-4-1-sertifikater som oppgir oppnådd modenhetsnivå, også under IECEE CB Scheme.

Krever IEC 62443-4-1 en SBOM?

Kravtitlene fra 2018 nevner ikke SBOM-er. Flere krav handler om eksternt leverte komponenter og om oppdateringer av avhengige komponenter og operativsystemer, og en pålitelig liste over komponentene i hver utgivelse er den praktiske måten å vise hvordan du håndterer dem på.