Wymagania co do bezpieczeństwa zapisane są w wewnętrznych politykach ING jako obowiązkowe

Z Przemysławem Wolkiem, szefem Cyberbezpieczeństwa w ING Hubs Poland rozmawiamy o roli i zadaniach polskiej organizacji w Grupie ING; automatyzacji działań związanych z CyberSec; wpisaniu testów bezpieczeństwa w proces tworzenia i rozwoju oprogramowania; największych cyberzagrożeniach i wyzwaniach związanych z bezpieczeństwem IT; a także wykorzystaniu rozwiązań cybersecurity oferowanych w modelu Software as a Service oraz podejściu do outsourcingu bezpieczeństwa IT w ramach usług CyberSec as a Service.

Czym – w kontekście cyberbezpieczeństwa – zajmuje się działający w Katowicach i Warszawie ING Hubs Poland?

Przede wszystkim dostarczamy usługi cybersecurity dla całej Grupy ING. Po pierwsze jest to detekcja cyberzagrożeń. Stanowimy w tym zakresie globalne centrum usług dla Grupy ING. Działamy w trybie 24/7 monitorując próby ataków dla wszystkich, naszych podmiotów w 50 krajach na świecie, a także wszystkie nasze centra danych. W tym zespole pracuje ok. 100 osób. Zajmują się one wykrywaniem cyberataków na infrastrukturę krytyczną i aplikacje banków należących do Grupy ING.

Drugi, duży obszar dotyczy usług związanych z prewencją, przeciwdziałaniem cyberatakom. Tam zatrudniamy bardzo duży zespół ofensywny. Jest to 30 pentesterów, którzy próbują włamywać się do naszych systemów bankowych. Sprawdzają w ten sposób, czy są one odpowiednio zabezpieczone. Jeśli wykryją jakieś luki sugerują, co można poprawić w zakresie bezpieczeństwa IT. Osobny, także ok. 30-osobowy zespół zajmuje się automatycznym skanowaniem podatności naszej infrastruktury IT i aplikacji. Zajmuje się on też tematami związanymi z Compliance i zarządzaniem ryzykiem.

Trzeci filar działalności ING Hubs Poland to zarządzanie tożsamością i dostępami. Są to usługi Identity and Access oferowane w modelu „as a Service”. W ramach tego obszaru świadczymy dla Grupy ING usługi związane z technologią i zarządzaniem dostępem do systemów IT dla 55 tys. naszych pracowników. Przy tej skali jest to bardzo skomplikowane zadanie. Jedna grupa specjalistów w tym dziale zajmuje się zarządzaniem usługami Active Directory i Identity Governance. Polega to na zarządzaniu warstwą, w ramach której mamy zdefiniowany tzw. Role Based Access dla całej Grupy ING.

Wróciłbym do tematu pentesterów. Dużo mówi się o rozporządzeniu DORA, które wymusi regularne testowanie luk bezpieczeństwa. Czy będą Państwo wobec tego zatrudniać dodatkowych, białych hakerów?

W naszych wewnętrznych politykach mamy już zapisane jako obowiązkowe bardzo rozbudowane wymagania co do bezpieczeństwa IT. Wydaje mi się, że dalej niż my unijna rekomendacja raczej nie pójdzie. Przykładowo, w ING zdefiniowaliśmy procedurę, która zobowiązuje nas do tego, aby każda aplikacja została poddana co roku co najmniej jednemu testowi bezpieczeństwa IT. Wymóg ten dotyczy także testów CyberSec po każdej, dużej zmianie. Wątpię, aby regulacje zewnętrzne poszły tak daleko.

Warto podkreślić, że naszych 30 pentesterów to nie są wszyscy specjaliści, których angażujemy do wykonywania testów. W naszych politykach bezpieczeństwa mamy bowiem zapisane to, iż należy rotować zespół, który zajmuje się przeciwdziałaniem cyberatakom. Dlatego też część testów penetracyjnych wykonuje zespół zewnętrzny. W rzeczywistości pentesterów mamy więc więcej.

