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 interviewer is testing risk-based judgement and partnership. They want to see that you can hold a security line without becoming “the department of no”. Use the STAR structure and keep the focus on how you handled the people and the trade-off, not only the technical flaw.

• Situation — set the stakes briefly. For example: “Two days before a customer portal launch, I found during a staging review that the invoice API returned any customer’s invoice if you changed the ID in the URL.”
• Task — your responsibility was to assess the real risk and help the team reach a decision, not to block the release on your own authority.
• Action — show the steps: you confirmed the issue with two test accounts, rated it in context (internet-facing, no special privileges needed, personal data exposed), and explained it to the developers with a clear reproduction rather than an accusatory ticket. Then you laid out options: fix now, delay launch, or launch with a compensating control such as disabling the feature behind a flag. If anyone proposed accepting the risk, it went to the business owner in writing.
• Result — quantify: “The developers added an ownership check in one day, we added an automated test to CI so the same bug could not return, and the launch went ahead on time.”

Points that impress: you understood the business pressure, you offered solutions rather than only problems, you respected who owns the risk decision, and you fixed the root cause (a missing authorisation pattern) rather than a single endpoint.

Note: Avoid stories where you “refused to let it go live” unilaterally. Unless policy gave you that authority, the stronger answer is that you escalated to the accountable risk owner with a clear recommendation.

This question checks whether you can translate technical risk into business language. Security teams that cannot do this struggle to get budget or decisions, so interviewers weigh it heavily for mid-level and senior roles.

Structure your answer around four moves:

1. Lead with business impact, not jargon. Instead of “a CVSS 9.8 pre-auth RCE on our VPN concentrator”, say “anyone on the internet could get into our internal network without a password, and criminals are actively using this exact flaw in ransomware attacks.”
2. Quantify where you can. Likely downtime, number of customer records exposed, regulatory consequences, and what similar incidents cost peers.
3. Offer options with costs. For example: patch this Saturday with a two-hour outage; apply a temporary mitigation today and patch next week; or accept the risk, with a named owner signing off.
4. Ask for a specific decision and a deadline, then confirm it in writing.

Example points to include: you prepared a one-page brief rather than a slide deck full of screenshots, you used an analogy the audience understood (such as leaving the office’s back door unlocked), you anticipated the question “has anyone else been hit?”, and the outcome was an approved emergency change window.

What to avoid: fear-mongering, drowning executives in detail, or presenting a problem with no recommendation. Also avoid implying that management was foolish; the point is that you made the decision easy for them.

Note: Close by saying what you learned, for example that you now keep a standard risk-brief template so urgent issues get decisions within hours rather than days.

The interviewer is looking for integrity combined with tact and due process. Policies must apply to everyone, but the way you handle a senior person matters as much as the outcome.

A strong answer walks through these steps:

• Establish the facts first. Confirm what you saw, for instance from a DLP alert or mail logs, without jumping to conclusions. Record what data was involved and when.
• Assess the impact. Was the data confidential or personal? If personal data has left the organisation’s control, it may be a personal data breach, and the privacy or legal team must assess any notification duties under the DPDP Act.
• Follow the escalation path. Report through your manager or the CISO rather than confronting the executive publicly or discussing it with colleagues. Keep it confidential.
• Understand the reason. Executives usually bypass controls because something gets in their way, such as a clumsy file-sharing tool or no mobile access while travelling. That is useful feedback.
• Fix the root cause. Provide a secure alternative (approved cloud sharing, a managed mobile device), request deletion of the copies from the personal account, and reinforce the policy.

Example to mention: “In a previous role, a DLP rule flagged board papers going to a Gmail address. I escalated to the CISO, who spoke to the executive. It turned out his tablet could not open the secure portal. We fixed access within a week and the behaviour stopped.”

Note: Senior executives are prime targets for whaling and business email compromise, so their exceptions carry more risk, not less. Make that point calmly and you show both judgement and courage.

Everyone makes mistakes in operations. The interviewer wants to see ownership, honesty and systemic thinking. Choose a real mistake of moderate size, one that was caught and contained, not a catastrophe caused by negligence.

Structure it in four parts:

1. The mistake, owned plainly. For example: “While tuning a noisy SIEM rule for failed logins, I added an exclusion that was too broad. It suppressed alerts for an entire subnet, including a server segment.”
2. How it was detected. “A weekly detection-coverage review showed that the rule had gone silent for that subnet, which was unusual.”
3. Immediate correction. “I rolled back the exclusion, then searched the raw logs for the eight days it was active to confirm nothing had been missed. I informed my lead straight away rather than quietly fixing it.”
4. The systemic fix. This is the most important part: “I proposed that all detection changes go through peer review in a change ticket, and we added an alert that fires when any rule stops producing events.”

What makes the answer strong: you did not blame the tool or a colleague, you told people quickly, you verified the impact rather than assuming, and you changed a process so the whole team benefited. Mention the blameless post-incident review culture if your team used one.

Pitfalls to avoid: fake mistakes (“I work too hard”), stories where the real lesson is that someone else was at fault, and mistakes that suggest a lack of basic care, such as sharing credentials.

Note: A security professional who hides errors is dangerous. Showing that you surface them quickly is itself a security competence.

This question tests whether you can triage under pressure without missing the one alert that matters, and whether you improve the system rather than just surviving it.

Explain your triage logic:

• Severity and confidence — a high-fidelity EDR detection of credential dumping outranks a generic “suspicious login” rule.
• Asset and identity criticality — the same alert on a domain controller or a finance administrator’s account is more urgent than on a test VM.
• Correlation — several low alerts on one host or user within an hour often outweigh one medium alert on its own.
• Playbooks — you follow documented runbooks so decisions are consistent, and you escalate to L2 early when scope looks larger than one asset.

Then show how you reduced the noise: “About 40 percent of our alerts came from an impossible-travel rule firing whenever staff connected through the corporate VPN. I documented the pattern, raised it with detection engineering, and we excluded known VPN egress addresses. Volume fell sharply and our mean time to triage for the remaining alerts improved.”

Other good points: using SOAR to auto-enrich alerts with WHOIS, reputation and asset owner data; tracking false-positive rates per rule; never suppressing a rule silently; and writing clear case notes so the next shift can continue the work.

