Cybersecurity Analyst interview questions and answers

The CIA triad is the base model for security goals. Confidentiality means only authorised people can see data. A data breach, where an attacker steals customer records from a misconfigured cloud bucket, is an attack on confidentiality; controls include access control, MFA and encryption. Integrity means data is accurate and not changed without permission. If an attacker edits bank account details in invoices, that breaks integrity; hashing, digital signatures and change logging help detect it. Availability means systems work when users need them. A DDoS attack or ransomware that encrypts servers attacks availability; controls include DDoS protection, redundancy and tested offline backups. Ransomware with data theft actually hits all three, which is why analysts think about the full triad during an incident.

First I look at the full headers: the real sender, the Return-Path and Reply-To, the sending IP and the Authentication-Results for SPF, DKIM and DMARC. A lookalike domain or a failed DMARC check is a strong red flag. Next I check the content for urgency or payment requests. I never click links; I extract URLs and attachment hashes and check them in tools like VirusTotal or URLScan, and detonate attachments in a sandbox if needed. If it is malicious, I search the mail gateway for the same sender, subject or URL to find all recipients, pull the emails from mailboxes, and check proxy and EDR logs for anyone who clicked or opened it. Then I block the domain, URLs and hashes, reset credentials for anyone who entered them, and thank the user for reporting.

A firewall controls which traffic is allowed, based on rules such as source, destination, port and, in next-generation firewalls, application and user. An IDS, or Intrusion Detection System, looks at a copy of the traffic and compares it with signatures or normal behaviour, then raises an alert for an analyst. It does not stop anything by itself. An IPS, or Intrusion Prevention System, sits inline in the traffic path, so it can drop packets or reset connections when it sees an attack. The trade-off is that an IPS false positive can block real business traffic, so rules are usually tested in detect mode before being switched to block. Many modern firewalls include IPS features, and tools like Suricata can run as either IDS or IPS.

A SIEM, or Security Information and Event Management system, collects logs from many sources such as firewalls, Windows servers, EDR, cloud platforms and email gateways. It normalises them into a common format so they can be searched together. Correlation rules look for suspicious patterns, for example many failed logons followed by a success, and create alerts. As an analyst, I use the SIEM to triage alerts, run queries in languages like SPL or KQL to build a timeline, and pivot between users, hosts and IPs. It also stores logs for months, which helps investigations and compliance. Examples are Splunk, Microsoft Sentinel and Elastic. Many teams pair it with a SOAR tool to automate repeated steps like enrichment.

Encoding changes data into another format so systems can handle it, like Base64 or URL encoding. Anyone can decode it, so it gives no security, although attackers often use it to hide commands, such as encoded PowerShell. Encryption protects confidentiality. It is reversible, but only with the right key. Symmetric algorithms like AES use one shared key, while asymmetric ones like RSA use a public and private key pair. Hashing is a one-way function that produces a fixed-length digest, such as SHA-256. You cannot get the original data back, so it is used to check integrity and identify files, for example matching a malware hash. For passwords we use slow, salted hashing algorithms such as Argon2 or bcrypt rather than plain SHA-256.

Defence in depth means protecting systems with several independent layers, so that if one control fails, others still stop or limit the attacker. No single tool is perfect, so we avoid a single point of failure. A phishing example shows it well. The email gateway may miss a malicious link. If the user clicks and enters their password, MFA stops the attacker from logging in. If malware runs, EDR can detect and block it. Network segmentation limits how far it can spread, and logging in the SIEM helps the SOC detect what happened. Finally, offline backups let us recover if ransomware still gets through. Good layering mixes preventive, detective and recovery controls, and covers people, process and technology, not only tools.

Multi-factor authentication asks for at least two different types of proof: something you know, like a password, something you have, like a phone or security key, and something you are, like a fingerprint. It blocks most attacks that rely only on stolen passwords. But methods differ in strength. SMS codes can be stolen through SIM swapping or simply typed into a phishing page. Push notifications can be abused through MFA fatigue, where attackers spam prompts until a user approves, though number matching helps. The strongest options are FIDO2 security keys and passkeys. They use public key cryptography and are bound to the real website domain, so a fake login page cannot use them. For admins and high-risk users, I would push for phishing-resistant methods first.

A false positive is an alert that fires on harmless activity, like a backup job flagged as data exfiltration. A false negative is a real attack that produces no alert at all. False negatives are usually worse because nobody knows to respond, and the attacker keeps going. But false positives are not harmless either. If analysts see hundreds of noisy alerts a day, they suffer alert fatigue and may close a real one by mistake. So the goal is balance. I would tune noisy rules with specific exclusions instead of disabling them, add context like asset criticality to prioritise, and regularly test detections with simulated attacks to find false negatives. Tracking the true positive rate per rule helps decide where to spend tuning effort.

