Jak napisać pracę magisterską z cyberbezpieczeństwa i inżynierii bezpieczeństwa – poradnik

Praca magisterska z cyberbezpieczeństwa to jeden z niewielu dyplomów, przy których promotor może zapytać wprost: „Czy to przebadałeś na prawdziwych systemach?” – i nie będzie to komplement. Kierunek stoi na przecięciu techniki (ataki, exploity, kryptografia, analiza sieci) i prawa (RODO, dyrektywa NIS2, polska ustawa o KSC, normy ISO). Błąd metodologiczny tutaj nie kończy się tylko na słabej ocenie – może mieć konsekwencje prawne. To sprawia, że pisanie tej pracy jest inne niż na większości kierunków informatycznych.

Jednocześnie cybersecurity to pole, gdzie opublikowane raporty instytucji takich jak CERT Polska, ENISA czy CISA dają dostęp do danych, jakich inne dziedziny mogłyby ci zazdrościć. MITRE ATT&CK Framework kataloguje techniki atakujących w sposób, który jest gotowym szkieletem do analizy. CVE/NVD to baza podatności z opisami, ocenami CVSS i referencjami do exploitów. Jeśli dobrze dobierzesz temat i środowisko testowe, możesz napisać pracę opartą na realnych danych – bez narażania się na kłopoty.

Poniżej znajdziesz praktyczny przewodnik: od wyboru tematu, przez metodologię i setup laboratorium, po to, czego promotor i komisja będą szukać na obronie.

Specyfika kierunku – co odróżnia cyberbezpieczeństwo od zwykłej informatyki

Większość kierunków informatycznych pozwala pisać prace w trybie „zaimplementuj i zmierz”. W bezpieczeństwie podział jest głębszy: jesteś albo po stronie atakującego (offensive security), albo obrońcy (defensive security). Dobra praca magisterska zazwyczaj obejmuje oba – bo żeby skutecznie bronić, trzeba rozumieć atak.

Strona ofensywna to analiza podatności, testy penetracyjne, inżynieria wsteczna malware’u, fuzzing aplikacji, ataki na protokoły kryptograficzne. Tutaj pracujesz z narzędziami takimi jak Metasploit, Burp Suite, OWASP ZAP, Nmap, Volatility. Punktem odniesienia jest OWASP Top 10 (edycja 2021 jest aktualna) – lista najczęstszych klas podatności aplikacji webowych, od Broken Access Control po Server-Side Request Forgery.

Strona defensywna to monitoring, detekcja, reagowanie na incydenty. SOC (Security Operations Center), SIEM (Security Information and Event Management), threat intelligence, analiza logów, forensics sieciowy. Narzędzia: Wazuh, Splunk, Elastic Security, Zeek, Suricata. Frameworki obrony: NIST Cybersecurity Framework (CSF 2.0 z 2024), architektura Zero Trust (NIST SP 800-207).

W środku jest modelowanie zagrożeń – metodologie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) i PASTA (Process for Attack Simulation and Threat Analysis). To narzędzia do strukturyzowanego myślenia o tym, gdzie system jest podatny, zanim zaczniesz testować.

Osobna warstwa to regulacje. Dyrektywa NIS2 (obowiązuje od października 2024 w UE) nakłada wymagania na operatorów usług kluczowych i istotnych. W Polsce implementuje ją ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC), znowelizowana w 2023-2024. ISO 27001/27002 to normy zarządzania bezpieczeństwem informacji – certyfikacja organizacji. NIST CSF to podejście ramowe stosowane głównie w USA, ale coraz częściej globalnie. Jeśli twoja praca dotyka compliance, musisz znać te dokumenty, nie tylko ich nazwy.

CTF-y (Capture the Flag) – zawody hakerskie – to osobna ścieżka, z której wielu studentów cybersecurity korzysta praktycznie. Jeśli masz udokumentowane wyniki z HackTheBox, TryHackMe albo CTF akademickich, możesz to włączyć do kontekstu pracy. To pokazuje komisji, że nie piszesz teorii z głowy.

Wybór tematu – konkretne propozycje z realiami 2024-2025

Najgorzej wybrany temat w tej dziedzinie to taki, który brzmi poważnie, ale nie da się go zbadać etycznie i bezpiecznie. „Analiza ataków na infrastrukturę krytyczną” – pięknie, ale co konkretnie zrobisz? Dobry temat ma jasno określone środowisko badawcze i daje się zmierzyć.

Tematy, które realnie działają:

• Analiza podatności aplikacji webowych w sektorze bankowym PL przy użyciu OWASP ZAP i Burp Suite – środowisko: własna instancja testowej aplikacji (np. DVWA, WebGoat, Juice Shop), metodologia: OWASP Testing Guide, wyniki: klasyfikacja podatności według CVSS.

