Agent skills for the firewall work you actually do — parsing, auditing, converting, running Juniper SRX, and deploying Security Director On-Prem and ClearPass — not vibe configuring.

Firewall work is unforgiving. A confidently wrong access-list line, a Junos stanza that won't commit, a compliance claim you can't back up in an audit — these aren't cosmetic. Coding agents are astonishingly good at producing plausible firewall config and astonishingly bad at knowing when it's wrong.

These skills exist to close that gap. They pin the agent to vendor syntax that's been checked against real devices, to one shared schema so four vendors speak the same language, and to control-to-evidence maps that don't overpromise. They're small, self-contained, and composable — copy the two you need or all 26. Hack around with them. Make them your own.

Unofficial / community project. Not affiliated with, endorsed by, or supported by Cisco, Fortinet, Palo Alto Networks, Juniper Networks, or HPE. See License and Provenance for the full notice and the trademark disclaimer.

Quickstart (30-second setup)

  1. Run the installer and pick what you want:
curl -fsSL https://raw.githubusercontent.com/fastrevmd-lab/fwskillsshare/main/install.sh | bash

  1. Choose your skills (space/numbers to toggle, a for all) and where to install them — Claude Code (~/.claude/skills/), Codex (~/.agents/skills/), Hermes, or all three.

  2. Restart the selected agent only if it does not detect the new skills automatically.

  3. Done. Paste a config or name a vendor and the right skill loads itself.

Prefer flags, or installing from a clone? See Installation.

Why These Skills Exist

I built these to fix the failure modes I kept hitting when I let Claude Code, Codex, and other agents touch firewalls.

#1: The Agent Invents CLI That Won't Commit

"It Has To Work."

Ross Callon, RFC 1925 — The Twelve Networking Truths, truth (1)

The Problem. Ask an agent for an SRX ADVPN config or a Junos 24.4R1 IKE gateway and you'll get something that reads perfectly and then throws a commit error — or worse, commits and silently doesn't forward. The model has seen a decade of blog posts, including the wrong ones and the ones for the wrong release.

The Fix is playbooks pinned to syntax that's been proven on real hardware. The SRX skills carry the gotchas that only show up in production: the Junos 24.4R1+ IKEv2 with authentication-method pre-shared-key is not allowed commit error, the Remote-ip 0.0.0.0/0 in traffic-selector is not supported split, the ADVPN No public key found IKE_AUTH failure root-caused to the dynamic cert-gateway responder path. Disputed syntax was settled by commit-checking on a live vSRX 24.4R1, not by vibes.

Reach for srx-policy, srx-nat, srx-mnha, srx-advpn and friends whenever you're designing or debugging real Junos.

#2: Every Vendor Speaks A Different Dialect

"All problems in computer science can be solved by another level of indirection."

David Wheeler

The Problem. A Cisco ACL, a FortiGate policy block, a PAN-OS <entry>, and an SRX set security line all express the same idea four incompatible ways. Ask an agent to compare or convert them and it hand-waves the parts that don't line up.

The Fix is a shared language. The four parsing-* skills normalize every vendor into one vendor-neutral intermediate JSON schema — zones, objects, policies, NAT, routing, VPN, HA, the lot — with a 240+ entry canonical L7 application map and confidence scores. Once a config is in the schema, cross-vendor audit, conversion, and diff all operate by meaning, not text. Features with no equivalent are flagged, never silently dropped.

This is the piece that makes the rest composable. See the Intermediate Schema below.

#3: "Is It Compliant?" Gets A Confident, Unfounded Yes

"Trust, but verify."

Russian proverb

The Problem. Point an agent at a firewall and ask if it's "PCI compliant" and it will happily tell you yes. That answer is worthless to a QSA, and dangerous to you. A firewall supports evidence for a control; it is never itself "certified."

The Fix is seven compliance and STIG playbooks (PCI, HIPAA, CMMC / NIST 800-171, CIS, ISO 27001, SOC 2, and SRX DISA STIG) that map firewall capabilities to specific control evidence, produce assessor-ready findings and gap lists, and are explicit at every turn that compliance is assessed for the environment and program, not conferred by the box. They tell you what evidence to collect and where the gaps are — the honest version of the answer.

