University of Turku Cyber Security Master’s Thesis Guide: DTEK1002, DTEK1103, 30 ECTS and UTUGradu

Quick answer: what is the University of Turku Cyber Security thesis route?

The current Cyber Security specialisation track in the University of Turku Master’s Degree Programme in Information and Communication Technology is a 120 ECTS, two-year Master of Science (Technology) programme in the Faculty of Technology. The controlling current curriculum object is ICTCS2427 / programme 99351. The exact thesis is DTEK1002 Master’s Thesis in Technology, 30 ECTS, graded 0-5, with TTDK1308, 0 ECTS as the maturity examination. The track-specific seminar is DTEK1103 Master’s Thesis in Technology Seminar, Cyber Security Engineering, 5 ECTS, Pass/Fail. Keep DTEK1103 separate from DTEK1002 and do not automatically equate it with the public page’s separate 10 ECTS “Studies supporting Master’s thesis” line.

1. Start from ICTCS2427 / programme 99351

Cyber Security is one of five ICT specialisation tracks. For thesis planning, use the current 2024-2027 Peppi object rather than copying another track’s structure. The public programme page is useful for the high-level degree architecture, but the exact courses, credits and placement need to be read from Peppi and the student’s current HOPS.

2. The degree is 120 ECTS even when Peppi shows a selection range

The public programme page defines the degree as 120 ECTS. Peppi can display a root range such as 117-127 ECTS because optional modules are represented with minimum and maximum values. That technical range is not a new degree size. Your final personal study plan still has to resolve to the degree requirements approved for your study right.

3. Understand the public 40 + 10 + 30 summary

The public page describes 40 ECTS advanced-level major studies, 10 ECTS studies supporting the Master’s thesis, and a 30 ECTS Master of Science in Technology Thesis, alongside thematic/minor and other studies. This is a useful summary, but it is not numerically identical to how the current Peppi tree labels the same curriculum.

4. Peppi models an 82 ECTS Advanced Studies block

Programme 99351 contains ISCAS2427, 82 ECTS. Inside it are 20 ECTS Cyber Security, 22 ECTS Cryptography and Management, a 10 ECTS Common Studies in ICT choice category, and the 30 ECTS thesis category. The 20 + 22 breakdown means Peppi exposes 42 ECTS of major-content categories where the public page gives a 40 ECTS headline. Preserve that difference in your planning notes instead of silently forcing the two descriptions to match.

5. The public 10 ECTS support line is not one fixed seminar package

Current Peppi names the 10 ECTS category Common Studies in Information and Communication Technology and marks it as a choice block. Its options include project/working-life and language-study objects such as Capstone, Internship and Finnish courses. Therefore, do not describe the public “10 ECTS studies supporting Master’s thesis” line as a fixed 10 ECTS research-methods or thesis-seminar package unless your current HOPS explicitly shows that configuration.

6. DTEK1103 is a separate 5 ECTS Cyber Security thesis seminar

The track-specific course DTEK1103 Master’s Thesis in Technology Seminar, Cyber Security Engineering is 5 ECTS, Advanced Studies and Pass/Fail. Its learning outcomes explicitly support the student’s thesis, research-method choices and presentation skills. Current Moodle identifies it as the MSc Thesis Seminar for Cyber Security, Cyber Security Engineering and EIT Digital Cyber Security students.

7. Do not hide the DTEK1103 placement issue

Programme 99351 lists DTEK1103 under Other Studies, not as a child of the compulsory 30 ECTS thesis category and not inside the 10 ECTS Common Studies block. DTEK1002 nevertheless requires presentation in a related thesis seminar. The safe interpretation is: DTEK1103 is the relevant track-specific seminar process, but its exact placement in your degree should be confirmed in your HOPS. Do not call it embedded inside the 30 ECTS thesis and do not automatically say it consumes half of the public 10 ECTS support line.

8. DTEK1002 is the exact 30 ECTS thesis course

The thesis itself is DTEK1002 Master’s Thesis in Technology, 30 ECTS. It is an Advanced Studies course, can be completed in Finnish or English and is graded 0-5. The course expects scientific work, management of research methods, knowledge of the research field and scientific writing. A cybersecurity build or test becomes thesis work only when it is connected to a defensible research problem and evidence chain.

9. Build the plan with your assigned supervisor or supervisors

