Bezpieczeństwo OT zaczyna się od hardware’u – podkreśla Błażej Pawlak

Cyberbezpieczeństwo systemów OT (Operational Technology) – począwszy od farm fotowoltaicznych, przez elektrociepłownie, po urządzenia embedded – przestało być niszowym problemem inżynierów automatyki. Stało się realnym czynnikiem stabilności państwa oraz codziennego życia obywateli.

O tym, dlaczego bezpieczeństwa OT nie da się „dodać” na końcu w software, rozmawiałam z Błażejem Pawlakiem – inżynierem oprogramowania i architektem systemów, specjalizującym się w bezpieczeństwie, kryptografii oraz projektowaniu rozwiązań dla środowisk regulowanych i infrastruktury krytycznej.

Błażej Pawlak, inżynier oprogramowania i architekt systemów

OT jest bliżej nas, niż myślimy

W powszechnym wyobrażeniu OT kojarzy się z fabrykami i ciężkim przemysłem. W rzeczywistości ten świat jest znacznie bliżej. Operational Technology to systemy sterujące procesami fizycznymi: w energetyce, ciepłownictwie, transporcie, OZE, magazynach energii i inwerterach, ale także w automatyce budynkowej, z której codziennie korzysta rosnąca grupa prosumentów. Inżynierowie, którzy hobbystycznie budują w domu systemy alarmowe, sterowniki ogrzewania podłogowego czy mechanizmy podnoszenia rolet, a do tego korzystają z paneli fotowoltaicznych, magazynów energii i inwerterów zarządzanych zdalnie przez aplikację w telefonie – też są dziś uczestnikami ekosystemu OT.

Problem zaczyna się wtedy, gdy urządzenie odpowiedzialne za proces fizyczny staje się jednocześnie urządzeniem sieciowym. Jeśli pracuje na Linuksie, ma zdalny dostęp, interfejs administracyjny, możliwość aktualizacji i komunikacji z aplikacją mobilną, do świata OT przenosi się znacząca część krajobrazu zagrożeń dobrze znanego z IT. Kontrola zdalnego dostępu nie jest wtedy funkcją dodatkową – staje się mechanizmem przetrwania systemu.

– Podczas mojej pracy w IBM w Kopenhadze, w dziale kryptografii stosowanej, pracowaliśmy z klientami utrzymującymi bardzo złożone środowiska. W takich projektach widać było, że programiści często skupiają się przede wszystkim na funkcjonalności i uznają, że aby spełnić wymagania bezpieczeństwa, wystarczy wygenerować dobre hasło – wspomina Błażej Pawlak. – Tylko że w przemysłowych rozwiązaniach, gdzie istnieją środowiska testowe i produkcyjne, kryptograficznych kluczy dostępu jest bardzo dużo: setki tysięcy, a nawet miliony. Bezpieczeństwo nie jest tam wyłącznie kwestią algorytmów, ale również procedur i interakcji człowieka z komputerem. To właśnie człowiek bywa najsłabszym ogniwem.

W OT celem nie są dane, tylko proces i ciągłość działania

– W IT walczymy o dane i o dostęp. W OT stawką jest ciągłość procesu, bezpieczeństwo ludzi i stabilność usług. Jeżeli problem dotyczy elektrociepłowni, ludziom robi się zimno. Jeżeli dotyczy transportu – ktoś może utknąć w środku systemu, który przestaje działać.

Różnica między IT a OT nie polega tylko na używanych technologiach. Chodzi przede wszystkim o konsekwencje incydentu. W klasycznym środowisku IT atak oznacza zwykle wyciek danych, utratę dostępu lub przestój biznesowy. W OT skutki przekładają się na zakłócenie dostaw energii, ciepła, działania transportu lub usług krytycznych.

