Sektor bankowy, rynek kapitałowy, ubezpieczeniowy i emerytalny, a także instytucje płatnicze i biura usług płatniczych, instytucje pieniądza elektronicznego oraz kasy spółdzielcze w Polsce podlegają nadzorowi Komisji Nadzoru Finansowego (KNF).

Jednym z zadań komisji jest udział w przygotowywaniu projektów aktów prawnych w zakresie nadzoru nad rynkiem finansowym. Takim aktem jest Rekomendacja D dotycząca zarządzania ryzykami towarzyszącymi systemom informatycznym i telekomunikacyjnym używanym przez banki.

Rekomendacja DKNF

Postęp w technologiach informatycznych, popularność rozwiązań cloud computingu oraz rosnący pakiet usług dostępnych na urządzeniach mobilnych spowodowały wyraźny wzrost zależności instytucji finansowych od rozwiązań teleinformatycznych. Dlatego w 2013 r. KNF znowelizowała swoją rekomendację. Implementacja nowej wersji Rekomendacji D ma służyć poprawie jakości zarządzania i poziomu bezpieczeństwa IT. Co warte podkreślenia, od początku 2015 r. wszystkie instytucje podlegające nadzorowi KNF są do tego zobligowane.

Bardzo dużym ułatwieniem przy wdrożeniu Rekomendacji D przez instytucje finansowe są światowe standardy takie jak: ISO/IEC 27001, ISO/IEC 20000 czy ISO/IEC 22301 oraz kodeks ITIL (Information Technology Infrastructure Library) czy COBIT (Control Objectives for Information and related Technology).

Dokument zawiera 22 rekomendacje, podzielone na następujące obszary:

  • strategia i organizacja obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego,
  • rozwój środowiska teleinformatycznego,
  • utrzymanie i eksploatacja środowiska teleinformatycznego,
  • zarządzanie bezpieczeństwem środowiska teleinformatycznego.

W obszarze utrzymanie i eksploatacja środowiska teleinformatycznego Rekomendacja D wskazuje na konieczność wykonywania bieżących testów penetracyjnych i przeglądów kodu, zapewniając odpowiedni stopień niezależności w przypadku rozwoju oprogramowania realizowanego własnymi zasobami: „9.21. Konfiguracja komponentów infrastruktury teleinformatycznej powinna podlegać okresowej weryfikacji pod kątem pozostałych zmian zachodzących w tym środowisku, a także ujawnianych luk bezpieczeństwa. Bank powinien przeanalizować zasadność (uwzględniając w szczególności poziom złożoności środowiska teleinformatycznego oraz stopień narażenia na ryzyko w zakresie bezpieczeństwa tego środowiska) i na tej podstawie podjąć odpowiednią decyzję dotyczącą zapewnienia wsparcia tego procesu przez narzędzia automatyzujące czynności kontrolne. Jednym z narzędzi, które powinno być systematycznie stosowane przy ocenie skuteczności mechanizmów kontrolnych w obszarach infrastruktury teleinformatycznej o wysokiej istotności, są testy penetracyjne”.

Normy i systemy bezpieczeństwa IT dla sektora finansowego, które zobowiązują do wykonania testów penetracyjnych

  • KNF: Rekomendacja D, punkty 9.21, 9.25, 18.7
  • PN-ISO/IEC 27001, punkt A.12.6
  • Payment Card Industry Data Security Standard (PCI-DSS) 3.0

Weryfikacja stanu faktycznego

Wdrożenie zaawansowanych mechanizmów ochrony, polityki bezpieczeństwa reguł pracy czy światowych standardów to dobpiero pierwszy krok na drodze budowania bezpieczeństwa IT. Jednak równie ważne jak implementacja tych reguł jest dalsze skuteczne przestrzeganie zasad oraz przede wszystkim okresowa weryfikacja stanu faktycznego. Służą temu m.in. regularne symulacje ataków cyberprzestępców wykonywane przez wykwalifikowanych konsultantów ds. bezpieczeństwa IT.

