When 600 Addresses Isn’t Enough: Building a Smarter Threat Feed
Managed Cybersecurity • Firewall Architecture • Threat Intelligence • IT Operations
Strategic Summary: A standard FortiGate address group caps out at 600 members—a ceiling that active SOC operations can quickly breach. Security Specialist Jacques van der Merwe details how Si Futures engineered a dynamic external threat-feed API to bypass static object limits, streamline firewall policies, and transform perimeter security into an automated intelligence engine.
For a while, the process was straightforward. We added the IP addresses to the relevant FortiGate address group, applied the necessary inbound and outbound block rules, and cleared any existing sessions associated with those addresses. Clean, simple, done.
Then the lists started growing rapidly.
Within a week or two, the 600-member address group was full and we created a second group, then a third. Each new group introduced more configuration overhead. Every security policy referencing the first group had to be manually updated to include the second and third. Maintenance overhead increased steadily—and so did the risk of a policy being missed or applied inconsistently.
The problem was no longer simply the number of malicious IP addresses. The architecture itself needed to change.
Figure 1: Architectural migration from static FortiGate address groups (left) to a centralized, dynamic external threat feed API (right).
The Better Architecture for Threat Intelligence Integration
FortiGate firewalls support a native external threat-feed mechanism that works fundamentally differently from a conventional address group. Instead of storing every address as an individual object inside the firewall configuration database, the FortiGate periodically retrieves a formatted list from an external API endpoint. When that list updates, the firewall pulls changes automatically on a schedule.
The capacity increases dramatically. Depending on the FortiGate appliance model and FortiOS release, an external threat feed can support hundreds of thousands of entries—far beyond the 600-member cap of a static group. Policies also stay remarkably clean because only a single threat feed object needs to be referenced, regardless of how many thousands of IP addresses it contains.
Building the solution required engineering the backend data store and application behind that endpoint. We developed a lightweight web application that houses the IP list, accepts updates through a controlled administrative interface, and publishes the formatted feed for scheduled firewall retrieval.
Now, when a new list of malicious IP addresses arrives from the client’s SOC, our engineers add the entries directly to the application. The FortiGate retrieves the updated feed during its next automated poll.
One Threat Feed, Multiple Sources of Intelligence
During development, another operational advantage became apparent. A separate client’s connectivity reporting regularly surfaces IP addresses that appear suspicious, generate false positives, or require policy review. While these addresses may not justify an immediate permanent block, they need continuous evaluation.
The same endpoint architecture can ingest intelligence from multiple approved sources rather than relying on a single SOC pipeline. This creates the opportunity for the threat feed to evolve into a broader protection layer across our entire client ecosystem.
An IP address identified in one environment can be evaluated by our security team and, where the intelligence is sufficiently reliable, incorporated into active defenses for other participating clients. However, that does not mean every suspicious address should be automatically blocked everywhere.
IP addresses are frequently reassigned, shared, or associated with legitimate multi-tenant cloud platforms. Cross-environment threat distribution requires strict validation, allow-list checks, automatic expiration rules, and client-specific policy scoping. The value lies not in maintaining one indiscriminate global blacklist, but in running a controlled system where threat intelligence is assessed once and applied appropriately everywhere it adds value.
What a Smarter Firewall Management Approach Looks Like in Practice
When we informed the client’s InfoSec team that we were shifting from multiple static address groups to a dynamic external threat feed, the immediate response was: “I love you.” It wasn’t formal corporate sign-off—it was an engineer recognizing that someone had solved a persistent operational problem they had been quietly living with.
The application is now used daily by our engineering team. New SOC requests are ingested directly, and the FortiGate ecosystem retrieves the updated feeds automatically. The system is fully documented so any authorized engineer can manage it seamlessly without needing to maintain the underlying codebase.
What This Means for Managed Security Operations
Managed firewall services are typically evaluated on uptime, SLAs, and rule updates. While those metrics matter, the real value of an embedded security partner comes down to execution quality:
- Execution vs. Governance: A standard provider acts quickly when a block list arrives; an engineering partner evaluates how that list is processed and builds a better system when legacy methods break down.
- Infrastructure Stewardship: Managing security infrastructure with the same rigor, care, and continuous optimisation as if it were our own.
Building Actionable Threat Intelligence
If your organisation relies on active threat intelligence—whether from an internal SOC, a commercial feed, or custom network telemetry—the infrastructure handling those indicators deserves the same scrutiny as the threats themselves.
Our Trusted Response Centre is built around this exact proactive, engineering-led ethos: not just reacting to intelligence, but engineering the platforms that make intelligence actionable at scale.