#4: Rulebases Rot, And Agents Accelerate The Rot

"Complexity is the worst enemy of security."

Bruce Schneier

The Problem. Every rulebase drifts toward any-any, shadowed rules, orphaned objects, and plaintext management. Agents make firewall changes faster, which means they make the rot faster too, unless something keeps them honest.

The Fix is firewall-best-practices-audit — overly permissive and shadowed/redundant rules, missing deny-all and logging, exposed telnet/http/SNMPv1-2c, weak IKE/IPsec crypto, device-plane hardening, unused objects — and firewall-config-diff for drift and HA-pair parity. Prioritized findings with severity and confidence, vendor-neutral plus source-vendor remediation. Run them before you ship a change, not after the incident.

Summary

Firewall fundamentals don't get easier in the AI age — the blast radius just gets bigger. These skills are my attempt to hand the agent the discipline: verified syntax, a shared schema, honest compliance mapping, and a hygiene checklist. Use them, break them, and make them yours.

Reference

26 skills across five families. All of them are model-invoked — the agent reaches for them automatically when it sees vendor keywords, an SRX operational topic, a Security Director On-Prem or ClearPass deployment request, or compliance language in your message or a pasted config. 25 of the 26 packages have completed the review record below; clearpass-proxmox-deploy is a draft. Invoke one explicitly as /srx-nat in Claude Code or Hermes, or $srx-nat in Codex.

Config parsers

Normalize a vendor config into the shared intermediate schema. Everything else composes on top.

  • parsing-cisco-configs — Cisco ASA & FTD (show running-config): access-lists, object/object-group, NAT, failover, port-to-app inference.
  • parsing-fortinet-configs — FortiGate / FortiOS (show full-configuration): the config/edit/set block format, VDOMs, UTM profiles, compound IPsec proposals.
  • parsing-palo-configs — Palo Alto PAN-OS & Panorama: XML or flat set-format, vsys, app-default decomposition, device-groups.
  • parsing-srx-configs — Juniper SRX / Junos: display set or curly-brace, address-book migration to global, junos-* app mapping, routing-instances.

SRX operational playbooks

Actionable Junos playbooks — commands, design guidance, verification, troubleshooting matrices, source attribution.

  • srx-policy — Enforced global-policy output with explicit zone-pair opt-outs on 23.x+, AppID/AppFW, NGWF-first web filtering, SecIntel, ATP, hit-count troubleshooting.
  • srx-nat — Source/destination/static NAT, NAT64/DNS64, CGN/PBA, persistent NAT, hairpin, proxy-ARP, session verification.
  • srx-mnha — Multi-Node High Availability: routed/default-gateway/hybrid modes, SRGs, ICL/ICD, eBGP/BFD failover, VIPs, DHCP caveats.
  • srx-advpn — Auto Discovery VPN dynamic spoke-to-spoke shortcuts, suggester/partner roles, multipoint st0, OSPF p2mp, the cert-auth requirement and the No public key found fix.
  • srx-autovpn-full-tunnel — AutoVPN hub-and-spoke full-tunnel backhaul: dynamic group-ike-id, traffic selectors + ARI, shared st0.0, anti-recursion route.
  • srx-ipsec-hub-spoke — Static point-to-point route-based IPsec hub-and-spoke, one explicit tunnel per spoke, hub source-NAT egress, spoke-to-spoke hairpin.
  • srx-chassis-cluster-proxmox — Chassis cluster whose nodes are Proxmox VE guests: control/fabric bridge and VLAN design, the fabric-jumbo vs control-1500 MTU split, virtual NIC to Junos interface mapping, the reth virtual-MAC anti-spoof trap, cluster bootstrap and validation.
  • srx-mpls-in-flow — MPLS L3VPN in flow mode (secure PE/CPE): decoupled family mpls packet-based with inet/inet6 flow-mode, VRF-aware policy/NAT/AppID.
  • srx-dynamic-ip-feed — Dynamic IP objects from HTTPS feed servers: .tgz bundles, cert validation, basic-auth / mTLS, ipfd log interpretation.
  • srx-license-signature-maintenance — AppID and IDP/IPS entitlement audit, license installation, and offline signature updates behind two independent approval gates, with secret-safe license handling, per-node chassis-cluster verification, pilot-then-batch rollout, and condition-based polling.

