Dwóch Polaków na czele kluczowych obszarów CyberSec w ING

Z Przemysławem Wolkiem, Global Head Security Detection and Response oraz Maciejem Ogórkiewiczem, Global Head Attack Surface Management for ING Bank rozmawiamy o ich awansie w strukturach Grupy ING; podejściu i strategii zarządzania cyberbezpieczeństwem; buzzwordach, takich jak Security by Design czy DevSecOps; a także planach i najważniejszych wyzwaniach w pionach, którymi kierują.

Obaj Panowie awansowali właśnie w strukturach ING. Jaka jest Wasza nowa rola i wspólna historia?

Przemysław Wolek (P.W.): W ciągu ostatniego roku ING przeprowadziło proces ustanawiania nowego modelu operacyjnego w obszarze cyberbezpieczeństwa. Tego, w jaki sposób globalny CISO chce pracować i w jaki sposób cały nasz pion ma funkcjonować. Ostatecznie zdecydowano, że powstaną trzy główne filary związane z dostarczaniem usług bezpieczeństwa IT. Są nimi: Security Detection and Response, Attack Surface Management oraz Identity and Access Management. W każdym z tych obszarów poszukiwano nowego lidera. Pod koniec 2022 roku otwarto nabór na te pozycje. Wspólnie z Maćkiem aplikowaliśmy na nie. Obu nam się udało uzyskać awans.

Co warto zaznaczyć, znamy się z Maćkiem już bardzo długo. W 2010 roku zaczynaliśmy budowę Centrum Usług Security dla ING od małego, 5-osobowego zespołu. Dziś, 12 lat później, pracuje w nim już 420 osób! Także za nami już kawał wspólnej historii. Obaj mamy też długą historię pracy w Grupie ING, ja 16-letnią w ING Hubs Poland, a Maciek 13-letnią, ostatnio jako CISO w ING Banku Śląskim.

Jakie nowe stanowiska objęliście?

P.W.: Maciek został Global Head Attack Surface Management for ING Bank, a ja Global Head Security Detection and Response for ING Bank.

Maciej Ogórkiewicz (M.O.): Zdecydowałem się na przejście do globalnej jednostki ze względu na większy zakres odpowiedzialności. Mój nowy dział związany jest z ogólnie pojętym zabezpieczaniem środowiska IT, wdrożeniami mechanizmów, które mają chronić infrastrukturę i systemy IT oraz jej użytkowników.

Naszą rolą jest również wykrywanie wszelkiego rodzaju podatności, ewentualnych luk, które musimy poprawić. Gromadzimy informacje na temat wszelkich zagrożeń, aby uzyskać spójny obraz sytuacji cyberbezpieczeństwa w Grupie ING i by móc w odpowiedni sposób zareagować. Celem jest oczywiście ograniczenie do minimum ekspozycji na cyberataki.

P.W.: Z kolei filar, za który ja odpowiadam, zajmuje się wykrywaniem i odpowiadaniem na cyberzagrożenia. W ING Hubs Poland nadzorowałem dotąd pracę zespołów dostarczających usługi cybersecurity dla całej Grupy ING. Byłem też członkiem zespołu zarządzającego naszego globalnego CISO. To, co teraz się dla mnie zmieni, to fakt objęcia globalnej odpowiedzialności za całość mojego obszaru, w tym relacje z regulatorem czy tak strategiczne tematy, jak wybór narzędzi i platform technologicznych.

Czy te zmiany przekładają się na to, co robi ING Hubs Poland? Czy te awanse „idą w dół”? Wiążą się np. ze zwiększeniem zatrudnienia?

P.W.: Na pewno tak, choć nie będą to setki czy tysiące osób. Łącznie w najbliższym roku zatrudnimy 40-50 dodatkowych pracowników. Już jesteśmy dużym, ponad 400-osobowym zespołem. Jest on mniej więcej równo podzielony pomiędzy obszary: Detection and Response, Attack Surface Management oraz Identity and Access Management. Po zatrudnieniu nowych osób staniemy się największą tego typu jednostką w Polsce nie będącą Shared Services, pracującą dla wielu klientów, ale jednej, dużej organizacji.

