StokumNET Threat Model: A Practical STRIDE Analysis

In an ideal world, threat modeling happens before the first line of code. You identify assets, map trust boundaries, enumerate threats, and design countermeasures—all before git init. Textbooks and frameworks prescribe this sequence for good reason: it's cheaper to fix design flaws on a whiteboard than in production.

In reality, many of us build iteratively. Security thinking happens continuously—during architecture decisions, code reviews, and late-night debugging sessions—but the formal documentation often comes later. That's the honest story of this post.

The security principles that shaped StokumNET were present from day one. I chose Go for memory safety. I designed tenant isolation into the data model. I built the infrastructure with zero-trust assumptions. But I never sat down and produced a formal threat model document until now.

This post captures that security thinking in a structured format: a STRIDE-based threat model that documents what we're defending, who might attack it, and how the architecture responds. Whether you're evaluating StokumNET's security posture, learning threat modeling techniques, or facing the same challenge of formalizing security for an existing system—I hope this analysis is useful.

For those unfamiliar with my previous posts: StokumNET Architecture covers the infrastructure design, and the Security Roadmap details planned enhancements. This threat model ties them together with a systematic risk analysis.

The STRIDE Framework

For this analysis, I'm using STRIDE—a threat modeling methodology developed at Microsoft that categorizes threats into six types. It's systematic without being overwhelming, and maps well to the controls we typically implement:

System Context

Before analyzing threats, let's establish what we're protecting.

Assets

Trust Boundaries

StokumNET has several distinct trust boundaries where data crosses between security zones:

Data Flow Summary

1. User Request → Internet → Edge Server (TLS terminated) → VPN Tunnel → Ingress Controller → Frontend or Backend
2. Authentication → Backend validates JWT → Extracts tenant_id → Scopes all queries
3. Data Access → Backend → Database (RLS enforces tenant isolation)
4. Secrets → Backend → Secrets Manager (runtime secret retrieval)

STRIDE Analysis by Component

Edge Server (Cloud VPS)

Residual Risk: DDoS protection at the edge is limited to basic rate limiting. A sustained volumetric attack could impact availability. Mitigation: A CDN with DDoS protection is a future consideration for production scale.

Encrypted VPN Tunnel

Residual Risk: If the edge VPS is compromised, attacker gains tunnel access to private cloud. Mitigation: Defense in depth—application-layer authentication still required.

Ingress Controller

Frontend (React)

Backend (Go)

Critical Control - Tenant Isolation:

// Every database query MUST include tenant filter
// Tenant ID comes from JWT, never from request parameters

func GetProducts(ctx *Context) {
    tenantID := ctx.GetInt("tenant_id")  // Extracted from validated JWT
    
    var products []Product
    // ✅ CORRECT: Tenant filter always applied
    db.Where("tenant_id = ?", tenantID).Find(&products)
    
    // ❌ WRONG: Never trust request parameters for tenant
    // requestedTenant := ctx.Query("tenant_id")  // VULNERABLE!
}

Non-Repudiation Through Activity Logging:

Every significant action is logged with sufficient context to prove who did what, when:

// Activity log entry structure
type ActivityLog struct {
    ID          int       `json:"id"`
    TenantID    int       `json:"tenant_id"`
    UserID      int       `json:"user_id"`
    Action      string    `json:"action"`      // CREATE, UPDATE, DELETE, LOGIN, etc.
    Resource    string    `json:"resource"`    // products, transactions, users
    ResourceID  int       `json:"resource_id"`
    OldValue    *string   `json:"old_value"`   // JSON of previous state (for updates)
    NewValue    *string   `json:"new_value"`   // JSON of new state
    IPAddress   string    `json:"ip_address"`
    UserAgent   string    `json:"user_agent"`
    Timestamp   time.Time `json:"timestamp"`
}

// Example: User cannot deny deleting a product
// Log shows: user_id=5 deleted product_id=123 at 2026-01-18T14:30:00Z from IP 192.168.1.100

What gets logged:,

• ✅ All authentication events (login, logout, failed attempts)
• ✅ All data modifications (create, update, delete)
• ✅ Permission changes (role assignments)
• ✅ Export/download of data
• 📋 Planned: Read access to sensitive fields (for compliance scenarios)

Log integrity:

• Logs written to append-only storage
• 📋 Planned: Cryptographic chaining (each entry includes hash of previous)
• 📋 Planned: Forward to tamper-proof centralized SIEM

Database

Row-Level Security Policy:

-- Defense in depth: Even if application has a bug, RLS prevents cross-tenant access
ALTER TABLE products ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON products
    USING (tenant_id = current_setting('app.current_tenant')::int);

-- Application sets tenant context on each connection
SET app.current_tenant = '123';  -- From validated JWT

Secrets Manager

Mobile Applications (iOS/Android)

Tenant Data Lifecycle

Data doesn't just need protection while active—the full lifecycle matters. When a tenant leaves, how do we ensure their data is truly gone? And how do we prove it?

Planned Deletion Workflow:

Tenant Requests Deletion
         │
         ▼
┌─────────────────────────┐
│  Grace Period (30 days) │  ← Tenant can cancel, data soft-deleted
│  • Data inaccessible    │
│  • RLS blocks all access│
│  • Marked for deletion  │
└─────────────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Hard Delete Process    │
│  • Cascade delete all   │
│    tenant records       │
│  • Generate deletion    │
│    certificate           │
│  • Log with hash proof  │
└─────────────────────────┘
         │
         ▼
┌─────────────────────────┐
│  Backup Purge (90 days) │  ← Backups age out naturally
│  • No tenant data in    │
│    backups older than   │
│    retention period     │
└─────────────────────────┘

Deletion Certificate:

To address repudiation concerns, tenant deletion generates a cryptographically signed certificate:

{
  "tenant_id": "abc123",
  "tenant_name": "Acme Corp",
  "deletion_requested": "2026-01-15T10:30:00Z",
  "deletion_completed": "2026-02-15T00:00:00Z",
  "records_deleted": {
    "users": 12,
    "products": 1547,
    "transactions": 8923,
    "companies": 34
  },
  "certificate_hash": "sha256:a1b2c3...",
  "signed_by": "StokumNET Platform"
}

This provides the tenant with proof of deletion for their compliance requirements (GDPR Article 17, CCPA, etc.) and protects the platform from claims that data was retained.

Scenario 1: Malicious Tenant Attempts Cross-Tenant Access

Attacker Profile: Authenticated user from Tenant A attempting to access Tenant B's data.

Attack Vector:

1. Attacker examines API requests, notices product IDs in URLs
2. Attempts to access /api/products/12345 (belongs to Tenant B)
3. Modifies request parameters hoping for IDOR vulnerability

Defense Layers:

Verdict: Attack fails at multiple layers. Defense in depth working as designed.

Scenario 2: Credential Stuffing Attack

Attacker Profile: Automated bot using leaked credentials from other breaches.

Attack Vector:

1. Attacker obtains credential lists from dark web
2. Attempts automated login with thousands of email/password combinations
3. Hopes users reused passwords from breached services

Defense Layers:

Verdict: Attack significantly impeded. Improvement: Implement CAPTCHA after N failures, consider WebAuthn/passkeys.

Scenario 3: Compromised Edge Server

Attacker Profile: Sophisticated attacker gains shell access to edge VPS.

Attack Vector:

1. Exploits vulnerability in exposed service (SSH, reverse proxy)
2. Gains shell access to edge server
3. Attempts lateral movement to private cloud

Defense Layers:

Potential Impact: Attacker could intercept/modify traffic at TLS termination point. This is the highest-risk compromise scenario.

Mitigations:

• ✅ VPS hardening (minimal services, SSH keys only, brute-force protection)
• ✅ Regular security updates
• 📋 Planned: Host-based intrusion detection
• 📋 Planned: Immutable infrastructure (rebuild vs patch)

Scenario 4: Supply Chain Attack

Attacker Profile: Nation-state or sophisticated criminal compromising package dependencies.

Attack Vector:

1. Attacker compromises popular package used by frontend or backend
2. Malicious code exfiltrates user data or injects cryptocurrency miner
3. Malicious package published, automatically pulled by CI/CD

Defense Layers:

Current Gaps:

• ❌ No dependency proxy (packages pulled directly from public registries)
• ❌ No private registry with approval workflow

Planned Mitigations:

• 📋 Dependency proxy to cache and scan packages
• 📋 SBOM analysis before deployment
• 📋 Signed commits and container images

Scenario 5: Social Engineering / Support Desk Impersonation

Attacker Profile: Social engineer targeting tenant employees or posing as platform support.

Attack Vectors:

Vector A - Targeting Tenant Users:

1. Attacker researches company using StokumNET (LinkedIn, company website)
2. Sends phishing email mimicking StokumNET login page
3. Harvests credentials when user attempts to "log in"
4. Uses stolen credentials to access legitimate system

Vector B - Impersonating Support:

1. Attacker contacts tenant claiming to be "StokumNET Support"
2. Requests password reset, MFA codes, or remote access
3. Uses social pressure ("your account will be suspended") to create urgency
4. Gains access through manipulation rather than technical exploit

Defense Layers:

Current Gaps:

• ❌ No formal security awareness documentation for tenants
• ❌ No published policy on what support will/won't ask for
• 🔄 MFA available but not enforced for all tenants

Planned Mitigations:

• 📋 Tenant onboarding security guide
• 📋 Published "StokumNET will never ask for..." policy
• 📋 Enforce MFA for all accounts (or strong incentive)
• 📋 Login anomaly detection (new device, new location alerts)
• 📋 Consider WebAuthn/passkeys to eliminate phishable credentials

Risk Summary Matrix

Recommendations and Roadmap Alignment

Based on this threat model, here's how the Security Roadmap addresses identified risks:

High Priority (Addresses Critical/High Risks)

Medium Priority

Lower Priority (Already Well-Mitigated)

Conclusion

Formalizing this threat model—even retroactively—proved valuable. It forced me to articulate assumptions that were implicit in the design, identify gaps I hadn't consciously prioritized, and create a document that can evolve as the system grows.

The exercise confirmed that the foundational architecture addresses the most critical threats, particularly multi-tenant data isolation. But it also highlighted areas where my intuitive security decisions need reinforcement with additional controls—especially around the human element (social engineering) and data lifecycle (secure deletion).

The most significant residual risks are:

1. Edge server compromise — Mitigated by defense in depth, but monitoring improvements needed
2. Supply chain attacks — Basic controls in place, dependency proxy planned
3. Social engineering — Technical controls (MFA) exist, but documentation and user awareness gaps remain
4. Tenant data lifecycle — Deletion workflow and compliance documentation needed

If you're in a similar position—building something with security in mind but without formal documentation—I'd encourage you to do this exercise. The structure of STRIDE (or PASTA, or attack trees, or whatever framework fits your thinking) transforms scattered security intuitions into a coherent, reviewable, improvable artifact.

Security is iterative. This threat model will evolve as the system grows and the threat landscape changes. The discipline of regularly revisiting these scenarios keeps security decisions grounded in reality rather than compliance theater.

This threat model covers StokumNET as of January 2026. Threat models should be updated when architecture changes significantly, new features are added, or new threat intelligence becomes available.

Related Posts:

• StokumNET Architecture: Building a Secure Multi-Tenant Platform
• StokumNET Security Roadmap: From Foundation to Enterprise-Grade