IEC 62443-4-1: dlaczego bezpieczne wytwarzanie oprogramowania staje się wymogiem w produkcji

Przez większą część ostatniej dekady o IEC 62443-4-1 słyszało się głównie od dużych dostawców automatyki - tych z certyfikatem na stronie i osobnym zespołem ds. bezpieczeństwa produktu. Dla producenta maszyn piszącego własny HMI albo zakładu z wewnętrznym oprogramowaniem komunikującym się ze sterownikiem PLC norma wygodnie mieściła się w kolumnie „fajnie mieć, może później“.

Ta kolumna właśnie się zamyka. Trzy unijne akty prawne zbiegają się w tym samym pytaniu - czy potrafisz wykazać, że oprogramowanie w Twoim produkcie zostało wytworzone bezpiecznie i że nadal będziesz utrzymywać je w bezpiecznym stanie? - a IEC 62443-4-1 jest najszerzej uznawaną odpowiedzią na to pytanie w świecie przemysłowym.

1. Czym właściwie jest IEC 62443-4-1

IEC 62443 to rodzina norm dotyczących bezpieczeństwa przemysłowych systemów automatyki i sterowania. Większość z nich opisuje, jak operator zabezpiecza zakład albo jakie możliwości techniczne musi mieć komponent. Część 4-1 jest inna: w ogóle nie opisuje produktu. Opisuje proces, którym dostawca go wytwarza i utrzymuje - bezpieczny cykl życia oprogramowania (SDL).

Jest podzielona na osiem praktyk:

• Zarządzanie bezpieczeństwem - kto odpowiada za bezpieczeństwo produktu, jak szkolony jest zespół, jak kontrolowany jest sam proces
• Specyfikacja wymagań bezpieczeństwa - model zagrożeń i wymagania bezpieczeństwa, które istnieją, zanim powstanie kod
• Secure by design - obrona w głąb, minimalna powierzchnia ataku, architektura poddana przeglądowi bezpieczeństwa
• Bezpieczna implementacja - standardy kodowania, analiza statyczna, przegląd każdej zmiany
• Weryfikacja i walidacja bezpieczeństwa - testy wymagań, fuzzing, skanowanie podatności, testy penetracyjne
• Zarządzanie problemami bezpieczeństwa - przyjmowanie, ocena i naprawa zgłoszeń podatności, również z zewnątrz
• Zarządzanie aktualizacjami bezpieczeństwa - terminowe, udokumentowane i podpisane poprawki
• Wytyczne bezpieczeństwa - dokumentacja, która mówi integratorowi i operatorowi, jak bezpiecznie wdrożyć i eksploatować produkt

Każda praktyka oceniana jest na poziomie dojrzałości od 1 (doraźnie) do 4 (ciągłe doskonalenie), więc norma jest czymś, do czego się dorasta, a nie checkboxem typu zaliczone/niezaliczone.

2. Cyber Resilience Act zamienia „fajnie mieć“ w prawo

Unijny Cyber Resilience Act (CRA) obejmuje praktycznie każdy produkt z elementami cyfrowymi wprowadzany na rynek UE - w tym sterowniki przemysłowe, oprogramowanie maszyn, HMI, bramy i aplikacje PC, które nimi sterują. Pierwsze obowiązki już obowiązują: od 11 września 2026 producenci muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty do ENISA i krajowego CSIRT, z wczesnym ostrzeżeniem w ciągu 24 godzin. Pełny zakres wymagań obowiązuje od 11 grudnia 2027.

Wystarczy położyć załącznik I do CRA obok IEC 62443-4-1, żeby zobaczyć, jak bardzo się pokrywają: bezpieczeństwo oparte na ocenie ryzyka, bezpieczna konfiguracja domyślna, wykaz komponentów oprogramowania (SBOM), niezwłoczna obsługa podatności, polityka skoordynowanego ujawniania, aktualizacje bezpieczeństwa oddzielone od funkcjonalnych i dokumentacja dla użytkownika. To te same tematy co osiem praktyk powyżej - CRA mówi, co musi być spełnione, a 62443-4-1 opisuje, jak zorganizować zespół, żeby było spełnione stale.

Dlatego europejskie prace normalizacyjne pod CRA w przypadku produktów przemysłowych tak mocno opierają się na IEC 62443. Niezależnie od tego, jak ostatecznie będą nazywać się normy zharmonizowane, zespół pracujący już zgodnie z 62443-4-1 będzie mapował istniejące dowody, a nie zaczynał od zera. Koszt błędu też nie jest teoretyczny: naruszenie zasadniczych wymagań CRA może oznaczać kary do 15 mln € lub 2,5% światowego obrotu - i, co bardziej bolesne, produkty, których nie można legalnie sprzedawać w UE.

3. Rozporządzenie maszynowe dokłada aspekt bezpieczeństwa funkcjonalnego

