Mobilny operator - przenośne i bezprzewodowe HMI

Można wymienić kilka atutów urządzeń przenośnych, dzięki którym sprawdzają się one jako HMI w przemyśle. Przede wszystkim operator może je wszędzie ze sobą zabrać. Oprócz tego obsługuje się je za pośrednictwem ekranów dotykowych, a liczba przycisków jest ograniczona do minimum.

Zaletą jest także dodatkowe wyposażenie będące obecnie standardem w tabletach i smartfonach, które rozszerza funkcjonalność panelu operatorskiego o opcje często niedostępne w przypadku stacjonarnych HMI. Ponadto z serwisów takich jak na przykład Google Play, często za darmo, można pobrać dedykowane aplikacje mobilne.

Warto dodać, że przy użyciu pojedynczego podręcznego HMI, na którym zainstalowane zostaną odpowiednie aplikacje, można nadzorować pracę wielu urządzeń. W przypadku rozbudowanych parków maszynowych i złożonych linii technologicznych znacząco zmniejsza to koszty zakupu, ułatwia instalację, a później także modernizację sprzętową i aktualizację oprogramowania, w porównaniu do analogicznych obciążeń wynikających z korzystania ze stacjonarnych paneli operatorskich.

W dalszej części przedstawiamy każdą z wyżej wymienionych cech mobilnych HMI. Z niektórych z nich, jeżeli spojrzeć na nie z innej perspektywy, wynikają również pewne ograniczenia.

BLASKI I...

Urządzenia przenośne takie jak tablety i smartfony są lekkie, nieduże i zasilane bateryjnie. Dzięki temu można je mieć zawsze przy sobie. Tę cechę HMI docenią szczególnie pracownicy zajmujący stanowiska, które wymagają częstego przemieszczania się po zakładzie. Przykładem jest personel działu utrzymania ruchu. Dzięki temu niezależnie od tego, gdzie pracownik przebywa, ma stały dostęp do interesujących go informacji. To pozwala mu na zdalny nadzór nad stanem urządzeń, przebiegiem procesów i rozwiązywanie problemów na odległość.

Z kolei osoby, które pracują przez większość czasu stacjonarnie, może to zachęcić do większej aktywności i wyjścia zza biurka albo przejścia na stanowisko do innej części fabryki, żeby na miejscu przekonać się, jak działa dana maszyna albo instalacja, czy można wprowadzić jakieś ulepszenia w jej pracy albo co jest przyczyną awarii. Zmieniając za pośrednictwem smartfona ustawienia urządzenia, od razu mogą również zaobserwować skutki swoich działań.

Przenośne HMI pozwalają oprócz tego z bezpiecznej odległości monitorować pracę na przykład instalacji w strefach zagrożonych wybuchem i tam, gdzie dostęp jest utrudniony, na przykład z powodu ekstremalnych temperatur, dużego zapylenia, występowania substancji chemicznych groźnych dla ludzi albo wymogu zachowania sterylności, na przykład w cleanroomach.

...CIENIE MOBILNYCH HMI

Niestety, mobilne HMI może zostać zgubione albo skradzione. Jest to tym bardziej prawdopodobne i groźne, jeśli pracownik korzysta z niego poza terenem zakładu pracy, szczególnie gdy jest to jego prywatny sprzęt. Przed konsekwencjami dostania się go w niepowołane ręce można się chronić na różne sposoby, na przykład zabezpieczając dostęp do urządzenia i aplikacji hasłem, automatycznie wylogowując urządzenie z sieci zakładowej i odmawiając korzystania z niej sprzętom znajdującym się poza terenem zakładu.

Poza tym, mając przenośny HMI cały czas przy sobie, nietrudno jest go w ciężkich przemysłowych warunkach uszkodzić. W przypadku sprzętu służbowego, by się przed tym zabezpieczyć, można, zamiast urządzeń zaliczanych do elektroniki konsumenckiej, wybrać sprzęt do zastosowań specjalnych, o wzmocnionej konstrukcji w porównaniu do elektroniki konsumenckiej.

