Cybersecurity Engineer Top 100 Interview Questions

Forward secrecy means that stealing a server's long-term private key later does not let an attacker decrypt traffic recorded earlier. Each session uses fresh, temporary keys that are discarded after use.

Why it matters:

• Record now, decrypt later: an attacker can capture encrypted traffic for years and wait for a key leak, a court order or future computing advances.
• Limits breach impact: a compromised server key exposes only sessions made while the attacker holds it.

Ways forward secrecy is weakened in practice:

• Session resumption tickets are encrypted with a server key; if that key is never rotated, stealing it exposes resumed sessions.
• Long-lived pre-shared keys used without an ephemeral exchange give no forward secrecy.

Rotate ticket keys frequently and keep ephemeral key exchange enabled for every connection.

Authenticated encryption protects both confidentiality and integrity in one step: it encrypts the data and adds a tag that fails to verify if a single bit is changed. Older modes only hide data, which leaves room for tampering and padding attacks.

Rules for using authenticated encryption safely:

• Never reuse a nonce with the same key. For GCM this can reveal the authentication key and allow forgeries.
• Check the tag before using any decrypted data, and treat a failed check as an attack, not a glitch.
• Use associated data for values such as headers or record IDs that must be authenticated but stay readable.

Prefer a well-reviewed library's high-level "encrypt" interface over assembling modes yourself.

Envelope encryption encrypts data with a data key, then encrypts that data key with a key-encryption key held in a key management service or hardware security module. The bulk data never travels to the key service, and the master key never leaves it.

1. Encrypt: generate a fresh data key, encrypt the data locally with it, ask the key service to encrypt (wrap) the data key, and store the wrapped key next to the data.
2. Decrypt: send the wrapped key to the key service, receive the plaintext data key, decrypt locally, then discard the plaintext key from memory.
3. Control: the key service checks permissions and logs every unwrap request.

flowchart LR
  A["Plaintext data"] -->|encrypt with| B["Data key"]
  B -->|wrapped by| C["Key-encryption key in key service"]
  A --> D["Ciphertext"]
  B --> E["Wrapped data key"]
  D --> F["Stored together"]
  E --> F

How rotation works:

• Rotating the key-encryption key creates a new version; new data keys are wrapped with it, and old versions stay available for decryption only.
• To retire an old version, rewrap the stored data keys: a few hundred bytes each, not the data itself.
• Rotating data keys means re-encrypting data, so it is done when data is rewritten or after a suspected compromise.

Tokens, keys, salts and password-reset links are only safe if attackers cannot predict them. General-purpose random number generators are designed for statistics and simulations, not secrecy, so their output can be predicted.

Why ordinary generators fail:

• Guessable seeds: many are seeded from the current time or a process ID, which an attacker can narrow down to a small range.
• Recoverable state: for common generators, observing enough outputs lets an attacker rebuild the internal state and compute every future value.
• Reproducibility is a feature for simulations but a disaster for secrets.

What to use instead:

• The operating system's cryptographically secure generator, exposed in most languages as a dedicated "secrets" or "secure random" module.
• At least 128 bits of randomness for session IDs and reset tokens; 256 bits is common for keys.
• Encode tokens in a URL-safe format and compare them in constant time.

A predictable reset token turns "forgot password" into "take over any account". This is one of the easiest mistakes to avoid with the right library call.

Estimate the number of possible passwords, then divide by how fast the attacker can test guesses.

• keyspace = charset_size ^ length
• average_time = keyspace / 2 / guesses_per_second
• entropy_bits = length × log2(charset_size)

What each term means:

• charset_size: how many characters each position can take, such as 26 for lowercase letters or 95 for all printable characters.
• length: the number of characters.
• guesses_per_second: depends on the attack. An online attack against a login page might manage a few guesses per second before rate limits apply; an offline attack on a stolen fast hash can reach billions per second on graphics cards.
• On average the right password is found after searching half the keyspace.

When to use it: to compare password policies and to show why slow password hashing matters. Length grows the keyspace far faster than adding character types.

The formula assumes random passwords. Human-chosen passwords fall to dictionary and pattern attacks long before the full keyspace is searched, so real-world times are much shorter.

Attacks happen at every layer of the network stack, and each layer needs defenses that can see that layer. A firewall that only reads addresses and ports cannot stop an injection attack hidden in a valid web request.

Why the layer matters:

• Placement: a control must sit where it can inspect the attack. Application attacks need application-aware controls, and encrypted traffic must be inspected where it is decrypted.
• Blind spots: encryption protects against eavesdropping but also hides attacks from network sensors, so endpoint and application logs become more important.
• Defense in depth: most real intrusions cross several layers, from a phishing email at the application layer to lateral movement across the internal network.

They differ in how much context they use to decide. A packet filter judges each packet alone, a stateful firewall tracks connections, and an application-layer firewall understands the protocol content itself.

When to use which:

• Stateless filters suit high-volume edges and simple network rules, such as cloud network access lists.
• Stateful firewalls are the default between network zones.
• Application-layer firewalls fit where user and application identity matter, such as controlling outbound web access.
• A web application firewall adds a shield in front of web apps, but it never replaces fixing the application's own flaws.

