Trading Firms Are High-Value Targets

Trading infrastructure combines:

• Direct access to money (API keys, wallets)
• Valuable data (order flow, positions)
• Critical uptime requirements

Attackers know this. Your security must assume you’re targeted.

---

What You’ll Learn

By the end of this lesson, you’ll understand:

1. Defense in depth - Multiple layers of protection
2. Network segmentation - Isolating critical systems
3. Secret management - Protecting API keys and credentials
4. Incident response - Detecting and responding to breaches

---

The Foundation: Defense in Depth

No single control stops all attacks. Layer your defenses:

Layer 1: Perimeter (firewall, WAF)
Layer 2: Network (segmentation, monitoring)
Layer 3: Host (hardening, EDR)
Layer 4: Application (auth, input validation)
Layer 5: Data (encryption, access control)

An attacker must breach ALL layers to reach critical assets.

---

The “Aha!” Moment

Here’s the principle that guides trading security:

Assume breach. Your perimeter will be compromised eventually. What matters is: Can attackers move laterally? Can they access keys? Can they exfiltrate data? Design your internal architecture to resist an attacker who’s already inside.

Don’t just build walls-build compartments.

---

Network Segmentation

Zone Architecture

┌────────────────────────────────────────────────────────────┐
│                     INTERNET                               │
└─────────────────────────┬──────────────────────────────────┘
                          │
┌─────────────────────────▼──────────────────────────────────┐
│ DMZ Zone                                                    │
│   [Load Balancer] [VPN Gateway] [Bastion]                  │
└─────────────────────────┬──────────────────────────────────┘
                          │ (strict firewall rules)
┌─────────────────────────▼──────────────────────────────────┐
│ Application Zone                                            │
│   [API Servers] [Order Manager] [Risk Engine]              │
└─────────────────────────┬──────────────────────────────────┘
                          │ (no internet access)
┌─────────────────────────▼──────────────────────────────────┐
│ Data Zone                                                   │
│   [Database] [Cache] [Message Queue]                       │
└─────────────────────────┬──────────────────────────────────┘
                          │ (most restrictive)
┌─────────────────────────▼──────────────────────────────────┐
│ Vault Zone                                                  │
│   [HSM] [Key Management] [Signing Service]                 │
└────────────────────────────────────────────────────────────┘

Firewall Rules Example

# Only ALB can reach API servers
resource "aws_security_group_rule" "api_from_alb" {
  type                     = "ingress"
  from_port                = 8080
  to_port                  = 8080
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.alb.id
  security_group_id        = aws_security_group.api.id
}

# API can only reach DB on postgres port
resource "aws_security_group_rule" "db_from_api" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.api.id
  security_group_id        = aws_security_group.db.id
}

# Vault zone: only signing service, only specific port
resource "aws_security_group_rule" "hsm_from_signer" {
  type                     = "ingress"
  from_port                = 2223
  to_port                  = 2223
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.signer.id
  security_group_id        = aws_security_group.hsm.id
}

---

Secret Management

Never Hardcode Secrets

# ❌ NEVER
api_key = "sk-live-abc123"

# ✓ From environment (minimum)
api_key = os.environ["EXCHANGE_API_KEY"]

# ✓✓ From secrets manager (better)
import boto3
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='exchange/api-key')
api_key = response['SecretString']

# ✓✓✓ From HSM for signing keys (best)
# Key never leaves hardware
signature = hsm.sign(data, key_id="signing-key-1")

Secrets Rotation

class RotatingSecret:
    def __init__(self, secret_id: str, rotation_days: int = 30):
        self.secret_id = secret_id
        self.rotation_days = rotation_days
        self._cached_secret = None
        self._cached_at = None
    
    def get(self) -> str:
        # Cache for 5 minutes (balance security vs latency)
        if self._cached_at and (time.time() - self._cached_at < 300):
            return self._cached_secret
        
        self._cached_secret = self._fetch_from_manager()
        self._cached_at = time.time()
        return self._cached_secret
    
    def _fetch_from_manager(self) -> str:
        # Supports automatic rotation by AWS Secrets Manager
        return secrets_manager.get_secret_value(SecretId=self.secret_id)

---

Common Misconceptions

Myth: “We’re too small to be targeted.”
Reality: Small firms often have worse security and similar access. Attackers scan broadly-they’ll find you. Crypto/trading firms are specifically targeted regardless of size.

Myth: “Cloud providers handle security.”
Reality: Shared responsibility model. AWS secures the infrastructure; you secure the configuration. Most cloud breaches are misconfiguration, not AWS failures.

Myth: “MFA everywhere means we’re secure.”
Reality: MFA protects authentication. It doesn’t help if your application has SQL injection, your secrets are leaked in logs, or your admin credentials are phished with a fake MFA prompt.

---

Incident Response

Detection

# SIEM rules for trading-specific threats
DETECTION_RULES = [
    {
        "name": "unusual_api_key_usage",
        "query": "api_key_requests | where source_ip != known_ips | where count > 100",
        "severity": "high"
    },
    {
        "name": "after_hours_withdrawal",
        "query": "withdrawals | where hour < 6 or hour > 22",
        "severity": "critical"
    },
    {
        "name": "lateral_movement",
        "query": "ssh_logins | where source_host in application_zone and dest_host in vault_zone",
        "severity": "critical"
    }
]

Response Playbook

ALERT: Unauthorized API access detected

1. IMMEDIATE (0-5 min)
   □ Revoke affected API keys
   □ Enable emergency rate limiting
   □ Capture current system state for forensics

2. INVESTIGATION (5-60 min)
   □ Identify scope (which keys, which accounts)
   □ Review access logs (how did attacker get keys?)
   □ Check for lateral movement

3. REMEDIATION (1-24 hours)
   □ Rotate all potentially exposed secrets
   □ Patch vulnerability
   □ Review and harden related systems

4. POST-INCIDENT
   □ Write incident report
   □ Update runbooks
   □ Conduct blameless postmortem

---

Practice Exercises

Exercise 1: Design Segmentation

Your trading firm has:
- Public API for clients
- Internal trading engine
- Database with positions
- Hot wallet for trading
- Cold wallet for reserves

Design network zones and rules between them.

Exercise 2: Secret Audit

Audit your current secret management:
1. Where are API keys stored?
2. Who has access?
3. When were they last rotated?
4. Are any hardcoded in code/configs?

Exercise 3: Tabletop Exercise

Scenario: You receive an alert that an unknown IP
accessed your exchange API 500 times in 1 minute.

Walk through your response:
1. What's your first action?
2. Who do you notify?
3. What logs do you check?
4. When do you escalate?

---

Key Takeaways

1. Defense in depth - Multiple layers, any one can fail
2. Network segmentation - Limit blast radius
3. Secrets in managers, not code - HSM for signing keys
4. Assume breach - Design for attacker already inside

---

What’s Next?

🎯 Continue learning: Insider Threat Protection

🔬 Expert version: Security Architecture for Trading

Now you can architect secure trading infrastructure. 🏰