Stąd w tym obszarze tak ważne jest odrzucenie myślenia w stylu „security through obscurity” – założenia, że atakujący nie zna architektury naszego systemu, więc nie znajdzie sposobu, by go przejąć. Co istotne, wiele ataków na OT nie wymaga zaawansowanych exploitów typu zero-day – czyli podatności, o których istnieniu nikt jeszcze nie wie poza ich autorem. Jeżeli atakujący uzyska właściwy poziom dostępu, może używać legalnych funkcji systemu i poprawnych komend protokołów przemysłowych.

– W energetyce czy przemyśle motoryzacyjnym błędem jest przekonanie, że nikt z zewnątrz nie wie, jak zbudowana jest fabryka i jakich systemów używamy do jej ochrony – mówi Błażej Pawlak. – „Ja Ci nic nie powiem, a Ty się nie domyślisz” to bardzo zły fundament. Wcześniej czy później ktoś przeanalizuje ścieżki dostępu i zhakuje system. Atakujący może wysyłać poprawne komendy protokołem przemysłowym – żaden zero-day nie jest mu do tego potrzebny.

Współczesny łańcuch ataku: od IT do OT

W praktyce atak na środowisko OT rzadko zaczyna się od samego urządzenia przemysłowego. Punkt wejścia znajduje się zwykle wcześniej: w słabo zabezpieczonym dostępie zdalnym, źle zabezpieczonym urządzeniu brzegowym, źle skonfigurowanym pulpicie zdalnym albo poświadczeniach używanych w wielu miejscach.

Najczęściej powtarzające się słabości w łańcuchu IT → OT to:

• domyślne lub współdzielone poświadczenia,
• brak uwierzytelniania wieloskładnikowego (MFA),
• niewystarczająca segmentacja sieci,
• zbyt szeroki zdalny dostęp do systemów i urządzeń,
• ograniczona audytowalność – brak logów lub brak ich przeglądu.

– Software nie obroni systemu, który ufa wszystkiemu, co się na nim uruchamia – zaznacza Błażej Pawlak. – Jeżeli ktoś dostanie się do odpowiedniego miejsca w łańcuchu dostępu, może wejść dalej: przez VPN, system pośredniczący, HMI, SCADA, aż do urządzeń sterujących procesem – inwerterów, sterowników, regulatorów. Dlatego bezpieczeństwo OT trzeba rozpatrywać warstwowo: od architektury dostępu i segmentacji sieci, przez kontrolę tożsamości, aż po sposób, w jaki samo urządzenie startuje, weryfikuje firmware i przyjmuje aktualizacje.

Atak na polski sektor energii jako moment przebudzenia

Punktem odniesienia dla tej rozmowy jest skoordynowany atak z 29 grudnia 2025 roku, opisany później przez CERT Polska. Incydent objął co najmniej 30 farm wiatrowych i fotowoltaicznych, elektrociepłownię w zasięgu około 500 tysięcy odbiorców ciepła oraz podmiot z sektora produkcyjnego. Atak miał charakter destrukcyjny – nie był to ransomware – i skutkował uszkodzeniem sterowników na obiektach OZE, choć nie wpłynął bezpośrednio na bieżącą produkcję energii. Działania wymierzone w elektrociepłownię nie osiągnęły celu i nie przerwały dostaw ciepła.

Typowy łańcuch cyberataku IT → OT – scenariusz odpowiadający polskiemu incydentowi z 29 grudnia 2025 roku.

Najlepiej udokumentowanym mechanizmem destrukcyjnym był atak na sterowniki RTU produkcji Hitachi. W uproszczeniu: urządzenia przyjęły zmodyfikowany firmware, ponieważ działały z domyślnym kontem „Default” mającym uprawnienia do zmiany oprogramowania, a funkcja weryfikacji podpisu aktualizacji nie była włączona. Efektem była pętla restartu i utrata komunikacji z obiektami OZE.

Raport CERT Polska pokazuje tu ważny mechanizm: zabezpieczenie istniało w firmware od wersji 13.2.1, ale wymagało aktywacji. Dodatkowo podatność CVE-2024-2617 umożliwiała obejście secure update do czasu poprawki w wersji 13.7.7.

