IEC 62443-4-1: de veilige ontwikkelcyclus voor industriële producten

Wat is IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, is in januari 2018 gepubliceerd. Volgens zijn eigen scope legt de norm procesvereisten vast voor de veilige ontwikkeling van producten die in industriële automatiserings- en besturingssystemen worden gebruikt. De levenscyclus die hij definieert, omvat de definitie van beveiligingseisen, veilig ontwerp, veilige implementatie, verificatie en validatie, defectbeheer, patchbeheer en het einde van de levensduur van het product.

De norm geldt voor de ontwikkelaar en onderhouder van een product: de productleverancier die controllers, embedded apparaten, netwerkapparatuur, hostsoftware of applicaties maakt. Hij geldt niet voor de integrator of de gebruiker van het product, die hun eigen delen van de reeks hebben. ISA publiceert de reeks als ISA/IEC 62443.

De norm beschrijft procesvereisten, beleid en procedures, geen technische beveiligingsfuncties. De technische eisen voor componenten staan in IEC 62443-4-2.

De acht praktijken van IEC 62443-4-1

De eisen zijn ingedeeld in acht praktijken, elk met een korte afkorting die aan de eis-ID's voorafgaat. De ISA Global Cybersecurity Alliance telt in totaal 47 eisen:

Praktijk	Eisen	Wat ze omvat
1. Beveiligingsbeheer (SM)	SM-1 tot SM-13	Het beveiligingsproces plannen en uitvoeren: verantwoordelijkheden, expertise, beveiliging van de ontwikkelomgeving, privésleutels, extern geleverde componenten en componenten van derden, procesverificatie, continue verbetering
2. Specificatie van beveiligingseisen (SR)	SR-1 tot SR-5	Beveiligingscontext van het product, dreigingsmodel, beveiligingseisen voor het product en de beoordeling daarvan
3. Secure by design (SD)	SD-1 tot SD-4	Veilige ontwerpprincipes, ontwerp voor defense in depth, ontwerpreview, best practices voor ontwerp
4. Veilige implementatie (SI)	SI-1 tot SI-2	Review van de beveiligingsimplementatie en normen voor veilig coderen
5. Verificatie- en validatietests voor beveiliging (SVV)	SVV-1 tot SVV-5	Testen van eisen, testen van dreigingsbeperking, kwetsbaarheidstests, penetratietests, onafhankelijkheid van testers
6. Beheer van beveiligingsgerelateerde problemen (DM)	DM-1 tot DM-6	Beveiligingsproblemen in het product ontvangen, beoordelen, inschatten, aanpakken en openbaar maken
7. Beheer van beveiligingsupdates (SUM)	SUM-1 tot SUM-5	Beveiligingsupdates kwalificeren, documenteren en op tijd leveren
8. Beveiligingsrichtlijnen (SG)	SG-1 tot SG-7	Gebruikersdocumentatie voor defense in depth, hardening, veilig gebruik, accountbeheer en buitengebruikstelling

Praktijk 6: beheer van beveiligingsgerelateerde problemen (DM)

DM is de praktijk die een PSIRT als de zijne herkent. Volgens de ISAGCA worden de processen ervan gebruikt om beveiligingsgerelateerde problemen af te handelen van een product dat is geconfigureerd volgens zijn defense-in-depth-strategie. De zes eisen volgen een probleem van melding tot afsluiting:

• DM-1: Meldingen van beveiligingsgerelateerde problemen ontvangen
• DM-2: Beveiligingsgerelateerde problemen beoordelen
• DM-3: Beveiligingsgerelateerde problemen inschatten
• DM-4: Beveiligingsgerelateerde problemen aanpakken
• DM-5: Beveiligingsgerelateerde problemen openbaar maken
• DM-6: Periodieke beoordeling van de praktijk voor het beheer van beveiligingsdefecten

Eenvoudig gezegd: meldingen aannemen, controleren, beoordelen, oplossen, gebruikers informeren en het proces zelf evalueren.

Die volgorde is de levenscyclus van kwetsbaarheidsbeheer onder een andere naam, en bij DM-1 en DM-5 komt gecoördineerde openbaarmaking van kwetsbaarheden in beeld. De openbaarmaking kan verlopen via een CSAF-advisory, met een VEX-verklaring voor versies die niet zijn getroffen.

Praktijk 7: beheer van beveiligingsupdates (SUM)