Dlatego zespoły te trzeba rotować?

Ważne jest, aby zmieniać perspektywę. My bardzo dobrze znamy systemy wewnętrzne banku. Szybciej i skuteczniej możemy więc obchodzić warstwę zabezpieczeń. Zewnętrzny tester musi się dopiero tego nauczyć. Z drugiej strony zewnętrzna firma może mieć własne „modus operandi”, narzędzia, z których nie korzystamy. Dzięki temu mogą gdzieś włamać się skuteczniej. Uważam, że dobrą zasadą jest podejście do prewencji zarówno z perspektywy wewnętrznej, jak i zewnętrznej. Nie zmieniałbym tego podejścia.

Jakie są dziś – z punktu widzenia sektora finansowego – największe cyberzagrożenia?

W tej chwili numerem jeden jest – przynajmniej z perspektywy ING – obszar detekcji i zwiększanie jej skuteczności. Ale inny bank może mieć gdzie indziej osadzone priorytety. Chcemy przeciwdziałać kilku zagrożeniom. Na pewno – z perspektywy instytucji finansowej – są to ataki na klientów banku i naszych pracowników. Jest to już swego rodzaju „zdarta płyta”, ale człowiek zawsze jest najsłabszym ogniwem w ochronie przed cyberatakiem. Zawsze zaczyna się on od człowieka, czy to poprzez Social Engineering, phishing, czy inną, nawet relatywnie prostą technikę. Często zapewniają one jednak dostęp do wewnętrznych zasobów organizacji.

Dużo inwestujemy też we wspomnianą detekcję i zwiększenie skuteczności naszych narzędzi bezpieczeństwa IT. Powodem jest m.in. geometryczny wzrost kompleksowość środowisk IT. W efekcie coraz większe są wyzwania, przed jakimi stoi dział CyberSec. Wiele rzeczy automatyzujemy, dzięki czemu stajemy się coraz lepsi. Niemniej wyścig ten to kolejne, duże dla nas wyzwanie.

Inwestujemy zarówno w nowe technologie, jak i zaawansowane systemy detekcji klasy XDR. Widzimy bowiem, że kolejnym, postawionym przed nami wyzwaniem będzie ochrona bardzo skomplikowanych ekosystemów chmury prywatnej i publicznej, a raczej ich hybrydy. Mocno komplikuje to zadania specjalistów ds. bezpieczeństwa, którzy są na pierwszej linii „frontu”. Muszą analizować coraz więcej danych. Musimy więc zapewnić im skuteczne narzędzia do kontroli hybrydowych środowisk IT.

Czy taki monitoring da się zautomatyzować, np. poprzez wykorzystanie algorytmów AI, aby odsiewać fałszywe alarmy?

W ogóle staramy się wiele rzeczy automatyzować. ING jest bankiem, który w dużym stopniu pracuje w metodologiach agile. Oznacza to, że nasze zespoły CyberSec także muszą być zwinne. Musimy zbudować technologię ułatwiającą dynamiczne prowadzenie projektów, np. pozwalającą na to, aby dostępy do konkretnych zasobów IT mogły być szybko przenoszone pomiędzy zespołami. Sporo wysiłku kosztuje nas przygotowanie własnych narzędzi automatyzujących pewne procesy. Dotyczy to np. provisioningu uprawnień czy wymagań Compliance dla banku, czyli porównania tego, co mamy w nich zdefiniowane z tym, co faktycznie znajduje się w systemach IT.

Około 20-osobowy zespół ING Hubs Poland pisze np. aplikacje, które zintegrowane są zarówno z naszym systemem Governance, jak i systemami LDAP – Active Directory dla Windows, Boks dla systemów Linux. Za pomocą tych samych narzędzi „wpinamy” się także w – budowaną w ING – chmurą prywatną. Projekt ten zmierza m.in. do centralizacji naszych centrów danych. Dzięki naszym narzędziom to, co zdefiniujemy automatycznie „ląduje” w systemach IT. Zdecydowanie więc mocno idziemy w kierunku automatyzacji.