Podobny wniosek płynie z pozostałych elementów incydentu: w sterownikach Mikronika wykorzystano dostęp SSH i domyślne poświadczenia konta root, a w dwóch obiektach uszkodzono Hitachi Relion 650 v1.1 z aktywną usługą FTP i domyślnymi danymi dostępowymi. Szczegóły techniczne warto zostawić raportowi CERT; dla projektanta OT kluczowy jest wniosek, że opcjonalne zabezpieczenie bywa w praktyce zabezpieczeniem niewdrożonym.

– To dokładnie ten przypadek, który tłumaczy, dlaczego mówimy, że bezpieczeństwo zaczyna się w hardware – komentuje Błażej Pawlak. – Producent zdążył już zaimplementować weryfikację podpisu firmware. Ale skoro funkcja była opcjonalna i nikt jej nie włączył, atakujący mógł wgrać dowolny plik. Hardware root of trust i secure boot mają sens dopiero wtedy, gdy są domyślnie aktywne i nie da się ich pominąć.

Zalecenia cyberbezpieczeństwa dla operatorów OZE

Po incydencie Pełnomocnik Rządu do spraw Cyberbezpieczeństwa opublikował zalecenia dla operatorów OZE. Ich rdzeń jest jednoznaczny:

• urządzenia OT i powiązane z nimi systemy (SCADA, HMI) nie powinny być wystawiane bezpośrednio do internetu,
• zdalny dostęp musi być realizowany przez kontrolowany kanał VPN (np. site-to-site lub SSL VPN serwisowy) terminowany na firewallu w strefie zdemilitaryzowanej, a nie konsumencki VPN do „ukrywania adresu IP”,
• obowiązkowe uwierzytelnianie wieloskładnikowe (MFA),
• segmentacja sieci zgodna z modelem Purdue,
• twarda kontrola kont administracyjnych: brak domyślnych poświadczeń, brak kont współdzielonych,
• logowanie zdarzeń i regularny audyt.

– Państwo powiedziało wprost, że cyberbezpieczeństwo rozproszonej energetyki ma wpływ na stabilność systemu elektroenergetycznego i dotyczy nie tylko właścicieli farm i operatorów, ale także obywateli – mówi Błażej Pawlak. – OZE to dziś niewygodne źródło energii w sensie cyber, ponieważ rozproszenie generacji oznacza wielu dostawców, dużych i małych, a cała infrastruktura krytyczna jest organizmem naczyń połączonych.

„Software nie obroni systemu, który ufa wszystkiemu, co się na nim uruchamia.” – Błażej Pawlak

Książkowe przykłady ataków na OT

Aby zrozumieć skalę problemu i odróżnić go od klasycznych cyberataków, warto przywołać kilka przypadków, które stały się punktem odniesienia w branży.

Stuxnet (2010)

Jest dziś uznawany za pierwszy publicznie znany przypadek malware zaprojektowanego do fizycznego sabotażu procesu przemysłowego. Robak atakował sterowniki PLC firmy Siemens, sterujące wirówkami wzbogacania uranu w irańskim ośrodku w Natanz, zmuszając je do destrukcyjnych zmian prędkości i jednocześnie ukrywając anomalie przed operatorami. Wykorzystywał aż cztery podatności typu zero-day i rozprzestrzeniał się m.in. przez zainfekowane pamięci USB. Publicznie atak przypisuje się operacji Olympic Games – wspólnemu przedsięwzięciu służb amerykańskich i izraelskich, w którym za techniczną realizację odpowiadać miały głównie NSA i izraelska jednostka 8200.

Industroyer / CrashOverride (2016)

Był pierwszym dedykowanym malware celującym w protokoły komunikacyjne podstacji energetycznych: IEC 60870-5-101, IEC 60870-5-104, IEC 61850 oraz OPC DA. Użyto go w ataku na ukraiński sektor energetyczny pod Kijowem. Pokazał, że można sterować urządzeniami podstacji bezpośrednio z poziomu malware, bez „klikania” w SCADA.