Weryfikacja poziomu bezpieczeństwa może przebiegać na wiele sposobów, z użyciem różnych metod i scenariuszy, zależnie od testowanych systemów oraz zdefiniowanych potrzeb. Takie testy nazywa się testami penetracyjnymi.

W sektorze bankowym (i ogólnie finansowym) najbardziej popularnymi usługami z obszaru IT security są przede wszystkim testy aplikacji webowych, testy infrastruktury oraz coraz częściej testy aplikacji mobilnych.

Testy aplikacji webowych

Szczególnie aplikacje webowe, które służą do wykonywania transakcji lub innych operacji na środkach finansowych, liczne w pejzażu systemów instytucji finansowych, są często poddawane testom. Do sprawdzenia poziomu bezpieczeństwa web aplikacji wykorzystuje się trzy podstawowe modele testów: Black Box, White Box oraz Gray Box.

Każdy z tych modeli charakteryzuje się nieco odmiennym sposobem podejścia do testów, który w skrócie można opisać następująco:

  • Black Box to testy bez użycia danych logowania do web aplikacji. Weryfikują wszystkie podstawowe próby „dostania się” do web aplikacji przez nieautoryzowanych użytkowników oraz wykonywanie ewentualnych dalszych czynności, np. na danych użytkowników bądź w systemie operacyjnym. Ten model testów nie obejmuje jednak testowania logiki biznesowej aplikacji lub prób zrozumienia, jak podatności mogą wpłynąć na użytkowników systemu bądź system, poza aspektem autentykacji i autoryzacji.
  • Testy White Box to spojrzenie na bezpieczeństwo web aplikacji z innej strony, takie testy swoim zakresem są zbliżone do audytu bezpieczeństwa kodu źródłowego, uwzględniającego weryfikację ewentualnie odnalezionych podatności bądź błędów w kodzie aplikacji. W takim przypadku konieczne jest udostępnienie kodu źródłowego.
  • Z kolei najczęściej wybierany model Gray Box w przypadku aplikacji webowych oznacza pełną weryfikację bezpieczeństwa, zarówno z poziomu użytkownika niezalogowanego, jak i zalogowanego, także na wszystkich wybranych przez klienta poziomach ról w systemie. Takie testy umożliwiają weryfikację logiki biznesowej lub finansowej aplikacji (np. sprawdzają, czy użytkownik o niskich uprawnieniach nie może wykonywać czynności administracyjnych założonych w rolach) oraz wpływ ewentualnych podatności na użytkowników systemu bądź sam system. W modelu Gray Box testuje się web aplikację kompleksowo, od strony osoby niemającej dostępu do kodu źródłowego.

Zewnętrzne i wewnętrzne testy infrastruktury

W przypadku testów infrastruktury możemy wyróżnić dwa podstawowe typy: testy zewnętrzne oraz wewnętrzne.

Najczęściej instytucje finansowe decydują się na przeprowadzanie testów zewnętrznych, czyli prób przełamania zabezpieczeń dokonywanych z Internetu. Coraz częściej banki decydują się na zlecenie wykonania zewnętrznych pentestów profesjonalnej firmie. Testy takie polegają na przeprowadzeniu ataków typu APT (Advanced Persistent Threat). Ten rodzaj testów charakteryzuje się znaczną czasochłonnością, jednak pozwala kompleksowo zweryfikować bezpieczeństwo instytucji z zewnątrz, na przykład poprzez długotrwałą obserwację i specjalnie przygotowane ukierunkowane ataki phishingowe.