Trzeba oprócz tego pamiętać, że mobilność, dzięki uniezależnieniu od podłączenia do zasilania, uzyskuje się kosztem niepewności, czy bateria nie rozładuje się w nieodpowiednim momencie albo, w przypadku intensywniejszego wykorzystania, szybciej niż zazwyczaj.

Aby do tego nie dopuścić, trzeba kontrolować poziom jej naładowania. Powinno się również zaplanować harmonogram ładowania. Dostępne są poza tym smartfony i tablety w wersji z drugim kompletem baterii zapewniającym zabezpieczenia na wypadek rozładowania się tego pierwszego.

ZALETY I WADA EKRANÓW DOTYKOWYCH

Smartfony i tablety wyposażone są w ekrany dotykowe, których zaletą jest intuicyjność obsługi. Dzięki niej interakcja użytkownika z urządzeniem jest płynniejsza, popełnia on mniej błędów, a zadania wykonuje w czasie nawet kilka razy krótszym niż wówczas, kiedy używa klawiatury albo myszki. Ponadto obsługi urządzenia z takim wyświetlaczem można się łatwo nauczyć, a w zasadzie w związku z tym, że obecnie smartfony oraz tablety są wszechobecne, w ogóle nie trzeba się w tym zakresie specjalnie doszkalać.

Dzięki temu, że interfejs dotykowy wyeliminował klawiaturę oraz myszkę, można było zwiększyć powierzchnię wyświetlacza. Brak tych peryferii ułatwia swobodne przenoszenie tych urządzeń, a ze względu na ich awaryjność i łatwość przypadkowego uszkodzenia, wydłuża czas eksploatacji smartfonu lub tabletu oraz obniża jej koszty. Ponadto przenośnych HMI nie trzeba dodatkowo zabezpieczać przed czynnikami takimi, jak brud, pył, wysoka temperatura, chemikalia oraz wibracje.

Wyświetlacze dotykowe można łatwo wyczyścić. Dzięki temu lepiej sprawdzają się tam, gdzie wymagana jest sterylność wyposażenia, na przykład w przemyśle farmaceutycznym. Poza tym przystosowanie klawiatury i myszki do pracy w strefach zagrożonych wybuchem jest kosztowne. Panele z ekranami dotykowymi takich modyfikacji na ogół nie potrzebują, a jeżeli już, to ich koszt jest niewielki.

Pomimo tak wielu zalet nie powinno się zapominać o wadzie, która w przemyśle jest istotnym ograniczeniem. Chodzi o to, że ekrany dotykowe w technologii pojemnościowej działają tylko wówczas, gdy są dotykane przez materiał przewodzący prąd elektryczny, na przykład dłonią lub rysikiem. Przez to, jeśli operator nosi rękawice ochronne, mobilny HMI może nieprawidłowo reagować na jego dotyk.

DODATKOWE WYPOSAŻENIE TO NOWE MOŻLIWOŚCI

Standardowe wyposażenie smartfonu i tabletu obejmuje obecnie m.in.: kamerę, mikrofon, czujniki, w tym przyspieszenia, ruchu, światła, żyroskop oraz nawigację GPS. Podzespoły te w HMI można wykorzystać na wiele sposobów. Na przykład kamera i mikrofon, a konkretnie funkcja dyktafonu, przydają się w tworzeniu dokumentacji technicznej.

Z kolei aktualna lokalizacja operatora jest wykorzystywana do ograniczania danych, które są mu udostępniane tylko do tych z jego punktu widzenia najpotrzebniejszych, dotyczących na przykład maszyny, w pobliżu której się znajduje. Podobnie informacje o awarii mogą być przesyłane jedynie do wąskiego grona odbiorców, którzy znajdują się najbliżej miejsca jej wystąpienia, z wyłączeniem pracowników, którzy nie mają wystarczających kompetencji, żeby dany problem rozwiązać lub nie mają odpowiednich uprawnień, aby w niego ingerować.

