The Principle of Least Privilege in Action: Implementing Deny by Default (Activity 1.7.1 “Deny User by Default Policy”)   

This activity is a key way to achieve Zero Trusts “always verify” or “never trust” principle.  (In contrast to the allowing “implicit trust” that has historically granted users potentially far more access than they actually need). This activity mandates a thorough process of auditing internal user and group usage for permissions and revoking excess permissions wherever possible. A key focus is the revocation and/or decommissioning of excess permissions and access for application/service-based identities and groups – those accounts living outside your central IdP. Furthermore, it requires reducing permissions for or decommissioning static privileged users in preparation for the more dynamic access methods we’ve discussed. 

The outcomes of Activity 1.7.1 “Deny User by Default Policy” are tangible and represent a fundamental shift in access posture: 

1. Applications updated to deny by default to functions/data requiring specific roles/attributes for access. 

2. Reduced default permissions levels are implemented. 

3. Applications/services have reviewed/audited all privileged users and removed those users who do not need that level of access. 

4. Applications identify functions and data requiring specific roles/attributes for access. 

This activity is less about implementing new technical enforcement points immediately and more about a crucial cleanup and re-configuration effort to embody the principle of least privilege and prepare for attribute-based dynamic enforcement. 

Solutions for Achieving Deny User by Default Policy 

Achieving a “deny by default” posture requires visibility into existing permissions, a systematic process for remediation, and collaboration between security and application owners. This is where a combination of capabilities, including those increasingly found within modern Identity Governance and Administration (IGA) solutions, comes into play: 

Comprehensive Permission Auditing and Analysis: 

• Permission Discovery and Reporting Tools: Utilize specialized tools that can scan various systems – including applications, file shares (like NTFS permissions), databases, and cloud services – to discover who has what level of access. These tools are essential for gaining the necessary visibility beyond what your IdP or PAM might inherently see within their direct scope. These are a combination of free or paid tools.   

• Data Access Governance (DAG) Tools: For unstructured data residing in file shares, collaboration platforms, or cloud storage, DAG tools provide crucial visibility into data ownership, classification, and who has access. They help identify sensitive data exposed by overly broad permissions.  

• IGA Platforms: Modern IGA solutions are designed to aggregate and correlate identity and access data from various sources, providing a more centralized view of entitlements (permissions) across connected applications and systems. They can facilitate access reviews and help identify dormant accounts or potentially excessive permissions within their integrated scope.  

Define a Least Privilege Policy: 

Establish clear, enterprise-wide policies defining the principle of least privilege – users and entities should only have the minimum access necessary to perform their authorized functions. 

Permission Revocation and Remediation: 

Based on the audit findings and the least privilege policy, systematically revoke unnecessary permissions. This often requires workflows to involve application owners and system administrators. IGA platforms can help orchestrate and track these remediation workflows for integrated applications. Prioritize the revocation of excessive privileges, especially for high-risk accounts and access to sensitive data identified through auditing and DAG tools. 

Decommissioning of Excess Identities and Groups: 

Address the application/service-based identities and groups identified in your inventory (Activity 1.1.1). Decommission those that are no longer needed or whose functions can be migrated to users managed by your central IdP. Clean up unused or overly broad groups within directories and applications. IGA solutions can assist in identifying dormant accounts and unused permissions. 

Reduce Default Permissions and Identify Required Attributes: 

Work closely with application owners and developers to reconfigure applications to operate on a “deny by default” principle for specific functions and data. 

Identify precisely which enterprise roles or attributes (defined in Activity 1.2.1) are required for access to those specific functions and data. This critical step prepares your applications for attribute-based dynamic access controls. 

Identity Governance (IGA) Capabilities: Okta Identity Governance directly addresses key aspects of Activity 1.7.1. Its Access Certifications feature allows for periodic reviews of user access to applications, groups, and entitlements within Okta’s scope, helping to identify and revoke excess access. Entitlement Management provides capabilities to manage fine-grained permissions for integrated SaaS and hybrid applications, enabling the reduction of default permission levels and the assignment of access based on attributes. Okta’s IGA features can help in identifying dormant accounts and streamlining access reviews for the resources it governs. 

Nuances: 

Auditing and Decommissioning of Completely Unmanaged Identities and Groups: While IdP tools help manage the lifecycle for users within its system, identifying and decommissioning application-based identities and groups that have no tie back to a central directory remains a challenge that requires broader discovery and management tools. 

Enforcement of “Deny by Default” Within Applications: While the IdP can enforce policies that deny access to an application unless certain attributes are present, implementing “deny by default” for specific functions or data within an application often requires configuration changes within the application itself, guided by the identity of the user and their attributes. 

The Technical Buyer’s Cleanup Mandate: 

Activity 1.7.1 “Deny User by Default Policy” is a fundamental and necessary step in building a strong Zero Trust security posture. It’s about actively implementing the principle of least privilege by systematically auditing and revoking excessive permissions and cleaning up unnecessary identities. This activity demands visibility into access across your entire environment, not just what your IdP or PAM solution directly manages. Successfully achieving comprehensive permission reduction and “deny by default” requires augmenting its capabilities with dedicated “Permission Auditing and Reporting Tools” and “Data Access Governance Tools” to gain the necessary visibility into permissions residing in diverse systems. For technical buyers, this activity underscores that Zero Trust is a layered approach, requiring a combination of strong identity governance, specialized auditing tools, and a commitment to reducing the attack surface by ensuring users only have the access they absolutely need. This crucial cleanup prepares your environment for the precision of attribute-driven dynamic access. 

Pillar: User 

Capability: 1.7 Least Privileged Access 

Activity: 1.7.1 Deny User by Default Policy 

Phase: Target Level  

Predecessor(s): None 

Successor(s): None