The SOC Analyst
Glossary

A finance team signs up for an expense tool on a Friday, connects it to the company Google Workspace with an OAuth grant, and shares a folder of receipts with "anyone with the link." No firewall saw it. No endpoint agent logged it. The security team learns the app exists three months later, when a researcher reports the receipts are publicly indexed.

An admin enables a third-party calendar plugin in Microsoft 365. To work, it asks for read access to every user's mailbox, and an end user with consent rights clicks accept. No password is phished, no malware runs, no firewall is touched.

Most breaches are not the failure of a single tool. They are the failure of how the tools fit together. A firewall that does not talk to the SIEM.

A phishing alert lands in the queue. Done by hand, an analyst pulls the reported email, extracts the URL and checks it against threat intelligence, looks up the sender's reputation, searches the mail logs for everyone else who received it, and quarantines the copies. Thirty minutes, maybe more, for one alert.

An attacker does not need a zero-day to get into most organizations. They need one person to click a link, approve a login they did not initiate, or wire money to a vendor whose email address changed by one character. Verizon's 2026 Data Breach Investigations Report, built on more than 22,000 confirmed breaches across 145 countries, found the human element involved in 62 percent of them.

Open the average SOC's tooling list and you will find thirty to seventy separate products. A firewall from one vendor, endpoint detection from another, a cloud posture tool, an email gateway, a SIEM, a sandbox, three threat-intelligence feeds, and a SOAR that is supposed to glue some of it together. Each one was bought to close a specific gap.

A single failed login means nothing. A firewall deny means nothing. A new service installed on a host means nothing.

The old security model had one perimeter: a firewalled network edge, with everything trusted inside it and everything hostile outside. That model broke the moment workloads moved to three clouds, users started logging in from home, and SaaS apps started holding the crown-jewel data outside the network entirely. The assets a defender has to protect no longer sit inside one boundary you can draw a box around.

It is 3 a.m. An alert fires: a service account just authenticated from an IP in a country your company does not operate in, then started enumerating file shares. The endpoint agent flagged a suspicious process minutes earlier.

A vulnerability scanner flags a critical CVE on a production database server Monday morning. The security team files a ticket and moves on. The IT operations team, measured on uptime and bonused on it, sees that patching means downtime and a maintenance window they have to fight for.

A user reports a phishing email. An analyst opens it, copies the sender, pastes it into a reputation tool, extracts the URL, checks it against a sandbox, pulls the attachment hash, searches the mail logs for everyone else who got the same message, deletes the copies, blocks the domain, and opens a ticket. Twelve steps, eight minutes, zero judgment required.

A misconfigured storage bucket, a service account with standing admin rights, a forgotten SaaS app holding customer data, and an unpatched internet-facing host all share one trait: each is a gap that exists right now, before any attacker shows up. Detection tools catch the intrusion. Posture management is about closing the gaps that make the intrusion easy in the first place.

A salesperson opens a SaaS CRM from a hotel Wi-Fi network, on a laptop that never touches the corporate VPN. The traffic goes straight from the browser to the vendor's cloud. The old security stack, the proxy in the data center, the firewall at the headquarters edge, the VPN concentrator, sees none of it.

A contractor signs in to your corporate identity provider once, in the morning. By noon their browser has presented credentials to a SaaS analytics app, an internal wiki, and an AWS account, and not one of those systems ever saw the contractor's password. Each handed off to something that vouched for the identity and minted a short-lived token scoped to exactly what that app was allowed to do.

Ask most teams where their customer Social Security numbers live and you get a confident answer that names two systems. The discovery scan then finds the same data in a forgotten staging database, a quarterly export sitting in a shared drive, an analyst's local spreadsheet, and a logging bucket nobody remembered turning on. The gap between what people believe and what is actually out there is the problem sensitive data discovery exists to close.

drafts/service-account-security.html obody logs into and nobody remembers. It was created years ago so an application could reach a database, set with a password that was never rotated, and granted broad rights "to be safe." It runs every day, never prompts for MFA, and sits outside every list of who-has-access-to-what. When an attacker lands in the environment, it is one of the first credentials they hunt for, because it is powerful, persistent, and unwatched.

