Przebranżowienie do cyberbezpieczeństwa: plan na 90 dni

Punkt startu: czy cyberbezpieczeństwo jest dla ciebie?

Szybka autodiagnoza w 10 pytań

Przebranżowienie do cyberbezpieczeństwa w 90 dni wymaga dwóch rzeczy: trzeźwej diagnozy punktu startu i brutalnie szczerej rozmowy ze sobą o czasie oraz motywacji. Zanim zaczniesz układać plan nauki cyberbezpieczeństwa, odpowiedz na kilka prostych pytań. Najlepiej na kartce, bez upiększania.

Zadaj sobie kolejno:

• Czy masz dziś jakiekolwiek doświadczenie w IT (helpdesk, administracja, testy, wsparcie biurowe, Excel, praca z systemami)?
• Ile realnie godzin tygodniowo możesz przeznaczyć na naukę przez 90 dni (nie życzeniowo, tylko rzeczywiście)?
• Czy masz w domu spokojne miejsce, w którym możesz pracować przy komputerze przez 2–3 godziny bez ciągłych przerw?
• Czy lubisz rozwiązywać zagadki, łamigłówki, debugować problemy, nawet jeśli odpowiedź nie pojawia się od razu?
• Jak reagujesz na brak jasnej instrukcji? Czekasz, aż ktoś powie, co dokładnie zrobić, czy próbujesz różnych rozwiązań?
• Czy kiedykolwiek „rozkręcałeś” (dosłownie albo metaforycznie) jakiś system, aplikację, sprzęt tylko po to, by zrozumieć, jak działa?
• Czy stresuje cię praca pod presją czasu i ciągłe zmiany priorytetów, czy raczej cię mobilizują?
• Jak znosisz monotonię? Bo analiza logów, korelacja zdarzeń czy twarde laby bywa powtarzalna i żmudna.
• Czy kiedykolwiek samodzielnie uczyłeś się czegoś trudnego (język, programowanie, gitara) i doprowadziłeś temat do sensownego poziomu?
• Po co chcesz wejść w cyberbezpieczeństwo: dla pieniędzy, prestiżu, ciekawości, zmiany stylu pracy? Co jest motywacją numer 1?

Policz, na ile z tych pytań odpowiedziałeś „tak” w kontekście samodzielności, uporu, ciekawości. Jeśli przeważa „tak” – masz dobry materiał na przebranżowienie do cyberbezpieczeństwa. Jeśli większość odpowiedzi to „nie wiem” albo „raczej nie” – nie przekreśla cię to, ale potrzebujesz bardziej rozważnego, wolniejszego planu niż agresywne 90 dni.

Co z twojego dotychczasowego doświadczenia da się wykorzystać?

Nie trzeba być programistą, żeby wejść w od zera do junior security. Ważniejsze jest to, co już robisz i jak możesz to przekuć na atut. Zastanów się: z czego startujesz?

• Helpdesk / wsparcie IT – rozumiesz użytkowników, systemy operacyjne, podstawy sieci, pracowałeś z ticketami. To świetna baza pod SOC Analyst pierwsza praca lub rolę w Blue Teamie.
• Administrator systemów / sieci – znasz Windows Server, Linuxa, urządzenia sieciowe. Dla ciebie nauka bezpieczeństwa IT w 90 dni będzie bardziej „profilowaniem” niż totalnym startem od zera.
• Tester oprogramowania / QA – umiesz szukać błędów, myślisz przypadkami testowymi. Łatwiej ci będzie wejść w pentesty aplikacyjne, bezpieczeństwo testów lub security QA.
• Biznes / prawo / compliance / księgowość – znasz procesy, dokumentację, ryzyko. Tu dobrze pasuje ścieżka kariery w cyberbezpieczeństwie typu GRC (Governance, Risk & Compliance) lub analityk ryzyka.
• Brak IT, inne branże – liczy się logika, rzetelność, nawyk uczenia się. Początek będzie cięższy, ale nie niemożliwy. Musisz włożyć więcej energii w fundamenty IT.

Pomyśl teraz: z której z powyższych grup jesteś najbliżej? Jakie konkretne narzędzia, systemy, procedury znasz dziś, które pojawiają się również w cyberbezpieczeństwie (Active Directory, VPN, Office 365, JIRA, ITIL)? Zapisz je – to twój startowy kapitał.

Proste testy: jak reagujesz na abstrakcję i brak instrukcji?

Żeby sprawdzić, czy praca z logami, danymi i abstrakcyjnymi problemami jest dla ciebie, możesz zrobić dwa mini‑testy. Nie chodzi o poziom wiedzy, tylko o sposób działania.

Test 1: zagadka logiczna

Wyobraź sobie, że dostajesz informację: „Użytkownik Kowalski nie może zalogować się do systemu X. Wczoraj działało, dziś nie”. Nie masz żadnych dodatkowych danych. Co robisz przez pierwsze 5 minut?

Wypisz na kartce:

• Jakie pytania zadajesz użytkownikowi?
• Jakie logi/systemy chciałbyś sprawdzić?
• Jakie hipotezy przychodzą ci do głowy (hasło, konto zablokowane, sieć, VPN, błąd aplikacji)?

Jeśli automatycznie budujesz listę hipotez i szukasz sposobów ich weryfikacji – myślisz jak przyszły security analyst. Jeśli stoisz w miejscu i czekasz na „instrukcję” – to sygnał, że musisz potrenować samodzielność w analizie problemów.

Test 2: intuicyjna analiza logów

