V roce 2026 o 131% více nahlášených CVE denně než loni.

PSIRT

IEC 62443-4-1: bezpečný životní cyklus vývoje průmyslových produktů

IEC 62443-4-1 stanoví procesní požadavky, které dodavatel dodržuje při vývoji a údržbě bezpečných produktů pro průmyslové automatizační a řídicí systémy. Dva z jejích osmi postupů, řízení bezpečnostních problémů a dodávání bezpečnostních aktualizací, jsou prací týmu PSIRT.

Aktualizováno

Co je IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, vyšla v lednu 2018. Podle vlastního rozsahu normy stanoví procesní požadavky na bezpečný vývoj produktů používaných v průmyslových automatizačních a řídicích systémech. Životní cyklus, který definuje, zahrnuje definici bezpečnostních požadavků, bezpečný návrh, bezpečnou implementaci, verifikaci a validaci, správu defektů, správu záplat a konec životnosti produktu.

Vztahuje se na vývojáře a správce produktu: dodavatele, který vyrábí řídicí jednotky, vestavěná zařízení, síťová zařízení, hostitelský software nebo aplikace. Nevztahuje se na integrátora ani uživatele produktu, kteří mají v řadě vlastní části. ISA vydává řadu pod označením ISA/IEC 62443.

Norma popisuje procesní požadavky, politiky a postupy, nikoli technické bezpečnostní funkce. Technické požadavky na komponenty obsahuje IEC 62443-4-2.

Osm postupů IEC 62443-4-1

Požadavky jsou rozdělené do osmi postupů, z nichž každý má krátkou zkratku, která tvoří předponu identifikátorů jeho požadavků. ISA Global Cybersecurity Alliance uvádí celkem 47 požadavků:

Postup Požadavky Co pokrývá
1. Řízení bezpečnosti (SM) SM-1 až SM-13 Plánování a provoz bezpečnostního procesu: odpovědnosti, odbornost, bezpečnost vývojového prostředí, privátní klíče, externě dodané komponenty a komponenty třetích stran, ověřování procesu, neustálé zlepšování
2. Specifikace bezpečnostních požadavků (SR) SR-1 až SR-5 Bezpečnostní kontext produktu, model hrozeb, bezpečnostní požadavky na produkt a jejich revize
3. Bezpečnost již od návrhu (SD) SD-1 až SD-4 Principy bezpečného návrhu, návrh s ochranou do hloubky, revize návrhu, osvědčené postupy návrhu
4. Bezpečná implementace (SI) SI-1 až SI-2 Revize bezpečnosti implementace a standardy bezpečného kódování
5. Testování verifikace a validace bezpečnosti (SVV) SVV-1 až SVV-5 Testování požadavků, testování zmírnění hrozeb, testování zranitelností, penetrační testy, nezávislost testerů
6. Řízení problémů souvisejících s bezpečností (DM) DM-1 až DM-6 Přijímání, posuzování, vyhodnocování, řešení a zveřejňování bezpečnostních problémů v produktu
7. Řízení bezpečnostních aktualizací (SUM) SUM-1 až SUM-5 Kvalifikace, dokumentace a včasné dodávání bezpečnostních aktualizací
8. Bezpečnostní pokyny (SG) SG-1 až SG-7 Uživatelská dokumentace k ochraně do hloubky, zabezpečení konfigurace (hardening), bezpečnému provozu, správě účtů a likvidaci

Postup 6: řízení problémů souvisejících s bezpečností (DM)

DM je postup, ve kterém PSIRT pozná svou vlastní práci. Podle ISAGCA se jeho procesy používají k řešení bezpečnostních problémů produktu nakonfigurovaného podle jeho strategie ochrany do hloubky. Jeho šest požadavků sleduje problém od nahlášení až po uzavření:

  • DM-1: Přijímání oznámení o problémech souvisejících s bezpečností
  • DM-2: Posuzování problémů souvisejících s bezpečností
  • DM-3: Vyhodnocování problémů souvisejících s bezpečností
  • DM-4: Řešení problémů souvisejících s bezpečností
  • DM-5: Zveřejňování problémů souvisejících s bezpečností
  • DM-6: Pravidelná revize postupu správy bezpečnostních defektů

Jednoduše řečeno: přijímat hlášení, ověřit je, vyhodnotit je, opravit, informovat uživatele a revidovat samotný proces.

Tato posloupnost je životní cyklus správy zranitelností pod jiným názvem a v DM-1 a DM-5 vstupuje do hry koordinované zveřejňování zranitelností. Zveřejnění lze publikovat jako bezpečnostní upozornění CSAF, s prohlášením VEX pro verze, které dotčené nejsou.

Postup 7: řízení bezpečnostních aktualizací (SUM)