Jeśli zaś chodzi o wykorzystanie algorytmów AI do odsiewania fałszywych alarmów, to nazywamy to w ING Integration Layer. Jest to technologia, którą właśnie rozwijamy. Nie jesteśmy jednak jeszcze na etapie, na którym procesy te realizowane były całkowicie w trybie „unsupervised”. Obecne rozwiązania nie są gotowe na to, aby działać w pełni autonomicznie.

Skutecznie udaje się jednak budować już takie rozwiązania, które podpowiadają analitykom jakie – w danej sytuacji – były najczęściej podejmowane historyczne decyzje. Narzędzia tego typu są też w stanie samodzielnie przeanalizować wstępnie dany case i podpowiedzieć rozwiązanie. Takie rzeczy już wykorzystujemy w ING. Obszar ten też mocno rozwijamy.

Wspomniał Pan o hybrydowych środowiskach IT. Czy dotyczy to też działu CyberSec? Czy poza własnymi rozwiązaniami ING korzysta także z tych, udostępnianych w modelu chmurowym?

Cyberbezpieczeństwo staje się obszarem commodity. Wielu, dużych graczy – jak Microsoft, Google, czy dostawcy systemów SIEM – rozwija dostarczane przez siebie narzędzia w taki sposób, aby nie trzeba było ich w znaczący sposób modyfikować.

Dostarczają reguły monitoringu w taki sposób, aby generowały tzw. wynik True Positive. Dzięki temu są bardziej skuteczne. Zdejmują dużą część pracy z analityków. Jednocześnie to, co wcześniej musieliśmy budować wewnętrznie, teraz zapewne będziemy mogli kupić na rynku. Pozwoli nam to skoncentrować się na tym, co jest specyficzne dla działalności ING, czy ogólnie dla sektora finansowego.

Czy opisane przez Pana funkcjonalności to nowy trend w rozwiązaniach CyberSec?

Obietnica dostawców klasy SIEM jeszcze 10 lat temu była taka, że powstanie marketplace, w którym znajdą się – niejako „out of the box”­- gotowe, skutecznie działające reguły. Ale była to – przynajmniej w naszym kontekście – obietnica niespełniona. Każdą taką regułę nasi specjaliści musieli przepisać lub zmodyfikować, aby zadziałała w ING. Powodem był niewielki stopień standaryzacji. Teraz dostawcy zapewniają, że stworzono „content”, który działa.

Dzieje się tak również dzięki temu, że mamy do czynienia z coraz większą standaryzacją stacków technologicznych. Rozwiązania są oparte o agenta, który działa na systemie operacyjnym. Firmy zainwestowały ogromne środki – liczone w miliardach dolarów – w to, aby działało to skuteczniej niż kiedyś. Samodzielnie nie możemy konkurować z takimi nakładami. Nie chcemy nawet tego robić, bo liczymy na to, że swego rodzaju commodity kupimy na rynku. My zaś skoncentrujemy się na pisaniu czegoś, co – w kontekście naszych procesów biznesowych i aplikacji – robione jest nieco inaczej.

Co, Pana zdaniem, jest najważniejszym aspektem w zakresie ochrony bezpieczeństwa IT?

W tym momencie jest to kombinacja rozwiązań prewencyjnych uniemożliwiających dokonanie ataku oraz wspomniana już – detekcja i skuteczna reakcja na wykryte zagrożenia. Przeciwdziałanie im, a w najgorszym przypadku odzyskanie utraconych danych i przywrócenie ciągłości działania infrastruktury IT.

Jakie są najlepsze praktyki w tym zakresie stosowane przez ING?

Na pewno skuteczne wykrywanie oraz szybkie usuwanie podatności bezpieczeństwa oraz narzędzia detekcji klasy XDR. Również rozwiązania SOAR – Security Orchestration, Automation, and Response. Jest to obszar, który obecnie rozwijamy. Chcemy wdrożyć systemy klasy SOAR, które wesprą naszego analityka w skutecznej odpowiedzi na cyberatak.

