Career path
SOC Analysis
What people in this area work on
A security operations center, or SOC, is the team that watches an organization’s systems for signs of attack. Security tools collect logs from computers, networks, and cloud services, and raise an alert when activity matches a rule someone wrote.
Most alerts turn out to be harmless. The analyst’s core job is triage: gathering enough evidence to decide whether an alert is malicious, benign, or needs a closer look, and escalating the real problems with a clear explanation of what was found.
The work rewards careful reading, consistent notes, and steady judgment. Because alerts touch nearly every system, it is also a practical way to learn how the other areas of security fit together.
Terms used on this page
- Log
- A timestamped record of activity, such as a sign-in, a file download, or a network connection.
- Alert
- A notification raised when activity matches a detection rule.
- Triage
- Sorting alerts by what they are and how urgently they need action.
- SIEM
- Security information and event management: a platform that gathers logs in one place so analysts can search them and receive alerts.
- False positive
- An alert that fired on harmless activity.
- Escalation
- Handing a confirmed or suspected incident to a responder or senior analyst, together with the evidence gathered so far.
How the work flows
One piece of work, start to finish. Every step below is something you can practise in the starter project.
- AlertA rule fires on something that looks off
- TriageDecide what it is and how urgent
- EvidencePull the logs around it
- DecisionMalicious, benign, or needs more
- EscalateHand confirmed problems to responders
Examples of everyday tasks
- Work through a queue of new alerts and record a decision for each one.
- Search logs to see what happened just before and after an alert.
- Check whether an IP address, web domain, or file has been reported as malicious by trusted sources.
- Write short case notes that another analyst could pick up and follow.
- Escalate confirmed incidents to incident responders with the supporting evidence.
- Point out detection rules that keep firing on normal activity so they can be improved.
Related job titles
- SOC analyst
- Security operations analyst
These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.
Starter project
Investigate a Small Alert Queue
Use practice security alerts and supporting logs. Decide which alerts look malicious, which appear harmless, and which need more evidence.
What you’ll use
- A handful of practice alerts and the logs behind them, from a public practice dataset or a training scenario
- A spreadsheet or any log search tool you are comfortable with
- A document for your notes and decisions
Resources to start with
- Security Datasets (Open Threat Research Forge) (opens in a new tab)
Free recordings of simulated attack activity and the logs it produced, useful for practice investigations.
- MITRE ATT&CK (opens in a new tab)
A public knowledge base of attacker techniques. Look up the behavior an alert describes to understand what it could mean.
More projects for this path
Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.
- Alert Queue Triage
Work a small queue of practice alerts and decide which ones are real.
- Phishing Report Triage
Work a batch of reported emails and decide which are phishing, safe or unclear.
- Detection Noise Review
Find the rules that cry wolf, tune one, and measure the difference.
Project walkthrough
- Pick five to ten practice alerts and write down, in your own words, what each alert claims happened.
- For each alert, find the related log entries and note who was involved, what happened, when, and from where.
- Look for an ordinary explanation first, then note what would make the activity suspicious instead.
- Label each alert malicious, benign, or needs more evidence, and write one or two sentences explaining why.
- For each alert you would escalate, list the evidence and what you would ask a responder to check next.
- Finish with a short summary of patterns you noticed, such as alerts that fire on routine activity.
What to publish
- An investigation report with a short section for each alert
- The log excerpts or screenshots that support each decision
- Your decision for each alert and the reasoning behind it
- Escalation recommendations for the alerts you judged malicious
- A note that the alerts and logs are practice data
Optional extension
Explain a change that could reduce unnecessary alerts, then test it against the practice examples.
Example résumé bullet
Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.
Numbers to record while you work
| Count | Where it comes from |
|---|---|
| Alerts triaged | your queue table, one row per alert |
| Log volume searched | date range and sources in the report |
| Escalations raised | decisions marked malicious, with evidence |
| False positives explained | tuning note and the events it covers |
Project name | tools, datasets and frameworks | link
NightwatchSplunk Free, Sigma, MITRE ATT&CK, Security Datasets, MarkdownGitHub
Triaged 12 practice alerts against 3 days of endpoint and sign-in logs; escalated the 2 confirmed intrusions with evidence, closed 10 with written reasoning, and proposed a rule change that removed 40 repeat false positives.
Give the project a name of its own: “Nightwatch” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.
A day on the job
Try the work before you try the project
A short walkthrough of a realistic situation. Nothing is scored: each choice explains what would happen, so you can talk through the reasoning later.
4,200 alerts overnight, 10 marked critical
You start your shift and the queue is full. Ten alerts are marked critical. I need each one either closed with a reason or escalated by noon.
Where do you start?
One critical alert says a professor signed in from two countries an hour apart. What first?
Choose above to continue.
The logs show a successful login from a new country, then new mailbox rules forwarding invoices. Now what?
Choose above to continue.
Turn your project into a portfolio piece
A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.
Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.
Include:
- Goal: What question or problem did you investigate?
- Environment: What tools, practice data, or systems did you use?
- Your work: What did you personally do, and why?
- Evidence: Include useful screenshots, queries, code, or test results.
- Findings: What did you discover? What remains uncertain?
- Fix or recommendation: What should change, and did you test it?
- Sources and limitations: Credit datasets and guides. Clearly identify simulated work.
Use sample or redacted information in the public version.
Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.
Put numbers in it
Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.
Name it, then show your tools
A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.
Project name | tools, datasets and frameworks | link
- Role-Based Access LabTurnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
- Login HuntBeacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
- Cloud ProjectBedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub
Why link a report?
Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.
Not every recruiter will open it, but it makes your work available for review.
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Investigated a public authentication-log dataset for repeated failed logins followed by successful access; documented search queries, supporting evidence, and limitations in a reproducible hunt report.
Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.
Preview the write-up template
# Project title > Practice project. Describe the simulated scenario, practice data, or lab used. ## Goal What question or problem did you investigate? ## Environment What tools, practice data, or systems did you use? Link datasets and guides. ## My work What did you personally do, and why? ## Evidence Screenshots, queries, code, or test results. Use sample or redacted information only. ## Findings What did you discover? The numbers behind it (records searched, findings confirmed, tests added). What remains uncertain? ## Fix or recommendation What should change, and did you test it? ## Sources and limitations - Datasets and guides used: - What was simulated: - Limitations: