Security Architect interview questions

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. Cloud runs on a shared responsibility model: the provider secures the underlying infrastructure ('security of the cloud'), but you remain responsible for your data, identity and access management, configuration, and — for IaaS — the OS and patching ('security in the cloud'). The large majority of cloud breaches are customer-side misconfigurations like public buckets and over-permissive IAM, not provider failures. Assuming the provider secures your data is how those breaches happen.

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.

Unbounded autonomy plus tool access is OWASP LLM 'excessive agency': a manipulated or mistaken model can take destructive actions. Constrain it with least-privilege tool scopes, require human confirmation for irreversible operations, and keep permissions narrow and audited. Trusting it or granting admin widens the blast radius, and hiding a UI button does nothing about the model's underlying capability to call the action.

Untrusted content the model ingests can carry instructions — indirect prompt injection. You can't fully prevent the model from being influenced, so isolate fetched content as data, constrain what tools/permissions the agent has, require confirmation for sensitive actions, and avoid giving it secrets it could be coerced into leaking. Assuming the model will simply ignore injected instructions is exactly the failure mode being exploited.

Sending customer PII to an external API exposes it to a third party's processing and retention and can breach privacy obligations. Minimize and redact what's sent, confirm the provider's data-use/retention terms and a data-processing agreement (or no-training guarantees), or move to a private deployment for sensitive data. Key length is irrelevant, and sending more PII increases the exposure.

If retrieval pulls any indexed document regardless of who's asking, the model will faithfully surface data the user shouldn't see — this is an authorization flaw, not hallucination. Enforce the user's document-level permissions at retrieval time so only authorized chunks enter the context. A bigger system prompt is bypassable and doesn't implement access control, temperature is unrelated, and another model has the same gap.

Training on unvetted user data lets an attacker poison the model — implanting backdoors, triggers, or skewed behavior that surfaces later. Control it with data vetting and filtering, provenance tracking, anomaly detection on the dataset, and evaluation of model behavior after training. 'More data is better' ignores integrity, and the real concern is poisoning, not speed or disk space.

Inconsistent handling usually means there's no shared definition of sensitivity, so the foundational control is a data classification scheme (e.g., public/internal/confidential/restricted) with defined handling, storage, and sharing requirements per level, letting teams apply proportionate controls. Encrypting nothing 'to keep things simple' or treating all data as public strips protection from data that needs it. Deleting all data older than a day destroys records the business and the law require. Only a classification scheme aligns the strength of controls to the actual sensitivity of the data.

PCI DSS scope covers systems that store, process, or transmit cardholder data plus anything connected to or able to affect them, so effective network segmentation isolates the cardholder data environment (CDE) and removes unrelated systems from scope, shrinking cost, effort, and risk. Encrypting every server doesn't define a boundary and connected systems stay in scope; adding untargeted firewalls everywhere isn't segmentation if it doesn't restrict and validate the data flows; and stopping people reading card numbers aloud is hygiene, not a scoping control. The systemic answer is to control where cardholder data lives and what can reach it.

A SOC 2 report only assures you if you actually read it: confirm it's the right type (Type II tests operating effectiveness over time, Type I only design at a point), check the scope and which Trust Services Criteria it covers, that the period is current and has no gap, what opinion the auditor gave (unqualified vs qualified), and review the noted exceptions plus the complementary user-entity controls (CUECs) you're responsible for. Merely confirming the report exists — or judging it by its cover logo or page count — tells you nothing about the vendor's actual control effectiveness or your residual obligations.

Prompt injection can't be fully solved with more prompt text; assume the model can be subverted and constrain what it's allowed to DO. Give tools least privilege, gate high-impact actions behind human confirmation, and validate or sandbox tool calls before acting (OWASP LLM 'excessive agency' and 'improper output handling'). System-prompt pleading is bypassable. Higher temperature only adds randomness, and logging alone records the damage without preventing the injected action.

Balance usability and risk: enforce conditional access tied to device posture and isolate corporate data in a managed container (MAM/MDM) so it can be controlled and selectively wiped without taking over a personal device. Unrestricted access risks leakage on unmanaged, possibly compromised endpoints. An outright ban pushes people to insecure workarounds like forwarding data to personal email. And emailing attachments scatters sensitive data uncontrollably across devices you can never reclaim.

