POIT #239: Jak przejść do cyberbezpieczeństwa z innej specjalizacji IT?

Witam w dwieście trzydziestym dziewiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak przejść do cyberbezpieczeństwa z innej specjalizacji IT?

Dziś moim gościem jest Andrzej Dyjak – rozpoczął swoją karierę w cyberbezpieczeństwie ponad 15 lat temu, przechodząc od hackowania do zabezpieczania. Ta ścieżka kariery dała mu perspektywę zarówno atakującego, jak i obrońcy. Obecnie prowadzi firmę doradczo-szkoleniową Bezpieczny Kod, gdzie rozwija umiejętności zespołów i doradza w zakresie najlepszych praktyk dla bezpiecznego procesu wytwórczego. Jest aktywnym twórcą treści. Buduje otwartą społeczność wokół bezpieczeństwa aplikacji na Discord, prowadzi kanał YouTube i podcast, oraz wysyła cotygodniowy newsletter. Stworzył szkolenie online 'Ofensywne Testowanie Web Aplikacji’ (OTWA) i jest w trakcie budowania kolejnego, poświęconego tematyce DevSecOps.

W tym odcinku o karierze w cyberbezpieczeństwie rozmawiamy w następujących kontekstach:

  • jak rozpocząć w cyberbezpieczeństwie?
  • jakie mamy możliwe ścieżki kariery w tej branży?
  • jakie są wymagania per ścieżka?
  • jakie wygląda rynek pracy?
  • czy do pentestów nadają się tylko wcześniejsi hakerzy?
  • czy certyfikaty są wymagane lub potrzebne?
  • praca w jakich specjalizacjach IT ułatwia przejście do cybersecurity?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

Cześć!

To jest 239. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak przejść do cyberbezpieczeństwa z innej specjalizacji IT. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja, czeka na Ciebie na porozmawiajmyoit.pl/239. 

Myślisz o zmianie pracy? Zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste oferty z informacją co do zarobków, technologii i projektów. 

Ja się nazywam Krzysztof Kempiński. Ten podcast jest zupełnie darmowy. Zostaw ocenę lub podziel się nim w social mediach, abym mógł realizować misję polegającą na poszerzaniu horyzontów ludzi z branży IT. To dla mnie wiele znaczy. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! Mój dzisiejszy gość rozpoczął swoją karierę w cyberbezpieczeństwie ponad 15 lat temu, przechodząc od hakowania do zabezpieczania. Ta ścieżka kariery dała mu perspektywę zarówno atakującego, jak i obrońcy. Obecnie prowadzi firmę doradczo-szkoleniową Bezpieczny Kod, gdzie rozwija umiejętności zespołów i doradza w zakresie najlepszych praktyk dla bezpiecznego procesu wytwórczego. Jest aktywnym twórcą treści, buduje otwartą społeczność wokół bezpieczeństwa aplikacji na Discord, prowadzi kanał YouTube i podcast oraz wysyła cotygodniowy newsletter. Stworzył szkolenie online Ofensywne testowanie web aplikacji i jest w trakcie budowania kolejnego poświęconego tematyce DevSecOps. Moim  i Waszym gościem jest Andrzej Dyjak. 

Cześć, Andrzej, bardzo miło mi gościć Cię w podcaście. 

 

Siema, Krzysztof! Mnie również bardzo miło jest gościć w podcaście Porozmawiajmy o IT po raz drugi, więc to już nie jest debiut. 

 

Właśnie, to tutaj już nie pierwsza Twoja wizyta, ale sprawdziłem sobie, ostatnim razem mieliśmy okazję tutaj rozmawiać 3,5 roku temu, trochę czasu minęło. Tematem wtedy naszej rozmowy było bezpieczeństwo aplikacji, nadal zostajemy w tematyce cyberbezpieczeństwa oczywiście, bo jakże mogłoby być inaczej, natomiast dzisiaj poopowiadamy sobie trochę o tym, jak to jest pracować jako specjalista w tej dziedzinie, jakie możliwe ścieżki kariery w tej specjalizacji możemy odnaleźć i wreszcie, z jakich innych specjalizacji IT najprościej będzie nam do cyberbezpieczeństwa wskoczyć. 

Wszystkie raporty pracowe, wszystkie raporty HR-owo tutaj związane z rynkiem pracy mówią, że to jest bardzo gorąca, potrzebna i gdzieś tam oczekiwana przez pracodawców specjalizacja IT, więc myślę, że ten temat zdecydowanie wstrzeli się w obecne trendy na rynku pracy. 

Ale zanim do tego, moje pierwsze pytanie, które pewnie Cię w ogóle nie zaskoczy i spodziewam się, że raczej go oczekiwałeś, czyli czy słuchasz podcastów, jeśli tak, to może jakieś ciekawe audycje będziesz w stanie zarekomendować? 

 

Tak, oczekiwałem tego pytania, bo Twojego podcastu też słucham, więc oczekiwałem tego pytania. Tak, w dalszym ciągu słucham podcastów, chociaż w zasadzie na przestrzeni tych ostatnich kilku lat, jak się nie słyszeliśmy od ostatniego razu, to tematyka trochę uległa zmianie tego, co słucham. 

W dalszym ciągu słucham bardzo dużo zagranicznych podcastów, natomiast kiedyś słuchałem dużo więcej podcastów technicznych, technologicznych, a w chwili obecnej słucham więcej podcastów o tematach takich jak inwestowanie, jak tworzenie treści, jak produktywność, czy wszystko wokół zdrowia, health. I przykładowo podcasty takie jak… Nie wiem, z głowy teraz powiem All In – myślę, że sporo osób będzie kojarzyć All In od czterech znanych inwestorów z Silicon Valley.

 Albo ten podcast może nie każdy będzie kojarzył How I Write, czyli Jak Ja Piszę od Davida Perella – bardzo polecam ten podcast. Przede wszystkim dlatego, że od pewnego momentu, od paru miesięcy David zaprasza naprawdę bardzo ciekawych gości i nawet jeżeli ktoś nie pracuje aktywnie nad swoimi umiejętnościami pisarskimi, to warto po prostu posłuchać tych ludzi, których on tam zaprasza. Więc ten podcast naprawdę bardzo mocno polecam, przede wszystkim przez pryzmat gości, którzy się tam pojawiają. 

Trochę bardziej niszowy The Network State od Balajiego Srinivasena też polecam. Natomiast jeżeli miałbym trochę wrócić tak na nasze polskie poletko, bo jednak tych polskich podcastów też trochę słucham, to oczywiście słucham Porozmawiajmy o IT. Słucham Twojego podcastu w dalszym ciągu. Ale poza Twoim podcastem słucham Nowoczesna sprzedaż i marketing NSM od Szymona Negacza. Słucham podcastu od Michała Sadowskiego z Brand24. On tam różnych ciekawych ludzi sprowadza i rozmawia na tematy okołobiznesowe. I od jakiegoś czasu, chyba od roku też dość sporo słucham podcastu Technologicznie od Bartka Pucka i Kuźniara. Na tyle aktywnie go słucham, że nawet wszedłem do tej społeczności Pucka, którą tworzy wokół swojego newslettera. 

Więc generalnie tak, trochę tego jest. Słucham podcastów, aktywnie staram się poświęcić tych kilka godzin w tygodniu na słuchanie podcastów, bo jest to taka fajna forma, którą można uskuteczniać, robiąc interakcje rzeczy. Ja nie lubię słuchać audiobooków, książki wolę czytać, bo lepiej mi się przyswaja informacje, więc zamiast audiobooków słucham po prostu podcastów i najczęściej albo pod kątem swoich autorów, których gdzieś tam zebrałem, albo pod kątem gości, którzy się po prostu pojawiają. 

Przykładowo, jeżeli pojawi się jakiś mega ciekawy gość, taki jak, nie wiem, w moich oczach jest nim Michael Saylor z MicroStrategy, to potem szukam go we wszystkich podcastach i robię sobie taki podcastowy binge, gdzie słucham wszystkich audycji z wszystkich lat, gdzie był Michael Saylor. I potem w zasadzie ja mógłbym streszczać innym, co mówi Michael, bo wiadomo, bo jeżeli mamy jednego gościa, to on powtarza wiele rzeczy. Trochę rozbudowana odpowiedź na to pytanie, ale jak sam widzisz, żywo podchodzę do podcastów. Bardzo lubię tę formę, można powiedzieć rozrywki i nauki. 

 

Bardzo Ci dziękuję za te rekomendacje. Cieszę się, że te audycje, które słuchasz na przestrzeni tych prawie czterech lat, się zmieniły, bo to znaczy, że się po prostu rozwijasz i to jak najbardziej tutaj też dobrze o Tobie świadczy. 

Świetnie. Zatem proponuję przejść do naszego głównego tematu, który sobie tutaj postawiliśmy. Będzie on się kręcić wokoło kariery, codziennej pracy, rozwoju, jeśli chodzi o właśnie bycie specjalistą w cyberbezpieczeństwie, ale żeby nim zostać, żeby się rozwijać,  musimy od czegoś zacząć. Co Ty byś sugerował, jakie pierwsze kroki byś podjął, aby właśnie do tej branży wejść? 

 