The account that breaches you next may not be yours. It may belong to a managed service provider whose technician's laptop got phished last week, or a SaaS vendor whose support tooling holds a standing token into your tenant. You did not provision that laptop.

A marketing team needs to share large files with an agency, so someone signs up for a free Dropbox account and starts uploading customer lists. A developer spins up a personal cloud VM to test an idea over a weekend and leaves it running with a database open. An analyst pastes a quarter of sensitive contract text into a consumer AI assistant to summarize it.

An authentication bypass gets written on a Monday. With a static scanner wired into the developer's editor, it is flagged before the commit even lands, and the fix is a two-line change nobody outside the team ever hears about. Without that scanner, the same flaw clears review, builds, ships, and surfaces eight months later as a breach disclosure, a forensic engagement, and a line item in next year's audit.

The text says your package could not be delivered. It has a tracking link. You tap it on your phone while walking to a meeting, the page looks like the courier's site, and it asks for a card number to cover a small redelivery fee.

Your shift starts and the queue has 312 open alerts. By lunch it will have more. One of them is a service account authenticating from a country your company does not operate in, then touching file shares it has never touched before.

The intrusion did not start with an exploit. It started with a phone call to a help desk. The caller knew the employee's name, manager, and start date, all pulled from a public profile, and asked for a password reset because they were locked out before a meeting.

Open a browser, log in to Salesforce, and start working. Nobody on your team installed it, patched it, or racked a server for it. Salesforce wrote the code, runs it on its own infrastructure, ships every update, and keeps the lights on.

When Log4Shell broke on December 10, 2021, the first question in every SOC was not how to patch it. It was simpler and worse: do we even run Log4j, and where? CVE-2021-44228 scored a CVSS 10.0 and sat inside log4j-core, a logging library bundled three and four layers deep inside applications nobody thought of as "Java apps." Teams with an inventory of their software components answered in an afternoon.

Most of the code shipping in a modern application was not written by the team shipping it. A typical build pulls in hundreds of open-source packages, and each of those pulls in more. When one of them turns out to carry a known flaw, the way Log4j did with Log4Shell in late 2021, the question is not whether you should patch.

A single attacker can rent a botnet, load a list of ten million addresses, and push a campaign out for the price of a cheap server. If one in a hundred thousand recipients clicks, the campaign pays for itself many times over. That asymmetry is the whole reason spam exists.

The email opened with the name of a vendor the finance lead had paid eleven times that year. It referenced the right purchase order number, used the contact's real signature block, and arrived two days after a genuine invoice from the same supplier. The only change was a single line: updated remittance bank details, effective immediately.

A login form asks for a username and password. An attacker types ' OR '1'='1 into the username field and leaves the password blank. The application drops that text straight into a SQL query: SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''.

A single command is enough to take over a database. Point sqlmap at a vulnerable URL parameter with something like sqlmap -u "https://target.site/item.php?id=1" --dbs --batch, and it will fingerprint the backend, confirm the injection, enumerate every database and table, and dump the rows, often without the operator typing a line of SQL. That is sqlmap: an open-source tool that automates the detection and exploitation of SQL injection.

A developer commits a function that builds a SQL query by concatenating a user-supplied string. Nothing breaks. The tests pass, the build is green, the feature ships.

What Is a Supply Chain Attack? A supply chain attack, also known as a value-chain or third-party attack, occurs when someone infiltrates your system through an outside partner or provider with access to your systems and data. This type of attack can happen in any industry, from the financial sector to utilities and in public and private sectors.

In December 2020, around 18,000 organizations downloaded a routine update to SolarWinds Orion. The update was signed, it came from the vendor's own build system, and it carried a backdoor the attackers had planted inside the build pipeline. None of the victims had a vulnerability of their own to patch.

When SolarWinds was compromised in 2020, the malicious code rode in through a signed software update that around 18,000 organizations installed without a second look. The update was legitimate by every check those organizations ran. The problem was not the update.

