[REVIEW] firewall-review: add cloud implicit-rule and IPv6 evidence

[mlodygbelmondo]

Skill Being Reviewed

Skill name: firewall-review
Skill path: skills/network/firewall-review/

False Positive Analysis

Benign AWS security group that can be over-reported if a traditional explicit deny-all rule is required:

resource "aws_security_group" "api" {
  name   = "api-prod"
  vpc_id = aws_vpc.prod.id

  ingress {
    protocol    = "tcp"
    from_port   = 443
    to_port     = 443
    cidr_blocks = ["203.0.113.0/24"]
  }

  egress {
    protocol    = "tcp"
    from_port   = 443
    to_port     = 443
    cidr_blocks = ["198.51.100.10/32"]
  }
}

Why this can be misleading:

The skill says every rule base must terminate with an explicit deny-all rule and lists absence of explicit default deny as Critical. That is a good model for ordered packet filters such as iptables, pf, Cisco ACLs, and many firewall policies, but AWS security groups are stateful allow lists and do not support explicit deny rules. A restrictive AWS security group can be safe even though it has no terminal deny line. The review should evaluate the platform's implicit behavior instead of applying a traditional first-match rule-base model to every firewall type.

The inverse can also happen in Azure and Google Cloud: a configuration can contain a deny-all default or implied ingress deny while earlier default/implicit rules still allow broad outbound internet or same-VNet traffic. A report that only records "default deny present" can overstate effective restriction.

Coverage Gaps

Missed variant 1: Azure NSG default rules are not evaluated as effective policy

NSG default rules:
  AllowVnetInBound
  AllowAzureLoadBalancerInBound
  DenyAllInBound
  AllowVnetOutBound
  AllowInternetOutBound
  DenyAllOutBound

Naive result:
  outbound default deny exists -> Pass

Effective result:
  internet outbound is allowed by a higher-priority default rule unless explicitly denied

Why it should be caught:

Azure NSGs contain default security rules with priorities. The existence of DenyAllOutBound does not prove outbound default deny if AllowInternetOutBound and AllowVnetOutBound remain effective. The report needs an effective-rule evaluation that includes platform default rules, priority, direction, and association scope.

Missed variant 2: GCP implied egress allow and IPv6 implied rules are not first-class evidence

GCP VPC:
  explicit firewall rules: none
  IPv4 implied ingress: deny 0.0.0.0/0
  IPv4 implied egress: allow 0.0.0.0/0
  IPv6 enabled: yes
  IPv6 implied ingress/egress rules: not reviewed

Why it should be caught:

Google Cloud VPC networks have implied allow egress and deny ingress rules, and IPv6-enabled networks have corresponding IPv6 implied rules. A source review that checks only explicit firewall resources can miss the effective allow-egress posture or fail to review ::/0 paths.

Missed variant 3: IPv4-only findings can miss dual-stack exposure

resource "aws_security_group" "web" {
  ingress {
    protocol    = "tcp"
    from_port   = 443
    to_port     = 443
    cidr_blocks = ["10.0.0.0/8"]
  }

  ingress {
    protocol         = "tcp"
    from_port        = 443
    to_port          = 443
    ipv6_cidr_blocks = ["::/0"]
  }
}

Why it should be caught:

The skill lists ignoring IPv6 as a pitfall, but the output format does not require an IPv4/IPv6 coverage matrix or a dual-stack effective exposure result. A rule can look restricted in IPv4 while permitting global IPv6 access.

Missed variant 4: cloud association scope can make a clean rule set non-enforcing

Reviewed:
  restrictive Azure NSG rules

Missing:
  NSG association to subnet or NIC
  NIC-level NSG that overrides/combines with subnet policy
  effective security rules export
  target resources actually attached to the NSG

Why it should be caught:

Cloud firewall policy is not only rule text. Security groups, NSGs, NACLs, hierarchical policies, and VPC firewall rules apply at different resource scopes. A restrictive rule set that is not associated with the intended resource should not be marked as passing, and a permissive inherited/default policy should not be missed.

Edge Cases

