Module 5 · Unit 12 · Discussion 12
Threat Modelling a Service
Security is not a feature that can be added at the end; it is a property that emerges from design decisions made throughout a system's lifetime. Threat modelling is the discipline of systematically identifying what can go wrong before it does. This discussion asks you to apply a simple threat model to a small SaaS platform, identify the top threats, propose layered mitigations, and reason about the one trade-off you cannot avoid.
01 Overview
| Course | COMP 3150 / CMIS 3150 — Operating Systems |
|---|---|
| Unit | Unit 12 — Security and Protection |
| Weight | Part of the 5% participation grade (each discussion is worth approximately 0.4% of the final grade) |
| Opens | Monday of Week 12 |
| Initial post due | Thursday of Week 12, 23:59 |
| Peer replies due | Sunday of Week 12, 23:59 |
| Format | One initial post (550–700 words, including a threat table) and at least two substantive peer replies (150–250 words each) |
| CLOs assessed | CLO6, CLO7 |
02 Learning outcomes addressed
By participating in this discussion you will
- Explain the classical security goals — confidentiality, integrity, availability — and the principle of least privilege (U12.1).
- Describe Linux authentication and authorization mechanisms (U12.2, U12.3).
- Compare access-control models — DAC, MAC, RBAC — and their applications (U12.4).
- Explain the risks of setuid and how capabilities mitigate them (U12.5).
- Describe sandboxing and hardening techniques (U12.6).
- Apply a threat model to a realistic system and propose layered defences (U12.7).
This discussion assesses CLO6 (apply Linux systems tools) and CLO7 (evaluate operating-system security).
03 Discussion prompt
The scenario
You are the security engineer for a small SaaS company. The product is a web application with the following components:
- A public web front end. Runs on a Linux server, accepts HTTP and HTTPS, serves a static front end, and proxies API requests to the backend. It uses Nginx and a Python-based application server.
- An application backend. Runs on a separate Linux server. Implements the business logic, talks to the database, and accesses object storage for user uploads.
- A PostgreSQL database. Runs on a third Linux server. Stores user accounts, sessions, and business data. A read replica exists for analytics.
- An administrator panel. Used by the company's staff to manage accounts, view logs, and run reports. Accessible from the company's office network and from remote staff over VPN.
- A CI/CD pipeline. Runs on a fourth server. It builds the application from the company's Git repository, runs tests, and deploys to the front-end and back-end servers.
Your task
- Perform a threat model. Use the STRIDE framework (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to identify threats to the system. You do not need to be exhaustive; identify at least six threats across at least four of the six STRIDE categories.
- Prioritise the threats. Select the three threats you consider most serious, and explain why. Consider both impact (what happens if the threat is realised) and likelihood (how easy it would be for an attacker to realise it).
-
Propose layered mitigations.
For each of your top three threats, propose
a defence-in-depth strategy. Your defence
must use at least two different mechanisms
from the course — for example, a DAC
mechanism plus a MAC mechanism, or a
sandboxing mechanism plus an auditing
mechanism. For each mechanism, state:
- What it does.
- Which threat it mitigates.
- One limitation of the mechanism.
- Discuss one trade-off. Security always trades against some other property — performance, usability, development velocity, or cost. Choose one trade-off you made in your design (for example, the added latency of a sandboxing layer, or the development burden of a MAC policy) and explain how you would decide whether the trade-off is worth it. What metrics would you track? At what point would you relax the control?
- Reflect on what threat modelling adds. What does a systematic threat model catch that a code review or a penetration test would miss? What are the limits of the exercise — what kinds of threats does it not capture?
Your post should be 550–700 words. Include a table with the STRIDE categories, the threats you identified, and the priority. Cite at least one source (a textbook section, the STRIDE paper, an OWASP guide, or a documentation page for one of the mechanisms you propose).
04 Notes on the mechanisms
4.1 STRIDE
STRIDE is a mnemonic developed at Microsoft for categorising threats. Each letter maps to a security property it violates:
- Spoofing — authenticity.
- Tampering — integrity.
- Repudiation — non-repudiation.
- Information disclosure — confidentiality.
- Denial of service — availability.
- Elevation of privilege — authorization.
4.2 DAC, MAC, and RBAC
Discretionary access control (mode bits,
POSIX ACLs) allows the resource owner to grant or
deny access. Mandatory access control
(SELinux, AppArmor) enforces a global policy that
even the owner cannot override. Role-based
access control (sudo) assigns
permissions to roles. In a layered design, DAC
governs ordinary file access, RBAC governs
administrative privilege, and MAC provides a
system-wide policy that restricts even privileged
processes. All three are typically used together.
4.3 Setuid and capabilities
A setuid binary runs with the owner's effective
UID (often root). It is dangerous because any bug
in the binary — a buffer overflow, a TOCTOU race,
a failure to sanitise the environment — can be
exploited to gain the binary's privileges.
Capabilities replace this all-or-nothing
arrangement with fine-grained privileges: a
binary can be granted CAP_NET_BIND_SERVICE
to bind a low port without acquiring any other
root privilege. This is the principle of least
privilege applied to privilege itself.
4.4 Sandboxing
A sandbox confines a process to a limited set of
resources. Linux provides namespaces (mount, PID,
network, UTS, IPC, user), seccomp for
system-call filtering, cgroups for resource
limits, capabilities, and LSM policies. A
well-designed sandbox uses several of these
together. The core insight is that a sandbox is
only as strong as its weakest enforcement point:
a vulnerability in the kernel, an unfiltered
syscall, or a shared resource outside the sandbox
can allow an escape.
4.5 Auditing
Auditing records security-relevant events so that
they can be analysed after the fact. Linux's
auditd can log system calls, file
accesses, and other events. Auditing is not a
preventive control — it does not stop an attack —
but it is essential for detection and response.
05 Grading rubric
The discussion is marked out of 100 points. The criteria and their weights are given below.
| Criterion | Weight |
|---|---|
| Post quality (threat model, priorities, mitigations, trade-off) | 40% |
| Peer response quality | 30% |
| Engagement and timeliness | 20% |
| Netiquette and clarity | 10% |
5.1 Post quality (40 points)
| Level | Descriptor |
|---|---|
| Exemplary (90–100%) | A clear threat model with at least six threats across at least four STRIDE categories. The top three are selected with a reasoned impact-likelihood analysis. Each has a layered defence with at least two mechanisms, and each mechanism is correctly connected to the threat it mitigates. The limitations are stated. The trade-off discussion is concrete and metric-driven. The reflection on threat modelling is insightful. |
| Proficient (80–89%) | A clear threat model with six threats. The top three are selected with a reasoned justification. Each has at least one mitigation, and the mitigations are correctly chosen. The trade-off is mentioned. The reflection is present but brief. |
| Developing (70–79%) | The threat model is incomplete (fewer than six threats, or only one or two STRIDE categories). The top three are not clearly prioritised. The mitigations are generic. The trade-off and the reflection are superficial. |
| Beginning (60–69%) | The threat model is a list of generic security concerns rather than threats to the specific system. No mitigations are proposed, or they are not connected to the threats. |
| Not demonstrated (<60%) | The post is missing, off-topic, or a restatement of the prompt. |
5.2 Peer response quality (30 points)
The descriptors are the same as for Discussion 1. An exemplary reply might identify a threat the classmate missed, propose a mechanism the classmate did not consider, or challenge the prioritisation with a concrete argument.
5.3 Engagement and timeliness (20 points)
The descriptors are the same as for Discussion 1.
5.4 Netiquette and clarity (10 points)
The descriptors are the same as for Discussion 1.
06 Resources
- Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 16 (Security and Protection).
- Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 9 (Security).
- Saltzer, J. H., & Schroeder, M. D. The Protection of Information in Computer Systems. Proceedings of the IEEE, 1975.
- Shostack, A. Threat Modeling: Designing for Security. Wiley, 2014.
- Microsoft's STRIDE documentation (the original description of the framework).
- OWASP Top Ten and the OWASP Threat Modeling Cheat Sheet.
- Linux man-pages:
man 7 capabilities,man 2 seccomp,man 7 namespaces,man 5 sudoers,man 8 setfacl,man 8 setcap,man 8 auditctl. - Linux kernel documentation:
Documentation/admin-guide/LSM/,Documentation/userspace-api/seccomp_filter.rst.