Zabezpieczanie zabezpieczeń

Jan T. Grusznic

Cyberdefilada ruszyła na całego. Rynek ciągle nienasycony literaturą omawiającą dobre praktyki w zakresie cyberbezpieczeństwa domaga się kolejnych informacji. Działalność marketingowa firm z  branży security pokazuje, jak istotna to pozycja w portofolio produktowym, którym producent może się szczycić.

Na podstawie docierających z rynku przekazów można wywnioskować, że niektórzy dostawcy zmienili zakres swojej działalności na rzecz rozwoju produktów zwiększających bezpieczeństwo sieciowe. Dzielni handlowcy sprzedają cyberbezpieczeństwo jako kolejny produkt, który można dostarczyć „w pakiecie”, ponieważ wpisuje się w trend obecnych oczekiwań posiadania bezpiecznego rozwiązania.

Z moich obserwacji wynika, że z cyberbezpieczeństwem na rynku zabezpieczeń technicznych jest trochę jak z kolejną funkcją na liście życzeń użytkownika, którą musi spełnić urządzenie – WDR: jest, super(światło)czułość: jest, megarozdzielczość: obecna, cyberbezpieczeństwo: zaimplementowane. I szafa gra…

Chciałbym, aby tak było – niestety nie jest. Stosowanie zabezpieczeń przed atakami sieciowymi zbytnio się nie różni od reguł, jakie od dekad stosujemy w zabezpieczaniu mienia za pomocą rozwiązań technicznych. Najpierw tworzymy listę potencjalnych zagrożeń, uwzględniając charakter obiektu, jego otoczenie, działania biznesowe itp. (identyfikacja). Następnie analizujemy je pod kątem prawdopodobieństwa wystąpienia i skutków z tym związanych (ocena). Na tej podstawie tworzymy potencjalne rozwiązanie lub kilka rozwiązań, które mają za zadanie zmniejszyć ryzyko pojawienia się prawdopodobnych zagrożeń (planowanie) i je wdrażamy (rys. 1)1).

Co istotne, cała procedura powinna być powtarzana cyklicznie lub wg potrzeb i bynajmniej nie ograniczać się do rozwiązań technicznych – dotyczy całego rozwiązania, przedsiębiorstwa, ludzi czy procesów. Tylko podejście całościowe ma sens, jaki bowiem może być pożytek z drzwi antywłamaniowych osadzonych w karton-gipsie czy kamer wandaloodpornych instalowanych na suficie podwieszanym?

Z cyberbezpieczeństwem nie jest inaczej – jedynie holistyczne podejście do problemu ma szansę na uzyskanie solidnego zabezpieczenia. Dobrze skonfigurowana kamera nie zapewni właściwej ochrony przed atakiem, jeśli pozostałe urządzenia podłączone do tej samej sieci będą pracowały w ustawieniach domyślnych (czytaj: będą niezabezpieczone).
Istnieje kilka podstawowych kroków, które pozwalają, aby system mógł być traktowany jako zabezpieczony. Zastrzegam, że głębokość wprowadzanych zmian zależy od kontekstu i przeprowadzonej analizy ryzyka. Nie ma jednej recepty na wszystkie potencjalne zagrożenia. Tych kilka kroków prowadzących do uzyskania świadomego minimalnego poziomu bezpieczeństwa, które wpajam już od kilku lat podczas szkoleń lub wizyt w obiektach, są niczym porządne okna i drzwi z solidnymi okuciami chroniące mienie.

Czas
Podstawą utrzymania bezpieczeństwa w sieci jest czas. To zmienna istotna z kilku powodów – od czasu, tj. sparametryzowanych daty, godziny, strefy czasowej, zależą uprawnienia dostępu do urządzeń, odtworzenie logów lub nagrań wizji/fonii czy automatyzacja procesów, takich jak wyzwalanie akcji w reakcji na wystąpienie zależnych od siebie zdarzeń. Technikom synchronizacja wszystkich elementów systemu względem jednej sygnatury czasu pozwala na szybkie ustalenie przyczyn awarii. Administratorzy sieci na podstawie oprogramowania analizującego ruch w sieci oraz logów urządzeń brzegowych reagują na anomalie, które mogą wskazywać na obecność niechcianego oprogramowania. Aby wymienione działania były efektywne, wszystkie te elementy systemu muszą synchronizować się z autorytatywnym serwerem czasu. Brak synchronizacji wśród urządzeń może stanowić przyczynę poważnego „bólu głowy”. Urządzenie pracujące w sieci wydzielonej na ogół w jakimś stopniu jest dozorowane przez narzędzia SIEM2).