• AWS security groups are stateful allow lists; network ACLs are stateless ordered rules. The report should not apply the same shadowing/default-deny model to both.
• Azure evaluates NSG rules by priority and includes default rules; subnet and NIC associations both matter.
• GCP VPC firewall rules have implied ingress/egress rules and can also be affected by hierarchical firewall policies.
• IPv6 can be enabled later or through managed platform defaults; reports should record whether IPv6 is disabled, unsupported, or reviewed.
• Hit counters and flow logs may be unavailable from IaC alone; unused-rule findings should include counter baseline time or flow-log evidence.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add platform-specific effective-policy evidence for AWS security groups/NACLs, Azure NSGs, and GCP VPC firewalls. Require implicit/default rules, priority/order, association scope, IPv4/IPv6 coverage, stateful/stateless semantics, and source-only confidence before marking default-deny, egress, shadowing, or exposure findings as pass/fail.

Comparison to Other Tools

Tool / Framework	Catches this?	Notes
AWS security group review	Partial	Shows allow-list egress/ingress and stateful behavior, but no explicit deny rules exist.
Azure effective security rules	Yes	Captures default rules, priority, subnet/NIC association, and effective allow/deny state.
GCP firewall policy review	Partial	Shows implied and hierarchical firewall behavior when the reviewer includes network-level and policy-level evidence.
Traditional firewall rule analyzers	Partial	Good for ordered rule bases and shadowing, but can mis-score cloud-native stateful/implicit models.
Flow logs / hit counters	Partial	Helps validate unused and effective traffic, but needs baseline timestamp and scope.

Overall Assessment

Strengths:

• Strong traditional firewall audit workflow for default deny, any/any rules, shadowing, logging, egress filtering, and stale rules.
• Good NIST SP 800-41 and CIS Controls v8 framing.
• Useful pitfalls for cloud security groups, IPv6, hit counters, and AWS NACL versus security group differences.

Needs improvement:

• The output format should require platform-specific effective-policy evidence, not only rule text.
• Default-deny checks should distinguish explicit terminal deny, implicit deny, implied allow, and unsupported deny semantics.
• Cloud rule evaluation should include default/implicit rules, inherited or hierarchical policies, priority/order, and resource association scope.
• IPv4 and IPv6 exposure should be reported separately.
• Source-only reviews should use Not Evaluable or lower confidence for unused-rule, hit-count, and effective-policy conclusions.

Priority recommendations:

1. Add a Platform Effective Policy section with platform, firewall type, stateful/stateless, ordered?, explicit deny supported?, implicit/default rules, resource association, IPv4 reviewed, IPv6 reviewed, source of effective rules, and confidence.
2. Split default-deny output into Explicit terminal deny, Implicit deny, Implied allow, and Unsupported by platform rather than a single Pass/Fail field.
3. Add cloud-specific checks for AWS security group versus NACL semantics, Azure NSG default rules/effective security rules, and GCP implied and hierarchical firewall rules.
4. Add an IPv4/IPv6 exposure matrix for inbound and outbound findings, including 0.0.0.0/0 and ::/0.
5. Add Not Evaluable from IaC Only outcomes for unused-rule findings, resource association gaps, hit-counter claims, and cloud effective-policy state when runtime exports are missing.

References

• AWS Security group rules: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html
• Azure NSG traffic filtering and default rules: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works
• Google Cloud VPC firewall rules and implied rules: https://cloud.google.com/firewall/docs/firewalls
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy: https://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final
• CIS Controls v8: https://www.cisecurity.org/controls/v8

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms.
• Preferred payment method: To be provided privately after acceptance.

[kingtechies]

Review: firewall-review Cloud Implicit-Rule + IPv6 Evidence

Overall Assessment: ✅ VALID GAP

The contributor identifies two real gaps:

1. Cloud implicit rules: AWS security groups have implicit outbound allow rules that traditional firewall scanners miss. A review that only checks explicit rules can miss this.
2. IPv6 evidence: Dual-stack environments often have IPv6 paths that bypass IPv4-only firewall reviews.

False Positive Analysis: Confirmed

A reviewer checking only explicit rules in a security group can flag a resource as "well-secured" while missing that the implicit rules allow outbound traffic. The contributor's example is accurate.

Coverage Improvement

The firewall-review skill should add:

• Cloud provider implicit rules section (AWS default outbound allow, Azure NSG default rules, GCP implied rules)
• IPv6 dual-stack checks — verify IPv6 firewall rules exist and match IPv4 intent
• Rule ordering/precedence — cloud firewalls process rules in order, first match wins

Assessment

