Security

Defense in Depth: Security Architecture for High-Stakes Trading

Zero Trust networking with Teleport, supply chain security with Sigstore, and real-time risk engines with Chainalysis. How to secure an exchange from the inside out.

3 min
#security #zero-trust #teleport #sigstore #compliance

In 2024, exchanges are not hacked by script kiddies attacking firewalls. They are hacked by nation-state actors (Lazarus Group) who spear-phish your lead DevOps engineer, compromise their laptop, and inject malicious code into your CI/CD pipeline.

Your threat model is not a brute-force attack. It is social engineering combined with supply chain compromise.

This post documents the Defense in Depth strategy for securing a modern trading firm using Zero Trust Networking and Supply Chain Attestation.

1. The Physics of Trust

Traditional security assumes “Inside = Safe” and “Outside = Dangerous” (the Castle-and-Moap model). This fails when the attacker is inside, via a compromised laptop or a malicious dependency.

Zero Trust Architecture (ZTA) assumes the network is always hostile.

2. The Decision Matrix: SSH Access

Scenario: An engineer needs SSH access to the production Matching Engine to debug a crash. Constraint: If their laptop is compromised, the attacker must NOT gain persistent access.

MechanismCredential DurationLateral Movement RiskVerdict
A. Static SSH KeysForeverCriticalRejected. Key exfil = game over.
B. VPN + LDAPSessionHighRejected. VPN breach = full access.
C. Teleport (JIT)1 HourLowSelected. Identity-based, short-lived.

3. The Kill: Just-in-Time Access with Teleport

We use Teleport to proxy all SSH and Kubernetes access. Engineers do not have static SSH keys.

Step 1: Login via SSO

tsh login --proxy=teleport.exchange.com --auth=okta
# Opens browser, MFA via TouchID
# Issues a 1-hour mTLS certificate

Step 2: Access the Server

tsh ssh user@matching-engine
# Uses the short-lived certificate, not a static key

After 1 hour, the certificate expires. The engineer must re-authenticate.

4. Supply Chain Security: Sigstore/Cosign

Attacks often occur in the build phase. A compromised CI runner can inject malicious code into your container image.

We sign every artifact with Cosign (Sigstore).

# In CI Pipeline
cosign sign --key gcpkms://projects/my-project/cryptoKeys/ci-signer \
  gcr.io/my-exchange/matching-engine:$COMMIT_SHA

The Kubernetes cluster (via Kyverno Policy) rejects any image without a valid signature.

# kyverno-policy.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
spec:
  rules:
    - name: verify-image
      verifyImages:
        - image: "gcr.io/my-exchange/*"
          key: gcpkms://projects/my-project/cryptoKeys/ci-signer

5. Systems Thinking: The Trade-offs

  1. Friction vs. Velocity: Zero Trust adds friction. Engineers hate re-logging every hour.
    • Mitigation: Use TouchID/biometric MFA for frictionless re-authentication.
  2. Break-Glass Scenarios: If Teleport goes down, how do you access servers?
    • Solution: Physical “Break Glass” keys stored in a safe. Using them triggers a P1 alert to the C-Suite.
  3. Dependency on Vendors: Teleport, Sigstore, Okta are all external dependencies.
    • Mitigation: Test failover procedures quarterly.

6. The Philosophy

Security is not a feature. It is a tax that you pay on every feature you ship.

The question is not “How much security do we need?” but “How much friction can we tolerate while remaining secure?” Zero Trust architectures answer this by making security invisible: short-lived credentials, automatic verification, no static secrets.

The goal is not to make attacks impossible-that is a fantasy. The goal is to make attacks expensive and detectable.


Need a Security Architecture Review?

Building trading infrastructure with security in mind? I help firms design defense-in-depth architectures that don’t compromise on latency. Let’s discuss your security posture →

Share: LinkedIn X