Cyber Security Analyst interview questions and answers

It's the three goals of information security. Confidentiality means only authorised people can see the data; a data breach or someone sniffing unencrypted traffic attacks it, and encryption and access control protect it. Integrity means data isn't changed without authorisation; changing the amount in a payment request or defacing a website attacks it, and hashing, digital signatures and change control protect it. Availability means systems and data are there when needed; a DDoS attack or ransomware attacks it, and redundancy, backups and DDoS protection protect it.

Mention that one attack can hit several at once: modern ransomware encrypts files (availability) and also steals them to threaten publication (confidentiality).

A vulnerability is a weakness, such as an unpatched web server, a weak password or an open port that shouldn't be. A threat is anything that could exploit a weakness: an attacker, malware, a careless insider, even a flood in the server room. Risk is the chance that a threat exploits a vulnerability, combined with the damage it would cause, often described as likelihood times impact.

Example: the company's VPN appliance has a known critical flaw (vulnerability), attackers are scanning the internet for it (threat), and it guards access to the whole network, so the risk is high and patching is urgent. A similar flaw on an isolated test machine would be a lower risk. Security work is mostly about lowering risk, since threats can't be controlled.

Authentication proves who you are: a password, an OTP, a fingerprint. Authorisation decides what you're allowed to do once identified: an HR user can open payroll records, an intern can't. Authentication always comes first.

Multi-factor authentication strengthens the first step by requiring two or more different kinds of factor: something you know (a password), something you have (a phone or security key) and something you are (a fingerprint). Two passwords aren't MFA, because they're the same kind. Mention that not all MFA is equal: SMS codes can be stolen through SIM swaps or phishing pages, and push approvals can be abused by flooding a user with requests, so authenticator apps with number matching, or hardware keys, are stronger.

Defence in depth means several independent layers of control, so when one fails, the next can still stop or detect the attack. With phishing: the email gateway should filter the message. If it gets through, trained users report it instead of clicking. If someone clicks, a web proxy or DNS filter can block the known malicious site. If they enter their password, MFA stops the attacker logging in. If malware runs, EDR on the laptop detects and isolates it. Least privilege limits what the account can reach, network segmentation slows lateral movement, and the SIEM alerts on unusual sign-ins. Tested backups allow recovery.

The point to make: no single control is perfect, so you plan for each one failing.

A SIEM, security information and event management system, collects logs from across the organisation, normalises them into common fields, stores them for searching, and runs correlation rules that raise alerts. Common ones are Splunk, Microsoft Sentinel and IBM QRadar.

I'd start with the sources that show attackers most clearly: identity (Active Directory domain controllers and cloud sign-ins such as Microsoft Entra ID), endpoint protection or EDR, firewalls and VPN, web proxy and DNS, email security, cloud audit logs such as AWS CloudTrail or Microsoft 365, and critical servers. Mention two practical points: all sources need correct time through NTP, or timelines won't line up, and every new source needs checking that its fields are parsed correctly.

In the Security log: 4624 is a successful logon and 4625 a failed one; the logon type tells you how, such as 2 for interactive at the keyboard, 3 for network and 10 for Remote Desktop. 4648 is a logon using explicit credentials, 4672 means special privileges were assigned to a new logon, usually an admin, and 4740 is an account lockout. For account changes, 4720 is a user account created, and 4728, 4732 and 4756 are a member added to a global, local or universal security group.

Two more that should always alert: 1102, the audit log was cleared, and 7045 in the System log, a new service installed, which attackers use to keep access.

The logic: in a short window, say 10 minutes, the same account has many failed logons, 4625, followed by a successful one, 4624, from the same source. In Splunk it could look like: index=wineventlog EventCode IN (4624, 4625) | bin _time span=10m | stats count(eval(EventCode=4625)) as failures, count(eval(EventCode=4624)) as successes by _time, src_ip, user | where failures > 10 AND successes > 0. Field names depend on how your logs are parsed.

Then tune it: exclude known vulnerability scanners, set thresholds from your normal data, and write a separate rule for password spraying, where one source tries a few passwords against many accounts. A success after many failures should be high priority.

Prioritise by severity and by the asset and user involved: an alert on a domain controller or a finance admin comes before one on a test machine. Group related alerts into one case. For each, gather context: who, which host, when, what happened before and after, threat intelligence on the IP, domain or file hash, and whether there's a change ticket or planned test. Then decide: true positive, false positive, or benign (real but expected). Escalate true positives to L2 or incident response with the evidence written up clearly.

