Threat Modeling a Crypto Trading Desk: STRIDE Applied to a Real Multi-Venue Architecture

When I joined Upside as Head of Engineering, one of the first things I did was run a full threat modeling exercise on the existing infrastructure. Not a checklist audit. Not a penetration test. A structured threat model: enumerate the assets, enumerate the surfaces, apply the threat categories systematically, and produce a risk matrix that the board could review.

The output of that exercise shaped the entire security roadmap for the next 18 months. It identified three high-likelihood, high-impact threats that had no mitigations. It also clarified which threats the team was over-invested in defending against (external network attacks) relative to the actual risk profile (insider threats and supply-chain compromises).

This is the complete STRIDE threat model I use for a typical crypto trading desk. Run this exercise with your engineering and security teams before you go live, before you add a new exchange integration, and after any major architectural change.

STRIDE: The Framework

STRIDE is a threat classification developed by Microsoft. It gives you six categories of threats to apply systematically to every component and data flow in your system:

• S - Spoofing: Claiming to be something you are not (a user, a service, a market data source)
• T - Tampering: Unauthorized modification of data or code
• R - Repudiation: Denying that an action occurred
• I - Information Disclosure: Unauthorized access to information
• D - Denial of Service: Degrading or preventing legitimate use
• E - Elevation of Privilege: Gaining capabilities beyond what was authorized

For each threat: assess the likelihood (1-5), the impact (1-5), and identify the mitigation.

The architecture we are modeling: a typical crypto trading desk with multiple exchange connections, an order management system (OMS), a market data feed aggregator, a signing service for custody operations, and an admin/ops tooling layer.

Surface 1: Exchange Connectivity

The exchange connectivity layer connects your trading engine to exchange WebSocket and REST APIs. This is the interface between your infrastructure and external systems you do not control.

S1.1 - Spoofing: Man-in-the-Middle on Exchange API

Threat: An attacker intercepts the TLS connection between your API client and the exchange, presenting a forged certificate. The attacker observes order flow and potentially injects orders.

Likelihood: 2/5 - TLS certificate pinning is standard; MITM requires a CA compromise or a specific attack against your client TLS configuration. But public Wi-Fi, compromised egress proxies, and misconfigured corporate firewalls that perform SSL inspection have all produced real incidents.

Impact: 5/5 - An attacker who can observe your order flow in real time can front-run trades. An attacker who can inject orders can generate unauthorized positions.

Mitigations:

• Pin exchange TLS certificates in your API client. When the certificate changes (exchanges rotate certificates), your client should fail closed - refuse to connect - rather than accept the new certificate without review.
• Use exchange-provided HMAC signing on all API requests. Even if an attacker intercepts your orders, they cannot modify them without invalidating the HMAC.
• Monitor for certificate changes and alert before deployment of a pinned update.
• Never route exchange API traffic through corporate proxies that perform SSL inspection.

S1.2 - Tampering: Modification of Market Data Feed

Threat: An attacker injects false price data into your market data feed, causing your strategy to make trading decisions based on prices that do not reflect the actual market.

Likelihood: 2/5 - Market data feed injection requires compromising a feed provider or intercepting a feed that is delivered over an unauthenticated channel.

Impact: 4/5 - A strategy that trades on false prices can accumulate positions in the wrong direction, leading to losses when real market prices diverge.

Mitigations:

• Subscribe to the same symbol from multiple independent feeds and alert when prices diverge beyond a threshold.
• Apply a sanity check on incoming prices: if the price changes by more than N% in a single tick, reject the update and use the last known good price.
• For feeds delivered over authenticated channels (exchange WebSocket with API key authentication), the HMAC on messages provides tamper detection.

S1.3 - Repudiation: Dispute over Executed Orders

Threat: The exchange claims an order was executed differently than your records show, and you cannot prove the exchange is wrong.

Likelihood: 2/5 - Repudiation disputes with exchanges are rare but not unheard of. More common: internal disputes about which orders were placed and by which strategy.

Impact: 3/5 - Without an authoritative record, reconciliation is expensive and may be unresolvable.

Mitigations:

• Log every outbound API request with the full request body, the response, and the timestamp, before any processing of the response.
• Log every exchange acknowledgment with the exchange-assigned order ID and the timestamp.
• Reconcile your internal order state against the exchange’s order history API at the end of each trading session.

Surface 2: Order Management System

The OMS receives trading signals from strategies, validates them, and routes orders to exchanges.

T2.1 - Tampering: Malicious Modification of Order Parameters

Threat: An attacker with access to the OMS process (or the message queue between the strategy and OMS) modifies order parameters - increasing the quantity, changing the side, or altering the price - before the order is sent to the exchange.

Likelihood: 3/5 - If the OMS process runs on the same host as other services, a compromised co-tenant service can inject into shared memory or the message queue.

Impact: 5/5 - Tampered orders can produce large unauthorized positions. A quantity multiplied by 10x on a large order can exceed the account’s margin.

Mitigations:

• Sign order objects at the point of strategy generation using a key that is only accessible to the strategy process. The OMS verifies the signature before forwarding.
• Pre-trade risk checks in the OMS: maximum order size, maximum position size, price deviation from mid-market. The OMS rejects orders that exceed these limits regardless of the signature.
• Isolate strategy and OMS processes - no shared memory, no co-tenancy on the same Kubernetes pod.

E2.2 - Elevation of Privilege: Strategy Accesses Execution Directly

Threat: A compromised strategy process bypasses the OMS and sends orders directly to the exchange API, avoiding pre-trade risk checks.

Likelihood: 2/5 - Requires a compromised strategy process with knowledge of the exchange API credentials.

Impact: 4/5 - Orders placed without pre-trade risk checks can create positions that exceed risk limits or trigger margin calls.

Mitigations:

• Strategy processes do not hold exchange API credentials. Only the OMS holds exchange credentials.
• Firewall rules prevent strategy processes from making outbound connections to exchange API endpoints. All exchange traffic must route through the OMS.
• Monitor for unexpected outbound connections from strategy process pods.

Surface 3: Market Data Feed

The market data feed aggregates price and depth data from multiple exchanges and distributes it to all strategies.

D3.1 - Denial of Service: Feed Flooding

Threat: An attacker floods the market data feed aggregator with high-volume spurious data, overwhelming the system’s processing capacity and causing legitimate price updates to be delayed or dropped.

Likelihood: 2/5 - Requires access to the feed ingestion path, which is typically protected.

Impact: 4/5 - Delayed market data causes strategies to trade on stale prices. In a fast-moving market, this can produce significant losses.

Mitigations:

• Rate limit ingestion per feed source. If any single source exceeds the expected message rate by 10x, throttle that source rather than the entire feed.
• Separate feed ingestion from strategy distribution - feed flooding degrades the ingestion tier without directly affecting the distribution tier.
• Alert when feed latency (time from exchange event to strategy receipt) exceeds threshold.

I3.2 - Information Disclosure: Leakage of Order Flow

Threat: The market data feed, which aggregates internal order book state, leaks information about your own pending orders to an external party.

Likelihood: 2/5 - Requires unauthorized access to the internal feed distribution.

Impact: 4/5 - Knowledge of pending orders enables front-running.

Mitigations:

• Internal order book data (your own pending orders) must not be included in the market data feed. The feed should contain only external exchange data.
• Access to the raw order flow (all orders across all strategies) is restricted to named services with documented justification.

Surface 4: Signing Service

The signing service holds private keys and performs cryptographic signing for custody operations, order authentication, and message integrity.

I4.1 - Information Disclosure: Leakage of Private Keys

Threat: An attacker extracts the private key material from the signing service, enabling them to sign arbitrary transactions.

Likelihood: 1/5 - If the signing service uses a TEE or HSM, key extraction is essentially impossible. With a software-only signing service, the risk increases to 3/5.

Impact: 5/5 - Extracted keys enable unlimited unauthorized signing. This is the highest-impact threat in the model.

Mitigations:

• Run the signing service in a TEE (AWS Nitro Enclave) or on an HSM. The private key never exists in plaintext outside the hardware boundary.
• Log every signing request with the requester identity, request content, and timestamp.
• Alert on signing request rate anomalies - if the signing service suddenly processes 100x its normal request volume, this may indicate an automated attack.

E4.2 - Elevation of Privilege: Unauthorized Signing

