feat: add rule AZ-CMP-007 management ports open without JIT VM access

[shariqueahmad108-ship-it]

What

Implements #270 as AZ-CMP-007 — flags VMs whose management ports (SSH 22 / RDP 3389) are open to the internet via their NIC's NSG but are not covered by a Microsoft Defender for Cloud Just-In-Time (JIT) VM access policy. Standing-open management ports are continuously scanned and brute-forced; JIT limits exposure to approved, time-boxed windows.

Detection logic

Reuses the repo's own building blocks rather than reinventing them:

• Management-port exposure — the same "allow inbound <port> from any source (*/0.0.0.0/0/Internet)" test that AZ-NET-001/002 use, applied to ports 22 and 3389.
• VM → NIC → NSG resolution — the AZ-CMP-001 path: each VM's NIC is resolved, its NSG looked up by id from get_network_security_groups(), and its security_rules scanned.
• JIT cross-reference — a new AzureClient.get_jit_network_access_policies() getter (Defender for Cloud SecurityCenter SDK). Each policy's virtual_machines[].id + ports[].number build a per-VM covered-port set. A VM is flagged only for management ports that are open and not covered.

Edge cases handled deliberately:

• No management ports open → NOT_APPLICABLE (not flagged).
• Trusted-source-only rule (e.g. a corporate CIDR, not the internet) → not flagged.
• Partial coverage → only the uncovered port is reported (metadata lists open_management_ports, uncovered_ports, jit_policy_present).
• Defender for Cloud unreadable (None) → coverage is indeterminate, so the VM is not flagged — the rule never false-positives when it can't confirm "no JIT". This mirrors the repo's existing "never treat indeterminate as a violation" stance.

Compliance mappings (all four framework JSONs)

Framework	Control
NIST CSF	PR.AC-3	Remote access is managed
ISO 27001	A.13.1.1	Network controls
SOC 2	CC6.6	Restricts access from outside the network boundary
CIS	N/A-CMP-007	JIT is a Defender-for-Cloud recommendation; CIS Azure Foundations 2.0.0 has no numbered control, so this uses the repo's existing N/A convention (as AZ-KV-001). Happy to map to a preferred id.

Notes

• azure-mgmt-security is already a dependency on dev, so no requirements change — only the new getter.
• The playbook fix_az_cmp_007.sh enables JIT via the ARM jitNetworkAccessPolicies endpoint (az rest), with args guarded (${1:-}) per the convention flagged on feat: add rule AZ-CMP-005 Trusted Launch (Secure Boot + vTPM) check #273.

Tests

Six unit tests in tests/test_rules_compute.py (mock-based, no network): open-SSH-no-JIT, JIT-covered, no-mgmt-ports (NOT_APPLICABLE), trusted-source, partial-coverage, and indeterminate-JIT.

pytest tests/test_rules_compute.py   -> 22 passed
ruff check .            -> clean
ruff format --check .   -> clean

Honest testing note

I don't have an Azure subscription, so I could not run the issue's "tested against a real Azure free-trial subscription" step — that box is left for a maintainer to confirm. The SDK shapes the code relies on (SecurityCenter(credential, subscription_id), jit_network_access_policies.list(), JitNetworkAccessPolicyVirtualMachine.id/.ports, JitNetworkAccessPortRule.number, and the NSG rule fields) were verified against the installed azure-mgmt-security==7.0.0 and azure-mgmt-network models, and the rule logic is fully covered by the unit tests above.

Test plan (from the issue)

• Compliant case returns no findings (unit)
• Non-compliant case returns correct finding (unit)
• VMs with no management ports open return NOT_APPLICABLE (unit)
• CLI playbook written (fix_az_cmp_007.sh)
• All four compliance framework JSONs updated
• Tested against a real Azure free-trial subscription (needs maintainer — no Azure access on my side)

Closes #270

[ritiksah141]

1. Port ranges are missed

The detection only compares exact values and *. A valid NSG range such as 20-30 exposes SSH, but the rule returns false. I reproduced this directly.

Suggested inline comment around az_cmp_007.py:52:

This only recognises an exact port or *. Azure NSG rules can express destination ranges, so a rule such as 20-30 exposes SSH but this implementation treats
port 22 as closed. Please parse ranges in both destination_port_range and destination_port_ranges, and add regression coverage for 22/3389 contained inside a
range.

2. Subnet-level NSGs are ignored

The implementation only follows nic.network_security_group. A VM can be exposed through the NSG attached to its NIC’s subnet while having no NIC-level NSG,
Suggested inline comment around az_cmp_007.py:91:

This only checks an NSG attached directly to the NIC. A VM can have no NIC-level NSG while its subnet NSG permits inbound SSH/RDP, so the rule would
incorrectly return NOT_APPLICABLE for an exposed VM. Please include the NIC IP configuration’s subnet NSG/effective exposure path and add a subnet-only
regression test.

3. The remediation can overwrite existing JIT coverage