No single product stops every attack, so mature security layers independent controls — defense-in-depth — so the failure of one does not mean compromise. Map the proposed spend to the actual gaps across identity, network, endpoint, data and detection, and keep the complementary controls already working. Betting everything on one tool creates a single point of failure, and ripping out existing controls to replace them reduces coverage. Declining to spend at all ignores real gaps.

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.

Threat modeling is cheapest and most effective at design time, before code locks in decisions: walk the data flows, enumerate threats with a framework like STRIDE, and bake in mitigations, then revisit as the design evolves. Doing it only post-incident or at the annual pentest finds problems after they are expensive to fix and already exposed. And relying on 'careful developers' is a hope, not a repeatable, auditable control.

Sending PII to a third party extends your trust boundary, so first run a vendor security assessment — data handling, encryption, access controls, certifications like SOC 2 / ISO 27001, sub-processors, breach-notification terms — and put a data-processing agreement (DPA) in place before any PII flows. A pricing contract or a sales rep's verbal word is not due diligence. And a 'polished website' tells you nothing about how the vendor actually protects data; you remain accountable for it.

Network-location trust means a single foothold inside grants broad lateral access — one phished VPN credential and the attacker is 'inside.' Zero trust removes implicit trust: every access is authenticated, authorized, and continuously evaluated on identity and device posture, with least privilege and segmentation (NIST SP 800-207). A second VPN or a wider VPN just extends the same flat-trust problem to more places, and trusting the LAN instead of the VPN repeats the original mistake.

When you can't remediate, you manage the risk: reduce exposure with compensating controls (network segmentation, tightened access, enhanced monitoring), quantify the residual risk, and have the accountable business owner formally accept it with a defined review date. Unilateral shutdown oversteps the CISO's authority and harms the business. Ignoring it because it can't be fixed is negligence. Omitting it from the risk register hides accountability, breaks audit trails, and means no one is on record owning the decision.

An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.

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.

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.

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.

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.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Classification labels data by sensitivity so the organization applies controls proportional to value and risk, avoiding both under-protection and wasteful over-protection. The data owner (a business role) sets the classification and accepts risk, while the data custodian (often IT) implements and maintains the protective controls.

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.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

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.

A policy is the high-level mandatory statement of management intent; a standard is a mandatory specific rule that enforces policy (e.g. AES-256); a procedure is the mandatory step-by-step how-to; a guideline is an optional recommendation. Policies, standards, and procedures are mandatory, while guidelines are discretionary.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

You can mitigate (reduce likelihood/impact with controls), transfer (shift the financial impact via insurance or contracts), avoid (stop the risky activity entirely), or accept (knowingly tolerate the residual risk). The choice depends on risk appetite and a cost-benefit comparison against the risk's expected loss.

Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.

CI/CD is high-value because it holds deploy credentials and runs untrusted code. Risks include compromised dependencies and build actions, leaked or over-broad secrets, mutable third-party actions, and over-privileged runners or OIDC trust. Reduce them with pinned and verified dependencies, short-lived OIDC federation instead of long-lived keys, least-privilege scoped to specific repos/branches, isolated ephemeral runners, and signed, provenance-tracked artifacts (SLSA).

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.

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.

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.

