Skill Being Reviewed
Skill name: zero-trust-assessment
Skill path: skills/identity/zero-trust-assessment/
False Positive Analysis
Benign configuration that can be over-rated as Advanced/Optimal based on identity pillar alone:
pillar_scores:
identity: Advanced
devices: Initial
networks: Traditional
applications: Advanced
data: Initial
cross_cutting:
visibility: Initial
automation: Traditional
governance: Initial
assessment_output: |
Overall: Advanced
Recommendation: Continue advancing Identity pillar
Why this is a false positive:
The current skill produces a pillar-by-pillar maturity scorecard and overall assessment, but it does not enforce a minimum pillar parity or require that cross-cutting capabilities reach a threshold before any single pillar can be rated Advanced. An organization can achieve "Advanced" on Identity (phishing-resistant MFA, centralized IdP, automated lifecycle) while remaining "Traditional" on Networks (flat network, VPN-only access) and Devices (no compliance enforcement). The skill's output summary can misrepresent the organization's true zero-trust posture by averaging or highlighting the strongest pillar. Without a "weakest pillar" floor or cross-cutting dependency gate, the overall maturity rating can be inflated.
Benign device compliance program that can be scored lower than warranted:
devices:
asset_inventory:
managed_devices: 100% (Intune + Jamf)
unmanaged_devices: detected via Entra ID device registration
iot_devices: inventoried in separate OT network
compliance:
os_patch_compliance: 95% within 14 days
disk_encryption: 100% (BitLocker + FileVault)
edr_coverage: 100% (CrowdStrike)
posture_as_access_condition:
compliant_device_required_for_saas: true
non_compliant_remediation: automated (user notified, restricted)
continuous_evaluation: device_state_change_triggers_access_re_evaluation: trueWhy this is a false positive:
The Devices pillar assessment criteria (ZT-DEV-01 through ZT-DEV-10) cover specific controls but do not require evidence that device compliance is enforced at runtime as a prerequisite for each access decision. ZT-DEV-06 asks "Device posture not evaluated at access decision time" and ZT-DEV-09 asks "Device state changes do not trigger access re-evaluation," but these are binary yes/no questions. The skill does not require evidence of the integration depth between the device compliance system and the policy engine, nor does it ask for proof that device compliance failure results in session revocation rather than just a warning. A reviewer can check both boxes with partial integration, producing a higher maturity score than warranted.
Coverage Gaps
Missed variant 1: Device compliance enforcement gap — grace period allows access drift.
policy:
device_compliance_enforcement: true
grace_period_for_remediation_hours: 72
access_during_grace: full_access
session_termination_on_expiry: partial (web only, not CLI/API)
observations:
- Users continue to access resources for up to 72 hours with non-compliant devices.
- CLI/API access tokens are not revoked when device compliance expires.
Why it should be caught:
ZT-DEV-02 and ZT-DEV-06 ask about compliance as an access condition but do not require evidence of enforcement granularity: grace periods, per-access-path enforcement (web vs CLI vs API), or session revocation on compliance expiry. A device compliance program that grants full access during a 72-hour grace period and only partially revokes web sessions is weaker than a system that enforces at every access attempt and revokes all session types. The skill should add fields for grace_period_hours, enforcement_paths, session_revocation_on_compliance_drift, and remediation_sla_enforcement.
Missed variant 2: Cross-pillar maturity gap — identity-centric zero trust without network microsegmentation.
pillar_assessment:
identity: Advanced (phishing-resistant MFA, CAE, risk-based policies)
networks: Traditional (flat internal network, VPN remote access, no microsegmentation)
applications: Initial (ZTNA for some apps, legacy access for others)
risk: |
An attacker who compromises an identity through a non-phishing-resistant
path (e.g., service principal, federated IdP compromise, or MFA bypass)
gains unrestricted lateral movement on the flat network.
Why it should be caught:
The skill's pillar-by-pillar maturity scorecard and findings classification (ZT-NET-01 through ZT-NET-11, ZT-ID-01 through ZT-ID-10) treat each pillar independently. Missing is a cross-pillar dependency analysis that identifies gaps created by pillar maturity imbalance. The skill should include a cross-pillar risk matrix that identifies specific attack paths that exploit a strong-identity/weak-network imbalance (e.g., federated IdP to flat network to sensitive data store). CISA ZTMM v2 emphasizes cross-pillar integration, but the skill's output does not require explicit cross-pillar risk scoring.
Missed variant 3: Legacy system zero-trust readiness not assessed.
legacy_systems:
- mainframe-payment-processor:
modern_auth: impossible (custom protocol, no IdP support)
segmentation: air-gapped via bastion host
access: shared service account, no individual accountability
zt_roadmap: enclave-based gateway planned for next fiscal yearWhy it should be caught:
The skill mentions legacy systems in Common Pitfall #4 ("Ignoring legacy systems — legacy applications often cannot support modern authentication. Plan enclave-based or proxy-based patterns for them."), but the maturity scorecard and findings checklist do not include a dedicated assessment dimension for legacy system ZT readiness. The skill should require a legacy_zt_readiness subsection per pillar that inventories systems incompatible with modern auth, segmentation, or monitoring, and documents the compensating controls or migration path.
Edge Cases
- BYOD access through a managed browser (e.g., Edge via Intune MAM) where the device itself is unmanaged but the browser session is policy-enforced. The device pillar assumes "managed" vs "BYOD" as a binary; a managed browser on an unmanaged device is a middle ground not captured.
- Non-human identities (service principals, CI/CD runners, Lambda execution roles) that do not have a "device" to assess for posture. These identities fall between the identity and devices pillars.
- Virtual desktop infrastructure (VDI) where device posture is inherited from the VDI host rather than the end-user device. The current pillar model does not account for inherited device posture.
Remediation Quality
Recommended additions:
- Add a "weakest pillar floor" rule: overall maturity cannot exceed the lowest pillar maturity + 1 level.
- Add cross-pillar dependency scoring that identifies attack paths enabled by pillar maturity gaps.
- Add device compliance enforcement granularity fields: grace period, enforcement paths, session revocation triggers.
- Add a legacy system readiness dimension with fields for modern auth compatibility, segmentation pattern, and migration timeline.
- Handle non-human, VDI, and managed-browser posture in the Devices pillar with dedicated categories.
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| CISA ZTMM v2 self-assessment |
Partial |
Provides per-pillar scoring but no cross-pillar dependency risk or weakest-pillar floor |
| NIST SP 800-207 |
Partial |
Describes principles but does not enforce minimum pillar parity in maturity scoring |
| Commercial ZT assessments (CrowdStrike, Zscaler, Illumio) |
Partial |
Vendor tools emphasize their own pillar; cross-pillar imbalance analysis is rare |
Overall Assessment
Strengths:
- Comprehensive per-pillar maturity criteria aligned with CISA ZTMM v2 and NIST SP 800-207.
- Good findings checklist (ZT-ID-01 through ZT-DATA-10) covering common gaps.
- Clear maturity stage definitions from Traditional through Optimal.
- Useful cross-references to related skills.
Needs improvement:
- The maturity scorecard and overall rating do not enforce minimum pillar parity — a single strong pillar can inflate the overall maturity rating.
- Device compliance enforcement depth (grace periods, path-specific enforcement, session revocation) is not evaluated beyond binary yes/no.
- Legacy system ZT readiness and cross-pillar dependency risk are mentioned but not assessed in the structured output.
- Non-human, VDI, and managed-browser posture models are not handled.
Priority recommendations:
- Add a weakest-pillar floor rule and cross-pillar dependency risk matrix to the maturity scorecard output.
- Add device compliance enforcement granularity fields to the Devices pillar assessment.
- Add a legacy system ZT readiness subsection with modern-auth compatibility, segmentation pattern, and migration evidence fields.
Sources Checked
Bounty Info
Skill Being Reviewed
Skill name: zero-trust-assessment
Skill path:
skills/identity/zero-trust-assessment/False Positive Analysis
Benign configuration that can be over-rated as Advanced/Optimal based on identity pillar alone:
Why this is a false positive:
The current skill produces a pillar-by-pillar maturity scorecard and overall assessment, but it does not enforce a minimum pillar parity or require that cross-cutting capabilities reach a threshold before any single pillar can be rated Advanced. An organization can achieve "Advanced" on Identity (phishing-resistant MFA, centralized IdP, automated lifecycle) while remaining "Traditional" on Networks (flat network, VPN-only access) and Devices (no compliance enforcement). The skill's output summary can misrepresent the organization's true zero-trust posture by averaging or highlighting the strongest pillar. Without a "weakest pillar" floor or cross-cutting dependency gate, the overall maturity rating can be inflated.
Benign device compliance program that can be scored lower than warranted:
Why this is a false positive:
The Devices pillar assessment criteria (ZT-DEV-01 through ZT-DEV-10) cover specific controls but do not require evidence that device compliance is enforced at runtime as a prerequisite for each access decision. ZT-DEV-06 asks "Device posture not evaluated at access decision time" and ZT-DEV-09 asks "Device state changes do not trigger access re-evaluation," but these are binary yes/no questions. The skill does not require evidence of the integration depth between the device compliance system and the policy engine, nor does it ask for proof that device compliance failure results in session revocation rather than just a warning. A reviewer can check both boxes with partial integration, producing a higher maturity score than warranted.
Coverage Gaps
Missed variant 1: Device compliance enforcement gap — grace period allows access drift.
Why it should be caught:
ZT-DEV-02 and ZT-DEV-06 ask about compliance as an access condition but do not require evidence of enforcement granularity: grace periods, per-access-path enforcement (web vs CLI vs API), or session revocation on compliance expiry. A device compliance program that grants full access during a 72-hour grace period and only partially revokes web sessions is weaker than a system that enforces at every access attempt and revokes all session types. The skill should add fields for
grace_period_hours,enforcement_paths,session_revocation_on_compliance_drift, andremediation_sla_enforcement.Missed variant 2: Cross-pillar maturity gap — identity-centric zero trust without network microsegmentation.
Why it should be caught:
The skill's pillar-by-pillar maturity scorecard and findings classification (ZT-NET-01 through ZT-NET-11, ZT-ID-01 through ZT-ID-10) treat each pillar independently. Missing is a cross-pillar dependency analysis that identifies gaps created by pillar maturity imbalance. The skill should include a cross-pillar risk matrix that identifies specific attack paths that exploit a strong-identity/weak-network imbalance (e.g., federated IdP to flat network to sensitive data store). CISA ZTMM v2 emphasizes cross-pillar integration, but the skill's output does not require explicit cross-pillar risk scoring.
Missed variant 3: Legacy system zero-trust readiness not assessed.
Why it should be caught:
The skill mentions legacy systems in Common Pitfall #4 ("Ignoring legacy systems — legacy applications often cannot support modern authentication. Plan enclave-based or proxy-based patterns for them."), but the maturity scorecard and findings checklist do not include a dedicated assessment dimension for legacy system ZT readiness. The skill should require a
legacy_zt_readinesssubsection per pillar that inventories systems incompatible with modern auth, segmentation, or monitoring, and documents the compensating controls or migration path.Edge Cases
Remediation Quality
Recommended additions:
Comparison to Other Tools
Overall Assessment
Strengths:
Needs improvement:
Priority recommendations:
Sources Checked
skills/identity/zero-trust-assessment/SKILL.mdBounty Info