# A practical threat model for your hosted project

> Map assets and trust boundaries, choose a few realistic failure scenarios and turn them into controls you can test.

Canonical human page: https://swissoctet.com/insights/threat-model-a-hosted-project/

SwissOctet Editorial. Topic: operations. Level: Applied. Reading time: 6 minutes.

## Direct answer
A useful threat model explains what you protect, who or what can affect it, where trust changes and how you will reduce and test the most important risks. Start with the actual project rather than a generic list of tools.

## Define a scope small enough to reason about
Start with one working service: a customer portal, publishing site or internal application. Write down the components you operate and the external systems you rely on. A threat model should make assumptions visible, not suggest that every possible attack has been solved. Keep the first version small enough that the people deploying the application can explain it without a separate consultant interpreting the diagram.

List the valuable outcomes and assets. These may include customer data, administration access, payment state, published content and the ability to restore service. Availability can be an asset even when the information is public. Decide which failures would be inconvenient and which would damage people or the organisation. That distinction helps you prioritise controls instead of treating every warning equally.

## Draw the places where trust changes
OWASP's threat-model guidance uses data flows and trust boundaries to make a design understandable. For a small hosted application, draw the browser, web process, database, administrator, backup destination and external integrations. Mark the information moving between them. A request crossing from an untrusted client into a privileged server operation deserves explicit validation and authorisation.

Do not assume that being inside the same machine makes every component equally trusted. A public upload process should not have the same permissions as database administration. A backup job may need read access without the ability to modify live application records. Separating those roles makes the effect of a compromised component easier to contain and the required permissions easier to review.

## Choose concrete failure scenarios
Use a handful of plausible events to challenge the design. An attacker steals an administrator password; a user requests another user's record; an upload fills the disk; a deployment exposes a configuration file; a recovery copy cannot be restored. Describe the starting condition, the affected component and the consequence. A specific scenario is easier to test than a broad instruction to improve security.

Include mistakes and legitimate workflow abuse as well as external intrusion. A retry may create two valuable operations, or two requests may race to change the same object. OWASP's business-logic guidance highlights these process assumptions. Check who is allowed to move a workflow into its next state and whether repeating or reordering a request changes the result unexpectedly.

| Scenario | Control to investigate | Evidence to collect |
| --- | --- | --- |
| Stolen administration credential | Restricted access and a second factor where supported | An unauthorised login cannot complete |
| Another user's object requested | Server-side object authorisation | An isolated test returns a denied result |
| Disk exhausted by uploads | Size, quota and retention controls | A limit is enforced before service failure |
| Duplicate workflow request | Idempotency and transaction boundaries | A repeated request creates one outcome |

## Prioritise by impact and a credible path
For each scenario, record its potential impact and the conditions required for it to occur. Avoid pretending that a guessed numerical score is a precise probability. You can still distinguish an internet-exposed weak password from a highly conditional local event. Assign an owner and a practical next step to the important risks so the model creates work that someone can actually complete.

Consider the information lifecycle as well as application compromise. A diagnostic export can disclose unnecessary data during otherwise normal operation. A retained account field may create exposure long after its purpose ends. Privacy review can therefore remove information or shorten retention, while security review restricts access to what remains. Both changes belong in the model when they protect the project.

## Test the controls in an authorised environment
Create a staging environment with representative permissions and fabricated records. Test denied access, request limits, workflow retries and recovery. Do not use real customer data when synthetic data can demonstrate the behaviour. The objective is to verify the control, not to generate impressive attack traffic. Stay within systems you own or are explicitly authorised to assess.

Record what passed, what failed and what remains unknown. A scanner result can contribute evidence but does not replace a test of the application's business rules. Likewise, a network protection option does not verify object authorisation or secret-file handling. Attach the useful results to the scenario so future maintainers understand why a particular control exists.

## Keep the model connected to change
Review the relevant parts when you add an integration, expose a new endpoint, change a privilege or move data to another destination. You do not need to redraw the entire architecture for a minor text edit. The trigger is a changed assumption about access, information or system behaviour. Keep the model beside deployment and recovery documentation rather than leaving it as a one-time workshop output.

SwissOctet supplies a catalogue of infrastructure choices, not a completed application threat model. Choose the configuration and options that support your controls, then verify the deployment you build. A small, maintained model with tested actions is more useful than a large collection of security products with no clear explanation of the risks they address.

## Checklist
- List assets and consequences of failure.
- Draw data flows and trust boundaries.
- Choose specific intrusion, mistake and workflow scenarios.
- Assign controls and owners to the important risks.
- Test with synthetic data in an authorised environment.
- Review the model when a relevant assumption changes.

## Frequently asked questions
### Do I need a formal framework to start?
No. A small diagram and a documented set of scenarios can be useful. A framework helps ensure you review risks consistently.

### Does a vulnerability scanner replace threat modelling?
No. Scanners may find technical weaknesses, while a threat model also examines design assumptions, permissions and business workflows.

### How often should I update the model?
Update the affected parts when data flows, integrations, privileges or exposed functionality change, and review unresolved risks regularly.

## Primary sources
- [OWASP: Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
- [OWASP: Threat modelling in practice](https://devguide.owasp.org/en/04-design/01-threat-modeling/07-practical-threat-modeling/)
- [OWASP: Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html)

## Related infrastructure
- [Vector VPS](https://swissoctet.com/services/vector/index.txt): Your own Linux environment, with KVM virtualization and a clear path from small projects to larger workloads.
- [Metal Atlas](https://swissoctet.com/services/metal-atlas/index.txt): Dedicated compute with more memory and storage headroom for established workloads.
- [Canvas Web](https://swissoctet.com/services/canvas/index.txt): A clean foundation for websites and publishing. Pick your storage, domains and hosting options.

## Related guides
- [Build a backup you can actually restore](https://swissoctet.com/insights/build-a-backup-you-can-restore/index.txt): Choose a recovery target, protect an independent copy and practise the restoration before an incident forces the issue.
- [Secure Windows RDP administration without losing access](https://swissoctet.com/insights/secure-windows-rdp-administration/index.txt): Separate network reachability, authentication and privilege, then verify a recovery route before tightening remote access.
- [A Linux VPS hardening baseline you can maintain](https://swissoctet.com/insights/linux-vps-hardening-baseline/index.txt): Secure administration, expose only required services and establish updates and recovery without locking yourself out.