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

1 engagement

SEVERE R-01 ↔ B-01 DMARC-permissive impersonation of @benefitadvisorsnetwork.com High confidence

Red · Adversary Vector R-01

DMARC-permissive impersonation of @benefitadvisorsnetwork.com

The combination of DMARC p=none with a brand whose function is moving authoritative correspondence between brokers, plan participants, and insurance carriers is the most exploitable single finding in this investigation. Named executives Perry Braun (ent_012) and Bobbi Kloss (ent_013) provide ready impersonation handles. The fix is mechanical and entirely under BAN's control: deploy aggregate-report monitoring, identify legitimate senders (Microsoft 365, Shield Security, EncryptTitan, the AWS 3.13.39.22 mystery, and any others), then ramp DMARC through p=quarantine to p=reject.

Blue · Defensive Control B-01

Stage DMARC to p=reject with a 30–60 day monitoring ramp

Step 1: deploy a DMARC aggregate-report mailbox (rua=mailto:dmarc@…) and a forensic mailbox if available. Step 2: monitor for 30 days, identify every legitimate sender (M365, Shield Security, EncryptTitan, the AWS 3.13.39.22 mystery, plus any benefit-administration tools), confirm each has SPF and DKIM alignment. Step 3: move to p=quarantine; pct=25, ramp to 100% over two weeks. Step 4: move to p=reject. This closes R-01 mechanically.

Moderate · Plan Mitigation

6 engagements

MODERATE R-05 ↔ B-05 Named executive surface — Braun and Kloss as spear-phish anchors High

Red R-05

Named executive surface — Braun and Kloss as spear-phish anchors

Spear-phishing risk is multiplicative with R-01: weak DMARC raises the success rate of identity-spoofed lures targeting either executive. The control set is layered awareness training, out-of-band verification for any payment / credential / system-change request, and (where commercially supportable) executive-protection processes including curated mailbox monitoring.

Blue B-05

Executive impersonation defence — training plus out-of-band verification

Augment B-01's DMARC enforcement with explicit training for ent_012 and ent_013, plus their immediate finance and operations contacts: any payment-redirection, credential-prompt, document-share, or system-change request that arrives by email must be confirmed via a second channel (voice call to a stored number, in-app message, in-person). Codify the rule in BAN's standard operating procedures. Closes R-05's residual capability after B-01 lands.

MODERATE R-02 ↔ B-02 Unidentified AWS SPF authorisation as an attribution-laundering relay Moderate

Red R-02

Unidentified AWS SPF authorisation as an attribution-laundering relay

Without identifying the operator of 3.13.39.22, BAN cannot scope the blast radius of a hypothetical compromise of that vendor. The mitigation is to identify the vendor (typically by reviewing finance/HR/marketing SaaS contracts or by direct request to vendors for their official SPF includes), then either replace the bare ip4: entry with the vendor's named SPF include macro, or revoke the authorisation if the relationship is dormant.

Blue B-02

Identify and named-include the AWS 3.13.39.22 sender

Determine which vendor operates 3.13.39.22 (typically discoverable via finance/HR/marketing-tool inventory or by issuing a query to vendors for their official SPF includes). Replace the bare ip4: entry in BAN's SPF with the vendor's named macro (include:_spf..com), or remove the authorisation entirely if the relationship is dormant. Closes R-02 and removes the attribution gap.

MODERATE R-03 ↔ B-03 Any-CA issuance permitted — MitM enabled by missing CAA Moderate

Red R-03

Any-CA issuance permitted — MitM enabled by missing CAA

Single-line DNS remediation: CAA 0 issue "letsencrypt.org" (or the actual CA-of-record) plus a CAA 0 iodef reporting address. This restricts certificate issuance to the named CA and gives BAN visibility into attempted misissuance.

Blue B-03

Publish CAA records restricting cert issuance

