Explain Security Principles and Zero Trust for Security+ (SY0-701)
Understand CIA, AAA, non-repudiation, zero trust, and deception technology well enough to apply them correctly in Security+ scenarios.
Security+ treats security principles as practical design rules, not as decorative vocabulary. The exam wants to know whether you can tell which part of the CIA triad is at risk, how AAA fits access control, when non-repudiation matters, and why zero trust changes the default assumptions behind network access.
What the exam is really testing
CompTIA is usually checking whether you can:
- connect the principle to the scenario instead of only naming it
- distinguish identity, authorization, auditability, and trust-boundary concepts cleanly
- understand that zero trust is an architectural posture, not a single tool or purchase
The foundation you need to keep straight
| Principle | What it protects or enables | Typical question angle |
|---|---|---|
| Confidentiality | Only authorized access to data | encryption, access control, data exposure |
| Integrity | Data stays accurate and unaltered | hashing, signatures, validation, logging |
| Availability | Systems and data stay reachable when needed | redundancy, backups, resilience, DoS protection |
| Authentication | Proving identity | passwords, biometrics, certificates, MFA |
| Authorization | Deciding allowed actions | RBAC, ABAC, ACLs, privilege assignments |
| Accounting | Recording activity | logging, audit trails, session tracking |
| Non-repudiation | Preventing denial of an action | digital signatures, signed records |
Principle chooser
| If the problem is really about… | Principle you should think of first |
|---|---|
| exposed confidential records | confidentiality |
| silent unauthorized change | integrity |
| outage or inability to restore service | availability |
| proving a user is who they claim to be | authentication |
| limiting what an authenticated user may do | authorization |
| proving what actions occurred | accounting or auditability |
| proving a signer cannot later deny an action | non-repudiation |
Why zero trust keeps showing up
Zero trust is not “trust nothing and block everything.” It means verify explicitly, apply least privilege, and assume breach. The internal network is no longer automatically trusted just because a request originated from an inside IP address.
flowchart LR
U["User or workload"] --> I["Identity and device check"]
I --> P["Policy decision"]
P --> E["Enforcement point"]
E --> R["Resource access with logging"]
What to notice:
- identity and device signals are evaluated before access
- access is granted based on policy, not on simple network location
- logging and verification continue even after access is granted
Zero-trust chooser
| Traditional assumption | Zero-trust correction |
|---|---|
| internal network traffic is trustworthy by default | every request still needs evaluation |
| location alone is enough | identity, device, and context matter together |
| broad standing access is simpler | least privilege reduces blast radius |
| logging is secondary after access is granted | monitoring remains part of the control model |
Deception and disruption technologies
CompTIA also expects you to recognize deception concepts such as honeypots, honeynets, honeyfiles, and honeytokens. These are not primary production controls. They help detect adversaries, study movement, or generate high-signal alerts when someone touches something that legitimate users should never access.
Deception tools in plain terms
Deception technologies matter because they create activity that should be nearly impossible for legitimate users to trigger. That makes them useful for high-signal detection, especially when an attacker is already inside the environment.
How principles show up in scenario questions
Security+ often hides principle questions inside architecture language:
- a question about tokenization or encryption is often a confidentiality problem
- a question about digital signatures, hashing, or change detection is often an integrity problem
- a question about clustering, failover, or load balancing is often an availability problem
The strongest answer is usually the one that protects the correct principle without breaking another requirement unnecessarily.
Harder scenario question
A company wants administrators to connect to sensitive systems only after identity verification, device checks, and policy evaluation, even when those administrators are already on the corporate network. Which principle set is strongest?
A. Trust the internal network and focus only on perimeter firewalls B. Use zero-trust access principles with explicit verification, least privilege, and continuous logging C. Remove MFA because administrators are already inside the building D. Replace authorization with stronger symmetric encryption
Best answer: B. The scenario is describing zero-trust access logic directly: identity and context matter even inside the internal network boundary.
Common traps
- calling authorization an authentication control
- confusing non-repudiation with confidentiality
- treating zero trust like a single product purchase
- forgetting that availability is part of security, not a separate discipline
Quiz
Continue with 1.3 Change Management to connect security principles to the way security changes should actually be proposed, tested, approved, and rolled back.