To jest takie pytanie z tych, co brzmi prosto, no jak wejść do jakiejś branży, ale w zasadzie jest dość skomplikowane. 

 

Powiedz, że to zależy, i pójdziemy dalej. 

 

Właśnie, bo ja, jak na początku wspomniałeś, działam jako konsultant, więc no właśnie, to zależy. Nie, ale oczywiście rozwinę, jak na konsultanta przystało. Odpowiedź może nie jest jakoś super skomplikowana, ale nie jest też jakoś super prosta. Ponieważ przede wszystkim odpowiedź jest wielotorowa, bo żeby wskoczyć w cyberbezpieczeństwo, to można w zasadzie to zrealizować na wiele różnych sposobów i nie ma jakiegoś jednego, idealnego sposobu, jak wskoczyć w cyberbezpieczeństwo. 

A czemu? Bo cyber, i ja lubię powtarzać taki frazes, jest zarówno szerokie, jak i głębokie. Czyli zarówno mamy dość szeroki krajobraz tego, co możemy robić, a potem wchodząc dalej i zbliżając się do jakiejś konkretnej poddziedziny, możemy wchodzić głębiej i głębiej i głębiej. Więc nie ma tutaj jednej jedynej słusznej drogi, a skoro nie ma jednej jedynej słusznej drogi, to też nie ma jednego jedynego słusznego startu ani oczywiście jednej jedynej słusznej destynacji. 

To jest zaleta, no ale jest to też pewnego rodzaju minus, bo można się w tym wszystkim pogubić. Ale zaleta jest taka, że mamy bardzo dużo możliwości rozwoju, jak już się o coś zaczepimy. I oczywiście, jeżeli to, o co się zaczepiliśmy, nam się w jakimś punkcie po prostu znudzi albo zaciekawimy się czymś innym, więc jesteśmy wtedy w stanie przejść do jakiejś innej ścieżki. 

A minusem jest oczywiście, tak jak już powiedziałem, to, że można się w tym wszystkim pogubić, więc dobrze jest mieć jakąś mapę tego, co można byłoby zrobić w cyberbezpieczeństwie, jak można byłoby zacząć. I teraz przejdę trochę, zrobię taki leapfrog do tego, jak można byłoby zacząć, bo w zasadzie, o ile nie będę jakoś mocno wchodził w szczegóły poszczególnych ścieżek, to jeżeli popatrzymy z takiego wyższego poziomu, to możemy wyszczególnić takie trzy ścieżki ogólnego rozwoju w cyber. 

Można pójść w analitykę, a przepraszam, jeżeli mówimy o cyberbezpieczeństwie technicznym. Bo ja też jestem osobą techniczną, bo oczywiście moglibyśmy mówić o takim governance, ale jeżeli mówimy o cyberbezpieczeństwie technicznym, bo zakładam, że większość słuchaczy będzie interesowała jednak ta ścieżka, to mamy trzy takie główne ścieżki rozwoju. Jest to albo analityk bezpieczeństwa, albo tester bezpieczeństwa, albo inżynier bezpieczeństwa. I w zasadzie wszystko się zamyka w tych trzech ścieżkach, ale oczywiście w każdej z tych ścieżek moglibyśmy wejść głębiej i głębiej i powiedzieć np. jaki tester bezpieczeństwa. Może być taki od infrastruktury, może być taki od aplikacji, a w aplikacjach może być taki od web aplikacji albo od aplikacji mobilnych. A w infrastrukturze może być taki od Azure’a, taki od AWS’a, więc w zasadzie moglibyśmy tam coraz głębiej wchodzić. 

I oczywiście, jak ze wszystkim, na samym początku lepiej wybrać jakąś konkretną ścieżkę, czyli np. wejść jako analityk i robić jakąś jedną konkretną rzecz, a potem ewentualnie rozszerzać. Ale wracając do oryginalnego pytania, nie jest tutaj jakoś super łatwo odpowiedzieć, jak wejść w cyber, ale są generalne ścieżki. Jeżeli chcesz, to mogę opowiedzieć trochę szerzej o tych konkretnych ścieżkach albo doszczegółowić coś, o czym już powiedziałem. 

 

Tak, myślę, że tutaj wejście minimalnie, przynajmniej głębiej w zdefiniowanie tych trzech ścieżek będzie istotne, bo będę też Cię za chwilkę prosił, co prawda możemy na moment to pytanie zaparkować, ale będę Cię prosił, żebyś może wskazał, jak wybrać tę ścieżkę dla siebie, żeby się w tym nie pogubić. Myślę, że to jest taka istotna wiedza na początku. 

 

Jasne, jasne. Dobra, to wróćmy do tego podziału, przypomnę go. Można pójść w analityka bezpieczeństwa, można pójść w testera bezpieczeństwa lub można pójść w inżyniera bezpieczeństwa. 

Więc tak, na samym początku analitycy pracują w tzw. SOC-ach, to jest Security Operations Center. I o ile ja dobrze pamiętam, to masz, Krzysztofie, osobny odcinek na temat SOC-ów, więc ja nie będę tutaj wchodził jakoś super głęboko i omawiał, czym jest SOC, bo słuchacza po prostu odeślemy do tego konkretnego odcinka i tam jest to lepiej wytłumaczone. I też oczywiście cały odcinek jest wokół tego, więc będzie to i lepiej i głębiej wytłumaczone. 

Powiem tylko tyle, że ta ścieżka jest mega ciekawa. Ale tutaj nie weryfikujemy bezpieczeństwa, a raczej je monitorujemy lub, i to na trochę wyższych poziomach, aktywnie walczymy z atakującymi. A więc ta ścieżka jest taka typowo defensywna i w zasadzie często w cyber nazywa się ją blue teamową. To jest niebieski zespół. To jest ten zespół, który broni organizację czy sieć przed wszystkimi zagrożeniami, które mogą przyjść z zewnątrz. I to jest ta pierwsza ścieżka, analityk bezpieczeństwa. 

Następnie ta druga ścieżka, czyli tester bezpieczeństwa, leży trochę po drugiej stronie od tego analityka. Tutaj głównym zadaniem jest weryfikacja bezpieczeństwa systemów IT. Jeśli mówimy o testowaniu bezpieczeństwa potocznie zwanym pentestingiem, czyli testami penetracyjnymi, lub całych organizacji, jeśli mówimy o ćwiczeniach redteamingowych, gdzie wychodzi się już w zasadzie poza samo IT, nie skupiamy się tylko na systemach IT, ale włączamy w to ludzi i procesy.

I tę ścieżkę, tę ofensywną ścieżkę, tę testerską ścieżkę często nazywa się redteamową, czyli czerwony zespół, i tutaj jest to pewnego rodzaju kontra dla tego blue teamu, więc mamy red team, który atakuje i blue team, który broni.

Natomiast można powiedzieć, że tak trochę pomiędzy tymi dwoma ścieżkami, czyli pomiędzy ścieżką defensywną (analityczną) a ofensywną (testerską) leży ścieżka inżyniera bezpieczeństwa, która w bezpieczeństwie aplikacji, w AppSecu, często nazywa się po prostu Product Security Engineer i taka osoba gra trochę rolę testerską, ale też trochę rolę analityczną, i przede wszystkim oczywiście gra rolę inżynierską, więc samo z siebie już wynika, że taka osoba powinna umieć coś zbudować, bo inżynierzy nie tylko pasywnie coś obserwują, ale też faktycznie coś budują, w zasadzie to jest główna rola inżyniera.

Przede wszystkim osoba, która przyjmuje tę rolę, proaktywnie działa, żeby to, nad czym firma pracuje, było bezpieczne lub żeby to, w jaki sposób firma nad tym pracuje, czyli np. w jaki sposób wytwarza oprogramowanie, był bezpieczny, czyli żeby np. nasz proces wytwórczy, SDLC, był bezpieczny, żebyśmy mieli analizę statyczną, analizę dynamiczną w odpowiednich kawałkach procesu i żeby to, co na końcu procesu wychodzi, czyli ta aplikacja, była na tyle bezpieczna, na ile nam pozwala na to budżet. Bo oczywiście nigdy nic nie będzie w 100% bezpieczne. Tutaj zawsze jesteśmy niejako pochodną całej ekonomii i ogólnych kosztów, więc nie chodzi o to, żeby coś było superbezpieczne, ale żeby nie miało takich podstawowych błędów bezpieczeństwa.

Oczywiście tutaj uogólniam, bo są oczywiście sytuacje, w których zależy nam na tym, żeby to nad czym pracujemy, było super bezpieczne, ale to są, powiedzmy, jakieś małe wycinki tego, co się robi w IT.

Natomiast tak jak wcześniej wspomniałem o tym red teamie i blue teamie, to od paru lat można spotkać określenie tej ścieżki inżynierskiej, szczególnie ludzi, którzy pracują w procesie wytwórczym przy zabezpieczaniu procesu wytwórczego, tę ścieżkę od jakiegoś czasu nazywa się yellow team, żółty zespół. Tutaj niejako trochę łączymy ten aspekt ofensywny i ten defensywny.