Urządzenia przenośne dla przemysłu wyposaża się dodatkowo w czytniki kodów kreskowych i skanery tagów RFID. Wykorzystuje się je na przykład do rozpoznawania wyposażenia zakładu i potwierdzania obecności pracownika na danym stanowisku albo jego tożsamości oraz szybkiego wyszukiwania w bazie danych informacji o oznakowanym urządzeniu, na przykład jego instrukcji obsługi. W przyszłości, w razie upowszechnienia się w przemyśle Internetu Rzeczy, przydatna okaże się również możliwość połączenia się za pośrednictwem interfejsów komunikacyjnych urządzeń podręcznych z węzłami IoT.

Używając smartfonów i tabletów jako narzędzi pracy, uzyskuje się dodatkowe możliwości w zakresie komunikacji ze współpracownikami. Dzięki temu informacjami o stanie maszyn oraz problemach w ich funkcjonowaniu czy pomysłami na usprawnienie ich pracy można się dzielić bez ograniczeń wynikających z lokalizacji czy ram czasowych, wyznaczanych godzinami pracy.

Za ich pośrednictwem można też pobrać z zakładowego serwera lub Internetu potrzebną dokumentację czy instrukcje. Zapewnia to oszczędność czasu, który inaczej byłby tracony na przemieszczanie się między halą produkcyjną a dyspozytornią, jeśli sytuacja wymagałaby konsultacji z innymi członkami zespołu albo sięgnięcia po dodatkowe dane.

URZĄDZENIA WZMOCNIONE, A MOŻE BYOD?

Jak wspomniano wcześniej, w ciężkich przemysłowych warunkach nie jest trudno o uszkodzenie urządzeń o takich rozmiarach, wadze oraz konstrukcji, jak w przypadku smartfonów i tabletów. Dlatego w tym zastosowaniu najlepiej sprawdzają się ich wersje wzmocnione.

Jedną z ich ważniejszych cech jest duża szczelność. Stopień ich ochrony może wynosić od IP42, co oznacza ochronę przed wnikaniem ciał o wielkości ponad 1 mm i kroplami deszczu, do nawet IP68. Wówczas gwarantowana jest ich całkowita odporność na pył oraz zalanie przy ciągłym zanurzeniu.

Zakres temperatur pracy wynosi typowo od -30°C do +60°C. Dodatkowym zabezpieczeniem przed uszkodzeniem mechanicznym są gumowe narożniki i osłony na krawędziach, a wyświetlacze przed zarysowaniem chronią specjalne nakładki.

Aby można było używać ich na zewnątrz i przy różnym oświetleniu, ekrany pokrywa się powłoką antyrefleksyjną. Stosownie do warunków otoczenia regulowane jest też ich podświetlenie. Tablety oraz smartfony dla przemysłu zwykle spełniają wymagania amerykańskiej normy MIL-STD 810G, według której testowane są sprzęty wojskowe. W ramce przedstawiamy przykłady urządzeń w wykonaniu specjalnym.

Nie zawsze jednak wzmocnione urządzenia są potrzebne. Wówczas można wdrożyć koncepcję BYOD, czyli Bring Your Own Device, obecnie bowiem w zasadzie każdy pracownik dysponuje własnym smartfonem i/albo tabletem. W ramce przedstawiamy jej zalety i wady.

PROJEKTOWANIE APLIKACJI MOBILNYCH

