A letter to firewall vendors (they won't read it)

Dear Check Point, Dear Fortinet, Dear Cisco: Pick a Schema Already

An IP address is an IP address. A subnet is a subnet. A port range is a port range. And yet, somehow, every firewall vendor on the planet has decided to represent these identical concepts in completely, maddeningly, aggressively different JSON formats. You, the network engineer, are the human translator in the middle.

7-minute read For anyone who's written a vendor API adapter

They all do the same thing. None of them agree on how.

You want to create a firewall rule that allows TCP port 443 from 10.0.1.0/24 to 192.168.5.0/24. That's it. One sentence. One concept. Universal across every firewall product manufactured in the last 20 years.

Here's what that looks like when you try to automate it across three vendors:

Check Point R81 API
// POST /web_api/add-access-rule { "layer": "Network", "position": "top", "name": "Allow-Web", "source": "Net_10.0.1.0", "destination": "Net_192.168.5.0", "service": "https", "action": "Accept", "track": { "type": "Log" } } // But first you need to // create the network objects // with separate API calls // and then "publish" the // session. Because reasons.
Fortinet FortiOS API
// PUT /api/v2/cmdb/ // firewall/policy { "policyid": 0, "srcintf": [{ "name": "internal" }], "dstintf": [{ "name": "wan1" }], "srcaddr": [{ "name": "subnet_10.0.1.0" }], "dstaddr": [{ "name": "subnet_192.168.5.0" }], "service": [{ "name": "HTTPS" }], "action": "accept", "logtraffic": "all" } // Interfaces are mandatory. // Everything is an array. // Even when it's one item.
Cisco ASA REST API
// POST /api/access/in/ // outside_access_in/rules { "sourceAddress": { "kind": "IPv4Network", "value": "10.0.1.0/24" }, "destinationAddress": { "kind": "IPv4Network", "value": "192.168.5.0/24" }, "destinationService": { "kind": "NetworkProtocol", "value": "tcp/https" }, "permit": true, "active": true, "isAccessRule": true } // "kind" and "value". // For an IP address. // In 2026.

Three vendors. Three completely different JSON structures. Three different field names for the same concept. Three different authentication models. Three different error response formats. Three different ways to say "yes, it's allowed."

Action: "Accept" vs "accept" vs true.
Source: named object reference vs named object reference vs inline CIDR with a "kind" wrapper.
Service: "https" vs "HTTPS" vs "tcp/https".

The same concept, three different representations
Check Point
"action": "Accept"
"service": "https"
"source": "Net_10.0.1.0"
Fortinet
"action": "accept"
"service": [{"name":"HTTPS"}]
"srcaddr": [{"name":"..."}]
Cisco ASA
"permit": true
"value": "tcp/https"
"kind": "IPv4Network"

Your daily translation job

Here's what your actual workday looks like when you maintain multi-vendor automation:

  1. Parse the AWS Security Group change event. Extract the CIDR, port range, protocol, and direction from AWS's JSON format. Handle the 9 different edge cases: prefix lists, security group references, IPv6, ephemeral port ranges, self-referencing groups...
  2. Translate for Check Point. Create the network object first (separate API call). Then create the service object if it doesn't exist (another API call). Then create the rule (another API call). Then "publish" the session (yet another API call). Handle the session lock if someone else is editing the policy. Handle the 10-minute session timeout.
  3. Translate again for Fortinet. Different field names. Different nesting structure. Everything in arrays. Interfaces are mandatory but Check Point doesn't use them. Map your internal interface naming convention. Handle the API key auth (not session-based like Check Point).
  4. Translate again for Cisco. Inline CIDR this time, not named objects. "kind/value" wrappers around everything. Different URL path structure per access list. No bulk operations — one rule per API call.
  5. Handle the errors. Check Point returns a task ID you have to poll. Fortinet returns the error in a different JSON path depending on the error type. Cisco returns HTTP 500 for everything and puts the actual error in the response body. Parse all three error formats. Decide what to do for each one.
  6. Repeat every time a vendor releases an API update. Check Point R81.10 changed three field names. Fortinet 7.4 deprecated two endpoints. Cisco ASA 9.18 added a mandatory field. Each one breaks your code silently. You find out at 2am.
You are not a security engineer. You are a full-time JSON translator who happens to understand firewalls.

What if the translation just... happened?

This is the part that's almost too simple to believe. Cyberm8 understands what an IP address is. What a subnet is. What a port range is. What "allow TCP 443 from A to B" means. It knows how to express that concept in Check Point's language, and Fortinet's language, and Cisco's language, and Palo Alto's language.

You describe the rule once. In human terms. The engine translates it for every vendor in your estate.

In Cyberm8, you describe the request once

// What you configure in Cyberm8: Rule: Allow-Web-Finance Source: 10.0.1.0/24 Destination: 192.168.5.0/24 Service: TCP/443 Action: Allow Targets: all-perimeter-firewalls // What Cyberm8 does automatically: // → Translates to Check Point format. Creates objects. Publishes session. // → Translates to Fortinet format. Maps interfaces. Wraps in arrays. // → Translates to Cisco format. Inlines CIDR. Adds kind/value wrappers. // → Pushes to all targets atomically. Verifies. Logs. Done.

No Python. No per-vendor code. No JSON parsing. No session management. No error format translation. You described the what. The engine handled the how.

And when Check Point releases R82 and changes three field names? Cyberm8 updates the adapter. Your configuration doesn't change. Your night's sleep doesn't change. You don't even need to know it happened.

How to make the case to your team

The elevator pitch for your team lead

"We're spending X hours a week maintaining three vendor-specific API adapters that do the same thing: translate firewall rules between formats. Every vendor update breaks at least one of them. There's a platform that handles the translation natively for all our vendors. It would eliminate our entire vendor-specific codebase and the on-call burden that comes with it. I want to test it against our Check Point cluster for one hour. Can I?"

The strongest version of this pitch is: show your team lead the three JSON payloads side by side (use the ones above — they're real). Then show them the Cyberm8 version. The visual says more than any argument.

Stop being a JSON translator.

Connect your firewalls to the free test instance. Push one rule to three vendors. See the translation happen in real time. Takes less time than debugging one Check Point session timeout.

Try the Multi-Vendor Demo → info@cyberm8.com — we know what "kind": "IPv4Network" feels like.