The SOC Analyst
Glossary

Pull the incident reports for almost any large breach of the last few years and the root cause is rarely exotic. It is a server two patch cycles behind, a service account whose password had not changed since the vendor set it, a public storage bucket, an admin who kept domain rights long after the project ended, an employee who reused a password that had already leaked. None of these required a zero-day.

A mid-size manufacturer gets hit with ransomware on a Friday night. By Monday the bill is already forming: an incident response firm at a few hundred dollars an hour, outside legal counsel to handle notification, a forensic team to scope what was touched, lost production while the lines sit idle, and a ransom demand on top of all of it. None of that was budgeted.

What Is the Cyber Kill Chain? 7 Stages Explained An attacker has to get every step right. You only have to catch one. That asymmetry, normally working against the defender, runs the other way once an intrusion is broken into stages.

A ransomware crew lands on a domain controller at 2 a.m. on a holiday weekend. Prevention already failed: the phishing email got clicked, the credential got reused, the lateral movement went unnoticed for days. The question that decides whether the organization survives is no longer "how did they get in." It is "how long until billing, fulfillment, and payroll run again, and how much data did we lose for good." A security program built only to keep attackers out has no answer to that question.

Two organizations run the same unpatched server. One holds a public marketing brochure on it; the other holds a payment database that processes a million transactions a day. Same vulnerability, same attacker pool, completely different cyber risk.

Two reports land on a SOC analyst's desk, both about the same IP address. The first says: 198.51.100.23: malicious, block it. That is the whole report.

A web server runs an admin login page with no rate limit and a password that was set during install and never changed. A cloud storage bucket is configured for public read access "temporarily" during a migration. A library buried six dependencies deep in an application parses untrusted input without bounds checking.

A SOC analyst opens her queue on a Monday. An endpoint agent flagged powershell.exe spawning from a Word document, then reaching out to an IP in a country the company does no business with. Within twenty minutes she has pulled the process tree, confirmed the macro, isolated the host, and pushed a detection rule so the next attempt fires an alert before anyone clicks.

A board asks one question after every headline breach: "Could that happen to us?" The honest answer is rarely a yes or no. It is a list. The endpoint agent that was never deployed to the OT subnet.

A mid-size SOC runs an endpoint agent from one vendor, a SIEM from a second, a separate email gateway, a standalone network sensor, a cloud posture tool, and a ticketing system that none of them write to cleanly. An analyst chasing one phished credential opens six consoles, exports three CSVs, and reconciles timestamps by hand. The intrusion is one story.

A typical SOC runs a SIEM, an EDR agent, a separate cloud posture tool, a standalone email gateway, two threat intel feeds, and a SOAR that stitches a fraction of it together. Each product has its own console, its own alert format, its own data lake, and its own renewal date. An analyst chasing one incident pivots across four tabs to assemble what one timeline should have shown.

A board asks the security team one question: what are the odds we get breached this year, and what would it cost us? The honest answer is not a list of 4,000 open vulnerabilities or a stack of unread scanner reports. It is a short, ranked statement of the handful of scenarios most likely to cause real loss, what each would cost, and what reduces that loss for the least money.

An analyst gets a flagged attachment: invoice_0423.docm, sender spoofed, no detection on the perimeter scanner. Opening it on a workstation is out of the question. So the file goes to a sandbox.

Most security programs do not fail on a single missing tool. They fail because the architecture underneath them was built for an environment that no longer exists. The firewall-and-VPN model assumed a perimeter: trusted users inside, hostile traffic outside, a clear edge to defend.

A user gets an email that looks like it came from their bank. The link reads paypaI.com, with a capital I where the lowercase L should be. They click, the page is a pixel-perfect copy of the real login, and they type their password into an attacker's form.

On July 25, 2023, a Netenrich researcher published an analysis of a tool being sold on dark web forums and Telegram for $200 a month or $1,700 a year. It was called FraudGPT. The seller advertised it to write malicious code, build undetectable malware, generate phishing pages, and find cardable sites, with no refusals and no safety filter.