Nie musimy już rosnąć, jeśli chodzi o liczbę pracowników. Natomiast jeżeli chodzi o wiedzę i zakres odpowiedzialności, to ten obszar z pewnością wciąż będzie rósł. Zwłaszcza że ING staje się coraz bardziej aktywny w public cloud, usługach Software as a Service. Staje się dużą firmą, która ma hybrydowy sposób pracy. Część systemów IT jest w naszych centrach danych, scentralizowanych w większości w głównych ośrodkach w Amsterdamie, a część w chmurze publicznej. W związku z tym nasi ludzie też muszą zmienić zarówno sposób myślenia, jak i działania. A to wymaga dodatkowej wiedzy, pozwalającej skutecznie funkcjonować w systemie hybrydowym.

Czyli będą Państwo zarządzać większymi, międzynarodowymi grupami?

P.W.: Nowy sposób funkcjonowania pionu cyberbezpieczeństwa w ING, to w ogóle bardzo ciekawy konstrukt. Obaj mamy zespoły zarówno w Polsce, jak i w Holandii. Ale nadzoruję też pracę osób znajdujących się w Singapurze, a Maciek w Manili. Faktycznie są to zespoły międzynarodowe.

M.O.: To, co się tak naprawdę stało to fakt, że Global CISO – poprzez implementację nowego modelu operacyjnego – rozciągnęła zarządzanie funkcjonalne obszarem cyberbezpieczeństwa na więcej niż jedną, fizyczną organizację. Obejmuje ona ING Bank NV, który jest tak naprawdę centralą banku, oraz ING Hubs Poland, które do tej pory świadczyło usługi na rzecz całej Grupy. Byliśmy wewnętrznym dostawcą różnego rodzaju serwisów, aktywności i procesów bezpieczeństwa.

Chodzi o to, aby zoptymalizować strukturę zarządzania i uzyskać maksimum wartości biznesowej z takiego układu. Global CISO wpływa więc na to, co dzieje się w zakresie cyberbezpieczeństwa w innych jednostkach, lokalnych bankach Grupy, takich jak ING Bank Śląski w Polsce czy ING Australia.

Do tego dochodzą jeszcze obszary, które do tej pory były poza CISO, np. Cyber Risk Management w pierwszej linii. To dzieje się również w zarządzaniu danymi czy strategią. Poprzez wdrożenie takiej struktury rośnie rola CISO. Zaczyna mieć więcej narzędzi do tego, aby efektywniej zarządzać bezpieczeństwem globalnego banku, jakim jest ING.

P.W.: Działania ING Hubs Poland są spójne z tym, co dzieje się w Grupie. Ale jednocześnie nie chcemy być klasycznym centrum Shared Services. Do tej pory jako szef tego Centrum w obszarze CyberSec byłem w CISO Management Team, odpowiadając za dostarczanie usług bezpieczeństwa IT. Teraz to się zmieniło dla mnie i Maćka, ale i wielu menedżerów, którzy do nas raportują. Wszyscy otrzymaliśmy odpowiedzialność funkcyjną za całość, nie tylko za Centrum Shared Service.

Mamy więc teraz wpływ na to, jakich technologii będziemy używać, jak będziemy wpływać na kształtowanie strategii cyberbezpieczeństwa całego Banku. Oczekiwania wobec nas są takie, abyśmy mieli na to pomysł. Tak więc dużo się zmienia. Pomaga to nam o tyle, że nasi inżynierowie, nasi pracownicy mają nie tyle wąski zakres, dobrze opisanych odpowiedzialności – jak to zwykle bywa w Shared Service Center – lecz pracują w globalnych zespołach.

Rozumiem, że jest jeden globalny CISO i kilka zespołów, takich jak Wasze?

P.W.: WING CTO Grupy również zaczął raportować bezpośrednio do zarządu. To wydarzyło się ok. 2 lata temu.

M.O.: De facto stał się członkiem zarządu Grupy. Do tej pory był pod szefem operacji, COO. To samo stało się w innych jednostkach, np. ING Banku Śląskim. Celem było uspójnienie modelu zarządzania. Wynikało to z istotności technologii dla cyfrowego banku. Nie jest już ona centrum kosztów czy dobrem takim, jak prąd. To jest coś, co wspiera biznes w rozwoju. Dlatego też CTO stał się członkiem zarządu.

