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