CISSP interview questions

No. You can't compare raw key length across different algorithm families. Because of how each one's underlying math hardens, a 256-bit elliptic-curve key gives roughly the same security as a 3072-bit RSA key — about 128-bit strength, per NIST. Bigger isn't simply stronger: ECC reaches equivalent strength with far smaller keys, which is why modern systems prefer it. Within a single algorithm, longer keys do help, up to a point.

No. Cloud runs on a shared responsibility model: the provider secures the underlying infrastructure ('security of the cloud'), but you remain responsible for your data, identity and access management, configuration, and — for IaaS — the OS and patching ('security in the cloud'). The large majority of cloud breaches are customer-side misconfigurations like public buckets and over-permissive IAM, not provider failures. Assuming the provider secures your data is how those breaches happen.

Not necessarily. Double-encrypting with the same algorithm doesn't simply double security — the classic result is that 2DES adds only about one bit of effective strength because of meet-in-the-middle attacks, which is why 3DES exists. More importantly, hand-rolled multi-layer schemes tend to introduce implementation bugs that weaken the whole thing. Use one well-vetted authenticated cipher (AES-GCM) with sound key management instead of stacking crypto.

Reliable incident reconstruction comes from correlating independent telemetry into one timeline: auth logs, EDR process/exec data, filesystem MAC timestamps, network flows and SIEM events, so you can order actions and bound the scope. A single log or the latest event alone misses the chain and can be misleading or tampered with. Guessing from one source or asking the attacker are not investigative methods. Correlation across independent sources is what reveals the full attacker activity and survives an attacker who edited one of them.

Evidentiary integrity rests on hashing the image at acquisition (e.g., SHA-256) and verifying the hash later to prove it's unaltered, maintaining a documented chain of custody, and analyzing a working copy so the original stays pristine. Renaming the file does nothing for integrity, and compressing it to save space neither proves integrity nor helps admissibility. Touching the original risks spoliation that can get the evidence thrown out. Hash, document custody, and work on a verified copy.

Balance usability and risk: enforce conditional access tied to device posture and isolate corporate data in a managed container (MAM/MDM) so it can be controlled and selectively wiped without taking over a personal device. Unrestricted access risks leakage on unmanaged, possibly compromised endpoints. An outright ban pushes people to insecure workarounds like forwarding data to personal email. And emailing attachments scatters sensitive data uncontrollably across devices you can never reclaim.

No single product stops every attack, so mature security layers independent controls — defense-in-depth — so the failure of one does not mean compromise. Map the proposed spend to the actual gaps across identity, network, endpoint, data and detection, and keep the complementary controls already working. Betting everything on one tool creates a single point of failure, and ripping out existing controls to replace them reduces coverage. Declining to spend at all ignores real gaps.

Encryption at rest defends exactly one threat — physical or disk theft — and does nothing against a compromised application, stolen credentials, or sniffed traffic, because the database decrypts transparently for any authorized query. A sound design also requires TLS in transit, strong authentication and authorization, and proper key management with separation of duties. Doubling the at-rest encryption adds cost without changing the threat model, and encrypting only the backups leaves the live data and its access paths exposed.

If the key lives with the ciphertext, anyone who steals the database gets both, so the encryption protects nothing — it is a lock with the key taped to it. Keys must be managed in a dedicated KMS or HSM, separated from the data, with strict access control, rotation, and separation of duties. Hashing the key makes it one-way and useless for decryption, and storing extra copies in the same place just multiplies the exposure rather than reducing it.

Threat modeling is cheapest and most effective at design time, before code locks in decisions: walk the data flows, enumerate threats with a framework like STRIDE, and bake in mitigations, then revisit as the design evolves. Doing it only post-incident or at the annual pentest finds problems after they are expensive to fix and already exposed. And relying on 'careful developers' is a hope, not a repeatable, auditable control.

