Od PM do bezpieczeństwa: co się faktycznie przenosi

Kierownicy projektów myślący o przejściu do cyberbezpieczeństwa często zakładają, że zaczynają od zera. Się mylą. Miękkie umiejętności, które dały Ci powodzenie w zarządzaniu projektami — zarządzanie interesariuszami, śledzenie ryzyka, koordynacja incydentów — mapują się bezpośrednio na pracę w bezpieczeństwie. Czego brakuje, to podstawy techniczne, i tę lukę można zamknąć w ciągu 12-18 miesięcy, jeśli będziesz o tym deliberatnie myśleć.

Co się faktycznie przenosi

Jeśli zarządzałeś projektem z rejestrem ryzyka, już rozumiesz podstawową logikę oceny ryzyka bezpieczeństwa: zidentyfikuj aktywa, oszacuj prawdopodobieństwo i wpływ, zdecyduj o działaniu (zaakceptuj, zmniejsz, przenieś, unikaj). Zespoły bezpieczeństwa używają dokładnie tej samej struktury, tylko stosowanej do systemów zamiast dostaw. NIST Risk Management Framework i ISO 27005 to sformalizowane wersje tego, co kierownik projektów certyfikowany w PMP już robi intuicyjnie.

Zarządzanie incydentami to kolejne obszar, w którym się pokrywają. Prowadzenie war room podczas przestoju produkcji jest strukturalnie podobne do prowadzenia go podczas ataku ransomware: ktoś musi być odpowiedzialny za komunikację, ktoś musi śledzić oś czasu, ktoś musi podejmować decyzje pod presją bez pełnych informacji. Zespoły bezpieczeństwa nazywają to incident command; ty możesz to rozpoznać jako zarządzanie kryzysowe z innym słownictwem.

Nadzór nad dostawcami i umowy również się dobrze przenoszą. Zarządzanie ryzykiem trzeciej strony — weryfikacja dostawców SaaS, przegląd raportów SOC 2, negocjowanie klauzul bezpieczeństwa w umowach — to rosnąca nisza wewnątrz ról GRC (governance, risk, and compliance), i wynagradza kogoś, kto już wie, jak czytać umowę i zarządzać relacją z dostawcą.

Luka techniczna, której nie możesz pominąć

Tu застревают większość przejść z PM do bezpieczeństwa: nie możesz zarządzać SOC, przejrzeć raport pen testu lub zaplanować plan remedial podatności bez zrozumienia tego, co się pod tym kryje. Potrzebujesz praktycznej wiedzy na temat sieci (TCP/IP, DNS, jak firewall faktycznie filtruje ruch), podstawowej linii poleceń Linux i tego, jak działają podatności OWASP Top 10 w praktyce, a nie tylko jako punkty na slajdzie.

To nie oznacza, że staniesz się penetration testerem. Oznacza to, że potrafisz przeczytać wyjście skanera Nessus lub Qualys i zrozumieć, dlaczego brakujący patch na porcie 445 ma znaczenie, lub dlaczego uwierzytelniona instancja Redis narażona na internet to pożar pięciozadań. Poświęć czas home lab: uruchom kilka maszyn wirtualnych w VirtualBox, zainstaluj pfSense jako firewall, uruchom Wireshark wobec własnego ruchu. Koncepcje przylegają szybciej, gdy sam coś sobie zepsujesz.

Certyfikaty, które mają sens dla tej ścieżki

Pomiń bezpośrednie przejście do OSCP lub czegokolwiek ciężkiego w zabezpieczeniach ofensywnych — to inny tor. Dla historii PM, sekwencja, która zwykle działa, to:

1. CompTIA Security+ — daje Ci słownictwo i koncepcje fundamentalne w całej sieci, zagrożeniach i kontrolach.
2. CISM lub CRISC (ISACA) — te skupiają się na governance i ryzyku, co gra na Twoje istniejące mocne strony i jest często bardziej odpowiednie dla ról GRC lub menedżera programu bezpieczeństwa niż certy techniczne.
3. CISSP — ostatecznie, gdy masz już pewną praktyczną ekspozycję; wymaga pięciu lat odpowiedniego doświadczenia do pełnej certyfikacji, więc to cel w połowie drogi, a nie punkt wyjścia.

Unikaj zbierania certów jako zastępstwa dla doświadczenia. Menedżer ds. zatrudnienia na stanowisko Security Program Manager chce zobaczyć, że możesz inteligentnie mówić o procesie triażu alertów SIEM, a nie że masz cztery akronimy po swoim imieniu.

Gdzie faktycznie wylądujesz jako pierwszy

Realistyczny punkt wejścia zwykle to nie