IEC 62443-4-1: den sikre udviklingslivscyklus for industrielle produkter

Hvad 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, blev udgivet i januar 2018. I standardens eget anvendelsesområde hedder det, at den "specifies process requirements for the secure development of products used in industrial automation and control systems". Den livscyklus, den definerer, dækker definition af sikkerhedskrav, sikkert design, sikker implementering, verifikation og validering, fejlhåndtering, patchhåndtering og produktets end of life.

Den gælder for den, der udvikler og vedligeholder et produkt: produktleverandøren, der laver controllere, indlejrede enheder, netværksudstyr, værtssoftware eller applikationer. Den gælder ikke for integratoren eller brugeren af produktet, som har deres egne dele af serien. ISA udgiver serien som ISA/IEC 62443.

Standarden beskriver proceskrav, politikker og procedurer frem for tekniske sikkerhedsfunktioner. De tekniske krav til komponenter står i IEC 62443-4-2.

De otte praksisser i IEC 62443-4-1

Kravene er samlet i otte praksisser, hver med en kort forkortelse, der indleder dens krav-ID'er. ISA Global Cybersecurity Alliance angiver i alt 47 krav:

Praksis	Krav	Hvad den dækker
1. Sikkerhedsstyring (SM)	SM-1 til SM-13	Planlægning og drift af sikkerhedsprocessen: ansvar, ekspertise, sikkerhed i udviklingsmiljøet, private nøgler, eksternt leverede komponenter og tredjepartskomponenter, procesverifikation, løbende forbedring
2. Specifikation af sikkerhedskrav (SR)	SR-1 til SR-5	Produktets sikkerhedskontekst, trusselsmodel, produktets sikkerhedskrav og gennemgang af dem
3. Sikkert design (SD)	SD-1 til SD-4	Principper for sikkert design, design med dybdeforsvar, designgennemgang, bedste praksis for design
4. Sikker implementering (SI)	SI-1 til SI-2	Gennemgang af sikkerhedsimplementeringen og standarder for sikker kodning
5. Test af sikkerhedsverifikation og -validering (SVV)	SVV-1 til SVV-5	Test af krav, test af trusselsafhjælpning, sårbarhedstest, penetrationstest, testeres uafhængighed
6. Håndtering af sikkerhedsrelaterede problemer (DM)	DM-1 til DM-6	Modtagelse, gennemgang, vurdering, håndtering og offentliggørelse af sikkerhedsproblemer i produktet
7. Styring af sikkerhedsopdateringer (SUM)	SUM-1 til SUM-5	Kvalificering, dokumentation og levering af sikkerhedsopdateringer, til tiden
8. Sikkerhedsvejledninger (SG)	SG-1 til SG-7	Brugerdokumentation om dybdeforsvar, hærdning, sikker drift, kontostyring og bortskaffelse

Praksis 6: håndtering af sikkerhedsrelaterede problemer (DM)

DM er den praksis, et PSIRT genkender som sin egen. Ifølge ISAGCA bruges dens processer til at håndtere sikkerhedsrelaterede problemer i et produkt, der er konfigureret efter dets strategi for dybdeforsvar. Dens seks krav følger et problem fra rapport til afslutning:

• DM-1: Modtagelse af underretninger om sikkerhedsrelaterede problemer
• DM-2: Gennemgang af sikkerhedsrelaterede problemer
• DM-3: Vurdering af sikkerhedsrelaterede problemer
• DM-4: Håndtering af sikkerhedsrelaterede problemer
• DM-5: Offentliggørelse af sikkerhedsrelaterede problemer
• DM-6: Periodisk gennemgang af praksis for håndtering af sikkerhedsfejl

Enkelt sagt: tag imod rapporter, tjek dem, vurdér dem, ret dem, informér brugerne, og gennemgå selve processen.

Den rækkefølge er livscyklussen for sårbarhedsstyring under et andet navn, og DM-1 og DM-5 er der, hvor koordineret offentliggørelse af sårbarheder kommer ind. Offentliggørelse kan ske som en CSAF-advisory med en VEX-erklæring for versioner, der ikke er ramt.

Praksis 7: styring af sikkerhedsopdateringer (SUM)