A SOC analyst opens the process list on a flagged host and sees svchost.exe running. Nothing unusual, every Windows machine runs many copies of it. Then the analyst checks where it launched from: C:\Users\Public\svchost.exe, not C:\Windows\System32.

Mandiant's M-Trends 2026 report draws on more than 500,000 hours of incident response from 2025. In it, financially motivated groups make up the single largest share of the activity Mandiant tracked, around 41 percent of all observed threat clusters. That one number reframes the whole defense problem.

No alert fired. The dashboards are green. A hunter starts anyway, with a hunch: an attacker who got in would try to run code in memory to dodge antivirus, and on Windows the easiest way is encoded PowerShell.

A SOC subscribes to five threat feeds. One arrives as a CSV of malicious IPs. One is a STIX/TAXII stream of indicators.

In 2024 the average time for an intruder to move from the first compromised machine to a second one was around 48 minutes. In CrowdStrike's 2026 Global Threat Report it is 29 minutes, and the fastest case they recorded was 27 seconds. That single number is the threat landscape doing what it always does: shifting under the defenders who have to live on it.

A login service hashes passwords, rate-limits attempts, and logs every failure. It looks secure. Then someone draws the data flow and notices the password-reset endpoint trusts an email address from the request body, never re-checks the session, and emits a reset token over an unauthenticated GET.

At 3 a.m., an alert fires: a server that normally talks only to internal systems just opened an outbound connection to a domain registered last week. An on-call analyst sees it, pulls the connection history, confirms the server is beaconing, and isolates it before sunrise. The intrusion that could have run for months, quietly siphoning data until a customer or a regulator delivered the bad news, is contained on night one.

A scanner returns 4,000 findings. The SIEM throws 600 alerts in a shift. The vulnerability feed adds a few hundred new CVEs a week.

A payment processor stores 40 million card numbers. An attacker who reaches that database walks away with 40 million usable cards. Now change one thing: the database holds tok_8f2a91c4d7 instead of 4111 1111 1111 1111.

An attacker does not always need the password. In an adversary-in-the-middle phishing run, the victim types the password, passes the multi-factor prompt, and the proxy in the middle copies the thing the server hands back: a session token. From that point the attacker replays the token and is logged in as the user.

A user double-clicks what looks like a Zoom installer. It installs nothing useful. Behind the splash screen, a second process drops a payload, writes a registry run key, and opens a channel to an IP in another country.

A studio will not hand an unreleased film to a post-production house on trust alone. Before a vendor touches a pre-release cut, a script, or dailies, the studio wants evidence that the vendor's facility, network, and people will not be the reason that content leaks. The Trusted Partner Network (TPN) audit is how that evidence gets produced: a structured assessment of a media and entertainment vendor against a published content security standard, run through a shared platform so every studio that vetted the vendor can read the same result.

A valid password is no longer evidence of a valid user. Infostealer logs sell for a few dollars, combo lists circulate by the billion, and a convincing login page harvests credentials the moment someone types them. By the time a stolen password reaches an attacker, the only thing standing between them and the account is whatever else the login demands.

A user means to type paypal.com. They hit paypa1.com instead, with a digit 1 standing in for the letter l. The page looks identical.

On March 7, 2017, the Apache Software Foundation shipped a patch for CVE-2017-5638, a remote code execution flaw in Apache Struts 2. Equifax did not apply it. Two months later, attackers used that exact flaw to get in, moved through the network, and walked out with personal data on roughly 147 million people.

export const frontmatter = { title: "What Is Unstructured Data? A SOC Analyst's Guide", description: "Unstructured data is the 80-90% of enterprise data with no fixed schema. Learn what it is, why it matters for SIEM, and how to make it searchable.", date: "2026-06-21", author: "CyberDefenders", tags: ["siem", "log-analysis", "threat-detection", "fundamentals"], readingTime: 9, image: "/blog-unstructured-data.png" }; A firewall log line fits neatly into columns: timestamp, source IP, destination IP, port, action.

In late 2024, an attacker logged into PowerSchool's customer support portal with a single stolen credential and reached a school-information system holding records on tens of millions of students and teachers. No malware fired. No exploit ran.