Threat: A service or user who should not be able to initiate signing operations gains access to the signing service’s interface.

Likelihood: 2/5 - Requires a misconfigured network policy or a compromised service that legitimately has signing access.

Impact: 5/5 - Unauthorized signing is equivalent to key compromise in terms of what the attacker can do.

Mitigations:

• The signing service only accepts connections from a specific list of service identities (enforced via mTLS and SPIFFE IDs).
• Every signing request must carry a policy token (a short-lived JWT issued by the policy engine, valid only for a specific transaction). The signing service verifies the policy token before signing.
• Human operators cannot directly call the signing service. All signing must go through the automated pipeline.

Surface 5: Custody Infrastructure

The custody infrastructure manages the long-term storage and disbursement of assets.

D5.1 - Denial of Service: Preventing Legitimate Withdrawals

Threat: An attacker disrupts the custody withdrawal approval pipeline, preventing authorized withdrawals from completing. This could be a technical attack (DDoS on the approval service) or a policy abuse (submitting large numbers of invalid approval requests to exhaust reviewer capacity).

Likelihood: 2/5 - Technical DDoS on internal services is difficult; approval queue exhaustion is more credible.

Impact: 4/5 - Blocked withdrawals prevent clients from accessing their assets. For trading firms with active positions, this can cause cascading losses.

Mitigations:

• Separate the approval pipeline from the execution pipeline. Even if the approval service is unavailable, in-progress withdrawal executions should complete.
• Implement a maximum queue depth for pending withdrawal requests. When the queue is full, new requests are rejected with an explicit error rather than queued indefinitely.
• Time-bound approvals: a withdrawal request that has been pending for more than N hours without reviewer action automatically escalates.

Surface 6: Admin and Ops Tooling

The admin layer includes dashboards, runbook tooling, alert management, and the CLI tools used by engineers to interact with the system.

E6.1 - Elevation of Privilege: Ops Engineer Escalates to Production Signing Capability

Threat: An operations engineer with access to the admin tooling discovers a path from their access level to the production signing capability. This may be through a misconfigured RBAC policy, a service account with over-broad permissions, or a debugging tool that grants elevated temporary access.

Likelihood: 3/5 - Admin tooling is typically the least-hardened surface in a trading system because it is built for operational convenience.

Impact: 5/5 - An ops engineer with signing capability has the ability to authorize and execute arbitrary transactions.

Mitigations:

• Strictly separate the permissions model for ops tooling and for the production pipeline. Ops tooling access grants read access to logs, metrics, and configuration; it explicitly does not grant access to any service in the production signing or execution path.
• Audit ops tooling access quarterly. Any service account used by ops tooling that has access to production financial infrastructure should be flagged for review.
• Break-glass access to production is a separate access tier with mandatory audit logging and next-day review.

The Threat Model Table

This is the format I present to boards and security committees:

Risk score = Likelihood × Impact. Anything ≥ 10 should have an active mitigation and a quarterly review.

The two 15-scored threats - order parameter tampering and ops privilege escalation - were the first two remediation items from my threat model at Upside. Both were subsequently mitigated through architectural changes.

How This Breaks in Production

The threat model is not a one-time artifact. The failure mode I see most often is a threat model that was created at system design and never updated. The system has changed - new exchange integrations, new tooling, new team members - but the threat model reflects the architecture from two years ago.

Run the threat model as a living document. Every time you add a significant new component or integration, add it to the threat model before you deploy it. Every time a new threat is publicly disclosed in your industry (a new DPRK campaign, a new smart contract attack pattern, a new exchange API vulnerability), review whether your existing mitigations cover it.

The second failure mode is treating the threat model as a compliance document rather than an operational tool. The value of STRIDE is not the finished table - it is the structured conversation that produces the table. When engineers walk through each surface and ask “how could this be spoofed, tampered with, repudiated?” they identify threats that they have been implicitly aware of but never formally documented. The documentation forces clarity about which threats have no mitigation.

A threat model with 10 items, all “Mitigated,” is less valuable than a threat model with 15 items where 3 are “Partial” or “Open” - because the latter honestly reflects the actual risk posture. The document that earns trust at a trading firm is the one that does not pretend the risks do not exist.