• Implementacja i ocena skuteczności SIEM Wazuh dla małych i średnich przedsiębiorstw – studium przypadku. Wazuh to open-source, działa na własnym serwerze, masz pełną kontrolę nad środowiskiem. Możesz symulować ataki i mierzyć czas detekcji.

• Analiza łańcucha ataku ransomware LockBit 3.0 na podstawie raportów CERT Polska, CISA i FBI. To praca analityczna – nie testujesz malware’u, analizujesz opublikowane raporty i budujesz mapę technik ATT&CK. Bezpieczna metodologicznie, a materiału nie brakuje.

• Security by design w konteneryzacji – analiza konfiguracji Docker/Kubernetes pod kątem CIS Benchmark. Środowisko: lokalny klaster Minikube, narzędzia: kube-bench, Trivy, Falco. Mierzysz odstępstwa od baseline’u bezpieczeństwa i oceniasz ryzyko.

• Detekcja anomalii sieciowych metodami uczenia maszynowego – IsolationForest na danych PCAP. Łączysz ML z security. Zbiory danych: NSL-KDD, CICIDS 2017/2018 – publicznie dostępne, z etykietami ataków. Piszesz w Pythonie, mierzysz precision/recall/F1.

• Phishing simulation jako metoda szkolenia bezpieczeństwa – analiza skuteczności kampanii edukacyjnej vs. pasywnych szkoleń. Jeśli masz dostęp do organizacji (firma, uczelnia), możesz zrobić eksperyment za pisemną zgodą. Narzędzia: GoPhish (open-source).

• Zero Trust implementacja w środowisku Microsoft 365 – analiza Conditional Access, Azure AD (Entra ID) i polityk DLP. Można badać na środowisku dev/testowym z bezpłatnym tenantciem Azure.

Przy każdym temacie pytaj się: czy mam dostęp do środowiska, w którym to zbadam? Czy dane są publicznie dostępne albo mogę je wygenerować legalnie? Czy promotor rozumie temat na tyle, żeby ocenić metodologię?

Osobna kategoria to tematy oparte na threat intelligence. Możesz np. zbadać ewolucję taktyk konkretnej grupy APT (Advanced Persistent Threat) na podstawie publicznych raportów z okresu 2021-2024 – mapując techniki w ATT&CK i analizując zmiany. Takie prace są czysto analityczne, ale wymagają dobrego warsztatu badawczego i znajomości kontekstu geopolitycznego. CERT Polska i ENISA regularnie publikują analizy grup powiązanych z Rosją, Chinami, Koreą Północną – to gotowy materiał źródłowy z pełną dokumentacją.

Metodologia – jak badać bezpieczeństwo bez łamania prawa

To jest krytyczny punkt. Testy penetracyjne bez pisemnej zgody właściciela systemu są przestępstwem – w Polsce odpowiada za to art. 267 KK (nieuprawniony dostęp do systemu informatycznego). Nawet jeśli „tylko sprawdzasz”, nawet jeśli system jest słabo zabezpieczony, nawet jeśli robisz to „w celach badawczych”.

Bezpieczne ramy metodologiczne:

Pierwsza opcja to własna infrastruktura laboratoryjna. VirtualBox lub VMware, Kali Linux jako maszyna atakującego, Metasploitable 2/3 albo DVWA jako cel. Sieć izolowana (host-only lub NAT bez dostępu do internetu). Wszystko działa lokalnie, nie ma żadnego ryzyka prawnego. To standardowe podejście dla prac dyplomowych.

Druga opcja to legalne platformy CTF/lab. HackTheBox, TryHackMe, VulnHub – maszyny stworzone specjalnie do testowania, z regulaminem, który wprost zezwala na ataki. Możesz opisywać swoje podejście metodologiczne na podstawie pracy z tymi maszynami.

Trzecia opcja to analiza wtórna opublikowanych danych. Raporty CERT Polska (publikuje co kwartał), raporty CISA Advisories, analizy ENISA Threat Landscape, opisy CVE z NVD, whitepapery dostawców (Mandiant, CrowdStrike, Recorded Future). Budujesz analizę na tym, co jest publicznie dostępne.

Czwarta opcja to badanie za pisemną zgodą. Firma, instytucja lub uczelnia wyraża pisemną zgodę na przeprowadzenie audytu. Dokument musi precyzować zakres, czas trwania, systemy objęte badaniem i odpowiedzialność stron. To closest do prawdziwego pentestingu, ale wymaga formalności.