Efektywność tego narzędzia polega na przetwarzaniu logów z urządzeń, których wpisy są wprowadzane zgodnie z kolejnością momentu wygenerowania wpisu, nie zaś dostarczenia. Bez dokładnego znacznika czasu w plikach dzienników SIEM nie jest w stanie ponownie utworzyć dokładnej sekwencji wzoru dla proaktywnego ostrzegania i wyjaśnienia anomalii po awarii.
Niektórzy z nas uważają, że synchronizacja jest zbyteczna, skoro wszystko działa… O ile utrzymanie synchronizacji sygnałów fonii i wizji z dwóch różnych urządzeń na serwerze zapisu nie wymaga synchronizacji czasu3), o tyle do osiągnięcia podstawowego poziomu bezpieczeństwa jest kluczowe. Aby nie być gołosłownym, posłużę się przykładem sprawy hakerskiej opisanej później przez Clifforda Stolla w książce „Kukułcze jajo”. Na podstawie informacji zawartych w logach autor odtwarza niewinny błąd w rachunkach na 75 centów, aż do wykorzystania komputerów przez 9 sekund, co nie zostało odnotowane. Dane z logów i zastosowanie różnych technik dochodzeniowych pozwoliły Stollowi prześledzić atak Markusa Hessa z Hanoweru w Niemczech, który zbierał informacje z amerykańskich komputerów i sprzedawał je sowieckiemu KGB. Niesamowita rozgrywka, która swój początek ma w 9 sekundach nieodnotowanych w dziennikach systemowych.

Historia ta pokazuje jednocześnie, że jeśli nie wiesz, czego szukasz, odnalezienie tego wśród niezsynchronizowanych danych będzie niewiarygodnie trudne. Dlatego po pierwsze, zacznij od kompleksowego spisu systemów, usług i aplikacji w środowisku zarządzania dziennikami/SIEM. Sprawdź, czy są one synchronizowane i z jakim serwerem. Gdy wiesz, skąd pochodzi informacja o sygnaturze czasowej (lokalizacja geograficzna, strefa czasowa, system, aplikacja i/lub usługa), zastosuj techniki normalizacji w systemie zarządzania dziennikami aplikacji. Jeśli log jest pobierany z urządzenia, o którym wiadomo że ma bardzo dokładne i wiarygodne zewnętrzne źródło czasu, oryginalny znacznik czasu w dzienniku można uznać za akceptowalny. Należy jednak pamiętać, że mechanizm zarządzania dziennikami może nadal wymagać normalizacji informacji o czasie, by odtworzyć pojedynczy meta-czas dla wszystkich urządzeń, aby reguły korelacji mogły działać efektywnie. Weźmy dla przykładu firmy z firewallami w ich biurach w Londynie, Nowym Jorku i San Jose.

Dane dziennika z zapór są analizowane przez silnik i ostrzegają, że 15 stycznia 2018 r. o godz. 15:45, 13:45 i 10:45 wykryto odmowę usługi. W przypadku ich stref lokalnych są to poprawne znaczniki czasu, ale jeśli mechanizm zarządzania dziennikami normalizuje czas geograficzny w pojedynczy meta-czas lub uniwersalny czas koordynowany (UTC), jasne jest, że wszystkie trzy zapory zostały zaatakowane w tym samym czasie. Innym podejściem jest dostrojenie raportowania czasu w plikach dziennika urządzeń, aby odzwierciedlić pożądany czas uniwersalny w silniku korelacji zamiast prawidłowego czasu lokalnego.
Bez względu na rodzaj normalizacji niezawodność źródła czasu ma znaczenie kluczowe. Podczas odtwarzania zdarzeń znaczniki czasu w sieci organizacji mogą być porównywane z urządzeniami zewnętrznymi. Z tego powodu należy mieć pewność, że źródło, z którego korzystasz, jest tak dokładne, jak to tylko możliwe.

Jednym z najpopularniejszych protokołów używanych do synchronizacji czasu jest NTP (Network Time Protocol), wersja 34), który dostarcza informacji o czasie w UTC. Systemy Microsoft Windows implementują NTP jako WTS (Windows Time Service)5), a niektóre zegary atomowe dostarczają danych do Internetu w celu synchronizacji NTP. Jednym z przykładów jest Tempus udostępniony nieodpłatnie przez Główny Urząd Miar6).
Co prawda istnieją pewne obawy związane z bezpieczeństwem NTP, ponieważ używa on protokołu bezstanowego do transportu i nie jest w żaden sposób uwierzytelniany. Zdarzały się także przypadki ataków typu Denial of Service (DoS) na serwery NTP, przez co stały się one czasowo niedostępne na potrzeby dostarczania informacji o czasie.

Co możemy z tym zrobić? Niewiele, pomimo drobnych problemów związanych z bezpieczeństwem NTP jest najczęściej stosowanym (i szeroko obsługiwanym) protokołem do synchronizacji czasu urządzeń sieciowych. Można więc dołożyć wszelkich starań, aby obejść te problemy, tworząc strukturę drzewa rozpinającego serwerów (rys. 2). Dzięki takiemu podejściu urządzenia w wydzielonej sieci będą miały dostęp do odseparowanych serwerów czasu. Można też rozważyć dodanie dodatkowego monitorowania i segregacji sieci do autorytatywnych źródeł czasu tam, gdzie to możliwe.

Hasła
Nie od dziś wiadomo, że odpowiednio zbudowane i wykorzystywane hasła dostępowe to jeden z podstawowych i najważniejszych elementów budowania bezpieczeństwa teleinformatycznego w organizacji. Większość z nas doskonale zdaje sobie sprawę, jak ważnym elementem bezpieczeństwa jest odpowiednie zarządzanie takimi poświadczeniami uwierzytelniającymi. Mimo wszystko często nie przykładamy do tego wielkiej wagi, bagatelizujemy takie zabezpieczenie, żyjąc w przekonaniu, że ponieważ to wydzielona instalacja, więc co wielkiego może się zdarzyć? Tymczasem, jak podano w raportach7), coraz poważniejszym problem stają się „wewnętrzni intruzi”.

Formalnie w zakresie złożoności, długości oraz częstotliwości zmiany haseł dostępowych do systemów informatycznych, w których zachodzi proces przetwarzania danych osobowych (a do takich należy zaliczyć obrazy z monitoringu wizyjnego ukazujące wizerunki osób)8), do 25 maja 2018 r. obowiązują przepisy rozporządzenia MSWiA. Wskazują one jednoznacznie, iż w sytuacji, gdy przynajmniej jedno urządzenie infrastruktury sieci lokalnej jest podłączone do sieci publicznej, hasła dostępowe do takich systemów powinny składać się z co najmniej 8 znaków, w tym muszą wystąpić małe i duże litery, cyfra lub znak specjalny oraz być zmieniane nie rzadziej niż co 30 dni. Po wejściu RODO wymóg częstotliwości zmiany, odpowiedniej złożoności i długości hasła zostanie zniesiony. Uważam rekomendowaną przez MSWiA częstotliwość zmiany hasła za zbyt dużą, tym bardziej że większość systemów jest odizolowana od sieci zewnętrznych. Nie mam natomiast wątpliwości, że hasło powinno być na tyle bezpieczne, aby czas jego odgadnięcia (tabela) był niewspółmierny do korzyści wynikających z uzyskania dostępu do zasobów.

W przypadku branży security oznacza to, że powinno:

• składać się z co najmniej 8 znaków,
• zawierać zarówno małe, jak i duże litery,
• zawierać cyfry,
• zawierać również znaki specjalne (np. &, @, !).

Optymalnym rozwiązaniem jest utworzenie unikatowej pary: użytkownik, hasło, które będzie używane przez systemy współkorzystające z danych zasobów. Korzystanie z fabrycznego użytkownika na prawach administratora, takiego jak admin czy root, jest mniej bezpieczne nie tylko ze względu na wymóg odgadnięcia samego hasła użytkownika w celu uzyskania dostępu. Większość fabrycznych „administratorów” zezwala na nieograniczony dostęp do urządzeń w porównaniu do użytkowników stworzonych zgodnie z prawami administratora.

Ten dostęp to np. możliwość debugowania (kontrolowane wykonywanie poleceń programu, w tym włączanie i wyłączanie usług), zmiany plików wykonawczych, ładowanie plików specjalnych (np. testowe niepodpisane oprogramowanie układowe) czy dostęp przez telnet, ssh lub ftp.
W celu wymiany standardowych informacji często wystarczą nawet uprawnienia na prawach niższych niż administrator. Jeśli jednak są wymagane wyższe, zachęcam do tworzenia unikalnych par: użytkownik, hasło.

