Cyber Security Engineer Interview Questions

The first thing I do is establish a timeline. If I have an EDR alert or a SIEM correlation that triggered the suspicion, I anchor on the timestamp and affected host. From there I pull NetFlow or firewall logs first, not full packet capture, because NetFlow is retention-friendly and gives me the connection graph: which hosts the suspected host communicated with, on which ports, and how much data moved. I am looking for patterns inconsistent with normal behavior: a workstation making SMB connections to 20 other workstations it has never talked to, which is likely Pass-the-Hash or SMB worm propagation; LDAP or Kerberos queries to a domain controller at unusual times or volume, suggesting credential enumeration; connections to internal hosts on ports like WinRM 5985 or RDP 3389 from a non-admin source. Once I have a set of suspicious host pairs from NetFlow, I check whether I have full packet capture for those flows. If SPAN or TAP data is available via a tool like Zeek or Wireshark, I reconstruct the sessions. For SMB lateral movement I look at SMB command sequences in the capture: do I see net use, PsExec patterns, or IPC$ share access? For command-and-control that has gone internal, I look at beaconing: regular intervals of small outbound connections. Zeek's conn.log is excellent for this because it gives per-connection duration and byte counts, making periodic beaconing stand out. I also correlate DNS logs: lateral movement tools often query internal hostnames they should not know about. If I find a compromised host, I image it before isolating it when possible, because isolation can trigger attackers to destroy evidence.

The OWASP Top 10 is a consensus list of the most critical web application risk categories. The ones I think are most dangerous in practice are injection, particularly SQL injection, because a single unsanitized parameter can dump an entire database; broken access control, because it is pervasive and often lets any authenticated user reach any other user's data just by changing an ID; and cryptographic failures, because misconfigured TLS or weak password hashing silently exposes data at rest and in transit. Security misconfigurations and vulnerable dependencies round out the top of my personal danger list because they are everywhere and often go unnoticed for years. Injection and IDOR are high exploitability plus high impact, which is why they sit at the top. Insecure design and software and data integrity failures are newer entries that reflect supply chain and architectural risks that are harder to bolt on after the fact. I treat the list as a triage framework: know which categories your tech stack is most exposed to and attack those first.

Symmetric encryption uses one shared key for both encryption and decryption. AES is the standard -- it is fast, hardware-accelerated on modern CPUs, and suitable for bulk data. Asymmetric encryption uses a key pair: a public key to encrypt and a private key to decrypt. RSA is much slower and has a hard upper limit on the data size it can handle directly. In practice I never use RSA to encrypt actual payloads. I use RSA or ECC to encrypt a short symmetric key, then use AES to encrypt the data itself -- that is the hybrid model TLS and PGP both rely on. I would choose AES-256-GCM for encrypting files or database fields, and use RSA-2048 or P-256 only for key exchange or digital signatures.

PICERL is Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. In practice, teams tend to fail hardest at Preparation and Lessons Learned -- the two bookends. Preparation is under-invested because it's invisible until you need it: runbooks aren't updated, asset inventories are stale, and on-call contacts go dead. Lessons Learned is skipped or done badly because teams are exhausted and want to close the ticket. The result is the same incident type recurring six months later. During an actual response I've seen Identification drag on because nobody agreed on what 'confirmed incident' meant versus 'potential incident', which delays the decision to escalate. I try to drive consistency by writing a decision tree into the runbook: if X conditions are met, call it a P1 and page the CISO. Containment is where the isolate-versus-observe tradeoff lives -- you want to preserve evidence but not let the attacker pivot further. I document that decision explicitly in the ticket so legal and leadership understand why we waited. The phases look clean on paper; the job is making them work under pressure with incomplete information.

The shared responsibility model splits security duties between the cloud provider and the customer. For IaaS, the provider owns physical infrastructure, hypervisor, and network fabric. I own the OS, middleware, runtime, application code, and data. For PaaS, the provider also takes the OS and runtime, so my responsibility narrows to the application and data. For SaaS, I basically own data, access controls, and configuration. The critical thing people miss is that 'managed' does not mean 'secure by default.' An RDS instance is still my problem from the database account, network ACL, encryption-at-rest, and parameter group perspective. I always map out the boundary explicitly at the start of a project, because misunderstanding it is the root cause of most cloud breaches I have seen reviewed.

When a new system or feature comes in, I start by getting context before I open any diagrams. I meet with the engineering lead to understand what the system does, who the users are, and what data it touches. Then I ask for a data-flow diagram or create one with them if it does not exist. From there I identify trust boundaries, entry points, data stores, and privilege levels. I use STRIDE to systematically think through spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege for each boundary crossing. I document findings in a shared tracker, classify them by severity, and distinguish blockers from nice-to-haves. I schedule a review meeting where I present findings as trade-offs rather than mandates, so engineering understands the why. Before sign-off I verify that blockers are resolved or have an accepted risk decision with a named owner and a revisit date.