Cybersecurity Interview Questions

Note: Security interviews reward precision about scope. "I worked in security" covers everything from running a SIEM to writing policy, and the interviewer needs to place you.

Cover:

• The environment. Size of the organisation, number of endpoints and users, on-premises or cloud, and the regulatory context — PCI DSS, GDPR, HIPAA, or ISO 27001 change the job substantially.
• Your discipline. Security operations and monitoring, vulnerability management, application security, identity, incident response, or governance and compliance. These are different careers, and claiming all of them is a warning sign.
• What you actually did. Concrete: tuned detection rules, ran a phishing simulation programme, remediated findings from a penetration test, implemented MFA, or led an incident.
• A measurable outcome. Mean time to detect, patch compliance percentage, phishing click rate, or open critical findings — before and after.

Follow the standard incident response phases, which shows you work to a process rather than improvising.

• Detection and analysis. How it surfaced — an alert, a user report, a third-party notification — and how you determined it was a genuine incident rather than a false positive. State the scope you established: which systems, which accounts, what data.
• Containment. Short-term first: isolating the host, disabling the account, blocking the indicator. Crucially, preserve evidence before you wipe anything — memory capture and disk imaging, because rebuilding the machine destroys the ability to understand what happened.
• Eradication. Removing the foothold and closing the entry point. If you do not know how they got in, you have not eradicated anything.
• Recovery. Restoring service with monitoring in place to catch a return, and validating the systems are clean before reconnecting.
• Lessons learned. What controls failed, and what specific changes followed.

Note: Mentioning that you involved legal and communications early — and that notification obligations may have regulatory deadlines — shows you understand a breach is not purely a technical event. If you handled a simulated incident or tabletop exercise rather than a real one, say so honestly; that is still valuable and lying about it is easily caught.

This is the core of a senior security role, and the answer must not be "because it is important".

• Speak in risk, not in threats. Risk is likelihood times impact, expressed in business terms: "a ransomware event would halt order processing for an estimated five days, which is roughly X in lost revenue plus recovery cost". That is a number a finance director can weigh.
• Use evidence they cannot dismiss. Penetration test findings, a phishing simulation click rate, an audit finding, or a peer organisation's public breach. Abstract threats are easy to defer; a report showing your own domain admin was compromised in a test is not.
• Offer options with costs, not a single demand. A tiered proposal lets them choose the level of risk to accept, which is genuinely their decision to make.
• Tie it to something they already want — a customer contract requiring ISO 27001, a regulatory deadline, or cyber insurance conditions. Security funded as a business enabler moves faster than security funded as insurance.

Note: Being able to say you accepted a decision not to fund something, documented the risk acceptance, and moved on shows maturity. Security people who treat every rejection as a battle lose influence.

Show that you understand security which people work around provides no protection at all.

• Start from the risk, not the control. Applying maximum security everywhere is both expensive and counterproductive. Protect the crown jewels heavily and accept lighter controls elsewhere.
• Prefer controls users do not feel. Single sign-on with conditional access is better security and less friction than forcing separate complex passwords everywhere. Automated patching beats asking people to reboot. The best controls are invisible.
• Watch for workarounds as a signal. Passwords on sticky notes, personal cloud storage for files, and shadow IT are all evidence that a control is too painful. That is a design failure, not a user failure.
• Involve the business early. A control designed with the team that will live under it survives; one imposed on them gets circumvented.

Note: The password guidance shift is a good concrete example — NIST now advises against forced periodic rotation and complex composition rules, because they produced predictable passwords and reuse. Longer passphrases, breach-list checking, and MFA give better security with less friction. Citing that shows you follow evidence rather than tradition.

Sources, and what each is for:

• Vulnerability feeds — CISA's Known Exploited Vulnerabilities catalogue is the most useful single list, because it contains what is actively being exploited rather than everything ever published. Vendor advisories for your specific stack.
• Threat intelligence — sector-specific ISACs, and vendor reporting on the groups likely to target your industry.
• Practitioner community — security researchers, conference talks, and write-ups of real incidents, which teach far more than vulnerability counts.
• Hands-on practice — a lab, CTF exercises, or reproducing a published technique. Understanding an attack by performing it is different from reading about it.