SUM navazuje tam, kde DM rozhodne o opravě. Jeho procesy podle shrnutí ISAGCA zajišťují, že bezpečnostní aktualizace hardwaru, softwaru nebo firmwaru produktu jsou otestovány na regrese a včas zpřístupněny uživatelům. Pět požadavků zní:

  • SUM-1: Kvalifikace bezpečnostní aktualizace
  • SUM-2: Dokumentace bezpečnostní aktualizace
  • SUM-3: Dokumentace bezpečnostních aktualizací závislých komponent nebo operačního systému
  • SUM-4: Dodání bezpečnostní aktualizace
  • SUM-5: Včasné dodání bezpečnostních záplat

SUM-3 je požadavek, který sahá do vašeho dodavatelského řetězce: aktualizace komponent a operačních systémů, na kterých váš produkt závisí. U vestavěného produktu postaveného na linuxové distribuci to může být většina záplat, které dodáváte.

Úrovně vyspělosti

IEC 62443-4-1 se neptá, zda proces existuje; ptá se, jak je vyspělý. Používá čtyři úrovně vyspělosti založené na CMMI for Development:

Úroveň Význam
ML1 Initial Procesy se provádějí ad hoc nebo nejsou zdokumentované
ML2 Managed Procesy jsou zdokumentované a popisují, jak se činnost provádí a řídí
ML3 Defined (Practiced) Procesy jsou zdokumentované, prováděné a opakovatelné
ML4 Improving Procesy se v čase zlepšují na základě metrik výkonnosti a účinnosti

Rozdíl mezi ML2 a ML3 je praxe. Sepsaný proces DM může odpovídat ML2. ML3 znamená, že se proces provádí a opakuje: problémy se přijímají, vyhodnocují a uzavírají, aktualizace se dodávají a existují záznamy, které to dokládají.

Certifikace

  • ISASecure SDLA. Program Security Development Lifecycle Assurance certifikuje proces životního cyklu vývojové organizace podle IEC 62443-4-1. Hodnocení provádějí autorizované laboratoře SDLA akreditované jako subjekty posuzování shody.
  • Certifikační orgány a schéma IECEE CB. Zkušební a certifikační orgány jako Applus+ a TÜV Rheinland posuzují dodavatele podle 62443-4-1 a uvádějí dosaženou úroveň vyspělosti, a to i v rámci schématu IECEE CB, které platí ve více než 50 zemích.

Certifikát 62443-4-1 pokrývá vývojový proces dodavatele, nikoli jednotlivý produkt. Produkty se posuzují samostatně podle 62443-4-2.

Jak 62443-4-1 souvisí se zbytkem řady

  • IEC 62443-4-2, technické bezpečnostní požadavky na komponenty IACS: co musí produkt umět. 4-1 popisuje, jak ho vyvíjíte a udržujete.
  • IEC 62443-3-3, systémové bezpečnostní požadavky a úrovně zabezpečení: odpovídající technické požadavky na úrovni systému.
  • IEC 62443-2-4, požadavky na bezpečnostní program poskytovatelů služeb IACS: integrátorů a poskytovatelů údržby, kteří váš produkt instalují a servisují u vlastníka aktiva a kteří závisejí na vašich bezpečnostních aktualizacích a pokynech.

Mapování IEC 62443-4-1 na práci týmu PSIRT

Činnost týmu PSIRT Kam spadá v 62443-4-1
Příjem hlášení o zranitelnostech DM-1
Triáž a analýza DM-2, DM-3
Náprava DM-4, SUM-1
Bezpečnostní upozornění a zveřejnění DM-5, SUM-2
Záplaty komponent třetích stran SUM-3, se SM-9 a SM-10 o externě dodaných komponentách a komponentách třetích stran
Vydání opravy SUM-4, SUM-5
Metriky a revize procesu DM-6, SM-13

Toto mapování je naše, podle názvů požadavků. Norma týmy PSIRT jménem nezmiňuje; stejnou práci popisují PSIRT Services Framework od FIRST a ISO/IEC 30111.

SBOM jako důkaz pro DM a SUM

Názvy požadavků z roku 2018 SBOM nezmiňují. Mnoho bezpečnostních problémů průmyslového produktu ale leží v komponentách, které jeho dodavatel nenapsal: jádro Linuxu, OpenSSL, BusyBox, protokolový stack. Odpovědět na DM-2 a DM-3 u nového bezpečnostního upozornění znamená vědět, které produkty a verze obsahují dotčenou komponentu. Dokumentovat aktualizace podle SUM-3 znamená vědět, s jakými verzemi komponent se každé vydání dodávalo. Na úrovni ML3 musí za těmito odpověďmi stát záznamy.