W projektowaniu aplikacji mobilnych dla przemysłu trzy ich aspekty mają kluczowe znaczenie - funkcjonalność, interfejs użytkownika oraz bezpieczeństwo. Jeżeli chodzi o tę pierwszą, to w serwisach takich jak Google Play pojawia się coraz więcej specjalistycznych programów na urządzenia mobilne, m.in. o funkcjonalności HMI, ułatwiających rozwiązywanie problemów sprzętowych, do wykonywania szybkich przeliczeń, parametryzacji i wizualizacji danych (patrz ramka).

W kwestii projektowania interfejsu użytkownika w odniesieniu do mobilnych HMI występują takie same wymagania, jak w przypadku stacjonarnych paneli operatorskich. Oznacza to, że oczekuje się, że będzie on intuicyjny w obsłudze oraz zapewni czytelną i zrozumiałą informację. Dążąc do realizacji tych celów, trzeba pamiętać o specyfice mobilnych HMI, a przede wszystkim o stosunkowo małej powierzchni ich wyświetlacza oraz o tym, że obsługuje się je za pomocą dotyku.

Jeżeli pierwszy warunek nie zostanie spełniony i aplikacja będzie w obsłudze zbyt skomplikowana, operator szybko się zniechęci lub z czasem zacznie szukać sposobów na ominięcie niewygodnych rozwiązań. Ani ich, ani tym bardziej ich wpływu na działanie programu, a w konsekwencji całego systemu, z którym aplikacja się łączy, jej twórca nie jest w stanie przewidzieć, dlatego lepiej tego wymogu nie lekceważyć.

Przy uwzględnieniu specyfiki przenośnych HMI jednym ze sposobów na poprawę intuicyjności obsługi aplikacji mobilnych jest ograniczenie do minimum konieczności wpisywania przez użytkownika informacji za pomocą klawiatury ekranowej. Zamiast można na przykład korzystać ze skanerów kodów kreskowych oraz czytników RFID. Zmniejszy to frustrację operatora oraz liczbę błędnie podanych danych.

MNIEJ ZNACZY WIĘCEJ

Jeżeli dane prezentowane na ekranie będą nieczytelne, wydłuży się czas reakcji operatora i łatwiej będzie o ich błędną interpretację. Istnieje kilka sposobów, aby tego uniknąć.

Przede wszystkim ilość informacji prezentowanych użytkownikowi powinna być ograniczona do niezbędnego minimum - przy małych wyświetlaczach ten wymóg jest jeszcze ważniejszy niż w przypadku stacjonarnych paneli operatorskich. Ponadto na niedużym ekranie czytelniejsza może okazać się informacja tekstowa niż schemat graficzny, inaczej niż w przypadku dużych ekranów stacjonarnych HMI. Trzeba również pamiętać, że dostarczenie użytkownikowi danych nie zawsze jest jednoznaczne z zapewnieniem mu użytecznych informacji.

Dlatego, aby ułatwić ich interpretację, dobrze jest na przykład zamiast tabel przedstawiać je na wykresach, co ułatwia analizę ich zmienności w czasie i porównywanie wartości różnych wielkości oraz danych różnych urządzeń względem siebie.

Ważny jest poza tym wybór kolorów. Zaleca się stosowanie tych ciemniejszych na jasnym tle oraz szarości w różnych odcieniach. Innych kolorów powinno się używać oszczędnie, a jednocześnie konsekwentnie. Poprawi to czytelność oraz zagwarantuje ich jednoznaczną interpretację.

Jeżeli chodzi o bezpieczeństwo mobilnych HMI, jakość kodu aplikacji ma na nie bez wątpienia ogromny wpływ. Jednocześnie nie można pominąć innych aspektów, dlatego tę kwestię powinno się rozpatrywać kompleksowo, co wyjaśniamy w ramce, przedstawiając różne zagrożenia i scenariusze ataków. Dalej koncentrujemy się przede wszystkim na poradach dla twórców aplikacji.

APLIKACJE MOBILNE NA CELOWNIKU

