TS-54: Threat Modeling
🚧 DRAFT
This technical standard covers the art and science of threat modeling. It provides guidance on how to identify potential security and privacy vulnerabilities in software systems, and how to decide on mitigation strategies, in a structured and systematic way. It also covers the practical considerations for maintaining a risk register.
What is threat modeling?
Threat modeling is the process of analyzing representations of a system with the purpose of identifying potential security and privacy vulnerabilities, and deciding on mitigation strategies.
Threat modeling is more of a process than a tool or an artifact. There are various tools and frameworks that can be used to facilitate the process, but the core of threat modeling is the systematic analysis of a system’s design to identify potential attack vectors and vulnerabilities.
The output of threat modeling workshops is a set of identified threats, with associated risk ratings and mitigation strategies. These are typically captured initially in a threat assessment table, and ultimately maintained in the application’s risk register.
General best practices
Threat modeling works best when it is iterative, baked into the regular development process, rather than a one-time activity.
Threat modeling workshops SHOULD begin during the design phase of a new software product. Thereafter, the threat assessments SHOULD be treated as living documents that are regularly revised as the system evolves, new threats emerge, or business requirements change.
Threat modeling workshops SHOULD NOT be postponed until the product/system is nearly ready to ship to production. With iterative threat assessment you will catch potential vulnerabilities earlier in the development cycle, when they will be cheaper to remediate. Because security and privacy requirements are cross-cutting architectural concerns, they tend to be expensive to retrofit into an established architecture.
It is RECOMMENDED to schedule threat modeling workshops at the breakpoint between each iterative development/release cycle. Threat modeling workshops should be organized and facilitated by a security champion within each team.
Effective threat modeling benefits from a multi-disciplinary approach. Participants in threat modeling workshops should be drawn from architecture and security, product and business, and development, testing, and operations. The purpose is to view the system from diverse perspectives.
Various types of models SHOULD be used as input to threat modeling workshops. Different representations of a system will reveal different categories of potential attack vectors. RECOMMENDED models include:
- Infrastructure.
- Data (in situ and in transit).
- Services and components.
- Component boundaries and interfaces.
- Business processes (or application logic).
- External dependencies.
See also the Threat Modeling Manifesto for more information about the principles of threat modeling.
Threat modeling frameworks
There are a number of standardized frameworks that can be used to guide the threat modeling process. These frameworks provide structured approaches to identifying potential threats and vulnerabilities.
The following standardized threat modeling frameworks may be helpful, depending on the type of system being modeled. You may choose to use a combination of these frameworks, or a custom framework tailored to your own needs.
STRIDE
The core activity of a threat modeling workshop is the systematic assessment of individual components and data flows within a system against various categories of potential threats.
One of the most useful frameworks for this part of the process is STRIDE, a mnemonic-based framework developed by Microsoft that categorizes threats into six groups:
Threat category | Definition | Example | Examples of countermeasures |
|---|---|---|---|
Spoofing | Impersonation of another user or system (Wikipedia) | Faking an email address to manipulate the recipient into sharing confidential information | Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM) to verify the sender |
Tampering | Unauthorized modification of data (Wikipedia) | Modifying data on a website to redirect visitors to a phishing page | Hashes and digital signatures for data validation and tamper detection |
Repudiation | Measures that attackers take to leave no trace of their malicious actions (Wikipedia) | Altering log files to hide unauthorized access | Audit and logging mechanisms to track all system activity, and automated log analysis to reveal suspicious events |
Information disclosure | Leaking of sensitive data to unauthorized parties (Wikipedia) | Hacking into a database to steal credit card information | Encryption of sensitive data, and access control mechanisms |
Denial of service (DoS) | Rendering a system unusable (Wikipedia) | Flooding a website with excessive requests to crash the server | Rate limiting to prevent DoS, and load balancing to distribute traffic across multiple servers |
Elevation of privilege | Gaining higher access levels than authorized (Wikipedia) | Exploiting a vulnerability to elevate user permissions, allowing access to confidential data or systems | Implementing the principle of least privilege with role-based access controls |
PASTA
PASTA – Process for Attack Simulation and Threat Analysis – is a multi-stage methodology that aligns business objectives with technical requirements. The stages progress through:
- Defining the business objectives.
- Defining the technical scope.
- Decomposing the application into its component parts.
- Identifying potential vulnerabilities.
- Enumerating the likelihood and impact of attacks.
To identify potential vulnerabilities, analysts use either the STRIDE framework or a vulnerability database (see below).
The end result is a comprehensive risk and impact assessment.
PASTA can be a very time-consuming process so it does not lend itself to fast iterative development processes. It is most suited to long-lived critical systems.
VAST
VAST – Visual, Agile, and Simple Threat modeling – is designed to scale threat modeling across entire organizations and to work well with iterative development workflows. VAST’s scalability makes it a good fit for organizations with multiple teams and products, and short release cycles.
VAST covers two types of threat modeling:
- Application threat modeling for development teams, focusing on process flow diagrams.
- Operational threat modeling for infrastructure teams, focusing on attack trees.
LINDDUN
LINDDUN is a privacy-focused threat modeling framework. It serves as a privacy-oriented counterpart to STRIDE. LINDDUN helps identify privacy threats by systematically examining how personal data flows through a system and where privacy violations may occur. The name is an acronym for the following threat classifications:
- Linkability. An attacker can link two or more items of data without knowing the actual identity behind them.
- Identifiability. An attacker can identify a specific user or system entity.
- Non-repudiation. A user cannot deny having performed a malicious action.
- Detectability. An attacker can determine whether an item of interest (eg a user or transaction) exists in the system.
- Disclosure of information. When sensitive data is exposed to unauthorized parties.
- Unawareness. When users are unaware that their data is being collected, processed, or shared, and therefore cannot exercise meaningful control over it.
- Non-compliance. When a system or its operators fail to comply with privacy-related regulations, standards, or user agreements.
LINDDUN is recommended for systems handling personal information, particularly those subject to regulations like GDPR or CCPA.
Attack trees
Attack trees are hierarchical diagrams representing how attackers might compromise a system to achieve a specific goal.
The tree’s root represents the attacker’s ultimate objective, with branches showing different paths or sub-goals needed to achieve it. Leaf nodes represent specific actions or vulnerabilities the attacker could exploit.
Attack trees can be enriched with attributes like cost, likelihood, or required skill level.
Attack trees are useful models for visualizing complex attack scenarios, where multiple steps are required to compromise a system.
Kill chains
A kill chain (or cyber kill chain) is a framework originally developed by Lockheed Martin that models the stages of a cyber attack. The traditional seven stages are:
- Reconnaissance. Research and target identification.
- Weaponization. Creating a malicious payload.
- Delivery. Transmitting the weapon to the target.
- Exploit. Triggering the exploit.
- Installation. Installing malware.
- Command and control. Establishing remote access.
- Actions on objectives. Achieving the attacker’s goal.
Understanding these stages helps defenders implement layered defenses. The framework is particularly valuable for understanding advanced threats.
Threat modeling workshops
Threat modeling workshops SHOULD be conducted at regular intervals. It is RECOMMENDED to schedule threat modeling workshops at the breakpoint between each iterative development or release cycle. Betters still, workshops should be integrated into the normal development life cycle of individual features.
Threat modeling workshops SHOULD be organized and facilitated by a security champion within each team. The rest of the participants play the role of security analysts.
Effective threat modeling benefits from a multi-disciplinary approach. Therefore, threat modeling workshops are the most effective when participants are drawn from architecture and security, product and business, and development, testing, and operations. The purpose is to view the system from diverse perspectives.
Threat modeling workshops SHOULD follow a structured approach. The following steps are RECOMMENDED:
- Review business objectives and scope.
- Review component architecture, data flows, system interfaces, etc.
- Systematically assess threats against individual components.
- Rank risks based on assessment of likelihood and impact.
- Identify and prioritize mitigation strategies.
The outcome of a threat modeling workshop is a list of identified threats, risk ratings, and agreed mitigation strategies (if any). The outcomes of a threat modeling workshop SHOULD be captured in a formal report, with the identified threats and their mitigation strategies summarized in a threat assessment table.
The following serves as a useful starter template for reporting the outcomes of a threat modeling workshop. It incorporates patterns from threat modeling frameworks such as STRIDE and PASTA. A concrete example follows.
# Threat modeling workshop <YYYY-MM-DD> - **System/application name:** _____ - **Workshop facilitator:** _____ - **Participants:** - **Business stakeholder:** _____ - **Technical architect:** _____ - **Development lead:** _____ - **Security analyst:** _____ - **Privacy officer (eg. data controller):** _____ - **Other stakeholders:** _____ Pre-workshop checklist: - [ ] Schedule participants. - [ ] Gather architecture diagrams and documentation. - [ ] Review previous threat models (if updating). - [ ] Prepare collaboration tools (whiteboard, diagramming software). Workshop checklist: - [ ] Review business objectives and scope. - [ ] Review component architecture, data flows, system interfaces, etc. - [ ] Assess STRIDE threat categories against individual components. - [ ] Rank risks based on assessment of likelihood and impact. - [ ] Identify and prioritize mitigation strategies. Post-workshop checklist: - [ ] Distribute completed threat assessment to stakeholders. - [ ] Create tickets for mitigation work. - [ ] Schedule next treat modeling workshop - [ ] Transfer newly identified threats to the risk register. ## Business context What are the business objectives? Why does the system exist? What business value does it provide? What are the critical business functions? Who are the key stakeholders? What is the business impact of security/privacy failures – eg. financial, reputational, regulatory, operational, etc.? ## Technical scope Define what is being threat modeled. What the system boundaries, or the in-scope components? What is the technology stack? What are the deployment environments? What are the integration points or interfaces with other (out-of-scope) systems? ## System decomposition How does the system work? Include or link to architectural diagrams and other useful design documents and models. Use the models to identify key components, data flows, entry points, trust boundaries, and the most sensitive assets. ### Key components Identify the key components of the system, along with their trust levels and the categories of data they handle. Internal components tend to be trusted while external ones are not; components at the interface between internal and external components, such as API gateways, are semi-trusted. |Component |Description |Trust level |Data handled | |----------|------------|------------|-------------| |... |... |... |... | |... |... |... |... | |... |... |... |... | ### Data flows Identify the data flows between the key components. Include details of data types, transport protocols (and whether they are encrypted), and any authentication or signing systems in place. |Source |Destination |Data type |Protocol |Authentication | |-------|------------|---------|---------|----------------| |... |... |... |... |... | |... |... |... |... |... | |... |... |... |... |... | ### Sensitive assets Identify the assets that must be protected from unauthorized access, eg. data, keys, certificates, and other secrets. |Asset |Sensitivity |Integrity requirements |Availability requirements |Privacy concern | |------|------------|-----------------------|--------------------------|----------------| |... |... |... |... |... | |... |... |... |... |... | |... |... |... |... |... | ### Entry points Identify the external interfaces, APIs, and user interfaces to the system. ### Trust boundaries Identify where trust changes, eg. internet to DMZ, DMZ to internal network. ## Threat assessment Finally, consider the potential threats against the identified components, data flows, and assets. Use the STRIDE framework to rank each threat against each component/flow and rank the resulting risks. |Ref |Component/Flow |Description |Type |Countermeasures |Likelihood |Impact |Rating | |----|---------------|------------|-----|----------------|-----------|-------|-------| |TA1 |... |.. |... |... |... |... |... | |TA2 |... |.. |... |... |... |... |... | |TA3 |... |.. |... |... |... |... |... | |TA4 |... |.. |... |... |... |... |... | |TA5 |... |.. |... |... |... |... |... | (Add links to issue trackers, resolution deadlines, etc. as required.)
For the threat assessment, an alternative structure is to analyze each component’s vulnerability a list of threat types – eg. the STRIDE categories, or the OWASP Top 10 – to determine if a sensitive asset can be compromised by each particular attack vector.
## Component/Flow: _____ |Threat type |Threat description |Asset at risk | Countermeasures |Likelihood |Impact |Rating | |------------|-------------------|--------------|-----------------|-----------|-------|-------| |Spoofing |... |... |... |... |... |... | |Tampering |... |... |... |... |... |... | |Repudiation |... |... |... |... |... |... | |Disclosure |... |... |... |... |... |... | |DoS |... |... |... |... |... |... | |Elevation |... |... |... |... |... |... | (Repeat for each critical component and data flow.)
# Threat modeling workshop 2026-01-16
- **System/application name:** PixelVault Image Storage Service
- **Workshop facilitator:** Sarah Chen (Security Architect)
- **Participants:**
- **Business stakeholder:** Marcus Rodriguez (Product Manager)
- **Technical architect:** Jennifer Park (Principal Engineer)
- **Development lead:** Ahmed Hassan (Engineering Lead)
- **Security analyst:** David Kim (Security Engineer)
- **Privacy officer (eg. data controller):** Lisa Thompson (Data Protection Officer)
- **Other stakeholders:** Tom Wilson (DevOps Lead), Rachel Green (Compliance Manager)
## Business context
PixelVault is a cloud-based image storage and sharing service that allows users
to upload, store, organize, and share photographs and images. The service
provides both free and premium tiers, with revenue generated through
subscription fees and enterprise licensing.
The critical business functions include secure image upload and storage, image
retrieval and download, user authentication and authorization, image
organization (albums, tags), sharing capabilities (private links, public
galleries), and integration with third-party applications via an HTTP API.
Key stakeholders include end users (photographers, content creators, families),
enterprise customers (marketing agencies, media companies), partners (camera
manufacturers, photo editing software vendors), and regulatory bodies (GDPR,
CCPA compliance authorities).
Business impact of security/privacy failures:
- **Financial.** Loss of customer trust leading to churn, potential regulatory
fines under GDPR, litigation costs from data breaches, loss of enterprise
contracts.
- **Reputational.** Brand damage as a trusted platform for personal memories,
negative press coverage, loss of competitive advantage.
- **Regulatory.** Non-compliance with GDPR, CCPA, SOC 2 requirements leading to
sanctions and inability to operate in certain markets.
- **Operational.** Service disruption affecting millions of users, emergency
incident response costs, mandatory breach notifications.
## Technical scope
The threat model covers the core PixelVault platform including the web
application, mobile applications (iOS/Android), API gateway, authentication
service, image processing pipeline, storage layer, and content delivery network.
**System boundaries:** The scope includes all components from user-facing
interfaces through to persistent storage. Out-of-scope are third-party payment
processing (Stripe integration), email delivery service (SendGrid), and
monitoring/analytics platforms (DataDog).
**Technology stack:**
- **Front-end:** React web app, Swift (iOS), Kotlin (Android).
- **API layer:** Node.js with Express, GraphQL.
- **Authentication:** Auth0 with custom user database.
- **Image processing:** Python microservices using Pillow and ImageMagick.
- **Storage:** AWS S3 for objects, PostgreSQL for metadata, Redis for caching.
- **CDN:** CloudFront for content delivery.
- **Infrastructure:** Kubernetes on AWS EKS, Terraform for IaC.
**Deployment environments:** Production (multi-region AWS deployment in us-east-1
and eu-west-1), staging (single region), development (local and shared dev/test
environment).
**Integration points:** Auth0 authentication service, AWS S3 storage, CloudFront
CDN, Stripe payment API, SendGrid email API.
## System decomposition
### Key components
| Component | Description | Trust level | Data handled |
|------------------------------|----------------------------------------------------------------------|-----------------------------|----------------------------------------------------------------------------------------------|
| **Web application** | React SPA hosted on CloudFront, handles user interactions | UNTRUSTED (public internet) | User credentials (transit only), session tokens, image metadata, UI state |
| **Mobile apps** | Native iOS/Android applications | UNTRUSTED (user devices) | User credentials (transit only), session tokens, cached image thumbnails, user preferences |
| **API gateway** | Kong Gateway handling routing, rate limiting, authentication | SEMI-TRUSTED (DMZ) | JWT tokens, API keys, request/response data, rate limiting metadata |
| **Authentication service** | Auth0-based service with custom user database integration | TRUSTED (internal) | User credentials (hashed), session tokens, MFA secrets, authentication logs |
| **Image upload service** | Node.js microservice handling multipart uploads | TRUSTED (internal) | Raw image files, upload metadata, temporary presigned URLs |
| **Image processing service** | Python workers for thumbnail gen, format conversion, meta extraction | TRUSTED (internal) | Original images, generated thumbnails, EXIF metadata, processing queue messages |
| **Metadata service** | Node.js API for image metadata, albums, tags, sharing settings | TRUSTED (internal) | Image metadata, user-created tags, album structures, sharing permissions, user relationships |
| **Storage layer** | AWS S3 buckets for image storage | TRUSTED (internal) | Original images, thumbnails, encrypted backups |
| **Metadata database** | PostgreSQL cluster | TRUSTED (internal) | User profiles, image metadata, sharing permissions, album data, audit logs |
| **CDN** | CloudFront distribution for image delivery | SEMI-TRUSTED (public edge) | Cached images, signed URLs, access logs |
| **Background jobs** | Celery workers for async tasks | TRUSTED (internal) | Image processing tasks, cleanup jobs, notification data |
### Data flows
| Source | Destination | Data type | Protocol | Authentication |
|------------------------------|--------------------------|----------------------------------------|--------------------------|--------------------------------------|
| **Web/mobile clients** | API gateway | Login credentials | HTTPS (TLS 1.3) | HTTP Basic auth |
| **API gateway** | Authentication service | Authentication request | HTTPS (mTLS) | Service certificate |
| **Authentication service** | Client | JWT access token, refresh token | HTTPS (TLS 1.3) | N/A (response) |
| **Client** | API gateway | Image upload request with JWT | HTTPS (TLS 1.3) | JWT Bearer token |
| **API gateway** | Image upload service | Validated upload request | HTTPS (mTLS) | Service certificate + JWT validation |
| **Image upload service** | S3 | Image file data | HTTPS (AWS Signature V4) | IAM role credentials |
| **Image upload service** | Image processing service | Processing job via message queue | TLS over AMQP | Service credentials |
| **Image processing service** | S3 | Read original, write thumbnails | HTTPS (AWS Signature V4) | IAM role credentials |
| **Metadata service** | PostgreSQL | Image metadata, permissions | TLS (certificate auth) | Database credentials (rotated) |
| **Client** | CDN | Image download request with signed URL | HTTPS (TLS 1.3) | Signed URL (time-limited) |
| **CDN** | S3 | Origin fetch | HTTPS (AWS Signature V4) | CloudFront OAI |
| **Background jobs** | Metadata database | Cleanup operations, analytics | TLS (certificate auth) | Database credentials (rotated) |
### Sensitive assets
| Asset | Sensitivity | Integrity requirements | Availability requirements | Privacy concern |
|---------------------------------------------|-------------|------------------------------------------------------------|---------------------------------------------|---------------------------------------------------------------|
| **User images (original files)** | HIGH | CRITICAL (must not be modified or corrupted) | HIGH (users expect reliable access) | YES (GDPR personal data, potentially intimate/private images) |
| **User credentials and password hashes** | CRITICAL | CRITICAL (compromise enables account takeover) | HIGH (required for authentication) | YES (authentication secrets) |
| **JWT signing keys** | CRITICAL | CRITICAL (compromise allows token forgery) | CRITICAL (service cannot function without) | NO (infrastructure secret) |
| **S3 encryption keys (KMS)** | CRITICAL | Critical (compromise exposes all stored images) | CRITICAL (required for data access) | NO (infrastructure secret) |
| **Image metadata (titles, EXIF)** | MEDIUM-HIGH | HIGH (must accurately reflect user intent) | HIGH (core functionality) | YES (may contain location data, personal information) |
| **Sharing permissions and access controls** | HIGH | Critical (incorrect permissions cause unauthorized access) | HIGH (required for sharing features) | YES (defines privacy boundaries) |
| **User profile data** | MEDIUM | HIGH (must be accurate) | MEDIUM (degraded experience if unavailable) | YES (PII - name, email, preferences) |
| **API keys and OAuth tokens** | HIGH | CRITICAL (compromise enables impersonation) | HIGH (required for partner integrations) | NO (authorization credentials) |
| **Database connection strings** | CRITICAL | CRITICAL (compromise exposes all data) | CRITICAL (service depends on database) | NO (infrastructure secret) |
| **Audit logs** | MEDIUM | CRITICAL (must be tamper-proof for compliance) | MEDIUM (needed for investigations) | YES (contains user activity data) |
### Entry points
1. **Web application.** Public-facing React SPA.
2. **Mobile applications.** iOS App Store and Google Play Store downloads.
3. **Public API.** RESTful and GraphQL endpoints for partners.
4. **OAuth 2.0 endpoints.** Third-party application integration.
5. **Admin console.** Internal administration interface.
6. **CDN endpoints.** Image delivery URLs.
7. **Webhook receivers.** Callbacks from Auth0, Stripe, partner services.
### Trust boundaries
1. **Internet → API gateway.**
Transition from untrusted public internet to semi-trusted DMZ.
2. **API gateway → internal services.**
Transition from DMZ to trusted internal network.
3. **Application layer → data layer.**
Transition from application services to data persistence.
4. **Internal network → AWS services.**
Transition from self-managed infrastructure to AWS-managed services.
5. **Internal network → third-party services.**
Boundary with integrated services (Auth0, Stripe).
## Threat assessment
### TA1: API gateway
Attacker spoofs authentication tokens to impersonate legitimate users and access
their images.
Counter-measures: JWT signature verification with RS256, short token expiry
(15min access, 7day refresh), token rotation, Auth0 integration with MFA support,
IP-based anomaly detection.
- Type: SPOOFING
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **HIGH**
### TA2: S3 storage
Attacker gains unauthorized access to S3 bucket and downloads all user images
directly.
Counter-measures: S3 bucket policies with explicit deny for public access, IAM
roles with least privilege, VPC endpoints for S3 access, bucket versioning
enabled, MFA delete enabled, CloudTrail logging of all access.
- Type: ELEVATION OF PRIVILEGE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA3: Image upload service
Attacker uploads malicious files (malware, XSS payloads embedded in images)
that exploit other users.
Counter-measures: File type validation using magic bytes, antivirus scanning
(ClamAV integration), content security policy headers, image re-encoding to
strip malicious payloads, size limits (50MB max), upload rate limiting.
- Type: TAMPERING
- Likelihood: HIGH
- Impact: HIGH
- Overall Risk Rating: **HIGH**
### TA4: CDN/download flow
Attacker intercepts or enumerates signed URLs to access private images they
shouldn't have permission to view.
Counter-measures: Short-lived signed URLs (1 hour expiry), URL signing with
cryptographically secure keys, permission verification before URL generation,
no predictable URL patterns, HTTPS-only delivery, CloudFront geo-restrictions
for sensitive content.
- Type: INFORMATION DISCLOSURE
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA5: API gateway
Attacker performs denial of service attack overwhelming the API with requests.
Counter-measures: Kong rate limiting (100 req/min per user, 1000 req/min per
IP), WAF rules (AWS WAF), auto-scaling based on load, CDN caching to reduce
origin load, request size limits, connection limits, DDoS protection (AWS
Shield).
- Type: DENIAL OF SERVICE
- Likelihood: HIGH
- Impact: MEDIUM
- Overall Risk Rating: **MEDIUM**
### TA6: Metadata database
SQL injection vulnerability allows attacker to extract sensitive user data or
sharing permissions.
Counter-measures: Parameterized queries exclusively (no string concatenation),
ORM usage (Sequelize), input validation, least privilege database user,
database activity monitoring, regular security scanning (SAST/DAST).
- Type: TAMPERING + INFORMATION DISCLOSURE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA7: Image processing service
Attacker uploads specially crafted image that exploits ImageMagick
vulnerability causing remote code execution.
Counter-measures: Sandboxed processing environment (separate K8s namespace),
ImageMagick policy.xml restrictions, input validation, regular patching,
resource limits on workers, network segmentation preventing internet access
from workers.
- Type: ELEVATION OF PRIVILEGE
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **HIGH**
### TA8: User session
Attacker performs session fixation or session hijacking to take over user
accounts.
Counter-measures: Secure session cookies (httpOnly, secure, sameSite), session
regeneration on privilege change, session timeout (24h idle, 7d absolute),
binding sessions to IP/user-agent, logout on multiple failed attempts.
- Type: SPOOFING
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA9: API endpoints
Insecure direct object references allow users to access images belonging to
other users by manipulating IDs.
Counter-measures: Permission verification on every request, UUIDs instead of
sequential IDs, authorization middleware enforced globally, separation of
resource ownership from resource ID, audit logging of access attempts.
- Type: AUTHORIZATION BYPASS
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **HIGH**
### TA10: Data at rest
Unencrypted database backups expose user data if stolen from backup storage.
Counter-measures: AES-256 encryption for all S3 objects using KMS, encrypted
EBS volumes, encrypted RDS snapshots, encrypted database connections, key
rotation every 90 days, separate encryption keys per environment.
- Type: INFORMATION DISCLOSURE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA11: Mobile apps
Reverse engineering of mobile apps exposes API keys or encryption secrets
hardcoded in the application.
Counter-measures: API keys stored in secure enclave (iOS Keychain, Android
KeyStore), certificate pinning, code obfuscation, no hardcoded secrets in
source, secrets retrieved from backend after authentication, tamper detection.
- Type: INFORMATION DISCLOSURE
- Likelihood: HIGH
- Impact: MEDIUM
- Overall Risk Rating: **MEDIUM**
### TA12: Audit logging
Attacker deletes or modifies logs to hide malicious activity from detection.
Counter-measures: Write-only log permissions, centralized logging to immutable
storage (S3 with object lock), log integrity verification, separate IAM role
for log access, CloudTrail enabled and protected, SIEM integration for
real-time monitoring.
- Type: REPUDIATION
- Likelihood: LOW
- Impact: MEDIUM
- Overall Risk Rating: **LOW**
### TA13: Third-party integrations
Compromised OAuth tokens for partner applications grant unauthorized access to
user images.
Counter-measures: OAuth 2.0 with authorization code flow, granular scope
permissions, token expiration and refresh, user consent for each permission,
ability to revoke tokens, audit logging of third-party access, partner
application vetting.
- Type: ELEVATION OF PRIVILEGE
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA14: EXIF metadata
Images retain geolocation and timestamp metadata exposing user privacy (home
addresses, travel patterns).
Counter-measures: Optional metadata stripping feature (enabled by default),
user controls for metadata retention, privacy education in UI, separate
processing pipeline for shared vs. private images, EXIF data not exposed in
API responses without explicit permission.
- Type: INFORMATION DISCLOSURE
- Likelihood: HIGH
- Impact: MEDIUM
- Overall Risk Rating: **MEDIUM**
### TA15: Shared links
Publicly shared image links are indexed by search engines exposing supposedly
private images.
Counter-measures: Robots.txt directives, noindex meta tags on shared link
pages, separate domain for user-generated content, signed URLs with
authentication even for "public" shares, user warnings about public sharing
implications.
- Type: INFORMATION DISCLOSURE
- Likelihood: MEDIUM
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA16: Data retention
User data retained indefinitely after account deletion violates GDPR right to
erasure.
Counter-measures: Automated deletion workflow triggered 30 days after deletion
request, hard delete from all systems including backups, deletion verification
audit, user confirmation of deletion, retention policy documentation,
compliance monitoring.
- Type: NON-COMPLIANCE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA17: Cross-tenant data leakage
Shared infrastructure allows one user's processing job to access another
user's images in memory/temp storage.
Counter-measures: Namespace isolation in Kubernetes, separate temp directories
per job with unique IDs, cleanup after processing, no shared memory between
workers, container security contexts, resource quotas per tenant.
- Type: INFORMATION DISCLOSURE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA18: Admin console
Compromised admin credentials provide unrestricted access to all user data and
system configuration.
Counter-measures: Mandatory MFA for admin access, admin actions require
approval workflow for sensitive operations, separate VPN access required, IP
allowlisting, privileged access management (PAM) system, session recording,
just-in-time access provisioning.
- Type: ELEVATION OF PRIVILEGE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **MEDIUM**
### TA19: Man-in-the-middle
Network traffic interception between client and server exposes images and
authentication tokens.
Counter-measures: TLS 1.3 exclusively, HSTS headers with preloading,
certificate pinning in mobile apps, no mixed content, monitoring for
certificate transparency, regular TLS configuration audits.
- Type: INFORMATION DISCLOSURE
- Likelihood: LOW
- Impact: HIGH
- Overall Risk Rating: **LOW**
### TA20: Credential stuffing
Attackers use leaked credentials from other breaches to compromise PixelVault
accounts.
Counter-measures: Integration with HaveIBeenPwned API, password complexity
requirements, mandatory password reset for compromised credentials, rate
limiting on login attempts, account lockout after 5 failed attempts, CAPTCHA
after 3 failures, login anomaly detection.
- Type: SPOOFING
- Likelihood: HIGH
- Impact: HIGH
- Overall Risk Rating: **HIGH**Identifying threats
The most important part of the threat modeling process is the identification of potential threats. This is done by systematically analyzing each component and data flow within a system against various categories of known threats and vulnerabilities.
It is RECOMMENDED to use a structured framework for this part of the process.
STRIDE is a RECOMMENDED minimal framework for threat identification. For complex applications, this framework SHOULD be augmented with other frameworks as well as analysis of public vulnerability databases and other sources of information about security and privacy threats.
Vulnerability databases
Another approach is to assess the system against common vulnerabilities. Public vulnerability databases are a useful resource for this purpose. Public vulnerability databases include:
- The Common Vulnerabilities and Exposures (CVE) database
- The Common Weakness Enumeration (CWE) list
- Common Attack Pattern Enumerations and Classifications (CAPEC)
- The National Vulnerability Database (NVD)
- The OWASP Cheat Sheets, including the Attack Surface Cheat Sheet or the OWASP Top 10 lists
Systems-level threats
STRIDE and the OWASP categories frame threats at the application layer. Where a system includes code written in a memory-unsafe language – C, C++, or any component compiled to native code, including runtime extensions and third-party binary dependencies – the threat model MUST also reach the layers beneath the application: the language’s semantics, the compiler, the runtime library, the operating system, and the hardware.
The reason is that an attacker is not bound by the abstraction the developers reason in. The C standard classifies a buffer overflow only as undefined behavior, and says nothing further about it. Whether that undefined behavior produces a crash, an information leak, or remote code execution is decided by the compiler’s code generation, the memory allocator, the C library, and the hardware. A threat model that stops at the specification level therefore cannot rate the threat. It can establish that the defect exists, but not how exploitable it is.
Two rules follow.
- Rate exploitability against the implementation, not the specification. Where the workshop has the expertise to reason about the compiled artifact and its runtime, it SHOULD do so, and record that reasoning against the threat. Where it does not, the threat MUST be rated as exploitable rather than as a mere correctness defect. Undefined behavior of unknown consequence is not evidence of low likelihood.
- Record exploit mitigations as countermeasures, not as remediation. Address space layout randomization (ASLR), data execution prevention (DEP/NX), stack canaries, control-flow integrity (CFI), hardened allocators, and position-independent executables raise the cost of exploitation. None of them removes the underlying defect, and each has a known bypass – ASLR falls to an address leak, DEP to return-oriented programming – so the residual risk after such a mitigation is never zero. In the risk register (see Risk register) they belong in the countermeasures column, with the memory-safety defect itself left open until it is fixed or the code is replaced.
The only mitigation that removes the threat class is elimination: writing new components in a memory-safe language, and isolating native code that cannot be replaced behind a process or sandbox boundary, so that a successful exploit gains the attacker the least possible authority.
Where a system contains no native code at all, the workshop SHOULD record that finding explicitly in its technical scope, rather than passing over the category in silence. The finding is rarely absolute: language runtimes, interpreters, image and document parsers, and compression libraries are native code that the application inherits through its dependencies, and they carry the supply-chain concerns covered in TS-52.
Prompt questions
It is useful to prepare a list of questions to guide threat modeling workshops. These prompts help systematically interrogate system design against common vulnerabilities.
STRIDE framework
The STRIDE framework provides structured categories for threat assessment. Here are some example questions to consider for each STRIDE category.
Spoofing:
- Who has their identity verified before processing data?
- How are authentication credentials transmitted and validated?
- Can external entities be verified as who they claim to be?
Tampering:
- How are inputs validated and sanitized?
- Are there integrity checks on stored and transmitted data?
- Is data-in-transit protected (eg. HTTPS, signatures)?
- Can unauthorized users modify stored data and configurations?
Repudiation:
- Are actions logged with sufficient context to trace responsible parties?
- Can changes be attributed to specific users or systems?
- Are logs protected from tampering?
Information disclosure:
- Could sensitive data be unintentionally exposed via error messages, logs, or debug information?
- Is sensitive data encrypted at rest? Is it access-controlled?
- Can sensitive data be intercepted during transmission?
- Do external parties receive only necessary data?
Denial of service (DoS):
- Can the system be overwhelmed through resource exhaustion or flooding?
- Are rate limits and throttling in place?
- Can storage be exhausted or locked?
- Are DoS protections implemented?
Elevation of privilege:
- Are role-based access controls properly implemented?
- Could users escalate privileges through logic or configuration flaws?
- Are permissions default-deny and properly enforced?
- Can external entities access restricted functions?
OWASP vulnerability categories
Alternatively, you could choose to assess the system against common vulnerability categories.
Authentication failures:
- Does the system require authentication for all access?
- Is multi-factor authentication implemented where practical?
- Are weak passwords disallowed (to prevent brute-force attacks)?
- Are passwords checks against common password lists (rainbow tables)?
Broken access controls:
- Is all access "deny by default" with explicit allow rules?
- Can the authorization system (eg. role-based) be bypassed or manipulated to allow privilege escalation?
- Are session identifiers secure (random, transferred over HTTPS, invalidated on logout)?
- Are authorization checks enforced consistently across all entry points?
- Are APIs rate-limited?
- Are HTTP redirects disabled or restricted?
- Are admins alerts of unauthorized access control attempts?
- Is there anything that can accessed without authentication or authorization?
- Are there any unexpected file accessible from web server root directories?
- Does the application process any unverified data?
Cryptographic failures:
- Is all network traffic encrypted (HTTPS, TLS)? This includes traffic between load balancers and application servers, between application servers and databases, and so on.
- Are there any open ports which are not currently encrypted (even if not in use)?
- Are any self-signed certificates used?
- Are default certificates and keys avoided?
- Are certificates and their trust chain properly validated?
- Are current, strong algorithms used (SHA-256+, bcrypt, TLS 1.2+)? Are any deprecated hash functions used (eg. MD5 or SHA-1)?
- Are strong cryptographic keys used?
- Are any randomness functions used suitable for cryptographic purposes?
- Are cryptographic keys managed securely (not hardcoded, not in version control)?
- Are key invalidation and rotation processes in place?
- Are appropriate HTTP security headers set (CSP, HSTS, X-Content-Type-Options)?
- Does any sensitive data leak into logs?
- Are any logs accessible to users?
Injection:
- Are all client-supplied URLs validated (schema, port, destination)?
- Are all inputs (parameters, headers, cookies, JSON/XML) validated? Are allow-lists (not deny-lists) used for validation purposes?
- Does a parameterized interface ensure that only valid commands are executed, and that only expected parameters are processed?
- Are user-provided values properly escaped before rendering in HTML or executing in interpreters?
- Is any other user-provided data stored, processed, or outputted verbatim?
- Is mass disclosure prevented in SQL queries, eg. with
LIMIT?
Deployment pipelines:
- Are all code and configuration changes reviewed and approved before deployment?
- Are applications securely deployed to their host systems?
- Is there a patch management process?
- Are deployments and rollbacks highly automated?
- Are applications deployed to minimal platforms, with only necessary features enabled?
- Are development, test, and production environments configured identically (except credentials)?
- Are cloud storage permissions regularly audited?
Dependency management and software supply chain vulnerabilities:
- Are library and dependency versions inventoried and tracked?
- Is there continuous monitoring and automated alerting for known vulnerabilities?
- Is there continuous monitoring that identifies outdated and unmaintained dependencies?
- Are components obtained only from official, secure sources?
- Are only signed packages used, to reduce the chances of including maliciously modified components?
- Are unmaintained or unsupported dependencies identified and replaced at regular intervals?
Logging and monitoring:
- Are authentication, authorization, and input validation failures logged with attack context?
- But are error messages also generic enough to not reveal unnecessary implementation details?
- Are logs monitored for suspicious patterns?
- Are logs held long enough for forensic analysis?
- Are logs protected from modification and deletion?
- Is there an incident response plan (documented and tested, with escalation procedures)?
- What happens when an attack is detected? Are there automated responses (eg. blocking IPs, rate-limiting, alerting admins)?
- Can attacks be detected, alerted, and mitigated in real-time?
Other secure-by-design questions
- Is security integrated into every phase of the development lifecycle?
- Are plausibility checks implemented across front-end and back-end?
- Are resource consumption limits enforced per user and per service?
- Are tenants properly isolated from one another?
- Are remote resource requests isolated to separate networks?
- Is "deny by default" enforced for network access via firewall policies, or are network access controls configured to block all but essential traffic?
- Are all blocked network requests logged for suspicious activity?
- Has ownership and lifecycle management for firewall rules been established?
Memory safety and exploit mitigations
Where the system includes native code, add the following prompts to those above. See Systems-level threats for how to rate what they turn up.
Memory safety:
- Which components are written in a memory-unsafe language, and which of those parse input that originates outside a trust boundary?
- Are the classic defect classes tested for – out-of-bounds reads and writes, use-after-free, double free, integer overflow feeding an allocation size, type confusion, and disclosure of uninitialized memory?
- Are inputs fuzzed? Are sanitizers (address, memory, undefined behavior, thread) enabled in a build that the test suite is run against?
- Are there time-of-check-to-time-of-use races between validating a resource and acting on it?
Exploit mitigations:
- Are ASLR, DEP/NX, stack canaries, RELRO, and position-independent executables enabled on every deployed binary? Is that verified in the build pipeline, rather than assumed from the toolchain’s defaults?
- Is control-flow integrity or a hardened allocator available on the target platform, and if so, why is it not enabled?
- What does each mitigation actually cost an attacker here, and what single additional primitive – an address leak, an arbitrary write – would defeat it?
- Is native code isolated behind a process, container, or sandbox boundary that limits what a successful exploit can reach?
Risk ratings
After identifying potential threats, the next step is to rate them based on their likelihood of occurrence and scale of impact.
Each identified threat SHOULD be rated based on its likelihood of occurrence and scale of impact. Combining the likelihood and impact scores gives an overall severity level, typically rated from high to low.
The following diagram shows a common risk rating scheme. You may design your own scoring system. The important thing is to be consistent in how you rank potential threats.