RED×BLUE

Threat Playbook

Adversary vectors paired with the defensive controls that close them. Read top-to-bottom — engagements are sorted by severity. Baseline controls below apply across the surface.

Severe

Moderate

Low

Baseline

Severe · Act Now

3 engagements

SEVERER-01↔B-01Spear-phishing named principals under quarantine-only DMARCHigh confidence

Red · Adversary VectorR-01

Spear-phishing named principals under quarantine-only DMARC

Spoofed mail addressed to or impersonating the named co-founders / senior principals will very likely reach Jane Street mailboxes because p=quarantine leaves messages in the inbox-spam continuum rather than rejecting them outright. Combined with high-fidelity org context the recon dataset already exposes (Delaware partnership structure, 250 Vesey HQ, FCA/SEC/MAS/AFM regulatory cadence, vendor stack from TXT records), adversaries can build firm-specific pretexts referencing real Bloomberg / Atlassian / Slack / Pardot workflows. Mitigated by b_01 (DMARC reject + SEG hardening) and b_07 (executive-protection workflows).

Blue · Defensive ControlB-01

Move DMARC policy from quarantine to reject

Reconfigure _dmarc.janestreet.com from p=quarantine to p=reject after a brief monitoring window using existing rua=dmarc-reports-aggregate@janestreet.com / ruf=dmarc-reports-failure@janestreet.com feedback. Pair with an MDN-Observatory re-test target (current grade B/70 with 2 failed tests). Closes the spear-phishing margin in r_01.

SEVERER-02↔B-02Bloomberg supply-chain trust boundaryModerate confidence

Red · Adversary VectorR-02

Bloomberg supply-chain trust boundary

Bloomberg sits in two places on the trust boundary: as an SPF-authorized outbound mail relay (include:bloomberg.net) and as the de facto industry terminal/MSG layer. Either path provides an adversary who compromises Bloomberg infrastructure the ability to spoof internal-looking messages and/or observe trading-context flows. Paired control b_02 covers vendor-segmentation hardening.

Blue · Defensive ControlB-02

Segment Bloomberg trust boundary and validate inbound mail provenance

Remove or tighten the SPF include:bloomberg.net authorization to the specific Bloomberg-managed enterprise relays in use (rather than the full include set), and validate inbound Bloomberg-MSG / B-net traffic with DKIM-domain pinning. Audit Bloomberg Terminal IAM access by trader-role and apply just-in-time elevation. Counters r_02.

SEVERER-03↔B-03AWS Route 53 + Global Accelerator concentrationModerate confidence

Red · Adversary VectorR-03

AWS Route 53 + Global Accelerator concentration

Single-provider DNS + edge IP routing creates a concentration point where one AWS-side incident affects every customer-facing surface of janestreet.com. Adversaries targeting AWS organizational accounts (cross-tenant escalation, IAM credential theft from a JS engineer) would inherit DNS-control authority. Mitigated by b_03 (multi-provider DNS + CAA / DNSSEC posture).

Blue · Defensive ControlB-03

Diversify authoritative DNS and enable DNSSEC

Add a second authoritative DNS provider (Cloudflare, NS1, or Akamai) and enable DNSSEC on janestreet.com. The current AWS-only posture is a concentration point — multi-provider hidden-primary or split-horizon authoritative DNS removes the single failure mode in r_03 at low operational cost. Keep CAA + iodef escalation intact.

Moderate · Plan Mitigation

4 engagements

MODERATER-04↔B-04Pardot recruiting-pipeline impersonationModerate

RedR-04

Pardot recruiting-pipeline impersonation

The two Salesforce org IDs already exposed in janestreet.com TXT records (00D40000000Mzos=1TBPK00000000Pp, 00DO800000NGrHd=1TBO80000000jwP) let an adversary craft Pardot-shaped lures targeting Jane Street campus and lateral recruiting flows — a flow that, by design, accepts outbound mail to unauthenticated external parties (candidates) and inbound replies. Mitigated by b_04.

BlueB-04

Pardot tenant hardening + recruiting-pipeline impersonation training

Apply Salesforce Pardot tenant-side hardening (sender authentication on every outbound program; mandatory IP-allowlisting for admin console; org-id rotation if feasible). Run targeted impersonation-awareness training for campus / lateral recruiting and institutional outreach teams who interact with external counterparties. Counters r_04.

MODERATER-06↔B-06Multi-jurisdiction regulator-impersonation pretextingModerate

RedR-06

Multi-jurisdiction regulator-impersonation pretexting

