IEC 62443-4-1: den säkra utvecklingslivscykeln för industriprodukter

Vad är IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, publicerades i januari 2018. Enligt standardens eget tillämpningsområde är det en standard som "specifies process requirements for the secure development of products used in industrial automation and control systems". Livscykeln den definierar omfattar definition av säkerhetskrav, säker design, säker implementering, verifiering och validering, defekthantering, patchhantering och produktens slut på livscykeln.

Den gäller den som utvecklar och underhåller en produkt: produktleverantören som tillverkar styrenheter, inbyggda enheter, nätverksutrustning, värdprogramvara eller applikationer. Den gäller inte integratören eller användaren av produkten, som har egna delar i serien. ISA publicerar serien som ISA/IEC 62443.

Standarden beskriver processkrav, policyer och rutiner, inte tekniska säkerhetsfunktioner. De tekniska kraven på komponenter finns i IEC 62443-4-2.

De åtta metoderna i IEC 62443-4-1

Kraven är indelade i åtta metoder, var och en med en kort förkortning som inleder kravens id:n. ISA Global Cybersecurity Alliance listar totalt 47 krav:

Metod	Krav	Vad den omfattar
1. Säkerhetsstyrning (SM)	SM-1 till SM-13	Planering och drift av säkerhetsprocessen: ansvar, kompetens, säkerhet i utvecklingsmiljön, privata nycklar, externt tillhandahållna komponenter och tredjepartskomponenter, processverifiering, ständig förbättring
2. Specifikation av säkerhetskrav (SR)	SR-1 till SR-5	Produktens säkerhetskontext, hotmodell, produktens säkerhetskrav och granskningen av dem
3. Säker design (SD)	SD-1 till SD-4	Principer för säker design, design för försvar på djupet, designgranskning, bästa praxis för design
4. Säker implementering (SI)	SI-1 till SI-2	Granskning av säkerhetsimplementering och standarder för säker kodning
5. Testning för säkerhetsverifiering och validering (SVV)	SVV-1 till SVV-5	Kravtestning, testning av hotreducering, sårbarhetstestning, penetrationstestning, testarnas oberoende
6. Hantering av säkerhetsrelaterade problem (DM)	DM-1 till DM-6	Att ta emot, granska, bedöma, åtgärda och offentliggöra säkerhetsproblem i produkten
7. Hantering av säkerhetsuppdateringar (SUM)	SUM-1 till SUM-5	Att kvalificera, dokumentera och leverera säkerhetsuppdateringar i tid
8. Säkerhetsriktlinjer (SG)	SG-1 till SG-7	Användardokumentation för försvar på djupet, härdning, säker drift, kontohantering och kassering

Metod 6: hantering av säkerhetsrelaterade problem (DM)

DM är den metod som ett PSIRT känner igen som sin egen. Enligt ISAGCA används dess processer för att hantera säkerhetsrelaterade problem i en produkt som är konfigurerad enligt dess strategi för försvar på djupet. De sex kraven följer ett problem från rapport till avslut:

• DM-1: Mottagande av underrättelser om säkerhetsrelaterade problem
• DM-2: Granskning av säkerhetsrelaterade problem
• DM-3: Bedömning av säkerhetsrelaterade problem
• DM-4: Åtgärdande av säkerhetsrelaterade problem
• DM-5: Offentliggörande av säkerhetsrelaterade problem
• DM-6: Periodisk översyn av metoden för hantering av säkerhetsdefekter

Enkelt uttryckt: ta emot rapporter, kontrollera dem, bedöm dem, åtgärda dem, informera användarna och se över själva processen.

Den ordningen är livscykeln för sårbarhetshantering under ett annat namn, och det är i DM-1 och DM-5 som samordnat offentliggörande av sårbarheter kommer in. Offentliggörandet kan publiceras som ett CSAF-meddelande, med ett VEX-uttalande för de versioner som inte berörs.

Metod 7: hantering av säkerhetsuppdateringar (SUM)

SUM tar vid där DM beslutar om en rättning. Dess processer ser, enligt ISAGCA:s sammanfattning, till att säkerhetsuppdateringar för produktens hårdvara, programvara eller firmware testas för regressioner och görs tillgängliga för användarna i rimlig tid. De fem kraven är:

• SUM-1: Kvalificering av säkerhetsuppdateringar
• SUM-2: Dokumentation av säkerhetsuppdateringar
• SUM-3: Dokumentation av säkerhetsuppdateringar för beroende komponenter eller operativsystem
• SUM-4: Leverans av säkerhetsuppdateringar
• SUM-5: Leverans av säkerhetspatchar i rimlig tid

SUM-3 är kravet som når in i din leveranskedja: uppdateringar av komponenter och operativsystem som din produkt är beroende av. För en inbyggd produkt som bygger på en Linux-distribution kan det vara de flesta av patcharna du levererar.

Mognadsnivåer

IEC 62443-4-1 frågar inte om en process finns, utan hur mogen den är. Standarden använder fyra mognadsnivåer, baserade på CMMI for Development:

Nivå	Betydelse
ML1 Initial	Processer utförs ad hoc eller är odokumenterade
ML2 Managed	Processer är dokumenterade och beskriver hur aktiviteten genomförs och styrs
ML3 Defined (Practiced)	Processer är dokumenterade, utförda och repeterbara
ML4 Improving	Processer förbättras över tid med hjälp av mätetal för prestanda och effektivitet

Skillnaden mellan ML2 och ML3 ligger i tillämpningen. En skriftlig DM-process kan vara ML2. ML3 innebär att processen har utförts och upprepats: problem har tagits emot, bedömts och avslutats, uppdateringar har levererats och det finns dokumentation som visar det.

Certifiering

• ISASecure SDLA. Programmet Security Development Lifecycle Assurance certifierar en utvecklingsorganisations livscykelprocess enligt IEC 62443-4-1. Utvärderingarna görs av auktoriserade SDLA-laboratorier som är ackrediterade som organ för bedömning av överensstämmelse.
• Certifieringsorgan och IECEE CB Scheme. Test- och certifieringsorgan som Applus+ och TÜV Rheinland bedömer leverantörer mot 62443-4-1 och anger vilken mognadsnivå som uppnåtts, även inom IECEE CB Scheme, som gäller i mer än 50 länder.

Ett 62443-4-1-certifikat omfattar leverantörens utvecklingsprocess, inte en enskild produkt. Produkter bedöms separat mot 62443-4-2.

Hur 62443-4-1 hänger ihop med resten av serien

• IEC 62443-4-2, tekniska säkerhetskrav på IACS-komponenter: vad produkten måste kunna göra. 4-1 är hur du bygger och underhåller den.
• IEC 62443-3-3, säkerhetskrav och säkerhetsnivåer för system: motsvarande tekniska krav på systemnivå.
• IEC 62443-2-4, krav på säkerhetsprogram för IACS-tjänsteleverantörer: integratörerna och underhållsleverantörerna som installerar och servar din produkt hos anläggningsägaren och som är beroende av dina säkerhetsuppdateringar och riktlinjer.

Så mappas IEC 62443-4-1 mot PSIRT-arbete

PSIRT-aktivitet	Var den hamnar i 62443-4-1
Mottagning av sårbarhetsrapporter	DM-1
Triage och analys	DM-2, DM-3
Åtgärd	DM-4, SUM-1
Säkerhetsmeddelanden och offentliggörande	DM-5, SUM-2
Patchar för tredjepartskomponenter	SUM-3, med SM-9 och SM-10 om externt tillhandahållna komponenter och tredjepartskomponenter
Release av rättningen	SUM-4, SUM-5
Mätetal och processöversyn	DM-6, SM-13

Den här mappningen är vår, utifrån kravens titlar. Standarden nämner inte PSIRT vid namn; samma arbete beskrivs i FIRST:s PSIRT Services Framework och i ISO/IEC 30111.

SBOM:er som underlag för DM och SUM

Kravtitlarna från 2018 nämner inte SBOM:er. Men många av säkerhetsproblemen i en industriprodukt finns i komponenter som leverantören inte har skrivit: Linux-kärnan, OpenSSL, BusyBox, en protokollstack. Att besvara DM-2 och DM-3 för ett nytt säkerhetsmeddelande innebär att veta vilka produkter och versioner som innehåller den berörda komponenten. Att dokumentera SUM-3-uppdateringar innebär att veta vilka komponentversioner varje release levererades med. På ML3 behöver de svaren ha dokumentation bakom sig.