W 2017 roku opublikowano raport "SCADA and mobile security in the Internet of Things era". Powstał on w oparciu na badaniach przeprowadzone wspólnie przez Embedi oraz IOActive, firmy, które specjalizują się w dziedzinie cyberbezpieczeństwa. Ich celem była weryfikacja poziomu bezpieczeństwa aplikacji mobilnych dla przemysłu.

W ramach tego przedsięwzięcia wybrane programy zostały przetestowane pod kątem najczęstszych błędów w kodzie, które mogą być wykorzystane przez hakerów do przeprowadzenia cyberataku. Punktem odniesienia dla badań Embedi i IOActive była lista Top 10 Mobile Risks 2016, którą opracowała organizacja OWASP (Open Web Application Security Project). Celem jej działania jest wspieranie twórców aplikacji, webowych oraz mobilnych, w tworzeniu bezpiecznego oprogramowania.

Specjaliści z Embedi i IOActive przetestowali ponad 30 programów, losowo wybranych spośród tych dostępnych w serwisie Google Play, których ostatnia aktualizacja miała miejsce później niż w czerwcu 2015 roku. Odkryli łącznie prawie 150 luk w zabezpieczeniach.

W tabeli przedstawiamy podsumowanie wyników ich badań, w postaci liczby wykrytych błędów, zaliczanych do konkretnej kategorii od M1 do M10 według klasyfikacji OWASP i procentowego udziału aplikacji, które okazały się mieć co najmniej jedną lukę danego typu. Dalej przedstawiamy analizę błędów poszczególnych kategorii.

SŁABE PUNKTY TYPU M1 I M2

Kategoria M1 obejmuje niewłaściwe użycie funkcji platformy mobilnej lub niekorzystanie z dostępnych zabezpieczeń. Specjaliści Embedi i IOActive odkryli pięć tego typu przypadków. Cztery wynikały z korzystania z przestarzałych, podatnych na ataki bibliotek uruchomieniowych. Piąty polegał na nieprawidłowych ustawieniach w pliku konfiguracyjnym aplikacji.

Przez to każdy inny program działający na urządzeniu mógł odczytywać i zmieniać informacje zapisane w jej bazie danych. Zapewniało to swobodny dostęp do danych uwierzytelniających i ustawień, na przykład do konfiguracji połączenia z serwerem. Umożliwiało to złośliwej aplikacji jego przekierowanie przez zmianę adresu serwera właściwego na adres serwera podszywającego się pod niego.

Do kategorii M2 zalicza się brak ochrony danych oraz ich niezamierzone wycieki. Luka wystąpiła w prawie połowie przetestowanych aplikacji mobilnych (47%), które zapisywały dane na karcie SD albo w pamięci wirtualnej, dziedzicząc przez to słabości systemów plików tych nośników, jak brak implementacji list kontroli dostępu czy mechanizmów uprawnień.

Dlatego aplikacja z prawem do odczytu i zapisu danych na karcie SD miała jednocześnie dostęp do danych zapisywanych na niej przez inne programy. Ponadto, w razie pozostawienia urządzenia bez opieki, kartę pamięci można niepostrzeżenie skopiować albo zmodyfikować informacje na niej zapisane.

Przykłady bezpłatnych aplikacji mobilnych dla przemysłu w Google Play
SEW Diagnostics Zapewnia wsparcie serwisantom przemienników częstotliwości marki SEW w zakresie szybkiej diagnostyki błędów tych urządzeń.	easyRemote Display Służy do sterowania przekaźnikami programowalnymi z serii easy800 za pomocą smartfonu. Aplikacja firmy Eaton.	Danfoss Trouble Shooter Aplikacja firmy Danfoss ułatwia diagnozowanie problemów w funkcjonowaniu systemów chłodniczych.	Pro-face Remote HMI Aplikacja od firmy Schneider Electric zapewnia zdalny dostęp do HMI.

LUKI M3 - M5

 

Podsumowanie badań luk w aplikacjach mobilnych