Jednocześnie, wewnętrznie toczymy dyskusję, na ile zespoły związane z cyberbezpieczeństwem będą mogły skutecznie podejmować decyzje, których efektem może być brak ciągłości w działaniu banku. A jeśli nie zaburzą, to co stanie się np. w przypadku ataku ransomware, który może zaszyfrować i zniszczyć dane całkowicie zaburzając ciągłość naszego działania.

Coraz więcej zasobów migrowanych jest do chmury. Jak zadbać o prawidłową migrację do środowiska cloud computing?

Nasza koncepcja konsumpcji chmury publicznej polega na tym, że umieszczamy tam tylko te aplikacje, które są na to gotowe, tzw. Cloud Native. Są one uruchamiane w sposób automatyczny, przez naszą platformę One Delivery Pipeline. Uważamy, że migracja do chmury dopiero wówczas ma sens, jeśli funkcjonowanie aplikacji w dużym stopniu jest zautomatyzowane. Wykonywane są więc automatyczne testy bezpieczeństwa i konfiguracji. To właśnie zapewnia One Delivery Pipeline.

Największym wyzwaniem w migracji do chmury jest właściwa konfiguracja środowiska IT. Ale to dotyczy też własnego centrum danych. Ryzyko rośnie, jeśli nie wprowadzi się żadnych mechanizmów kontrolnych. W tym aspekcie ważna jest dojrzałości procesów. Mamy ten aspekt dobrze zaadresowany, więc dla nas de facto nie ma znaczenia to, gdzie znajduje się dana aplikacja. Choć trzeba pamiętać, że w przypadku środowisk cloud computing tracimy kontrolę nad pewnym aspektem jej funkcjonowania, w tym fizycznym dostępem do centrum danych czy współdzieleniem zasobów.

Czy są określone kroki, które trzeba podjąć przed migracją aplikacji do chmury? Jak chronić je, gdy są już w chmurze? Na co zwrócić uwagę?

Jest ich kilka. Po pierwsze, dopuszczamy konsumpcję chmury publicznej jedynie w dojrzały sposób, a więc wyłącznie za pośrednictwem One Delivery Pipeline. Mamy tam zapiętych sporo mechanizmów kontrolnych, a wszystkie aplikacje korzystają ze standardowego stacku technologicznego. Ważna jest też kontrola tego, jaki ruch dopuszczamy do i z chmury publicznej. Wykorzystujemy do tego broker zabezpieczeń dostępu do chmury Microsoft CASB.

Uważamy też, że konieczne jest monitorowanie chmury publicznej z własnego centrum danych. Zbudowaliśmy serwisy, które umieściliśmy niejako „pod warstwą” chmury publicznej i przechodzące przez wszystkie jej warstwy. Oparte są o natywne rozwiązania dostawców usług cloud computing. Stosowanie ich jest u nas obowiązkowe. Nie da się konsumować chmury publicznej w banku bez obowiązkowej warstwy zabezpieczeń służących do monitoringu i prewencji.

Chmura publiczna musi zostać obudowana narzędziami bezpieczeństwa IT. Nie mogę sobie wyobrazić umieszczenia tam czegokolwiek bez dodatkowych mechanizmów CyberSec. Z własnego doświadczenia doradzałbym przestrzeganie tej zasady. Zdarzało się nam – na samym początku konsumpcji chmury publicznej – że deweloperzy sami tworzyli pewne cyberzagrożenia. Nie duże oczywiście, bo były to środowiska całkowicie odcięte od infrastruktury IT banku, ale z punktu naszej reputacji mogłyby zostać uznane za zagrożenie.

Dużo mówi się dziś o zwinnym modelu zarządzania. Czy stosowany jest też w CyberSec?