What interviewers dislike: answers implying you close alerts in bulk to hit a queue target, or that you ignore a category of alert because “it is always a false positive”.

Note: Mention metrics such as MTTD and MTTR, and say you treat every false positive as a tuning opportunity. That signals you think like a detection engineer, not only a ticket handler.

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.

Threat modelling is a structured way of finding and fixing security weaknesses while a system is still being designed, when changes are cheap. A popular framing asks four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job?

A typical process:

1. Draw a data flow diagram showing external entities, processes, data stores, data flows and, most importantly, trust boundaries (for example, between the internet and your API, or between the app and the database).
2. Walk each element and flow through STRIDE to generate threats.
3. Rate each threat, decide on a mitigation, and track it as a work item.
4. Validate that the mitigations were built and tested.

Example: for a mobile banking login flow, spoofing leads you to device binding and MFA; tampering leads you to sign transaction requests; repudiation leads you to log every transfer with the user, device and time.

Note: Mention alternatives to show breadth: PASTA is risk-centric, attack trees suit specific goals, and LINDDUN focuses on privacy threats. Threat modelling works best as a short, repeated team exercise, not a one-off document.

Multi-factor authentication requires evidence from at least two different categories: something you know (password, PIN), something you have (phone, security key) and something you are (fingerprint, face). Stealing one factor is then not enough. It blocks the large majority of automated credential-stuffing and password-spray attacks.

Not all MFA is equal. From weakest to strongest:

• SMS or voice OTP — vulnerable to SIM-swap fraud, interception and phishing. Better than nothing, but the weakest option.
• Authenticator app codes (TOTP) — no SIM risk, but a user can still type the code into a fake site, and an attacker-in-the-middle proxy relays it in real time.
• Push notifications — convenient, but prone to MFA fatigue, where attackers trigger repeated prompts until the user taps approve. Number matching and showing location context reduce this.
• FIDO2/WebAuthn (security keys, passkeys) and smart cards — phishing-resistant. The credential is cryptographically bound to the genuine website’s origin, so a lookalike domain simply cannot obtain a valid response, whatever the user does.

Where MFA still fails:

• Session token theft — if malware or a phishing proxy steals the session cookie after login, MFA has already been satisfied. Short session lifetimes and device-bound sessions help.
• Weak recovery flows — a help desk that resets MFA over the phone becomes the easiest path in.
• Legacy protocols that do not support MFA, such as basic authentication on old mail protocols, must be disabled.

Note: A strong answer recommends phishing-resistant MFA for administrators and high-risk users first, combined with risk-based or conditional access that considers device health, location and behaviour.

All three are used for federated access, but they solve different problems, and confusing them is a common interview mistake.

OAuth 2.0 lets a user grant an application limited access (scopes) to a resource without sharing their password. The access token says what the client may do; it does not reliably tell the client who the user is. Using OAuth alone for login is a known anti-pattern.

OpenID Connect adds an ID token containing claims such as the issuer, subject, audience, expiry and nonce, so the client can verify who authenticated. It is the modern choice for consumer and mobile login.

SAML 2.0 is older and XML-based. An identity provider (such as Entra ID or Okta) sends a signed assertion through the browser to a service provider. It remains very common for workforce SSO.

Security points worth mentioning:

• Use the authorisation code flow with PKCE; the implicit flow is deprecated.
• Register exact redirect URIs and use the state parameter against CSRF.
• Always validate token signature, issuer, audience and expiry.
• For SAML, validate signatures strictly to avoid XML signature-wrapping attacks.

Note: A neat summary: OAuth answers “what can this app do?”, OIDC and SAML answer “who is this user?”.

These three are often confused, and mixing them up in an interview is a red flag.

• Encoding (Base64, URL encoding) changes the representation of data so it can travel safely. There is no key and anyone can reverse it. It provides no security.
• Encryption (AES, RSA) is reversible, but only with the correct key. It protects confidentiality.
• Hashing (SHA-256, SHA-3) is a one-way function producing a fixed-length digest. A good hash is preimage resistant (you cannot recover the input) and collision resistant (you cannot find two inputs with the same digest). It supports integrity checks. MD5 and SHA-1 are broken for collision resistance and should not be used for security.

Why passwords need special handling: general-purpose hashes are designed to be fast, and a modern GPU can compute billions of them per second, so a leaked table of plain SHA-256 password hashes falls quickly to guessing. Passwords should instead use a deliberately slow, tunable password hashing function: Argon2id (preferred), scrypt, bcrypt or PBKDF2 with a high iteration count.

Salting: a unique random value generated for each user and stored alongside the hash. It means two users with the same password get different hashes, and it defeats precomputed rainbow tables, because an attacker must attack each hash separately.

Peppering: an additional secret applied to every password, stored outside the database, for example in a secrets vault or HSM. If only the database leaks, the hashes cannot be attacked without the pepper.

Related tool: an HMAC combines a hash with a secret key to prove that a message came from someone holding the key and was not altered.

Note: Never say passwords are “encrypted” in the database. They should be salted and hashed with a slow algorithm, and the work factor should be raised over time as hardware improves.

Public Key Infrastructure (PKI) is the set of roles, policies, software and hardware used to create, distribute, validate and revoke digital certificates. It answers a key question in asymmetric cryptography: how do I know this public key really belongs to the site or person it claims to?

Core components:

• Certificate Authority (CA) — a trusted party that signs certificates. A root CA is kept offline; intermediate CAs do the day-to-day signing so the root key is rarely exposed.
• Registration Authority — verifies the identity of the requester before the CA issues.
• X.509 certificate — binds a public key to an identity. It contains the subject, Subject Alternative Names (the hostnames it covers), issuer, validity dates, key usage and the CA’s signature.
• Trust store — the list of root CAs that operating systems and browsers trust by default.

Chain of trust: a browser receives the server certificate and any intermediates, verifies each signature up to a root in its trust store, checks the hostname matches a SAN entry, and checks the certificate is within its validity period and not revoked.

Revocation: certificates whose keys are compromised are revoked via CRLs (published lists) or OCSP (online status queries). OCSP stapling lets the server attach a signed status response, improving privacy and speed.