How you turn it into action — the part that matters:

• Filter by exposure. A critical CVSS score in software you do not run is noise. Asset inventory is what makes triage possible.
• Prioritise on exploitability and exposure, not severity alone. An internet-facing service with a working public exploit outranks a higher-scored flaw on an internal system.
• Map to detection. Ask whether you would see it if it happened, and add the detection if not.

Note: MITRE ATT&CK is worth naming as the framework for mapping techniques to detections systematically rather than chasing individual headlines.

The CIA triad is the foundation of information security:

• Confidentiality — only authorised parties can read the data. Enforced by encryption, access control, and classification.
• Integrity — data has not been altered improperly. Enforced by hashing, digital signatures, checksums, and version control.
• Availability — authorised users can access it when needed. Enforced by redundancy, backups, DDoS protection, and capacity planning.

The three trade off against each other, which is the point interviewers want. Encrypting everything and locking it away maximises confidentiality and harms availability. Ransomware is fundamentally an availability attack. Which corner matters most depends entirely on the system.

AAA — authentication, authorisation, accounting:

• Authentication — proving who you are. Factors are something you know (password), have (token, phone), or are (biometric). Multi-factor means two different categories; a password and a security question are both "know" and are not MFA.
• Authorisation — what you are permitted to do once authenticated. Enforced through RBAC, ABAC, or access control lists.
• Accounting (or auditing) — recording what was done, so actions are attributable and reviewable.

Note: Non-repudiation is a worthwhile addition — the guarantee that someone cannot deny an action, provided by digital signatures and tamper-evident logging.

Symmetric encryption uses one shared key for both encryption and decryption. AES is the standard, typically AES-256. It is fast — suitable for bulk data — but creates a key distribution problem: how do you get the key to the other party securely?

Asymmetric encryption uses a mathematically related key pair. What the public key encrypts, only the private key decrypts, and vice versa. RSA and elliptic curve are the common algorithms. It solves key distribution — you can publish the public key freely — but is orders of magnitude slower, so it is impractical for large volumes.

In practice they are used together. TLS is the standard example: asymmetric cryptography authenticates the server and establishes a shared secret, then a fast symmetric cipher encrypts the actual traffic for the rest of the session. Asymmetric for key exchange, symmetric for bulk data.

Other uses: asymmetric keys also provide digital signatures — signing with the private key lets anyone verify with the public key, giving integrity and non-repudiation.

Note: Hashing is a third category and is frequently confused with encryption. A hash is one-way — SHA-256 produces a fixed-length digest that cannot be reversed. Passwords should be hashed, not encrypted, using a deliberately slow algorithm such as bcrypt or Argon2 with a unique salt per password. Saying "we encrypt passwords" in an interview is a serious mistake.

The OWASP Top 10 is the standard reference for web application risk. The current categories, with the defence for each:

• Broken Access Control — the top risk. Users reaching data or functions they should not. Defence: enforce authorisation server-side on every request, deny by default, and check object-level ownership — not just that the user has a role.
• Cryptographic Failures — data exposed through weak or absent encryption. Defence: TLS everywhere, strong algorithms, proper key management, and not storing what you do not need.
• Injection — SQL, command, and LDAP injection, plus cross-site scripting. Defence: parameterised queries, and context-appropriate output encoding.
• Insecure Design — flaws in the design itself, which no amount of secure coding fixes. Defence: threat modelling early.
• Security Misconfiguration — defaults left in place, verbose errors, unnecessary features enabled. Defence: hardened baselines and automated configuration checks.
• Vulnerable and Outdated Components — Defence: dependency scanning in CI and a patching process.
• Identification and Authentication Failures — Defence: MFA, breach-list password checks, rate limiting, secure session management.
• Software and Data Integrity Failures — unverified updates and insecure deserialisation. Defence: signed artefacts and verified pipelines.
• Security Logging and Monitoring Failures — Defence: log authentication and access-control events centrally, and alert on them.
• Server-Side Request Forgery (SSRF) — Defence: allowlist outbound destinations rather than blocklisting.