Jednocześnie CISO także przeszedł z operacji – będąc dotąd kompletnie w oderwaniu od technologii – do pionu technologicznego. Poprzez wdrożenie spójnego modelu operacyjnego, raportujemy z Przemkiem bezpośrednio do Global CISO. Patrząc hierarchicznie, jesteśmy na 2. poziomie, bezpośrednio pod zarządem Grupy.

P.W.: Poza wspomnianymi już trzema najważniejszymi obszarami w zakresie cyberbezpieczeństwa są jeszcze oczywiście małe zespoły związane z architekturą i strategią. One też raportują do globalnego CISO. Pozycje są jednak trzy: Attack Surface Management, Security Detection and Response oraz Identity and Access Management.

Wspominacie, że będziecie mieli wpływ na wybór technologii. Czy wiadomo już, w jakim kierunku będziecie chcieli iść w każdym z Waszych obszarów?

P.W.: Niedawno miałem prezentację na CTO Management Team na temat założeń dotyczących tego, jakie technologie będziemy wykorzystywać w przyszłości w kontekście detekcji cyberzagrożeń. Nie mogę jeszcze powiedzieć, co to będzie. Na stole są dwie możliwości. Jak zgodę otrzymam, a pewnie tak będzie, to ustalimy kierunek technologiczny dla ING na najbliższe 3 lata. Nie przewidujemy jednak rewolucji. Aczkolwiek plany, które mamy – biorąc pod uwagę inwestycję ING w public cloud, zwłaszcza w technologie Software as a Service – wymuszają zastosowanie bardzo nowoczesnych rozwiązań.

To, co mogę już powiedzieć, to, że będziemy wymieniać całą platformę SIEM. To pewnie będzie swego rodzaju rewolucja technologiczna. Przez najbliższe 2 lata będziemy budować tzw. narzędzie Extended Detection Response na bazie technologii, które częściowo mamy już wdrożone.

U Maćka też będzie się dużo działo pod kątem technologicznym, przy wykorzystaniu One Pipeline i Secure Software Development.

M.O.: Koncentruję się przede wszystkim na public cloud, do którego szybko zmierzamy, ale również na takich obszarach, które są dziś dużym wyzwaniem dla świata security – konteneryzacji, mikroserwisach, z dużym naciskiem na bezpieczeństwo kodu, który wytwarzamy. W tym kontekście konieczne jest wdrożenie lepszych mechanizmów detekcji i zabezpieczania, aby ustawicznie podnosić na wyższy poziom kulturę kodowania pod kątem bezpieczeństwa.

Istotna jest zmiana kulturowa i bliska współpraca z DevOps, aby oni rozumieli zagadnienia security i traktowali je jako część swoich zadań. Dlatego ważnym tematem dla nas jest wbudowanie strategii bezpieczeństwa w strategię testowania oprogramowania już na etapie jego wytwarzania. Ważne jest również dbanie o to, aby aplikacje, które wytwarzamy i utrzymujemy, były bezpieczne w trakcie całego swojego życia.

Mamy dedykowany program Security Champions, którego celem jest podnoszenie świadomości, umiejętności i kultury bezpieczeństwa wśród osób zatrudnionych w pionie technologii. Jest to o tyle istotne, że nie można tu zastosować klasycznego podejścia do budowania świadomości, np. poprzez wysłanie newslettera. Nie spowoduje on bowiem, że deweloper będzie zwracał większą uwagę na to, aby w jego kodzie nie było błędów.

Zmiana ma spowodować to, że tak jak dziś deweloperzy dbają o czystość kodu, czy to, aby zmienne „ładnie” się nazywały, tak chcielibyśmy, aby również uwzględniali fakt, by kod był bezpieczny. Żeby to uczynić, musimy dać im możliwości zdobywania wiedzy, testowania, próbowania, swego rodzaju zabawy. Choć najlepiej nie wprost na kodzie, który wytwarzają.

Czemu mikroserwisy są takim wyzwaniem z punktu widzenia cyberbezpieczeństwa?