Metodologia techniczna powinna opierać się na uznanym standardzie. PTES (Penetration Testing Execution Standard) definiuje fazy: rozpoznanie, skanowanie, eksploatacja, post-eksploatacja, raportowanie. OWASP Testing Guide (v4.2) to szczegółowy podręcznik dla testów aplikacji webowych. Dla compliance – ISO 27001 Annex A jako checklist kontroli.

W rozdziale metodologicznym opisz dokładnie:
– jakie środowisko zbudowałeś (wersje oprogramowania, topologia sieci, hardware)
– jakie narzędzia uruchomiłeś i w jakiej kolejności
– jak rejestrowałeś wyniki (logi, screenshoty, pcap)
– jak oceniałeś ryzyko (CVSS v3.1 albo v4.0)
– co zrobiłeś, żeby upewnić się, że testy nie wychodzą poza środowisko lab

Struktura pracy – co gdzie powinno stać

Typowy układ dla pracy z cyberbezpieczeństwa (60-100 stron):

Wstęp – problem badawczy, cel pracy, hipoteza, struktura. Powiedz wprost, co badasz i dlaczego to ma znaczenie. Nie opisuj, że „internet jest ważny”.

Rozdział 1 – Tło i kontekst – threat landscape (możesz oprzeć się na ENISA Threat Landscape 2024), regulacje prawne (NIS2, KSC, RODO w kontekście security), przegląd literatury. Tutaj pokazujesz, że rozumiesz pole, w którym pracujesz. Odwołaj się do konkretnych statystyk: liczba incydentów raportowanych przez CERT Polska w ostatnim roku, dane ENISA o kosztach naruszeń, rankingi CVE według CVSS.

Rozdział 2 – Metodologia badań – szczegółowy opis środowiska i podejścia (patrz wyżej). To rozdział, który komisja czyta uważnie. Brak jasnej metodologii = słaba ocena, niezależnie od wyników.

Rozdział 3 – Wyniki – co znalazłeś, co zmierzyłeś, jak wygląda to w liczbach. Dla pentestingu: lista podatności z klasyfikacją CVSS, przykłady exploitów (z zanonimizowanymi danymi jeśli potrzeba), mapa ATT&CK (które techniki zostały użyte). Dla pracy analitycznej: tabele porównawcze, wykresy, statystyki.

Rozdział 4 – Dyskusja – co wyniki oznaczają, jak mają się do literatury, jakie są ograniczenia badania. Ograniczenia wpisuj uczciwie – komisja i tak je widzi, lepiej że ty je nazwieniasz.

Rozdział 5 – Rekomendacje – co powinien zrobić administrator, organizacja, prawodawca. Konkrety, nie ogólniki.

Rozdział 6 – Etyka i odpowiedzialność – osobny podrozdział lub cały rozdział. Opisz jak zadbałeś o to, żeby badanie było legalne i etyczne. Powołaj się na kodeks etyczny (np. EC-Council Code of Ethics, ISC2 Code of Ethics). To ważne – promotor z tej branży będzie to sprawdzał.

Zakończenie – podsumowanie, wnioski, kierunki dalszych badań.

Jeden praktyczny tip: zanim napiszesz rozdział wynikowy, porozmawiaj z promotorem o tym, jak ma wyglądać dokumentacja testów. Niektórzy wymagają pełnych logów w załączniku, inni wystarczy syntetyczny raport. Lepiej wiedzieć wcześniej niż przepisywać.

Narzędzia i źródła – co realnie używają profesjonaliści

Dobór narzędzi do pracy magisterskiej powinien odpowiadać temu, co jest używane w branży – nie temu, co jest najprostsze do nauki.

Narzędzia Kali Linux (dystrybucja dedykowana security):
– Nmap – skanowanie sieci, wykrywanie otwartych portów i wersji usług
– Metasploit Framework – framework do eksploatacji podatności, zawiera setki modułów
– Burp Suite Community Edition – proxy do analizy ruchu HTTP, aktywne i pasywne skanowanie aplikacji webowych
– OWASP ZAP – alternatywa dla Burpa, open-source, dobre API do automatyzacji
– Wireshark – analiza pakietów sieciowych, PCAP
– Volatility 3 – analiza memory forensics (dump pamięci)
– Nikto – skaner podatności serwerów webowych
– Gobuster / Feroxbuster – directory bruteforcing
– John the Ripper / Hashcat – łamanie hashów

Dla defensive security i SIEM:
– Wazuh – open-source SIEM + XDR, można wdrożyć lokalnie
– Elastic SIEM / ELK Stack – analiza logów na dużą skalę
– Suricata / Snort – IDS/IPS (Intrusion Detection/Prevention System)
– Zeek (dawniej Bro) – monitoring sieci i analiza protokołów

