Security Analyst vs Security Engineer: Jaki jest rzeczywisty podział?
Praktyczne wyjaśnienie, czym różnią się role analityka bezpieczeństwa i inżyniera bezpieczeństwa w pracy codziennej, umiejętnościach i ścieżkach kariery.
Te stanowiska są używane zamiennie w ogłoszeniach o pracę, ale praca na co dzień jest naprawdę inna. Jeśli wybierasz kierunek do nauki, zrozumienie podziału zaoszczędzi ci miesięcy zmarnowanego czasu na certyfikaty i umiejętności, które się nie sprawdzą.
Co analityk robi przez cały dzień
Analityk bezpieczeństwa spędza większość czasu obserwując, triage'ując i śledząc zagrożenia. To oznacza patrzenie na SIEM (Splunk, Sentinel, QRadar), pracę z kolejkami alertów i decyzję, czy flagowany proces na stacji roboczej to fałszywy alarm, czy początek incydentu. Dużą część pracy stanowi pisanie raportu z ustaleń na tyle jasno, że menadżer lub klient bez wiedzy o bezpieczeństwie zrozumie, co się stało.
Analytycy Tier 1 robią triage. Analytycy Tier 2/3 głębiej — wyciągają process trees, sprawdzają telemetrię EDR w czymś takim jak CrowdStrike czy Defender for Endpoint, korelują logi w firewall'ach i identity providerach, aby zbudować oś czasu. Praca ma charakter reaktywny: coś się dzieje, ustalasz, co to oznacza i co z tym zrobić.
Typowa lista zadań analityka: przejrzenie alertów z nocy, zamknięcie fałszywych alarmów z udokumentowanym uzasadnieniem, eskalacja podejrzanego wykonania PowerShell, aktualizacja runbooka po nowym wzorcu phishingu oraz udział w call'u incydentu. To praca śledcza i wymagająca komunikacji.
Co inżynier naprawdę buduje
Inżynier bezpieczeństwa buduje i utrzymuje systemy, na których polega analityk. To pisanie reguł detekcji w Sigma lub KQL, strojenie SIEM, aby nie zalewał kolejki szumem, wdrażanie i konfiguracja agentów EDR na 5000 endpointów, lub automatyzacja playbooку phishingu w platformie SOAR, takiej jak Tines czy Cortex XSOAR.
Inżynierowie pracują także przed incydentami: utwardzanie konfiguracji cloud'u w AWS czy Azure, konfiguracja segmentacji sieci, pisanie Terraform do wymuszania reguł security group, łatanie CI/CD pipeline'ów, aby sekrety nie przeciekały do git history. Wiele pracy inżynierskiej jest niewidoczne, dopóki się nie psuje — nikt nie zwróci uwagi na dobrze skonfigurowaną regułę WAF, ale wszyscy zwrócą, gdy jej brakuje.
Gdy analityk pyta „co się tu stało,
Napisane z pomocą AI, zweryfikowane i opublikowane przez Michal Pilch (CISSP), Korra Studio.
To jedna notatka z bazy wiedzy Korra Studio — platforma łączy każdy temat z mentoringiem 1 na 1.
Zacznij za darmoarrow_forward