An intrusion detection system watches a copy of the traffic and raises alerts; an intrusion prevention system sits in the traffic path and can block what it detects. Both use the same detection logic, but their placement changes the risk they carry.

How they detect:

• Signature-based: matches known attack patterns. Precise, but blind to new attacks.
• Anomaly-based: learns a baseline and flags deviations. Finds new behavior but produces more false positives.

When to use which: start new rules in detection mode, measure their false positive rate, and switch only the precise, high-confidence rules to blocking. Decide in advance whether an inline device should fail open, keeping traffic flowing, or fail closed, keeping protection.

Segmentation divides a network into zones with controlled paths between them, so an attacker who compromises one system cannot reach everything else. A DMZ is a zone for internet-facing services, placed between the internet and the internal network.

flowchart LR
  A["Internet"] --> B["Edge firewall"]
  B --> C["DMZ: reverse proxy and web servers"]
  C --> D["Internal firewall"]
  D --> E["Application tier"]
  E --> F["Database tier"]
  G["Admin network"] -->|managed access only| E

How segmentation limits an attacker:

• Contains the breach: a compromised web server in the DMZ can reach only the application ports it needs, not the databases or staff laptops.
• Forces detection points: traffic between zones crosses firewalls that log and alert.
• Protects the crown jewels: the most sensitive systems sit in the most restricted zones.

Good practice:

• Default-deny between zones and allow only named flows, such as "proxy to app on port 8443".
• Segment by function and sensitivity, and keep management interfaces on a separate network.
• Microsegmentation applies the same idea per workload, often with host-level or cloud security rules, and limits lateral movement even inside one zone.

On a local network, devices use the address resolution protocol to map IP addresses to hardware addresses, and the protocol has no authentication. An attacker sends forged replies claiming the gateway's IP address, so victims send their traffic through the attacker's machine.

1. The attacker tells the victim "the gateway's IP is at my hardware address", and tells the gateway the same about the victim.
2. Both update their caches and send traffic to the attacker.
3. The attacker forwards the traffic on, so nothing seems broken, while reading or altering anything that is not encrypted.

sequenceDiagram
  participant V as Victim
  participant A as Attacker
  participant G as Gateway
  A->>V: Forged reply, gateway is at attacker address
  A->>G: Forged reply, victim is at attacker address
  V->>A: Traffic meant for the gateway
  A->>G: Forwarded traffic, read or altered

Prevention and detection:

• Switch-level inspection that checks replies against a table of known address bindings, built from address assignment records.
• Port security that limits which hardware addresses each switch port can use.
• Encryption everywhere: with TLS and certificate validation, intercepted traffic is unreadable and tampering is detected.
• Monitoring for sudden changes in the hardware address behind the gateway's IP address.

DNS translates names to addresses, so whoever controls the answers can send users anywhere. Attacks either forge or redirect answers, abuse DNS as a hidden channel, or use it to amplify floods.

Operational practices:

• Force internal devices to use your own resolvers, and block direct outbound DNS to the internet. This makes tunneling and malware lookups visible.
• Log DNS queries centrally; they are one of the cheapest and richest detection sources.
• Use encrypted DNS between clients and resolvers where privacy matters, while keeping visibility on the resolver.

They exhaust different resources. Volumetric attacks fill the network pipe, protocol attacks exhaust connection state in servers and firewalls, and application-layer attacks make the application do expensive work.

How to prepare:

1. Know your normal baseline of traffic, so an attack is recognized quickly.
2. Put internet-facing services behind a provider with enough capacity to absorb volumetric floods.
3. Make expensive endpoints cheap to defend: cache results, require authentication and add per-client limits.
4. Write a runbook with provider contacts and pre-approved emergency rules.
5. Cap autoscaling, because unlimited scaling turns a denial-of-service attack into a denial-of-wallet attack.

Application-layer attacks are the hardest to filter because each request looks valid. Defending them depends on understanding what normal users actually do.

A port scan probes a host's ports to find which ones accept connections. From that, an attacker or defender learns which services are exposed, often their versions, and sometimes the operating system, which points to likely vulnerabilities.

Other scan types: UDP scans are slow because closed ports often send nothing back. Version detection connects to services and reads their banners.

Defensive view:

• Scan your own address ranges regularly and compare results with what should be exposed. Unexpected open ports are findings in themselves.
• Detect scans by looking for one source touching many ports or many hosts in a short time.
• Do not rely on hiding services on unusual ports; scanners find them in seconds.

Any protocol that sends credentials or data unencrypted can be read or altered by someone on the network path. Replace each with its encrypted equivalent, including on internal networks, because attackers who get inside listen there too.

When replacing them:

• Turn off the old protocol after migrating; leaving both enabled keeps the weakness.
• Validate certificates. Encryption without validation still allows a man-in-the-middle attack.
• Disable outdated versions of the secure protocols too, such as early TLS and SSL versions.
• Find remaining plaintext use by watching network flows for the old ports before switching them off.

A site-to-site VPN joins two networks, such as an office and a data center, through a permanent encrypted tunnel between gateways. A remote-access VPN connects one user's device to a network, using client software and user authentication.

