Piotr Mierzwiński:

Witam Państwa serdecznie w kolejnym odcinku podcastu „Praktyczna strona bezpieczeństwa”. Dziś naszym gościem jest Marek Makowski, Inżynier w Zespole Bezpieczeństwa Defenswynego EXATEL. Cześć Marku.

Marek Makowski:

Cześć.

Piotr:

Chciałbym z Tobą porozmawiać na temat twojej przeszłości i przyszłości w cyberbezpieczeństwie. Skąd w ogóle twoja osoba w cyberbezpieczeństwie? Wcześniej cyberbezpieczeństwem się nie zajmowałeś?

Marek:

Rzeczywiście wcześniej nie zajmowałem się cyberbezpieczeństwem, natomiast od samego początku swojej kariery zawodowej, a nawet jeszcze wcześniej bo na studiach, byłem mocno związany z szeroko pojętą transmisją danych i technologiami związanymi z taką transmisją. Każdego dnia przekonujemy się, że te bity, które są przesyłane przez Internet i zawierają jakieś informacje, to dobrze żeby były jak najlepiej chronione. Także gdzieś tam cały czas jakiś fokus na tym bezpieczeństwie był i w EXATELU udało mi się zrealizować marzenie dołączenia do pełnoprawnego zespołu cyberbezpieczeństwa.

Piotr:

To czym zajmujesz się w Zespole Bezpieczeństwa Defensywnego? Czym w ogóle jest bezpieczeństwo defensywne?

Marek:

Bezpieczeństwo defensywne to taki zestaw działań, który ma na celu mitygację zagrożeń w szeroko pojętej cyberprzestrzeni. Ja w tym zespole odpowiadam bezpośrednio za rozwój naszego autorskiego rozwiązania chroniącego przed atakami DDoS. Ta platforma nazywa się TAMA.

Piotr:

A czym są ataki DDoS?

Marek:

Są to ataki skierowane na infrastrukturę jakiegoś podmiotu, które mają na celu uniemożliwienie wykorzystania tej infrastruktury przez wysycenie zasobów. Mogą to być zasoby w postaci przepustowości łącza, dostępu do Internetu czy możliwości sprzętu, który do tego łącza jest podłączony. To właśnie ten sprzęt czy też infrastruktura ma zostać unieruchomiona.

Piotr:

Wydaje się, że atak DDoS to dosyć prosty atak, skoro polega na wysyceniu czy zablokowaniu konkretnej infrastuktury. Czy jest tak rzeczywiście? Czy atak DDoS nie jest trochę jak młotek, który służy do przybijania gwoździ?

Marek:

To bardzo dobre pytanie, a odpowiedź brzmi – to zależy, ponieważ są dwa aspekty, które należałoby w mojej opinii poruszyć. Na pewno jest to jeden z najpopularniejszych ataków występujących w szeroko pojętym Internecie, a jego popularność wynika z tego, że jest bardzo prosty do zamówienia. Tak naprawdę grupa atakujących odrobiła świetnie pracę domową, ponieważ zrobili świetny produkt, u niektórych dostępny w Internecie nawet z oficjalnymi cennikami. Taki DDoS as a Service. I posiadając kartę kredytową, tudzież rozliczając się w jakimś Bitcoinie, można sobie spokojnie taki atak na wybrany cel zamówić i ten atak zostanie przeprowadzony. Skala i poziom skomplikowania samego ataku, to jest ten drugi aspekt. Oczywiście w tych najtańszych opcjach atak DDoS będzie bardzo prosty, nieskomplikowany, o poziomie wysublimowania młota pneumatycznego. Taran wjeżdża i pozostawia wyłącznie zgliszcza i po tym co zostało trzeba podnosić całą infrastrukturę. Może być też atak, który będzie bardziej wysublimowany, wielowektorowy i będzie trwał dłużej i będzie zdecydowanie cięższy w mitygacji. Jest kilka takich aspektów, które komplikują atak.

Piotr:

To jakie to są aspekty? Czy polega on na tym co atakujemy, jak i z wykorzystaniem jakich urządzeń? Co wpływa na stopień skomplikowania ataku DDoS?

