Połączenie oprogramowania OEE z siecią PLC zakładu produkcyjnego tworzy nową ścieżkę danych między środowiskami technologii operacyjnej (OT) i informatycznej (IT).
W większości zakładów sieci OT są celowo odizolowane od korporacyjnych sieci IT, aby chronić systemy produkcyjne przed zagrożeniami cyberbezpieczeństwa, naruszenie bezpieczeństwa PLC w środowisku produkcyjnym stanowi ryzyko dla bezpieczeństwa i ciągłości działalności, a nie tylko ryzyko związane z ochroną danych.
Każde oprogramowanie przekraczające tę granicę OT, IT, w tym platformy OEE, wymaga rygorystycznej oceny bezpieczeństwa przed wdrożeniem. Krajobraz bezpieczeństwa oprogramowania OEE znacznie się poprawił w ciągu ostatnich pięciu lat, ale różnice między dostawcami są duże.
Platformy OEE natywne dla chmury, oparte na nowoczesnych architekturach bezpieczeństwa, mają zasadniczo inny profil bezpieczeństwa niż systemy OEE instalowane lokalnie, tworzone w latach 2000., które nie były projektowane z myślą o zabezpieczeniu granicy OT, IT. Pytania zadawane w ocenie bezpieczeństwa powinny ujawnić te różnice i dostarczyć udokumentowanych dowodów dotyczących postawy bezpieczeństwa dostawcy, które zespoły ds.
bezpieczeństwa IT i OT będą mogły przejrzeć przed zatwierdzeniem łączności sieciowej. Konsekwencje niedostatecznej oceny bezpieczeństwa OEE wahają się od drobnych, nieautoryzowanego dostępu do danych lub problemów z przestrzeganiem przepisów dotyczących prywatności, po poważne, np. oprogramowanie ransomware przedostające się do sieci OT przez skompromitowany serwer OEE i zakłócające procesy produkcyjne.
Biorąc pod uwagę, że oprogramowanie OEE jest podłączone do urządzeń produkcyjnych na każdej linii, skompromitowana platforma OEE ma szerszy dostęp do sieci niż większość systemów IT łączących się ze środowiskiem OT. Taki podwyższony profil ryzyka uzasadnia bardziej wnikliwą ocenę bezpieczeństwa niż standardowe przeglądy oprogramowania korporacyjnego.
Pytania dotyczące architektury i przepływu danych: (1) Czy platforma OEE używa jednokierunkowej architektury przepływu danych z OT do IT (tylko do odczytu z PLC), czy też ma możliwość komunikacji dwukierunkowej? (2) Gdzie przechowywane są dane produkcyjne, lokalnie (on-premise), w określonym regionie chmurowym, czy w współdzielonej chmurze wielodostępowej (multi-tenant)?
(3) Czy serwer OEE jest umieszczony w strefie DMZ między sieciami OT i IT, czy wymaga bezpośredniego dostępu do obu sieci jednocześnie? (4) Jakie porty sieciowe i protokoły muszą być otwarte między sieciami OT i IT dla platformy OEE?
(5) Czy platforma OEE wspiera wdrożenie bez jakichkolwiek połączeń przychodzących z internetu (odizolowane fizycznie/air‑gapped lub lokalne wdrożenie on‑premise)? Pytania dotyczące uwierzytelniania i kontroli dostępu: (6) Czy platforma obsługuje SAML 2.0 lub OIDC w celu integracji z firmowym Single Sign‑On (SSO)?
(7) Czy obsługiwane jest uwierzytelnianie wieloskładnikowe (MFA) i czy można je wymusić dla wszystkich ról użytkowników? (8) Czy platforma wdraża kontrolę dostępu opartą na rolach (RBAC), która ogranicza dostęp do danych w oparciu o zakład, linię i funkcję?
(9) Czy istnieją oddzielne dane uwierzytelniające administratora dla aplikacji OEE i dla leżącej u podstaw infrastruktury (baza danych, system operacyjny)? (10) Jak zarządzane i rotowane są klucze API oraz dane uwierzytelniające kont serwisowych? Pytania dotyczące bezpieczeństwa danych: (11) Czy dane są szyfrowane w tranzycie przy użyciu TLS 1.2 lub nowszego dla wszystkich połączeń?
(12) Czy dane są szyfrowane w stanie spoczynku (at rest) i jaki standard szyfrowania jest stosowany? (13) Jakie dane produkcyjne są wysyłane do chmury, a jakie przechowywane lokalnie (on‑premise)? (14) Czy platforma rejestruje wszystkie zdarzenia dostępu użytkowników oraz działania eksportu danych w dzienniku audytu dostępnym dla klienta?
(15) Jaka jest polityka przechowywania danych i proces usuwania danych po rozwiązaniu umowy przez klienta? Pytania dotyczące zarządzania podatnościami i reagowania na incydenty: (16) Jaki jest proces dostarczania poprawek bezpieczeństwa przez dostawcę i jaki jest typowy czas od ujawnienia podatności do udostępnienia poprawki?
(17) Czy dostawca przeprowadził zewnętrzny test penetracyjny w ciągu ostatnich 12 miesięcy i czy dostępne jest streszczenie wyników? (18) Czy dostawca opublikował politykę ujawniania podatności oraz posiada dedykowany kontakt ds. bezpieczeństwa? (19) Jaki jest SLA dostawcy dotyczący reagowania na incydenty w przypadku wykrycia naruszenia bezpieczeństwa wpływającego na dane klienta?
(20) Czy dostawca posiada odpowiednie certyfikaty bezpieczeństwa (ISO 27001, SOC 2 Type II) obejmujące infrastrukturę platformy OEE?
Oceniając odpowiedzi dostawców na kwestionariusz bezpieczeństwa, szukaj konkretów zamiast ogólników. Dostawca, który na pytanie "czy dane są szyfrowane podczas przesyłu?" odpowie "tak, używamy szyfrowania zgodnego ze standardami branżowymi", jest mniej wiarygodny niż ten, który odpowie "tak, cała komunikacja korzysta z TLS 1.3 z przypinaniem certyfikatu w aplikacjach mobilnych." Niejasne, pozytywne twierdzenia łatwo wygłosić; konkretne, techniczne stwierdzenia trudniej sfałszować i łatwiej zweryfikować.
Traktuj niektóre odpowiedzi jako twarde warunki, które muszą zostać rozwiązane przed zatwierdzeniem wdrożenia. Należą do nich: dwukierunkowa komunikacja sieciowa z systemów OT do chmury dostawcy (tworzy powierzchnię ataku od zewnątrz) brak wsparcia dla uwierzytelniania wieloskładnikowego (MFA) przy dostępie administratorskim (nieakceptowalne dla systemów połączonych z OT) przechowywanie danych w jurysdykcji niezgodnej z wymaganiami dotyczącymi suwerenności danych
brak testu penetracyjnego wykonanego przez stronę trzecią w ciągu ostatnich 18 miesięcy oraz brak udokumentowanego procesu reagowania na incydenty. To nie są przedmioty do negocjacji, to podstawowe wymagania bezpieczeństwa, których wymaga odpowiedzialne zabezpieczenie sieci OT.
Włącz wymagania bezpieczeństwa, które dostawcy muszą spełnić, do umowy zakupu przed jej podpisaniem.
Uwzględnij konkretne zapisy obejmujące: obowiązek powiadomienia, jeśli dostawca wykryje incydent bezpieczeństwa dotyczący twoich danych; prawo do przeprowadzenia własnej rocznej oceny bezpieczeństwa platformy; obowiązek dostawcy usunięcia krytycznych podatności w ciągu 30 dni; oraz prawo klienta do rozwiązania umowy bez ponoszenia kar, jeśli dostawca nie wywiąże się ze zobowiązań dotyczących bezpieczeństwa.
Wymagania bezpieczeństwa, które nie są zawarte w umowie, to sugestie, wymagania umowne to zobowiązania, które dają środki zaradcze w razie ich naruszenia.
Zaloguj
Blog