SUM tager over, hvor DM beslutter sig for en rettelse. Dens processer sikrer, i ISAGCA's sammenfatning, at sikkerhedsopdateringer til produktets hardware, software eller firmware testes for regressioner og gøres tilgængelige for brugerne rettidigt. De fem krav er:

• SUM-1: Kvalificering af sikkerhedsopdateringer
• SUM-2: Dokumentation af sikkerhedsopdateringer
• SUM-3: Dokumentation af sikkerhedsopdateringer til afhængige komponenter eller styresystemer
• SUM-4: Levering af sikkerhedsopdateringer
• SUM-5: Rettidig levering af sikkerhedspatches

SUM-3 er det krav, der rækker ind i din forsyningskæde: opdateringer af komponenter og styresystemer, dit produkt afhænger af. For et indlejret produkt bygget på en Linux-distribution kan det være de fleste af de patches, du leverer.

Modenhedsniveauer

IEC 62443-4-1 spørger ikke, om en proces findes; den spørger, hvor moden den er. Den bruger fire modenhedsniveauer baseret på CMMI for Development:

Niveau	Betydning
ML1 Initial	Processer udføres ad hoc eller udokumenteret
ML2 Managed	Processer er dokumenteret og beskriver, hvordan aktiviteten leveres og styres
ML3 Defined (Practiced)	Processer er dokumenteret, udført og kan gentages
ML4 Improving	Processer forbedres over tid ved hjælp af metrikker for ydeevne og effektivitet

Forskellen på ML2 og ML3 er praksis. En skriftlig DM-proces kan være ML2. ML3 betyder, at processen er blevet udført og gentaget: problemer modtaget, vurderet og afsluttet, opdateringer leveret, med registreringer, der viser det.

Certificering

• ISASecure SDLA. Programmet Security Development Lifecycle Assurance certificerer en udviklingsorganisations livscyklusproces efter IEC 62443-4-1. Evalueringer udføres af chartrede SDLA-laboratorier, der er akkrediteret som overensstemmelsesvurderingsorganer.
• Certificeringsorganer og IECEE CB Scheme. Test- og certificeringsorganer som Applus+ og TÜV Rheinland vurderer leverandører efter 62443-4-1 og angiver det opnåede modenhedsniveau, også under IECEE CB Scheme, der gælder i mere end 50 lande.

Et 62443-4-1-certifikat dækker leverandørens udviklingsproces, ikke et enkelt produkt. Produkter vurderes separat efter 62443-4-2.

Sådan hænger 62443-4-1 sammen med resten af serien

• IEC 62443-4-2, tekniske sikkerhedskrav til IACS-komponenter: hvad produktet skal kunne. 4-1 er, hvordan du bygger og vedligeholder det.
• IEC 62443-3-3, sikkerhedskrav og sikkerhedsniveauer for systemer: de tilsvarende tekniske krav på systemniveau.
• IEC 62443-2-4, krav til sikkerhedsprogrammer hos IACS-tjenesteudbydere: de integratorer og vedligeholdelsesleverandører, der installerer og servicerer dit produkt hos anlægsejeren, og som er afhængige af dine sikkerhedsopdateringer og vejledninger.

Sådan kobles IEC 62443-4-1 til PSIRT-arbejde

PSIRT-aktivitet	Hvor den hører hjemme i 62443-4-1
Modtagelse af sårbarhedsrapporter	DM-1
Triage og analyse	DM-2, DM-3
Afhjælpning	DM-4, SUM-1
Advisories og offentliggørelse	DM-5, SUM-2
Patches til tredjepartskomponenter	SUM-3, sammen med SM-9 og SM-10 om eksternt leverede komponenter og tredjepartskomponenter
Release af rettelsen	SUM-4, SUM-5
Metrikker og procesgennemgang	DM-6, SM-13

Denne kobling er vores egen, ud fra kravenes titler. Standarden nævner ikke PSIRT'er ved navn; det samme arbejde er beskrevet i FIRST's PSIRT Services Framework og i ISO/IEC 30111.

SBOM'er som dokumentation for DM og SUM

Kravtitlerne fra 2018 nævner ikke SBOM'er. Men mange af sikkerhedsproblemerne i et industrielt produkt ligger i komponenter, leverandøren ikke selv har skrevet: Linux-kernen, OpenSSL, BusyBox, en protokolstak. At besvare DM-2 og DM-3 for en ny advisory betyder at vide, hvilke produkter og versioner der indeholder den ramte komponent. At dokumentere SUM-3-opdateringer betyder at vide, hvilke komponentversioner hver release blev leveret med. På ML3 skal de svar have registreringer bag sig.