Cross-vendor tooling

Vendor-neutral, driven off the parsed schema.

  • firewall-best-practices-audit — Rulebase hygiene independent of any framework: any-any, shadowed/orphaned rules, missing deny/logging, exposed plaintext services, weak crypto, device-plane hardening.
  • firewall-config-conversion — Migrate between Cisco/FortiGate/Palo/SRX with a per-section fidelity report (converted / caveats / manual). A reviewed draft, never production-ready.
  • firewall-config-diff — Compare two configs by meaning (order- and name-insensitive) — same-vendor drift & HA parity, or cross-vendor migration validation.

NGFW compliance playbooks

Map firewall capability to control evidence — assessor/auditor output templates, description/tag markers, honest scoping.

  • pci-ngfw-compliance — PCI DSS v4.0.1: CDE segmentation, Requirement 1 network security controls, six-month rule review, QSA/ROC/SAQ evidence.
  • hipaa-ngfw-compliance — HIPAA Security Rule (45 CFR 164.312): ePHI segmentation, access/audit controls, transmission security, BAA considerations.
  • cmmc-nist-800-171-ngfw-compliance — CMMC Level 2 / NIST SP 800-171: CUI enclave scoping, boundary protection, SSP boundary language, POA&M-style gaps.
  • cis-controls-ngfw-compliance — CIS Controls v8/v8.1: secure configuration, network infrastructure management, IG1/IG2/IG3 safeguards, audit evidence.
  • iso27001-ngfw-compliance — ISO/IEC 27001:2022 ISMS & Annex A (A.8.20–A.8.23), Statement of Applicability support, supplier access, corrective actions.
  • soc2-ngfw-compliance — SOC 2 Trust Services Criteria (CC6/CC7/CC8), Type I/II examinations, operating-effectiveness samples.
  • srx-disa-stig-compliance — Source-pinned DISA Y25M01 SRX NDM/ALG/IDPS/VPN rule assessment, CAT status, evidence gaps, and Junos compatibility review.

Security management and NAC deployment

Install with --family deployment.

  • clearpass-proxmox-deploy — (v0.2.0, draft) Deploy, validate, and bring into service HPE Aruba ClearPass Policy Manager 6.14 as a Proxmox VE KVM guest, including CLABV/C1000V/C2000V/C3000V sizing, the mandatory UEFI firmware and pre-boot second disk, MAC-ordered management interface mapping, CRC-verified streaming of the 45 GiB raw image, driving the VGA-only first-boot wizard through the QEMU monitor, and day-2 operations — licence order and artifact formats, HTTPS certificate import via the Trust List, and the REST API's retrievable-token/unretrievable-secret split.
  • sd-onprem-proxmox-deploy — Plan, deploy, validate, and troubleshoot Juniper Security Director On-Prem 25/26 as a Proxmox VE guest from the vendor KVM artifacts, including sizing, four-IP planning, first-boot seed configuration, NTP/DNS reachability, SRX onboarding behind a device-clock NTP sync gate, and mandatory source-identical routing, bundle, device-channel, and TLS log-path proof before VM creation.

Quality and Review

