ATALAIA
  1. Home
  2. Services
  3. Threat Modeling
03Station 03 · Design

Threat Modeling

One hour with the people who know the feature best: product, the dev lead and security. We leave with the threats that matter and who owns each fix.

Inside the hour

Pick a step, or let it play. Every line is what someone in the room actually says.

Step 1Pick the feature

One feature or service that matters this quarter, not the whole estate.

PRODUCTThis quarter it's partner redemption: users spend points in partner stores.

ATALAIAThen that's the one. Money moves and a partner is involved. Just that flow, today.

DEV LEADIt touches the ledger, the partner API and the redeem screen.

Leaves the roomFeature: redeem points at partner stores

Step 2Draw it together

Data flows and trust boundaries on one board, with product, devs and cyber in the room.

DEV LEADThe app calls redeem, we debit the ledger, then ask the partner for a voucher.

ATALAIADraw a dashed line where the partner's network starts. That's a trust boundary.

DEVELOPERAnd the partner calls us back to confirm. That webhook is public.

Leaves the roomBoard: 6 flows, 2 trust boundaries

Step 3Find the threats

STRIDE-style prompts, attacker stories, and the questions nobody asked yet.

ATALAIAWhat if someone sends redeem twice, at the same moment?

DEVELOPERTwo debits race. They could spend the same points twice.

CHAMPIONAnd a fake webhook could confirm vouchers nobody paid for.

PRODUCTDouble spend is the one the business can't live with. Rank it first.

Leaves the room4 threats found, 2 ranked high

Step 4Turn them into tickets

Every threat leaves as a ticket, an owner, and a test.

DEV LEADIdempotency key on redeem. That ticket is mine, this sprint.

ATALAIASigned webhooks with the partner's key. QA gets the race as a test.

PRODUCTAnd the model goes in the repo. We run the next one without you.

Leaves the room4 tickets, 3 abuse-case tests

  • ATALAIA
  • PRODUCT
  • DEV LEAD
  • DEVELOPER
  • CHAMPION

The board, after one hour

This is what the room draws: boxes, arrows, dashed lines where trust changes, and a pin on every threat.

USER DEVICEREWARDS BACKENDPARTNER NETWORKredeem(offer)debit pointsissue voucherconfirmmark usedRewards appmobileAPI gatewayauth, rate limitRedeem serviceredeem()Webhook/partner/confirmPoints ledgerdatastorePartner APIexternal1234
  1. 1
    Tampering · double spend

    Two redeems race between the balance check and the debit. Ticket: idempotency key and a conditional debit.

  2. 2
    Spoofing · fake confirm

    Anyone can call the public webhook. Ticket: signed callbacks, checked against the partner's key.

  3. 3
    Disclosure · partner key

    The partner API key sits in a config file. Ticket: move it to the secret store, rotate it.

  4. 4
    Abuse · bulk redeems

    Bots redeem from many accounts. Ticket: rate limit per user, and a QA abuse test.

Before and after

Before

Threat models written by security alone describe a system nobody recognises. Written too late, they describe a system that already shipped.

  • Security reviews happen after the code is written
  • Nobody can say which features handle money, identity or personal data
  • Findings come back as a PDF and stay there
After
  • A threat model your team wrote with us, in your own repo
  • Ranked threats, each tied to a backlog ticket and an owner
  • Abuse cases your QA team can turn into tests
  • A one-hour format your team can run without us

Typical shape: One session per feature, or a short run of sessions to seed the habit.

Talk it through

A 30-minute call. No slides, no price list, and a next step either way.