Criteria	Result
Valid gap?	✅ Yes
Production relevant?	✅ Yes
Recommend merge?	✅ Yes

[JamesJi79]

Review: firewall-review — Cloud Implicit-Rule & IPv6 Evidence

Issue: #220
Skill reviewed: firewall-review (skills/network/firewall-review/SKILL.md)
Reviewer: Hermes Agent
Date: 2026-06-03
Version reviewed: 1.0.0

---

Overall Assessment: ✅ VALID GAP — Recommend Merge with Conditions

The contributor identifies two genuine structural gaps in the firewall-review skill. The skill is strong for traditional ordered rule-base firewalls (iptables, pf, Cisco ASA) but lacks first-class support for cloud-native firewall semantics (implicit rules, stateful allow-lists, association scope) and parallel IPv6 evidence. The existing pitfalls mention these issues but the core process and output format do not enforce their evaluation.

---

1. Summary of Findings

#	Finding	Severity	Status
F1	Cloud implicit/default rules are not evaluated as effective policy	High	Unconfirmed
F2	No structured IPv4/IPv6 exposure matrix in output format	High	Unconfirmed
F3	Default-deny check conflates explicit terminal deny with implicit deny	Medium	Unconfirmed
F4	No association scope coverage (NSG/subnet/NIC binding, SG attachment)	Medium	Unconfirmed
F5	No Not Evaluable outcome for IaC-only source limitations	Low	Unconfirmed

---

2. Finding Analysis

F1 — Cloud implicit/default rules not evaluated as effective policy

Claim: The skill requires an explicit deny-all as the last rule and flags absence as Critical, but AWS security groups, Azure NSGs, and GCP VPC firewalls have stateful/implicit behaviors that make this check inapplicable or misleading.

Evidence from skill (Step 2.1):

The skill's Step 2.1 lists as a pattern to check:

egress: 0.0.0.0/0 allow all

And says default_action = "Allow" is "BAD — should be 'Deny'". It also adds a bullet: "No implicit allow rules override the default deny (e.g., cloud security groups that default to allow outbound)."

Analysis: The skill acknowledges cloud implicit rules as a pitfall and as a bullet point in Default Deny Verification, but:

• No structured check exists to enumerate platform default rules (AWS: implicit allow outbound; Azure: DenyAllInBound, AllowVnetInBound, AllowVnetOutBound, AllowInternetOutBound; GCP: implied allow egress, implied deny ingress).
• No platform-aware branching — the same default-deny logic is applied to iptables and AWS security groups identically.
• No effective-policy evaluation — the skill does not instruct the LLM to compute effective policy from (explicit rules + implicit/default rules + priority), only to scan for explicit deny-all.

Contributor's examples are accurate:

• AWS SG with restrictive ingress + restrictive egress but no explicit deny — a naive review could mark this as "missing default deny" (false positive), or mark default-deny as "Pass" just because it's an allow-list (false sense of security).
• Azure NSG with DenyAllOutBound present but AllowInternetOutBound at a higher priority — a naive review could mark Pass for outbound default deny while internet access is still permitted.
• GCP VPC with no explicit rules — implied allow egress 0.0.0.0/0 is active and would be missed.

Verdict: ✅ Valid gap. The skill needs a structured Platform Effective Policy section.

---

F2 — No structured IPv4/IPv6 exposure matrix

Claim: The skill mentions IPv6 as a pitfall but does not require IPv4/IPv6 coverage separation in the output format.