DTEK1002 requires a thesis plan at the beginning. When seeking a topic, the student should contact a professor of the main subject so supervisors can be assigned. Company and organisation challenges are possible, including co-supervision, and a University research-group thesis is also possible. Put the security problem, target environment, threat model, methods, data/traffic/log sources, permissions and intended evidence into the plan early.

10. Know the examiner and approval chain

The thesis is evaluated by at least two examiners using University grading guidance. Final acceptance and grading are decided by the head of the department based on the examiner evaluations. That is separate from seminar completion. Keep the examiner-ready thesis, seminar deliverables and HOPS/course completion evidence distinct so one missing administrative step does not block the final degree process.

11. TTDK1308 is the 0 ECTS maturity examination

The thesis category also contains TTDK1308 Degree Qualifying Examination for Master’s Degree, 0 ECTS. Normally the thesis abstract or another suitable part serves as the maturity test and demonstrates knowledge of the thesis field. A conditional written-exam route can apply depending on prior degree and Finnish/Swedish educational-language background, so verify your own case rather than copying another student’s maturity-test route.

12. Use DTEK1103 as a thesis-development process, not only a presentation requirement

DTEK1103 asks students to analyse a previous relevant thesis, present their own thesis near completion, participate in peer presentations and complete a research-methods exercise. The course is designed for about 135 hours of work. Use it to test whether your research question, method, evidence and conclusion fit together, not merely to satisfy an oral-presentation checkbox.

13. Define the cyber-security evidence type before collecting data

A Cyber Security thesis can be a secure-system design study, controlled penetration-test study, IDS/IPS evaluation, digital-forensics investigation, IoT-security evaluation, privacy-engineering study, human-factor study, cryptographic analysis or a mixed project. These evidence types support different claims. Decide first what kind of evidence can answer the question, then choose tools and datasets.

14. Write the threat model before using the word “secure”

A useful threat model identifies the asset, adversary capabilities, trust boundaries, assumed protections and success condition. “The system is secure” is normally too broad. A stronger conclusion says that a specific control resisted a defined attack class under a stated configuration and test protocol. That wording also makes limitations much easier to defend.

15. Separate vulnerability discovery from exploitability

A scanner, static analyser or configuration checker can identify a potential issue, but a finding is not automatically a confirmed exploitable vulnerability. Validate important findings using safe, authorised methods and record the target version and configuration. If a controlled proof-of-concept is necessary, keep it bounded to the smallest demonstration required to support the scientific claim.

16. Authorisation is part of the research method

The programme teaches ethical hacking, but a university thesis does not grant permission to probe arbitrary third-party systems. Use owned, course-provided, CTF, laboratory or explicitly authorised targets. If the project involves a company, define the allowed systems, time window, data handling, prohibited actions and reporting channel before testing begins. Treat scope documentation as part of research validity, not as paperwork added later.

17. Do not generalise a lab result into a production claim

DTEK8063 and related courses use controlled security laboratories. A result from one firewall, IDS/IPS, traffic mix or testbed supports a claim about that evaluated setting. Production networks can differ in topology, policy, user behaviour, software versions and attack distribution. State what was tested and what remains untested.

18. Report IDS/IPS metrics with operational meaning

For detection research, define the positive and negative classes, sampling process and evaluation split. False positives and false negatives create different costs. A single accuracy value can hide a detector that performs poorly on the events that matter. Explain class balance, attack mix and threshold selection so a reviewer can interpret the reported metric.

19. Freeze the target configuration for security experiments

Record operating-system and application versions, patch level, network topology, relevant firewall or service configuration, test data and tool versions. A vulnerability can disappear after a patch or appear only under a particular configuration. Without a frozen environment description, later reproduction may be impossible and comparisons can become misleading.

20. Treat security engineering and empirical validation as separate layers

DTEK0039 and DTEK8025 emphasise secure design and system assurance. A strong architecture can be justified conceptually, but implementation errors can still invalidate it. Conversely, one successful test cannot prove the architecture safe against every threat. Explain the design rationale, then evaluate concrete security properties with evidence appropriate to the implemented system.

21. IoT-security claims need architecture boundaries

For an IoT thesis, specify which layers are actually studied: end device, radio/link, gateway, edge, cloud service, identity infrastructure or application. Authentication, authorisation and channel protection solve different problems. A lightweight cryptographic mechanism should be interpreted together with resource limits and the exact security objective rather than described as universally “secure for IoT.”