SolarWinds / Sunburst (2020)

To klasyczny atak na łańcuch dostaw – atakujący zmodyfikowali aktualizację oprogramowania Orion, której ufały tysiące organizacji. Choć sam SolarWinds nie był atakiem na OT, mechanizm ma wprost przekładalność na świat urządzeń przemysłowych: jeżeli sterownik przyjmuje aktualizację bez weryfikacji podpisu i pochodzenia, rolę „zaufanego Oriona” może odegrać dowolny zmodyfikowany plik firmware – co dokładnie zaobserwowano w grudniu 2025 roku w Polsce.

FrostyGoop (styczeń 2024)

To z kolei – według Dragos – pierwsze udokumentowane ICS malware, które wykorzystało protokół Modbus TCP do oddziaływania na realną infrastrukturę OT. Atak uderzył w sieć ciepłowniczą we Lwowie i pozbawił ogrzewania ponad 600 budynków mieszkalnych przez około dwie doby – w środku zimowych mrozów. Wektorem wstępnym była podatność w urządzeniu MikroTik; właściwym celem były sterowniki regulatorów ciepła z otwartym portem TCP/502.

Wspólny mianownik tych przypadków jest prosty: w OT atak nie musi oznaczać kradzieży danych. Celem jest zakłócenie procesu, utrudnienie odzyskania systemu albo bezpośredni wpływ na świat fizyczny. Klasyczne ataki na ukraińską energetykę pokazały wzorzec, w którym chodzi nie tyle o samo wyłączenie systemu, ile o utrudnienie jego restartu – i ten sam wzorzec widać w polskim incydencie z 29 grudnia 2025 roku. Wszystkie te przypadki łączy też jedno: moment, w którym warstwa software zaufała czemuś, czemu nie powinna była ufać.

Dlaczego bezpieczeństwo OT nie może zaczynać się od software’u

W wielu projektach rozmowa o bezpieczeństwie zaczyna się od aplikacji, konfiguracji systemu i narzędzi klasy EDR (Endpoint Detection and Response – oprogramowanie monitorujące urządzenia końcowe pod kątem podejrzanych działań i zaawansowanych zagrożeń). W świecie OT to często za późno. Urządzenie potrafi pracować w terenie kilkanaście lat, bywa trudno dostępne serwisowo, a fizyczny dostęp osób trzecich pozostaje całkiem realny – wystarczy szafa przy przejeździe kolejowym albo skrzynia inwertera na farmie PV.

Dlatego w projektowaniu bezpiecznego urządzenia OT wraca ta sama triada zabezpieczeń:

• hardware root of trust – sprzętowy fundament zaufania,
• secure boot – kontrolowany start systemu,
• weryfikacja integralności i pochodzenia firmware przy każdej aktualizacji.

Jeżeli urządzenie przyjmuje aktualizację tylko dlatego, że ma wyższy numer wersji – a nie sprawdza jej podpisu i źródła – wcześniej czy później staje się to punktem krytycznym. Dokładnie ten mechanizm ujawnił się w atakach z 29 grudnia 2025 roku.

Porównanie ataku cybernetycznego IT na OT: z i bez sprzętowego root of trust. Po lewej – udany atak na urządzenie bez sprzętowego korzenia zaufania; po prawej – atak powstrzymany przez bezpieczny rozruch i ochronę kluczy.

ARM, TrustZone i hardware root of trust w praktyce

Hardware root of trust to sprzętowy fundament zaufania, oparty na niezmiennym elemencie sprzętowym (np. fragmencie kodu w Boot ROM i kluczach umieszczonych w pamięci OTP/eFuses), któremu cały system ufa „domyślnie”. Działa jako punkt początkowy, od którego weryfikowane są kolejne etapy uruchamiania urządzenia: bootloader, jądro systemu, system plików, aplikacja. W przeciwieństwie do rozwiązań programowych, które można zainfekować, sprzętowy root of trust jest znacząco trudniejszy do zmodyfikowania – w praktyce atakujący musiałby fizycznie wymienić chip.