For false positives, tune the rule with narrow exclusions, such as one scanner's IP, never by disabling it, and record why. Mention measuring time to triage and false-positive rates per rule.

The classic NIST lifecycle has four: preparation (plans, playbooks, tools, contacts and training before anything happens); detection and analysis (spotting the incident, confirming it, and working out scope and severity); containment, eradication and recovery (stopping the spread, removing the cause such as malware or stolen accounts, and restoring systems safely); and post-incident activity (lessons learnt and improvements). The SANS model splits the same work into six: preparation, identification, containment, eradication, recovery and lessons learnt.

Add the Indian context: CERT-In's directions require organisations to report certain kinds of cyber incidents to CERT-In within six hours of noticing them, so reporting is part of the plan.

Act fast, because attackers use stolen passwords within minutes. Reset the password and revoke the user's active sessions and tokens. Check the sign-in logs for logins from unusual IPs or countries since the click, and whether a new MFA method was registered. Look for mailbox rules the attacker may have added, such as forwarding mail outside or deleting replies.

Then protect others: search for the same email in other mailboxes and remove it, block the sender and the link at the email gateway and proxy, and check proxy logs for anyone else who visited it. If an attachment was opened, scan or isolate the laptop. Thank the user for reporting quickly; blaming people stops them reporting next time.

Isolate it from the network rather than powering it off: use EDR network containment, disable the switch port, or unplug the cable. Powering off loses memory, which may hold evidence such as the running processes and network connections, and sometimes even encryption keys. Capture memory if you can.

Then find the scope: which other hosts and accounts are involved, how the attacker got in, and whether data was stolen. Disable compromised accounts and protect the backups by keeping them offline. Escalate to the incident manager and management, who decide on legal steps and reporting, including to CERT-In within six hours. Restore only from clean backups after the way in is closed, and reset credentials widely, since attackers usually steal them first.

Collect the most volatile evidence first: memory and live network connections, then disks and logs. Take forensic images, record each one's SHA-256 hash, and work on copies, never the original. Keep a chain of custody: who collected what, when, how, and everyone who handled it since. Record times with their time zone, because systems often log in UTC.

A post-incident review is blameless and factual. It covers a timeline from first sign to recovery, the root cause, what worked, what didn't, why detection took as long as it did, and actions with an owner and a date, such as a new detection rule or a patching fix. Then update the playbooks. Interviewers look for the action items, not just the story.

An IDS, intrusion detection system, watches a copy of the traffic and raises alerts but doesn't block anything. An IPS, intrusion prevention system, sits inline, so traffic passes through it and it can drop malicious packets or reset connections. The trade-off: an IPS stops attacks but a false positive blocks real traffic, so new rules often start in alert-only mode. Snort and Suricata are common open-source engines, and most next-generation firewalls include an IPS.

Detection is either signature-based, matching known attack patterns, which is accurate but misses new attacks, or anomaly-based, flagging behaviour that differs from normal, which can catch new attacks but produces more false positives. Encrypted traffic can't be inspected without TLS decryption.

A packet-filtering firewall checks each packet's source and destination IP, port and protocol against rules, with no memory of connections. A stateful firewall tracks connections, so it allows replies to traffic that went out and drops packets that don't belong to a known session; this is the baseline today. A next-generation firewall adds application awareness (it can allow WhatsApp Web but block file transfer), rules by user identity, an IPS, URL filtering and TLS inspection.

A web application firewall is different: it sits in front of a website and inspects HTTP requests for attacks such as SQL injection and cross-site scripting. Interviewers like it when you say which threat each type stops and which it misses.

I'd look for rules that allow too much: any-to-any rules, management ports like RDP 3389 or SSH 22 open to the internet, and wide source ranges where one IP would do. Then rules that are dead or misleading: zero hit counts over months, rules shadowed by a broader rule above them so they never match, and temporary rules that were never removed. Insecure protocols such as Telnet, FTP or old SMB. Rules with no owner, ticket or business reason recorded. Missing logging on important rules. Whether there's a default deny at the end, and whether outbound traffic is filtered too, not just inbound.

Report findings by risk, with a suggested change and an owner for each.

Split the network into zones by function and trust, with firewalls between them that allow only the traffic each zone needs. Typical zones: user laptops, servers, databases, management and admin systems, OT or medical devices if any, guest Wi-Fi, and a DMZ for internet-facing services. Users should reach servers only on the application ports they use, never SMB or RDP across zones, and only admins from hardened jump hosts should reach management interfaces. Isolate backups so they can't be reached from the same accounts.

