Tampere University Information Security Master's Thesis Guide: 30 ECTS, COMP.SEC-S02 and Trepo

What governs the Information Security thesis?

Tampere University’s international Information Security option is part of the Master’s Programme in Computing Sciences and Electrical Engineering and awards Master of Science (Technology). The programme is 120 ECTS and designed for two years of full-time study. That degree title determines the thesis family: the thesis follows Tampere’s Technology thesis process and is 30 ECTS, graded on the 0-5 scale.

The current 2026-2027 curriculum exposes several similarly named security objects, so careful boundary control matters. The international programme object TTEM-ISY Information Security is at least 120 ECTS. The engineering advanced-studies object COMP.SEC-S02 Advanced Studies in Information Security is at least 80 ECTS, taught in English and current through 2026-2027. Tampere also exposes a separate COMP.SEC-S01 engineering module of at least 60 ECTS and a separate TIM-ISY Master of Science Information Security curriculum. Do not mix their credit structures into the MSc Technology applicant route without checking your current Sisu study plan.

1. What Information Security means academically

The applicant-facing programme covers security and privacy from theoretical to applied perspectives. Tampere names cryptography, network security, software security, access management and identity management among the study areas. The programme also emphasises learning how to protect systems and how to analyse systems for weaknesses.

This breadth means an Information Security thesis can be theoretical, empirical, design-oriented, implementation-led, measurement-based or literature-based. A thesis does not need to perform penetration testing, discover a new vulnerability or build a new security product. The research question should determine the method.

2. COMP.SEC-S02 and the advanced-studies boundary

Current COMP.SEC-S02 expects students to understand digital security and privacy, assess existing systems, analyse/design/implement secure systems and contribute to scientific research in security and privacy. Those outcomes are useful for thesis scoping because they combine engineering and research rather than treating security as only operational practice.

A second current module, COMP.SEC-S01, is listed at at least 60 ECTS. This guide does not pretend those two objects are interchangeable or assign one to every possible study right. For the international MSc Technology route, use the current programme structure shown in your own Sisu plan. The public evidence proves that both objects are current; it does not justify silently merging them.

3. Do not import the separate TIM-ISY MSc structure

Tampere also has a current TIM-ISY Information security curriculum under a Master of Science route. That object explicitly describes a different structure including 50 ECTS advanced studies and a 30 ECTS thesis. It is a useful non-conflation control, not a template for the applicant-facing MSc Technology guide.

Both routes can legitimately contain a 30 ECTS thesis while still following different degree regulations and programme structures. Thesis credit value alone does not determine whether the work is a Technology diplomityö or a non-technical MSc thesis. Follow the degree title and your own curriculum object.

4. The 30 ECTS Technology thesis

For Information Security MSc Technology students, Tampere’s current Technology thesis framework applies. The thesis is 30 ECTS. Topic and method can vary, but the work must demonstrate independent scholarly and professional competence appropriate to the degree.

A strong security thesis does more than show that a tool ran, an attack worked in a lab or a defence improved one metric. It defines a research problem, states assumptions, chooses a defensible evaluation, analyses evidence and discusses limitations. Engineering implementation can be central, but the thesis needs an academic argument around it.

5. Start with a threat model

Security questions become clearer when the threat model is explicit. Identify the protected asset, adversary goal, adversary capability, trust boundaries and assumptions. Also state what is outside scope. A defence against a remote unauthenticated attacker is a different claim from resistance to a privileged local attacker or a malicious administrator.

Do not use “secure” as an undefined outcome. Security is always relative to a property and threat model. A system may protect confidentiality under one assumption while providing weak availability under another.

For privacy-oriented work, identify what information could be learned, by whom, under which data or access conditions. Privacy and security overlap, but they are not identical.

6. Keep security experiments authorised and contained

Academic intent does not create permission to probe systems. Perform security testing only in environments where you have explicit authorisation. Prefer owned systems, Cyber Labs, test networks, virtual machines, isolated ranges, synthetic datasets or deliberately vulnerable training targets when live systems are unnecessary.