Protokoły
Jedną z zasad bezpieczeństwa, jaką wyniosłem po nauce administracji sieci w banku, jest wyłączaj, jeśli nie używasz. I stosuję ją wszędzie, również w technicznych systemach zabezpieczeń, a zwłaszcza w opartych na komunikacji IP. Wyłączanie dotyczy przede wszystkich niebezpiecznych lub nieużywanych protokołów, które są niczym bramy, przez które można się dostać do urządzenia.

Niewątpliwie wszystkie są użyteczne. Dzięki nim proces wykrycia, instalacji i konfiguracji przebiega szybciej. Dla większości ich użyteczność kończy się jednak wraz z zakończeniem procesu wdrażania i odbiorem systemu. Wówczas należałoby pozamykać furtki, które mogłyby posłużyć innym do niecnych celów, a które nie są wymagane do stabilnego działania systemu. Są to wszelkiego rodzaju protokoły Discovery, które służą do wykrywania urządzeń w sieci za pomocą oprogramowania dostępnego powszechnie lub ze strony producenta. Co ciekawe, jest to jedno ze skuteczniejszych sposobów zabezpieczania urządzeń przed niechcianą próbą ingerencji przez osoby nieuprawnione.

Jestem również za absolutnym zakazem wykorzystania protokołu UPnP (Universal Plug and Play), który umożliwia przesyłanie danych między dwoma urządzeniami bez autoryzacji i jakichkolwiek zabezpieczeń. FBI i inni eksperci od cyberbezpieczeństwa sugerują wyłączenie tego protokołu nawet we wszystkich urządzeniach domowych.

Urządzenie wykorzystujące UPnP potrafi przekierować porty komunikacyjne oraz adresy serwerów DNS w innym urządzeniu (również z uruchomionym UPnP) bez konieczności potwierdzania swojej tożsamości. Natomiast takie protokoły, jak ftp, ssh czy telnet według moich doświadczeń są pomocne w rozwiązaniu problemu, gdy taki pojawi się w systemie. Nie jestem zatem taki skory do ich całkowitego wyłączania. Jednocześnie dają zbyt wiele możliwości „napsucia” ustawień urządzenia i powinny być dostępne tylko dla przeszkolonego personelu. Inną kwestią jest to, że korzystając z niezabezpieczonych kanałów, takich jak ftp i telnet, nazwy użytkowników i hasła są wysyłane jawnie przez sieć lub kodowane tzw. base64 (kodowanie transportowe), które można bez problemu odkodować.

Bezpieczniejsze jest korzystanie z protokołu ssh (secure shell), następcy telnetu, które na szczęście coraz większa liczba producentów wprowadziła w elektronicznych systemach zabezpieczeń. Protokół ten wykorzystuje AES (Advanced Encryption Standard) – symetryczny (do szyfrowania i odszyfrowywania stosuje się ten sam klucz) szyfr blokowy o różnych długościach klucza. Dzięki temu wymiana danych między urządzeniami jest bezpieczna.

Izolacja
Zasadę „wyłączaj, jeśli nie używasz” należy stosować nie tylko do protokołów komunikacyjnych, ale także do wszystkich pozostałych elementów systemu. W przypadku przełączników sieciowych (oczywiście umieszczonych w zabezpieczonych przed nieautoryzowanym dostępem pomieszczeniach) dotyczy to portów, które nieobciążone powinny być trwale wyłączone. W tym celu należy stosować zarządzalne przełączniki sieciowe. Gdy trzeba podłączyć dodatkowe urządzenie do infrastruktury, administrator sieci aktywuje port w przełączniku. Nie jest to najszybsza metoda, ale skuteczna, ze względu na naturalną weryfikację tego, co i w jakim celu jest podłączane.

Dla niecierpliwych istnieją inne rozwiązania. W switchach dostępowych warstwy drugiej można również stosować polisy bezpieczeństwa lub listy dostępowe (ACL – Access Control List) opartych na adresach fizycznych urządzeń (adres MAC – Media Access Control). MAC jest adresem sprzętowym karty sieciowej Ethernet, unikatowym w skali światowej, nadawanym przez producenta danej karty podczas produkcji. Każdy port przełącznika może być zaprogramowany do obsługi tylko jednego urządzenia z jednym adresem MAC. Jeśli zostanie do niego podłączone inne urządzenie, port przekieruje ruch do specjalnie utworzonej sieci wirtualnej (VLAN – Virtual Local Area Network) odseparowanej od sieci bezpieczeństwa.