M.O.: W informatyce jest generalnie tak, że najpierw świat myśli nad tym, aby coś nowego w ogóle zaczęło działać. Jak już tak jest, pewne decyzje dotyczące designu zostały podjęte, to dopiero wówczas ktoś zaczyna myśleć o bezpieczeństwie nowych rozwiązań. Niestety, na tym etapie siłą rzeczy musi dochodzić do różnego rodzaju „zgniłych” kompromisów.

Sprawa z mikroserwisami i kontenerami jest taka, że często platformy te nie oferują mechanizmów bezpieczeństwa na takim poziomie, jakiego byśmy sobie życzyli. Wyobraźmy sobie, że mamy platformę, która pozwala nam na stawianie tego typu środowiska, ale – z punktu widzenia regulacji czy bezpieczeństwa – chcielibyśmy je podzielić tak, aby kontenery należące do różnych aplikacji, o różnych klasyfikacjach ryzyka nie widziały się nawzajem. Możemy to zrobić częściowo za pomocą mechanizmów, które oferuje platforma konteneryzująca, ale chcemy zrobić to bardziej granularnie, a także mieć lepszą „widoczność” na infrastrukturę. Musimy wówczas kupić dodatkowe rozwiązanie, wdrożyć je i utrzymywać.

Podobna historia jest w przypadku usług public cloud. Standardowe mechanizmy, które są oferowane przez dostawców chmury, mają ograniczenia. Jeżeli chcemy zrobić coś lepszego, to ponownie musimy zrobić to sami, np. dobudowując brakującą część albo skorzystać z mechanizmów dostarczanych jako produkt firm trzecich. Co warto podkreślić, sama platforma chmurowa nie jest niebezpieczna, ale – patrząc z perspektywy wykonania i implementacji – po prostu musimy ją poprawić.

P.W.: Trzeba też mieć na uwadze to, że od zawsze trwa „wyścig zbrojeń”. Do tej pory platformy kontenerowe były bezpieczniejsze niż świat maszyn wirtualnych, który ma doskonale rozpoznane exploity. Z drugiej strony jednak narzędzia detekcji były dostosowane praktycznie tylko do świata maszyn fizycznych i wirtualnych. W świecie kontenerów nie było dotąd takich rozwiązań albo było ich bardzo mało i były bardzo drogie.

Teraz pojawiają się nowe rozwiązania, które tanieją, ale często – z różnych powodów ­– wciąż nie są wykorzystywane. Istnieje bowiem przeświadczenie, że kontenery to jest coś, co jest nieedytowalne. Bardzo krótko żyją, nie można ich modyfikować, a w związku z tym są bezpieczne. Takie założenie można było przyjmować jeszcze 2 lata temu. Teraz środowiska te zaczynają być exploitowane. Są podatne i powinny być zabezpieczane. Nie jest to łatwe, bo to rozwiązania nowe dla wielu osób, również związanych z bezpieczeństwem czy audytem.

Pojawia się wyzwanie dla ekspertów dotyczących bezpieczeństwa, aby aktywnie zabezpieczać systemy kontenerowe i zmieniać standardy. Trzeba jednak pamiętać, że jeśli opublikuje się standard dotyczący bezpieczeństwa tradycyjnej technologii, to on potrafi być aktualny nawet kilka lat. W przypadku kontenerów standardy powinny być odświeżane w zasadzie co roku. Technologia ta tak dynamicznie się rozwija, że trzeba przyglądać się jej częściej i publikować nowe standardy. To wszystko jest w moim i Maćka zakresie odpowiedzialności.

M.O.: Staliśmy się właścicielami niektórych standardów i decydujemy, jak Bank będzie podchodził do poszczególnych zagadnień bezpieczeństwa, jak chcemy je realizować.

To mi przypomina ideę Security by Design. Hasło to było popularne przez jakiś czas, choć krótko.

P.W.: Idea, że niektóre polityki bezpieczeństwa wymagają zaprojektowania systemu w taki sposób, aby był on całkowicie bezpieczny wciąż niestety „ciągnie się” za nami. Istnieje też przeświadczenie, że jak masz system zbudowany zgodnie z określonym schematem, to można uznać, że wszystko jest OK.