Trzecia kategoria obejmuje nieprawidłową konfigurację lub niewłaściwe korzystanie z rozwiązań, które zapewniają poufność transmisji danych. Lukę wykryto w ponad jednej trzeciej ze zbadanych aplikacji. Najczęstszy zidentyfikowany problem polegał na niesprawdzaniu poprawności certyfikatu TLS, a tylko w 10% aplikacji zostało to zrealizowane poprawnie.

W korzystających w tym zakresie z własnego mechanizmu wykryto błędy implementacji, przez które certyfikat wygenerowany przez przestępcę nie zostałby odrzucony, umożliwiając mu tym samym dokonanie ataku typu man in the middle. W kilku aplikacjach stwierdzono przeprowadzanie uwierzytelniania oraz komunikację z serwerem otwartym tekstem.

W jednej przejście w ten tryb następowało w razie nienawiązania bezpiecznego połączenia. To mogło zostać wykorzystane przez hakera, który poprzez celowe zakłócanie transmisji wywoływałby ten tryb, żeby przeprowadzić atak man in the middle i podsłuchać albo zmienić przesyłane dane.

Do kategorii M4 zaliczane są przypadki niewłaściwie przeprowadzanego uwierzytelniania. Wykryto je aż w 18% testowanych aplikacji. Nieprawidłowości polegały na: niewłaściwym zarządzaniu sesją, niesprawdzaniu hasła przy interakcji z serwerem lub urządzeniem, nawet w czasie wykonywania operacji o znaczeniu krytycznym oraz szyfrowaniu haseł metodami, które nie zapewniają już odpowiedniego poziomu bezpieczeństwa, jak MD5, a nawet base64.

Twórcy prawie jednej czwartej aplikacji (24%) wykazali się niefrasobliwością w zakresie implementacji funkcji kryptograficznych (M5). Na przykład w dwóch z nich wykryto identyczny fragment kodu. Jak się potem okazało, został on zaczerpnięty z tego samego źródła, którym był ogólnodostępny portal dla programistów. Co gorsza, zapisano w nim w otwarty sposób wartość wektora inicjalizującego, która miała pozostać niezmienna, chociaż prawidłowo powinna być unikalna dla każdej operacji szyfrowania.

M6, M7

Do kategorii M6 zaliczane są przypadki niewłaściwie przeprowadzanej autoryzacji. Z kolei M7 obejmuje dużą grupę niedociągnięć, które są przyczyną słabej jakości kodu aplikacji klienckiej. Dotyczą one m.in. nieefektywnego zarządzania pamięcią czy nieprzestrzegania dobrych praktyk w zakresie obsługi wyjątków.

Ponieważ wiele mobilnych HMI dopuszcza wgrywanie, pobieranie oraz zapisywanie projektów w postaci archiwum .ZIP, postanowiono zbadać także, czy występuje w nich luka typu directory traversal. Polega ona na oparciu się na nazwie pliku podanej w archiwum, bez sprawdzenia, czy nie zawarto w niej znaków specjalnych wykorzystywanych w zapisie ścieżek relatywnych.

Może mieć to poważne konsekwencje, jeżeli bowiem w nazwie pliku zapisano odwołanie do katalogu nadrzędnego lub innego miejsca, zaś aplikacja nie została przed tym zabezpieczona, zostanie on tam rozpakowany. W ten sposób atakujący jest w stanie nadpisać konkretny plik, o ile oczywiście z poziomu aplikacji zapis w danej lokalizacji jest dopuszczalny.

W ramach eksperymentu specjaliści z Embedi i IOActive dokonali ataku na jedną z aplikacji mobilnych o funkcjonalności HMI. Umożliwiała ona pobranie z serwera archiwum .ZIP, bez prawidłowo zaimplementowanego sprawdzenia, czy jego adres jest właściwy. W rezultacie w ramach ataku man in the middle badacze spowodowali, że za jej pośrednictwem z fałszywego serwera pobrane zostało odpowiednio przez nich przygotowane archiwum.