SUM gaat verder waar DM over een fix beslist. Volgens de samenvatting van de ISAGCA zorgen de processen ervan ervoor dat beveiligingsupdates voor de hardware, software of firmware van het product op regressies worden getest en tijdig aan gebruikers beschikbaar worden gesteld. De vijf eisen zijn:

• SUM-1: Kwalificatie van beveiligingsupdates
• SUM-2: Documentatie van beveiligingsupdates
• SUM-3: Documentatie van beveiligingsupdates voor afhankelijke componenten of besturingssystemen
• SUM-4: Levering van beveiligingsupdates
• SUM-5: Tijdige levering van beveiligingspatches

SUM-3 is de eis die tot in uw softwareketen reikt: updates van componenten en besturingssystemen waarvan uw product afhankelijk is. Voor een embedded product dat op een Linux-distributie is gebouwd, kan dat het grootste deel van de patches zijn die u levert.

Volwassenheidsniveaus

IEC 62443-4-1 vraagt niet of een proces bestaat, maar hoe volwassen het is. De norm gebruikt vier volwassenheidsniveaus, gebaseerd op CMMI for Development:

Niveau	Betekenis
ML1 Initial	Processen worden ad hoc of ongedocumenteerd uitgevoerd
ML2 Managed	Processen zijn gedocumenteerd en beschrijven hoe de activiteit wordt geleverd en beheerd
ML3 Defined (Practiced)	Processen zijn gedocumenteerd, uitgevoerd en herhaalbaar
ML4 Improving	Processen worden in de loop van de tijd verbeterd met metrics voor prestaties en effectiviteit

Het verschil tussen ML2 en ML3 is de praktijk. Een schriftelijk DM-proces kan ML2 zijn. ML3 betekent dat het proces is uitgevoerd en herhaald: problemen ontvangen, beoordeeld en afgesloten, updates geleverd, met de records om het aan te tonen.

Certificering

• ISASecure SDLA. Het programma Security Development Lifecycle Assurance certificeert het levenscyclusproces van een ontwikkelorganisatie volgens IEC 62443-4-1. Evaluaties worden uitgevoerd door erkende SDLA-laboratoria die zijn geaccrediteerd als conformiteitsbeoordelingsinstanties.
• Certificeringsinstanties en het IECEE CB Scheme. Test- en certificeringsinstanties zoals Applus+ en TÜV Rheinland beoordelen leveranciers aan de hand van 62443-4-1 en vermelden het behaalde volwassenheidsniveau, ook onder het IECEE CB Scheme, dat in meer dan 50 landen van toepassing is.

Een 62443-4-1-certificaat dekt het ontwikkelproces van de leverancier, niet één product. Producten worden apart beoordeeld aan de hand van 62443-4-2.

Hoe 62443-4-1 zich verhoudt tot de rest van de reeks

• IEC 62443-4-2, technische beveiligingseisen voor IACS-componenten: wat het product moet kunnen. 4-1 gaat over hoe u het bouwt en onderhoudt.
• IEC 62443-3-3, beveiligingseisen en beveiligingsniveaus voor systemen: de vergelijkbare technische eisen op systeemniveau.
• IEC 62443-2-4, eisen aan beveiligingsprogramma's voor IACS-dienstverleners: de integrators en onderhoudspartijen die uw product op de locatie van de asset owner installeren en onderhouden, en die afhankelijk zijn van uw beveiligingsupdates en richtlijnen.

IEC 62443-4-1 afgezet tegen PSIRT-werk

PSIRT-activiteit	Waar die in 62443-4-1 terechtkomt
Intake van kwetsbaarheidsmeldingen	DM-1
Triage en analyse	DM-2, DM-3
Herstel	DM-4, SUM-1
Advisories en openbaarmaking	DM-5, SUM-2
Patches voor componenten van derden	SUM-3, met SM-9 en SM-10 over extern geleverde componenten en componenten van derden
Release van de fix	SUM-4, SUM-5
Metrics en procesevaluatie	DM-6, SM-13

Deze koppeling is van onze hand, op basis van de titels van de eisen. De norm noemt PSIRT's niet bij naam; hetzelfde werk wordt beschreven in het PSIRT Services Framework van FIRST en in ISO/IEC 30111.

SBOM's als bewijs voor DM en SUM

De titels van de eisen uit 2018 noemen geen SBOM's. Maar veel van de beveiligingsproblemen in een industrieel product zitten in componenten die de leverancier niet zelf heeft geschreven: de Linux-kernel, OpenSSL, BusyBox, een protocolstack. Om DM-2 en DM-3 voor een nieuwe advisory te beantwoorden, moet u weten welke producten en versies de getroffen component bevatten. Om SUM-3-updates te documenteren, moet u weten met welke componentversies elke release is geleverd. Op ML3 moeten er records achter die antwoorden staan.