A vulnerability scan is an automated check, using tools like Nessus, that compares systems against a database of known issues such as missing patches or weak settings. It is broad, fast and should run regularly, often weekly or continuously. It tells you what might be vulnerable but can include false positives. A penetration test is a manual, deeper exercise where skilled testers try to safely exploit weaknesses and chain them together, for example from a phishing foothold to domain admin. It shows real impact and finds logic flaws that scanners miss. Pentests are done less often, have a defined scope, and always need written authorisation and agreed rules of engagement. Both are useful: scans for hygiene, pentests to validate defences and priorities.

Least privilege means each user, service and system gets only the access it needs to do its job, and only for as long as it needs it. This limits the blast radius if an account is phished or misused. In practice I would start with role-based access, so permissions are tied to job roles instead of individuals. Admins should have separate admin accounts that are not used for email or browsing, and ideally use just-in-time elevation through tools like Privileged Identity Management, so standing admin rights are rare. Service accounts should have narrow permissions and no interactive logon. Regular access reviews remove rights people no longer need, especially after role changes or leaving. Logging privileged actions in the SIEM helps detect misuse.

First I read what the rule is designed to catch and the raw event behind it, so I know what normal and abnormal look like. Then I enrich: who is the user, what is the host, is it a critical server, and do any IPs, domains or hashes appear in threat intelligence. Next I build a short timeline around the alert, checking what happened before and after, such as logons, process creation, network connections and other alerts for the same user or host. From that I decide whether it is a true positive, a benign true positive or a false positive, and rate the severity based on impact. If it is malicious I follow the playbook: contain the host or account and escalate to incident response. Either way I write clear notes, and if it is a false positive I suggest tuning.

I would not just sort by CVSS, because severity is not the same as risk. First I flag anything in the CISA Known Exploited Vulnerabilities catalog, since those are being used in real attacks. Then I use EPSS to see the probability of exploitation in the next 30 days. I combine that with asset context: is the system internet-facing, does it hold sensitive data, is it a domain controller or VPN gateway. An actively exploited flaw on an internet-facing device goes to the top with a short SLA, perhaps days. Many findings share one fix, like a single browser or OS update, so I group them for the owners. Where patching is not possible yet, I suggest compensating controls such as restricting access, WAF rules or disabling the vulnerable feature, and I track exceptions with an owner and end date.

MITRE ATT&CK is a free knowledge base of how real attackers behave, built from observed incidents. Tactics are the goals, like Initial Access, Persistence, Privilege Escalation or Exfiltration, and techniques and sub-techniques are the ways they achieve them, like T1566 Phishing or T1003 OS Credential Dumping. In the SOC I tag alerts and incidents with technique IDs, which gives everyone a common language and helps reports. I also use it to map our detection rules and see coverage gaps, for example if we have nothing for lateral movement through remote services. When threat intelligence says a group targeting our industry uses certain techniques, I check whether we can detect them and plan hunts. I keep in mind that coverage on a heatmap does not mean good detection, so rules still need testing.

I start with Entra ID sign-in logs: new countries, unusual IPs, unknown devices, impossible travel, or legacy protocols. Then I check audit logs for signs of persistence, such as new MFA methods, new inbox forwarding or delete rules, and consent to unfamiliar OAuth apps. If it looks real, I contain quickly: disable the account or reset the password, revoke all sessions and refresh tokens, remove the attacker MFA method and malicious rules or apps. Because modern phishing kits steal session tokens, a password reset alone is not enough. Then I scope the damage using the unified audit log: which emails and files were read, downloaded or sent, and whether the account sent phishing internally. Finally I find the root cause, such as an adversary-in-the-middle phishing email, and recommend phishing-resistant MFA like passkeys.

First I measure. I look at which rules produce the most alerts and their true positive rate, because usually a few rules create most of the noise. For each noisy rule I find the cause and tune it narrowly, for example excluding a known backup service account on specific hosts, instead of disabling the whole rule or excluding a full subnet. I add context such as asset criticality and user risk, and move weak signals into risk-based alerting, so one low-risk event adds a score and only several related events create an alert. SOAR playbooks can automate enrichment, like IP reputation and user lookups, so analysts spend less time per alert. Every exclusion is documented and reviewed, and I re-test the detection with tools like Atomic Red Team to make sure it still fires on real attacks.

I structure the report so each reader finds what they need quickly. It starts with a short executive summary in plain language: what happened, what business impact it had, whether data was affected, and the current status. Next comes a clear timeline in UTC, from initial access to containment and recovery. Then I explain the root cause, for example a phished account without MFA, and how the attacker moved. After that I list what we did to contain and fix it, and recommendations with owners and due dates, prioritised by risk reduction. Technical details like IOCs, queries and ATT&CK mappings go into an appendix so engineers can use them without overwhelming leaders. I avoid jargon and blame, state facts and confidence levels, and keep evidence references.