Po jego rozpakowaniu okazało się, że zgodnie z planem został zmieniony obrazek, który przedstawiał instalację sterowaną za pomocą tej aplikacji. I chociaż na pierwszy rzut oka wszystko wyglądało tak jak wcześniej, ze schematu został usunięty jeden z ważnych wskaźników. To wprowadzało operatora w błąd co do rzeczywistego stanu instalacji. Blisko jedna trzecia przetestowanych aplikacji miała luki zaliczane do kategorii M7.

JAK WYKRYĆ ZROOTOWANIE?

Kolejną grupę stanowią niedociągnięcia, przez które złośliwe oprogramowanie może ingerować w kod aplikacji. W większości tych, które na celownik wzięli specjaliści z Embedi i IOActive (94%), nie zaimplementowano przeciwko temu żadnych środków zaradczych. Zaledwie w dwóch z nich został wprowadzony prosty mechanizm detekcji wykrywający to, czy urządzenie, na którym jest zainstalowana aplikacja, zostało zrootowane.

W praktyce oznacza to, że użytkownik uzyskał prawa administratora, a zatem może dodawać, usuwać lub modyfikować komponenty systemowe, będące poza zasięgiem "zwykłych" użytkowników. Wadą tego rozwiązania jest to, że wtedy w niektórych urządzeniach analogiczne uprawnienia zyskują również aplikacje, które takie operacje mogą wykonywać bez wiedzy użytkownika na prywatnych folderach i plikach innych programów.

Wykrywanie tego, czy urządzenie zostało zrootowane, jest realizowane na kilka sposobów. Na przykład można wprowadzić mechanizm sprawdzania, czy zainstalowano oprogramowanie, z którego korzysta się, aby uzyskać uprawnienia roota. Ponadto podejmuje się próbę modyfikacji chronionych folderów, sprawdza ustawiania systemowe i próbuje się je zmieniać. W przypadku wykrycia stanu zrootowania aplikacja powinna ostrzec o tym użytkownika.

M9, M10 ORAZ LUKI W BACKENDZIE

Do kategorii M9 zaliczany jest brak ochrony kodu aplikacji przed inżynierią wsteczną. Niepowołana osoba, która podejmie się takich działań, dysponując niezabezpieczonym kodem źródłowym aplikacji, może na podstawie jego analizy uzyskać wiele informacji, z jej punktu widzenia użytecznych, zaś dla bezpieczeństwa programu groźnych.

Przykładowo poznając działanie zaimplementowanych algorytmów i wykorzystywane biblioteki, może odkryć jego najsłabsze punkty. Aby to utrudnić, stosuje się różne techniki, na przykład zaciemnianie kodu. Polega ono na wprowadzaniu w nim takich zmian, które utrudniają jego zrozumienie, lecz nie wpływają na jego działanie.

Najprostsze z nich polegają na stosowaniu takich nazw zmiennych i metod, na podstawie których nie można wywnioskować ich znaczenia. Te bardziej skomplikowane wymagają zmodyfikowania na przykład działania pętli czy relacji dziedziczenia. Niestety w ponad połowie przetestowanych aplikacji nie zastosowano żadnej ochrony przed inżynierią odwrotną.

Do kategorii dziesiątej zalicza się różnego typu rozwiązania zaimplementowane w kodzie aplikacji, dla których nie ma żadnego praktycznego zastosowania w ramach gwarantowanej funkcjonalności programu (na przykład uprawnienia do rejestrowania głosu bez zastosowania dla nagrań) i takie wykorzystywane jedynie na etapie tworzenia kodu, nieprzeznaczone do użytku w środowisku produkcyjnym. Są one niepożądane, gdyż atakujący może je wykorzystać w sposób trudny do przewidzenia. W prawie jednej czwartej sprawdzonych aplikacji wykryto luki kategorii M10.