Network-location trust means a single foothold inside grants broad lateral access — one phished VPN credential and the attacker is 'inside.' Zero trust removes implicit trust: every access is authenticated, authorized, and continuously evaluated on identity and device posture, with least privilege and segmentation (NIST SP 800-207). A second VPN or a wider VPN just extends the same flat-trust problem to more places, and trusting the LAN instead of the VPN repeats the original mistake.

Without control-plane audit logs you're blind to who did what at the cloud layer, and detection, forensics, and compliance all depend on that record. Enable CloudTrail immediately, org-wide, delivering to a separate, access-controlled, tamper-resistant (immutable) bucket. Saying it doesn't matter while nothing is wrong ignores that you'd have no history when something does go wrong. Waiting until an incident means the formative early actions are already unlogged and unrecoverable. Application logs don't capture API, IAM, or console activity at the control plane.

An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.

Follow the order of volatility. RAM, live network connections and the process table vanish on shutdown, so capture them first, then take a forensic disk image while documenting hashes and an unbroken chain of custody. A clean shutdown destroys memory-resident evidence — including fileless malware and keys that live only in RAM. Copy-then-delete tampers with the scene and breaks integrity. Running the company antivirus mutates the system and may quarantine or delete the very artifact you need to analyze.

Containment beats premature recovery: stop the spread by isolating affected segments and killing the propagation path — disable the abused service account, block SMB between segments, pull the staging host — while preserving evidence, then eradicate and recover. Restoring into a network that's still encrypting just re-loses the restored data. Paying the ransom doesn't stop active encryption and carries legal and sanctions risk. Cutting power to every machine destroys volatile evidence and can corrupt files mid-write, making clean recovery harder.

Eradicating before you understand scope lets the attacker persist on systems you haven't found and simply return. Quickly hunt the IOCs and stolen credentials across the estate, identify every affected host and persistence mechanism, then eradicate everywhere at once. Wiping one host is whack-a-mole that tips off the attacker while leaving their other footholds intact. A week-long full internet blackout is disproportionate and harms the business. Deleting just the malware file ignores persistence, lateral movement, and the credentials already stolen.

Flat networks let one compromised guest device reach crown-jewel systems directly. Segment by trust level and enforce least-privilege traffic between zones so lateral movement is contained and monitored. An edge firewall does nothing for east-west traffic between hosts already inside. Re-IPing the finance servers is security-by-obscurity that any scan defeats. Endpoint AV is one detective layer, not a substitute for the architectural control of isolating sensitive systems.

Least privilege plus just-in-time access: grant the minimum permissions needed, time-boxed and logged, so debugging is possible without standing admin that becomes a permanent risk and audit gap. Permanent cluster-admin violates least privilege and widens the blast radius of any compromise. A blanket denial blocks legitimate work and invites risky shadow workarounds. Sharing the common admin service-account credential destroys accountability — actions can't be traced to a person.

The LLM supply chain spans base models, fine-tuned variants, datasets, embeddings, plugins, libraries, and the hosting platform — each a place to introduce risk. Threats include downloading tampered or backdoored model weights, malicious fine-tunes, poisoned or license-tainted datasets, vulnerable or over-permissioned plugins, and typosquatted model repos. Defenses: source models from trusted registries, verify integrity and provenance, maintain an AI bill of materials, scan and pin dependencies, vet plugins, and apply least privilege to anything the model integrates with.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, risk-based framework for governing trustworthy AI across its lifecycle. Its core is four functions: Govern (culture, policy, accountability — and it runs through the others), Map (context and risk identification), Measure (assess and track risks), and Manage (prioritize and respond). It also defines trustworthiness characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair. It complements technical lists like the OWASP LLM Top 10 at the program level.

The OWASP Top 10 for LLM Applications is the consensus list of the most critical risks when building with large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It exists because traditional appsec lists don't capture LLM-specific failure modes, and it gives teams a shared vocabulary and a checklist to prioritize controls.

RAG security means treating every retrieved document as untrusted input. Key risks: indirect prompt injection hidden in retrieved content, poisoning of the knowledge base or embeddings, and missing per-user authorization so the model returns data the user can't access. Defenses include access control enforced at retrieval, content provenance and ingestion vetting, treating retrieved text as data not instructions, output validation, and isolating the vector store per tenant.

