Least Privilege and Zero Trust

Why This Topic Matters
Least Privilege and Zero Trust are two of the most frequently tested secure design principles in the CSSLP Domain 1 (Secure Software Concepts). They appear directly as definitions, indirectly inside scenario questions, and as the 'correct' reasoning behind many architecture, access control, and cloud security answers. Both principles exist to limit the blast radius of a compromise: if an attacker, a bug, or an insider gains a foothold, the damage should be contained to the smallest possible set of resources. Breaches such as credential theft, lateral movement inside flat networks, over-privileged service accounts, and supply-chain compromises are all failures of these two ideas. Understanding them well also helps you reason about related CSSLP concepts such as separation of duties, defense in depth, fail secure, and complete mediation.

What Is Least Privilege?
The Principle of Least Privilege (PoLP) states that every subject (user, process, service, module, or component) should be granted only the minimum rights and permissions necessary to perform its legitimate function, and only for the minimum time necessary. Key characteristics:
• Minimum necessary rights – an application that only reads a table should not have write or delete rights.
• Time-bounded – privileges are elevated only when needed (just-in-time, JIT) and dropped afterward (just-enough-access, JEA).
• Applies to code, not just people – processes should run under restricted service accounts, not as root/Administrator/SYSTEM; containers should not run privileged; database connection strings should use low-privilege accounts.
• Default deny – start with nothing and add permissions explicitly, rather than starting with everything and trying to remove.
Least privilege is closely linked to Need to Know (restricting access to information) and Separation of Duties (splitting a sensitive task so no single subject controls it end-to-end). On the exam, remember: least privilege is about permissions/actions, need to know is about data/information, and separation of duties is about splitting tasks between people or roles.

How Least Privilege Works in Software
• Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) to map subjects to tightly scoped permissions.
• Privilege dropping – a service that must bind to a privileged port starts with elevated rights, then immediately drops to an unprivileged account.
• Sandboxing and isolation – browsers, mobile apps, and containers constrain what code can touch.
• Scoped tokens and API keys – OAuth scopes, IAM policies, and short-lived credentials instead of broad, permanent keys.
• Compartmentalization / modular design – each module or microservice gets its own identity and only the permissions it needs.
• Regular access reviews – privileges are recertified and revoked when no longer required (combating privilege creep).
• Secure defaults and fail secure – if an authorization check fails or errors, access is denied.

What Is Zero Trust?
Zero Trust is a security model built on the assumption that no user, device, network, or workload should be implicitly trusted, regardless of whether it sits 'inside' or 'outside' a traditional perimeter. Its motto is 'Never trust, always verify.' Zero Trust rejects the legacy 'castle-and-moat' idea that anything inside the corporate network is safe. Core tenets (aligned with NIST SP 800-207):
• Verify explicitly – authenticate and authorize every request based on all available signals: identity, device health, location, time, data sensitivity, behavior.
• Use least privilege access – Zero Trust directly embeds PoLP, using JIT/JEA and risk-adaptive policies.
• Assume breach – design as though the attacker is already inside; minimize blast radius through segmentation, encryption, and continuous monitoring.
• Continuous evaluation – trust is not granted once per session; it is re-evaluated as context changes.
• Per-session, per-resource access – access is granted to a specific resource, not to the whole network.

How Zero Trust Works in Software and Architecture
• Strong identity – multi-factor authentication (MFA), federated identity, and identity as the new perimeter.
• Micro-segmentation – breaking networks and applications into small zones so lateral movement is blocked.
• Policy Enforcement Points (PEP) and Policy Decision Points (PDP) – every access request is evaluated against policy by a decision engine before being allowed.
• Device posture and health checks – only compliant, patched, managed devices are allowed.
• Encryption everywhere – mutual TLS (mTLS) between services, encrypting data in transit even inside the data center.
• Service-to-service authentication – microservices authenticate each other (e.g., via a service mesh) rather than trusting the internal network.
• Comprehensive logging, telemetry, and analytics – continuous monitoring feeds back into access decisions.
• Complete mediation – every access to every object is checked every time; no cached or assumed authorization.
In software development, Zero Trust means: do not trust input from 'internal' systems any more than external ones, authenticate every API call, validate every request server-side, never rely on client-side enforcement, and never assume a request is safe because it came from inside the VPC or behind the firewall.

How Least Privilege and Zero Trust Relate
Least privilege is a principle; Zero Trust is a broader architectural model that operationalizes least privilege along with explicit verification and the assume-breach mindset. Zero Trust answers 'who/what should be trusted and when?' (nothing by default, verify every time), while least privilege answers 'how much access should be granted?' (the minimum). Together they reduce attack surface, contain breaches, limit insider threat, and support compliance requirements.

Common Pitfalls and Anti-Patterns
• Running services as root/Administrator for convenience.
• Shared 'god' accounts or hard-coded admin credentials.
• Granting broad wildcard IAM permissions (e.g., *:*).
• Trusting traffic because it is on an internal network or VPN.
• Performing authorization only once at login and caching the result indefinitely.
• Privilege creep as employees change roles without revocation.
• Relying on client-side checks for authorization decisions.

Exam Tips: Answering Questions on Least Privilege and Zero Trust
1. Look for the 'minimum' keyword. If a question asks which principle is violated when a process or user has more access than its job requires, the answer is almost always least privilege.
2. Distinguish the three related principles. Least privilege = minimum permissions/actions. Need to know = minimum information/data. Separation of duties = no single person can complete a critical task alone (e.g., developer cannot deploy their own code to production). Exam distractors frequently swap these.
3. 'Never trust, always verify' and 'assume breach' point to Zero Trust. Any scenario about removing implicit trust from the internal network, verifying every request, device posture, or micro-segmentation is Zero Trust.
4. Internal does not mean trusted. If an answer choice relies on 'the request came from inside the network' or 'behind the firewall' as justification for skipping checks, it is wrong under Zero Trust.
5. Code must enforce it too. CSSLP emphasizes the developer's perspective: run with restricted service accounts, drop privileges after startup, use scoped tokens, validate and authorize every request server-side. If a choice puts security in the client or assumes the caller is trusted, eliminate it.
6. Default deny / fail secure is the companion answer. When unsure between 'grant then restrict' versus 'deny then allow explicitly', choose default deny.
7. Time matters. Just-in-time and just-enough-access (temporary elevation, short-lived credentials) are the modern expression of least privilege and are favored over standing privileges.
8. Watch for privilege creep scenarios. Questions about an employee who changed roles and kept old access are testing least privilege plus periodic access review/recertification.
9. Zero Trust is identity-centric. If asked for the 'new perimeter' in a Zero Trust model, the answer is identity (user and device), not the network boundary.
10. Choose the most complete, least-trusting option. When two answers both seem correct, the CSSLP generally rewards the one that verifies more, assumes less, and grants the narrowest access, as long as the application can still perform its function (security must still support business requirements).
11. Map to NIST SP 800-207 if it is mentioned: tenets include per-session access, dynamic policy, continuous monitoring, and treating all data sources and computing services as resources.
12. Remember the 'why'. Many questions ask about the benefit: the correct answer typically involves reducing attack surface, limiting blast radius, containing lateral movement, or mitigating insider threat.

Quick Recap
• Least Privilege: grant only the minimum rights, for the minimum time, to users and code alike; default deny; drop privileges; review regularly.
• Zero Trust: never trust, always verify; assume breach; verify identity and device explicitly; micro-segment; enforce least privilege continuously on every request.
• On the exam, identify the keyword (minimum vs. verify vs. split task), reject answers that trust the internal network or the client, and prefer the option that grants the least and verifies the most while still letting the software do its job.