Frameworki i bazy danych:
– MITRE ATT&CK – katalog technik i taktyk atakujących, z mapowaniem na narzędzia i grupy APT. Adres: attack.mitre.org
– CVE/NVD (National Vulnerability Database) – baza podatności z ocenami CVSS. Adres: nvd.nist.gov
– OWASP (Open Web Application Security Project) – standardy, narzędzia, checklist. Adres: owasp.org
– Exploit-DB – archiwum publicznie znanych exploitów

Źródła akademickie i branżowe:
– CERT Polska – raporty kwartalne, statystyki incydentów PL (cert.pl)
– ENISA Threat Landscape (roczny raport, edycja 2024 dostępna na enisa.europa.eu)
– CISA Advisories i Known Exploited Vulnerabilities (KEV) catalog (cisa.gov)
– SANS Reading Room – artykuły praktyczne z bezpieczeństwa
– IEEE Security & Privacy, ACM CCS – konferencje naukowe z recenzowanymi pracami
– arXiv cs.CR – preprinty z kryptografii i bezpieczeństwa

Literatura:
– William Stallings, „Cryptography and Network Security” – klasyk, solidne podstawy
– Bruce Schneier, „Secrets and Lies” oraz „Applied Cryptography”
– Ross Anderson, „Security Engineering” (3. edycja 2020, dostępna za darmo na stronie autora)
– Georgia Weidman, „Penetration Testing” (No Starch Press) – praktyczne podejście
– Jon Erickson, „Hacking: The Art of Exploitation”

Przy pracy opartej na analizie raportów: CERT Polska publikuje każdego roku raport „Krajobraz bezpieczeństwa polskiego internetu” – to legitne źródło z danymi o atakach, phishingu, botnetach w polskiej sieci. Możesz cytować go jako podstawowe źródło danych.

Kryptografia stosowana – osobna ścieżka dla prac teoretyczno-technicznych

Nie każda praca z bezpieczeństwa musi opierać się na testach penetracyjnych. Kryptografia stosowana to osobna nisza, która daje inne możliwości badawcze – i inne wymagania.

Prace kryptograficzne zazwyczaj obejmują jedno z trzech:

Implementacja i analiza protokołu. Bierzesz protokół (TLS 1.3, Signal Protocol, WireGuard) i badasz go: albo implementujesz uproszczoną wersję, albo analizujesz istniejącą implementację pod kątem zgodności ze specyfikacją, poprawności generowania kluczy, podatności na znane ataki (padding oracle, timing attack, BEAST). Wymaga dobrej znajomości matematyki (teoria liczb, algebra liniowa) i programowania w C/Python/Rust.

Analiza bezpieczeństwa systemu uwierzytelniania. OAuth 2.0/OIDC, JWT, WebAuthn/FIDO2 – to protokoły, których używają miliony aplikacji i które mają udokumentowane podatności. Możesz zbadać konkretną implementację (np. popularną bibliotekę open-source) pod kątem błędów: nieprawidłowa walidacja podpisu JWT (alg: none), słabe generowanie state w OAuth, podatność na replay attack.

Zastosowanie kryptografii w konkretnym kontekście. Np. analiza bezpieczeństwa przechowywania haseł – porównanie Argon2id, bcrypt i scrypt pod kątem odporności na ataki GPU. Albo analiza implementacji szyfrowania end-to-end w aplikacjach mobilnych. Albo ocena bezpieczeństwa podpisu elektronicznego kwalifikowanego (eIDAS) w polskich systemach.

Co odróżnia prace kryptograficzne metodologicznie: potrzebujesz bardziej formalnego aparatu pojęciowego (definicje bezpieczeństwa, modele zagrożeń, dowody bezpieczeństwa w uproszczonej formie), ale masz mniejsze ryzyko prawne – atakujesz protokoły matematycznie albo testujesz własne implementacje.

Dobre źródła: Coursera „Cryptography I” Bona (Stanford), Dan Boneh & Victor Shoup „A Graduate Course in Applied Cryptography” (dostępne za darmo online), RFC dokumentujące protokoły (IETF), CryptoPals challenges jako ćwiczenia praktyczne.

Najczęstsze błędy w pracach z cyberbezpieczeństwa

Widzę pewne powtarzające się problemy, które obniżają ocenę albo prowadzą do poprawek. Warto znać je z góry.

