Security Engineer interview questions

For practical purposes, no. AES-128 already needs about 2^128 work to brute-force — utterly infeasible — so AES-256 doesn't make you meaningfully safer against brute force; it mainly adds margin (e.g. post-quantum headroom, compliance). Both are standardized and unbroken. Your mode (GCM), nonce handling, and key management matter far more than 128 vs 256. 'AES-256 is twice as secure' is the misconception.

No. You can't compare raw key length across different algorithm families. Because of how each one's underlying math hardens, a 256-bit elliptic-curve key gives roughly the same security as a 3072-bit RSA key — about 128-bit strength, per NIST. Bigger isn't simply stronger: ECC reaches equivalent strength with far smaller keys, which is why modern systems prefer it. Within a single algorithm, longer keys do help, up to a point.

No. The three authentication factor categories are something you know (password/PIN), something you have (token/phone), and something you are (biometrics). A fingerprint or face scan is 'something you are', a measured physical trait. The gotcha: biometrics aren't secrets and can't be rotated — if your fingerprint template leaks, you cannot change your fingerprint. That's why biometrics work best as one factor, often unlocking a local key, rather than as a standalone password replacement.

No. Deleting the cookie just removes the credential from your browser — the session record (or a still-valid JWT) on the server typically remains usable until it expires or is explicitly invalidated. An attacker who already captured the token can keep using it. The misconception treats the cookie as the session itself; it is only a pointer to server-side state. Real logout must invalidate the session server-side, or revoke and short-TTL the token.

Not necessarily. Double-encrypting with the same algorithm doesn't simply double security — the classic result is that 2DES adds only about one bit of effective strength because of meet-in-the-middle attacks, which is why 3DES exists. More importantly, hand-rolled multi-layer schemes tend to introduce implementation bugs that weaken the whole thing. Use one well-vetted authenticated cipher (AES-GCM) with sound key management instead of stacking crypto.

Mostly no. The destination hostname is sent in the clear in the TLS ClientHello's SNI extension, and your DNS query usually reveals it too, so an ISP or network can see WHICH site you visit even over HTTPS — they just can't read the path or content. Encrypted ClientHello (ECH) and DNS-over-HTTPS can close this gap, but they aren't universal. 'HTTPS hides everything' is the misconception.

No. TLS/HTTPS secures data in transit between client and server; once received, the data is decrypted and handled in plaintext by the app, then stored however the database is configured. Protecting data at rest is a separate concern — disk/column encryption, a KMS, and access control. Conflating 'we use HTTPS' with 'our stored data is encrypted' is a common and dangerous misconception.

No. The whole 127.0.0.0/8 range is reserved for loopback, so 127.0.0.2, 127.1.1.1, and so on all resolve to the local host. This matters for SSRF and allow-list bypasses — an attacker may use 127.0.0.2 or other encodings to dodge a naive 'block 127.0.0.1' check — and for binding multiple local services. (In IPv6, loopback is the single address ::1.)

No. MFA raises the bar a lot, but OTP and push factors are phishable: adversary-in-the-middle kits (e.g. Evilginx) proxy the login and relay the code in real time, and MFA-fatigue/push-bombing tricks users into approving. Captured codes are reusable within their short window. The misconception is 'MFA = unphishable'; the factor type is what matters. Phishing-resistant MFA — FIDO2/WebAuthn passkeys bound to the site's origin — is what actually defeats this.

No. NAT (and PAT) maps private addresses to a public IP and, as a byproduct, drops unsolicited inbound connections because no mapping exists for them. That's not a security policy — there's no inspection, no rules, no logging — and NAT traversal, hole punching, and outbound-initiated C2 pass right through. NAT is an addressing tool; you still need an actual firewall. 'NAT = firewall' is the misconception.

No. A salt is a unique, random value stored right alongside the hash; its job is to make identical passwords hash differently and to defeat precomputed rainbow tables — not to stay secret. It's fine if an attacker who steals the database also gets the salts. What actually protects passwords is a slow, salted hash (bcrypt, scrypt, Argon2). A separate, optional secret 'pepper' is a different concept.

No. A VPN encrypts traffic to the VPN server and hides your IP from the destination, but the provider can see and may log your activity, and logins, cookies, and browser fingerprinting still identify you. It moves trust from your local network/ISP to the VPN operator — that's privacy from the local network, not anonymity. Tor and strict operational discipline are different tools for a different goal.

Password storage needs a deliberately slow, salted, memory-hard hash — bcrypt, scrypt, or Argon2 — so cracking stolen hashes is expensive and rainbow tables don't apply. A fast hash like SHA-256 is trivially brute-forced at scale; reversible encryption means one key compromise exposes every password at once; and plaintext is indefensible no matter how locked down the database is. Choose Argon2id (or bcrypt) with a tuned work factor and a unique per-user salt.

SSLv3, TLS 1.0, and RC4 are broken or deprecated and enable downgrade and decryption attacks, so disable them and require TLS 1.2 or 1.3 with strong, forward-secret cipher suites — accepting the rare loss of very old clients. Leaving them on for compatibility keeps the weakness exploitable. Adding a second certificate or switching to a self-signed one doesn't remove the weak protocols, and self-signed certs harm trust without fixing the cryptography.

Leaver risk is lingering access, so the control to verify is timely deprovisioning of every access path — directory accounts, SSO, VPN, privileged and service credentials, and third-party SaaS — reconciled against the joiner/mover/leaver (JML) process. Assuming HR handles it all without verification leaves gaps no one owns. Keeping the account active 'in case they come back' is standing, unmonitored risk. Disabling only email ignores the many other systems the person could still reach. The point is to verify access is actually and fully removed, not to trust that it was.

Unused, over-privileged service accounts are prime targets and a large attack surface. Inventory them, disable or delete the unused ones (watching for breakage), right-size the survivors to least privilege, and give each an owner plus a recurring review. Leaving them is standing risk, granting blanket admin maximizes blast radius, and consolidating onto one shared account destroys least privilege and accountability.

An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.

A SUID-root binary executes with root privileges, and if it's world-writable an attacker can replace or modify it to run arbitrary code as root — a classic local privilege-escalation path. Remove the SUID bit, correct ownership and permissions, and investigate how the misconfiguration appeared, since it may indicate compromise. Encrypting the file leaves the executable path intact, and renaming it just moves the problem without removing the escalation. Neither addresses the root cause.

Because firewalls evaluate rules top-down, a broad any/any allow near the top short-circuits every rule below it and permits all traffic — the firewall effectively stops enforcing anything. Replace it with explicit least-privilege rules for the flows actually needed, ordered so specific allows and denies take effect, ending in a default deny. Calling it efficient is wrong, moving it to the bottom can still shadow the default deny, and renaming changes nothing about what it permits.

