Quick Reference focus
This independent Quick Reference is for candidates preparing for CompTIA SecurityX (CAS-005). Use it to review advanced security architecture, engineering, operations, and governance decision points before doing original practice questions and performance-based tasks.
SecurityX questions often ask for the best control in context, not just a definition. Anchor each answer on:
| Exam cue | Ask yourself | Strong answer pattern |
|---|
| Enterprise architecture | What reduces risk at scale without breaking operations? | Layered controls, segmentation, identity-first access, automation, measurable governance |
| “Most secure” | What blocks the threat while preserving business requirements? | Least privilege, deny by default, strong crypto, managed keys, centralized logging |
| “Best next step” | What phase is the team in? | Identify before contain; contain before eradicate; validate before closeout |
| “Cost-effective” | Can an existing control or managed service solve it? | Prioritize risk reduction, automation, and operational simplicity |
| “Compliance” | What provides evidence and repeatability? | Policies, standards, control mapping, audit trails, exception process |
| “Zero trust” | Is access continuously evaluated? | Identity, device posture, context, segmentation, least privilege, telemetry |
| “High availability” | What fails over without data loss beyond tolerance? | RTO/RPO-driven design, redundancy, tested recovery |
| “Cloud security” | Who owns the control in the shared model? | IAM, data protection, configuration, monitoring, and workload security |
Architecture decision matrix
| Requirement | Prefer | Why | Watch for |
|---|
| Replace broad network VPN access | ZTNA | App-level access, identity/context checks, reduced lateral movement | ZTNA is not “install MFA and keep flat network” |
| Limit east-west movement | Microsegmentation | Controls workload-to-workload communication | Needs asset inventory and policy lifecycle |
| Secure remote branch/cloud access | SASE/SSE pattern | Combines secure web gateway, CASB, ZTNA, DLP, policy enforcement | Avoid assuming all SASE products provide identical controls |
| Protect web apps from common attacks | WAF + secure code fixes | WAF reduces exposure; code fixes remove root cause | WAF is compensating, not a substitute for remediation |
| Protect APIs | API gateway + authz + schema validation + rate limits | Handles authentication, authorization, throttling, logging | OAuth scopes are not enough without object-level authorization |
| Isolate privileged administration | PAM + jump host/bastion + session recording | Controls, monitors, and limits admin paths | Shared admin accounts break attribution |
| Reduce credential theft impact | Phishing-resistant MFA + conditional access + PAM | Stronger auth and just-in-time privilege | SMS/OTP MFA is weaker than FIDO2/WebAuthn |
| Meet strict key custody needs | HSM or cloud KMS with appropriate key ownership model | Protects key material and centralizes lifecycle | BYOK/HYOK improves control but adds operational burden |
| Detect unknown endpoint behavior | EDR/XDR | Behavioral telemetry, response actions, investigation | EDR does not replace hardening and patching |
| Detect network lateral movement | NDR | East-west traffic analytics and anomaly detection | Encrypted traffic may need metadata or endpoint correlation |
| Centralize event correlation | SIEM | Log aggregation, rules, correlation, investigation | SIEM detects; it does not automatically remediate |
| Automate repetitive response | SOAR | Playbooks, enrichment, ticketing, containment | Bad playbooks can amplify false positives |
| Protect SaaS usage and data | CASB | Visibility, DLP, access controls, shadow IT discovery | Needs integration with IdP and SaaS platforms |
| Reduce cloud misconfiguration | CSPM + policy as code | Continuous posture checks and guardrails | Findings still require ownership and remediation workflow |
| Protect cloud workloads | CWPP | Runtime, host, container, and workload protection | Different from CSPM, which focuses on posture |
| Unified cloud security program | CNAPP | Combines posture, workload, identity, IaC, and runtime views | Do not assume one tool removes need for architecture decisions |
Zero trust reference
Zero trust is an architecture approach, not a single product.
| Principle | Practical implementation | Evidence to look for |
|---|
| Verify explicitly | Strong identity, device posture, location, risk score, app sensitivity | Conditional access policies, IdP logs, device compliance |
| Least privilege | RBAC/ABAC, JIT/JEA admin, scoped tokens, short-lived credentials | Access reviews, privilege reports, PAM logs |
| Assume breach | Segmentation, continuous monitoring, deception, rapid containment | EDR/NDR telemetry, segmentation policy, tested IR playbooks |
| Continuous evaluation | Reassess sessions based on risk changes | Token revocation, re-auth triggers, adaptive policies |
| Protect data | Classification, encryption, DLP, tokenization, retention controls | Data inventory, DLP incidents, key management logs |
Zero trust traps
| Trap | Correct interpretation |
|---|
| “We use MFA, so we have zero trust.” | MFA is one control. Zero trust also needs least privilege, context, segmentation, telemetry, and continuous enforcement. |
| “Zero trust means no network controls.” | Network segmentation still matters; zero trust reduces implicit trust. |
| “ZTNA is always better than VPN.” | ZTNA is preferred for app-specific access; VPN may still exist for legacy or administrative use with compensating controls. |
| “Device trust is permanent.” | Device posture should be continuously checked and can change during a session. |
IAM and access control
Protocols and identity components
| Component | Use when | Key details | Common trap |
|---|
| SAML 2.0 | Enterprise browser-based SSO | XML assertions between IdP and service provider | Good for federation, not modern API authorization |
| OAuth 2.0 | Delegated authorization | Access tokens grant scoped access to resources | OAuth is not an authentication protocol by itself |
| OpenID Connect | Authentication on top of OAuth 2.0 | Adds ID token and user identity claims | Do not use ID token as API authorization token |
| Kerberos | Internal enterprise authentication | KDC, tickets, mutual auth, time sensitivity | Clock skew and SPN issues cause failures |
| LDAP/LDAPS | Directory queries and identity store access | LDAPS protects directory traffic | LDAP is not the same as SSO |
| RADIUS | Network access authentication | Common for VPN, Wi-Fi, NAC | Limited command authorization |
| TACACS+ | Network device administration | Separates authn, authz, and accounting | Preferred for granular admin command control |
| SCIM | Identity provisioning | Automates user/group lifecycle into SaaS apps | Federation without provisioning leaves orphaned accounts |
| FIDO2/WebAuthn | Phishing-resistant MFA | Public key authentication, origin binding | Stronger than SMS or push-only MFA |
Access models
| Model | Best fit | Strength | Weakness |
|---|
| RBAC | Job roles are stable | Simple to audit and administer | Role explosion in complex environments |
| ABAC | Dynamic context matters | Uses attributes: user, device, data, location, risk | Requires strong attribute governance |
| DAC | Owner-controlled access | Flexible for collaboration | Less centralized control |
| MAC | Highly classified or rigid environments | Strong central policy enforcement | Operationally inflexible |
| ReBAC | Relationship-based access | Useful for social/collaboration graphs | Complex policy reasoning |
| PBAC/XACML-style | Centralized policy decisions | Decouples policy from applications | Needs mature policy design |
Privileged access controls
| Control | Purpose | Exam decision point |
|---|
| PAM vault | Stores and rotates privileged secrets | Use for administrator, service, and break-glass accounts |
| JIT access | Grants privilege only when needed | Reduces standing privilege |
| JEA | Grants only required admin capability | Stronger than broad temporary admin |
| Session recording | Accountability and forensics | Useful for sensitive admin access and third-party support |
| Break-glass account | Emergency access | Must be protected, monitored, tested, and tightly controlled |
| Service account governance | Prevents unmanaged machine privileges | Use rotation, scoped permissions, ownership, and noninteractive controls |
Cryptography and PKI
Crypto selection table
| Need | Prefer | Notes |
|---|
| Fast bulk data encryption | Symmetric encryption, such as AES-GCM | GCM provides authenticated encryption when used correctly |
| Secure key exchange over untrusted network | ECDHE/DHE | Enables perfect forward secrecy when ephemeral keys are used |
| Digital signature | RSA/ECDSA/EdDSA-style signature schemes | Provides integrity, authenticity, and nonrepudiation support |
| Password storage | Salted adaptive hash/KDF | Use bcrypt, scrypt, Argon2, or PBKDF2-style approach; never plain hash alone |
| Message integrity with shared secret | HMAC | Stronger than plain hash for authenticity |
| File integrity check only | Cryptographic hash | Detects change, does not provide secrecy |
| Key protection | HSM/KMS/TPM | Reduces key exposure and centralizes lifecycle |
| Transport security | TLS with modern cipher suites | Validate certificates and avoid weak protocols/ciphers |
| Mutual service identity | mTLS | Both client and server present certificates |
| Data field substitution | Tokenization | Reduces exposure of sensitive values in applications |
| Format-preserving protection | Format-preserving encryption or tokenization | Useful where legacy field format must remain |
PKI terms that matter
| Term | Practical meaning |
|---|
| Root CA | Trust anchor; compromise affects all subordinate trust |
| Intermediate CA | Issues certificates while protecting root CA offline |
| Certificate chain | Path from leaf certificate to trusted root |
| CSR | Certificate signing request containing public key and identity information |
| CRL | Published list of revoked certificates |
| OCSP | Online certificate status check |
| OCSP stapling | Server provides status proof to reduce client lookup overhead |
| Certificate pinning | App trusts specific cert/key; improves control but complicates rotation |
| SAN | Subject Alternative Name; modern identity field for DNS names |
| mTLS | Mutual certificate authentication for client and server |
| Key escrow | Third party stores recoverable key material; useful but increases risk |
| Key rotation | Periodic or event-driven key replacement |
| Key destruction | Removes ability to decrypt; must align with retention/legal hold needs |
Crypto traps
| Statement | Correction |
|---|
| “Hashing encrypts data.” | Hashing is one-way integrity verification, not encryption. |
| “Encoding protects secrets.” | Encoding such as Base64 is reversible representation, not security. |
| “TLS solves all API security.” | TLS protects transport; API authorization, validation, and rate limiting are still required. |
| “Use the same key everywhere for simplicity.” | Use separation of duties, key hierarchy, and scoped keys. |
| “Hard-coded secrets are acceptable if the repo is private.” | Use a secrets manager and rotate exposed secrets. |
| “Old clients require weak ciphers, so keep them enabled globally.” | Isolate legacy support and document risk exceptions. |
Data protection and privacy engineering
| Control | Best use | Distinction |
|---|
| Data classification | Drives handling requirements | Must be tied to labels, storage, access, retention, and DLP |
| Encryption at rest | Protects stored data from unauthorized access to media/storage | Does not stop authorized misuse |
| Encryption in transit | Protects data crossing networks | Requires proper certificate validation |
| Tokenization | Replaces sensitive value with token | Often reduces sensitive data exposure in apps |
| Masking | Hides part of data in display or test sets | Static masking changes copy; dynamic masking changes view |
| Anonymization | Irreversibly removes identity link | Hard to guarantee with rich datasets |
| Pseudonymization | Replaces identifiers but can be re-linked with extra data | Still sensitive if reidentification is possible |
| DLP | Detects or blocks sensitive data movement | Needs classification, tuning, and workflow |
| DRM/IRM | Controls document usage after distribution | Useful for sensitive documents, not all data flows |
| DAM | Monitors database access and activity | Useful for high-value structured data |
| Data minimization | Collect less data | Reduces breach impact and compliance scope |
| Retention policy | Keeps data only as long as required | Must align with business, legal hold, and disposal needs |
| Secure disposal | Prevents recovery after use | Use media-appropriate sanitization and verification |
Cloud and hybrid security
Shared responsibility cues
| Model | Provider typically handles more of | Customer still owns |
|---|
| IaaS | Physical facilities, hardware, core virtualization | OS, applications, data, IAM, network configuration, logging choices |
| PaaS | Managed runtime/platform components | App code, data, identity, secrets, platform configuration |
| SaaS | Application hosting and maintenance | User access, data governance, configuration, integrations, monitoring exports |
| On-premises | Customer owns nearly everything | Full stack security, physical to application |
Cloud control selection
| Problem | Choose | Why |
|---|
| Public storage exposure | CSPM finding + preventive policy + remediation | Detects and prevents misconfiguration |
| Excessive cloud permissions | CIEM + least privilege review | Finds unused, risky, and overbroad entitlements |
| Runtime container compromise | CWPP/EDR for containers | Observes workload behavior and can respond |
| Insecure IaC template | IaC scanning + policy as code | Stops misconfigurations before deployment |
| Secrets in repository | Secrets scanning + secrets manager + rotation | Removes static secrets from code |
| Multi-account governance | Landing zone/organization guardrails | Standardizes logging, identity, network, and policy boundaries |
| SaaS data leakage | CASB + DLP + IdP integration | Controls access and data movement |
| Cloud key control | KMS/HSM with rotation and access policy | Centralized key lifecycle and audit |
| Workload identity | Federated workload identity | Avoids long-lived static cloud keys |
| Cloud incident investigation | Centralized logs + immutable storage + snapshots | Preserves evidence and enables timeline reconstruction |
Container and Kubernetes security
| Layer | Controls |
|---|
| Image | Minimal base image, signed images, vulnerability scan, SBOM, no secrets |
| Registry | Access control, image signing verification, retention, scanning |
| Pod | Non-root user, read-only filesystem where possible, resource limits |
| Secrets | External secrets manager or encrypted secret storage; no secrets in images |
| Network | Default deny, namespace segmentation, service-level allow rules |
| Admission | Policy enforcement for allowed registries, privileged containers, capabilities |
| Runtime | Behavior monitoring, syscall restrictions, container-aware EDR/CWPP |
| Cluster | RBAC least privilege, audit logs, secure API server, patching |
Example concept: default deny plus explicit allow.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-then-allow-api
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: web
ports:
- protocol: TCP
port: 8443
Key interpretation: only selected web pods can reach selected api pods on TCP 8443; other ingress to those API pods is denied if policy is enforced by the CNI.
Network and infrastructure security
| Technology | Best use | Key distinction |
|---|
| Stateless ACL | Simple packet filtering | Does not track sessions |
| Stateful firewall | Network/session control | Allows return traffic based on state |
| NGFW | App/user-aware filtering | Adds application identity, threat features |
| IDS | Detects suspicious traffic | Out-of-band; usually does not block |
| IPS | Blocks suspicious traffic | Inline; tuning matters to avoid disruption |
| WAF | HTTP/S application protection | Layer 7 web traffic, not all protocols |
| API gateway | API routing, auth, throttling, observability | Complements, not replaces, app authorization |
| NAC/802.1X | Controls network admission | Uses identity/device posture |
| NDR | Network behavior analytics | Useful for lateral movement and unmanaged devices |
| DNS filtering | Blocks malicious domains | Good early control; can be bypassed if unmanaged DNS allowed |
| DNSSEC | Authenticates DNS data origin/integrity | Does not encrypt DNS queries |
| DoH/DoT | Encrypts DNS transport | Can reduce enterprise DNS visibility if unmanaged |
| VPN | Encrypted network tunnel | Often broad network access unless tightly segmented |
| ZTNA | App-specific remote access | Better least privilege for private apps |
| DDoS protection | Absorbs/filters volumetric and app-layer attacks | Needs upstream/provider support and runbooks |
| Network segmentation | Limits blast radius | Enforce with firewalls, VLANs, SDN, microsegmentation |
| Honeypot/deception | Detects attacker interaction | Must be isolated and monitored |
OT/ICS security cues
| OT constraint | Security response |
|---|
| Safety and availability dominate | Avoid disruptive scanning; use passive monitoring where possible |
| Legacy systems cannot patch quickly | Segment, monitor, restrict access, use compensating controls |
| Vendor remote access is required | Use PAM, MFA, jump hosts, session logging, time-bound access |
| Flat plant network | Create zones/conduits and restrict IT/OT paths |
| Protocols lack auth/encryption | Isolate, monitor command patterns, wrap access through secure gateways |
| Change windows are rare | Test changes, document rollback, coordinate with operations |
Secure engineering and DevSecOps
| Tool/type | Finds | Best stage | Limitations |
|---|
| SAST | Source/code-level flaws | Early development | False positives; may miss runtime issues |
| DAST | Runtime web/app flaws | Test/staging | Needs running app; may miss code paths |
| IAST | Runtime issues with instrumentation | Test | Requires agent/instrumentation |
| SCA | Vulnerable dependencies/licenses | Build and CI | Must manage transitive dependencies |
| Container scan | OS/package/image flaws | Build/registry | Image clean at build can become stale |
| IaC scan | Misconfigured infrastructure templates | Before deploy | Needs policy alignment |
| Secrets scan | Exposed keys/passwords/tokens | Commit/CI/repository | Detection must trigger rotation |
| Fuzzing | Crash/input handling flaws | Test | Requires harness and triage |
| RASP | Runtime app self-protection | Production | Not a replacement for secure code |
| Pen test | Exploitable paths | Pre-release or periodic | Point-in-time assessment |
| Red team | Detection and response validation | Mature programs | Goal is objective-based, not full coverage |
Secure SDLC gates
| Phase | Security activities |
|---|
| Requirements | Data classification, abuse cases, compliance/control needs |
| Design | Threat modeling, architecture review, trust boundaries |
| Development | Secure coding, peer review, secrets handling |
| Build | SAST, SCA, IaC scan, container scan, signing |
| Test | DAST, IAST, fuzzing, security regression tests |
| Release | Change approval, artifact integrity, deployment guardrails |
| Operate | Logging, monitoring, vulnerability management, incident playbooks |
| Improve | Lessons learned, metrics, backlog remediation |
Threat modeling quick map
| Method/concept | Use |
|---|
| STRIDE | Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege |
| Attack trees | Decompose attacker goals into paths |
| PASTA-style approach | Risk-centric threat modeling tied to business impact |
| MITRE ATT&CK | Map adversary tactics, techniques, and detection coverage |
| Kill chain | Understand attack progression and control placement |
| Abuse cases | Define how features can be misused |
| Trust boundary | Where data/control crosses privilege, network, or ownership boundary |
API and application security cues
| Issue | Best control |
|---|
| SQL/LDAP/command injection | Parameterized queries, safe APIs, input validation, least privilege |
| XSS | Output encoding, CSP, input validation, secure frameworks |
| CSRF | Anti-CSRF tokens, SameSite cookies, re-auth for sensitive actions |
| SSRF | Egress filtering, metadata service protection, allowlists, URL validation |
| Broken object-level authorization | Server-side authorization checks per object |
| Excessive data exposure | Response filtering, schema control, least data return |
| Weak JWT handling | Validate signature, issuer, audience, expiry; avoid accepting none algorithm |
| Token leakage | Secure storage, short lifetimes, refresh token rotation |
| Insecure deserialization | Avoid unsafe deserialization, sign/validate serialized data |
| File upload risk | Type validation, malware scan, storage isolation, no direct execution |
| Rate abuse | Rate limiting, quotas, bot controls, anomaly detection |
| Insecure CORS | Restrict origins, methods, credentials; avoid wildcard with credentials |
Supply chain security
| Risk | Controls |
|---|
| Malicious dependency | SCA, dependency pinning, trusted registries, package integrity checks |
| Compromised build pipeline | Least privilege CI/CD, isolated runners, signed builds, secrets manager |
| Tampered artifact | Code signing, artifact signing, provenance verification |
| Unknown components | SBOM generation and inventory |
| Developer account takeover | Phishing-resistant MFA, conditional access, branch protection |
| Secret exposure | Pre-commit/CI secrets scanning and immediate rotation |
| Unreviewed code | Pull request reviews, CODEOWNERS-style approvals, protected branches |
| Third-party service risk | Due diligence, contract controls, monitoring, exit plan |
Security operations
| Need | Primary tool/control | Why |
|---|
| Correlate logs across enterprise | SIEM | Central search, correlation, alerting |
| Automate enrichment and containment | SOAR | Playbooks and integrations |
| Endpoint detection and response | EDR | Process, file, registry, memory, and response actions |
| Extended correlation across domains | XDR | Endpoint, identity, email, cloud, and network correlation |
| User/entity anomaly detection | UEBA | Baselines behavior and flags anomalies |
| Network behavior visibility | NDR | Detects lateral movement and unusual traffic |
| Threat intel management | TIP | Normalizes and distributes indicators/intel |
| Vulnerability tracking | VM platform | Asset risk, scan findings, remediation workflow |
| Attack surface visibility | ASM/EASM | External exposure discovery |
| Configuration compliance | CSPM/SCAP/policy tools | Detects drift from baselines |
Incident response workflow
flowchart TD
A[Alert or report] --> B{Validate?}
B -- False positive --> C[Document and tune]
B -- True incident --> D[Classify severity and scope]
D --> E[Preserve evidence]
E --> F{Active threat?}
F -- Yes --> G[Contain: isolate, block, disable, revoke]
F -- No --> H[Investigate root cause]
G --> H
H --> I[Eradicate: remove malware, patch, rotate secrets]
I --> J[Recover and monitor]
J --> K[Lessons learned and control improvements]
Incident phase decision table
| Phase | Goal | Typical actions |
|---|
| Preparation | Be ready before incidents | Playbooks, contacts, tools, logging, tabletop exercises |
| Identification | Confirm and scope | Triage alerts, correlate logs, determine affected assets |
| Containment | Stop spread/damage | Isolate host, block IOC, disable account, revoke token |
| Eradication | Remove cause | Remove malware, close persistence, patch, rotate credentials |
| Recovery | Restore safely | Rebuild, restore backups, monitor for reinfection |
| Lessons learned | Improve controls | Root cause, metrics, detection tuning, policy updates |
Containment choices
| Situation | Prefer | Avoid |
|---|
| Malware actively spreading | Network isolate host or segment | Powering off before volatile evidence if forensics required |
| Stolen credentials | Disable account, revoke sessions/tokens, reset credentials | Only changing password while sessions remain valid |
| Leaked API key | Revoke/rotate key, search usage, update secret store | Leaving old key active “temporarily” |
| Ransomware on one host | Isolate, preserve evidence, check lateral movement | Immediately restoring without understanding entry point |
| DDoS | Activate provider mitigation, rate limits, traffic filtering | Local-only response if upstream saturated |
| Compromised cloud role | Disable/limit role, review activity logs, rotate credentials | Deleting evidence before timeline is built |
Forensics quick reference
| Concept | Practical meaning |
|---|
| Order of volatility | Collect most volatile evidence first when feasible: memory, network state, running processes, disk, backups |
| Chain of custody | Document who collected, handled, transferred, and stored evidence |
| Hashing evidence | Proves integrity of acquired images/files |
| Write blocker | Prevents modification of source media during acquisition |
| Timeline analysis | Reconstructs sequence of attacker and system events |
| Memory capture | Useful for malware, keys, processes, network connections |
| Disk image | Preserves filesystem and deleted artifacts |
| Log preservation | Centralized, time-synchronized, immutable logs improve investigation |
| Legal hold | Suspends normal deletion where required by counsel/process |
Logs and detection patterns
Common log interpretation cues
| Evidence | Possible meaning | Next check |
|---|
| Many failed logins then success | Brute force or password spraying | Source IPs, target accounts, MFA status, impossible travel |
| New admin account | Privilege escalation or legitimate change | Change ticket, creator account, directory audit logs |
| PowerShell encoded command | Possible obfuscation | Parent process, command line, script block logs |
| Rare outbound domain | Command and control or new SaaS | DNS logs, proxy logs, reputation, host process |
| Large outbound transfer | Exfiltration or backup | Destination, data type, user, timing |
| Login from new geography | Account compromise or travel | Conditional access, MFA, device posture |
| Repeated 401/403 | Credential attack or broken integration | User agent, source, endpoint, account lockouts |
| Repeated 500 errors | App issue or exploit attempt | Web logs, WAF events, payloads |
| New scheduled task/service | Persistence | Creator, binary path, hash, endpoint telemetry |
| Disabled security tool | Defense evasion | Admin action logs, EDR health, process history |
Generic Sigma-style detection example
title: Suspicious Encoded PowerShell
status: experimental
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains:
- '-enc'
- '-encodedcommand'
condition: selection
fields:
- Image
- ParentImage
- CommandLine
- User
- Hostname
level: high
Exam interpretation: encoded PowerShell is suspicious, but triage should confirm parent process, user context, script content, endpoint history, and business justification.
Vulnerability management and testing
| Activity | Purpose | Output |
|---|
| Asset discovery | Know what exists | Asset inventory and ownership |
| Vulnerability scan | Identify known weaknesses | Findings, severity, affected systems |
| Configuration scan | Detect baseline drift | Misconfiguration reports |
| Risk-based prioritization | Fix what matters most | Remediation order based on exploitability, exposure, asset value |
| Patch management | Apply vendor fixes | Change records and validation |
| Exception process | Accept temporary residual risk | Owner, justification, compensating controls, expiration |
| Penetration test | Validate exploitability | Findings with proof and remediation guidance |
| Red team exercise | Test detection/response against objectives | Gaps in controls, process, and monitoring |
| Purple team | Improve detections collaboratively | Tuned detections and response playbooks |
| Bug bounty | Continuous external researcher testing | Validated reports and coordinated disclosure |
Prioritization factors
Do not prioritize by scanner score alone. Consider:
- Internet exposure
- Known exploitation
- Asset criticality
- Data sensitivity
- Compensating controls
- Ease and reliability of exploit
- Business impact of patching
- Availability of mitigation
- Regulatory or contractual commitments
- Whether the weakness enables privilege escalation or lateral movement
Governance, risk, and compliance
Risk calculations
Use these formulas when a scenario gives enough values.
\[
\text{SLE} = \text{Asset Value} \times \text{Exposure Factor}
\]\[
\text{ALE} = \text{SLE} \times \text{ARO}
\]\[
\text{Risk} = \text{Likelihood} \times \text{Impact}
\]
| Term | Meaning |
|---|
| Asset value | Business value of the asset |
| Exposure factor | Percentage of asset value lost in one event |
| SLE | Single loss expectancy |
| ARO | Annualized rate of occurrence |
| ALE | Annualized loss expectancy |
| Inherent risk | Risk before controls |
| Residual risk | Risk remaining after controls |
| Risk appetite | Amount of risk organization is willing to accept |
| Risk tolerance | Acceptable variation around appetite |
| Control effectiveness | How much a control reduces likelihood or impact |
Risk treatment
| Treatment | Use when | Example |
|---|
| Mitigate | Reduce likelihood or impact | Add MFA, segmentation, patching |
| Transfer | Shift financial/operational impact | Cyber insurance, contractual transfer |
| Avoid | Stop risky activity | Decommission vulnerable public service |
| Accept | Residual risk is within appetite | Documented exception with owner and review date |
Control types
| Classification | Examples |
|---|
| Administrative | Policies, standards, training, risk assessments |
| Technical | MFA, encryption, firewalls, EDR, DLP |
| Physical | Locks, cameras, guards, secure disposal bins |
| Preventive | Access control, hardening, secure coding |
| Detective | SIEM alerts, IDS, audits |
| Corrective | Restore from backup, patch, reimage |
| Deterrent | Warning banners, visible cameras |
| Compensating | Alternative control when primary control is not feasible |
| Directive | Policies, procedures, required standards |
| Recovery | Backups, DR site, failover |
Governance artifacts
| Artifact | Purpose |
|---|
| Policy | High-level management intent and mandatory rules |
| Standard | Specific mandatory requirements |
| Procedure | Step-by-step instructions |
| Guideline | Recommended practice |
| Baseline | Minimum secure configuration |
| Control framework | Organized catalog of controls |
| Risk register | Tracks risks, owners, ratings, treatment plans |
| Exception register | Tracks approved deviations and expiration |
| BIA | Identifies critical processes and outage impact |
| SLA/OLA | Defines service expectations internally/externally |
| MOU/MOA | Defines shared responsibilities between organizations |
| NDA | Protects confidential information |
| DPA/data processing terms | Defines data handling responsibilities |
Business continuity and disaster recovery
| Metric/design | Meaning | Decision point |
|---|
| BIA | Determines criticality and impact over time | Drives recovery priorities |
| MTD/MAO | Maximum tolerable downtime/outage | RTO must fit inside this tolerance |
| RTO | Target time to restore service | Shorter RTO usually costs more |
| RPO | Acceptable data loss window | Drives backup/replication frequency |
| Hot site | Ready-to-run alternate site | Fast recovery, higher cost |
| Warm site | Partially prepared | Balance of cost and speed |
| Cold site | Space/infrastructure only | Slower recovery, lower cost |
| Active-active | Multiple active locations | High availability and load sharing |
| Active-passive | Standby environment | Simpler, may have failover delay |
| Backup | Copy of data | Not sufficient unless restore is tested |
| Immutable backup | Resistant to modification/deletion | Important for ransomware resilience |
| Tabletop exercise | Discussion-based validation | Good for roles and decisions |
| Failover test | Technical validation | Confirms recovery design works |
Third-party and vendor risk
| Area | What to verify |
|---|
| Due diligence | Security posture, financial/operational stability, references |
| Data access | What data, where stored, who can access it |
| Contract terms | Security obligations, audit rights, breach notification expectations |
| Subcontractors | Use of subprocessors and flow-down obligations |
| Identity integration | SSO, MFA, provisioning/deprovisioning |
| Logging | Availability of audit logs and export/API access |
| Encryption | At rest, in transit, key ownership options |
| Resilience | Backup, DR, availability commitments |
| Exit strategy | Data return/deletion, portability, transition support |
| Continuous monitoring | Security reports, attestations, issue tracking |
Privacy and data governance cues
| Principle | Practical security action |
|---|
| Purpose limitation | Collect/use data only for defined purposes |
| Data minimization | Reduce fields collected and retained |
| Consent/notice management | Align user expectations with processing |
| Retention limitation | Delete or anonymize when no longer needed |
| Access rights support | Maintain searchable inventories and workflows |
| Privacy by design | Include privacy in requirements and architecture |
| Data localization | Understand where data is stored and processed |
| Cross-border transfer review | Verify contractual and organizational controls |
| Deidentification | Use anonymization/pseudonymization where appropriate |
| Breach readiness | Know data owners, notification workflow, and evidence sources |
Common CAS-005 decision traps
| Trap answer | Better exam reasoning |
|---|
| “Encrypt it” for every data problem | Encryption protects confidentiality but does not solve authorization, retention, misuse, or integrity by itself. |
| “Block everything immediately” during incident response | Preserve evidence and choose containment proportional to business impact and active threat. |
| “Patch the highest CVSS first” | Prioritize using exploitability, exposure, asset criticality, and business context. |
| “Move to cloud for better security” | Cloud changes control ownership; misconfiguration and IAM risk remain. |
| “Use SIEM to prevent attacks” | SIEM detects and correlates; prevention requires controls and response actions. |
| “Use blockchain for integrity” | Most integrity requirements are better met with hashes, signatures, logs, and access controls. |
| “Use AI/ML for any anomaly” | ML needs quality data, tuning, explainability, and operations workflow. |
| “IDS blocks the attack” | IDS detects; IPS blocks inline. |
| “Tokenization and encryption are the same” | Tokenization substitutes values; encryption transforms data with keys. |
| “Backups equal resilience” | Backups must be isolated, restorable, tested, and aligned to RTO/RPO. |
| “Compliance equals security” | Compliance is evidence against requirements; security also needs risk-based control effectiveness. |
Before the exam, practice doing these quickly:
- Select the best architecture control from business and threat cues.
- Identify insecure configuration patterns: broad allow rules, public exposure, weak TLS, hard-coded secrets, excessive IAM permissions.
- Map controls to zero trust, defense in depth, and least privilege.
- Order incident response steps correctly.
- Interpret logs and distinguish indicator, event, alert, incident, and breach.
- Choose between SAST, DAST, IAST, SCA, fuzzing, and pen testing.
- Prioritize vulnerabilities with business context, not severity alone.
- Match IAM protocols to use cases.
- Choose encryption, hashing, tokenization, masking, or signing correctly.
- Apply RTO/RPO and risk formulas when numbers are provided.
- Recommend compensating controls when ideal remediation is not immediately feasible.
- Recognize when governance artifacts, risk acceptance, or vendor controls are required.
Final review sequence
- Review the official CompTIA SecurityX (CAS-005) objectives alongside this Quick Reference.
- Drill decision tables until you can explain why the best option is better than plausible distractors.
- Practice scenario and performance-based questions that require architecture selection, log interpretation, risk analysis, and incident response ordering.
- After each missed question, record the decision rule you failed to apply and retest with fresh original practice items.