Hard Cyber Security Interview Questions

A zero-day is a flaw that the vendor does not know about or has not yet patched, so defenders have had zero days to fix it. Exploits for zero-days are valuable and often used in targeted attacks. Since patches are unavailable, defence relies on layered controls: EDR behaviour detection, network segmentation, least privilege, virtual patching with WAF or IPS rules, and fast patching once a fix is released.

CVSS alone is not enough. I combine severity with exploitability and exposure: check the CISA Known Exploited Vulnerabilities list and EPSS score, whether the asset is internet facing, and how critical the business data on it is. Internet-facing systems with known exploited flaws are fixed first, often within days. Internal low-severity findings go into normal patch cycles. Group fixes by patch to reduce effort.

Secure Access Service Edge combines networking, such as SD-WAN, with cloud-delivered security services: secure web gateway, CASB, ZTNA and firewall as a service. Users connect to the nearest provider point of presence, and policy follows them anywhere. It suits Indian companies with many branches and hybrid workers because traffic no longer has to backhaul to a head office data centre. Vendor lock-in and migration effort are the trade-offs.

Egress filtering controls outbound traffic, allowing only needed destinations and ports. It blocks malware call-backs, data exfiltration and servers reaching the internet directly. Many networks allow all outbound traffic because it is easier and legacy apps have undocumented dependencies. A practical approach is forcing web traffic through a proxy, blocking direct outbound from servers, and allowing exceptions only with business justification.

Confirm it is an attack and not a traffic spike by checking request patterns, user agents and source spread. Enable or tighten the CDN or WAF bot protection and rate limits on targeted URLs, add challenge pages for suspicious clients, and cache heavy pages. Inform the ISP or DDoS provider and management. After the attack, review logs, tune rules and update the runbook.

I would start by inventorying applications and who uses them, then pick a low-risk app group for a pilot with an identity-aware proxy or ZTNA service. Integrate it with the identity provider, enforce MFA and device posture checks, and monitor access logs. Expand app by app, keep the VPN for legacy needs during transition, and retire it once every app is covered and tested.

AES-GCM is an authenticated encryption mode, so it gives confidentiality and integrity together, detecting any tampering through its authentication tag. AES-CBC gives only confidentiality and needs a separate MAC; mistakes in combining them caused padding oracle attacks. GCM is also fast with hardware support. Its main rule is never reusing a nonce with the same key, because reuse breaks both confidentiality and integrity.

An HSM is tamper-resistant hardware that generates, stores and uses cryptographic keys without exposing them. Keys never leave the device in plain form. Banks and payment processors use HSMs for PIN processing, card keys and signing, and CAs protect root keys with them. Cloud offerings include managed HSM and KMS services. HSMs are often required for compliance standards such as PCI DSS and certified to FIPS 140-3.

Key management covers generating, distributing, storing, rotating, backing up and destroying keys. It is hard because strong encryption is useless if keys sit in code, config files or shared drives. Good practice is a central KMS or vault, envelope encryption with data keys wrapped by master keys, automatic rotation, strict IAM on key usage and logging every decrypt call. Losing keys can also mean losing data permanently.

Large quantum computers could break RSA and elliptic curve cryptography using Shor's algorithm. NIST published post-quantum standards in 2024: ML-KEM for key exchange, and ML-DSA and SLH-DSA for signatures. Attackers can harvest encrypted traffic now and decrypt it later, so long-lived sensitive data is at risk. Organisations should inventory cryptography, prefer crypto agility, and test hybrid key exchange that browsers already support.

Certificate Transparency requires publicly trusted CAs to log every issued certificate in public append-only logs. Browsers require proof of logging before trusting a certificate. Domain owners can monitor these logs to detect certificates issued for their domains without permission, for example by a compromised CA or a phishing actor. Security teams also use CT logs for subdomain discovery and asset inventory.

MD5 is fast and broken, so these hashes can be cracked quickly if leaked. Recommend Argon2id or bcrypt with proper cost settings. To migrate without forcing resets, wrap existing hashes: compute Argon2id over the MD5 value now, and on next login replace it with a direct Argon2id hash of the password. Also check whether the database was ever exposed, and enforce MFA.

Treat it as compromised. Revoke the certificate with the CA, issue a new one with the key generated and stored in an HSM or cloud key service, and restrict signing to the build pipeline. Search for any binaries signed with the old key after the exposure time and investigate them. Remove the file, check drive access logs to see who opened it, and update the key handling policy.

Combine several sources: scan network services for TLS versions, ciphers and certificate keys; query CT logs and internal PKI for issued certificates; use code scanning to find crypto library calls and hardcoded keys; and export KMS and HSM key lists. Record algorithm, key length, owner, data sensitivity and expiry. This inventory supports compliance, certificate renewals and planning the post-quantum migration.