En komponentlista som skrivits för hand, eller en skanning av källkodsträdet, blir inaktuell. En SBOM från bygget som producerade releasen blir det inte, så länge själva bygget registreras.

Var CRACI passar in

CRACI certifierar ingenting enligt IEC 62443 och driver inte din utvecklingsprocess. Dess registreringar kan fungera som underlag för delar av den: inventeringen av komponenter i varje release och bevakningen av levererade byggen mot nya sårbarheter.

CRACI kör GitHub Actions-byggen, inklusive Yocto-byggen, på egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från cachar och beroenden som ingen lockfile listar. Varje SBOM har en fullständighetsstatus och exporteras som CycloneDX eller SPDX. Bevakade SBOM:er omvärderas löpande, bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart beroende, och inventeringsvyn visar vilka versioner som är driftsatta i vilka produkter. Leverantörers SBOM:er för inköpta komponenter bevakas bredvid dina egna byggen. Se sårbarhetsuppföljning och CRACI för PSIRT-team.

IEC 62443-4-1: vanliga frågor

Vad är IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, är den del av IEC 62443-serien som ställer processkrav på leverantörer som utvecklar produkter för industriella automations- och styrsystem. Den omfattar säkerhetskrav, säker design, implementering, verifiering och validering, defekthantering, patchhantering och produktens slut på livscykeln.

Vilka är de åtta metoderna i IEC 62443-4-1?

Säkerhetsstyrning (SM), specifikation av säkerhetskrav (SR), säker design (SD), säker implementering (SI), testning för säkerhetsverifiering och validering (SVV), hantering av säkerhetsrelaterade problem (DM), hantering av säkerhetsuppdateringar (SUM) och säkerhetsriktlinjer (SG). Tillsammans innehåller de 47 krav.

Vad är skillnaden mellan IEC 62443-4-1 och 62443-4-2?

4-1 handlar om processen som en leverantör använder för att utveckla och underhålla produkter. 4-2 ställer tekniska säkerhetskrav på själva komponenterna, till exempel inbyggda enheter, nätverksenheter, värdenheter och programvaruapplikationer. En leverantör bedöms vanligtvis mot 4-1 för sin utvecklingsprocess och mot 4-2 för en specifik produkt.

Vilka metoder i IEC 62443-4-1 täcker sårbarhetshantering?

Främst metod 6, hantering av säkerhetsrelaterade problem (DM-1 till DM-6), som omfattar att ta emot, granska, bedöma, åtgärda och offentliggöra säkerhetsproblem, och metod 7, hantering av säkerhetsuppdateringar (SUM-1 till SUM-5), som omfattar att kvalificera, dokumentera och leverera säkerhetsuppdateringar i tid. Det är arbetet som ett PSIRT utför.

Vilka är mognadsnivåerna i IEC 62443-4-1?

Fyra nivåer, baserade på CMMI for Development: ML1 Initial (ad hoc eller odokumenterat), ML2 Managed (dokumenterade processer), ML3 Defined eller Practiced (dokumenterat, utfört och repeterbart) och ML4 Improving (processer som förbättras över tid med hjälp av prestandamått).

Hur blir man certifierad enligt IEC 62443-4-1?

Genom ett ackrediterat certifieringsorgan. ISASecures SDLA-program certifierar utvecklingsorganisationer enligt IEC 62443-4-1 genom auktoriserade laboratorier, och certifieringsorgan som TÜV Rheinland och Applus+ utfärdar 62443-4-1-certifikat som anger vilken mognadsnivå som uppnåtts, även inom IECEE CB Scheme.

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

Kravtitlarna från 2018 nämner inte SBOM:er. Flera krav handlar om externt tillhandahållna komponenter och om uppdateringar av beroende komponenter och operativsystem, och en tillförlitlig lista över komponenterna i varje release är det praktiska sättet att visa hur du hanterar dem.