Kiber təhlükəsizlik · 10 min read

What does a SOC analyst do and how to become one?

A SOC analyst works in shifts at a security operations center (SOC). They check the alerts generated in the SIEM (Security Information and Event Management), read logs and determine whether an event is a real attack or a false positive. When a suspicion is confirmed, they escalate the incident to a higher level. To get started, you need knowledge of networking, Windows and Linux logs, one SIEM tool and the triage skill — writing code is not required.

What does a SOC analyst do?

A SOC analyst is a member of the defensive team (Blue Team) who monitors the logs and alerts coming from the company's infrastructure and distinguishes suspicious behavior from a real incident. The work is organized in shifts, because attacks do not observe working hours. The analyst assesses not the system that raised the alert itself, but the behavior behind the alert.

The role's area of responsibility is fairly narrow, and that is good: it ensures decisions are fast and traceable.

• Monitoring — watching the SIEM dashboards and the alert queue.
• Alert triage — determining the alert's priority and whether it is real.
• Investigation — checking logs, the user account, source and destination addresses.
• Escalation — passing an incident beyond one's authority to a higher level.
• Recording and reporting — keeping every step documented in the ticketing system.
• Feedback — notifying the team about a malfunctioning detection rule.

How does a SOC shift go hour by hour?

1. The first 15–20 minutes of the shift: handover from the previous shift. Open incidents, unfinished investigations and expected planned work (migration, scan, update) are read through.
2. Dashboard check: the health of the log sources. If the log flow from a source has been cut off, it means alerts are silently being lost — this is the first thing to look at.
3. The main part of the shift: the alert queue. Alerts are sorted by priority: high-priority alerts are handled immediately, low-priority ones in turn.
4. Interruptions in the middle: user requests, notifications such as a phishing complaint, questions from system owners awaiting confirmation.
5. Toward the end of the shift: wrapping up incidents that were not closed, listing recurring false positives.
6. Handover note: a short, factual summary is written so the next team is not left without context.

A real day does not go this neatly. A single incident can swallow the whole shift, while on another day the shift is almost entirely filled with false positives. The only constant is note-taking discipline: a step that is not written down is considered not to have happened.

What steps does the analyst take when an alert comes in?

1. Read the alert's context: which rule fired, which log source it came from, when it happened.
2. Identify the actors: source and destination IP, user account, device, process name.
3. Build a timeline: what happened before and after the event on the same account and the same device.
4. Check the history: whether a similar alert was closed earlier for this account or this IP, and with what decision it was closed.
5. Perform enrichment: check the indicators of compromise (IOC — Indicator of Compromise), i.e. IPs, hashes and domains, in sources such as VirusTotal, MISP or OpenCTI.
6. Map it to MITRE ATT&CK: which tactic and technique this behavior resembles and what the continuation of the chain might be.
7. Make a decision: if it is a false positive, close it with the reason; if doubt remains, deepen the investigation; if it is confirmed, escalate it.
8. Write it down: what you saw, what you based it on, what you did — all three must be in the ticket note.

This flow corresponds to the detection and analysis phase of the incident response framework. The NIST SP 800-61 document divides incident handling into phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. The L1 analyst mainly works in the second phase.

What is the difference between L1, L2 and L3 SOC analysts?

In job postings this division is not always named the same way. In small teams one person may do the work of all three levels. In large centers, however, the boundary is strict and the escalation procedure is documented.

What is a false positive and why does it take up most of the time?

A false positive is when legitimate activity is assessed by a detection rule as an attack. The more sensitively a rule is configured, the more alerts there are and the smaller the share of useful alerts. In the SOC Survey reports by the SANS Institute, reducing false positives is listed among the main problems of SOC teams.

• A planned vulnerability scan — looks like a port scan across the network.
• An admin script — a PowerShell task that runs at night resembles malicious behavior.
• A VPN exit — the user connects from another country, and a geographic anomaly alert is raised.
• A new application — software installed for work is flagged as an unrecognized process.
• A service account — automatic authentication generates a series of failed logins.

