W tym odcinku podcastu gościmy Jakuba Domareckiego, Senior Cloud Security Engineer z firmy Egnyte, który dzieli się swoją niezwykłą ścieżką kariery. Jakub opowiada, jak doświadczenie ze stażu w marketingu oraz wieloletnia praktyka w brydżu sportowym – zarówno jako zawodnik, jak i instruktor – pomogły mu w rozwoju w cyberbezpieczeństwie, ucząc strategicznego myślenia i efektywnej komunikacji. Dowiemy się, jak incydent WannaCry i postać Marcusa Hutchinsa zainspirowały go do wkroczenia w świat bezpieczeństwa IT.
W podcaście:
- Nietypowa Ścieżka Kariery i Znaczenie Umiejętności Miękkich: Jakub podkreśla, jak jego doświadczenia spoza IT, takie jak brydż sportowy, rozwinęły umiejętności strategicznego myślenia i komunikacji, które okazały się kluczowe w cyberbezpieczeństwie. Podkreśla również znaczenie znajomości języka angielskiego w branży, nawet przy początkowo ograniczonym doświadczeniu technicznym.
- DevSecOps w Chmurze i Koncepcja „Guardrails”: Rozmowa zagłębia się w praktyczne aspekty DevSecOps w środowiskach chmurowych, ze szczególnym uwzględnieniem „guardrails”. Te mechanizmy zapobiegają błędom bezpieczeństwa na wczesnych etapach developmentu, minimalizując ryzyko i skracając pętlę informacji zwrotnej dla deweloperów.
- Rola Product Security Inżyniera i Zarządzanie Podatnościami: Jakub dzieli się swoją perspektywą na rolę Product Security Inżyniera, która wymaga łączenia wiedzy technicznej z kontekstem biznesowym. Omówione jest również narzędzie Defect Dojo do efektywnego zarządzania podatnościami, co jest kluczowe dla utrzymania wysokiego poziomu bezpieczeństwa aplikacji.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzisiaj gościmy Jakuba Domerackiego, Senior Cloud Security Engineer z firmy Egnyte. Jakubie, witam w naszym programie. Od czego chciałbym zacząć? Ja chciałbym zacząć od tego, że masz bardzo ciekawe, oryginalne doświadczenie i jeszcze nie będę wskakiwał w tą taką wisienkę na torcie w tym doświadczeniu, ale zacznę od samego początku, który masz przynajmniej wpisany na Linkedinie, bo ty masz tam wpisany, że zajmowałeś się marketingiem.
Jakub: Tak jest. Po pierwsze dziękuję za zaproszenie. Ten krótki epizod to był staż, który załatwiła mi mama, którą pozdrawiam z tego miejsca. I podczas tego stażu, miałem wtedy 18 lat, pomagałem z po pierwsze przesyłkami, ale zajmowałem się też bazą danych, czyli można powiedzieć, że było to doświadczenie zakrawające o pracę informatyka. Polecam firma Albedo Marketing, darmowa reklama. Nie mam o wiele więcej do powiedzenia, bo już nie do końca pamiętam, jakie były szczegóły tych moich zadań, ale doświadczenie było bardzo pozytywne.
Krzysztof: Czyli taki one-man army.
Jakub: Tak, chłopak na posyłki.
Andrzej: No nic, ktoś musi robić tą. nazwijmy to czarną i brudną robotę. Ale teraz wchodzimy do tej wisienki, bo faktycznie ten marketing to był taki dość krótki romans, ale potem masz w zasadzie kilka lat działalności wokół brydża. Tak jest. Powiedz trochę o co chodzi z tym brydżem, bo to chyba nie tylko jako zawodnik, tylko też instruktor. generalnie jakoś tam działałeś mocniej.
Jakub: Tak. Zacznę od początku. W wieku 14-15 lat byłem mocno zainteresowany informatyką. Były to sieci komputerowe plus jakieś podstawy programowania w C++. Pamiętam, że wraz z zespołem braliśmy wtedy udział w takim turnieju Dialnet Masters organizowany przez Dialog Telekom. Jeszcze wtedy istniał. No i wydawało się, że w tej informatyce już wtedy zostanę. ale nasz profesor, nauczyciel fizyki, pan Jan Sibilski, który założył w 2004 roku klub UKB z Dąbrówka Poznań, organizował po prostu zajęcia z brydża sportowego. I ja jako jedna z 20 osób z klasy w tych zajęciach brałem udział. No i tak zaczęła się moja przygoda z brydżem, która trwała, trwa nieprzerwanie tak naprawdę, ale już w o wiele mniejszym stopniu aktywnie. Pierwsze parę lat przede wszystkim grałem. Graliśmy na zawodach przede wszystkim krajowych. Olimpiada sportów umysłowych, Mistrzostwa Polski Juniorów. A w 2015 roku zacząłem uczyć wewnętrznie w ramach klubu młodszych zawodników. co ostatecznie przerodziło się w pierwszą taką przygodę zawodową z prowadzeniem kursów w ramach szkoły nauka Brydża.pl. Tutaj z tego miejsca dziękuję braciom Jasem za zaufanie. Byłem wtedy dosyć młodą osobą, a prowadziłem kursy dla dorosłych. Było to świetne doświadczenie, nauczyło mnie po pierwsze jak wchodzić w interakcję z ludźmi, a przy okazji sprawiło, że lepiej zrozumiałem podstawy gry, ponieważ były to osoby początkujące. Ja już wtedy miałem kilka lat doświadczenia jako zawodnik, ale nic tak nie uczy jak nauka początkujących. Pytania, które zadawali sprawiały, że musiałem na nowo tak naprawdę poznać te fundamenty i to ze mną zostało po tym doświadczeniu.
Andrzej: Tak, czyli ja mam dokładnie takie same doświadczenia, że nauka, szczególnie właśnie osób początkujących, zmusza nas do ugruntowania swoich własnych fundamentów, do niejako rewizji tych zakamarków, które gdzieś tam przejmujemy wcześniej za jakiś pewnik. I to pomaga nam samym, bo jak lepiej rozumiemy fundamenty, to potem tak naprawdę te wyższe warstwy zaczynają się lepiej w taką większą całość układać. Ja nie wiem czy wiesz, ale nie jesteś jedyną osobą, która gra w bridge’a w polskim security, bo mamy takiego gościa, Rafał. Teraz nie mogę sobie do końca przypomnieć. Martu? Nie, nie Martu. Ale na pewno Rafał. I Rafał pracował ze znaną polską badaczką Joanną Rudkowską. I Rafał Wojtczuk, Rafał Wojtczuk. I Rafał Wojtczuk to w ogóle jest taki kot. On znalazł tyle podatności takich niskopoziomowych w Hypervisorach, w Kernelu. Nawet miał taką jedną podatność, którą znalazł. Ona była w wielu systemach operacyjnych, ma taka cross podatność, przy czym została 10 lat wcześniej odkryta w Linuxie, w Linuxie została załatana, ale w tych innych BSD nie została załatana. Więc Rafał Wojtczuk to jest mega kok i też gra w Brydża i tam jest jakimś takim dobrym, dobrym zawodnikiem. z tego co tam kiedyś patrzyłem.
Jakub: Muszę to zweryfikować, mamy taki centralny system tak zwany MSC Cezar, także wpiszę i zobaczymy co mi wyskoczy.
Andrzej: Ok, a czy ten system jest publiczny?
Jakub: On jest publiczny. Każdy zawodnik w ramach Polskiego Związku Brydża Sportowego, który ma aktywną licencję po dwa tysiące którymś roku jest w tym systemie, także sprawdzę to.
Andrzej: To sprawdźcie Rafała. Ja myślę, że on tam jest gdzieś na górze, bo to jest dobry…
Jakub: Dobry zawodnik.
Andrzej: Dobry zawodnik. Myślę, że jest równie dobry w brydża jak w security. Ale wracając do naszego głównego tematu. W pewnym momencie przestałeś zajmować się brydżem jakoś mocniej. Tak. No i wskoczyłeś w security. Jak to się wydarzyło?
Jakub: W trakcie studiów na Politechnice Poznańskiej zacząłem studiać w 2015 roku na kierunku bioinformatyka. Tam odnalazłem się dobrze w tej części politechnicznej, nie do końca w tej biologiczno-chemicznej na UAM-ie. Także stwierdziłem, że czas zakończyć tę przygodę i poprawiłem maturę z matematyki, poszedłem na informatykę. Miałem taki wybór, coś trzeba będzie ze sobą robić zawodowo. Czy będzie to Brydż? Nie byłem na tyle dobrym zawodnikiem, żeby na Brydżu zarabiać jako gracz. Jeśli chodzi o prowadzenie kursów, to o ile było to bardzo fajne zajęcie dla studenta, to długoterminowo też siebie nie widziałem w tej roli. Także zastanowiłem się, co chciałbym robić w ramach szeroko pojętej informatyki. No i pamiętam jak dziś, że miałem za zadanie napisać artykuł na angielski o jakimś wydarzeniu ze świata IT. No i padło wtedy na bardzo znaną sprawę WannaCry, gdzie Marcus Hutchins jako solo bohater był w stanie tak naprawdę zatrzymać tę kampanię ransomware, która wtedy zatrzymała ileś szpitali w UK w ramach NHS. I po opisaniu tej historii stwierdziłem, wow, jest taki jeden gość i połapał się, że Command and Control tam była jakaś domena, już szczegółów nie pamiętam, i że jeden facet był w stanie mieć taki wpływ pozytywny na świat. Oczywiście… To gdzieś taką romantyczną zasiało myśl. No i gdzieś na początku 2019 roku podszedłem do tematu tak na poważnie. Po prostu we własnym zakresie zacząłem się uczyć. I tu mogę chwilę o tym opowiedzieć, jak taka nauka na tamten moment wyglądała. Mając dosyć ograniczoną wiedzę, stwierdziłem, że zacznę od tego, co poznałem wcześniej. To znaczy wtedy jeszcze mówiło się sporo o certyfikatach od Cisco. Także zrobiłem jakieś kursy pod CCNT, tego od certyfikatu już nie ma, to jest Cisco Certified Technician z tego co pamiętam oraz CompTIA Security Plus jako taki no-brainer. Do tych egzaminów ostatecznie do nich nie podchodziłem, bo szkoda im było pieniędzy na tamten moment, ale z tym zalążkiem wiedzy zacząłem po prostu się zgłaszać na staże. No i tutaj historia tego jak dostałem się na staż do GSK. Też jest ciekawą historią, mogę o niej opowiedzieć jeśli mamy na to chwilę.
Krzysztof: Ja mam takie pytanie, jak pomogło ci twoje Jakub doświadczenie z Brydża w kontekście kroczenia właśnie w CyberSec?
Jakub: OK, no i tutaj płynnie przejdziemy do tego, jak się dostałem faktycznie do tego GSK. Mój poziom wiedzy na tamten czas określa, określiłbym jako novice, tak dwa na dziesięć. I pomimo, że moje CV wyglądało pewnie na papierze całkiem fajnie, co znaczy, że studiuję informatykę, mam już jakieś tam doświadczenie zawodowe, angielskie i tak dalej. No to byłem w dwóch procesach rekrutacyjnych. Jeden to był właśnie w ramach firmy GSK, a drugi już dokładnie nie pamiętam jaka to była firma. I w tym procesie w GSK pierwsze stanowisko, na które się rekrutowałem, pierwszy staż w ogóle nie był w Cyber Security. To było stanowisko, w którym zarządzało się Windows Serverami. no czyli umówmy się, nie jest to bardzo sexy zajęcie. I na tej rozmowie menadżer, któremu dziękowałem wielokrotnie potem za to, zauważył, że o ile jakieś te podstawy informatyczne mam solidne, to nie do końca interesuje się tym obszarem zarządzaniem serwerami i po prostu wewnętrznie w ramach firmy przekierował informację, że jest taka osoba zainteresowana bezpieczeństwem. I po paru miesiącach, już nie spodziewając się tego, dostałem po prostu zaproszenie na kolejną rozmowę. I to już była rozmowa do zespołu Application Security Testing. Zespół, który zajmuje się takim wewnętrznym procesem testowania aplikacji mikroserwisów pod kątem właśnie, no… szeroko pojętego bezpieczeństwa, trochę compliance’u plus część techniczna. No i tam na rozmowie, poza tym, że byłem komunikatywny i miałem dobry angielski, to mogę przyznać, że nie wiedziałem zbyt wiele. Miałem taką znaną wpadkę, zostałem spytany czym jest routing, nie routing. No ja tak mówię routing, no sieciowo oczywiście poszedłem na temat, a tu chodziło jailbreaking mobilek, także iOS-a przede wszystkim. No, nie wiedziałem zbyt wiele, ale miałem dobry angielski. i tak sobie teraz właśnie po latach mówię, że dzięki mamo za to, że mnie na ten angielski zapisałaś bardzo wcześnie. Dostałem się na staż i zacząłem się uczyć, no bo kwestia przejścia rozmowy to jedno, ale idąc do zespołu, który się zamówił o bezpieczeństwo aplikacji, no wypadałoby się trochę dowiedzieć i tutaj to była nauka przede wszystkim we własnym zakresie.
Andrzej: Ja tutaj dodam jedną uwagę do tego, co powiedziałaś, do tego tematu języka angielskiego, bo to jest wątek, który się przewija w rozmowach z wieloma ludźmi, które ja gdzieś tam mam prywatnie, a w moim życiu też to widzę. Angielski jest bardzo dużym, no w angielsku by się powiedziało, edżem, tak? Bardzo, bardzo mocno pomaga w momencie, kiedy nawet jeżeli nie do końca mamy umiejętności techniczne, to sama umiejętność języka angielskiego może przeważyć, czy dostaniemy się na jakąś rolę, czy nie, a już pomijając to, czy się dostaniemy na jakąkolwiek rolę, czy nie dzięki angielskiemu, no to jednak angielski jest potrzebny, żeby po prostu w najzwyczajniejszym świecie konsumować treści techniczne, które są w większości po angielsku, więc ten angielski musi być na co najmniej dobrym poziomie, a im lepiej tym więcej wartości będziemy zbierać po tym.
Krzysztof: Tak, ja wam powiem, kojarzy mi się taka historia jeszcze z czasów Bollywoody, gdzie na otwarciu chyba rektor powiedział, dziekan wydziału powiedział, że wiecie co, angielski to nie jest język obcy tutaj na tym wydziale. To jest nasz język po prostu takiego pierwszego użycia i tego się trzymajmy, panowie.
Jakub: Pełna zgoda. Tu tylko mogę dodać, że akurat ta rola, na którą trafiłem, była taka semitechniczna i tamta komunikacja przede wszystkim w języku angielskim z różnymi wewnętrznymi klientami z całego świata, bo GSK jest firmą globalną, to po prostu był warunek konieczny. To nie był warunek wystarczający, ale konieczny.
Andrzej: Dokładnie. No i na tym skorzystałeś. Ja mam jedno pytanie takie bardziej specyficzne, bo Kojarzę, że chyba masz doświadczenie z takim narzędziem Defect Dojo.
Jakub: Tak jest.
Andrzej: To powiedz mi, czy byłeś zadowolony z tego narzędzia? Nie chodzi o użycie, ale jeżeli używałeś komercyjnie, to czy to narzędzie według ciebie zdaje egzamin? Dla słuchaczy dodam, że Defect Dojo jest narzędziem, które agreguje podatności z różnych skanerów, pozwala nam po prostu zarządzać podatnościami, tak zwanym vulnerability management. Jest to narzędzie darmowe, możemy sobie postawić swojego własnego defect dojo, no ale jak ze wszystkim, jeżeli coś jest darmowe, to niejako praca schodzi, ceduje się trochę na nas. I powiedz mi, czy, czy, jak miałeś doświadczenia z defect dojo?
Jakub: Ok, ja jako świeżak w tym 2019 roku, jak wdrażaliśmy to w ramach naszego zespołu, to jest w ogóle projekt open source’owy, ale ze wsparciem. Tam jest opcja, z tego co pamiętam, pan nazywa się MateZauro, nawet mieliśmy z nim pewne spotkania, takiego wsparcia płatnego. Ja zostałem w ramach zespołu poproszony o zrobienie integracji pomiędzy tym narzędziem, a ówcześnie stosowanym w firmie systemem ticketowym. I te moje podstawy Pythona wystarczyły, żeby nie elegancko, ale skutecznie jakoś ze sobą skleić te dwa systemy. Jeśli chodzi o sam Defect Dojo, wiem, że jest to dosyć kontrowersyjny projekt, Po czasie okazuje się, że utrzymanie tego kosztuje więcej niż zysk, który się wynosi z tego rozwiązania, ale ja długo nie miałem okazji z nim pracować, a jako, że byłem osobą naprawdę świeżą, to nie miałem też porównania. Także na tamten moment wydawało mi się to bardzo fajne. Po czasie na pewno nie jest to tak, że mamy coś za darmo i tyle, tylko wdrożenie i utrzymanie kosztuje.
Andrzej: Dokładnie, to tak myślałem, że to pójdzie w tym kierunku, bo ja generalnie też mam takie doświadczenia komercyjne z Affect Dodge’u i nie tylko z Affect Dodge’u, w ogóle z narzędziami, które są darmowe. w cudzysłowie, że jeżeli coś jest darmowe to spoko możesz tego używać, ale w takim wypadku będziesz płacił swoim czasem, swoją uwagą i we wdrożeniu i potem w utrzymaniu. I potem pytanie jest czy nie lepiej kupić usługę żeby ktoś ci to utrzymywał. Być może lepiej być może nie no ale to trzeba sobie po prostu wyliczyć ten koszt i samemu ocenić bo to zależy od firmy zależy od przypadków.
Krzysztof: Myślę że maintainerzy Defect Dojo też dostrzegli ten problem bo z tego co dobrze kojarzę to można u nich tą usługę kupić jako SAS po prostu w chwili obecnej więc oni chyba też znaleźli ten pain point userów Defect Dojo.
Andrzej: No to jest taki znany model open source’owe zarabiania gdzie udostępniasz core’owe narzędzie za darmo ale sprzedajesz utrzymanie tego narzędzia właśnie w takiej formie SaaS’owej np. Wydaje mi się że chyba Sidekick to jest takie narzędzie do Ruby do obsługi Redis’a. Tak działa w tym modelu. Sidekick’a można używać za darmo. no ale jeżeli chcesz mieć wsparcie etc. no to kupujesz od autora licencję. I on tam całkiem dobre pieniądze na tym zrobił, to takie setki tysięcy dolarów chyba miesięcznie zarabia na tym, więc to jest taki dobry deal, no ale oczywiście wtedy trzeba mieć faktycznie szerokie użycie. Wracając do naszej sprawy, Jakub, bo W GSK działałeś jak bardziej od tej strony takiej, może nawet nie tyle działałeś od tej strony tylko wchodziłeś tak jakby w cybersecurity. No ale potem potem wylądowałeś w miejscu w którym chyba jesteś do tej pory czyli w Egnyte.
Jakub: Zgadza się.
Andrzej: I tu już miałeś pewien poziom doświadczenia. Nazwałbym to, że już byłeś na tym poziomie juniora plus. I jak to się potoczyło od tego momentu?
Jakub: Dobrze, opowiem jeszcze chwilkę o GSK, bo chcę podkreślić wartość, którą taki staż dla młodej osoby wnosi. Sam fakt, że moja rola nie była ściśle techniczna, w jakimś sensie był ograniczający. To jest duża organizacja, pewnych rzeczy osoba na stażu nie może robić. Przykładowo, przeprowadzać samodzielnie testu penetracyjnego aplikacji, no po prostu w dużych organizacjach to się nie dzieje. Ale samo przebywanie, obok miałem kolegów z Incident Response, z SOKA, z zarządzających WAFem, kolegów, którzy zajmowali się EDR-em. Także przebywanie, chodzenie na lunche z tymi osobami sprawiło, że przez osmozę nauczyłem się bardzo dużo z generalnego security i z tego miejsca. bardzo polecam studentom i nie tylko próbować się dostać na taki staż, bo to jest takie doświadczenie, które trudno inaczej zebrać. Tylko ja w pewnym momencie poczułem, że te moje inklinacje i chęć rozwoju takiego technicznego sprawia, że mogę przyspieszyć ten rozwój zmieniając miejsce pracy. No i pojawiła się po prostu oferta na tamten moment dla mnie wymarzone stanowisko, junior product security inżynier w Egnyte. Ja sobie musiałem się zaznajomić z czym Egnyte jest, czym się zajmuje. Opis stanowiska wyglądał bardzo wymagająco, ale zapisałem się, wysłałem CV i faktycznie po jakimś czasie dopiero do mnie dotarło, że rozmowę rekrutacyjną będę miał z Dawidem Bałutem, którego myślę, że część przynajmniej widzów kojarzy. Nie ukrywam, byłem zestresowany bardziej niż teraz. ponieważ ja z twórczością Dawida, z tej twórczości korzystałem, ucząc się zarówno przed, jak i w trakcie stażów GSK, więc było to dla mnie takie trochę zderzenie z osobą, która o tym nie wiedziała, ale była dla mnie wtedy jakimś mentorem. Może mentorem to jest za dużo powiedziane, ale przynajmniej osobą, której się sporo nauczyłem. No i Dawid, jeden z jego webinarów, jeden z jego filmików, wideoblogów miał tytuł, jak schakować proces rekrutacyjny. No także głupie byłoby nie skorzystać z rad osoby, do której siedzie na rekrutację. Także ja się zapoznałem bardzo dogłębnie z tym filmikiem i z całą gamą innych powiązanych wideoblogów. i przyszedłem przygotowany na rozmowę rekrutacyjną, pomimo tak naprawdę niewielkiego doświadczenia technicznego, ponieważ na tamten moment nie miałem wyeksploitowanych żadnych ciekawych łańcuchów podatności, tak naprawdę poza taką wiedzą wyciągniętą z platform typu Pentester Lab czy Web Security Academy. Przeczytałem, nie wiem, Web Application Hacker’s Handbook, czyli Biblię Hakowania Web Aplikacji od ludzi z sportswigera. Ale tak jak mówię, ta rozmowa rekrutacyjna to było przede wszystkim wykorzystanie rad samego Dawida. No i okazało się, że z tej puli kandydatów wybrali mnie. Dostałem się na to stanowisko już techniczne. No i to było zdecydowane przyspieszenie rozwoju. Musiałem się po prostu bardzo, bardzo wiele nauczyć.
Andrzej: Jakub, mi się bardzo podoba to, że zwróciłeś uwagę na ten aspekt, który ja tutaj trochę rozszerzę i jeszcze bardziej uwypuklę, zainteresowania się tym, o ile mamy taką informację, kto będzie Cię rekrutował i zapoznania się z jego twórczością, o ile taka osoba taką ma. Ale nawet jeżeli nie ma takiej jasnej, otwartej twórczości, to zawsze można i warto spojrzeć na Linkedina, przeczytać co ta osoba robiła, bo tak jak powiedziałeś sam, że nie mienia się jakiegoś głębokiego doświadczenia w technicznych aspektach związanych z bezpieczeństwem. to jednak w tych aspektach, w których mogłeś podejść rzetelnie, odszedłeś rzetelnie. I tym nadrobiłeś, ale przede wszystkim, bo o to chodzi tak naprawdę w tych pierwszych rolach na początku swojej drogi, w jakiejkolwiek ścieżce kariery, żeby pokazać, że jesteś czymś zainteresowany i że ci się chce.
Jakub: No i faktycznie tak było.
Krzysztof: Dobry rekonesans podstawą rozmowy rekrutacyjnej ze strony kandydata.
Jakub: Tu miałem tą przewagę, że akurat Dawid faktycznie upublicznił sporo swoich przemyśleń na ten temat, ale według mnie, zgadzam się w pełni z tym co powiedziałeś Andrzej, wykazać, pracę wejścia po prostu włożyć, tak, zaznajomić się z tym czym firma się zajmuje, jaki jest tak technologiczny, na stanowiskach już nawet bardziej mid, senior można wejść głębiej, można poczytać engineering blog, zrozumieć jakie technologie są wykorzystywane, jakie jest podejście, może nawet nie jest się dobrym fitem tak naprawdę organizacyjnym.
Andrzej: Dokładnie tak i wtedy samemu sobie zaoszczędzimy czas bo może być tak że np. nie chce się pracować w jakimś konkretnym staku z jakimiś konkretnymi narzędziami i wtedy sami siebie wyeliminujemy i tak naprawdę i sobie zaoszczędzimy czas. i też firmie zaoszczędzimy czas. i nie chodzi mi teraz o firmę ale zaoszczędzimy czas ludziom którzy musieliby nam go poświęcić w ramach jakiegoś działania biznesowego. Więc pełna zgoda. i raz jeszcze, jak ktoś chce się gdzieś rekrutować, to warto wykazać inicjatywą, przynajmniej gdzieś tam na początku naszej drogi w karierze, no bo wiadomo, jak ktoś już ma x lat doświadczenia, to niejako to jego doświadczenie staje się już tą kartą przetargową.
Jakub: Ale hacker mindset zawsze się przyda.
Andrzej: To jest tak, że jak go masz, to nie jest tak, że możesz sobie go wyłączyć, nie?
Krzysztof: Tak jest. Tak, no i jesteśmy w Egnyte’cie, wskakujesz w Product Security i powiedz mi jak wtedy widziałeś swoją rolę, czym dla Ciebie wtedy było to Product Security i z perspektywy czasu jak ta myśl się rozwinęła, czym Product Security jest teraz według Ciebie?
Jakub: Ok, dla mnie ten przeskok z bardzo dużej organizacji, bardzo ustrukturyzowanej, z procesami do dużego startupu w skali polskiej już tak naprawdę firmy, która na siebie poważnie zarabia, ale w skali amerykańskiej to nadal duży startup, gdzie w Polsce mamy tak naprawdę tylko i wyłącznie engineering, To był ogromny przeskok. Poziom średni inżyniera w Egnyte był zdecydowanie wyższy. Problemy, z którymi się mierzyliśmy. Więc ja na początku dostałem zadania przede wszystkim takie niezależne, w których mogłem przykładowo automatyzować pewne procesy. Wykorzystaliśmy tą wiedzę, którą miałem na tamten moment, czyli jakieś podstawy programowania, zapoznałem się z podstawami chmury Google Cloud Platform i robiłem tematy takie około APSECowe. Przy czym samo Product Security to od początku moim zdaniem warto zrozumieć, że to nie jest tylko i wyłącznie praca techniczna. To znaczy my jako Product Security Inżynier to przede wszystkim musimy nie tylko brać pod uwagę wymagania techniczne dla danego projektu, ale też kontekst biznesowy, to ile tak naprawdę osób w firmie z różnych stron ciągnie, jak priorytety muszą być żonglowane, także powoli się tego uczyłem, przy okazji robiąc robiąc pracę techniczną. I tutaj ja polecę, nie wiem czy ten blog nadal jest dostępny, Michał Zalewski, I Come Tough, miał kiedyś taki fenomenalny wpis o product security, gdzie powiedział, że to jest protonauka, że my tak naprawdę jeszcze nie mamy takiego paradygmatu wypracowanego, ścisłego. I to jest kwestia tutaj budowania kultury. Ja w ogóle opieram dużo, dużo tego jak podchodzę do tematów o kulturę z Google, bo uważam, że oni są jednak liderem, jeśli chodzi o tą myśl techniczną i budowanie kultury security w firmie. Także bardzo polecam ten wpis. To jest chyba z 2017 roku, jeśli dobrze pamiętam. Mam nadzieję, że to przynajmniej częściowo odpowiedziało na twoje pytanie.
Andrzej: Tak, tak, tak. By the way, ten wpis od Michała dalej jest dostępny. Michał nie ma zwyczaju kasowania swojej twórczości, tylko ma trzy blogi, o ile dobrze pamiętam, więc tam trzeba poguglać.
Krzysztof: I ten wpis z tego bloga na pewno załączymy w referencjach do tego odcinka. Powiedziałeś bardzo fajną rzecz Jakub, że nie tylko stricte wymagania techniczne, ale też praca z biznesem. i czy ty uważasz, że to jest klucz do tego, aby bezpieczeństwo było szerzej inkorporowane w organizacji, żeby jakby przedrzeć się przez te meandry biznesu, żeby biznes zrozumiał dlaczego bezpieczeństwo jest istotne.
Jakub: Powiem tak, szczególnie w rolach liderskich, engineering managerowie, dyrektorzy, senior inżynierowie już prawdopodobnie też, nie każdy w zespole musi mieć tę chęć i umiejętność takiego pewnego lawirowania, żonglowania priorytetami, ale takie osoby są bardzo potrzebne i czasami w pewnym kontekście te umiejętności są nawet bardziej wartościowe niż stricte skill techniczny, co nie znaczy, że skill techniczny nie jest potrzebny, jest wiele ról, niekoniecznie w takich organizacjach, jako niezależny konsultant, researcher, gdzie zdecydowanie ten priorytet jest, ta waga jest inna i skill techniczny jest tą podstawową przewagą danej osoby, ale w firmach produktowych uważam, że jest to bardzo istotne, żeby rozumieć te współzależności, które są pomiędzy działami w firmie i właśnie rozumieć te priorytety.
Andrzej: Tak, ja tutaj bym dodał, że ja to widzę często jako taki. nazwijmy gradient i im jesteś bardziej, im masz bardziej senior rolę, czyli przechodząc od juniora do mida, potem do seniora i powiedzmy do staff, inżyniera, tym tak naprawdę zmieniasz nacisk na coraz bardziej i coraz większy nacisk na umiejętności miękkie, umiejętności komunikacji, umiejętności przekazywania informacji, zgrywania ludzi czy zespołów, a nie na takie twarde umiejętności techniczne. że te twarde umiejętności techniczne, one są ważne i w moim spojrzeniu od tego należałoby wychodzić, że masz te umiejętności techniczne, żeby nie być po prostu takim czarodziejem, ale im jesteś bardziej głębiej w tej króliczej norze, czyli powiedzmy im idziesz wyżej w swojej karierze, tym większy nasisk powinien być stawiany właśnie na umiejętności miękkie.
Jakub: ten balans jest bardzo potrzebny, żeby nie wyprzedzić umiejętnościami miękkimi, komunikacją, zrozumieniem, aż tak umiejętności technicznej, że dana rola jakby nie oddaje tego poziomu, który reprezentujesz. I to dla niektórych, myślę, że dla większości jest w drugą stronę, osób po informatyce przykładowo, że nadganiają komunikacją i tym zrozumieniem całościowym tych procesów, które występują w firmie, ale w drugą stronę. to też jest potrzebne, żeby nie zostać osobą, która jest seniorem, a nie do końca umie ten bread and butter, czyli te podstawy.
Andrzej: Tak, tak, tak. Można to spotkać czasami. To nie jest dobry widok. Ja mam jedno pytanie, bo Co prawda mówisz o produkt Security Engineering, ale ty w zasadzie masz rolę wpisaną też w Security Engineering, więc… Co się stało? Właśnie, co poszło nie tak? O co chodzi z tą humorą?
Jakub: Już opowiem, nawet trochę zasiałem już o co może chodzić. Pierwsze zadania, które miałem były związane przede wszystkim z automatyzacją. Padła taka sugestia, żeby spróbować wykorzystać podejście serwerless, żeby nie utrzymywać po prostu jakiejś tam maszyny wirtualnej, a że Google oferuje w tym zakresie sensowne rozwiązania takie jak Cloud Functions, to zrobiliśmy wtedy takie POC. I okazało się po jakimś czasie, że całkiem nieźle sobie radzę z poruszaniem się po tym świecie chmury, a jeśli chodzi o ten mój skill upsecowy na ten moment nie był aż tak potrzebny. i zdecydowaliśmy się, że zrobimy piwot. Ja wyszedłem z tą inicjatywą, została ona przyjęta optymistycznie i pozytywnie i faktycznie tam na początku 2021 roku zacząłem po prostu się intensywnie uczyć zarówno chmury GCP jak i absolutnych podstaw narzędzi devopsowych. z tego miejsca chciałbym pozdrowić cały zespół Production Engineering z Egnyte. chłopaki mieli ze mną na początku niezłą przeprawę ponieważ ja nie zaznajomiony z tym jak działa Puppet, Terraform, Kubernetes to już nawet nie wspomnę. Trochę psułem. Psułem, robiłem chaos engineering, ale nie zamówiony i nie zaplanowany. W sumie tak powinno być. Realny chaos. Także te pierwsze parę miesięcy to byłem po prostu kompletnym noobem i musiałem nadgonić. Z całkiem niezłym skutkiem ostatecznie udało się to zrobić.
Andrzej: A ja mam pytanie, no bo już trochę tych lat doświadczenia masz. To jest takie trochę meta, może nie metafizyczne, ale meta. pytanie. Jak widzisz bezpieczeństwo? Czy widzisz bezpieczeństwo bardziej jako kawałek, który podchodzi pod dział engineering w firmie, czy bardziej jako osobny silos?
Jakub: na pewno nie jako silos, przede wszystkim w firmach produktowych. moim zdaniem podstawą jest zmiana percepcji, znaczy bezpieczeństwo nie może być tylko kosztem, bo w takim momencie jest to naturalne, że osoby decyzyjne podejmują takie decyzje, które minimalizują koszt, no bo tak działa ta funkcja optimum w tym sensie. Także trzeba po pierwsze siłą argumentu i umiejętnym wykazaniem wartości, znaczy ograniczaniem strat tak naprawdę potencjalnych zmienić tą percepcję i bezpieczeństwo musi być bardzo blisko albo być w ramach inżynieringu moim zdaniem. Dobrym przykładem z tego, co kojarzę jest GitHub, gdzie CISO jest przy okazji VP of Engineering, także ma dwie role równolegle, to musi być wyjątkowo trudne i obciążające, ale to pokazuje, że te firmy topowe decydują się, niektóre przynajmniej, że bezpieczeństwo nie jest już na przykład obok IT, tylko jest praktycznie integralną częścią inżynieringu. Przy czym, to mówimy, ja bym chciał rozróżnić, że to są firmy produktowe. Widzę też takie organizacje, czy niezależny consulting, czy bardzo uregulowane, gdzie bezpieczeństwo może być trochę bardziej obok, ale jeśli tutaj skupiamy się na takich firmach jak Egnyte, no to zdecydowanie jak najbliżej inżynieringu.
Krzysztof: Zdecydowanie w firmach produktowych. Ja też nie widzę innej opcji, aby bezpieczeństwo było osobnym silosem, w ogóle nie powiązanym z zespołem inżynierów po prostu. To jest 100% zgody.
Jakub: Także tu można tylko ten klasyk przywołać projekt Feniks. jak ktoś nie czytał no to zdecydowanie polecam. pokazuje tak namacalnie można to poczuć tak naprawdę jak nie działa taki system z sztywnymi podziałami pomiędzy pomiędzy tymi działami technicznymi w firmie.
Andrzej: Tak, postać Johna z The Phoenix Project to jest klasyczny obraz bezpiecznika, który chodzi po całej firmie, bije wszystkich pałką po głowie i w zasadzie nic nie osiąga, jest nieskuteczny.
Jakub: Tak jest.
Andrzej: Ale jest zadowolony, bo może pomerzać świstkiem i powiedzieć, o tak nie, tak się nie, tak nie można, tak się, tak się nie robi. No okej. No i każdy cię obchodzi, nikt z tobą nie rozmawia, bo nie chce mieć problemów.
Jakub: Tak jest.
Andrzej: I nikt tak naprawdę nie jest do końca zadowolony. bo ani bezpieczny nie jest zadowolony, bo praca jest nieskuteczna, nie osiąga tego, co chce, ani ci ludzie nie są zadowoleni, bo muszą robić jakieś obejścia, zamiast po prostu żyć w jakimś współżyciu produktywnie.
Jakub: Tak jest.
Krzysztof: Wychodząc od The Phoenix Project, który opowiada o DevOps-ie, powiedz mi Jakub, jak ty widzisz tą relację adaptowania praktyk DevOps-owych, DevSecOps-owych w kontekście właśnie chmury? Czy chmura przyspiesza jeszcze tą transformację w tym kierunku, czy może nie? Może się to dziać po prostu samoistnie na dwóch torach i nie ma nic ze sobą wspólnego. Jak to widzisz?
Jakub: Ja to widzę tak, że w momencie kiedy korzystamy z zarządzanych usług, czyli mamy od AWS, Azure czy GCP usługi, które są, nie wymagają już utrzymywania przykładowo infrastruktury pod spodem, to proces dewelopmentu, iterowanie tak przyspiesza, deweloperzy i devopsi, nazwijmy to osoby w różnych firmach, definicja devopsa jako pracownika to nie jest jasne, bo czasami są to osoby, które się zajmują przede wszystkim jako build team CICD, taki release inżynier, czasami są to osoby bardziej przy infrastrukturze, coś jak SRI w Google, ale w każdym razie te zespoły sobie poautomatyzowały naprawdę wiele i security takie dwudziestowieczne czy nawet z początku tego wieku po prostu nie nadąża, jest blokerem, jest kulą u nogi i w idealnym wariancie security, ja to widzę, czasami nam się to udaje, nie zawsze, jest nawet enablerem, to znaczy można wprowadzać równocześnie usprawnienia w samym procesie plus podnosić poziom bezpieczeństwa. i tutaj mówię o takich skalowalnych rozwiązaniach typu wpinanie sensownych jobów, tasków, guardrailsów w pipeline’y. Sorry za ten polinglish, ale naprawdę tutaj polskich, czasami to spolszczanie nawet jest gorsze.
Andrzej: Dokładnie tak i zresztą już nawet dzisiaj o tym mówiliśmy. Angielski jest ma stref i czasami da się uniknąć tego. Przykładowo nie musiałem użyć ma stref. ale już używanie konkretnego keyworda jak guardrails. nie ma takiego polskiego dobrego odpowiednika na to słowo. Czy mógłbyś rozwinąć te właśnie guardrails i to, bo mi się to bardzo spodobało co powiedziałeś, że jeżeli już chcemy wpinać jakieś narzędzia w nasz potomice ICD, to raczej powinniśmy to robić z głową. To nie chodzi tylko o to, żeby wpiąć narzędzie i mieć jakiś wynik, bo tak naprawdę wtedy może mi to w dużym… Często jest tak, że dodaje mi to praca, tak naprawdę nie wnosi żadnej wartości, więc po co to komu? Czy mógłbyś rozwinąć właśnie ten koncept guardraisów, bo ja się ogólnie z nim zgadzam, i trochę wejść właśnie w ten temat tego, co ma sens według ciebie.
Jakub: Tutaj mogę spróbować przez analogię. Jest takie podejście secure by design, które samo w sobie może być buzzwordem, ale implementacja, tu znowu się o firmę Google opere, miała za zadanie przede wszystkim wykluczyć całe klasy problemów przede wszystkim jeśli chodzi o kod aplikacji. Trusted types. jeśli chodzi o prewencję injection typu cross-site scripting czy specjalnie nadpisane implementacje w Javie class, które obsługują SQL queries. One tak naprawdę z punktu widzenia organizacji nie tylko zmniejszają ryzyko jakiejś eksploitacji, ale też z punktu widzenia dewelopera. sprawiają, że on musi myśleć o mniejszej puli problemów. To znaczy, jeśli ja jako deweloper mam klasę, która przy kompilacji mojego kodu Java, napisanego w Javie, wywali się, ponieważ moje query jakby nie spełnia założeń, no to ja o tym się dowiaduję w momencie, kiedy piszę kod. kiedy go kompiluje. czyli mamy ten idealny przypadek kiedy jest znowu shift left najbardziej przesunięte w lewo jak tylko można bo to nawet nie zdążyło pójść do żadnego potoku CICD. tylko to się dzieje na maszynie na maszynie dewelopera zakładając że kompilacja tam się odbywa.
Krzysztof: Czyli wkracamy te nasze feedback loopy.
Andrzej: Dokładnie feedback loop jest very tight.
Jakub: I tutaj mogę podać przykład bardziej z tego świata takiego devopsowo-cloudowego. Przykładowo w GCP, nie wiem czy inne chmury mają takie podejście, zakładam, że tak. Jest takie podejście, jest takie mechanizmy jak org policies, organization policy constraints, które pozwalają część część możliwych konfiguracji zablokować na poziomie całej organizacji, a jako że organizacja to jest takie drzewo hierarchiczne, no to przez kaskadę pewnych ustawień nie da się po prostu zrobić na poziomie całej organizacji i to sprawia, Kosztowne błędy, nie tylko z punktu widzenia bezpieczeństwa, które w tym sensie jest pod zbiorem dobrego inżynieringu, tylko też z punktu widzenia availability, resilience i tak dalej, pewnych błędów nie da się popełnić, no bo można powiedzieć, że przypadkowe usunięcie bazy danych Czy to jest bezpieczeństwo? DropDB? Czy to jest availability? No jak baza nie istnieje, no to mamy problem też z usługą. A jak mamy problem z usługą, to mamy problem z uptimem. Gdy mamy problem z uptimem, no to mamy problem, bo klienci krzyczą, że hej, nie działa. Także powiedziałbym tak, nie skupiałbym się tutaj na już wchodzeniu jeszcze większe szczegóły, bo mechanizmy są różne, a chodzi bardziej o szukanie, o szukanie takich klas problemów, które da się rozwiązać maksymalnie szeroko.
Andrzej: Dokładnie, dokładnie tak. I ja bardzo lubię wracać do tego przykładu, jak zaczął to robić Microsoft w momencie, gdy projektował swoje Secure Development Lifecycle, SDL. po sławnym memo Billa Gatesa z 2002. Oni tak naprawdę tworzyli podwaliny procesu bezpieczeństwa w ogólnym SDLC. I oni też już wtedy mieli, jedną z zasad tego podejścia był Secure by Design, ale właśnie w podejściu takim trzymania guard race’ów, gdzie na poziomie kompilatora po prostu pewnych funkcji nie dopuszczali, takich jak, niebezpiecznych, takich jak na przykład string copy. gdzie bardzo łatwo popełnić błąd i tak łatwo, że my w zasadzie chcemy, żeby programista tego nie mógł użyć.
Jakub: Dokładnie.
Andrzej: I to podejście jest faktycznie skuteczne, bo jeżeli jesteśmy w stanie przykładowo właśnie dzięki analizie statycznej wyłączyć coś i idealnie już na maszynie dewelopera, a przynajmniej krzyczeć o tym, że nie powinieneś tego robić, nie powinieneś używać tego iwala, zrób to jakoś inaczej, no to tak naprawdę rozwiązujemy problem w zarodku. Tam gdzie tak naprawdę jeszcze nie miał się szansy zmaterializować. Bardzo mi się podoba, że również masz takie spojrzenie na to.
Krzysztof: Mi się to też mega podoba, no to jest to o czym mówimy, czyli skracamy, feedback loop, informacja zwrotna jest bardzo szybka do dewelopera i to też powoduje, że on nie jest sfrustrowany. Przez ostatnie kilka lat popularny koncept budowania takiego wysokiego developer experience wśród właśnie programistów. to jest istotne i my jako bezpieczeństwo nie powinniśmy tego po prostu niszczyć tymi naszymi narzędziami, które krzyczą dopiero na ostatnim etapie, tak naprawdę przed wypuszczeniem czegoś na produkcję. Ja będę miał do Ciebie ostatnie pytanie, Jakub, bo będziemy dobijać pewnie do brzegu. Powiedziałeś, że wdrażać rzeczy w potok CI, które mogą być znane jako biznes enabler. Załóżmy, że masz taki Greenfieldowy projekt. Jaką praktykę bezpieczeństwa w CI wdrożyłbyś jako pierwszą?
Andrzej: Jako pierwszą?
Jakub: Bardzo dobre pytanie. Ja na co dzień stricte z tym naszym build procesem w firmie nie pracuję. także jest to bardziej z peryferiów tego jak obserwuję co co się dzieje w branży.
Andrzej: Jakby co to tu nie ma złych odpowiedzi.
Jakub: Nie ma złych odpowiedzi. Co bym zrobił. Co bym wprowadził pierwsze w procesie CICD.
Krzysztof: Są tylko niepopularne opinie.
Jakub: Zrobimy wybór negatywny i dojdziemy może do tego co bym zrobił. Dust, jak już to z boku, nie na pewno jako blokujący, może jako ciekawostka na start. Może w trybie audit, żeby dawać informacje, też raczej niejako blokujący, powoduje frustrację, czasami długo trwa, trzeba poświęcić sporo czasu na fine tuning, nawet jeśli to jest semgrep czy jakieś rozwiązanie, szczególnie jak to jest semgrep, ale jak są to rozwiązania jakieś płatne, z tego co obserwowałem w innych zespołach, też to wydłuża ten czas. Może powiem coś, co jest nieoczywiste, ale w sumie tak oczywiste, że od tego powinno się zacząć. Wymusić, zależnie czy korzystamy z GitHub’a czy z GitLab’a, proces, ale strict proces, code approvers, czy są wąskie grupy, które w ramach wydzielonych małych repozytorów, chyba że mamy jakieś monorepo, mogą aprobować zmiany. I chodzi tu przede wszystkim o to, że jak zmiana już jest zaaprobowana, załóżmy podwójnie, to dalej już niech się dzieje. wola nieba, idzie automat i dzieją się te kolejne kroki, ale żeby ten proces code review był procesem, który jest w firmie traktowany na poważnie, Nie tylko chodzi o podniesienie poziomu bezpieczeństwa, ale chodzi też o podniesienie kultury i wiedzy w ramach zespołów i pomiędzy zespołami. Czyli przykładowo mamy jakiś wycinek, za który odpowiada zespół X. Ten zespół X jest tam co-donorem. i my chcemy jako zespół Y wprowadzić jakąś zmianę, to po pierwsze oczekujemy, że dostaniemy sensowny feedback w kontekście tego, czy nasza zmiana spełnia założenia danego serwisu, repozytorium, a po drugie już mamy taką świadomość, że jeśli zbierzemy od odpowiednich osób te potwierdzenie, to dalej powinny już działać moim zdaniem automaty. i tutaj, co dalej będziemy wpinać, jaka to będzie analiza, czy statyczna, czy komponentów, czy będziemy generować S-bomby, gdzie będą trafiać artefakty, czy będą podpisywane, to już są rzeczy, które możemy później iteracyjnie podnosić. jakby ten poziom dojrzałości, ale zacząłbym od tych podstaw, czyli sensowne code review wymuszone na warstwie konfiguracji, to znaczy tego się nie da obejść wtedy.
Andrzej: Bardzo mi się podoba ta odpowiedź.
Jakub: Trochę mi zajęło dojście do niej, ale zgadzam się sam ze sobą, także…
Andrzej: Co najważniejsze.
Jakub: Praca u podstaw. Praca u podstaw, tak.
Andrzej: I podoba mi się też to, że to tak jak sam powiedziałeś, że to jest trochę szersze wychodzące poza samo security, bo przykładowo DAST to jednak security, SAST w dużej mierze też. Natomiast to jest, to wychodzi poza ramy security. W takim procesie code review security jest jednym z aspektów, ale tam jest dużo więcej aspektów i Wdrożenie albo usprawnienie takiego procesu Code Review może nam pomóc na wielu różnych wielu różnych ścieżkach nie tylko w tej jednej ścieżce ścisłe związanej z security.
Jakub: Tak i sprawia że security jest jednoznacznie częścią inżynieringu. Nie da się od tego uciec. Jeśli w ramach Code Review powinien być ten element Security Review. Na poziomie podstawowym, umówmy się, to nie będzie pełna, manualna analiza kodu pod kątem bezpieczeństwa, ale przynajmniej taki sanity-check, no to już zrobiliśmy krok w dobrym kierunku.
Andrzej: Tak, tak, przybliżamy, przybliżamy do siebie pewne grupy ludzi.
Krzysztof: Jak jeszcze jesteśmy w stanie sfokusować przez code ownerów, wymusić to, żeby faktycznie te czeki były były dane przez osoby, które faktycznie w danym module, w danej jakiejś jednostce tej aplikacji, tego repozytorium siedzą, to…
Jakub: Znają kontekst.
Krzysztof: Tak, znają kontekst, dokładnie.
Andrzej: Dobra, z mojej strony to już wszystkie pytania, wystrzelałem się.
Krzysztof: Ja już też mam magazynek pusty, także Jakub, bardzo ci dziękujemy za tą wartościową rozmowę.
Andrzej: i być może do usłyszenia kiedyś w przyszłości.
Jakub: Dziękuję wam panowie za zaproszenie, było mi bardzo miło i też mam nadzieję na część drugą.