W zasadzie zależy to od tego, czego konkretnie organizacja od nas oczekuje. Ale i w jednym, i w drugim aspekcie dokładamy te nasze umiejętności inżynierskie i raczej w naszej pracy spotkamy się z może nie przymusem, ale z obowiązkiem budowania czegoś, czyli np. wbudowywania jakichś narzędzi do procesu albo wytwórczego, jeżeli mówimy o AppSecu , albo jeżeli mamy bardziej rolę taką defensywną,  to we wbudowywaniu różnych narzędzi w sieć, żeby ją obserwować. Tutaj nie tylko pasywnie gdzieś obserwujemy, ale faktycznie też budujemy i działamy.

Mam nadzieję, że odpowiedziałem na to pytanie.

Natomiast można powiedzieć, że tak trochę pomiędzy tymi dwoma ścieżkami, czyli pomiędzy ścieżką defensywną (analityczną) a ofensywną (testerską) leży ścieżka inżyniera bezpieczeństwa, która w bezpieczeństwie aplikacji, w AppSecu, często nazywa się po prostu Product Security Engineer i taka osoba gra trochę rolę testerską, ale też trochę rolę analityczną, i przede wszystkim oczywiście gra rolę inżynierską, więc samo z siebie już wynika, że taka osoba powinna umieć coś zbudować, bo inżynierzy nie tylko pasywnie coś obserwują, ale też faktycznie coś budują, w zasadzie to jest główna rola inżyniera.

 

Tak, myślę, że wyczerpałeś temat jak najbardziej. Czy gdy obserwujesz kolegów, koleżanki z twojej branży, to czy zauważasz pewną prawidłowość, że wcześniejsze doświadczenie, wcześniejsze specjalizacje, może pewne cechy charakteru wpływają na to, że któraś z tych ścieżek, którą opisałeś, jest wybierana przez daną grupę osób, a inna przez inną, czy tutaj nie ma takich prawidłowości?

 

To jest, Krzysztofie, świetnie pytanie. Chciałbym na nie odpowiedzieć, ale tam zrobiłeś takie założenie – najpierw musiałbym mieć kolegów i koleżanki. Oczywiście żartuję. Mam, mam. Mam i kolegów, i koleżanki i tak, obserwuję pewną prawidłowość, która w zasadzie można powiedzieć, że jest to pewnego rodzaju pattern.

Przykładowo dla ról testerskich, czyli tych ofensywnych, na samym początku, czyli powiedzmy na początku ogólnego cyberbezpieczeństwa, czyli jakieś 20 lat temu, bardzo dużo administratorów, ludzi od infrastruktury przychodziło w testowanie bezpieczeństwa. W pewnym momencie trochę się to zmieniło i szczególnie w ostatnich latach widać sporo ludzi z doświadczeniem testerskim – chodzi mi tutaj o quality assurance, inżynierzy QA, testerzy automatyczni, manualni. Ci ludzie zaczynają przechodzić do bezpieczeństwa, co ma sens, dlatego że bezpieczeństwo jest pod zbiorem jakości. Więc jeżeli ktoś już jest testerem jakości, to będzie mu łatwo przejść do bezpieczeństwa, bo niejako po prostu nauczy się pewnego nowego skillsetu i jest w stanie przetestować podstawowe właściwości bezpieczeństwa systemu IT bez większego problemu.

Oczywiście jeżeli będzie taka osoba chciała iść dalej, to też nie ma problemu, żeby się uczyła jeszcze więcej, jeszcze więcej i… i nie zaprzestała na tych podstawowych właściwościach, a weszła w to jako już specjalizację i ekspertyzę. Tutaj sky is the limit, to nie jest żadna czarna magia.

Więc dla tej ścieżki testerskiej klasycznie ludzie przechodzili z administratorki, z operacji, ale w pewnym momencie, od paru lat jest to dość widoczne, ludzie ze ścieżki QA przechodzą do testowania bezpieczeństwa.

Jeżeli mówimy o rolach analitycznych, to z moich obserwacji też często ludzie z doświadczeniem administratorskim przechodzą do tych ról, ale też widziałem, że szczególnie jeżeli mówimy o przejściu na pierwszą linię, bo w SOC-ach mamy trzy linie klasycznie, pierwsza linia obrony, druga linia obrony i trzecia linia obrony, to przynajmniej takim punktem wejścia na wskoczenie do pierwszej linii jest helpdesk. Ludzie zaczynają w helpdesku IT, zyskują nowe umiejętności, zaczynają umieć rozwiązywać typowe problemy,  i przechodzą do pierwszej linii SOC-a, gdzie też tak naprawdę robimy trochę za taki helpdesk.

Oczywiście jeżeli taka osoba znowu będzie poświęcić czas na naukę, będzie się edukować, będzie iść do przodu, to nic nie stoi na przeszkodzie, żeby przejść w przyszłości na drugą linię, czy oczywiście nawet na trzecią, bo znowu komputery to nie jest czarna magia, więc jeżeli ktoś ma chęć, ma zaparcie, ma czas, ma przestrzeń do nauki, to oczywiście jest się w stanie tego nauczyć.

Natomiast jeżeli mówimy o tej ostatniej ścieżce, czyli ścieżce dla inżyniera bezpieczeństwa,  to tutaj niejako z racji tego, że często gęsto jednak trzeba umieć budować coś, a przez budowanie mam na myśli przynajmniej skryptować, a idealnie to w ogóle już po prostu programować, to jednak ludzie, którzy przychodzą do roli inżyniera, raczej przychodzą z ról mocno technicznych, takich jak Dev, Ops czy po prostu DevOps. Raczej jest mniej osób, które przychodzą tam z typowej administratorki czy z jakości.

Oczywiście, znowu, nie jest tak, że takie osoby się nie pojawiają, ale nie nazwałbym tego jakąś prawidłowością czy patternem. To są raczej takie exceptiony. Natomiast chciałbym dodać jedną rzecz. Można trochę wnioskować z tego, co powiedziałem. Z tego trochę jednak wynika, że w zasadzie wszystkie trzy może nie wymagają, ale mocno czerpią z solidnych podstaw w samym IT.

Czyli dużo łatwiej jest osobie, która ma już jakieś doświadczenie w IT przejść do bezpieczeństwa, niż robić to bez żadnego doświadczenia. I ja tutaj mam taką jedną uwagę. Właśnie, to może teraz pomniejszę zbiór swoich kolegów i koleżanek, natomiast muszę to powiedzieć, muszę wbić tę małą szpileczkę albo wbić ten kij w mrowisko. Jak ktoś się z tym moim zdaniem nie zgadza, że jednak wypadałoby mieć doświadczenie w IT, żeby wejść do cyberbezpieczeństwa, bo to jest taka górka, na której umrę, to jest hill I’m willing to die on. Jeżeli ktoś się ze mną w tym aspekcie nie zgadza, to według mnie ma swój interes w tym, żeby tak było i ten interes najczęściej jest komercyjny.

Ja w cyber siedzę już 20 lat, hobbystycznie, a komercyjnie 15. Widziałem je i lokalnie w kraju, i globalnie w Europie, i ludzi ze Stanów i z Australii też znam. Znam generalnie masę osób, wiem jakie osoby zachodzą daleko, a jakie potykają się o, nazwijmy to, własne nogi. Szybko dochodząc do punktu, którego w zasadzie nie są w stanie przeskoczyć, a nie mogą go przeskoczyć, bo brakuje im fundamentów w IT.

Ogólnie ja mówię stanowcze nie takim dyrdymałom, że nie musisz być w IT, żeby wejść do cyber, czy nie musisz umieć programować, żeby być pentesterem. Oczywiście nikt nic nie musi, problem w tym, że jeśli masz takie braki, to po prostu szybko uderzysz w ścianę i będzie bardzo ci ją trudno przebić głową. Ja takie namawianie ludzi bez doświadczenia w IT do wejścia w cyber porównuję do namawiania ludzi bez odpowiedniej wiedzy do inwestowania swoich oszczędności. Owszem, będą przypadki, w którym się uda, zainwestują i pomnożą ten swój kapitał – tutaj odsyłam do książki Fooled by Randomness od Nassima Taleb’a. On tam tłumaczy, dlaczego będą takie przypadki, ale statystycznie to w większości się nie uda. A oczywiście najlepiej wyjdzie na tym osoba, która nas namawia do wejścia do cyber bez doświadczenia w IT.

 

Tak. Bardzo ciekawy temat. Może spróbujmy chwilkę jeszcze w tym pogrzebać, bo tutaj powiedziałeś o pewnych wzorcach, pewnych patternach, które widzisz, mianowicie, jakie ścieżki rozwoju właśnie w cyber security są wybierane pod kątem wcześniejszych specjalizacji.

Myślę, że to jest bardzo ciekawa i istotna obserwacja, ale też chciałbym odczarować to, że trzeba mieć wcześniej doświadczenia w innych tych dziedzinach, w innych specjalizacjach, żeby dopiero obrać kurs na cyberbezpieczeństwo. Myślę, i tutaj chciałbym Cię zapytać, co Ty o tym sądzisz, że da się wejść do cyberbezpieczeństwa jako, powiedzmy, swojej pierwszej pracy, jako pierwszej specjalizacji, którą wybieramy. I dla tych osób pewnie bardzo ciekawe będzie, jeśli powiesz, jakie wymagania albo doświadczenie jest wymagane w tych poszczególnych ścieżkach rozwoju.

 