Marek:

Na poziom komplikacji w mitygacji takiego ataku tudzież wykrywania, na pewno wpływa to jak ów atak jest prowadzony. Czy jest on prowadzony na jedno urządzenie? A może jest to zyskujący ostatnimi czasy na popularności atak typu carpet bombing, który nawiązuje do nalotów dywanowych z II wojny światowej. Wtedy zasoby klienta atakowane są bardzo szeroko (cały zakres adresacji IP) i taki atak zdecydowanie zwiększa prawdopodobieństwo powodzenia, zwłaszcza że sam poziom ataku na pojedynczy adres IP może być zdecydowanie niższy, a i tak łącze zostanie wysycone. W takim przypadku może dochodzić do takiej sytuacji, gdzie obrona (mitygacja) będzie trochę bardziej skomplikowana. Bo jeśli mamy pouruchamiane różne usługi na różnych adresach IP, to ciężej jest mitygować wszystko, ponieważ każda usługa związana jest z tym, że jest tam jakaś charakterystyczna sygnatura ruchu prawidłowego, a wszystko co nie jest ruchem prawidłowym, powinno zostać zmitygowane. Natomiast gdy atakujemy całą sieć, to nie mamy tych wariantów zbyt wiele i nie ma takich bardzo uniwersalnych mechanizmów, które pozwoliłyby takie działania skutecznie prowadzić. Są to jednak zwykle bardzo customizowane mechanizmy, zarówno detekcji jak i mitygacji tych ataków.

Piotr:

Powiedziałeś, że atak sam w sobie może być i skomplikowany i nieskomplikowany. Mam teraz pytanie do drugiej natury Marka Makowskiego, czyli do tego, że jesteś również Product Ownerem. Jesteś osobą która odpowiada za rozwój narzędzia służącego do obrony przeciwko tego typu atakom. Jak w takim razie i w oparciu o co tworzyć rozwiązanie, żeby działało ono zarówno przeciwko tym prostym, ale też tym bardziej skomplikowanym i problematycznym atakom DDoS?

Marek:

Ponownie bardzo dobre pytanie. Przede wszystkim chyba trzeba się skoncentrować na tym co jest aktualnie popularne w świecie zagrożeń. Analiza tego co było popularne, czyli nauka na tym co już się wydarzyło i próba przewidzenia jakichś elementów w przyszłości. Czyli jakieś takie elementy, które pozwolą wyprodukować uniwersalne mechanizmy, pozwalające szybko dostosowywać się do zmiennej natury ataku, żeby już we wsparciu osoby która będzie monitorowała daną sytuację, można było te polityki detekcji i mitygacji dostosowywać. Istotnym tutaj elementem, są również oczekiwania naszych klientów. Jest to element, który trzeba brać pod uwagę, tak samo jak wymagania naszych interesariuszy wewnętrznych i trochę analizy tego co robi konkurencja, bo to zawsze warto śledzić. Może skupienie nie jest największe na tym ostatnim elemencie, ale też warto brać go pod uwagę.

Piotr:

Czyli szukamy pomysłów na rozwiązania. Zbierasz gdzieś później te pomysły jako Product Owner, jako osoba która spina gdzieś te wszystkie informacje od tego co potrzebujemy my jako EXATEL, ale także czego potrzebują klienci i czego realnie potrzebuje rynek. Jak wygląda natomiast wybieranie tych najfajniejszych pomysłów? W jaki sposób decydujesz o tym? Robisz to sam czy w grupie? Decydujesz o tym co należy wdrożyć, w którą stronę rozwijać te rozwiązanie. Bo rozwiązanie, które nie jest rozwijane, jest tak naprawdę martwym rozwiązaniem.

Marek:

Tutaj jest na pewno wykonywana analiza aktualnych potrzeb i jest to taka codzienna praca, żeby zastanowić się właśnie całym zespołem, który działa na rzecz rozwoju tego produktu. Faktycznie na koniec te priorytety są przypisywane przez Business Product Ownera, natomiast priorytety wynikają z wielu zadań, które są podejmowane przez cały zespół. Bo jest dana funkcjonalność, ale wraz ze wsparciem analityków rozbijamy ją sobie na części pierwsze, dzielimy na bardzo konkretne zadania, które muszą zostać wykonane chociażby przez zespół deweloperski. Na tej podstawie podejmujemy decyzje co aktualnie jest najistotniejsze z punktu widzenia samej platformy. Bo może to być faktycznie potrzeba danego klienta, a może się zdarzyć taka sytuacja, gdzie dowiezienie jakiejś funkcjonalności przyspieszy proces radzenia sobie z danym problemem. Gdzieś tam ta praca analityka znajdującego się na pierwszej linii Security Operation Center zostanie na tyle usprawniona, że będzie to miało wymierne korzyści tak naprawdę dla wszystkich. Mogą być sytuacje, które sprawią, że łatwiej będzie daną usługę skonfigurować administratorom, tudzież wzmocnią jakieś tam ich zdolności analityczne co do tego jaki ruch jest prawidłowy, a jak lepiej dobrać polityki mitygacyjne. Także są to takie analizy, które są codziennie prowadzone. I podejmowanie czasami ciężkich decyzji, bo to nie jest tak, że zespół jest z gumy i jest w stanie zrealizować wszystkie zadania, ale staramy się pogodzić te wszystkie grupy interesów i tych naszych interesariuszy.

Piotr:

Powiedziałeś że oprócz Ciebie w tym zespole jest też Business Product Owner i analitycy. Wspomniałeś też o deweloperach. Jakie grupy osób pracują nad tym projektem, bo to nie jest chyba mała grupa osób?

Marek:

Business Product Ownerem jestem ja, więc tak, współpracuję z nim na co dzień i oglądam go nawet w lustrze.  Do tego dochodzi na pewno Scrum Product Owner, czyli osoba najbliżej pracująca z zespołem wytwórczym, opiniująca dosłownie każde zadanie – czy będzie ono wchodziło na sprint czy nie. Bo razem ze Scrum Product Ownerem podejmujemy decyzję co do priorytetów, ale później jeszcze zespół wytwórczy musi mieć jasne wskazania co, gdzie, jak i kiedy. Z mojej strony też jest ta bezpośrednia praca z zespołem wytwórczym, bo uczestniczę w spotkaniach i wyjaśniamy sobie bardzo różne aspekty. Na pewno wsparcie analityków jest istotne, żeby wszystkie potrzeby biznesowe i techniczne rozbijać na części pierwsze. Ten zespół deweloperski o którym tutaj mówimy, to też jest taki skrót myślowy, bo tam oczywiście mamy samych specjalistów od backendu i frontendu. Są jeszcze osoby, które wykonują świetną pracę weryfikując czy wszystko to co zostało wyprodukowane ma ręce i nogi i czy spełnia nasze oczekiwania. Tych grup interesu i współpracy jest trochę, także w takim zakresie rozwój tego rozwiązania się odbywa.

Piotr:

Wspomniałeś o tym, że jest cały tabun osób zajmujących się programowaniem, bo rozwiązanie jest tworzone wewnątrz organizacji. Jak w ogóle wygląda praca osoby, która z jednej strony nadaje kierunek rozwoju systemu, a z drugiej strony ma kontakt z klientami, którzy są odbiorcami tego rozwiązania? Dodatkowo pracujesz w Departamencie Cyberbezpieczeństwa, który jest również bezpośrednim użytkownikiem tego systemu, a po drugiej stronie masz osoby, które realnie go tworzą, znają pewne ograniczenia programistyczne i wyzwania które są realizowane. Jak wygląda taka codzienna praca osoby zamawiającej z wykonawcą w jednej organizacji?

Marek:

To jest bardzo ciekawa praca, która wymaga zaufania wewnątrz zespołu, który tworzy rozwiązanie. Zaczynając chociażby od wymagań klienckich o których tutaj wspominamy, to mam jak najbardziej przyjemność rozmowy z klientami, prowadzenia jakichś warsztatów i czasami delikatnego wsparcia administratorów w konfiguracji tych usług, nie zabierając im jednak chleba, bo wykonują fantastyczną robotę. Tej pracy jest jednak czasami tak dużo, że dodatkowa para rąk zawsze się przydaje. Ale nie wszystkie aspekty związane z wymaganiami klienta przechodzą przeze mnie, bo tych przypadków jest za dużo, także muszę mieć tutaj zaufanie do zespołu Presales, który również zbiera wymagania klientów. I ta współpraca jest na pewno fajna, natomiast musi się opierać na jakimś zaufaniu. I mam nadzieję że tak jak mam do nich zaufanie, to oni też trochę tego zaufania do mnie mają i zostanie to gdzieś uwzględnione w naszych wymaganiach czy w realizacji celów. Współpraca z zespołem deweloperskim to na pewno jest też taka praca, która wymaga bezpośredniego kontaktu. Z jednej strony ja otrzymuję informacje co można zrobić i w jaki sposób lepiej, czasami są do mnie pytania w jaki sposób coś ma być zrobione żeby było bardziej optymalne i dobrze by było, żeby te pytania i odpowiedzi były wymieniane jak najszybciej i jak najsprawniej aby tego procesu nie wstrzymywać. Ten zespół wykonuje też świetną robotę i to dzięki nim tak naprawdę udało się zrobić tak wiele przez ostatnie dwa lata w tym projekcie. TAMA z listopada 2019 roku, to nie jest absolutnie ta sama TAMA, którą mamy dzisiaj. W dużej mierze jest to na pewno zasługa tego zespołu. I współpraca taka już bardziej organizacyjna, analityczna, Business Product Ownerska ze Scrum Product Ownerem. Dużo decyzji jest podejmowanych w zasadzie „on daily basis”, żeby ten projekt szedł do przodu.

Piotr:

Powiedziałeś bardzo ciekawą rzecz, a mianowicie że jest bardzo duża przepaść pomiędzy systemami TAMA 2019, a TAMA 2021. Jak często są wdrażane poprawki w tym systemie? Czy jest to kwestia patchy raz na kwartał, raz w miesiącu? Jak to wygląda w praktyce? Każda taka zmiana, to jest też mniejsza lub większa zmiana kodu, który tę aplikację napędza.

Marek:

Zabijesz mnie zaraz wzrokiem, czego nie będą widzieli słuchacze bo mamy podcast, ale ja znowu odpowiem: to zależy. Ale dobrze by było wspomnieć od czego. A zależy to trochę od tego, ile tych poprawek i ile elementów nowych funkcjonalności mamy aktualnie do wdrożenia. Produkt rozwija się dynamicznie i staramy się żeby średnio co dwa tygodnie wychodziła jakaś poprawka, zawierająca większą lub mniejszą liczbę nowych funkcjonalności, ewentualnie jakieś zmiany w systemie. Oczywiście nie zawsze jest to realizowane i nie zawsze w ten sam sposób, ale dążenie jest takie by w tę stronę iść. Przy tych zmianach trzeba też analizować potrzebę chwili. Dużą zaletą całości przedsięwzięcia jest to, że programiści są pracownikami EXATEL, czyli jeżeli mamy sytuację (bardzo hipotetyczną, ale mogącą się zdarzyć) krytyczną gdzie jakaś poprawka wymagana jest by ten system działał stabilnie w określonym reżimie SLA, to nawet w ciągu pojedynczych godzin zespół wytwórczy był podrywany, stawał na wysokości zadania i był w stanie takie zmiany w samym systemie wprowadzić i umożliwić nam – jako zespołowi bezpieczeństwa defensywnego – skuteczne działanie. Jest więc tak, że te aspekty mają zdecydowanie duże znaczenie.

Piotr:

W takim razie chciałem się Ciebie spytać, jak z praktycznego punktu widzenia oceniasz swoją pracę? Czy jest to więcej pracy zarządczej, związanej z konfigurowaniem, z przekonywaniem klientów do danego rozwiązania, czy więcej pracy związanej z wymyślaniem nowych funkcjonalności i tworzeniem? Jako Business Product Owner i osoba, która zajmuje się jednocześnie kilkoma aspektami funkcjonowania, choćby produktów bezpieczeństwa defensywnego, pełnisz wiele funkcji jednocześnie.

Marek:

To zależy od tygodnia i od aktualnych potrzeb. Mamy np. sytuację gdzie czysto hipotetycznie jesteśmy umówieni z klientem na jakieś warsztaty, mające na celu doprowadzenie do jak najskuteczniejszej konfiguracji usługi i prowadzimy dialog techniczny. Mogłoby się wydawać, że są to zadania ściśle związane właśnie z taką konfiguracją, tudzież wsparciem naszych administratorów, którzy tę usługę starają się konfigurować. W trakcie takich warsztatów bardzo często wychodzą jasne potrzeby klientów, które na pewno chcemy odnotować. Uważamy, że rozwiązanie jest elastyczne, ponieważ faktycznie bierzemy pod uwagę potrzeby klientów i staramy się je wdrażać (oczywiście z jakimś tam prawdopodobieństwem), niekoniecznie w ciągu kilku godzin, ale staram się umieszczać to gdzieś w backlogu i reagować na takie zdarzenia. Także to wymyślanie i ustalanie priorytetów, to bardzo płynna sprawa i zależna od tego, jak aktualnie wygląda sytuacja projektowa.

Piotr:

Gdybyś miał doradzić komuś, kto chciałby być Business Product Ownerem rozwiązania, które jest stworzone od zera, albo jest na takim wstępnym etapie, to co byś mu zarekomendowała? Na co zwróciłbyś uwagę? W którą stronę zwróciłbyś wzrok tej osoby, żeby być może poszło jej sprawniej, spokojniej?

Marek:

Nie wiem czy są to jakieś porady, ale z mojej perspektywy to co jest istotne, to mieć dobre wyczucie biznesowe, które pomaga podejmować wiele decyzji. Druga, jeszcze ważniejsza sprawa, to zwracanie uwagi na zespół z którym się współpracuje, bo jeśli mam iść w okopy, to naprawdę chcę być w tych okopach z ludźmi, do których mam zaufanie i którzy mają zaufanie do mnie. Mam nadzieję, że taką sytuację mamy w tej chwili. Ufam zespołom z którymi współpracuję i wierzę, że wykonują świetną robotę. Udowadniają to każdego dnia, także mam nadzieję, że każdy z członków tego zespołu ma jakieś zaufanie do mnie, że ja też podejmuję decyzje, które są na tę chwilę najsensowniejsze, by ten produkt rozwijał się dalej. Nie wiem czy to rada, ale zwracanie uwagi na zespół z którym się współpracuje, to naprawdę istotny element by ta praca dawała też satysfakcję.

Piotr:

Gdyby obecny Marek mógł spojrzeć w 2019 rok i mógł ponownie zadecydować czy podejmie się projektu rozwoju systemu anty-DDoS TAMA, to jaka by była jego decyzja?

Marek:

Podjąłbym dokładnie taką samą decyzję. Od samego początku twierdziłem że jest to bardzo ciekawy projekt i bardzo chcę w nim uczestniczyć. Co do roli którą miałem pełnić, to tutaj były jakieś decyzje do podjęcia, natomiast jak najbardziej jestem bardzo szczęśliwy i mam dużo satysfakcji z tego w jaki sposób pracujemy i co się dzieje w ramach tego projektu.

Piotr:

Bardzo dziękuję Ci za dzisiejszą rozmowę i za to, że podzieliłeś się z nami informacjami o tym jak wygląda bycie Product Ownerem rozwiązania TAMA, jak również jak wygląda ekosystem ataków DDoS, które są naszą codziennością. Naszym gościem był dzisiaj Marek Makowski, Inżynier w Zespole Bezpieczeństwa Defensywnego EXATEL. Dziękuję Ci Marku za poświęcony czas.

Marek:

Dzięki serdeczne!