Threat Model: Cards

Status: Draft | Owner: Security Team | Last Updated: 2026-04-03 Methodology: STRIDE | Scope: Card payment flow including 3DS, tokenisation, and disputes

Overview

STRIDE threat analysis for Simpaisa's Card payment product. Covers Visa, Mastercard, and local card schemes across PK, BD, NP, and IQ. Card payments carry heightened risk due to PCI DSS scope, chargeback liability, and the irreversibility of card-not-present (CNP) fraud.

---

Data Flow Diagram

┌───────────┐   HTTPS    ┌──────────┐   gRPC    ┌───────────┐
│ Cardholder│───────────▶│ KrakenD  │──────────▶│   Card    │
│ (Browser) │  (TLS 1.3) │ Gateway  │  (mTLS)   │  Service  │
└───────────┘            └──────────┘           └─────┬─────┘
      │                       │                       │
      │                       │                  ┌────┴────┐
      │ 3DS redirect          │                  │         │
      ▼                       ▼                  ▼         ▼
┌───────────┐           ┌──────────┐      ┌─────────┐ ┌────────┐
│  3DS ACS  │           │  Auth    │      │Tokenise │ │Acquirer│
│ (Issuer)  │           │ Service  │      │ Vault   │ │Adapter │
└───────────┘           └──────────┘      │ (CDE)   │ └───┬────┘
                                          └─────────┘     │
                                               ▲          │
                        ┌──────────┐           │          ▼
                        │ SurrealDB│◀──────────┤    ┌──────────┐
                        │ (non-CDE)│           │    │ Card     │
                        └──────────┘           │    │ Network  │
                                               │    │(Visa/MC) │
                        ┌──────────┐           │    └──────────┘
                        │ CDE Vault│───────────┘
                        │(SurrealDB│  token↔PAN
                        │ isolated)│  lookup
                        └──────────┘

---

PCI DSS Scope Boundary

┌─────────────────────────────────────────────────┐
│              PCI DSS CDE Boundary                │
│                                                   │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐   │
│  │ CDE Vault│    │ Tokenise │    │ Acquirer │    │
│  │ (PAN     │    │ Service  │    │ Adapter  │    │
│  │  store)  │    │          │    │ (transit)│    │
│  └──────────┘    └──────────┘    └──────────┘   │
│                                                   │
│  Encrypted at rest (AES-256-GCM)                 │
│  Separate key management (HSM-backed)             │
│  Network-segmented (dedicated VLAN)               │
│  No direct internet access                        │
└─────────────────────────────────────────────────┘
          │ token only
          ▼
┌─────────────────────────────────────────────────┐
│           Out-of-scope (non-CDE)                 │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ KrakenD  │  │  Card    │  │ SurrealDB│       │
│  │ Gateway  │  │ Service  │  │ (main)   │       │
│  └──────────┘  └──────────┘  └──────────┘       │
│                                                   │
│  Only tokenised references — no raw PAN           │
└─────────────────────────────────────────────────┘

---

Attack Surfaces

Surface	Entry Point	Trust Level
Card data handling	Tokenise service in CDE	Highly restricted
3DS authentication	Issuer ACS redirect	External
Tokenisation vault	CDE vault service	Highly restricted
Acquirer integration	Acquirer adapter (CDE)	External
Dispute management	Merchant portal	Authenticated

---

STRIDE Analysis

S — Spoofing

ID	Threat	Likelihood	Impact
S-CD-1	Auth replay (reuse of previous auth code)	Medium	High
S-CD-2	3DS bypass (force non-3DS path)	Medium	Critical

S-CD-1: Auth replay - Attack: Attacker captures a valid authorisation response and replays it to create fraudulent captures without a genuine card interaction. - Mitigation: Auth codes are single-use; capture attempts validated against authorisation record. Idempotency key prevents duplicate processing. Auth record includes timestamp — captures rejected if auth expired. Temporal workflow enforces auth→capture sequence.

S-CD-2: 3DS bypass - Attack: Attacker manipulates the payment flow to skip 3D Secure authentication (e.g. by intercepting the redirect and returning a spoofed success). - Mitigation: 3DS result validated server-side against Directory Server response. eci and cavv values verified with card scheme. Transactions without valid 3DS carry full liability with merchant — flagged in risk scoring. Option to reject non-3DS transactions at merchant level.

T — Tampering

ID	Threat	Likelihood	Impact
T-CD-1	PAN theft via memory scraping	Low	Critical
T-CD-2	Log leakage of card data	Medium	Critical
T-CD-3	Token abuse (use of revoked token)	Medium	High

T-CD-1: PAN theft (memory scraping) - Attack: Malware on CDE servers scrapes process memory to extract PANs during tokenisation or acquirer communication. - Mitigation: CDE runs on hardened, minimal-surface containers. Runtime security monitoring (Falco). PAN held in memory only during tokenisation operation (< 100ms). No swap enabled on CDE nodes. Regular penetration testing of CDE. → STD-SECURITY-042

