Bezpieczeństwo to kwestia honoru

Jednym z najistotniejszych problemów, z jakim spotykają się osoby odpowiedzialne za centra przetwarzania danych (data center) i infrastrukturę informatyczną organizacji, jest zapewnienie bezpieczeństwa systemów informatycznych w nich alokowanych. Bezpieczeństwo można tutaj rozumieć dwojako. Z jednej strony chodzi o zapewnienie dostępności systemu w rozumieniu jak najmniejszej liczby przerw w pracy oraz jak najszybsze udostępnienie i zabezpieczenie przed utratą danych po awarii. Z drugiej bezpieczeństwo to ochrona przed wyciekiem informacji i utratą danych w wyniku niedozwolonych działań w rodzaju włamania do systemów czy sabotażu.

Awarie sprzętu i aplikacji spowodowane przyczynami zależnymi bądź niezależnymi od człowieka zdarzały się, zawsze będą się zdarzać i traktowane są raczej „normalnie”, jako zło konieczne. Jednak kompromitacja organizacji w wyniku udanego ataku na zabezpieczenia infrastruktury informatycznej i znajdujące się w niej systemy zawsze negatywnie odbije się na jej wizerunku. Wynika to między innymi z faktu, że w większości przypadków udane włamanie obnaża słabości nie tylko systemów zabezpieczeń, ale przede wszystkim personelu odpowiedzialnego za prawidłową pracę systemów informatycznych i podważa zaufanie do ich umiejętności, profesjonalizmu, a czasami nawet lojalności.

A zatem z punktu widzenia menedżerów, dyrektorów oraz całego personelu obsługującego infrastrukturę informatyczną oraz centra przetwarzania danych istotne jest upewnienie się, że stosowane zabezpieczenia są wystarczające, że wykorzystywane systemy IDS i IPS są odpowiednio wyskalowane i czułe, że konfiguracja firewalla oraz poszczególnych systemów i aplikacji jest optymalna z punktu widzenia bezpieczeństwa, wydajności i dostępności.

Jak i co testować?

Jedną z form kontroli poziomu zabezpieczeń jest przeprowadzenie testów penetracyjnych (pentstów). Polegają one na symulowaniu, a także przeprowadzaniu różnego rodzaju ataków na systemy oraz personel centrum przetwarzania danych. Ponieważ są to rzeczywiste ataki, mogą stanowić zagrożenie dla dostępności systemów. Dlatego w przypadku systemów produktywnych należy przeprowadzać je po odpowiednim przygotowaniu, na przykład zabezpieczając się uprzednio kopią bezpieczeństwa, oraz wykonywać testy w zaplanowanym uprzednio oknie serwisowym, w którym nie pracują użytkownicy systemu.

Testy penetracyjne powinny być przeprowadzane metodycznie, z uwzględnieniem celów, jakie organizacja chce dzięki nim osiągnąć, według ustalonego zakresu oraz harmonogramu. Jest to o tyle ważne, że wykonując je zgodnie z ustaloną metodyką, na początku określamy, co ma być przetestowane i jakie cele chcemy osiągnąć, a także eliminujemy te elementy, których przetestowanie w żaden sposób nie wpłynie na bezpieczeństwo systemów informatycznych wykorzystywanych w organizacji.

Najlepszym sposobem na opisanie schematu postępowania jest przegląd rzeczywistego przypadku. Oprzyjmy się więc na przykładzie firmy BillBird, w której BCC (aktualnie All for One Poland) przeprowadziło testy penetracyjne infrastruktury sieciowej oraz aplikacji wykorzystywanej w działalności biznesowej organizacji. Testy penetracyjne były częścią większego projektu wdrożenia systemu zarządzania bezpieczeństwem informacji zgodnego z normą ISO/IEC 27001. W pierwszej kolejności nastąpiła faza przygotowania do testów, w której określono:

  • rodzaj testów – zdecydowano się na dwa rodzaje testów przeprowadzanych z zewnątrz organizacji (z Internetu) – wybrano formułę „black box”, dla testów z wewnątrz organizacji (czyli ogólnie mówiąc z sieci LAN) wybrano formułę „gray box”;
  • zakres adresacji IP – między innymi wskazano adresy, które są krytyczne dla funkcjonowania organizacji, na których bezpieczeństwie firmie szczególnie zależy, oraz adresy, które odpowiadają systemom produktywnym i ich niedostępność może spowodować przerwanie działalności biznesowej, co oznaczało, że w tym zakresie testy należy wykonywać ze szczególną ostrożnością;
  • aplikacje WWW – z wskazaniami podobnymi jak przy wyborze adresacji IP;
  • tryb testów stacji roboczych użytkowników oraz sieci bezprzewodowej;
  • sposób testowania systemu IDS;
  • czy mają być przeprowadzane testy socjotechniczne;
  • harmonogram testów;
  • cel testów, którym było określenie stopnia bezpieczeństwa infrastruktury informatycznej organizacji oraz wybranych aplikacji.

Ataki z zewnątrz i z wewnątrz