25 of the 26 skills have passed independent technical review; the exception is clearpass-proxmox-deploy, which ships as a draft and is described at the end of this section. The original 21 were first reviewed on 2026-06-30, then re-reviewed on 2026-07-02 with a two-stage process: an OpenAI Codex CLI review per skill (vendor command/syntax correctness for Cisco ASA/FTD, FortiGate, PAN-OS, and Junos SRX; schema/field accuracy; standards/control-ID accuracy; secret hygiene) followed by per-skill application QA tests (fixture execution for the parsers, engineer-walkthrough scenarios for the playbooks, control-ID spot-checks for the compliance skills). Disputed Junos syntax claims were settled empirically by commit-checking on a live vSRX 24.4R1. All findings were remediated and the four parsing-* skills share one byte-identical intermediate schema (verified by scripts/check-shared-schema.py).

A third round on 2026-07-04/05 applied an authoring-quality pass across those original 21 skills (frontmatter, discovery keywords, secret redaction, cross-skill hand-offs, progressive disclosure into references/ files), then closed it out with fresh clean-context retrieval tests against the restructured skills — every question had to be answerable from the SKILL.md pointers alone. The tests passed and surfaced a handful of fixes (including two operational-command syntax errors caught and corrected by live verification on vSRX 24.4R1), all remediated.

The 25th skill, srx-chassis-cluster-proxmox, was validated on 2026-08-11 by a different method: instead of a document review, it was executed. A second chassis cluster was built from a factory template on a separate host by following the skill's own procedure, on a different Junos release (26.2R1.7) than the reference build (24.4R1.9). The run confirmed the skill's NIC-mapping rule and reth MAC formula on both releases, and falsified its fabric-MTU claim — forcing the fabric segment to 1500 broke nothing observable, which established that the fault is latent rather than immediate. That correction and two others were folded in before release. The throwaway cluster was destroyed afterwards.

Family Skills Reviewed
Config parsers 4 4 / 4
SRX operational playbooks 10 10 / 10
NGFW compliance and STIG playbooks 7 7 / 7
Cross-vendor tooling (audit · convert · diff) 3 3 / 3
Security management and NAC deployment 2 1 / 2
Total 26 25 / 26

The later srx-disa-stig-compliance addition completed an independent review on 2026-07-22. That review verified the NIST checklist 657 / DISA Y25M01 artifact, all 148 source-ordered NDM/ALG/IDPS/VPN rule identities and CAT severities, conservative status/evidence behavior, Junos schema paths and source conflicts, installer integration, and synthetic behavior/mutation fixtures. All findings were remediated and re-reviewed cleanly.

sd-onprem-proxmox-deploy was added later and was not part of the 2026-06-30, 2026-07-02, or 2026-07-04/05 review rounds. It passed the repository's portable-package and runtime-intake validation, and was promoted to v1.0.0 on 2026-08-05 after the maintainer ran the full deployment to completion three separate times — the repeat runs its draft label was waiting on. Its device-onboarding NTP gate was verified read-only against production SRXs on Junos 26.2R1: the hidden set system processes ntp enable was confirmed valid and present, and the pass/fail criterion was moved onto show ntp associations after live output showed sync_ntp appearing alongside no_sys_peer (so it cannot mean "synced") while a device missing clock_sync was in fact synchronized with a selected peer at full reach (so its absence cannot mean "failed").

On 2026-07-31 firewall-best-practices-audit and parsing-srx-configs were re-validated against live SRX devices over NETCONF (read-only), covering a policy-light standalone vSRX and a 101-policy two-node chassis cluster. The run is documented in the live SRX audit and found two real defects, both since fixed: security dynamic-address objects were not extracted (producing false SEC-ORPHAN-REF on every GeoIP or feed-backed reference), and match dynamic-application was dropped (collapsing distinct AppID-scoped rules into false SEC-REDUNDANT pairs, and letting an AppID-scoped deny pass as a terminal deny-all so SEC-NO-DENY-ALL stayed silent). parsing-srx-configs v1.4.0 and firewall-best-practices-audit v1.2.0 carry the fixes; both behaviors are pinned by regressions in scripts/check-audit-rule-contract.py. Two catalog gaps found in the same run — no check for a rule name contradicting its configured action, and none for plaintext threat-feed transport — remain open.

