Tomasz Dacka
Elektroniczne systemy zabezpieczeń już dawno przestały być postrzegane jako proste autonomiczne rozwiązania wykorzystujące do transmisji standardy analogowe lub szeregowe, stając się zaawansowanymi rozwiązaniami opartymi na protokole TCP/IP. Zmiana ta przyniosła nie tylko wymierne korzyści, ale także nowe zagrożenia. Cyberbezpieczeństwo odmieniane jest przez wszystkie przypadki, a ataki na infrastrukturę krytyczną jedynie dodają temu zagadnieniu rozgłosu.
Jak w związku z tym, w kontekście bezpieczeństwa teleinformatycznego (IT), należy podchodzić do elektronicznych systemów zabezpieczeń technicznych? Czy rzeczywiście trzeba je chronić również w obszarze środowiska IT, w którym pracują? Postaram się odpowiedzieć na te pytania, wskazując, na co zwracać szczególną uwagę i jak z korzyścią łączyć cyberbezpieczeństwo z bezpieczeństwem fizycznym.
- Zabezpieczenia elektroniczne stały się już istotnym aspektem każdej polityki bezpieczeństwa i śmiało wkroczyły do świata IT, a co za tym idzie, do świata bezpieczeństwa IT. Powody tego są następujące:
- Wzrasta świadomość i wiedza nt. urządzeń i systemów zabezpieczeń, które są „na pierwszej linii ognia”. Cóż z tego, że wdrożymy w środowisku IT kompleksową ochronę wielowarstwową, tzw. DiD (Defence in Depth), jeśli dostęp do terenu, budynku, pomieszczenia, szafy rack będzie nieodpowiednio zabezpieczony, co może doprowadzić do łatwego skompromitowania zabezpieczeń IT.
Krajowe uregulowania prawne, tj. ustawa o Krajowym Systemie Cyberbezpieczeństwa czy ustawa o ochronie informacji niejawnych zaczęły zauważać istotę problemu, nie tylko odnosząc się do omawianej tematyki, ale także wydając oddzielne rozporządzenia wykonawcze.
Czy zatem każda osoba z branży security powinna stać się administratorem środowiska IT? Zdecydowanie nie (chociaż to interesująca tematyka). Czy należy więc to ryzyko w pełni przenieść do działów IT? Nie jestem zwolennikiem tej metody. Działy Sec IT bardzo często nie rozumieją istoty sprawy, celów i zasady działania elektronicznych systemów zabezpieczeń, nie znają standardów, wytycznych czy norm. Z kolei osoby odpowiedzialne za zabezpieczenia elektroniczne nie kwapią się z dostarczaniem pomocnych informacji. Kamera CCTV lub kontroler SKD to jednak nie serwer czy środowisko wirtualne. Do tego dochodzą bariera wynikająca z braku zrozumienia podstawowych zasad zabezpieczania architektury IT przez typowych „bezpieczników” oraz brak wypracowanego wspólnego języka dwóch odrębnych działów bezpieczeństwa, grających tak naprawdę do jednej bramki. Czy można zatem te dwa światy połączyć w sposób optymalny? Uważam, że można. Ponieważ urządzenia i systemy zabezpieczeń działają w środowisku IT, a nie odwrotnie, to właśnie one głównie muszą dostosować się do standardów, prawideł świata IT. Na co zatem zwrócić szczególną uwagę?
Ogólne wytyczne
Branża security może z powodzeniem czerpać z najlepszych praktyk (best practices) z branży IT, przekładając je na codzienną pracę. Branża IT wypracowała kilka tzw. frameworków, ogólnych wytycznych działania, metodyk, które w pewnych aspektach są zbieżne z celami branży zabezpieczeń. Wspólnie chronimy przecież aktywa. I tak w typowym świecie zer i jedynek wykorzystujemy czynniki kontrolne (security controls), dzięki czemu zapewniamy zasobom odpowiedni poziom bezpieczeństwa.
Security controls dzielą się na trzy główne obszary:
- administracyjne – określane za pomocą polityk, procedur i wytycznych sposoby postępowania w określonych sytuacjach. Można to przełożyć na zasady dostępu do obiektu, ustalenie harmonogramu przeglądów technicznych, skanów podatności, zasad obsługi incydentów lub przekazywania materiału wizyjnego zainteresowanym stronom;
- techniczne – dotyczą bezpieczeństwa urządzeń (appliances), aplikacji (software) czy środowisk systemów operacyjnych (OS). Do tego obszaru zaliczymy zabezpieczenia, tj. ACL (Access Control Lists) czy IDS (Intrusion Detection Systems), a także dobrze nam znane SKD, VSS, VMS, SSWiN;
- fizyczne – organizujące głównie ruch, np. ogrodzenie, śluza, zamki, znaki ostrzegawcze, bramki, oświetlenie itp.
Analiza ryzyka
Z dużym niepokojem obserwuję w branży security niechęć do przeprowadzania analizy ryzyka na etapie koncepcji czy projektu wykonawczego, a tym samym brak wymagań po stronie inwestorów co do jej przeprowadzania. A to właśnie ten dokument wskazuje, przed czym i w jaki sposób mamy chronić. Analiza ryzyka w security IT jest wszechobecna, wiele decyzji podejmuje się właśnie na jej podstawie. Zanim zaprojektujemy, zamontujemy kamerę, musimy wiedzieć, jakie cele i zadania dany punkt kamerowy ma realizować (np. obserwację czy inspekcję zgodnie z normą PN EN 62676-4
Systemy dozoru wizyjnego stosowane w zabezpieczeniach: Wytyczne stosowania). Identyfikacja aktywów, podatności, zagrożeń, a następnie ocena ryzyka i sposobu postępowania z nim (tzw. mitygacja) są sprawą kluczową na początkowych etapach wdrażania, późniejszej modernizacji czy wymiany systemów. Zachęcam do przeprowadzania analiz, które nie muszą być rozbudowanym dokumentem, można je wykonać np. w sposób graficzny (analiza typu Bow – Tie). Schemat tego typu analizy przedstawiono na rys. 1.
CIA
Nie mam zamiaru wprowadzać czytelnika w tajniki pracy operacyjnej jednej z najbardziej znanych agencji na świecie. CIA to również skrót od Confidentiality, Integrity, Availability i odnosi się do trzech głównych atrybutów informacji i danych: poufność, integralność, dostępność (rys. 2). Systemy VSS czy KD przetwarzają ogromne ilości danych (w tym dane osobowe), które ze względu na ogólnie pojęte bezpieczeństwo są szczególnie narażone na utratę wymienionych atrybutów. Do tego dochodzą zapisy RODO wymuszające ochronę danych osobowych w sposób adekwatny do celu ich przetwarzania.
Poufność – informacje są przeznaczone tylko dla uprawnionych osób. Nasze nagrania wideo czy możliwość nadawania uprawnień nie mogą być dostępne dla każdego użytkownika.
Integralność – zapewniona jest spójność danych, które nie mogą być w żaden sposób modyfikowane bez naszej wiedzy. Najlepszym przykładem jest atak typu Man in the Middle, kiedy atakujący jest w stanie przechwycić uprawnienia administratora systemu SKD i dobrowolnie nadawać prawo dostępu do zabezpieczonych stref. Innym przykładem są nagrania wideo, które mogą stanowić dowody wystąpienia incydentu, tutaj również musimy być pewni, że materiał nie był modyfikowany.
Dostępność – informacja jest osiągalna dla osób uprawnionych, poufność zapewnia nam uprawnienie do zapoznania się z nią, a dostępność to, że w każdym momencie możemy to zrobić. Zapewniamy tym samym pełną rozliczalność systemów bezpieczeństwa w momencie śledztwa w obszarze wystąpienia incydentu, czy zasilamy danymi systemy analityczne. To również atrybut, który zapewnia dostęp do kopii zapasowych.
W jaki zatem sposób triada CIA przekłada się na codzienne obowiązki specjalisty ds. bezpieczeństwa? Czy poufność, integralność i dostępność odgrywają ważną rolę w codziennych obowiązkach? Zachęcam do przeanalizowania wybranych kwestii:
- Jaki system operacyjny pracuje w danej kamerze i czy np. nie jest to stara dystrybucja Linuxa z dosyć długą listą dobrze wszystkim znanych podatności?
- Czy dana kamera zawiera moduł TPM (Trusted Platform Module), aby w sposób bezpieczny przechowywać poświadczenia (klucze kryptograficzne, certyfikaty)? I czy mamy pomysł na to, jak z tych poświadczeń korzystać?
- Czy nasze urządzenia pozwalają nam na wdrożenie uwierzytelniania zgodnie ze standardem 802.1x? Dzięki temu eliminujemy ryzyko wpięcia do naszej sieci urządzeń, które nie będą w stanie się uwierzytelnić zgodnie z wdrożonymi przez nas zasadami.
Jaką technologię RFID wykorzystują nasze karty i czytniki SKD? Czy jest bezpieczna, czy jednak łatwa do skompromitowania, a skopiowanie karty nie nastręcza problemów?
Jakie protokoły komunikacyjne wykorzystują nasze systemy i czy gwarantują poufność oraz integralność przetwarzanych informacji? - Czy szyfrujemy dane? A jeśli tak, to za pomocą jakiego algorytmu i czy jest on na tyle „silny”, by w akceptowalny sposób „obudować” nasze dane?
- Czy jest sens tworzenia kopii zapasowych i budowania środowiska redundantnego na wypadek awarii serwera i błędów bazy danych (dostępność informacji)? Czy mamy wdrożone plany backupowe oraz disaster recovery dla naszego obszaru?
- Czy jesteśmy zabezpieczeni odpowiednimi umowami aktualizacji systemów w momencie wykrycia błędów w oprogramowaniu?
- Czy sprawdziliśmy łańcuch dostaw urządzeń i oprogramowania, czy jest on dla nas akceptowalny?
- Czy zapewniliśmy unikatowe loginy do urządzeń, a może nadal działają na domyślnym użytkowniku i haśle? Czy wprowadziliśmy politykę dotyczącą haseł?
Hardening
Pojęcie to, niestety nieznane jeszcze w branży zabezpieczeń (security), wywodzące się ze świata IT, tłumaczy się jako „utwardzanie” urządzeń. Co oznacza i dlaczego jest tak ważne? Wyjmując kamerę z pudełka czy instalując oprogramowanie VMS od dostawcy, mamy produkt skonfigurowany domyślnie pod kątem łatwości użytkowania (tzw. plug and play). Kamerze należy tylko nadać adres IP, wyregulować optykę i już działa (zachęcam do głębszych konfiguracji każdego punktu kamerowego).
Patrząc jednak przez pryzmat sposobu, w jaki kamera się komunikuje, sprawa nie jest taka prosta. Domyślna konfiguracja zazwyczaj nie zapewnia odpowiedniego poziomu bezpieczeństwa w warstwach aplikacyjnych i komunikacyjnych. Jak to w życiu często bywa, to, co ułatwia pracę (np. protokoły typu discovery usprawniające wyszukiwanie kamer w sieci po adresach MAC) stanowi duże zagrożenie od strony cyberbezpieczeństwa.
Wiodący producenci wydają wytyczne w tym zakresie, tzw. hardening guide, krok po kroku opisujące czynności, jakie należy wykonać, aby utrudnić potencjalnym intruzom „dostęp” do systemu (np. zamykać porty niepotrzebne do codziennej pracy kamery, jakie usługi systemu VMS, OS należy wyłączyć, jeśli nie są wykorzystywane). Uważam, że hardening systemów zabezpieczeń powinien być ostatnim elementem wdrożenia i podlegać ocenie przy odbiorze.
Least privilege
Termin ten odnosi się do wyspecyfikowania uprawnień do urządzeń i aplikacji w taki sposób, aby użytkownik posiadał tylko te poświadczenia i dostępy, które są mu potrzebne do wykonywania swoich obowiązków. Operator centrum nadzoru ma dostęp do obrazu na żywo, może przeglądać materiał archiwalny, ale nie ma uprawnień do jego kasowania czy kopiowania. Jeśli jest to konieczne, wymaga poświadczeń kierownictwa, które tym samym autoryzuje taką czynność (tzw. zasada two-man rule). Ma to również odniesienie do wymagań RODO, w ten sposób zapewniamy wymóg tzw. minimalizacji danych.
Certyfikaty
Certyfikat dla urządzenia (np. kamery) potwierdza jego tożsamość. Powinien być wydany przez jednostkę certyfikującą (Certificate Authority – CA). Nie wchodząc w strukturę działania CA, załóżmy, że mamy w organizacji swój wewnętrzny CA wystawiający odpowiednie certyfikaty dla naszych urządzeń. Wtedy jesteśmy pewni, że w sieci działają tylko autoryzowane przez nas urządzenia (odnosząc się dodatkowo do wspomnianego wcześniej standardu uwierzytelniania 802.1x).
Ryzyko podmiany kamery czy jej demontażu, by w ten sposób dostać się do sieci, jest raczej niewielkie, natomiast ryzyko nieuprawnionego wejścia do sieci za pomocą stacji interkomowej wyniesionej do strefy ogólnodostępnej gwałtownie wzrasta. To jedna strona medalu. Drugą jest sposób działania intruzów, który przedstawię w drugiej części artykułu.
W kolejnej części postaram się też wyjaśnić na czym polega modus operandi cyberprzestępców opisany przez tzw. The Kill Chain, rozszyfruję znaczenie skrótu AAA oraz przedstawię cykl „życia” bita w elektronicznych systemach zabezpieczeń.
 |
|