Document the test boundary in the thesis. If a company commissions the project, clarify which hosts, applications, accounts, data and techniques are authorised before testing begins. Do not expand the test scope because a tool discovers another reachable system.

If a weakness could affect third parties, discuss disclosure and publication timing with the supervisor and affected organisation. A public thesis should not create avoidable harm by releasing sensitive operational details before remediation.

7. Vulnerability research: finding is not the same as proving

Automated scanners and static-analysis tools can produce false positives and false negatives. Treat findings as hypotheses that require validation in an authorised environment. A scanner count is rarely a meaningful thesis result by itself.

For a vulnerability-oriented thesis, define the class of weakness being studied, selection criteria, validation method and severity or impact framework. Explain which findings were excluded and why. Avoid measuring “security” only by the number of alerts.

If the thesis develops a detection method, evaluate sensitivity and specificity or another suitable error framework. A system that reports everything as suspicious can have high recall but little practical value.

8. Cryptography theses: separate model, implementation and performance

Cryptographic research can involve protocols, constructions, implementations or applied evaluation. Be explicit about which layer the thesis studies. A mathematically secure construction can still have implementation flaws; a fast implementation does not prove the underlying protocol secure.

When benchmarking cryptographic software, record algorithm/parameter choices, library versions, compiler settings, hardware platform and workload. Compare like with like. If hardware acceleration is enabled for one implementation but not another, state that clearly.

Do not claim a new cryptographic scheme is secure solely because attacks were not found experimentally. Security claims normally depend on formal assumptions, proofs or established analysis appropriate to the construction.

9. Network-security experiments

Tampere’s applicant page describes Cyber Labs with switches, routers, next-generation firewalls, virtualisation, SDN capability, traffic generation and monitoring. That environment supports controlled network-security research, but the thesis still needs a clear experiment design.

Document topology, device and software versions, firewall/routing policy, traffic profile, monitoring configuration and timing. If comparing detection or mitigation approaches, use comparable traffic and attack scenarios. Separate normal background traffic from injected test events.

Network measurements can be affected by buffering, synchronisation, packet loss, sampling and capture placement. If the conclusion depends on latency or detection rate, explain where and how it was measured.

10. Software-security theses

Software-security work can focus on secure development, code analysis, dependency risk, authentication, access control, memory safety, vulnerability detection or another justified topic. Reproducibility requires more than publishing a script.

Record application version, dependency versions, build configuration, compiler/runtime settings and test corpus when they affect the result. If using static or dynamic analysers, document tool versions and important configuration.

A tool comparison should use a defined ground truth or defensible validation process. Otherwise differences in alert counts may only reflect different taxonomies or defaults.

11. Identity and access-management topics

The programme explicitly includes access and identity management. A thesis in this area should define the security property being evaluated: authentication strength, authorisation correctness, privilege minimisation, usability-security trade-offs, policy consistency or another narrow question.

When user studies are involved, treat participant data and authentication artefacts carefully. Credentials, tokens and logs can be sensitive even if the project is not formally classified. Use test accounts where possible and never expose real credentials in the thesis.

For policy analysis, distinguish intended policy from effective enforcement. A documented role model does not prove that the deployed system enforces it correctly.

12. Privacy research and personal data

Privacy is a named programme theme. If the thesis uses personal data, treat data protection as part of research design rather than a final administrative task. Define purpose, data controller arrangements, minimisation, access, retention and secure storage with the supervisor before collection or transfer.

Security logs can contain identifiers, IP addresses, user behaviour or authentication events. Do not assume log data are anonymous. Pseudonymisation can reduce direct identification while still leaving data personal.

When publishing results, consider disclosure risk from small groups, rare events or detailed examples. Aggregate reporting can still expose individuals in narrow datasets.

13. Security metrics and validity