srx-license-signature-maintenance was added on 2026-07-31 and promoted to v1.0.0 on 2026-08-05. It passed portable-package, runtime-intake, installer, and its own behavioral contract validation (scripts/check-srx-license-signature-contract.py), a five-reviewer independent pass, and a read-only fleet audit across 9 devices / 10 node records on Junos 24.4R1.9, 25.4R1.12, and 26.2R1.7 — documented here.

That live run earned its keep. On a two-node cluster it caught the nodes disagreeing — AppID package installed on the secondary, absent on the primary — while IDP matched on both; the cluster-level read, a primary-only read, and an IDP-only read would each have missed it. It also corrected four documentation defects: show system license accepts no node argument (every per-node form is a syntax error, while the IDP and AppID version commands do take node 0 / node 1); IDP and AppID use different version-qualifier formats; Application package version: 0 means not-installed rather than a version mismatch; and a used counter of 1 does not imply an active IDP policy.

The mutating paths (request system license add, security-package install) remain unexercised against hardware — running them needs a real entitlement file or signature bundle and changes device state — so that boundary is stated plainly in the skill-test record. Its contract validator is offline by construction — it asserts that the two approval gates stay independent, that unsafe license sources are refused, that polling only ends on a terminal state, that cluster aggregates never substitute for per-node evidence, that version qualifiers survive comparison, and that a package install with no active IDP policy is never reported as active enforcement. Each of those assertions was mutation-checked.

clearpass-proxmox-deploy was added on 2026-08-13 and is the one skill here that has not been through any independent review round. It ships at v0.2.0 (draft): the deploy procedure was executed end-to-end once, on ClearPass 6.14.0.371380 as a C1000V on Proxmox VE 9.2, and the day-2 reference (licensing, HTTPS certificate import, REST API) was confirmed against that same appliance on 2026-08-15/16. Every claim in its Gotchas is either from those runs or explicitly marked [unverified]. It passed the repository's portable-package and runtime-intake validation.

Its central finding is that the ClearPass 6.14 KVM image only boots under UEFI — undocumented by the vendor, and silent when violated: the appliance reaches its GRUB menu and fails every boot attempt, which presents as an unresponsive keyboard rather than a boot failure. That was confirmed two independent ways: the on-screen GRUB error (can't find command `linuxefi'), and the image's own /boot/grub2/i386-pc/command.lst, which registers linux/linux16 and no linuxefi at all. The vendor guide's competing IDE disk-bus instruction is recorded as unverified rather than disproven — virtio-scsi was verified working; IDE was not tested. The skill needs a repeat run, and ideally one non-C1000V flavor, before it earns a stable label.

These are research/operational and assessment-support skills, not certified products: review their output against current vendor documentation, live device behavior, and (for compliance work) a qualified assessor before relying on it.

Each skill also includes optional agents/openai.yaml UI metadata for Codex. Claude Code and Hermes continue to use the portable SKILL.md content and ignore that product-specific folder.

Run python3 scripts/check-skill-packages.py to validate portable frontmatter, reference paths, the combined Codex discovery budget, and all Codex UI metadata. Run python3 scripts/check-shared-schema.py to verify the four parser schemas remain byte-identical.

Installation

Installer (recommended)

The install.sh installer runs interactively when piped from curl, or with flags for scripted/non-interactive use:

# Interactive: pick skills + target
curl -fsSL https://raw.githubusercontent.com/fastrevmd-lab/fwskillsshare/main/install.sh | bash

# Or from a clone
git clone [email protected]:fastrevmd-lab/fwskillsshare.git
cd fwskillsshare
./install.sh

Flags:

--all                 Install all 24 skills
--skill NAME          Install a specific skill (repeatable)
--family NAME         parsers | srx | tooling | compliance | deployment (repeatable)
--target WHERE        claude | codex | hermes | both | all
                      (`both` keeps the legacy Claude+Hermes meaning; default: prompt, or claude with -y)
--dir PATH            Explicit install directory (overrides --target)
--list                List the skill inventory and exit
--uninstall           Remove the selected skills instead of installing
--force               Overwrite existing skill directories without prompting
-y, --yes             Non-interactive; assume defaults
-h, --help            Show help