Boot ROM (Boot Read-Only Memory) to pierwsza, niezmienialna instrukcja kodu wbudowana w SoC (System on Chip) i uruchamiana zaraz po włączeniu zasilania. Inicjalizuje sprzęt, wczytuje bootloader z pamięci zewnętrznej i sprawdza jego podpis kryptograficzny przy użyciu kluczy zapisanych fabrycznie w eFuses. Dopiero gdy podpis jest poprawny, kolejne warstwy mogą się załadować.

ARM TrustZone to natomiast architektura sprzętowej izolacji wewnątrz procesora. TrustZone rozdziela środowisko wykonawcze procesora na dwa światy: Normal World, w którym pracuje system operacyjny i aplikacje, oraz Secure World, w którym uruchamiane są krytyczne operacje bezpieczeństwa (Trusted Execution Environment, np. OP-TEE). Sam TrustZone nie przechowuje kluczy – te trzymane są w dedykowanych blokach sprzętowych (eFuses, CAAM); TrustZone udostępnia izolowane środowisko, w którym te klucze mogą być używane bez ryzyka, że sięgnie do nich aplikacja działająca w Normal World.

ARM TrustZone jako granica zaufania – Secure World oddzielony od Normal World

W platformie NXP i.MX 8M Plus klucze kryptograficzne i operacje na nich obsługiwane są przez dedykowane bloki sprzętowe. CAAM (Cryptographic Acceleration and Assurance Module) zapewnia silnik kryptograficzny i bezpieczne przechowywanie kluczy. eFuses przechowują Super Root Keys (SRK) używane przez mechanizm High Assurance Boot (HAB). Opcjonalnie EdgeLock Secure Enclave dostarcza odizolowane środowisko do operacji krytycznych. Wszystkie te bloki TrustZone udostępnia programistycznie – w środowisku, do którego nie sięga zwykła aplikacja.

Cały ten łańcuch ma sens, jeżeli urządzenie rzeczywiście zapewnia podstawowe usługi kryptograficzne: poufność, integralność, autentyczność i niezaprzeczalność – w sprzęcie, a nie tylko deklaratywnie w aplikacji. Wtedy nowy firmware można przyjąć dopiero po sprawdzeniu, że jego podpis weryfikuje się względem klucza z eFuses, a integralność pliku zgadza się z hashem podpisanym przez producenta. W atakach z 29 grudnia 2025 roku urządzenia po prostu wgrały nowy firmware bez takiej weryfikacji – mechanizm secure update, choć dostępny w firmware tych sterowników, nie został włączony w konfiguracji urządzenia.

Dotyczy to nie tylko firmware’u, ale także aplikacji wdrażanych później na urządzeniu. Jeżeli logika OT działa wyłącznie w zwykłym Normal World, atakujący po przejęciu systemu może próbować sięgnąć do funkcji, które powinny pozostać izolowane. Dlatego mechanizmy TrustZone i TEE warto wykorzystywać również w aplikacjach: do operacji na kluczach, autoryzacji aktualizacji oraz krytycznej logiki bezpieczeństwa.

Raspberry Pi a przemysłowy SoM – gdzie naprawdę leży różnica

Platforma ARM dominuje w OT z kilku powodów: energooszczędność, długie cykle wsparcia ze strony producentów krzemu, dojrzały ekosystem embedded. Trzeba jednak pamiętać, że nie każdy chip ARM ani moduł obliczeniowy SoM (System on Module) zapewnia ten sam poziom bezpieczeństwa i nie każda platforma referencyjna jest przeznaczona do wdrożeń infrastrukturalnych.

