srx-disa-stig-compliance

Assess Juniper SRX evidence against the pinned DISA Y25M01 STIG and produce rule-level findings.

9|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/fastrevmd-lab/fwskillsshare --skill srx-disa-stig-compliance-fastrevmd-lab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: srx-disa-stig-compliance
Source: https://github.com/fastrevmd-lab/fwskillsshare/tree/main/skills/srx-disa-stig-compliance
Command: npx skills add https://github.com/fastrevmd-lab/fwskillsshare --skill srx-disa-stig-compliance-fastrevmd-lab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Firewall compliance reviews against DISA STIGs are error-prone: agents and engineers mix benchmark releases, overstate findings from incomplete evidence, or claim compliance they cannot defend in an audit. This Skill pins the assessment to the verified DISA Y25M01 SRX benchmark and enforces conservative, evidence-based rule statuses. ## Core Features & Use Cases - Source-pinned rule catalogs: Evaluates 148 rules across NDM, ALG, IDPS, and VPN components with preserved V-ID, SV-ID, JUSX identifiers, and CAT severities, failing closed if the checksum does not match. - Four-class evidence model: Classifies normalized config, raw config, operational output, and manual evidence separately, defaulting to Not Reviewed when proof is incomplete. - Junos compatibility tracking: Separates formal STIG status from current Junos support, flagging legacy or contradictory benchmark guidance for verification before remediation. - Use Case: Given a redacted SRX configuration export and operational command output, produce an assessor-ready report with per-rule status, evidence gaps, and remediation candidates routed to the appropriate SRX configuration skills. ## Quick Start Use the srx-disa-stig-compliance skill to assess this parsed SRX configuration and show version output against the DISA Y25M01 STIG and list all Open and Not Reviewed rules.

Frequently Asked Questions about srx-disa-stig-compliance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I assess a Juniper SRX against the DISA STIG?

Parse the raw SRX configuration first, then supply it with operational evidence such as show version and license output. The skill selects NDM and ALG profiles plus IDPS or VPN based on device roles, then assigns a conservative status per rule with evidence citations.

What STIG release does this SRX assessment use?

It is pinned to DISA Y25M01, NIST NCP checklist 657, verified by SHA-256 checksum 9ffd17664efa307503f620434fec16501857196b091ea946f59284572f87690f. If a supplied checklist or CKL has a different release or checksum, the assessment fails closed rather than mixing revisions.

Why are so many rules marked Not Reviewed in my SRX STIG report?

Not Reviewed is the fail-closed default when evidence is missing, partial, stale, or ambiguous. Many rules require operational or manual evidence beyond configuration, such as log samples, license state, or approved flow matrices, so a config-only review cannot close them.

Can this skill remediate or fix STIG findings on the SRX?

No, it is read-only assessment support. It prepares remediation candidates and routes design work to SRX configuration skills, but any device change requires explicit approval, target release validation, a reviewed diff, rollback protection, and post-change verification.

Does a passing STIG report mean my SRX is DISA compliant?

No. The report records evidence alignment with selected Y25M01 rules only and explicitly does not establish device, enclave, or organizational compliance. Final scope, risk acceptance, and authorization decisions belong to the qualified assessor and Authorizing Official.

How are Junos version conflicts with STIG guidance handled?

Formal STIG status follows the pinned benchmark, while current Junos compatibility is tracked as a separate field. Rules with legacy or contradictory guidance, such as SHA-1 deprecation or dynamic-vpn examples, are marked verification_required and checked against current Juniper documentation before any recommendation.