First I look at the destination. I check its reputation in threat intel and VirusTotal, when the domain was registered, and how many other hosts in our environment talk to it. A rare, new domain is suspicious. Next I study the pattern in proxy or Zeek logs: regular intervals with small jitter, similar byte sizes, and activity at night when the user is away all point to beaconing. Then I pivot to EDR to find which process made the connections, and check its path, signature, hash, parent process and any persistence like scheduled tasks or run keys. If it looks malicious, I isolate the host, block the domain and IP, and search the SIEM for other hosts contacting the same infrastructure or running the same hash, before handing over for remediation.

I start with relevance. We care most about actors that target our sector and the technologies we run, so I prioritise reports from our ISAC, vendors and government advisories that match. Raw IOC feeds are useful but noisy and short-lived, so I import them into a platform like MISP with confidence scores and expiry dates, and use them mainly for automatic enrichment of alerts, not as standalone alerts. The bigger value is in TTPs, following the Pyramid of Pain. When a report describes how an actor works, I map it to ATT&CK, check if our detections cover it, and either write new rules or run a hunt. I also feed our own incident findings back as intel, and share sanitised indicators with partners.

First I confirm exposure: which assets have the vulnerable version, whether they are internet-facing, and what data they hold. If it is in the CISA KEV catalog or has public exploits, I treat it as urgent. Then I apply any vendor workaround, such as disabling the affected feature. Next come compensating controls: restrict network access to only required sources, put it behind a VPN, add WAF or IPS signatures for the exploit, and remove unnecessary accounts. Because it has been exploited elsewhere, I also hunt for signs that we were already hit, using published IOCs and behaviour like new processes or web shells. I raise monitoring on that system, and record a time-bound risk acceptance with a named owner until the patch is applied.

I start with the full command line. If it uses -EncodedCommand, I decode the Base64 as UTF-16LE in CyberChef and peel off further layers, and I check PowerShell script block logs (Event 4104) for the real script. Then I look at the process tree. PowerShell launched by Word, Outlook or a browser points to phishing, while one launched by a known management tool may be legitimate. Next I check what it did: network connections, files dropped, child processes and any persistence. I also confirm the user and whether they were active, and search the SIEM for the same command or hash on other hosts. If it is malicious, I isolate the host, block indicators, reset credentials if needed and document everything clearly for escalation.

I would activate the incident response plan, open an incident channel and bring in the IR lead, IT, management and legal early. Containment comes first: use EDR to isolate affected hosts, disable compromised and privileged accounts, block command and control indicators, and if needed segment or disconnect network zones. I would quickly protect backups by taking them offline. I keep systems powered on where possible to preserve memory and logs. Next I scope: find patient zero, the initial access path such as an exposed VPN or phishing, the accounts used, and check for data exfiltration, since most groups also steal data. Eradication means removing persistence, resetting credentials including the krbtgt account twice, and patching the entry point. Recovery is from clean, tested backups in business priority order, with monitoring. Throughout, I keep timed notes. Afterwards we hold a lessons learned review and meet legal reporting duties, such as CERT-In reporting within six hours in India.

I would start with a hypothesis, for example: an attacker with stolen credentials is moving between hosts using remote services like PsExec, WMI, WinRM or RDP (ATT&CK TA0008). Data sources are Windows Security logs from servers and domain controllers, Sysmon or EDR process and network events, and network flow data. First I baseline normal behaviour: which admin accounts and jump hosts usually connect to which servers. Then I look for outliers: network logons (4624 type 3) or RDP logons (type 10) from workstations to other workstations, new service installs (7045) with random names, WmiPrvSE or wsmprovhost spawning cmd or PowerShell, and one account logging into many hosts in a short time. Rare parent-child process pairs are useful too. I document each finding, escalate anything malicious, and convert the reliable patterns into SIEM detections so the hunt keeps value after it ends.

Zero trust means we never give trust just because a request comes from inside the network. Every access to a resource is checked using identity, device health and context, with least privilege, and is re-checked over time, as described in NIST SP 800-207. It is a journey, not a product. I would start with identity, because that is where most attacks begin: single sign-on for all apps, phishing-resistant MFA such as passkeys for admins first, and conditional access policies that consider risk and location. Next comes device posture, so only managed, patched devices with EDR can reach sensitive apps. Then replace flat VPN access with ZTNA that grants access to specific apps, and segment networks so a compromised laptop cannot reach every server. Throughout, we need an inventory of users, devices and data, and good logging to monitor decisions. I would phase it by risk, starting with crown jewel systems, and track measurable progress.