Ale rzeczywistość jest taka, że cyberzagrożenia rozwijają się bardzo szybko i nie można uznać systemu za bezpieczny, tylko dlatego, że jest zgodny z jakimś frameworkiem. Przeciwnie, jeśli jakiś framework jest dobrze znany, to oznacza to, że na pewno znane są też jego podatności. Zasada Security by Design jest już więc właściwie nieaktualna.

Teraz prowadzimy dyskusję na temat tego, aby wszystko robić as a Code i by kod ten był regularnie testowany pod kątem bezpieczeństwa. Dobrze byłoby również, aby nic nie trwało w niezaktualizowanej konfiguracji zbyt długo, by było regularnie testowane, odświeżane i poprawiane. Zaliczyłbym do tego też infrastrukturę budowaną as a Code. Aby „buildy systemowe także były w jakiś sposób testowane i zabezpieczane na bieżąco w ramach całego buildu aplikacji i infrastruktury. Wtedy jest szansa, że kolejne podatności – które cały czas się pojawiają – będą jednak usuwane.

M.O.: Trochę żartując, mogę podać kilka innych buzzwordów, które wciąż funkcjonują, jak np. Security by Default, albo ostatnio bardzo modne Zero Trust Network Access. Oczywiście każdy przez Zero Trust rozumie coś innego. Powstają więc opracowania na temat tego, co de facto przez to rozumiemy?

Kończąc jednak z żartami, odchodzi się dziś od podejścia, że raz opracowany system jest – i zawsze będzie – bezpieczny. Bezpieczeństwo systemów IT, ich poziom zabezpieczeń zawsze będzie obniżał się w funkcji czasu, a my musimy na to odpowiednio reagować.

Co więcej, całość technologii idzie obecnie w kierunku Software Defined. Teraz już nawet reguły firewall sterowane są – w nowoczesnych instalacjach – z pipeline’u. Trzeba zatem je odpowiednio sprawdzać, walidować. Tradycyjne mechanizmy, które znamy od wielu lat, często nie mają już zastosowania.

Dlatego zabezpieczenie nowoczesnych technologii stanowi dziś duże wyzwanie. Sama technologia nie oferuje jeszcze odpowiedniej dojrzałości, a jednocześnie wymaga nowego podejścia i wiedzy.

Jak wygląda cykl testowania i sprawdzania podatności? Odbywa się regularnie, np. raz dziennie, czy też przy każdej, nowej, wprowadzanej funkcji lub podatności?

M.O.: Trochę zależy od technologii. W klasycznych środowiskach wirtualizacji lub opartych na systemach fizycznych, testowanie podatności ma charakter cykliczny. Przykładowo wykrywamy brakującą poprawkę czy błąd konfiguracyjny i ktoś podejmuje decyzję, co z tym robić.

W sytuacji, kiedy mamy rzecz zdefiniowaną jako kod źródłowy, to najczęściej sprawdzanie konfiguracji, ewentualnych podatności następuje w momencie deploymentu. Ale musi za tym iść założenie, że to, co z tego kodu powstało – np. kontener albo aplikacja – będzie podlegało okresowemu odświeżeniu, redeploymentowi.

Jeśli zaś chodzi o kod, to mamy dwa podejścia. Testujemy go pod kątem bezpieczeństwa w momencie, kiedy robimy deployment czy build aplikacji uruchamia pewnego rodzaju mechanizmy analizujące ewentualne podatności. Niektóre rozwiązania oferują wtyczki do zintegrowanych środowisk deweloperskich, które pozwalają wykrywać luki bezpieczeństwa już na etapie pisania kodu.

Niektóre rzeczy jesteśmy jednak w stanie testować jedynie wtedy, gdy system już działa. Mamy wówczas do czynienia z testowaniem dynamicznym, testami penetracyjnymi. Są też inne, ciekawe metody testowania, jak np. Red & Blue Teaming. Symulujemy zaawansowane metody włamania, które przeprowadzają ludzie znający techniki ofensywne. Udowadniamy w ten sposób, jak dobre są zabezpieczenia naszego systemu, próbując znaleźć i wykorzystać wszelkie luki. Jest to ćwiczenie zwykle robione w sposób niezapowiedziany. Dzięki temu jesteśmy w stanie również sprawdzić reakcję na niebezpieczne zdarzenia, a także czy w ogóle zostały zauważone. Jest to swego rodzaju kontrolowane włamanie.