The 38-entity / 14-jurisdiction footprint creates many small compliance teams, each receiving routine regulator correspondence. An adversary running region-specific pretexting (ADGM-styled notice to Jane Street MENA Limited, FCA-styled to Jane Street Financial Limited) exploits the inverse-square law of vigilance — junior reviewers at distant subsidiaries see less suspicious mail than the NY HQ. Mitigated by b_06 (cross-jurisdiction compliance-channel attestation).

BlueB-06

Cross-jurisdiction regulator-channel attestation

Publish an internal directory mapping each regulator (SEC/FINRA/CFTC/NFA/FCA/AFM/MAS/SFC/ADGM/SEBI/etc.) to authoritative correspondence channels and a single Jane Street compliance liaison. Require every regional compliance officer to validate inbound regulator correspondence against the directory before action. Counters r_06.

MODERATER-08↔B-09SBSE swap-counterparty onboarding impersonationModerate

RedR-08

SBSE swap-counterparty onboarding impersonation

Standing up a Security-Based Swap Dealer entity creates a new counterparty-onboarding flow with formal confirmation channels. Adversaries impersonating Jane Street swap confirms or ISDA-amendment outreach to mid-size counterparties exploit the freshness of the registration (procedures still bedding in). Mitigated by b_09 (swap-confirmation out-of-band attestation).

BlueB-09

Swap-confirmation out-of-band attestation channel

For every new SBS counterparty onboarded under Jane Street Derivatives Dealer, LLC, establish an out-of-band (phone / dedicated portal) confirmation step on first swap confirm and on any material ISDA amendment. Document procedures in the post-SBSE compliance manual. Counters r_08.

MODERATER-05↔B-05Anthropic enterprise integration — emerging surfaceLow

RedR-05

Anthropic enterprise integration — emerging surface

The Anthropic verification confirms integration exists but recon does not reveal scope (workspace? code review? trader-assist? research summarization?). The vector class — prompt injection, shared-context leakage, retrieval-corpus poisoning, supplier-side incident — is real and growing. Paired control b_05 covers AI-integration governance.

BlueB-05

AI-integration governance: scope, audit, and prompt-injection defenses

Document the scope of every enterprise AI integration (Anthropic confirmed; others likely follow). Apply per-workspace data-loss prevention on prompt content, retrieval-corpus contents, and tool-call surfaces. Establish a prompt-injection regression-test pipeline against the deployed AI surface. Counters r_05.

Low · Monitor

1 engagement

LOWR-07↔B-08CAA-bypass cert-misissuance against janestreet.comLow

RedR-07

CAA-bypass cert-misissuance against janestreet.com

Defensive posture is already strong (CAA + iodef + Mac MDM via Jamf for endpoint trust). The residual vector is the small class of CA mistakes that issue against CAA-restricted FQDNs anyway; CT-log monitoring closes most of this, but Jane Street's monitoring cadence on derivative subsidiary domains (jane-street-* variants, country-TLD analogues) was not directly observed in recon. Mitigated by b_08 (continuous CT-log monitoring).

BlueB-08

Continuous CT-log monitoring across the multi-jurisdiction domain footprint

Extend the existing CAA / iodef posture with continuous CT-log monitoring against janestreet.com AND the country-TLD analogues (janestreet.co.uk, janestreet.nl, etc.) AND likely typosquats. Alert on any non-allowlisted CA issuance regardless of whether CAA blocked it (defense-in-depth). Counters r_07.

Baseline · Surface-Wide

3 controls

B-10Baseline

FIDO2 / phishing-resistant MFA across SSO, code-hosting, and cloud admin consoles

Enforce phishing-resistant MFA (FIDO2 hardware tokens or platform passkeys) on every SSO surface, AWS Organizations admin console, GitHub / GitLab repos, Atlassian admin, and Pardot admin. Removes credential-stuffing payoff from any vector that depends on password-only auth, including r_01/r_04 credential capture.

B-11Baseline

OpenSanctions / OFAC / EU consolidated sanctions screening pipeline for counterparties

Stand up a sanctions / PEP / debarment screening pipeline that does NOT depend on the single (currently HTTP-404) OpenSanctions endpoint — instead poll OFAC SDN List, EU CFSL, UK OFSI, and a self-hosted yente or OpenSanctions deploy. The recon evidence base lacks any sanctions data (ev_028 kj_005) — closing that analytical gap is itself a control.

B-12Baseline

Continuous attack-surface monitoring across the 38-entity family

Each newly-founded entity (most recently JSQC Ltd 2026-03, Jane Street MENA Ltd 2025-06) creates new domain / DNS / email surface. Run continuous ASM (CT-log feed + DNS history + WHOIS history) against every entity-name variant in GLEIF's ultimate-children query for this family. Catches new subsidiary infrastructure before it can be impersonated.