An LLM agent turns text into actions via tools and function calls, so a prompt injection becomes a real-world action — the excessive-agency risk. Secure it by giving each tool the least privilege and scope it needs, validating and constraining tool arguments, requiring human confirmation for sensitive or irreversible actions, sandboxing execution, rate-limiting and budgeting calls, and logging every tool invocation. Never let the model's untrusted-data-influenced output directly authorize a high-impact action.

LLM apps leak data several ways: the model memorizes and regurgitates sensitive training or fine-tuning data, the system prompt (which may hold secrets or logic) gets extracted, retrieved RAG documents expose data the user shouldn't see, and context from one user or session bleeds into another. Prevention means data minimization before training, never putting secrets in prompts, enforcing per-user authorization on retrieval, output filtering and PII redaction, and tenant isolation.

Training-data poisoning is when an attacker tampers with the data used to pre-train, fine-tune, or embed a model so the resulting model behaves maliciously — embedding a backdoor trigger, injecting bias, or degrading accuracy. It exploits the fact that models scrape and trust large, often web-sourced datasets. Defenses include curating and signing data sources, provenance and integrity checks, anomaly detection on training data, dataset versioning, and limiting who can contribute to training and RAG corpora.

DAC lets the data owner grant access at their discretion; MAC enforces access centrally via labels/clearances and is non-discretionary; RBAC grants access through job roles; ABAC evaluates attributes (user, resource, environment) against policy for fine-grained, context-aware decisions.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Classification labels data by sensitivity so the organization applies controls proportional to value and risk, avoiding both under-protection and wasteful over-protection. The data owner (a business role) sets the classification and accepts risk, while the data custodian (often IT) implements and maintains the protective controls.

Defense in depth layers multiple, diverse, and independent controls across people, process, and technology so that the failure of any one control does not result in compromise. It assumes every control will eventually fail and uses redundancy and variety to slow, detect, and contain an attacker.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

Identity lifecycle management governs an account from creation to retirement: provisioning at onboarding (joiner), adjusting entitlements on role change (mover), and timely deprovisioning at exit (leaver), with periodic access reviews throughout. The most common failures are privilege creep on movers and orphaned accounts from missed deprovisioning.

A policy is the high-level mandatory statement of management intent; a standard is a mandatory specific rule that enforces policy (e.g. AES-256); a procedure is the mandatory step-by-step how-to; a guideline is an optional recommendation. Policies, standards, and procedures are mandatory, while guidelines are discretionary.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

You can mitigate (reduce likelihood/impact with controls), transfer (shift the financial impact via insurance or contracts), avoid (stop the risky activity entirely), or accept (knowingly tolerate the residual risk). The choice depends on risk appetite and a cost-benefit comparison against the risk's expected loss.

Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.

The client builds a chain from the server (leaf) certificate up through one or more intermediate CAs to a root CA in its trust store. It verifies each certificate's signature using the next issuer's public key, checks validity dates, name/hostname match, key usage, and revocation (CRL/OCSP). Trust terminates at a self-signed root that is pre-trusted; the chain is valid only if every link checks out.

Signing cryptographically binds an artifact to its producer so consumers can verify it wasn't tampered with or swapped. Provenance is signed metadata describing how, where, and from what source the artifact was built. Together — via tooling like Sigstore for keyless signing and the SLSA framework for provenance levels — they let a deployer verify an image came from the expected pipeline and source, defeating tampering and dependency-substitution attacks.

Treat the pipeline as production infrastructure: it holds the credentials to ship code and reach prod, so compromising it bypasses every downstream control. Harden it with isolated, ephemeral runners; least-privilege, short-lived tokens (OIDC federation instead of long-lived secrets); protected branches and reviewed pipeline config; pinned third-party actions by digest; and full audit logging. The pipeline is a top-tier target, not plumbing.