Raspberry Pi to świetna platforma do nauki, prototypowania, warsztatów i części zastosowań embedded. Problem zaczyna się tam, gdzie oczekujemy od niej pełnienia roli stabilnego fundamentu dla rozwiązania wdrażanego na lata w środowisku krytycznym – z gwarantowaną dostępnością części, kontrolą BOM (Bill of Materials), deterministycznym cyklem życia i uwierzytelnionym kanałem dostarczania firmware.

Różnica nie sprowadza się też do samego poboru prądu. Raspberry Pi 5 pozostaje energooszczędną platformą prototypową, ale jego profil zasilania zależy mocno od peryferiów, USB, chłodzenia i sposobu użycia. W projekcie OT ważniejsze jest coś innego: przewidywalność całego urządzenia. Przemysłowy SoM, taki jak SoMLabs SpaceSOM-8MPlus, pozwala projektantowi budować własny carrier board, dobrać interfejsy, storage, chłodzenie i profil energetyczny pod konkretny produkt, zamiast przyjmować gotową płytkę SBC jako stały punkt wyjścia.

To nie znaczy, że Raspberry Pi jest „złe” albo że nie da się go zabezpieczyć. Raspberry Pi 5 ma udokumentowany secure boot, a rodzina Compute Module jest bliższa światu embedded niż klasyczna płytka SBC. W rozwiązaniach OT pytanie brzmi jednak nie tylko „czy działa?”, ale „czy da się to powtarzalnie produkować, aktualizować, audytować i utrzymać przez dekadę?”.

Raspberry Pi i przemysłowy SoM – praktyczna różnica w projekcie OT

– Prototyp to nie to samo co produkt przemysłowy – mówi Błażej Pawlak. – W projekcie, który ma działać kilkanaście lat w terenie, decydująca jest cała otoczka: kontrola łańcucha dostaw, predykcyjność BOM, długoterminowe wsparcie SoC, certyfikaty, wdrożeniowy proces key provisioning. To nie są rzeczy, które się dorabia po kupnie płytki w sklepie.

Konkretnym przykładem rozwiązania z drugiej strony tej skali jest moduł SoMLabs SpaceSOM-8MPlus oparty na NXP i.MX 8M Plus. To rozwiązanie projektowane do zastosowań przemysłowych – z zakresem temperatur pracy do −40…+85 °C w wariancie przemysłowym bez Wi-Fi, sprzętowymi mechanizmami bezpieczeństwa (secure boot, TrustZone, sprzętowy moduł kryptograficzny CAAM) oraz SoC objętym 15-letnim NXP Product Longevity Program. To ogranicza ryzyko wycofania kluczowego komponentu i ułatwia planowanie cyklu życia produktu, choć stabilność całego BOM nadal zależy od konfiguracji modułu, carrier boardu i umów z dostawcą. SoMLabs to polski producent z siedzibą w Legionowie pod Warszawą. W zastosowaniach takich jak energetyka, logistyka, sieci krytyczne, urządzenia medyczne czy systemy transportu, ta różnica jakościowa decyduje o tym, czy projekt w ogóle nadaje się do regulowanego środowiska.

Ta sama zasada wraca przy kluczach kryptograficznych: sprzętowy fundament zaufania ma sens tylko wtedy, gdy klucze używane w produkcji, aktualizacjach i utrzymaniu urządzeń są chronione równie konsekwentnie.

Cykl życia urządzenia OT obejmuje cztery fazy: projekt, produkcję, wdrożenie i 10–15-letnią eksploatację. Decyzje o bezpieczeństwie podjęte na początku tego łańcucha kształtują odporność systemu przez całą jego dekadę pracy w terenie.

Klucze kryptograficzne powinny być chronione sprzętowo

Jeden z praktycznych wniosków z całej rozmowy dotyczy roli kluczy kryptograficznych. Jeśli klucz, którym podpisuje się firmware albo uwierzytelnia urządzenia, jest przechowywany jako zwykły plik na dysku, ryzyko kompromitacji rośnie radykalnie. Kto przejmie taki klucz, może podszyć się pod zaufane źródło.

