Summary The Cisco Meraki Inspector does not collect the MX Threat Protection settings found under Security & SD-WAN → Configure → Threat protection in the Meraki dashboard. This means Advanced Malware Protection (AMP) and Intrusion Detection/Prevention (IDS/IPS) state cannot be alerted on, reported on, or tracked for change in Liongard. These are two of the highest-value security controls on an MX, and both can be disabled by a single dropdown change in the dashboard with no other visible side effect. Today that change is invisible to Liongard. Current behavior The current data print returns the following per network under Configuration.Networks[]: VLANs, FirewallRules, InboundFirewallRules, L7FirewallRules, SSIDs, AccessPolicies, StaticRoutes, VPNs, NAT, QOS, PortForwardingRules, GroupPolicies, Interfaces, FirmwareUpgrades, Devices, AirMarshals, Traffic There is no security/threat-protection node. A search of the full data print for malware, intrusion, threat, ruleset, prevention, and balanced returns no matches. Content filtering is also absent. Requested data Two read-only Dashboard API calls, both already within the scope of the API key the inspector uses today: GET /networks/{networkId}/appliance/security/malware json { "mode": "enabled", "allowedUrls": [ { "url": " example.org ", "comment": "..." } ], "allowedFiles": [ { "sha256": "...", "comment": "..." } ] } mode is enabled or disabled. GET /networks/{networkId}/appliance/security/intrusion json { "mode": "prevention", "idsRulesets": "balanced", "protectedNetworks": { "useDefault": false, "includedCidr": [ "10.0.0.0/8" ], "excludedCidr": [ "10.0.100.0/24" ] } } mode is disabled, detection, or prevention. idsRulesets is connectivity, balanced, or security. Suggested data print placement Nesting under the existing network object keeps it consistent with how VPNs, NAT, and QOS are already structured: Configuration.Networks[].Security.Malware.Mode Configuration.Networks[].Security.Malware.AllowedUrls[] Configuration.Networks[].Security.Malware.AllowedFiles[] Configuration.Networks[].Security.Intrusion.Mode Configuration.Networks[].Security.Intrusion.IdsRulesets Configuration.Networks[].Security.Intrusion.ProtectedNetworks Rolled-up org-level summary fields, in the style of the existing Firewall.Count and Users.Privileged.Count fields, would also be useful for at-a-glance metrics: Configuration.Security .AMPDisabled.Count Configuration.Security .IDSDisabled.Count Configuration.Security .IDSDetectionOnly.Count Implementation notes Both endpoints are MX-only. Calling them against a switch-only or wireless-only network returns an error, so the collection should be gated on productTypes containing appliance. In our environments that reduces the call volume substantially — most organizations have far fewer appliance networks than total networks. These are per-network calls, so the added cost is 2 × (appliance network count) per inspection. For a typical SMB organization of 1–5 appliance networks that is 2–10 additional requests. Both are GET only. No additional API scope or permission level is required beyond what the inspector already holds. If per-network call volume is a concern for very large organizations, collecting these behind an optional inspector toggle (similar to how per-device licensing data is handled) would still be far better than no coverage. Why this matters Security control drift is exactly the problem Liongard solves. AMP and IDS/IPS are licensed features customers pay for through Advanced Security. When a technician sets IDS to Detection while troubleshooting a false positive and never sets it back, or disables AMP to test a download, nothing in the dashboard flags it. The MX keeps passing traffic and the dashboard keeps looking healthy. As an MSP we have no way to detect that today short of manually opening every customer's Threat protection page. Detection-only mode is a silent failure. An MX with IDS set to Detection still generates security events, so the security center looks populated and active — while nothing is being blocked. This is arguably worse than fully disabled, because it looks fine. A metric that distinguishes prevention from detection would surface it immediately. Compliance and cyber insurance evidence. We are increasingly asked to attest that IPS and malware protection are enabled at the perimeter across a customer's sites. Right now that attestation is a manual screenshot exercise. With this data in the data print it becomes a standing metric with historical change evidence attached. Ruleset downgrades go unnoticed. Moving idsRulesets from Security or Balanced down to Connectivity materially weakens inspection and is a one-click change. What we would build with it Once the fields exist, this becomes a single metric and a single alert per customer: Metric — Meraki Networks With Threat Protection Off (Number): jmespath length(Configuration.Networks[?contains(productTypes, 'appliance') && (Security.Malware.Mode != 'enabled' || Security.Intrusion.Mode != 'prevention')][]) Metric — Meraki Threat Protection Offenders (String): jmespath Configuration.Networks[?contains(productTypes, 'appliance') && (Security.Malware.Mode != 'enabled' || Security.Intrusion.Mode != 'prevention')].name | join(', ', @) Alert: Number Greater Than 0, evaluated on change, with the offender list in the notification body. Secondary request If the security data node is being added anyway, content filtering (GET /networks/{networkId}/appliance/contentFiltering) has the same gap and the same justification — blocked URL categories and allow/block lists are also absent from the current data print.
