IEC 62443-4-1: bezpieczny cykl rozwoju produktów przemysłowych

Czym jest IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, ukazał się w styczniu 2018 roku. Zgodnie z własnym zakresem standard określa wymagania procesowe dotyczące bezpiecznego rozwoju produktów używanych w przemysłowych systemach automatyki i sterowania. Definiowany przez niego cykl życia obejmuje definiowanie wymagań bezpieczeństwa, bezpieczne projektowanie, bezpieczną implementację, weryfikację i walidację, zarządzanie defektami, zarządzanie poprawkami oraz koniec życia produktu.

Dotyczy on podmiotu, który rozwija i utrzymuje produkt: dostawcy produktu wytwarzającego sterowniki, urządzenia wbudowane, sprzęt sieciowy, oprogramowanie hostów lub aplikacje. Nie dotyczy integratora ani użytkownika produktu, którzy mają własne części serii. ISA publikuje tę serię jako ISA/IEC 62443.

Standard opisuje wymagania procesowe, polityki i procedury, a nie techniczne funkcje bezpieczeństwa. Wymagania techniczne dla komponentów znajdują się w IEC 62443-4-2.

Osiem praktyk IEC 62443-4-1

Wymagania są pogrupowane w osiem praktyk, z których każda ma krótki skrót poprzedzający identyfikatory jej wymagań. ISA Global Cybersecurity Alliance wymienia łącznie 47 wymagań:

Praktyka	Wymagania	Co obejmuje
1. Zarządzanie bezpieczeństwem (SM)	SM-1 do SM-13	Planowanie i prowadzenie procesu bezpieczeństwa: odpowiedzialność, wiedza specjalistyczna, bezpieczeństwo środowiska rozwojowego, klucze prywatne, komponenty dostarczane z zewnątrz i komponenty stron trzecich, weryfikacja procesu, ciągłe doskonalenie
2. Specyfikacja wymagań bezpieczeństwa (SR)	SR-1 do SR-5	Kontekst bezpieczeństwa produktu, model zagrożeń, wymagania bezpieczeństwa produktu i ich przegląd
3. Bezpieczeństwo na etapie projektowania (SD)	SD-1 do SD-4	Zasady bezpiecznego projektowania, projektowanie obrony w głąb, przegląd projektu, dobre praktyki projektowe
4. Bezpieczna implementacja (SI)	SI-1 do SI-2	Przegląd implementacji pod kątem bezpieczeństwa i standardy bezpiecznego kodowania
5. Testy weryfikacji i walidacji bezpieczeństwa (SVV)	SVV-1 do SVV-5	Testy wymagań, testy ograniczania zagrożeń, testy podatności, testy penetracyjne, niezależność testerów
6. Zarządzanie problemami związanymi z bezpieczeństwem (DM)	DM-1 do DM-6	Przyjmowanie, przegląd, ocena, rozwiązywanie i ujawnianie problemów bezpieczeństwa w produkcie
7. Zarządzanie aktualizacjami bezpieczeństwa (SUM)	SUM-1 do SUM-5	Kwalifikowanie, dokumentowanie i terminowe dostarczanie aktualizacji bezpieczeństwa
8. Wytyczne bezpieczeństwa (SG)	SG-1 do SG-7	Dokumentacja użytkownika dotycząca obrony w głąb, utwardzania, bezpiecznej eksploatacji, zarządzania kontami i utylizacji

Praktyka 6: zarządzanie problemami związanymi z bezpieczeństwem (DM)

DM to praktyka, którą PSIRT rozpozna jako własną. Według ISAGCA jej procesy służą do obsługi problemów bezpieczeństwa produktu skonfigurowanego zgodnie z jego strategią obrony w głąb. Sześć wymagań prowadzi problem od zgłoszenia do zamknięcia:

• DM-1: Przyjmowanie powiadomień o problemach związanych z bezpieczeństwem
• DM-2: Przegląd problemów związanych z bezpieczeństwem
• DM-3: Ocena problemów związanych z bezpieczeństwem
• DM-4: Rozwiązywanie problemów związanych z bezpieczeństwem
• DM-5: Ujawnianie problemów związanych z bezpieczeństwem
• DM-6: Okresowy przegląd praktyki zarządzania defektami bezpieczeństwa

Mówiąc prosto: przyjąć zgłoszenia, sprawdzić je, ocenić, naprawić, poinformować użytkowników i przejrzeć sam proces.

Ta sekwencja to cykl życia zarządzania podatnościami pod inną nazwą, a DM-1 i DM-5 to miejsca, w których pojawia się skoordynowane ujawnianie podatności. Ujawnienie można opublikować jako biuletyn CSAF, z oświadczeniem VEX dla wersji, których problem nie dotyczy.

Praktyka 7: zarządzanie aktualizacjami bezpieczeństwa (SUM)

