Core Security Principles
What is it?
A small set of recurring ideas — least privilege, defense in depth, need to know, separation of duties, secure defaults, and reducing the attack surface — that shape almost every security decision.
Why it matters
These principles are not tools you buy — they are how you configure and design anything, so you keep applying them long after this lesson.
Where you see it
In access-request forms, firewall rule reviews, and account permission audits.
What normal looks like
An employee has exactly the access their job requires, no more; a new system ships locked down by default.
What suspicious looks like
An account with administrator rights it never uses, or a single person who can both approve and process the same payment with no second check.
How analysts investigate
When reviewing access, ask whether this specific permission is actually needed for this specific job — and whether one control failing would leave the asset completely exposed.
Common beginner mistakes
- Thinking defense in depth means buying more tools — it means layering different kinds of protection so one failure is not the whole story.
- Granting broad access 'to be safe' or 'just in case' — that is the opposite of least privilege and quietly grows the attack surface.
A new intern at NovaCore is given full administrator access to the finance system 'to save time later.' Two principles are already being broken.
- Need to know — access to information, not just systems, should match the job.
- Separation of duties — no single person should both approve and execute the same sensitive action alone.
- Secure defaults — a new system should start locked down, not wide open.
- Attack surface reduction — fewer exposed services and permissions means fewer ways in.
Quick check
Which principle does the intern's 'full admin access to save time' violate most directly?
A quick self-check — it doesn't affect your XP or progress.
One control is never enough
Defense in depth means stacking different kinds of protection, so that a single mistake — an employee clicking a bad link — does not immediately become a full compromise.
The intern's admin access, principle by principle
The new intern was given full administrator access to the finance system 'to save time later.' Name every principle that breaks, and design the access that would have been correct.
Measure the grant against the actual job.
An intern's job needs, say, read access to a few reports. Full admin over the finance system is vastly more than that — a direct least-privilege violation. A tempting false lead is 'it's just an intern, low risk'; but the size of the access, not the person's seniority, is what defines the exposure.
Look for the second, quieter violation.
Admin rights on finance usually mean the intern could both create and approve a payment — no second person in the loop. That breaks separation of duties, the control that stops one person alone from completing a sensitive action. And every unused admin right also enlarges the attack surface: if the intern is phished, the attacker inherits full finance admin, not read-only.
Design the correct access and state why layering still matters.
Correct design: give the intern read access to exactly the reports the role needs (least privilege + need to know), require a second approver for payments (separation of duties), and start the account locked down, adding rights only on request (secure defaults). Even then, no single principle guarantees safety — defense in depth means if one control fails, the others still limit the damage. The fix is not one setting; it is the stack.
Sign in to save your progress on the server.