Znajdź w sieci przykładowy plik logów HTTP albo prosty log systemowy (np. z Linuxa). Nie musisz wszystkiego rozumieć. Zadaj sobie trzy pytania:

• Co jest tu powtarzalne (czas, IP, metoda, URL)?
• Które wpisy wydają się inne niż większość (inny kod odpowiedzi, inne IP, inne ścieżki)?
• Jak mógłbyś je pogrupować, żeby coś z tego wyczytać?

Jeśli odczuwasz frustrację, ale jednocześnie ciekawość i chęć „dokopania się” do znaczenia – to dobry sygnał. Jeśli po minucie masz ochotę wszystko zamknąć, bo „za dużo tego” – praca z logami w SOC może okazać się dla ciebie męcząca.

Kiedy lepiej wybrać inną ścieżkę w IT

Nie każdy musi iść w przebranżowienie do cyberbezpieczeństwa. Zanim wejdziesz w plan na 90 dni, zadaj sobie pytanie: co tak naprawdę chcesz robić w pracy?

• Wolisz przewidywalne zadania, jasne procedury i powtarzalność? Lepiej sprawdzi się rola w QA, administracji lub wsparciu użytkowników niż analiza incydentów.
• Najwięcej satysfakcji daje ci tworzenie (kod, automaty, skrypty)? Może bliżej ci do DevOps, SRE albo klasycznego developmentu, gdzie security będzie „dodatkiem”, a nie rdzeniem pracy.
• Źle reagujesz na stres, dyżury, nagłe incydenty typu „pali się, wszystko stoi”? Zastanów się nad GRC, audytem lub bezpieczeństwem aplikacji po stronie procesów – tam adrenalina jest mniejsza niż w SOC/IR.

Zauważ, że cyberbezpieczeństwo to szerokie pojęcie. Jeśli techniczne incydenty brzmią jak koszmar, ale lubisz regulacje, polityki, standardy – nadal możesz rozwijać się w bezpieczeństwie, tylko w innym segmencie.

Jak odpowiadasz sobie na te pytania? Bardziej ciągnie cię do śrubek technicznych, czy do procedur i biznesu?

Mapy terenu: jakie ścieżki kariery istnieją w cyberbezpieczeństwie

Role wejściowe a role docelowe w bezpieczeństwie IT

Plan nauki cyberbezpieczeństwa na 90 dni musi mieć konkretny punkt docelowy. Nie „chcę być w cyber”, tylko: „chcę celować w SOC analyst pierwsza praca” albo „celuję w junior GRC/analiza ryzyka”. Żeby to nazwać, potrzebujesz orientacji, jakie role istnieją.

Najczęstsze ścieżki:

• SOC Analyst (Security Operations Center) – monitorowanie zdarzeń bezpieczeństwa, analiza alertów, eskalacja incydentów, praca na zmianach, dużo logów i narzędzi typu SIEM.
• Junior Security Engineer / Blue Team – konfiguracja i utrzymanie narzędzi security (firewalle, EDR, antywirusy), twarde IT z perspektywą obrony systemów.
• Pentester / Red Team – testy penetracyjne aplikacji, sieci, socjotechnika; ofensywne podejście „jak włamać się, żeby poprawić zabezpieczenia”.
• Incident Responder (IR) – reagowanie na incydenty, forensyka, analiza malware; dużo adrenaliny i pracy pod presją czasu.
• GRC / analityk ryzyka – polityki bezpieczeństwa, zgodność z normami, ocena ryzyka, praca blisko biznesu i prawa.
• Bezpieczeństwo aplikacji (AppSec) – współpraca z developerami, przeglądy kodu, integracja security w cyklu wytwórczym.

Na start, przy przebranżowieniu, zwykle patrzy się na role bardziej juniorowe: SOC Analyst, młodszy specjalista ds. bezpieczeństwa IT, junior GRC, ewentualnie wsparcie przy testach penetracyjnych. Pentester senior czy architekt bezpieczeństwa to raczej cele na kilka lat, nie na 90 dni.

Techniczne vs procesowe ścieżki bezpieczeństwa

Jaki typ pracy lubisz: bardziej śrubki i konfiguracje, czy rozmowy, dokumenty, analizy ryzyka? To jedno z ważniejszych pytań przy wyborze ścieżki kariery w cyberbezpieczeństwie.

Jeśli ciągnie cię do terminala, narzędzi, skryptów – szukasz raczej ścieżki technicznej. Jeśli lepiej czujesz się w rozmowach z ludźmi, tłumaczeniu z „technicznego” na „biznesowy”, organizacji procesów – rozglądaj się za GRC i analityką ryzyka.

Przy planie „nauka bezpieczeństwa IT w 90 dni” łatwiej zbliżyć się do roli technicznej na poziomie juniora, bo szybciej pokażesz praktyczne umiejętności (laby, projekty, portfolio projektów security). Role procesowe wymagają z kolei dobrej znajomości norm i kontekstu biznesowego – tu czas wejścia bywa dłuższy, ale wcześniejsze doświadczenie poza IT może paradoksalnie przyspieszyć wejście.

Jak twoje dotychczasowe doświadczenie skraca drogę

Zamiast zaczynać od zera, zadaj sobie pytanie: co możesz „przenegocjować” z obecnego zawodu do bezpieczeństwa IT?

