Top 84 Cybersecurity / Web Security Interview Questions & Answers (2026)

Cybersecurity is the practice of protecting computer systems, networks, programs, and data from digital attacks, unauthorized access, damage, or theft. It encompasses a wide range of technologies, processes, and practices designed to defend against cyber threats. Key domains include: network security (protecting the network infrastructure), application security (securing software from vulnerabilities), information security (protecting data integrity and confidentiality), operational security (procedures for handling sensitive data), disaster recovery, and end-user education. With increasing digitization, cybersecurity has become critical for businesses, governments, and individuals alike.

The CIA triad is the foundational model of information security, representing three core principles. Confidentiality: ensuring data is accessible only to authorized parties — achieved through encryption, access controls, and authentication. Integrity: ensuring data is accurate and has not been tampered with — achieved through hashing, checksums, digital signatures, and access controls. Availability: ensuring systems and data are accessible to authorized users when needed — achieved through redundancy, failover, backups, and DDoS protection. Every security control, policy, and technology maps back to one or more of these three principles. Some models extend this to AAA (Authentication, Authorization, Accounting) or add Non-repudiation as a fourth pillar.

A firewall is a network security device (hardware or software) that monitors and controls incoming and outgoing network traffic based on predefined security rules. It acts as a barrier between a trusted internal network and untrusted external networks. Types: Packet-filtering firewall: inspects packets at the network layer (IP/port rules). Stateful inspection firewall: tracks the state of connections, allowing return traffic for established connections. Application-layer firewall (WAF): inspects HTTP traffic, understands application protocols. Next-generation firewall (NGFW): combines stateful inspection with DPI (Deep Packet Inspection), IDS/IPS, and application awareness. Rules are typically defined as: source IP, destination IP, port, protocol, and action (allow/deny/log).

Encryption is the process of transforming plaintext data into an unreadable format (ciphertext) using an algorithm and a key, so that only authorized parties with the correct decryption key can read it. Symmetric encryption: same key for encryption and decryption (AES, 3DES) — fast, used for bulk data. Asymmetric encryption: uses a public key (encrypt) and private key (decrypt) pair (RSA, ECC) — slower, used for key exchange and digital signatures. At rest: encrypting stored data (database encryption, full-disk encryption). In transit: encrypting data over the network (TLS/HTTPS, SSH, VPN). End-to-end: data encrypted by the sender and only decryptable by the recipient (Signal protocol, WhatsApp). Encryption is a cornerstone of confidentiality in the CIA triad.

HTTP (HyperText Transfer Protocol) transmits data in plaintext — anyone who intercepts the traffic can read it. HTTPS (HTTP Secure) wraps HTTP in TLS/SSL encryption, providing three guarantees: (1) Confidentiality: data is encrypted in transit. (2) Integrity: data cannot be tampered with undetected (MAC). (3) Authentication: the server's identity is verified via a digital certificate issued by a trusted Certificate Authority (CA). HTTPS uses port 443 (HTTP uses port 80). The TLS handshake negotiates cipher suites, exchanges keys, and establishes a secure session before any application data is sent. Modern browsers mark HTTP sites as "Not Secure." All websites handling any sensitive data (including login forms) must use HTTPS.

SQL injection (SQLi) is an attack where malicious SQL code is inserted into an input field and executed by the database. Example: a login form with SELECT * FROM users WHERE username='$user' AND password='$pass' — an attacker enters admin'-- as the username, making the query: SELECT * FROM users WHERE username='admin'--' AND password='...' — the -- comments out the password check, bypassing authentication. SQLi can allow attackers to read, modify, or delete database data, execute administrative operations, and sometimes execute OS commands. Prevention: (1) Parameterized queries / prepared statements (most important). (2) Stored procedures (if parameterized). (3) Input validation and whitelisting. (4) Least privilege database accounts. (5) WAF. SQLi is consistently #1 or top-3 in OWASP Top 10.

Cross-Site Scripting (XSS) is an attack where malicious scripts are injected into web pages viewed by other users. Types: Stored XSS: the malicious script is permanently stored on the server (e.g., in a comment field) and served to every visitor. Reflected XSS: the script is embedded in a URL/request and reflected back in the response — the victim must click a malicious link. DOM-based XSS: the attack occurs entirely in the browser's DOM without hitting the server. XSS allows attackers to steal cookies/session tokens, redirect users, deface pages, and perform actions as the victim. Prevention: (1) Output encoding/escaping (HTML encode all user input before displaying). (2) Content Security Policy (CSP) headers. (3) Use frameworks that auto-escape (React, Angular). (4) HttpOnly cookies (prevents JS cookie theft). (5) Input validation.

CSRF (Cross-Site Request Forgery) tricks an authenticated user's browser into sending an unwanted request to a web application where they're logged in. Example: a user is logged into their bank; they visit a malicious page containing <img src="https://bank.com/transfer?amount=1000&to=attacker"> — the browser automatically sends the request with the user's cookies, executing the transfer. CSRF exploits the fact that browsers automatically include cookies with cross-origin requests. Prevention: (1) CSRF tokens (anti-forgery tokens): a unique secret included in forms and verified server-side. (2) SameSite cookie attribute: SameSite=Strict or SameSite=Lax prevents cookies from being sent in cross-site requests. (3) Verify the Origin/Referer header. (4) Re-authentication for sensitive operations.