Controls are classified two ways. By type: administrative (policies, training, procedures), technical/logical (firewalls, MFA, encryption), and physical (locks, badges, cameras). By function: preventive (stop an event — MFA, access control), detective (find an event — SIEM, IDS, audit logs), corrective (fix after — restore from backup, patch), deterrent (discourage — warning banners), and compensating (an alternative when the primary control isn't feasible). Defence in depth layers these so no single control failure leads to compromise.

GDPR Article 5 sets seven principles: lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. For a personal data breach, the controller must notify the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware (Article 33). If the breach is likely to result in a high risk to individuals, the controller must also notify the affected data subjects without undue delay (Article 34).

Governance is how leadership sets direction, defines accountability, and aligns security with business objectives — the policies, roles, and oversight that say what 'good' looks like. Risk management is the process of identifying, assessing, treating, and monitoring threats to those objectives. Compliance is demonstrating adherence to obligations — laws, regulations, contracts, and internal policy. Governance drives risk decisions; risk informs which controls you need; compliance evidences that those controls meet required standards. Compliance is an outcome of good GRC, not a substitute for security.

HIPAA (the US Health Insurance Portability and Accountability Act) protects Protected Health Information (PHI). The Privacy Rule governs use and disclosure of PHI; the Security Rule applies to electronic PHI (ePHI) and requires three categories of safeguards — administrative, physical, and technical. It applies to covered entities (providers, health plans, clearinghouses) and to business associates that handle PHI on their behalf, bound by Business Associate Agreements. The Breach Notification Rule sets obligations to notify individuals, HHS, and sometimes the media.

ISO/IEC 27001 specifies the requirements for an Information Security Management System (ISMS): a risk-based, top-down framework of policies, processes, roles, and continual improvement (Plan-Do-Check-Act) governing how an organisation manages information security. Annex A is a reference catalogue of controls. You don't apply them all blindly — you run a risk assessment, decide which controls are needed, and document the include/exclude decisions with justification in a Statement of Applicability (SoA).

The NIST Cybersecurity Framework organises cybersecurity outcomes into core functions. In CSF 2.0 there are six: Govern (the new overarching function for strategy, roles, risk decisions, and oversight), Identify (understand assets and risks), Protect (safeguards to limit impact), Detect (find events), Respond (act on incidents), and Recover (restore capabilities). They are not strictly sequential — they run continuously and together describe a full lifecycle of managing cyber risk.

PCI DSS (Payment Card Industry Data Security Standard) is a security standard maintained by the PCI Security Standards Council that applies to any organisation that stores, processes, or transmits cardholder data. It is organised around control objectives covering a secure network, protection of stored cardholder data, vulnerability management, strong access control, monitoring/testing, and an information security policy. Scope is everything in the cardholder data environment (CDE) — so segmentation, tokenisation, and not storing data you don't need are the main ways to shrink scope.

Treat awareness as behaviour change, not an annual checkbox. Make it role-based (a developer needs different content than finance), continuous rather than a once-a-year slideshow, and grounded in real risks like phishing, social engineering, and data handling. Reinforce it with phishing simulations, just-in-time nudges, and clear reporting channels. Measure outcomes — phishing report rates, click rates, time-to-report — not just completion percentages. Build a culture where people report mistakes without fear, because fear suppresses reporting.

A KPI (Key Performance Indicator) measures how well a security activity is performing against its objective — for example mean time to detect, patch SLA compliance, or percentage of systems with MFA. A KRI (Key Risk Indicator) is a forward-looking signal that risk exposure is increasing toward an unacceptable level, with a threshold that should trigger action — for example the number of overdue critical patches, count of unmanaged devices, or failed access reviews trending up. KPIs tell you how you're doing; KRIs warn you about where you're heading.

A SOC 2 Type I report assesses whether a service organisation's controls are suitably designed at a single point in time. A Type II report goes further: it tests whether those controls operated effectively over a review period, typically 3 to 12 months. Both are based on the AICPA Trust Services Criteria — Security (the required common criteria), plus optional Availability, Processing Integrity, Confidentiality, and Privacy.

Treat vendor risk as a lifecycle, not a one-off questionnaire. Inventory your third parties and tier them by criticality and data sensitivity. Run due diligence proportional to tier — review SOC 2 / ISO 27001 reports, security questionnaires, pen-test summaries, and the data and access involved. Bake controls into the contract (security requirements, right to audit, breach notification, data handling, subprocessors). Then monitor continuously, not just at onboarding, and have a clean offboarding process to revoke access and recover or destroy data. Fourth-party (subprocessor) risk matters too.

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.

Identity federation establishes trust between an identity provider (IdP) that authenticates users and service providers (relying parties) that consume that authentication. The IdP verifies the user and issues a signed assertion or token; the service provider trusts it instead of managing its own credentials. This enables cross-domain SSO and centralized control, but concentrates risk: compromise the IdP and you compromise everything that trusts it.

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.

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.

Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.