A set of valid credentials for your VPN shows up for sale on a Russian-language access-broker forum: a username, a working password, and the note "US, healthcare, ~4k endpoints." The seller did not breach you. They bought a log from an infostealer operator who infected an employee's home laptop three weeks ago. Nobody on your team has seen an alert, because nothing on your network was touched.

The breach does not look like the movies. There is no frantic typing, no progress bar racing toward the mainframe. A password an employee reused turns up in an unrelated breach dump, an attacker tries it against the company VPN, which has no multi-factor authentication, and it works.

A spreadsheet of Social Security numbers and a published marketing brochure get the same treatment in most environments: stored on the same shares, backed up the same way, reachable by the same people. That is the gap data classification closes. Until you know which data is which, every control you apply is either too loose for the sensitive data or too heavy for the public data, and usually both at once.

A regulator's first request after an incident is never "tell me you were secure." It is "show me your records." Show me where the customer data lives and which law governs it. Show me who could access the database under regulatory scope, and prove it was only the people who should. Show me the retention schedule, the encryption status, the consent records, and the breach notification you sent inside the legal deadline.

An attacker dumps a customer database. The export runs clean, the file lands on their machine, and they open it expecting names, emails, and card numbers. Instead they get this: 4f8d2a1c9e... repeated for every field, megabytes of it, with no structure they can read.

An attacker who has spent three weeks inside a network does not declare victory until the data leaves. The intrusion, the stolen credentials, the lateral movement across hosts, all of it is setup. The payoff is the moment a few gigabytes of customer records, source code, or design files cross the perimeter and land on infrastructure the attacker controls.

Most data security programs are built to scan data sitting still. They point a scanner at a database, a bucket, or a file share, classify what is there, and call it covered. That worked when data lived in a handful of central stores.

A SOC keeps 18 months of endpoint, identity, and cloud telemetry in one platform. The threat hunters query it there. The detection engineers write rules against it there.

A developer pastes a config file into a public support forum to debug a connection error. The file holds a live database password. Nobody attacked anything.

A misconfigured cloud storage bucket sits open to the internet for eight months. No attacker, no exploit, no malware. Anyone who guesses the URL can read every file inside it, including customer records.

Every meaningful action on a system can leave a record: a user authenticated, a process spawned a child, a firewall dropped a packet, an API key was used from a new IP. Data logging is the discipline of capturing those records as timestamped entries and putting them somewhere you can search them later. Skip it and an incident becomes a guessing game.

What is Data Loss Prevention (DLP)? Data Loss Prevention (DLP) is a set of security tools, policies, and processes designed to detect, monitor, and block the unauthorized transfer, sharing, or exposure of sensitive data. DLP solutions inspect data in motion (network traffic), data at rest (stored files), and data in use (endpoint activity) to prevent accidental leaks and deliberate exfiltration before damage occurs.

A test database cloned from production carries every real Social Security number, card PAN, and patient record the live system holds. Now it sits on a developer laptop, in a CI runner, and in three analytics notebooks, far outside the controls that guarded the original. Data obfuscation is what makes that copy safe to spread: it replaces the sensitive values with stand-ins, so the data stays useful for the work but worthless to anyone who steals it.

A detection engineer writes a perfect rule for a credential-stuffing attack: ten failed logins then a success from one source. It never fires. Not because the attack did not happen, but because the authentication logs reach the SIEM with the source IP parsed into the wrong field, the timestamp in local time instead of UTC, and the username buried in a free-text message the rule never reads.

In 2016, Microsoft put a chatbot named Tay on Twitter and let it learn from whatever users said to it. Within about 16 hours, coordinated users had fed it enough abuse that it was repeating racist and inflammatory content, and Microsoft pulled it. Nobody breached a server.