Jasne, da się. Natomiast jeżeli obierzemy taką drogę, należałoby zrobić sobie od razu pewne założenie, że podciągniemy swoje fundamenty w pewnych obszarach z biegiem czasu. Czyli przykładowo, jak przed chwilą powiedziałem, że trudno być pentesterem, jeżeli się nie umie programować, no bo trudno jest tak naprawdę testować bezpieczeństwo web aplikacji, jeśli nie umiemy pisać aplikacji. A nawet jeżeli jesteśmy w stanie ją przetestować, to potem trudno nam rozmawiać z programistą, który ma ją na koniec dnia naprawić, bo nie rozumiemy tak naprawdę, jak się pisze aplikację.

Ale oczywiście to nie znaczy, że nie możemy się tego nauczyć. Oczywiście, że możemy. Tylko musimy zrobić sobie od razu założenie, że w pewnym punkcie po prostu nadrobimy tę swoją zaległość i to jest jak najbardziej okej. Natomiast na pewno byłoby łatwiej, mając już jakieś nawet bazowe doświadczenie.

Ale tak, jak mówisz, wiem, że będą ludzie, którzy po prostu będą chcieć wskoczyć w cyberbezpieczeństwo, bo chociażby taki typowy przypadek, gdzie mamy osobę młodą, która poszła na studia i poszła od razu na studia związane z cyberbezpieczeństwem. Czyli tak naprawdę kończy studia i ona chce już iść do pracy jako bezpiecznik. A przecież nie ma doświadczenia komercyjnego w tych innych ścieżkach. I oczywiście może to zrobić, ale będzie musiała poprawić te swoje fundamenty.

Jeżeli mówimy o tej ścieżce analityka bezpieczeństwa, to akurat tutaj jest trochę łatwiej, bo jest i ścieżka certyfikatów, ale nie tylko certyfikatów, bo też ogólnych materiałów w internecie; jest, powiedzmy, trochę bardziej ogólnodostępna, więc można tutaj mocno działać we własnym zakresie. Chociaż jeżeli mówimy o ścieżce testerskiej, to tutaj też nie będzie dużo gorzej. Najgorzej jest oczywiście w ścieżce inżynierskiej. Ale w ścieżce analitycznej możemy działać na własną rękę, nie musimy mieć wcześniej doświadczenia komercyjnego i jesteśmy w stanie w jakiś sposób, mogę zaraz ewentualnie rozwinąć, w jakie dalsze sposoby można to udowadniać, ale jesteśmy w stanie zbudować pewne fundamenty na własną rękę i potem już przyjść do potencjalnego pracodawcy i się czymś pochwalić.

W ścieżce testerskiej jest to w zasadzie nawet jeszcze prostsze, bo mamy takie rzeczy jak programy Bug Bounty, jak konkursy Capture the Flag. Programy Bug Bounty to są takie programy, w których uczestniczą różnego rodzaju duże firmy. Przykładowo Google czy polskie Allegro uczestniczy w Bug Bounty od platformy Intigrity, i jeżeli sobie wejdziemy do Intigrity i znajdziemy ten program Bug Bounty od Allegro, to jesteśmy w stanie tam dostać informacje, które kawałki web aplikacji Allegro jesteśmy w stanie próbować atakować i jeżeli znajdziemy tam jakieś podatności – czyli faktycznie testujemy, wykonujemy faktyczny test bezpieczeństwa – to zgłaszamy to tej platformie, ona się komunikuje z Allegro i potem jest tam cała komunikacja.

I jeżeli to, co znaleźliśmy, jest faktyczną podatnością, no to Allegro po pierwsze ją wyprowadzi, po drugie albo nam zapłaci, albo wyśle nam koszulkę, generalnie coś tam od nich dostaniemy, to już nie ma znaczenia co, ale przede wszystkim my, jako ta osoba, która to wykonuje, jesteśmy w stanie się pochwalić tym, co zrobiliśmy. I to jesteśmy w stanie zrobić tak proaktywnie, czyli możemy to opisać na swoim blogu, a potem taki wpis na blogu możemy podesłać naszemu przyszłemu pracodawcy. Więc możemy budować te fundamenty, te umiejętności nawet nie mając wcześniej konkretnej pracy, do czego oczywiście zachęcam.

Najgorzej jest w ścieżce inżynierskiej. Tutaj powiem tak: o ile ścieżkę testerską i ścieżkę analityczną da się rozpocząć bez jakiegoś konkretnego komercyjnego doświadczenia, to ścieżkę inżynierską jest trudno rozpocząć bez komercyjnego doświadczenia i w jakiejś innej ścieżce. Bo jednak musimy umieć programować, integrować i powinniśmy mieć doświadczenie już z systemami, które są produkcyjne. Więc nie tylko my sobie postawiliśmy jakiegoś laba na wirtualnej maszynie, ale faktycznie działaliśmy w produkcyjnym środowisku. Więc tę ścieżkę inżynierską tutaj jednak bym powiedział, że nie. To raczej nie. To jednak należałoby mieć doświadczenie komercyjne w tych innych ścieżkach.

Testerską czy analityczną da się, ale bez wcześniejszego komercyjnego doświadczenia będzie trochę trudniej, będzie pod górkę. Ale to też nie jest tak, że ta górka jest jakaś bardzo stroma. Po prostu będziemy mieć trochę więcej pracy niż osoba, która ma doświadczenie. Czyli przykładowo, jeżeli ja nie mam żadnego doświadczenia, to będę miał trochę więcej pracy niż osoba, która już teraz jest testerem jakości. Bo ona musi się tylko kilku rzeczy nauczyć i w zasadzie będzie już testować bezpieczeństwo, a ja muszę się nauczyć trochę większej ilości rzeczy.

W ścieżce testerskiej jest to w zasadzie nawet jeszcze prostsze, bo mamy takie rzeczy jak programy Bug Bounty, jak konkursy Capture the Flag. Programy Bug Bounty to są takie programy, w których uczestniczą różnego rodzaju duże firmy. Przykładowo Google czy polskie Allegro uczestniczy w Bug Bounty od platformy Intigrity, i jeżeli sobie wejdziemy do Intigrity i znajdziemy ten program Bug Bounty od Allegro, to jesteśmy w stanie tam dostać informacje, które kawałki web aplikacji Allegro jesteśmy w stanie próbować atakować i jeżeli znajdziemy tam jakieś podatności – czyli faktycznie testujemy, wykonujemy faktyczny test bezpieczeństwa – to zgłaszamy to tej platformie, ona się komunikuje z Allegro i potem jest tam cała komunikacja.

 

Mam tutaj pytanie odnośnie tej ścieżki testerskiej. Tutaj Hollywood bardzo mocno kreuje taki obraz hakera, tak jako osoby w bluzie, która tam poszczególne znaczki w haśle odnajduje i w ten sposób dostaje się do systemów rządowych itd. Włóżmy to oczywiście między bajki, ale chciałbym Cię zapytać, czy bycie pentesterem wymaga jednak takiego backgroundu właśnie troszkę hakerskiego, czyli bardzo dogłębnego, mocnego zrozumienia tego, jak komputer działa, jak sieć działa, jak internet działa, jakie są technikalia, które za tym wszystkim stoją, aby właśnie wyszukiwać różnych podatności, aby mieć w ogóle świadomość, gdzie i czego szukać? Jeden słowem mówiąc, czy pentesterem może zostać ktoś, kto wcześniej był hakerem, czy też po prostu można się tego nauczyć podczas takiej regularnej nauki, jak w przypadku chociażby inżynierii oprogramowania?

 

Jasne, to jest bardzo częste pytanie. Oczywiście, że da się tego nauczyć, nie trzeba być wcześniej hakerem. Oczywiście takie doświadczenie pomoże, ale nie jest ono wymagane. Osobiście miałem takie doświadczenie, tzn. na początku, jak byłem tam nastolatkiem, to hakowałem komputery i włamywałem się na serwery. Generalnie robiłem głupie rzeczy, których nie polecam robić, bo w chwili obecnej to mogłyby mieć jakieś konkretne implikacje. Wtedy to jeszcze nie było tak restrykcyjne. Teraz raczej nie polecam. Ale oczywiście teraz jest multum innych dróg, które można wykorzystać.

Natomiast znam multum świetnych bezpieczników, którzy nie hakowali przed wskoczeniem w cyberbezpieczeństwo. Znam nawet ludzi, którzy w ogóle się jakoś nie interesowali za bardzo hakowaniem. Gdzieś tam może interesowali się jakimś IT jako nastolatkowie, ale hakowaniem się niezbyt interesowali. No a końcem końców skończyli jako pentesterzy i są naprawdę mocni, pracują w jakichś firmach, nawet nie lokalnych, tylko globalnych, które mają naprawdę mocny poziom i albo są testerami, albo są inżynierami. Tylko oczywiście to są ludzie, którzy poświęcili mnóstwo czasu, żeby się douczyć, i przede wszystkim mieli tzw. hacker mindset, czyli ogólnie byli ciekawi względem technologii, i ta ciekawość na pewno ma bardzo duże znaczenie, bo technologia tech idzie cały czas do przodu i robi to bardzo szybko.

