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.

---

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)
```diff

An attacker must breach multiple layers to reach critical assets.

---

## 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

```text
┌────────────────────────────────────────────────────────────┐
│                     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]                 │
└────────────────────────────────────────────────────────────┘
```text

### Firewall Rules Example

```hcl
# 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
}
```diff

---

## Secret Management

### Never Hardcode Secrets

```python
# Never
api_key = "NEVER_HARDCODE_KEYS"

# From environment (minimum viable)
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")
```text

## Secrets Rotation

```python
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)
```python

---

## Common Misconceptions

**Myth:** "We're too small to be targeted."
**Reality:** Small firms often have worse security and similar access. Crypto/trading firms are specifically targeted. Automated scanners don't care about your revenue.

**Myth:** "Cloud providers handle security."
**Reality:** Shared responsibility model. AWS secures the infrastructure; you secure the configuration. Most cloud breaches are misconfiguration, not infrastructure 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 in logs, or your admin credentials are phished with a fake MFA prompt.

---

## Incident Response

### Detection

```python
# 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"
    }
]
```text

## Response Playbook

```yaml
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
```diff

---

## Practice Exercises

### Exercise 1: Design Segmentation
```python
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.
```text

### Exercise 2: Secret Audit
```sql
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?
```text

### Exercise 3: Tabletop Exercise
```yaml
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?

Insider Threat Protection

Compliance by Design - Automating regulatory governance with Enclaves.

Security Architecture for Trading