Testy wewnętrzne są częściej wykonywane w mniejszych instytucjach, w których istnieje konieczność weryfikacji segmentacji sieci LAN. W większych jednostkach ten element infrastruktury jest zwykle bardziej uporządkowany. Takie testy mogą również obejmować sposób fizycznej kontroli dostępu. Wcale nierzadko zdarza się, że dociekliwy pentester odnajduje luki w zabezpieczeniach pozwalające na dostanie się do pomieszczeń działu IT z pełnym dostępem do systemów w gniazdkach sieciowych „prosto z ulicy”, zdarza nam się wykrywać też inne ewidentne błędy w kontroli dostępu. Zakres i zasięg testów jest za każdym razem ustalany indywidualnie z klientem.

Poddajemy się testom penetracyjnym, bo mamy świadomość, że poprawa stanu bezpieczeństwa IT to proces ciągły. Weryfikacja stanu naszej infrastruktury i zabezpieczeń to także element wdrożonego przy udziale BCC (aktualnie All for One Poland) systemu zarządzania bezpieczeństwem informacji (SZBI) zgodnego z normą ISO/IEC 27001.
W ramach testów penetracyjnych w BillBird konsultanci BCC przeprowadzali ataki z zewnątrz. Sprawdzili, czy istnieje możliwość, by ważne dane firmowe zostały ujawnione w Internecie (na przykład poprzez tzw. Google Hacking). Kolejne testy dotyczyły ataków z wewnątrz sieci BillBird, prób złamania zabezpieczeń systemów oraz ataku na sieć Wi-Fi i aplikacje WWW.
Od ponad 10 lat BillBird jest liderem w zakresie innowacyjnych sposobów regulowania należności. Świadczymy usługi przekazu pieniężnego jako Krajowa Instytucja Płatnicza na podstawie zezwolenia Komisji Nadzoru Finansowego uzyskanego jako drugi podmiot w Polsce po wejściu w życie ustawy o usługach płatniczych. Okresowe przeglądy i usprawnianie procesów i rozwiązań w takich obszarach jak komunikacja wewnętrzna i zewnętrzna, bezpieczeństwo teleinformatyczne, czy bezpieczeństwo fizyczne osób i aktywów to nasz obowiązek względem klientów, którzy codziennie powierzają nam swoje dane osobowe i finansowe.
Przemysław Odrozek, Risk Manager, BillBird SA

Black, Gray, White Box

W odniesieniu do testów penetracyjnych innych niż testy web aplikacji (czyli infrastruktury, sieci bezprzewodowych i pozostałych) także istnieją trzy podstawowe modele, według których wykonuje się testy. Modele te mają takie same nazwy jak dla aplikacji webowych, jednak rozróżnia się tutaj trochę inne podejście:

  • Black Box – pentesterzy na starcie mają minimalną wiedzę na temat atakowanego celu (np. nazwa firmy, liczba adresów IP). Ten model jest najbliższy rzeczywistym cyberatakom. Jest dość czasochłonny, bo dużo czasu poświęca się na rekonesans;
  • White Box – pentesterzy mają pełną wiedzę na temat celu (np. dostęp do dokumentacji i pełen wywiad z administratorami), testy są wówczas bardziej symulacją zakrawającą o audyt, jednak pozwalają bardzo dokładnie sprawdzić systemy;
  • Gray Box – także w przypadku systemów IT najczęściej wybierany model – jest połączeniem dwóch poprzednich. Pentesterzy otrzymują pewną ograniczoną ilość informacji określoną przez klienta (np. zakres adresacji IP, listę systemów, które są wystawione).

Każdy z modeli ma swoje wady i zalety. Na przykład Black Box jest najbardziej realistyczną symulacją ataku (nie licząc zagrożeń typu insider-threat), jednak rekonesans (ustalenie celu, zebranie informacji oraz inne czynności) jest bardzo czasochłonny, a przede wszystkim istnieje szansa przeoczenia systemu przez pentestera.

Standard PCI DSS

Instytucje, które przetwarzają dane kartowe (pełne dane kart kredytowych), często decydują się na testy penetracyjne na potrzeby uzyskania bądź przedłużenia certyfikacji zgodności ze standardem Payment Card Industry Data Security Standard (PCI DSS), obecnie w wersji 3.0. Standard ten zakłada m.in. wykonywanie testów penetracyjnych zewnętrznych i wewnętrznych obejmujących także weryfikację segmentacji sieci (m.in. oddzielenie środowiska kartowego od reszty sieci) przynajmniej raz do roku lub po większych zmianach w infrastrukturze.