Other points worth knowing:

• Certificate Transparency logs publicly record issued certificates, so organisations can spot mis-issued certificates for their domains.
• CAA DNS records restrict which CAs may issue for a domain.
• Private keys should be protected, ideally in an HSM for CAs and critical services.

Note: Public TLS certificate lifetimes are being shortened in stages under a CA/Browser Forum decision, which makes automated renewal (for example via the ACME protocol) essential. Expired certificates are a very common cause of outages.

TLS 1.3 completes a full handshake in one round trip and encrypts most of the handshake itself. The goals are to agree keys securely, authenticate the server, and protect the rest of the session.

1. ClientHello — the client sends the TLS versions and cipher suites it supports, a random value, the server name (SNI) and, crucially, a key share: its ephemeral Diffie-Hellman public value, commonly X25519 or another elliptic curve group.
2. ServerHello — the server picks a cipher suite and returns its own key share. Both sides now compute the same shared secret using ephemeral (EC)DHE and derive handshake keys with HKDF. From this point the handshake is encrypted.
3. EncryptedExtensions, Certificate, CertificateVerify — the server sends its certificate chain, then signs a hash of the whole handshake transcript with its private key. That signature proves it holds the private key matching the certificate.
4. Server Finished — a MAC over the transcript, proving nothing was tampered with.
5. Client verification and Finished — the client validates the chain, the hostname and the signature, then sends its own Finished message. Application data now flows, protected by an AEAD cipher such as AES-GCM or ChaCha20-Poly1305.

Key differences from TLS 1.2:

• Static RSA key exchange was removed, so forward secrecy is mandatory: stealing the server’s private key later does not decrypt past sessions.
• Weak options such as CBC-mode ciphers, RC4 and SHA-1 signatures were removed.
• The handshake is shorter: one round trip instead of two.

0-RTT resumption lets a returning client send data immediately, but that early data can be replayed, so it should only be used for idempotent requests.

Note: SNI is still visible in plaintext unless Encrypted Client Hello is used, which is why network filters can see which site you visit even over TLS 1.3.

Network segmentation divides a network into separate zones and controls what traffic may pass between them. On a flat network, an attacker who compromises one laptop can reach every server, database and domain controller. Segmentation turns one breach into a contained incident.

Traditional segmentation uses VLANs, subnets and firewalls or ACLs between zones, for example:

• A DMZ for internet-facing services.
• Separate zones for user endpoints, servers, databases, guest Wi-Fi, OT/industrial systems and a dedicated management network for admin interfaces.
• An isolated cardholder data environment under PCI DSS, which also shrinks audit scope.

Micro-segmentation applies the same idea at the level of individual workloads. Policies follow the application or identity rather than the IP subnet, using host firewalls, cloud security groups, software-defined networking or service meshes. It controls east-west traffic between servers in the same data centre, which traditional perimeter firewalls rarely inspect.

How to implement it well:

1. Build an asset inventory and map legitimate application flows first.
2. Start with the crown jewels: domain controllers, databases, backup servers.
3. Move to default deny, allowing only documented flows.
4. Monitor denied traffic, then test that the rules actually block what they should.

Benefits: contains ransomware spread, protects backups from being encrypted alongside production, makes anomalous traffic easier to detect, and supports zero trust principles.

Common failures: “any-any” rules added during an outage and never removed, management interfaces reachable from user networks, and backup servers sitting in the same segment as everything else.

Note: Segmentation is only as good as its rule review process. Rules should have owners, business justifications and periodic recertification.

A Security Operations Centre (SOC) is the team, process and technology that monitors an organisation continuously, detects threats and coordinates the response. It may be in-house, outsourced to a managed security provider, or a hybrid.

Core functions: security monitoring, alert triage, investigation, incident response, threat hunting, detection engineering, threat intelligence and reporting.

A SOC manager oversees staffing, metrics and escalation to the CISO and business.

A typical alert workflow:

1. An alert fires in the SIEM or EDR.
2. Automated enrichment adds asset owner, user details, IP reputation and related alerts.
3. L1 triages: benign, false positive, or suspicious.
4. Suspicious cases are escalated with clear notes.
5. L2 confirms, scopes and contains, following an incident response playbook.
6. The case is closed with root cause, actions taken and any tuning feedback.

Common tools: SIEM, EDR/XDR, SOAR for automation, a case management system and a threat intelligence platform.

Key metrics: mean time to detect (MTTD), mean time to respond (MTTR), attacker dwell time, false-positive rate per rule and detection coverage mapped to MITRE ATT&CK.

Note: Entry-level candidates should stress curiosity, clear note-taking and knowing when to escalate. Escalating too late is a much bigger failure than escalating something that turns out to be benign.

The most widely cited model is from NIST SP 800-61. Its Revision 2 describes four phases, and the SANS model splits the same work into six steps (PICERL).

1. Preparation — an incident response plan and playbooks, defined roles, an on-call rota, contact lists (legal, PR, regulators, insurers), logging and EDR in place, jump bags and forensic tools ready, and regular tabletop exercises. Most of an incident’s outcome is decided here.
2. Detection and analysis — identify that something is happening from alerts, user reports or third parties; validate it; determine scope, severity and affected assets; start a timeline and preserve evidence.
3. Containment — short-term actions to stop the spread (isolate hosts, disable accounts, block IPs or domains) and longer-term measures that keep the business running while the root cause is found.
4. Eradication — remove the attacker: delete malware and persistence mechanisms, close the entry point, reset compromised credentials, patch the exploited vulnerability.
5. Recovery — restore systems from known-good sources, return them to production in stages, and monitor closely for re-infection.
6. Lessons learned — a blameless review, usually within two weeks, covering what happened, what worked, what did not, and concrete actions with owners.

Cross-cutting activities: communication with stakeholders, documentation of every decision, chain of custody for evidence, and meeting legal and regulatory reporting deadlines. In India, specified incidents must be reported to CERT-In within six hours of being noticed.

NIST’s Revision 3, published in 2025, reframes incident response around the six functions of the Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), treating response as part of overall risk management rather than a standalone cycle.

Note: Interviewers like candidates who stress that containment decisions are business decisions too. Pulling a payment server offline stops the attacker but also stops revenue, so the incident commander must involve the business owner.