Dlatego w dojrzałych architekturach klucze są chronione sprzętowo. HSM (Hardware Security Module) to dedykowane urządzenie, które generuje, przechowuje i wykorzystuje klucze w izolowanym środowisku – klucze nigdy nie opuszczają modułu w postaci jawnej. Klasycznym przykładem są koprocesory kryptograficzne w mainframe’ach IBM (np. produkty z rodziny IBM Crypto Express), w których klucze pozostają w obrębie chronionej granicy sprzętowej.

Polski rynek również nie jest pusty – sprzętowe moduły kryptograficzne klasy enterprise oferują w Polsce m.in. Enigma SOI oraz CryptoTech. Osobną kategorią, ale również krajową, jest Creotech Quantum, która rozwija technologię kwantowej dystrybucji kluczy (QKD) w ramach europejskiej infrastruktury EuroQCI – to jednak inny obszar niż klasyczne HSM.

– Nie ma nic gorszego niż trzymanie klucza w pliku na pendrivie – podkreśla Błażej Pawlak. – Można go po prostu skopiować i wraz z nim ukraść zaufanie do całej floty urządzeń. Klucz zaszyty w sprzęcie – w eFuses, w CAAM, w HSM – jest dużo trudniejszy do wydobycia. W niektórych konfiguracjach tak trudny, że jego wydobycie byłoby ekonomicznie nieopłacalne.

Czy AI jest akceleratorem zagrożeń?

Zdaniem Błażeja Pawlaka – tak, ale nie w takim sensie, jak sugerują niektóre nagłówki. Sztuczna inteligencja sama z siebie nie atakuje infrastruktury. Obniża natomiast próg wejścia: zwiększa liczbę aktorów zdolnych do tworzenia narzędzi rozpoznawczych, generowania skryptów albo przygotowania komponentów destrukcyjnych. W przypadku OT przekłada się to na większą liczbę tańszych, szybszych i bardziej powtarzalnych ataków.

– Żyjemy w świecie, w którym infrastruktura krytyczna jest elementem presji geopolitycznej, a sztuczna inteligencja obniża próg wejścia – mówi Błażej Pawlak. – Dla OT oznacza to więcej tanich i destrukcyjnych ataków. Dlatego bezpieczeństwo na różnych warstwach jest ważne, a to sprzętowe – jest podstawą.

Paradoksem rynku jest jednak to, że produkty oparte na bezpieczeństwie wciąż sprzedają się gorzej niż te skupione wyłącznie na funkcjonalności. Odbiorcy indywidualni cieszą się, że coś działa, i chętnie oddadzą swoje dane w zamian za rabat. Z bezpieczeństwem OT jest podobnie – z tą różnicą, że stawką nie są tu ankiety marketingowe, tylko ciągłość energii, ciepła, transportu i bezpieczeństwo ludzi. Europa musi zadbać o własne podwórko nie tylko w warstwie danych, lecz przede wszystkim w procesach fizycznych. A to oznacza bezpieczeństwo projektowane na dekady, zaczynające się od hardware’u.

***

Błażej Pawlak studiował telekomunikację oraz bezpieczeństwo oprogramowania na Technical University of Denmark (DTU). Przez wiele lat związany z IBM, gdzie współtworzył rozwiązania z obszaru zarządzania kryptografią klasy enterprise, w tym IBM Unified Key Orchestrator for z/OS and Containers. Jest współzałożycielem Smart Coders – firmy inżyniersko-doradczej realizującej długoterminowe projekty dla klientów enterprise – oraz Secure M Systems, spółki budującej platformę, która otwiera inżynierom i agentom AI kontrolowaną ścieżkę dostępu do danych zamkniętych w infrastrukturze krytycznej za segmentacją sieci, VPN-ami i warstwami zdalnego dostępu. Specjalizuje się w bezpieczeństwie, kryptografii oraz projektowaniu rozwiązań dla środowisk regulowanych i infrastruktury krytycznej, łącząc wymagania IT z realiami systemów produkcyjnych.