Wpisz czego szukasz
i kliknij enter

20 najlepszych praktyk tworzenia kodu dla sterowników

Udostępnij wpis


TLDR;

Pojawił się dokument opisujący 20 najlepszych praktyk tworzenia kodu dla sterowników.
Zapoznaj się z nim i zastosuj w swojej organizacji.

Link do pobrania:  https://www.plc-security.com/


15 Czerwca 2021 pojawiła się wersja 1.0. dokumentu „Secure PLC Coding Practices: Top 20 List”. Jest to zbiór 20 najlepszych praktyk tworzenia kodu dla sterowników. Znajdziesz go pod tym adresem: https://www.plc-security.com/.

Dobre praktyki pojawiają się w każdym aspekcie naszego życia. Od dotyczących spraw codziennych jak „Sprawdź czy kuchenka jest wyłączona przed wyjściem z domu”, do spraw związanych z cyberbezpieczeństwem różnego rodzaju systemów przemysłowych, medycznych itp.

‘Insecure by design’ 

Środowisko ICS/OT wypracowało wiele dokumentów, standardów i porad, jak zabezpieczyć sieci przemysłowe przed włamaniami. Podstawowym problemem jest jednak fakt, że sterowniki, serce całego systemu, najczęściej stanowią jego najbardziej podatny na atak element. W środowisku stosuje się nawet określenie ‘insecure by design’ czyli ‘niezabezpieczone zgodnie z projektem’. Jak to rozumieć?

W dużym uproszczeniu sterowniki najczęściej programuje się w taki sposób, żeby jak najszybciej wykonywały polecenia, które otrzymują. Najczęściej nie poświęcają zbyt wiele cennego czasu procesora na weryfikację skąd pochodzi komenda. W dużym skrócie, jeśli atakujący uzyska dostęp do sieci, w której znajdują się sterowniki, to nie musi szukać żadnych podatności, bo najczęściej wystarczy wysłać odpowiednie komendy do urządzenia, lub zastosować proste tricki, żeby sterownik wykonał naszą komendę. 

Jak to możliwe, że te systemy da się obronić przed atakami?

Po dziś dzień w środowiskach przemysłu, ceniących sobie bezpieczeństwo, stosuje się inne dobre praktyki, takie jak standard IEC-62443 i tworzy się „kokony” bezpieczeństwa wokół sterowników i procesu. Dodatkowo, postępująca konwergencja IT i OT nie zniszczyła całkowicie  mitycznej separacji sieci IT i OT, ale już widać ślady ‘korozji’, w postaci wyłomów bezpieczeństwa, przez które dane płyną pomiędzy tymi środowiskami. Zespoły bezpieczeństwa organizacji zajmujących się sieciami ICS/OT również doskonalą swoje umiejętności i procesy detekcji anomalii.

W dalszym ciągu jednak, tworzymy coraz bardziej skomplikowane struktury w celu zabezpieczenia tego sterownika, który nie jest w stanie się obronić. Podoba mi się analogia budowania coraz bardziej zawiłej konstrukcji wokół człowieka, który nie chce nosić kasku. A gdyby tak skłonić go do założenia kasku?

Właśnie tego tyczy się dokument, który zainspirował mnie do napisania tego wpisu. Dokument „Najlepsze 20 praktyk tworzenia kodu dla sterowników” opisuje jak „założyć kask” sterownikowi. Oprócz standardowych porad, jak wyłączanie nieużywanych portów i usług, walidacji danych wejściowych itp., znanych z środowisk IT, znajdziesz w dokumencie również porady typu „Określ bezpieczny stan procesu podczas restartu sterownika”. Jeśli jesteś inżynierem, pracującym z środowiskiem przemysłowym, zapewne nie lubisz restartować sterowników, zwłaszcza przy działającym procesie, bo przez chwilę, porty wejścia/wyjścia sterownika znajdują się w stanie nieustalonym, co może spowodować spore zakłócenia w działaniu procesu. Ta dobra praktyka ma za zadanie wyeliminować ten problem.

Dokument zawiera informacje tłumaczące te zalecenia, ich zasadność i odniesienia do innych uznanych standardów (np. MITRE ATT&CK, IEC-62443), a także zalety zastosowania tych zaleceń, w kontekście Bezpieczeństwa, Niezawodności i Utrzymania systemu.

Dlaczego uważam, że właśnie Ty musisz znać ten dokument?

  • Jeśli tworzysz kod – stworzysz rozwiązanie, które będzie lepiej oceniane, więc będziesz mógł osiągnąć większy zysk
  • Jeśli jesteś użytkownikiem tego kodu – będziesz mieć mniej problemów. Uczul swojego dostawcę, że chcesz tak napisanego kodu. Zawrzyj zgodność z tym dokumentem w wytycznych do zamówienia. Im więcej organizacji będzie tego wymagać, tym szybciej producenci zaczną to wdrażać.  
  • Jeśli masz wpływ na normy i standardy stosowane w przemyśle, dodaj ten dokument jako wymagania do Twojego. Twój wpływ może kiedyś uratować jakąś organizację przed poważnym incydentem.

Pamiętaj, że wszyscy jesteśmy zależni od technologii stosowanych w przemyśle. Działając razem możemy zapewnić sobie i naszym najbliższym bezpieczeństwo. Damy radę!

Jeśli przydał Ci się nasz artykuł podziel się nim z innymi. Jeśli natomiast szukasz większej ilości informacji z obszaru cyberbezpieczeństwa – zachęcamy do przeczytania naszych pozostałych wpisów z tej dziedziny.

Zobacz inne wpisy

Sieci przemysłowe
Jak wdrożyć MPLS-TP w energetyce? Case study

Jak wygląda od strony praktycznej wdrożenie MPLS-TP w sektorze energetycznym? Zobacz, jak poradził sobie z tym klient, który szukał łatwego we wdrożeniu i obsłudze oraz intuicyjnego rozwiązania.

OTnośnik – cykliczny biuletyn z komentarzami ekspertów Tekniska
OTnośnik: Cyberatak zablokował pociągi w Danii. Kolejny raz atak na infrastrukturę IT zatrzymuje OT

Zapraszamy do lektury kolejnego wydania OTnośnika – cyklicznego biuletynu z komentarzami ekspertów Tekniska! Stefan Bednarczyk (Kierownik Działu Technicznego / Starszy Specjalista Cyberbezpieczeństwa IT/OT) komentuje doniesienia Reuters na temat ataku na infrastrukturę IT, który zatrzymał pociągi w Danii.

Ta strona używa plików Cookie. Korzystając ze strony wyrażasz zgodę na używanie Cookie, zgodnie z aktualnymi ustawieniami używanej przeglądarki. Szczegóły znajdziesz w Polityce prywatności.