Server-side fetching of attacker-controlled URLs is server-side request forgery (SSRF): it lets an attacker reach internal-only services or the cloud metadata endpoint to steal credentials. Mitigate by allow-listing permitted hosts and schemes, blocking private and link-local ranges (re-checking after every redirect), and hardening metadata access with IMDSv2. Saying there's no risk ignores the access the fetch grants, and a loading spinner or response caching does nothing about where the server is allowed to connect.

This is broken access control (IDOR): the server isn't checking that the authenticated user may access the requested object. The fix is per-object authorization enforced server-side on every request. Sanitizing the number doesn't establish ownership. Encrypting or obfuscating the ID is obscurity that's still guessable, leakable, or replayable. The HTTP method is irrelevant to authorization. Always verify the caller's right to the specific object before returning it.

Parameterized queries are the actual fix: they separate code from data so user input is always treated as a value, never as SQL that can change the query's structure. Manual escaping is error-prone and bypassable across encodings and dialects. A WAF is a compensating control, not a fix, and encoding tricks defeat it. A length check doesn't stop injection at all. Fix it at the query layer.

Encryption at rest defends exactly one threat — physical or disk theft — and does nothing against a compromised application, stolen credentials, or sniffed traffic, because the database decrypts transparently for any authorized query. A sound design also requires TLS in transit, strong authentication and authorization, and proper key management with separation of duties. Doubling the at-rest encryption adds cost without changing the threat model, and encrypting only the backups leaves the live data and its access paths exposed.

If the key lives with the ciphertext, anyone who steals the database gets both, so the encryption protects nothing — it is a lock with the key taped to it. Keys must be managed in a dedicated KMS or HSM, separated from the data, with strict access control, rotation, and separation of duties. Hashing the key makes it one-way and useless for decryption, and storing extra copies in the same place just multiplies the exposure rather than reducing it.

The manual console change is configuration drift: the next terraform apply can silently revert the fix, and the change also bypassed peer review and audit. Reconcile it by codifying the change in Terraform, running plan/apply so code and reality match, and adding guardrails against ad-hoc console edits (least-privilege console access, SCPs, drift detection). Doing nothing leaves a landmine for the next apply. Deleting the Terraform state is destructive and can orphan or duplicate resources. Abandoning Terraform throws away reproducibility, review, and audit trails.

An internet-facing, unauthenticated RCE is emergency-grade: shrink the exposure window with a tested, staged or rolling deploy, and add compensating controls (restrict access, WAF rules) in the meantime. Waiting for the quarterly window leaves a wormable hole open for weeks. Blind production patching during business hours with no testing risks an outage and a botched rollback. Trusting the perimeter firewall does nothing — the service is already exposed and the exploit needs no credentials.

Executives are exactly the accounts attackers want (BEC, wire fraud), so exempting them inverts the risk model. Solve the friction, not the control: deploy phishing-resistant FIDO2/passkeys that are faster than codes. Caving to the exemption guts the program's credibility and leaves your highest-value accounts unprotected. Killing the MFA project abandons a top-tier control. Quietly enabling it behind their backs destroys trust and accountability.

Flat networks let one compromised guest device reach crown-jewel systems directly. Segment by trust level and enforce least-privilege traffic between zones so lateral movement is contained and monitored. An edge firewall does nothing for east-west traffic between hosts already inside. Re-IPing the finance servers is security-by-obscurity that any scan defeats. Endpoint AV is one detective layer, not a substitute for the architectural control of isolating sensitive systems.

Least privilege plus just-in-time access: grant the minimum permissions needed, time-boxed and logged, so debugging is possible without standing admin that becomes a permanent risk and audit gap. Permanent cluster-admin violates least privilege and widens the blast radius of any compromise. A blanket denial blocks legitimate work and invites risky shadow workarounds. Sharing the common admin service-account credential destroys accountability — actions can't be traced to a person.

Treat any pushed secret as burned: revoke and rotate it first, because bots scrape public commits within seconds, then review CloudTrail for misuse and purge it from history. Deleting the commit doesn't help — the key is already cloned, forked, and cached by third parties. Making the repo private leaves a live, already-leaked key in attackers' hands. Adding the file to .gitignore does nothing for a secret that is already committed.

Sensitive data should never reach logs: redact or mask at the source first to stop the bleeding, then remediate the historical logs and tighten access. PCI DSS forbids storing full PANs and CVVs this way, and passwords should never be logged at all. 'Internal' logs are still a prime breach target. Encrypting or ACLing the store still leaves cleartext secrets sitting in logs for anyone with read access — backups, SIEM pipelines, and admins all see them.

Manual renewals fail, so engineer the problem away with automated ACME renewal plus expiry monitoring that alerts days in advance. A calendar reminder is the manual process that already failed once. A long-lived self-signed cert breaks public trust and violates modern lifetime limits (CAs cap validity at ~398 days, dropping further). Disabling TLS trades an availability blip for a catastrophic confidentiality and integrity loss.

Cut false positives through detection engineering, not by blinding yourself. Re-tune so alerts fire only on patterns that matter — many accounts hit with one password (spraying), one account hit many times (stuffing/brute force), impossible travel — while keeping the raw failed-login events searchable on a dashboard. Then measure alert precision over time. Disabling the rule removes a real signal, blanket suppression creates a permanent blind spot, and hiring people to triage pure noise doesn't scale and burns them out.

AI helps the SOC by triaging and de-duplicating alerts, summarizing incidents, enriching context, drafting detections, and accelerating analyst onboarding — reducing fatigue and dwell time. The risks: hallucinated or confidently wrong conclusions, automation bias where analysts stop verifying, prompt injection through attacker-controlled log or alert data, sensitive data leaking into third-party models, and adversaries using the same tools. Keep a human in the loop, verify outputs, and isolate untrusted inputs.

Direct prompt injection is when a user types adversarial instructions straight into the prompt to override the system prompt or safety rules. Indirect prompt injection hides malicious instructions inside external content the model later ingests — a web page, email, PDF, or RAG document — so the attack fires without the victim ever typing it. Indirect injection is the bigger risk because the attacker and the victim are different people, and the payload rides in on data the app implicitly trusts.

Insecure output handling is trusting what the model returns and passing it to a downstream system without validation or encoding. Because model output is attacker-influenceable, rendering it as raw HTML causes XSS, feeding it to a URL fetcher causes SSRF, and passing it to a shell or SQL query causes command or SQL injection. The fix is to treat model output exactly like untrusted user input: context-aware output encoding, allowlisting, sanitization, and parameterization before it reaches any sink.

A jailbreak targets the model's safety alignment — it tricks the model into producing content the provider tried to prohibit, like instructions for harm. Prompt injection targets the application's instruction hierarchy — it overrides the developer's system prompt or hijacks the model's behavior within an app, often via untrusted data. Jailbreaks attack the model; prompt injection attacks the surrounding system. They overlap, but the goal and the trust boundary they cross are different.