Centrum Rozliczeń Elektronicznych Polskie ePłatności jako najbardziej dynamicznie rozwijający się agent rozliczeniowy w Polsce od początku działalności stawia sobie za cel wspomaganie rozwoju oraz wprowadzanie rozwiązań innowacyjnych w sektorze obrotu bezgotówkowego, tym samym oferując szeroki zakres usług opartych na obsłudze płatności kartowych, wśród nich obsługę transakcji, doładowania telefonów komórkowych, cashback, programy lojalnościowe czy karty podarunkowe. Wprowadziliśmy również na rynek mobilny terminal płatniczy typu mPOS składający się z przenośnego czytnika kart płatniczych współpracującego bezpośrednio w technologii Bluetooth z aplikacją mPeP na smartfonie czy tablecie, pozwalający na przyjmowanie wszystkich typów płatności, w szczególności płatności zbliżeniowych, przez co jest pierwszym na Polskim rynku terminalem mobilnym przyjmującym płatności w technologii zbliżeniowej. W procesie akceptacji płatności za pomocą kart płatniczych przez nasze ręce codziennie przechodzą transakcje milionów posiadaczy kart o ogromnej wartości. To oczywiste, że na pierwszym miejscu stawiamy ochronę danych i transakcji oraz minimalizację ryzyka związanego z nieuprawnionym dostępem do danych kartowych.
Jako organizacja spełniająca międzynarodowe standardy bezpieczeństwa PCI DSS okresowo poddajemy się testom penetracyjnym, weryfikującym spełnianie tych wymagań. Wykonujemy takie testy cyklicznie – raz do roku, lub bezpośrednio po wprowadzeniu większych zmian w systemach IT.
Testy penetracyjne przeprowadzone przez BCC (aktualnie All for One Poland) na początku 2015 r. nie tylko pozwoliły wypełnić nam zobowiązania wynikające z norm PCI DSS, ale stały się również cennym źródłem wskazówek dotyczących dalszego rozwoju naszych systemów i procedur bezpieczeństwa. Rekomendacje przekazywane przez BCC umożliwiają zarówno projektowanie, jak i budowę bezpiecznego środowiska IT.
Magdalena Litwin, Specjalista ds. Nadzoru Operacyjnego, Centrum Rozliczeń Elektronicznych Polskie ePłatności

Brawurowe cyberataki na banki

To, jak ważne jest wykonywanie symulacji ataków możliwie jak najbardziej zbliżonych do zagrożeń typu APT oraz przestrzeganie polityk bezpieczeństwa, obrazują dwa przykłady brawurowych ataków na banki.

Firma Kaspersky Lab. opisała niedawno działania grupy hakerskiej Carbanak, która prowadziła długotrwałą kampanię ukierunkowaną na infrastruktury banków w różnych krajach – m.in. w Polsce. W ciągu około dwóch lat instytucjom finansowym na całym świecie skradziono prawie miliard dolarów. Tym razem celem nie byli klienci, a same banki i ich infrastruktura.

W początkowej fazie przestępcy uzyskali dostęp do komputera pracownika banku za pośrednictwem ukierunkowanych phishingowych wiadomości e-mail, infekując ofiarę szkodliwym oprogramowaniem. Następnie wniknęli do wewnętrznej sieci i zidentyfikowali komputery administratorów. Dzięki monitorowaniu widzieli i rejestrowali wszystko, co działo się na ekranach i klawiaturach pracowników obsługujących systemy przelewu gotówki. W ten sposób mogli imitować działania pracowników banku w celu dokonywania przelewów i zdeponowania gotówki.