SUM przejmuje pałeczkę tam, gdzie DM decyduje o poprawce. Jej procesy, w podsumowaniu ISAGCA, zapewniają, że aktualizacje bezpieczeństwa sprzętu, oprogramowania lub firmware'u produktu są testowane pod kątem regresji i terminowo udostępniane użytkownikom. Pięć wymagań to:

• SUM-1: Kwalifikacja aktualizacji bezpieczeństwa
• SUM-2: Dokumentacja aktualizacji bezpieczeństwa
• SUM-3: Dokumentacja aktualizacji bezpieczeństwa komponentów zależnych lub systemu operacyjnego
• SUM-4: Dostarczanie aktualizacji bezpieczeństwa
• SUM-5: Terminowe dostarczanie poprawek bezpieczeństwa

SUM-3 to wymaganie sięgające do Państwa łańcucha dostaw: aktualizacje komponentów i systemów operacyjnych, od których zależy produkt. W przypadku produktu wbudowanego opartego na dystrybucji Linuksa może to być większość dostarczanych przez Państwa poprawek.

Poziomy dojrzałości

IEC 62443-4-1 nie pyta, czy proces istnieje; pyta, jak bardzo jest dojrzały. Stosuje cztery poziomy dojrzałości oparte na CMMI for Development:

Poziom	Znaczenie
ML1 Initial	Procesy są wykonywane doraźnie lub nie są udokumentowane
ML2 Managed	Procesy są udokumentowane i opisują, jak działanie jest realizowane i jak się nim zarządza
ML3 Defined (Practiced)	Procesy są udokumentowane, wykonywane i powtarzalne
ML4 Improving	Procesy są z czasem ulepszane na podstawie wskaźników wydajności i skuteczności

Różnicą między ML2 a ML3 jest praktyka. Spisany proces DM może być na poziomie ML2. ML3 oznacza, że proces został wykonany i powtórzony: problemy przyjęto, oceniono i zamknięto, aktualizacje dostarczono, a zapisy to potwierdzają.

Certyfikacja

• ISASecure SDLA. Program Security Development Lifecycle Assurance certyfikuje proces cyklu życia organizacji rozwojowej na zgodność z IEC 62443-4-1. Oceny przeprowadzają uprawnione laboratoria SDLA akredytowane jako jednostki oceny zgodności.
• Jednostki certyfikujące i IECEE CB Scheme. Jednostki badawcze i certyfikujące, takie jak Applus+ i TÜV Rheinland, oceniają dostawców względem 62443-4-1 i podają osiągnięty poziom dojrzałości, także w ramach IECEE CB Scheme, który ma zastosowanie w ponad 50 krajach.

Certyfikat 62443-4-1 obejmuje proces rozwoju dostawcy, a nie pojedynczy produkt. Produkty są oceniane osobno względem 62443-4-2.

Jak 62443-4-1 ma się do reszty serii

• IEC 62443-4-2, techniczne wymagania bezpieczeństwa dla komponentów IACS: co produkt musi potrafić. 4-1 to sposób, w jaki go Państwo budują i utrzymują.
• IEC 62443-3-3, wymagania bezpieczeństwa systemu i poziomy bezpieczeństwa: odpowiednik wymagań technicznych na poziomie systemu.
• IEC 62443-2-4, wymagania programu bezpieczeństwa dla dostawców usług IACS: integratorów i dostawców usług utrzymania, którzy instalują i serwisują Państwa produkt w zakładzie właściciela zasobu i którzy polegają na Państwa aktualizacjach bezpieczeństwa i wytycznych.

Mapowanie IEC 62443-4-1 na pracę PSIRT

Działanie PSIRT	Miejsce w 62443-4-1
Przyjmowanie zgłoszeń podatności	DM-1
Triaż i analiza	DM-2, DM-3
Usuwanie podatności	DM-4, SUM-1
Biuletyny i ujawnianie	DM-5, SUM-2
Poprawki komponentów zewnętrznych	SUM-3, wraz z SM-9 i SM-10 dotyczącymi komponentów dostarczanych z zewnątrz i komponentów stron trzecich
Wydanie poprawki	SUM-4, SUM-5
Wskaźniki i przegląd procesu	DM-6, SM-13

To mapowanie jest nasze, oparte na tytułach wymagań. Standard nie wymienia PSIRT z nazwy; tę samą pracę opisują PSIRT Services Framework organizacji FIRST oraz ISO/IEC 30111.

SBOM-y jako dowód dla DM i SUM

Tytuły wymagań z 2018 roku nie wspominają o SBOM-ach. Jednak wiele problemów bezpieczeństwa w produkcie przemysłowym znajduje się w komponentach, których dostawca nie napisał: w jądrze Linuksa, OpenSSL, BusyBox, stosie protokołów. Odpowiedź na DM-2 i DM-3 przy nowym biuletynie oznacza wiedzę o tym, które produkty i wersje zawierają dany komponent. Dokumentowanie aktualizacji SUM-3 oznacza wiedzę o tym, z jakimi wersjami komponentów dostarczono każde wydanie. Na poziomie ML3 za tymi odpowiedziami muszą stać zapisy.

