JUMP TO SECTIONChoose a lesson section
Think in layers—and in failure modes.
Suppose a malicious email bypasses filtering. What happens next? Does the workstation stop untrusted code, does the user lack the privileges needed to reach critical data, and will anyone recognize the attempted abuse? The answer is your defense architecture, not your product count.
Assume one safeguard will fail.
Defense in Depth coordinates overlapping and complementary protections across people, processes and technology. The goal is to make compromise harder, detect failed or successful attempts earlier, reduce the damage of a breach, and restore critical services.
Multiple independent controls cover cases where any single safeguard misses a threat.
Identity controls, code restrictions, segments and human review address different mechanisms.
Monitoring, response procedures and tested recovery matter after prevention fails.
Layering does not mean blindly stacking products or making every application harder to use. More controls can create blind spots, conflicts and alert fatigue if nobody owns, tests or operates them. Choose controls based on threat scenarios, protected assets and realistic operating capacity.
Prevention is only one job.
Make an attempted action harder or deny it.
MFA, allowlisting, a restrictive firewall rule, least-privilege access.
Observe or alert on suspicious activity so someone can investigate.
SIEM correlation, authentication alerts, EDR detections, audit reviews.
Contain an incident, remove access or remediate the underlying weakness.
Isolate a host, revoke a session, patch a vulnerability, rotate a secret.
Restore acceptable business operations after disruption or loss.
Tested immutable backups, exercised recovery runbooks, alternate capacity.
Provide governance or physical protections supporting the technical controls.
Change control, training, keycard access, secure disposal.
One tool may serve several functions. Endpoint detection and response (EDR), for example, may prevent some executable behavior, detect other activity, and support host isolation. A firewall can deny traffic and also produce useful logs. Classify what the control does in context, rather than assigning a permanent label to the product.
Protection must follow the resource.
People & governance
Asset ownership, risk decisions, secure onboarding, staff training, incident roles and change review. These shape how technical controls are configured and maintained.
A defined process for reporting suspicious email.Identity & access
Strong authentication, least-privilege roles, conditional access, controlled admin elevation and fast account/session revocation.
Phishing-resistant MFA plus tightly scoped privileged roles.Endpoint & workload
Patch exposure, harden configurations, restrict unsafe code execution, monitor endpoint behavior and isolate compromised systems.
Application control and centrally monitored EDR.Network & boundaries
Segment critical systems, restrict east-west connections, monitor allowed paths, and apply default-deny rules where appropriate.
Workstations cannot directly administer backup repositories.Application & data
Use application authorization, secret management, data classification, encryption, logging and appropriate export protections.
A regular user cannot export every customer's financial record.Detection, response & recovery
Collect meaningful logs, prioritize alerts, practice containment, preserve incident evidence and routinely prove backup restorability.
Detect suspicious privilege use, isolate the device and restore tested data.Physical security, identity governance, cloud configuration and business continuity aren't separate from cybersecurity. A perfectly configured firewall won't protect an unsecured backup console, an overly privileged service account, or a lost recovery key.
Inside the network is not a permission slip.
Traditional perimeter assumptions often treated a successful VPN connection or internal network location as a broad sign of trust. Zero Trust aims to remove that implicit assumption: requests should be explicitly authenticated and authorized for the specific resource, with context considered by policy.
Defense in Depth and Zero Trust complement one another. Defense in Depth is the broader strategy of complementary protections; Zero Trust informs how access to resources is evaluated. Neither means removing all networks or treating an enrolled device as universally safe.
Scope privileged roles, segment sensitive services, limit reachable administrative interfaces and restrict service-account permissions. A contained compromise is still an incident, but it is not automatically an organization-wide disaster.
Turn controls on. Look for the gaps.
Select a fictional threat scenario, enable or disable the available security controls, and inspect each stage. The model explains which barrier is relevant, what it can change, and what it cannot guarantee. There is no artificial “100% secure” score.
1 relevant preventive/limiting safeguard is enabled. Each addresses a particular attempt, not every possible way an attacker could bypass it.
Telemetry could reveal suspicious activity, but no response procedure is enabled. Detection does not automatically contain an incident.
Known harmful attachment arrives in employee email
The attachment is delivered, creating a chance for user execution.
Unapproved ransomware executable attempts to launch
No modeled execution restriction blocks this sample.
Compromised workstation attempts to reach a protected file subnet
The workstation can reach the file subnet if other safeguards and permissions allow.
User session tries to modify protected administrative shares
The session lacks the privileges required for this modeled administrative action.
Suspicious execution and access events are produced
The monitored pipeline raises an actionable event for triage.
Incident team needs to isolate the device
Containing spread depends on improvisation rather than a tested workflow.
Affected files must be restored after authorized containment
Protected, tested restore points are available for the modeled recovery plan.
Educational tabletop only. Safeguards are assumed configured and effective for each specifically stated attempt. It is not a live attack, a risk score, or proof that a real threat would succeed or fail. Controls can overlap and adversaries can change techniques.
How real failures cross boundaries.
Phished password
Single point of failure: A password is the only defense.
Better layered design: Email filtering and user reporting may interrupt the lure; phishing-resistant MFA blocks the modeled password-only replay; scoped access limits misuse; sign-in telemetry and response expose and contain attempts.
MFA does not make stolen sessions, compromised endpoints or phishing-resistant-method bypasses impossible.Ransomware on a workstation
Single point of failure: The antivirus is expected to catch everything.
Better layered design: Hardened software and endpoint controls reduce execution, segmentation limits lateral paths, monitoring supports isolation, and protected/tested backups enable recovery if damage occurs.
Backups address recoverability—not confidentiality. Files already stolen cannot be made secret again by a restore.Misused vendor account
Single point of failure: The vendor logged in successfully, so the network trusts it.
Better layered design: Narrow vendor permissions and segmented access contain the blast radius, while logging, expiration and session revocation support oversight.
Strong MFA may authenticate an already-authorized vendor and does not itself reduce excessive permissions.Build a program, not just a wall.
NIST Cybersecurity Framework 2.0 organizes cybersecurity risk outcomes into six ongoing functions. These are not six sequential steps of an attack or a prescribed product checklist. They help teams connect security technology to ownership, detection, response and recovery.
Set expectations, assign risk owners and decide what adequate protection means.
Inventory assets, dependencies and risks so protection covers actual business priorities.
Limit the likelihood and impact of unwanted access or misuse.
Spot suspicious activity and unexpected conditions in time to act.
Triage, contain, communicate and remediate an active incident.
Restore services and learn whether the recovery plan met its objectives.
Good incident operations connect those functions: identify the critical asset, protect it according to risk, detect suspicious activity, respond without destroying evidence, recover within business requirements and govern improvements over time.
Ask better questions at your next customer site.
Identify the crown jewels.
Map systems, administrator accounts, sensitive data and recovery dependencies. Start with the highest-consequence business workflows.
Look for common-cause weaknesses.
Will a stolen domain admin account also delete backup copies? Does one shared identity manage all clients? Is monitoring isolated from the systems it monitors?
Validate evidence and ownership.
Confirm alerts are actionable, logs are retained, roles are clear, and someone tests that detections reach an accountable responder.
Practice containment and recovery.
Confirm isolation steps, authorized access revocation, immutable backup protections and real restore-test evidence. Record any remaining unknowns.
Disabling MFA, opening unrestricted firewall paths, deploying a random CA, or deleting protected backups may remove an error while weakening the system. Diagnose the failed layer and make an approved, measurable correction.
Can you defend your design decisions?
01If two antivirus agents run on the same workstation, is that automatically Defense in Depth?
Not necessarily. Two highly correlated controls can share a failure mode, produce conflicting actions or add little coverage. Prefer independent barriers across execution, identity, privilege, segmentation, monitoring and recovery.
02Is MFA a detective control?
MFA is primarily a preventive authentication control. Its sign-in events may also feed detection, but the purpose of requiring a second or phishing-resistant factor is to prevent unauthorized authentication.
03How is least privilege different from network segmentation?
Least privilege limits what an identity or process is authorized to do; segmentation restricts which network paths are reachable. Both reduce blast radius, but they protect different boundaries.
04Can encryption stop data theft by a fully authorized but compromised account?
Encryption protects data at rest and in transit, but an authorized session can often read plaintext. Application authorization, monitoring, data protection and privilege limits still matter.
05Does zero trust mean no one is trusted, ever?
No. The principle is not to grant implicit trust simply because a request originated from an internal network or managed device. Access should be explicitly authenticated, authorized and evaluated under appropriate policy.
06Do immutable backups stop ransomware?
They help preserve recovery points against tampering and deletion within their protection design. They don't stop initial compromise, lateral movement, data theft or every disruption, and a real restore still needs testing.
Keep the model grounded.
Illustrative educational scenarios only. Control outcomes are conditional on correct deployment, threat assumptions and ongoing operations. No real security systems are tested by the explorer.