Malware is any software designed to harm, spy on or take control of systems. Categories overlap, and modern attacks often chain several together.

Common delivery routes: phishing attachments and links, malicious macros, drive-by downloads, cracked software, infected USB drives and exploitation of unpatched internet-facing services.

Defences that work across types:

• Prompt patching and removal of unnecessary services.
• EDR that detects behaviour, not only known signatures.
• Application allowlisting and blocking macros from internet-sourced documents.
• Least privilege, so malware running as a normal user cannot take over the system.
• Email and web filtering, plus tested offline or immutable backups.

Note: The virus-versus-worm distinction is a classic question: a virus needs a host file and user action, a worm spreads by itself across the network.

Vulnerability management is a continuous programme, not a monthly scan. The lifecycle usually runs:

1. Asset discovery — you cannot protect what you do not know about, including cloud resources and shadow IT.
2. Identification — authenticated scanning, agent-based scanning, container and code scanning, plus vendor advisories and bug bounty reports.
3. Assessment and prioritisation — rate each finding in the context of your environment.
4. Remediation — patch, change configuration, apply a compensating control, or formally accept the risk with an owner and an expiry date.
5. Verification — rescan to confirm the fix worked.
6. Reporting — track SLA compliance, ageing and trends.

CVSS (Common Vulnerability Scoring System) rates the technical severity of a vulnerability from 0 to 10. The base score considers exploitability (attack vector, attack complexity, privileges required, user interaction) and impact on confidentiality, integrity and availability. Ratings map to Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9) and Critical (9.0–10.0). CVSS v4.0 also defines threat and environmental metrics so organisations can adjust the score.

The problem: thousands of CVEs score High or Critical every year, yet only a small fraction is ever exploited. Severity alone creates an impossible queue.

Better prioritisation adds:

• EPSS (Exploit Prediction Scoring System) — a probability that a vulnerability will be exploited in the next 30 days.
• CISA Known Exploited Vulnerabilities (KEV) catalogue — vulnerabilities with confirmed exploitation in the wild. These go to the top.
• Asset context — is it internet-facing, does it hold sensitive data, is it a critical business system?

Note: A mature answer mentions SLAs tied to risk, for example exploited and internet-facing within days, and recognises that some systems cannot be patched quickly, so segmentation and virtual patching through a WAF or IPS serve as interim controls.

A professional penetration test follows a structured methodology so it is safe, legal and repeatable. Well-known references include PTES, the OWASP Web Security Testing Guide, NIST SP 800-115 and OSSTMM.

1. Pre-engagement and scoping — agree the targets (IP ranges, applications, cloud accounts), what is out of scope, testing windows, the test type (black, grey or white box), emergency contacts and a stop procedure. Written authorisation from someone with authority over the systems is mandatory; testing without it can be a criminal offence.
2. Reconnaissance — passive information gathering (public DNS, certificate transparency logs, job adverts, leaked credentials in breach data) and then active discovery of hosts and services.
3. Scanning and enumeration — identify open ports, service versions, users, shares and application endpoints.
4. Vulnerability analysis — combine automated findings with manual analysis to decide which weaknesses are real and worth attempting.
5. Exploitation — carefully demonstrate that a weakness can actually be used, with minimal disruption. The aim is proof of impact, not damage.
6. Post-exploitation — within scope, assess what an attacker could reach from that foothold: privilege escalation, lateral movement, access to sensitive data. Everything is logged and any artefacts are removed afterwards.
7. Reporting — an executive summary in business language, then detailed findings with risk ratings, evidence, reproduction steps and practical remediation advice.
8. Retesting — verify that fixes are effective.

Box types: black box gives no inside knowledge; grey box gives partial knowledge such as user credentials; white box gives source code and architecture, and usually finds the most in the time available.

Note: Interviewers value candidates who emphasise the report. A brilliant test with a confusing report delivers little value, because the client cannot act on it.

In the shared responsibility model, the cloud provider is responsible for security of the cloud, and the customer is responsible for security in the cloud. The dividing line moves depending on the service model.

The last row is the key point: data, identity and access configuration always remain the customer’s responsibility, whatever the service.

Common misconfigurations behind real breaches:

• Storage buckets or blobs left publicly readable.
• Overly broad IAM permissions, such as wildcard actions on all resources.
• Long-lived access keys committed to code repositories.
• Security groups allowing SSH or RDP from anywhere.
• No MFA on the root or global administrator account.
• Audit logging (for example AWS CloudTrail or Azure activity logs) disabled or not retained.
• Unencrypted snapshots or databases shared publicly.
• Instance metadata endpoints reachable through SSRF flaws, exposing temporary credentials.

Controls: guardrails through organisation-level policies, infrastructure as code with scanning before deployment, CSPM tools that continuously check configuration, CIEM for excessive permissions, short-lived role-based credentials instead of static keys, and central logging into the SIEM.

Note: A useful line in interviews: most cloud breaches are not caused by the provider being hacked; they are caused by customers misconfiguring the services they are responsible for.

Identity and access management (IAM) ensures the right identities have the right access to the right resources, for the right reasons, and that this stays true over time. Identity has become the main security perimeter in cloud and hybrid environments.

The identity lifecycle (joiner, mover, leaver): accounts are provisioned automatically from HR when someone joins, access changes when they move roles, and everything is revoked promptly when they leave. The mover stage is often neglected and causes privilege creep, where people accumulate access they no longer need.

Privileged access management (PAM) focuses on the most powerful accounts: domain admins, root, database administrators and cloud administrators. Typical controls:

• Credential vaulting with automatic rotation.
• Just-in-time elevation, so admin rights exist only for an approved time window.
• Session recording and monitoring.
• Separate admin accounts, never used for email or browsing.
• Tightly controlled break-glass accounts for emergencies.

Governing principles: least privilege, separation of duties (no one person can both create and approve a payment), regular access reviews by managers or data owners, and SSO with MFA to centralise control.

Note: Do not forget non-human identities such as service accounts, API keys and workload identities. In many organisations they outnumber human accounts and are poorly governed.

Good security logging lets you detect attacks, investigate incidents and prove accountability. Poor logging is repeatedly cited in breach reports as the reason attackers remained undetected for months.