W kolejnej fazie zaczęto przeprowadzać testy zgodnie z ustalonym harmonogramem. Najpierw z sieci Internet w formule „black box”. Dla bezpieczeństwa były one wykonywane w dni wolne od pracy. W tym samym czasie administratorzy BillBird monitorowali reakcje systemów obronnych organizacji (między innymi firewalla i systemu IDS). W ramach zbierania informacji o organizacji wykonano między innymi takie operacje jak przeszukanie Internetu pod kątem dostępnych informacji o firmie (nie tylko na temat organizacji i osób, ale także sieci) oraz „klasyczne” skanowanie portów TCP/UDP.

Zidentyfikowano w ten sposób hosty, wobec których można przeprowadzić ataki oraz próby penetracji. Takie próby wykonano w kolejnym kroku, wraz z testami aplikacji internetowych. Do tego celu zastosowano techniki takie jak: wykorzystanie tzw. eksplojtów, ataki typu DoS (denial of service), SQL Injection, XSS, PHP File Inclusion itd.

Po testach z Internetu w następnej kolejności wykonano testy z wewnętrznej sieci LAN, testy stacji roboczych oraz sieci bezprzewodowej. W tym celu zastosowano między innymi techniki słownikowe czy tzw. fake access point. Podczas testów systemy były cały czas kontrolowane przez administratorów BillBird pod kątem ich dostępności oraz integralności w celu zapobieżenia sytuacji, w której operacje biznesowe nie mogłyby być wykonywane.

Testy bezpieczeństwa systemów IT
Black Box – osoby testujące nie posiadają wiedzy lub posiadają minimalną wiedzę na temat atakowanego celu. Testy te są najbardziej zbliżone do rzeczywistych zagrożeń, jednak wiążą się ze znacznie dłuższym czasem trwania testów.
Cristal Box – osoby testujące mają bardzo szczegółową wiedzę na temat systemu; testy są wówczas bardziej symulacją, jednak pozwalają dokładnie sprawdzić dany element, co znacznie oszczędza czas.
Gray Box – jest to połączenie dwóch powyższych rodzajów testów, osoby testujące otrzymują pewną ograniczoną liczbę informacji.

Rekomendacje i wnioski

Wszystkie czynności, które przeprowadzono, oraz uzyskane podczas testów rezultaty były rejestrowane w celu ich późniejszej analizy. Były one podstawą rekomendacji zawartych w raporcie końcowym, w którym oprócz wniosków znalazły się również opisy wszystkich przeprowadzonych podczas testów operacji oraz ich wyniki. Raport zostały przedstawiony w postaci prezentacji na specjalnym spotkaniu konsultantów BCC z zespołem BillBird odpowiedzialnym za bezpieczeństwo systemów informatycznych. Omówiono na nim zarówno wykonywane działania i ich wyniki (zidentyfikowano między innymi wszystkie tak zwane false positives), jak i przede wszystkim rekomendacje i wnioski.

Podstawową zaletą testów penetracyjnych jest to, że są wykonywane na „żywym organizmie”. Pomimo tego, że w nazwie działań jest słowo „test”, to w zasadzie jedyną różnicą pomiędzy prawdziwym atakiem a tym wykonywanym w ramach testów penetracyjnych jest to, że w tym drugim wypadku wszystko odbywa się w sposób kontrolowany. Dlatego pentesty są jedną z najwartościowszych metod badania stanu bezpieczeństwa nie tylko infrastruktury informatycznej oraz aplikacji, ale również poprzez przeprowadzanie testów socjotechnicznych stanu bezpieczeństwa i poziomu świadomości organizacji, a także ludzi w niej pracujących.

Audyt bezpieczeństwa IT w Lurgi
W sierpniu 2011 r. konsultanci BCC (aktualnie All for One Poland) przeprowadzili audyt bezpieczeństwa systemu do transferu danych w firmie Lurgi świadczącej usługi dla podmiotów z sektora paliwowego. Celem audytu było zbadanie stanu bezpieczeństwa systemu wykorzystywanego do transferu danych pomiędzy Lurgi a klientami spółki.
Zakres audytu obejmował przeprowadzenie testów penetracyjnych na poziomie aplikacji oraz zbadanie wykorzystywanej przez nią infrastruktury. Testy zostały przeprowadzone poprzez dokonanie ataków na system klienta. Atak z zewnątrz został zrealizowany bez wiedzy konsultantów BCC o charakterystyce systemu klienta oraz braku przyznanego konta w systemie (Black Box). Druga część testów penetracyjnych polegała na dokonaniu ataku z wewnątrz systemu. W tym przypadku konsultanci BCC posiadali udostępnione przez administratora Lurgi konto w badanym systemie.
Audyt bezpieczeństwa infrastruktury polegał na zdiagnozowaniu struktury sieciowej, analizie funkcjonowania data center, procedur bezpieczeństwa oraz planów ciągłości działania.
Efektem pracy konsultantów BCC był raport przedstawiający stan bezpieczeństwa używanego w Lurgi SA systemu wraz z rekomendacjami wprowadzenia działań zmierzających do zwiększenia jego bezpieczeństwa.