Een handmatig geschreven componentenlijst of een scan van de broncode veroudert. Een SBOM uit de build die de release heeft opgeleverd niet, zolang de build zelf is vastgelegd.

De rol van CRACI

CRACI certificeert niets onder IEC 62443 en voert uw ontwikkelproces niet uit. De records van CRACI kunnen als bewijs dienen voor delen ervan: de inventaris van componenten in elke release en de monitoring van geleverde builds op nieuwe kwetsbaarheden.

CRACI draait GitHub Actions-builds, inclusief Yocto-builds, op zijn eigen runners en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Elke SBOM heeft een volledigheidsstatus en wordt geëxporteerd als CycloneDX of SPDX. Gemonitorde SBOM's worden doorlopend opnieuw beoordeeld, de buildgeschiedenis toont welke eerdere builds een kwetsbare afhankelijkheid bevatten, en de inventarisweergave toont welke versies op welke producten zijn uitgerold. Leveranciers-SBOM's voor ingekochte componenten worden naast uw eigen builds gemonitord. Zie het volgen van kwetsbaarheden en CRACI voor PSIRT-teams.

IEC 62443-4-1: veelgestelde vragen

Wat is IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, is het deel van de IEC 62443-reeks dat procesvereisten stelt aan leveranciers die producten ontwikkelen voor industriële automatiserings- en besturingssystemen. Het omvat beveiligingseisen, veilig ontwerp, implementatie, verificatie en validatie, defectbeheer, patchbeheer en het einde van de levensduur van het product.

Wat zijn de acht praktijken van IEC 62443-4-1?

Beveiligingsbeheer (SM), specificatie van beveiligingseisen (SR), secure by design (SD), veilige implementatie (SI), verificatie- en validatietests voor beveiliging (SVV), beheer van beveiligingsgerelateerde problemen (DM), beheer van beveiligingsupdates (SUM) en beveiligingsrichtlijnen (SG). Samen bevatten ze 47 eisen.

Wat is het verschil tussen IEC 62443-4-1 en 62443-4-2?

4-1 gaat over het proces dat een leverancier gebruikt om producten te ontwikkelen en te onderhouden. 4-2 stelt technische beveiligingseisen aan de componenten zelf, zoals embedded apparaten, netwerkapparaten, hostapparaten en softwareapplicaties. Een leverancier wordt doorgaans aan de hand van 4-1 beoordeeld op zijn ontwikkelproces en aan de hand van 4-2 op een specifiek product.

Welke praktijken van IEC 62443-4-1 gaan over kwetsbaarheidsbeheer?

Vooral praktijk 6, beheer van beveiligingsgerelateerde problemen (DM-1 tot DM-6), die het ontvangen, beoordelen, inschatten, aanpakken en openbaar maken van beveiligingsproblemen omvat, en praktijk 7, beheer van beveiligingsupdates (SUM-1 tot SUM-5), die het kwalificeren, documenteren en op tijd leveren van beveiligingsupdates omvat. Dit is het werk van een PSIRT.

Wat zijn de volwassenheidsniveaus van IEC 62443-4-1?

Vier niveaus, gebaseerd op CMMI for Development: ML1 Initial (ad hoc of ongedocumenteerd), ML2 Managed (gedocumenteerde processen), ML3 Defined of Practiced (gedocumenteerd, uitgevoerd en herhaalbaar) en ML4 Improving (processen die in de loop van de tijd worden verbeterd met prestatiemetrics).

Hoe krijgt u een IEC 62443-4-1-certificering?

Via een geaccrediteerde certificeringsinstantie. Het SDLA-programma van ISASecure certificeert ontwikkelorganisaties volgens IEC 62443-4-1 via erkende laboratoria, en certificeringsinstanties zoals TÜV Rheinland en Applus+ geven 62443-4-1-certificaten uit waarop het behaalde volwassenheidsniveau staat, ook onder het IECEE CB Scheme.

Vereist IEC 62443-4-1 een SBOM?

De titels van de eisen uit 2018 noemen geen SBOM's. Verschillende eisen gaan over extern geleverde componenten en over updates van afhankelijke componenten en besturingssystemen, en een betrouwbare lijst van de componenten in elke release is de praktische manier om te laten zien hoe u daarmee omgaat.