The LLM supply chain spans base models, fine-tuned variants, datasets, embeddings, plugins, libraries, and the hosting platform — each a place to introduce risk. Threats include downloading tampered or backdoored model weights, malicious fine-tunes, poisoned or license-tainted datasets, vulnerable or over-permissioned plugins, and typosquatted model repos. Defenses: source models from trusted registries, verify integrity and provenance, maintain an AI bill of materials, scan and pin dependencies, vet plugins, and apply least privilege to anything the model integrates with.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, risk-based framework for governing trustworthy AI across its lifecycle. Its core is four functions: Govern (culture, policy, accountability — and it runs through the others), Map (context and risk identification), Measure (assess and track risks), and Manage (prioritize and respond). It also defines trustworthiness characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair. It complements technical lists like the OWASP LLM Top 10 at the program level.

The OWASP Top 10 for LLM Applications is the consensus list of the most critical risks when building with large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It exists because traditional appsec lists don't capture LLM-specific failure modes, and it gives teams a shared vocabulary and a checklist to prioritize controls.

RAG security means treating every retrieved document as untrusted input. Key risks: indirect prompt injection hidden in retrieved content, poisoning of the knowledge base or embeddings, and missing per-user authorization so the model returns data the user can't access. Defenses include access control enforced at retrieval, content provenance and ingestion vetting, treating retrieved text as data not instructions, output validation, and isolating the vector store per tenant.

An LLM agent turns text into actions via tools and function calls, so a prompt injection becomes a real-world action — the excessive-agency risk. Secure it by giving each tool the least privilege and scope it needs, validating and constraining tool arguments, requiring human confirmation for sensitive or irreversible actions, sandboxing execution, rate-limiting and budgeting calls, and logging every tool invocation. Never let the model's untrusted-data-influenced output directly authorize a high-impact action.

LLM apps leak data several ways: the model memorizes and regurgitates sensitive training or fine-tuning data, the system prompt (which may hold secrets or logic) gets extracted, retrieved RAG documents expose data the user shouldn't see, and context from one user or session bleeds into another. Prevention means data minimization before training, never putting secrets in prompts, enforcing per-user authorization on retrieval, output filtering and PII redaction, and tenant isolation.

Training-data poisoning is when an attacker tampers with the data used to pre-train, fine-tune, or embed a model so the resulting model behaves maliciously — embedding a backdoor trigger, injecting bias, or degrading accuracy. It exploits the fact that models scrape and trust large, often web-sourced datasets. Defenses include curating and signing data sources, provenance and integrity checks, anomaly detection on training data, dataset versioning, and limiting who can contribute to training and RAG corpora.

Credential stuffing replays known username:password pairs from third-party breaches, betting on password reuse — high success rate per attempt, often distributed across many IPs and devices to look human. Password spraying tries one or two common passwords (like Winter2026!) across many accounts to stay under lockout thresholds. Stuffing exploits reuse; spraying exploits weak shared passwords. MFA defeats both.

The Cyber Kill Chain models an intrusion as seven sequential stages: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and actions on objectives. Defenders map detections and controls to each stage; because the stages are sequential, breaking any single link — blocking the phishing email, killing C2 — disrupts the whole attack. It pushes you to detect early rather than only at the final breach.

DNS exfiltration encodes stolen data into DNS queries (e.g. long subdomain labels sent to an attacker-controlled authoritative server), abusing the fact that DNS is almost always allowed outbound and often unmonitored. Detect it with anomalies: unusually high query volume to one domain, long/high-entropy subdomains, many unique subdomains per parent domain, TXT/NULL record abuse, and queries to newly registered or rare domains.

Traditional antivirus matches files against signatures of known malware and blocks or quarantines them — great for known threats, weak against novel or fileless attacks. EDR continuously records endpoint behavior (processes, network, registry, memory), uses behavioral analytics to detect suspicious activity, and lets responders investigate, hunt, and remotely contain or roll back. AV is prevention by signature; EDR adds visibility, detection, and response.

On Windows, local account hashes (NTLM) live in the SAM hive under C:\Windows\System32\config\SAM, protected while the OS runs; live credentials sit in LSASS memory, and domain hashes are in NTDS.dit on a domain controller. On Linux, hashes are in /etc/shadow (readable only by root), while /etc/passwd holds account metadata. Attackers steal these to crack passwords offline or pass-the-hash.

SPF publishes which IPs may send mail for a domain. DKIM adds a cryptographic signature so the receiver can verify the message was not altered and came from the domain. DMARC ties SPF/DKIM results to the visible From: header via 'alignment', tells receivers what to do on failure (none/quarantine/reject), and sends reports. SPF and DKIM alone do not protect the From a user sees — DMARC is what enforces that.

A honeypot is a decoy system or service with no legitimate business use, deliberately exposed to attract attackers. Because nothing benign should ever touch it, any interaction is a high-confidence alert. Low-interaction honeypots emulate services cheaply; high-interaction ones are real systems that yield richer intel but carry more risk. Honeytokens are the same idea applied to fake credentials, files, or records. Value: early detection, low false positives, and threat intelligence.

DAC lets the data owner grant access at their discretion; MAC enforces access centrally via labels/clearances and is non-discretionary; RBAC grants access through job roles; ABAC evaluates attributes (user, resource, environment) against policy for fine-grained, context-aware decisions.

Defense in depth layers multiple, diverse, and independent controls across people, process, and technology so that the failure of any one control does not result in compromise. It assumes every control will eventually fail and uses redundancy and variety to slow, detect, and contain an attacker.

Identity lifecycle management governs an account from creation to retirement: provisioning at onboarding (joiner), adjusting entitlements on role change (mover), and timely deprovisioning at exit (leaver), with periodic access reviews throughout. The most common failures are privilege creep on movers and orphaned accounts from missed deprovisioning.

Start from a minimal, trusted base image (distroless or slim) to shrink attack surface, scan images for known CVEs in CI and in the registry, pin and verify image digests, run as a non-root user, and avoid baking in secrets. Sign images and enforce admission policies so only scanned, signed images run. Rebuild regularly so patched base layers flow through.

Encryption in transit (TLS) protects data moving over the network from eavesdropping and tampering; enforce TLS everywhere and reject plaintext. Encryption at rest protects stored data on disks and backups, typically via KMS-managed keys using envelope encryption. Both are baseline controls, but neither stops an authorized-but-malicious request — the service decrypts transparently for valid callers — so access control still matters most.

A user is a long-lived identity with permanent credentials; a role is an identity with no permanent credentials that any trusted principal can assume to get short-lived tokens; a policy is the JSON document that grants permissions, attached to either. Least privilege means preferring roles over users, scoping policies to specific actions and resources, and granting only what a task needs — then reviewing and pruning over time.