I would assume the keys are already compromised, because automated bots scan public repos within minutes. First, deactivate the access key in IAM and create a new one only if it is still needed, updating the application. If AWS attached a quarantine policy, I keep it until the review is done. Then I investigate CloudTrail for every API call made with that access key ID, across all regions, since attackers often launch crypto-mining instances in unused regions. I look for persistence: new IAM users, access keys, roles, trust policy changes, Lambda functions, or changes to logging. I also check data access in S3 and review GuardDuty findings and billing spikes. Anything the attacker created is removed. Deleting the commit is not enough, so the history must be rewritten and treated as public forever. To prevent repeats: enable GitHub push protection and secret scanning, use pre-commit hooks, and move to short-lived credentials through IAM roles, SSO or OIDC for CI pipelines.

First I study the technique, here ATT&CK T1003.001, and what telemetry it leaves. Tools like Mimikatz or procdump open a handle to lsass.exe with memory read rights, which shows up in Sysmon Event ID 10 (process access) or EDR events, and LSASS dump files may be written to disk. I write the logic in Sigma so it is vendor-neutral and stored in Git, then convert it to SPL or KQL. The rule focuses on suspicious access rights and unusual source processes, with careful exclusions for known security tools. I test it by running Atomic Red Team tests in a lab to confirm it fires, then run it against 30 days of production data to estimate false positives. I attach a short triage guide and severity. After deployment, changes go through pull request review, and I track alert volume and true positive rate, re-testing when tools or the OS change. Enabling LSA protection also reduces the risk itself.

First I scope it. I find who received the email, who clicked through proxy logs, and whose sign-ins came from the attacker's infrastructure, looking for unfamiliar IPs and devices soon after the click. For each affected user I revoke all sessions and refresh tokens, reset the password, and remove any MFA methods the attacker registered. Then I hunt for post-compromise activity: new inbox forwarding rules, emails sent for invoice fraud, OAuth app consents, file downloads from SharePoint, and further internal phishing. I purge the emails from all mailboxes and block the domains. To harden, I would move high-risk users to FIDO2 or passkeys, require compliant or managed devices through Conditional Access, enable token protection where supported, and add detections for sign-ins that do not match the user's device.

I start from the threat model. For a cloud-first company, most attacks begin with identity, so Entra ID or Okta sign-in and audit logs come first, along with cloud control plane logs like AWS CloudTrail or Azure Activity logs. These are fairly low volume and high value. Next is EDR telemetry, which many EDRs keep in their own console, so I forward only alerts and key events to the SIEM. Email security and SaaS audit logs, such as Microsoft 365, follow because phishing and data theft happen there. High-volume sources like VPC flow logs, DNS and proxy logs are valuable for hunting, so I send them to cheaper storage tiers or data lakes and query them on demand. I map each source to ATT&CK techniques it helps detect and review cost against value every quarter.

Insider cases are sensitive, so I first agree scope and authority with HR and legal, and keep the investigation on a need-to-know basis. Monitoring must follow company policy and local privacy law. Then I preserve evidence before anything changes: EDR data, mailbox and cloud storage audit logs, and repository access logs, with chain of custody. I look for signs like large Git clones or downloads, uploads to personal cloud storage or email, USB file copies, printing, and access to repositories outside the person's normal work. Comparing to their own baseline from previous months matters, because a developer cloning code can be normal. I report facts objectively with timestamps, not conclusions about intent. Legal and HR decide on actions, and I help revoke access at the agreed time.

I first agree the plan with the system owner and legal, including whether to contain immediately or observe briefly, and how to keep the service running, for example by failing over to another node. Then I collect evidence by order of volatility. I capture memory using a trusted tool such as AVML or LiME, and record running processes, network connections, logged-in users and open files. Tools run from trusted media, and output goes to external storage, not the suspect disk. Next I take a disk image or a cloud volume snapshot, and copy key logs. Every item is hashed with SHA-256 and recorded in a chain of custody log with who, when and where. Analysis happens on copies. Finally the server is rebuilt from a known good image, not cleaned in place.

I would use a mix of speed, quality and coverage metrics. For speed, mean time to detect, acknowledge, contain and recover show how quickly we act, measured from the first malicious event where possible. For quality, I track the true positive rate per detection, how often escalations are confirmed, and repeat incidents. For coverage, I use ATT&CK mapping validated by purple team exercises, not just rules that exist on paper. Each has pitfalls. Counting closed alerts rewards rushing, and pushing MTTR down can cause shallow investigations. Low incident counts may mean poor detection, not safety. So I report metrics as trends with context, review samples of closed tickets for quality, and link results to business risk, such as how quickly we would stop a ransomware attack.