• Admin → Blue Team / Security Engineer
  Znasz już systemy, sieci, uprawnienia. Twój plan nauki cyberbezpieczeństwa skupia się głównie na:
  • poznaniu narzędzi security (SIEM, EDR, WAF),
  • przełożeniu dotychczasowej wiedzy na kontekst zagrożeń,
  • zrozumieniu podstawowych ataków i sposobów ich detekcji.
• Tester → Pentest / AppSec
  Masz mindset szukania błędów. W 90 dni możesz:
  • nauczyć się podstaw OWASP Top 10,
  • robić proste laby ataków webowych,
  • przełożyć wiedzę o testach na wymagania security.
• Compliance / prawo → GRC
  Rozumiesz regulacje, RODO, audyty. Twoja ścieżka:
  • poznanie standardów ISO 27001, NIST,
  • złapanie podstaw technologii (systemy, sieci),
  • praktyka w rozpisywaniu ryzyka i kontroli.
• Helpdesk → SOC / junior security
  Wiesz, jak wygląda użytkownik, incydenty zgłaszane do IT. Twój plan:
  • wejście w narzędzia monitoringu,
  • zrozumienie podstaw ataków (phishing, malware, brute-force),
  • praktyka w analizie logów i ticketów security.

Pytanie do ciebie: czyją historię widzisz tu najbardziej? Admina, testera, prawnika, helpdesku, czy kogoś zupełnie innego?

Które role są realne po 90 dniach?

Przebranżowienie do cyberbezpieczeństwa w 90 dni nie oznacza, że po trzech miesiącach zostaniesz pentesterem senior albo architektem bezpieczeństwa. Da się natomiast zbudować fundamenty i profil na poziom:

• Junior SOC Analyst / młodszy specjalista ds. bezpieczeństwa IT – realny cel, jeśli poświęcisz na naukę 10–15 godzin tygodniowo i masz już choćby minimalne tło IT.
• Praktykant / stażysta w obszarze GRC lub security – realny, jeśli masz doświadczenie w prawie, compliance, zarządzaniu ryzykiem.
• Osoba z mocnym portfolio labów i projektów security – realna baza do szukania pierwszej pracy.

Rolami „poza zasięgiem” na pierwszy 90‑dniowy etap są zwykle: samodzielny pentester, architekt bezpieczeństwa, senior incident responder. Te pozycje wymagają lat praktyki, a nie tylko krótkiego kursu.

Fundamenty przed startem: techniczny niezbędnik, który musisz ogarnąć

Na czym dziś stoisz technicznie?

Zanim rozpiszesz ambitny plan na 90 dni, zatrzymaj się na chwilę. Zadaj sobie kilka szczerych pytań:

• Czy umiesz sprawnie poruszać się po systemie operacyjnym (Windows, Linux) bez „klikania na ślepo”?
• Czy rozumiesz, jak działa sieć na poziomie IP, portów, protokołów typu HTTP, DNS, TCP/UDP?
• Czy miałeś kontakt z terminalem / wierszem poleceń i nie przeraża cię czarne okno?
• Czy potrafisz przeczytać prosty skrypt lub fragment kodu i z grubsza zrozumieć, co robi?

Jeśli większość odpowiedzi brzmi „tak”, 90‑dniowy plan może mocno przyspieszyć. Jeśli dominują „nie” – nic straconego, tylko trzeba rozsądnie ułożyć priorytety.

Pomyśl: z czym miałeś ostatnio realny kontakt – sieciami, kodem, a może tylko Wordem i Excelem?

Systemy operacyjne: użytkownik vs operator

W cyberbezpieczeństwie nie musisz być guru od każdego systemu, ale musisz umieć myśleć jak operator, nie jak zwykły użytkownik. Co to znaczy w praktyce?

• Windows – rozumiesz:
  • podstawy uprawnień (użytkownik, admin, UAC),
  • jak przeglądać logi (Event Viewer) i gdzie szukać podstawowych informacji,
  • jak działa instalacja usług, programów, autostart.
• Linux – radzisz sobie przynajmniej z:
  • nawigacją po katalogach (cd, ls, pwd),
  • edycją plików konfiguracyjnych (np. nano),
  • zarządzaniem procesami (ps, top, kill),
  • podstawami uprawnień (chmod, chown).

Nie chodzi o to, żebyś znał wszystkie przełączniki każdej komendy. Wystarczy, że umiesz szybko sprawdzić pomoc (--help, man) i nie tracisz głowy, kiedy coś nie działa.

Pomyśl: który system operacyjny chcesz potraktować jako „bazowy” w swoich labach – Windows czy Linux?

Sieci: od „działa / nie działa” do rozumienia, co płynie w kablu

Większość ataków, detekcji i incydentów kręci się wokół ruchu sieciowego. Bez podstaw sieci będziesz zgadywać, a nie analizować. Potrzebujesz minimum:

• zrozumienia modeli TCP/IP (warstwy z grubsza, nie na egzamin CCNA),
• co to jest adres IP, maska, gateway, DNS, port,
• jak działa proste połączenie klient–serwer (np. przeglądarka → serwer WWW),
• świadomości, czym różni się HTTP od HTTPS, TCP od UDP,
• umiejętności użycia podstawowych narzędzi:
  • ping, tracert/traceroute, nslookup/dig,
  • podgląd tablicy ARP, routingu, aktywnych połączeń.

Przykład z praktyki: analityk SOC widzi alert „podejrzany ruch DNS do nietypowej domeny”. Ktoś, kto rozumie, jak działa DNS, wie, co sprawdzić i gdzie szukać. Bez tych podstaw – to tylko straszący komunikat w panelu.