Events worth logging:

• Authentication successes and failures, MFA events, lockouts and password resets.
• Authorisation failures, especially attempts to access other users’ objects or admin functions.
• Privilege and role changes, account creation and deletion.
• Access to or export of sensitive data.
• Administrative actions and configuration changes.
• Input validation failures and unexpected application errors.
• Security control events: antivirus, firewall, WAF and EDR actions.

Each entry should include: an accurate timestamp (synchronised to a trusted time source, ideally in UTC), the user or service identity, source IP, action, target object, outcome and a correlation or request ID.

What not to log: passwords, session tokens, full card numbers, encryption keys and unnecessary personal data. Logs themselves become sensitive data stores.

Protecting integrity:

• Forward logs in near real time to a central platform, so an attacker who compromises a host cannot simply erase local logs.
• Store them on immutable or write-once storage, or use hash chaining to make tampering evident.
• Restrict access, and separate log administrators from the system administrators being monitored.
• Alert when a log source stops sending, since silence can mean tampering.
• Define retention to meet legal needs. CERT-In’s 2022 directions require organisations in India to maintain ICT system logs for a rolling 180 days within Indian jurisdiction.

Note: OWASP’s logging guidance and NIST SP 800-92 are good references. Also mention log injection: user-supplied data written into logs should be encoded so it cannot forge entries.

ISO/IEC 27001 is the international standard for an information security management system (ISMS): a management framework for identifying information security risks and treating them systematically. Organisations can be independently certified against it, which is why clients, especially overseas ones, often ask Indian IT and services firms for it.

Structure of the standard:

• Clauses 4–10 are mandatory requirements: context of the organisation and scope, leadership commitment, planning (risk assessment and risk treatment), support (resources, competence, awareness, documented information), operation, performance evaluation (monitoring, internal audit, management review) and improvement (nonconformities and corrective action).
• Annex A lists reference controls. The 2022 edition has 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). ISO/IEC 27002 gives implementation guidance for them.

How the ISMS works in practice: it follows a Plan-Do-Check-Act cycle. You define scope, assess risks, choose controls and document why each Annex A control is included or excluded in a Statement of Applicability (SoA). You then operate the controls, measure them, audit internally, and improve.

Certification process:

1. A Stage 1 audit reviews documentation and readiness.
2. A Stage 2 audit tests whether controls are actually implemented and effective.
3. The certificate lasts three years, with annual surveillance audits and a recertification audit at the end.

Common interview follow-ups: ISO 27001 is risk-based, so it does not prescribe the same controls for everyone. It differs from SOC 2, which is an attestation report widely requested by US clients rather than a certification. And certification proves a managed process exists; it does not guarantee an organisation cannot be breached.

Note: Organisations certified to the 2013 version had to transition to the 2022 version by October 2025, so interviewers may ask what changed: the controls were consolidated from 114 to 93 and new ones were added, such as threat intelligence and cloud services security.

Organisations operating in India can face several parallel reporting obligations after an incident, and a strong candidate knows the main ones.

CERT-In Directions of 28 April 2022 (issued under Section 70B of the IT Act, 2000) apply broadly to service providers, intermediaries, data centres, body corporates and government organisations. Key requirements:

• Report specified cyber incidents to CERT-In within six hours of noticing them or being told about them. The listed types include targeted scanning of critical systems, compromise of systems, unauthorised access, website defacement, malware and ransomware attacks, data breaches and data leaks, and attacks on cloud or IoT systems.
• Maintain logs of all ICT systems for a rolling 180 days within Indian jurisdiction and provide them to CERT-In on request.
• Synchronise system clocks with the NTP servers of NIC or NPL, or with sources traceable to them.
• Designate a point of contact to interface with CERT-In.
• Data centres, VPS, cloud and VPN providers must keep specified subscriber information for five years.

Digital Personal Data Protection Act, 2023:

• A Data Fiduciary must take reasonable security safeguards to prevent personal data breaches.
• If a personal data breach occurs, it must intimate the Data Protection Board of India and each affected Data Principal.
• The Act’s schedule allows penalties of up to ₹250 crore for failing to take reasonable security safeguards and up to ₹200 crore for failing to notify a breach.
• The DPDP Rules, 2025 add operational detail, including a fuller report to the Board within 72 hours, and bring obligations into force in phases, so candidates should check the current commencement status.

In practice: a ransomware attack that exposes customer data can trigger the CERT-In six-hour report, DPDP notifications, and sector regulator requirements from bodies such as RBI, SEBI or IRDAI, each with its own format and timeline. Incident response plans should include a pre-approved reporting matrix and templates so legal and security teams are not working this out during the crisis.

Note: The six-hour clock runs from noticing the incident, not from completing the investigation. Report what you know, then update as facts emerge.

A distributed denial-of-service (DDoS) attack attempts to make a service unavailable by overwhelming it with traffic or requests from many sources, typically a botnet of compromised computers, servers or IoT devices. It is an attack on availability.

Three main categories:

• Volumetric attacks — saturate bandwidth, measured in bits per second. Reflection and amplification attacks send small spoofed requests to open DNS, NTP or memcached servers, which send much larger responses to the victim.
• Protocol attacks — exhaust state tables in servers, firewalls or load balancers, measured in packets per second. A SYN flood leaves thousands of half-open TCP connections.
• Application-layer (Layer 7) attacks — imitate legitimate traffic, such as HTTP floods against expensive search or login pages, or slow attacks that hold connections open. They need far less traffic and are harder to distinguish from real users.

Mitigation layers:

1. Upstream scrubbing and CDNs with large anycast networks absorb volumetric floods before they reach your link. Your own firewall cannot help if your internet pipe is already full.
2. Network protections such as SYN cookies, connection limits and ISP-level filtering.
3. WAF and bot management for Layer 7: rate limiting per IP or session, challenges, behavioural bot detection and caching of expensive responses.
4. Architecture: autoscaling (with cost limits), removing single points of failure, and hiding origin servers so attackers cannot bypass the CDN.
5. A runbook with provider contacts, pre-agreed escalation and a tested failover plan.