Lista komponentów pisana ręcznie lub skan drzewa źródeł dezaktualizuje się. SBOM z buildu, który wytworzył wydanie, nie dezaktualizuje się, o ile sam build jest rejestrowany.

Gdzie wpisuje się CRACI

CRACI niczego nie certyfikuje w ramach IEC 62443 i nie prowadzi Państwa procesu rozwoju. Jego zapisy mogą służyć jako dowody dla części tego procesu: inwentarza komponentów w każdym wydaniu oraz monitorowania dostarczonych buildów pod kątem nowych podatności.

CRACI uruchamia buildy GitHub Actions, łącznie z buildami Yocto, na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache i zależnościami, których nie wymienia żaden lockfile. Każdy SBOM ma określony stan kompletności i można go eksportować w formacie CycloneDX lub SPDX. Monitorowane SBOM-y są stale ponownie oceniane, historia buildów pokazuje, które wcześniejsze buildy zawierały podatną zależność, a widok inwentarza pokazuje, które wersje są wdrożone w których produktach. SBOM-y dostawców dla komponentów kupowanych są monitorowane razem z Państwa własnymi buildami. Zob. śledzenie podatności i CRACI dla zespołów PSIRT.

IEC 62443-4-1: najczęściej zadawane pytania

Czym jest IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, to część serii IEC 62443 określająca wymagania procesowe dla dostawców rozwijających produkty używane w przemysłowych systemach automatyki i sterowania. Obejmuje wymagania bezpieczeństwa, bezpieczne projektowanie, implementację, weryfikację i walidację, zarządzanie defektami, zarządzanie poprawkami oraz koniec życia produktu.

Jakich osiem praktyk obejmuje IEC 62443-4-1?

Zarządzanie bezpieczeństwem (SM), specyfikacja wymagań bezpieczeństwa (SR), bezpieczeństwo na etapie projektowania (SD), bezpieczna implementacja (SI), testy weryfikacji i walidacji bezpieczeństwa (SVV), zarządzanie problemami związanymi z bezpieczeństwem (DM), zarządzanie aktualizacjami bezpieczeństwa (SUM) oraz wytyczne bezpieczeństwa (SG). Łącznie obejmują 47 wymagań.

Jaka jest różnica między IEC 62443-4-1 a 62443-4-2?

4-1 dotyczy procesu, którego dostawca używa do rozwijania i utrzymywania produktów. 4-2 określa techniczne wymagania bezpieczeństwa dla samych komponentów, takich jak urządzenia wbudowane, urządzenia sieciowe, urządzenia hostów i aplikacje. Dostawca jest zwykle oceniany względem 4-1 pod kątem procesu rozwoju, a względem 4-2 pod kątem konkretnego produktu.

Które praktyki IEC 62443-4-1 obejmują zarządzanie podatnościami?

Przede wszystkim praktyka 6, zarządzanie problemami związanymi z bezpieczeństwem (DM-1 do DM-6), która obejmuje przyjmowanie, przegląd, ocenę, rozwiązywanie i ujawnianie problemów bezpieczeństwa, oraz praktyka 7, zarządzanie aktualizacjami bezpieczeństwa (SUM-1 do SUM-5), która obejmuje kwalifikowanie, dokumentowanie i terminowe dostarczanie aktualizacji bezpieczeństwa. To praca wykonywana przez PSIRT.

Jakie są poziomy dojrzałości IEC 62443-4-1?

Cztery poziomy oparte na CMMI for Development: ML1 Initial (działania doraźne lub nieudokumentowane), ML2 Managed (udokumentowane procesy), ML3 Defined lub Practiced (udokumentowane, wykonywane i powtarzalne) oraz ML4 Improving (procesy ulepszane z czasem na podstawie wskaźników wydajności).

Jak uzyskać certyfikat IEC 62443-4-1?

Przez akredytowaną jednostkę certyfikującą. Program SDLA organizacji ISASecure certyfikuje organizacje rozwojowe na zgodność z IEC 62443-4-1 przez uprawnione laboratoria, a jednostki certyfikujące, takie jak TÜV Rheinland i Applus+, wydają certyfikaty 62443-4-1 podające osiągnięty poziom dojrzałości, także w ramach IECEE CB Scheme.

Czy IEC 62443-4-1 wymaga SBOM?

Tytuły wymagań z 2018 roku nie wspominają o SBOM-ach. Kilka wymagań dotyczy komponentów dostarczanych z zewnątrz oraz aktualizacji komponentów zależnych i systemów operacyjnych, a wiarygodna lista komponentów w każdym wydaniu to praktyczny sposób, aby pokazać, jak Państwo to obsługują.