The CIA triad is the three core goals of information security: confidentiality (only authorized parties can read data), integrity (data isn't altered without authorization), and availability (authorized users can access systems when needed). Almost every control maps to one or more of these.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. It assumes no single control is perfect — for example combining a firewall, network segmentation, endpoint protection, MFA, least privilege, and encryption rather than relying on a perimeter alone.

Least privilege means every user, process, and service gets only the minimum access required for its task, and nothing more. It limits the blast radius of a compromised account, reduces insider-threat risk, and shrinks the attack surface. You apply it via role-based access, regular access reviews, and just-in-time elevation.

A vulnerability is a weakness (unpatched software). A threat is an actor or event that could exploit it (a ransomware group). Risk is the combination of likelihood that a threat exploits a vulnerability and the impact if it does. Risk = threat x vulnerability x impact, and it's what you actually prioritize.

Because they are fast. MD5 and SHA-256 are designed for speed, which is exactly wrong for passwords: an attacker who steals the hashes can compute billions of guesses per second on a GPU. The fix is a deliberately slow, memory-hard key-derivation function — bcrypt, scrypt, or Argon2 — combined with a per-user salt and a tunable work factor.

Controls are classified two ways. By type: administrative (policies, training, procedures), technical/logical (firewalls, MFA, encryption), and physical (locks, badges, cameras). By function: preventive (stop an event — MFA, access control), detective (find an event — SIEM, IDS, audit logs), corrective (fix after — restore from backup, patch), deterrent (discourage — warning banners), and compensating (an alternative when the primary control isn't feasible). Defence in depth layers these so no single control failure leads to compromise.

The NIST Cybersecurity Framework organises cybersecurity outcomes into core functions. In CSF 2.0 there are six: Govern (the new overarching function for strategy, roles, risk decisions, and oversight), Identify (understand assets and risks), Protect (safeguards to limit impact), Detect (find events), Respond (act on incidents), and Recover (restore capabilities). They are not strictly sequential — they run continuously and together describe a full lifecycle of managing cyber risk.

Access reviews (recertification) are periodic checks where an accountable owner confirms each person's access is still justified, and revokes what isn't. They're the backstop that catches privilege creep, orphaned accounts, and entitlements granted for a project that ended. The control only works if a knowledgeable owner — usually the manager or resource owner — actually scrutinizes access rather than rubber-stamping it, and if revocations are enforced.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.

A secure SDLC embeds security into every phase rather than testing at the end: requirements (security and abuse cases), design (threat modeling), implementation (secure coding standards, SAST/SCA in the IDE and CI), testing (DAST, pentest), release (gates and sign-off), and operations (monitoring, patching, feedback). Shift-left moves defects earlier where they're cheap to fix; maturity models like OWASP SAMM and BSIMM measure how well you actually do it.

Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.

A DMZ (demilitarized zone) is a network segment that sits between the untrusted internet and the trusted internal network, hosting public-facing services like web, mail, and DNS servers. Firewall rules let the internet reach the DMZ but tightly restrict the DMZ's access to the internal network. The goal is containment: if a public server is compromised, the attacker is stuck in the buffer zone rather than landing inside the LAN.

A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. No single control is assumed perfect, so you stack preventive, detective, and responsive measures across the network, host, application, and data layers.

Least privilege means every user, process, or service gets only the minimum access required to do its job, and nothing more. It shrinks the blast radius of any compromise or mistake. You enforce it with role-based access, just-in-time elevation, regular access reviews, and removing standing admin rights.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Segmentation divides a network into isolated zones so a breach in one can't freely reach others, limiting lateral movement. Zero trust goes further: it removes implicit trust based on network location entirely, authenticating and authorizing every request regardless of where it originates — microsegmentation is one way to implement it.

A PKI is the system of CAs, certificates, and policies that binds public keys to identities. To validate a server cert a client builds a chain to a trusted root, verifies each signature, checks validity dates and the hostname, confirms key usage, and checks revocation via CRL or OCSP.