Choose metrics that correspond to the question. Detection research may need precision, recall, false-positive rate, false-negative rate, time-to-detection or cost. Authentication research may need error rates, attack success probability or user-performance measures. Performance-security work may require latency, throughput, resource use and security efficacy together.

Avoid choosing metrics after seeing which ones make the proposed method look strongest. Define primary evaluation criteria before final testing where practical.

External validity matters. Results from one network, software version, dataset or threat model do not automatically generalise to another environment. State that boundary directly.

14. Baselines and comparative evaluation

A security mechanism needs an appropriate baseline. Compare against the existing control, a simpler method, established tool or no-defence condition depending on the question. Keep test conditions comparable.

If the proposed approach is extensively tuned, give the baseline a fair configuration. Otherwise the comparison tests researcher effort rather than the method.

Report negative or mixed results. A defence that reduces attack success but doubles false positives or system overhead may still be useful, but the trade-off should be visible.

15. Reproducibility and evidence preservation

Keep version control for code, configuration, experiment scripts and documentation. Record test-environment versions and relevant commits. Security research is especially sensitive to version drift because a patched dependency can change the result completely.

Preserve raw measurements separately from processed results. Keep a data dictionary or event schema for logs. Record how alerts or events were matched to ground truth.

If company data or exploit details cannot be shared publicly, reproducibility can still be improved with synthetic examples, pseudocode, configuration descriptions, test-harness logic and a clear account of what was withheld.

Pre-register the main security evaluation where feasible

Security experiments are vulnerable to researcher degrees of freedom: choosing favourable attack variants, filtering inconvenient runs, changing thresholds after inspection or repeatedly tuning a detector against the final test set can make an apparently strong result difficult to trust. Before the decisive evaluation, freeze the main threat model, primary metric, baseline, dataset or traffic split, and the conditions that count as a successful attack or defence. Exploratory work can continue, but distinguish it from the confirmatory result.

Also plan how you will handle nondeterminism. Network timing, randomised defences, fuzzing, probabilistic classifiers and concurrent systems can vary across runs. Use enough repetitions to characterise that variability and report the spread rather than only the best run. If an experiment fails because the environment changed, preserve that fact in the research log instead of silently replacing the run.

16. ITC.CEE.800 Tools for theses

Current ITC.CEE.800 Tools for theses is 5 ECTS and pass/fail. Its four current parts are research methods, research ethics, information searching skills and career planning. All parts of the completion option are compulsory for students who take the course, and Tampere recommends completing it before the thesis.

The current course no longer lists the old one-credit presentation/seminar component found in older curricula. Do not copy a historical CSEE seminar structure into 2026-2027.

The current public Information Security advanced-studies pages used for this guide do not prove ITC.CEE.800 is compulsory in every student’s plan. Check its exact placement in your own Sisu study plan.

17. Seminar and presentation boundary

Tampere’s Technology thesis process still requires seminar/presentation activity. Current public Information Security evidence, however, does not establish a separate current Information Security-specific thesis seminar course code.

Follow the implementation in current Sisu and Moodle. Confirm attendance, presentation and any opposition or feedback requirements with the programme. Do not resurrect the old Computer Sciences seminar or older ITC.CEE.800 seminar component simply because archived pages remain searchable.

18. Topic, supervisor and research environment

The applicant page points to Cyber Labs and NISEC as part of the Information Security research environment. A thesis can also be commissioned by an external organisation or originate from a student proposal if academically suitable.

Match supervision to the thesis’s centre of gravity. Applied cryptography, network defence, software security, privacy and identity research can need different expertise. If the project crosses areas, agree who owns the primary academic question and who advises secondary technical layers.

Before accepting an industry topic, check whether the thesis can be written as a public academic document. A useful company project can still be unsuitable if the evidence cannot be described publicly enough for examination.

19. Thesis Supervision Plan and scope control

Technology students use a Thesis Supervision Plan. Agree the question, method, schedule, supervision practices and expected milestones early. Security work should add explicit authorisation and disclosure controls.