A user clicks "export my data" and a few minutes later a download link lands in their inbox. That link is the whole problem in one place. It holds a full copy of someone's personal data, it travels over the open internet, and it was generated by an automated job that ran with broad read access to the production database.

A company can encrypt a customer database, lock it behind least-privilege access, and monitor every query, and still be breaking the law. If it collected that data without consent, kept it longer than it said it would, or sold it to a broker the customer never agreed to, the controls are flawless and the privacy is gone. That gap is the whole point of data privacy: it governs whether you should hold the data and what you are allowed to do with it, not just whether you can keep an attacker out of it.

A company encrypts its customer database, locks it behind multi-factor authentication, and monitors every query against it. The data is secure. Then a regulator asks a different question: why are you still holding records for customers who closed their accounts four years ago, and where is the consent that let you collect them in the first place.

A finance team exports a quarterly report to a shared drive. That single file now lives on a laptop, a cloud bucket, an email thread, and a backup tape. Each copy is a place the data can be read by the wrong person, changed without anyone noticing, or deleted in a ransomware run.

A copy of the production customer database lands in a developer's sandbox account so someone can test a feature. The test ships, the sandbox stays. Six months later that copy is still there: unencrypted, in a different region, attached to a security group no one reviews, holding real names and card numbers.

A customer database copied to a personal cloud account. A source-code repo pushed to a public GitHub. A pricing model dragged onto a USB stick the week before someone resigns.

A service account that normally runs a few hundred read queries an hour against the customer table suddenly runs a single SELECT * with no WHERE clause and pulls every row. The application that owns the account never issues that query. Nothing on the host looks wrong, no malware, no new process, no failed logins, and the network sees an authorized account talking to its own database over its normal port.

A user reports that checkout fails intermittently. The error log shows one line: payment declined. That is all the production logger was set to record.

Every centralized identity provider is a honeypot. Put a few hundred million usernames, password hashes, and identity documents in one database and you have built the single most valuable target an attacker can hit. Breach it once and the whole population is exposed at the same time.

Your online banking dashboard is on the deep web. So is your webmail inbox, the patient portal at your doctor's office, and the internal wiki at work. None of it shows up in a Google search, and none of it is sinister.

In January 2024, a finance worker in the Hong Kong office of the engineering firm Arup joined a routine video call. The chief financial officer was on it. So were several colleagues he recognized.

A single firewall is a single point of failure. The moment an attacker gets past it, nothing else slows them down. Defense in depth is the answer to that problem: stack independent controls so that getting through one does not get you anything.

A web server has a fixed number of connection slots, a finite pool of memory, and a network link that can carry only so many packets per second. A denial-of-service attack does not steal any of that. It just uses all of it.

A detection rule that alerts on powershell.exe -enc catches the lazy attacker and misses everyone else. Rename the binary, split the flag, encode it differently, and the rule goes silent while the attack runs. A rule that instead models the behavior, an encoded PowerShell command spawned by a Microsoft Office process, catches the technique no matter what the attacker renames.

A team ships a feature. The developers wrote it weeks ago, but it sat in a queue waiting for a separate operations team to provision servers, write deployment scripts by hand, and find a maintenance window. By the time it went live, the requirements had changed and a competitor had shipped something similar.

A team pushes forty deployments a day. One of them swaps a base container image for a tagged version that looks identical but carries an extra layer: a script that phones an external host on first run. The application works.

A pipeline ships forty times a day. Each change moves from a developer's commit through automated build, test, and deploy with no manual gate in the path. That is DevOps working as designed.

A pull request adds one line to a build script: a curl command that fetches a helper from an external URL during the build. The change passes review because it looks like a convenience. The build goes green.

Delete a file, empty the recycle bin, and most people assume it is gone. It is not. On an NTFS volume the operating system removes the file's entry from the master file table and marks its clusters as free, but the bytes sit untouched in unallocated space until something else overwrites them, which may be minutes or months later.