Examples:

./install.sh --all --target claude              # everything, into ~/.claude/skills
./install.sh --all --target codex               # everything, into ~/.agents/skills
./install.sh --family parsers --family srx      # just the parsers + SRX playbooks
./install.sh --family tooling --target all      # tooling skills into all three agents
./install.sh --family deployment --target codex # Security Director On-Prem deployment skill
./install.sh --skill sd-onprem-proxmox-deploy --target claude -y
./install.sh --skill parsing-srx-configs --skill srx-nat -y
./install.sh --list                             # see what's available

Manual install

The skills are plain directories — copy the ones you want:

git clone [email protected]:fastrevmd-lab/fwskillsshare.git

# All of them
cp -r fwskillsshare/skills/* ~/.claude/skills/

# Or a single skill
cp -r fwskillsshare/skills/srx-mnha ~/.claude/skills/

# Security Director On-Prem deployment skill
cp -r fwskillsshare/skills/sd-onprem-proxmox-deploy ~/.claude/skills/

For Codex, copy into the user skill tree. Codex normally detects changes automatically; restart it if a new skill does not appear:

mkdir -p ~/.agents/skills
cp -r fwskillsshare/skills/* ~/.agents/skills/

For Hermes, copy into your local Hermes skills tree (usually ~/.hermes/skills/devops/) and confirm with hermes skills list:

mkdir -p ~/.hermes/skills/devops
cp -r fwskillsshare/skills/* ~/.hermes/skills/devops/
hermes skills list | grep -E 'parsing-|srx-|firewall-|-ngfw-compliance|sd-onprem-'

Skills auto-trigger when they detect vendor-specific keywords, SRX operational topics, Security Director On-Prem or Proxmox deployment requests, or PCI/HIPAA/CMMC/NIST 800-171/CIS/ISO 27001/SOC 2/DISA STIG compliance language in your messages or pasted configs.

Managing context

Skill bodies only load when a skill is invoked, but each skill's short description stays in context so the agent knows when to reach for it. If you rarely use certain skills (e.g. compliance frameworks you don't work with), you can drop just their descriptions from context while keeping them invocable, via skillOverrides in ~/.claude/settings.json:

{ "skillOverrides": { "soc2-ngfw-compliance": "name-only" } }

"name-only" keeps the skill listed and invocable but hides its description; "user-invocable-only" hides it from the model entirely (slash-command only); "off" hides it completely.

For Codex, disable an installed skill without deleting it by adding its SKILL.md path to ~/.codex/config.toml:

[[skills.config]]
path = "/home/you/.agents/skills/soc2-ngfw-compliance/SKILL.md"
enabled = false

Usage

What you can do

  • Parse — Extract all objects, policies, NAT rules, and routes into structured JSON
  • Audit — Find unused objects, shadowed rules, overly permissive policies, missing logging
  • Convert — Transform configs between vendors (e.g., SRX to PAN-OS)
  • Compare — Diff two configs by meaning, not text
  • Summarize — Get a high-level overview of zones, policy counts, and security profiles
  • Operate SRX dynamic feeds — Configure, validate, and troubleshoot SRX dynamic-address feed servers
  • Design SRX MPLS in flow mode — Keep inet/inet6 in stateful flow mode for policy, NAT, and AppID while family mpls is packet-based
  • Design SRX MNHA — Reason about MNHA modes, SRGs, ICL/ICD, eBGP/BFD failover, VIPs, and DHCP caveats
  • Operate SRX NAT — Source/destination/static NAT, NAT64/DNS64, CGN/PBA, persistent NAT, hairpin, proxy ARP
  • Design SRX security policy — Enforce security policies global for generated greenfield, migration, and onboarding output absent an explicit opt-out; then layer AppID/AppFW, NGWF-first web filtering, SecIntel, ATP
  • Deploy Security Director On-Prem — Plan the Proxmox VE guest, vendor artifact extraction, four same-subnet IPs, first-boot settings, and SRX onboarding gated on proven device NTP sync
  • Assess compliance evidence — Map NGFW policies, NAT, zones, logging, IDS/IPS, and segmentation to PCI / HIPAA / CMMC-NIST 800-171 / CIS / ISO 27001 / SOC 2 / SRX DISA STIG evidence expectations

Examples

# Parse and audit
"Here's my ASA config, parse it and show me security issues:"
[paste running-config]

# Convert between vendors
"Convert this SRX config to Palo Alto format"
[paste SRX config]

# Summarize
"Summarize this FortiGate config — how many policies, what zones, any UTM profiles?"
[paste config]

# Read from file
"Read /path/to/running-config.txt and audit it"

# SRX dynamic IP feed server
"Help me configure an SRX dynamic-address feed-server with HTTPS certificate validation and show me the verification commands"

# SRX MPLS in Flow
"Review this SRX MPLS L3VPN config and verify that family mpls is packet-based while inet traffic remains flow-based with VRF-aware policies"

# SRX MNHA design/troubleshooting
"Review this SRX MNHA hybrid eBGP design and tell me what to verify before failover testing"

# SRX NAT troubleshooting
"Help me troubleshoot this SRX destination NAT rule: hits increment, but the policy denies the translated web server session"

# SRX global policy migration
"Convert this vendor rulebase into an SRX 23.x global security policy design with AppFW, NGWF-first web filtering, SecIntel, logging, and a final deny"

# Security Director On-Prem on Proxmox
"Plan a fresh Security Director On-Prem deployment on Proxmox VE, including artifact extraction, VM sizing, the four required IPs, and first-boot NTP/DNS checks"

# Compliance review (any of the seven compliance/STIG playbooks)
"Review this firewall export for PCI DSS CDE segmentation evidence and recommend policy/NAT/zone description markers"
"Review this NGFW design for HIPAA Security Rule ePHI access control, audit logging, and transmission security"
"Review this firewall estate against CIS Controls v8 for secure configuration, logging, and vendor access"

Tips

  • Paste the full config — partial configs may produce unresolved reference warnings
  • Use the appropriate show command output for each vendor:
    • Cisco ASA: show running-config
    • FortiGate: show full-configuration
    • PAN-OS: XML config export or show config flat (set-format)
    • SRX: show configuration | display set or show configuration
    • SRX dynamic feeds: show security dynamic-address summary, show security dynamic-address, show log messages | match ipfd
    • SRX MPLS in Flow: show security flow status, show route table bgp.l3vpn.0, show route table <vrf>.inet.0, show ldp neighbor, show mpls interface, show security flow session extensive, show security policies hit-count
    • SRX MNHA: show chassis high-availability information, show chassis high-availability services-redundancy-group <id>, show security flow session, show bgp summary, show bfd session
    • SRX NAT: show security nat source/destination/static rule all, show security nat source pool all, show security nat proxy-arp, show security flow session ... extensive
    • SRX security policy: show configuration security policies global | display set, show security policies hit-count, show security application-firewall rule-set <name>, show security utm web-filtering status/statistics
    • Compliance reviews: collect the firewall policy/NAT/zone/VPN/object exports plus the framework-specific evidence (CDE/ePHI/CUI/ISMS-scope diagrams, rule-review records, logging/SIEM evidence, change tickets, segmentation/pen-test results) — each compliance skill lists exactly what it needs
  • For large configs, save to a file and point Claude at the file path
  • Each parsing-* skill includes references/fixture-minimal-input.md and references/fixture-expected-output.json as a smoke-test fixture for parser behavior and schema shape

Conversion Caveats

  • Application-level rules (Palo Alto apps, FortiGate app control) don't map 1:1 to port-based platforms (ASA)
  • User-ID / FSSO source-user rules have no equivalent on most platforms
  • Dynamic address groups (PAN-OS) have no static equivalent
  • Geography/GeoIP objects have limited cross-platform support

Intermediate Schema

The four parsing-* skills output to a common schema with these sections:

Section Contents
zones Security zones and their interfaces
address_objects Hosts, subnets, FQDNs, ranges, and dynamic objects (GeoIP, threat feeds, tag selectors) whose membership resolves at runtime
address_groups Groups of address objects
service_objects Service/port definitions
service_groups Groups of service objects
security_policies Firewall rules with resolved apps, services, profiles, and dynamic_applications (runtime App-ID matches)
applications Resolved L7 apps with canonical names and confidence scores
application_groups Groups of L7 applications (canonical keys)
nat_rules NAT translations (source, dest, static)
static_routes Routing table entries
virtual_routers Routing namespace / VRF separation
ospf_config OSPF areas, interfaces, redistribution
bgp_config BGP neighbors, networks, redistribution
ha_config High availability / failover
vpn_tunnels Route-based IPsec VPN with IKE/IPsec detail
interfaces Physical/logical interfaces with IPs, IPv6, LAG
admin_users Users with roles and SSH keys
system Hostname, DNS, NTP, management services
dhcp_config DHCP server pools and relay
residual_raw Unparsed config sections for manual review
metadata Source vendor, version, parse timestamp, warnings

Shared schema maintenance

The intermediate-schema.md file is intentionally duplicated in each parsing-* skill so every skill stays self-contained when copied alone. Treat skills/parsing-srx-configs/references/intermediate-schema.md as the canonical editing copy, sync the same content to the other parser skills, then run:

python3 scripts/check-shared-schema.py

See skills/SHARED-SCHEMA.md for the full policy.

Compliance Skills (detail)

pci-ngfw-compliance

pci-ngfw-compliance is a PCI DSS v4.0.1 NGFW/firewall assessment playbook. It explains that an NGFW can support PCI DSS network security control evidence, but the device is not independently "PCI compliant."

Use it for:

  • mapping firewall policy, NAT, zones, IDS/IPS, WAF/WAAP, logging, and segmentation controls to PCI DSS evidence expectations
  • reviewing CDE inbound/outbound restrictions, default deny, payment processor paths, and public-facing service exposure
  • preparing assessor-ready evidence requests, findings, and gap-analysis summaries
  • adding short PCI evidence markers to firewall descriptions/tags for policies, NAT, zones, objects, and profiles where supported

hipaa-ngfw-compliance

hipaa-ngfw-compliance is a HIPAA Security Rule NGFW/firewall assessment playbook. It explains that an NGFW can support reasonable and appropriate safeguards for ePHI, but HIPAA compliance is assessed at the covered entity or business associate program/environment level.

Use it for:

  • mapping firewall policy, NAT, VPN, zones, IDS/IPS, WAF/WAAP, logging, and segmentation controls to HIPAA Security Rule safeguards
  • reviewing ePHI access control, audit controls, person/entity authentication, transmission security, incident response, documentation, and business associate/vendor access evidence
  • preparing compliance-ready evidence requests, findings, and risk-treatment recommendations
  • adding short HIPAA evidence markers to firewall descriptions/tags where supported

cmmc-nist-800-171-ngfw-compliance

cmmc-nist-800-171-ngfw-compliance is a CMMC Level 2 / NIST SP 800-171 NGFW/firewall assessment playbook. It explains that an NGFW can support CUI protection requirements, but CMMC/NIST 800-171 compliance is assessed at the contractor environment and CUI protection program level, not by certifying the firewall product alone.

Use it for:

  • mapping firewall policy, NAT, VPN, zones, IDS/IPS, logging, segmentation, and remote-access controls to NIST 800-171 / CMMC evidence expectations
  • reviewing CUI enclave scope, CUI data flows, boundary protection, external connections, public-system separation, audit controls, and system security plan evidence
  • preparing assessor-ready evidence requests, findings, POA&M-style gaps, and remediation recommendations
  • adding short CMMC/CUI evidence markers to firewall descriptions/tags where supported

cis-controls-ngfw-compliance

cis-controls-ngfw-compliance is a CIS Critical Security Controls v8/v8.1 NGFW/fire