Alright, team, I’ve spent the last two weeks deep in the weeds of Akamai Prolexic, not just as a security tool but as an operational system. We’re a mid-sized shop, and we needed our NOC to be able to handle a mitigation event without panicking or needing to call in the principal architect at 3 AM.
Since I'm always comparing how different platforms handle documentation and workflows (looking at you, Salesforce vs. HubSpot admin guides 😅), I took a systematic approach to building our runbook. Here’s how we did it.
**First, we mapped the triggers.**
We didn't just write "when there's an attack." We documented the exact sources of truth:
* Alert from our SIEM (specific rule IDs)
* Direct email from Akamai SIRT
* Spike in dashboard graphs (Prolexic portal) - and we specified which ones: connection rate, bandwidth, filtered traffic.
**Then, the access and initial triage.**
This seems obvious, but we created a dedicated section with:
* Direct link to the Prolexic customer portal (bookmarked in the NOC's shared browser)
* Login credentials stored in the team's password manager (with 2FA details)
* A screenshot of the main dashboard with key areas highlighted: the mitigation status, top source countries, and top attack vectors.
**The core of the runbook is the decision tree.**
We broke it down by attack type, because the response for a DNS flood is different from a TCP SYN flood. For each type, we listed:
* The typical Prolexic configuration we’d expect to see auto-applied
* What the NOC should verify is working (e.g., "check that the mitigation profile is set to 'DNS Flood' and not 'Standard'")
* Any manual steps they might need to take, like contacting Akamai support via the portal to request a profile tweak.
* We also included a "false positive" branch, detailing how to check if legitimate traffic is being impacted and how to request IP allow-listing.
**Finally, we added the "softer" but crucial details.**
* Internal comms template: who to notify (SOC lead, CISO, comms team), and the Slack/Teams channel to use.
* Post-mitigation steps: how to generate the Akamai after-action report, and where to file it for our own post-mortem.
* A list of "gotchas" we learned during our testing, like the slight delay in dashboard data propagation and the importance of clearing local cache if the portal seems stuck.
The result? It's less of a novel and more of a field manual. It forced us to really understand Prolexic's logic, not just flip the switch. Curious if others have taken a similar approach or if you've baked your runbooks directly into something like ServiceNow or PagerDuty playbooks? The integration possibilities are interesting.
Still looking for the perfect one
Mapping triggers to specific, actionable inputs is the only way to make a runbook that doesn't crumble under pressure. Good call.
Your access section reminded me of the time our NOC got locked out during a weekend event because the shared password manager session had expired. We added a failsafe: a separate, minimal-privilege service account just for portal read-only access, with a static token stored in a secure vault the NOC can pull via API. No 2FA dance at 3 AM.
One thing I'd throw in - did you bake in the cost visibility? When Prolexic kicks in, your egress charges can get weird. Our runbook has a side note for the NOC to tag the mitigation event in our cloud billing console immediately. Helps FinOps untangle the bill later.
- elle
Love that you started with triggers. So many runbooks fail because they're vague on what kicks things off. I'm a huge fan of that approach - we do the same for our marketing automation incident response.
Your access section is smart, especially the screenshot. We learned to include a "healthy state" screenshot right next to the "alert state" one. Helps the NOC spot the deviation faster.
One thing we added after a few drills: a simple pre-check list *before* they even log in. Stuff like "confirm external monitoring shows downtime" and "check if scheduled maintenance is active." Avoids a panic login for a false positive.
automate or die