Następnie „spieniężali” środki, przenosząc je na inne konta standardowymi przelewami. Później, gdy uzyskali większą kontrolę nad systemami (m.in. bazami danych), zwiększali salda kont, a następnie kradli te dodatkowe środki w wyniku oszukańczej transakcji. Mogli również wydawać wskazanym bankomatom polecenia typu „opróżnij wszystkie kasetki” o określonej godzinie. Na odbiór gotówki czekały już zamaskowane osoby.

O konieczności wykonywania symulacji ataków zbliżonych do typu APT pod koniec ubiegłego roku przekonali się także pracownicy jednego z niewielkich stanowych banków w USA. W tym banku podjęto próbę kradzieży prawie miliona dolarów i przetransferowania kwoty w dwóch przelewach do dwóch oddziałów banków w Polsce. Jeden z tych przelewów się udał.

Bank, który padł ofiarą cyberprzestępców, pomimo swoich niewielkich rozmiarów ma wdrożone odpowiednie mechanizmy i procedury bezpieczeństwa. A jednak wszystko to okazało się bezużyteczne, ponieważ jeden z pracowników ignorował ostrzeżenia systemu antywirusowego i używał swojej stacji roboczej do przeglądania stron internetowych. Miał także zwyczaj otwierania każdej wiadomości e-mail. Przed wystąpieniem incydentu na obsługiwany przez niego adres e-mail przyszła wiadomość z linkiem do złośliwego oprogramowania. Pomimo kilku ostrzeżeń o wykryciu zagrożenia pracownik banku zignorował alert.

Po 13 dniach od wykrycia konia trojańskiego pobrany został dodatkowy moduł, który posłużył cyberprzestępcom do wykonania bezpośredniego ataku na stację. Wykonanie kradzieży ułatwił pracownik banku, który na niewyłączonej na noc stacji roboczej pozostawił dwa zalogowane tokeny do autoryzacji przelewów. Następnego dnia zorientował się, że istnieją dwa nieautoryzowane przelewy, jednak nie udało się anulować ich drogą elektroniczną, ponieważ dostawcy usług internetowych dla banku padli ofiarą ataków DDoS. Przypadek?

Po interwencji w Banku Rezerw Federalnych udało się anulować jeden z przelewów.

Te dwie historie obrazują, jak ważne jest przestrzeganie polityk bezpieczeństwa oraz regularne wykonywanie symulacji ataków możliwie jak najbardziej zbliżonych do typu APT (Advanced Persistent Threat) zlecanych zewnętrznym konsultantom (tzw. pentesterom).

Pentesty w BCC

W ramach oferty bezpieczeństwa IT, BCC (aktualnie All for One Poland) realizuje testy penetracyjne (pentesty) dotyczące dowolnych elementów infrastruktury IT firmy. Ich celem jest podwyższenie poziomu bezpieczeństwa firmowych systemów i danych poprzez identyfikację słabych punktów infrastruktury IT, które mogą być celem skutecznego ataku hakerskiego.

BCC realizuje usługi związanie z dziedziną szeroko pojętego bezpieczeństwa IT. Nasz zespół certyfikowanych konsultantów ds. zabezpieczeń jest w stanie przyjąć rolę grupy hakerów (pentesterów) i sprawdzić zabezpieczenia firmy, przeprowadzajac testy penetracyjne według zakresu i scenariusza uzgodnionego z klientem.

Wykonujemy również audyty konfiguracji pod kątem ustawień bezpieczeństwa, hardeningu, dobrych praktyk i innych wytycznych oraz metodologii.

Pracujemy według własnej metodologii przeprowadzania testów penetracyjnych oraz audytów konfiguracji bezpieczeństwa, opartej na:

  • doświadczeniach BCC w tym zakresie i kilkudziesięciu projektach z zakresu bezpieczeństwa IT,
  • technikach przygotowanych przez renomowane organizacje zajmujące się bezpieczeństwem systemów IT (min. OSSTMM, EC-Council, OWASP,COBIT).