SQL injection occurs when user input is concatenated into a query, so input becomes executable SQL. Entering ' OR '1'='1 into a login field can turn the WHERE clause into something always true.

Prevention:

• Parameterised queries (prepared statements) — the definitive fix. Query structure is sent separately from values, so a value can never be parsed as SQL.
• Least privilege on the database account — the application should not connect as an administrator, limiting damage if something slips through.
• Input validation as defence in depth, never as the primary control.

Cross-site scripting (XSS) injects JavaScript that runs in another user's browser, in their session context — allowing session token theft, keylogging, or actions performed as them. Three types:

• Stored — the payload is saved server-side and served to every visitor. The most dangerous.
• Reflected — the payload comes in a request and is echoed back, requiring the victim to follow a crafted link.
• DOM-based — client-side JavaScript writes untrusted data into the page.

Prevention: context-aware output encoding — HTML, attribute, JavaScript, and URL contexts each need different escaping. A Content Security Policy limits what can execute even if a payload lands. Set session cookies httpOnly so script cannot read them, and use a framework that escapes by default rather than doing it manually.

Note: Both share a root cause: mixing data with code. Say that, and the two answers become one principle.

A vulnerability assessment is broad and automated. A scanner enumerates systems and reports known vulnerabilities against a signature database, producing a prioritised list. It answers "what weaknesses might we have?" — cheap enough to run continuously, wide in coverage, and it produces false positives that need triage. It does not confirm anything is actually exploitable.

A penetration test is narrow and human-driven. A tester attempts to actually exploit weaknesses, chain them together, and demonstrate real impact. It answers "what could an attacker actually achieve?" — expensive, point-in-time, and far more valuable because it proves consequence rather than listing possibility.

The key difference: a scanner might report three medium-severity findings independently. A tester chains them into domain administrator access and shows you the customer database. The findings were the same; the understanding is completely different.

Types of penetration test: black box (no prior knowledge, simulating an external attacker), white box (full information and source access, most thorough per hour spent), and grey box (partial knowledge, often simulating a compromised user).

Note: Two further distinctions worth making. A red team engagement is broader still — testing detection and response, not just technical vulnerabilities, and usually without the defenders knowing. And scope and rules of engagement must be agreed in writing before any test; testing without written authorisation is a criminal offence regardless of intent.

A firewall controls traffic between network segments based on rules. Types, in increasing sophistication:

• Packet filtering — decisions on source and destination address, port, and protocol. Fast, but no awareness of connection state.
• Stateful inspection — tracks connection state, so return traffic for an established connection is permitted automatically. The standard baseline.
• Next-generation firewall — adds application awareness, user identity, and integrated threat inspection, so it can distinguish traffic beyond port numbers.
• Web application firewall (WAF) — operates at the HTTP layer specifically, filtering application attacks such as injection attempts.

IDS versus IPS:

• IDS (Intrusion Detection System) is passive. It monitors a copy of traffic and alerts. It cannot block, but it also cannot break anything — no risk of a false positive dropping legitimate traffic.
• IPS (Intrusion Prevention System) is inline and active. Traffic passes through it and it can drop malicious packets. It stops attacks in real time, but a false positive becomes an outage, and it is a potential bottleneck and point of failure.

Detection methods for both: signature-based (matching known patterns — reliable but blind to novel attacks) and anomaly-based (deviation from a learned baseline — can catch new attacks but produces more false positives).

Note: The practical deployment answer is that organisations often run IPS in detection mode first, tune the rules against real traffic, then enable blocking selectively.

Social engineering manipulates people rather than technology. It is the most successful attack category because it bypasses technical controls entirely — no exploit is needed if someone hands over their password.

The variants:

• Phishing — mass fraudulent emails.
• Spear phishing — targeted at a specific person using researched detail. Far more effective.
• Whaling — targeting executives.
• Business Email Compromise — impersonating an executive or supplier to redirect a payment. Financially the most damaging category by a wide margin, and it often involves no malware at all.
• Vishing and smishing — by phone and SMS.
• Pretexting, baiting, and tailgating — a fabricated scenario, a lure such as a dropped USB drive, or simply following someone through a secure door.