To szczególnie widać w ostatnich miesiącach na AI, gdzie tak naprawdę te zmiany mamy z tygodnia na tydzień. I jeśli technologia nas nie interesuje, no to w zasadzie szybko zostaniemy w tyle.

Więc odpowiadając na pytanie, czy trzeba mieć, nazwijmy to taką hakerską przeszłość, nie, nie trzeba. Ale należałoby mieć albo wyrobić w sobie, bo to też nie jest coś, z czym się człowiek po prostu rodzi, to da się wyrobić, tak samo jak dyscyplinę, da się wyrobić taką ciekawość, więc należałoby mieć ten hacker mindset, czyli po prostu ciekawość względem swojej pracy względem po prostu komputerów, względem technologii.

Bo jeżeli jesteśmy ciekawi tego, nad czym pracujemy, no to poświęcimy kolejną godzinę, kolejną dwie godziny na to, żeby po prostu to lepiej poznać. A na koniec dnia różnica pomiędzy tymi, którym się udaje, a tymi, którym się nie udaje, najczęściej leży po prostu w wytrwałości, w dojściu do celu, a nie w jakichś ukrytych talentach.

 

Czy gdybyś zaczynał dzisiaj swoją przygodę z cyberbezpieczeństwem, to rozpoczynałbyś od właśnie takich prób hakowania komputerów, może lokalnej sieci, ogólnego pentestingu, nazwijmy to w ten sposób, hakowania czegokolwiek? Myślisz, że to jest coś, co później definiuje, jakie masz właśnie podejście do rozwoju w tej branży? Coś daje, czego nie jesteś w stanie wynieść, np. kończąc regularne studia, kończąc kursy?

 

To jest dobre pytanie, bo można na nie odpowiedzieć na dwa sposoby. W zależności jak będę chciał zrozumieć to, o co pytasz, spróbuję omówić obydwa. Mianowicie: czy robiłbym przykładowo to, co robiłem, jak ja zaczynałem? Nie, odradzam hakowanie nieswoich komputerów, jest to jest to niefajne i jest to mało etyczne, ja byłem po prostu młody i narwany. Ale też nie miałem żadnych innych sposobów na naukę, po prostu kiedyś tak to się robiło.

Teraz jest dużo innych, lepszych sposobów na uczenie się tych umiejętności, które nie tylko są lepsze, bo po prostu ułatwiają nam naukę, ale są też lepsze, bo możemy nawet zacząć zarabiać jakieś pieniądze czy zbierać jakiegoś różnego rodzaju nagrody. Natomiast jeżeli będziemy hakować nieswoje komputery, to raczej nie powinniśmy się tym chwalić, bo na pewno nie zbierzemy za to żadnych nagród. Możemy sobie tylko przysporzyć niepotrzebnych kłopotów.

Więc odradzam hakowanie nie swoich komputerów. Na pewno doradzam zainteresowanie się dostępnymi sposobami uczenia się tego i nieczekanie na to, co przykładowo będzie na studiach albo co będzie w pracy, czyli namawiam do bycia proaktywnym w nabywaniu umiejętności, w nabywaniu wiedzy.

Jak to można teraz robić? Tak jak wcześniej wspomniałem, mamy te platformy Bug Bounty, na których można ćwiczyć, rozwijać swoje umiejętności i można też na nich zarobić jakieś pieniądze, jeżeli bierzemy udział w tych programach, które oferują nagrody pieniężne, a te programy mają to jasno wylistowane, więc to nie jest tak, że nie wiemy z góry. Możemy wybrać tylko te, które oferują pieniądze i jeżeli znajdziemy coś w firmach, w systemach tych firm, to najczęściej po prostu dostaniemy za to jakieś pieniądze. To nie są Bóg wie jakie sumy, bo oczywiście zdarzają się nagrody typu 100 tys. dolarów, ale raczej nie należy liczyć na taką nagrodę, raczej należałoby liczyć na jakieś pomniejsze, 500, 1000 dolarów, ale w dalszym ciągu to są całkiem fajne pieniądze, biorąc pod uwagę, że możemy mieć 15 lat i możemy to robić. Dla piętnastolatka tysiąc dolarów, jeszcze bawiąc się tak naprawdę, to myślę, że fajny deal. Też chciałbym mieć taki deal.

Mamy też te konkursy Capture the Flag. Capture the Flag to jest trochę co innego niż Bug Bounty. Można na to popatrzeć właśnie dokładnie jak na takie konkursy, które trwają 24 lub 48 godzin. One często są organizowane w weekendy, czyli np. zaczynają się w piątek i kończą się w niedzielę, gdzie mamy parę zadań z kilku kategorii, np. jest kategoria bezpieczeństwa web aplikacji, jest kategoria eksploatacja, taka niskopoziomowa, jest kategoria reverse engineering, jest kategoria steganografii, to zależy od konkretnego Capture the Flag, od konkursu i tam możemy oczywiście grać solo, możemy grać w zespole.

I tutaj namawiam do znalezienia zespołu albo założenia swojego, dlatego że łatwiej się uczy człowiek w zespole, po prostu współpracując z innymi, więc namawiam do działania w grupie, a nie solo. Ale oczywiście solo też można, można wystartować samemu i po prostu, nazwijmy to, zanurzyć te palce w wodzie i zobaczyć, że woda wcale nie jest taka straszna.

Więc mamy Bug Bounty, mamy Capture the Flag i jeżeli ktoś po prostu wpisze te keywordy w Google, to bez problemu znajdzie odpowiednie rzeczy, natomiast ja Tobie, Krzysiek, podeślę linki do przynajmniej większych platform Bug Bounty i do takiego jednego dużego agregatu dla konkursów Capture the Flag, gdzie można sobie zobaczyć daty najbliższych. I tu jeszcze dodam, że są takie w cyklu rocznym przynajmniej jedno, o ile dobrze pamiętam, Seesaw chyba z New Yorku. Takie Capture the Flag, które jest nastawione od razu na poziom bardziej właśnie licealny, high school. Czyli to nie jest nastawione na ludzi, którzy mają Bóg wie jak dużo doświadczenia, tylko właśnie dla takich początkujących. I takich Capture the Flag też jest więcej. Ja po prostu w głowie nie mam, bo już w tej chwili po prostu się tym nie zajmuję.

Natomiast w tym wszystkim, czyli robiąc cokolwiek, bawiąc się w te Bug Bounty, bawiąc się w te Capture the Flag, albo bawiąc się na takich stronach jak Hack the Box czy Try Hack Me, namawiam do dzielenia się własną drogą, tak jak wcześniej już powiedziałem, do dzielenia się własną drogą na jakimś swoim blogu, na jakichś swoich social mediach, to nie ma znaczenia gdzie, ale namawiam do dzielenia się tym, dlatego że będziemy dokumentować swoją drogę, raz, że nam samym będzie łatwiej się uczyć, bo jeśli coś zrobimy, a potem to zapiszemy i jeszcze spróbujemy wytłumaczyć to osobie trzeciej, to my sami na tym korzystamy najwięcej, ale poza tym oczywiście budujemy pewnego rodzaju ślad, który potem jesteśmy w stanie przedstawić potencjalnemu pracodawcy, albo on w ogóle nas jest w stanie sam znaleźć, po to, żeby po prostu dostać już pracę w branży.

Więc taka dokumentacja swojej pracy jest czymś, do czego ja bardzo, bardzo mocno namawiam wszystkie osoby, które chcą się bawić w Capture the Flag, w cokolwiek.

Innym sposobem pokazania wiedzy są certyfikaty, chociaż tak naprawdę one po pierwsze swoje kosztują, bariera wejścia jest wyższa, więc jeżeli ktoś zaczyna, to ja odradzam certyfikaty, bo certyfikaty mają swoją konkretną rolę. One potwierdzają, że umiesz to, z czego egzaminuje Cię certyfikat. To ma swoją wartość, ale ta wartość nie jest taka duża, jak mogłoby się wydawać, bo mając takiego bloga aktywnego, jak na nim opisujemy te swoje rzeczy, to tak naprawdę to też pokazuje, że mamy jakąś wiedzę i jeżeli mówimy, że się na czymś znamy, no to faktycznie się na tym znamy, bo mamy jakiś dowód spełnienia tego.

I jeszcze jedna rzecz, którą (trochę autopromocja) muszę tutaj dorzucić, jak wspomniałeś na samym początku, ja mam swoje szkolenie ofensywne, testowanie web aplikacji, które adresuje dokładnie ten problem, czyli jak nauczyć się testować bezpieczeństwo web aplikacji, ale z tą gwiazdką, a to jest duża gwiazdka, że ten program kieruje do ludzi, którzy już pracują w procesie wytwórczym.