Start by mapping real traffic flows from firewall logs, so you don't break applications, then tighten in phases. For critical systems, microsegmentation can limit traffic between individual servers too.

ISO/IEC 27001 is the international standard for an information security management system, or ISMS: the policies, processes and people an organisation uses to manage its information security risks in a planned way. The organisation defines the scope, assesses its risks, chooses how to treat them, and records in a Statement of Applicability which Annex A controls apply and why. The current 2022 version has 93 controls in four themes: organisational, people, physical and technological.

It runs as a cycle of improvement: internal audits, management reviews and corrective actions. Certification is done by an accredited body in a two-stage audit, followed by surveillance audits each year and recertification every three years.

List the assets that matter, then for each, the threats and vulnerabilities, and the controls already in place. Rate the likelihood and the impact, for example from 1 to 5 each, and multiply for a risk score. Compare it with the organisation's risk appetite and choose a treatment: reduce it with controls, transfer it, for example through insurance, avoid it by stopping the activity, or accept it, with the risk owner's signed approval. Record it all in a risk register with an owner and a review date.

Example: the customer database (asset), ransomware (threat), backups kept on the same network (vulnerability). Likelihood 4, impact 5, score 20, high. Treatment: offline, tested backups; the residual risk is rated again afterwards.

ISO 27001 certifies the organisation's ISMS against an international standard, and the certificate is public. SOC 2 is an attestation report by an independent CPA firm, under the AICPA's Trust Services Criteria: security is always included, and availability, processing integrity, confidentiality and privacy are optional. A Type I report checks that controls are designed properly at one point in time; Type II tests that they actually worked over a period, often six to twelve months. SOC 2 is common for companies selling services to US clients.

To prepare: fix the scope, do a gap assessment, write the missing policies, and collect evidence such as access reviews, joiner and leaver records, change tickets, backup tests and vulnerability scans. An internal audit first finds problems early.

Show interest backed by what you've done. Structure: what got you interested, how you've built skills, and what you want to do. For example: "I got interested when [a real trigger, such as a friend's account being hacked or a college workshop]. Since then I've completed [course or certification] and practised on [TryHackMe, Hack The Box or a home lab], where I set up [a SIEM with logs from a test machine] and wrote detections for [attack]. I'd like to start in a SOC, because seeing real alerts every day is the fastest way to learn."

Avoid saying it's because the field pays well or sounds exciting; interviewers want evidence you'll keep learning.

Be honest and show you understand why: attackers often strike at night and on holidays, precisely when fewer people are watching. For example: "I'm comfortable with rotating shifts. I understand the SOC must be covered at all times, and I'd plan my sleep and routine around the rotation. I'd also make sure my handover notes are clear, so the next shift doesn't lose track of an ongoing investigation."

If you have a real constraint, say so politely and ask how the rotation works. Mentioning handovers shows you understand how a SOC actually runs.

Interviewers are testing integrity and judgement. The answer: treat it like any other case, stay factual, and follow the process instead of confronting the person or ignoring it. For example: "I'd make sure of the facts first from the logs, record what I found without adding opinions, and report it to my lead or the security manager as our process says. I wouldn't discuss it with colleagues or the manager directly. If the client data is at risk, containment comes first, such as asking for the message to be recalled or the mailbox secured."

Show that a person's rank doesn't change how you apply policy, and that you protect confidentiality during the case.

Give specific sources and show you act on them. For example: "I follow CERT-In advisories and CISA's Known Exploited Vulnerabilities list, read vendor threat reports, and follow a few security researchers and newsletters. When a major vulnerability comes out, I read how it's exploited and try to write a detection for it in my lab, using the MITRE ATT&CK framework to map techniques. Recently I looked at [recent threat] and [what you did with it]."

Avoid naming only YouTube or news sites. Mentioning a habit of turning news into detections or checks shows how you'd add value in a SOC.

Use STAR and show attention to detail with a careful method. For example: "In my internship, an alert about a login from a new country had been closed as a VPN user (situation). While reviewing closed cases (task), I noticed the same account had also created a mail-forwarding rule an hour later. I checked the sign-in logs, found the login didn't come from our VPN range, and escalated it with the evidence (action). It was a compromised account; the password was reset and the rule removed, and we added mailbox rule creation to the triage checklist (result)."

Credit the team's process, and show how you checked before raising it.