Create a customer managed key in the cloud KMS with strict IAM so only the app role can use it. The app asks KMS for a data key, encrypts records locally with AES-GCM using the plaintext data key, stores the encrypted data key next to the data, and discards the plaintext key. To decrypt, it sends the encrypted data key to KMS. Enable key rotation and audit logging.

Detection engineering treats detections like software: rules are written from threat models and ATT&CK techniques, stored in version control, tested with attack simulations, peer reviewed and measured for false positive rate. Formats like Sigma let rules be shared across SIEMs. Teams track coverage, tune noisy rules and retire obsolete ones. This replaces ad hoc rule creation that leads to noisy, untested alerts.

Analyse alert data to find the top noisy rules, which usually create most of the volume. Tune them with context and allowlists, or turn low-value ones into dashboards. Add enrichment and automated closure for known benign patterns using SOAR, group related alerts into incidents and add risk-based alerting that scores entities. Track false positive rate per rule weekly and require testing for new rules.

Situation: during a suspected malware case, a senior engineer wanted to wipe the laptop immediately to save time. Task: contain the threat while preserving evidence. Action: I explained that we needed a memory capture and EDR timeline first, which would take 20 minutes, and isolated the laptop meanwhile. Result: the capture revealed stolen browser credentials, so we reset them before they were misused.

Legal advises on regulatory notification, such as CERT-In within six hours and the Data Protection Board and affected people under the DPDP Act, contractual duties to clients, evidence handling and privilege. Communications manage messaging to customers, staff, media and investors so statements are accurate and consistent. Technical teams should involve them early, because poor communication can cause more damage than the incident itself.

Activate the incident plan and set up a war room with a separate communication channel. Contain by isolating affected segments, disabling compromised accounts, and blocking known command and control. Preserve evidence from a few hosts. Identify initial access and scope, including data theft. Verify offline backups, rebuild from clean images, and restore by business priority. Report to CERT-In within six hours and involve legal before any ransom discussion.

Do not just delete it. Capture the file, web logs and a memory image if possible, then identify when it was created and which request uploaded it. Search logs for commands executed through it and lateral movement from the server. Contain by isolating the server or blocking the path at the WAF, then patch the vulnerable application, rebuild from a clean image and rotate any credentials stored on it.

Search the hash, file name and parent process across all endpoints, and look for related indicators like network destinations and persistence mechanisms. Build a timeline to find patient zero and the delivery method, for example an email attachment or a compromised software update. Group affected hosts by criticality, isolate them, and check whether any credentials were stolen to plan resets broadly.

Deactivate the key immediately and check who owns it. Review cloud audit logs for every action taken with it, such as new instances, users, roles or policy changes, because attackers often create persistence. Terminate unauthorised resources, delete created users and keys, and check billing impact. Then find how it leaked, move workloads to roles with short-lived credentials and enable budget and anomaly alerts.

Collect timestamps from many sources: Windows event logs, file system MFT records, prefetch, browser history, EDR telemetry, proxy, firewall and cloud logs. Normalise all of them to UTC, then merge them using tools like Plaso and Timeline Explorer. Mark key points such as initial access, privilege escalation, lateral movement and exfiltration. The timeline drives scoping, root cause and the incident report.

Common attacks are password spraying, Kerberoasting, which requests service tickets for accounts with SPNs and cracks them offline, AS-REP roasting on accounts without pre-authentication, pass-the-hash, DCSync to pull password hashes, and abusing misconfigured ACLs and delegation. Defences include long random service account passwords or gMSAs, tiered admin models, LAPS for local admin passwords, Protected Users group and monitoring ticket requests.

Service accounts and API keys often have broad privileges, never expire, are shared among teams and are excluded from MFA. Machine identities now outnumber human ones in cloud environments. Risks include hardcoded secrets and silent abuse. Controls are an inventory with owners, least privilege, managed identities or workload identity federation instead of static keys, secret rotation, and monitoring for interactive logins.

Start with assessment: their AD health, privileged accounts, trust relationships, MFA coverage and any signs of compromise. Avoid creating a full two-way forest trust early, as it can import their risks. Prefer bringing users into your cloud identity provider with B2B access or migration, with conditional access. Reset privileged credentials, apply your tiering model, and migrate application by application.

Create two cloud-only emergency accounts excluded from normal conditional access but protected by FIDO2 keys stored in a safe. Use long random passwords, store them split between two senior people or in a sealed vault, and give them the minimum emergency role. Alert the SOC on any sign-in, and test them every quarter. They exist for identity provider outages or misconfigured policies.