Internet hygiene: ingress and egress filtering against spoofed source addresses (BCP 38) and securing IoT devices reduce the pool of attack resources. The Mirai botnet in 2016 showed how many insecure cameras and routers could be weaponised.

Note: DDoS is sometimes a smokescreen to distract the SOC while a quieter intrusion happens elsewhere, so keep monitoring other alerts during an attack.

Traditional antivirus mainly compares files against signatures of known malware and blocks them at the point of execution or download. It is useful against commodity threats, but struggles with new variants, fileless techniques and attackers using legitimate admin tools.

EDR (endpoint detection and response) continuously records detailed telemetry from each endpoint and applies behavioural analytics. It captures:

• Process creation, parent-child relationships and full command lines.
• Network connections, DNS requests and file changes.
• Registry modifications, scheduled tasks and other persistence mechanisms.
• Logins and privilege use.

What EDR adds:

• Detection of suspicious behaviour, such as Word spawning PowerShell that downloads a script, even with no known malicious file involved.
• Investigation through a process tree and timeline showing exactly what happened on the host.
• Response actions from the console: isolate the host from the network, kill a process, quarantine a file, collect forensic artefacts and, with some products, roll back changes.
• Threat hunting by querying telemetry across all endpoints, for example “which machines ran this command line this week?”

Limitations: coverage gaps (unmanaged devices, servers without agents), attackers trying to disable or evade agents, and the need for skilled people to tune and act on alerts.

Note: When isolating a host with EDR, capture memory and key artefacts first where possible. Isolation keeps the machine running for forensics, unlike simply powering it off.

In a man-in-the-middle (MITM) attack, also called adversary-in-the-middle, an attacker secretly positions themselves between two communicating parties so they can read, modify or relay traffic, while each party believes it is talking directly to the other. It threatens both confidentiality and integrity.

Common forms, described conceptually:

• ARP spoofing on a local network, redirecting traffic through the attacker’s machine.
• Rogue or “evil twin” Wi-Fi access points imitating a café or airport network.
• DNS spoofing that sends victims to an attacker-controlled IP address.
• SSL stripping, which downgrades a user from HTTPS to HTTP if the site does not enforce HTTPS.
• Fraudulent certificates, from a compromised CA or a malicious root certificate installed on the device.
• Phishing proxy kits that sit between the user and the real login page, relaying the MFA code and stealing the resulting session cookie.

Preventive controls:

• TLS everywhere, with proper certificate validation. Developers must never disable certificate checks, even “temporarily”.
• HSTS and HSTS preload, so browsers refuse to connect over plain HTTP and SSL stripping fails.
• Mutual TLS for service-to-service traffic and APIs.
• Certificate pinning in high-risk mobile apps, managed carefully so that key rotation does not break the app.
• Network controls: 802.1X port authentication, DHCP snooping and dynamic ARP inspection on switches, and WPA3 on Wi-Fi.
• DNSSEC and encrypted DNS to reduce DNS manipulation.
• Phishing-resistant MFA (FIDO2), which defeats proxy kits because the credential is bound to the genuine domain.

Note: Corporate TLS inspection proxies are a deliberate, authorised form of interception. They must be tightly secured, because a compromised inspection device is a perfect MITM platform.

Broken access control means users can act outside their intended permissions. It has topped the OWASP Top 10 since 2021 because it is common, often high impact, and hard for automated scanners to find, since the scanner does not know who should be allowed to see what.

Main forms:

• IDOR (insecure direct object reference) — the application uses an identifier from the request without checking ownership. Changing /api/orders/10452 to /api/orders/10453 returns another customer’s order. In API security this is called BOLA (broken object level authorisation).
• Vertical privilege escalation — a normal user reaches admin functions because only the menu link was hidden, not the endpoint.
• Missing function-level checks on particular HTTP methods, such as allowing DELETE when only GET was reviewed.
• Mass assignment — the client sends an extra field such as role=admin and the server binds it to the user object.
• Token or parameter tampering, such as editing unsigned JWT claims or a hidden form field.
• Misconfigured CORS that lets malicious sites make authenticated requests and read the responses.

Prevention:

• Deny by default, and enforce authorisation on the server for every request.
• Check that the requested object belongs to, or is shared with, the authenticated user.
• Centralise authorisation logic in one well-tested component rather than scattering checks across controllers.
• Use allowlists of bindable fields to stop mass assignment.
• Log and alert on repeated authorisation failures.

Testing approach: create two users at the same role and one at a higher role, then replay each user’s requests with the other’s session, swapping identifiers. Automate these checks as integration tests so regressions are caught in CI.

Note: Random UUIDs make identifiers harder to guess, but they are not access control. IDs leak through URLs, logs and shared links; ownership checks are still required.

DevSecOps integrates security testing into the delivery pipeline so issues are found early, when they are cheapest to fix (“shift left”), without slowing releases.

Where each fits:

1. Developer workstation and pre-commit — IDE security plugins and secrets scanning to stop keys being committed.
2. Pull request — SAST and SCA on the changed code, with results shown as review comments.
3. Build — container image scanning and infrastructure-as-code scanning (Terraform, Kubernetes manifests) for misconfigurations.
4. Test or staging — DAST and IAST against a deployed build.
5. Production — runtime protection, WAF, monitoring, and continuous SCA alerts when new CVEs are published for components you already run.

Making it work culturally:

• Break the build only for high-confidence, high-severity findings; report the rest, or developers will bypass the tools.
• Tune rules and suppress confirmed false positives centrally.
• Pair tooling with security champions in development teams and threat modelling at design time.

Note: Tools complement, but do not replace, manual review. Business logic flaws and broken access control are frequently missed by all automated scanners.

A software supply chain attack compromises something you trust, such as a vendor, a library, a build system or an update mechanism, so that malicious code reaches you through a legitimate channel. One compromise can reach thousands of downstream organisations.

Well-known examples:

• SolarWinds (2020) — attackers compromised the vendor’s build process, and trojanised Orion updates were signed and shipped to customers.
• Log4Shell (2021) — not a malicious insertion, but a critical flaw in a ubiquitous Java logging library. Many organisations could not quickly tell where they used it.
• xz Utils (2024) — a backdoor introduced by a contributor who had spent a long time gaining maintainer trust, discovered shortly before it reached stable Linux releases.
• Malicious packages — typosquatted names on npm or PyPI, and dependency confusion, where a public package with the same name as an internal one gets installed instead.