Czyli jeżeli ktoś jest programistą, jeżeli ktoś jest inżynierem QA, testerem czy opsem, to super, to ten program jest dla tej osoby, ale jeżeli ktoś nie pełni tych ról, to oczywiście, że się czegoś nauczy, ale czy to jest idealny program dla takiej osoby? Nie sądzę, nie jestem pewien. Wydaje mi się, że jednak ja wiem, jak go budowałem, i budowałem go raczej dla ludzi, którzy już mają konkretne doświadczenie w procesie wytwórczym i te osoby wyciągną najwięcej wartości.

Więc jeżeli ktoś nie ma, to zawsze może wejść, popatrzeć na agendę tego, co tam mam i oczywiście te wszystkie zasoby są za darmo dostępne w internecie i może na własną rękę douczyć się pewnych rzeczy. Więc przynajmniej ma pewnego rodzaju mapkę, czego może się nauczyć i więcej skorzysta, jak zrobi to na własną rękę, bo jednak ja celuję w ludzi, którzy zarabiają na tym, czym się zajmują, bo cyber dla nich powinien być dodatkową umiejętnością, a nie czymś, co jest dla nich jedyną jakąś drogą.

 

Dzięki za takie szczere postawienie sprawy. Oczywiście link do Twojego szkolenia będzie w notatce do odcinka dla osób zainteresowanych. Myślę, że to jest bardzo wartościowa rzecz, warto tam zerknąć.

Ja natomiast chciałbym się uczepić jednego wątku, o którym tutaj wspomniałeś, mianowicie certyfikatów, bo to jest zawsze taki element świętej wojny naturalnie, wiadomo, różne są opinie. Wspomniałeś, że startując w tej branży, może niekoniecznie warto jest inwestować w certyfikaty, są lepsze sposoby, żeby pokazać potencjalnemu przyszłemu pracodawcy, że wykonaliśmy pewną pracę, że pewien materiał mamy opanowany.

Ale co myślisz na temat certyfikatów, idąc dalej, rozwijając się tutaj właśnie w tej dziedzinie? Albo w sytuacji, kiedy pracodawca jest w stanie nam jakoś dołożyć się do tego certyfikatu, być może sfinansować? Czy szedłbyś w tym kierunku? Uważasz, że to może być wartościowe właśnie w rozwoju kariery, być może w szukaniu zleceń, jeśli jesteśmy freelancerem? Jaka jest Twoja opinia?

 

Moja opinia jest taka, że na pewno będzie przydatne. Czy jest super wymagane? Nie, oczywiście są ludzie, którzy nie mają certyfikatów i sobie świetnie radzą. Ja sam nie mam jakoś dużo certyfikatów i też nie sądzę, żeby był to jakiś bloker. Natomiast jeżeli jesteśmy w sytuacji, gdzie możemy sobie pozwolić na zrobienie jakiejś większej ilości certyfikatów, szczególnie będę kierował to do osób, które są po prostu młodsze, bo gdybym ja miał robić certyfikaty w przedziale 20–27 lat, to pewnie zrobiłbym ich dużo więcej.

Ale że ja zacząłem się obracać w usługach consultingowych, czyli tam, gdzie certyfikaty mają większe znaczenie już po tym wieku, to one dla mnie po prostu miały dużo mniejszą wartość. Zrobiłem, co tam musiałem zrobić, dlatego, że…* – i to jest duża gwiazdka, certyfikaty często są potrzebne do zleceń w publicu. Więc jeżeli mamy np. firmę konsultingową bezpieczeństwa i taka firma chce wziąć udział w przetargu i wykonać jakiś test bezpieczeństwa dla instytucji państwowej, to ta instytucja państwowa jest zobligowana do rozpoczęcia przetargu na ten test. I w tym przetargu oczywiście musi wylistować pewne warunki, i jednym z tych warunków będą certyfikaty, które muszą posiadać osoby wykonujące taki test.

Oczywiście te warunki czasami są bardziej wyśrubowane, czasami są bardziej otwarte, natomiast raczej zawsze jest tak, że osoby wykonujące dany test, i też często nadzorujące, muszą mieć jakiś określony zestaw certyfikatów. A więc niejako w interesie firm dostarczających tego typu usługi jest, żeby ich pracownicy mieli te certyfikaty. I stąd pracownicy tych firm, które dostarczają przykładowo testy penetracyjne, często mają sporo tych certyfikatów, ale nie wynika to z tego, że po prostu trzeba mieć certyfikaty, bo one tak dużo dają. Wynika to po prostu z tego, że certyfikaty są przydatne, żeby podchodzić do pewnego rodzaju zleceń.

Ale też nie chcę, żeby to wybrzmiało tak, że ja jakoś jestem mocno przeciwny certyfikatom, bo oczywiście w certyfikatach również robiąc, ucząc się do certyfikatów, również możemy się sporo nauczyć i polepszyć, nazwijmy to, swoją trajektorię, trajektorię swojej kariery, Ale tutaj ważny jest po prostu ten punkt w czasie, czyli na początku swojej kariery certyfikaty mają dość dużą wagę. Jak jesteśmy już później, dalej w tej swojej karierze, to waga certyfikatów zaczyna być po prostu coraz lżejsza, aż dojdziemy do punktu, w którym tak naprawdę nikt nie będzie nas pytał o certyfikaty, bo nie będzie to nikogo interesować.

Wiesz, nikogo nie interesuje, czy Piotr Konieczny ma certyfikat z bezpieczeństwa. Nikogo to nie interesuje. Ale jeżeli nie jesteśmy Piotrem Koniecznym, nie mamy takiego mocnego brandu, to już potencjalnego pracodawcy albo zleceniodawcy będzie interesował, czy mamy jakiś certyfikat. Więc to mocno zależy od punktu kariery, w którym jesteśmy. Na pewno na tym nie stracimy. Czyli jeżeli zrobimy sobie jakieś certyfikaty, to na pewno na tym nie stracimy. Możemy tylko zyskać, pytanie, jak dużo.

 

Faktycznie ma to sens. Jednym z takich głównych wątków naszej rozmowy, który sobie postawiliśmy na początku, jest próba odpowiedzenia na pytanie, jakie specjalizacje IT, takie wcześniejsze związane z naszym wcześniejszym doświadczeniem, ułatwiają przejście właśnie do tej domeny cyber security.

I tutaj mówiłeś o tych różnych ścieżkach rozwoju i wspomniałeś, że tester bezpieczeństwa jest jedną z takich potencjalnych specjalizacji. Jestem ciekawy, czy można postawić jakąś analogię pomiędzy testerem oprogramowania, takim klasycznym, a właśnie testerem bezpieczeństwa. Czy ta praca takiego testera klasycznego, nazwijmy to, polegająca na przechodzeniu, wykonywaniu pewnych przypadków testowych, sprawdzaniu, czy nowe feature’y, nowe funkcjonalności jakoś nam nie zepsuły już wcześniej działających, działa też w ten sam sposób w przypadku testów bezpieczeństwa, czy tam jest większe pole na jakąś swobodę, jakąś kreatywność, jakieś wynajdywanie dziwnych przypadków, które mogą nam właśnie wykryć luki w bezpieczeństwie, jak to wygląda?

 

Znowu, brzmi prosto, ale odpowiedź nie będzie taka prosta. To zależy, ale jeśli mielibyśmy uogólnić, potem doszczególnię, od czego to zależy, ale jeżeli mielibyśmy uogólnić, to tak jak wcześniej powiedziałem, bezpieczeństwo jest podzbiorem, jest odnogą jakości, więc w zasadzie hacking security to tak trochę pół żartem, pół serio, ale to jest taki glorified QA. W zasadzie zapewnianie jakości. I to nie jest żadna tak naprawdę jakaś czarna magia, pomimo tego, że może bezpiecznicy by chcieli i przez długi czas próbowali utrzymywać to jako czarną magię, ale nie, to nie jest czarna magia.

I powiem więcej, na zachodzie, szczególnie w US, widać już mocny trend i to nie od wczoraj, tylko od kilku lat, gdzie to podstawowe testowanie bezpieczeństwa, nazwijmy to security testing, jak najbardziej przechodzi w ręce ludzi od jakości czy deweloperów. Więc  przestaje to być jakaś domena tylko pentesterów. Pentesterzy oczywiście w dalszym ciągu jako pewna specjalizacja są przydatni, ale oni mogą się wtedy skupić właśnie na tych bardziej wyśrubowanych, bardziej zaawansowanych technikach łamania aplikacji, a nie na tych nisko wiszących owocach, takich jak jakieś podstawowe XSS-y.

Co oczywiście ma swoje duże plusy, bo osoby, które lubią hakować, z mojego doświadczenia nie lubią dziesiąty raz zgłaszać tego samego XSS-a, bo one chciałyby takie mięso, one chciałyby rozwalić tą aplikację. A w procesie przykładowo wytwórczym nie ma znaczenia, czy Ty napiszesz exploita, czy nie. Jest tylko znaczenie, czy znalazłeś tą podatność, bo z założenia ta podatność tak naprawdę jest jakimś bugiem. Każda podatność to bug, ale nie każdy bug to podatność.