Niestety takie rozwiązanie nie jest bez wad. Urządzeniom można chwilowo zmienić adres MAC, tak aby „udawały” inny produkt. Zatem możliwe jest podłączenie komputera jako kamery, jeśli komputerowi wprowadzimy adres fizyczny tej kamery. Wtedy przełącznik zaakceptuje komputer jako element systemu bezpieczeństwa i wprowadzi do sieci zabezpieczonej.
Z tego też powodu bardziej skuteczne są polisy bezpieczeństwa, które w przypadku odłączenia urządzenia natychmiast wyłączają port w przełączniku, a także stosowanie zabezpieczeń IEEE802.1x opartych na certyfikatach uwierzytelniających. Wymaga to jednak zastosowania sprzętu o odpowiedniej klasie i zarządzania certyfikatami wszystkich elementów systemu, co wiąże się z wyższymi kosztami.

A co z bezpieczeństwem urządzeń klienckich? Wnioskując po wynikach badań przeprowadzonych przez Cisco 2018 Security Capabilities Benchmark Study, największym zagrożeniem cybernetycznym dla przemysłowych systemów sterowania (w tym systemów bezpieczeństwa) jest nieprzeszkolony personel i błędy ludzkie, które często pozostają nieujawnione. Dlatego należy tak przygotować środowisko użytkownika, aby zminimalizować prawdopodobieństwo popełnienia błędu z powodu choćby nieuwagi. Nie mam na myśli interfejsu użytkownika aplikacji – to jest zrozumiałe. Chodzi mi o uprawnienia w systemie operacyjnym komputera używanego jako stacja kliencka systemu.

Optymalnym rozwiązaniem jest odizolowanie jednostki roboczej od użytkownika, w ten sposób można ograniczyć możliwość uruchamiania zewnętrznych plików z pamięci przenośnych. Natomiast jeśli nie jest to możliwe, sugerowałbym wyłączanie dostępu do napędów i portów USB, ograniczenie wykorzystania skrótów klawiszowych oraz zmianę konfiguracji sieciowej. W środowisku Windows można za pomocą zasad grupy (group policy) poważnie ograniczyć dostęp do zasobów nawet użytkownikowi na prawach administratora.

1) Sprawa jest bardziej złożona. Nawiązanie do analizy ryzyka ma na celu uzmysłowienie, że ten proces zachodzi niemal niezauważalnie i jest naturalny dla branży zabezpieczeń technicznych. Wszystkich zainteresowanych kieruję do literatury poświęconej temu zagadnieniu.
 2) Security Information and Event Management – zarządzanie informacją związaną z bezpieczeństwem i zdarzeniami. Warstwa technologiczna rozwiązań klasy SIEM pozwala na centralne zarządzanie dziennikami zdarzeń generowanymi z wielu urządzeń w jednym czasie oraz ich archiwizację. W tym celu wszystkie informacje generowane przez urządzenia są przesyłane, gromadzone i scentralizowane. Ponadto silnik SIEM przechowuje informacje i udostępnia je zespołowi bezpieczeństwa w celu analizy, mapowania oraz generowania raportów i zarządzania w sytuacjach kryzysowych, zgodnie z określonymi procedurami. Możliwość korelacji, czyli szukania zależności pomiędzy nimi, daje działom bezpieczeństwa niespotykany dotychczas poziom wiedzy.
 3) RFC3550 – RTP: A Transport Protocol for Real-Time Applications.
 4) RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis.
 5) https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-top
 6) https://www.gum.gov.pl/pl/uslugi/zegar/524,Zegar.html.
 7) 2018 Cybersecurity Predictions A Shift to Managing Cyber as an Enterprise Risk, styczeń 2018, Stroz Friedberg an AON Company.
 8) Wyrok Wojewódzkiego Sądu Administracyjnego w Warszawie z dn. 9.04.2013 r., II SA/Wa 211/13.

Jan T. Grusznic, z-ca red. naczelnego „a&s Polska”.
Z branżą wizyjnych systemów zabezpieczeń związany od 2004 r. Ma bogate doświadczenie w zakresie projektowania i wdrażania rozwiązań dozoru wizyjnego w aplikacjach o rozproszonej strukturze i skomplikowanej dystrybucji sygnałów. Ceniony diagnosta zintegrowanych systemów wspomagających bezpieczeństwo.