Od 20 stycznia 2027 nowe unijne rozporządzenie maszynowe zastępuje dyrektywę maszynową. Po raz pierwszy jego zasadnicze wymagania w zakresie ochrony zdrowia i bezpieczeństwa wprost obejmują ochronę przed uszkodzeniem - w tym złośliwymi próbami z zewnątrz - i wymagają, by układy sterowania związane z bezpieczeństwem były odporne na zamierzoną i niezamierzoną manipulację, a zmiany w oprogramowaniu były rejestrowane i identyfikowalne.

Innymi słowy, słabość cyberbezpieczeństwa w oprogramowaniu maszyny jest teraz potencjalną niezgodnością w zakresie bezpieczeństwa i trafia prosto w oznakowanie CE. Dla producenta maszyn „przetestowaliśmy przed wysyłką“ nie będzie przekonującą odpowiedzią na ten wymóg. Udokumentowany, powtarzalny proces wytwarzania - będzie.

4. NIS2 przenosi to w dół łańcucha dostaw

Dotyczy to nawet producentów, którzy w ogóle nie sprzedają oprogramowania. Art. 21 NIS2 wymaga od podmiotów objętych dyrektywą zarządzania bezpieczeństwem łańcucha dostaw oraz zapewnienia bezpieczeństwa przy nabywaniu, rozwoju i utrzymaniu systemów, w tym obsługi i ujawniania podatności. W praktyce staje się to pytaniem zakupowym: jakie dowody ma Twój dostawca, że oprogramowanie działające na Twojej linii jest wytwarzane i utrzymywane bezpiecznie?

Już teraz widzimy, jak zgodność z IEC 62443-4-1 - albo oparty na niej certyfikat ISASecure SDLA lub IECEE - pojawia się w zapytaniach ofertowych i ankietach dla dostawców. Dostawca, który odpowie opisem procesu, SBOM-em i polityką obsługi podatności, wygrywa tę rozmowę. Ten, który ma do zaoferowania tylko zeszłoroczny raport z pentestu, zwykle nie.

5. Dlaczego pentest już nie wystarcza

Jednorazowy audyt bezpieczeństwa jest cenny - często dopiero dzięki niemu wiadomo, gdzie się naprawdę jest. Ale opisuje jedną wersję oprogramowania jednego dnia. Wszystkie powyższe regulacje dotyczą cyklu życia: co dzieje się z kolejnym wydaniem, kolejną aktualizacją zależności, kolejnym CVE w bibliotece, o której nie wiedziałeś, że ją dostarczasz.

Dokładnie to formalizuje IEC 62443-4-1. W naszych własnych audytach bezpieczeństwa oprogramowania przemysłowego same znaleziska są tylko połową rezultatu. Drugą połową jest wpięcie analizy statycznej, skanowania zależności, analizy kodu natywnego i generowania SBOM w każdy pull request, tak żeby kolejne wydanie było sprawdzane automatycznie, zamiast czekać na następny audyt.

Od czego zacząć

Nikt nie osiąga 3. poziomu dojrzałości w kwartał i nikt nie musi zaczynać od audytu certyfikacyjnego. Praktyczna ścieżka dla producenta lub producenta maszyn wygląda tak:

1. Zinwentaryzuj produkty z elementami cyfrowymi - łącznie z „małymi“ narzędziami wewnętrznymi, które rozmawiają z PLC. Zwykle to one są najsłabiej chronione.
2. Przeprowadź analizę luk względem ośmiu praktyk, uczciwie ocenioną według poziomów dojrzałości. Większość zespołów odkrywa, że bezpieczna implementacja i weryfikacja częściowo istnieją, a brakuje wymagań bezpieczeństwa, zarządzania problemami i dokumentacji dla użytkownika.
3. Najpierw zautomatyzuj to, co da się zautomatyzować - SAST, skanowanie zależności i generowanie SBOM w CI są tanie, szybkie we wdrożeniu i bezpośrednio wytwarzają dowody, których wymaga CRA.
4. Uruchom obsługę podatności teraz, nie w 2027: kontakt do zgłoszeń, proces triażu i osobę, która potrafi złożyć zgłoszenie w 24 godziny. W ramach CRA ta część już obowiązuje.
5. Zapisuj, co robisz - modele zagrożeń, wymagania bezpieczeństwa, protokoły przeglądów, informacje o wydaniach. W 62443-4-1 nieudokumentowany proces traktowany jest tak samo jak brakujący.

Okno między „zalecane“ a „wymagane“ jest krótkie i już się zamyka. Zespoły, które zaczną budować bezpieczny proces wytwarzania teraz, dotrą do terminów z 2027 roku z dowodami, które gromadzą od roku. Pozostałe będą próbowały odtworzyć je pod presją - a to dokładnie ten rodzaj pracy, której wolelibyśmy producentom oszczędzić.