Evidence from skill (Pitfall #3):

"Ignoring IPv6 rules. Many environments have parallel IPv4 and IPv6 rule bases (ip6tables, IPv6 security group rules). If IPv6 is not explicitly disabled at the interface level, an unmanaged IPv6 rule base can bypass all IPv4 firewall controls."

Analysis: The pitfall correctly identifies the risk, but the output format has no IPv6 section. The Default Deny Status, Egress Filtering Status, and individual findings only reference IPv4 constructs (0.0.0.0/0). A reviewer could flag an IPv4-only allow and miss a ::/0 IPv6 allow on the same resource.

Contributor's example is accurate:

ingress {
    cidr_blocks = ["10.0.0.0/8"]        # restricted
}
ingress {
    ipv6_cidr_blocks = ["::/0"]          # global access
}

Verdict: ✅ Valid gap. Output format should separate IPv4/IPv6 or require dual-stack coverage evidence.

---

F3 — Default-deny check conflates explicit/implicit/unsupported semantics

Claim: The single Pass/Fail field for default deny does not distinguish between explicit terminal deny, implicit deny (platform enforces deny for non-matching), implied allow (platform's default is permissive), and unsupported (platform cannot express deny rules).

Evidence from skill (Output Format — Default Deny Status):

| Direction | Status | Evidence |
|-----------|--------|----------|
| Inbound   | Pass/Fail | <rule reference> |
| Outbound  | Pass/Fail | <rule reference> |

Analysis: A Pass/Fail binary is insufficient:

• AWS security groups: stateful allow-lists — no explicit deny, but denied traffic is implicitly dropped (implicit deny).
• Azure NSGs: default rules exist with explicit deny and allow — priority matters.
• GCP VPC: implied deny ingress, implied allow egress — active unless overridden.
• iptables: explicit :INPUT DROP policy with terminal -j DROP — explicit terminal deny.

All four would get "Pass" for inbound, but the security posture and confidence are very different.

Verdict: ✅ Valid gap. Needs a more expressive classification.

---

F4 — No association scope coverage

Claim: Cloud firewall policy is only effective when the rule set is attached to the correct resource.

Evidence: The skill has no check for NSG-to-subnet/NIC association, security-group-to-instance attachment, or GCP hierarchical firewall policy scope.

Contributor's variant 4 shows a restrictive NSG that is not associated with any subnet or NIC — the review would give a false sense of security.

Verdict: ✅ Valid gap. Association scope should be a first-class check in cloud contexts.

---

F5 — No Not Evaluable outcome for IaC-only source limitations

Claim: Hit counters, flow logs, and effective-policy state may be unavailable from IaC source alone.

Evidence: Step 2.4 (Unused Rules) requires hit counters, but if the source is IaC files only, no such data exists. The skill does not define a Not Evaluable or Insufficient Evidence outcome.

Verdict: ✅ Valid gap. Reduces false findings and improves report honesty.

---

3. Review of Contributor's Priority Recommendations

#	Recommendation	Priority	Assessment
R1	Add Platform Effective Policy section	P0	Essential. Without this, the skill cannot reliably audit cloud firewall policy.
R2	Split default-deny output into Explicit terminal deny, Implicit deny, Implied allow, Unsupported	P0	Essential. Directly addresses F3.
R3	Add cloud-specific checks for AWS SG vs NACL, Azure NSG default rules/effective rules, GCP implied/hierarchical rules	P0	Essential. Core cloud coverage.
R4	Add IPv4/IPv6 exposure matrix	P1	High value. Dual-stack is ubiquitous in cloud.
R5	Add Not Evaluable from IaC Only outcomes	P1	High value. Reduces false positives in source-only reviews.

---

4. Existing Skill Strengths

• Strong traditional firewall audit workflow (ordered rules, shadowing, any/any).
• Good NIST SP 800-41 and CIS Controls v8 alignment.
• Pitfalls section correctly identifies cloud SG behavior, IPv6, and hit-counter caveats.
• Prompt injection safety notice is well-written.
• Clear remediation guidance in findings format.

---

5. Specific Changes Needed

5.1 Process — Add Step 2.8: Cloud Platform Effective Policy Evaluation

A new step should be inserted between Step 2.7 (Egress Filtering) and Step 3 (Compile Assessment Report):

2.8 Cloud Platform Effective Policy Evaluation

For each discovered cloud firewall resource, evaluate effective policy by combining:

• Explicit rules (user-defined)
• Platform default/implicit rules (AWS implicit egress allow; Azure default NSG rules; GCP implied ingress/egress)
• Rule priority/order (Azure NSG priority, AWS SG rule order, GCP firewall priority)
• Association scope (NSG-to-subnet/NIC, SG-to-instance/ENI, GCP hierarchical policy target)
• Stateful vs. stateless semantics (AWS SG = stateful allow-list; AWS NACL = stateless ordered list; Azure NSG = stateful, GCP VPC FW = stateful)

Record the effective allow set for each direction and address family.

5.2 Output Format — Add Platform Effective Policy Section

After the Default Deny Status table:

### Platform Effective Policy Summary

| Property | Value |
|----------|-------|
| Platform | AWS / Azure / GCP / On-prem |
| Firewall type | Security Group / NSG / NACL / VPC FW / iptables / pf / etc. |
| Stateful / Stateless | Stateful / Stateless |
| Ordered rules? | Yes / No |
| Explicit deny supported? | Yes / No |
| Implicit/default rules in effect | <list of implicit rules documented> |
| Resource association verified | Yes / No (list associated resources) |
| IPv4 reviewed | Yes / No |
| IPv6 reviewed | Yes / No |
| IPv6 disabled at platform level? | Yes / No / Unknown |
| Source of effective rules | IaC only / Runtime export / Both |
| Confidence | High / Medium / Low / Not Evaluable |

5.3 Output Format — Split Default Deny Status

Replace the binary Pass/Fail with:

### Default Deny Status

| Direction | Explicit Term. Deny | Implicit Deny | Implied Allow | Platform Status | Confidence |
|-----------|-------------------|--------------|--------------|----------------|------------|
| Inbound   | Found / Absent / N/A | Present / Absent | Present / Absent | Pass / Fail | High / Med / Low / NE |
| Outbound  | Found / Absent / N/A | Present / Absent | Present / Absent | Pass / Fail | High / Med / Low / NE |

5.4 Output Format — Add IPv4/IPv6 Exposure Matrix

After the Egress Filtering Status table:

### IPv4/IPv6 Exposure Matrix

| Direction | Address Family | Most Permissive CIDR | Count of Overly Permissive Rules | Effective Exposure |
|-----------|---------------|---------------------|--------------------------------|--------------------|
| Inbound   | IPv4          | 0.0.0.0/0 / restricted | <count> | Open / Restricted |
| Inbound   | IPv6          | ::/0 / restricted | <count> | Open / Restricted |
| Outbound  | IPv4          | 0.0.0.0/0 / restricted | <count> | Open / Restricted |
| Outbound  | IPv6          | ::/0 / restricted | <count> | Open / Restricted |

5.5 Findings — Add Association Scope and IaC-Only Caveats

The remediation section for findings related to hit counters, unused rules, and effective policy should include:

- **Confidence:** High (runtime data available) / Medium (IaC + documentation) / Low (IaC only) / Not Evaluable (data unavailable)

---

6. Additional Observations

Edge Cases Not in Issue

1. AWS Network ACLs are stateless and ordered — the contributor notes this but the skill currently doesn't distinguish NACLs from SGs in the discovery patterns section.

2. GCP hierarchical firewall policies (organization-level, folder-level, VPC-level) can override VPC firewall rules and are not mentioned anywhere in the skill.

3. Multi-cloud deployments — the skill assumes a single platform per review; a multi-cloud review would need multiple effective-policy evaluations.

4. AWS prefix lists / Azure service tags — cloud providers support managed prefix lists that reference AWS/Azure services by tag; these are broader than explicit CIDR evaluation and could introduce blind spots.

Documentation Quality

The issue is well-structured, provides concrete examples for each variant, and includes platform-specific documentation links. The priority recommendations are actionable and appropriately scoped.

---

7. Recommendation

Criteria	Result
Valid security/quality gap?	✅ Yes
Production-relevant?	✅ Yes — cloud native firewalls are the majority of modern deployments
False positive analysis correct?	✅ Yes
Recommendations actionable?	✅ Yes
Recommend merge?	✅ Yes, with note that the skill's process and output format need the above structural additions

Merge condition: The contributor's 5 priority recommendations (R1-R5) should be implemented in the skill. The specific changes outlined in Section 5 above provide a concrete implementation blueprint.

---

References

• Issue [REVIEW] firewall-review: add cloud implicit-rule and IPv6 evidence #220 body: [REVIEW] firewall-review: add cloud implicit-rule and IPv6 evidence #220
• AWS Security Group rules: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html
• Azure NSG default rules: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works
• GCP VPC firewall implied rules: https://cloud.google.com/firewall/docs/firewalls
• Skill file: /private/tmp/SecuritySkills/skills/network/firewall-review/SKILL.md

[modelsbridgeaicom-ship-it]

Implemented this in PR #934: #934

The update adds platform-aware default-deny handling, cloud effective-policy evaluation, IPv4/IPv6 exposure reporting, association-scope checks, and Not Evaluable confidence outcomes for IaC-only evidence gaps.