Remove standing admin roles. Make users eligible for roles through a PIM or PAM tool, so they request activation with justification, MFA and optional approval, for a limited time like two hours. Log every activation and alert on unusual ones. For automation, use workload identities with narrow roles instead of admin keys. Review eligible assignments quarterly to keep the list small.

CSPM, Cloud Security Posture Management, checks cloud configurations against benchmarks like CIS and flags risks. CWPP, Cloud Workload Protection Platform, protects running workloads such as VMs, containers and serverless with vulnerability scanning and runtime detection. CNAPP combines these with identity analysis, IaC scanning and attack path analysis in one platform. The goal is to prioritise risks that combine, like a public VM with a critical flaw and admin role.

Cloud VMs can query a local metadata endpoint at 169.254.169.254 to get instance details and temporary role credentials. If an application has a server-side request forgery flaw, an attacker can make it fetch these credentials. AWS IMDSv2 requires a session token obtained with a PUT request and limits hops, which blocks most SSRF abuse. Enforce IMDSv2 and give instance roles minimal permissions.

Use minimal, scanned base images and sign them. Run containers as non-root with read-only filesystems and dropped capabilities. In Kubernetes, enforce Pod Security Standards, use RBAC with least privilege, network policies to restrict pod traffic, secrets from an external store, and keep the API server private. Enable audit logs and runtime detection such as Falco, and patch clusters regularly.

Separate accounts or subscriptions for production, development, security tooling, logging and shared services create strong blast-radius boundaries and simpler permissions. A compromised dev account cannot touch production. Central guardrails like AWS Service Control Policies or Azure Policy enforce rules everywhere, and a dedicated log archive account protects audit logs. Landing zone frameworks automate this setup for new teams.

The DPDP Act 2023 allows cross-border transfer of personal data except to countries the government restricts, though sector rules can be stricter. RBI requires payment system data to be stored only in India. CERT-In requires ICT logs to be kept in India for 180 days. SEBI and IRDAI have their own requirements for regulated entities. Cloud architects choose Indian regions such as Mumbai or Hyderabad for compliance.

I would require a landing zone with separate accounts, Indian region hosting for data residency, private networking with no public database endpoints, WAF and DDoS protection, customer managed KMS keys, PAM for admin access, central immutable logging to the SIEM, CSPM against CIS benchmarks, vulnerability scanning in CI, and a tested backup and disaster recovery plan. All mapped to RBI and audit requirements.

Capture the pod spec, image digest, logs and runtime alerts before deleting anything. Check how it got in: a vulnerable app, a compromised image in the registry or an exposed dashboard or kubelet. Review Kubernetes audit logs for who created the workload and what service account it used. Cordon affected nodes, rotate service account tokens and secrets, patch the entry point and enforce image signing.

Use workload identity federation with OIDC. The CI system issues a short-lived signed token for each job, and the cloud provider trusts that issuer and exchanges the token for temporary credentials of a narrow role. Restrict the trust policy to a specific repository and branch. This removes long-lived secrets from pipeline settings, so a leaked log or variable no longer gives permanent access.

Situation: in one quarter I had an ISO surveillance audit, a client security questionnaire backlog and a regulator report due. Task: deliver all without missing dates. Action: I listed every deliverable with owners and deadlines in a tracker, reused a central evidence library for overlapping requests, and gave weekly status to my manager. Result: everything was delivered on time with no major findings.

RBI issues directions for banks, NBFCs and payment operators, including the IT governance and risk management directions and the cyber security framework for banks. SEBI issued the Cybersecurity and Cyber Resilience Framework for regulated entities in 2024. IRDAI has information and cyber security guidelines for insurers. All require board-approved policies, SOC monitoring, incident reporting and periodic audits.

Get leadership sponsorship and define the ISMS scope. Run a gap assessment against clauses and Annex A, then do the risk assessment and build the risk treatment plan and Statement of Applicability. Write core policies, implement missing controls, and train staff. Collect evidence for a few months, run an internal audit and management review, fix findings, then book stage 1 and stage 2 audits.

I would avoid a single score and present risk in business terms: the top five cyber risks, such as ransomware and third-party breach, with likelihood, impact and trend. Show maturity against NIST CSF 2.0 with current and target levels, key metrics like MFA coverage, patch timeliness and incident response times, and the investments needed to close gaps. Keep it to a few slides.

Describe the processing: what personal data, purpose, legal basis, data flows, storage, retention and vendors. Assess risks to individuals, such as unauthorised access or excessive collection, and evaluate safeguards like encryption, access control and minimisation. Recommend changes, get sign-off from the data protection officer or privacy lead, and review it when processing changes. Significant data fiduciaries must perform periodic DPIAs and audits.