Zdecydowanie. Jest nawet dedykowana koncepcja DevSecOps. Przede wszystkim warto podkreślić, że w ING Hubs Poland mam duży dział IT. Jest to ponad 300 inżynierów. Oni też stosują metodologię zwinną. Jesteśmy zorganizowani wokół produktów, którymi zarządzamy. Stosujemy podstawowe metodologie agile takie, jak Scrum i Kanban. Stawiamy na Continuous Improvement. Dajemy ludziom bardzo dużo swobody. Wdrożyliśmy podstawowe aspekty agile u siebie i stosujemy się do nich.

Stosowaniu zwinnego podejścia sprzyja też to, że staramy się dostarczać usługę w sposób automatyczny, oferujemy kod źródłowy jako usługę. Przykładowo skanowanie podatności to dla nas jeden z serwisów. Wystawiamy jedynie dostęp do niego deweloperom przez dedykowane API. Dzięki temu sami mogą uruchomić skan tworzonej aplikacji, gdy tylko tego potrzebują.

Wbudowaliśmy portal, za pomocą którego można uruchomić usługi CyberSec. Jedną z nich jest Distributed Denial of Services. Ona też jest dostępna w modelu as a Service. Można ją zasubskrybować i uruchomić „testowy” atak typu DDoS. Usługi cyberbezpieczeństwa integrujemy też z platformą One Delivery Pipeline. Wszystkie usługi i standardowe mechanizmy bezpieczeństwa staramy się integrować i automatyzować.

Ostatni, trzeci, ważny aspekt to wyznaczanie roli tzw. Security Championów. Osoby te – znając się na bezpieczeństwie i działając w ramach tzw. Squadów – potrafią aspekty CyberSec wyjaśnić kolegom. Tworzymy dla nich szkolenia, udostępniamy wiedzę naszych ekspertów, wszystko, aby przygotować ich do tej roli. Security Championem może zostać np. deweloper, który 90% czasu poświęca na tworzenie kodu. Dodatkowo jednak specjalizuje się i dokształca pod kątem bezpieczeństwa IT. Jest więc w stanie np. podpowiedzieć, w jaki sposób pisać bezpieczny kod, czy też jak uruchomić dodatkowy test.

Czym jest Squad?

ING zaadaptowało model, który kiedyś wykorzystywał Spotify. Squad to zespół, który został zorganizowany wokół produktu i ma swojego Product Ownera. Pracuje oczywiście w zgodzie z metodologiami zwinnymi. Z drugiej strony mamy chaptery, które istnieją niejako w poprzek organizacji. Są one bardziej skoncentrowane na tzw. craftsmanship, czyli tym, jakiej wiedzy potrzebują konkretni inżynierowie. Squad może być budowany nie tylko w IT. Może – a właściwie to powinien – zawierać przedstawicieli biznesu. Powinien więc znaleźć się w nim też ktoś ze sprzedaży czy marketingu, a do tego kilku deweloperów, którzy wspólnie zbudują np. nowy produkt lub moduł aplikacji mobilnej.

Wróciłbym jeszcze do platformy One Delivery Pipeline. Jaka jest w niej rola osób odpowiedzialnych za cyberbezpieczeństwo?

Jesteśmy zaangażowani w jej rozwój na poziomie tworzenia zautomatyzowanych tekstów bezpieczeństwa IT. Pewne metody i skrypty, które wykorzystują nasi pentesterzy integrujemy – obok testów funkcjonalnych – na poziomie testów oprogramowania. W ramach Continuous Delivery Pipeline staramy się budować automatyczne testy bezpieczeństwa analizujące, czy kod jest bezpieczny, czy nie ma w nim luk, które można wykorzystać do cyberataku.

Vulnerability Scaning, czyli skanery podatności, są wykorzystywane na poziomie wdrożenia. W tym przypadku testujemy też podatność całego stacku technologicznego. Ostatni element to przegląd kodu źródłowego. Te testy też są zintegrowane z platformą One Delivery Pipeline. Przy każdym wdrożeniu aplikacji uruchamiany jest taki zestaw testów bezpieczeństwa. Na tym więc poziomie jesteśmy włączeni w proces tworzenia i rozwoju oprogramowania w ING.

