W tym odcinku podcastu gości Marcin Ratajczyk, IT Security Specialist w Allegro, specjalizujący się w obsłudze incydentów i threat huntingu („niebieska strona” bezpieczeństwa).
Marcin szczegółowo omawia koncepcję „purple team” w Allegro, czyli unikalną współpracę między zespołami ofensywnymi i defensywnymi. Ta synergia pozwala na symulowanie realistycznych ataków, co znacząco różni się od tradycyjnych pentestów, i efektywnie podnosi ogólny poziom bezpieczeństwa firmy, przekładając się na konkretne ulepszenia infrastruktury i aplikacji. Dodatkowo poruszana jest kwestia ataków na deweloperów, w tym popularnych oszustw rekrutacyjnych wykorzystujących złośliwe zależności w zadaniach programistycznych, co podkreśla, że nikt nie jest odporny na phishing.
Kluczowe wątki odcinka:
- „Purple Teaming” w praktyce: Jak współpraca zespołów ofensywnych i defensywnych symuluje ataki i podnosi bezpieczeństwo w Allegro.
- Bezpieczeństwo w procesie tworzenia oprogramowania: W jaki sposób Allegro wbudowuje zabezpieczenia od wczesnych etapów developmentu, m.in. poprzez Threat Modeling i szkolenia.
- Praktyczne porady i zagrożenia dla deweloperów: Jak deweloperzy mogą dbać o bezpieczeństwo swoich stacji roboczych i na jakie ataki (np. phishing w rekrutacji) powinni uważać.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof: Witamy, jest z nami Marcin Ratajczyk, jest też Andrzej i jestem ja. Bardzo Ci miło Marcinie powitać w naszym podcaście.
Marcin: Dzięki za zaproszenie, witam Andrzej, witam Krzysztof i witam wszystkich słuchaczy i oglądających ten odcinek.
Krzysztof: Marcin, security specialist obecnie w Allegro, jedna z większych organizacji jeżeli chodzi o IT w Polsce. Wcześniej też całkiem fajne i bogate doświadczenie, za dwa lata pyknie dziesiątka. jeżeli chodzi o Twój experience w IT, ale myślę, że najlepiej będzie jak przedstawisz się słuchaczom sam i powiesz czym się obecnie zajmujesz, bo to Twoje doświadczenie pewnie skakało i tych obszarów, które dotkałeś w IT było co najmniej kilka.
Marcin: Tak, obecnie moją rolą to jest IT Security Specialist w Allegro, jestem odpowiedzialny za obsługę incydentów, jeżeli ktoś postrzega IT Security w ramach kolorów to ta niebieska strona rozwiązywania incydentów szeroko pojęty threat hunting pisanie reguł w różnych systemach tak żeby być na bieżąco ze wszystkimi zagrożeniami. i tak na obecnie 8 lat doświadczenia to zdecydowanie więcej bo 7 to przypada na typową obsługę incydentów i właśnie wspomniany wcześniej threat hunting.
Krzysztof: Czyli blue team w serduszku a dusza red teamera.
Marcin: Inaczej, blue team w serduszku, jak najbardziej, ale podejście takie bardziej fioletowe, o z kolei.
Andrzej: To mógłbyś wytłumaczyć na szybko. to podejście fioletowe?
Marcin: Oczywiście, ja pracuję w zespole po prostu powiedzmy niebieskim, czyli tym defensywnym, odpowiedzialnym za obsługę incydentów, szeroko pojęty threat hunting, ale oczywiście też w Allegro, w miejscu, w którym obecnie pracuję, mamy zespół ofensywny, oni z kolei zajmują się testowaniem naszej infrastruktury, aplikacji i wszystkich rzeczy związanych z technologią i po prostu tak zwany purple teaming, to jest takie podejście, że te dwa zespoły współpracują ze sobą tak, żeby na końcu mamy wspólny cel, żeby podnieść po prostu bezpieczeństwo całej firmy i po prostu symulujemy sobie takie Można powiedzieć testy, że oni próbują coś osiągnąć swoimi ofensywnymi metodami, a my próbujemy albo im to uniemożliwić, albo ich wykryć na jak najwcześniejszym etapie. I właśnie o to mi chodziło mówiąc o tym fioletowym podejściu.
Krzysztof: Jakie są efekty, które wynikają z takiego ćwiczenia purple teamingowego? Są jakieś zalecenia, które potem taka organizacja, w której ty pracujesz, wdraża? Jak to potem finalnie wygląda?
Andrzej: Tutaj jeszcze dopowiem do tego pytania, bo myślę, że sporo osób z IT kojarzy taki zwykły test penetracyjny, gdzie na wejściu mamy jakiś zestaw systemów do przetestowania, a na wejściu mamy raport z podatnościami. Czym w takim wypadku się to różni od takiego ćwiczenia purple teamingowego czy red teamingowego?
Marcin: Tak, to jest akurat tym testem penetracyjnym, to jest bardzo dobry przykład, bo faktycznie na końcu często możemy, czy to sami wygenerować, czy otrzymać od takich filmów taki suchy raport, który tam jest ładnie zaznaczony kolorkami, że czerwony to źle, zielony to dobrze, ale mało co z tego wynika. Kwestia przeprowadzania takich testów polega też na tym, że nie każdej podatności czy nie każdemu niepożądanemu działaniu przypiszesz numerek CVI czy jesteś go w stanie sklasyfikować tym bardziej że my mamy podejście takie właśnie fioletowe czyli ten purple teaming ale też korzystamy oczywiście z jakby to powiedzieć pomocy firm zewnętrznych żeby też rzuciły swoim zewnętrznym, fachowym okiem. i kwestia jest taka, że na koniec to jak naprawdę jest zrobiony raport, potykamy się, jest robiony raport i są konkretne zalecenia dla konkretnych zespołów, czyli np. to musimy powiedzmy w graciu aktualizacji, bo idzie w gracie aktualizacji, bo jest takie coś zrobione, a w tym przypadku np. musimy ograniczyć dostęp do jakiegoś systemu, bo dostęp jest za szeroki albo nie wszystkie osoby powinny mieć taki poziom dostępu. to jest naprawdę bardzo dużo takich zaleceń. oczywiście nie wszystkie zalecenia jesteśmy w stanie zrobić sami jako zespół IT Security czy to ten ofensywny czy defensywny. dlatego też często po takich testach współpracujemy z administratorami danych rozwiązań i pomagamy im w to wdrożyć. bo też nie zawsze jakby to powiedzieć Administratorzy są od tego, żeby systemy działały. Oni też nie zawsze do końca rozumieją, że dla nas bezpieczeństwo jest priorytetem, bo w nim pracujemy. Dla nich jest priorytetem to, żeby dana usługa działała. I teraz musimy znaleźć taki złoty środek, żeby było i bezpiecznie, i żeby było zachowane tak zwane SLA, czyli ciągłość działania.
Krzysztof: Powiedz Marcin, czy ten Purple Teaming wpływa jakoś na pracę deweloperów? Jak to wygląda? Czy zalecenia wynikające z tego Purple Teamingu, właśnie tak jak powiedziałeś o tym SLA dla administratorów, dla ciągłości trwania jakiejś usługi, czy też ma to jakieś przełożenie na realną pracę w developmencie?
Marcin: znaczy to jest dobre pytanie i tu byście musieli zaprosić jakiegoś dewelopera od nas firmy. ale tak patrząc z punktu widzenia zespołu security to oczywiście zespół ten ofensywny o którym już wspominałem. on często prowadzi konsultacje dla deweloperów w ramach jakichś projektów jak zrobić to bezpiecznie. ma też uruchomiony proces tak zwanego trend modelingu czyli już na etapie projektowania danego rozwiązania danej aplikacji to już przykładowo deweloper jest w stanie określić jakie są potencjalne ryzyka tak żeby później właśnie ta aplikacja była w 100% może nie w 100% ale w bardzo dużym procencie bezpieczna i żeby właśnie później zespół niebieski nie musiał reagować na incydent. to też jest taka bardzo wczesna. No i oczywiście mamy też program bug bounty, jest program bug bounty publiczny, z którego każdy może skorzystać.
Andrzej: Ja tutaj nadmienię, że o ile kojarzę to Allegro było gdzieś tam jednym z pierwszych filmów, które chyba otwierały taki publiczny bug bounty w Polsce. Znaczy to nie dziwi bo Alegro jest chyba największą firmą taką inżynieryjną.
Marcin: Jakby na to popatrzeć to tak z jednej strony to takim software housem faktycznie jesteśmy bo deweloperów mamy dużo tego oprogramowania się wytwarza i tam jest faktycznie miejsce i na konsultacje i na program backbounty.
Andrzej: Więc tak przodownicy pracy w Polsce chyba za bardzo nie ma. jak ktoś już działa w Alegro to potem możesz chyba tylko pójść do jakichś fangów. nie bo to.
Marcin: Trzeba by było bardzo dokładnie prześledzić ścieżki deweloperów, którzy już np. w Allegro nie pracują. Tak na to pytanie nie odpowiem, ale faktycznie, jeżeli ktoś ma w CV Allegro, to faktycznie jest to mocny gracz. Tak, jak najbardziej mocny gracz i myślę, że dużo widział jak pracował w Allegro, w developmencie, ale myślę, że nie tylko w tej dziedzinie.
Krzysztof: Wspomniałeś wcześniej o modelowaniu zagrożeń. Powiedz, czy ty też bierzesz udział w tych ćwiczeniach jako blue teamowiec, czy tylko przyglądasz się gdzieś z boku?
Andrzej: Ja tutaj doprecyzuję, dlatego, że modelowanie zagrożeń to jest taki proces, który można realizować właśnie w tej działce inżynierii w developmencie. Powiedzmy mamy sprint, chcemy pracować nad nowym featurem, to możemy sobie odpalić sesję modelowania zagrożeń i spróbować przewidzieć co może pójść źle. Ale można też to robić właśnie już w takim bardziej klasycznym bezpieczeństwie, no przykładowo pod kątem jakiejś infrastruktury, czyli właśnie blue team’owcy też mogą robić. I technicznie proces jest podobny, no bo i tu i tu robimy modelowanie zagrożeń, ale no niejako operujemy na trochę czymś innym, mamy też inne spojrzenie na systemy i można powiedzieć wysokość tego spojrzenia jest inna. I teraz, czy po pierwsze, czy miałeś okazję kiedykolwiek brać udział w jakiejś sesji modelowania zagrożeń, czy raczej ty się skupiasz głównie na fret huntingu, na blue teamie i to nie chodzi mi tu o twojego obecnego pracodawcę, tylko w ogóle w twojej karierze.
Marcin: Sam proces trety modelingu, o którym wspomniałeś, powstał z inicjatywy, jest obsługiwany w ramach tego zespołu ofensywnego i on właśnie powstał po to na tak wczesnym etapie, żeby przykładowo zespół niebieski, czyli zespół Cessir, w którym pracuję, No nie musiał reagować, bo lepiej od razu zapobiegać takim sytuacjom niż później obsługiwać, bo wiadomo to jest duża organizacja i obsługa incydentów w tak dużej organizacji to też nie jest powiedzmy to bułka z masłem, więc po co został ten proces wdrożony? Tak żeby właśnie, jakby to powiedzieć, żebym ja nie miał za dużo pracy, co świadczy tylko dobrze o tym procesie thread modelingu, ale jeżeli chodzi o sam proces thread modelingu, to nie brałem w nim udział.
Andrzej: Pytałem, bo w zasadzie masz dość, trochę tych firm w CV masz, większych, w sumie same, więc być może brałeś też udział w innych firmach. firmach, ale mówisz, że nie. OK, klasycznie raczej nie biorą udział osoby w Twojej roli. Raczej właśnie to jest proces typowo albo takiego ofensywnego bezpieczeństwa, albo no deweloperów czy security championów.
Marcin: Dlatego właśnie to jest w tym zespole czerwonym, bo tutaj faktycznie występuje taka silna relacja między deweloperami a zespołem ofensywnym. Też oczywiście deweloperzy akurat w Allegro. bo Allegro to jest taki pracodawca, który faktycznie, znaczy w moim CV, który przy okazji może być definiowany z waszej perspektywy słuchaczy tego kanału jako właśnie trochę taki trochę taki software house, więc tak tamta zażyłość jeżeli chodzi o deweloperów i zespoły zespołu ofensywnego jest zażyła i też oczywiście Non-stop prowadzone są konsultacje nad danymi projektami, oczywiście z perspektywy bezpieczeństwa i też cyklicznie odbywają się szkolenia dla deweloperów. Chociażby słynne OWAS Top 10 to też tak jak najbardziej. Każdy deweloper może, jak tego nie zna, to może się zgłosić do tego zespołu i zostać praktycznie, bo to nie chodzi o to, żeby teorię kogoś zasypać linkami, tylko praktycznie zostać przeszkolony w ramach wewnętrznego szkolenia.
Krzysztof: Ja odbiję trochę od tego tematu. W ostatnich latach intensyfikują się działania mające na celu wejście do jakiejś organizacji poprzez deweloperów. Nie mówię tutaj stricte o sytuacji, w której wykorzystywane są osoby pracujące w bardziej miękkich działach HR-owych czy księgowości. Tylko wykorzystujemy tutaj tych naszych technicznych inżynierów i to przez ich komputery, przez ich stacje robocze dostajemy się m.in. do środowisk CI czy do usług cloudowych. I z Twojej strony jako Blue Teamowca powiedz mi co mógłbyś poradzić Takiemu początkującemu deweloperowi, który chce zadbać o bezpieczeństwo swojej końcówki, swojej stacji roboczej.
Marcin: No to tak, przede wszystkim kwestia aktualizacji i oprogramowania frameworków, z których korzystacie. Myślę, że od tego należy zacząć, bo jednak nie bez powodu te wszystkie CVE się pojawiają. Bardzo często jest tak, jeżeli nie jest to oczywiście jakaś krytyczna podatność, że można to zaktualizować. i tak szczerze mówiąc to takie mityczne twierdzenie że nie zaktualizuje bo po drodze rozsypie mi się projekt. ja się osobiście z taką sytuacją nie spotkałem. przynajmniej nie znam takiego dewelopera który by faktycznie jakby to powiedzieć przeżył taką sytuację, a nie tylko słyszał ją od osoby trzeciej. To jest jedna rzecz, a po drugie to kwestia, jakby to powiedzieć, uprawnień. Oczywiście, jeżeli macie dostęp do, jakby to powiedzieć, nadawania sobie uprawnień na własnej stacji, no nie wszystko musi być wykonywane z, jakby to powiedzieć, sprawami administratora. Czasami warto najpierw sprowadzić zwykłego użytkownika i dopiero później się zastanawiać nad eskalacją uprawnień, bo w przeciwnym razie ktoś za was eskaluje te uprawy, nie?
Krzysztof: Ale ale jak to tak jest sudo.
Andrzej: ale po co? po prostu działasz na koncie ruta i przynajmniej szybciej nie trzeba pisywać haseł nic o nic nie krzyczę.
Marcin: to jest taka naturalna naturalna ludzka właśnie można powiedzieć podatność trochę takie. nasze lenistwo, doskonale to rozumiem. powiem tak, nie będę udawał świętszego niż jestem, też czasami zdarza mi się popełnić jakiś prosty błąd ale mówię, jakbym miał dawać takie wskazówki. to aktualizacje i zastanawianie się czy do każdego do każdego działania potrzebny jest mi ród czy administrator w zależności od systemu w którym działać.
Krzysztof: Ja myślę, że ta kwestia patch managementu, szczególnie u osób, które są wysoko uświadomione w kierunku właśnie engineeringu, te osoby mają takie przeświadczenie, że mnie to nie dotyczy. Ja się nie dam. Ja jestem za mądry na to, żeby to mogło mnie jakoś objąć. A w ostatnich latach widzę, że coraz więcej tych ataków polega na tym, żeby jednak wbić się przez maszynę dewelopera. Szczególnie takiego, który uważa, że go ten problem nie dotyczy.
Marcin: I właśnie a propos tego, że jest takie myślenie, że ten problem mnie nie dotyczy, bo jestem super seniorem, to też pokazuje jak te ataki się zmieniają, bo o ile, jakby to powiedzieć, przeciętnego użytkownika internetu można nabrać mailem phishingowym, że wygrałeś voucher do tego i tego sklepu, tylko wpisz tutaj
Krzysztof: wszystko
Marcin: swoje znane. To jest jedno, ale w przypadku takich bardziej uświadomionych użytkowników też bardzo częstym wektorem jest tak zwany atak na rekrutację. Ktoś zaprasza Cię na rekrutację, ale podsyła swój instalator danego komunikatora. albo słuchaj, może poanalizujesz coś z nami. i nagle podsyłają próbkę, która jest do analizowania, a jednak się okazuje, że ona jeszcze robi coś więcej niż powinna robić. To jest też takie idealne pokazanie, że na phishing nabierają się wszyscy, Tak, fajnego kontekstu.
Krzysztof: My z Andrzejem w jednym z odcinków naszych podcastów opowiadaliśmy o historii, w której deweloperzy byli nabierani na fałszywe rozmowy rekrutacyjne i zadanie rekrutacyjne było udostępniane normalnie przez GitHuba. i cały szkopuł tkwił w tym, że w tym repozytorium To był bodajże Python, więc paczki brano z PyPI. Jedna z tych paczuszek była po prostu zainfekowana, więc jeżeli chciałeś odpalić to zadanie rekrutacyjne, więc musiałeś sobie postawić całe środowiska, zaciągałeś zależność, która była złośliwa, która po prostu była klasycznym infostillerem, więc…
Marcin: Jak robiłeś to na swoim komputerze właśnie z uprawnieniami administratora, to… Można powiedzieć, że jest po temacie, tak swoją drogą. Też warto by mieć do takich rozmów, jak już bierzemy udział w takich rozmowach, jakieś odizolowane środowisko, żeby, bez naszych danych oczywiście, bo jak pokazuje przykład, który przed chwilą przytoczyłeś, no jakby to powiedzieć, ja wiem o tych atakach na rekrutację i ty wiesz i pewnie coraz więcej osób wie, więc też prośba do specjalistów, wy też musicie być świadomi.
Andrzej: Tak, to lepiej się nie dowiadywać na własnej skórze.
Marcin: Dokładnie.
Krzysztof: Ja z pytań do Marcina się już wystrzelałem, nie wiem. Andrzej czy chciałbyś jeszcze coś poruszyć?
Andrzej: Ja chciałbym wrócić jeszcze do tego atakowania organizacji przez deweloperów, ale nie chodzi mi teraz tylko o deweloperów tylko ogólnie przez narzędzia deweloperskie. Czy jako ekspert w temacie zaobserwowałeś, widzisz jakiś trend? No bo my z różnych raportów widzimy wzrost tego trendu i przez narzędzia deweloperskie mam na myśli wejście do organizacji np. przez potok CICD. albo wejście na maszynę dewelopera, ale właśnie nie przez taki zwykły phishing, tylko przez już taki bardziej wysublimowany typu właśnie zadanie rekruterskie, czyli gdzieś ten komponent taki inżynierski jest tego jakiegoś ataku. i czy widzisz, czy obserwujesz, czy w ogóle po prostu ogólnie na rynku można zaobserwować, no właśnie te ataki na potoki CICD, czy na narzędzia, które typowo są w typowym tu secie deweloperów.
Marcin: znaczy powiem tak takiego trendu wyraźnie wybijającego się poza inne wektory ataków. to nie zauważam ale jak najbardziej jest to jakby to powiedzieć wektor ataków który należy mieć na uwadze. a tak naprawdę jakby to powiedzieć? oczywiście nie mam żadnego raportu teraz żeby przytoczyć ale myślę że jeżeli ktoś jest deweloperem rozważa tą ścieżkę deweloperską no to powinien o takich jakby to powiedzieć zagrożenia ich wiedzieć w ramach, jakby to powiedzieć, samoświadomości takiej higieny swojej pracy, no bo inaczej, tak jak mówicie. można zaatakować dewelopera a na przykład zupełnie inaczej można administratora serwera zaatakować. więc jakby to powiedzieć poziom ryzyka i poziom takiej akceptacji tego czy my jesteśmy na coś podatni czy nie wynika z narzędzi których używamy. i tak naprawdę wracamy do punktu z aktualizacjami że też te narzędzia często jakby to powiedzieć to nie są narzędzia napisane przez nas albo przez jednego dewelopera któremu pomaga drugi deweloper i są po drugiej stronie globu. często te narzędzia mają swoje jakby to powiedzieć działy pomocy społeczność więc myślę że warto tam raz na jakiś czas zaglądać. a jeżeli jest taka możliwość i się zdecydujecie no to też powiedzmy te narzędzia na pewnym etapie mogą tą pracę jakby to powiedzieć czy tam nawet aktualizację zautomatyzować. więc to też jest bezbolesne. i też widzę że w przypadku różnego rodzaju narzędzi nie tylko dla deweloperów to wszystko idzie w takim jakby to powiedzieć stawia na wysokim poziomie user experience tak żeby faktycznie deweloper zajął się tylko swoją pracą a nie musiał poświęcać czas na właśnie rzeczy związane typowo z konfiguracją albo jeszcze żeby sobie wziął jedną trzecią etatu jako specjalista od IT security.
Andrzej: Tak tak no to to to to świetna rada. to chyba to chyba ma taką nazwę bezpieczeństwo operacyjne nie OPSEC.
Marcin: Tak, OpSec. Zgadza się. Znaczy ciekawsze są OpSec faile, ale to nie życzę nikomu.
Andrzej: Tak, OpSec faile są zawsze najciekawsze, ale znowu wtedy, kiedy przydarzają się innym, nie nam.
Marcin: Lubimy o nich słuchać, nie lubimy uczestniczyć. To się zgadza.
Krzysztof: Ja myślę, że o OpSec failach to zupełnie nowy odcinek.
Andrzej: dałoby radę tutaj nakręcić. Właśnie, tutaj to może jest pomysł na jakiś osobny odcinek pogadania o obsekfejlach.
Marcin: Osobną serię nawet.
Andrzej: No w zasadzie, w zasadzie tyle ich jest na przestrzeni lat, że można całą serię walnąć. Dobrze, z mojej strony to wszystko.
Krzysztof: Z mojej również. Dziękujemy ci bardzo Marcinie za twój czas, no i trzymamy za słowo z tymi obsekwailami.
Andrzej: No właśnie, bo tutaj idzie wciągniemy.
Marcin: Powiem tak, jak się spodoba, odbiór będzie pozytywny, można myśleć. Dzięki jeszcze raz.
Krzysztof: Dzięki wielkie.
Marcin: Na razie. Cześć.