Ručně psaný seznam komponent nebo sken stromu zdrojového kódu zastarává. SBOM z buildu, který vydání vytvořil, nezastarává, pokud je zaznamenaný samotný build.

Kde se uplatní CRACI

CRACI nic podle IEC 62443 necertifikuje a neřídí váš vývojový proces. Jeho záznamy mohou sloužit jako důkaz pro jeho části: inventář komponent v každém vydání a monitorování dodaných buildů kvůli novým zranitelnostem.

CRACI spouští buildy GitHub Actions, včetně buildů Yocto, na vlastních runnerech a zaznamenává balíčky, které každý job skutečně stáhl, včetně tranzitivních závislostí, balíčků obnovených z cache a závislostí, které neuvádí žádný lockfile. Každá SBOM nese stav úplnosti a exportuje se ve formátu CycloneDX nebo SPDX. Monitorované SBOM se průběžně znovu vyhodnocují, historie buildů ukazuje, které dřívější buildy obsahovaly zranitelnou závislost, a zobrazení inventáře ukazuje, které verze jsou nasazené ve kterých produktech. SBOM dodavatelů pro nakupované komponenty se monitorují spolu s vašimi vlastními buildy. Podívejte se na sledování zranitelností a CRACI pro týmy PSIRT.

Dodáváte produkty nebo komponenty výrobci OEM? Přečtěte si průvodce SBOM pro dodavatele a kontrolní seznam kvality SBOM, který váš zákazník pravděpodobně použije.

IEC 62443-4-1: časté dotazy

Co je IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, je část řady IEC 62443, která stanoví procesní požadavky pro dodavatele vyvíjející produkty používané v průmyslových automatizačních a řídicích systémech. Pokrývá bezpečnostní požadavky, bezpečný návrh, implementaci, verifikaci a validaci, správu defektů, správu záplat a konec životnosti produktu.

Jakých osm postupů IEC 62443-4-1 obsahuje?

Řízení bezpečnosti (SM), specifikace bezpečnostních požadavků (SR), bezpečnost již od návrhu (SD), bezpečná implementace (SI), testování verifikace a validace bezpečnosti (SVV), řízení problémů souvisejících s bezpečností (DM), řízení bezpečnostních aktualizací (SUM) a bezpečnostní pokyny (SG). Dohromady obsahují 47 požadavků.

Jaký je rozdíl mezi IEC 62443-4-1 a 62443-4-2?

4-1 se týká procesu, kterým dodavatel vyvíjí a udržuje produkty. 4-2 stanoví technické bezpečnostní požadavky na samotné komponenty, například vestavěná zařízení, síťová zařízení, hostitelská zařízení a softwarové aplikace. Dodavatel se obvykle posuzuje podle 4-1 za svůj vývojový proces a podle 4-2 za konkrétní produkt.

Které postupy IEC 62443-4-1 pokrývají správu zranitelností?

Hlavně postup 6, řízení problémů souvisejících s bezpečností (DM-1 až DM-6), který pokrývá přijímání, posuzování, vyhodnocování, řešení a zveřejňování bezpečnostních problémů, a postup 7, řízení bezpečnostních aktualizací (SUM-1 až SUM-5), který pokrývá kvalifikaci, dokumentaci a včasné dodávání bezpečnostních aktualizací. To je práce, kterou dělá PSIRT.

Jaké úrovně vyspělosti IEC 62443-4-1 rozlišuje?

Čtyři úrovně založené na CMMI for Development: ML1 Initial (ad hoc nebo nezdokumentované), ML2 Managed (zdokumentované procesy), ML3 Defined neboli Practiced (zdokumentované, prováděné a opakovatelné) a ML4 Improving (procesy zlepšované v čase pomocí metrik výkonnosti).

Jak získat certifikaci IEC 62443-4-1?

Prostřednictvím akreditovaného certifikačního orgánu. Program SDLA od ISASecure certifikuje vývojové organizace podle IEC 62443-4-1 prostřednictvím autorizovaných laboratoří a certifikační orgány jako TÜV Rheinland a Applus+ vydávají certifikáty 62443-4-1, které uvádějí dosaženou úroveň vyspělosti, a to i v rámci schématu IECEE CB.

Vyžaduje IEC 62443-4-1 SBOM?

Názvy požadavků z roku 2018 SBOM nezmiňují. Několik požadavků se týká externě dodaných komponent a aktualizací závislých komponent a operačních systémů a spolehlivý seznam komponent v každém vydání je praktický způsob, jak doložit, jak s nimi zacházíte.

Zjistěte, které dodané buildy obsahují zranitelnou komponentu

Řízení bezpečnostních problémů začíná znalostí obsahu každého vydání. Rezervujte si demo a podívejte se na to ze záznamu toho, co každý build, včetně buildů Yocto, stáhl.

Rezervujte si demo