Write down the testing boundary, environments, credentials, datasets and responsible contacts. If external systems are involved, preserve written permission appropriate to the project.

Define a fallback if access is withdrawn or a vulnerability is patched during the thesis. A research plan should survive routine changes in a fast-moving security environment.

20. Literature review and standards

The literature review should connect the security problem to prior research and, when relevant, standards, protocols or recognised guidance. Distinguish peer-reviewed research from vendor documentation, vulnerability databases, advisories and blog posts.

Technical documentation can be essential primary evidence for an implementation, but it does not replace scholarly literature when the thesis makes research claims. Use each source for the role it can legitimately support.

For fast-moving vulnerabilities, record dates and versions. A security statement can become obsolete after a patch or protocol change.

21. AI use in security research

Tampere’s current AI guidance permits appropriate assistance while keeping responsibility with the student. AI-generated code, security explanations, configuration suggestions or literature summaries must be independently verified.

Do not provide credentials, confidential code, unpublished vulnerability details, personal data or restricted logs to an external AI service without an approved basis. Security projects often contain exactly the material that should not leave the controlled research environment.

If AI is itself the research object, document the model/service version, relevant settings and evaluation conditions. Treat model output as generated data, not as an authoritative security source.

22. Writing confidential and sensitive results

Tampere theses are public documents. Separate confidential company material from the assessed public manuscript. Avoid placing credentials, private keys, unpatched exploit details, sensitive architecture or personally identifying logs in the thesis.

This does not mean hiding the method. Describe the research design, evidence and limitations at a level that supports academic examination without exposing protected details. If redaction would remove the substance of the thesis, redesign the project earlier rather than at final submission.

Responsible disclosure may require coordinating publication timing with affected organisations. Discuss this before the final manuscript is made public.

23. Maturity test, Turnitin and Trepo

The master’s degree includes a maturity test under Tampere’s current rules. For international Technology master’s students, the thesis abstract normally serves as the maturity test at MSc stage, while individual language-history situations can change the route.

After supervisor permission, the final thesis goes through Turnitin originality checking. Similarity percentage is not an automatic plagiarism verdict; the comparison report must be interpreted.

The final thesis is submitted through Tampere’s process and deposited in Trepo. The permanent archival file should be PDF/A. Keep enough time for file conversion and administrative completion.

24. Examination, grading and appeal

Information Security follows the Technology thesis 0-5 grading scale. Architecture’s pass/fail exception does not apply. Any pass/fail course such as ITC.CEE.800 is separate from the thesis grade.

The examiners normally have 21 days to assess the thesis, extended to 28 days where the applicable maturity-test route requires it. These are assessment windows, not the thesis-writing timeline.

The student receives the proposed assessment and has the current response and appeal rights. Once the thesis is approved, it is final rather than freely resubmittable.

25. Practical Information Security thesis workflow

1. Confirm your study right is the MSc Technology Information Security route and check the exact TTEM-ISY/COMP.SEC structure in Sisu.
2. Confirm the 30 ECTS Technology thesis and whether ITC.CEE.800 appears in your plan.
3. Define a narrow security or privacy research question and threat model.
4. Obtain explicit authorisation for every system, dataset and account used in security testing.
5. Choose a contained research environment and define baselines, metrics and ground truth.
6. Record versions, configurations, data provenance and experiment scripts.
7. Validate scanner/tool findings rather than treating output as truth.
8. Plan personal-data, company-confidentiality and responsible-disclosure handling early.
9. Complete the current seminar/presentation implementation shown in Sisu/Moodle without importing historical course codes.
10. Write alongside experiments and preserve negative findings and limitations.
11. Complete maturity, Turnitin, Trepo PDF/A, examination and graduation processing.

The strongest Information Security thesis is not the one with the most dramatic vulnerability. It is the one where the threat model, authorisation, method, evidence and public reporting fit together tightly enough that the conclusion is both academically defensible and responsibly produced.