IMDS is a link-local endpoint (169.254.169.254) that gives an instance its metadata, including temporary credentials for its attached IAM role. SSRF can trick the server into fetching that URL and leaking those credentials. IMDSv2 requires a PUT to obtain a short-lived session token, sets a default IP TTL/hop limit of 1, and rejects requests with certain headers — so a simple SSRF GET can no longer reach it.

RBAC controls what identities can do against the Kubernetes API — Roles and ClusterRoles grant verbs on resources, bound to subjects via RoleBindings — and should follow least privilege, avoiding cluster-admin and wildcards. Network policies control pod-to-pod traffic, which is allow-all by default until you apply a default-deny and then explicitly permit required flows. Together they limit blast radius if a pod or token is compromised.

The classic mistakes are public ACLs or bucket policies that allow anonymous or all-AWS-users access, overly broad principals or wildcard actions, no default encryption, and no logging. Prevent them by enabling account-level Block Public Access, using IAM/bucket policies with least privilege, enforcing default encryption and TLS, and turning on access logging and Config rules to catch drift.

Store secrets in a dedicated managed service (Secrets Manager, Parameter Store, Vault), encrypted with a KMS key, and grant access through IAM roles so workloads fetch them at runtime with short-lived credentials. Never bake secrets into code, container images, or committed .env files. Add automatic rotation, scoped key policies, and audit logging so every retrieval is traceable.

Security groups are stateful firewalls attached to instances/ENIs: they allow rules only, and return traffic for an allowed flow is automatically permitted. Network ACLs are stateless filters at the subnet boundary: they have ordered allow and deny rules and you must explicitly allow return traffic on ephemeral ports. Security groups are the primary control; NACLs add coarse subnet-level guardrails like blocking an IP range.

The provider secures the cloud itself — physical data centers, hardware, the hypervisor, and the managed services they run. You secure what you put in the cloud — your data, identities, configurations, OS patching where applicable, and access controls. The exact line shifts: with IaaS you own the OS up, with SaaS you mostly own data and access.

RSA is an asymmetric algorithm used to encrypt data or create digital signatures using a key pair. Diffie-Hellman is a key-agreement protocol that lets two parties derive a shared secret over a public channel without ever transmitting it. They solve different problems: RSA proves identity and can wrap keys; DH negotiates a session key — and its ephemeral variant gives forward secrecy.

A digital signature is the hash of a message transformed with the signer's private key. The verifier recomputes the hash, applies the signer's public key, and checks they match. Because only the signer holds the private key, a valid signature proves the message came from them (authenticity), wasn't altered (integrity), and that they can't credibly deny it (non-repudiation).

