SOC Operations and SIEM Interview Questions for Cyber Security

A SOC is the team, processes and technology that monitor an organisation's environment around the clock, detect threats, triage alerts and coordinate response. Tier 1 analysts triage alerts, Tier 2 investigate and contain, and Tier 3 or threat hunters handle complex cases and build detections. A SOC can be in-house, outsourced to an MSSP or hybrid. Many Indian IT firms run global SOCs for international clients.

A Security Information and Event Management platform collects logs from firewalls, endpoints, servers, cloud and applications, normalises them, stores them for search and correlates events to raise alerts. Examples are Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security and Google Security Operations. A SIEM supports detection, investigation, dashboards and compliance reporting. Its value depends on good log sources, parsing and tuned rules.

A SIEM collects and correlates logs to detect threats. SOAR, Security Orchestration, Automation and Response, takes alerts and runs playbooks that enrich, decide and act, for example looking up an IP's reputation, querying EDR, disabling a user and opening a ticket. SIEM answers what is happening; SOAR speeds up the response. Many platforms now combine both, but automation still needs human approval for disruptive actions.

Endpoint Detection and Response records detailed endpoint activity, like process creation, command lines, network connections and registry changes, and detects suspicious behaviour, not just known files. Analysts can investigate a process tree, isolate a host and remove malware remotely. Traditional antivirus mainly blocks known signatures. XDR extends EDR by correlating endpoint, email, identity and cloud signals in one platform.

A false positive is an alert on benign activity, such as an admin running a legitimate script flagged as malicious. A false negative is a real attack that produced no alert, which is more dangerous. Too many false positives cause alert fatigue and missed real incidents. Analysts tune rules with allowlists, thresholds and context, and test detections against simulated attacks to find false negatives.

Get the original email with full headers. Check SPF, DKIM and DMARC results, the real sender and Reply-To, and the received path. Extract URLs and attachments without clicking, check them in a sandbox and reputation services, and compare the sender domain for lookalikes. If malicious, search for the same message across mailboxes, purge it, block indicators and check whether anyone clicked or entered credentials.

Use a laptop with virtualisation, run a Windows VM with Sysmon, a Linux server and a free SIEM such as Elastic or Splunk Free, or Wazuh as an open source option. Forward logs, then simulate attacks safely with Atomic Red Team tests on your own VMs. Write detections for each test, document them on GitHub and explain them in interviews.

A good answer shows realism and discipline. For example: I understand SOCs run 24x7 and night shifts are common early in a career. I keep a fixed sleep routine, prepare handover notes carefully and read previous shift notes before starting. During quiet hours I study detections or practise queries. I communicate early if a schedule conflict arises so the team can plan cover.

Key Security log events are 4624 successful logon, 4625 failed logon, 4672 special privileges assigned, 4688 process creation, 4720 user created, 4728 and 4732 user added to privileged groups, 4740 account lockout, 1102 audit log cleared, 4698 scheduled task created and 7045 service installed in the System log. Logon type in 4624, such as 3 for network and 10 for RDP, adds important context.

Sysmon is a free Microsoft Sysinternals tool that logs detailed endpoint events to the Windows event log. Useful events are ID 1 process creation with hashes and command line, ID 3 network connection, ID 11 file creation, ID 13 registry changes and ID 22 DNS queries. With a tuned configuration, it gives rich telemetry for SIEM detections when a full EDR is not available or as an extra source.

Threat intelligence is analysed information about adversaries, their tools and behaviour. Indicators of Compromise are artefacts like malicious IPs, domains and file hashes; they are easy to use but change quickly. TTPs, tactics, techniques and procedures, describe how attackers operate, and are harder for attackers to change. The Pyramid of Pain shows that detecting TTPs causes attackers more cost than blocking hashes.

Threat hunting is proactive searching for attackers who evaded existing detections. Hunters start from a hypothesis, for example that attackers use scheduled tasks for persistence, then query EDR and SIEM data to confirm or reject it. Findings become new detection rules. Hunting requires good data retention, knowledge of normal behaviour and frameworks like MITRE ATT&CK to guide hypotheses.

Important metrics are mean time to detect, mean time to respond, alert volume per analyst, false positive rate per rule, percentage of alerts closed within SLA, detection coverage against priority ATT&CK techniques and log source health. Metrics should drive improvement, not punish analysts. For example, a rule with 95 percent false positives should be tuned, and long response times may point to missing automation.

User and Entity Behaviour Analytics builds baselines of normal behaviour for users, hosts and service accounts, then flags anomalies such as logging in from a new country, accessing far more files than usual or a service account doing interactive logins. It helps detect insider threats and stolen credentials that look like normal logins. It needs good identity data and careful tuning to avoid noisy alerts.

This pattern suggests brute force or password spraying that succeeded. Check source IPs, location and logon type, and whether MFA was used for the success. Review what the account did after login, such as mailbox rules, file access or new tokens. If suspicious, disable the account or revoke sessions, reset the password, block source IPs and check whether the same IPs targeted other accounts.

Office apps rarely start PowerShell, so this usually means a malicious macro or document exploit. Decode the Base64 command to see what it does, check the process tree and any network connections for downloads, and find the source email. Isolate the host through EDR, block the sender and URLs, search for the same email in other mailboxes and hunt for the same command line elsewhere.

This is an impossible travel alert. First rule out benign causes like corporate VPN, cloud proxy egress or mobile networks. Check device IDs, user agents and MFA results for both logins. If the second login is from an unknown device without MFA, or followed by mailbox rule creation or data download, revoke sessions, reset credentials, review MFA methods and contact the user through a separate channel.

Silent log gaps create blind spots where attacks go undetected, and they can also break compliance. Raise it as a priority issue, check the forwarder or agent health, network path, licence limits and parsing errors, and restore ingestion. Check whether the gap overlapped any suspicious activity. Then add log source health monitoring that alerts when expected volume drops, so gaps are found in hours, not days.

Define why the source is needed and which detections it supports. Configure collection through an agent, syslog or API, verify time sync and time zone, and ensure parsing maps fields to the SIEM's data model. Check volume and licence impact, set retention, and test with sample events. Finally build or enable detections and add health monitoring so the team knows if it stops.

Situation: as a Tier 1 analyst I closed an alert as false positive without checking the user's later activity. Task: my lead found it was a real phishing compromise. Action: I owned the mistake, helped contain it, and proposed a checklist for credential alerts that includes reviewing activity after login. Result: the checklist was adopted by the shift and similar misses stopped.

Detection engineering treats detections like software: rules are written from threat models and ATT&CK techniques, stored in version control, tested with attack simulations, peer reviewed and measured for false positive rate. Formats like Sigma let rules be shared across SIEMs. Teams track coverage, tune noisy rules and retire obsolete ones. This replaces ad hoc rule creation that leads to noisy, untested alerts.

Analyse alert data to find the top noisy rules, which usually create most of the volume. Tune them with context and allowlists, or turn low-value ones into dashboards. Add enrichment and automated closure for known benign patterns using SOAR, group related alerts into incidents and add risk-based alerting that scores entities. Track false positive rate per rule weekly and require testing for new rules.