Chociaż nie było to głównym celem badań specjalistów z firmy Embedi i IOActive, sprawdzili oni również podatność na ataki od strony backendu. Jak się okazało, najczęściej występującą luką był brak zabezpieczeń serwerów SCADA przed atakiem typu SQL injection. Niefiltrowanie po stronie serwera danych użytkownika wykorzystywanych do tworzenia zapytań do bazy danych okazało się dużą niespodzianką, ponieważ nie jest to zagrożenie nowe, a wręcz przeciwnie, zaś sposoby na jego ograniczenie są powszechnie znane.

DOBRE RADY

W podsumowaniu wniosków z przeprowadzonych testów aplikacji mobilnych HMI twórcy raportu "SCADA and mobile security in the Internet of Things era" podali kilka zaleceń, które powinni wziąć pod uwagę ich twórcy. Przede wszystkim muszą pamiętać, że tworzone przez nich oprogramowanie stanowi swego rodzaju bramę do kluczowych dla funkcjonowania zakładów przemysłowych instalacji, maszyn i systemów.

Powinno to wpłynąć na decyzje projektowe, w tym dotyczące danych wejściowych i wyjściowych aplikacji. Muszą też podjąć wszelkie możliwe starania, które zapobiegną awariom oprogramowania lub wprowadzaniu jego użytkowników w błąd. Tworząc kod, powinni mieć stale w pamięci wytyczne takich organizacji jak OWASP i innych, które opracowują dobre praktyki w zakresie projektowania aplikacji mobilnych.

Testy jednostkowe i funkcjonalne muszą być przeprowadzane obowiązkowo, aby uzyskać pewność, że przynajmniej podstawowe zabezpieczenia, takie jak uwierzytelnianie i autoryzacja dostępu, działają prawidłowo. Powinno się również unikać przechowywania oraz przesyłania danych uwierzytelniających sposobami, które nie spełniają standardów bezpieczeństwa i nie przechowywać wrażliwych danych na kartach pamięci bez wprowadzenia kontroli dostępu.

Trzeba ponadto zapewnić poufność oraz integralność danych aplikacji. Połączenie z serwerem powinno być szyfrowane. Do zadania obsługi wyjątków trzeba podejść bardzo poważnie. W przypadku, gdy wystąpi nieprzewidziany błąd, należy zadbać, aby aplikacja zakończyła pracę w sposób zrozumiały dla użytkownika. Ważne także, by w logach programu w zapisach odnotowujących wystąpienie wyjątków przypadkiem nie umieszczać informacji wrażliwych. Poza tym nie wolno zapominać o zaciemnianiu kodu i wdrożeniu rozwiązań, które nie pozwolą na zewnętrzną ingerencję w kod aplikacji.

PODSUMOWANIE

 

Tematy numerów APA w przyszłości

Jeszcze do niedawna nikt nie przewidywał, że smartfony i tablety znajdą w przemyśle profesjonalne zastosowanie, a tym bardziej że za pośrednictwem urządzeń konsumenckich będzie można uzyskać dostęp do kluczowych maszyn oraz instalacji w zakładzie.

Biorąc jednak pod uwagę przedstawione w artykule korzyści, jakie to ze sobą niesie i fakt, że świadomość w zakresie cyberbezpieczeństwa wciąż rośnie, co wcześniej czy później wymusi na twórcach aplikacji mobilnych dla przemysłu uwzględnienie zaleceń specjalistów w tej dziedzinie, można jedynie oczekiwać dalszej popularyzacji przenośnych HMI.

Na to, że nie ma już właściwie od tej tendencji odwrotu, wskazuje również fakt, że na rynek pracy zaczynają wkraczać młodzi ludzie na co dzień nierozstający się ze smartfonami, którzy możliwości korzystania z nich będą oczekiwać również w życiu zawodowym.

Monika Jaworowska