Add complete OSI Network Layer assurance and Azure Layer 3 checks

[ritiksah141]

Problem

OpenShield has several Azure network rules, but it does not yet have a closed OSI Layer 3 model proving which Network Layer functions are covered, customer-controlled, provider-owned, observable, unsupported, or not applicable.

Existing NSG, routing, peering, firewall, VPN, public IP, and DDoS rules must be classified by their actual protocol behavior. Layer 4 port checks and Layer 7 DNS or application controls must not be relabeled as Layer 3 merely because they are stored in the Network category.

Azure Virtual Networks expose authoritative management-plane state for selected Layer 3 controls. Microsoft still owns the underlying fabric routing, tenant isolation, forwarding implementation, and physical packet handling that customers cannot inspect directly.

Required implementation

Build a backend-only Network Layer assurance feature after #247 is merged. Reuse the shared assurance catalog and reporting foundation introduced by #240 and generalized by #247. Resolve or account for #244 before relying on scanner rule counts or discovery.

Functional coverage

The closed catalog must represent these Layer 3 domains:

1. IPv4 addressing and prefix management
2. IPv6 addressing and dual-stack behavior
3. Subnetting and address-space overlap
4. Packet forwarding and next-hop selection
5. System routes and user-defined routes
6. Route propagation and effective routes
7. Virtual network peering and transit
8. Hub-and-spoke routing
9. Network address translation
10. Public and private IP boundaries
11. IP fragmentation, MTU, and path MTU behavior
12. ICMP and diagnostic reachability
13. Source-address validation and anti-spoofing
14. BGP routing
15. VPN gateway routing
16. ExpressRoute routing and route advertisement
17. Route redundancy and failover
18. DDoS protection at the IP boundary
19. Network isolation and segmentation
20. Layer 3 monitoring, flow visibility, and route diagnostics

Every domain must declare Azure applicability, responsibility owner, observability method, evidence sources, verification state, and cross-references to genuine Layer 3 scanner rules.

Existing rule audit

Audit every AZ-NET-* rule and classify it as Layer 2, Layer 3, Layer 4, Layer 7, or cross-layer.

• Do not change a rule category solely to increase Layer 3 coverage.
• Do not count port-specific NSG checks as pure Layer 3 controls.
• Do not count DNS findings as Layer 3 controls.
• Preserve the two ExpressRoute Direct MACsec rules as Layer 2 controls.
• Document any domain that has no safe customer-actionable automated check.

Automated checks

Add new rules only where Azure exposes authoritative management-plane state and the security expectation is safe across supported deployments. Candidate checks must be validated before implementation and may include:

• Network interfaces with IP forwarding enabled without an identified routing function.
• Route configurations that expose an unintended direct internet path.
• Address-space overlap or invalid transit topology where Azure inventory proves the condition.
• Missing Layer 3 diagnostic coverage where the required Azure service and scope are authoritative.

Do not create findings from assumptions about Microsoft fabric internals. Empty inventory must be not applicable. Azure API and permission failures must remain indeterminate and must never create false findings.

Each new rule must include offline compliant and non-compliant regression tests, a safe remediation playbook, and mappings in all four compliance framework files.

API and catalog

Add an authenticated GET /api/assurance/network-layer endpoint returning:

• Layer number, name, scope, catalog version, and responsibility boundary
• Complete domain coverage
• Existing and new rule cross-references by actual OSI classification
• Provider-assurance and platform-enforcement states
• Automated-control applicability
• Catalog coverage and evidence freshness as separate measurements
• Evidence review dates and Microsoft source links
• Explicit limitations preventing assurance from being interpreted as live Azure fabric inspection

The catalog must fail validation when any required domain, responsibility, applicability decision, evidence source, verification state, rule classification, or cross-reference is missing.

Acceptance criteria

• All 20 Network Layer domains are represented and validated
• Every existing AZ-NET-* rule has an evidence-based OSI classification
• Layer 2, Layer 4, and Layer 7 rules are not relabeled as Layer 3
• New checks use the existing AzureClient abstraction
• Empty inventory and API failure paths do not create findings
• Provider-owned controls do not alter the tenant security score
• Catalog coverage and evidence freshness remain independent
• No frontend changes are included
• No paid OpenShield service or external runtime API is required
• Documentation explains the Azure Layer 3 responsibility boundary
• Ruff, DCO, backend tests, rule validation, CodeQL, Semgrep, Bandit, Gitleaks, pip-audit, dependency review, SBOM, Trivy, and the CI summary pass

Non-goals

• Frontend or dashboard work
• Packet capture or live traffic inspection
• On-premises router discovery
• SNMP, NetFlow, sFlow, or external NMS integrations
• Claiming visibility into Microsoft forwarding tables or tenant-isolated fabric internals
• Treating every Network-category rule as a Layer 3 control
• Adding speculative checks that cannot distinguish non-compliance from an Azure API failure

Dependencies

Blocked by #247 because the implementation must build on the generalized assurance foundation. Rule discovery and count consistency from #244 must also be resolved or explicitly handled before completion.