Więc trochę do brzegu, pentesty są rysowane jako taka czarna magia, ale w zasadzie na koniec dnia to nie jest żadna czarna magia. Jak najbardziej pentesty, testowanie bezpieczeństwa web aplikacji opiera się o konkretne metodyki, o konkretne standardy i jak najbardziej można je realizować nawet tak checklistowo.

Jednym z takich standardów jest Web Security Testing Guide WSTG z OWASPA, który jeżeli nasi słuchacze wejdą do tego dokumentu, to zobaczą, że tam nawet konkretnie opisują w trzeciej części, jak testować konkretne przypadki testowe, czyli np. mamy podatność Insecure Direct Object Reference i oni tam opisują, jak przetestować aplikację, żeby zobaczyć, czy jest ta podatność.

A trochę odwracając i przechodząc w tę checklistę, no to mamy też Application Security Verification Standard, ASVS, który agreguje pewne kontrole, pewne kontrolki do weryfikacji pod kątem bezpieczeństwa w web aplikacjach, żeby osiągnąć określony poziom tego standardu. I odwracając te kontrole do weryfikacji, możemy sobie stworzyć oczywiście przypadki testowe. Bo jeżeli jest napisane, że aplikacja tam powinna mieć nagłówki bezpieczeństwa, to możemy to odwrócić i powiedzieć: a dobra, to czyli muszę przetestować, czy aplikacja ma nagłówki bezpieczeństwa, czy ich nie ma.

Tutaj odsyłam do swojego YouTube’a, gdzie powiedziałem trochę więcej o tych narzędziach. Natomiast tak, testowanie mocuje się konkretnie w narzędziach, w standardach. To nie jest czarna magia, to nie jest żadne voodoo dostępne dla wybrańców. Jak najbardziej można w to wskoczyć. Nie każdy będzie chciał iść dalej, nie każdy będzie chciał być pentesterem, bo to już jest konkretna specjalizacja, ale żeby przetestować bezpieczeństwo u aplikacji, powiedzmy, na poziomie drugim standardu Application Security Verification Standard, to ja myślę, że każdy tester QA sobie z tym jak najbardziej poradzi. Szybciej lub może trochę wolniej, zależy, jaką ma bazę wiedzy w danym punkcie czasu, ale myślę, że jeżeli ktoś jest na poziomie seniora, to spokojnie sobie z tym poradzi.

I powiem więcej, na zachodzie, szczególnie w US, widać już mocny trend i to nie od wczoraj, tylko od kilku lat, gdzie to podstawowe testowanie bezpieczeństwa, nazwijmy to security testing, jak najbardziej przechodzi w ręce ludzi od jakości czy deweloperów. Więc  przestaje to być jakaś domena tylko pentesterów. Pentesterzy oczywiście w dalszym ciągu jako pewna specjalizacja są przydatni, ale oni mogą się wtedy skupić właśnie na tych bardziej wyśrubowanych, bardziej zaawansowanych technikach łamania aplikacji, a nie na tych nisko wiszących owocach, takich jak jakieś podstawowe XSS-y.

 

Powiedziałeś całkiem sporo o ścieżkach rozwoju, powiedziałeś o tym, jakie są wymagania na tych ścieżkach, trochę zdradziłeś, jak wygląda praca właśnie w tych poszczególnych różnych odnogach cyber security, to teraz powiedz, proszę, z pierwszej ręki, jak ten rynek pracy wygląda, w sensie, czy faktycznie jest takie duże zapotrzebowanie, czy zarobki są, powiedziałbym, daleko satysfakcjonujące, jak Ty ten rynek widzisz, jak Ty go obserwujesz?

 

Dobrze, jak wygląda branża od środka? W zasadzie to akurat jest dość proste pytanie, easy peasy. Branża wygląda całkiem dobrze i w zasadzie z roku na rok wygląda lepiej, wszystko się otwiera i rozrasta, i oczywiście mówię i o możliwościach rozwoju, czyli pojawia się więcej ról, więcej stanowisk na określone role, więc, powiedzmy, jako kariera ma potencjał, przynajmniej tak wygląda, że ma potencjał.

Co do zarobków… Powiem tak, są w górnym przedziale płac w IT, więc nie ma na co narzekać. Te wszystkie rankingi, które są gdzieś tam robione przez Just Join IT i inne agregaty, nie odbiegają od rzeczywistości, czyli można im zaufać. Da się zarabiać w cyberbezpieczeństwie całkiem dobre pieniądze. W zasadzie, jeśli mówimy o ludziach z takim doświadczeniem, powiedzmy senior-senior, np. o moim przypadku, to to są naprawdę dobre pieniądze i w zasadzie jest się z czego cieszyć, i można powiedzieć, że być wdzięcznym za obrót tej całej sytuacji na rynku pracy.

Oczywiście w chwili obecnej każdy wie, że mamy pewnego rodzaju mniejszy lub większy kryzys w IT, nie tylko w IT, generalnie jest pewnego rodzaju spowolnienie na rynkach od roku, więc da się to odczuć, ale w cyber z moich obserwacji przebiega to dość lekko. Czyli nie przyglądałem się innym kategoriom pracy w IT, ale w cyber przebiega to dość okej.

Więc reasumując, ścieżki rozwoju są fajne. Też na samym początku mówiłem, że jest ich dużo, pojawiają się nowe. Jest to ścieżka kariery o pewnym fajnym potencjale na przyszłość, a zarobkowo jest bardzo dobrze.

 

To optymistycznie. Wiem, że Ty masz takie doświadczenie też developerskie, związane z tworzeniem aplikacji. I właśnie zastanawiam się, czy ten fakt, te doświadczenia, w jakiś sposób znaczący przełożyły się na to, w jaki sposób dzisiaj pracujesz, jak wykonujesz swoje obowiązki, czy przełożyły się na to, że lepiej jest Ci po prostu pracować w cybersecurity, ponieważ rozumiesz pewne aspekty związane z softwarem i czy w związku z tym według Ciebie bycie programistą to jest ta ścieżka, która umożliwia łatwiejsze wejście do cyber security albo też później sprawniejsze działanie właśnie w tej branży, czy też może chciałbyś tu powiedzieć o innych specjalizacjach, które równie dobrze przełożą się na nasz sukces zawodowy właśnie w cyber security?

 

Z mojego punktu widzenia to moje doświadczenie programistyczne dało mi bardzo wiele, bo ja wszedłem do cyberbezpieczeństwa od strony cyberbezpieczeństwa, więc się tym interesowałem jako nastolatek. Potem wskoczyłem w security research, szukałem podatności w aplikacjach takich jak przeglądarki, jak systemy operacyjne, jak procesory tekstu, i pisałem na nie exploity. Następnie po tym wszedłem jako programista, software engineer, pisałem w PHP i w Ruby on Rails na produkcji i potem wróciłem do cyberbezpieczeństwa.

Natomiast to doświadczenie programistyczne zmieniło całkowicie moje spojrzenie i na bezpieczeństwo, i ogólnie, szerzej na IT. Wtedy zrozumiałem bardzo dużo różnych rzeczy, m.in. zrozumiałem drugą stronę, bo jeżeli wcześniej szukałem podatności, błędów w aplikacjach, a potem sam byłem osobą, która tworzyła te błędy, to zrozumiałem niejako genezę błędów. Zrozumiałem, że to nie jest tak, że wystarczy kogoś wyedukować i nie będzie popełniał błędów, bo te błędy to się popełnia z zupełnie innych powodów.

I programy, aplikacje czy systemy posiadają podatności nie dlatego, że tam ludzie mają małe pojęcie, bo nawet ci, którzy mają duże pojęcie, też wprowadzają podatności. Czemu? Bo na koniec dnia liczy się dowożenie feature’ów biznesowi, bo biznes musi mieć pieniądze. I jeżeli pograliśmy przez chwilę na boisku w tej roli osoby, która musi dowozić feature’y, to wtedy łatwiej nam jest zrozumieć, jak wracamy do tej pozycji bezpiecznika, że a dobra, te problemy nie powstają dlatego, że ty czegoś nie wiesz, tylko no po prostu, bo tak wyszło, to weźmy teraz, zróbmy coś, żeby ich nie było. Albo zastanówmy się, co możemy zrobić, co możemy dodać do procesu, żeby wyłapać je na wcześniejszym etapie procesu wytwórczego.

Więc zrozumienie też całości procesu wytwórczego, SDLC, różnych jego faz, ale nie tylko pod takim technicznym kątem, że tu mam jakiś pipeline i coś mi się tam dzieje, tylko też na poziomie osoby, która bierze udział w tym procesie, czyli bierze udział w sprincie, bierze udział w retro, bierze udział w myśleniu o produkcie, w jakimś designie, gdzie bezpiecznicy, szczególnie ofensywni, raczej nie biorą udziału w takich spotkaniach, to jest mega wartość, którą ja polecam każdemu bezpiecznikowi, który myśli o swojej karierze poważnie.

Bo szczególnie jeżeli mówimy o testowaniu, jeżeli ktoś testuje bezpieczeństwo, to raczej powinien rozumieć, jak się wytwarza i utrzymuje system IT. I jeżeli to rozumie, to po prostu będzie mu łatwiej pracować, będzie bardziej efektywny. I to nie jest też tylko gdzieś tam moje zdanie, bo zaraz ktoś może powiedzieć: Andrzej, ale ja znam świetnych bezpieczników, którzy nie mają takiego doświadczenia. Oczywiście, ja też znam, ale nie bez powodu ci ludzie często po x latach są w tym samym punkcie, w którym byli parę lat temu. To jest jeden z tych powodów.