HMAC is a keyed message authentication code: it hashes the message together with a secret key using a nested construction (inner and outer hash with key-derived pads). It proves both integrity (the message wasn't altered) and authenticity (it came from someone holding the key). A plain hash proves neither, since anyone can recompute it; HMAC also resists length-extension attacks.

A JWT is three base64url parts — header, payload (claims), and signature — joined by dots. The server signs the header and payload with a secret or private key, and verifies that signature on each request to trust the claims without server-side session state. Pitfalls: accepting alg=none, RS256-to-HS256 key confusion, not validating expiry/issuer/audience, putting secrets in the readable payload, and no revocation path.

Kerberos relies on a trusted Key Distribution Center (KDC). The client authenticates once to the Authentication Server and gets a Ticket-Granting Ticket (TGT) encrypted with the KDC's key. To reach a service, it presents the TGT to the Ticket-Granting Service and receives a service ticket encrypted with that service's key. The service decrypts and trusts it. Passwords never traverse the network, and tickets are time-limited.

The app redirects the user to the authorization server to log in and consent. The server redirects back with a short-lived authorization code. The app's backend then exchanges that code (plus its client secret) at the token endpoint for an access token, over a server-to-server back channel. This keeps tokens out of the browser/URL. Public clients add PKCE to bind the code to the original requester.

Store passwords using a deliberately slow, salted, adaptive password-hashing function — bcrypt, scrypt, or Argon2 — never a fast general-purpose hash like SHA-256 or MD5. Fast hashes are built for speed, so attackers with GPUs can test billions of guesses per second against a leaked database. Slow hashes have a tunable work factor (and memory cost) that makes each guess expensive, keeping brute force impractical even after a breach.

Perfect Forward Secrecy (PFS) means each session derives a unique key from an ephemeral key exchange that is thrown away afterward. If an attacker later steals the server's long-term private key, they still cannot decrypt previously captured traffic, because that key was never used to derive the session keys. It's achieved with ephemeral Diffie-Hellman (DHE/ECDHE).

The client builds a chain from the server (leaf) certificate up through one or more intermediate CAs to a root CA in its trust store. It verifies each certificate's signature using the next issuer's public key, checks validity dates, name/hostname match, key usage, and revocation (CRL/OCSP). Trust terminates at a self-signed root that is pre-trusted; the chain is valid only if every link checks out.

A salt is a unique, random value generated per user and combined with the password before hashing. It ensures identical passwords produce different hashes and makes precomputed attacks like rainbow tables useless, since the attacker would need a separate table per salt. Salts are stored alongside the hash. A pepper is an additional secret value, the same for all users, kept separately (e.g., in app config or an HSM) so a database leak alone isn't enough.

SSO centralizes authentication at an Identity Provider (IdP). When a user visits a Service Provider (the app), the app redirects to the IdP; the user logs in once, and the IdP returns a signed assertion or token vouching for their identity. SAML carries this as a signed XML assertion; OIDC carries it as a signed JSON ID token layered on OAuth 2.0. The app trusts the IdP's signature rather than handling passwords itself.

TOTP (Time-based One-Time Password) combines a shared secret, established at enrollment, with the current time divided into fixed windows (usually 30 seconds). It runs HMAC over the time-step counter with the secret, then truncates the result to a 6-digit code. Both the app and server hold the same secret and clock, so they independently compute the same code — no network call needed. The code rotates each window.

Lockfiles pin exact dependency versions and hashes so every build resolves the same, verified bytes — making builds reproducible and blocking silent malicious updates. Pinning by digest, verifying integrity hashes, and scoping internal packages to a private registry also defend against dependency confusion, where an attacker publishes a higher-version public package matching an internal name to hijack resolution. The principle: never let the build silently pull unverified code.

SAST reads source code without running it, finding flaws like injection sinks early but with many false positives. DAST attacks the running app from the outside with no code visibility, finding real exploitable issues but late and with shallow coverage. IAST instruments the running app to correlate runtime behavior with code, getting accurate results with code context, but needs an exercised application and agent support.

Use defense in depth: pre-commit hooks (e.g. gitleaks) catch secrets before they ever land, server-side CI scanning catches what slips past, and periodic full-history scans find old leaks. Critically, a secret that reached a remote repo must be treated as compromised and rotated — deleting the commit doesn't help because it lives in history, forks, and logs. Pair this with a real secrets manager so secrets aren't in code at all.

Treat the pipeline as production infrastructure: it holds the credentials to ship code and reach prod, so compromising it bypasses every downstream control. Harden it with isolated, ephemeral runners; least-privilege, short-lived tokens (OIDC federation instead of long-lived secrets); protected branches and reviewed pipeline config; pinned third-party actions by digest; and full audit logging. The pipeline is a top-tier target, not plumbing.

Break the build only on high-confidence, high-severity, newly introduced findings; warn (don't block) on everything else so developers keep trust in the gate. Manage false positives with tuned rules, baselining of pre-existing issues, and documented, time-boxed, reviewed suppressions rather than disabling scanners. A gate that cries wolf gets ignored or bypassed, so signal quality is the whole game.

Shifting left means moving security earlier — into design, the IDE, and the pull request — where issues are cheaper to fix than in production. You avoid blocking developers by making the secure path the easy path: fast in-context feedback, low-false-positive gates that only hard-fail on high-severity new issues, secure defaults and paved-road templates, and treating security as enablement rather than a late veto.

SCA inventories the open-source and third-party components an application pulls in — including transitive dependencies — and flags those with known CVEs or problematic licenses. It matters because most modern code is dependencies you didn't write, and a single vulnerable transitive package (like Log4j) can expose the whole app. Good SCA prioritizes by reachability and exploitability, not just raw CVE counts.

Client and server agree on a shared secret in a single round trip using ephemeral Diffie-Hellman (ECDHE). The ClientHello carries the supported groups and a key share; the server replies with its key share and certificate, both sides derive the same keys, and application data flows immediately — with forward secrecy by default.

The CIA triad is the three core goals of information security: confidentiality (only authorized parties can read data), integrity (data isn't altered without authorization), and availability (authorized users can access systems when needed). Almost every control maps to one or more of these.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. It assumes no single control is perfect — for example combining a firewall, network segmentation, endpoint protection, MFA, least privilege, and encryption rather than relying on a perimeter alone.

Encoding (like Base64) is a reversible format change with no secret — not security. Encryption is reversible with a key and protects confidentiality. Hashing is a one-way function producing a fixed-length digest, used for integrity checks and password storage, and cannot be reversed back to the input.

An IDS (intrusion detection system) monitors traffic and raises alerts but does not block — it's typically out-of-band. An IPS (intrusion prevention system) sits inline in the traffic path and can actively drop or block malicious traffic. IPS prevents, but a false positive can break legitimate traffic.

Least privilege means every user, process, and service gets only the minimum access required for its task, and nothing more. It limits the blast radius of a compromised account, reduces insider-threat risk, and shrinks the attack surface. You apply it via role-based access, regular access reviews, and just-in-time elevation.

MFA requires two or more authentication factors from different categories — something you know (password), something you have (phone/token), something you are (biometric). It helps because an attacker who steals one factor, like a password, still can't log in without the others. Phishing-resistant MFA like FIDO2 is strongest.

Symmetric encryption uses a single shared secret key for both encryption and decryption and is fast, but both parties must already share the key. Asymmetric uses a public/private key pair, solving the key-distribution problem but more slowly. Real protocols like TLS use asymmetric crypto to exchange a symmetric key, then switch to symmetric for the bulk data.

TCP is connection-oriented and reliable: it uses a three-way handshake, guarantees ordered delivery, and retransmits lost packets. UDP is connectionless and fast with no delivery, ordering, or congestion guarantees. Use TCP for accuracy (web, email, file transfer) and UDP for speed-sensitive traffic (DNS, VoIP, streaming, gaming).

A vulnerability is a weakness (unpatched software). A threat is an actor or event that could exploit it (a ransomware group). Risk is the combination of likelihood that a threat exploits a vulnerability and the impact if it does. Risk = threat x vulnerability x impact, and it's what you actually prioritize.

A firewall controls traffic between network zones by allowing or denying it based on rules. A stateless firewall evaluates each packet in isolation against rules; a stateful firewall tracks the state of connections so it can allow return traffic for sessions it permitted. Next-gen firewalls add application-layer awareness.

Compress first, then encrypt. Good encryption produces output that is statistically indistinguishable from random, so ciphertext has no patterns left to compress — compressing afterward is pointless. The important caveat: compressing secret and attacker-controlled data together before encryption can leak information through ciphertext length, which is exactly the CRIME and BREACH attacks.

No. CORS is not a defense against CSRF — it actually loosens the same-origin policy so a page can read cross-origin responses it otherwise couldn't. CSRF doesn't need to read the response; it just needs the victim's browser to send an authenticated state-changing request. The real defenses are anti-CSRF tokens, the SameSite cookie attribute, and checking Origin/Referer.

Filtered. A filtered port silently drops the packet, so the scanner gets no response and must wait for a timeout — it learns nothing about whether the host even exists, and scanning is slowed dramatically. A closed port sends back a TCP RST, which confirms the host is alive and responding, handing the attacker reconnaissance value for free.

Not on its own. HTTPS prevents MITM only when certificate validation is strictly enforced and the client reaches the site over HTTPS to begin with. If a rogue CA is trusted (corporate proxy, malware-installed root), if the user clicks through cert warnings, or if SSL stripping downgrades the connection to HTTP before TLS starts, an attacker can still sit in the middle.

HTTPS is not a protocol of its own — it is plain HTTP running inside an encrypted TLS tunnel. SSL is the old name: SSL 2.0/3.0 are the deprecated, insecure predecessors of TLS, which superseded them (TLS 1.0 through 1.3). When people say 'SSL certificate' or 'SSL', they almost always actually mean TLS.

Because they are fast. MD5 and SHA-256 are designed for speed, which is exactly wrong for passwords: an attacker who steals the hashes can compute billions of guesses per second on a GPU. The fix is a deliberately slow, memory-hard key-derivation function — bcrypt, scrypt, or Argon2 — combined with a per-user salt and a tunable work factor.

A baseline is a model of normal behaviour for a host, user, account, or network segment — what processes run, who logs in from where and when, typical data volumes, normal beaconing intervals. Once you know normal, anomalies (rare parent-child process pairs, first-seen binaries, logons at odd hours, unusual data egress) become detectable as deviations. Baselining is the foundation of anomaly detection, but it requires enough clean history and careful handling of legitimate change so you do not drown in false positives.

C2 beaconing is the periodic check-in an implant makes to its controller. Hunt for it in network/proxy/DNS telemetry by looking for regularity: connections to a destination at near-fixed intervals (even with jitter), small uniform request sizes, low data-in/data-out ratios, long-lived rare destinations, and suspicious TLS/JA3 fingerprints or odd user-agents. The signal is the rhythm and the rarity of the destination, not the payload — which is usually encrypted.

Start from the techniques you want to detect, then work backwards to the telemetry that reveals them — ATT&CK's data sources mapping helps. In practice the highest-value sources are endpoint process/command-line and module-load telemetry (EDR/Sysmon), authentication and identity logs, DNS and proxy/network flow, and cloud control-plane logs. You then audit what you actually collect and retain versus what each technique needs, exposing visibility gaps. A technique you cannot see in any log is not huntable yet.

Detection engineering treats detections as a software product with a lifecycle: identify a threat or technique to cover, research the telemetry and behaviour, develop the rule, test it against true-positive and benign data, deploy it (often staged), validate with adversary emulation, then continuously tune for false positives and retire rules that no longer earn their keep. Each stage is documented and version-controlled, and coverage is tracked against a framework like ATT&CK.

LOLBins (living-off-the-land binaries) are legitimate, signed, pre-installed system tools — like certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — that attackers abuse to download, execute, or persist while blending in with normal admin activity. Because the binary itself is trusted, you cannot detect on the file; you detect on context: anomalous command-line arguments, unusual parent processes, unexpected network connections from these tools, and execution from odd paths or by odd users.

The Pyramid of Pain ranks indicator types by how costly it is for an attacker to change them once you detect on them. Hashes are trivial to alter (bottom), then IP addresses, domain names, network/host artifacts, tools, and finally TTPs at the top — which an attacker can only change by fundamentally re-tooling their behaviour. Detecting on higher levels causes more 'pain' and is more durable, so mature programs invest detection effort toward behaviours and TTPs rather than just IOCs.

TTP-based hunting uses MITRE ATT&CK as the map: pick a technique relevant to your threat model (ideally one with weak coverage), form a concrete hypothesis about how it would appear in your telemetry, identify the data sources that reveal it, query for it, and analyze hits. A good hunt is scoped, hypothesis-driven, tied to a real adversary behaviour, repeatable, and produces a durable output — a new detection, a documented coverage gap, or evidence the technique is absent — regardless of whether it finds a compromise.

UEBA (User and Entity Behaviour Analytics) builds behavioural baselines for users and entities (hosts, service accounts, devices) and uses statistics or machine learning to score deviations as risk. It excels at threats that have no clean signature: compromised credentials, insider misuse, and lateral movement — e.g. a user suddenly accessing systems they never touch, at unusual hours, or moving abnormal data volumes. It complements rule-based detection rather than replacing it, and needs tuning to avoid false positives from legitimate behaviour change.

Threat hunting is the proactive, hypothesis-driven practice of searching telemetry for adversary activity that existing detections missed. Unlike alert triage — which is reactive and waits for a tool to fire — hunting starts from a question ('if an attacker did X, what evidence would I see?'), tests it against data, and either finds something or produces a new detection. It assumes prevention and alerting are imperfect and that a determined adversary may already be inside.

Sigma is an open, vendor-neutral YAML format for describing SIEM detections. You define a logsource (product/category, e.g. Windows process_creation), a detection block with named selections of field/value matches, and a condition that combines them. A converter (like sigma-cli/pySigma) translates the rule into the query language of your actual backend — Splunk, Sentinel, Elastic — so one rule is portable. It also carries metadata: title, level, status, false positives, and ATT&CK tags.

Access reviews (recertification) are periodic checks where an accountable owner confirms each person's access is still justified, and revokes what isn't. They're the backstop that catches privilege creep, orphaned accounts, and entitlements granted for a project that ended. The control only works if a knowledgeable owner — usually the manager or resource owner — actually scrutinizes access rather than rubber-stamping it, and if revocations are enforced.

Conditional access makes the access decision depend on context rather than a fixed rule. It evaluates signals — who the user is, device compliance, location, the app, and a computed risk score from anomaly detection — and responds proportionally: allow, block, or require step-up like MFA or a compliant device. Risk-based access is the dynamic variant where a real-time risk signal drives the policy.

Just-in-time access grants elevated privileges only when needed, for a limited time, usually with approval — then they expire automatically, so there's no standing privilege to steal. Break-glass accounts are the deliberate exception: highly privileged emergency accounts, normally dormant, locked behind strict controls and heavy alerting, used only when normal access paths fail. JIT shrinks the everyday attack surface; break-glass guarantees you can still get in during a crisis.

Modern NIST SP 800-63B favors length over complexity: allow long passphrases (at least 8, support 64+), accept all characters including spaces, and don't impose composition rules like 'one uppercase, one symbol.' Screen new passwords against known-breached lists, drop mandatory periodic expiration (rotate only on evidence of compromise), and ditch knowledge-based 'security questions.' The aim is rules that resist real attacks instead of just annoying users into predictable patterns.

Phishing-resistant MFA means the second factor can't be replayed against the real site even if the user is tricked. FIDO2/WebAuthn passkeys achieve this with origin-bound public-key cryptography: the authenticator signs a challenge tied to the real site's domain, so a credential captured by a lookalike or attacker-in-the-middle site is useless. TOTP codes and push prompts are still phishable because they can be relayed in real time.

PAM controls and monitors the accounts that can do the most damage — domain admins, root, service accounts. It vaults and rotates their credentials so secrets aren't shared or hardcoded, brokers sessions so admins never see the raw password, records what privileged users do, and ideally grants elevation just-in-time rather than standing access. The goal is to shrink the blast radius of the accounts attackers most want.

RBAC grants permissions through roles assigned to users — simple to reason about but prone to role explosion as edge cases multiply. ABAC evaluates policies over attributes of the user, resource, action, and environment, so it scales to fine-grained, context-aware decisions at the cost of complexity. Most mature systems layer them: roles for coarse grants, attributes and policy for the conditional details.

SCIM (System for Cross-domain Identity Management) is a standard REST/JSON API and schema for creating, updating, and deleting user accounts across applications. Wired to an HR system or IdP, it automates the joiner-mover-leaver lifecycle: accounts and entitlements are provisioned on hire, adjusted on role change, and — most importantly — deprovisioned on departure, eliminating the orphaned accounts attackers love.

Keep access tokens short-lived (minutes) so a stolen one expires fast, and use longer-lived refresh tokens to get new access tokens without re-prompting the user. Rotate refresh tokens on every use and detect reuse of a consumed token as a theft signal, revoking the chain. The goal is to balance limiting the window of a compromised token against not forcing users to re-authenticate constantly.

Zero Trust drops the assumption that being inside the network makes you trusted. Every request to a resource is authenticated and authorized on its own merits — verifying identity, device health, and context — by a policy decision point, granting least-privilege access per session. There is no trusted internal zone; the network location of a request is just one signal, not a free pass.

Coordinated vulnerability disclosure is a process where a researcher reports a flaw privately to the vendor, both sides agree on remediation and a timeline, and details are published only after a fix is available (or an agreed deadline lapses). It balances giving defenders time to patch against the public's right to know. A security.txt file and a clear policy make reporting frictionless; bug bounty programs add structured rewards on top.

ATT&CK is a knowledge base of real adversary tactics (the why), techniques (the how), and procedures. You use it to map your existing detections onto the matrix, identify coverage gaps, and prioritize the techniques used by threat actors that actually target your sector. It gives a common language across CTI, detection engineering, and IR, turning 'are we secure?' into a concrete, measurable coverage map driven by real-world adversary behavior.

A secure SDLC embeds security into every phase rather than testing at the end: requirements (security and abuse cases), design (threat modeling), implementation (secure coding standards, SAST/SCA in the IDE and CI), testing (DAST, pentest), release (gates and sign-off), and operations (monitoring, patching, feedback). Shift-left moves defects earlier where they're cheap to fix; maturity models like OWASP SAMM and BSIMM measure how well you actually do it.

Vulnerability management is a continuous loop: discover assets and vulnerabilities (scanning, asset inventory), prioritize by real risk (CVSS plus exploitability, exposure, and asset criticality — frameworks like EPSS and SSVC help), remediate or mitigate, verify the fix, and report on trends and SLAs. The scan is the easy part; the discipline is prioritizing and closing the loop so risk actually goes down over time.

SSH is TCP 22, HTTP is TCP 80, HTTPS is TCP 443, DNS is 53 (UDP and TCP), RDP is TCP 3389, and SMB is TCP 445. Knowing the well-known ports lets you read scan output, write firewall rules, and triage alerts quickly — a service on its expected port versus an unexpected one is an immediate signal.

A stub resolver asks a recursive resolver for a name. If it isn't cached, the recursive resolver walks the hierarchy: it queries a root server (which points to the TLD), the TLD server (which points to the domain's authoritative servers), and finally the authoritative server, which holds the actual record. The answer is cached along the way per its TTL. DNS uses port 53 — UDP for most queries, TCP for large ones.

A forward proxy sits in front of clients and makes outbound requests on their behalf — used for egress control, filtering, caching, and anonymity. A reverse proxy sits in front of servers and receives inbound requests on their behalf — used for load balancing, TLS termination, caching, and as a security front for a WAF. The direction it faces, client-side or server-side, is the key distinction.

Traceroute discovers the routers between you and a destination by exploiting the TTL field. It sends packets with TTL=1, then 2, then 3, and so on. Each router decrements TTL; when TTL hits zero, that router drops the packet and returns an ICMP Time Exceeded message, revealing its address. By stepping the TTL up, traceroute maps each hop in order until the destination is reached.

NAT (Network Address Translation) rewrites the source and/or destination IP as packets cross a boundary, typically mapping private internal addresses to public ones. PAT (Port Address Translation, or NAT overload) extends this by also translating ports, letting many internal hosts share a single public IP — each flow distinguished by its port. PAT is what home and office routers use to put a whole LAN behind one address.

The OSI model splits networking into seven layers, each adding one responsibility: Physical (bits on the wire), Data Link (frames and MAC addressing), Network (IP routing), Transport (TCP/UDP, ports, reliability), Session (managing connections), Presentation (encoding, encryption, compression), and Application (protocols like HTTP). Each layer wraps the one above it as data goes down the stack.

A subnet is a logical subdivision of an IP network. The subnet mask marks which bits of an IP address are the network portion and which are the host portion — for example, /24 (255.255.255.0) means the first 24 bits identify the network and the last 8 identify hosts. Subnetting controls how traffic is routed and lets you segment a network into smaller broadcast domains.

TCP opens a connection in three steps. The client sends a SYN with an initial sequence number, the server replies with SYN-ACK (acknowledging the client's number and sending its own), and the client returns an ACK. After this exchange both sides have agreed on starting sequence numbers and the connection is established for reliable, ordered byte delivery.

TCP is connection-oriented: it handshakes, numbers bytes, retransmits losses, and controls congestion, giving reliable ordered delivery at the cost of latency and overhead. UDP is connectionless and fire-and-forget — no handshake, no retransmission, no ordering. Use TCP when correctness matters (web, email, file transfer) and UDP when speed matters more than perfection (DNS, VoIP, gaming, video).

The TCP/IP model has four layers — Link, Internet, Transport, and Application — and describes how the real internet works. OSI has seven. They map closely: TCP/IP's Application layer absorbs OSI's Application, Presentation, and Session; its Link layer combines OSI's Physical and Data Link. OSI is the better teaching and troubleshooting reference; TCP/IP is the implemented protocol suite.

A VLAN (Virtual LAN) logically partitions a physical switch into separate Layer 2 broadcast domains, so devices on different VLANs can't reach each other directly even on the same hardware. It's labeled with an 802.1Q tag on trunk links. The security value is segmentation: isolating user, server, guest, and IoT traffic limits broadcast scope and lateral movement, with inter-VLAN traffic forced through a router or firewall where policy is applied.

A VPN creates an encrypted tunnel at the network/OS level, so all of a device's traffic is routed through it and protected end to end — used for secure remote access. A proxy operates at the application level, relaying traffic for specific apps or protocols and not necessarily encrypting it. The big differences are scope (whole-device vs per-application) and that a VPN encrypts by design while many proxies do not.

A DMZ (demilitarized zone) is a network segment that sits between the untrusted internet and the trusted internal network, hosting public-facing services like web, mail, and DNS servers. Firewall rules let the internet reach the DMZ but tightly restrict the DMZ's access to the internal network. The goal is containment: if a public server is compromised, the attacker is stuck in the buffer zone rather than landing inside the LAN.

Start with a full TCP port scan, then enumerate every open service in depth — banners, versions, default creds, anonymous access, and web content — before touching any exploit. Most boxes fall to thorough enumeration, not clever exploits, which is the core of the 'try harder' mindset.

Use the compromised host as a relay into the unreachable subnet. Set up port forwarding for a single service, or a dynamic SOCKS proxy (SSH -D or chisel) and route your tools through it with proxychains, so your attacker box can reach internal hosts via the pivot.

Enumerate current privileges (whoami /priv), misconfigured services (weak permissions, unquoted service paths), AlwaysInstallElevated, scheduled tasks, stored credentials, and missing patches. WinPEAS or PowerUp automates the sweep; token-privilege abuses like SeImpersonate are common high-value wins.

Defense in depth means layering multiple independent security controls so that if one fails, others still protect the asset. No single control is assumed perfect, so you stack preventive, detective, and responsive measures across the network, host, application, and data layers.

Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.

Encryption is reversible — with the key you get the plaintext back; it protects confidentiality. Hashing is a one-way function producing a fixed-size digest you cannot reverse; it verifies integrity and identity. Passwords should be hashed with a slow, salted algorithm like bcrypt or Argon2, never encrypted.

Least privilege means every user, process, or service gets only the minimum access required to do its job, and nothing more. It shrinks the blast radius of any compromise or mistake. You enforce it with role-based access, just-in-time elevation, regular access reviews, and removing standing admin rights.

Never hardcode secrets in source or commit them to git. Store them in a dedicated secrets manager or vault, inject them at runtime, scope access with least privilege, rotate regularly, and prefer short-lived dynamic credentials over long-lived static ones. Audit every access.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Enforce TLS everywhere, authenticate every request (e.g. OAuth2/OIDC tokens), and authorize per-object so users can only reach their own data. Add input validation, rate limiting and quotas, schema validation, and thorough logging. The most common API flaw is broken object-level authorization, so check ownership on every resource access.

Segmentation divides a network into isolated zones so a breach in one can't freely reach others, limiting lateral movement. Zero trust goes further: it removes implicit trust based on network location entirely, authenticating and authorizing every request regardless of where it originates — microsegmentation is one way to implement it.

Symmetric encryption uses one shared key for both encrypt and decrypt — it's fast but the key must be shared securely. Asymmetric encryption uses a public/private key pair, solving key distribution but slowly. Real systems use asymmetric crypto to exchange a symmetric session key, then use the fast symmetric cipher for bulk data.

A PKI is the system of CAs, certificates, and policies that binds public keys to identities. To validate a server cert a client builds a chain to a trusted root, verifies each signature, checks validity dates and the hostname, confirms key usage, and checks revocation via CRL or OCSP.

Alert fatigue is the desensitization that sets in when analysts face too many low-value or false-positive alerts, causing them to miss or rush real ones. You fight it by tuning noisy rules, prioritizing by risk, deduplicating and grouping related alerts, automating repetitive enrichment with SOAR, and measuring alert quality, not just volume.

Almost everything touches DNS, so DNS logs reveal threats other sources miss: command-and-control beaconing (regular callbacks to a domain), DNS tunneling and exfiltration (high volume of long, encoded subdomains), and algorithmically generated (DGA) domains. You detect these through patterns like query regularity, entropy, record types, and volume rather than single bad lookups.

EDR is endpoint-focused: it records and responds to process, file, and network activity on hosts. XDR extends that correlation across multiple domains — endpoint, network, identity, email, cloud — as one vendor-integrated stack. SIEM is the broad log-aggregation layer that ingests data from anything, including non-security sources, for detection, search, and compliance.

First understand why the rule is firing so much — find the common benign pattern behind the noise. Then write the narrowest possible exclusion (specific host, account, or behavior), document the rationale, and validate that a true positive would still fire. Avoid broad suppressions that quietly create blind spots.

ATT&CK is a knowledge base of real-world adversary tactics and techniques. In a SOC you map each detection rule to the techniques it covers, build a coverage map (often with the ATT&CK Navigator), then prioritize closing gaps based on which techniques are most relevant to your threat model and which you have no visibility into.

A SIEM ingests and correlates logs from across the estate to generate alerts — it is your detection and search layer. A SOAR sits downstream and automates the response: it runs playbooks, enriches alerts via integrations, and handles case management so analysts spend less time on repetitive steps.

Content-Security-Policy is an HTTP response header that tells the browser which sources of scripts, styles, images, and other content are allowed to load and execute on a page. By disallowing inline script and untrusted origins — ideally via nonces or hashes — it acts as a defense-in-depth backstop that neutralizes injected XSS payloads even when one slips through.

CSRF tricks a logged-in user's browser into sending a state-changing request to a site where they are authenticated, abusing the fact that cookies are sent automatically. It is stopped with anti-CSRF tokens (a secret per-session value the attacker cannot read or guess) and the SameSite cookie attribute, which stops cookies from riding along on cross-site requests.

The OWASP Top 10 is a community-driven awareness document that ranks the most critical web application security risks, refreshed every few years from real-world data. It is not a checklist or standard but a starting point — recent entries include Broken Access Control (#1), Cryptographic Failures, Injection, and Insecure Design.

Never store passwords in plaintext or reversibly encrypted, and never with fast general-purpose hashes like MD5 or SHA-256. Use a slow, memory-hard password hashing function — Argon2id (preferred) or bcrypt — with a unique random salt per password and a tuned work factor, so an attacker who steals the database cannot feasibly crack the hashes.

Prepared statements send the query template to the database first, with placeholders, so the structure is fixed before any user data arrives. Parameters are then bound as pure data and can never be parsed as SQL — so input like ' OR 1=1 is treated as a literal string, not code. This separation is the canonical, reliable fix for injection.

The primary defense is contextual output encoding — encode untrusted data for the exact place it lands (HTML body, attribute, JavaScript, URL). Pair that with safe DOM APIs (textContent over innerHTML), framework auto-escaping, input validation, and a Content-Security-Policy as a defense-in-depth backstop that limits what scripts can run.

The Same-Origin Policy is the browser rule that script from one origin (scheme + host + port) cannot read responses from a different origin, which protects authenticated sessions. CORS is a controlled relaxation: a server returns Access-Control-Allow-Origin headers to explicitly opt in to letting specific origins read its responses, so it loosens SOP rather than bypassing it.

HttpOnly hides the cookie from JavaScript so XSS cannot steal it via document.cookie. Secure ensures the cookie is only sent over HTTPS, blocking network interception. SameSite controls whether the cookie is sent on cross-site requests, mitigating CSRF. Together they harden session cookies against the most common theft and abuse paths.

Key security headers include Strict-Transport-Security (forces HTTPS, blocks SSL stripping), Content-Security-Policy (limits script sources, mitigates XSS), X-Frame-Options or CSP frame-ancestors (blocks clickjacking), X-Content-Type-Options: nosniff (stops MIME sniffing), and Referrer-Policy (controls referrer leakage). Each addresses a specific attack class.

SQL injection lets attacker input alter a query. In-band techniques return data directly: union-based appends a UNION SELECT to pull extra columns, and error-based leaks data through database error messages. When no output is visible, attackers use blind SQLi — boolean-based infers data from true/false response differences, and time-based uses delays like SLEEP() to read data one bit at a time.

HTTP is stateless — each request is independent and carries no memory of prior ones. Sessions add state on top: after login, the server issues an identifier the browser stores in a cookie and replays on every request. Server-side sessions keep the state on the server keyed by an opaque session ID; stateless tokens like JWTs put signed state in the token itself so the server can verify without storage.

All XSS injects attacker-controlled script into a victim's browser. Stored XSS persists the payload on the server (e.g. a comment) and hits everyone who views it; reflected XSS bounces the payload off the server in a single response, usually via a crafted link; DOM-based XSS never reaches the server logic — vulnerable client-side JavaScript writes untrusted input into the page.

XXE abuses an XML parser that resolves external entities defined in a document's DTD. An attacker declares an entity pointing at a local file or internal URL, and the parser fetches it — enabling file disclosure, SSRF, and denial of service. The fix is to disable DTD processing and external entity resolution in the parser configuration.