Zastanów się: czy potrafisz wytłumaczyć w 2–3 zdaniach, jak komputer znajduje stronę example.com w internecie?

Podstawy skryptów i automatyzacji

Nie każdy w cyber musi być programistą, ale umiejętność napisania prostego skryptu to ogromne ułatwienie. Przyda ci się do:

• filtrowania i obrabiania logów,
• automatyzacji powtarzalnych zadań (np. pobranie plików, prosta analiza),
• budowy małych narzędzi ułatwiających pracę.

Na początek wystarczy jedna technologia, ale używana świadomie:

• Python – dobry wybór uniwersalny, masa bibliotek security,
• Bash (Linux) lub PowerShell (Windows) – świetne do pracy z systemem i logami.

Nie potrzebujesz wzorców projektowych i architektury mikroserwisów. Wystarczy, że potrafisz:

• czytać plik linia po linii,
• wyszukać fragment tekstu (np. po IP, dacie, słowie kluczowym),
• zbudować prostą pętlę i warunek (if).

Pytanie do ciebie: który język / powłokę chcesz potraktować jako „narzędzie numer 1” na najbliższe 90 dni?

Myślenie „systemowe”, nie „aplikacyjne”

Duża część osób przebranżawiających się z innych branż myśli w kategoriach: „aplikacja działa / aplikacja się zawiesiła”. W bezpieczeństwie potrzebujesz innej perspektywy: jak zachowuje się cały system.

Przydaje się nawyk zadawania pytań:

• co się dzieje pod spodem, kiedy użytkownik klika link w mailu?
• która część łańcucha może zostać zaatakowana (przeglądarka, DNS, serwer, użytkownik)?
• jakie ślady (logi, wpisy, pliki) zostaną po tym w systemach?

W praktyce różnica między „klasycznym IT” a security polega często na jednym dodatkowym pytaniu: „a co jeśli ktoś to wykorzysta przeciwko nam?”

Pomyśl o swojej aktualnej pracy: gdzie w twoim codziennym procesie najłatwiej byłoby „wstrzyknąć” atak lub błąd?

Minimalny stos narzędzi na start

Nowa osoba w cyber łatwo tonie w narzędziach. Setki nazw, frameworków, skanerów. Na 90 dni potrzebujesz bardzo prostego zestawu, który będziesz faktycznie używać, a nie tylko instalować:

• System do labów:
  • Linux (np. Ubuntu / Kali jako VM) + Windows (też jako VM) – żebyś mógł patrzeć na problemy z dwóch stron.
• Narzędzia sieciowe:
  • Wireshark – podgląd ruchu sieciowego,
  • nmap – skanowanie portów i usług.
• Narzędzia do logów:
  • cokolwiek, co wygodnie otwiera duże pliki (np. less w terminalu, Notepad++),
  • proste komendy filtrujące (grep, findstr).
• Środowisko do skryptów:
  • Python + edytor (VS Code, PyCharm Community) lub PowerShell.

Pytanie kontrolne: czy jesteś w stanie w ciągu tygodnia zainstalować i choć raz uruchomić każde z tych narzędzi na jakimś prostym przykładzie?

Konstrukcja planu 90 dni: zasady, rytm, oczekiwane efekty

Dlaczego akurat 90 dni?

Trzy miesiące to ciekawy horyzont: na tyle krótki, że widzisz koniec, ale na tyle długi, że możesz zbudować realną zmianę. Nie zrobisz z siebie eksperta, ale:

• możesz zbudować podstawową mapę pojęć,
• zrobić kilkadziesiąt godzin praktycznych labów,
• przygotować małe portfolio, o którym konkretnie opowiesz na rozmowie.

Kluczowe pytanie: co chcesz mieć „namacalne” po tych 90 dniach? Notatnik pełen teorii, czy kilka konkretnych projektów i labów, do których możesz wrócić?

Stałe elementy tygodnia: teoria, praktyka, refleksja

Plan nauki bezpieczeństwa IT łatwo zamienić w „binge-watching kursów”. Żeby tego uniknąć, poukładaj tydzień w trzy bloki:

• Teoria (ok. 30–40% czasu) – kursy, artykuły, książki, dokumentacja. Celem nie jest przeczytać wszystko, tylko wiedzieć, o co pytać w praktyce.
• Praktyka (ok. 50–60% czasu) – laby, ćwiczenia, CTF‑y dla początkujących, własne mini‑projekty.
• Refleksja (ok. 10% czasu) – podsumowania tygodnia, notatki, lekcje typu „czego nie rozumiem i czego szukam następnym razem?”.

Wypróbuj prosty schemat: każda godzina teorii = minimum godzina praktyki. Zadaj sobie wtedy pytanie: „gdzie mogę to kliknąć lub zobaczyć na żywo?”.

Realne tempo: ile godzin tygodniowo?

Przy przebranżowieniu zwykle nie masz luksusu pełnego etatu na naukę. Trzeba szczerze policzyć czas:

• 5 godzin tygodniowo – tempo „wolne”, sensowne raczej przy podtrzymywaniu, niż pełnym przebranżowieniu.
• 10–15 godzin tygodniowo – optymalny poziom dla większości pracujących osób. Daje to około 120–180 godzin w 90 dni.
• 20+ godzin tygodniowo – możliwe przy przerwie między pracami lub elastycznym grafiku, ale wymaga dobrej higieny nauki, żeby się nie wypalić.

Zastanów się: ile godzin realnie możesz wygospodarować tygodniowo przez 3 kolejne miesiące, nie kosztem snu i zdrowia?