Można określić, ile testów musi przejść kod aplikacji, aby wejść na produkcję?

Trudno to dokładnie określić, ale na pewno jest ich wiele. Trzeba jednak pamiętać, że w przypadku konkretnej aplikacji testy mają charakter przyrostowy. Nie jest więc testowana całość kodu, lecz tylko te elementy, które się zmieniają. Nie trwa więc to jakoś bardzo długo.

Przed jakimi, największymi wyzwaniami stoją dziś szefowie działów bezpieczeństwa?

Przede wszystkim jest to wojna o talenty. Wyzwania zewnętrzne są oczywiście ogromne i ciągle się zwiększają. Ale zapewnienie ludzi, którzy będą sobie w stanie z tym wszystkim poradzić, jest chyba większym wyzwaniem. Rynek pracy dla specjalistów ds. bezpieczeństwa IT rośnie geometrycznie. Większość opracowań na rynku mówi nawet – w perspektywie kilku lat – o luce kilku milionów specjalistów CyberSec na świecie.

Dodatkowo sytuacja geopolityczna, np. na Ukrainie, jeszcze zwiększa to wyzwanie. Przeciwnikami stają się tzw. Nation State Actor. To powoduje, że zarówno my – jak i inne firmy na rynku – inwestujemy coraz więcej w bezpieczeństwo IT. Otwieramy dedykowane centra cybersecurity. Potrzebujemy więc jeszcze więcej dodatkowych ludzi. Większy popyt powoduje, że coraz trudniej jest utrzymać i pozyskać specjalistów od bezpieczeństwa IT. Chyba właśnie ten problem najczęściej spędza mi sen z powiek.

Drugie, największe wyzwanie dotyczy nowych typów cyberataków. Dziś trzeba bać pod uwagę np. atak wrogiej agencji rządowej, którego celem nie będzie kradzież, a zniszczenie danych. Błyskawiczna, a nawet automatyczna reakcja na takie zagrożenie będzie miała duży priorytet.

Czy rozwiązaniem niektórych problemów mogłoby być wynajęcie usługi bezpieczeństwa, np. w modelu CyberSec as a Service?

Bezpieczeństwo, jeśli chodzi o instytucje finansowe, jest jedną z ostatnich rzeczy, którą oddaje się w outsourcing. Jest to coś, co chcemy trzymać blisko siebie, głównie ze względu na szybkość reakcji, dostosowywania się do nowych sytuacji, budowy mechanizmów zabezpieczających. Jesteśmy bliżej biznesu, dzięki temu elastyczniej reagujemy na zagrożenia niż w relacji z dostawcą, któremu trzeba zlecić wykonanie pewnych działań. To wymaga czasu. My zaś jesteśmy w stanie zareagować natychmiast.

Czy automatyzacja może nieco zmniejszyć zapotrzebowanie na specjalistów IT?

Z pewnością jest to dobre rozwiązanie. Tym bardziej, że utrzymanie zespołu ds. bezpieczeństwa IT, który chciałby pracować w trybie 24/7 – na rynku pracy, jaki dziś mamy – jest trudne. Jeśli więc uda się zautomatyzować większość zadań, które nie dają wielkiej wartości, są żmudne, ale konieczne, to praca analityków bezpieczeństwa IT stanie się dużo ciekawsza. Łatwiej także będzie zatrzymać w organizacji tych specjalistów. Dzięki temu będziemy też potrzebować mniej ludzi, a tym zatrudnionym będziemy mogli płacić więcej.

Automatyzacja jest więc zdecydowanie dobrym kierunkiem. Na razie jednak w ING narzędzia tego typu służą raczej jako element wsparcia. Choć już to oszczędza nam sporo czasu. Kiedy jednak będziemy mieli więcej doświadczeń w wykorzystaniu tego typu narzędzi, to zapewne pozwolimy, aby narzędzia te samodzielnie podejmowały niektóre decyzje. Choć oczywiście – post factum – zostaną one skontrolowane przez człowieka.