Quick Review Purpose
This independent Quick Review is for candidates preparing for the real CompTIA Security+ V8 (SY0-801) exam from CompTIA. Use it to refresh high-yield concepts before moving into topic drills, mock exams, original practice questions, and detailed explanations.
Security+ questions often test whether you can choose the best control, next step, root cause, or most likely attack in a short scenario. Memorization helps, but the exam rewards practical judgment: protect confidentiality, integrity, and availability; reduce risk; preserve evidence; and select controls that fit the business and technical context.
High-Yield Exam Mindset
| If the question asks… | Think first about… | Common trap |
|---|
| “Best” control | The control that directly reduces the stated risk with least unnecessary complexity | Choosing the most advanced tool instead of the most relevant one |
| “First” step in incident response | Safety, scope, preservation, containment plan, and procedure | Jumping to eradication before identifying or containing |
| “Most likely attack” | Clues in symptoms, logs, user behavior, and affected layer | Matching on buzzwords only |
| “Most secure” design | Least privilege, segmentation, strong identity, encryption, monitoring | Ignoring availability or operational fit |
| “Cost-effective” option | Risk reduction proportional to cost and complexity | Picking enterprise tools where policy or configuration would solve it |
| “Cloud responsibility” | What the provider secures vs. what the customer configures | Assuming the cloud provider secures customer data, IAM, and app settings |
| “Compliance” or “governance” | Policy, evidence, accountability, audits, data handling | Treating compliance as the same thing as security |
Core Security Objectives
| Concept | Meaning | Example controls |
|---|
| Confidentiality | Prevent unauthorized disclosure | Encryption, access control, data classification, DLP |
| Integrity | Prevent unauthorized modification | Hashing, digital signatures, change control, file integrity monitoring |
| Availability | Keep systems and data usable | Redundancy, backups, DDoS protection, clustering |
| Non-repudiation | Prevent denial of an action | Digital signatures, signed logs, timestamps |
| Authentication | Prove identity | Passwords, MFA, certificates, biometrics |
| Authorization | Grant appropriate access | RBAC, ABAC, ACLs, policy engines |
| Accounting / auditing | Record activity | Logs, SIEM, audit trails |
Risk Basics
Security decisions usually balance likelihood, impact, cost, and operational needs.
\[
\text{Risk} = \text{Likelihood} \times \text{Impact}
\]
| Risk term | Review meaning |
|---|
| Asset | Something valuable: data, system, service, people, reputation |
| Threat | Potential cause of harm |
| Vulnerability | Weakness that can be exploited |
| Impact | Damage if the event occurs |
| Likelihood | Probability or frequency of occurrence |
| Inherent risk | Risk before controls |
| Residual risk | Risk remaining after controls |
| Risk appetite | Amount of risk the organization is willing to accept |
| Risk tolerance | Acceptable variance around risk appetite |
Risk Response Options
| Response | Use when… | Example |
|---|
| Mitigate | Reduce likelihood or impact | Patch, segment, enable MFA |
| Transfer | Shift financial or operational consequence | Cyber insurance, outsourcing |
| Avoid | Stop the risky activity | Retire exposed legacy service |
| Accept | Risk is within tolerance | Documented exception for low-risk issue |
Control Types and Functions
Control Categories
| Category | What it is | Examples |
|---|
| Administrative | Policies, procedures, governance | Security policy, training, background checks |
| Technical | Technology-enforced controls | Firewall, MFA, EDR, encryption |
| Physical | Protect facilities and hardware | Locks, guards, cameras, mantraps |
Control Functions
| Function | Purpose | Example |
|---|
| Preventive | Stop an event before it happens | ACL, firewall rule, least privilege |
| Detective | Identify that something happened | IDS, SIEM alert, audit log |
| Corrective | Restore after an event | Patch, restore from backup |
| Deterrent | Discourage behavior | Warning banner, camera |
| Compensating | Alternative control when primary is not feasible | Extra monitoring for legacy system |
| Directive | Tell people what to do | Policy, standard, procedure |
Quick trap: A control can belong to more than one idea depending on context. A camera may be detective if used to review footage, deterrent if visible, and physical because of the control category.
Identity and Access Management
Authentication Factors
| Factor | Description | Examples |
|---|
| Something you know | Secret knowledge | Password, PIN |
| Something you have | Physical or digital possession | Smart card, hardware token, authenticator app |
| Something you are | Biometric trait | Fingerprint, face, iris |
| Somewhere you are | Location context | Geolocation, network zone |
| Something you do | Behavioral pattern | Typing cadence, gesture pattern |
MFA requires different factor types. A password plus a PIN is not strong MFA because both are “something you know.”
Access Control Models
| Model | Key idea | Best fit |
|---|
| DAC | Owner controls access | Small environments, file ownership |
| MAC | System-enforced labels | High-security classified environments |
| RBAC | Access based on role | Enterprise job functions |
| ABAC | Access based on attributes and context | Dynamic access decisions |
| Rule-based | Access follows configured rules | Firewall rules, time-based access |
Account and Privilege Controls
| Control | Why it matters |
|---|
| Least privilege | Users and services get only required access |
| Just-in-time access | Privilege granted temporarily when needed |
| Privileged access management | Controls and monitors admin accounts |
| Separation of duties | Prevents one person from completing sensitive actions alone |
| Job rotation | Helps detect fraud and reduces dependency |
| Mandatory vacation | Can expose hidden fraud or misuse |
| Account recertification | Confirms access is still appropriate |
| Deprovisioning | Removes access when users leave or change roles |
Federation and SSO
| Term | Review meaning |
|---|
| SSO | One authentication event grants access to multiple services |
| Federation | Trust relationship between identity provider and service provider |
| SAML | Common XML-based enterprise federation protocol |
| OAuth | Authorization framework for delegated access |
| OIDC | Authentication layer built on OAuth 2.0 |
| Kerberos | Ticket-based authentication in many enterprise networks |
| RADIUS | Centralized authentication often used for VPN, Wi-Fi, network access |
| TACACS+ | Device administration authentication, authorization, and accounting |
Common trap: OAuth is commonly about delegated authorization. If the question is about proving user identity to an application, OIDC is usually the closer answer.
Threats, Attacks, and Indicators
Social Engineering
| Attack | Key clues | Best defenses |
|---|
| Phishing | Broad fraudulent email | Awareness, filtering, reporting, MFA |
| Spear phishing | Targeted phishing | Training, verification process, anti-spoofing controls |
| Whaling | Targets executives | Executive training, payment verification |
| Vishing | Voice-based deception | Call-back procedures, help desk scripts |
| Smishing | SMS-based deception | User awareness, mobile security |
| Pretexting | Fabricated scenario | Verification and least disclosure |
| Baiting | Enticing user with reward/media | Device control, training |
| Tailgating | Following authorized person | Badges, mantraps, challenge culture |
Malware and Host-Based Threats
| Threat | What to recognize |
|---|
| Virus | Attaches to files and needs user/system action |
| Worm | Self-propagates across networks |
| Trojan | Disguises malicious function as legitimate software |
| Ransomware | Encrypts or exfiltrates data for extortion |
| Rootkit | Hides privileged compromise |
| Keylogger | Captures keystrokes |
| Spyware | Monitors user activity |
| Logic bomb | Triggers on condition/date |
| Fileless malware | Uses memory and legitimate tools |
| Botnet | Compromised systems controlled by attacker |
Network Attacks
| Attack | Symptom or clue | Defensive focus |
|---|
| DDoS | Service exhaustion from many sources | DDoS protection, rate limiting, CDN |
| DNS poisoning | Users redirected to wrong IP | DNSSEC, secure DNS configuration |
| ARP spoofing | LAN traffic redirected through attacker | Dynamic ARP inspection, segmentation |
| Evil twin | Fake Wi-Fi access point | WPA3/WPA2-Enterprise, certificate validation |
| Rogue AP | Unauthorized access point | Wireless scans, NAC |
| On-path attack | Attacker intercepts traffic | TLS, VPN, certificate validation |
| Replay attack | Captured valid traffic reused | Nonces, timestamps, session protection |
| VLAN hopping | Unauthorized VLAN access | Disable trunking, native VLAN controls |
| MAC flooding | Switch CAM table exhaustion | Port security |
| Credential stuffing | Reused credentials tried at scale | MFA, rate limiting, password monitoring |
| Password spraying | Few common passwords across many accounts | Lockout strategy, MFA, monitoring |
Application and Web Attacks
| Attack | Core issue | Prevention |
|---|
| SQL injection | Untrusted input alters database query | Parameterized queries, input validation |
| Command injection | Input executes OS commands | Input validation, safe APIs, least privilege |
| XSS | Malicious script runs in user browser | Output encoding, CSP, input validation |
| CSRF | User is tricked into submitting authenticated request | Anti-CSRF tokens, SameSite cookies |
| SSRF | Server is tricked into requesting internal resource | Allow lists, metadata protection |
| Directory traversal | Input accesses unauthorized paths | Canonicalization, input validation |
| Insecure deserialization | Serialized data triggers code/object abuse | Avoid unsafe deserialization, integrity checks |
| Buffer overflow | Memory overwritten | Bounds checking, memory protections |
| Race condition | Timing flaw changes outcome | Locking, atomic operations |
| API abuse | Weak auth, rate limits, validation | API gateway, auth, throttling, schema validation |
Injection decision rule: If user-controlled input changes the meaning of a command, query, or interpreter instruction, think injection.
Vulnerability Management
Standard Workflow
flowchart LR
A[Inventory assets] --> B[Scan and collect findings]
B --> C[Validate findings]
C --> D[Prioritize by risk]
D --> E[Remediate or mitigate]
E --> F[Verify fix]
F --> G[Report and improve]
Scanning and Testing
| Method | Purpose | Trap |
|---|
| Non-credentialed scan | External view with limited insight | May miss local misconfigurations |
| Credentialed scan | Authenticated view of system state | Requires secure credential handling |
| Agent-based scan | Local continuous visibility | Agent deployment and coverage matter |
| Passive scan | Observes traffic without probing | May miss inactive systems |
| Penetration test | Demonstrates exploitability and impact | Not the same as a routine vulnerability scan |
| Red team | Tests detection and response against realistic attacker behavior | Broader than finding CVEs |
| Bug bounty | External researchers report issues | Requires scope and triage process |
Prioritization Factors
Prioritize using more than a severity label. Consider:
- Exploitability in the current environment
- Asset criticality
- Internet exposure
- Data sensitivity
- Known active exploitation
- Compensating controls
- Business impact of remediation
- Availability of patches or mitigations
Common trap: The highest numeric vulnerability score is not always the first patch if a lower-scored issue is actively exploited on a public-facing critical system.
Cryptography and PKI
Cryptographic Building Blocks
| Concept | Purpose | Examples / notes |
|---|
| Symmetric encryption | Fast encryption with same key | Used for bulk data encryption |
| Asymmetric encryption | Public/private key pair | Key exchange, digital signatures, certificates |
| Hashing | One-way integrity check | Same input should produce same digest |
| Salting | Adds randomness to password hashing | Defends against rainbow tables |
| HMAC | Integrity and authenticity with shared secret | Hash plus secret key |
| Digital signature | Integrity, authenticity, non-repudiation | Created with private key, verified with public key |
| Key exchange | Establish shared secret | Used in secure session setup |
| Perfect forward secrecy | Past sessions stay protected if long-term key is compromised | Uses ephemeral session keys |
PKI Terms
| Term | Meaning |
|---|
| CA | Certificate authority that issues certificates |
| RA | Registration authority that verifies identity information |
| CSR | Certificate signing request |
| CRL | Certificate revocation list |
| OCSP | Online certificate status checking |
| SAN | Subject alternative name; common for DNS names in certificates |
| Wildcard certificate | Covers multiple subdomains at a level |
| Self-signed certificate | Not trusted by default unless explicitly trusted |
| Certificate pinning | Application expects a specific certificate or public key |
Certificate Troubleshooting Clues
| Symptom | Likely issue |
|---|
| Browser says name mismatch | CN/SAN does not match requested hostname |
| Certificate expired | Validity period ended |
| Untrusted issuer | CA not trusted or missing chain |
| Revoked certificate | CRL/OCSP indicates invalid certificate |
| Users warned after TLS inspection | Endpoint does not trust inspection CA |
| Works by IP but not hostname | Name validation or DNS issue |
Quick trap: Hashing is not encryption. If the data must be recovered, use encryption. If the goal is integrity verification, use hashing or signatures.
Network Security Review
Common Ports and Protocols
| Protocol | Port(s) | Review use |
|---|
| FTP | 20/21 | Insecure file transfer |
| SSH / SFTP | 22 | Secure remote administration / file transfer |
| Telnet | 23 | Insecure remote terminal |
| SMTP | 25 | Mail transfer |
| DNS | 53 | Name resolution |
| DHCP | 67/68 | Dynamic addressing |
| HTTP | 80 | Web traffic, not encrypted |
| Kerberos | 88 | Ticket-based authentication |
| POP3 | 110 | Mail retrieval |
| NTP | 123 | Time synchronization |
| IMAP | 143 | Mail access |
| SNMP | 161/162 | Network management and traps |
| LDAP | 389 | Directory services |
| HTTPS | 443 | HTTP over TLS |
| SMB | 445 | Windows file sharing |
| SMTPS / submission | 465/587 | Secure mail submission contexts |
| LDAPS | 636 | LDAP over TLS |
| Syslog | 514 / 6514 | Logging; 6514 commonly TLS-protected |
| RADIUS | 1812/1813 | Authentication/accounting |
| RDP | 3389 | Remote desktop |
Network Security Devices and Services
| Technology | Primary role |
|---|
| Firewall | Permit or deny traffic based on rules |
| NGFW | Adds application awareness, identity, threat features |
| WAF | Protects web applications from HTTP-layer attacks |
| IDS | Detects suspicious activity |
| IPS | Blocks or prevents suspicious activity |
| Proxy | Intermediates client requests |
| Reverse proxy | Fronts servers and can add security/performance controls |
| VPN | Encrypted tunnel over untrusted network |
| NAC | Enforces device/user posture before network access |
| DLP | Detects or prevents sensitive data movement |
| SIEM | Aggregates and correlates logs |
| SOAR | Automates response workflows |
| EDR | Endpoint detection and response |
| XDR | Correlates detection across multiple telemetry sources |
Segmentation Concepts
| Concept | Purpose |
|---|
| VLAN | Logical network segmentation |
| Subnet | IP-level segmentation |
| DMZ | Exposes public services while limiting internal access |
| Microsegmentation | Fine-grained workload-to-workload control |
| Jump server | Controlled administrative access path |
| Bastion host | Hardened exposed host for a specific purpose |
| Air gap | Physical/logical isolation from networks |
| Zero trust | Never trust solely based on network location; verify continuously |
Segmentation decision rule: Place public-facing services in a DMZ, restrict management interfaces, limit east-west movement, and allow only required traffic.
Wireless and Mobile Security
Wireless Security
| Topic | Review point |
|---|
| WPA2/WPA3-Personal | Uses pre-shared key; suitable for smaller/simple environments |
| WPA2/WPA3-Enterprise | Uses 802.1X authentication; better for organizations |
| WPS | Convenience feature; often disabled for security |
| Captive portal | Web-based network access flow; not equivalent to strong encryption |
| Site survey | Identifies coverage, interference, and rogue devices |
| Guest Wi-Fi | Should be segmented from internal networks |
Mobile Device Management
| Control | Use |
|---|
| MDM | Enforce device policies, wipe, inventory |
| MAM | Manage specific applications and data |
| Containerization | Separate corporate and personal data |
| Remote wipe | Remove data from lost/stolen devices |
| Full-device encryption | Protect data at rest |
| Geofencing | Apply controls based on location |
| Sideloading restrictions | Reduce untrusted app installation |
Common trap: BYOD requires policy and technical enforcement. Encryption alone does not solve app risk, data leakage, or account deprovisioning.
Cloud, Virtualization, and Modern Architecture
Shared Responsibility
| Cloud model | Provider generally handles more of… | Customer generally handles more of… |
|---|
| IaaS | Physical infrastructure, virtualization platform | OS, applications, data, IAM configuration |
| PaaS | Infrastructure, runtime platform | Application logic, data, access settings |
| SaaS | Application platform and infrastructure | Users, data, configuration, access governance |
Cloud trap: Misconfigured storage, excessive IAM permissions, exposed secrets, and weak logging are often customer-side risks.
| Term | Review use |
|---|
| CASB | Visibility and policy enforcement for cloud service use |
| CSPM | Finds cloud configuration risks |
| CWPP | Protects cloud workloads |
| IaC scanning | Detects risky infrastructure templates before deployment |
| Secrets management | Stores and rotates credentials securely |
| KMS / HSM | Key management and hardware-backed key protection |
| Security groups | Instance or workload-level traffic filtering |
| VPC/VNet | Isolated cloud network boundary |
| Private endpoint | Access service without public internet exposure |
| Immutable infrastructure | Replace rather than manually modify systems |
Containers and Orchestration
| Topic | Review point |
|---|
| Container image | Should be scanned, signed, and minimal |
| Registry | Must enforce access control and integrity |
| Orchestrator | Needs secure API, RBAC, secrets, network policies |
| Container escape | Breakout from container isolation |
| Sidecar | Helper container for logging, proxying, security functions |
| Secrets | Should not be baked into images or committed to repositories |
Secure Application and DevSecOps Review
Secure SDLC
| Phase | Security activity |
|---|
| Requirements | Define security and privacy requirements |
| Design | Threat modeling, architecture review |
| Development | Secure coding, code review, dependency management |
| Testing | SAST, DAST, IAST, fuzzing, penetration testing |
| Deployment | Harden configuration, sign releases, protect secrets |
| Operations | Monitor, patch, log, improve |
Testing Types
| Test | What it examines |
|---|
| SAST | Source code or binaries without running the app |
| DAST | Running application from outside |
| IAST | Runtime testing with instrumentation |
| Fuzzing | Unexpected, malformed, or random input |
| Dependency scan | Vulnerable third-party libraries |
| SCA | Software composition analysis |
| SBOM | Inventory of software components |
| Regression testing | Confirms changes did not break expected behavior |
Secure Coding Rules
- Validate input on the server side.
- Encode output for the correct context.
- Use parameterized queries.
- Avoid hardcoded secrets.
- Enforce authentication and authorization on every sensitive function.
- Fail securely.
- Log security events without exposing secrets.
- Use secure defaults.
- Keep dependencies updated.
- Protect CI/CD pipelines and signing keys.
Data Security and Privacy
Data States
| State | Meaning | Controls |
|---|
| Data at rest | Stored data | Disk/database encryption, access control |
| Data in transit | Moving across networks | TLS, VPN, secure protocols |
| Data in use | Being processed | Memory protections, secure enclaves, access control |
Data Handling
| Concept | Review point |
|---|
| Classification | Labels data by sensitivity |
| Labeling | Marks data so handling rules can be applied |
| Tokenization | Replaces sensitive data with non-sensitive token |
| Masking | Hides part of data from view |
| Anonymization | Removes identifying information |
| Pseudonymization | Replaces identifiers but may be reversible with extra data |
| Retention | Defines how long data is kept |
| Disposal | Secure deletion, shredding, crypto-erasure |
| Data minimization | Collect only what is needed |
| DLP | Detects or prevents sensitive data exposure |
Trap: Encryption protects confidentiality, but it does not automatically enforce retention, minimization, consent, or appropriate access.
Security Operations
Logging and Monitoring
| Log source | What it helps detect |
|---|
| Authentication logs | Brute force, impossible travel, privilege misuse |
| Endpoint logs | Malware, process execution, persistence |
| Firewall logs | Blocked/allowed traffic patterns |
| DNS logs | Malware callbacks, tunneling, suspicious domains |
| Web server logs | Injection, scanning, unusual requests |
| Cloud audit logs | IAM changes, public exposure, API activity |
| EDR telemetry | Suspicious process, registry, memory, network behavior |
| Application logs | Business logic abuse, errors, suspicious actions |
SIEM Tuning Terms
| Term | Meaning |
|---|
| True positive | Alert correctly identifies malicious/suspicious activity |
| False positive | Alert fires on benign activity |
| True negative | No alert and no issue |
| False negative | Issue occurs but no alert fires |
| Correlation rule | Combines events to identify patterns |
| Baseline | Normal behavior used for comparison |
| Alert fatigue | Too many low-quality alerts reduce effectiveness |
Hardening Checklist
- Disable unnecessary services.
- Remove default accounts and passwords.
- Apply secure configuration baselines.
- Enforce least privilege.
- Enable host firewall.
- Patch operating systems and applications.
- Configure logging and time synchronization.
- Use secure protocols.
- Protect management interfaces.
- Validate backups and recovery procedures.
Incident Response
Standard Flow
flowchart TD
A[Preparation] --> B[Identification]
B --> C[Containment]
C --> D[Eradication]
D --> E[Recovery]
E --> F[Lessons learned]
F --> A
Incident Response Phases
| Phase | What to do | Avoid |
|---|
| Preparation | Policies, tools, contacts, playbooks, training | Waiting until an incident to define roles |
| Identification | Confirm incident, scope impact, collect indicators | Declaring root cause too early |
| Containment | Limit spread and damage | Destroying evidence unnecessarily |
| Eradication | Remove malware, close vulnerability, reset credentials | Restoring without fixing cause |
| Recovery | Return systems safely, monitor closely | Bringing systems online without validation |
| Lessons learned | Improve controls, documentation, detection | Treating the incident as “over” after recovery |
First Action Decision Rules
| Scenario clue | Likely best first action |
|---|
| Active safety risk | Protect people and critical operations |
| Possible legal/evidence issue | Preserve evidence and follow chain of custody |
| Malware spreading | Contain affected systems |
| Unconfirmed alert | Validate and scope |
| Compromised credentials | Disable/reset affected credentials and investigate use |
| Public data exposure | Follow incident plan, contain exposure, notify internal stakeholders per procedure |
| Ransomware | Isolate affected systems, preserve evidence, activate response plan |
Digital Forensics and Evidence
Evidence Principles
| Concept | Meaning |
|---|
| Chain of custody | Document who handled evidence, when, where, and why |
| Integrity | Evidence must not be altered |
| Hashing | Verifies evidence copy integrity |
| Legal hold | Preserve relevant data for legal/regulatory reasons |
| Write blocker | Prevents modification during acquisition |
| Order of volatility | Collect most temporary data first when appropriate |
Volatility Review
Most volatile evidence disappears first. A typical order is:
- CPU registers/cache
- RAM
- Network connections and running processes
- Disk data
- Logs and remote monitoring data
- Backups and archives
Common trap: Pulling the power may preserve disk state but destroy volatile memory. The best action depends on the incident plan, evidence needs, and safety.
Business Continuity and Disaster Recovery
Key Metrics
| Metric | Meaning | Common confusion |
|---|
| RTO | Maximum acceptable time to restore service | Time, not data loss |
| RPO | Maximum acceptable data loss measured in time | Data loss window, not restore time |
| MTD / MAO | Maximum tolerable downtime/outage | Business limit before unacceptable harm |
| MTTR | Mean time to repair/recover | Operational repair average |
| MTBF | Mean time between failures | Reliability measure |
Backup Types
| Backup | Strength | Limitation |
|---|
| Full | Complete copy | More time/storage |
| Incremental | Changes since last backup | Faster backup, slower restore chain |
| Differential | Changes since last full backup | Larger over time, simpler restore than incremental |
| Snapshot | Point-in-time state | Must be protected from compromise |
| Offline backup | Isolated from network attacks | Slower access |
| Immutable backup | Cannot be altered for set period | Requires correct retention design |
Resilience Concepts
| Concept | Purpose |
|---|
| High availability | Reduce downtime |
| Fault tolerance | Continue operating despite failure |
| Redundancy | Duplicate components |
| Load balancing | Distribute traffic |
| Clustering | Multiple systems work together |
| Geographic diversity | Reduce regional outage impact |
| Tabletop exercise | Discussion-based plan validation |
| Failover test | Confirms alternate systems work |
Ransomware trap: Backups only help if they are restorable, protected, recent enough for the RPO, and not encrypted or deleted by the attacker.
Governance, Risk, and Compliance
Policy and Documentation
| Document | Purpose |
|---|
| Policy | High-level management intent |
| Standard | Mandatory specific requirement |
| Procedure | Step-by-step instructions |
| Guideline | Recommended practice |
| Baseline | Minimum secure configuration |
| AUP | Acceptable use of systems |
| NDA | Confidentiality agreement |
| SLA | Service performance expectations |
| MOU/MOA | Agreement between parties |
| BPA | Business partnership agreement |
Third-Party and Supply Chain Risk
| Review area | What to check |
|---|
| Vendor due diligence | Security posture before onboarding |
| Contract terms | Security requirements, audit rights, breach notification |
| Data access | Minimum necessary access |
| Fourth-party risk | Vendor’s vendors |
| Software supply chain | Dependencies, signing, SBOM, repository security |
| Ongoing monitoring | Reassess risk over time |
| Offboarding | Remove access and return/destroy data |
Personnel Security
| Control | Purpose |
|---|
| Background checks | Reduce hiring risk where appropriate |
| Onboarding | Assign correct access and training |
| Offboarding | Remove access promptly |
| User training | Reduce human risk |
| Role changes | Update access when duties change |
| Insider threat program | Detect and manage misuse risk |
Physical Security
| Control | Purpose |
|---|
| Bollards | Stop vehicle impact |
| Fencing | Perimeter control |
| Badges | Identify authorized personnel |
| Biometrics | Strong identity verification |
| Mantrap | Prevent tailgating |
| Cameras | Deterrence and investigation |
| Guards | Human verification and response |
| Locks | Restrict physical access |
| Faraday cage | Block electromagnetic signals |
| Fire suppression | Protect facilities and equipment |
| HVAC | Maintain safe operating environment |
| UPS / generator | Maintain power availability |
Physical security trap: If an attacker has uncontrolled physical access, many technical controls become easier to bypass.
Common “Best Answer” Patterns
When Two Answers Look Correct
Ask:
- Which answer addresses the stated risk most directly?
- Which answer fits the phase of the process?
- Which answer is preventive vs. detective vs. corrective as requested?
- Which answer preserves evidence and follows procedure?
- Which answer is least disruptive while still effective?
- Which answer is scalable and manageable?
- Which answer is appropriate for cloud, mobile, or on-premises context?
- Which answer solves root cause rather than symptoms?
Frequent Candidate Mistakes
- Confusing encryption with hashing.
- Treating authentication and authorization as the same thing.
- Selecting a tool before defining the requirement.
- Skipping containment in incident response.
- Ignoring chain of custody.
- Assuming a vulnerability scan proves exploitability.
- Assuming compliance means secure.
- Picking “deny all” without allowing required business traffic.
- Forgetting that availability is part of security.
- Overlooking misconfiguration as a major cloud risk.
- Confusing RTO and RPO.
- Forgetting that MFA must use different factor types.
- Selecting public cloud provider responsibility for customer-side IAM or data mistakes.
- Choosing eradication before identification and containment.
- Choosing a technical control when the scenario asks for policy, governance, or training.
Rapid Review Tables
Attack to Control Matching
| If you see… | Think… |
|---|
| Reused passwords abused across services | MFA, password monitoring, user education |
| Many accounts tried with one common password | Password spraying |
| One account tried with many passwords | Brute force |
| Login from impossible locations | Account compromise / impossible travel analytics |
| Sensitive data leaving by email | DLP |
| Web app database errors after input | SQL injection |
| Browser executes injected script | XSS |
| User tricked into making authenticated request | CSRF |
| Internal metadata service accessed through app | SSRF |
| Unknown device on switch port | NAC / port security |
| Public bucket with sensitive files | Cloud misconfiguration |
| Admin account used at unusual time | Privileged account monitoring |
| Malware beaconing to domains | DNS logs, EDR, network detection |
| Logs across systems need correlation | SIEM |
| Repetitive response steps | SOAR playbook |
| Need | Likely tool/control |
|---|
| Block malicious HTTP requests to web app | WAF |
| Inspect endpoint behavior | EDR |
| Correlate logs from many sources | SIEM |
| Automate alert response | SOAR |
| Enforce data movement rules | DLP |
| Authenticate network access | NAC / 802.1X |
| Manage mobile devices | MDM |
| Control SaaS usage | CASB |
| Detect cloud misconfiguration | CSPM |
| Protect cloud workloads | CWPP |
| Store and rotate secrets | Secrets manager |
| Verify file integrity | Hash / file integrity monitoring |
| Prove software publisher | Code signing |
| Protect keys strongly | HSM / KMS |
Final Quick Checklist Before Practice
Before you start topic drills or mock exams for SY0-801, make sure you can quickly explain:
- CIA triad and how controls map to it.
- Administrative, technical, and physical controls.
- Preventive, detective, corrective, deterrent, directive, and compensating controls.
- Authentication vs. authorization vs. accounting.
- MFA factor types and common identity protocols.
- Common attacks and their indicators.
- Injection, XSS, CSRF, SSRF, and directory traversal differences.
- Symmetric encryption, asymmetric encryption, hashing, HMAC, and digital signatures.
- PKI certificate trust and revocation basics.
- Firewall, IDS, IPS, WAF, proxy, VPN, NAC, DLP, EDR, SIEM, and SOAR roles.
- Cloud shared responsibility and common cloud misconfigurations.
- Vulnerability scan vs. penetration test vs. red team.
- Incident response order and evidence preservation.
- RTO vs. RPO and backup strategy tradeoffs.
- Data classification, retention, masking, tokenization, and disposal.
- Secure SDLC testing methods and CI/CD risks.
- Governance documents and third-party risk controls.
Practice Connection
Use this Quick Review as a checkpoint, not a replacement for practice. After reviewing the tables, move into IT Mastery practice with original practice questions, focused topic drills, timed mock exams, and detailed explanations. When you miss a question, identify whether the issue was vocabulary, scenario interpretation, process order, or choosing a control that did not match the risk.
A practical next step: choose one weak area, complete a short question bank drill on that topic, review every explanation carefully, and then retest the same objective under timed conditions.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official CompTIA questions, copied live-exam content, or exam dumps.