Metod testowania jest wiele. Podobnie jak sygnałów, które potem trzeba przetworzyć, aby posiąść całą wiedzę na temat cyberzagrożeń. Do tego jeszcze dochodzą nam działania Cyber Threat Actors. To wszystko trzeba zebrać w jedno miejsce i zdecydować, gdzie jesteśmy mocni i tam nic nie robimy, albo gdzie mamy braki i należy np. wprowadzić nowe mechanizmy, które nam pozwolą zabezpieczyć nasz system i lepiej wykrywać podatności. To jest niekończący się taniec.

Pan Przemysław wspomniał o Extended Detection Response. Czym jest?

P.W.: Extended Detection Response to bardziej filozofia niż technologia. Chociaż są dostawcy, którzy twierdzą, że sprzedają już gotowe systemy EDR. Dzięki nim mamy mieć pełen obraz detekcji w danej organizacji. Moim zdaniem te deklaracje są trochę naciągane. Niewielu dostawców rzeczywiście jest w stanie taki zintegrowany system sprzedać.

To, co w skrócie oznacza EDR to jest materializacja tego, co kiedyś nazywało się Defense in Depth, czyli obrona – a w tym kontekście detekcja – w wielu warstwach. To, od czego w ogóle zaczęła się detekcja, to był obszar sieciowy. Sprawdzano, czy ktoś się włamuje. Potem zbieraliśmy logi i obserwowaliśmy, czy nie dzieje się coś niebezpiecznego na poziomie infrastruktury i systemu operacyjnego. Kolejna była warstwa stacji roboczych. Tam zaczęły funkcjonować takie technologie jak EDR. Rozwiązania te były coraz bardziej zaawansowane. Pozwalały nie tylko wykrywać, lecz także blokować pewne rzeczy, odpowiadać na zagrożenie np. poprzez blokowanie lub izolowanie stacji roboczej.

Dostawcy zorientowali się, że dziś bardzo trudno jest wykryć atak cybernetyczny w jednym miejscu. Czasem widzimy, że ktoś próbuje uzyskać wyższe uprawnienie czy to na poziomie systemu operacyjnego, czy Active Directory, czy innego systemu LDAP, który funkcjonuje w organizacji. Wcześniej jednak musiał zapewne zainfekować np. stację roboczą. Dostał się do niej np. poprzez phishing. Następnie zaś przerzucił się w inne miejsce infrastruktury IT. Być może zaatakował z poziomu sieci.

Ataki te, widoczne w różnych miejscach, powodują różnego rodzaju alerty bezpieczeństwa, ale często o bardzo niskim priorytecie. Haker będzie starał się być jak najciszej. Będzie próbował zachowywać się w taki sposób, w jaki zachowuje się sama organizacja, administratorzy, użytkownicy.

Z punktu widzenia detekcji ważne jest połączenie tych zdarzeń w umiejętny sposób, tak aby ten łańcuszek różnego typu zdarzeń zbudował przeświadczenie o prawdopodobnym cyberataku. Najtrudniejsze do zrobienia jest właśnie stworzenie tych korelacji, możliwych schematów działania i ataku. Do tej pory inżynierowie ING Hubs Poland – na podstawie dostępnych frameworków, takich jak Mitre – próbowali sami budować takie korelacje. Wiele razy nam się to udawało, bo mamy dobre informacje dotyczące tego, jakie reguły budować. Ale ten wyścig jest coraz trudniejszy.

W związku z tym liczymy na to, że wkrótce powstaną systemy zintegrowane Extended Detection and Response, które – przy wykorzystaniu takich technologii, jak algorytmy Machine Learning i Artificial Intelligence – będą w stanie, na poziomie analityki danych, korelować zdarzenia z bardzo różnych warstw. Pozwolą wskazywać nam – z dużym prawdopodobieństwem – że mamy do czynienia z cyberatakiem, a nie zwykłą aktywnością użytkowników. To będzie prawdziwe narzędzie Extended Detection and Response.

Jak zrobić to skutecznie?

