Security concepts and program elements
Threats, vulnerabilities, exploits and mitigation techniques, plus user awareness, training and physical access control.
Threats, vulnerabilities, exploits, mitigation
Key security definitions
| Term | Definition | Example |
|---|---|---|
| Asset | Something worth protecting | Customer database, a router's config |
| Threat | Potential cause of harm to an asset | Malware, an intruder, a flood |
| Vulnerability | Weakness that could be exploited | Unpatched SSH, default password |
| Exploit | Technique/tool that uses a vulnerability | Brute-force script, buffer-overflow code |
| Risk | Likelihood × impact of a threat exploiting a vulnerability | High risk: unpatched internet-facing device |
| Mitigation | Control that reduces risk | Patch, ACL, MFA, physical lock |
Risk = threat × vulnerability × impact, roughly. You cannot control the threat — you control exposure: remove vulnerabilities, reduce impact, or transfer risk. 'Mitigation' covers every control: technical (ACLs, patching), administrative (policy, training) and physical (locks, badges).
- Event
- An attacker uses a leaked default password to log into a branch switch
- The leaked default password is the vulnerability.
- The attacker's login attempt is the threat realized via an exploit (credential reuse).
- Mitigation that would have stopped it: changed credentials at install, management ACL, or AAA with MFA.
One incident always chains vulnerability + exploit — mitigation breaks the chain anywhere.
Program elements
Security program elements
| Element | Purpose | Examples |
|---|---|---|
| User awareness | Keep threats visible to users | Phishing simulations, security bulletins |
| Training | Build the skills to act correctly | Incident handling drills, admin certification |
| Physical access control | Stop unauthorized hands reaching gear | Badge readers, locked racks, console port policy, camera coverage |
Verifying controls
- A mitigation is verified by testing it: does the ACL deny the traffic, does the locked door actually lock?
- Audits and reviews verify program elements — awareness is measured by behavior, not by attendance.
- Physical controls are verified by access logs and walk-throughs, not by policy text.
Mistakes and verification
Common mistakes
- Using 'threat' and 'vulnerability' interchangeably — threat is the actor/event; vulnerability is the weakness it needs.
- Believing training removes risk — it reduces likelihood; technical controls handle exposure.
- Treating physical access as out of scope — a console cable bypasses every network control.
- Assuming mitigation = prevention — detection and response are mitigations too.
Observation: Written password policy exists; audits still find default credentials on devices.
- Policy not enforced technically (no check at provisioning)
- Awareness gap — installers don't know the requirement
- Exceptions granted but never tracked
| Check | Indicates |
|---|---|
| Sample devices for compliance | Policy vs reality gap size. |
| Provisioning checklist | Where the control should apply but doesn't. |
| Exception register | Untracked exceptions are uncontrolled risk. |
Correction: Add a technical enforcement step and awareness follow-up; track exceptions.
Next audit shows compliance at the sampled devices.
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.