How do I automate firewall or blocklist updates using Tines?

Tines Stories: Ask + Answer
1

When we confirm a malicious IP or domain, the next step is usually adding it to a blocklist or firewall rule. That process is manual right now and introduces lag between detection and blocking. I’d like to automate it with Tines. Has anyone built workflows for this, and what does the typical approach look like?

2

Automating this is a solid move, and it’s a well-worn pattern in Tines builds as the payoff is immediate and easy to measure.

The typical shape: something confirms an IP or domain is malicious (a human approving, a threat intel feed crossing a confidence threshold, or a triage workflow deciding on its own), and that confirmation triggers an HTTP Request action against whatever holds your blocklist. The exact mechanics depend on what you’re blocking with.

If you’re using Palo Alto, a common pattern is maintaining an External Dynamic List that Tines keeps updated, rather than touching firewall rules directly each time. The firewall polls the list on its own schedule, so Tines’ job is just keeping it current. There’s a library example for this, blocking scanning IPs via a Palo Alto EDL.

For cloud environments, AWS WAF is a common target, updating a rule group directly via API. There’s a library example doing this with JA3 fingerprints from Abuse.ch, but the pattern is the same for IPs.

For a combined detect-and-respond version, here’s a story that takes Elastic Security alerts, checks them against GreyNoise to filter out benign scanners, and only blocks IPs that clear that check.

And if you need to generate containment rule groups dynamically rather than append to a static list, here’s an example for that within CrowdStrike.

A few things that might be worth building in before going live:

  • Put a confidence gate in front of the block action. If a human confirms malicious, that’s your gate. If a feed triggers it automatically, make sure there’s a reputation threshold rather than any single hit.
  • Add an expiry or review mechanism so the blocklist doesn’t grow indefinitely and eventually block something legitimate that rotated into an old IP range.
  • Always build an easy rollback path through the same workflow.
  • Log every block somewhere visible (Slack, a Case) so blocks are auditable even though the process runs unattended.
  • The IP list capability page is also worth a look for the general pattern of maintaining shared blocklists across multiple tools.

Hope this helps. :blush: