Skip to content
Notifications
Clear all

Step-by-step: How we automated attack response triggers with Akamai's API

3 Posts
3 Users
0 Reactions
0 Views
(@annie82)
Estimable Member
Joined: 1 week ago
Posts: 61
Topic starter   [#14531]

Hi everyone,

I've been lurking for a while, learning so much from you all. 😊 My team recently started using Akamai Prolexic, and honestly, the dashboard is powerful but a lot to handle manually. We're a small operations group, and getting paged for every alert, then having to log in and manually review before taking action was burning us out.

We knew the API could help, but the documentation felt huge and we were scared of automating the wrong thing. Our goal was simple: automatically block traffic from a source country if we saw a specific, high-volume attack signature, but only during non-business hours. We finally pieced together a workflow that works for us.

It starts with a SIEM alert that triggers a Python script. The script first checks if it's outside our defined business window. If it is, it uses the Akamai API to validate the attack is ongoing, then creates a temporary block rule in a specific security policy we set up just for these automated actions. We log everything, and the rule expires after 6 hours so we don't forget about it.

The biggest hurdle was managing API credentials securely and getting the policy ID right for our configuration. We also built in a simple "approval" step by having the script post to a private Slack channel before executing, where we can override with a simple emoji reaction.

It’s not fancy, but it’s cut our after-hours stress in half. I’m curious if anyone else has set up similar automated triggers? How do you handle false positive risks? I’d love to compare notes and see if there’s a better way to structure this.

✌️ annie



   
Quote
(@alexm82)
Estimable Member
Joined: 1 week ago
Posts: 71
 

That sounds like a huge step forward from manual work. I'm curious about the temporary block rule expiring after 6 hours. Do you find that's always enough time for an attack to subside, or do you sometimes have to manually extend it? We've been burned by automated things that expire too early.



   
ReplyQuote
(@bookworm42)
Estimable Member
Joined: 1 week ago
Posts: 88
 

Six hours is usually sufficient for our use case, but the key is flexibility in the design. Our script pulls the rule ID and logs it to our incident ticket. If the attack's still raging when the sun comes up, an engineer can easily use that ID to find and extend the duration through the API, or convert it to a permanent rule.

The bigger lesson for us was setting the expectation that these are *mitigation* rules, not permanent policy. If we're consistently blocking a source for the same reason during business hours, that's a signal we need to review and update our core security posture. The automation handles the immediate fire, but we still have to do the manual review, just not at 2 AM.



   
ReplyQuote