Security points:

• A VPN usually grants access to a whole network, so a stolen VPN login can expose a lot. Limit what VPN users can reach.
• Split tunneling sends only corporate traffic through the VPN; it improves speed but means the device is directly on the internet at the same time.
• Patch VPN gateways quickly. As internet-facing devices that hold credentials, they are frequent targets.

Many organizations now replace remote-access VPNs with per-application access proxies, in line with zero trust.

Secure corporate wireless with per-user or per-device authentication instead of a shared password, the strongest current wireless encryption, and strict separation between staff, guest and device networks.

1. Use enterprise authentication: each user or device proves its identity, ideally with a device certificate, against a central authentication server. Leaving staff means revoking one identity, not changing a password for everyone.
2. Enable the latest wireless security protocol with protected management frames, and disable older encryption standards that can be cracked.
3. Separate networks: guests get internet-only access with client isolation; printers and building systems go on their own restricted segment.
4. Check device health on connection and place devices in the right segment automatically.
5. Detect rogue and look-alike access points with wireless monitoring, since an attacker's "evil twin" network with the same name is a common trick.
6. Treat wireless as untrusted: require the same authentication and encryption for internal apps as for remote users.

Physical placement matters too. Tune signal strength so the network does not reach the car park, which is where attackers would sit.

Detect exfiltration by comparing outbound traffic with each system's normal behavior, and by watching the channels attackers favor to hide data. Volume alone is not enough, because careful attackers move data slowly.

Where the data comes from:

• Network flow records for volumes and destinations.
• Proxy and DNS logs for domains and query patterns.
• Endpoint telemetry to tie a connection to a specific process and user.
• Data loss prevention tools for content-aware rules on known sensitive data.

The strongest position combines detection with egress filtering: if servers can reach only a short list of approved destinations, most exfiltration paths are closed before they need detecting.

Egress filtering controls which outbound connections are allowed to leave a network. Most networks filter inbound traffic carefully but let anything out, which is exactly what malware and data thieves rely on.

Why it gets neglected:

• Outbound rules break things visibly when they are wrong, while open egress fails silently.
• Applications often call many external services, and nobody keeps a list.
• The risk is less obvious than an open inbound port.

What it stops:

• Command-and-control: malware cannot call home to receive instructions.
• Exfiltration: stolen data has fewer ways out.
• Payload downloads: a first-stage infection cannot fetch its tools.
• Server-side request forgery impact: a tricked server cannot reach arbitrary destinations.

How to roll it out:

1. Log outbound flows for a few weeks to learn what each server genuinely needs.
2. Route web traffic from servers through a proxy with an allowlist of domains.
3. Allow DNS only to internal resolvers, and block direct outbound connections on other ports.
4. Default-deny, then alert on denied attempts, which often reveal compromised hosts.

Interview tip: when asked about network defense, mention egress control alongside inbound firewalls; candidates often forget that most attacks need to get data or signals out.

Parse the address and the ranges with a real IP address library, then test membership. Comparing strings, such as checking whether an address starts with "10.2", is a classic bug: it also matches 10.200.0.1.

Key points:

• Parse, do not pattern-match: a proper parser understands prefix lengths and rejects malformed input such as 300.1.1.1.
• Fail closed: anything that does not parse as a single address is denied, including ranges and extra characters.
• Handle IPv6: keep IPv6 ranges in the list, and unwrap IPv4-mapped IPv6 addresses such as ::ffff:10.20.1.1, which some servers report for IPv4 clients.
• Trust the right source: behind a load balancer, read the client address only from a header your own proxy sets, because clients can forge forwarding headers.
• Keep the list in configuration, so changing it does not need a code release.

Allowlists by IP address are a useful extra layer for admin tools, but they are not authentication. Addresses can be shared, reassigned or spoofed on some networks.

Treat it as a possible compromise, but confirm before acting: establish what the traffic is, which process sends it, and whether it is legitimate, then contain quickly if it is not.

1. Scope the traffic: from flow logs, get the destination, ports, volume, timing and how long it has been happening.
2. Enrich the destination: check its domain, registration age, reputation and whether other hosts talk to it.
3. Find the process: use endpoint telemetry to identify the program, its parent, its file hash, its signer and how it starts.
4. Decide: match it against known jobs such as backups, updates or monitoring agents, and confirm with the system owner.
5. Contain if suspicious: isolate the host from the network while keeping it powered on to preserve memory, and block the destination at the egress firewall.
6. Investigate scope: look for the same indicators on other hosts, find the initial entry point and check for persistence.

flowchart TD
  A["Unexpected outbound traffic"] --> B["Scope with flow logs"]
  B --> C["Identify the sending process"]
  C --> D{"Known and approved?"}
  D -->|yes| E["Document and tune the alert"]
  D -->|no| F["Isolate host and block destination"]
  F --> G["Hunt for the same indicators elsewhere"]
  G --> H["Eradicate, recover, review"]

Trade-offs:

• Isolating immediately limits damage but warns the attacker; watching longer reveals more but risks more data loss.
• Rebooting or reimaging destroys memory evidence, so capture it first when the stakes justify it.