22. Human-factor cyber security can become human-subject research

DTEK2029 covers digital footprints, behaviour, awareness and risk. If your thesis surveys users, observes behaviour, uses account-linked traces or experimentally changes warnings/interfaces, the ethics and privacy route can be different from a purely technical lab study. Define what is collected, why it is needed, who can access it and how participation or organisational permission is handled.

23. Digital footprints and logs can remain personal data

Security telemetry can include usernames, device identifiers, IP-related information, authentication events or incident narratives. Removing obvious names does not necessarily make the data anonymous if people or devices remain linkable. Use the minimum necessary data, document access controls and keep protected raw material separate from public examples.

24. Digital forensics needs an auditable evidence chain

DTEK2091 covers file-system, log, malware, memory and network forensics. Keep original evidence conceptually separate from working copies and analysis outputs. Link each conclusion to the artifact or trace that supports it. Document time-zone or clock assumptions in timeline work and collection-point limitations in network forensics, because missing visibility can change the interpretation.

25. Integrity checks do not prove interpretation

Hashes or equivalent integrity controls can show that a file or image has not changed between two documented points, but they do not prove that the analyst’s interpretation is correct. Likewise, recovered deleted data does not automatically prove user intent. Keep technical integrity, provenance and substantive interpretation as separate parts of the argument.

26. Privacy engineering is not the same thing as confidentiality

DTEK8102 connects security, privacy, GDPR, anonymisation and differential privacy. Encryption and access control can protect data, but they do not by themselves establish lawful or privacy-preserving processing. If the thesis uses anonymisation or differential privacy, state the mechanism, assumptions, parameters and utility trade-off instead of using “anonymous” as an untested label.

27. Cryptography claims need parameter and key-management context

Cyber Security students also study mathematical cryptography. When encryption, signatures or authentication appear in the thesis, identify the concrete algorithm/protocol, parameter choices, key-management assumptions and the property it supports. Passing functional tests shows the implementation behaves as expected for those tests; it does not prove resistance to every implementation attack or misuse scenario.

28. Capstone, internship and thesis have different academic roles

DTEK0088 Capstone develops team-based engineering and project skills. DTEK0045 Internship develops professional competence through supervised work and reflection. Either can provide context for a thesis, but neither automatically substitutes for DTEK1002’s scientific research requirement. If workplace data or a Capstone prototype becomes thesis evidence, define the research question, permissions, method and publication boundary separately.

29. Build a reproducibility manifest

For experiments, preserve a small manifest linking research question, target version/configuration, code revision, traffic/dataset/test case, random seed where relevant and generated outputs. Record hardware and software environment for timing or throughput results. The goal is not to publish secrets; it is to make the scientific path from input to conclusion traceable.

30. Separate development data from final evaluation evidence

Repeatedly tuning a detector, exploit heuristic or model against the same final test set can make the result look better than it generalises. Where the method is data-driven, keep a development/tuning stage separate from the final evaluation evidence. Document any unavoidable overlap and bound the conclusion accordingly.

31. Keep negative findings and failed attack hypotheses

A thesis is not weaker because an attack hypothesis fails or an expected vulnerability is absent in the tested version. Negative results can narrow the threat model, invalidate an assumption or show that a control worked under specific conditions. Preserve them when they materially affect interpretation instead of selecting only dramatic findings.

32. Confidential vulnerability detail needs an early disclosure plan

Company or research-group projects may involve source code, network maps, credentials, logs or vulnerability details. Decide early what can appear in the public thesis, what stays in protected research storage and what must be described at a higher level. Reproducibility can use synthetic fixtures or redacted configurations when real operational detail cannot safely be disclosed.

33. Use AI under the DTEK1002 disclosure rule

DTEK1002 explicitly permits generative-AI tools but requires clear documentation so the student’s own work can be identified and graded. If AI generates code, threat-model text, references or security explanations, validate them against primary sources and actual execution/evidence. Never upload protected source code, credentials, private keys, incident logs or partner data to an uncontrolled AI service.

34. Distinguish AI as a research object from AI as a research assistant