SBOM (software bill of materials): a machine-readable inventory of every component and version in a piece of software, in standard formats such as SPDX or CycloneDX. When the next Log4Shell appears, an SBOM lets you answer “are we affected, and where?” in hours instead of weeks. Organisations increasingly ask vendors to supply one.

SLSA (Supply-chain Levels for Software Artifacts) is a framework of increasing assurance levels for build integrity: scripted builds, signed provenance showing where and how an artifact was built, and hardened, isolated build platforms.

Other controls:

• Lock files and version pinning, private package mirrors, and verification of package signatures (for example with Sigstore).
• Least privilege and MFA for CI/CD systems and code repositories, which are high-value targets.
• Continuous SCA monitoring of dependencies.
• Vendor risk assessments and contractual security requirements for third parties.

Note: Supply chain risk also covers service providers. The 2023 MOVEit file-transfer compromise hit many organisations through vendors and payroll providers they relied on.

Active Directory (AD) is the identity backbone of most Windows enterprises, so compromising it usually means compromising everything. Ransomware groups almost always aim for domain admin rights before deploying encryption.

How authentication works, briefly: Kerberos is the default. A user obtains a ticket-granting ticket (TGT) from the domain controller’s KDC, then uses it to request service tickets for specific services. The older NTLM protocol is still present for compatibility.

Key attacks, conceptually:

• Pass-the-hash — NTLM accepts a password hash as proof of identity, so an attacker who extracts a hash from memory on one machine can authenticate elsewhere without ever cracking the password.
• Kerberoasting — any domain user can request service tickets for accounts with a registered SPN. Part of the ticket is encrypted with the service account’s password hash, so it can be taken offline and brute-forced. Weak service account passwords make this very effective.
• Golden ticket — with the hash of the krbtgt account, an attacker can forge TGTs for any user.
• DCSync — abusing replication rights to request password hashes from a domain controller.

Defensive controls:

• A tiered administration model: domain admin credentials are used only on domain controllers and privileged access workstations, never on ordinary servers or laptops.
• LAPS so every machine has a unique, rotated local admin password.
• Group managed service accounts with long random passwords, and AES rather than RC4 for Kerberos.
• Restrict or disable NTLM; enable Credential Guard; place admins in the Protected Users group.
• Keep Domain Admins membership minimal and review it; audit who holds replication rights.
• Monitor for anomalies such as bursts of service-ticket requests using weak encryption types.

Note: After a suspected golden ticket compromise, the krbtgt password must be reset twice, with an interval between resets, to invalidate forged tickets.

Cyber threat intelligence (CTI) is evidence-based knowledge about adversaries (who they are, what they target and how they operate) that has been analysed so defenders can make better decisions. Raw data feeds are not intelligence until they are relevant, contextual and actionable.

Four levels of intelligence:

• Strategic — trends and risks for executives, such as “ransomware groups are targeting Indian healthcare”.
• Operational — details of specific campaigns and actors.
• Tactical — adversary TTPs for defenders and detection engineers.
• Technical — specific indicators for blocking and searching.

IoCs versus TTPs: an indicator of compromise is an artefact showing that an intrusion may have happened: a file hash, IP address, domain or registry key. TTPs (tactics, techniques and procedures) describe how the adversary behaves, such as dumping credentials from memory or using scheduled tasks for persistence. MITRE ATT&CK is the standard catalogue of techniques.

The Pyramid of Pain ranks indicators by how much blocking them hurts the attacker, from trivial to tough: hash values, IP addresses, domain names, network and host artefacts, tools, and finally TTPs. Changing a hash takes seconds; changing how a group operates takes months. Mature programmes therefore detect behaviours, not just indicators.

The intelligence lifecycle: direction (what do we need to know?), collection, processing, analysis, dissemination and feedback.

Sources and sharing: open-source reporting, commercial feeds, industry ISACs, government advisories such as those from CERT-In, and internal incident data. Intelligence is exchanged using standards like STIX and TAXII, often through platforms such as MISP.

Note: The Lockheed Martin Cyber Kill Chain (reconnaissance, weaponisation, delivery, exploitation, installation, command and control, actions on objectives) is often compared with ATT&CK: the kill chain gives a high-level sequence, while ATT&CK gives granular techniques for mapping detection coverage.

Digital evidence can disappear or change the moment a system is touched, rebooted or powered off. Forensic practice therefore follows principles that preserve evidence and make it defensible later, internally or in court.

Order of volatility (from RFC 3227): collect the most short-lived evidence first.

1. CPU registers and cache.
2. Routing table, ARP cache, process table, kernel statistics and system memory (RAM).
3. Temporary file systems.
4. Disk contents.
5. Remote logging and monitoring data.
6. Physical configuration and network topology.
7. Archival media such as backups.

In practice, capturing a memory image of a live system is often the most valuable early step: it can reveal running malware, network connections, encryption keys and command history that never touch the disk. Pulling the plug destroys all of that.

Chain of custody is a documented record of who collected each item of evidence, when, how, where it was stored and every person who handled it afterwards. Gaps in that record allow the other side to argue that evidence was altered.

Evidence integrity:

• Create forensic images using write blockers, so the original media is never modified.
• Calculate a cryptographic hash such as SHA-256 of the original and the image, and record both. Matching hashes prove the copy is exact.
• Analyse copies, never originals, and keep originals sealed and securely stored.
• Keep detailed contemporaneous notes, with time zones recorded.

In India, courts expect a certificate supporting the admissibility of electronic records. This was previously governed by Section 65B of the Indian Evidence Act and is now covered by Section 63 of the Bharatiya Sakshya Adhiniyam, 2023.

Note: Even if you never expect prosecution, handle evidence as if you might. Disputes with insurers, regulators or former employees often arise months after an incident.

DNS translates names into IP addresses and is involved in almost every connection, which makes it both a target and a rich source of detection data.

Common DNS-related threats:

• Cache poisoning or spoofing — forged responses inserted into a resolver’s cache send users to attacker-controlled servers.
• Domain hijacking — taking over the registrar account and changing name servers, redirecting an organisation’s entire domain.
• Subdomain takeover — a DNS record still points to a deleted cloud resource, such as an old storage bucket or app service, which an attacker then claims.
• DNS tunnelling — encoding data in DNS queries and responses to exfiltrate data or run command-and-control, because DNS is often allowed out of networks with little inspection.
• DNS amplification — abusing open resolvers to flood victims with large responses in DDoS attacks.
• Lookalike and typosquatted domains used for phishing, and malware using algorithmically generated domains.

Defences:

• DNSSEC digitally signs DNS records so resolvers can verify they are authentic and unaltered. It protects integrity and origin, but not confidentiality.
• DNS over HTTPS or TLS encrypts queries for privacy. In enterprises it must be managed, because uncontrolled DoH can bypass corporate monitoring and filtering.
• Protective DNS blocks resolution of known malicious and newly registered domains.
• Registrar security: MFA on the registrar account, registry lock for critical domains, and restricted access.
• Hygiene: regularly audit DNS zones for dangling records, publish CAA records to limit which CAs may issue certificates, and monitor Certificate Transparency for lookalike domains.
• Monitoring: send resolver logs to the SIEM and alert on unusually long or high-entropy queries and high query volumes to a single domain, which are signs of tunnelling.

Note: Email security records such as SPF, DKIM and DMARC also live in DNS, so protecting the DNS zone protects email trust too.

Data loss prevention (DLP) is a set of tools and processes that detect and stop sensitive data leaving the organisation’s control, whether through malicious exfiltration or honest mistakes such as emailing a spreadsheet to the wrong person.

Data exists in three states, and DLP covers each:

• In motion — network and email DLP inspect outbound traffic and messages.
• In use — endpoint DLP controls copying to USB drives, printing, screenshots and uploads from the device.
• At rest — discovery scans find sensitive data sitting in file shares, databases and cloud storage. Cloud DLP and CASB tools cover SaaS applications.

How DLP recognises sensitive data:

• Pattern matching with validation, for example card numbers checked with the Luhn algorithm, or Aadhaar and PAN formats.
• Exact data matching against fingerprints of real customer records.
• Document fingerprinting of specific templates or confidential files.
• Classification labels applied by users or automatically.
• Machine-learning classifiers for unstructured content such as contracts or source code.

Why classification comes first: DLP can only protect what the organisation has defined as sensitive. A simple scheme such as Public, Internal, Confidential and Restricted, with clear handling rules and owners for each level, makes policies precise and reduces false positives.

Where encryption at rest fits: full-disk encryption protects lost laptops; database transparent encryption and field-level encryption protect stored records; persistent rights management keeps documents encrypted even after they leave. Encryption is only as strong as key management, so keys should sit in a KMS or HSM, separate from the data.

Rolling DLP out sensibly: start in monitor-only mode, tune the rules, move to user warnings with a justification option, and block only well-understood high-risk flows.

Note: Under India’s DPDP Act, organisations must take reasonable security safeguards to prevent personal data breaches. Data discovery and DLP are practical ways to show you know where personal data lives and control how it moves.

Risk is the combination of the likelihood that a threat exploits a vulnerability and the impact on an asset if it does. A risk assessment turns that idea into decisions.

Typical steps (as in ISO/IEC 27005 or NIST SP 800-30):

1. Identify assets and their value to the business.
2. Identify threats and vulnerabilities relevant to each asset.
3. Evaluate existing controls.
4. Estimate likelihood and impact, and rate the risk.
5. Choose a treatment: mitigate (add controls), transfer (insurance, contracts), avoid (stop the activity) or accept (with a named owner signing off).
6. Record everything in a risk register and review residual risk regularly.

Qualitative analysis rates likelihood and impact on scales such as 1–5 and plots them on a heat map. It is quick and good for prioritising, but subjective.

Quantitative analysis uses money:

• Single loss expectancy (SLE) = asset value × exposure factor (the fraction of value lost in one incident).
• Annualised rate of occurrence (ARO) = expected incidents per year.
• Annualised loss expectancy (ALE) = SLE × ARO.

Worked example: a customer database is valued at ₹2 crore, and a breach would cost about 25 percent of that, so SLE = ₹50 lakh. If one such breach is expected every five years, ARO = 0.2 and ALE = ₹10 lakh per year. A control costing ₹4 lakh a year that reduces ARO to 0.05 lowers ALE to ₹2.5 lakh. The annual benefit is ₹10 lakh − ₹2.5 lakh − ₹4 lakh = ₹3.5 lakh, so the control is justified.

Note: Real-world inputs are uncertain, so mature teams use ranges and models such as FAIR rather than single numbers. The point is to make trade-offs explicit, not to produce false precision.

Both terms come from business continuity and disaster recovery planning and are set through a business impact analysis (BIA), which asks how long each process can be down and how much data it can afford to lose.

• Recovery Point Objective (RPO) — the maximum acceptable data loss, measured in time. An RPO of 15 minutes means that after an incident you must be able to restore data as it was no more than 15 minutes earlier.
• Recovery Time Objective (RTO) — the maximum acceptable downtime: how quickly the service must be running again.
• Maximum tolerable downtime — the point beyond which the business suffers unacceptable harm. RTO must sit comfortably inside it.

Why they drive architecture: a nightly backup gives an RPO of up to 24 hours. An RPO of minutes needs database log shipping or continuous replication. Likewise, an RTO of hours may be met by restoring from backup, while an RTO of minutes needs a warm or hot standby site with automated failover. Tighter objectives cost more, so they should be set per system, not one number for everything.

Backup strategy:

• 3-2-1 rule — at least three copies of the data, on two different types of media, with one copy off-site.
• Its modern extension 3-2-1-1-0 adds one copy that is offline or immutable, and zero errors confirmed by verified restores.
• Backup types: full, incremental (changes since the last backup) and differential (changes since the last full backup), which trade storage against restore speed.

Ransomware lessons: attackers deliberately hunt for and delete backups, so backup systems need separate credentials, MFA, network isolation and immutability. Backups also need to be scanned before restore, so you do not reintroduce the attacker.

Note: An untested backup is only a hope. Regular restore tests, timed against the RTO, are the only way to prove the plan works.