Single-record DNS change. Recommended baseline: CAA 0 issue "letsencrypt.org" (or BAN's actual CA of record), CAA 0 iodef "mailto:security@benefitadvisorsnetwork.com". Restricts certificate issuance to the named CA and gives BAN reporting visibility into misissuance attempts. Closes R-03.

MODERATE R-04 ↔ B-04 DNS responses unauthenticated — cache-poisoning capable Moderate

Red R-04

DNS responses unauthenticated — cache-poisoning capable

Enabling DNSSEC at GoDaddy is a configuration step rather than infrastructural work. The upstream resolver chain still has to validate DNSSEC for the protection to apply end-to-end, but GoDaddy-signed zones force any tampering attempt to either break the chain (detectable) or compromise the signing infrastructure (much harder).

Blue B-04

Enable DNSSEC at GoDaddy

GoDaddy supports DNSSEC signing for the domain. Enable via the registrar's management UI; the signed records propagate to GoDaddy's DNS infrastructure (NS69/NS70.DOMAINCONTROL.COM). End-to-end protection depends on the resolver chain validating DNSSEC; nonetheless the signed zone closes the cheap on-path tampering vector. Closes R-04.

MODERATE R-06 ↔ B-06 Zywave npm publishing concentrates supply-chain risk in two engineers Moderate

Red R-06

Zywave npm publishing concentrates supply-chain risk in two engineers

The package licence (UNLICENSED) does not technically prevent installation — npm enforces no licence-based access control — so the public registry is a viable distribution channel even for closed-source SaaS components. This is upstream of BAN's direct remit; the actionable control is vendor-risk dialogue with Zywave to confirm publish-token hardening (npm 2FA enforced on the org, granular access tokens, branch-protection on the publish workflow).

Blue B-06

Vendor-risk dialogue with Zywave on publish-token hygiene

BAN cannot directly secure Zywave's npm org but can raise the question as part of vendor-risk review: confirm npm org-level 2FA is enforced, that publish workflows use granular tokens rather than personal access tokens, that the @zywave scope has provenance / sigstore verification enabled, and that npm session timeouts are appropriately short. Closes R-06's first-order risk to the extent Zywave's posture matches BAN's expectations.

MODERATE R-07 ↔ B-07 Press-release pretext for member-firm targeting Moderate

Red R-07

Press-release pretext for member-firm targeting

The pattern requires sub-domain monitoring (CT log subscription for *benefitadvisors* / *benefit-advisors* / *banadvisors*) plus a quarterly takedown workflow for the highest-similarity matches. BAN's member-firm onboarding email should include explicit anti-impersonation language and a verifiable out-of-band channel for confirming first-contact authenticity.

Blue B-07

Lookalike-domain monitoring and member-firm onboarding hardening

Subscribe to a CT-log feed for variants of benefitadvisors* / benefit-advisors* / IDN homoglyph permutations. Take down the highest-similarity matches on a quarterly cadence (registrar abuse channels). Bake an explicit anti-impersonation paragraph into BAN's member-firm welcome packet, naming an out-of-band channel (specific phone number, signed PDF callback) for confirming first-contact authenticity. Closes R-07.

Baseline · Surface-Wide

4 controls

B-08 Baseline

MFA enforced across all BAN and tenant access — M365, Shield, EncryptTitan, Zywave

BAN's Microsoft 365 tenant (ent_006) is the single most leveraged authentication surface. Enforce MFA (preferably phishing-resistant FIDO2 / WebAuthn rather than SMS or TOTP) on every M365 account, every Shield Security admin account, every EncryptTitan administrator, and every Zywave admin. Baseline hardening that closes a large fraction of credential-stuffing and phishing-derived account-takeover scenarios beyond R-01 alone.

B-09 Baseline

Remediate the MDN Observatory F (CSP, HSTS, security headers)

Apply Mozilla Observatory's recommended security headers to benefitadvisorsnetwork.com — at minimum HSTS with a 12-month max-age, a baseline Content-Security-Policy, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, and X-Frame-Options or CSP frame-ancestors. Re-scan; the grade should move from F to at least B in a single deploy. Closes ent_025's specific failure modes.

B-10 Baseline

Asset and SaaS inventory — bind every SPF authorisation to a named owner

Maintain a living inventory of every third-party SaaS that sends mail as BAN. For each entry: owner inside BAN, vendor contact, contractual review date, the corresponding SPF include or IP authorisation. The B-02 fix for 3.13.39.22 is the proximate instance; a general inventory makes future drift visible.

B-11 Baseline

Subdomain and CT-log monitoring across benefitadvisorsnetwork.com

Subscribe to certificate-transparency log feeds (e.g., crt.sh notification, Cloudflare CT monitoring) for any certificate issued under benefitadvisorsnetwork.com or member-firm-adjacent domains. Catches both legitimate-but-unknown internal services and adversary-issued certificates from rogue CAs (paired with B-03's CAA control). Closes the kj_007 completeness gap proactively.