Several Cyber Security courses now discuss AI in security contexts. A thesis may evaluate AI as part of the security system, use AI to assist analysis, or do both. State the role clearly. Model performance, hallucination risk and data handling belong to the research design when AI is the object; disclosure and verification belong to academic integrity when AI is an assistant.

35. Turnitin checks originality, not cyber-security validity

Turnitin is part of the University thesis originality workflow. A low similarity score does not prove that a vulnerability is exploitable, a threat model is appropriate, a forensic interpretation is correct or an IDS benchmark is unbiased. Originality, research integrity, security validity and empirical validity are separate quality controls.

36. UTUGradu is the institutional submission route

UTUGradu manages higher-degree thesis submission, examination, approval and electronic publication/archiving. Before upload, make sure the examiner-ready manuscript matches the final evidence, confidentiality has been resolved and the required originality process is complete. Recheck current operational instructions at submission because interface and workflow details can change independently of the 30 ECTS thesis rule.

37. A safe penetration-testing thesis workflow

Start with written scope and authorisation, define target/version and threat hypothesis, create a controlled test plan, collect only the evidence needed, validate findings without unnecessary disruption, record configuration and tool versions, analyse impact and limitations, then coordinate reporting with the responsible owner. The thesis should explain what the controlled evidence establishes without becoming an operational playbook for attacking unrelated systems.

38. A digital-forensics thesis workflow

Define the forensic question, acquisition source and legal/organisational authority, preserve provenance, create working copies or controlled analysis inputs, document tools and versions, extract relevant artifacts, build the timeline or event reconstruction, test alternative explanations and map each conclusion back to evidence. Keep personally identifiable or confidential material out of public appendices unless disclosure is authorised and necessary.

39. A network/IoT security thesis workflow

Define architecture and trust boundaries, choose the security property, freeze device/network/software versions, build the authorised testbed, establish a normal baseline, execute the planned bounded tests, record traffic and results consistently, compare with the baseline, analyse failures and residual risk, then reproduce one central result from the preserved configuration before freezing the manuscript.

40. Freeze a claim-to-evidence map before submission

List each headline conclusion and the evidence that supports it: configuration analysis, controlled exploit, IDS/IPS experiment, forensic artifact, user study, cryptographic argument, privacy analysis or literature synthesis. Put the strongest defensible verb beside it. This catches category errors such as using a scanner finding to claim universal exploitability or using one lab benchmark to claim production security.

41. Reproduce one headline result from scratch

From a clean or controlled environment, regenerate one important figure, detection table, forensic timeline, vulnerability result or performance measurement from the documented inputs. Check that versions, units, configuration and manuscript values match. Investigate material differences rather than manually editing the final table to look consistent.

As a second check, compare the reproduced result with the exact manuscript claim, not merely with an older notebook or screenshot. Confirm that the same target version, configuration, input set, aggregation rule and exclusion criteria were used. If the result depends on timing, traffic load, random sampling or model inference, record the acceptable tolerance before looking at the regenerated value. A reproducibility check is most useful when it can expose a stale parameter or hidden manual step rather than simply reproduce a preferred number.

For vulnerability or forensic work, also verify that the public manuscript does not accidentally contain credentials, private keys, internal addresses, identifying log fragments or operational exploit details that were present in the working evidence. Redaction should not alter the scientific meaning of the finding. Keep a protected internal mapping where necessary so the examiner can understand how the public evidence relates to the original material without disclosing it to every reader.

Finally, check the HOPS and seminar record together. Because DTEK1103 is a separate 5 ECTS object and the current Peppi 10 ECTS Common Studies block is not the same thing, make sure both the thesis-seminar obligation and the degree-credit placement are actually satisfied for your study right. A technically excellent thesis can still be delayed by a missing course registration or incorrectly assumed credit placement.

42. Final Cyber Security checklist

Confirm ICTCS2427 / programme 99351, 120 ECTS, the public 40 + 10 + 30 structure, the Peppi 82 ECTS Advanced Studies packaging, DTEK1002 30 ECTS, DTEK1103 5 ECTS Pass/Fail, TTDK1308 0 ECTS, at least two examiners and department-head final acceptance/grading. Verify the exact HOPS placement of the 10 ECTS Common Studies/support area rather than merging it with the seminar. Then audit authorisation, threat model, reproducibility, privacy/ethics, confidentiality, AI disclosure, Turnitin and UTUGradu.