P.W.: Bardzo liczymy na to, że będziemy mogli budować własne reguły detekcji w kontekście danej organizacji. Ale liczymy również na to, że technologia będzie coraz bardziej dojrzała, że będziemy w stanie kupić jak najwięcej systemów, które będą dostarczały gotowe korelacje. Nasze zadanie na 2 lata to, aby mieć taki w pełni zintegrowany, zaawansowany system.

Czy to jest największe wyzwanie w Pana obszarze?

P.W.: W kontekście detekcji tak. My zresztą już w dużym stopniu technologie klasy EDR mamy, czy to w public cloud, czy na poziomie naszych urządzeń końcowych. Zakończyliśmy pierwszą fazę jej wdrożenia. Choć kilka rzeczy musimy jeszcze dokończyć, by ten system był w pełni zintegrowany, w pełni skuteczny.

A jak to wygląda w obszarze Attack Surface Management?

M.O.: Dla nas najważniejszym działaniem jest podniesienie na wyższy poziom bezpieczeństwa kodu tworzonego w ING, a także detekcji podatności już na etapie jego wytwarzania czy deploymentu aplikacji. Wymaga to jednak zmiany kulturowej.

Do tego dochodzi nieustanne zabezpieczanie środowisk public cloud, kontenerowych i miejsc pracy. Wraz z pandemią zmienił się model dostępowy do infrastruktur, które coraz bardziej wychodzą na zewnątrz, otwierają się. Klasyczny VPN już więc nie wystarczy. Trzeba dziś bowiem pozwolić na korzystanie bezpośrednio z takich serwisów chmurowych, jak np. Microsoft 365, ale również sprawować kontrolę nad tym, co ze stacji roboczej użytkownika „wychodzi” i co do niej „wchodzi”.

W moim obszarze istotne jest też sprawienie, abyśmy mieli naprawdę dobry system informacji o zagrożeniach (tzw. Threat Intelligence). Zbieranie danych „wywiadowczych” to jest pewnego rodzaju sztuka. Przede wszystkim chodzi o to, aby nie być reaktywnym, umieć przewidzieć i odpowiednio zareagować na konkretne sytuacje. Nieustanne sprawdzanie tego, gdzie występują cyberzagrożenia i odpowiednie reagowanie na nie poprzez ulepszanie naszych możliwości ochrony i detekcji to zadanie, które w obszarze Zarządzania Zagrożeniami (tzw. Threat Management) będziemy usprawniać.

W cyberbezpieczeństwie stale dąży się do tego, aby coś poprawiać, poprawiać i jeszcze raz poprawiać. To jest proces, który nigdy się nie kończy.

W kontekście bezpieczeństwa kodu zapytałbym o jeszcze jeden, popularny termin DevSecOps.

M.O.: W naszym obszarze to kolejny Yeti, o którym wszyscy wiedzą, że istnieje, ale nikt go nie widział (śmiech). Żartuję oczywiście. Problem z DevSecOps jest taki, że tych ludzi od „Sec” jest niewielu. Generalnie branża cierpi na stosunkowo małą liczbę osób, które rzeczywiście znają się na security. W związku z tym np. wybiera się właśnie „rokujących w CyberSec” deweloperów, a następnie uczy się ich, aby część czasu poświęcili na budowanie bezpieczeństwa kodu aplikacji od początku.

Spodziewam się, że – w związku z dużą liczbą wakatów – w bezpieczeństwie w najbliższej przyszłości powstanie coraz więcej narzędzi opartych na AI wspomagających operacje czy mierzenie tego, jak działają DevOps z punktu widzenia security.

P.W.: Zapotrzebowanie na specjalistów od cyberbezpieczeństwa rośnie. Mówi się nawet o 6 mln wakatów na całym świecie w tym obszarze w perspektywie 3 lat. Deficyt ten będzie się tylko pogłębiał.

M.O.: Jeżeli chodzi o deficyt specjalistów, to jest to trochę syndrom wędkarza, który opowiada o rybie, która mu właśnie uciekła. Z każdym rokiem jest ona coraz większa. Faktem jest jednak, że rzeczywiście odczuwamy te braki, szczególnie w zakresie bezpieczeństwa aplikacyjnego. Widać to nawet po stawkach proponowanych np. architektom bezpieczeństwa usług public cloud. Są naprawdę wysokie.