Piotr Rogalewski

Kamery i inne urządzenia security już dawno przestały być systemami zamkniętymi. W istocie są to specjalizowane komputery, które realizują mnóstwo zadań dodatkowych, z wykorzystaniem sztucznej inteligencji włącznie. Filtrowanie fałszywych alarmów, rozpoznawanie sylwetki człowieka lub pojazdu, rozpoznawanie twarzy czy numerów rejestracyjnych „na pokładzie” urządzeń to tylko kilka przykładów możliwości obecnych rozwiązań.

W architekturze systemu traktujemy kamerę czy rejestrator jako sprzęt, ale tak naprawdę realizacja tych przykładowych zadań możliwa jest tylko dzięki oprogramowaniu działającemu wewnątrz tego sprzętu. Na rynku komercyjnym o podobnych systemach mówi się, że są „smart”.

Jaki mamy problem?

Można przyjąć za pewnik, że jeśli coś jest „smart”, to jest podatne na atak cybernetyczny. Dlaczego? Ponieważ mylić się jest rzeczą ludzką, a współczesne metody inżynierii oprogramowania oparte na metodykach „zwinnych” (np. SCRUM) niestety sprawy nie ułatwiają. W 2015 r. międzynarodowa firma konsultingowa Roland Berger przeprowadziła badania, z których wynika, że średnia stopa błędów programistycznych zawiera się w granicach między 15 a 50 problemów na każde 1000 linii kodu programu. Samo jądro systemu operacyjnego Linux stosowanego powszechnie w urządzeniach security to obecnie kilkanaście milionów linii kodu. Oprogramowanie kamery IP to kolejne kilka, kilkanaście milionów linii.

Co więcej, twórcy oprogramowania wykorzystują w swoich projektach wiele gotowych komponentów, tzw. bibliotek, które realizują zadania typowe dla niemal każdego systemu komputerowego, np. szyfrowanie danych, transmisję czy obsługę dzienników zdarzeń. Pozwala to skupić czas i środki na samym „rdzeniu” oprogramowania, nie zajmując się od podstaw sprawami, które ktoś już dobrze opracował i napisał (doskonałym przykładem są biblioteki obsługujące autentykację SSL czy EAP-TLS).

Ale tu pojawia się problem, bo nawet jeśli producent dołożył maksymalnych starań, świetnie przetestował produkt i wprowadził go na rynek jako wolny od luk, to takie ukryte luki mogły istnieć w komponentach (bibliotekach), których producent użył w swoim projekcie.

Co może się wydarzyć?

Na początku 2021 r. jedna z największych w USA firm oferujących chmurowe usługi zabezpieczeń technicznych padła ofiarą ataku hakerskiego. Przestępcy uzyskali dostęp do ponad 150 tys. kamer. Ofiarami ataku były szpitale, posterunki policji, szkoły, firmy, a nawet więzienia i areszty śledcze. Ten przykład doskonale oddaje wagę zagadnień bezpieczeństwa cybernetycznego w systemach zabezpieczeń technicznych.

Nawet gdyby skala ataku była mniejsza, to oprócz konsekwencji dla wizerunku firmy czy instytucji może wystąpić wprost zagrożenie dla bezpieczeństwa mienia i/lub osób tam pracujących. Mogą też pojawić się poważne konsekwencje prawne i finansowe, jeśli np. okaże się, że podmiot nie dołożył należytych starań związanych z implementacją zapisów RODO. Problem jest naprawdę poważny, a w aktualnej rzeczywistości geopolitycznej śmiało można stwierdzić, że zagadnienia te nigdy nie były istotniejsze niż obecnie.

Technik stosowanych przez hakerów jest wiele. Exploit, czyli wykorzystanie błędów (luk) systemu do przejęcia kontroli nad nim, metoda brute force, czyli łamanie hasła metodą podstawiania kolejnych kombinacji znaków, middle man (człowiek w środku) polegający na podsłuchaniu i/lub modyfikacji transmisji do odbiorcy to tylko kilka przykładów.
Do tych technik programistycznych dochodzą inne, czysto socjotechniczne, np. „phishing” (fałszywe wiadomości ze spreparowanymi linkami lub niebezpiecznymi załącznikami), czy nawet „haking” fizyczny (np. kradzieże nośników danych).

W walce z socjotechnikami każdy z nas jest na pierwszej linii ognia, ale zwykle czujność i rozsądek wystarczą do zneutralizowania zagrożenia. Nie otwieramy maili z nieznanego źródła, nie klikamy linków, nie otwieramy załączników. Usuwamy wiadomość i zwykle jest po kłopocie. Jednak zagrożenia innego typu są tak różnorodne i jest ich tak wiele, że wymagają bardziej kompleksowego podejścia do zagadnienia.

Co można zrobić?