Defence in layers:

• Technical — email authentication with SPF, DKIM, and DMARC; attachment and link filtering; external sender banners; and above all phishing-resistant MFA such as FIDO2 security keys, which defeats credential theft even when the user is fooled.
• Process — out-of-band verification for payment changes. A callback to a known number defeats BEC almost entirely.
• People — regular simulations with training, measured by click and report rates.

Note: Say that the goal of awareness training is a reporting culture, not a zero click rate. Punishing people who click means the next victim stays silent, which is far worse.

Traditional perimeter security assumed a trusted inside and an untrusted outside, defended by a firewall — the "castle and moat" model. Once inside, a user or device was largely trusted, so an attacker who got a foothold could move laterally with little resistance.

That model broke because there is no longer a meaningful perimeter: cloud services, remote work, personal devices, and third-party integrations all sit outside it.

Zero trust operates on "never trust, always verify". Its core principles:

• Verify explicitly. Every access request is authenticated and authorised using all available signals — user identity, device health, location, and behaviour — regardless of network position.
• Least privilege access. Just-in-time and just-enough access, so a compromised account has limited reach.
• Assume breach. Design as though an attacker is already inside: segment networks, encrypt internal traffic, and monitor continuously.

What it looks like in practice: strong identity as the control plane with conditional access policies, device compliance checks before access is granted, micro-segmentation so systems cannot reach each other without justification, per-application access rather than full VPN network access, and comprehensive logging.

Note: Emphasise that zero trust is an architecture and a strategy, not a product — vendors sell "zero trust solutions" but it is achieved through many controls working together. And it is implemented incrementally; a wholesale switch is not realistic for an existing estate.

Ransomware encrypts an organisation's data and demands payment for the key. Modern operations use double extortion — exfiltrating data before encrypting, so refusing to pay still risks publication. That changes the calculus, because good backups no longer remove the leverage entirely.

The typical chain: initial access through phishing, an exposed remote access service, or an unpatched internet-facing system → credential theft and privilege escalation → lateral movement → deletion of backups and shadow copies → mass encryption.

Prevention, mapped to that chain:

• Close the entry points. MFA on all remote access, no RDP exposed to the internet, and prompt patching of internet-facing systems.
• Limit lateral movement. Network segmentation, no shared local administrator passwords, and tiered administrative accounts.
• Endpoint detection and response that can spot mass file modification and isolate the host automatically.
• Application allowlisting and macro restrictions.

Recovery — the decisive control:

• Immutable, offline, or air-gapped backups. Attackers specifically target backups first, so a backup reachable with the credentials they stole is worthless. This is the single most important defence.
• Tested restores with a known recovery time.
• An incident response plan that assumes systems are unavailable — including offline copies of the plan itself and out-of-band communication.

Note: On paying: law enforcement advises against it, roughly a third who pay do not recover all data, and payment may breach sanctions rules. It is a business and legal decision, not a technical one.

A SIEM (Security Information and Event Management) platform centralises logs from across the estate, correlates events, and raises alerts. Its value is correlation: a failed login on one system is noise, but failed logins across twenty systems from one source followed by a success is an attack, and only a central view reveals that.

What to feed it, in rough priority:

• Authentication logs — domain controllers, VPN, cloud identity providers. Most attacks involve credentials at some point.
• Endpoint detection and response telemetry — process creation, and parent-child relationships, which is where malicious activity actually shows.
• Firewall, proxy, and DNS logs for command-and-control and exfiltration.
• Cloud audit logs — CloudTrail or Azure Activity Log.
• Critical application and database logs.

Making it work:

• Start with high-fidelity detections rather than enabling every rule. A SIEM producing 500 alerts a day is ignored, which is worse than no SIEM.
• Tune continuously. Every false positive should either be suppressed or the rule refined.
• Map coverage to MITRE ATT&CK to find gaps deliberately instead of hoping.
• Protect the logs. Ship them off-host immediately and make them immutable — attackers clear logs, and a log an attacker can delete is not evidence.

Note: Measure with mean time to detect and mean time to respond. Alert volume is not a success metric.