Detection Engineering

Every attack path found on the line becomes a detection. Pentest and bounty findings turn into SOC use cases for your stack.

From attack path to alert

One pentest finding, carried all the way to an analyst's screen.

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

From pentests, bounty reports and threat models.

ATALAIANine attack paths from your pentests and bounty. These are real. They worked.

OFFENSIVEThe IDOR on /redeem is the one we'd try again.

Leaves the room9 attack paths from pentests and bounty

Which log, event or metric would show each one.

SOCWhat would that look like in our logs?

ATALAIAOne user asking for offers owned by many others. But /redeem doesn't log the owner.

DEV LEADWe'll add the owner ID to the access log this sprint.

Leaves the roomSignal: user ≠ owner on /redeem

Rules, then attack simulations that prove they fire.

ATALAIARule: one user, more than five foreign offer IDs in ten minutes.

OFFENSIVERunning the attack in staging now.

SOCAlert fired. Forty seconds.

Leaves the roomRule written, simulation fired

Thresholds and runbooks the analysts agree with.

SOCSupport agents will trip it. They look up offers all day.

ATALAIAThen exclude the support role and keep it for everyone else. Here's the runbook.

Leaves the roomRunbook, threshold agreed

“We'll add the owner ID to the access log this sprint.”
DEV LEAD · step 2, Find the signal

Most SOCs watch generic signals. The attacks that matter to you are the ones your own pentests already found.

Typical shape: Ongoing, a batch of use cases per cycle.

Every station reports to the same tower. These are the neighbours.

Scoped, manual, retested

New threats checked against your stack

Scope, triage, rewards, fixes

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