The script sends a complete PUT to a shared policy named default, with only the selected VM in properties.virtualMachines. The Azure API defines this as “Create
or Update” and requires the complete VM configuration array, so existing entries need to be preserved. Microsoft API documentation
(https://learn.microsoft.com/en-us/rest/api/defenderforcloud/jit-network-access-policies/create-or-update?view=rest-defenderforcloud-2020-01-01).

Suggested inline comment around fix_az_cmp_007.sh:25:

This PUT sends a complete default policy containing only the selected VM. If that policy already protects other VMs, this can replace its virtualMachines
array and remove their JIT configuration. Please fetch the current policy and merge/update this VM without dropping existing entries, or use a safely scoped
policy name. Add a test or documented validation proving an existing multi-VM policy is preserved.

Suggested overall review in your style:

@shariqueahmad108-ship-it, the overall rule structure, framework mappings and categorized tests look good, but there are three cases holding my approval:

• NSG destination port ranges such as 20-30 are not evaluated, which causes false negatives for SSH/RDP.
• Only NIC-level NSGs are checked, so exposure through a subnet-level NSG is missed.
• The remediation PUT writes the shared default JIT policy with only one VM and can remove existing VM entries.

Please address the inline comments and add regression coverage for the range and subnet cases, plus make the playbook preserve existing JIT policy entries.
Also the full repository CI checks still need to run; currently only the Semgrep check is shown.

[TFT444]

Three correctness blockers. First, port-range detection does not handle range strings like '20-30', so a rule covering port 22 via a range never fires. Second, only NIC-level NSGs are checked and subnet-attached NSGs exposing the same port are silently missed. Third, the remediation PUT replaces the entire jitNetworkAccessPolicies/default VM list, which destroys existing JIT entries for other VMs in the policy. Scope the PUT to only the target VM.

[shariqueahmad108-ship-it]

Thanks @ritiksah141 and @TFT444 — all three are fixed in 0466e42c:

1. Port ranges — _rule_allows_port_from_any now parses *, single ports, and inclusive ranges (e.g. 20-30 covering 22) in both destination_port_range and destination_port_ranges. Regression tests added for 22 inside 20-30 and 3389 inside a 3380-3400 ranges-list entry.
2. Subnet-level NSGs — exposure is now evaluated across every NSG that governs the VM: the NIC's NSG and the subnet's NSG (resolved via each NSG's .subnets back-reference, so no extra API calls). Added a subnet-only regression test — no NIC-level NSG, exposing subnet NSG → correctly flagged instead of NOT_APPLICABLE.
3. Remediation — fix_az_cmp_007.sh now GETs the existing default policy and merges this VM in via the new jit_policy_merge.py (preserving every other VM's entry) before the create-or-update PUT, instead of overwriting the shared policy. Added tests/test_jit_policy_merge.py proving an existing multi-VM policy is preserved, and that re-remediating the same VM updates its entry in place rather than duplicating it.

Local: 25 compute-rule tests + 4 merge tests pass, ruff clean. Thanks for the thorough reviews!

[parthrohit22]

Checked this against az_net_001.py/az_net_002.py's "allow from any" helper and azure_client.py's existing caching/error-handling conventions, and verified the JIT and NSG SDK model shapes this rule relies on actually match azure-mgmt-security/azure-mgmt-network (jit_network_access_policies.list(), JitNetworkAccessPolicy.virtual_machines[].id/.ports[].number, NetworkSecurityGroup.subnets back-reference).

What stands out as solid:

• Indeterminate-vs-violation handling is correct: get_jit_network_access_policies() returns None on API/permission failure (distinct from [] for "no policies exist"), and scan() treats None as indeterminate rather than a confirmed finding — matches this codebase's convention, and it's directly tested.
• The remediation script (jit_policy_merge.py) does a GET-then-merge before PUT rather than a naive replace — a naive single-VM PUT would have silently dropped every other VM's JIT config off the shared default policy. Good catch, and it's covered by tests proving existing VMs survive re-remediation.
• Port-range matching (a 20-30 range covering port 22) and subnet-level NSG resolution (VM with only a subnet NSG, no NIC-level NSG) are both handled, with regression tests for each.
• Six original + seven regression tests exercise real scenarios (open-no-JIT, JIT-covered, NOT_APPLICABLE, trusted-source-only, partial coverage, indeterminate JIT, range-based exposure) rather than being tautological.

Two non-blocking notes, no action needed to merge:

• _rule_allows_port_from_any doesn't check protocol (a UDP-only allow on port 22 would still flag) or NSG rule priority ordering — inherited as-is from the existing az_net_001/az_net_002 helper this rule reuses, not something new here.
• docs/rules-reference.md and website/content.js still only list AZ-CMP-001..004 — AZ-CMP-007 isn't in the public rule catalog docs yet. Not enforced by CI, so not a blocker, but worth a quick follow-up.

Full suite passes (724 passed, 3 skipped, all pre-existing/unrelated), ruff clean, playbook and merge-helper script both valid, no RULE_ID or PLAYBOOK path issues.

[parthrohit22]

@TFT444 @ritiksah141
I think this PR is ready for merge now, re-requesting reviews from you guys,
if agreed with my previous comments update it, I will merge it .

[ritiksah141]

All issues flagged by me is being addressed, so approving it

[shariqueahmad108-ship-it]

Friendly nudge — this one looks ready whenever a maintainer has a moment:

• All three review points (port-range parsing, subnet-level NSGs, and the JIT-preserving remediation) are fixed in 0466e42c, with regression tests for each.
• @ritiksah141 re-reviewed after the fixes and approved; @parthrohit22 also approved and noted it's ready to merge.
• All 20 CI checks are green.

@TFT444 — since your review flagged the same three items, could you take another look (or dismiss if satisfied)? Happy to address anything else. Thanks all for the thorough reviews!

[Vishnu2707]

Approved

[TFT444]

merging now as everything good to go