En komponentliste skrevet i hånden eller en scanning af kildetræet bliver hurtigt forældet. Det gør en SBOM fra det build, der producerede releasen, ikke, så længe selve buildet er registreret.

Hvor CRACI passer ind

CRACI certificerer ikke noget under IEC 62443, og det driver ikke din udviklingsproces. Dets registreringer kan fungere som dokumentation for dele af den: inventaret over komponenter i hver release og overvågning af leverede builds for nye sårbarheder.

CRACI kører GitHub Actions-builds, inklusive Yocto-builds, på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra caches og afhængigheder, som ingen lockfile angiver. Hver SBOM har en fuldstændighedsstatus og eksporteres som CycloneDX eller SPDX. Overvågede SBOM'er genvurderes løbende, build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, og inventaroversigten viser, hvilke versioner der er udrullet til hvilke produkter. Leverandørers SBOM'er for indkøbte komponenter overvåges side om side med dine egne builds. Se sårbarhedssporing og CRACI til PSIRT-teams.

IEC 62443-4-1: ofte stillede spørgsmål

Hvad er IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, er den del af IEC 62443-serien, der fastsætter proceskrav til leverandører, som udvikler produkter til industrielle automations- og kontrolsystemer. Den dækker sikkerhedskrav, sikkert design, implementering, verifikation og validering, fejlhåndtering, patchhåndtering og produktets end of life.

Hvad er de otte praksisser i IEC 62443-4-1?

Sikkerhedsstyring (SM), specifikation af sikkerhedskrav (SR), sikkert design (SD), sikker implementering (SI), test af sikkerhedsverifikation og -validering (SVV), håndtering af sikkerhedsrelaterede problemer (DM), styring af sikkerhedsopdateringer (SUM) og sikkerhedsvejledninger (SG). Tilsammen rummer de 47 krav.

Hvad er forskellen på IEC 62443-4-1 og 62443-4-2?

4-1 handler om den proces, en leverandør bruger til at udvikle og vedligeholde produkter. 4-2 fastsætter tekniske sikkerhedskrav til selve komponenterne, for eksempel indlejrede enheder, netværksenheder, værtsenheder og softwareapplikationer. En leverandør vurderes typisk efter 4-1 for sin udviklingsproces og efter 4-2 for et bestemt produkt.

Hvilke praksisser i IEC 62443-4-1 dækker sårbarhedsstyring?

Primært praksis 6, håndtering af sikkerhedsrelaterede problemer (DM-1 til DM-6), som dækker modtagelse, gennemgang, vurdering, håndtering og offentliggørelse af sikkerhedsproblemer, og praksis 7, styring af sikkerhedsopdateringer (SUM-1 til SUM-5), som dækker kvalificering, dokumentation og rettidig levering af sikkerhedsopdateringer. Det er det arbejde, et PSIRT udfører.

Hvad er modenhedsniveauerne i IEC 62443-4-1?

Fire niveauer baseret på CMMI for Development: ML1 Initial (ad hoc eller udokumenteret), ML2 Managed (dokumenterede processer), ML3 Defined eller Practiced (dokumenteret, udført og kan gentages) og ML4 Improving (processer forbedret over tid ved hjælp af metrikker for ydeevne).

Hvordan bliver man certificeret efter IEC 62443-4-1?

Gennem et akkrediteret certificeringsorgan. ISASecures SDLA-program certificerer udviklingsorganisationer efter IEC 62443-4-1 gennem chartrede laboratorier, og certificeringsorganer som TÜV Rheinland og Applus+ udsteder 62443-4-1-certifikater, der angiver det opnåede modenhedsniveau, også under IECEE CB Scheme.

Kræver IEC 62443-4-1 en SBOM?

Kravtitlerne fra 2018 nævner ikke SBOM'er. Flere krav handler om eksternt leverede komponenter og om opdateringer af afhængige komponenter og styresystemer, og en pålidelig liste over komponenterne i hver release er den praktiske måde at vise, hvordan du håndterer dem.