T-CD-2: Log leakage - Attack: Full PAN or CVV accidentally logged by application code, debug output, or error handler. - Mitigation: PAN regex scrubber on all log output (pre-emission filter). CVV never assigned to any variable outside tokenisation function. Automated PAN-in-log scanner runs daily. CDE services have separate log pipeline with enhanced controls.

T-CD-3: Token abuse - Attack: Attacker uses a previously revoked or expired card token to initiate a new payment. - Mitigation: Token status checked in real-time at CDE vault before every transaction. Revoked/expired tokens return immediate rejection. Token status transitions are immutable (no re-activation).

R — Repudiation

ID	Threat	Likelihood	Impact
R-CD-1	Chargeback fraud (friendly fraud)	High	High
R-CD-2	Disputed capture without merchant awareness	Low	Medium

R-CD-1: Chargeback fraud (friendly fraud) - Attack: Cardholder makes a legitimate purchase, receives goods/services, then disputes the charge with their issuer claiming the transaction was unauthorised. - Mitigation: 3DS authentication shifts liability to issuer for authenticated transactions. Comprehensive evidence collection: 3DS result, delivery confirmation, IP address, device fingerprint. Automated dispute response with evidence package. Chargeback rate monitoring per merchant — suspension at >1% rate. → DisputeCase entity with evidence tracking.

R-CD-2: Unacknowledged capture - Mitigation: Capture events generate webhook notification to merchant. Capture requires explicit merchant action (manual mode) or is tied to order fulfilment (auto mode). Full audit trail in Temporal workflow.

I — Information Disclosure

ID	Threat	Likelihood	Impact
I-CD-1	PAN exposure via API response	Low	Critical
I-CD-2	Card metadata inference from tokens	Low	Medium

I-CD-1: PAN in API response - Attack: API bug returns full PAN instead of masked version in payment response. - Mitigation: API response serialisation explicitly uses maskedPan field only. Full PAN field does not exist outside CDE service. Integration tests verify no PAN patterns in API responses. KrakenD response transformation strips any field matching PAN regex.

I-CD-2: Token inference - Attack: Token format allows inference of original PAN characteristics (e.g. sequential tokens map to sequential PANs). - Mitigation: Tokens are cryptographically random (UUID v4), bearing no mathematical relationship to the original PAN. Token→PAN mapping stored only in CDE vault with HSM-managed encryption keys.

D — Denial of Service

ID	Threat	Likelihood	Impact
D-CD-1	Auth flood exhausting acquirer quota	Medium	High
D-CD-2	CDE vault overload	Low	Critical

D-CD-1: Auth flood - Attack: Attacker submits thousands of card authorisation requests to exhaust acquirer API quota, blocking legitimate transactions. - Mitigation: Per-merchant auth rate limiting. Card BIN-level velocity checks (max 3 attempts per card per hour). CAPTCHA/challenge on repeated failures. Circuit breaker on acquirer adapter.

D-CD-2: CDE vault overload - Mitigation: CDE vault scaled independently with dedicated resources. Rate limiting at CDE ingress. Tokenisation requests queued with backpressure. CDE monitoring with separate alerting pipeline.

E — Elevation of Privilege

ID	Threat	Likelihood	Impact
E-CD-1	Non-CDE service accessing PAN data	Low	Critical
E-CD-2	Merchant accessing another merchant's tokens	Low	Critical

E-CD-1: CDE boundary breach - Attack: A non-CDE service obtains network access to the CDE vault, bypassing tokenisation to access raw PANs. - Mitigation: Network segmentation: CDE on dedicated VLAN with firewall rules allowing only whitelisted services. mTLS with client certificate pinning. CDE access requires separate authentication (not shared with main platform). Quarterly network segmentation testing. → PCI DSS Req 11.3.4

E-CD-2: Cross-merchant token access - Mitigation: Tokens scoped to merchantId. Token lookup requires both token ID and merchant context. CDE vault enforces tenant isolation at query level.

---

Risk Matrix

Threat	Likelihood	Impact	Risk Level	Mitigation Status
S-CD-1	Medium	High	High	Implemented
S-CD-2	Medium	Critical	High	Implemented
T-CD-1	Low	Critical	Medium	Implemented
T-CD-2	Medium	Critical	High	Implemented
T-CD-3	Medium	High	High	Implemented
R-CD-1	High	High	High	In progress
R-CD-2	Low	Medium	Low	Implemented
I-CD-1	Low	Critical	Medium	Implemented
I-CD-2	Low	Medium	Low	Implemented
D-CD-1	Medium	High	High	Implemented
D-CD-2	Low	Critical	Medium	Implemented
E-CD-1	Low	Critical	Medium	Implemented
E-CD-2	Low	Critical	Medium	Implemented

---

ADR Cross-References

Mitigation Area	Related ADR / Standard
PCI DSS compliance	SECURITY-ARCHITECTURE
Tokenisation	ADR-038 Card Tokenisation
CDE architecture	ADR-039 CDE Network Segmentation
Penetration testing	STD-SECURITY-042
PII handling	PII-HANDLING-STANDARD
Logging	LOGGING-STANDARD
Rate limiting	RATE-LIMITING-POLICY