Brak wyraźnej hipotezy badawczej. „Celem pracy jest zbadanie bezpieczeństwa aplikacji webowych” to nie hipoteza. „Aplikacje webowe w badanym środowisku testowym zawierają podatności sklasyfikowane jako High lub Critical według CVSS v3.1, wynikające z błędów w kontroli dostępu i walidacji danych wejściowych” – to hipoteza. Promotor i komisja szukają odpowiedzi na pytanie: co konkretnie chciałeś sprawdzić i czy to potwierdziłeś?

Środowisko niezdefiniowane albo niereprezentatywne. Opisujesz wyniki bez podania wersji oprogramowania, konfiguracji, topologii sieci. Recenzent nie może zreplikować badania – to poważny problem metodologiczny. Tabela „wersje komponentów środowiska testowego” powinna być w pracy.

Mylenie narzędzia z metodologią. „Użyłem Metasploita” to nie metodologia. Metodologia to: wybrałem fazy PTES, w fazie rozpoznania zastosowałem pasywne OSINT (Shodan, theHarvester), aktywne skanowanie Nmap z profilami -sV -sC, identyfikację podatności za pomocą OpenVAS, a eksploatację przez Metasploit w kontrolowanym środowisku VM. Różnica jest ogromna.

Pominięcie ograniczeń badania. Każde badanie ma ograniczenia – środowisko laboratoryjne != produkcja, próba jest mała, narzędzia mają FP/FN. Napisz to sam, zanim napisze to recenzent w uwagach.

Nieaktualne źródła. W cybersecurity dane sprzed 5 lat są często nieaktualne. Jeśli cytujesz raport o zagrożeniach z 2019, komisja zapyta o to, co się zmieniło. Priorytetyzuj źródła z ostatnich 2-3 lat, szczególnie w rozdziale o threat landscape.

Brak rozróżnienia CVS Base Score od CVSS Temporal/Environmental. CVSS Base Score opisuje podatność w izolacji. W twojej pracy interesuje cię też Temporal (czy jest exploit, czy producent wydał patch) i Environmental (jak ważny jest system w kontekście twojej organizacji/badania). To pokazuje głębsze rozumienie oceny ryzyka.

Zbyt obszerne wstępy, za mało wyników. Połowa pracy to definicje, historia internetu, opis co to jest firewall. A wyniki na 8 stronach. To odwrócone proporcje – wstęp i teoria powinny zajmować góra 30-35% pracy, reszta to metodologia + wyniki + dyskusja.

Obrona pracy – na co się przygotować

Komisja na obronie pracy z cyberbezpieczeństwa jest bardziej techniczna niż na większości kierunków. Zakładaj, że przynajmniej jeden recenzent rozumie, o czym mówisz – i będzie pytał konkretnie.

Pytania, które słyszę najczęściej od studentów po obronie:

O etykę i legalność: „Jak upewnił się Pan/i, że testy nie wyszły poza środowisko laboratoryjne?” – musisz opisać konfigurację sieci (izolacja, brak routingu do internetu) i pokazać, że to było kontrolowane. Nie wystarczy powiedzieć „robiłem to na VirtualBoxie”.

O uogólnienie wyników: „Wyniki odnoszą się do Metasploitable 3 – jak ma się to do realnych systemów?” – to uczciwe pytanie. Odpowiedź: opisz, jakie klasy podatności badałeś i jak mają się do OWASP Top 10 albo CVE w realnych produktach. Twoja praca to nie audyt konkretnej firmy, ale model badawczy.

O narzędzia: „Dlaczego wybrał/a Pan/i Burp Suite, a nie ZAP?” – miej uzasadnienie. Burp ma lepszy interfejs do manualnych testów, ZAP lepsze API do automatyzacji. Znaj różnicę.

O wyniki negatywne: „Nie znalazł/a Pan/i żadnych podatności wysokiego ryzyka – dlaczego?” – wyniki negatywne są wynikami. Opisz co to oznacza: albo środowisko było dobrze skonfigurowane, albo zakres testów był ograniczony. Bądź precyzyjny.

O aktualność: „Praca bazuje na danych z 2023 – co się zmieniło?” – w cybersecurity rok to dużo. Wiedz, co się wydarzyło po dacie twojego badania, przynajmniej w zarysie.

Jedna rzecz, która zawsze robi dobre wrażenie: przygotuj diagram architektury środowiska testowego. Rysunek sieci laboratoryjnej (nawet prosty, zrobiony w draw.io) pokazuje komisji, że naprawdę to zbudowałeś.

FAQ – Najczęstsze pytania

Natalia Witek-Dąbrowska

Redaktorka i korektorka z 20-letnim doświadczeniem

Specjalizuję się w korekcie prac naukowych i dyplomowych. Jeśli potrzebujesz pomocy z tekstem, napisz do mnie.