The OWASP Top 10 is a standard awareness document for web application security, representing the most critical security risks. The 2021 edition: (1) Broken Access Control (was #5, now #1). (2) Cryptographic Failures (data exposure). (3) Injection (SQL, NoSQL, OS, LDAP). (4) Insecure Design (new — design-level flaws). (5) Security Misconfiguration. (6) Vulnerable and Outdated Components. (7) Identification and Authentication Failures. (8) Software and Data Integrity Failures (new — insecure deserialization, CI/CD). (9) Security Logging and Monitoring Failures. (10) Server-Side Request Forgery (SSRF) (new). It is updated every few years based on real-world breach data and industry surveys. Used as a baseline for security assessments and developer training.

Authentication (AuthN) is the process of verifying who you are — confirming that a user is who they claim to be. Methods: passwords, MFA, biometrics, certificates, API keys, OAuth tokens. Authorization (AuthZ) is the process of determining what you are allowed to do — what resources or actions an authenticated identity can access. Example: a user logs in (authentication), then attempts to access the admin panel — the system checks if their role allows it (authorization). Both are distinct and both are necessary. A common confusion: successful authentication doesn't guarantee access. Systems like RBAC (Role-Based Access Control), ABAC (Attribute-Based), and ACLs (Access Control Lists) implement authorization. Broken access control (failing to properly authorize) is the #1 OWASP risk.

Multi-Factor Authentication (MFA) requires users to provide two or more verification factors from different categories: (1) Something you know: password, PIN, security question. (2) Something you have: physical token, authenticator app (TOTP — Google Authenticator), SMS OTP, hardware key (YubiKey). (3) Something you are: biometrics (fingerprint, face recognition). MFA dramatically reduces the risk of account compromise — even if a password is stolen, the attacker still needs the second factor. TOTP (Time-based One-Time Password) is more secure than SMS (which is vulnerable to SIM swapping). Hardware security keys (FIDO2/WebAuthn) are the most phishing-resistant MFA method. Organizations should require MFA for all privileged accounts, admin panels, and sensitive data access.

A VPN (Virtual Private Network) creates an encrypted tunnel between a user's device and a VPN server, routing all traffic through it. This provides: (1) Privacy: hides the user's real IP address — websites see the VPN server's IP. (2) Encryption: protects data from eavesdropping on public/untrusted networks. (3) Remote access: corporate VPNs allow employees to securely access internal network resources as if on-site. (4) Geo-bypass: access region-restricted content. Protocols: OpenVPN (open-source, widely trusted), WireGuard (modern, fast, lean), IPSec/IKEv2 (enterprise-grade), L2TP/IPSec, PPTP (outdated, insecure). VPNs don't make you fully anonymous — the VPN provider can see your traffic. For full corporate security, combine VPN with Zero Trust Network Access (ZTNA).

Hashing is a one-way transformation of data into a fixed-size digest using a hash function (MD5, SHA-256, bcrypt). It is irreversible — you cannot get the original data from the hash. Encryption is two-way — data can be decrypted back to the original with the correct key. Key use cases for hashing: Password storage (never store plaintext passwords — store the hash), data integrity verification (compare hash of downloaded file to expected hash), digital signatures. For password hashing, use adaptive algorithms like bcrypt, scrypt, or Argon2 — they are slow by design (adjustable work factor) to resist brute force. Avoid MD5 and SHA-1 for security purposes (both are cryptographically broken). Always use salting with password hashes to prevent rainbow table attacks.

A salt is a random value added to a password before hashing, making each password hash unique even if two users have the same password. Without salting: hash("password123") always produces the same digest — attackers can precompute a rainbow table (mapping passwords to hashes) and look up any hash instantly. With salting: hash("password123" + randomSalt) — the attacker must brute-force each hash individually. Salts must be: (1) Randomly generated per password. (2) Stored alongside the hash (they are not secret — their purpose is uniqueness, not secrecy). (3) Long enough (16+ bytes) to prevent precomputation. Modern password hashing libraries (bcrypt, Argon2) handle salt generation automatically. Never implement your own password hashing — use a vetted library.

A DDoS (Distributed Denial of Service) attack floods a target (server, network, service) with massive amounts of traffic from many distributed sources (a botnet), overwhelming its capacity to respond to legitimate requests. Types: Volumetric attacks: saturate bandwidth (UDP floods, ICMP floods). Protocol attacks: exploit protocol weaknesses (SYN floods exhaust TCP connection tables). Application-layer attacks: target the web application (HTTP flood, Slowloris — sending slow partial requests to keep connections open). Mitigation: CDN/scrubbing services (Cloudflare, AWS Shield, Akamai) that absorb and filter attack traffic. Rate limiting, anycast routing, IP reputation filtering, and CAPTCHA for application-layer attacks. DDoS attacks are often used as diversions while other attacks occur.

A Man-in-the-Middle (MITM) attack occurs when an attacker secretly intercepts and potentially alters communication between two parties who believe they are communicating directly with each other. The attacker positions themselves between the victim and the legitimate server — relaying (and potentially modifying) messages. Common techniques: ARP spoofing (poisoning ARP tables on a LAN to redirect traffic), DNS spoofing (redirecting domain lookups to attacker-controlled IPs), SSL stripping (downgrading HTTPS to HTTP), evil twin WiFi (fake access point). Prevention: (1) TLS/HTTPS with certificate validation. (2) HSTS (HTTP Strict Transport Security) prevents SSL stripping. (3) Certificate pinning for mobile apps. (4) VPN on public networks. (5) MFA (limits damage from credential theft).

Phishing is a social engineering attack that tricks users into revealing sensitive information (credentials, credit card numbers) or installing malware by impersonating a trusted entity. Delivered via: Email (most common — fake bank/IT notifications), SMS (smishing), voice calls (vishing), and malicious websites (typosquatting — e.g., g00gle.com). Spear phishing: highly targeted at specific individuals using personal information. Whaling: targets executives (CEO, CFO). Business Email Compromise (BEC): impersonates executives to authorize fraudulent wire transfers. Prevention: User training and awareness, email filtering and anti-phishing tools, DMARC/DKIM/SPF (email authentication), MFA (limits damage even if credentials are stolen), hardware security keys (phishing-resistant MFA).

A penetration test (pen test) is an authorized simulated cyberattack on a system, network, or application to identify security vulnerabilities before malicious actors do. Types: Black box: tester has no prior knowledge (simulates an external attacker). White box: tester has full access to source code, architecture, credentials. Grey box: partial knowledge (common in practice). Phases: (1) Reconnaissance: gather information. (2) Scanning: identify open ports, services, vulnerabilities. (3) Exploitation: attempt to exploit findings. (4) Post-exploitation: determine impact and lateral movement. (5) Reporting: document findings with severity and remediation. Tools: Metasploit, Burp Suite, Nmap, Nikto, Nessus, OWASP ZAP. Distinct from vulnerability scanning (automated, no exploitation). Results must be addressed by developers.

Social engineering is the manipulation of people (rather than systems) into performing actions or divulging confidential information. It exploits human psychology — trust, fear, urgency, authority, and curiosity. Common techniques: Phishing (email/SMS), vishing (voice/phone calls pretending to be IT or bank), pretexting (fabricating a scenario to gain trust — e.g., "I'm from IT, I need your password to fix an issue"), baiting (leaving infected USB drives in parking lots), quid pro quo (offering something in exchange for info), tailgating/piggybacking (physical access by following an authorized person). Defense: security awareness training, clear verification procedures, never sharing passwords verbally, and a security culture where employees feel safe reporting suspicious incidents.

A zero-day vulnerability is a software security flaw that is unknown to the software vendor or has been disclosed but not yet patched. The term "zero-day" means defenders have had zero days to fix the issue. A zero-day exploit is attack code that takes advantage of such a flaw. Zero-days are highly valuable — nation-states, criminal groups, and security researchers discover and sell them (vulnerability marketplaces). When a zero-day is disclosed (publicly or to the vendor), it becomes a known vulnerability and the vendor has a deadline to patch (responsible disclosure uses a 90-day window — Google Project Zero standard). After a patch is released, it's no longer a zero-day but unpatched systems remain vulnerable. Defense: timely patching, defense-in-depth, application whitelisting, network segmentation, and anomaly detection.

The principle of least privilege (PoLP) states that every user, process, and system component should have only the minimum permissions necessary to perform its legitimate function — no more, no less. Why it matters: if an account or process is compromised, the attacker's capabilities are limited to only what that account was authorized to do. Applications: (1) User accounts: regular users don't need admin rights. (2) Service accounts: a web app's database account should only have SELECT/INSERT/UPDATE on required tables — not DROP or admin privileges. (3) Cloud IAM: granular resource-level permissions. (4) Network access: servers should only communicate on required ports. (5) Code execution: run web servers as non-root users. Regularly audit and revoke unused permissions. This is fundamental to Zero Trust security.

A TLS certificate (formerly SSL certificate) is a digital document that binds a public key to the identity of a server (domain name). Issued by a trusted Certificate Authority (CA) (Let's Encrypt, DigiCert, Comodo). The certificate contains: the domain name, the server's public key, the CA's digital signature, validity period, and the certificate chain. When a browser connects to HTTPS, it: (1) Receives the server's certificate. (2) Verifies it was signed by a trusted CA. (3) Checks it hasn't expired or been revoked (CRL/OCSP). (4) Verifies the domain matches. This prevents MITM attacks — an attacker can't fake a valid certificate for a domain they don't control. Types: DV (Domain Validated — basic), OV (Organization Validated), EV (Extended Validation — shows org name in browser). Let's Encrypt provides free DV certificates.

A cookie is a small piece of data stored by the browser and sent with every HTTP request to the originating domain. Used for session management, user preferences, and tracking. Security attributes: HttpOnly: prevents JavaScript from accessing the cookie — mitigates XSS cookie theft. Secure: cookie is only sent over HTTPS connections. SameSite: controls cross-site sending — Strict (never sent cross-site), Lax (sent on top-level navigations), None (always sent, requires Secure). Domain and Path: restrict which requests include the cookie. Expiration: session cookies are deleted when the browser closes; persistent cookies have an explicit expiry. Best practice for session cookies: always set HttpOnly, Secure, and SameSite=Lax (or Strict).

An IDS (Intrusion Detection System) monitors network traffic or system activity for suspicious patterns and alerts administrators — it is passive (detect and notify only). An IPS (Intrusion Prevention System) actively blocks or prevents detected attacks in real time — it sits inline in the network and can drop malicious packets. Types: Network-based (NIDS/NIPS): monitors network traffic at a strategic point. Host-based (HIDS/HIPS): monitors activities on individual hosts (file changes, process activity). Detection methods: Signature-based: matches known attack patterns (low false positives, misses zero-days). Anomaly-based: baseline normal behavior and alert on deviations (catches unknown attacks, higher false positives). Behavioral: monitors sequence of actions. Popular tools: Snort, Suricata (NIDS/NIPS), OSSEC (HIDS), CrowdStrike, Carbon Black.

HSTS (HTTP Strict Transport Security) is a web security policy mechanism that forces browsers to only communicate with a website over HTTPS — preventing HTTP connections and SSL stripping attacks. Set via HTTP response header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. max-age: how long (in seconds) the browser should enforce HTTPS. includeSubDomains: applies to all subdomains. preload: submit the domain to browser preload lists (Chrome, Firefox hardcode HSTS domains). How it prevents attacks: an attacker performing SSL stripping (redirecting HTTPS to HTTP) is defeated because the browser refuses to make HTTP connections. Once a browser sees the HSTS header, it will not make insecure connections to that domain for the max-age duration, even if the user types http://.

Content Security Policy (CSP) is an HTTP response header that tells browsers which sources of content (scripts, styles, images, fonts, etc.) are trusted and allowed to load. It is the most effective defense against XSS. Example header: Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' 'unsafe-inline'. Directives: default-src (fallback for all types), script-src (JavaScript sources), style-src, img-src, connect-src (fetch/XHR), frame-ancestors (prevents clickjacking). 'self' means only the same origin. 'none' blocks everything. Avoid 'unsafe-inline' (allows inline scripts — the main XSS vector) and 'unsafe-eval'. Use nonce or hash for legitimate inline scripts. Report-only mode (Content-Security-Policy-Report-Only) tests policies without enforcing them.

Symmetric encryption uses the same key for both encryption and decryption. Fast and efficient for large data. The key must be shared securely — the "key distribution problem." Algorithms: AES (Advanced Encryption Standard — the standard, 128/256-bit keys), 3DES, ChaCha20. Asymmetric encryption uses a key pair: a public key (shared freely — anyone can encrypt with it) and a private key (kept secret — only the owner can decrypt). Much slower than symmetric — used for key exchange and digital signatures, not bulk data. Algorithms: RSA, ECC (Elliptic Curve), Diffie-Hellman. In practice, TLS combines both: asymmetric crypto is used in the handshake to securely exchange a symmetric session key; then symmetric encryption is used for the actual data transfer (fast + secure).

A vulnerability assessment is the systematic process of identifying, quantifying, and prioritizing security weaknesses in a system, network, or application. Unlike a penetration test, it does not attempt to exploit vulnerabilities — it only identifies and documents them. Process: (1) Asset discovery: inventory all systems and software. (2) Scanning: use automated tools (Nessus, OpenVAS, Qualys) to scan for known CVEs, misconfigurations, and patch levels. (3) Analysis: rank findings by severity (CVSS score) and exploitability. (4) Reporting: document findings with remediation recommendations. (5) Remediation: apply patches, fix configurations. Vulnerability assessments should be run regularly (monthly/quarterly) and after major system changes. They complement penetration testing but serve a different purpose — breadth (all known vulnerabilities) vs depth (actual exploitability).

Security misconfiguration (OWASP #5) occurs when security settings are defined, implemented, or maintained incorrectly. Common examples: Default credentials (admin/admin left unchanged), unnecessary features enabled (debug mode, directory listing, unused ports/services), overly permissive CORS, verbose error messages exposing stack traces, unpatched software, missing security headers, cloud storage buckets publicly accessible (S3 bucket misconfigurations have caused major data breaches), open MongoDB/Elasticsearch without authentication. Prevention: (1) Minimal install — disable/remove all unused features. (2) Consistent hardening procedures (CIS benchmarks). (3) Automated configuration scanning. (4) Change all default passwords. (5) Security-as-code — infrastructure configuration in version control with reviews. (6) Regular audits.

HTTP security headers instruct browsers to enable protective behaviors. Key headers: Strict-Transport-Security (HSTS — force HTTPS). Content-Security-Policy (CSP — whitelist trusted content sources, prevent XSS). X-Frame-Options: DENY or SAMEORIGIN — prevents clickjacking by controlling framing. X-Content-Type-Options: nosniff: prevents MIME type sniffing attacks. Referrer-Policy: controls how much referrer info is sent (e.g., strict-origin-when-cross-origin). Permissions-Policy (formerly Feature-Policy): disables browser features (camera, mic, geolocation). X-XSS-Protection: 1; mode=block: legacy browser XSS filter (largely obsoleted by CSP). Check your headers at securityheaders.com. All these headers should be set in your web server or application middleware.

Input validation is the process of ensuring that all user-supplied input meets expected format, type, length, and range requirements before processing it. It is a foundational security control because many attacks (SQL injection, XSS, command injection, buffer overflows, path traversal) rely on malformed or malicious input reaching the application. Validation approaches: Whitelist (allowlist) validation — define what is valid and reject everything else (most secure). Blacklist (denylist) — block known bad input (fragile, easy to bypass). Server-side validation is mandatory — client-side validation (JavaScript) is easily bypassed. Validate: data type, length, range, format (regex), allowed characters. Output encoding (escaping) is separate from validation — it handles the case where special characters are legitimate but must be safely rendered. Defense-in-depth: validate, encode, use parameterized queries, use a WAF.

Broken access control (OWASP #1 in 2021) occurs when users can act outside their intended permissions — accessing data or functionality they should not be able to. Examples: (1) IDOR (Insecure Direct Object Reference): changing /api/orders/123 to /api/orders/124 and seeing another user's order. (2) Privilege escalation: a regular user accessing admin endpoints. (3) Forced browsing: directly accessing URLs that should be restricted (e.g., /admin/dashboard). (4) Path traversal: ../../../etc/passwd. Prevention: (1) Deny access by default — whitelist specific permissions. (2) Server-side enforcement of access rules (never trust client-side). (3) Log access control failures. (4) Rate limit API endpoints. (5) Invalidate tokens on logout. (6) Test access control in all scenarios including authenticated-as-different-user.

CVE (Common Vulnerabilities and Exposures) is a standardized identifier for publicly known cybersecurity vulnerabilities. Each CVE has a unique ID like CVE-2021-44228 (Log4Shell). Maintained by MITRE Corporation, sponsored by CISA. The CVE dictionary provides: a unique ID, a description of the vulnerability, and references to advisories and patches. CVSS (Common Vulnerability Scoring System) is a separate standard that rates severity from 0-10 (Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 0.1-3.9). The NVD (National Vulnerability Database) enriches CVE data with CVSS scores, affected configurations, and remediation. Security teams use CVEs to track which vulnerabilities affect their software (Software Composition Analysis). Subscribing to CVE feeds and having a patch management process are essential for staying ahead of known vulnerabilities.

Defense in depth (also called the layered security approach) is a security strategy that uses multiple independent layers of controls so that if one layer is breached, others still protect the system. Inspired by military strategy (concentric defensive rings). Layers include: Perimeter security (firewalls, WAF, DDoS protection), Network security (network segmentation, VLANs, IDS/IPS), Host security (hardening, endpoint protection, patch management), Application security (input validation, authentication, SAST/DAST), Data security (encryption at rest/transit, DLP), Identity security (MFA, least privilege, PAM), Physical security (data center access controls), and Monitoring/response (SIEM, SOC, incident response). No single control is perfect; depth ensures multiple failures must occur simultaneously for a successful breach.

A security audit is a systematic, independent evaluation of an organization's security posture — assessing policies, procedures, controls, and technical configurations against security standards and best practices. Types: Internal audit: conducted by the organization's own security team. External audit: conducted by an independent third party (more objective). Compliance audit: verifies compliance with standards like PCI-DSS, HIPAA, SOC 2, ISO 27001, GDPR. Areas covered: access controls, patch management, network security, data protection, incident response plans, employee awareness, physical security, and vendor risk. Audits produce a report with findings, gaps, and recommendations. Regular audits (annually or after major changes) are required by many compliance frameworks. Audits are distinct from penetration tests (audits evaluate controls; pen tests try to break them).

Encryption at rest protects stored data — files, databases, backups — from unauthorized access if the physical media is stolen or the storage system is compromised. Implementations: Full disk encryption (BitLocker, LUKS — encrypts entire drive), database encryption (TDE — Transparent Data Encryption in SQL Server/PostgreSQL), file-level encryption, object storage encryption (AWS S3 SSE). Encryption in transit protects data moving over a network from interception or tampering. Implementations: TLS/HTTPS for web traffic, SSH for remote administration, SFTP/FTPS for file transfer, VPN for network tunnels, TLS for database connections (always enable SSL for database connections even on internal networks). Both are required by most compliance frameworks (PCI-DSS, HIPAA, GDPR). Encryption at rest alone doesn't protect against a running compromised system — combine with access controls.

A Security Operations Center (SOC) is a centralized team (and facility) responsible for continuously monitoring, detecting, analyzing, and responding to cybersecurity incidents in an organization. The SOC operates 24/7 and uses technologies including: SIEM (Security Information and Event Management — collects and correlates logs from all systems), SOAR (Security Orchestration, Automation, and Response — automates repetitive tasks), EDR (Endpoint Detection and Response), threat intelligence feeds, and vulnerability scanners. SOC analysts triage alerts (Tier 1), investigate incidents (Tier 2), and handle advanced threats (Tier 3). Key metrics: MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond). Organizations without a dedicated SOC can use MDR (Managed Detection and Response) services.

The GDPR (General Data Protection Regulation) is the EU's comprehensive data privacy law (effective May 2018) that applies to any organization processing personal data of EU residents, regardless of where the organization is based. Security requirements under GDPR: (1) Data protection by design and default: build privacy into systems from the start. (2) Appropriate technical measures: encryption, pseudonymization, access controls. (3) Breach notification: notify supervisory authority within 72 hours of discovering a breach; notify affected individuals without undue delay. (4) Data minimization: collect only what is necessary. (5) Right to erasure ("right to be forgotten"). Non-compliance penalties: up to €20 million or 4% of global annual turnover (whichever is higher). GDPR has influenced privacy laws worldwide (CCPA, PIPEDA). Security teams must ensure technical controls align with GDPR's requirements.

Malware (malicious software) is any software intentionally designed to cause harm to systems, steal data, or gain unauthorized access. Types: Virus: attaches to legitimate files and spreads when the file is executed. Worm: self-replicating, spreads across networks without user action. Trojan: disguises itself as legitimate software. Ransomware: encrypts victim's files and demands payment for the decryption key (WannaCry, REvil). Spyware: secretly monitors user activity and exfiltrates data. Adware: displays unwanted ads, often bundled with free software. Rootkit: hides its presence by modifying the OS. Keylogger: records keystrokes (captures passwords). Botnet: network of compromised machines used for DDoS or spam. Defense: antivirus/EDR, keeping software patched, not running untrusted code, email filtering, application whitelisting, and user training.

A security patch is a software update that fixes a known vulnerability. When a vulnerability is disclosed (especially with a public exploit), attackers immediately begin scanning for unpatched systems — the window between disclosure and active exploitation is measured in hours. The WannaCry ransomware (2017) exploited a Windows SMB vulnerability (MS17-010) for which a patch had been available for two months — organizations that hadn't patched were compromised. Patch management process: (1) Inventory all software and versions. (2) Monitor CVE feeds and vendor advisories. (3) Test patches in staging environments. (4) Deploy promptly (critical patches within 24-72 hours; high within 1-2 weeks). (5) Verify deployment. Automated patch management tools (WSUS, Ansible, Qualys) help at scale. Unpatched systems are one of the most common attack entry points.

A password policy defines rules for creating and managing passwords in an organization. Modern guidance (NIST SP 800-63B) focuses on: Length over complexity: a long passphrase (16+ characters) is stronger than a short complex password. No forced rotation: forced periodic changes lead to weak patterns (password1 → password2). Change only when compromise is suspected. No composition rules: rigid rules (uppercase, numbers, special chars) reduce entropy. Check against breached password lists (HaveIBeenPwned API). MFA: the most effective additional control. A strong password characteristics: (1) Long (12-16+ characters minimum). (2) Random (not dictionary words or predictable patterns). (3) Unique (different for every site). (4) Managed with a password manager (LastPass, 1Password, Bitwarden). (5) Combined with MFA. Avoid: dictionary words, personal info, sequential numbers, common patterns (P@ssw0rd).

OAuth 2.0 is an authorization framework that allows third-party applications to obtain limited access to a user's resources on another service without exposing the user's password. Example: "Sign in with Google" — the app receives a token granting access to your Google profile, without ever seeing your Google password. Key roles: Resource Owner (user), Client (the app), Authorization Server (issues tokens — e.g., Google's auth server), Resource Server (API being accessed). Grant types (flows): Authorization Code (most secure — for web/mobile apps with a backend), PKCE extension for public clients (SPAs, mobile apps), Client Credentials (machine-to-machine — no user), Device Code (TVs, CLI). Tokens: Access Token (short-lived, used to call APIs), Refresh Token (longer-lived, gets new access tokens). OAuth 2.0 is for authorization — combine with OpenID Connect (OIDC) for authentication (identity).

A JWT (JSON Web Token) is a compact, URL-safe token format used for securely transmitting information between parties. Structure: three Base64URL-encoded parts separated by dots: header.payload.signature. Header: algorithm (HS256, RS256) and token type. Payload: claims (user ID, roles, expiration time). Signature: HMAC or RSA signature — verifies the token hasn't been tampered with. JWTs are self-contained — the server can verify them without a database lookup (stateless). Common use: access tokens in OAuth/OIDC flows, API authentication. Security pitfalls: (1) Algorithm confusion: validate the algorithm — never accept none. (2) Short expiration: set exp claim (15-60 minutes). (3) Secure storage: store in HttpOnly cookies (not localStorage — XSS risk). (4) Sensitive data: payload is only Base64-encoded, not encrypted — don't put secrets in it. Use JWE (encrypted JWT) for confidentiality.

Two-factor authentication (2FA) is a subset of multi-factor authentication (MFA) that requires exactly two factors to authenticate. It combines something you know (password) with one other factor: typically something you have (phone/authenticator app) or something you are (biometric). Methods from least to most secure: SMS OTP (vulnerable to SIM swapping and SS7 attacks — use only if nothing else is available), Email OTP (depends on email account security), TOTP apps (Google Authenticator, Authy — time-based codes, not transmitted over SMS), Push notifications (Duo, Microsoft Authenticator — vulnerable to MFA fatigue/bombing attacks), Hardware security keys (YubiKey, FIDO2/WebAuthn — the most phishing-resistant — the key cryptographically proves it's on the right domain). Organizations should phase out SMS 2FA for privileged accounts and move to FIDO2 keys or TOTP apps.

SSRF (Server-Side Request Forgery) is an attack where the attacker tricks the server into making HTTP requests to an attacker-specified target — typically internal systems inaccessible from the internet. Example: an application fetches a URL provided by users: fetch(req.params.url) — an attacker passes http://169.254.169.254/latest/meta-data/ (AWS metadata service) to steal IAM credentials. SSRF can expose: internal APIs, cloud metadata, internal databases, and allow port scanning of internal networks. Prevention: (1) Allowlist valid URL destinations — only allow known, trusted domains. (2) Block private IP ranges (10.x, 172.16.x, 192.168.x, 127.x, 169.254.x). (3) Disable HTTP redirects or validate the final destination after redirection. (4) Use a dedicated egress proxy. (5) Apply least privilege to outbound network access. SSRF was added to OWASP Top 10 2021 (#10) due to its prevalence in cloud environments.

XXE (XML External Entity) injection targets XML parsers that process external entity references in user-supplied XML. An external entity definition like <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> — when the XML is parsed, the parser reads the file and substitutes its contents. This allows: reading arbitrary files, SSRF (using http:// URIs), remote code execution (in some configurations), denial of service (billion laughs attack — entity expansion). Prevention: (1) Disable external entity processing in the XML parser configuration (most critical). In Java SAXParser: factory.setFeature("http://xml.org/sax/features/external-general-entities", false). (2) Use less complex formats like JSON instead of XML where possible. (3) Validate and sanitize XML input. (4) Use a WAF with XXE signatures. Many breaches have exploited XXE in enterprise applications.

Insecure deserialization occurs when an application deserializes (reconstructs objects from) untrusted data without proper validation, allowing attackers to manipulate the data to achieve remote code execution (RCE), authentication bypass, or privilege escalation. When an application deserializes attacker-controlled data, the attacker can craft a malicious serialized object that executes arbitrary code during deserialization (via "gadget chains" — sequences of legitimate classes that, chained together, produce dangerous behavior). Famous example: the Apache Commons Collections gadget chain exploited in Java applications via serialized Java objects in session cookies, RMI, JMX. Prevention: (1) Don't deserialize untrusted data if possible. (2) Use formats like JSON/XML with explicit parsing instead of native serialization. (3) Integrity check serialized data (sign with HMAC). (4) Implement deserialization filters (Java 9+ has a mechanism). (5) Run deserialization in sandboxed, low-privilege environments.

A WAF (Web Application Firewall) monitors, filters, and blocks HTTP traffic to and from a web application, protecting it from layer 7 attacks. Unlike network firewalls (layer 3/4), WAFs understand HTTP and can inspect request/response content. WAFs protect against: SQLi, XSS, CSRF, XXE, SSRF, command injection, path traversal, and other OWASP Top 10 attacks. Modes: Detection mode (log only — use to tune rules before enforcing), Prevention mode (block malicious requests). Rule sets: OWASP Core Rule Set (open source), commercial rule sets. Deployment: Cloud-based (Cloudflare WAF, AWS WAF, Akamai — easy to deploy, no infra), On-premise appliance (F5 BIG-IP, Fortiweb — full control), Reverse proxy (Nginx + ModSecurity). Limitations: WAFs are not a silver bullet — they don't fix code vulnerabilities, can be bypassed with obfuscation, and require tuning to avoid false positives. Use as one layer of defense-in-depth.

Preventing SQL injection requires multiple layers: (1) Parameterized queries (prepared statements): the most effective defense. The query structure is defined separately from the data — the database treats user input as a data value, never as SQL code. Example in PHP: $stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?'); $stmt->execute([$email]);. (2) ORM / query builders: most ORMs use parameterized queries internally (but raw query escape hatches must still be used carefully). (3) Stored procedures: when parameterized — same protection as prepared statements. (4) Input validation: whitelist expected characters (e.g., only digits for ID fields). (5) Least privilege: the DB user should only have necessary permissions — even if injected, damage is limited. (6) WAF: additional layer to catch obvious payloads. (7) Error handling: don't return DB error messages to users (they reveal schema). Regular SQLi testing in CI/CD pipeline.

Broken authentication (OWASP #7 in 2021) encompasses flaws in authentication mechanisms that allow attackers to compromise passwords, keys, or session tokens. Common issues: Weak passwords, credential stuffing (using leaked username/password lists — billions available from data breaches), brute force (no rate limiting), session fixation (attacker sets session ID before login), session tokens in URLs, session not invalidated on logout, insecure "remember me" tokens. Prevention: (1) Implement MFA. (2) Rate limit and lockout after failed attempts (with progressive delays). (3) Check passwords against known-breached lists (HaveIBeenPwned). (4) Use secure session management: regenerate session ID on login, expire sessions, invalidate on logout. (5) Never expose session tokens in URLs. (6) Use HTTPS everywhere. (7) Implement account lockout policies. (8) Use HttpOnly; Secure; SameSite cookie attributes.

These are three DNS-based email authentication standards that together prevent email spoofing and phishing. SPF (Sender Policy Framework): a DNS TXT record listing which IP addresses/mail servers are authorized to send email for a domain. Receiving servers check if the sending IP is in the SPF record. DKIM (DomainKeys Identified Mail): the sending server cryptographically signs emails with a private key; the receiving server verifies the signature using the public key published in DNS. Proves the email was sent by the domain owner and wasn't modified in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance): builds on SPF and DKIM, allowing domain owners to specify what to do with emails that fail SPF/DKIM checks (none/quarantine/reject) and receive reports. DMARC with p=reject prevents attackers from spoofing your domain in phishing emails. All three should be configured for any domain that sends email.

White-hat hackers (ethical hackers) use their hacking skills for defensive and authorized purposes — they work with organizations' permission to find and fix vulnerabilities before malicious actors do. They perform penetration testing, bug bounty research, and security assessments. Black-hat hackers are malicious actors who exploit vulnerabilities without authorization for personal gain (financial, espionage, destruction) — they are criminals. Grey-hat hackers fall between the two — they may hack without authorization but typically don't have malicious intent; they might notify the organization after finding a vulnerability (but this is still potentially illegal without prior authorization). Other categories: Script kiddies (unskilled attackers using existing tools), hacktivists (politically motivated), nation-state actors (government-sponsored advanced threats — APT groups like Lazarus, Cozy Bear). In professional contexts, always obtain written authorization before any security testing.

Threat modeling is a structured approach to identifying, analyzing, and prioritizing potential threats to a system so that security controls can be designed proactively. Performed during the design phase (shift left security). Key frameworks: STRIDE (Microsoft): Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege — each threat mapped to a security property. PASTA (Process for Attack Simulation and Threat Analysis): business risk-focused, 7-stage process. LINDDUN: privacy-focused. Attack trees: decompose attack goals into sub-goals. Process: (1) Define scope (data flow diagram). (2) Identify threats (STRIDE per element). (3) Assess risk (likelihood × impact). (4) Define mitigations. (5) Validate. Tools: Microsoft Threat Modeling Tool, OWASP Threat Dragon, IriusRisk. Threat modeling catches architectural security issues early when they're cheapest to fix.

Certificate pinning is a technique where a client application hardcodes (pins) the expected server certificate or public key, rejecting any other certificate — even a valid one signed by a trusted CA. This prevents MITM attacks where an attacker uses a certificate from a different (but trusted) CA. Two types: Certificate pinning: pins the exact certificate (must update the app every renewal). Public key pinning: pins the public key (more flexible — key can be in new certificates without changing the pin). Implementation: in mobile apps (Android TrustKit, iOS NSURLSession), in HTTP clients (OkHttp's CertificatePinner). HPKP (HTTP Public Key Pinning) was a web standard but was deprecated due to catastrophic failure risk (if pinned incorrectly, the site becomes permanently inaccessible). Certificate pinning is recommended for high-security mobile apps (banking, healthcare) but requires a robust pin update mechanism and backup pins.

A SIEM (Security Information and Event Management) system aggregates, correlates, and analyzes log data from across an organization's IT infrastructure in real time, providing a unified view for security monitoring and incident response. Functions: Log collection: ingests logs from firewalls, IDS/IPS, endpoints, servers, applications, cloud services. Normalization: converts diverse log formats into a common schema. Correlation: applies rules to identify patterns indicating attacks (e.g., failed logins + lateral movement + data exfiltration = likely breach). Alerting: notifies SOC analysts of suspicious events. Dashboards and reporting: compliance reports, real-time security dashboards. Retention: long-term log storage for forensics and compliance. Popular SIEM platforms: Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM, LogRhythm. SIEMs generate many alerts — tuning to reduce false positives and prioritize real threats is an ongoing challenge.

A buffer overflow occurs when a program writes data beyond the bounds of an allocated fixed-size buffer in memory, overwriting adjacent memory regions. In C/C++ programs, this can overwrite: return addresses (classic stack overflow — redirect execution to attacker's shellcode), function pointers, or heap metadata (heap overflow). Stack-based overflow: attacker crafts input larger than the buffer, overwrites the return address to point to injected shellcode or existing executable code (ROP — Return Oriented Programming). Famous examples: Morris Worm (1988), Code Red, Blaster. Modern mitigations: Stack canaries: random values before return addresses, checked before returning. ASLR (Address Space Layout Randomization): randomizes memory addresses, making exploitation harder. DEP/NX (Data Execution Prevention): marks data regions as non-executable. Safe languages: Rust, Java, Python perform bounds checking automatically. Compiler flags: -fstack-protector, -D_FORTIFY_SOURCE.

A path traversal attack (directory traversal) allows attackers to access files and directories outside the intended directory by manipulating file path references using ../ sequences. Example: an application serves files with /download?file=report.pdf — an attacker requests /download?file=../../../etc/passwd, and if the app constructs the path as /app/files/../../../etc/passwd, it resolves to /etc/passwd. URL encoding variants: %2e%2e%2f, %252e%252e%252f (double encoding). Prevention: (1) Canonicalize the path and verify it starts with the expected base directory: path.resolve(baseDir, userInput) then check with .startsWith(baseDir). (2) Whitelist valid filenames — don't use user input to construct file paths at all if possible. (3) Store files outside the web root. (4) Use an indirect reference map (ID → filename mapping, never expose real paths). (5) Apply least privilege to file system access.

Clickjacking (UI redress attack) tricks users into clicking on something different from what they perceive — by overlaying a transparent malicious frame on top of a legitimate page. Example: an attacker creates a page with a button labeled "Win a Prize!" and overlays a transparent iframe of a banking site's "Transfer Funds" button at the exact same position — when the user clicks what they think is the prize button, they actually click the bank's transfer button. Prevention: (1) X-Frame-Options header: DENY (never framed) or SAMEORIGIN (only same-origin frames). (2) CSP frame-ancestors directive: more flexible modern replacement — Content-Security-Policy: frame-ancestors 'none'. (3) Frame-busting JavaScript: legacy approach (easily bypassed). (4) SameSite cookies: mitigates authenticated clickjacking. Always set X-Frame-Options or CSP frame-ancestors on all pages.

An open redirect vulnerability occurs when an application accepts user-controlled input to redirect to an external URL without proper validation. Example: https://example.com/redirect?url=https://evil.com — the app redirects the user to the attacker's site. This is dangerous because: (1) Phishing: attackers use the trusted domain in the initial URL to bypass email filters, then redirect to a malicious site. (2) OAuth token theft: if redirect URIs aren't strictly validated in OAuth flows, attackers can redirect access tokens to their server. Prevention: (1) Avoid open redirects entirely — use indirect references (a whitelist mapping of allowed redirect targets). (2) If redirects must be dynamic, maintain a strict whitelist of allowed external URLs or domains. (3) Validate that the redirect destination is on an allowlist before redirecting. (4) Show the user the destination URL and require confirmation for external redirects. (5) Never use raw user input directly in redirect responses.

Command injection occurs when an application passes unsafe user-supplied data to a system shell (OS command). Example: exec("ping " + userInput) — attacker enters 8.8.8.8; cat /etc/passwd, resulting in the passwd file being read. The shell interprets ; as a command separator. Variations: &&, ||, backticks, | (pipe), $(...). Prevention: (1) Avoid OS command calls — use language-native library functions instead (e.g., use a DNS library instead of calling nslookup). (2) If unavoidable, use APIs that separate the command from arguments (no shell interpretation): subprocess.run(['ping', user_input]) in Python (list form, not string). (3) Input validation: whitelist allowed characters. (4) Apply least privilege to the process executing commands. (5) Run in a sandboxed environment. Command injection can lead to full server compromise.

LDAP injection occurs when user input is unsafely embedded into an LDAP query, allowing attackers to manipulate the query to bypass authentication or extract unauthorized directory data. Example: an authentication query (&(uid=USER)(password=PASS)) — if the attacker enters *)(& as the user, the query becomes (&(uid=*)(&)(password=...)) which returns the first user regardless of password. LDAP injection is analogous to SQL injection but for LDAP directory services (Active Directory, OpenLDAP). Prevention: (1) Parameterized LDAP queries (use the LDAP library's escaping functions). (2) Input validation: whitelist allowed characters in username/search fields. (3) Escape special LDAP characters: (, ), *, \, NUL. (4) Least privilege: the LDAP service account should have minimal read permissions. (5) Disable anonymous LDAP access.

Security in the SDLC (Secure SDLC or DevSecOps) integrates security practices throughout every phase of software development rather than treating it as an afterthought. Phases: Requirements: define security requirements, threat model. Design: threat modeling, architecture review, security patterns. Development: secure coding guidelines, IDE security plugins (SAST in editor), code reviews with security focus. Testing: SAST (static analysis — Checkmarx, SonarQube), DAST (dynamic analysis — OWASP ZAP, Burp Suite), SCA (software composition analysis for vulnerable dependencies — Snyk, OWASP Dependency-Check), penetration testing. Deployment: infrastructure security scanning, secrets management (never hardcode secrets). Operations: monitoring, patching, incident response. The "shift left" philosophy: find and fix security issues as early as possible (cheapest in requirements, most expensive in production). DevSecOps automates security checks in CI/CD pipelines.

SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing the program to find security vulnerabilities. It's done in the development phase (IDE plugins, CI/CD). Finds: hardcoded secrets, SQL injection patterns, buffer overflows, dangerous function use, insecure configs. Advantages: catches issues early (before deployment), covers 100% of code paths. Disadvantages: high false positive rate, can't find runtime/configuration issues. Tools: Checkmarx, Veracode, SonarQube, Semgrep, CodeQL. DAST (Dynamic Application Security Testing) tests the running application from the outside — like an attacker would, sending malicious inputs and observing responses. Finds: XSS, SQLi, SSRF, auth issues, misconfigurations that are only visible at runtime. Advantages: low false positives, finds runtime issues. Disadvantages: can't cover all code paths, runs later in lifecycle. Tools: OWASP ZAP, Burp Suite, Nikto, Nessus. Best practice: use both — SAST in CI for fast feedback, DAST against staging/pre-prod environments.

Virus: a malicious program that attaches itself to a legitimate executable file and spreads only when the infected file is executed or shared. Viruses require human action to propagate (sharing an infected file). They typically damage files, corrupt data, or use system resources. Worm: self-replicating malware that spreads automatically across networks without user intervention by exploiting vulnerabilities. WannaCry used the EternalBlue exploit to spread laterally across networks. Worms can cause massive network disruption. Trojan horse (Trojan): disguises itself as legitimate software (games, utilities, email attachments) — the user willingly installs it. Once executed, it installs a backdoor, steals data, or downloads additional malware. Doesn't self-replicate. Common vector for RATs (Remote Access Trojans). Key difference: virus needs a host file, worm is self-contained and self-propagating, trojan relies on deception. Modern malware often combines characteristics.

API security best practices: (1) Authentication: use OAuth 2.0/OpenID Connect; API keys for service-to-service. (2) Authorization: implement RBAC/ABAC; check object-level authorization on every request (prevent BOLA/IDOR). (3) HTTPS only: all API traffic must be encrypted. (4) Input validation: validate type, format, range, and length of all inputs; use an API schema (OpenAPI) for validation. (5) Rate limiting: prevent brute force and DoS. (6) No sensitive data in URLs: tokens, passwords, PII in query strings appear in logs and browser history. (7) Versioning: avoid breaking changes; maintain old versions. (8) Error handling: return generic errors — never expose stack traces, DB errors, or internal structure. (9) Logging and monitoring: log all API calls with user context. (10) Disable unused HTTP methods. (11) Security headers. (12) CORS policy: allowlist specific origins. (13) Dependency scanning: keep libraries updated. Reference: OWASP API Security Top 10.

Defense-in-depth for web applications means layering multiple security controls so no single control failure leads to a breach. Layers: (1) Network perimeter: CDN + DDoS protection (Cloudflare), WAF filtering. (2) Transport: HTTPS with HSTS, TLS 1.2+, strong cipher suites. (3) Application authentication: MFA, secure session management, account lockout. (4) Application authorization: RBAC, object-level auth, principle of least privilege. (5) Input handling: validation + parameterized queries + output encoding. (6) Security headers: CSP, X-Frame-Options, HSTS, Referrer-Policy. (7) Dependencies: SCA scanning, automated dependency updates. (8) Database: encrypted at rest, least privilege DB user, no public access. (9) Secrets management: vault (HashiCorp Vault, AWS Secrets Manager), no secrets in code. (10) Monitoring: SIEM, anomaly detection, alerting on auth failures. (11) Incident response: documented playbooks, backups, disaster recovery. Each layer independently reduces risk.

Ransomware is malware that encrypts the victim's files and demands a ransom (typically cryptocurrency) for the decryption key. Modern ransomware also exfiltrates data and threatens publication (double extortion). Famous attacks: WannaCry (2017), NotPetya (2017 — $10B in damages), Colonial Pipeline (2021). Attack chain: phishing email → malware delivery → execution → privilege escalation → lateral movement → data exfiltration → encryption → ransom demand. Defense: (1) Offline, immutable backups (3-2-1 rule: 3 copies, 2 media types, 1 offsite) — test restore regularly. (2) Patch management: most ransomware exploits known vulnerabilities. (3) MFA: prevents credential-based initial access. (4) Email security: DMARC, anti-phishing, sandbox attachments. (5) Network segmentation: limits lateral movement. (6) EDR: detects and contains ransomware behavior. (7) Least privilege: limits encryption scope. (8) Disable RDP or put behind VPN (major ransomware entry vector). (9) Incident response plan.

Security hardening is the process of reducing the attack surface of a system by removing unnecessary software, services, users, and permissions, and configuring secure settings. The goal: minimize the number of possible entry points an attacker can use. Hardening steps: (1) Remove unused services: disable/uninstall any service not needed (each is a potential vulnerability). (2) Change defaults: default credentials, ports, settings. (3) Least privilege: minimal permissions for users and services. (4) Enable firewall: only allow required ports. (5) Patch all software. (6) Enable logging and monitoring. (7) Disable/remove unused user accounts. (8) Encrypt sensitive data. (9) Configure strong password/key policies. (10) Enable host-based IDS. Baseline hardening standards: CIS Benchmarks (Center for Internet Security) provide step-by-step guides for every major OS, cloud service, and application. Tools: OpenSCAP, Lynis (audit), Ansible/Chef/Puppet (automate).

A supply chain attack targets the less-secure elements in a software or service supply chain — third-party vendors, open-source libraries, build tools, or update mechanisms — rather than attacking the primary target directly. The attacker compromises a trusted supplier to reach their actual targets at scale. Famous examples: SolarWinds (2020): attackers inserted malicious code into SolarWinds' Orion software update, compromising 18,000+ organizations (including US government agencies). XZ Utils (2024): malicious backdoor inserted into a popular Linux compression library via a long-term social engineering campaign on the maintainer. npm package hijacking: event-stream and colors npm packages were compromised. Defense: (1) Software Composition Analysis (SCA): track and audit all dependencies. (2) Dependency pinning: pin exact versions with hash verification. (3) Vendor security assessments. (4) SBOM (Software Bill of Materials): inventory all components. (5) Build pipeline security: sign artifacts, verify provenance (SLSA framework).

Zero Trust is a security model based on the principle "never trust, always verify" — abandoning the traditional perimeter-based model (trust everything inside the network). In Zero Trust, no user, device, or network segment is inherently trusted, even if inside the corporate perimeter. Core tenets: (1) Verify explicitly: always authenticate and authorize based on all available data points (identity, location, device, service, data, anomalies). (2) Least privilege access: limit user access with just-in-time and just-enough-access, risk-based adaptive policies. (3) Assume breach: design as if the attacker is already inside — minimize blast radius, segment access, encrypt everything, verify end-to-end. Implementation: Identity as the new perimeter (strong IAM, MFA), micro-segmentation, device health validation, continuous monitoring. Frameworks: NIST SP 800-207, Google BeyondCorp. Technologies: ZTNA (Zero Trust Network Access), PAM, CASB. Driven by remote work, cloud adoption, and insider threat concerns.

The MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. It organizes attacker behavior into: Tactics: the adversary's goal (why) — 14 tactics including Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact. Techniques: how the goal is achieved (what) — 200+ techniques with sub-techniques. Procedures: specific implementations (how particular groups implement techniques). Use cases: Detection engineering (writing detection rules for known techniques), red team planning (simulating adversary TTPs), purple teaming (red and blue teams collaborating), gap analysis (identify coverage gaps), threat intelligence mapping (attribute activity to known APT groups). ATT&CK Navigator visualizes coverage. Essential knowledge for SOC analysts, threat hunters, and red teamers.

Structured pen testing follows defined methodologies: PTES (Penetration Testing Execution Standard): Pre-engagement → Intelligence Gathering → Threat Modeling → Vulnerability Analysis → Exploitation → Post-Exploitation → Reporting. OWASP Testing Guide: web application specific, 11 categories. OSSTMM: rigorous scientific methodology. NIST SP 800-115: government standard. Phases in detail: (1) Pre-engagement: scope, rules of engagement, legal authorization, emergency contacts. (2) Reconnaissance (OSINT): Shodan, Google dorks, LinkedIn, WHOIS, DNS enumeration, Maltego. (3) Scanning: Nmap, Nessus, Nikto, Gobuster (directory), Wfuzz (parameter fuzzing). (4) Exploitation: Metasploit, Burp Suite (manual), SQLMap, custom exploit code. (5) Post-exploitation: privilege escalation, lateral movement, persistence, data access, pivoting. (6) Reporting: executive summary + technical findings (severity, CVSS, PoC, remediation). Always follow rules of engagement strictly.

A PKI (Public Key Infrastructure) is the set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, store, and revoke digital certificates. It enables trusted identity verification and encrypted communication at scale. Components: Certificate Authority (CA): the trusted issuer of digital certificates. Root CA: the ultimate trust anchor (self-signed, kept offline in air-gapped HSMs). Intermediate CA: issues end-entity certificates; if compromised, only its certificates are revoked, not the root. Registration Authority (RA): verifies identity before CA issues certificates. Certificate Repository: CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) for checking revoked certificates. X.509: the standard certificate format. PKI underpins HTTPS, S/MIME email encryption, code signing, VPN authentication, and smart card authentication. Corporate PKI enables internal certificate management without public CA costs. CA compromise (DigiNotar 2011) demonstrates the critical nature of CA security.

These are complementary but different security technologies: IDS/IPS (Intrusion Detection/Prevention System): network-focused, monitors network traffic for known attack signatures and anomalies. IDS alerts; IPS blocks. Operates at the network layer, inspects packets. Limited visibility into endpoint behavior. SIEM (Security Information and Event Management): aggregates and correlates log data from across the environment (network, endpoints, cloud, applications). Provides a unified view for threat detection, investigation, and compliance reporting. Relies on data fed to it — visibility depends on log sources. EDR (Endpoint Detection and Response): agent-based, runs on endpoints (servers, workstations). Collects telemetry (process, file, network, registry activity), detects anomalous behavior, enables investigation and remote response (isolate host, collect forensics, kill processes). Excellent at detecting fileless malware and living-off-the-land techniques invisible to network-only tools. Modern architecture: IDS/IPS feeds into SIEM; EDR feeds into SIEM; SIEM correlates across all sources; SOC uses all three. XDR (Extended Detection and Response) unifies EDR + network + cloud into a single platform.

An APT (Advanced Persistent Threat) is a sophisticated, long-term cyberattack campaign typically carried out by nation-state actors or well-funded criminal groups targeting high-value organizations. Characteristics: Advanced: use custom malware, zero-days, and sophisticated techniques. Persistent: maintain long-term covert access, moving slowly to avoid detection (dwell time can be months or years). Threat: motivated by espionage, IP theft, financial gain, or sabotage. Known APT groups (MITRE ATT&CK naming): APT28/Fancy Bear (Russian GRU — election interference, DNC hack), APT29/Cozy Bear (Russian SVR — SolarWinds), Lazarus Group (North Korean — Sony Pictures, WannaCry, crypto theft), APT41 (Chinese — espionage + financial crime). Kill chain: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives. Defense: assume breach mentality, threat hunting, behavioral detection, network segmentation, and strong identity controls.

Cryptographic key management encompasses the generation, storage, distribution, use, rotation, and destruction of cryptographic keys — the most critical aspect of any encryption system. A well-encrypted system with poor key management is effectively insecure. Key practices: (1) Key generation: use cryptographically secure random number generators (CSPRNG); sufficient key length (AES-256, RSA-4096, ECDSA-256). (2) Key storage: never store keys in plaintext — use HSMs (Hardware Security Modules) for the highest security, or cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault) for practical deployments. (3) Key rotation: rotate keys regularly and after suspected compromise. (4) Key separation: different keys for different purposes (data encryption keys vs key encryption keys). (5) Envelope encryption: encrypt data with a DEK (Data Encryption Key), encrypt the DEK with a KEK (Key Encryption Key) stored in KMS. (6) Audit trails: log all key access and operations. (7) Destruction: securely destroy keys that are no longer needed.

Fuzzing (fuzz testing) is an automated software testing technique that provides random, malformed, or unexpected inputs to a program to discover bugs, crashes, and security vulnerabilities. Fuzzing is particularly effective at finding buffer overflows, memory corruption, assertion failures, and input validation issues. Types: Mutation-based: mutates valid inputs randomly (bit flipping, byte substitution). Generation-based: generates inputs based on file/protocol specifications. Coverage-guided (grey-box): instruments the target binary to measure code coverage and evolve inputs toward unexplored paths — most effective. Tools: AFL++ (American Fuzzy Lop): coverage-guided C/C++ fuzzer. LibFuzzer: LLVM in-process fuzzer. OSS-Fuzz: Google's continuous fuzzing for open-source projects (has found 10,000+ bugs). Burp Suite Intruder: web application fuzzing. Boofuzz: network protocol fuzzing. Google, Microsoft, and Mozilla use continuous fuzzing — it discovered hundreds of CVEs in Chrome, Firefox, and critical libraries.

A side-channel attack exploits information leaked by the physical implementation of a cryptographic system — rather than weaknesses in the algorithm itself. The algorithm may be mathematically sound, but its implementation leaks information through measurable physical phenomena. Types: Timing attacks: measure time taken to execute cryptographic operations — variations reveal information about the secret key (non-constant-time comparisons). Power analysis: measure power consumption of hardware during crypto operations (Simple Power Analysis, Differential Power Analysis). Electromagnetic (EM) attacks: measure electromagnetic emissions. Cache attacks: Spectre and Meltdown exploited CPU cache behavior to read arbitrary memory across process boundaries (2018 — affected virtually all modern CPUs). Acoustic attacks: extract RSA keys from laptop fan noise during decryption. Countermeasures: constant-time implementations (no secret-dependent branches/memory access), blinding (randomize intermediate values), hardware shielding, and noise injection. Always use vetted cryptographic libraries rather than implementing crypto yourself.

A honeypot is a decoy system, network, or resource designed to attract attackers, detect unauthorized access, and gather intelligence about attack techniques — without endangering real systems. Types: Low-interaction honeypots: simulate services to attract automated scanners (Cowrie SSH honeypot, Honeyd). Easy to deploy, limited intelligence. High-interaction honeypots: full real systems (often VMs) that allow attackers to interact deeply — provides rich intelligence but risky (attacker could pivot). Honeynet: a network of honeypots simulating an organization's infrastructure. Honeytokens: fake credentials, documents, or data — alerts fire when accessed (e.g., a fake AWS key that triggers an alert if used). Use cases: (1) Detect attackers who breach the perimeter (honeyfiles, honeyservices). (2) Research attacker tools and techniques. (3) Early warning system. (4) Deflect attackers from real systems. Legal consideration: honeypots may raise entrapment concerns in some jurisdictions — consult legal counsel.

The OWASP API Security Top 10 (2023 edition) identifies the most critical API security risks. (1) Broken Object Level Authorization (BOLA/IDOR): APIs not verifying the user is authorized to access the specific object by ID — most common API vulnerability. (2) Broken Authentication: weak auth mechanisms, missing rate limiting on auth endpoints. (3) Broken Object Property Level Authorization: exposing or allowing modification of object properties a user shouldn't access (mass assignment, data exposure). (4) Unrestricted Resource Consumption: no rate limiting, request size limits, or resource quotas. (5) Broken Function Level Authorization: regular users accessing admin functions. (6) Unrestricted Access to Sensitive Business Flows: no controls on abusing legitimate business logic at scale (scalping, credential stuffing). (7) SSRF. (8) Security Misconfiguration. (9) Improper Inventory Management: forgotten old API versions. (10) Unsafe Consumption of APIs: trusting data from third-party APIs without validation.

A security incident response plan (IRP) is a documented set of procedures for detecting, responding to, and recovering from cybersecurity incidents. Phases (NIST framework): (1) Preparation: establish the CSIRT (Computer Security Incident Response Team), define roles, deploy tools (SIEM, EDR), create playbooks for common scenarios (ransomware, data breach, insider threat), conduct tabletop exercises. (2) Detection and Analysis: monitor for incidents, triage alerts, determine scope and severity, preserve evidence. (3) Containment: short-term (isolate affected systems), long-term (apply fixes to prevent re-infection). (4) Eradication: remove malware, patch vulnerabilities, change compromised credentials. (5) Recovery: restore systems from clean backups, verify integrity, monitor for recurrence. (6) Post-incident Activity: root cause analysis, lessons learned, update defenses. Key metrics: MTTD, MTTR. Legal obligations: GDPR 72-hour breach notification, HIPAA, industry-specific requirements. Practice the plan — simulate incidents quarterly.