I to moje zdanie, że jednak programowanie, takie faktyczne programowanie jako software engineering, a nie, że ja coś tam zakoduję sobie ze stacku overflowa, pomaga zrozumieć, jak działają komputery, a jednak jeżeli pracujemy z komputerami, to powinniśmy rozumieć, jak działają komputery.

Więc ja mam takie zdanie, ale inni ludzie mnie w nim też utwierdzają i to ludzie, których ja sam uważam za jakieś ikony cyberbezpieczeństwa, np. Halvar Flake, czyli to jest pseudonim, a imię to Tomasz Dullien, bardzo znany haker. Większość słuchaczy pewnie nie będzie kojarzyła w ogóle, kto to jest, bo to jest bardzo znana osoba, ale w takim niszowym polu niskopoziomowego bezpieczeństwa. On też miał taki jeden wywód właśnie o tym, że pracując w IT należałoby umieć programować, więc mocno polecam każdemu zdobycie tego doświadczenia.

Ale przepraszam Cię, Krzysztofie, uleciała mi druga część Twojego pytania, bo odpowiedziałem na pierwszą, ale na drugą jeszcze nie odpowiedziałem.

 

Wydaje mi się, że tutaj chodziło o to, czy właśnie programiści wynoszą to zrozumienie. Tutaj potwierdziłeś, że jak najbardziej i w związku z tym efekty ich pracy po tym przebranżowieniu do cybersecurity mogą być po prostu lepsze. Ale pytałem też o to, czy jakieś inne specjalizacje IT są równie skuteczne albo przynajmniej uważasz, że jak gdyby ma sens zdobywanie doświadczenia w jakichś innych właśnie branżach IT po to, żeby później efektywnie poruszać się w celu bezpieczeństwa.

 

Jasne. No więc oczywiście jeżeli ktoś ma doświadczenie w administratorce, w administrowaniu systemami, w operacjach, to to też jest bardzo, bardzo wartościowe doświadczenie, którego być może nie wykorzystamy tak efektywnie w testowaniu bezpieczeństwa web aplikacji, ale oczywiście testowanie bezpieczeństwa możemy też testować infrastrukturę. I tam już zrozumienie tego, jak działają sieci, jak się konstruuje systemy, co to jest segmentacja, ale nie segmentacja na poziomie procesora, tylko segmentacja na poziomie sieci, to to są wszystkie koncepty, które będą tylko działać na naszą korzyść.

I znowu, jeśli chcemy zajmować się np. bezpieczeństwem infrastruktury, co ma jak najbardziej sens, bo przecież możemy się chcieć zajmować bezpieczeństwem infrastruktury chmurowej, to takie doświadczenia administratorskie jest mega przydatne. I nie chodzi mi tylko o technikalia. Chodzi mi też o wszystko wokół budowania i utrzymywania infrastruktury.

Więc jeżeli wejdziemy tylko od strony bezpieczeństwa, to często gęsto mamy te techniczne umiejętności, jesteśmy w stanie ocenić coś pod kątem bezpieczeństwa, ale brakuje nam tej wiedzy, tego szerszego zrozumienia całego procesu. I przykładowo potem kończymy z takimi rekomendacjami, których się nie da tak naprawdę zaaplikować. Na poziomie procesu, na poziomie organizacji nie da się ich zaimplementować w systemie. A dla nas one brzmią, no wystarczy, że zrobicie to. No nie wystarczy, że zrobimy tego, bo nie możemy tego zrobić. Nie technicznie, ale organizacyjnie, procesowo nie jesteśmy w stanie tego zrobić. Bo np. zrobienie tego rozwali nam proces taki ogólny, organizacyjny, i się zakopiemy w pracy.

Więc zrozumienie ogólnego potoku pracy Jest mega przydatne, i tutaj też oczywiście odsyłam wszystkich do dwóch książek, które chyba zawsze polecam. The Phoenix Project o tym, jak działa DevOps i protoplastę tej książki, czyli The Goal. Jedna i druga książka skupia się na omawianiu teorii ograniczeń, Theory of Constraints, która tłumaczy, dlaczego w organizacjach pewne rzeczy zajmują tyle, ile zajmują. Więc mega polecam wszystkim ludziom, którzy pracują w IT, I zacząć od książki The Phoenix Project. To jest jedna z książek, które wciągnąłem bardzo szybko, jak zacząłem je czytać i po prostu miałem flashbacki z pracy. Cały czas było, co stronę, o kurczę, ja to znam, o kurczę, ja to znam.

 

Tak, tak. Życiowa bardzo książka. Jak najbardziej polecam.

Dobrze, Andrzej, skoro przeszedłeś już do rekomendacji książkowych, to myślę, że z takim podcastowym zwyczajem oznacza to, że pewnie zbliżamy się do końca naszej rozmowy. Cieszę się bardzo, że nakreśliłeś właśnie tę branżę tak bardziej od wewnątrz, pokazałeś też ścieżki rozwoju, pokazałeś, jakie wymagania i oczekiwania stoją przed osobami, które chciałyby się właśnie w tym kierunku zawodowym skierować. Myślę, że to jest taka fajna tutaj mapa, która wskaże drogę tym, którzy słuchają tego podcastu, aby właśnie dowiedzieć się, jak mogą do tej branży wskoczyć, więc bardzo takie, wiesz, praktyczne i życiowe podejście przekazałeś.

Dziękuję Ci bardzo za nasze spotkanie, dzięki wielkie za rozmowę.

 

Dziękuję, Krzysztofie. Ja mam jeszcze jedną małą uwagę. I tutaj zrobię promocję Twojej książki. Bo jestem już dalej niż w połowie i mega polecam książkę Krzyśka o brandzie w IT. Ja generalnie od paru lat też buduję swój brand i jednak przeczytanie tej książki nawet mnie otworzyło kilka szufladek w głowie, a już trochę doświadczenia mam. Jest naprawdę dobrze napisana, bardzo miło się czyta, bardzo też sprawnie. 

Są książki, które się czyta po prostu topornie. Tę Twoją książkę czyta się bardzo sprawnie, propsy dla Ciebie i oczywiście dla edytora, bo ja wiem, że pewnie jakiś swój wkład mocny miał. Mega polecam wszystkim ludziom, którzy pracują w IT, ale nie tylko ludziom, którzy pracują w IT, sięgnąć po Twoją książkę. Jest mega, mega wartościowa dla każdej osoby, która gdzieś chce popracować nad swoim brandem, a jak w książce mówisz, brand ma każdy, tylko nie każdy aktywnie nad nim działa, więc polecam aktywne działanie nad swoim brandem. Twoja książka 10 na 10.

 

Dzięki, dzięki wielkie, Andrzej, cieszę się bardzo, że przypadła Ci do gustu i że taki wyjadacz personal brandingowy jak Ty mógł też znaleźć tam jakieś smaczki dla siebie, bardzo mnie to cieszy.

Wiesz, tutaj rozmawiamy godzinę o tym temacie, ale zdaję sobie sprawę, że to jest dopiero wierzchołek góry lodowej, więc poproszę Cię, żebyś wskazał, gdzie słuchacze mogą się udać, aby dowiedzieć się więcej i gdzie można Cię znaleźć w internecie.

 

Oczywiście wszystkie linki będą w referencjach, więc najłatwiej będzie po prostu przejść i tam sobie przeklikać. Ja powiem, że najbardziej aktywny jestem na LinkedInie i oczywiście zachęcam wszystkich do uderzenia do mnie, do wejścia w znajomość, do dołączenia mnie do swojej sieci kontaktów, ale nie follow, tylko connect. Więc wiecie, Linkedin to robi tak, że najpierw pokazuje follow, a ja zachęcam do po prostu kliknięcia tam trzy kropeczki i dodaj do sieci kontaktów. I po prostu połączmy się na LinkedInie i jeżeli ktoś będzie miał dalsze pytania, to postaram się na nie odpowiedzieć.

W innych sieciach społecznościowych nie jestem jakoś za mocno aktywny. Mam kanał na YouTube, ale w chwili obecnej przychodzi małą reorganizację. Tutaj dopiero będę bardziej aktywny. I mam też konto na Instagramie, ale na Instagramie też jakoś super mocno nie jestem, przynajmniej na dzień dzisiejszy, ale to też się zmieni w nadchodzących tygodniach, miesiącach. Więc najlepiej zacząć od LinkedIna.

 

Z przyjemnością zatem będę obserwował te miejsca, które przechodzą rebranding. Oczywiście wszystkie te namiary, wszystkie materiały i linki standardowo znajdziecie w notatce do odcinka.

Andrzej, jeszcze raz wielkie dzięki za rozmowę i do usłyszenia. Cześć!

 

Na razie!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach.

Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak przejść do cyberbezpieczeństwa z innej specjalizacji IT.

Do usłyszenia w następnym odcinku. Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.