Po pierwsze – mieć świadomość zagrożeń. Skąd mamy wiedzieć, na jakie aktualne zagrożenia jest narażony nasz system zabezpieczeń technicznych? Pierwszoplanową rolę odgrywa tu jasna i szybka komunikacja ze strony producenta. Jeśli zidentyfikował on lukę w swoich produktach, musi jak najszybciej opracować odpowiednią poprawkę, przetestować ją i wydać np. w postaci nowej wersji firmware, jednocześnie powiadamiając swoich partnerów.

Ale producent sam nie jest w stanie rozwiązać problemu, gdyż uczestnikami procesu są też: klient końcowy, instalator/integrator i dystrybutor. Z różnych względów producent nie jest często w stanie dotrzeć do wszystkich podmiotów „na końcu łańcucha”. Dlatego komunikacja i szybkość działania mają tu kluczowe znaczenie. Zobaczmy scenariusz przedstawiony na rys. 1.

Hakerzy odkrywają podatność i wykorzystują ją do penetracji urządzenia. Producent urządzenia uzyskuje świadomość problemu albo samodzielnie go wykrywając, albo np. polegając na testach penetracyjnych realizowanych regularnie przez firmy zewnętrzne. Następnie producent przygotowuje poprawkę oprogramowania „łatającą” lukę i powiadamia o tym zainteresowanych partnerów/klientów.

I teraz rzecz zasadnicza: natychmiastowa instalacja poprawki powoduje „wyzerowanie” działań hakerskich, które będą musiały być uruchomione niejako od nowa w celu poszukiwania ewentualnej kolejnej (innej) luki lub próby obejścia wdrożonej poprawki. Hakerzy amatorzy, czyli grupa osób wykorzystująca publiczne już informacje o podatności, nie będzie mogła użyć ich do swoich celów.

Co jednak dzieje się, gdy klient nie ma świadomości istnienia poprawki lub taką świadomość ma, ale z aktualizacją zwleka? Spójrzmy na wykres z rys.2. Sytuacja przedstawia się tu o wiele gorzej – mimo wydania poprawki przez producenta hakerzy mogą operować bez żadnego dodatkowego nakładu pracy, wciąż wykorzystując „starą” lukę. Dodatkowo system jest narażony na działania hakerów amatorów, najczęściej wykorzystujących gotowe narzędzia typu exploit, zazwyczaj pojawiające się szybko po ujawnieniu podatności.

Tak więc skuteczny i szybki proces aktualizacji opiera się na ścisłej współpracy producenta, dystrybutorów, instalatorów/integratorów i klientów końcowych. Każdy z tych podmiotów może jednak zwiększyć sprawność swojej reakcji na zagrożenie, korzystając z publicznych baz danych wykrytych podatności. Najpopularniejszą chyba bazą tego typu jest strona http://cve.mitre.org. Zawiera ona wszystkie zgłoszone podatności, ich opis i stopień zagrożenia, jakie niosą.

Jak to robi Hikvision?

Zaufanie do urządzeń jako bezpiecznych elementów systemu jest nie do przecenienia. Hikvision podchodzi do tego zagadnienia kompleksowo. Przede wszystkim wdraża filozofię Secure by design i Secure by default. Ta pierwsza oznacza projektowanie urządzeń w taki sposób, by od momentu utworzenia miały bezpieczną architekturę i swoją konstrukcją logiczną i fizyczną minimalizowały ryzyko wystąpienia problemów.
Drugi element oznacza taką domyślną konfigurację produktów, by urządzenie „wyjęte z pudełka” było możliwie najbardziej bezpieczne. W praktyce oznacza to np. brak haseł domyślnych, brak ukrytych funkcji (tzw. backdoor), wymuszanie wysokiej komplikacji hasła, brak możliwości użycia w haśle nazwy użytkownika, szyfrowanie plików z oprogramowaniem układowym (firmware), szyfrowanie plików konfiguracyjnych itd.

To także szereg zabezpieczeń na różnych poziomach – od fizycznych (np. zamek chroniący panel dostępu do dysków, podwójny zasilacz, niezależne porty sieciowe dla stacji roboczych i kamer), przez systemowe (autentykacja w protokole 802.1x EAP-TLS, szyfrowanie strumieni wizyjnych, kody weryfikacyjne w chmurze HikConnect, bezpieczna transmisja plików SFTP czy filtrowanie adresów IP), po bezpieczeństwo danych (zapis RAID, zapis awaryjny n+1, automatyczna kopia zapasowa, zarządzanie retencją danych, zapis awaryjny na kartach SD kamer i automatyczne kopiowanie tych danych do rejestratorów).

Ramy tego artykułu pozwalają zaledwie na bardzo ogólne zarysowanie istoty zagadnienia bezpieczeństwa cybernetycznego w systemach zabezpieczeń technicznych. Gorąco zachęcamy wszystkich zainteresowanych zgłębieniem tematu do bezpośredniego kontaktu z firmą Hikvision lub jej autoryzowanymi dystrybutorami.

Hikvision Poland
ul. Żwirki i Wigury 16B
02-092 Warszawa
info.pl@hikvision.com
https://www.hikvision.com/europe/