The solution is not to silence the alert but to refine the rule (tuning). The analyst writes down the context of the recurring false positive, and the rule's author adds an exception in a narrow and explainable form. Setting a broad exception also makes a real attack invisible — this is one of the most expensive mistakes in a SOC.

What tools does a SOC analyst use daily?

• SIEM — collecting logs, correlation and generating alerts: Splunk, ELK, IBM QRadar.
• Endpoint and EDR — device-level behavior analysis and isolation: CrowdStrike, Cortex.
• Network analysis — reading traffic and finding traces of an attack: Wireshark, Zeek, tcpdump.
• Threat intelligence — checking IOCs and TTPs: MISP, OpenCTI, VirusTotal.
• Automation (SOAR) — turning repetitive response steps into a playbook: Cortex XSOAR, Splunk SOAR.
• System logs — checking at the source: Windows Event Viewer, Linux Auditd, PowerShell.
• Framework — naming the behavior and predicting the chain: MITRE ATT&CK.

You do not need to learn everything at once. Knowing one SIEM in depth makes the transition to a second one easier, because the query logic and log-normalization concepts are similar.

What skills do you need to become a SOC analyst?

• TCP/IP and port behavior — distinguishing which traffic is normal and which is unusual.
• Windows Event log — reading login, account-creation and process-start events.
• Linux audit — finding user and process traces in Auditd and system journals.
• SIEM query logic — filtering, grouping, time windows and simple correlation.
• Reading MITRE ATT&CK — finding the technique and predicting the attack's next step.
• Recording and reporting — writing an investigation so that someone else can continue it.
• Attention and patience — not missing the difference between similar alerts.

Programming is not mandatory on this list. Knowing scripting gives speed at the L2 and L3 levels, but the L1 job consists mainly of reading, comparing and making decisions.

What path do you need to take to become a SOC analyst from scratch?

1. Nail down the networking basics: TCP/IP, DNS, HTTP, VPN and general port behavior. Read your own traffic with Wireshark.
2. Learn system logs: enable the audit policy on Windows, write an Auditd rule on Linux, see what gets logged.
3. Build a home lab: stand up one SIEM (for example, ELK or the free edition of Splunk) and feed logs from two different sources into it.
4. Write your first correlation rule: start with a simple scenario such as a series of failed logins followed by a successful login.
5. Simulate an attack: run a simple scan or account-creation scenario and confirm that the alert fires.
6. Turn 5–10 incidents into written investigation reports: the alert, the evidence, the MITRE ATT&CK technique, the decision, the outcome.
7. Present these reports as a portfolio and apply for L1 positions.

On this path, the step most often skipped is the sixth. Doing something in a lab and being able to explain it are different things. In an interview, they most often ask you to talk through exactly your line of reasoning.

How is SOC work practiced in the Log Academy lab?

• M01 — reading network traffic: Wireshark, Zeek, tcpdump.
• M02 — Windows and Linux audit policies: Event Viewer, Auditd, PowerShell, SELinux.
• M03 — SIEM analysis, alert configuration and dashboard design: Splunk, ELK, IBM QRadar.
• M04 — endpoint and firewall defense: Cortex, CrowdStrike.
• M05 — threat intelligence, collecting IOCs and TTPs: MISP, OpenCTI, VirusTotal, MITRE ATT&CK.
• M06 — incident response and automation: Cortex XSOAR, Splunk SOAR.

Who is this job not suited for?

SOC work should be described honestly. It is not a thrilling profession where you detect a new attack every day. Most days are spent checking recurring alerts and writing notes.

• Shift work — night and weekend shifts are standard in many centers.
• Repetitive work — checking the same type of alert dozens of times is normal.
• A strict recording requirement — every decision must be justified in writing.
• The result is seen late — in a well-run SOC, «nothing happens» is the best result.

Nevertheless, the role is a natural transition for IT support specialists, network and system administrators. If you enjoy working with logs, looking for the cause and understanding how a system behaves, then a SOC is one of the clearest entry doors into cybersecurity.