Rytm dnia: mikro‑nawyki zamiast maratonów

Duża sesja raz na dwa tygodnie brzmi ambitnie, ale słabo działa. W cyber lepiej sprawdza się „kropla drąży skałę” – krótsze, regularne sesje:

• 3–5 dni w tygodniu po 1–2 godziny niż jeden 8‑godzinny maraton,
• na każdą sesję konkretny mini‑cel (np. „zrobię 2 laby z logami HTTP”, „przeczytam i przetestuję 3 reguły firewall”),
• po sesji jedno pytanie: „co mógłbym dziś wytłumaczyć komuś innemu?”.

Przykład: zamiast „uczę się sieci”, ustaw cel „rozumiem różnicę między TCP a UDP i umiem pokazać ją w Wiresharku na nagranym ruchu”.

Oczekiwane efekty po 30, 60 i 90 dniach

Żeby się nie rozjechać, dobrze mieć punkty kontrolne. Możesz potraktować je jak „kamienie milowe”:

• Dzień 30 – orientujesz się w podstawowych pojęciach, masz za sobą pierwsze laby (logi, podstawy sieci, proste skrypty).
• Dzień 60 – potrafisz odtworzyć kilka prostych scenariuszy atak–obrona, umiesz zebrać i zinterpretować proste logi.
• Dzień 90 – masz mini‑portfolio (np. repozytorium z notatkami i skryptami, opisane laby), umiesz konkretnie powiedzieć, w jaką rolę celujesz (SOC, GRC, pentest).

Zadaj sobie teraz pytanie: co konkretnie chciałbyś móc zrobić samodzielnie 90. dnia? Odpowiedź zapisz, nie trzymaj jej tylko w głowie.

Jak mierzyć postęp, a nie tylko czas przed ekranem

Łatwo po 3 tygodniach dojść do wniosku „uczę się tyle i nic nie umiem”. Dlatego zamiast mierzyć godziny, mierz artefakty:

• ilość zrobionych labów (np. z platform typu TryHackMe/HackTheBox Academy/INE),
• listę konkretnych zagadnień, które potrafisz wytłumaczyć na prostym przykładzie,
• zapisane scenariusze „atak → detekcja → reakcja”, które odtworzyłeś,
• liczbę dni z rzędu, w których zrobiłeś choć 30 minut nauki.

Dobrym nawykiem jest prowadzenie dziennika nauki. To może być zwykły plik Markdown lub notatnik papierowy, byle codziennie odpowiedzieć na trzy pytania:

1. Co dziś zrobiłem / zrobiłam?
2. Czego nie rozumiem?
3. Co zrobię następnym razem?

Czy masz już miejsce, w którym będziesz prowadzić takie krótkie logi z nauki?

Dostosowanie planu do wybranej ścieżki

Inaczej będzie wyglądał 90‑dniowy plan kogoś, kto celuje w SOC, a inaczej osoby idącej w GRC. Kilka bazowych różnic:

• Ścieżka SOC / Blue Team:
  • więcej labów z logami, SIEM‑ami, narzędziami monitoringu,

  Profile aktywności dla różnych ścieżek

  Dla porządku zestawmy, co może dominować w tygodniu przy poszczególnych kierunkach. Zastanów się, gdzie intuicyjnie ciągnie cię najmocniej.

  • SOC / Blue Team:
    • 70% – praca z logami, scenariusze atak–detekcja, mini‑incydenty w labie,
    • 20% – teoria protokołów, podstawy systemów, modele ataków,
    • 10% – czytanie raportów z prawdziwych incydentów (np. write‑upy, blogi vendorów).
  • Pentest / Red Team:
    • 60% – praktyka na maszynach testowych (CTF‑y, laby ofensywne),
    • 20% – solidne fundamenty sieci i systemów,
    • 20% – analiza raportów z testów penetracyjnych, nauka pisania prostych notek z wnioskami.
  • GRC / audyt / compliance:
    • 50% – standardy i regulacje (ISO 27001, RODO, NIS2),
    • 30% – zrozumienie, jak działają systemy i procesy biznesowe,
    • 20% – pisanie: polityki, procedury, check‑listy, proste raporty z ryzyka.

  Który z tych rozkładów brzmi jak „typowy tydzień”, który mógłbyś zaakceptować przez najbliższe lata?

  Strategia „T‑shape”: szeroko na start, głębiej tam, gdzie klika

  Dobre podejście na 90 dni to tak zwany profil „T”: szeroka podstawa z kilku obszarów i pierwsze zagłębienie w jednym z nich. Przekładając to na praktykę:

  • w pierwszych 30 dniach dotykasz trochę sieci, trochę systemów, trochę logów i trochę regulacji,
  • w dniach 31–60 wybierasz 1–2 obszary, które „kliknęły” najmocniej,
  • w dniach 61–90 robisz mini‑projekt powiązany z tą głębszą specjalizacją.

  Zapisz teraz trzy hasła, które po lekturze do tej pory wydają ci się najbardziej „twoje” (np. „logi”, „sieci”, „procesy i regulacje”). Czy już któryś z nich wyróżnia się na tle reszty?

  Dni 1–30: budowa fundamentów technicznych i bezpieczeństwa

  Cel na pierwsze 30 dni

  W pierwszym miesiącu nie gonisz certyfikatów ani „gotowości na rozmowę techniczną”. Twoim celem jest:

  • uruchomić stabilne środowisko do nauki (laby),
  • zbudować podstawowe słownictwo sieciowo‑systemowe,
  • dotknąć realnych danych: logów, ruchu sieciowego, prostych skryptów.

  Zadaj sobie pytanie: gdybyś miał pod koniec 30‑ego dnia pokazać jedną rzecz osobie z branży, co by to było? Screenshot z Wiresharka, opis małego incydentu, repozytorium ze skryptem do parsowania logów?

  Tydzień 1: przygotowanie środowiska i higiena pracy

  Bez sensu uczyć się cyberbezpieczeństwa „na sucho”. Zaczynasz od zbudowania piaskownicy, w której możesz bezpiecznie eksperymentować.

  Lab domowy – minimalna konfiguracja

  Załóżmy, że masz jeden komputer z minimum 8 GB RAM. Co robisz w pierwszym tygodniu?

  • Instalujesz VirtualBox lub VMware Player.
  • Tworzysz dwie maszyny wirtualne:
    • Linux (np. Ubuntu Desktop lub Kali – jeśli Kali, traktuj je jako zwykłego Linuksa z dodatkami),
    • Windows (jeśli nie masz licencji, możesz użyć triala / wersji developerskiej).
  • Konfigurujesz sieć VM w trybie:
    • NAT – na początek, żeby obie maszyny miały internet,
    • opcjonalnie internal network – później do symulacji „mini‑firmy” bez wychodzenia na zewnątrz.

  Twoim małym celem może być: z obu VM zalogować się do internetu, zainstalować przeglądarkę, zaktualizować system i zainstalować kilka narzędzi (Wireshark, nmap, edytor tekstu).

  Jak sprawdzisz, że VM działa poprawnie? Spróbuj z Linuksa zrobić ping na adres IP Windowsa i odwrotnie. Jeśli się nie udaje, dowiedz się dlaczego – to już pierwsza lekcja sieci.

  Podstawowe nawyki „bezpiecznego klikania”

  Nawet w labie opłaca się wyrobić dobre przyzwyczajenia:

  • oddzielaj środowisko labowe od „komputera do banku i życia” – nie rób wszystkiego na jednej maszynie,
  • rób snapshoty VM przed większymi eksperymentami,
  • notuj, co instalujesz i jakie komendy odpalasz – łatwiej będzie powtórzyć lab za miesiąc.

  Masz już wybrane miejsce na notatki z labów (np. katalog w repozytorium Git, Notion, zwykły folder z plikami Markdown)?

  Tydzień 2: sieć – od kabli do pakietów

  Drugi tydzień to fundament wszystkiego: sieci. Bez tego większość zagadnień security będzie brzmiała jak magia.

  Minimum teorii sieci na start

  Stwórz sobie mini‑listę pojęć, które chcesz „odczarować” w tym tygodniu:

  • model TCP/IP (warstwa sieci, transportu, aplikacji),
  • adres IP, maska, brama, DNS,
  • różnica między TCP a UDP,
  • porty (HTTP 80, HTTPS 443, SSH 22, RDP 3389 – kilka podstawowych).

  Nie chodzi o wykuwanie całego modelu OSI. Celem jest, byś umiał spojrzeć na komunikację i powiedzieć: „aha, to idzie z mojego IP X na serwer Y, port 443, przez TCP”.

  Praktyka z Wiresharkiem i nmapem

  W tym tygodniu dobrze zrobić kilka prostych zadań:

  1. Uruchom Wireshark na jednej z VM i:
     • złap ruch podczas wejścia na dowolną stronę HTTPS,
     • przefiltruj ruch tylko po protokole dns,
     • zlokalizuj zapytanie DNS dla domeny, na którą wszedłeś.
  2. Użyj nmap na swojej sieci labowej:
     • przeskanuj drugą VM (np. nmap -sV <IP>),
     • zobacz, jakie porty są otwarte i jakie usługi rozpoznaje nmap.

  Zadaj sobie pytanie: czy umiesz słowami opisać, co widzisz w Wiresharku i w wynikach nmap – tak, żeby ktoś nietechniczny zrozumiał, że „to jest lista drzwi do komputera i usług, które za nimi stoją”?

  Tydzień 3: systemy operacyjne i logi

  Trzeci tydzień to „wejście do środka” maszyn: uczysz się, jak patrzeć na systemy od strony procesów, usług i logów.

  Linux – pierwsze kroki od strony bezpieczeństwa

  Zamiast ogólnej nauki „Linuksa”, skup się na konkretnych elementach:

  • podstawowe komendy: ls, cd, cat, less, tail -f, ps, grep, sudo,
  • struktura katalogów: gdzie są logi (/var/log/), gdzie konfiguracje (/etc/),
  • przegląd wybranych logów:
    • /var/log/auth.log lub /var/log/secure – logi uwierzytelniania,
    • /var/log/syslog – ogólne logi systemowe.

  Ćwiczenie: spróbuj zalogować się kilka razy błędnym hasłem przez SSH do swojej VM, a potem w logach znajdź wpisy, które to odzwierciedlają. Użyj grep po słowach „Failed password”.

  Pytanie do ciebie: czy po takim ćwiczeniu potrafisz powiedzieć, jak wygląda ślad nieudanej próby logowania i gdzie byś go szukał w prawdziwym systemie?

  Windows – podgląd zdarzeń i procesy

  Po stronie Windowsa skup się na dwóch narzędziach:

  • Task Manager / Process Explorer – lista procesów, zużycie zasobów,
  • Event Viewer – przegląd logów (System, Application, Security).

  Prosty scenariusz do odtworzenia:

  1. Zaloguj się na Windowsie na swoje konto użytkownika.
  2. Otwórz Event Viewer i w logach Security wyszukaj zdarzenia logowania (ID 4624 – udane, 4625 – nieudane).
  3. Spróbuj opisać jednym zdaniem, co oznacza konkretne zdarzenie i jakie informacje są w nim najważniejsze (kto, skąd, kiedy).

  Jak się z tym czujesz? Czy widok Event Viewera cię przytłacza, czy jesteś w stanie znaleźć konkretny typ zdarzenia z filtrem?

  Tydzień 4: pierwsze scenariusze „atak–detekcja”

  Gdy masz już podstawową orientację w sieci i systemach, możesz połączyć to w pierwsze, bardzo proste scenariusze bezpieczeństwa. Chodzi o to, byś zobaczył ciąg przyczynowo‑skutkowy: działanie → ślad w logach → wniosek.

  Scenariusz 1: skan portów jako potencjalne rozpoznanie atakującego

  W tym ćwiczeniu bawisz się w „atakującego” i „obrońcę” jednocześnie:

  1. Na jednej VM odpal nmap skanując drugą:
     • nmap -sS -p 1-1000 <IP_drugiej_VM>
  2. Na skanowanej maszynie (np. Linux) spróbuj znaleźć w logach systemowych / firewall ślady tego skanowania.
  3. Zadaj sobie pytania:
     • czy system w ogóle odnotował takie działanie?
     • jak odróżnić „normalny ruch” od skanu?
     • jakie zabezpieczenia mogłyby utrudnić taki skan?

  Czy po tym scenariuszu umiesz przynajmniej ogólnie opowiedzieć, jak narzędzie typu IDS/IPS mogłoby wykryć taki ruch?

  Scenariusz 2: plik złośliwy vs. antywirus / Defender

  Nie musisz od razu pisać malware. Na początek wystarczy podejrzeć, jak zachowuje się system przy podejrzanym pliku.

  • Pobierz archiwum testowe EICAR (to nie jest prawdziwy wirus, ale większość antywirusów działa na niego jak na malware).
  • Zapisz je na Windows VM i zobacz:
    • czy antywirus (np. Microsoft Defender) go wykryje,
    • jaką informację zobaczysz w logach,
    • jakie okno/komunikat pojawi się użytkownikowi.

  Później możesz spróbować znaleźć w Event Viewer wpis, który opisuje to zdarzenie. Dzięki temu lepiej zrozumiesz, jak działają alerty i czym karmi się później system typu SIEM.

  Mini‑portfolio z pierwszych 30 dni

  Jeśli od początku myślisz o przebranżowieniu, dobrze jest w tym pierwszym miesiącu zacząć budować „ślady pracy”. Nie muszą być spektakularne, ale powinny być konkretne.

  Pomyśl o trzech prostych rzeczach, które możesz na tym etapie zebrać:

  • Notatki techniczne – plik lub repozytorium z opisem:
    • jak skonfigurowałeś lab (VM, sieć),
    • kilka podstawowych komend z Linuksa i Windowsa,
    • przykładowe wpisy logów z krótkim komentarzem, co oznaczają.
  • Małe skrypty – np. prosty Python/PowerShell, który:
    • filtruje log po słowie „Failed” i liczy wystąpienia,
    • parsuje plik z logami i wypisuje top 5 adresów IP.
  • Opisy scenariuszy – po jednym akapicie do wykonanych labów:
    • „Skan portów nmap → jak wygląda z perspektywy logów”,
    • „Wejście na stronę HTTPS → jak wygląda to w Wiresharku i DNS”.

  Usiądź na 15 minut: co już masz, co można „podczepić” pod takie mini‑portfolio, a czego brakuje? Czy jesteś w stanie w ciągu tygodnia dowieźć choć jeden konkretny artefakt, którym mógłbyś się pochwalić?

  Najczęściej zadawane pytania (FAQ)

  Czy da się realnie przebranżowić do cyberbezpieczeństwa w 90 dni?

  Da się zrobić sensowny start w 90 dni, ale nie „zostać ekspertem”. W trzy miesiące możesz zbudować fundamenty IT, ogarnąć podstawowe pojęcia bezpieczeństwa i przygotować się do pierwszych rozmów na role typu junior/SOC trainee/junior GRC. Pytanie brzmi: ile godzin tygodniowo jesteś w stanie uczciwie poświęcić i z jakiego poziomu startujesz?

  Jeśli masz już doświadczenie w IT (helpdesk, admin, QA), 90 dni to przyspieszony „turbo‑kurs” profilujący cię na security. Jeśli dopiero poznajesz sieci, systemy i podstawy, ten czas wystarczy na zbudowanie bazy i zorientowanie się, która ścieżka w cyber jest dla ciebie. Traktuj 90 dni jako mocny sprint startowy, a nie całą drogę zawodową.

  Jak sprawdzić, czy cyberbezpieczeństwo w ogóle jest dla mnie?

  Najprościej: odpowiedz na kilka brutalnie szczerych pytań. Czy lubisz łamigłówki i szukanie przyczyn błędów? Jak reagujesz, gdy nikt nie daje ci gotowej instrukcji? Czy umiesz samodzielnie „dokopać się” do rozwiązania, zamiast od razu pytać innych? I wreszcie: ile czasu tygodniowo naprawdę możesz przeznaczyć na naukę?

  Dobrym testem jest też mini‑scenariusz: ktoś pisze „nie mogę się zalogować, wczoraj działało”. Czy od razu układasz w głowie listę hipotez (hasło, konto, sieć, VPN, sam system) i potencjalnych logów do sprawdzenia? Jeśli tak – masz naturalne predyspozycje do analizy incydentów. Jeśli „zamierasz” i czekasz na instrukcję, przed wejściem w security przyda się trening samodzielności i myślenia diagnostycznego.

  Nie mam doświadczenia w IT – czy mogę zacząć karierę w cyberbezpieczeństwie?

  Możesz, ale tempo będzie inne niż u osoby z IT. Zadaj sobie pytanie: co już robiłeś, co wymagało logicznego myślenia, dokładności i samodzielnej nauki? Nawet jeśli pracowałeś w księgowości, prawie, logistyce czy administracji, część tych kompetencji da się przełożyć na GRC, analizę ryzyka czy role blisko procesów i regulacji.

  Przy starcie „spoza IT” pierwsze 90 dni to zwykle: fundamenty systemów (Windows, podstawy Linuxa), podstawy sieci (TCP/IP, VPN, firewall), ogólne pojęcia bezpieczeństwa. Zamiast cisnąć się na pentestera w trzy miesiące, lepiej wybrać spokojniejszy plan: najpierw zrozum IT, równolegle poznając, jakie typy ról w cyber w ogóle istnieją.

  Jakie dotychczasowe doświadczenie najbardziej pomaga przy wejściu w cyberbezpieczeństwo?

  Najłatwiej mają osoby, które już „dotykały” systemów i użytkowników. Jeśli pracowałeś w helpdesku, znasz systemy operacyjne, podstawy sieci i realne problemy użytkowników – to świetna baza pod SOC albo junior security specialist w Blue Teamie. Administratorzy systemów i sieci zazwyczaj szybciej łapią techniczne aspekty hardeningu, logów, uprawnień.

  Testerzy oprogramowania naturalnie przeskakują w kierunku bezpieczeństwa aplikacji i pentestów webowych – już umiesz szukać błędów i myśleć przypadkami testowymi. Osoby z biznesu, prawa, księgowości mają z kolei dobrą pozycję startową do ról GRC/analityka ryzyka. Zadaj sobie pytanie: jakie narzędzia i procesy znasz dzisiaj (AD, VPN, Office 365, JIRA, ITIL)? To twój startowy kapitał, nie lekceważ go.

  Jaką ścieżkę w cyberbezpieczeństwie wybrać na start?

  Najpierw odpowiedz: bliżej ci do śrubek technicznych, czy do procesów i regulacji? Jeśli lubisz logi, narzędzia, „grzebanie” w systemach, naturalnym celem będzie SOC Analyst, młodszy specjalista ds. bezpieczeństwa IT albo wsparcie przy testach penetracyjnych. Tu dużo czasu spędzisz w konsolach, SIEM‑ach, na labach i w scenariuszach „co poszło nie tak”.

  Jeśli za to lepiej czujesz się w pracy z dokumentacją, normami, rozmowami z biznesem, spójrz w stronę GRC, analizy ryzyka czy bezpieczeństwa procesów. Technia bardziej cię ciekawi niż przeraża, ale nie chcesz dyżurów i ciągłej adrenaliny? Pomiędzy jest AppSec – praca blisko developerów, przegląd kodu, dbanie o bezpieczeństwo w cyklu wytwórczym.

  Po czym poznać, że lepiej wybrać inną ścieżkę w IT niż cyberbezpieczeństwo?

  Zastanów się, jak reagujesz na: brak jasnej instrukcji, nagłe „pożary” w pracy, monotonną analizę danych. Jeśli najbardziej lubisz przewidywalne zadania, klarowne procedury i powtarzalność, spokojniejsze role w administracji, QA czy wsparciu użytkowników mogą być dla ciebie zdrowsze niż SOC czy Incident Response.

  Jeśli źle znosisz presję czasu, dyżury i poczucie ciągłej odpowiedzialności za „bezpieczeństwo wszystkiego”, pomyśl o GRC, audycie, bezpieczeństwie aplikacji od strony procesów. Cyberbezpieczeństwo to nie tylko „łapanie hakerów” – ale jeśli zarówno aspekt techniczny, jak i presja sytuacji cię męczą, sensowniej będzie rozwijać się w innym fragmencie IT, z bezpieczeństwem jako dodatkiem, a nie głównym tematem.

  Jak samodzielnie przetestować, czy praca z logami i danymi jest dla mnie?

  Najprostszy eksperyment: znajdź w sieci przykładowy plik logów HTTP albo log systemowy z Linuxa. Zapytaj siebie: co tu się powtarza (timestamp, IP, metoda, URL)? Co wygląda inaczej niż reszta (nietypowy kod odpowiedzi, ścieżka, adres)? Jak mógłbyś pogrupować te wpisy, żeby z tego coś wyczytać? Po 10–15 minutach zobacz, jak się z tym czujesz.

  Jeśli pojawia się frustracja, ale jednocześnie rośnie ciekawość i chęć „rozgryzienia” wzorca – to bardzo dobry znak. Jeśli po minucie masz ochotę wszystko zamknąć, bo „za dużo tego” i nie widzisz sensu dalszego drążenia, codzienna praca w SOC czy przy analizie incydentów może okazać się męcząca. Zadaj sobie wtedy pytanie: czy wolę inną formę pracy z bezpieczeństwem, bardziej procesową lub projektową?